PPA+Use+Case+1+-+Provider+Registration+with+Payer

include component="page" wikiName="siframework" page="esMD Header" Visit the following page for information on Use Case 1 Provider Registration: UC -1 Provider Registration Visit the following page for information on the Harmonization of Use Case 1: Harmonization UC -1


 * __ Thank you for your participation!! __**As of March 19th, 2012 the esMD PPA Provider Registration Use Case 1 has been finalized. The document below as well as the text embedded within the Wiki reflect updates that were proposed and agreed upon during the formal Consensus Process. Please contact the Workgroup Lead or Support Lead if you have any remaining questions or concerns.

To view the esMD PPA Provider Registration Use Case consensus page please ** click here **
 * Meetings for closed work-products, including Use Case 1-related meetings can be found ** **here**
 * [[file:SIFramework_esMD_PPA_UC1.docx|Click here]]** to download the MS Word version of the Use Case.

=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 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, 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 IHE XDR wrapper. There is added value to CMS, Commercial Payers, and Providers in pursuing additional automation of the electronic request and submissions process.

CMS continues to investigate additional capabilities of electronic submission of medical documentation. The next release, esMD Phase 2, is planned for January 2013, which enables Medicare Review Contractors to send electronic medical 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 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 Provider Registration with a payer entity within the Provider Profiles Authentication workgroup . To align with the short-term goals for CMS, the PPA workgroup will take place first, and be 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 first Use Case is registration of providers to receive eMDRs, and the second use case is the secure transmission of the eMDR from the payer to the registered provider.
 * 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 document requests 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: Discusses the registration process, technical transport and authentication needed to allow Payers to identify Providers and send requests to them. This workgroup will be 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 workgroup Provisional Assignment: Determine the structured electronic format of medical document request letters to be sent to Providers, with consideration for the technical transport, expected response and fields needed to support the response
 * Author of Record workgroup Provisional Assignment: Evaluate the business needs and discuss implementable solutions to prove the authorship and authenticity of any medical documentation submitted in response to a payer or contractor request

Key objectives specifically for the PPA workgroup are to define the business requirements related to the registration process, compliant with CMS policies and FISMA guidelines for the CMS User Story, and determine how to securely send medical document requests to registered providers. In addition to addressing requirements, this workgroup will also analyze and harmonize standards to support secure electronic sending of medical document requests. Business requirements and standards will have a key focus on the needs of CMS and the CMS post-payment Review Contractors, while also considering options to enable re-use of the processes and standards by other Payers and Medicare partners.

2.1 Initiative Challenge Statement
CMS and other appropriate 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 document requests and the electronic __submission__ of medical documentation, the following solutions will be required: > > * Structured Content for claims attachments 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 whether or not applicable standards will be suitable for structured content 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 for claims attachments*

2.1.1 PPA Purpose Statement
The specific purpose of the PPA workgroup is to evaluate solutions to: > =3.0 Use Case Scope=
 * 1) Register providers with CMS and other payers to receive eMDRs and
 * 2) Support CMS and other payers in securely sending eMDRs to Agents and Providers

The Electronic Submission of Medical Documentation (esMD) Initiative intends 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.

The initial phase of this Initiative will focus on the Use Cases and Functional Requirements related to eMDRs, in alignment with CMS’ goals for the CMS esMD Phase 2 implementation. This will involve the creation of two use cases:
 * 1) Provider Registration with Payer to receive eMDR
 * 2) Secure sending of eMDR from Payer/Contractors to Registration Requestor



Figure 1: Generic Context Diagram – Overall S&I Framework esMD Initiative for PPA

Note – The diagram above illustrates the full PPA Use Case Diagram. Use Case 1 does not incorporate the Contractors/Intermediaries in the registration process. This will be covered in Use Case 2.

