esMD+Use+Case+3+-+Digital+Identities+and+Submission+Level+Signatures+Use+Case

include component="page" wikiName="siframework" page="esMD Header"

=
All of the Use Case materials listed below have been consensus-approved and published to the [|S&I Framework Repository Browser]. For un-published, draft versions of any materials refer to the appropriate S&I Phase and/or workgroup.====== Consensus voting for esMD Use Case 3 is now closed. Click here to see the votes. include component="page" wikiName="siframework" page="esMD AoR Workgroup Artifacts" Click to download the Use Case in a MS Word document =1.0 Preface and Introduction= To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange; maximize efficiency, encourage rapid learning, and protect patients’ privacy in an interoperable environment. These Use Cases address the requirements of a broad range of Communities of Interests including: patients, their significant others and family members, providers, payers, vendors, standards organizations, public health organizations, and Federal agencies. These Use Cases describe: The Use Case is the foundation for identifying and specifying the standards required to support the data exchange and developing reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards. =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.
 * 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

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

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

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

The key objectives for the overall S&I Framework esMD Initiative include: In order to address the objectives above, this Initiative will include the following three workgroups: =2.1 Initiative Challenge Statement= The Centers for Medicare and Medicaid Services (CMS) and other Health Plans/Payers need a standardized, implementable, machine-interoperable electronic solution to reduce the time, expense, and paper required in current manual processing of both medical documentation request letters and the relevant medical documentation exchanged between Healthcare Providers and Health Plans/Payers. The challenge at hand is to identify the requirements to verify the origin and authenticity of data submitted to CMS and other Health Plans/Payers for proper medical documentation processing. =3.0 Use Case Scope= This workgroup will investigate and recommend solutions on various levels of Author of Record needs: The scope of effort includes the five focus areas for the Author of Record Workgroup identified during the initial pre-discovery efforts: 1) Identity Proofing, 2) Digital Identity Management, 3) Digital Signatures, 4) Delegation of Rights, and 5) Encryption (encryption only as it pertains to protecting the confidentiality of payloads containing PHI).
 * Develop a registration process to allow Providers to sign up to receive electronic medical documentation requests from CMS Review Contractors
 * Identify a standards-based machine-interoperable electronic format to provide an alternate electronic method for the current paper version of the medical documentation requests that are sent to providers
 * Identify a secure method of sending medical documentation requests from CMS review contractors to providers
 * Identify a solution that will enable an electronic replacement of wet signatures, for medical documents submitted from providers to CMS
 * Provider Profiles Authentication (PPA) workgroup: Addresses the registration process, technical transport and authentication needed to allow Payers to identify Providers and send requests to them. This workgroup is dependent on the Provider Directories Use Case #2 (Electronic Service Information Discovery) outputs, as well as the Exchange support (for the CMS User Story) for secure transport and other infrastructure.
 * Structured Content (SC) workgroup: Determines 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 : Evaluates 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 (esMD UC 1), the electronic submission of the structured medical documentation request (esMD UC 2) and the response by the provider or their agent to the payer or payer contractor.
 * AoR Level 1 – Digital signature on aggregated Medical Documentation bundle*
 * AoR Level 2 – Digital signature on an individual document
 * AoR Level 3 – Digital signature to allow traceability of individual contributions to a document
 * This Use Case document only focuses on AoR Level 1 Use Case. AoR Level 2 and Level 3 Use Cases will be developed at a later time.

The workgroup will focus on Identity Proofing, Digital Identity Management and Digital Signatures for NIST E-Authentication SP 800-63 Level 3 Authentication.

3.1 Background
The purpose of this workgroup is to investigate and develop operational solutions to address Author of Record, Identity Proofing, Digital Identity Management, Encryption (encryption only as it pertains to protecting the confidentiality of payloads containing Personal Health Information (PHI)), Digital Signatures, and Delegation of Rights within a healthcare context. The solution must support the digital signature and identity proofing requirements that allow healthcare Providers to register for and receive Electronic Medical Documentation Requests (eMDRs) from CMS and other Health Plans/Payers. This solution must also provide support for CMS and other Health Plans/Payers to accurately authenticate the author of documentation within the medical record, and trust the validity and authenticity of submitted medical documentation.

