esMD+AoR+L2+Use+Case+4+-+Digital+Signatures+on+an+Individual+Document

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 the esMD AoR L2 Use Case 4 - Digital Signatures on an Individual Document is now closed. Click here to see the votes. Click below to download the Use Case in a MS Word document:

To review the the AoR L2 workspace files, visit the AoR L2 wiki page. include component="page" wikiName="siframework" page="esMD AoR Workgroup Artifacts"

=1.0 Preface and Introduction = toc 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, caregivers, providers, payers, vendors, standards organizations, public health organizations, and Federal agencies.

 These Use Cases describe:

The Use Case is the foundation for identifying and specifying the standards required to support the data exchange and developing reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards.
 * The operational context for the data exchange
 * The stakeholders with an interest in the Use Case
 * The information flows that must be supported by the data exchange
 * The types of data and their specifications required in the data exchange

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

Healthcare payers frequently request that providers submit additional medical documentation in order to adjudicate and support the processing of a specific claim or set of claims and perform other administrative functions, including identification of improper payments. Currently, Medicare Review Contractors send over 1 million requests for medical documents per year manually using a paper request letter and mailing it through the US Postal Service to healthcare providers. Until recently, healthcare providers had only two options for submitting the requested records to Medicare Review Contractors: 1) mail paper or 2) send a fax. The manual paper process is costly, time consuming and can delay proper claims processing on both the senders’ and receivers’ end.As of September 15, 2011, a pilot group of Health Information Handlers (HIHs) and Medicare Review Contractors began accepting electronic submissions from providers, as part of the first phase of esMD. These electronic submissions consist of an unstructured .PDF format of a scanned image, within an Integrating the Healthcare Enterprise Cross-Enterprise Document Reliable Interchange (IHE XDR) wrapper. This initiative will provide added value to CMS, Commercial Payers, and Providers by defining the interoperability requirements for additional automation of the electronic request and submissions process.CMS continues to investigate additional capabilities of electronic submission of medical documentation. 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 included 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. =<span style="font-family: Arial,Helvetica,sans-serif;">3.0 Use Case Scope = <span style="font-family: Arial,Helvetica,sans-serif;">This workgroup will investigate and recommend solutions on various levels of Author of Record needs: <span style="font-family: Arial,Helvetica,sans-serif;">*This Use Case document only focuses on AoR Level 2 Use Case. AoR Level 1 is complete and available to the community for reference and Level 3 Use Case will be developed at a later time. <span style="font-family: Arial,Helvetica,sans-serif;">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 Personal Health Information (PHI)). The workgroup will focus on Identity Proofing, Digital Identity Management and Digital Signatures for Federal Bridge Certification Authority (FBCA) Medium Assurance.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Develop a registration process to allow Providers to sign up to receive electronic medical documentation requests from CMS Review Contractors
 * <span style="font-family: Arial,Helvetica,sans-serif;">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
 * <span style="font-family: Arial,Helvetica,sans-serif;">Identify a secure method of sending medical documentation requests from CMS review contractors to providers
 * <span style="font-family: Arial,Helvetica,sans-serif;">Identify a solution that will enable an electronic replacement of wet signatures, for medical documents submitted from providers to CMS
 * <span style="font-family: Arial,Helvetica,sans-serif;">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.
 * <span style="font-family: Arial,Helvetica,sans-serif;">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.
 * <span style="font-family: Arial,Helvetica,sans-serif;">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.
 * <span style="font-family: Arial,Helvetica,sans-serif;">AoR Level 1 – Digital signature on aggregated Medical Documentation bundle*
 * <span style="font-family: Arial,Helvetica,sans-serif;">AoR Level 2 – Digital signature on an individual document
 * <span style="font-family: Arial,Helvetica,sans-serif;">AoR Level 3 – Digital signature to allow traceability of individual contributions to a document

<span style="font-family: Arial,Helvetica,sans-serif;">3.1 Background
<span style="font-family: Arial,Helvetica,sans-serif;">The purpose of this workgroup is to investigate and develop operational solutions to address Author of Record Level 2 requirements for Digital Signatures on individual documents. To the extent solutions recommended during AoR Level 1 for Identity Proofing, Digital Identity Management, Digital Signatures, and Delegation of Rights are insufficient to support AoR Level 2, these topics will be revisited. However, there is no intent to review or revise AoR Level 1 recommendation regarding these topics without a clear need within the scope of AoR Level 2 use cases. This solution must allow CMS and other Health Plans/Payers to accurately authenticate the author of individual documents within the medical record, and trust the validity and authenticity of submitted medical documentation.

<span style="font-family: Arial,Helvetica,sans-serif;">3.2 In Scope
<span style="font-family: Arial,Helvetica,sans-serif;">A. Solutions for individual or organizational digital signatures for discrete Documents to attest to the validity and authenticity of the patient information (or other relevant medical documentation) within the Document or actions performed on the Document (e.g. review) - and will be agnostic regarding format of and the content in the Document. <span style="font-family: Arial,Helvetica,sans-serif;">B. Documents include, but are not limited to: PDFs, Word documents, text “blobs” with or without formatting, summary document (e.g. Consolidated Clinical Document Architecture (C-CDA)), Diagnostic Imaging files, and other instantiations of discrete or aggregate information that are persistent (persistence shall be defined in context of this use case). <span style="font-family: Arial,Helvetica,sans-serif;">C. Actions include,but are not limited to: document creation, document completion, document modification, document review and document exchange (including device signature). <span style="font-family: Arial,Helvetica,sans-serif;">D. The following products of AoR Level 1 may be reviewed and expanded as necessary to meet the requirements of AoR Level 2. <span style="font-family: Arial,Helvetica,sans-serif;"> a. Identity Proofing <span style="font-family: Arial,Helvetica,sans-serif;"> b. Digital Identity Management <span style="font-family: Arial,Helvetica,sans-serif;"> c. Encryption (encryption only as it pertains to protecting the confidentiality of payloads containing PHI) <span style="font-family: Arial,Helvetica,sans-serif;"> d. Digital Signature and Delegation of Rights artifacts <span style="font-family: Arial,Helvetica,sans-serif;">E. Persistence of Digital Signature and Delegation of Rights artifacts <span style="font-family: Arial,Helvetica,sans-serif;">F. Exchange of Documents and the associated Digital Signature and Delegation of Rights Artifacts between the Provider Entity (which could include one or more of the following: Provider, Health System, Agent/HIH) and Payer Entity (which could be Payer, Payer Contractor, or someone else on their behalf) <span style="font-family: Arial,Helvetica,sans-serif;">G. Defining delegation of rights between Providers and other authors <span style="font-family: Arial,Helvetica,sans-serif;">H. Specific envelope metadata used to store or transmit the Documentation, Digital Signature Artifacts and associated Delegation of Rights <span style="font-family: Arial,Helvetica,sans-serif;">I. Exchange of Documents between Provider Entities and the persistence of the associated Digital Signatures and Delegation of Rights Artifacts by the recipient where required by this use case. <span style="font-family: Arial,Helvetica,sans-serif;">J. Validation of signature and delegation of rights artifacts by recipient <span style="font-family: Arial,Helvetica,sans-serif;">K. Interactions between Provider Entity or Payer Entity and : <span style="font-family: Arial,Helvetica,sans-serif;"> a. Certificate Authority <span style="font-family: Arial,Helvetica,sans-serif;"> b. Registration Authority <span style="font-family: Arial,Helvetica,sans-serif;"> c. And each other