This Use Case (UC # 1 listed above), focuses on the registration process required in order for Payers and Payer Contractors to send communications containing PHI to providers. Use Case 2 (not included in this document) will include the requirements related to sending an eMDR from the Payer and Payer Contractor to the Registration Requestor (Provider/Provider Organization/ Agent). A provider must follow the registration steps detailed in Use Case 1, before the Payer and Payer Contractors can send them the eMDR in Use Case 2. 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 or Payer Contractors will be capable of sending an eMDR even if a provider or provider organization is 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 and misdirected communications, and establish the transactions required to initiate an electronic response. This use case, combined with esMD Use Case 2 (which addresses s ecure sending of eMDR from Payer/Contractors to registered providers), aims to reduce the need to mail paper request letters by replacing them with electronic alternatives. The first Use Case in particular focuses on the registration process required for Providers to indicate to the Payer that they wish to receive eMDRs instead of paper medical documentation request letters. 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.

Although the FISMA requirements are applicable to Federal agencies and therefore 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
>
 * Provider Registration process to receive eMDRs, in compliance with CMS and other payer requirements.
 * Requirements for standards pertaining to technical transport and authentication needed to allow CMS/Payers to receive registration requests for electronic medical document request from providers, either directly or via Agent.

3.3 Out of Scope
>
 * Guidelines and Policies for the medical documentation request letter, including limitations on the frequency and volume of the request letters, and what scenarios will warrant a need for additional claims attachments.
 * Standards for Structured Content of claims attachments sent from providers to payers/CMS.
 * Structure of eMDR will be covered in Use Case 2 and Structured content workgroup.
 * Requirements and standards pertaining to technical transport and authentication needed to allow CMS/Payers to send medical document request letter to specific providers, either directly or via Agent will be covered in Use Case 2
 * Secured sending of the eMDR will be covered in Use Case 2.
 * Authentication of content sent from Providers will be covered in the Author of Record workgroup.

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) RAC-Recovery Audit Contractors (Soon to be MRA - Medicare Recovery Auditor) PERM – Payment Error Rate Measurement CERT –Comprehensive Error Rate Testing ZPICS – Zone Program Integrity Contractors || Table 1: Communities of Interest
 * **Member of Communities of Interests** || **Working Definition** ||
 * 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, and other management personnel 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 HIPAA including Health Information Handlers) || Any organization that handles health information on behalf of a provider 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 that are established to prevent improper payments before a claim is processed as well as identify any improper payments that can be recouped after a claim is processed. 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. ||

=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 document 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 and consolidated Clinical Document Architecture (CDA) solutions 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 IT infrastructure to incorporate and validate signatures as part of structured documents.

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
 * Improves receipt 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
 * Promotes reduction in paper errors
 * Registration Process might be used by other Federal agencies and payers
 * Mechanisms/standards to send medical request letter might be used by Payers
 * Registration Process following FISMA requirements might be used by other Federal agencies and payers
 * Mechanisms/standards to send medical request might be used by other Payers and stakeholders, such as Commercial Payers.

**Relevance outside of CMS-esMD **


 * Registration Process following FISMA requirements might be used by other Federal agencies and payers
 * Mechanisms/standards to send medical request might be used by other Payers and stakeholders, such as Commercial Payers.

=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 that one is more important than another. >
 * 1) The electronic provider registration request will be in a structured electronic format (to be determined through the S&I Standards harmonization process).
 * 2) Providers will be identified by their National Provider Identifier (NPI) for registration. When a provider is not eligible to be issued an NPI, other unique provider identification can be used.
 * 3) Each provider registration request is for one individual or entity identified by a single NPI. When a provider is not eligible to be issued by an NPI, other unique provider identification can be used.
 * 4) The External Provider Directory can be a Provider's Internal PD, Payer entity’s Internal PD, or provided by a third party data source, Regional Health Information Organization (RHIO), Health Information Exchange (HIE), or PD established at the community, state, or national level.
 * 5) Gateways, if used by the payer, will support provider registration activities.
 * 6) All transactions will  utilize industry accepted standards, where available.
 * 7)  All transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, reliability; and with authentication of both the sender and receiver.
 * 8) All transactions will be delivered in a timely manner.
 * 9) Providers and/or Agents will register ESI information with the appropriate PD.
 * 10) Registration will not expire, but may be subject to reasonable update and termination conditions as determined by each payer.
 * 11) The transport of content and required data elements will be discussed during the harmonization phase.
 * 12) Inconsistencies between the registration request, payer internal systems and external provider directory will be managed based on individual payer rules.