3.2 In Scope

 * 1) Identity Proofing as part of Non-Repudiation of Actor Identity
 * 2) Digital Credential Management required for Non-Repudiation Actions (Signing and Delegation), Data Integrity and Encryption
 * 3) Digital Signatures and Signature Artifacts for Identity and Non-Repudiation
 * 4) Digital Credentials and Artifacts for Non-Repudiation of Delegation as required by esMD UC 1 and AoR L1
 * 5) Data Integrity requirement actions and artifacts
 * 6) Encryption of PHI requirements
 * 7) Payer Entity validates submission signature and encryption artifacts(Added 8/3)
 * 8) Payer Entity acknowledges validity* of submission to Provider Entity (Added 8/3)
 * 9) Interactions between Provider Entity or Payer Entity and :
 * 10) Certificate Authority
 * 11) Registration Authority
 * 12) External Provider Directory
 * 13) And each other

3.3 Out of Scope

 * 1) Interactions between:
 * 2) Payer and its Payer Contractors
 * 3) Provider and its Agent
 * 4) Payer or Payer Contractor and its Gateway
 * 5) Transaction level encryption
 * 6) Document level signatures and individual contribution signatures (AoR Levels 2,3)
 * 7) Defining delegation of rights within and between Providers and other authors (AoR Levels 2,3)
 * 8) Specific transport and envelope metadata used to send the Medical Documentation bundle and Signature Artifacts to the Payer Entity
 * 9) A definition of electronic transactions between RA and CA
 * 10) A definition of electronic transactions between Payer Entity and RA or CA
 * 11) A definition of electronic transactions between Provider Entity and RA or CA

3.4 Communities of Interest
The Communities of Interest section identifies relevant stakeholders that are potentially affected by the content of the Use Case. Note - All items pulled from the Use Case simplification tables are marked with an asterisk. //Some have been further modified to fit the working definition or newly added// to fit the initiative or Use Case needs. Click here to view the list of definitions: http://wiki.siframework.org/UC+Simplification+-+Stakeholder+Classification+SWG MAC- Medicare Administrative Contractors
 * || ** Members of Communities of Interest **  ||  ** Working Definition **  ||
 * 1 || ** 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. ||
 * 2 || ** Provider Organizations* ** || Organizations that are engaged in or support the delivery of healthcare to include Hospitals, Ambulatory Centers, Provider Practices, Integrated Delivery Networks, and Rehabilitation Centers. ||
 * 3 || ** Healthcare Administrators and Managers ** || Healthcare administrators with patient information and medical records management responsibilities including Health Information Management (HIM) personnel, Registered Health Information Administrator (RHIA), Registered Health Information Technicians (RHIT), Inpatient/Outpatient Clinical Coding Specialists, Medical Transcription Specialists, Medical Records Safety and Security staff, Quality Control personnel, Physician Practice Managers, Pharmacy Benefit Managers, and other management personnel or entities involved in managing patient information. ||
 * 4 || ** 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:

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 || Table 1: Communities of Interest
 * 5 || ** Payers* ** || Any private or public entity that finances heath care delivery or organizes health financing. This includes commercial for-profit health insurers, non-profit health insurers, ERISA self-insured, state and federal department agencies that oversee Medicaid and Medicare health services delivery. ||
 * 6 || ** EHR/EMR/PHR Vendors* ** || Vendors which provide specific EHR/PHR solutions to clinicians such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. ||
 * 7 || ** Other Healthcare Vendors* ** || Vendors that provide health care solutions other than EHR/EMR/PHR solutions such as software applications and services. Examples include: integration vendors, data providers, medical device vendors, RMMS (Remote Monitoring Management System) vendors, diagnostic imaging service provider, clinical order system supply vendor, transcription service vendors, clearinghouses, drug knowledge suppliers, network infrastructure provider, Clinical Decision Support (CDS) resource system, practice-based registry system suppliers, public health registry system, immunization information system providers, clinical genetic database/repository system vendor, practice management systems, and patient accounting systems, etc. ||
 * 8 || ** Patients* ** || Members of the public who receive 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.// ||
 * 9 || ** Certificate Authority* ** || An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs. ||
 * 10 || ** Registration Authority* ** || Any entity that is responsible for identification and authentication of subjects of certificates, but is not a CA, and hence does not sign or issue certificates. An RA may assist in the certificate application process or revocation process or both. ||
 * 11 || ** 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 systems ||
 * 12 || ** Licensing and Certification Organizations* ** || Organizations responsible for developing guidelines and ensuring that relevant parties adhere to those guidelines to ensure proper licensing and certification of systems and other health solutions related to healthcare. ||
 * 13 || ** Operating Rule Authoring Entities ** || As defined in Affordable Care Act Section 1104, such entities 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. ||
 * 14 || ** Beacon Communities* ** || Selected communities of groups who have received federal funding through the ONC to build and strengthen their health information technology (health IT) infrastructure and exchange capabilities to improve care coordination, increase the quality of care, and slow the growth of health care spending. ||
 * 15 || ** Federal Agencies* ** || Organizations within the federal government that deliver, regulate or provide funding for health and health care ||
 * 16 || ** Agent – (Healthcare Clearinghouses and Business Associate as defined by Health Insurance Portability and Accountability Act (HIPAA) including Health Information Handlers) ** || Any organization that handles health information on behalf of a provider as a covered entity or under a Business Associate Agreement (BAA) is an Agent. Many providers already use Agents to submit claims, provide electronic health record systems, etc. Organizations that are Agents include but are not limited to Healthcare Clearinghouses, Release of Information vendors, Health Information Exchanges, Electronic Health Record vendors, etc. ||
 * 17 || ** Health Information Exchange (HIE)/ Health Information Organization (HIO)* ** || __ HIE/HIO __ - Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system ||
 * 18 || ** Regional Extension Centers (REC)* ** || Entities that support and serve health care providers to help them quickly become adept and meaningful users of electronic health records (EHRs). RECs provide training and support services to assist doctors and other providers in adopting EHRs, offer information and guidance to help with EHR implementation, give technical assistance as needed. ||
 * 19 || ** Health Information Service Providers (HISP)* ** || Entities that serve as a node on the National Health & Information Network to enable a private, secure and safe alternative method to send and receive sensitive health information. ||

