esMD+Use+Case+2+-+Secure+Transport+and+Structured+Contents+of+Electronic+Medical+Documentation+Request+(eMDR)

include component="page" wikiName="siframework" page="esMD Header" include component="page" wikiName="siframework" page="esMD eMDR Workgroup Artifacts" Consensus voting for esMD Use Case 2 is now closed. Click here to see the votes.

Click to download the Use Case in a MS Word document =1.0 Preface and Introduction= To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange; maximize efficiency, encourage rapid learning, and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including patients, their significant others and family members, providers, payers, vendors, standards organizations, public health organizations, and Federal agencies. These Use Cases describe: The Use Case is the foundation for identifying and specifying the standards required to support the data exchange and developing reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards.
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data and their specifications required in the data exchange

=2.0 Initiative Overview=

Note: This section provides an overview of Centers for Medicare and Medicaid Services (CMS)’ esMD program as an overall initiative and also as part of the Standards & Interoperability Framework. The specific scope of this Use Case is discussed in the 3.0 Use Case Scope section.

Healthcare payers frequently request that providers submit additional medical documentation in order to adjudicate and support the processing of a specific claim or set of claims and perform other administrative functions, including identification of improper payments. Currently, Medicare Review Contractors send over 1 million requests for medical documents per year manually using a paper request letter and mailing it through the US Postal Service to healthcare providers. Until recently, healthcare providers had only two options for submitting the requested records to Medicare Review Contractors: 1) mail paper or 2) send a fax. The manual paper process is costly, time consuming and can delay proper claims processing on both the senders’ and receivers’ end.

As of September 15, 2011, a pilot group of Health Information Handlers (HIHs) and Medicare Review Contractors began accepting electronic submissions from providers, as part of the first phase of esMD. These electronic submissions consist of an unstructured .PDF format of a scanned image, within an Integrating the Healthcare Enterprise Cross-Enterprise Document Reliable Interchange (IHE XDR) wrapper. This initiative will provide added value to CMS, Commercial Payers, and Providers by defining the interoperability requirements for additional automation of the electronic request and submissions process.

CMS continues to investigate additional capabilities of electronic submission of medical documentation. The next release for CMS’ esMD Phase 2 will enable Medicare Review Contractors to send electronic medical documentation requests (eMDRs), eliminating the need to send the paper letters via mail or fax. CMS joined the Standards & Interoperability (S&I) Framework to accomplish their short-term goals for Phase 2, and to address their long-term requirement for replacement of wet signatures. In joining the S&I Framework, the esMD stakeholders were broadened beyond CMS to include discussions with other payers in the esMD Community including Commercial Payers. With a goal of promoting consistency across payers and standardizing processes for providers dealing with multiple payers, the requirements of multiple payer entities were incorporated into the Use Case.

The key objectives for the overall S&I Framework esMD Initiative include: > In order to address the objectives above, this Initiative will include the following three workgroups. > This Use Case specifically addresses the structured content requirements of the eMDR as well as the requirements to transport/send the eMDR from a payer entity to a registered eMDR Consumer[1].  To align with the short-term goals for CMS, the PPA workgroup took place first, and was followed by Structured Content and Author of Record. PPA will include two separate use cases, which will also require input and collaboration from the Structured Content workgroup participants. The PPA Use Case 1 focuses on registration of providers to receive eMDRs. This document outlines the Use Case for the secure transportation and the structured content of the eMDR from the payer entity to the registered eMDR Consumer.
 * Develop a registration process to allow Providers to sign up to receive electronic medical documentation requests from CMS Review Contractors
 * Identify a standards-based machine-interoperable electronic format to provide an alternate electronic method for the current paper version of the medical documentation requests that are sent to providers
 * Identify a secure method of sending medical documentation requests from CMS review contractors to providers
 * Identify a solution that will enable an electronic replacement of wet signatures, for medical documents submitted from providers to CMS
 * Provider Profiles Authentication (PPA) workgroup: Addresses the registration process, technical transport and authentication needed to allow Payers to identify Providers and send requests to them. This workgroup is dependent on the Provider Directories Use Case #2 (Electronic Service Information Discovery) outputs, as well as the Exchange support (for the CMS User Story) for secure transport and other infrastructure.
 * Structured Content (SC) workgroup: Determine the structured electronic format of medical document request letters to be sent to Providers, with consideration for the technical transport, expected response and information needed to support the response
 * Author of Record workgroup Provisional Assignment : Evaluate the business needs and implementable solutions to address the ability to prove the authorship and authenticity of any message or documentation that is part of the electronic submission of medical documentation (esMD). This includes all messages that are part of provider registration (UC1), the electronic submission of the structured medical documentation request (UC2) and the response by the provider or their agent to the payer or payer contractor.

Key objectives specifically for the PPA and Structured Content workgroup are to define the business requirements related to the registration process, compliant with CMS policies and Federal Information Security Management Act guidelines for the CMS User Story, and determine how to securely send medical document requests to registered providers. This Use Case also incorporates a Commercial User Story focused on the specific requirements for payers other than CMS. Business requirements and standards will have a key focus on the needs of CMS while also supporting options to enable re-use of the processes and standards by other Payers and Medicare partners.

2.1 Initiative Challenge Statement
The esMD Initiative as a whole intends to define the requirements and select the standards necessary to replace current paper processes for medical documentation requests with an electronic alternative. This Initiative was begun to provide solutions that address gaps raised by CMS post-payment reviews specifically; however, through the participation of other relevant stakeholders, the outputs of this Initiative will reflect the requirements of other Payers, Providers, and additional relevant stakeholders.

CMS and other payers need a standards-based, implementable, machine-interoperable electronic solution to reduce the time, expense, and paper required in current manual processing of medical documentation requests exchanged between providers and payers. To support the electronic __sending__ of medical documentation requests and the electronic __submission__ of medical documentation, the following solutions will be required:

> > * Structured Content for claims processing is currently out of scope for the S&I Framework esMD Initiative, but is a long-term esMD objective. As standards are harmonized by the esMD community, consideration will be given to what standards will be suitable for structured content submission goals.
 * Process for Provider Registration to receive eMDRs from Payers
 * Standardized electronic template to be used for eMDRs
 * Secure sending of the eMDRs to registered providers
 * Verifiable alternative for wet signatures on electronic medical documentation: a method of verifying the origin and authenticity of data submitted to payers and contractors for payment determination
 * Standardized structured content related to information required for claims processing*

=3.0 Use Case Scope=

The initial phase of this Initiative focuses on the Use Cases and Functional Requirements related to eMDRs, in support of CMS’ goals for the CMS esMD Phase 2 implementation. This will involve the creation of two use cases:
 * 1) Use Case 1 - Provider Registration with Payer to receive eMDR. This Use Case has already been completed and approved through consensus. (Completed on 3/19/2012 and posted [|here])
 * 2) Use Case 2 - Secure transportation and structured content of eMDR from Payer/Contractors to registered eMDR Requestor (Addressed by this Use Case)



Figure 1: Generic Context Diagram – Overall S&I Framework esMD Initiative for PPA Note – The diagram above illustrates the full PPA Use Case Diagram.