3.3 Out of Scope
<span style="font-family: Arial,Helvetica,sans-serif;">A. Digital Signatures and Delegation of Rights Artifacts as required by AoR Level 1 for Document Bundles and Use Case 1 (PPA) or Use Case 2 (secure eMDR) transactions <span style="font-family: Arial,Helvetica,sans-serif;">B. Identity Proofing, Digital Credential Management, Digital Signatures and Delegation of Rights as defined by and required for AoR Level 1 <span style="font-family: Arial,Helvetica,sans-serif;">C. Digital signature to allow traceability of individual contributions to a document and other items to be defined as part of AoR Level 3 <span style="font-family: Arial,Helvetica,sans-serif;">D. Interactions between: <span style="font-family: Arial,Helvetica,sans-serif;"> a. Payer and its Payer Contractors <span style="font-family: Arial,Helvetica,sans-serif;"> b. Provider and its Agent <span style="font-family: Arial,Helvetica,sans-serif;"> c. Payer or Payer Contractor and its Gateway <span style="font-family: Arial,Helvetica,sans-serif;">E. Transactio level encryption <span style="font-family: Arial,Helvetica,sans-serif;">F. A definition of electronic transactions between RA and CA <span style="font-family: Arial,Helvetica,sans-serif;">G. A definition of electronic transactions between Payer Entity and RA or CA <span style="font-family: Arial,Helvetica,sans-serif;">H. A definition of electronic transactions between Provider Entity and RA or CA <span style="font-family: Arial,Helvetica,sans-serif;">I. Consent,privacy, and use of the document in situations other than providing documentation to payers for the sake of program or benefits administration <span style="font-family: Arial,Helvetica,sans-serif;">J. Signature by patient or their authorized representative

3.4 Communities of Interest
<span style="font-family: Arial,Helvetica,sans-serif;">The Communities of Interest section identifies relevant stakeholders that are potentially affected by the content of the Use Case. <span style="font-family: Arial,Helvetica,sans-serif;">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: <span style="color: #ffffff; font-family: Arial,Helvetica,sans-serif;">http://wiki.siframework.org/UC+Simplification+-+Stakeholder+Classification+SWG

<span style="font-family: Arial,Helvetica,sans-serif;">MAC – Medicare Administrative Contractors MRA – Medicare Recovery Auditor (formerly Recovery Audit Contractors, RAC) PERM – Payment Error Rate Measurement Program CERT – Comprehensive Error Rate Testing Program ZPIC – Zone Program Integrity Contractors <span style="font-family: Arial,Helvetica,sans-serif;">SMRC – Supplemental Medicare Review Contractor ||
 * || **<span style="font-family: Arial,Helvetica,sans-serif;">Members of Communities of Interest ** || **<span style="font-family: Arial,Helvetica,sans-serif;">Working Definition ** ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">1 || <span style="font-family: Arial,Helvetica,sans-serif;">Individual Providers || <span style="font-family: Arial,Helvetica,sans-serif;">Healthcare providers with patient care responsibilities including, but not limited to, physicians, advanced practice nurses, physician assistants, nurses, psychologists, emergency care providers, home health providers, definitive care providers, pharmacists, caregivers and other personnel involved in patient care. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">2 || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Organizations* || <span style="font-family: Arial,Helvetica,sans-serif;">Organizations that are engaged in or support the delivery of healthcare to include Hospitals, Ambulatory Centers, Provider Practices, Integrated Delivery Networks, and Rehabilitation Centers. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">3 || <span style="font-family: Arial,Helvetica,sans-serif;">Healthcare Administrators and Managers || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">4 || <span style="font-family: Arial,Helvetica,sans-serif;">Payer Contractors || <span style="font-family: Arial,Helvetica,sans-serif;">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:
 * <span style="font-family: Arial,Helvetica,sans-serif;">5 || <span style="font-family: Arial,Helvetica,sans-serif;">Payers* || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">6 || <span style="font-family: Arial,Helvetica,sans-serif;">EHR/EMR/PHR Vendors* || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">7 || <span style="font-family: Arial,Helvetica,sans-serif;">Other Healthcare Vendors* || <span style="font-family: Arial,Helvetica,sans-serif;">Vendors that provide health care solutions other than EHR/EMR/PHR solutions such as plans of care coordination, software applications, and covered services. Examples include, but are not limited to: integration vendors, data providers, medical device vendors, Durable Medical Equipment (DME) suppliers, 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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">8 || <span style="font-family: Arial,Helvetica,sans-serif;">Patients* || <span style="font-family: Arial,Helvetica,sans-serif;">Members of the public who receive healthcare services from, but not limited to, ambulatory medical and/or surgical departments, emergency department, physician’s and/or Non-Physician Provider’s (NPP) office, Inpatient hospitals including Critical Care Hospitals and the VAH, Medical Home Care Models, Home Health and Hospice (HHH) entities that provide care within the patient’s home environment. and/or a public health agency/department, including services provided within the criminal justice system. While patient information is being digitally signed, the patient is not a direct participant in this use case. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">9 || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority* || <span style="font-family: Arial,Helvetica,sans-serif;">An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Root CAs and Subordinate CAs. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">10 || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority* || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">11 || <span style="font-family: Arial,Helvetica,sans-serif;">Standards Organizations* || <span style="font-family: Arial,Helvetica,sans-serif;">Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and systems ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">12 || <span style="font-family: Arial,Helvetica,sans-serif;">Licensing and Certification Organizations* || <span style="font-family: Arial,Helvetica,sans-serif;">Federal, Nationally approved and State Licensure Boards and local organizations, including accredited teaching academies, responsible for developing guidelines for Implementation, providing Licensure and defined scope of practice (healthcare services), to ensure that relevant parties qualify and adhere to those guidelines, ensuring proper licensing and certification under systems and other healthcare solutions related to delivery of safe healthcare services. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">13 || <span style="font-family: Arial,Helvetica,sans-serif;">Operating Rule Authoring Entities || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">14 || <span style="font-family: Arial,Helvetica,sans-serif;">Beacon Communities* || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">15 || <span style="font-family: Arial,Helvetica,sans-serif;">Federal Agencies* || <span style="font-family: Arial,Helvetica,sans-serif;">Organizations within the federal government that deliver, regulate or provide funding for health and health care ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">16 || <span style="font-family: Arial,Helvetica,sans-serif;">Agent – (Healthcare Clearinghouses and Business Associate as defined by Health Insurance Portability and Accountability Act (HIPAA) including Health Information Handlers) || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">17 || <span style="font-family: Arial,Helvetica,sans-serif;">Health Information Exchange (HIE)/ Health Information Organization (HIO)* || <span style="font-family: Arial,Helvetica,sans-serif;">HIE/HIO - Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">18 || <span style="font-family: Arial,Helvetica,sans-serif;">Regional Extension Centers (REC)* || <span style="font-family: Arial,Helvetica,sans-serif;">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. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">19 || <span style="font-family: Arial,Helvetica,sans-serif;">Health Information Service Providers (HISP)* || <span style="font-family: Arial,Helvetica,sans-serif;">Entities that serve as a node on the eHealth Exchange to enable a private, secure and safe alternative method to send and receive sensitive health information. ||

