Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Electronic Submission of Medical
Documentation (esMD) Use Case 2
Secure Transportation and Structured Content of
electronic Medical Documentation Requests (eMDRs)
5/30/2012
5/30/2012
1
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Table of Contents
1.0 Preface and Introduction ........................................................................................................................ 4
2.0 Initiative Overview .................................................................................................................................. 4
2.1 Initiative Challenge Statement............................................................................................................ 6
3.0 Use Case Scope ....................................................................................................................................... 7
3.1 Background ......................................................................................................................................... 8
3.2 In Scope ............................................................................................................................................... 8
3.3 Out of Scope........................................................................................................................................ 9
3.4 Communities of Interest ..................................................................................................................... 9
4.0 Value Statement ................................................................................................................................... 11
5.0 Generic Assumptions ............................................................................................................................ 12
5.1 – CMS User Story Additional Assumptions ....................................................................................... 13
5.2 – Commercial Payer User Story Additional Assumptions ................................................................. 13
6.0 Generic Pre-Conditions ......................................................................................................................... 13
6.1 CMS User Story Additional Pre-Conditions ....................................................................................... 13
6.2 Commercial Payer User Story Additional Pre-Conditions ................................................................. 14
7.0 Generic Post Conditions ........................................................................................................................ 14
7.1 CMS User Story Additional Post-Conditions ..................................................................................... 14
7.2 Commercial Payer User Story Additional Post-Conditions ............................................................... 14
8.0 Actors and Roles ................................................................................................................................... 14
9.0 Use Case Diagrams ................................................................................................................................ 16
10.0 Scenario............................................................................................................................................... 19
10.1 Generic User Story .......................................................................................................................... 19
10.1.1 CMS User Story ........................................................................................................................ 20
10.1.2 Commercial User Story ............................................................................................................ 20
10.2 Activity Diagram .............................................................................................................................. 21
10.2.1 Base Flow ................................................................................................................................. 21
10.3 Functional Requirements ................................................................................................................ 24
10.3.1 Information Interchange Requirements .................................................................................. 24
10.3.2 System Requirements .............................................................................................................. 25
10.4 Sequence Diagram .......................................................................................................................... 27
5/30/2012
2
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
11.0 Dataset Considerations ....................................................................................................................... 27
eMDR Object - "Return Method Object" data elements ..................................................................... 39
12.0 Risks, Issues and Obstacles ................................................................................................................. 41
Appendices.................................................................................................................................................. 42
Appendix A: Related Use Cases.............................................................................................................. 42
Appendix B: Glossary of Terms .............................................................................................................. 42
Appendix C: References .......................................................................................................................... 44
List of Figures:
Figure 1: Generic Context Diagram – Overall S&I Framework esMD Initiative for PPA ............................... 7
Figure 2: Use Case Diagram ........................................................................................................................ 16
Figure 3: CMS Context Diagram .................................................................................................................. 17
Figure 4: Commercial Payer Context Diagram excluding Payer Contractors.............................................. 18
Figure 5: Commercial Payer Context Diagram including Payer Contractors .............................................. 19
Figure 6: Activity Diagram ........................................................................................................................... 21
Figure 7: Sequence Diagram ....................................................................................................................... 27
List of Tables:
Table 1: Communities of Interest ............................................................................................................... 11
Table 2: Actors and Roles ............................................................................................................................ 15
Table 3: Base Flow ...................................................................................................................................... 24
Table 4: Information Interchange Requirements ....................................................................................... 25
Table 5: System Requirements ................................................................................................................... 26
Table 6: Dataset Requirements – eMDR Message – Message Level data elements .................................. 32
Table 7: Dataset Requirements - General Request Information ................................................................ 35
Table 8: Dataset Requirements - eMDR Object - Audit Specific Information ............................................. 36
Table 9: Dataset Requirements - eMDR Object – Claim Related Information and Specific Documentation
Request ....................................................................................................................................................... 39
Table 10: Dataset Requirements – eMDR Object - Return Method Object................................................ 40
5/30/2012
3
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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 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
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.
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.
5/30/2012
4
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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:




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
In order to address the objectives above, this Initiative will include the following three workgroups.

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.
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 Consumer1. To
align with the short-term goals for CMS, the PPA workgroup took place first, and was followed by
1
Refer to Glossary Section for eMDR Consumer definition
5/30/2012
5
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
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:





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*
* 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.
5/30/2012
6
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
5/30/2012
7
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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 secure 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
5/30/2012
8
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
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.
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 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.
Individual Providers
Healthcare Administrators and
Managers
5/30/2012
9
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Member of Communities of Interests
Working Definition
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.
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.
Organizations within the federal government that deliver,
regulate or provide funding for health, healthcare, clinical, or
biomedical research.
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.
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.
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.
Standards Organizations
Government Agencies
Healthcare Payers
EHR/EMR / Financial System Vendors
Agent – (Clearing Houses and other
entities as defined by Health Insurance
Portability and Accountability Act
(HIPAA) including Health Information
Handlers)
5/30/2012
10
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Member of Communities of Interests
Working Definition
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:
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
Supply systems and integration services for other
intermediaries and Payer Contractors
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.
Other System Vendors
Operating Rule Authoring Entities
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 realworld 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:
5/30/2012
11
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer








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
5/30/2012
12
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.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
5/30/2012
13
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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. Example – a Health Information Handler will play the role of the Agent in the CMS User
Story.
Business Actor Generic
eMDR Consumer
Business Actor Specific
eMDR Consumer
Provider Agent
Health Information
Handler (HIH)
5/30/2012
System
Role
eMDR Consuming
Information System
 Receives and consumes eMDR
