Query+for+Digital+Certificate+Use+Case+for+Direct+Project




 * Thank you all for your participation! **
 * As of July 20th, 2011 the content of the //Query for Digital Certificate Use Case for Direct Project//, as part of the Provider Directories Initiative has been finalized. Below are links to the Final versions of the Use Case Narrative as well as the Functional Requirements Spreadsheet i.e. the Use Case Package. The documents below as well as the text embedded within the Wiki reflect updates that were proposed and agreed upon during the formal Consensus Process. Please contact the Use Case and Requirements Support Leads if you have any remaining questions or concerns. **


 * To access the Final and Approved Microsoft Word version of the //Query for Digital Certificate Use Case for Direct Project// click here:**
 * To access the Microsoft Excel version of the //Query for Digital Certificate Use Case for Direct Project// Functional Requirements Spreadsheet click here:**

To view disposition to comments received through the Wiki discussion threads and during consensus, please click this [|Review Log]
 * To view final votes on the //Query for Digital Certificate Use Case for Direct Project//, please click the Consensus page. toc**

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 to 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, providers, vendors, laboratories, 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 required in the data exchange

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

**2.0 Overview and Scope**
The Provider Directories Initiative focuses on identifying the requirements, core data set, standards, and certification criteria that will support querying of Provider Directories to determine a destination's Electronic Service Information (including electronic address and any required security information) in order to support electronic exchange of health information. The initiative will over time encompass a number of Use Cases related to Provider Directories.


 * The scope of this Use Case** includes requirements and core data set to enable a system to query Certificate Directories for digital certificate(s) for the Direct Project (refer to Glossary). The digital certificate(s) obtained from the query will facilitate secure exchange of health information. This capability is used by the Certificate Directory Consumer System to obtain a Digital Certificate prior to secure communication with the target of their communication where the communications mechanism does not provide certificate discovery automatically (i.e. Message Based End-to-End Encryption).

This Use Case aligns with Meaningful Use and aims to enable providers and others to electronically obtain the digital certificate of a desired destination to support secure exchange of health information.

Successful outcomes for this first Use Case include:
 * Providers and other authorized entities can retrieve digital certificate(s) to facilitate secure exchange of health information
 * Standardized query mechanism for Certificate Directories can be adopted by EHR vendors, State HIEs, HISPs and other mediators of exchange
 * Standardization and simplification of the implementation of interfaces to query Certificate Directories

There is one scenario defined for this Use Case. This scenario focuses on querying the Certificate Directory to retrieve the digital certificate(s) needed to support secure health information exchange. In this scenario, the digital certificate requester has an Direct Address, but needs the ability to retrieve the digital certificate(s) by querying a Certificate Directory.

2.1 In Scope

 * Requirements, core data set and interface specification for the messaging between the digital certificate requester and the Certificate Directory that are needed to support queries to Certificate Directories to retrieve the digital certificate(s) when a Direct Address is known

2.2 Out of Scope

 * Data elements for physical addresses and attributes, beyond what is necessary for discovering the digital certificate(s)
 * Discovery of a Direct Address, which is covered in the //Query for Electronic Service Information including Electronic Address Use Case//
 * Discovery using a set of attributes (other than a Direct Address)
 * The manner in which the digital certificate requester uses the digital certificate(s) when received
 * The transport mechanism that will provide guaranteed delivery and error handling
 * Discovery across Certificate Directories
 * Certificate Directory Sourcing Data
 * Certificate Directory Data Management
 * Directories that are used internally in organizations or systems
 * Queries or Exchanges between Certificate Directories themselves
 * Federation of Certificate Directories
 * Query for other security artifacts
 * Query for certificate by any identifier (e.g. UUID) other than a Direct Address

2.3 Background
The Provider Directories Initiative addresses a central need to search for and find “discoverable” information essential for enabling health information exchange between senders and destinations. The Initiative aims to meet the immediate need for implementation specifications, guides, and standards to support EHR system certification for queries of Provider Directories and Certificate Directories under Meaningful Use Stage 2 and beyond. The Initiative also holds importance and relevance because it addresses broader requirements for secure exchange of health information.