5.1 – CMS User Story Additional Assumptions
>
 * 1) esMD Gateway is used by CMS and will support provider registration activities.
 * 2) All transactions will use NwHIN Exchange.
 * 3) CMS requires that all providers who wish to receive eMDRs to use this process.
 * 4) Digital certificates must be issued by Certificate Authorities cross certified with the Federal Bridge.

5.2 – Commercial Payer User Story Additional Assumptions
> =6.0 Generic Pre-Conditions=
 * 1) None. All Generic Assumptions apply for Commercial Payer.
 * 1) Provider or Agent can submit all required information electronically to payer entity to begin registration process.
 * 2) Payer entity can receive and process electronic requests for registration.
 * 3) Provider entity or Agent supports the required transaction and payload standards for the registration request.
 * 4) Participating entities have completed any required onboarding processes.
 * 5) Participating entities have signed any required participation or data use agreements.
 * 6) Payer internal information systems are established and in place for timely information verification.
 * 7) External Provider Directories are established and in place for timely information verification.
 * 8) External Provider Directories have the ability to receive information request queries sent from payer entities, process them, and respond back to payers using the S&I PD data sets.
 * 9) Payer entities can receive and process ESI information from External Provider Directories.
 * 10) Providers or Agents can receive and act on registration request confirmations (both affirmative and rejection) from Payer entities.

=7.0 Generic Post Conditions= >
 * 1) Providers and Agents will maintain the ability to receive eMDRs after successful registration unless terminated through established mechanisms.
 * 2) Provider registration information is maintained by the payer and available for use by the payer or other users of the provider registration system.

7.1 CMS User Story Additional Post-Conditions
>
 * 1) None. All Generic Post-Conditions apply for Commercial Payer

7.2 Commercial Payer User Story Additional Post-Conditions
> =8.0 Actors and Roles=
 * 1) None. All Generic Post-Conditions apply for Commercial Payer.

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. The system or system actor has roles (send, receive, publish, subscribe or in some cases display) and actions which involve exchanging content. Please see the table below for an example of these designations.

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** ||
 * Registration Requestor || Registration Requestor || Registration Requestors Information System || * Provider Information Source
 * Registration Requestor and Confirmation Receiver ||
 * Provider Agent / Access || Health Information Handler (CMS) || Agent/Access Information System || * Information Requestor/Collector
 * Information Combiner/Router ||
 * Payer (Healthcare) || Medicare

Commercial || Payer Information System || * Validates Providers against current enrolled provider list Table 2: Actors and Roles
 * Confirms ESI to receive MDRs electronically
 * Respond to registration request ||
 * External Provider Directory || External Provider Directory || Provider Directory || * Manage Provider Information
 * Stores and responds to queries for Provider Information ||
 * Payer Gateway || esMD Gateway (CMS) || Payer Gateway Information System || * Auditing
 * Transaction Logging
 * Routing
 * Transforming
 * Error Handling and Notification
 * Submitted Authentication ||

Expanded descriptions of the terms corresponding to the table above can be but are not limited to: > =9.0 Use Case Diagrams=
 * __ Registration Requestor __ - Provider, Provider Organization, Agent
 * __ Registration Requestors Information System __ - Provider Directory / Billing System / Medical Records System
 * __ Agent/Access 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

Figure 3: Use Case Diagram

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.



Figure 4: CMS Context Diagram

The CMS Context Diagram above is specific to the CMS User Story. A Registration Requestor can send a request either directly to CMS or through a Health Information Handler (HIH); however, all requests must go through the esMD Gateway prior to reaching CMS. In return, all registration requests responses must go through the esMD Gateway prior to being returned to either the HIH or the Registration Requestor.



Figure 5: Commercial Payer Context Diagram

The Commercial Payer Context Diagram above is specific to the Commercial Payer User Story. A Registration Requestor can send a request either directly to Commercial Payer or through an Agent. Requests may go through the Gateway prior to reaching the Commercial Payer. In return, all registration requests responses may go through the Gateway prior to being returned to either the Agent or the Registration Requestor.

=10.0 Scenario=

