Electronic Submission of Medical Documentation (esMD) Technical Overview

MELANIE COMBS-DYER, RN - Deputy Director, CMS/OFM/Provider Compliance Group

DANIEL KALWA - Health Insurance Specialist, CMS/OFM/Provider Compliance Group

MANOJ CHAGANTI - esMD Chief Architect, CMS/QSSI

RANJITH MADHUSOODANAN - esMD Project Manager, CMS/QSSI

MICHAEL FINKEL - esMD Project Director, CMS/QSSI

Monda

y

4:15

P.M

.

Agenda

• Technical Overview

▫ esMD Business Functionality

▫ Overview of XDR esMD Transporter and Translation Mechanism

▫ Future esMD Enhancement / Use Cases

▫ Overview of CAQH CORE Transport and X12 Translation Mechanism

▫ If time permits: Discussion as to whether X12 Message can be sent through the XDR Transactions.

2

Today’s Medical Documentation Process

3

Review Contractor

Provider

Doc’ n Request

Letter

Paper Medical Record

The Solution: Electronic Submission of Medical

Documentation (esMD)

4

Phase 1: Doc’n

Request Letter

electronic

electronic

electronic

Phase 2:

5

esMD HIHs ingest provider's medical records and metadata by either one of the following:

• going onsite to the provider's facility

• using a Virtual Private Network (VPN)

• using a secure web portal

Some esMD HIHs are considering using DIRECT.

Web Portal

VPN

CMS Does Not Dictate How an HIH Communicates with Providers

D I R E C T

D I R E C T

D I R E C TD I R E C T

Onside Pickup

http://wiki.directproject.org

http://directproject.org

esMD Phase 1 (In Production) : September 2011

6

esMDGateway Built by

ECM Built by

ECM

CONNECTCompatible

Doc’ n RequestLetter

MedicareAdministrative

Contractors

Medicare Recovery Auditors PERM

Content Transport Services

CMS Private Network

PDF PDF PDF

esMD Metadata Database

SOAP Message with SAML/XDR

SOAP Message with SAML/XDR

DIRECT

esMD Phase 2: October 2012

7

esMDGateway Built by

ECM Built by

ECM

CONNECTCompatible

MedicareAdministrative

Contractors

Medicare Recovery Auditors PERM

Content Transport Services

CMS Private Network

XML PDF PDF

esMD Metadata Database

SOAP Message with SAML/XDR

SOAP Message with SAML/XDR

DIRECT

Structured Electronic Requests for Medical

Documentation PDF

Imaged documents (PDF)

Important Metadata Fields:• Intended Recipient – Required Field• Claim ID – Required Field• NPI – Required Field• Case ID – Required If Known

A portion of a patient’s medical record in esMD format which will contain:

Definition of an esMD Package

8

Detailed description for each field can be found in: the esMD XDR Profile. the esMD Implementation Guide. (www.cms.gov/esMD)