Agent Information
System
 Communicate eMDR to eMDR
consumer
 Information
14
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Requestor/Collector
 Information
Combiner2*/Router
Payer (Healthcare)
Medicare
Commercial
Payer Information
System
 Validates Providers against
current enrolled provider list
 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





Payer Contractors /
Intermediaries
Payer Contractors /
Intermediaries
Payer Contractor
Information System
 Provider Registration
Information Requestor
 Appropriate ESI Requestor
 Sends eMDR
Auditing
Transaction Logging
Routing
Transforming
Error Handling and
Notification
 Submitted Authentication
Table 2: Actors and Roles
Descriptions of the terms corresponding to the table above can be but are not limited to:




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
2
An Agent or an HIH may combine eMDR requests for various providers within a group practice or a hospital
system that originates from the payer or payer contractor
5/30/2012
15
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer


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.
5/30/2012
16
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
5/30/2012
17
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an 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.
5/30/2012
18
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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
5/30/2012
19
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
5/30/2012
20
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
Note – Steps 1 and 3 are required only if a Payer Contractor is involved.
Figure 6: Activity Diagram
10.2.1 Base Flow
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
5/30/2012
21
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
Step
#
Actor
Role
eMDR
Consumer’s
Registration
Information
Requestor
Event/
Description
1
Payer
Contractor
or
Intermediary
2
Payer
Provider
information
validator
Payer validates
eMDR Consumer
registration
status to receive
eMDRs using
internal
information
system
3
Payer
Provider
information
validator
Payer sends the
response to
Payer Contractor
/Intermediary
regarding eMDR
Consumer
registration
status
5/30/2012
Payer Contractor
/ Intermediary
sends a request
to the Payer for
eMDR Consumer
registration
status to receive
eMDR
Interoperability
or System Step
Inputs
Outputs
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
Query for eMDR
Consumer
registration status
to receive eMDR
Interoperability
Internally
validated eMDR
registration status
(including
confirmation of
eMDR Consumers
identity)
System
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
22
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Step
#
Actor
Role
4
Payer, Payer
Contractor or
Intermediary
Provider
Information
Manager,
Current ESI
Requestor
5
External
Provider
Directory
Provider
Information
Manager,
Current ESI
and Request
responder
6
Payer, Payer
Contractor or
Intermediary
Current ESI
Requestor
5/30/2012
Event/
Description
Payer, Payer
Contractor/
Intermediary
sends request to
External Provider
Directory to
retrieve current
ESI
Inputs
Response to
requestor
confirming
eMDR
Consumer
registration
status, External
Provider
Directory
address and
available
provider or
Agent’s ESI
information
from the
registration
request
External Provider Electronic
Directory locates Service
and sends
Information
requested
Query for a
provider
specific provider
demographics
to obtain
and ESI
current ESI
information to
Payer Contractor
/ Intermediary
Payer, Payer
Current
Contractor /
Electronic
Intermediary
Service
receives and
Information for
verifies provider
the specific
demographics,
eMDR
eMDR
Consumer
Consumer’s
current ESI, and
requested
integration
profile returned
by the External
Provider
Directory
Outputs
Interoperability
or System Step
Electronic Service Interoperability
Information Query
for a specific
eMDR Consumer
to obtain current
ESI
Current Electronic
Service
Information for
the specific eMDR
Consumer
requested
Interoperability
Verified Current
Electronic Service
Information for a
specific eMDR
Consumer
System
23
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Step
#
Actor
Role
Event/
Description
7
Payer, Payer
Contractor or
Intermediary
eMDR Sender
Payer, Payer
Contractor/
Intermediary
sends eMDR(s)
information to
eMDR Consumer
/ Agent
8
eMDR
Consumer /
Agent
eMDR Receiver
eMDR Consumer
/Agent
incorporates the
eMDR into their
system
Inputs
Outputs
Verified Current
Electronic
Service
Information for
eMDR
Consumer and
content of the
eMDR
eMDR(s)
Interoperability
or System Step
eMDR(s)
Interoperability
END
System
Table 3: Base Flow
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, IV-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
I
Payer Contractor
Information System
5/30/2012
Send
Information
Interchange
Requirement Name
Query to validate eMDR
Consumer’s registration
status to receive eMDR
Receiving System
Receive
Payer Information System
24
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
II
Payer Information
System
Send
III-A
Payer Information
System
Payer Contractor
Information System
External Provider
Directory
External Provider
Directory
Payer Contractor
Information System
Payer Information
System
Payer Gateway
Information System
Payer Contractor
Information System
Payer Information
System
Send
III-B
IV-A
IV-B
V-A
V-B
V-C
V-D
V-E
Receive
Payer Contractor Information
System
Receive
External Provider Directory
Receive
External Provider Directory
Receive
Payer Information System
Receive
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
Request for Current ESI
of eMDR Consumer
Request for Current ESI
of eMDR Consumer
Response for Current
ESI for eMDR Consumer
Response for Current
ESI for eMDR Consumer
eMDR
Send
eMDR
Receive
Send
eMDR
Receive
Payer Contractor Information
System
Payer Information Gateway
System
Payer Information Gateway
System
eMDR Consumer
Send
eMDR
Receive
eMDR Consumer
Send
eMDR
Receive
eMDR Consumer
Send
Send
Send
Receive
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
Agent /Access Information System
a. Incorporate eMDR
b. Receives eMDR
c. Translate /transform received eMDRs to industry
standard or proprietary transactions that can be
consumed by the provider eMDR Consuming Information
System
d. Translate /transform information between payer and
industry standard transactions
Payer Gateway Information System
5/30/2012
25
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
System
Payer Information System
System Requirement
Payer Contractor Information System
e.
f.
g.
h.
i.
j.
Provider Directory
k.
l.
m.
n.
o.
p.
q.
r.
s.
Validate eMDR Consumer registration status
Query Provider Directory for current ESI
Receive ESI
Incorporate ESI
Generate eMDR
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
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
5/30/2012
26
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
5/30/2012
27
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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