=4.0 Value Statement= <span style="font-family: Arial,Helvetica,sans-serif;">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. <span style="font-family: Arial,Helvetica,sans-serif;">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= <span style="font-family: Arial,Helvetica,sans-serif;">A. All Payer Entities and Provider Entities must obtain a Digital Identity from a Federal Bridge cross-certified Certificate Authority in order to participate in Author of Record <span style="font-family: Arial,Helvetica,sans-serif;">B. Federal Bridge medium assurance credentials are available <span style="font-family: Arial,Helvetica,sans-serif;">C. Registration Authority models (RA) and registration authority processes exist for Federal Bridge medium assurance identity proofing <span style="font-family: Arial,Helvetica,sans-serif;">D. Certificate Authorities (CA) exist and are capable of providing the necessary X.509v3 digital credentials for document signing <span style="font-family: Arial,Helvetica,sans-serif;">E. Technology exists to utilize the digital credentials for signing of documents <span style="font-family: Arial,Helvetica,sans-serif;">F. Document signature process requires support for delegation of rights <span style="font-family: Arial,Helvetica,sans-serif;">G. The RA process, CA process, and digital credentials in combination with the signing process provide all of the necessary information and security context for non-repudiation of the signer and integrity of the Document, including any delegation of rights <span style="font-family: Arial,Helvetica,sans-serif;">H. Payer, Payer Contractors and Payer Gateway shall be treated as the Payer Entity <span style="font-family: Arial,Helvetica,sans-serif;">I. A Provider, Group of Providers, Agent, and Hospital/Health Systems shall be treated as Provider Entity <span style="font-family: Arial,Helvetica,sans-serif;">J. The signature on a document attests that the associated action(s) have been performed on the document at the indicated time <span style="font-family: Arial,Helvetica,sans-serif;">K. All entities involved in AoR L2 transactions will maintain appropriate audit logs <span style="font-family: Arial,Helvetica,sans-serif;">L. All actors shall create all transactions utilizing current industry accepted standards <span style="font-family: Arial,Helvetica,sans-serif;">M. All actors shall ensure all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, and reliability <span style="font-family: Arial,Helvetica,sans-serif;">N. All actors and systems shall ensure all transactions will be delivered in a timely manner <span style="font-family: Arial,Helvetica,sans-serif;">O. All actors shall have signed any required participation or data use agreements <span style="font-family: Arial,Helvetica,sans-serif;">P. X.509v3+ public certificates can be stored in the Provider Directory data model (Provider Directory UC 2) and are associated with the subject of the Certificate (e.g. the individual or entity to which the certificate is issued) <span style="font-family: Arial,Helvetica,sans-serif;">Q. In general, documents should be signed to attest to authorship when they are completed <span style="font-family: Arial,Helvetica,sans-serif;">R. Documents supporting services delivered should be digitally signed with the date/time and action (creation, review ...) at or prior to the time of billing. These signed documents and the digital signature artifacts should be maintained for the time required by the payer’s retention policy.The specific policies for payers should be followed for services covered by each payer.Subsequent changes to these documents that will be used for payment determination should be digitally signed with the action code indicating an update, addendum, or modification. The signed modified documents and any predecessor documents should be maintained and submitted as documentation for payment determination. <span style="font-family: Arial,Helvetica,sans-serif;">S. Document revision or addenda should be signed at the time the revisions are competed, indicating the appropriate action(s) [requirement to maintain antecedent signed documents should be based on medical legal documentation requirements (e.g. CMS Medicare Program Integrity Manual Chapter 3) and industry best practice] <span style="font-family: Arial,Helvetica,sans-serif;">T. EHRs will support the Document signature process and delegation of rights process defined in this use case. This support may be part of the EHR itself or an integrated module or service. <span style="font-family: Arial,Helvetica,sans-serif;">U. Signed Documents must be available to meet Payer Documentation requirements. <span style="font-family: Arial,Helvetica,sans-serif;">V. Document requirements may be defined by the specific transaction type (for example as definedby payer’s policy) and include metadata that is unique for a specific use case. Individual Document may include any of the following: <span style="font-family: Arial,Helvetica,sans-serif;">W. Relevant Documents must be signed prior to billing CMS and the Documents, signature artifacts, public X.509V3 certificates, validated Delegation of Rights Assertion (if required) must be maintained by the provider based on CMS record retention policies. (for other payers, see responsible payer policies) <span style="font-family: Arial,Helvetica,sans-serif;">X. Documents can be signed as actions are performed and the signatures / Documents added to an ongoing archive to meet payer documentation requirements. =6.0 Pre-Conditions= =7.0 Post Conditions= =8.0 Actors and Roles= <span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">This table outlines the business actors that are participants in the information exchange requirements. A business actor is a person or organization that directly participates in a scenario. Thus, as a person or organization, the actor can (and should) be a stakeholder.The business actor must use a system to perform the functions and to participate in the information interchange. NOTE: A Business Actor may be a Stakeholder and also can have more than one role. <span style="font-family: Arial,Helvetica,sans-serif;">Used by other Actors to obtain ESI || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Directory || * <span style="font-family: Arial,Helvetica,sans-serif;">Stores and manage Provider Information / Electronic Service Information (ESI) = = || =** 9.0 Use Case Diagram **=
 * 1) <span style="font-family: Arial,Helvetica,sans-serif;">Standardized formats, processes, and technology approaches
 * 2) <span style="font-family: Arial,Helvetica,sans-serif;">Increased security of information exchange involving PHI
 * 3) <span style="font-family: Arial,Helvetica,sans-serif;">Improved ability to identify and verify authorship of medical documentation for administrative purposes, clinical decision making, and care coordination
 * 4) <span style="font-family: Arial,Helvetica,sans-serif;">Providing industry best practices for other domains within healthcare where PHI is exchanged
 * 5) <span style="font-family: Arial,Helvetica,sans-serif;">Making the process of sending and receiving PHI less burdensome on Health Plans/Payers and Providers
 * 6) <span style="font-family: Arial,Helvetica,sans-serif;">Identifying security breaches or tampering of information sent or received that are not always evident in the paper process
 * 7) <span style="font-family: Arial,Helvetica,sans-serif;">Saving time, money, and resources for CMS, Commercial Health Plans/Payers, and Providers
 * 8) <span style="font-family: Arial,Helvetica,sans-serif;">Elimination of the paper process and its associated labor and error rate
 * 9) <span style="font-family: Arial,Helvetica,sans-serif;">Improved timeliness results in improved accounts receivable cycle for Providers, so payments are received sooner
 * 10) <span style="font-family: Arial,Helvetica,sans-serif;">Reduced improper payments
 * 11) <span style="font-family: Arial,Helvetica,sans-serif;">Guidance and recommendations on EHR Certification criteria as it relates to proof of document authorship and document submission
 * <span style="font-family: Arial,Helvetica,sans-serif;">PDF
 * <span style="font-family: Arial,Helvetica,sans-serif;">Text blobs
 * <span style="font-family: Arial,Helvetica,sans-serif;">Permanent representation of a transaction (order/ receive results lab test/imaging/pharmaceutical)
 * <span style="font-family: Arial,Helvetica,sans-serif;">Summary document such as a C-CDA (external signature, not as part of the CDA 2.0)
 * <span style="font-family: Arial,Helvetica,sans-serif;">Any valid Mime type
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity, Payer Entity, and recipient of Delegation of Rights has:
 * <span style="font-family: Arial,Helvetica,sans-serif;">Been identity proofed at Federal Bridge Medium Assurance
 * <span style="font-family: Arial,Helvetica,sans-serif;">Received and is maintaining X.509v3+ signing certificate
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity has the ability to perform the functions on a document that the Digital Signature will attest to, for example: creation, modification, review
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity has the ability to store and exchange the document and digital signature artifacts
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity systems shall have and maintain the ability to sign documents using X.509v3 signing certificates, and creates the digital signature artifacts defined by this use case.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity systems shall have and maintain the ability to send the public certificate, signed document and the signature artifacts in transactions defined by relevant esMD Use Cases.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity systems shall have the ability to create delegation of rights artifacts
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity systems shall have the ability to sign delegation of rights artifacts at the time they are used for document signing by the delegated agent.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Recipient of documents with associated digital signature artifacts shall be able to validate the public certificate, signature and integrity of the document to ensure non-repudiation of authorship and/or the declared action
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity systems shall maintain the documents, signature artifacts and,here appropriate, the delegation of rights artifacts for the period required by appropriate law regarding medical documentation
 * <span style="font-family: Arial,Helvetica,sans-serif;">Any entity receiving a digitally signed document must maintain the associated public certificates, signature artifacts and, where appropriate, the delegation of rights artifacts if they wish to prove non-repudiation in the future or retransmit the document to a third party as a digitally signed document
 * <span style="font-family: Arial,Helvetica,sans-serif;">**Actor** || **<span style="font-family: Arial,Helvetica,sans-serif;"> System ** || **<span style="font-family: Arial,Helvetica,sans-serif;">Role ** ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity
 * <span style="font-family: Arial,Helvetica,sans-serif;">An individual provider
 * <span style="font-family: Arial,Helvetica,sans-serif;">Caregiver
 * <span style="font-family: Arial,Helvetica,sans-serif;">A group of providers or caregivers
 * <span style="font-family: Arial,Helvetica,sans-serif;">A Hospital/Health System
 * || <span style="font-family: Arial,Helvetica,sans-serif;"> Provider Information System || * <span style="font-family: Arial,Helvetica,sans-serif;">Requests Digital Identity
 * <span style="font-family: Arial,Helvetica,sans-serif;">Receives Digital Certificate / Credentials
 * <span style="font-family: Arial,Helvetica,sans-serif;">Digitally signs documents attesting to specific actions
 * <span style="font-family: Arial,Helvetica,sans-serif;">Creates and Signs Delegation of Rights assertion
 * <span style="font-family: Arial,Helvetica,sans-serif;">Cancels Delegation of Rights assertion ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee
 * <span style="font-family: Arial,Helvetica,sans-serif;">An individual provider
 * <span style="font-family: Arial,Helvetica,sans-serif;">A group of providers
 * <span style="font-family: Arial,Helvetica,sans-serif;">A Hospital/Health System or
 * <span style="font-family: Arial,Helvetica,sans-serif;">An Agent on their behalf || <span style="font-family: Arial,Helvetica,sans-serif;"> Provider or Agent Information System || * <span style="font-family: Arial,Helvetica,sans-serif;">Requests Digital Identity
 * <span style="font-family: Arial,Helvetica,sans-serif;">Receives Digital Certificate / Credentials
 * <span style="font-family: Arial,Helvetica,sans-serif;">Receives Delegation of Rights assertion
 * <span style="font-family: Arial,Helvetica,sans-serif;">Digitally signs documents attesting to specific actions ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity
 * <span style="font-family: Arial,Helvetica,sans-serif;">Payer
 * <span style="font-family: Arial,Helvetica,sans-serif;">Payer Contractor
 * <span style="font-family: Arial,Helvetica,sans-serif;">Payer Gateway || <span style="font-family: Arial,Helvetica,sans-serif;"> Payer Information System || * <span style="font-family: Arial,Helvetica,sans-serif;">Receives digitally signed documents
 * <span style="font-family: Arial,Helvetica,sans-serif;">Authenticates signature and delegation of rights artifacts and data integrity ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">CA Information System || * <span style="font-family: Arial,Helvetica,sans-serif;">Receives requests for, creates, issues and manages security credentials and revocation lists
 * <span style="font-family: Arial,Helvetica,sans-serif;">May provide RA services ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority || <span style="font-family: Arial,Helvetica,sans-serif;">RA Information System || * <span style="font-family: Arial,Helvetica,sans-serif;">Validates and assist in completion of information required to obtain a certificate
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provides Identity proofing ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">External Provider Directory
 * <span style="font-family: Arial,Helvetica,sans-serif;">Responds to queries for Provider Information