4.0 Value Statement
The value of the esMD Initiative will be to provide consensus-based use cases, functional requirements, standards references and implementation specifications representing combined input from a broad range of stakeholders, including CMS, commercial Health Plans/Payers, Providers, and vendors. This will promote a nationally standardized approach to medical document request letters, claims attachments, and the proof of validity and authorship of medical documentation. Health Plans/Payers and Providers will benefit from this Initiative’s recommendations and implementation guidance on Digital Signatures attached to patient information and electronic transactions. This will enable communications regarding the administrative claims processing between Providers and Health Plans/Payers to occur in a secure electronic format. Additional benefits include:

=5.0 Use Case Assumptions= =6.0 Pre-Conditions= =7.0 Post Conditions= // The Post Conditions section describes the state of the system, from a technical perspective, that will result after the execution of the operation, process activity or task. // =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.
 * 1) Standardized formats, processes, and technology approaches
 * 2) Increased security of information exchange involving PHI
 * 3) Improved ability to identify and verify authorship of medical documentation for administrative purposes, clinical decision making, and care coordination
 * 4) Providing industry best practices for other domains within healthcare where PHI is exchanged
 * 5) Making the process of sending and receiving PHI less burdensome on Health Plans/Payers and Providers
 * 6) Identifying security breaches or tampering of information sent or received that are not always evident in the paper process
 * 7) Saving time, money, and resources for CMS, Commercial Health Plans/Payers, and Providers
 * 8) Elimination of the paper process and its associated labor and error rate
 * 9) Improved timeliness results in improved accounts receivable cycle for Providers, so payments are received sooner
 * 10) Reduced improper payments
 * 11) Guidance and recommendations on EHR Certification criteria as it relates to document submission
 * 1) All Payer Entities and Provider Entities must obtain a Digital Identity from a Federal Bridge cross-certified Certificate Authority //in order to participate in esMD//
 * 2) Federal Bridge and NIST specifications for Level 3 identity assurance are available
 * 3) Registrations Authority models (RA) and registration authority processes exist for Level 3 identity proofing
 * 4) Certificate Authorities (CA) exist and are capable of providing the necessary digital credentials for signing, encryption and other services required by this Use Case
 * 5) Technology exists to utilize the digital credentials for signing and encryption of documents and transactions
 * 6) Provider registration process as defined in Use Case 1 and AoR L1 require support for proxy or delegation of rights
 * 7) The RA process, CA process, and digital credentials in combination with the signing and encryption process provide all of the necessary information and security context for non-repudiation of the signer and integrity of the Medical Documentation bundle
 * 8) Payer, Payer Contractors and Payer Gateway shall be treated as the Payer Entity
 * 9) A Provider, Group of Providers, Agent, and Hospital/Health Systems shall be treated as Provider Entity
 * 10) The signature on a bundle attests that the information submitted is an appropriate, complete (except as noted) and accurate response to the information requested
 * 11) All entities involved in AoR L1 transactions will maintain appropriate audit logs
 * 12) All actors shall create all transactions utilizing industry accepted standards, where available
 * 13) All actors shall ensure all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, and reliability
 * 14) All actors and systems shall ensure all transactions will be delivered in a timely manner
 * 15) All actors shall have signed any required participation or data use agreements
 * 16) X.509v3+ certificates can be stored in the Provider Directory data model (Provider Directory UC 2) and associated with the subject of the Certificate (e.g. the individual or entity to which the certificate is issued)
 * Payer Entity has the ability to register Provider Entitles for the esMD service, produce and electronically transmit the eMDR to the Provider Entity
 * Provider Entity has the ability to assemble and electronically transmit the required documentation to the Payer Entity in the required format to the required destination
 * Provider Entity has the required identity materials to qualify for (be identity proofed), receive, and maintain the electronic signing credentials
 * Provider Entity and Payer Entity shall have completed any required onboarding processes
 * Provider Entity systems shall maintain the ability to receive eMDRs after successful registration unless terminated through established mechanisms
 * Payer Entity information system process the Medical Documentation bundle

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. Table 2: Actors and Roles =9.0 Use Case Diagram=
 * ** Actor ** || ** System ** || ** Role ** ||
 * **Provider Entity **
 * An individual provider
 * A group of providers
 * A Hospital/Health System or
 * An Agent on their behalf ||  Provider Information System || * Requests Digital Identity
 * Receives Digital Certificate / Credentials
 * Send Registration request to Payer Organization to receive eMDRs
 * Receive eMDRs from Payer Entity
 * Assembles Medical Documentation
 * Send documents in response to eMDR
 * Digitally attest to document submission ||
 * **Payer Entity **
 * Payer
 * Payer Contractor
 * Payer Gateway ||  Payer Information System || * Requests Digital Identity
 * Receives Digital Certificate / Credentials
 * Receives registration request from Provider Entity
 * Processes the registration request from Provider Entity
 * Approves or Rejects Provider Entity Registration Request
 * Send eMDR to Provider Entity
 * Receives Medical Documentation bundle
 * Authenticates Signature Artifacts and data integrity and sends acknowledgement of Bundle validation ||
 * **Certificate Authority ** || CA Information System || * Receives requests for, Creates, Issues and manages security credentials and revocation lists
 * May provide RA services ||
 * **Registration Authority ** || RA Information System || * Validates and assist in completion of information required to obtain a certificate
 * Provides Identity proofing ||
 * **External Provider Directory ** || Provider Directory || * Stores and manage Provider Information / ESI
 * Responds to queries for Provider Information
 * Provides appropriate ESI to receive eMDRs ||