An information requestor such as a provider/provider organization or an Agent on behalf of a provider sends a registration request to the payer. The registration request is for the ability to receive electronic Medical Documentation Request (eMDR) from the payer.

10.1 Generic User Story
The Provider Profile Authentication (PPA) work stream is a two part process. The first part is covered in this Use Case and is associated with the provider sending a registration request to a payer entity in order to receive the Medical Documentation Request electronically (eMDR). The provider or Agent submits a registration request to the payer. The payer entity could be CMS (Medicare) or Commercial Insurance[1]. A secure, trusted registration request is received by the payer entity, and provider eligibility to receive eMDR (including provider identity) is validated by the payer. The payer then requests Electronic Service Information (ESI) from an External Provider Directory using the validated provider’s identity to determine the capability of provider or Agent to receive an eMDR. If a valid ESI for eMDR is received by the payer entity from the External Provider Directory, a confirmation is sent to the provider or Agent as appropriate to notify them of their registration status. The provider’s registration request can be either confirmed or rejected by the payer entity. If the registration request is confirmed, the payer will attempt to send all future MDRs electronically. If the provider registration request is rejected, the provider does not receive eMDRs and can submit another registration request.

10.1.1 CMS User Story
The provider or Health Information Handler (HIH) submits a registration request to CMS. A secure, trusted registration request via NwHIN Exchange is received by CMS, and provider eligibility to receive eMDR (including provider identity) is validated by CMS. CMS then requests Electronic Service Information (ESI) from an External Provider Directory using the validated provider’s identity to determine the capability of provider or HIH to receive an eMDR. If a valid ESI for eMDR is received by CMS from the External Provider Directory, a confirmation is sent to the provider or HIH as appropriate to notify them of their registration status. The provider’s registration request can be either confirmed or rejected by the payer entity. If the registration request is confirmed, the payer will attempt to send all future MDRs electronically. If the provider registration request is rejected, the provider does not receive eMDRs and can submit another registration request.

10.1.2 Commercial User Story
The provider or Agent submits a registration request to the payer. A secure, trusted registration request is received by the payer entity, and provider eligibility to receive eMDR (including provider identity) is validated by the payer. The payer then requests Electronic Service Information (ESI) from an External Provider Directory using the validated provider’s identity to determine the capability of provider or Agent to receive an eMDR. If a valid ESI for eMDR is received by the payer entity from the External Provider Directory, a confirmation is sent to the provider or Agent as appropriate to notify them of their registration status. The provider’s registration request can be either confirmed or rejected by the payer entity. If the registration request is confirmed, the payer will attempt to send all future MDRs electronically. If the provider registration request is rejected, the provider does not receive eMDRs and can submit another registration request.

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



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 the associated inputs (records/data required to undertake the action) and outputs (records/data produced by actions taken). Table 3: Base Flow Note - *Transaction defined above in steps 1-2 refers to exchange of structured information based on a national standard.
 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** || **Interoperability or System Step** ||
 * 1 || Registration Requestor / Agent || Registration Requestor and Confirmation Receiver || Registration Requestor sends an electronic registration request to Payer Entity || Provider registration information || Provider registration transaction* || Interoperability ||
 * 2 || Payer / Gateway || Validates and Registers Providers || Payer validates provider eligibility (including provider identity) to receive eMDRs using internal information system || Provider registration transaction* || Internally validated provider eligibility (including confirmation of provider identity) || System ||
 * 3 || Payer /Gateway || Confirms ESI to receive MDRs electronically || Payer sends Electronic Service Information query to External Provider Directory to determine capability of provider/Agent to receive eMDR || Internally validated provider eligibility (including provider identity) || Electronic Service Information Query for a specific provider || Interoperability ||
 * 4 || External Provider Directory || Manage Provider Information || External Provider Directory locates and returns requested ESI information || Electronic Service Information Query for a specific provider || Determination of the provider’s ability to receive eMDR || System ||
 * 5 || External Provider Directory || Manage Provider Information || External Provider Directory sends validation back to Payer || Determination of the provider’s ability to receive eMDR || Electronic Service Information Response for a specific provider || Interoperability ||
 * 6 || Payer / Gateway || Confirms ESI to receive MDRs electronically || Payer determines if provider is capable of receiving eMDR based on ESI information returned by the External Provider Directory and incorporates the information || Electronic Service Information Response || Verified record of the providers ability to receive eMDR || System ||
 * 7 || Payer / Gateway || Confirms ESI to receive MDRs electronically || Payer sends validation information to Registration Requestor || Processed registration request || Response to provider registration request || Interoperability ||
 * 8 || Registration Requestor / Agent || Registration Requestor and Confirmation Receiver || Registration Requestor incorporates the response into their system || Response to provider registration request || 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. Functional requirements are of two types: Information Interchange Requirements and internal System Requirements. Note: The steps below are not outlined in a sequential order.

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.