The initial phase of the Provider Directories Initiative addresses two Use Cases: the discovery and retrieval of the digital certificate(s) from a Certificate Directory when a Direct Address is known and the discovery of Electronic Service Information from a Provider Directory.

The Provider Directories Initiative and the //Query for Digital Certificate Use Case for Direct Project// have been selected because they align with the anticipated Meaningful Use Stage 2 criteria.

2.4 Policy Issues
There are a number of policy issues that will need to be addressed in order to realize the capabilities envisioned in the //Query for Digital Certificate Use Case for Direct Project//. These include:
 * Maintenance (Sourcing Data and Data Management): The ability to maintain accurate data presents challenges for entities that own and maintain Certificate Directories. Policy direction may be needed to guide the proper maintenance of data including data reconciliation when data is received from different sources, data management, and other functions required to ensure the accuracy of data within directories.
 * Certification/accreditation of directories: Users of Certificate Directories will need a level of assurance regarding the reliability, accuracy, and security of the provider information. A certification/accreditation program may be required to ensure that Certificate Directories adopt practices and operate in a manner that will meet the standards of the health care industry.
 * Privacy and security: A risk analysis will need to be done to assess risks introduced as a result of the solution chosen for this Use Case.

2.5 Regulatory Issues
There are no regulatory issues identified for this Use Case.

2.6 Communities of Interest
Communities of Interest are public and private stakeholders that are directly involved in the business process or are involved in the development and use of interoperable implementation guides and implementation of the Solution. Some members are business actors in the Use Case. Communities of Interest may directly participate in the exchange, that is they are actors, or indirectly through the results of the improved business process.

The following list of Communities of Interest and their definitions have been identified for this Use Case: **Table 1: Communities of Interest**
 * **Member of Communities of Interest** || **Working Definition** ||
 * Clinicians || Healthcare providers with patient care responsibilities, including physicians, clinical laboratory personnel, advanced practice nurses, physician assistants, nurses, pharmacists, and other licensed and credentialed personnel involved in treating patients. Clinicians may in some instances be the owners of digital certificates maintained in Certificate Directories and may also need to query Certificate Directories. ||
 * Laboratories || A laboratory (often abbreviated lab) may need to discover the digital certificate(s) associated with the ordering or “copy to” provider associated with at lab order. ||
 * Pharmacies || Pharmacies may need to discover the digital certificate(s) of providers that they need to communicate with regarding a patient prescription. ||
 * Provider || Individuals or organizations that are engaged in or support the delivery of healthcare to include Hospital Ambulatory Centers and Provider Practices. These individuals or organizations may be the owners of digital certificate(s) maintained in Certificate Directories and may also need to query Certificate Directories. ||
 * Patients || Individuals who receive healthcare services. These individuals may be the owners of digital certificate(s) maintained in Certificate Directories and may also need to query Certificate Directories. (The inclusion of patients as part of the Communities of Interests is not intended to mandate that patients have digital certificates) ||
 * Standards Organizations || Organizations whose purpose is to define, harmonize and integrate standards that will meet clinical and business needs for sharing information among organizations and systems. ||
 * Electronic Health Record (EHR)/Electronic Medical Records (EMR) Vendors || Vendors which provide specific EHR/EMR 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. These software products may need to provide the capability to query Certificate Directories and then use digital certificates when sending transactions. ||
 * Personal Health Record (PHR) Vendors || Vendors which provide specific PHR solutions to patients such as software applications and software services. These suppliers may include developers, providers, resellers, operators, and others who may provide these or similar capabilities. These software products may need to provide the capability to query Certificate Directories and then use digital certificates when sending transactions. ||
 * Federal Agencies || Organizations within the federal government that deliver, regulate, or provide funding for health and health care. These organizations may in some instances need to have discoverable digital certificates and may need to query to obtain the digital certificate(s) of other organizations. ||
 * Health Information Exchanges (HIE)/Health Information Organizations (HIO) || Health Information Exchange (HIE) is defined as the mobilization of healthcare information electronically across organizations within a region, community or hospital system. HIEs/HIOs provide mechanisms that support this electronic mobilization of health information. HIEs may create and maintain Certificate Directories that can be queried for digital certificates. HIEs may utilize third party Certificate Directory for the discovery of digital certificate(s) given the Direct Address of the destination. ||
 * Beacon Communities || Selected communities of groups who have received federal funding through the ONC to build and strengthen their health information technology (health IT) infrastructure and exchange capabilities to improve care coordination, increase the quality of care, and slow the growth of health care spending. Beacon grantees may create or use Certificate Directories. ||
 * Health Associations || Professional organizations with health professionals as members focused on a joint purpose and having similarities such as specialty, medical field. They include medical associations, lab associations, pathology associations, academic organizations, other health associations etc. These organizations may create and maintain Certificate Directories that can be queried for digital certificates. Health Associations may utilize third party Certificate Directory for the discovery of digital certificate(s) given the Direct Address of the destination. ||
 * Health Information Service Providers (HISP) || Entities that serve as a node on the National Health & Information Network to enable a private, secure and safe alternative method to send and receive sensitive health information. These organizations may create and maintain Certificate Directories that can be queried for digital certificates. Health Information Service Providers may utilize third party Certificate Directory for the discovery of digital certificate(s) given the Direct Address of the destination. ||
 * Licensing and Certification Organizations || Organizations responsible for developing guidelines and ensuring that relevant parties adhere to those guidelines to ensure proper licensing and certification of systems and other health solutions related to healthcare. These organizations may certify vendor software for compliance with the Certificate Directory query specifications or may accredit Certificate Directories. ||
 * Public Health Agency (State/Local) || State or Local health department agencies that oversee and manage public health activities within their respective geographies. These organizations may in some instance need to have discoverable digital certificate(s) and may need to query to obtain the digital certificate(s) of other organizations. Public Health Agency (State/Local) may create and maintain Certificate Directories that can be queried for digital certificates. ||
 * Certificate Authority || An organization that is responsible for the creation, issuance, revocation, and management of Certificates. The term applies equally to both Roots CAs and Subordinate CAs. ||
 * Registration Authority || Any entity that is responsible for identification and authentication of subjects of certificates, but is not a CA, and hence does not sign or issue certificates. An RA may assist in the certificate application process or revocation process or both. ||