Figure 1: Use Case Diagram Figure 2: AoR Context Diagram =10.0 Scenario= A Provider Entity with a digital identity has successfully registered with a Payer Entity to receive electronic Medical Documentation Requests (eMDRs) in support of a claim. In response to the eMDR, the Provider Entity is able to send requested Medical Documentation as a digitally signed, aggregated document bundle. The Payer Entity is able to validate the submitter and integrity (not the accuracy of the content) of the Medical Documentation submission by the Provider Entity.

10.1 User Story
In order to participate in esMD, both Payer and Provider Entities obtain and maintain a non-repudiation digital identity. Both actors initiate the process to obtain a digital certificate from a Federal Bridge cross-certified Certificate Authority (validate with Commercial payers). Entities approved by a Registration authority will receive Credentials from a Certificate Authority to incorporate into their business process. Provider Entity with digital credentials submits a request to the Payer Entity to receive electronic Medical Documentation Request (eMDR). The Payer Entity checks the Provider Entity’s ability to receive such requests with an External Provider Directory. The Provider Entity receives a response either confirming or rejecting the request to receive eMDRs from the Payer Entity. For additional details refer to [|esMD UC 1]. When a Payer Entity identifies the need for additional documentation, they must first check to see if Provider Entity is registered to receive an electronic request (eMDR). If registered, the Payer Entity requests the current Electronic Service Information (ESI) of the Provider Entity from the External Provider Directory. Upon receiving the current ESI, the Payer Entity is able to send the encrypted and digitally signed eMDR to the Provider Entity. For additional details refer to [|esMD UC 2]. The Provider Entity, who has satisfied the esMD registration requirements, receives an eMDR from the Payer Entity, assembles the relevant Medical Documentation, applies a non-repudiation digital signature to each document bundle, and sends them to the Payer Entity. Upon receiving the digitally signed bundle of relevant Medical Documentation, the Payer Entity validates the following: Digital Certificate and chain to Federal Bridge, delegation of rights where required, and Signature Artifact. The Payer Entity then confirms that the signer is a registered Provider Entity or has signature rights delegated by the registered Provider Entity. Additionally, the Payer Entity decrypts the hash of the document bundle and validates data integrity of the Medical Documentation received. (Note - The Payer Entity does not validate the accuracy of the Medical Documentation received.) Payer Entity sends an acknowledgement of the success or failure of the validation performed by the Payer Entity to the Provider Entity.

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. Figure 3: 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). Note - Current actions involving the Provider Directories are covered in esMD UC 1 and 2. In the event access to the Public Key is required to be independent of interactions as a result of harmonization of standards, then the Provider Directories may be the location where the recipient of transaction retrieves the Public Key. Table 3: Base Flow
 * ** Step # ** ||  ** Actor **  ||  ** Role **  ||  ** Event/Description **  ||  ** Inputs **  ||  ** Outputs **  ||  ** Interoperability or System Step **  ||
 * 1A || Payer Entity || Requests Digital Identity || Pa yer Entity requests Digital Identity from Registration Authority || Payer Entity need for Digital Identity || Relevant Payer Entity identification information || Interoperability ||
 * 1B || Provider Entity || Requests Digital Identity || Provider Entity requests Digital Identity from Registration Authority || Provider Entity need for Digital Identity || Relevant Provider Entity identification information || Interoperability ||
 * 2 || Registration Authority || Validates and assists in completion of information required to obtain a certificate || Registration Authority approves (or rejects) the request for Identity Proofing and upon approval sends information to Certificate Authority || Relevant Payer/Provider Entity identification information || Response to Payer or Provider Entity request for a Digital Identity and request to Certificate Authority to issue Digital Certificate/ Credentials || Interoperability and System ||
 * 3A || Certificate Authority || Receives requests for, Creates, Issues and manages security credentials and revocation lists || Certificate Authority generates the Digital Certificate/Credentials and informs the Payer Entity of their availability || Registration Authority’s approval of Payer identification information || Digital Certificate/ Credentials made available by Certificate Authority || Interoperability and System ||
 * 3B || Certificate Authority || Receives requests for, Creates, Issues and manages security credentials and revocation lists || Certificate Authority generates the Digital Certificate/Credentials and informs the Provider Entity of their availability || Registration Authority’s approval of Provider identification information || Digital Credentials / Certificate made available by Certificate Authority || Interoperability and System ||
 * 4A || Payer Entity || Receives Digital Certificate / Credentials || Payer Entity obtains and incorporates Digital Certificate/ Credentials into its business process || Digital Credentials / Certificate made available by Certificate Authority || END || Interoperability and System ||
 * 4B || Provider Entity || Receives Digital Certificate / Credentials || Provider Entity obtains and incorporates Digital Certificate/ Credentials into its business process || Digital Credentials / Certificate issued by Certificate Authority || END || Interoperability and System ||
 * 5 || Provider Entity || Sends Registration request to Payer Entity || Provider Entity sends request to register with esMD to Payer Entity (esMD PPA Use Case 1) || Provider registration information || Provider registration transaction (transaction meaning exchange of structured information based on a national standard) || Interoperability ||
 * 6 || Payer Entity || Receives registration request, Approves or Rejects Provider Entity Registration Request || Payer Entity processes the request and sends a response either confirming or rejecting registration request to Provider Entity (esMD PPA Use Case 1) || Provider registration transaction || Response to provider registration request || Interoperability and System ||
 * 7 || Payer Entity || Sends eMDR to Provider Entity || Payer Entity sends eMDR(s) to registered Provider Entity (esMD Use Case 2) || Need for additional Medical Documentation and information required for eMDR transaction || eMDR transaction || Interoperability ||
 * 8 || Provider Entity || Assembles Medical Documentation and Digitally attests to document submission || Provider Entity assembles relevant Medical Documentation, applies a non-repudiation digital signature to each document bundle and sends to Payer Entity || eMDR and Medical Documentation required || Digitally Signed Medical Documentation bundle and Signature Artifact || Interoperability and System ||
 * 9 || Payer Entity || Receives Medical Documentaiton bundle and Authenticates Signature Artifacts and data integrity || Payer Entity receives Medical Documentation bundle, authenticates Signature Artifacts, and validates data integrity of submission from the Provider Entity || Digitally Signed Medical Documentation bundle and Signature Artifact || Success or failure of Signature Artifact and Data integrity authentication || System ||
 * 10 || Payer Entity || Sends Medical Documentation receipt acknowledge-ment to Provider Entity || Payer Entity sends an acknowledgement of the success or failure of the authentication and validation performed to the Provider Entity || Success or failure of Signature Artifact and Data integrity authentication || Acknowledgement of transaction || Interoperability ||
 * 11 || Provider Entity || Receives acknowledge-ment || Provider Entity receives acknowledgement of receipt of Medical Documentation from Payer Entity || Acknowledgement of transaction || END || System ||

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