(http://www.connectopensource.org/product/connect-NHIN-specs)

esMD Technical Details

9

System (HIH) to System (CMS) Gateway Communication HIH Submits XDR (Deferred Document Submission) SOAP Envelope Request to CMS

CONNECT gateway with the following details: SAML Assertions and its digital signature, Security Tags in the SOAP Header, IHE XDR and esMD Meta Data within the SOAP Body, MTOM Encoded C62 Payload in the SOAP Body.

SAML Assertions shall contain the HIH Organization Identifier (OID), Review Contractor Organization Identifier (OID), NPI Provider Identification, etc.

Authentication HIH IP Address validation, Mutual TLS v1.0 certificate validation (later used for encryption and decryption

of request, responses and its digital signatures), Exchange and validate FIPS 140/2 TLS Cipher Suites, Timestamp and SAML Digital Signature validation, HIH OID and Intended Review Contractor validation against HIH and CMS

Review Contractor OIDs based on the CMS onboarding Process, Message and payload integrity verification based on the base 64 encoding -

MD5 digest/hashcode algorithms. Authorization

HIH OID and Intended Recipient OID against the esMD CMS on-boarded data. Up to 19MB of PDF Payload size

Current esMD XDR Transport

and Translation Mechanism

10

11

esMD XDR Implementation

esMD XDR Profile and its references

12

IHE XDR SpecificationNHIN Message Platform SpecificationNHIN Authorization Framework SpecificationNHIN Document Submission SpecificationesMD XDR Profile

How does esMD implement the XDR Transport and Translation Mechanism?

Adapting CONNECT 3.1 XDR (Deferred Document Submission) Transportation and Translation Mechanism

13

esMD XDR Document Submission Message Flow – In Deferred Message Mode

14

Using the Health Information Handler (HIH) Gateway, the provider submits a claim document response to a single CMS Additional Documentation Request Letter (ADR), using the Document Submission deferred request (as a part of deferred messaging flow).

esMD implements the NHIN Document Submission with Deferred Messaging mode. In a deferred mode, the Document Submission is a two-way message as shown in the diagram below:

Sample Message: XDR Document Submission SOAP Envelope

15

16

So, What's Next? • Future esMD Use Cases• How will esMD accommodate ASC X12 transactions?

o Does CONNECT Support ASC X12 Transactions?o Are there any NHIN profiles to support the ASC X12 Transactions?

• How will esMD allow outbound transactions from CMS esMD Gateway to HIH in compliance with FISMA and other security requirement?

• Identify the Technical requirements to expand the esMD Use Cases.

• Provider Profile/ Provider Naming Service, etc.

In Sept 2011, esMD successfully implemented the IHE XDR Profile with inbound ADR Use Case.

17

Current and Future Use Casesfor esMD

We Are HereINBOUND Responses to Documentation Request Letters in PDF Appeal Requests in PDF Unsolicited Documentation in PDF (called paperwork or “pwk”) Structured Orders, Progress Notes, ADMC Requests Structured esMD Phase 2 Registration etc

OUTBOUND Structured Outbound Documentation Requests Review Results Letters Demand Letters etc

LOOKUP Request\Receive Documentation Status Request\Receive Claim Status Request\Receive Appeals Status Request\Receive Eligibility Info etc

17

18

Need to build CAQH Transport service (Parallel to XDR) in the CONNECT software by adopting Phase II CORE 270: Connectivity Rule version 2.2.0 specifications.

Develop NHIN CAQH CORE X12 Document Submission Profile (Similar to XDR Document Submission)

Develop the esMD X12 Profile based NHIN CAQH CORE X12 Document Submission Profile.

Implement the NHIN CAQH CORE X12 Document Submission Service with in the CONNECT.

Identify the ASC X12 Translator software to process the X12 Messages.

How to accommodate ASC X12 transactions through the esMD Gateway?

esMD XDR & CAQH CORE Transport

and X12 Translation Mechanism

19

20

Sample Message: CAQH Phase II CORE 270: Connectivity Rule version 2.2.0 - X12 824 Application Advice Forwarded Acknowledgment SOAP Envelope

21

Enhance CONNECT 3.1 with CAQH Phase II CORE 270: Connectivity Rule version 2.2.0 Transport Mechanism and esMD X12 Translator

22

NHIN CAQH CORE X12 Deferred Document Submission (using three CAQH CORE Connectivity Generic Batch message interactions) Communication

with Multiple SOAP over HTTP/S Connections

23

Can X12 Message be sent through the XDR Transactions?

24

QUESTIONS?

For more information, please contact:

25

• Melanie Combs-Dyer, RNDeputy Director,CMS/OFM/Provider Compliance Groupmelanie.combs-dyer@cms.hhs.gov

• Dan KalwaHealth Insurance Specialist,daniel.kalwa@cms.hhs.gov

• Manoj ChagantiesMD Chief Architect, CMS/QSSImchaganti@qssinc.comPhone: 847 903 5432

CONNECT 3.x

esMD System Architecture

XDR HIH

CMS QSSI esMD Project Confidential Document – Pl. contact Manoj Chaganti, mchaganti@gssinc.com , 847 903 5432

XDR Inbound Request

/Outbound Response - NHIN

Orchestration Document

Submission

CAQH CORE X12 Inbound Request / Outbound

Response- NHIN Orchestration

Document Submission

------ XDR ADR Use Case ---

------ XD

R A

ppeals Use C

ase --- ------X

DR

Ord

ers Use C

ase ---

------ X12 A

DR

Use C

ase --- ------ X

12 Ap

peals U

se Case ---

------ X12 O

rders U

se Case ---

< --

X12

Tra

ding

Par

tner

Agr

eem

ent

(TPA

) Use

Cas

e --

< -

- X

12

Tra

din

g P

art

ner

Ag

ree

men

t(T

PA

) U

se

Ca

se -

-

X12 HIHXDR & X12 HIH

X12 Translator

…..…..

ESMD Gateway

XDR Transporter CAQH CORE

Transporter

esMD Translation / Statistical and Business Logic Application

26