This Use Case (UC # 2 listed above), focuses on the requirements for sending an eMDR from the Payer or Payer Contractor to the registered eMDR Consumer which can be a Provider, Provider Organization, or an Agent on their behalf. Once an eMDR Consumer has registered with a Payer using the requirements detailed in Use Case 1, the Payer and Payer Contractors will have the appropriate registration information to send an electronic request to the eMDR Consumer. Use Case 2 will build off of Use Case 1, reusing similar requirements for communicating with External Provider Directories. As potential standards are analyzed and harmonized, requirements of both Use Case 1 and Use Case 2 will be considered.

Note – Not all Payers and Payer Contractors will be capable of sending an eMDR even if a provider or provider organization has successfully registered with that payer.

3.1 Background
Healthcare payers frequently request that providers submit additional medical documentation for a specific claim, to support claims processing and other administrative functions, such as the identification of improper payments. Currently, Medicare Review Contractors send over 1 million requests for medical documents per year by mailing a paper request letter via US Postal Service to healthcare providers. It is important to identify an alternative to the current process that reduces the number of paper requests that are sent to providers today. By introducing an electronic alternative, CMS, other Payers and Payer Contractors can reduce turnaround time, misdirected communications, and establish the transactions required to initiate an electronic response. This Use Case, which addresses s ecure transportation and structured content of eMDR from Payer/Contractors to registered eMDR Consumers, aims to reduce the need to mail paper request letters by replacing them with electronic alternatives. In order for CMS Payer Contractors to send an eMDR, the Provider Registration is of particular importance to CMS. Due to CMS policies required for FISMA compliance, CMS cannot send electronic notifications containing PHI to Providers, unless the Provider has specifically indicated that they wish to receive it. Once a Provider or Provider Organization has successfully registered with a Payer to receive eMDRs, the Payer and Payer Contractors can send the appropriate requests when necessary. Although the FISMA requirements are applicable to Federal agencies and not necessarily applicable to all Payers, the PPA workgroup determined that it would be beneficial for all Payers to follow a consistent registration process to identify providers wishing to receive electronic requests. This Use Case therefore includes input from a variety of stakeholders to validate that the transactions outlined here are applicable to a broad Payer and Provider community.

3.2 In Scope
>
 * Requirements for standards pertaining to technical transport, the structured content of the eMDR and authentication needed to allow CMS/Payers to send eMDR to providers, either directly or via an Agent.
 * Templates/Datasets relevant to structure of electronic Medical Documentation Request (eMDR)
 * Basic requirements for the response to the medical documentation request including but not limited to Due Date, Return Method, Return Format, and Documentation Required, to ensure the structured medical documentation request provides all the information that may be required in the response
 * Use of Digital Certificates for identity or encryption and Signature Artifacts required by this use case will be defined within the Author of Record Use Case and S&I Provider Directory data model

3.3 Out of Scope
>
 * Guidelines and Policies for the medical documentation request, including limitations on the frequency and volume of the requests, and what scenarios will warrant a need for additional claims attachments
 * Requirements and Standards for Structured Content of claims attachments sent from providers to payers/CMS
 * Authentication of content sent from Providers will be covered in the Author of Record workgroup
 * Requirements and Standards relating to Registration of Providers with esMD are addressed as part of Use Case 1
 * Templates/Standards relevant to Structured Inbound/Medical Documentation from Providers to CMS
 * Authentication of content sent from Providers (will be covered in the Author of Record workgroup)
 * Information requirements for requests other than documentation supporting claims
 * Defining the transactions between the Payer Contractor and Payer
 * Defining the transactions between the Agent and the Provider/Provider Organization

3.4 Communities of Interest
The Communities of Interest section identifies relevant stakeholders that are potentially affected by the content of the Use Case.

MAC- Medicare Administrative Contractors MRA –Medicare Recovery Auditor (formerly Recovery Audit Contractors, RAC) PERM – Payment Error Rate Measurement Program CERT –Comprehensive Error Rate Testing Program ZPICS – Zone Program Integrity Contractors ||
 * **Member of Communities of Interests** || **Working Definition** ||
 * Patients || Members of the public who require healthcare services from ambulatory, emergency department, physician’s office, and/or a public health agency/department. While patient information is being exchanged as part of the eMDR, the patient is not a direct participant in this use case. ||
 * Individual Providers || Healthcare providers with patient care responsibilities (including physicians, advanced practice nurses, physician assistants, nurses, psychologists, emergency care providers, home health providers, definitive care providers, pharmacists) and other personnel involved in patient care. ||
 * Healthcare Administrators and Managers || Healthcare administrators with patient information and medical records management responsibilities including Health Information Management (HIM) personnel, Registered Health Information Administrator (RHIA), Registered Health Information Technicians (RHIT), Inpatient/Outpatient Clinical Coding Specialists, Medical Transcription Specialists, Medical Records Safety and Security staff, Quality Control personnel, Physician Practice Managers, Pharmacy Benefit Managers, and other management personnel or entities involved in managing patient information. ||
 * Provider Organizations || Organizations that are engaged in or support the delivery of healthcare. These organizations include but are not limited to Hospitals, Ambulatory Centers, Provider Practices, Integrated Delivery Networks, Preferred Provider Organizations, Health Maintenance Organizations, Health Systems, Academic Medical Centers, Long-Term Care Organizations, Rehabilitation Centers, and other organizations such as Durable Medical Equipment providers, Pharmacies, and Emergency Transport. ||
 * Standards Organizations || Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and for system interoperability. ||
 * Government Agencies || Organizations within the federal government that deliver, regulate or provide funding for health, healthcare, clinical, or biomedical research. ||
 * Healthcare Payers || Insurers, including CMS (Medicare), commercial insurance, and other health plans, self-insured employer plans, and third party administrators, providing healthcare benefits to enrolled members and reimbursing provider organizations. ||
 * EHR/EMR / Financial System Vendors || Vendors which provide specific EHR/EMR / Financial System solutions to providers such as software applications and software services. These suppliers may include developers, providers, resellers, integrators, operators, and others who may provide these or similar capabilities. ||
 * Agent – (Clearing Houses and other entities as defined by Health Insurance Portability and Accountability Act (HIPAA) including Health Information Handlers) || Any organization that handles health information on behalf of a provider as a covered entity or under a Business Associate Agreement (BAA) is an Agent. Many providers already use Agents to submit claims, provide electronic health record systems, etc. Organizations that are Agents include but are not limited to Claim Clearinghouses, Release of Information vendors, Health Information Exchanges, Electronic Health Record vendors, etc. ||
 * Payer Contractors || Claims review programs and/or their specific implementation through associated contractors that are established to prevent improper payments before a claim is processed as well as identify any improper payments that can be recovered after a claim is paid. These programs include but are not limited to:
 * Other System Vendors || Supply systems and integration services for other intermediaries and Payer Contractors ||
 * Operating Rule Authoring Entities || As defined in Affordable Care Act Section 1104, such entities will develop operating rules that define the necessary business rules and guidelines for the electronic exchange of information that are not defined by a standard or its implementation specifications. Rules developed under ACA Section 1104 may not necessarily apply to this Use Case. ||

Table 1: Communities of Interest

=4.0 Value Statement=

The value of the esMD Initiative will be to provide consensus-based use cases, functional requirements, standards and implementation specifications representing combined input from a broad range of stakeholders, including CMS, commercial payers, providers, and vendors. This will promote a nationally standardized approach to medical documentation requests, claims attachments, the proof of authorship of medical documentation and reduce the costs associated with sending paper medical documentation requests via mail

The outputs of this initiative will ultimately be implemented in CMS’ future esMD releases. It is expected that CMS implementations stemming from this Initiative will also test Provider Directories in a real-world setting. The outputs and implementations of this Initiative are intended to be reused by the broader payer community. This Initiative also benefits national interoperability by expanding the health information technology infrastructure to incorporate and validate signatures as part of structured documents and transactions.

Payers, Providers, and Provider Organizations will benefit from the implementation of eMDRs. Some of the benefits of replacing the current paper process with an electronic option include:
 * Saves time, money and resources for CMS/Payers, Providers, and Provider Organizations
 * Eliminates print/mail operations required for sending or processing medical documentation request
 * Eliminates postage costs
 * Increases the accuracy of the information requested and received by avoiding errors, omissions and problems associated with paper based methods
 * Reduces turn-around-time for both providers and payers
 * Improves timeliness results in improved accounts receivable cycle for provider, so payments are received sooner
 * Reduces staff time spent handling paper
 * Mechanisms/standards to send other types of medical requests may be used by Payers

Relevance outside of CMS-esMD

 * Mechanisms/standards to send medical request may be used by other Payers and stakeholders, such as Commercial Payers.
 * Improve HIPAA compliance through the elimination of manual and paper processes
 * The standards adopted will have relevance to the industry as a whole and not merely to CMS and its partners.

=5.0 Generic Assumptions= The following assumptions apply to all user stories within this use case. Additional assumptions for CMS and commercial payer are outlined in subsequent sections. The numbering of assumptions does not indicate importance. >
 * 1) The eMDR will have structured content and meet the requirements set by the Structured Content Workgroup
 * 2) eMDR Consumer (either directly or through their Agent) will have an appropriate Electronic Service Information (ESI) for the eMDR transaction and will have successfully registered to receive the eMDR as defined in Use Case 1
 * 3) Payer or Payer Contractor will send the eMDR directly to the eMDR Consumer or through the eMDR Consumers’ Agent as determined by the appropriate ESI information in the External Provider Directory
 * 4) When an eMDR Consumer does not have a appropriate ESI, the provider will not receive an eMDR
 * 5) All transactions will utilize industry accepted standards, where available
 * 6) All transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, reliability; and with authentication of both the sender and receiver.
 * 7) All transactions will be delivered in a timely manner
 * 8) The transport of content and required data elements will be discussed during the harmonization phase
 * 9) It is the responsibility of an Agent or Gateway to ensure reliability and consistency of any transformation of information
 * 10) A single eMDR for a single claim will use the same code set revision for diagnoses
 * 11) Agents act on behalf of the Provider or Provider Organization they represent and assume responsibility for receiving and appropriately conveying eMDR information to the Provider or Provider Organization
 * 12) Gateways and Payer Contractors act on behalf of the Payers they represent and assume responsibility for receiving and appropriately conveying eMDR information to the Provider’s Agent (or Provider or Provider Organization).