Figure 2 : AoR Context Diagram
=** 10.0 Scenario **= <span style="font-family: Arial,Helvetica,sans-serif;">A Provider Entity or its delegated agent must attest to actions taken (e.g. creation, modification, review) with respect to a specific individual Document at the time the action is taken/completed. This attestation must be non-repudiable and verifiable by a third party from the artifacts created at the time of signing. The Provider Entity or its delegated agent has a need to send the Document to a third party accompanied by the attestation and, where necessary, the proof of delegation.

** 10.1 User Story **
<span style="font-family: Arial,Helvetica,sans-serif;">In order to participate in AoR Level 2 signing, the Provider Entity and any delegated agent must obtain and maintain a non-repudiation digital identity. Both actors initiate the process to obtain a Medium Assurance X.509v3 digital signing certificate from a Federal Bridge cross-certified Certificate Authority. Entities approved by a Registration authority will receive Credentials from a Certificate Authority to incorporate into their business process.

If required, Provider Entity creates and digitally signs a Delegation of Rights assertion (see AoR L1) to permit a delegated agent to sign Documents on their behalf. It is the responsibility of the Provider Entity to ensure that the Delegation of Rights is validated with each signature by using methods defined in the esMD AoR Level 1 Implementation Guide.

When a Provider Entity or their delegated agent completes an attestable action with respect to a Document, the Provider Entity or delegated agent will create a digital signature artifact (see AoR L1) attesting to the date/time and action taken by encrypting a digest of the Document, the date/time, and action code with the private key of signing digital certificate.