10.3.1 Information Interchange Requirements
The Information Interchange Requirementsdefine the system’s name and role. They also specify the actions associated with the actual transport of content from the sending system to the receiving system. Table 4: Information Interchange Requirements
 * || ** Initiating System ** || ** Action ** || ** Information Interchange Requirement Name ** || ** Action ** || ** Receiving System ** ||
 * I || Payer Entity Information System || Send || Request for Digital Identity || Receive || Registration Authority Information System ||
 * II || Provider Entity Information System || Send || Request for Digital Identity || Receive || Registration Authority Information System ||
 * III || Registration Authority Information System || Send || Digital Identity request response and request to issue Digital Certificate/Credentials by Certificate Authority || Receive || Certificate Authority Information System ||
 * IV || Certificate Authority Information System || Send || Availability of Digital Certificate/Credentials || Receive || Payer Entity Information System ||
 * V || Certificate Authority Information System || Send || Availability of Digital Certificate/Credentials || Receive || Provider Entity Information System ||
 * VI || Provider Entity Information System || Send || Provider Registration information for esMD || Receive || Payer Entity Information System ||
 * VII || Payer Entity Information System || Send || Response to provider registration request for esMD || Receive || Provider Entity Information System ||
 * VIII || Payer Entity Information System || Send || eMDR(s) || Receive || Provider Entity Information System ||
 * IX || Provider Entity Information System || Send || Medical Documentation bundle and Signature Artifact || Receive || Payer Entity Information System ||
 * X || Payer Entity Information System || Send || Acknowledgement of Medical Documentation Signature Artifact validation and data integrity || Receive || Provider Entity Information System ||

