1. 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 Phase 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.

2. esMD eMDR Process Flow The overall esMD eMDR process can be divided into three steps: esMD Phase 2 esMD Phase 1

3. Use Case 1 – Provider Registration with Payer to receive eMDRs esMD UC1/2 Summary

4. Use Case 2 – Secure Transportation and Structured Content of eMDRs esMD UC1/2 Summary

5. S&I Framework esMD eMDR Overview Provider Entity Payer Entity Payer Provider (Individual or Organization) Provider (Individual or Organization) Contractors / Intermediaries Agent Payer Internal System Gateway esMD UC 2: Secure eMDR Transmission esMD UC 1: Provider Registration esMD AoR Level 1 Digital 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

6. AoR -- Phased Scope of Work Level 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

7. 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)

8. esMD Landscape PhaseUse CaseStatusApproachDataRelevant Standards 1Send Medical Documentation ClosedUnstructured- Clinical - Billing - Admin - X12 275 & PDF - XD*, C62, & PDF 2Register to receive eMDRs ClosedStructured- Admin- X12 274 - XD* & HPD 2Send eMDRsClosedStructured- Billing - Admin - X12 277 2Author of Record (L1, L2, L3) HarmonizationStructured- Admin- CDA - XAdES-X-L & XML- DSIG - SAML 2.0 3eDoCHarmonizationStructured- Clinical - Billing - Admin - X12 275 - XD* & CDA

9. Each step in the esMD Process requires the exchange of specific types data esMD Data Requirements Register to Receive eMDRs Send eMDRs Send Medical Documentation

10. Transport Standards CONNECT DIRECT X12 Core

11. Electronic Submission of Medical Documentation (esMD) Supporting Multiple Transport Standards and Provider Directory ECM Content Transport Services Payer / Payer Contractors Internal PD EHR / HISP Direct Compatible Direct EDI Translator HIH CONNECT Compatible Practice Management Systems and Claims Clearinghouse EDI – CAQH CORE Compatible Federated External PD Federated External PD

12. PurposeStandard Register with CMS to receive eMDRsASC X12N 274 Register with Commercial Payers to receive eMDRs ASC X12N 274 IHE HPD Plus UC 1 Standards TransportPayloadUser Phase II CAQH CORE Rule 270 (Connectivity Rule 2.2.0)ASC X12N 274Commercial eHealth Exchange with CORE X12 DocumentASC X12N 274CMS/Commercial eHealth ExchangeHPD PlusCommercial DirectASC X12N 274 HPD Plus Commercial

13. PurposeStandard Payer/Contractor sends eMDR to Provider/Agent ASC X12N 277 Register with Commercial Payers to receive eMDRs ASC X12N 274 IHE HPD Plus UC 2 Standards TransportPayloadUser Phase II CAQH CORE Rule 270 (Connectivity Rule 2.2.0)ASC X12N 277Commercial eHealth Exchange with CORE X12 DocumentASC X12N 277CMS/Commercial DirectASC X12N 274 HPD Plus Commercial

14. UC 1/2 Standard Message Components Phase II CAQH CORE 270 eHealth Exchange Direct

15. 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)

16. Considerations for eDoC PurposePayloadTransportUser Claims Orders Results Reimbursement Eligibility Prior Authorization Request for Documentation Documentation for Submission Metadata

17. 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)

18. 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

19. 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

20. Other Considerations Authentication Audit trails Compliance Certification