The Provider Entity who has satisfied any payer registration (e.g. UC 1) that may be required for a specific exchange of documentation with a payer, sends (directly or through a delegated agent) the Document, the digital signature artifacts and any delegation of rights artifacts in a secure transaction to the payer using the methods described in other esMD use cases.

Upon receiving the digitally signed Document and signature artifacts, the Payer Entity validates the following: each Digital Certificate and its chain to the appropriate Federal Bridge Certificate Policy (CP), delegation of rights where required, and Signature Artifact. Additionally, the Payer Entity decrypts the hash of the Document and validates data integrity of the Document received. (Note - The Payer Entity does not validate the accuracy of the contents of the Documentation received as part of determining the document integrity.) Any responses to the sending Provider Entity regarding success or failure of validation of the digital signature, delegation of rights, and integrity of the document shall be defined in the specific esMD use case.

** 10.2 Activity Diagram **
<span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">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.

<span style="color: #0092d6; font-family: Arial,Helvetica,sans-serif;">Figure 3: Activity Diagram


Notes:
 * 1) <span style="font-family: Arial,Helvetica,sans-serif;">The following are alternative paths (1A/1B, 4A/4B, 6A/6B+6C+6D, and 7A/7B)
 * 2) <span style="font-family: Arial,Helvetica,sans-serif;">Activities related to Delegatee (1B, 4B, 5, 6B, 6C, 6D, and 7B) occur only if the is a need for a Delegation of Rights

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).
 * <span style="font-family: Arial,Helvetica,sans-serif;">Step# || <span style="font-family: Arial,Helvetica,sans-serif;">Actor || <span style="font-family: Arial,Helvetica,sans-serif;">Role  || <span style="font-family: Arial,Helvetica,sans-serif;">Event/Description  || <span style="font-family: Arial,Helvetica,sans-serif;">Inputs  || <span style="font-family: Arial,Helvetica,sans-serif;">Outputs  || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability or System Step  ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">1A || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Requests Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity requests Digital Identity from Registration Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity need for Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Relevant Provider Entity identification information || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">1B || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Requests Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee requests Digital Identity from Registration Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee need for Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Relevant Non-Provider Delegatee identification information || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">2 || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Validates Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority approves (or rejects) the request for Identity Proofing and upon approval sends information to Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Relevant Provider Entity /Non-Provider Delegatee identification information || <span style="font-family: Arial,Helvetica,sans-serif;">Response to Provider Entity or Non-Provider Delegatee request for a Digital Identity and request to Certificate Authority to issue Digital Certificate/ Credentials || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">3 || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Creates, Issues and manages security credentials and revocation lists || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority generates the Digital Certificate/Credentials and informs the Provider Entity or Non-Provider Delegatee of their availability || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority’s approved Provider Entity / Non-Provider Delegatee identification information || <span style="font-family: Arial,Helvetica,sans-serif;">Digital Certificate/ Credentials made available by Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">4A || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Receives Digital Certificate / Credentials || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity obtains and incorporates Digital Certificate/ Credentials into its business process || <span style="font-family: Arial,Helvetica,sans-serif;">Digital Certificate / Credentials / issued by Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">END || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">4B || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Receives Digital Certificate / Credentials || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee obtains and incorporates Digital Certificate/ Credentials into its business process || <span style="font-family: Arial,Helvetica,sans-serif;">Digital Credentials / Certificate issued by Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">END || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">5 || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Creator || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity creates and signs Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity and Delegatee Digital Certificate Information and need to delegate a right || <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Assertion available || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">6A || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Attests to action on Document || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity completes action on a Document and applies a non-repudiation digital signature attesting to the action || <span style="font-family: Arial,Helvetica,sans-serif;">Document and completed action || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document and Signature Artifact || <span style="font-family: Arial,Helvetica,sans-serif;">System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">6B || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Attests to action on Document || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee completes action on a Document and applies a non-repudiation digital signature attesting to the action and requests validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Document and completed action || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document and Signature Artifact and request for validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">6C || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Validator || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity system validates and signs Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee request for a validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">6D || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Applying Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee associates the validated Delegation of Rights Assertion with the signed document || <span style="font-family: Arial,Helvetica,sans-serif;">Validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document Signature Artifact and the validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability and System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">7A || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Document Sender || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity sends signed Document and Signature Artifacts to Payer Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document and Signature Artifact and need to send to payer entity || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document and Signature Artifact || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">7B || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Document Sender || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee sends signed Document, Signature Artifacts, and validated Delegation of Rights Assertion to Payer Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document, Signature Artifacts and validated Delegation of Rights Assertion and need to send to payer entity || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document, Signature Artifacts and validated Delegation of Rights Artifacts || <span style="font-family: Arial,Helvetica,sans-serif;">Interoperability ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">8 || <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity || <span style="font-family: Arial,Helvetica,sans-serif;">Receiver and validator of Document || <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity receives Document, authenticates Signature Artifacts, where appropriate any Delegation of Rights Assertions, and validates data integrity of submission from the Provider Entity or Delegatee || <span style="font-family: Arial,Helvetica,sans-serif;">Digitally Signed Document and Signature Artifact, and where appropriate Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Success or failure of Signature Artifact validation, Delegation of Rights Artifacts validation, and Data integrity authentication || <span style="font-family: Arial,Helvetica,sans-serif;">System ||