Table 6 - eMDR Message - Message Level data elements
eMDR Object - The structured content of the electronic medical documentation request




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)
No
Data Element
Description
Additional Notes
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.
This is a timestamp created by
the originator of the request
and propagated by all
intermediaries
Unique
eMDR
Message ID
Unique eMDR Message
ID
Timestamp
Timestamp of eMDR
Message
No
Date and Time the
eMDR message was
created
Unique Payer ID
No
Unique ID for the Payer
that will directly or
through a contractor
issue an electronic
request for medical
Payer
Organization
5/30/2012
28
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Payer
Contractor
Provider
Organization
documentation
The organization’s
name, street address,
city, state, and zip code
Demographics
 Name
 Address
 City
 State
 Zip Code
 Signature Artifact
No
No
Signature artifact
encrypted by owners
private key
 Public Digital
Certificate
Contact information
 Person / Role /
Department
 Telephone
 Email Address
 Fax
 URL
Unique Payer
Contractor ID
No
X.509 Token Profile
No
Information used to
contact the
organization by
telephone or email
No
Demographics
 Name
 Address
 City
 State
 Zip Code
 Signature Artifact
No
Unique ID for the Payer
Contractor that issues
an electronic request
for medical
documentation
The organization’s
name, street address,
city, state, and zip code
 Public Digital
Certificate
Contact information
 Person / Role /
Department
 Telephone
 Email Address
 Fax
 URL
Demographics
 Organization Name
No
5/30/2012
No
Exact nature of artifact to be
determined during
harmonization and Author of
Record
Signed by a trust authority
Contact would include a person
OR department OR role
(Example – Compliance
Officer). Contact information is
optional
Signature artifact
encrypted by owners
private key
X.509 Token Profile
Exact nature of artifact to be
determined during
harmonization
Signed by a trust authority
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
No
The organization’s
name, street address,
As registered with NPI or
alternative ID
29
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
(XYZ health system)
 Organization Address
 City
 State
 Zip Code
