Electronic Submission of Medical Documentation (esMD) Technical Overview

1. 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 Monday 4:15 P.M.

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

3. Today’s Medical Documentation Process Doc’ n Request Letter Review Contractor Paper Medical Record Provider

4. The Solution: Electronic Submission of Medical Documentation (esMD) Phase 1: Doc’n Request Letter electronic Phase 2: electronic electronic

5. CMS Does Not Dictate How an HIH Communicates with Providers • 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 Onside Pickup VPN http://directproject.org D I R E C T http://wiki.directproject.org D I R E C T

6. esMD Phase 1 (In Production) : September 2011 Medicare Recovery Auditors Doc’ n Request Letter Medicare Administrative Contractors PERM PDF PDF PDF DIRECT CMS Private Network Content Transport Services SOAP Message with SAML/XDR ECM CONNECTCompatible ECM Built by SOAP Message with SAML/XDR esMD Gateway Built by esMD Metadata Database

7. esMD Phase 2: October 2012 Medicare Recovery Auditors Medicare Administrative Contractors PERM PDF Structured Electronic Requests for Medical Documentation PDF XML PDF DIRECT CMS Private Network Content Transport Services SOAP Message with SAML/XDR CONNECTCompatible ECM ECM Built by SOAP Message with SAML/XDR esMD Gateway Built by esMD Metadata Database

8. Definition of an esMD Package • A portion of a patient’s medical record in esMD format which will contain: • Imaged documents (PDF) • Important Metadata Fields: • Intended Recipient – Required Field • Claim ID – Required Field • NPI – Required Field • Case ID – Required If Known Detailed description for each field can be found in: • the esMD XDR Profile. • the esMD Implementation Guide. (http://www.connectopensource.org/product/connect-NHIN-specs) (www.cms.gov/esMD)

9. esMD Technical Details • 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, responsesand 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

10. Current esMD XDR Transportand Translation Mechanism

11. esMD XDR Implementation

12. esMD XDR Profile and its references • IHE XDR Specification • NHIN Message Platform Specification • NHIN Authorization Framework Specification • NHIN Document Submission Specification • esMD XDR Profile • How does esMD implement the XDR Transport and Translation Mechanism?

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

14. esMD XDR Document Submission Message Flow – In Deferred Message Mode • 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:

15. Sample Message: XDR Document Submission SOAP Envelope

16. In Sept 2011, esMD successfully implemented the IHE XDR Profile with inbound ADR Use Case. • So, What's Next? • Future esMD Use Cases • How will esMD accommodate ASC X12 transactions? • Does CONNECT Support ASC X12 Transactions? • 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.

17. 17 Current and Future Use Casesfor esMD We Are Here • INBOUND • 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

18. How to accommodate ASC X12 transactions through the esMD Gateway? • 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.

19. esMD XDR & CAQH CORE Transport and X12 Translation Mechanism

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

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

23. NHIN CAQH CORE X12 Deferred Document Submission (using three CAQH CORE Connectivity Generic Batch message interactions) Communication with Multiple SOAP over HTTP/S Connections

24. Can X12 Message be sent through the XDR Transactions?

25. QUESTIONS?For more information, please contact: • Melanie Combs-Dyer, RN • Deputy Director,CMS/OFM/Provider Compliance Group • melanie.combs-dyer@cms.hhs.gov • Dan Kalwa • Health Insurance Specialist, • daniel.kalwa@cms.hhs.gov • Manoj Chaganti • esMD Chief Architect, CMS/QSSI • mchaganti@qssinc.com • Phone: 847 903 5432

26. esMD System Architecture CMS QSSI esMD Project Confidential Document – Pl. contact Manoj Chaganti, mchaganti@gssinc.com , 847 903 5432 XDR & X12 HIH XDR HIH X12 HIH ….. < -- X12 Trading Partner Agreement (TPA) Use Case -- ….. ------ X12 Appeals Use Case ---  ------XDR Orders Use Case ---  ------ X12 Orders Use Case ---  ------ XDR Appeals Use Case ---  < -- X12 Trading Partner Agreement (TPA) Use Case -- ------ X12 ADR Use Case ---  ------ XDR ADR Use Case ---  CONNECT 3.x XDR Inbound Request /Outbound Response - NHIN Orchestration Document Submission CAQH CORE X12 Inbound Request / Outbound Response- NHIN Orchestration Document Submission XDR Transporter CAQH CORE Transporter ESMD Gateway X12 Translator esMD Translation / Statistical and Business Logic Application