3.0 Challenge Statement
Health information exchange using the Direct Project requires a mechanism to obtain a digital certificate(s) to facilitate secure exchange of health data. Today, this functionality is generally supported by consistent and standardized electronic means, but not adopted widely. A scalable and standardized solution will be needed in order to efficiently, accurately, and reliably query and obtain digital certificates to enable health information exchange using the Direct Project, where the sender does not possess the receiver's digital certificate.

4.0 Value Statement
The ability of systems to query Certificate Directories to obtain digital certificates is needed to facilitate secure exchange of health data. Currently, there is widely available functionality that enables a sender to electronically obtain the digital certificate(s) for a desired destination. However, when the Direct Project is used to exchange health data across organizations, additional functionality is needed. A scalable and standardized method to enable senders to query and obtain digital certificates will facilitate secure health information exchange using the Direct Project, where the sender does not possess the receiver's digital certificate.

5.0 Use Case Assumptions

 * The digital certificate requester system has the Direct Address associated with the digital certificate being requested
 * The digital certificate requester system can access the external Certificate Directory
 * Digital certificate requester systems will be able to send the Direct Address for Certificate Directory searches
 * Digital certificate requester systems will be able to incorporate digital certificates into the Direct Project messaging
 * The Certificate Directory returns digital certificate(s) for the Direct Project and not a pointer
 * For any given Direct Address, the Certificate Directory may return zero, one, or more digital certificate(s)
 * Certificate Directories ensure that their data is accurate, timely, and complete in keeping with relying party agreement
 * A relying party agreement specifying legal and governance policies, data access authorizations and audit trails, data ownership, and the data and certificate use is in effect.
 * All applicable Federal, State & local regulations are supported.

6.0 Pre-Conditions

 * The digital certificate requester or the digital certificate requester system has identified a need to electronically send information to a destination using the Direct Project
 * The digital certificate requester system has the Direct Address associated with the digital certificate being requested
 * The digital certificate requester system has been configured to determine the Certificate Directories that may receive a query
 * Certificate Directories are available and can respond to queries
 * Certificate Authority trust relationships have been established
 * Certificates have been issued and placed in Certificate Directory