5.1 – CMS User Story Additional Assumptions
>
 * 1) esMD Gateway is used by CMS and its contractors to support the activities related to eMDR transactions
 * 2) All transactions will use NwHIN Exchange
 * 3) CMS requires that all providers who wish to receive eMDRs to use the process defined for Provider Registration in UC 1 as well as this use case (UC 2)
 * 4) CMS esMD Gateway requires Providers to use a CMS compliant gateway
 * 5) All Generic Assumptions apply for Commercial Payer
 * 6) Commercial payers may use an Agent or another Intermediary to send eMDRs

5.2 – Commercial Payer User Story Additional Assumptions
>
 * 1) All Generic Assumptions apply for Commercial Payer
 * 2) Commercial payers may use an Agent or another Intermediary to send eMDRs

= = =6.0 Generic Pre-Conditions= >
 * 1) Payer has authenticated the Provider Directory used by the Provider as set by PPA Use Case 1.
 * 2) Provider or Agent has successfully registered and requested the Payer to send the eMDR
 * 3) Provider or Agent supports the required transaction, payload and payload content standards for the eMDR transactions
 * 4) Payer internal information systems are capable of sending the eMDR
 * 5) Providers or Agents can receive an eMDR and acknowledge the receipt of eMDR using transport level acknowledgement
 * 6) Provider registration information is maintained by the payer and available for use by the payer or other users of the provider registration system
 * 7) Payers will send eMDRs to the location specified in the appropriate ESI for a registered provider at the time of transmission
 * 8) Providers and Agents will maintain and update appropriate ESI information in the Provider Directory indicated at the time of registration

6.1 CMS User Story Additional Pre-Conditions
None. All Generic Pre-Conditions apply for CMS User Story

6.2 Commercial Payer User Story Additional Pre-Conditions
None. All Generic Pre-Conditions apply for Commercial Payer

=7.0 Generic Post Conditions= Providers and Agents will be responsible for consuming and responding to the eMDR

7.1 CMS User Story Additional Post-Conditions
None. All Generic Post-Conditions apply for CMS User Story

7.2 Commercial Payer User Story Additional Post-Conditions
None. All Generic Post-Conditions apply for Commercial Payer User Story

=8.0 Actors and Roles=

This table outlines the business actors that are participants in the information exchange requirements. A business actor is a person or organization that directly participates in a scenario. Thus, as a person or organization, the actor can (and should) be a stakeholder.

The business actor must use a system to perform the functions and to participate in the information interchange. NOTE: A Business Actor may be a Stakeholder and also can have more than one role. The “Business Actor – Specific” column below identifies specific actors that play the role within a focused User Story. For example – a Health Information Handler will play the role of the Agent in the CMS User Story.
 * **Business Actor - Generic** || **Business Actor - Specific** || **System** || **Role** ||
 * **eMDR Consumer** || eMDR Consumer || eMDR Consuming Information System || * Receives and consumes eMDR ||
 * **Provider Agent** || Health Information Handler (HIH) || Agent Information System || * Communicate eMDR to eMDR consumer
 * Information Requestor/Collector
 * Information Combiner[1] */Router ||
 * **Payer (Healthcare)** || Medicare

Commercial || Payer Information System || * Validates Providers against current enrolled provider list Table 2: Actors and Roles Descriptions of the terms corresponding to the table above can be but are not limited to:
 * Confirms appropriate ESI to receive MDRs electronically
 * Send eMDR ||
 * **External Provider Directory** || External Provider Directory || Provider Directory || * Manage Provider Information
 * Stores and responds to queries for Provider Information
 * Provides appropriate ESI to receive eMDRs ||
 * **Payer Gateway** || esMD Gateway || Payer Gateway Information System || * Auditing
 * Transaction Logging
 * Routing
 * Transforming
 * Error Handling and Notification
 * Submitted Authentication ||
 * **Payer Contractors / Intermediaries** || Payer Contractors / Intermediaries || Payer Contractor Information System || * Provider Registration Information Requestor
 * Appropriate ESI Requestor
 * Sends eMDR ||
 * __eMDR Consumer__ - Provider, Provider Organization, Agent
 * __eMDR Consuming Information System__ - Provider Directory / Billing System / Medical Records System
 * __Agent Information System__ - Transforming/routing system, Auditing System, Internal Provider Directory
 * __Payer Information System__ - Claims System, Provider Registration System, Internal Provider Directory, Business to Business Systems
 * __Payer Gateway Information System__ - Transforming/routing system, Auditing System
 * __Payer Contractor Information System__ – Claims System, Auditing System, Provider Directory

=9.0 Use Case Diagrams= Figure 2: Use Case Diagram ESI – Electronic Service Information eMDR – Electronic Medical Documentation Request Note – The Payer Gateway is not included as an actor in the Use Case Diagram above as its only role is to transform / translate the transaction. However, it is included within the Context diagrams below as it is an important part of the chain of interactions.

Figure 3: CMS Context Diagram The CMS Context Diagram above is specific to the CMS User Story. When a CMS Contractor or subcontractor identifies a need for additional medical documentation for a submitted claim, they must first check the eMDR Consumers registration status with CMS. Once the Registration status is confirmed, the Contractor requests and obtains the current ESI from the External Provider Directory to send the eMDR to the registered eMDR Consumer. All CMS eMDRs must go through the esMD Gateway prior to reaching the eMDR Consumer.



Figure 4: Commercial Payer Context Diagram excluding Payer Contractors The Commercial Payer Context Diagram above is specific to the Commercial Payer User Story. When a Commercial Payer identifies a need for additional medical documentation for a submitted claim, they must first check for an eMDR Consumers registration status within the Payer Internal System. Once the Registration status is confirmed, they request and obtain the current ESI from the External Provider Directory.

Figure 5: Commercial Payer Context Diagram including Payer Contractors The Commercial Payer Context Diagram above is specific to the Commercial Payer User Story. When a Commercial Payer’s Contractor identifies a need for additional medical documentation for a submitted claim, they must first check for an eMDR Consumers registration status within the Payer Internal System. Once the Registration status is confirmed, the Contractors request and obtain the current ESI from the External Provider Directory.

=10.0 Scenario=

The Payer or Payer Contractor sends a payer-compliant electronic Medical Document Request (eMDR) to an eMDR Consumer for additional information to support review of a claim.