10.3.2 System Requirements
// This sectionlists the requirements **__internal to the system__** necessary to participate successfully in the transaction. System requirements may also detail a required workflow that is essential to the Use Case. // b) Assemble information required for eMDR (esMD UC 2) c) Verify assignment of rights (if any), digital signature, traceability to registered provider, and validate integrity of Medical Documentation bundle || b) Have internal controls to ensure all necessary registration information is compiled/properly packaged prior to sending to Payer Entity Information System (esMD UC 1) c) Incorporate eMDR (esMD UC 2) d) Compile requested Medical Documentation e) Apply non-repudiation digital Signature to Medical Documentation bundle and create Signature Artifacts || b) Validate identification information for approval/rejection || b) Manage Digital Certificate/Credential life cycle || Table 5: System Requirements
 * ** System ** ||  ** System Requirement **  ||
 * Payer Entity Information System || a) Process information required for registration (esMD UC 1)
 * Provider Entity Information System || a) Compile information required for registration (esMD UC 1)
 * Registration Authority Information System || a) Process Provider and Payer Entity identification information
 * Certificate Authority Information System || a) Generate Digital Certificate/Credentials

10.4 Sequence Diagram
// A Sequence Diagram is primarily used to show the interactions between objects in the sequential order that they occur. This representation can make it easy to communicate how the exchange works by displaying how the different components interact. The primary use of the diagram is in the transition from requirements expressed as use cases to the next and more formal level of refinement. //

Figure 4: Sequence Diagram

11.0 Dataset Requirements
This table lists the data elements and data element sets that will be available within the certificate information, certificate signature, message signature, document bundle, and acknowledgement of receipt. 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. Table 6: Certificate Information
 * 1) ** Certificate Information (see expanded from table below from Provider Directory UC 1) **
 * 2) ** Provider Registration Request (esMD UC 1) **
 * 3) ** Sending of eMDR (esMD UC 2) **
 * 4) ** Digitally Signed Medical Documentation bundle **
 * 5) ** Acknowledgement to Provider Entity **
 * Certificate Information **
 * Additional X.509v3+ specific field or extension requirements will be expanded after completion of AoR L1 SWG effort and during harmonization. **
 * ** Section ** || ** Data Element ** || ** Multiple Values (yes/no) ** || ** Data Element Description ** || ** Additional Notes ** ||
 * Certificate Information || Version || No || Version of X.509 || All must be version 3 or later (X.509v3+) ||
 * ^  || Serial Number || No || Unique Serial Number of Certificate from the CA ||   ||
 * ^  || Algorithm ID || No || Algorithm used by the CA to sign the certificate ||   ||
 * ^  || Issuer || No || Name of CA that issued cerficicate ||   ||
 * ^  || Validity || No || Period of time for which the certificate is valid || Not Before, Not After ||
 * ^  || Subject || No || Subject Name -- Name of whom the certificate is issued to ||   ||
 * ^  || Subject Public Key Info || No || The subject’s public key || Public Key Algorithm, Subject Public Key ||
 * ^  || Issuer Unique Identifier || No ||   ||   ||
 * ^  || Subject Unique Identifier || No ||   ||   ||
 * ^  || Extensions || Yes || Describes specific purpose of use, values, and critical or non-critical identifer || Object Identifier for each extension; this is where the non-repudiation “flag” is located (which must be set) ||
 * Certificate Signature || Certificate Signature Algorithm || No || Algorithm used to sign the certificate ||  ||
 * ^  || Certificate Signature || No ||   ||   ||
 * Provider Registration Request and Sending of the eMDR Data Requirements (esMD UC 1 and esMD UC 2) **
 * ** Section ** || ** Data Element ** || ** Multiple Values (yes/no) ** || ** Data Element Description ** || ** Additional Notes ** ||
 * Message Signature || Public Digital certificate of transmitter ||  || X.509v3+ Token Profile || Signed by trust authority