7.0 Post Conditions

 * The digital certificate requester performs Certificate Validation on the digital certificate returned by the Certificate Directory.
 * The digital certificate requester selects the correct digital certificate(s) for the intended use when multiple certificates are returned

8.0 Actors and Roles
This section describes the Business Actors that are participants in the information exchange requirements for each scenario. A Business Actor is an abstraction that is instantiated as an IT system application that a Stakeholder uses in the exchange of data needed to complete Use Case action(s); a Business Actor may be a Stakeholder. Furthermore, the systems perform specific roles in this Use Case as listed below: **Table 2: Actors and Roles**
 * **Actor** || **System** || **Role** ||
 * Certificate Directory || Certificate Directory || The Certificate Directory performs the function of processing the Certificate Directory Consumer Query to search for the digital certificate(s) based on the destination’s Direct Address and to return the certificate(s) if available. ||
 * Certificate Directory Consumer || Certificate Directory Consumer System || The Certificate Directory Consumer actor initiates a Certificate Directory query to the Certificate Directory actor indicating the Direct Address of interest and receives the certificate(s) if returned. ||

9.0 Use Case Diagram
The following diagram depicts the query for digital certificate information defined in this Use Case.

**Figure 1: Use Case Diagram**

**Figure 2: Context Diagram**

**10.0 Scenario**
This Use Case contains one scenario. In this scenario, the digital certificate requester has a Direct Address associated with the digital certificate being requested and queries a Certificate Directory to retrieve the digital certificate(s).

10.1 User Story
The digital certificate requester or the digital certificate requester system has a known Direct Address associated with the digital certificate being requested. The digital certificate requester’s system does not have the digital certificate(s) associated with the Direct Address. The digital certificate requester system sends a query to the Certificate Directory without user intervention. The Certificate Directory returns zero or more digital certificate(s) associated with the Direct Address. The digital certificate requester performs Certificate Validation on the digital certificate returned by the Certificate Directory. The digital certificate requester selects the correct digital certificate(s) for the intended use when multiple certificates are returned.

10.2 Triggers

 * **Triggering Event** || **Specific Pre-Conditions** || **Description** ||
 * A Certificate Directory Consumer determines that a digital certificate is required for a Direct transaction || The Certificate Directory Consumer has the Direct Address associated with the digital certificate to be retrieved and the means to send requests and information electronically ||  ||

10.3 Activity Diagram
The visuals below depict a combination of all events described in the scenario flows which are described in further detail in the tables that follow.

**Figure 3: Activity Diagram**

**10.3.1 Base Flow**
**Table 4: Base Flow**
 * **Step #** || **Actor** || **Role** || **Event/Description** || **Inputs** || **Outputs** ||
 * 1 || Certificate Directory Consumer || Digital Certificate Requester || Sends Direct Address || Direct Address || Direct Address ||
 * 2 || Certificate Directory || Query Responder || Sends digital certificate(s) associated with the Direct Address || Direct Address || Digital certificate(s) associated with the Direct Address ||

**10.4.1 Information Interchange Requirements**
**Table 5: Information Interchange Requirements** **10.4.2 System Requirements** **Table 6: System Requirements**
 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Certificate Directory Consumer System || Send || Query for digital certificate || Receives || Certificate Directory System ||
 * Certificate Directory System || Send || Digital certificate associated with the Direct Address || Receives || Certificate Directory Consumer System ||
 * **System** || **System Requirement** ||
 * Certificate Directory Consumer System || Form a query for digital certificate ||
 * Certificate Directory System || Return digital certificate that matches the Direct Address ||
 * Certificate Directory Consumer System || Receive digital certificate ||

**10.5 Sequence Diagram** **Figure 4: Sequence Diagram**