10.3 Functional Requirements
<span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">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
<span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">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.


 * || <span style="font-family: Arial,Helvetica,sans-serif;">Initiating System || <span style="font-family: Arial,Helvetica,sans-serif;">Action || <span style="font-family: Arial,Helvetica,sans-serif;">Information Interchange Requirement Name || <span style="font-family: Arial,Helvetica,sans-serif;">Action || <span style="font-family: Arial,Helvetica,sans-serif;">Receiving System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">I || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Request for Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">II || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Request for Digital Identity || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">III || <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Digital Identity request response and request to issue Digital Certificate/Credentials by Certificate Authority || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">IV || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Availability of Digital Certificate/Credentials || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">V || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Availability of Digital Certificate/Credentials || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Non-Provider Delegatee Entity Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">VI || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Link for Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">VII || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Request for validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">VIII || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">IX || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Document and Signature Artifact || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity Information System ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">X || <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee Information System || <span style="font-family: Arial,Helvetica,sans-serif;">Send || <span style="font-family: Arial,Helvetica,sans-serif;">Document, Signature Artifact, validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Receive || <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity Information System ||

10.3.2 System Requirements
<span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">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. <span style="font-family: Arial,Helvetica,sans-serif;">b) Create Delegation of Rights if required <span style="font-family: Arial,Helvetica,sans-serif;">c) Respond to request to Validate Delegation of Rights Assertion <span style="font-family: Arial,Helvetica,sans-serif;">d) Performs actions on a Document (create, modify, read) <span style="font-family: Arial,Helvetica,sans-serif;">e) Apply non-repudiation Digital Signature to Delegation of Rights Assertion, and Documents and creates Signature Artifacts || <span style="font-family: Arial,Helvetica,sans-serif;">b) Request Validated Delegation of Rights <span style="font-family: Arial,Helvetica,sans-serif;">c) Performs actions on a Document (create, modify, read) <span style="font-family: Arial,Helvetica,sans-serif;">d) Apply non-repudiation Digital Signature to Documents, creates Signature Artifacts and attaches validated Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">b) Validate identification information for approval/rejection || <span style="font-family: Arial,Helvetica,sans-serif;">b) Manage Digital Certificate/Credential life cycle ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">System || <span style="font-family: Arial,Helvetica,sans-serif;">System Requirement  ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Payer Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">a) Verify Delegation of Rights (if any), digital signatures, traceability to registered provider, and validates integrity of Document ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">a) Incorporate signing Digital Certificate
 * <span style="font-family: Arial,Helvetica,sans-serif;">Delegatee Information System (usually the same as Provider Entity Information System || <span style="font-family: Arial,Helvetica,sans-serif;">a) Incorporate signing Digital Certificate
 * <span style="font-family: Arial,Helvetica,sans-serif;">Registration Authority Information System || <span style="font-family: Arial,Helvetica,sans-serif;">a) Process Provider and Non-Provider Delegatee identification information
 * <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Authority Information System || <span style="font-family: Arial,Helvetica,sans-serif;">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.

