esMD Background

Phase I of esMD was implemented in September of 2011. It enabled Providers to send Medical Documentation electronically

Review Contractor

Provider

Request Letter

Paper Medical Record

Phase 1: Doc’n

Request Letter

electronic

electronic

electronicPhase 2:

Before esMD: Healthcare payers frequently request that providers submit additional medical documentation to support a specific claim(s). Until recently, this has been an entirely paper process and has proven to be burdensome due to the time, resources, and cost to support a paper system.

The Electronic Submission of Medical Documentation (esMD) initiative is developing solutions to support an entirely electronic documentation request.

esMD eMDR Process Flow

The overall esMD eMDR process can be divided into three steps:

• A provider registers with a payer to receive electronic medical documentation requests (eMDRs) -- must have valid S&I Use Case 2 compliant directory entry with ESI supporting end point for eMDR profile

1. Register to Receive eMDRs

• A payer sends an eMDR to a registered provider’s current ESI obtained from designated PD

2. Send eMDRs • A provider electronically sends medical documentation to a payer in response to an eMDR

3. Send Medical Documentation

esMD Phase 2 esMD Phase 1

• Use Case 1 – Provider Registration with Payer to receive eMDRs

esMD UC1/2 Summary

• Use Case 2 – Secure Transportation and Structured Content of eMDRs

esMD UC1/2 Summary

S&I Framework esMD eMDR Overview

Provider EntityPayer Entity

PayerProvider

(Individual or Organization)

Contractors / Intermediaries Agent

Payer Internal System

Gat

eway

esMD UC 2: Secure eMDR Transmission

esMD UC 1: Provider Registration

esMD AoR Level 1Digital Identities Bundle Signatures

Certificate Authority

Registration Authority

Provider Directories

User Story • All Actors obtain and

maintain a non-repudiation digital identity

• Provider registers for esMD (see UC1)

• Payer requests documentation (see UC2)

• Provider submits digitally signed document (bundle) to address request by payer

• Payer validates the digital credentials, signature artifacts and, where appropriate, delegation of rights

AoR -- Phased Scope of WorkLevel 1 – Current Focus

Level 2 - TBD

Level 3 - TBD

Digital signature on aggregated documents

(bundle)

Digital signature to allow traceability of individual

contributions to a document

Digital signature on an individual document

• Focus is on signing a bundle of documents prior to transmission to satisfy an eMDR

• Define requirements for esMD UC 1 and UC 2 Signature Artifacts• May assist with EHR Certification criteria in the future

• Focus is on signing an individual document prior to sending or at the point of creation by providers

• Will inform EHR Certification criteria for signatures on patient documentation

• Focus is on signing documents and individual contributions at the point of creation by providers

• Will inform EHR Certification criteria for one or multiple signatures on patient documentation

Underlying Challenge:• Enable provider capture of documentation and benefit determination based on

payer rules• Secure exchange of templates, decision support, and documentation between

payers, providers, service suppliers and beneficiary

Scope:• Define the use case, user stories and requirements supporting a standards-based

architecture• Reuse of existing S&I Initiative efforts• Creation of structured data capture templates and supporting exchange standards• Power Mobility Device as initial User Story

Outcome:• Successful pilot of templates, decision support, information exchange standards over

standard secure transactions for the purpose of determining coverage • Validation with initial Generic Use Case through user stories such as Power Mobility Device

Electronic Determination of Coverage (eDoC)

esMD Landscape

Phase Use Case Status Approach Data Relevant Standards

1 Send Medical Documentation

Closed Unstructured - Clinical- Billing- Admin

- X12 275 & PDF- XD*, C62, & PDF

2 Register to receive eMDRs

Closed Structured - Admin - X12 274- XD* & HPD

2 Send eMDRs Closed Structured - Billing- Admin

- X12 277

2 Author of Record(L1, L2, L3)

Harmonization Structured - Admin - CDA- XAdES-X-L & XML-DSIG- SAML 2.0

3 eDoC Harmonization Structured - Clinical- Billing- Admin