**11.0 Issues, Obstacles, and Potential Risks**
There are a number of issues that may impact the implementation or effectiveness of this Use Case:
 * The limited experience in the healthcare industry with the creation and use of Certificate Directories for the intended uses described in this Use Case.
 * The lack of extensive experience in the implementation of the existing standards
 * Ensuring that there are consistent and reliable mechanisms for updating Certificate Directories
 * The absence of a mechanism, such as accreditation, to ensure that Certificate Directories are reliable and have appropriate control and security
 * Providers are not broadly experienced in acquiring and using certificates
 * Concerns that providers may have about sharing their information
 * Security risks posed by sharing electronic addresses
 * Security risks posed by the inability of the sender or receiver to accurately determine the identity of the holder of the certificate
 * Security risks posed by the inability of the receiver to determine which sender identities will be accepted
 * Clinical risks posed by the lack of a formal mechanism to ensure that a sender understands the disposition of a message sent to a receiver
 * Security risks posed by metadata in the digital certificate
 * Security risks based on spoofing and other attacks on the Certificate Directory
 * Inadequate capability of digital certificate requester systems to use and manage digital certificate(s)
 * Potential for misidentification of a destination and the inappropriate sharing of PHI
 * Certificates issued by Certificate Authorities that are not cross-certified with the Federal Bridge creates a risk in that they are not accepted by federal entities using the Direct Project. (The S&I Framework PD Sprint Team believes that issuing some guidance on the requirement to use a Federal Bridge cross-certified Certification Authority will help mitigate this risk)