<span style="color: #0092d6; font-family: Arial,Helvetica,sans-serif;">Figure 4: Sequence Diagram
=** 11.0 Dataset Requirements **= <span style="font-family: Arial,Helvetica,sans-serif;">This table lists the data elements and data element sets that will be available within the certificate information, document signature, and delegation of rights assertion. 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.
 * 1) <span style="font-family: Arial,Helvetica,sans-serif;">Signing Certificate Information
 * 2) <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Assertion
 * 3) <span style="font-family: Arial,Helvetica,sans-serif;">Validated Delegation of Rights Assertion
 * 4) <span style="font-family: Arial,Helvetica,sans-serif;">Document Signature
 * 5) <span style="font-family: Arial,Helvetica,sans-serif;">Code Sets

<span style="font-family: Arial,Helvetica,sans-serif;">Signing Certificate Information <span style="font-family: Arial,Helvetica,sans-serif;">Note: Additional X.509v3+ specific field or extension requirements will be expanded during harmonization.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Section || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element || <span style="font-family: Arial,Helvetica,sans-serif;">Multiple Values (yes/no) || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element Description || <span style="font-family: Arial,Helvetica,sans-serif;">Additional Notes ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Signing Certificate Information || <span style="font-family: Arial,Helvetica,sans-serif;">Version || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Version of X.509 || <span style="font-family: Arial,Helvetica,sans-serif;">All must be version 3 or later (X.509v3+) ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Serial Number || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Unique Serial Number of Certificate from the CA ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Algorithm ID || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Algorithm used by the CA to sign the certificate ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Issuer || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Name of CA that issued certificate ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Validity || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Period of time for which the certificate is valid || <span style="font-family: Arial,Helvetica,sans-serif;">Not Before, Not After ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Subject || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Subject Name -- Name of whom the certificate is issued to ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Subject Public Key Info || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">The subject’s public key ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Issuer Unique Identifier || <span style="font-family: Arial,Helvetica,sans-serif;">No ||   ||   ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Subject Unique Identifier || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">NPI or Alternate Payer ID || <span style="font-family: Arial,Helvetica,sans-serif;">For billing entities only ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Extensions || <span style="font-family: Arial,Helvetica,sans-serif;">Yes || <span style="font-family: Arial,Helvetica,sans-serif;">Describes specific purpose of use, values, and critical or non-critical identifier || <span style="font-family: Arial,Helvetica,sans-serif;">Object Identifier for each extension; this is where the non-repudiation “flag” is located (which must be set) ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Signature || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Signature Algorithm || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Algorithm used to sign the certificate ||  ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Certificate Signature || <span style="font-family: Arial,Helvetica,sans-serif;">No ||   ||   ||
 * Delegation of Rights Assertion **
 * <span style="font-family: Arial,Helvetica,sans-serif;">Section || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element || <span style="font-family: Arial,Helvetica,sans-serif;">Multiple Values (yes/no) || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element Description || <span style="font-family: Arial,Helvetica,sans-serif;">Additional Notes ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights || <span style="font-family: Arial,Helvetica,sans-serif;">Public Digital certificate of assertion signer ||  || <span style="font-family: Arial,Helvetica,sans-serif;">X.509v3+ Token Profile || <span style="font-family: Arial,Helvetica,sans-serif;">Signed by trust authority, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Signature Artifact ||   || Signature Artifact encrypted by signer’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 Delegation of Rights Assertion ||
 * ^  || Delegation of Rights ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Assertion for the Delegation of Rights || <span style="font-family: Arial,Helvetica,sans-serif;">Exact nature of artifact to be determined during harmonization At a minimum the Delegation of Rights must include the CA and Serial Number of the Delegatee Signing Digital Certificate, the effective date range of the Delegation of Rights, and the rights granted ||

** Validated Delegation of Rights Assertion **

 * <span style="color: #000000; font-family: Arial,Helvetica,sans-serif;">Section || Data Element || <span style="font-family: Arial,Helvetica,sans-serif;">Multiple Values (yes/no)
 * es (yes/no) ** || Data Element Description || Additional Notes ||
 * Validation Signature || Public Digital certificate of Validation Server ||  || X.509v3+ Token Profile || Signed by trust authority, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || Signature Artifact ||   || Signature Artifact encrypted by signer’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 Signature Artifact and Delegation of Rights Assertion below ||
 * Delegation of Rights || Public Digital certificate of assertion signer ||  || X.509v3+ Token Profile || Signed by trust authority, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || Signature Artifact ||   || Signature Artifact encrypted by signer’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 Delegation of Rights Assertion ||
 * ^  || Delegation of Rights ||   || Assertion for the Delegation of Rights || Exact nature of artifact to be determined during harmonization At a minimum the Delegation of Rights must include the CA and Serial Number of the Delegatee Signing Digital Certificate, the effective date range of the Delegation of Rights, and the rights granted ||


 * Document Signature **
 * <span style="font-family: Arial,Helvetica,sans-serif;">Section || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element || <span style="font-family: Arial,Helvetica,sans-serif;">Multiple Values (yes/no) || <span style="font-family: Arial,Helvetica,sans-serif;">Data Element Description || <span style="font-family: Arial,Helvetica,sans-serif;">Additional Notes ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">ID || <span style="font-family: Arial,Helvetica,sans-serif;">Unique Transaction ID || <span style="font-family: Arial,Helvetica,sans-serif;">No || <span style="font-family: Arial,Helvetica,sans-serif;">Provider Entity Assigned Unique ID for the signed Document || <span style="font-family: Arial,Helvetica,sans-serif;">IDs must be globally unique across all Provider Entities (e.g., UUID). Unique ID may be a concatenation of more than one data element. ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Digital Identity and Signature of Signer || <span style="font-family: Arial,Helvetica,sans-serif;">Public Digital Certificate of Signer ||  || <span style="font-family: Arial,Helvetica,sans-serif;">X.509v3+ Token Profile || <span style="font-family: Arial,Helvetica,sans-serif;">Signed by trust authority, certificates must be issued by authorities cross- certified with the Federal Bridge ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Signature Artifact ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Signature Artifact encrypted by signer’s private key || <span style="font-family: Arial,Helvetica,sans-serif;">Exact nature of artifact to be determined during harmonization At a minimum the Signature Artifact will include the digest (hash) of the Document, Date/time of Signature and action ||


 * Code Sets **
 * **Section** || **Data Element** || **Multiple Values (yes/no)** || **Data Element Description** || **Additional Notes** ||
 * <span style="font-family: Arial,Helvetica,sans-serif;">Code Sets || <span style="font-family: Arial,Helvetica,sans-serif;">Document Action || <span style="font-family: Arial,Helvetica,sans-serif;">Yes || <span style="font-family: Arial,Helvetica,sans-serif;">Action performed on document || <span style="font-family: Arial,Helvetica,sans-serif;">Needs code table (see IHE DSG) ||
 * ^  ||   ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Create || <span style="font-family: Arial,Helvetica,sans-serif;">author ||
 * ^  ||   ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Modify || <span style="font-family: Arial,Helvetica,sans-serif;">Author of changes ||
 * ^  ||   ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Read || <span style="font-family: Arial,Helvetica,sans-serif;">Attesting to the review of the signed document ||
 * ^  || <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Assertion Action || <span style="font-family: Arial,Helvetica,sans-serif;">Yes || <span style="font-family: Arial,Helvetica,sans-serif;">Action performed on the Delegation of Rights Assertion || <span style="font-family: Arial,Helvetica,sans-serif;">Needs code table ||
 * ^  ||   ||   || <span style="font-family: Arial,Helvetica,sans-serif;">Validation || <span style="font-family: Arial,Helvetica,sans-serif;">Delegation of Rights Assertion is valid as of the time stamp ||