For CMS, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || Signature Artifact ||   || Signature Artifact encrypted by transmitter's private key || Exact nature of artifact to be determined during harmonization

At a minimum the Signature Artifact will include the digest (hash) of the message || Table 7: Provider Registration Request and Sending of the eMDR Data Requirements (esMD UC 1 and esMD UC 2)
 * Digitally Signed Medical Documentation Bundle **
 * ** Section ** || ** Data Element ** || ** Multiple Values (yes/no) ** || ** Data Element Description ** || ** Additional Notes ** ||
 * ID || Unique Transaction ID || No || Provider Entity Assigned Unique Transaction ID sent with Medical Documentation bundle submission || IDs must be globally unique across all Provider Entities and able to accommodate expected Medical Documentation bundle submission volumes (–e.g., UUID). Unique ID may be a concatenation of more than one data element. ||
 * Digital Identiy and Signature of Signer || Public Digital Certificate of Signer ||  || X.509v3+ Token Profile || Signed by trust authority

For CMS, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || Signature Artifact ||   || Signature Artifact encrypted by transmitter's private key || Exact nature of artifact to be determined during harmonization

At a minimum the Signature Artifact will include the digest (hash) of the Medical Documentation bundle ||
 * Delegation of Rights || Public Digital certificate of registered provider if not signer ||  || X.509v3+ Token Profile || Signed by trust authority

For CMS, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || Signature Artifact ||   || Signature Artifact encrypted by registered providers private key || Exact nature of artifact to be determined during harmonization

At a minimum the Signature Artifact will include the CA and Serial Number of the Signer’s Digital Certificate || Table 8: Digitally Signed Medical Documentation Bundle 1) assignment of rights failures 2) digital certificate failure reasons 3) digital signature reasons 4) Medical Documentaiton bundle integrity reasons || Table 9: Acknowledgement to Provider Entity =12.0 Risks, Issues and Obstacles= // The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the requirements of the Use Case. // a) Compliance with Identity Proofing Requirements b) Compliance with Certifiate Lifecycle (including revocation) c) Compliance with Deligation of Rights (including revocation) d) Issues inheritant in the creation and use of X.509v3+ Digital Certificates ||
 * Acknowledgement to Provider Entity **
 * ** Section ** || ** Data Element ** || ** Multiple Values (yes/no) ** || ** Data Element Description ** || ** Additional Notes ** ||
 * Receipt of Medical Documentation Bundle || Unique Transaction ID || No || Payer Entity Unique Transaction ID received with Medical Documentation bundle submission ||  ||
 * ^  || Status || No || Status of Submission Validity Check || “Valid” or “Failed” ||
 * ^  || Validation Failure Reason || Yes || Reason or Reasons for failure – need to return only the first failure reason || Includes:
 * # The burden to individual providers to obtain and manage certificates. Some reasons include that providers will need to learn how to obtain the certificates, undergo ID-proofing, implement enrollment policies, manage renewals, etc.
 * 1) Acceptance of AoR Level 1 Use Case solution for Digital Signatures on Medical Documentation bundle as sufficient solution to Author of Record problem and not proceeding to AoR Levels 2 and 3
 * 2) Provider or Payer Entities unable or unwilling to participate in esMD as a result of not being able to successfully obtain and maintain Digital Identities and the required Certificates/Credentials
 * 3) Provider Entities or Payer Entites that have Digital Certificates that are not issued by CAs cross-certified with the Federal Bridge that will need to obtain or have new Certificates issued to itself and its trading partners to be compliant with the identify proofing and certificate requirements
 * 4) Unintended disclosure of Personal Health Information
 * 5) Technical and/or operational barriers to scaling participating platforms or services to meet volume of eMDRs and Medical Documentation responses
 * 6) Delays related to inconsistencies in information provided to obtain Digital Certificates/Credentials and information submitted while registering for esMD
 * 7) Risks associated with the digital identity process