12.1 Message Content Requirements
The following table lists the expected content of a Certificate Directory query message.
 * **Section Description** || **Data Elements (Required if available and applicable to support Use Case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Direct Address || Direct Address ||  ||
 * Table 7: Dataset Considerations for Query Message **

The following table lists the expected content of a Certificate Directory return message. **Table 8: Dataset Considerations for Return Message**
 * **Section Description** || **Data Elements (Required if available and applicable to support Use Case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Digital Certificate(s) || Issuer, effective dates, public key, Direct Address || This could be zero if no certificate is found and can send multiple certificates. A return of zero certificate could be a result of a denial or no certificates ||

Appendix A: Related Use Cases
The Use Cases included in this section may be related to the Query for Digital Certificate Use Case for Direct Project.
 * IHE Healthcare Provider Directory (HPD) Profile Provider Information Query Transaction Use Cases
 * HIT Policy Committee Information Exchange Workgroup Entity Level and Individual Level Provider Directory Use Cases
 * HL7/OMG Version 3 Standard Healthcare, Community Services and Provider Directory Use Cases

Appendix B: Previous Work Efforts Related to Provider Directories
NOTE: This list should not be considered inclusive.
 * IHE Technical Framework Supplement Healthcare Provider Directory (HPD) Profile: This profile supports queries against, and management of, healthcare provider information that may be publicly shared in a directory structure.
 * HL7 Version 3 Domain Analysis Model: Interdependent Registries, Release 1: This specification aims to fulfill administrative and continuity of care Use Cases using electronic communication between information system
 * HL7/OMG Version 3 Standard - Healthcare, Community Services and Provider Directory, Release 1: This includes a Service Functional Model that describes the specific functions for Shared or Colloborative Care
 * ASC X12N 274 Provider Directory: This includes two implementation guides, ASC X12 004050X109 which is the Provider Directory and ASC X12 004050X185 which is the Provider Inquiry and Response
 * LDAP (Lightweight Directory Access Protocol): This internet and application protocol supports the storing of information in and editing of directories over an IP network
 * DNS (Domain Name System): A hierarchical naming system built on a distributed database and that translates domain names that are meaningful to humans into numerical identifiers of networking equipment in order to locate and address multiple devices.

Appendix C: Glossary
These items are included to clarify the intent of this Use Case. They should not be interpreted as approved terms or definitions but considered as contextual descriptions. There are parallel activities underway to develop specific terminology based on consensus throughout the industry.


 * Certificate Authority:** An authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs (Certification Authority Revocation List) or CRLs (Certificate Revocation List). (Ref: NIST SP 800-32)


 * Certification Authority Revocation List (****CARLs)**: A signed, time-stamped list of serial numbers of CA public key certificates, including cross-certificates, that have been revoked. (Ref: NIST SP 800-32)


 * Certificate Directory:** A system that either stores digital certificates or has a listing of sources such as Certificate Authorities where digital certificates are stored and can be obtained. This role may be carried out by a Provider Directory.


 * Certificate Revocation List** **(CRLs)**: A list maintained by a Certification Authority of the certificates which it has issued that are revoked prior to their stated expiration date. (Ref: NIST SP 800-32)


 * Certificate Validation:** A process that includes an algorithm to verify that a given certificate path is valid under a given public key infrastructure (PKI). It validates whether the certificate has expired, is used in accordance with its intended purpose and policy requirements, is within the trust chain, and is on any kind of certificate revocation list. (Ref: IEFT RFC 5280)


 * Destination:** The intended recipient who owns the Direct Address used in the query for digital certificate.


 * Digital Certificate**: 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. Additionally, the digital certificate are constrained to those following the Direct Project’s digital certificate criteria. In this context, the digital certificates are X.509 v3 certificates and the implementation is RFC5280. (Ref: NIST SP 800-32)


 * Digital Certificate Requester System**: The electronic system used by a digital certificate requester.


 * Digital Signature:** 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. (Ref: NIST SP 800-32)


 * Direct Address:** An electronic address used to identify an endpoint (a Sender or Receiver) when information is exchanged. The Direct Address has two parts, a Health End Point Name and a Health Domain Name, for example, drbob@samplehispname.org. (Ref: Direct Project FAQ)


 * Direct Project**: The Direct Project establishes standards and documentation to support simple scenarios of pushing data from where it is to where it's needed, in a way that will support more sophisticated interoperability in the future. (Ref: Direct Project Overview)


 * Entity:** An organization or a department, on the sending or receiving side, that may have an Direct Address.


 * Encryption Certificate:** A certificate containing a public key that is used to encrypt electronic messages, files, documents, or data transmissions, or to establish or exchange a session key for these same purposes. (Ref: NIST SP 800-32)


 * Nationwide Health Information Network:** The set of standards, services and policies that enable the secure exchange of health information over the Internet. Accordingly, it is not a particular instance of network connectivity; rather, it is nationwide exchange of health information using nationally recognized standards. (Ref: Direct Project FAQ)


 * Private Key:** (1) The key of a signature key pair used to create a digital signature. (2) The key of an encryption key pair that is used to decrypt confidential information. In both cases, this key must be kept secret. (Ref: NIST SP 800-32)


 * Provider**: An individual on the sending or receiving side, that may have an Direct Address.


 * Provider Directory:** An electronic, searchable resource that lists all information exchange participants, their names, addresses, and other characteristics. A Provider Directory can carry out the role of a Certificate Directory. (Ref: HITPC Information Exchange Workgroup Provider Directory Recommendations)


 * Public Key:** (1) The key of a signature key pair used to validate a digital signature. (2) The key of an encryption key pair that is used to encrypt confidential information. In both cases, this key is made publicly available normally in the form of a digital certificate. (Ref: NIST SP 800-32)


 * Public Key Infrastructure (PKI):** 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. (Ref: NIST SP 800-32)


 * Sender: An individual or entity on the sending side** that may have an Direct Address and needs to query for the digital certificate(s).


 * Receiver: An individual or entity on the receiving side** that has a Direct Address and the digital certificate(s).


 * Trusted Authority**: An entity that has been trusted to issue or manage digital certificates.


 * Trusted Framework**: A complete chain of trust that includes the Certificate Authorities, Certificate Directory, the Consumer, the Destination, and the security of the messaging framework.

Appendix D. References

 * 1) Elements in Transition of Care Use Case 
 * 2) Laboratory Results Reporting to Primary Care Providers (in an Ambulatory Setting) Use Case 
 * 3) Query for Electronic Address Use Case 
 * 4) NIST SP 800-32 - Introduction to Public Key Technology and the Federal PKI Infrastructure <[]>
 * 5) HITSC Privacy & Security Workgroup Meeting Materials on Digital Certificates <[]>
 * 6) HIT Policy Committee Information Exchange Workgroup Provider Directory Recommendations, February 28, 2011 <[]>
 * 7) Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <[]>
 * 8) Federal Public Key Infrastructure Policy Authority (FPKIPA) <[]>
 * 9) The Direct Project Overview <[]>
 * 10) Direct Project FAQ <[]>
 * 11) The Direct Project Session 5 (Provider Directories) <[]>
 * 12) CA Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates <[]>
 * 13) FPKIPA Criteria and Methodology For Cross-Certification With the U.S. Federal Bridge Certification Authority (FBCA) <[]>