=** 12.0 Risks, Issues and Obstacles **= <span style="font-family: Arial,Helvetica,sans-serif;">The Risks, Issues and Obstacles section lists the concerns that might interfere with meeting the requirements of the Use Case.

<span style="font-family: Arial,Helvetica,sans-serif;">A. 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. <span style="font-family: Arial,Helvetica,sans-serif;">B. 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 <span style="font-family: Arial,Helvetica,sans-serif;">C. 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 <span style="font-family: Arial,Helvetica,sans-serif;">D. Provider Entities or Payer Entities 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 <span style="font-family: Arial,Helvetica,sans-serif;">E. Unintended disclosure of Personal Health Information <span style="font-family: Arial,Helvetica,sans-serif;">F. Unintended disclosure of Medical Identifier information during the identity proofing <span style="font-family: Arial,Helvetica,sans-serif;">G. Technical and/or operational barriers to scaling participating platforms or services to meet volume of Documents to be signed <span style="font-family: Arial,Helvetica,sans-serif;">H. Technical and/or operational barriers to creating Delegation of Rights Assertions <span style="font-family: Arial,Helvetica,sans-serif;">I. Technical and/or operational barriers to validating Delegation of Rights Assertions when requested <span style="font-family: Arial,Helvetica,sans-serif;">J. Delays related to inconsistencies in information provided to obtain Digital Certificates/Credentials <span style="font-family: Arial,Helvetica,sans-serif;">K. Risks associated with the digital identity process <span style="font-family: Arial,Helvetica,sans-serif;">a) Compliance with Identity Proofing Requirements <span style="font-family: Arial,Helvetica,sans-serif;">b) Compliance with Certificate Lifecycle (including revocation) <span style="font-family: Arial,Helvetica,sans-serif;">c) Compliance with Delegation of Rights (including revocation) <span style="font-family: Arial,Helvetica,sans-serif;">d) Issues inherent in the creation and use of X.509v3+ Digital Certificates =** Appendices **=

** Appendix A: Related Use Cases **
<span style="font-family: Arial,Helvetica,sans-serif;">A. **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] <span style="font-family: Arial,Helvetica,sans-serif;">B. **Author (of Record)** - The individual that creates a record. <span style="font-family: Arial,Helvetica,sans-serif;">C. **Certificate Authority (NIST)**- An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or CRLs. <span style="font-family: Arial,Helvetica,sans-serif;">D. **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. <span style="font-family: Arial,Helvetica,sans-serif;">E. **Decryption** - The reverse process of encryption, i.e., to make the encrypted information readable again. <span style="font-family: Arial,Helvetica,sans-serif;">F. **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. 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. <span style="font-family: Arial,Helvetica,sans-serif;">G. **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). <span style="font-family: Arial,Helvetica,sans-serif;">H. **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.) <span style="font-family: Arial,Helvetica,sans-serif;">I. **Electronic Medical Documentation (eMD)**
 * [|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 **
 * <span style="font-family: Arial,Helvetica,sans-serif;">Submitting electronic Medical Documentation (eMD), upon request or unsolicited, is the act or an instance of furnishing authored structured or unstructured electronic documents that are digitally signed authenticating Provider/Supplier as Author of Record (AoR) for stated dates of service, services rendered, devices and/or items provided as billed on a claim submitted or in request for determination of coverage.
 * <span style="font-family: Arial,Helvetica,sans-serif;">Structured eMD is electronic information that can be stored in one or more computer file(s) in entirety as a single document, as a document having individual sections or sets of data elements, and/or as part of a database.

<span style="font-family: Arial,Helvetica,sans-serif;">J. **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. <span style="font-family: Arial,Helvetica,sans-serif;">K. **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. <span style="font-family: Arial,Helvetica,sans-serif;">L. **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. <span style="font-family: Arial,Helvetica,sans-serif;">M. **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. <span style="font-family: Arial,Helvetica,sans-serif;">N. **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. <span style="font-family: Arial,Helvetica,sans-serif;">O. **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. <span style="font-family: Arial,Helvetica,sans-serif;">P. **Record**- A completed body of data that is intended to represent an accurate and persistent report of actions, events, or evidence.
 * <span style="font-family: Arial,Helvetica,sans-serif;">**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.

<span style="font-family: Arial,Helvetica,sans-serif;">Q. **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). <span style="font-family: Arial,Helvetica,sans-serif;">R. **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]
 * US Copyright Office:
 * []