- X12 275- XD* & CDA

• Each step in the esMD Process requires the exchange of specific types data

esMD Data Requirements

• Provider Identification• Electronic Service Information

Administrative Data

• Claim Number• Claim Date

Billing Data

• Patient Identification• Procedures Performed

Clinical Data

Register to Receive eMDRs

Send eMDRs

Send Medical Documentation

Transport Standards

CONNECT

DIRECTX12 Core

Electronic Submission of Medical Documentation (esMD) Supporting Multiple Transport Standards and Provider

Directory

ECM

Content Transport Services

Payer / Payer Contractors

Internal PD

EHR / HISP

DirectCompatible

Direct

EDITranslator

HIHCONNECT

Compatible

Practice Management

Systems and ClaimsClearinghouse

EDI – CAQH CORECompatible

Federated External

PD

Purpose Standard

Register with CMS to receive eMDRs ASC X12N 274

Register with Commercial Payers to receive eMDRs

ASC X12N 274IHE HPD Plus

UC 1 Standards

Transport Payload UserPhase II CAQH CORE Rule 270 (Connectivity Rule 2.2.0) ASC X12N 274 Commercial

eHealth Exchange with CORE X12 Document ASC X12N 274 CMS/Commercial

eHealth Exchange HPD Plus Commercial

Direct ASC X12N 274HPD Plus

Commercial

Purpose Standard

Payer/Contractor sends eMDR to Provider/Agent

ASC X12N 277

Register with Commercial Payers to receive eMDRs

ASC X12N 274IHE HPD Plus

UC 2 Standards

Transport Payload UserPhase II CAQH CORE Rule 270 (Connectivity Rule 2.2.0) ASC X12N 277 Commercial

eHealth Exchange with CORE X12 Document ASC X12N 277 CMS/Commercial

Direct ASC X12N 274HPD Plus

Commercial

UC 1/2 Standard Message Components

Phase II CAQH CORE 270 eHealth Exchange

SMTP

XDM Submission Set Metadata

XDM Document Metadata

X12 277 Message

S/MIME AttachmentZip File

esMD Security Metadata

Direct

Standards Used

Payload- ASC X12N 274- ASC X12N 277- IHE HPD Plus- Directory Services Markup Language (DSML v2)

Transport- eHealth Exchange (NwHIN) / CONNECT- CAQH CORE Connectivity Rule 2.2.0- Direct - IHE XD* (XDR, XDS, XDM)

Considerations for eDoCPurpose Payload Transport User

Claims

Orders

Results

Reimbursement

Eligibility

Prior Authorization

Request for DocumentationDocumentation for SubmissionMetadata

Considerations for eDoC• Payload – the clinical documentation

• C-CDA (structured and unstructured document templates)• Current ballot for C-CDA R2

• Messaging Standards – required by HIPAA• X12 275

• not yet required by HIPAA

• X12 278? • Will need to check• Can be used to request additional information about a prior auth, but that

information would be sent back as a 275

• X12 277 – request for information (claims attachment)• not yet required by HIPAA

• X12 837 with 275 • PWK section in the 837 will specify the association between the two

• IHE XDR? (need to determine which category)

Considerations for eDoC• Operating Rules

• CAQH CORE• Metadata• Conformance and participation standards

• Transports (content-neutral—not dependent on the information transported)• Direct (SMTP)• CONNECT / eHealth Exchange (Healtheways)• SOAP• RESTful

• Security• OAuth (for RESTful)• SAML (for CONNECT or SOAP)• S/MIME for SMTP• IHE DSG

• Document Management• IHE XDS

Use Cases for “Attachments”• Use Cases

• Support for claims• Prior authorization• Post-payment review• Clinical exchange• Care coordination / management• Fraud / waste prevention• Quality management

• Coordination with HL7 Attachments WG to prevent duplication of effort• HL7 Informative guide dated June 2013

• Coordination with Author of Record• HL7-balloted CDA IG for Digital Signatures / DoR

Other Considerations• Authentication• Audit trails• Compliance• Certification