National Provider
Identifier (NPI)
Alternate ID (if no NPI)
city, state, and zip code
No
No
NPI issued to this
provider organization
or organization subpart by NPPES
ID issued to this
provider organization
or organization subpart 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
NPI
No
The individual’s name,
street address, city,
state, and zip code
No
Alternate ID (if no NPI)
No
NPI issued to this
provider organization
or organization subpart by NPPES
ID issued to this
provider organization
or organization subpart by Alternative ID
issuer
As registered with NPI or
alternative ID
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
5/30/2012
30
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Information
from eMDR
Object
Due Date
No
The date specified on
which the additional
documentation must
be submitted
Unique ID for eMDR
Object
Unique ID for eMDR
Object
No
Unique ID for original
eMDR Object
No
Unique ID for original
eMDR Object
Timestamp of eMDR
Object
No
Request Purpose
No
The Date and time
when the structured
content of the eMDR
included in this
message was created
Purpose of 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
Used only if this is a
replacement or termination
request
This is a timestamp created by
the originator of the request
and propagated by all
intermediaries
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
eMDR Object
No
Request Type
No
Request Type Reason
No
5/30/2012
Each request has one and only
one purpose. If information is
being requested for multiple
purposes, then multiple
requests should be created.
See table below
Structured Content of
the eMDR as an object
Indicator if this is a
Values: ‘New,’ ‘Replacement,’
replacement to a prior ‘Follow – Up,’ ‘Termination’
request, a new request,
follow up or a
termination request
Description of reason
for the replacement,
follow up or
31
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Message
Signature
Public Digital certificate
of transmitter
Signature Artifact
No
No
termination for a prior
request
X.509 Token Profile
Signed by a trust authority
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
Unique
eMDR ID
Unique ID for eMDR
Object
Timestamp
Timestamp of eMDR
Object
Multiple
Values
(yes/no)
No
No
Data Element
Description
Additional Notes
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.
Date and Time of the
eMDR Object
This element is identical to
Unique ID for eMDR Object
found under eMDR Message
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
5/30/2012
The organization’s
name, street address,
city, state, and zip code
32
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Payer
Contractor
Information
 City
 State
 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
 Public Digital
Certificate
No
Signature artifact
encrypted by owners
private key
X.509 Token Profile
Exact nature of artifact to be
determined during
harmonization
Signed by a trust authority
Payer Contact
information
 Person / Role /
Department
 Telephone Number
 Email
 Fax
 URL
No
Information used to
contact the
organization
Contact would include a person
OR department OR Role
(Example – Compliance
Officer). Contact information is
optional
Unique Payer
Contractor ID
No
Payer Contractor
Demographics
 Organization Name
 Organization Address
 City
 State
 Zip Code
 Signature Artifact
 Public Digital
Certificate
Payer Contractor
Contact information
 Person / Role /
Department
 Telephone Number
 Fax
 Email
5/30/2012
No
No
No
The URL to be provided
by payer for online
communication
between provider and
payer
Unique ID for the Payer
Contractor that issues
an electronic request
for medical
documentation
The organization’s
name, street address,
city, state, and zip code
Payer contractor on behalf of a
payer
Signature artifact
encrypted by owners
private key
X.509 Token Profile
Exact nature of artifact to be
determined during
harmonization
Signed by a trust authority
Information used to
contact the
organization.
Payer Contractor on behalf of a
payer.
Contact would include a person
OR department OR role
(Example – Compliance
Officer). Contact information is
optional
The URL to be provided
by payer contractor for
online communication
33
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
 URL
Individual
Provider
Information
Provider
Organization
Information
between provider and
payer contractor
The individual’s name,
street address, city,
state, and zip code
Individual Provider
Demographics
 First Name
 Middle Name
 Last Name
 Address
 City
 State
 Zip Code
NPI
No
Alternate ID (if no NPI)
No
Provider Organization
Demographics
 Organization Name
 Organization Address
 City
 State
 Zip Code