=Appendices=

Appendix A: Related Use Cases

 * [|esMD Use Case 1 – Provider Registration with a Payer to receive electronic Medical Documentation Requests (eMDR)]
 * [|esMD Use Case 2- Secure Transportation and Structured content of eMDR]
 * [[file:siframework/ONC_Certificate Interoperability_Full Report_FINAL.pdf|Certificate Interoperability Final Report]]
 * Query for Digital Certificate Use Case for Direct Project
 * Provider Directories - Query for Electronic Service Information including Electronic Address Use Case

Appendix B: Glossary

 * 1) ** Authentication (NIST) ** - Security measure designed to establish the validity of a transmission, message, or originator, or a means of verifying an individual's authorization to receive specific categories of information. [NS4009]
 * 2) ** Author (of Record) ** - The individual that creates a record.
 * 3) ** Certificate Authority (NIST) ** - An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs.
 * 4) ** Data Integrity (NIST) ** - A property whereby data has not been altered in an unauthorized manner since it was created, transmitted or stored. Alteration includes the insertion, deletion and substitution of data.
 * 5) ** Decryption ** - The reverse process of encryption, i.e., to make the encrypted information readable again.
 * 6) ** Delegation of Rights ** - The ability to delegate rights or authority to another to act in a specific capacity on behalf of the grantor of the right.
 * 7) ** Digital Certificate (NIST) ** - A digital representation of information which at least (1) identifies the certification authority issuing it, (2) names or identifies its subscriber, (3) contains the subscriber's public key, (4) identifies its operational period, and (5) is digitally signed by the certification authority issuing it.
 * 8) ** Digital Identity Management ** - A trusted authority is responsible for creating the key pair, distributing the private key, publishing the public key and revoking the keys as necessary. The “Passport Office” of the Digital World. The keys and their associated information (e.g. Digital Certificate) are typically stored as software tokens, browser certificate stores, and hardware tokens (Smart Cards, USB Tokens).
 * 9) ** Digital Signatures ** - An artifact appended to a record as a result of a user’s intended action wherein that entity memorializes a signing event by a process that digitally signs a document or transaction using the private key component of his certificate.(From NIST - The result of a transformation of a message by means of a cryptographic system using keys such that a Relying Party can determine: (1) whether the transformation was created using the private key that corresponds to the public key in the signer’s digital certificate; and (2) whether the message has been altered since the transformation was made.)
 * 10) ** Encryption ** - In cryptography, encryption is the process of transforming information (referred to as plaintext) using an algorithm (called a cipher) to make it unreadable to anyone except those possessing special knowledge, usually referred to as a key.
 * 11) ** Identity ** - A unique name of an individual person or legal entity. Since the legal names of persons and entities are not necessarily unique, the identity of a person or entity must include sufficient additional information (for example an address and NPI number) to make the complete name unique.
 * 12) ** Identity Proofing ** - The process by which the credential issuer validates sufficient information to uniquely identify a person or entity applying for the credential. It proves that the identity exists, proves the applicant is entitled to that identity, and address the potential for fraudulent issuance of credentials based on collusion.
 * 13) ** Medical Documentation ** - Clinical documentation or non-clinical documentation necessary to support the process for a claim or preauthorization for the delivery of health care services. Examples include, but are not limited to, medical records created during the delivery of services that are subject of the claim, records related to costs associated with the delivery of services (e.g. receipts for devices or transportation), and records that establish the need for covered services.
 * 14) ** Non-repudiation (NIST) ** - A service that is used to provide assurance of the integrity and origin of data in such a way that the integrity and origin can be verified by a third party. This service prevents an entity from successfully denying involvement in a previous action.
 * 15) ** Public Key Infrastructure ** - A set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.
 * 16) ** Record ** - A completed body of data that is intended to represent an accurate and persistent report of actions, events, or evidence.
 * From ISO: A record is a document, and can be used as an input from one process to another, but in contrast to documents that are purely informative, a record is generated to state results achieved or to provide evidence of activities performed.
 * 1) ** Registration Authority (NIST) ** -An entity that is responsible for identification and authentication of certificate subjects, but that does not sign or issue certificates (i.e., a Registration Authority is delegated certain tasks on behalf of an authorized CA).
 * 2) ** X.509v3+ ** - Includes X.509 version 3 and all subsequent versions [RFC 5280 and its predecessors]

Appendix C: References

 * [|CMS Internet Only Manuals (IOM)]
 * [|CMS National Coverage Determination (NCD) / CMS Local Coverage Determination (LCD)]
 * [|Health Insurance Portability and Accountability Act of 1996 (HIPAA) Privacy and Security Rules]

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