Table 4: Information Interchange Requirements
 * || **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * I || Registration Requestors Information System || Send || Registration Request || Receive || Payer Gateway Information System ||
 * II || Payer Gateway Information System || Send || Registration Request || Receive || Payer Information System ||
 * III || Payer Information System || Send || ESI Query || Receive || Provider Directory ||
 * IV || External Provider Directory || Send || ESI Query Response || Receive || Payer Information System ||
 * V || Payer Information System || Send || Registration Request Response || Receive || Payer Gateway Information System ||
 * VI || Payer Gateway Information System || Send || Registration Request Response || Receive || Registration Requestors Information System ||

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, essential to the Use Case.
 * **System** || **System Requirement** ||
 * Registration Requestors Information System || # Able to compile information required for registration
 * 1) Have internal controls to ensure all necessary registration information is compiled/properly packaged prior to sending to Payer Information System ||
 * Agent /Access Information System || # Have internal controls to ensure all necessary registration information is compiled/properly packaged prior to sending to Payer Information System
 * 1) Translate /transform information between provider and industry standard transactions ||
 * Payer Gateway Information System || # Translate /transform information between payer and industry standard transactions ||
 * Payer Information System || # Receive electronic registration request
 * 1) Validate provider information
 * 2) Query Provider Directory for ESI
 * 3) Validate and formulate response to provider registration request ||
 * Provider Directory || # Provide demographic and ESI information in the required format to the requestor
 * 1) Provide appropriate error messages
 * 2) Select appropriate provider based on query parameters
 * 3) Return provider demographic in ESI or appropriate error message ||

Table 5: System Requirements

10.4 Sequence Diagram


Figure 7: Sequence Diagram

=11.0 Risks, Issues and Obstacles=

This list is intended to be a starting point which will need further consideration as esMD Provider Registration process with payer entity grows and is further refined. > =12.0 Dataset Considerations=
 * Ensuring secure, trusted communications between payers and providers or Agents
 * Compliance with FISMA for transactions to CMS and other relevant federal agencies or their Agents
 * Time required to ensure CMS solution aligns with other payer requirements
 * Availability of dataset information from requesting provider or Agent (ex. If the registration requestor does not have an NPI or Alternate ID)
 * Inconsistencies in information provided in the registration request with information contained in payer internal systems or External Provider Directory (ex. If a provider is registered differently in both systems T. Smith and Tom Smith)
 * 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 federation
 * Potential for misidentification of a desired ESI destination and the inappropriate sharing of information
 * Potential opportunities for unauthorized organization to register and obtain eMDR
 * Potential for expired information if consumer system caches destination and electronic service information

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. For the purposes of this section, do not assume that any data elements are inferred and provide elements at their most granular level. For example, if it is necessary to specify a zip code, do not use the less specific data element set ‘address.’ // Note: Data element sets are defined for reuse within the Use Case Simplification Work Group. The identification of data elements forms the foundation for harmonization activities. The data elements identified in the Use Case set constraints on the contents of documents and messages. //