10.1 Generic User Story
A Payer or Payer Contractor identifies a need for supporting documentation from a provider. Prior to sending a request, the Payer or Payer Contractor checks the Payer’s internal system to verify that the provider/eMDR Consumer is registered to receive eMDRs.

If it is determined that the eMDR Consumer is registered within the payer internal system, either the payer or payer contractor sends query to the External Provider Directory to obtain the Provider’s Electronic Services Information (ESI). The External Provider Directory responds to the payer or payer contractor’s ESI query with the eMDR Consumer’s current ESI information.

The Payer or Payer Contractors sends the eMDR directly or through a Gateway to the eMDR Consumer or to their Agent. If the Payer does not send an eMDR directly to the eMDR Consumer/Agent, a Payer Contractor sends the eMDR on the Payer’s behalf.

The eMDR Consumer receives an eMDR if they are successfully registered and have appropriate ESI information. If the eMDR Consumer is not successfully registered or does not have appropriate ESI information they will not receive an eMDR.

10.1.1 CMS User Story
A CMS Contractor identifies claims for which supporting documentation is needed from a provider. Prior to sending a request, the CMS Contractor checks the CMS internal system to verify that the provider/eMDR Consumer is registered to receive eMDRs.

If it is determined that the eMDR Consumer is successfully registered within the payer internal system, either CMS or the CMS Payer Contractor sends a query to the External Provider Directory to obtain the Provider’s Electronic Services Information (ESI). The External Provider Directory responds to CMS or the CMS Contractor’s ESI query with the eMDR Consumer’s current ESI information. CMS or the CMS Contractor must send the eMDR through the esMD Gateway to the eMDR Consumer.

The eMDR Consumer receives an eMDR if they are successfully registered and have appropriate ESI information. If the eMDR Consumer is not successfully registered or does not have appropriate ESI information they will not receive an eMDR.

10.1.2 Commercial User Story
A Commercial Payer or Payer Contractor identifies a need for supporting documentation is needed from a provider. Prior to sending a request, the Payer or Payer Contractor checks the payer’s internal system to verify that the provider/eMDR Consumer is registered to receive eMDRs.

If it is determined that the eMDR Consumer is successfully registered within the payer internal system, either the payer or payer contractor sends a query to the External Provider Directory to obtain the Provider’s Electronic Services Information (ESI). The External Provider Directory responds to the Payer or Payer Contractor’s ESI query with the eMDR Consumer’s appropriate ESI information.

The Payer or Payer Contractor may send the eMDR directly or through a Gateway to the eMDR Consumer or to their Agent. If the payer does not send an eMDR directly to the eMDR Consumer and/or Providers’ Agent, a Payer Contractor sends the eMDR on the Payer’s behalf.

The eMDR Consumer receives an eMDR if they are successfully registered and have the appropriate ESI information. If the eMDR Consumer is not successfully registered or does not have the appropriate ESI information they will not receive an eMDR.

10.2 Activity Diagram
The Activity Diagram illustrates the Use Case flows graphically, and represents the flow of events and information between the actors. It also displays the main events/actions that are required for the data exchange and the role of each system in supporting the exchange.

10.2.1 Base Flow


Note – Steps 1 and 3 are required only if a Payer Contractor is involved.

Figure 6: Activity Diagram

The Base Flow presents the step by step process of the information exchange depicted in the activity diagram (above). It indicates the actor who performs the action, the description of the event/action, and the associated inputs (records/data required to undertake the action) and outputs (records/data produced by actions taken).

Note – In the Base Flow table, all activities are listed assuming that the sending of eMDR process is initiated by a Payer Contractor on a Payer’s behalf. In the event a Payer sends the eMDR, the process skips Step 1-3 below.

Table 3: Base Flow
 * **Step #** || **Actor** || **Role** || **Event/ Description** || **Inputs** || **Outputs** || ** Interoperability or System Step ** ||
 * 1 || Payer Contractor or Intermediary || eMDR Consumer’s Registration Information Requestor || Payer Contractor / Intermediary sends a request to the Payer for eMDR Consumer registration status to receive eMDR || Need to send one or more medical documentation requests to a specific provider identified in a previously submitted claim || Query for eMDR Consumer registration status to receive eMDR || Interoperability ||
 * 2 || Payer || Provider information validator || Payer validates eMDR Consumer registration status to receive eMDRs using internal information system || Query for eMDR Consumer registration status to receive eMDR || Internally validated eMDR registration status (including confirmation of eMDR Consumers identity) || System ||
 * 3 || Payer || Provider information validator || Payer sends the response to Payer Contractor /Intermediary regarding eMDR Consumer registration status || Internally validated eMDR Consumer registration status (including confirmation of eMDR Consumer identity) || Response to requestor confirming eMDR Consumer registration status, External Provider Directory address and available provider or Agent’s ESI Information from the registration request || Interoperability ||
 * 4 || Payer, Payer Contractor or Intermediary || Provider Information Manager, Current ESI Requestor || Payer, Payer Contractor/ Intermediary sends request to External Provider Directory to retrieve current ESI || Response to requestor confirming eMDR Consumer registration status, External Provider Directory address and available provider or Agent’s ESI information from the registration request || Electronic Service Information Query for a specific eMDR Consumer to obtain current ESI || Interoperability ||
 * 5 || External Provider Directory || Provider Information Manager, Current ESI and Request responder || External Provider Directory locates and sends requested provider demographics and ESI information to Payer Contractor / Intermediary || Electronic Service Information Query for a specific provider to obtain current ESI || Current Electronic Service Information for the specific eMDR Consumer requested || Interoperability ||
 * 6 || Payer, Payer Contractor or Intermediary || Current ESI Requestor || Payer, Payer Contractor / Intermediary receives and verifies provider demographics, eMDR Consumer’s current ESI, and integration profile returned by the External Provider Directory || Current Electronic Service Information for the specific eMDR Consumer requested || Verified Current Electronic Service Information for a specific eMDR Consumer || System ||
 * 7 || Payer, Payer Contractor or Intermediary || eMDR Sender || Payer, Payer Contractor/ Intermediary sends eMDR(s) information to eMDR Consumer / Agent || Verified Current Electronic Service Information for eMDR Consumer and content of the eMDR || eMDR(s) || Interoperability ||
 * 8 || eMDR Consumer / Agent || eMDR Receiver || eMDR Consumer /Agent incorporates the eMDR into their system || eMDR(s) || END || System ||

10.3 Functional Requirements
Functional Requirements identify the capabilities a system playing a role must have in order to enable interoperable exchange of the healthcare data of interest. They provide a detailed breakdown of the requirements in terms of the intended functional behaviors of the application. The Functional Requirements include Information Interchange Requirements and System Requirements.

10.3.1 Information Interchange Requirements
Information Interchange Requirements define the systems’ names and roles and specify the actions associated with the actual transport of content from the sending system to the receiving system. Information systems participating in this Use Case must meet certain functional requirements based on their role.

Note - Each row in the table is a unique interchange. In rows __III-A and III-B,__ I__V-A and IV-B__, and __V-A through V-E__, the interchange requirement itself is the same; however, the Sending and Receiving Systems vary.
 * || **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * I || Payer Contractor Information System || Send || Query to validate eMDR Consumer’s registration status to receive eMDR || Receive || Payer Information System ||
 * II || Payer Information System || Send || Response to eMDR Consumers registration status query, address of External Provider Directory, and available provider or agent’s ESI Information provided as part of registration request || Receive || Payer Contractor Information System ||
 * III-A || Payer Information System || Send || Request for Current ESI of eMDR Consumer || Receive || External Provider Directory ||
 * III-B || Payer Contractor Information System || Send || Request for Current ESI of eMDR Consumer || Receive || External Provider Directory ||
 * IV-A || External Provider Directory || Send || Response for Current ESI for eMDR Consumer || Receive || Payer Information System ||
 * IV-B || External Provider Directory || Send || Response for Current ESI for eMDR Consumer || Receive || Payer Contractor Information System ||
 * V-A || Payer Contractor Information System || Send || eMDR || Receive || Payer Information Gateway System ||
 * V-B || Payer Information System || Send || eMDR || Receive || Payer Information Gateway System ||
 * V-C || Payer Gateway Information System || Send || eMDR || Receive || eMDR Consumer ||
 * V-D || Payer Contractor Information System || Send || eMDR || Receive || eMDR Consumer ||
 * V-E || Payer Information System || Send || eMDR || Receive || eMDR Consumer ||

