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.

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

These Use Cases describe:

• The operational context for the data exchange
• The stakeholders with an interest in the Use Case
• The information flows that must be supported by the data exchange
• The types of data and their specifications required in the data exchange

The Use Case is the foundation for identifying and specifying the standards required to support the data exchange and developing reference implementations and tools to ensure consistent and reliable adoption of the data exchange standards.

2.0 Initiative Overview

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

Healthcare payers frequently request that providers submit additional medical documentation in order to adjudicate and support the processing of a specific claim or set of claims and perform other administrative functions, including identification of improper payments. Currently, Medicare Review Contractors send over 1 million requests for medical documents per year manually using a paper request letter and mailing it through the US Postal Service to healthcare providers. Until recently, healthcare providers had only two options for submitting the requested records to Medicare Review Contractors: 1) mail paper or 2) send a fax. The manual paper process is costly, time consuming and can delay proper claims processing on both the senders’ and receivers’ end.As of September 15, 2011, a pilot group of Health Information Handlers (HIHs) and Medicare Review Contractors began accepting electronic submissions from providers, as part of the first phase of esMD. These electronic submissions consist of an unstructured .PDF format of a scanned image, within an Integrating the Healthcare Enterprise Cross-Enterprise Document Reliable Interchange (IHE XDR) wrapper. This initiative will provide added value to CMS, Commercial Payers, and Providers by defining the interoperability requirements for additional automation of the electronic request and submissions process.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:

• Develop a registration process to allow Providers to sign up to receive electronic medical documentation requests from CMS Review Contractors
• Identify a standards-based machine-interoperable electronic format to provide an alternate electronic method for the current paper version of the medical documentation requests that are sent to providers
• Identify a secure method of sending medical documentation requests from CMS review contractors to providers
• Identify a solution that will enable an electronic replacement of wet signatures, for medical documents submitted from providers to CMS

In order to address the objectives above, this Initiative included the following three workgroups:

• Provider Profiles Authentication (PPA) workgroup: Addresses the registration process, technical transport and authentication needed to allow Payers to identify Providers and send requests to them. This workgroup is dependent on the Provider Directories Use Case #2 (Electronic Service Information Discovery) outputs, as well as the Exchange support (for the CMS User Story) for secure transport and other infrastructure.
• Structured Content (SC) workgroup: 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.

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:

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

3.1 Background

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.

3.2 In Scope

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.
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).
C. Actions include,but are not limited to: document creation, document completion, document modification, document review and document exchange (including device signature).
D. The following products of AoR Level 1 may be reviewed and expanded as necessary to meet the requirements of AoR Level 2.
a. Identity Proofing
b. Digital Identity Management
c. Encryption (encryption only as it pertains to protecting the confidentiality of payloads containing PHI)
d. Digital Signature and Delegation of Rights artifacts
E. Persistence of Digital Signature and Delegation of Rights artifacts
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)
G. Defining delegation of rights between Providers and other authors
H. Specific envelope metadata used to store or transmit the Documentation, Digital Signature Artifacts and associated Delegation of Rights
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.
J. Validation of signature and delegation of rights artifacts by recipient
K. Interactions between Provider Entity or Payer Entity and :
a. Certificate Authority
b. Registration Authority
c. And each other

3.3 Out of Scope

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
B. Identity Proofing, Digital Credential Management, Digital Signatures and Delegation of Rights as defined by and required for AoR Level 1
C. Digital signature to allow traceability of individual contributions to a document and other items to be defined as part of AoR Level 3
D. Interactions between:
a. Payer and its Payer Contractors
b. Provider and its Agent
c. Payer or Payer Contractor and its Gateway
E. Transactio level encryption
F. A definition of electronic transactions between RA and CA
G. A definition of electronic transactions between Payer Entity and RA or CA
H. A definition of electronic transactions between Provider Entity and RA or CA
I. Consent,privacy, and use of the document in situations other than providing documentation to payers for the sake of program or benefits administration
J. Signature by patient or their authorized representative

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

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: 

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 proof of document authorship and document submission

5.0 Use Case Assumptions

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 
B. Federal Bridge medium assurance credentials are available
C. Registration Authority models (RA) and registration authority processes exist for Federal Bridge medium assurance identity proofing
D. Certificate Authorities (CA) exist and are capable of providing the necessary X.509v3 digital credentials for document signing
E. Technology exists to utilize the digital credentials for signing of documents 
F. Document signature process requires support for delegation of rights
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
H. Payer, Payer Contractors and Payer Gateway shall be treated as the Payer Entity
I. A Provider, Group of Providers, Agent, and Hospital/Health Systems shall be treated as Provider Entity
J. The signature on a document attests that the associated action(s) have been performed on the document at the indicated time
K. All entities involved in AoR L2 transactions will maintain appropriate audit logs
L. All actors shall create all transactions utilizing current industry accepted standards
M. All actors shall ensure all transactions will have appropriate security to ensure data is transmitted with integrity, confidentiality, and reliability
N. All actors and systems shall ensure all transactions will be delivered in a timely manner
O. All actors shall have signed any required participation or data use agreements
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)
Q. In general, documents should be signed to attest to authorship when they are completed
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.
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]
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.
U. Signed Documents must be available to meet Payer Documentation requirements.
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:

• PDF
• Text blobs
• Permanent representation of a transaction (order/ receive results lab test/imaging/pharmaceutical)
• Summary document such as a C-CDA (external signature, not as part of the CDA 2.0)
• Any valid Mime type

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)
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

• Provider Entity, Payer Entity, and recipient of Delegation of Rights has:
  • Been identity proofed at Federal Bridge Medium Assurance
  • Received and is maintaining X.509v3+ signing certificate
• Provider Entity has the ability to perform the functions on a document that the Digital Signature will attest to, for example: creation, modification, review
• Provider Entity has the ability to store and exchange the document and digital signature artifacts
• 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.
• 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.
• Provider Entity systems shall have the ability to create delegation of rights artifacts
• 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.

7.0 Post Conditions

• 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
• 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
• 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

8.0 Actors and Roles

This table outlines the business actors that are participants in the information exchange requirements. A business actor is a person or organization that directly participates in a scenario. Thus, as a person or organization, the actor can (and should) be a stakeholder.The business actor must use a system to perform the functions and to participate in the information interchange. NOTE: A Business Actor may be a Stakeholder and also can have more than one role.

9.0 Use Case Diagram

Figure 1 : Use case Diagram

Image AddedUC 4.4.13.jpg

Figure 2 : AoR Context Diagram

Image Addedcontext diagram.jpg

10.0 Scenario

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

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

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

Image AddedActivity Diagram.jpg

Notes:

1. The following are alternative paths (1A/1B, 4A/4B, 6A/6B+6C+6D, and 7A/7B)
2. 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).

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.

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.

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

Image Addedseq dig.jpg

11.0 Dataset Requirements

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. Signing Certificate Information
2. Delegation of Rights Assertion
3. Validated Delegation of Rights Assertion
4. Document Signature
5. Code Sets

Signing Certificate Information
Note: Additional X.509v3+ specific field or extension requirements will be expanded during harmonization.

Delegation of Rights Assertion

Validated Delegation of Rights Assertion

Document Signature

Code Sets

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

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
• 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
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]
B. Author (of Record) - The individual that creates a record.
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.
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.
E. Decryption - The reverse process of encryption, i.e., to make the encrypted information readable again.
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. 
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).
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.)
I. Electronic Medical Documentation (eMD)

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

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

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).
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:
  • http://www.copyright.gov/eco/help-file-types.html