Time || No || Date and Time of the request transaction || This is a timestamp created by the originator of the request and propagated by all intermediaries ||
 * //Registration Request://**
 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * Unique Transaction ID || Unique Transaction ID || No || Unique ID for this transaction || Transaction IDs must be globally unique across all payers and able to accommodate expected transaction volumes (Ex. UUID) ||
 * Timestamp || Date
 * 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 ||
 * ^  || 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 trust authority ||
 * ^  || 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 || ID should include the issuer and the ID itself to allow tracking ||
 * ^  || __ Contact information __
 * Person / Role / Department
 * Telephone Number
 * Email || No || Information used to contact the organization by telephone or email || Contact would include a person OR department OR role. Contact information is optional ||
 * 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 ||
 * ^  || 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 trust authority ||
 * ^  || NPI || No || NPI issued to this provider by NPPES ||   ||
 * ^  || Alternate ID (if no NPI) || No || ID issued to this provider by Alternative ID issuer ||   ||
 * ^  || __ Contact information __
 * Person / Role / Department
 * Telephone Number
 * Email || Yes || Information used to contact the individual by telephone or email || Contact would include a person OR department OR role. Contact information is optional ||
 * Agent || Organizational Identifier (OID) || No || The Agent’s identification || Identification for the HIH (CMS) or other Unique Identifier (Commercial Payer) ||
 * ^  || Demographics
 * Organization Name (XYZ health system)
 * Organization 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 trust authority ||
 * ^  || __ Contact information __
 * Person / Role / Department
 * Telephone Number
 * Email || No || Information used to contact the individual by telephone or email || Contact would include a person OR department OR role. Contact information is optional ||
 * Request Information || NPI to register (one of the two possible above) || No || NPI to register (must be either the organization or individual NPI if it exists) || If both organizational NPI and individual NPI are included above, this is the NPI to register ||
 * ^  || Alternative ID (if required) || No || Alternative ID to register (When a provider is not eligible to be issued an NPI, other unique provider identification can be used) || If both organizational Alternative ID and individual Alternative ID are included above, this is the Alternative ID to register ||
 * ^  || Service || No || Service for which the provider is registering || Current Use Case: Registering for eMDR. A code set will need to be identified or created that includes initially a code for eMDR service ||
 * ^  || Options || Yes || Options required / allowed for the Service ||   ||
 * ^  || Update || No || Indicator if this is an update to a prior request or a new request || Values: ‘New’ and ‘Update’ ||
 * Provider Directory Information || Provider Directory ID || No || Unique Id of the provider directory ||  ||
 * ^  || Provider Directory Address || No || Electronic address of the provider directory ||   ||
 * ^  || Unique Organization ID || No || Unique Organization ID in the PD || Optional ||
 * ^  || Unique Provider ID || No || Unique Individual Provider ID in the PD || Optional ||
 * ^  || ESI ID || No || Unique ESI ID in the PD || Optional ||
 * ^  || ESI Integration Profile || No || Integration Profile to use || Optional ||
 * Message Encryption || Public Digital certificate of transmitter || No || X.509 Token Profile || Signed by trust authority ||
 * ^  || Encrypted hash of message || No || Digest (hash) of the message encrypted with the transmitters private key ||   ||

Table 6: Dataset Requirements – Registration Request