Table 4: Information Interchange Requirements

10.3.2 System Requirements
System Requirements are internal to the system capabilities necessary to participate successfully in the transaction. System requirements may also detail a required workflow that is essential to the Use Case.


 * **System** || **System Requirement** ||
 * eMDR Consuming Information System || * Incorporate eMDR ||
 * Agent /Access Information System || * Receives eMDR
 * Translate /transform received eMDRs to industry standard or proprietary transactions that can be consumed by the provider eMDR Consuming Information System ||
 * Payer Gateway Information System || * Translate /transform information between payer and industry standard transactions ||
 * Payer Information System || * Validate eMDR Consumer registration status
 * Query Provider Directory for current ESI
 * Receive ESI
 * Incorporate ESI
 * Generate eMDR ||
 * Payer Contractor Information System || * Request Payer Information System to validate eMDR Consumer registration status
 * Receive eMDR Consumer registration status
 * Incorporate eMDR Consumer registration status
 * Query Provider Directory for current ESI
 * Receive ESI
 * Incorporate ESI
 * Generate eMDR ||
 * Provider Directory || * Receive query for provider demographic and ESI Information
 * Select appropriate eMDR Consumer based on query parameters
 * Return eMDR Consumer demographic and ESI ||

Table 5: System Requirements

10.4 Sequence Diagram
Note – Steps 1 and 3 are required only if a Payer Contractor is involved. Additionally, steps 4, 6, and 7 can be completed by either the Payer Contractor (A) or a Payer (B). For each of those steps (4, 6, 7), only step A or B can be selected.

Figure 7: Sequence Diagram

=11.0 Dataset Considerations=

This table lists the data elements and data element sets that will be available within the message or document. Historically, the optional/required nature of each data element is deferred to the discussions during the harmonization phase of the Initiative; however, some data elements do contain recommendations for optionality. Each data element listed below is necessary for some aspect of the Use Case; however, the table does not specify exactly how they may be used together.

The development of the eMDR data elements below began with a review of various current paper letters sent by CMS to Providers today. The data fields on some of the paper letters sent today were used as a starting point to determine the scope of the eMDR.

Additionally, various workflows for the sending of eMDR were considered before a recommendation was made to support a //__single transaction for a single patient for a single claim__//. This not only supports patient privacy by reducing it to a single patient per transaction, but also simplifies the structure required to maintain, process and support the numerous transactions that take place. Also, this sets the stage to allow for a (future) discrete response back to the Payer from the Provider, Provider Organization. Elements within the eMDR allow for aggregation of responses prior to sending it back to the Payers.

//All data elements for both the Message as well as the Structure of eMDR are outlined in the below tables// __Message Level - This is metadata used for the routing and secured transmission of the eMDR message__ __eMDR Object - The structured content of the electronic medical documentation request__ >
 * Table 6 - eMDR Message - Message Level data elements
 * Table 7 - General Request Information (i.e. “Cover Letter”)
 * Table 8 - Audit Specific Information
 * Table 9 - Claim Related Information and Specific Documentation Request
 * Table 10 - Return Method Object (corresponds to Object identified in Contents of eMDR)
 * //Message Level - eMDR Message://**


 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * **Unique eMDR Message ID** || Unique eMDR Message ID || No || Unique Message ID for this eMDR || eMDR IDs must be globally unique across all payers and able to accommodate expected request volumes (Example - UUID). Unique ID may be a concatenation of more than one data element. ||
 * **Timestamp** || Timestamp of eMDR Message || No || Date and Time the eMDR message was created || This is a timestamp created by the originator of the request and propagated by all intermediaries ||
 * **Payer Organization** || Unique Payer ID || No || Unique ID for the Payer that will directly or through a contractor issue an electronic request for medical documentation ||  ||
 * ^  || __Demographics__
 * Name
 * Address
 * City
 * State
 * Zip Code || No || The organization’s name, street address, city, state, and zip code ||  ||
 * ^  || * Signature Artifact || No || Signature artifact encrypted by owners private key || Exact nature of artifact to be determined during harmonization and Author of Record ||
 * ^  || * Public Digital Certificate || No || X.509 Token Profile || Signed by a trust authority ||
 * ^  || __Contact information__
 * Person / Role / Department
 * Telephone
 * Email Address
 * Fax
 * URL || No || Information used to contact the organization by telephone or email || Contact would include a person OR department OR role (Example – Compliance Officer). Contact information is optional ||
 * **Payer Contractor** || Unique Payer Contractor ID || No || Unique ID for the Payer Contractor that issues an electronic request for medical documentation ||  ||
 * ^  || __Demographics__
 * Name
 * Address
 * City
 * State
 * Zip Code || No || The organization’s name, street address, city, state, and zip code ||  ||
 * ^  || * Signature Artifact || No || Signature artifact encrypted by owners private key || Exact nature of artifact to be determined during harmonization ||
 * ^  || * Public Digital Certificate || No || X.509 Token Profile || Signed by a trust authority ||
 * ^  || __Contact information__
 * Person / Role / Department
 * Telephone
 * Email Address
 * Fax
 * URL || No || Information used to contact the organization by telephone or email || Contact would include a person OR department OR role (Example – Compliance Officer). Contact information is optional ||
 * **Provider Organization** || __Demographics__
 * Organization Name (XYZ health system)
 * Organization Address
 * City
 * State
 * Zip Code || No || The organization’s name, street address, city, state, and zip code || As registered with NPI or alternative ID ||
 * ^  || National Provider Identifier (NPI) || No || NPI issued to this provider organization or organization sub-part by NPPES ||   ||
 * ^  || Alternate ID (if no NPI) || No || ID issued to this provider organization or organization sub-part by Alternative ID issuer || Either NPI or Alternate ID must be used, but the concurrent use of both is not supported. Should be consistent with Alternate ID provided in PPA Use Case 1 Registration Request.

Alternate ID may include an issuing Organization and may take the form of an OID ||
 * **Individual Provider** || __Demographics__
 * First Name
 * Middle Name
 * Last Name
 * Address
 * City
 * State
 * Zip code || No || The individual’s name, street address, city, state, and zip code || As registered with NPI or alternative ID ||
 * ^  || NPI || No || NPI issued to this provider organization or organization sub-part by NPPES ||   ||
 * ^  || Alternate ID (if no NPI) || No || ID issued to this provider organization or organization sub-part by Alternative ID issuer || Either NPI or Alternate ID must be used, but the concurrent use of both is not supported.

Should be consistent with Alternate ID provided in PPA Use Case 1 Registration Request.

Alternate ID may include an issuing Organization and may take the form of an OID ||
 * **Information from eMDR Object** || Due Date || No || The date specified on which the additional documentation must be submitted ||  ||
 * ^  || Unique ID for eMDR Object || No || Unique ID for eMDR Object || eMDR IDs must be globally unique across all payers and able to accommodate expected request volumes (Example - UUID). Unique ID may be a concatenation of more than one data element ||
 * ^  || Unique ID for original eMDR Object || No || Unique ID for original eMDR Object || Used only if this is a replacement or termination request ||
 * ^  || Timestamp of eMDR Object || No || The Date and time when the structured content of the eMDR included in this message was created || This is a timestamp created by the originator of the request and propagated by all intermediaries ||
 * ^  || Request Purpose || No || Purpose of eMDR || A code set will need to be identified or created that defines the purpose of the eMDR.

