esMD+Profile+Definition

=Electronic Submission of Medical Documentation (esMD)= =Profile Definition- V 0.0.4 8/23/2010= =Preface=

**Introduction**
For 2009 the Medicare fee-for-service (FFS) program made an estimated $24.1 billion in improper payments. Medicare review contractors compare the claims submitted by Medicare providers against entries in medical records to measure, prevent and correct improper payments.

 · **RACs identify and correct improper payments. **Recovery Audit Contractors (RACs) conduct post-payment review by comparing information from medical records to Medicare claims. The Centers for Medicaid & Medicare Services (CMS) estimates that RACs will request over 1 million medical records from providers each year.

 · **MACs prevent improper payments. **Medicare Administrative Contractors (MACs) conduct pre-payment and post-payment reviews of Medicare FFS claims. CMS estimates that MACs will request several thousand medical records per year. Prior to the Electronic Submission of Medical Documentation (esMD) Phase 1 pilot, the provider had three choices when responding to these documentation requests: mail paper, mail a CD containing a Portable Document Format (PDF) or Tag Image File Format (TIF) file, or transmit a fax. The esMD pilot will give providers an additional option for responding to these requests for medical documentation: electronic transmission via the Nationwide Health Information Network (NHIN). More details about esMD data exchange can be found in the esMD Implementation Guide (see www.CONNECTopensource.org/esMD).

Intended Audience
The primary audiences for this document include:  · Medicare Review Contractors that will receive medical documentation in esMD format sentby Health Information Handlers on behalf of Medicare providers,  · Developers of software that aim to assist Medicare Review Contractors in viewing and more efficiently processing documents received in esMD format,  · Health Information Handlers that will send medical documentation in esMD format to the Medicare Review Contractors on behalf of Medicare providers,  · Developers of Electronic Health Records (EHR) extraction software that assist Health Information Handlers more easily extract data from EHRs into the esMD format. It is assumed that the readers have prior knowledge of Health Information Technology Standards Panel (HITSP)/C62 **<span style="font-family: 'Arial','sans-serif';">Clinical ** **<span style="font-family: 'Arial','sans-serif';">Document ** **<span style="font-family: 'Arial','sans-serif';">Architecture ** (CDA) formats.

Business Needs Supported <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The esMD Phase 1 pilot will support the submission of documentation by providers such as physicians and hospitals to a limited number of Medicare Review Contractors. <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The purpose of this profile is to describe the esMD CDA formats and messaging formats and provide background information about the underlying standards upon which the esMD formats are based. It is intended to: <span style="display: block; line-height: normal; margin: 0in 0in 8pt 39.75pt; mso-list: l4 level1 lfo3; text-indent: -0.25in;"> · <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Communicate the data requirements necessary for Electronic Health Record (EHR) vendors to incorporate into the design and development of their EHR products, and <span style="display: block; line-height: normal; margin: 0in 0in 8pt 39.75pt; mso-list: l4 level1 lfo3; text-indent: -0.25in;"> · <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Serve as the roadmap for Health Information Handlers (HIHs) such as Regional Health Information Organizations (RHIOs), Health Information Exchanges (HIEs), Release of Information (ROI) vendors, and claim clearinghouses to use on behalf of providers submitting documentation to Medicare Review Contractors. <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Only a limited number of HIHs will be selected to participate in the esMD Phase 1 Pilot. <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">This esMD profile describes the **content** rules (e.g. what goes in which fields) and **submission** rules (e.g. how to address the packages, etc) for the esMD pilot. CMS will develop a different document called an "esMD Implementation Guide" to provide more detail such as contractor numbers, etc.
 * <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">NOTE: This document will refer to RHIOs, HIEs, ROI vendors, claim clearinghouses and others entities that move health information over NHIN gateways on behalf of health care providers known as “Health Information Handlers.” ||

Referenced Documents and Standards
The following documents and standards were referenced during the development of this profile. Specific deviations from or constraints upon these standards are identified below.

1) **Org/SDO name:** HITSP **Reference # / Spec Name:** C62 Unstructured Document Component  **Version #:** v.1.1  **NHIN Deviations or Constraints: None**  **Underlying Specs: None**  **Link:**  []

2) **Org/SDO name:** Centers for Medicare & Medicaid Services **Reference # / Spec Name:** esMD Implementation Guide  **Version #:** v.1.0  **NHIN Deviations or Constraints: None**  **Underlying Specs: None**  **Link:**  At the time this document was published, the esMD Implementation Guide was not yet published by CMS. This document will be updated once the Implementation Guide is available.