NPI
No
The organization’s
name, street address,
city, state, and zip code
No
Alternate ID (if no NPI)
No
NPI issued to this
provider organization
or organization subpart by NPPES
ID issued to this
provider organization
or organization subpart by Alternative ID
issuer
5/30/2012
No
NPI issued to this
provider organization
or organization subpart by NPPES
ID issued to this
provider organization
or organization subpart by Alternative ID
issuer
As registered with NPI or
Alternate ID
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
As registered with NPI or
Alternate ID
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
34
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
OID
Other
General
Information
Date of Request
No
The date that the
eMDR is sent
Cover Letter text
No
Program
No
Non computable text
corresponding to
statements required by
statutes, regulations or
contract
The type of program
that sends eMDR
Contact information for
this specific request
 Person / Role /
Department
 Telephone Number
 Email
 Fax
 URL
No
Information used to
contact the
organization
Date of request may be
different than timestamp of
eMDR Object depending on
processing of eMDR
Requesting Program examples
include MAC, RAC, ZPICS, CERT,
etc.
If different than the Payer or
Payer Contractor contact
information
The URL to be provided
by payer or payer
contractor for online
communication
between provider and
payer or payer
contractor
Table 7: Dataset Requirements - General Request Information
eMDR Object – Audit Specific Information
Section
Data Element
Audit
specific
Information
Scope or Type of Audit
Unique Claim Reference
Identifier
5/30/2012
Multiple
Values
(yes/no)
No
No
Data Element
Description
It is a codified field that
determines the type of
request including Pre
certification, Claim
Payment
Documentation, Audit,
Payment Recovery etc.
A unique number
associated with a
specific claim that
serves as a common
identifier used by both
the payer / payer
contractor and
Additional Notes
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
35
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Unique Case Reference
Identifier
No
provider
A case number used to
track one or more
related eMDRs. Serve
as a unique external ID.
control number.
Table 8: Dataset Requirements - eMDR Object - Audit Specific Information
eMDR Object - Claim Related Information and Specific Documentation Request
Section
Data Element
Document
Return
Requirements
Due Date
Multiple
Values
(yes/no)
No
Provider Directory
Address
Provider Directory ID
No
Return Method Object
Yes
Processor
Information
Claim Processor
Identifier
No
Patient
Information
Patient Name
No
Date of Birth
No
Account Number
No
Medical Record
Number
No
5/30/2012
No
Data Element
Description
Additional Notes
The date on which
information must be
submitted by
Electronic address of
the Provider Directory
An identifier assigned
to the provider
directory whose
purpose is to uniquely
identify the provider
directory from which a
set of data is returned.
See object definition
below.
The entity that
processes the claim
submission
Provider information
Identification of assigning
authority is to be determined
Examples – For CMS it would
be the Medicare Administrative
Contractors (MACs). It can also
be PBMs.
Name of the individual
that received health
services / care
Date of birth of the
patient that received
health services/ care
Identifier assigned by a
provider and
associated with a single
encounter for the
purposes of financial
management
A unique number
assigned to a patient
by the provider to
assist in management
36
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Payer Identifier for the
Policy holder
No
Payer Identifier for
Patient
No
Date Claim Received
No
Date(s) of Service
No
Type of Bill
Claim Level
Detail (all
data elements
are from the
submitted
claim
referenced in
this section,
unless
Place of Service
otherwise
indicated)
No
No
Diagnosis Code(s)
Yes
Diagnosis Code Set
Used
Diagnosis Related
Group Code
No
5/30/2012
No
of medical records
An identifier assigned
by the payer to the
policy holder under
which payment will be
made for this patient
An identifier assigned
by the Payer to identify
the patient
The date the claim for
which the eMDR is
requesting
documentation was
received by the claim
processor entity
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.
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.
Codes used on
professional claims to
specify the entity
where service(s) were
rendered
A diagnosis code
identifying a diagnosed
medical condition
Revision of diagnosis
code set
A classification system
that groups similar
clinical conditions
(diagnoses) and the
procedures furnished
by the hospital during
This field will be populated if
the holder of the policy and the
patient are different.
Example - Health Insurance
Claim Number for CMS
The date of service can be a
range
The first date is required
As defined by the National
Uniform Billing Committee in
Form locator 04
(www.nubc.org).
CMS maintains the code set for
Place of Service
Example - ICD 9, ICD 10
The code is derived by the
Grouper software
37
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Performing Provider
NPI
Performing Provider
Alternate ID
No
No
Alternate ID Type
No
Date(s) of Service
No
Line Level
Detail (all
data elements
are from the
submitted
claim
Place of Service
referenced in
this section,
unless
otherwise
indicated)
Revenue Code
No
No
Provider Specialty
No
Diagnosis Code
Yes
Procedure Code
No
5/30/2012
the stay.
The NPI of the provider
rendering the service
NPI Issued to this
provider by NPPES
Alternate ID of the
provider rendering the
service if the NPI is not
available
ID issued to this
provider by Alternate
ID issuer
A code value for the
source of the alternate
ID
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.
Example – State license
number, Commercial ID or
Location ID
The date of service can be a
range
The first date is required
Codes used on
professional claims to
specify the entity
where service(s) were
rendered
Identifies specific
accommodations,
ancillary services and
billing calculations as
determined by the
National Uniform
Billing Committee in
Form locator 42.
The area of medicine or
surgery in which a
clinician specializes
CMS maintains the code set for
Place of Service
One or more of the
diagnosis codes
identified in the Claim
Level that apply to this
line level item
HCPCS Code or HIPPS
Either the claim level diagnosis
code or up to 4 pointers to the
claim level diagnosis code
www.nubc.org
Example - Acupuncture,
Internal Medicine, Neurology,
Pathology etc.
HCPCS Codes, Healthcare
38
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Code
Procedure Modifier(s)
Documentatio Documentation
n Requested Requested
eMDR
Message
Signature
Yes
Yes
Specific modifier(s)
defined for HCPCS code
Documentation that
must be provided in
response to this eMDR
Description of
Documentation
Requested
Yes
Description of
documentation that
must be provided in
response to this eMDR
Public Digital certificate
of transmitter
No
X.509 Token Profile
Signature Artifact
No
Signature Artifact
encrypted by
transmitter’s private
key
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
Claim formats currently
support up to 4 modifiers
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
This can be medical
documentation or other types
of documentation necessary to
support the claim.
Signed by a trust authority. For
CMS, certificates must be
issued by authorities cross
certified with the Federal
bridge.
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
Section
Data Element
Multiple Data Element
Values
Description
(yes/no)
Return
Return Method(s)
No
The method by which a
Method
provider or provider
5/30/2012
Additional Notes
Defines the high level
transport to be used for the
39
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
Object
organization may return
the additional
documentation
requested in the eMDR
Electronic Service
Information (Electronic
Service Information
Object)
No
Physical Return
Address (Physical
Return Address Object)
Maximum Electronic
Return Size per
transaction
No
Return Constraints
Yes
Return Constraints for
this specific Return
Method - Physical,
Electronic Transaction,
URI
Return Format(s)
Yes
Return Formats allowed
for this specific Return
Method - Physical,
Electronic Transaction,
URI
No
Description of electronic
services supported by
the Payer / Payer
Contractor organization.
This is an object
The physical return
address for the
organization.
The maximum size
allowed per return
transactions in
megabytes
return. Transport could be:
Physical, Electronic
Transaction, and Universal
Resource Identifier (URI)
See Return Format below
Use ESI Object developed in
the Provider Directory data
model found here.
This will be the Address Object
from PPA UC 1.
Payer and Provider will need
to support multiple
transactions per submission if
documentation requirement
exceeds maximum return size
or use an alternative method
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.
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
5/30/2012
40
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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
5/30/2012
41
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer
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.
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 patient, and the provider, supplier, or
patient requesting payment must furnish the appropriate payer with sufficient information to
determine the amount of payment.
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 (Example - discharge summary, patient summary,
laboratory report, query for patient/provider/healthcare data). The information should include
the type of information (Example - patient summary or query) the destination’s Electronic
Address (see definition above), the Messaging Framework supported (Example - SMTP,
HTTP/SOAP), Security information supported or required (Example - digital certificate) and
specific payload definitions (Example - CCD C32 V2.5). In addition, this information may include
labels which help identify the type of recipient (Example - 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
5/30/2012
42
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer











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.3
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. 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 (Example - 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. 4
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
3
http://sig.nfc.usda.gov/pki/glossary/glossary.html
http://healthit.hhs.gov/portal/server.pt?open=512&objID=1407&parentname=CommunityPage&parentid=8&mo
de=2&in_hi_userid=11113&cached=true
4
5/30/2012
43
Use Case and Functional Requirements Development for Interoperability
esMD Use Case 2 – Secure Transportation and Structured Content of electronic Medical
Documentation Request (eMDR) from a Payer to an eMDR Consumer





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


CMS esMD Program - http://www.cms.gov/esMD/
FISMA Requirements
o http://fismapedia.org/index.php?title=Guide:_FISMA_Requirements
o http://www.cms.gov/InformationSecurity/Downloads/ssl.pdf
5/30/2012
44