Purpose will, in general, be related to the authority the payer has for requesting the medical documentation and the specific documentation requested under that authority

Each request has one and only one purpose. If information is being requested for multiple purposes, then multiple requests should be created. ||
 * ^  || eMDR Object || No || Structured Content of the eMDR as an object || See table below ||
 * ^  || Request Type || No || Indicator if this is a replacement to a prior request, a new request, follow up or a termination request || Values: ‘New,’ ‘Replacement,’ ‘Follow – Up,’ ‘Termination’ ||
 * ^  || Request Type Reason || No || Description of reason for the replacement, follow up or termination for a prior request ||   ||
 * **Message Signature** || Public Digital certificate of transmitter || No || X.509 Token Profile || Signed by a trust authority ||
 * ^  || Signature Artifact || No || Signature Artifact encrypted by transmitter’s private key || Exact nature of the artifact to be determined during harmonization and Author of Record.

At a minimum the Signature Artifact will include the digest (hash) of the message. ||

Table 6: Dataset Requirements – eMDR Message – Message Level data elements


 * //The below data elements are associated with the eMDR Object//**
 * //eMDR Object - General Request Information (i.e. “Cover Letter”)//**


 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * **Unique eMDR ID** || Unique ID for eMDR Object || No || Unique ID for eMDR Object || eMDR IDs must be globally unique across all payers and able to accommodate expected request volumes (Example - UUID). Unique ID may be a concatenation of more than one data element.

This element is identical to Unique ID for eMDR Object found under eMDR Message ||
 * **Timestamp** || Timestamp of eMDR Object || No || Date and Time of the eMDR Object || This is a timestamp created by the originator of the request and propagated by all intermediaries

This value of this element is identical to the 'Timestamp of eMDR Object' element found under the eMDR Section of the eMDR Message tab” ||
 * **__Payer Information__** || __Payer Demographics__
 * Organization Name
 * Organization Address
 * City
 * State
 * Zip Code ||  || The organization’s name, street address, city, state, and zip code ||   ||
 * ^  || Unique Payer Identifier || No || Unique ID of the Payer || In anticipation of a National Health Plan ID (HPID), there are other values that can be used in absence of the HPID ||
 * ^  || * Signature Artifact || No || Signature artifact encrypted by owners private key || Exact nature of artifact to be determined during harmonization ||
 * ^  || * Public Digital Certificate || No || X.509 Token Profile || Signed by a trust authority ||
 * ^  || __Payer Contact information__
 * Person / Role / Department
 * Telephone Number
 * Email
 * Fax
 * URL || No || Information used to contact the organization

The URL to be provided by payer for online communication between provider and payer || Contact would include a person OR department OR Role (Example – Compliance Officer). Contact information is optional || __Demographics__
 * **__Payer Contractor Information__** || Unique Payer Contractor ID || No || Unique ID for the Payer Contractor that issues an electronic request for medical documentation ||  ||
 * ^  || __Payer Contractor__
 * Organization Name
 * Organization Address
 * City
 * State
 * Zip Code ||  || The organization’s name, street address, city, state, and zip code || Payer contractor on behalf of a payer ||
 * ^  || * Signature Artifact || No || Signature artifact encrypted by owners private key || Exact nature of artifact to be determined during harmonization ||
 * ^  || * Public Digital Certificate || No || X.509 Token Profile || Signed by a trust authority ||
 * ^  || __Payer Contractor Contact information__
 * Person / Role / Department
 * Telephone Number
 * Fax
 * Email
 * URL || No || Information used to contact the organization.

The URL to be provided by payer contractor for online communication between provider and payer contractor || Payer Contractor on behalf of a payer. Contact would include a person OR department OR role (Example – Compliance Officer). Contact information is optional ||
 * **__Individual Provider Information__** || __Individual Provider Demographics__
 * First Name
 * Middle Name
 * Last Name
 * Address
 * City
 * State
 * Zip Code || No || The individual’s name, street address, city, state, and zip code || As registered with NPI or Alternate ID ||
 * ^  || NPI || No || NPI issued to this provider organization or organization sub-part by NPPES ||   ||
 * ^  || Alternate ID (if no NPI) || No || ID issued to this provider organization or organization sub-part by Alternative ID issuer || Either NPI or Alternate ID must be used, but the concurrent use of both is not supported. Should be consistent with Alternate ID provided in PPA Use Case 1 Registration Request. Alternate ID may include an issuing Organization and may take the form of an OID ||
 * **__Provider Organization Information__** || __Provider Organization Demographics__
 * Organization Name
 * Organization Address
 * City
 * State
 * Zip Code || No || The organization’s name, street address, city, state, and zip code || As registered with NPI or Alternate ID ||
 * ^  || NPI || No || NPI issued to this provider organization or organization sub-part by NPPES ||   ||
 * ^  || Alternate ID (if no NPI) || No || ID issued to this provider organization or organization sub-part by Alternative ID issuer || Either NPI or Alternate ID must be used, but the concurrent use of both is not supported. Should be consistent with Alternate ID provided in PPA Use Case 1 Registration Request. Alternate ID may include an issuing Organization and may take the form of an OID ||
 * **Other General Information** || Date of Request || No || The date that the eMDR is sent || Date of request may be different than timestamp of eMDR Object depending on processing of eMDR ||
 * ^  || Cover Letter text || No || Non computable text corresponding to statements required by statutes, regulations or contract ||   ||
 * ^  || Program || No || The type of program that sends eMDR || Requesting Program examples include MAC, RAC, ZPICS, CERT, etc. ||
 * ^  || __Contact information for this specific request__
 * Person / Role / Department
 * Telephone Number
 * Email
 * Fax
 * URL || No || Information used to contact the organization

The URL to be provided by payer or payer contractor for online communication between provider and payer or payer contractor || If different than the Payer or Payer Contractor contact information ||

Table 7: Dataset Requirements - General Request Information

Table 8: Dataset Requirements - eMDR Object - Audit Specific Information
 * //eMDR Object – Audit Specific Information//**
 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * **Audit specific Information** || Scope or Type of Audit || No || It is a codified field that determines the type of request including Pre certification, Claim Payment Documentation, Audit, Payment Recovery etc. ||  ||
 * ^  || Unique Claim Reference Identifier || No || A unique number associated with a specific claim that serves as a common identifier used by both the payer / payer contractor and provider || Internal Control Number (ICN), Document Control Number (DCN) or Claim Control Number (CCN) of the claim. Only one may be used. One field is sufficient because each number identifies the type of control number. ||
 * ^  || Unique Case Reference Identifier || No || A case number used to track one or more related eMDRs. Serve as a unique external ID. ||   ||


 * //eMDR Object - Claim Related Information and Specific Documentation Request//**


 * ** Section ** || ** Data Element ** || ** Multiple Values (yes/no) ** || ** Data Element Description ** || Additional Notes ||
 * ** Document Return Requirements ** || Due Date || No || The date on which information must be submitted by || Provider information ||
 * ^  || Provider Directory Address || No || Electronic address of the Provider Directory ||   ||
 * ^  || Provider Directory ID || No || An identifier assigned to the provider directory whose purpose is to uniquely identify the provider directory from which a set of data is returned. || Identification of assigning authority is to be determined ||
 * ^  || Return Method Object || Yes || See object definition below. ||   ||
 * ** Processor Information ** || Claim Processor Identifier || No || The entity that processes the claim submission || Examples – For CMS it would be the Medicare Administrative Contractors (MACs). It can also be PBMs. ||
 * ** Patient Information ** || Patient Name || No || Name of the individual that received health services / care ||  ||
 * ^  || Date of Birth || No || Date of birth of the patient that received health services/ care ||   ||
 * ^  || Account Number || No || Identifier assigned by a provider and associated with a single encounter for the purposes of financial management ||   ||
 * ^  || Medical Record Number || No || A unique number assigned to a patient by the provider to assist in management of medical records ||   ||
 * ^  || Payer Identifier for the Policy holder || No || An identifier assigned by the payer to the policy holder under which payment will be made for this patient || This field will be populated if the holder of the policy and the patient are different. ||
 * ^  || Payer Identifier for Patient || No || An identifier assigned by the Payer to identify the patient || Example - Health Insurance Claim Number for CMS ||
 * ** Claim Level Detail (all data elements are from the submitted claim referenced in this section, unless otherwise indicated) ** || Date Claim Received || No || The date the claim for which the eMDR is requesting documentation was received by the claim processor entity ||  ||
 * ^  || Date(s) of Service || No || Date of service, such as the start date of the service, the end date of the service, or the single day date of the service. || The date of service can be a range