Time || No || Date and Time of the request transaction || This is a timestamp created by the originator of the request response and propagated by all intermediaries || Zip Code || No || The organization’s name, street address, city, state, and zip code ||  || Email || No || Information used to contact the individual by telephone or email || Contact would include a person OR department OR role. Contact information is optional || Individual Provider information
 * //Registration Request Response://**
 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * Unique Payer ID || Unique Payer ID || No || Unique ID for the Payer || Some examples are National Association of Insurance Commissioners (NAIC) and potentially Health Plan Identifier (HPID) ||
 * Timestamp || Date
 * Payer Organization || 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 trust authority ||
 * ^  || Contact information
 * Person / Role / Department
 * Telephone
 * Email Address || No || Information used to contact the organization by telephone or email || Contact would include a person OR department OR role. Contact information is optional ||
 * Agent || Organizational Identifier (OID) || No || The Agent’s identification || Identification for the HIH (CMS) or other Unique Identifier (Commercial Payer) ||
 * ^  || Demographics
 * Organization Name (XYZ health system)
 * Organization Address
 * City
 * State
 * ^  || 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 trust authority ||
 * ^  || __ Contact information __
 * Person / Role / Department
 * Telephone Number
 * Information From Original Request || Organization Information
 * First Name
 * Middle Name
 * Last Name
 * Address
 * City
 * State
 * Zip Code
 * NPI / Alternate ID || No || The individual’s name, street address, city, state, and zip code || Return information from original request ||
 * ^  || Transaction ID || No || Unique ID from the registration request ||   ||
 * Request Information Processed || NPI || No || NPI to register (must be either the organization or individual NPI if it exists) || If both organizational NPI and individual NPI are included above, this is the NPI to register ||
 * ^  || Alternative ID || No || Alternative ID to register (When a provider is not eligible to be issued an NPI, other unique provider identification can be used) || If both organizational Alternative ID and individual Alternative ID are included above, this is the ID to register ||
 * ^  || Service || No || Service for which the provider is registering || Current Use Case: Registering for eMDR. A code set will need to be identified or created that includes initially a code for eMDR service ||
 * ^  || Options || Yes || Options required / allowed for the Service ||   ||
 * ^  || Update || No || Indicator if this is an update to a prior request or a new request || Values: ‘New’ and ‘Update’ ||
 * Provider Directory Information || Provider Directory ID || No || Unique Id of the provider directory || Provider Directory ID ||
 * ^  || Provider Directory Address || No || Electronic address of the provider directory || Provider Directory Address ||
 * ^  || ESI ID || No || Unique ESI ID in the PD || Optional ||
 * ^  || ESI Integration Profile || No || Integration Profile to use || Optional ||
 * Request Status || Unique Registration ID || No || Unique ID generated by payer for this registration request ||  ||
 * ^  || Success or Failure || No || Status of Request: Success, Failure, Pending ||   ||
 * ^  || Failure Reason(s) || Yes || If Request fails, need code set for failure reason(s) || Need code set for failure reasons ||
 * Message Encryption || Public Digital certificate of transmitter || No || X.509 Token Profile || Signed by trust authority ||
 * ^  || Encrypted hash of message || No || Digest (hash) of the message encrypted with the transmitter s private key ||   ||

Table 7: Dataset Requirements – Registration Request Response

=Appendices=

Appendix A: Related Use Cases

 * Provider Directories Use Case 2 – Electronic Service Information

Appendix B: Glossary of Terms

 * ** Alternate ID ** - An alternate ID can be used if a Registration Requester is not eligible to obtain an NPI.
 * ** Atypical Service Provider ** - Entities or individuals that are not defined as a health care provider; however, they do provide services that are payable by some health plans. Examples are taxi drivers, auto mechanics and carpenters.
 * ** Centers for Medicare and Medicaid Services (CMS) ** –CMS is used in this Use Case to refer specifically to Medicare
 * ** 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.
 * ** 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
 * **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[|[2].
 * ** Federal Information Security Management **** (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
 * ** Medicare Administrative Contractors (MACs) - ** Process claims submitted by physicians, hospitals, and other health care providers/suppliers, and submit payment to those providers in accordance with Medicare rules and regulations. This includes identifying and correcting underpayments and overpayments.
 * ** Medicare Recovery Auditors (MRA, formerly Recovery Audit Contractor, RACs) ** - 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.
 * ** Nationwide Health Information Network (NwHIN) Exchange - ** A  confederation of trusted entities, bound by mission and governance to securely exchange health information. [|[3]
 * ** Payment Error Rate Measurement (PERM) ** - 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 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 contains 2 use cases. This document contains Use Case #1 which focuses on provider registration with a Payer in order to receive electronic Medical Documentation Requests
 * ** Regional Health Information Organization (RHIO) ** – Regional Health Information Organization
 * ** 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 - []
 * FI SM A Requirements

o []

o []

[1] The provider registration process defined in this Use Case is not mandatory for any non-CMS payers. [|[2] http://sig.nfc.usda.gov/pki/glossary/glossary.html [|[3] http://healthit.hhs.gov/portal/server.pt?open=512&objID=1407&parentname=CommunityPage&parentid=8&mode=2&in_hi_userid=11113&cached=true

1. None. All Generic Pre-Conditions apply for Commercial Payer.

include component="page" wikiName="siframework" page="space.template.inc_contentleft_end"