3) **Org/SDO name:** NHIN **Reference # / Spec Name:** Document Submission Emergence Pilot Specification  **Version #: v.1.1.0**  **NHIN Deviations or Constraints:**   · Deviation from XDS Metadata defined within IHE ITI TF-3 Rev. 6.0 as described in section 3.2 “Submission Specifications”  **Underlying Specs:** IHE Cross-Enterprise Document Reliable Interchange  **Links:**  []

4) **Org/SDO name:** X12 **Reference # / Spec Name:** ASC X12N/005010X210  **Version #: Version 5, Release 1 (July 2007 Draft)**  **NHIN Deviations or Constraints:**   · Deviation from as described in section 4.2 “Submission Specifications”  **Underlying Specs:** IHE Cross-Enterprise Document Reliable Interchange  **Links:** [|www.wpc-edi.com].

Relationship to other NHIN Specifications
This profile is related to other NHIN specifications as described below:

· **Messaging Platform –** specifies a base set of messaging standards and web service protocols which must be implemented by each NHIN node and applies to all transactions. All NHIN inter-nodal messages are Simple Object Access Protocol (SOAP) messages over Hypertext Transfer Protocol (HTTP) using web services, must be encrypted and digitally signed. · **Authorization Framework** – defines the exchange of metadata used to characterize each NHIN request. The purpose of that exchange is to provide the responder with the information needed to make an authorization decision for the requested function. Each initiating message must convey information regarding end user attributes and authentication using Security Assertion Markup Language (SAML) 2.0 assertions. Together, the Messaging Platform and the Authorization Framework define the foundational messaging, security and privacy mechanisms for the NHIN.

· **Document Submission** – allows an initiating NHIN node to “push” one or more patient-centric documents to another node. The esMD profile specifies use of this mechanism for the submission of PQRI program data from healthcare providers to CMS.

=Profile Definition=

This profile defines how esMD program data may be submitted by healthcare providers to the U.S. CMS using the NHIN. The profile also describes how feedback pertaining to these submissions may be sent by CMS to healthcare providers. <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The approach taken in the development of this specification was to balance the needs of: <span style="display: block; line-height: normal; margin: 0in 0in 8pt 29pt; mso-list: l3 level1 lfo4; text-indent: -0.25in;"> · <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Medicare Review Contractors that desire to receive all data in a structured format to facilitate the review of Medicare claims, and <span style="display: block; line-height: normal; margin: 0in 0in 8pt 29pt; mso-list: l3 level1 lfo4; text-indent: -0.25in;"> · <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Many HIHs that still retain some patient records in an unstructured format (such as imaged pdf files or tif files). <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">As a result of this balanced approach, the esMD Phase I pilot will accept medical documentation only in the following format:
 * **Name of Specification** || **Purpose** || **Structured/ Unstructured** || **Section in Document** ||
 * <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 10pt; text-align: center;">C62 CDA || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">For submitting **any type** of documentation in pdf or tif format  || <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 10pt; text-align: center;">Unstructured  || <span style="display: block; font-family: 'Arial','sans-serif'; font-size: 10pt; text-align: center;">Section 3  ||

<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The U.S. HITSP identified Health Level 7 (HL7) CDA R2 as the exchange standards for the electronic movement of health-related information among organizations according to nationally recognized standards. The CDA documents are well-known to the EHR vendors and there is an existing certification process by Certification Commission for Healthcare Information Technology (CCHIT) for generation and consumption of CDA documents by EHR systems.

Design Principles and Assumptions

The following assumptions or design principles underlie this profile:

· **The provider decides what to submit**. In both the current paper process and the new esMD process, the Medicare Review Contractor does not specify what the provider must send. It is up to the provider to decide which documents to send. This often includes discharge summaries, progress notes, orders, radiology reports, lab results, etc. · **The esMD Phase I pilot will allow providers to send structured and unstructured documents**. The provider will have the option of sending structured documents or unstructured documents (imaged documents in pdf or tif format). · **One Way Transmission: Provider-to-Review Contractor.** The esMD Phase I pilot will be unidirectional (provider-to-Medicare Review Contractor). Future phases will allow the Medicare Review Contractor to send the documentation request letter to the provider electronically. · **Each package must contain documentation about a single Medicare beneficiary.** Throughout this profile, the term “package” will be used to refer to one or more documents associated with a single beneficiary. Each package can contain multiple documents so long as all documents are related to the same beneficiary. The technical term for a package is a “SOAP message.”

Technical Pre-conditions No technical pre-conditions have been identified specifically for this profile beyond those given in referenced specifications.

Technical Post-conditions

No technical post-conditions have been identified specifically for this profile beyond those given in referenced specifications.

=﻿NHIN Exchange of esMD Data in 275 Format=

This profile utilized the NHIN Document Submission service interface specifications.

Authentication Framework
esMD will follow the ASC X12 Additional Information to Support a Health Care Claim or Encounter (275) Format (ASC X12N/005010X210, Based on Version 5, Release 1, July 2007 Draft) without modification. The purpose for use for all submissions shall be labeled as “Payment”.