The first date is required ||
 * ^  || Type of Bill || No || A four-digit alphanumeric code which identifies the specific type of bill and represents the setting in which care was provided. Type of Bill only applies to institutional claims. || As defined by the National Uniform Billing Committee in Form locator 04 (www.nubc.org). ||
 * ^  || Place of Service || No || Codes used on professional claims to specify the entity where service(s) were rendered || CMS maintains the code set for Place of Service ||
 * ^  || Diagnosis Code(s) || Yes || A diagnosis code identifying a diagnosed medical condition ||   ||
 * ^  || Diagnosis Code Set Used || No || Revision of diagnosis code set || Example - ICD 9, ICD 10 ||
 * ^  || Diagnosis Related Group Code || No || A classification system that groups similar clinical conditions (diagnoses) and the procedures furnished by the hospital during the stay. || The code is derived by the Grouper software ||
 * ** Line Level Detail (all data elements are from the submitted claim referenced in this section, unless otherwise indicated) ** || Performing Provider NPI || No || The NPI of the provider rendering the service

NPI Issued to this provider by NPPES ||  ||
 * ^  || Performing Provider Alternate ID || No || Alternate ID of the provider rendering the service if the NPI is not available

ID issued to this provider by Alternate ID issuer ||  ||
 * ^  || Alternate ID Type || No || A code value for the source of the alternate ID || Example – State license number, Commercial ID or Location ID ||
 * ^  || Date(s) of Service || No || Date of service, such as the start date of the service, the end date of the service, or the single day date of the service. || The date of service can be a range

The first date is required ||
 * ^  || Place of Service || No || Codes used on professional claims to specify the entity where service(s) were rendered || CMS maintains the code set for Place of Service ||
 * ^  || Revenue Code || No || Identifies specific accommodations, ancillary services and billing calculations as determined by the National Uniform Billing Committee in Form locator 42. || www.nubc.org ||
 * ^  || Provider Specialty || No || The area of medicine or surgery in which a clinician specializes || Example - Acupuncture, Internal Medicine, Neurology, Pathology etc. ||
 * ^  || Diagnosis Code || Yes || One or more of the diagnosis codes identified in the Claim Level that apply to this line level item || Either the claim level diagnosis code or up to 4 pointers to the claim level diagnosis code ||
 * ^  || Procedure Code || No || HCPCS Code or HIPPS Code || HCPCS Codes, Healthcare Common Procedure Coding System numbers, are the codes used by all Payers and maintained by CMS, the Centers for Medicare and Medicaid Services, American Dental Association, American Medical Association as appropriate ||
 * ^  || Procedure Modifier(s) || Yes || Specific modifier(s) defined for HCPCS code || Claim formats currently support up to 4 modifiers ||
 * ** Documentation Requested ** || Documentation Requested || Yes || Documentation that must be provided in response to this eMDR || This can be medical documentation or other types of documentation necessary to support the claim.

This will need a code set which will be defined during harmonization ||
 * ^  || Description of Documentation Requested || Yes || Description of documentation that must be provided in response to this eMDR || This can be medical documentation or other types of documentation necessary to support the claim. ||
 * ** eMDR Message Signature ** || Public Digital certificate of transmitter || No || X.509 Token Profile || Signed by a trust authority. For CMS, certificates must be issued by authorities cross certified with the Federal bridge. ||
 * ^  || Signature Artifact || No || Signature Artifact encrypted by transmitter’s private key || Exact nature of the artifact to be determined during harmonization.

At a minimum the Signature Artifact will include the digest (hash) of the message. ||

Table 9: Dataset Requirements - eMDR Object – Claim Related Information and Specific Documentation Request

//eMDR Object - "Return Method Object" data elements //
See Return Format below ||
 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * **Return Method Object** || Return Method(s) || No || The method by which a provider or provider organization may return the additional documentation requested in the eMDR || Defines the high level transport to be used for the return. Transport could be: Physical, Electronic Transaction, and Universal Resource Identifier (URI)
 * ^  || Electronic Service Information (Electronic Service Information Object) || No || Description of electronic services supported by the Payer / Payer Contractor organization. This is an object || Use ESI Object developed in the Provider Directory data model found [|here]. ||
 * ^  || Physical Return Address (Physical Return Address Object) || No || The physical return address for the organization. || This will be the Address Object from PPA UC 1. ||
 * ^  || Maximum Electronic Return Size per transaction || No || The maximum size allowed per return transactions in megabytes || Payer and Provider will need to support multiple transactions per submission if documentation requirement exceeds maximum return size or use an alternative method ||
 * ^  || Return Constraints || Yes || Return Constraints for this specific Return Method - Physical, Electronic Transaction, URI || This is a code set that will be defined in harmonization. Examples -International Code Sets, Extended ASCII Character Sets, Language, Constraints related to paper submissions such as staples, holes in the paper, information included only on one side of the paper, etc. ||
 * ^  || Return Format(s) || Yes || Return Formats allowed for this specific Return Method - Physical, Electronic Transaction, URI || This is a code set that will be defined in harmonization. Examples – USB drive, CDs, PDFs, UML, XHTML, etc. Need to consider fax resolution, encryption of returns on CDs or via email, file naming conventions etc. ||

Table 10: Dataset Requirements – eMDR Object - Return Method Object

=12.0 Risks, Issues and Obstacles=


 * Assuming Provider Registration is not mandated, low adoption rates for Provider Registration with a payer or payer contractor to receive eMDR (i.e. adoption of Use Case 1) will result in fewer eMDRs being sent by Payer or Payer Contractors
 * Technical and / or operational barriers to scaling, participating platforms or services to meet volume of eMDRs
 * Ensuring secure, trusted communications between payers, payer contractors, provider directories and eMDR Consumers or Agents
 * Unintended disclosure of Personal Health Information
 * Compliance with FISMA for transactions to CMS and other relevant federal agencies or their Agents
 * Changes in the External Provider Directory information for a registered eMDR Consumer that make the ESI inaccessible
 * Ensuring that there are consistent and reliable mechanisms for establishing and updating Provider Directories
 * The inability to retrieve the correct ESI for the desired destination because of incomplete request or inconsistent federation
 * Fees that may be charged by Agents or HIHs may increase costs for adopters of esMD and therefore hinder adoption
 * Potential for expired information if consumer system caches destination and Electronic Service Information
 * When an Agent is acting on behalf of a Provider or Provider Organization, the Agent may fail to deliver or execute the eMDR in a timely or reliable fashion
 * When a Payer Contractor or Gateway is acting on behalf of a Payer, there is a risk that the eMDR may be incomplete, inaccurate, or may not be transmitted to the Provider or Provider’s Agent
 * Availability of provider directories for all providers

=Appendices=

Appendix A: Related Use Cases

 * Provider Directories Use Case 2 – [|Query for Electronic Service Information including Electronic Address Use Case]
 * esMD Provider Profiles Authentication (PPA) Use Case 1 – [|Provider Registration with a Payer to receive electronic medical documentation requests (eMDRs)]

Appendix B: Glossary of Terms

 * * ** Account Number - ** Identifier assigned by a provider and associated with a single encounter for the purposes of financial management
 * ** Alternate ID ** - An alternate ID can be used if a Registration Requester is not eligible to obtain an NPI, for example a number issued for provider of services by a commercial payer or Medicaid.
 * ** Beneficiary - ** It is the //individual// on which the service was performed. For purposes of CMS, the subscriber, member, and beneficiary are the same.
 * ** Centers for Medicare and Medicaid Services (CMS) ** –CMS is used in this Use Case to refer specifically to Medicare
 * ** Claim – ** Request for payment from a provider, supplier, or beneficiary, and the provider, supplier, or beneficiary requesting payment must furnish the appropriate payer with sufficient information to determine the amount of payment. For purposes of CMS, the subscriber, member, and beneficiary are the same.
 * ** Claim Date - ** The date the claim is submitted
 * ** Comprehensive Error Rate Testing (CERT) ** – Reviews claims to ensure that they have complied with Medicare coverage, coding, and billing rules. If not, assign error to claims.
 * ** Dates of Service - **Date of service, such as the start date of the service, the end date of the service, or the single day date of the service.
 * ** Digital Certificate – ** Refer to Author of Record definition for Digital Certificate.
 * ** Electronic Service Information (ESI) ** as defined in the Provider Directory ESI Use Case - All information reasonably necessary to define an electronic destination’s ability to receive and consume a specific type of information (e.g. discharge summary, patient summary, laboratory report, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summary or query) the destination’s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include labels which help identify the type of recipient (e.g. medical records department).
 * ** eMDR ** – Electronic Medical Documentation Request refers to a request sent electronically from a Payer or Payer Contractor to obtain additional documentation in support of a claim submitted by a Provider to a Payer.
 * ** eMDR Consumer – ** An eMDR Consumer can be a provider or a provider organization that has successfully registered with a payer or payer contractor to receive and consume electronic medical documentation Requests (eMDRs). An eMDR Consumer can also be an Agent on the provider’s behalf. In this Use Case, the Agent has been highlighted as a separate actor; however, their role is similar to a provider or provider organization if acting on their behalf.
 * ** eMDR Consuming Information System – ** The consuming information system of an individual provider, provider organization, or an Agent on their behalf that has successfully registered with a payer or payer contractor to receive electronic Medical Documentation Requests (eMDRs).
 * ** esMD Gateway – **CMS esMD Gateway is NwHIN compliant solution built using the open source CONNECT software. This solution enables secure exchange of electronic health information adhering to various Health Information Technology (HIT) interoperability standards. Currently the Gateway receives medical documents submitted by various Health Information Handlers (HIHs) on behalf of the Providers and will soon accept documents sent by CMS to the Providers as well, thus facilitating bi-directional health information exchange. The CMS esMD Gateway went live on September 15, 2011
 * ** Federal Bridge Certificate Authority ( **FBCA) - Supports interoperability among Federal Agency Public Key Infrastructure domains in a peer-to-peer fashion and acts as a facilitator between Federal agencies in reaching agreements on recognizing or cross-certifying each other's certificates and federal standards for identity verification.****[1]****
 * ** Federal Information Security Management **** of 2002 **** (FISMA) ** - A mandated U.S. Federal law that provides a framework to improve information security of federal agencies, contractors, and other entities that handle federal data. Security components include: Risk Assessment, Security policies and procedures, Subordinate plans, Security testing, Remedial action and Security incident handling.
 * ** Health Information Handler (HIH) ** – Any company that handles health information on behalf of a provider. For example, Health Information Exchange (HIE), Regional Health Information Organization (RHIO), Release of Information (ROI) vendors
 * ** Medical Record Number (MRN) - **A unique number assigned to patient by the provider to assist in retrieval of medical records.
 * ** Medicare Administrative Contractors (MACs) – ** Organizations contracted to process claims submitted by physicians, hospitals, and other health care providers/suppliers, and make payments to those providers in accordance with Medicare rules and regulations. This includes identifying and correcting underpayments and overpayments.
 * ** Medicare Recovery Auditors (MRA) ** - The MRAs are responsible for identifying improper Medicare payments that may have been made to healthcare providers and that were not detected through existing program integrity efforts.
 * ** National Provider Identifier (NPI) ** - The National Provider Identifier (NPI) is a standard required under HIPAA. The NPI is a unique, 10-digit identification number for health care providers that is free of any personal or identifying information. HIPAA covered health care providers, health plans, and health care clearinghouses must use the NPI in administrative and financial transactions (e.g., claims submission) that are adopted under HIPAA.
 * ** National Plan and Provider Enumeration System (NPPES) – ** Created by CMS to assign unique identifiers for health care providers. The purpose of these provisions is to improve the efficiency and effectiveness of electronic transmission of health information.
 * ** Nationwide Health Information Network (NwHIN) Exchange - ** A **confederation of trusted entities, bound by mission and governance to securely exchange health information. ******[2]****
 * ** Patient ** – For the purposes of this esMD use case, it is the individual on which the service was performed. For CMS Medicare, the patient is called the beneficiary. For CMS Medicaid, the patient is called the recipient. For Commercial Payers, the patient could be either the insured or a dependent of the insured.
 * ** Payment Error Rate Measurement (PERM) ** – CMS program and contractor that measures improper payments in Medicaid and CHIP and produces error rates for each program. The error rates are based on reviews of the fee-for-service (FFS), managed care, and eligibility components of Medicaid and CHIP programs in the fiscal year (FY) under review. It is important to note the error rate is not a "fraud rate" but simply a measurement of payments made that did not meet statutory, regulatory or administrative requirements.
 * ** Provider Directory (PD) ** as defined in the Provider Directory ESI Use Case - An electronic, searchable resource that lists all information exchange participants, their names, addresses, and other characteristics. A Provider Directory can carry out the role of a Certificate Directory. (Ref: HITPC Information Exchange Workgroup Provider Directory Recommendations)
 * ** Provider Profile Authentication (PPA) ** – PPA is the first workgroup for esMD which focused on the development of Use Case 1 for Provider Registration with a Payer to receive electronic medical documentation requests.
 * ** Type of Bill – **A four-digit alphanumeric code which identifies the specific type of bill and represents the setting in which care was provided. As defined by the National Uniform Billing Committee in Form locator 04 (FL04).
 * ** Wet Signatures ** - Physically signing a document by hand using an ink pen
 * ** Zone Program Integrity Contractors (ZPICs) ** - Identify cases of suspected fraud and take appropriate corrective actions. ||

Appendix C: References
Healthcare payers frequently request that providers submit additional medical documentation for a specific claim, to support claims processing and other administrative functions, such as the identification of improper payments. Currently, Medicare Review Contractors send over 1 million requests for medical documents per year by mailing a paper request letter via US Postal Service to healthcare providers. It is important to identify an alternative to the current process that reduces the number of paper requests that are sent to providers today. By introducing an electronic alternative, CMS, other Payers and Payer Contractors can reduce turnaround time, misdirected communications, and establish the transactions required to initiate an electronic response. This Use Case, which addresses s ecure transportation and structured content of eMDR from Payer/Contractors to registered eMDR Consumers, aims to reduce the need to mail paper request letters by replacing them with electronic alternatives. In order for CMS Payer Contractors to send an eMDR, the Provider Registration is of particular importance to CMS. Due to CMS policies required for FISMA compliance, CMS cannot send electronic notifications containing PHI to Providers, unless the Provider has specifically indicated that they wish to receive it. Once a Provider or Provider Organization has successfully registered with a Payer to receive eMDRs, the Payer and Payer Contractors can send the appropriate requests when necessary. include component="page" wikiName="siframework" page="space.template.inc_contentleft_end" Although the FISMA requirements are applicable to Federal agencies and not necessarily applicable to all Payers, the PPA workgroup determined that it would be beneficial for all Payers to follow a consistent registration process to identify providers wishing to receive electronic requests. This Use Case therefore includes input from a variety of stakeholders to validate that the transactions outlined here are applicable to a broad Payer and Provider community.
 * CMS esMD Program - []
 * FI SM A Requirements
 * []
 * []