Submission Specifications
Document submission specifications shall conform with the 275 transmissions except as noted below. The Transaction Set Header Segment (ST) identifies the transaction set by using 275 as the data value for the transaction set identifier code data element, ST01.

The originator of the transaction set assigns the unique control number ST02 which is shown here as 0001. In this example, the originator is the provider. ST03 carries the same value that is populated in GS08 which is the Implementation Version Identifier.

For the 275 transaction this is 005010X210, the 275 transaction structure only allows the submitter to send additional information for one claim in each 275. A separate Transaction Set Header/Trailer (ST/SE) must be sent for each claim response.

__The BGN Segments__ The Beginning Segment (BGN) indicates the transaction use. · The Transaction Set Purpose Code value of “11” in the BGN01 indicates that this 275 is a response to a **277 Request for Additional Information**. · A value of “02" indicates the unsolicited 275 is additional information sent to support a claim or encounter.

The originator of the transaction set assigns the unique reference number in BGN02 and the date of creation in BGN03. The

Functional Group Header Segment (GS) provides additional identification of the business purpose of multi-functional transaction sets. See Appendix C, EDI Control Directory, for a detailed description of the elements in the GS segment.

The following is an example of the transaction header segments.

** ST*275*0001*005010X210~ ** ** BGN*11*1*20060724~ **

__The NM1 Loop Participants__ For the solicited 275, the participants identified in the 275 are generally the: <span style="display: block; margin: 0in 0in 0pt 38.25pt; mso-list: l7 level1 lfo11; text-indent: -0.25in;"> 1. Payer (e.g., the Medicare Review Contractor) <span style="display: block; margin: 0in 0in 0pt 38.25pt; mso-list: l7 level1 lfo11; text-indent: -0.25in;"> 2. submitter (e.g., the HIH), <span style="display: block; margin: 0in 0in 0pt 38.25pt; mso-list: l7 level1 lfo11; text-indent: -0.25in;"> 3. provider, and <span style="display: block; margin: 0in 0in 0pt 38.25pt; mso-list: l7 level1 lfo11; text-indent: -0.25in;"> 4. patient.

The Loop ID 1000 is repeated to define the participants involved in the Transaction. The transaction participants __must__ be in the following order: 1. **Payer Name** - This entity is the decision maker in the business transaction. In this profile, this shall be the CMS-assigned OID for the RAC or MAC that is intended to receive the submission.

2. **Submitter** - This entity is the sender of the transaction. For this business use this entity is the HIH. A provider may choose to act as its own HIH.

3. **Provider** - This entity provided the health care service. In this profile, this shall be the NPI associated with the claim. 4. **Patient** - This is the person who received the services. The additional information is being sent to support the claim or encounter related to those services.

Claim ID and Case ID
<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The submitter shall include claim ID and case ID and shall conform with specifications for 1000D and 2000A Loop IDs contained in the July 2007 Draft ASC X12N/005010X210, Version 5 Release 1 document.

** Table 1 – 275 Claim ID and Case ID **

<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Segment ID: Ref
 * || **<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Definition ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Location ** || **<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Industry Usage ** ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Claim ID || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">To contain the claim number of the claim associated with the response package being submitted.  || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Loop ID: 1000D Patient Name

<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Segment Name: Claim Identification Number for clearninghouses and Other Transmission Intermediaries || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">R  || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Segment ID: TRN
 * <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Case ID || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">To contain the identification number assigned by the Medicare contractor who made the additional documentation request.  || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Loop ID: 2000A Assigned Number

<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Segment Name: Payer’s Control Number/Provier Attachment Control Number || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">R  ||

Error Handling
[AW1]

** Table 2 - Error Codes **


 * **Error** || **Errror Code** || **Description** ||
 * <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Document not well formed || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">XDSRepositoryError  || <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The document does not conform to esMD Profile. List violating elements if possible.  ||

esMD 275 Context Overview
The document body of X12 275 could include an unstructured (e.g UTF8 Text) presentation preserved format, such as PDF or TIF file. The PDF document format is further specified in the International Organization for Standardization (ISO) PDF/A ISO#19005-1b, Document management - Electronic document file format for long-term preservation standard. **__The documents must be attached following the HL7 standard.__**

The nonXMLbody element that contains a reference to the filename where the information block is encapsulated with the attributes of a document, such as persistence, authenticity, wholeness, etc. E Examples of documents that would be embedded in the 275 document include plain text file or PDF. esMD 275 Standards.

**__Submitters shall always use a CDA payload as defined by HL7 that can be either structured (future fully codified clinical information) or unstructured data (UTF8 such as PDF or TIF as described in the first paragraph). This includes the nonXMLbody tag that points to the actual content as described in the second paragraph.__**

** Table 3 - esMD 275 Standards ** ** D C62 <span style="color: white; font-family: 'Arial','sans-serif';">Standard ** and content to all users of ANSI ASC X12 **Patient Information (275) Transaction Set** that focuses on the use of the 275 to send additional information about a claim or encounter. This implementation guide provides a detailed explanation of the transaction set by defining uniform data content, identifying valid code tables, and specifying values applicable for the business use of conveying **Additional Information to Support a Health Care Claim or Encounter (275)**. For a fee, this guide is available at: [|www.wpc-edi.com]. ||
 * ~ **esMD C62 Standard** ||~ Description ||
 * <span style="display: block; font-family: 'Arial','sans-serif'; margin: 0in 0in 0pt;">ASC X12N/005010X210 || This guide provides standardized data requirements

Submission Specifications
<span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">This profile describes how to use 275 formats to foster submission of medical documentation requested by the Medicare Review Contractor. This profile: <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">References underlying 275 Segments, <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Specifies constraints and other rules for using the formats, and <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">Specifies additional constraints for using standard vocabularies and code sets where applicable. <span style="font-family: 'Arial','sans-serif'; font-size: 10pt;">The profile does not intend to detail 275 and messaging implementation constraints but rather directs implementers to 275 specification documents for conformance specifications.

Attachments in the edMD 275 Format
The following constraints apply to the 275 attachments:

a. The file must be in .pdf or .tif format b. The message size must not exceed 19 mb **(this constraint will be modified if and when the CONNECT/NHIN is changed to allow large file transfer)** c. The image resolution must be between 200 -300 dpi d. At least one file must be attached to a 275 e. Multiple files may be attached to a single 275. **__However, all documents in a 275 must relate to a single patient. Multiple documents can be attached by repeating the LX loop and down -- done? -- for each additional file.__** <span style="display: block; font-family: 'Verdana','sans-serif'; font-size: 9pt; text-align: center;">The 508 compliance standards address access to all information, documentation, and support provided to end users (e.g., Federal employees) of covered technologies. The information contained in this document is in compliance with 508 standards, and is available in alternate formats, upon request, at no additional charge.

Security and Transport Specifications for esMD 275 Documents
<span style="font-family: 'Times New Roman','serif'; font-size: 12pt;"> Since I believe you’ve made the decision to require the use of the Phase II CORE Connectivity Rule it’s probably better and more specific to state that up-front and then specify the specific constraints to be applied to the CORE rule for this project, e.g., from our internal notes of the in-person meeting on 8/10.

<span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of envelope type B only (SOAP only) <span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of real-time only (no batch) <span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of TLS only by adopting HITSP T85 as basis for security <span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of two-way TLS for authentication between parties <span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of Base64 encoding of Binary payload <span style="display: block; margin: 0in 0in 0pt 0.5in; mso-list: l1 level1 lfo13; tab-stops: list .5in; text-indent: -0.25in;"> · <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">Use of SAML

<span style="font-family: 'Times New Roman','serif'; font-size: 12pt;">My notes don’t show that the decision to use MTOM for real-time as a constraint on the CORE rule was made.

__ Transport __ The submitter shall use SOAP transport mechanism when transmitting an esMD 275 document. The submitter shall not use http or any transportation mechanism other than SOAP.

__ Timing __ The submitter shall use realtime transactions when transmitting an esMD 275 document. The submitter shall not use batch transactions.

__ MTOM __ The submitter shall use the MTOM mechanism for attaching the payload to the esMD 275 transaction. The submitter shall not use other attachment mechanisms. <span style="font-family: 'Times New Roman','serif'; font-size: 12pt;"> This is a bit confusing since the payload has not been specifically defined, I don’t think. For example, the payload could be defined as a complete ASC X12 Interchange consisting of a single Functional Group of a single 275 transaction set. Just referencing the use of the ASC X12 v5010 TR3 of the 275 probably doesn’t give sufficient detail to an implementer. Additionally, there are data elements in the ISA and GS segments used to identify sender/receivers that I don’t see specified elsewhere. These identifiers are outside the scope of the CORE Phase II Connectivity rule.

__ Security __ The submitter shall use TLS security when sending esMD 275 transaction. The submitter shall not use any other type of security in addition to TLS.

__ Authentication __ <span style="background: yellow; display: block; font-family: 'Arial','sans-serif'; font-size: 10pt;">The submitter shall use SAML “Holder of Key” when authenticating to send an esMD 275 document. The submitter shall not use any other type of authentication.

[|[AW1]] Recommend reviewing error handling for X12 transactions. Compare/contrast to the HITSP standard and choose the most appropriate method