PD+-+Query+for+Electronic+Address+Use+Case

toc

//**Please use the [|discussion threads] to provide your comments on the Query for Electronic Address Use Case.**//

1.0 Preface and Introduction
To fully realize the benefits of health IT, the Office of the National Coordinator for Health Information Technology (ONC), as part of the Standards and Interoperability (S&I) Framework is developing Use Cases that define the interoperability requirements for high priority health care data exchange 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 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.

Successful outcomes for this second Use Case include:
 * The scope of this Use Case** includes requirements and core data set to enable a system to query Provider Directories for electronic addresses (refer to Glossary) and security information e.g. digital certificate(s). The electronic address and security information obtained from the query will facilitate secure exchange of health information.


 * 1) Providers and other authorized entities can look up electronic addresses to facilitate secure exchange of health information
 * 2) Standardized query mechanism for Provider Directories that can be adopted by EHR vendors, State HIEs, HISPs and other mediators of exchange
 * 3) Standardization and simplification of the implementation of interfaces to query Provider Directories

There is one scenario defined for this Use Case. This scenario focuses on querying the Provider Directory to retrieve the electronic address and security information needed to support secure health information exchange.

2.1 In Scope

 * Requirements, core data set, and interface specifications for the messaging between the Electronic Address Consumer and the Provider Directory that are needed to support queries to Provider Directories to retrieve electronic address and security information to support electronic health information exchange
 * Support for the development of certification criteria for EHR systems to enable Provider Directory queries
 * Exchanges dealing with sending one message to one recipient
 * This Query for Electronic Address Use Case include the capabilities of the Query for Digital Certificate Use Case for Direct Project by reference as required.

2.2 Out of Scope

 * Data elements and attributes, beyond what is necessary for discovering the desired destination’s correct electronic address and security information
 * Validation of electronic addresses and how the consumer system selects the correct electronic address when multiple electronic addresses are returned
 * The manner in which the consumer uses the electronic address when received
 * The transport mechanism, between the Electronic Address Consumer and the desired destination, that will provide guaranteed delivery and error handling
 * Discovery across Provider Directories
 * Provider Directory Sourcing Data
 * Provider Directory Data Management
 * Directories that are used internally in organizations or systems
 * Queries or Exchanges between Provider Directories themselves
 * Federation of Provider Directories
 * Patient to provider consent relationships and messaging

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 Directory 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 an electronic address from a Provider Directory.

The Provider Directories Initiative and the Query for Electronic Address Use Case have been selected because of the critical need to support health information exchange under different exchange frameworks and their alignment to Meaningful Use.

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 Electronic Address Use Case. These include:
 * Architecture: An architecture across national, state, regional, and local levels that will support the provider directory initiative is critical and will need to be defined to support widespread adoption. Multiple Provider Directories exist today and the ability to query one or multiple directories depends on the architectural model that can reliably and efficiently support these queries.
 * Maintenance (Sourcing Data and Data Management): The ability to maintain accurate data presents challenges for entities that own and maintain Provider 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 Provider 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 Provider Directories adopt practices and operate in a manner that will meet the standards of the health care industry
 * Privacy and security: A risk analysis of issues related to unintended discoverability, privacy, and security breaches related to this Use Case must be conducted as part of Harmonization.

2.5 Regulatory Issues
There are no regulatory issues identified yet 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. 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 are for discussion purposes for health information exchange: **Table 1: Communities of Interest**
 * **Member of Communities of Interests** || **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 discoverable information maintained in Provider Directories and may also need to query Provider Directories. ||
 * Laboratories || A laboratory (often abbreviated lab) may need to discover the electronic addresses and security information associated with the ordering or “copy to” provider associated with at lab order. ||
 * Pharmacies || Pharmacies may need to discover the electronic addresses and security information 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 Physicians,HospitalAmbulatoryCenters, and Provider Practices. These individuals or organizations may be the owners of electronic addresses and security information maintained in Provider Directories and may also need to query Provider Directories. ||
 * Patients || Individuals that receive healthcare services. These individuals may be the owners of digital certificate(s) maintained in Provider Directories and may also need to query Provider Directories. (The inclusion of patients as part of the Communities of Interests is not intended to mandate that patients have electronic addresses) ||
 * 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/Electronic Medical Record 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 Provider Directories and then use electronic addresses and security information 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 Provider Directories and then use electronic addresses and security information 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 instance need to have discoverable electronic addresses and security information maintained in Provider Directories and may need to query Provider Directories to obtain the electronic addresses and security information of other organizations and individuals. ||
 * 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 Provider Directories that can be queried for electronic addresses and security information. HIEs may utilize Provider Directories for the discovery of electronic addresses and security information. ||
 * 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 Provider 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 Provider Directories that can be queried for electronic addresses and security information. Health Associations may utilize third party Certificate Directory for the discovery of electronic addresses and security information. ||
 * 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 Provider Directories that can be queried for electronic addresses and security information. Health Information Service Providers may utilize Provider Directories for the discovery of electronic addresses and security information. ||
 * 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 provider directory query specifications or may accredit Provider 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 electronic addresses and may need to query to obtain electronic addresses and security information. Public Health Agency (State/Local) may create and maintain Provider Directories that can be queried for electronic addresses and security information. ||

3.0 Challenge Statement
Health information exchange requires a mechanism to obtain an electronic address (see glossary) and security information to facilitate secure exchange of health data. Today, this functionality is generally supported within organizational boundaries, but there are not widely-adopted, consistent, and standardized means to query Provider Directories across organizational boundaries. A scalable and standardized solution will be needed in order to efficiently, accurately, and reliably query and obtain electronic address and security information to enable health information exchange across organizational boundaries.

4.0 Value Statement
The ability of consumer systems to query Provider Directories to obtain electronic addresses and security information is needed to facilitate secure exchange of health data. Currently, there is no widely available functionality that enables an Electronic Address Consumer to electronically obtain the electronic address and security information. A scalable and standardized method to enable consumers to query and obtain electronic addresses will facilitate secure health information exchange.

5.0 Use Case Assumptions

 * Electronic Address Consumer systems can access the external Provider Directory
 * Electronic Address Consumer systems will be able to receive responses from Provider Directories
 * Electronic Address Consumer systems will be able to interact with users to resolve ambiguous selections
 * Electronic Address Consumer systems will be able to send information for Provider Directory searches
 * Electronic Address Consumer systems will be able to receive and use electronic addresses and security information from Provider Directories
 * The Provider Directory returns electronic address and security information and not a pointer
 * The Provider Directory may return zero, one, or more electronic address and security information
 * Provider Directory systems have controls to ensure that destination information is maintained in a secure manner and that information is shared only with authorized users
 * Provider Directories have valid and reliable algorithms for identifying providers that match the query parameters
 * Provider 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, data ownership, and the data use is in effect
 * A Provider Directory will provide at least one secured and guaranteed delivery transport mechanism
 * All applicable Federal, State, & local regulations are supported

6.0 Pre-Conditions

 * The Electronic Address Consumer or Consumer system has identified need of an electronic address for a provider
 * The Electronic Address Consumer or Consumer system has sufficient information on the provider to be searched for
 * The Electronic Address Consumer system has been configured to determine a Provider Directory that may receive a query
 * Provider Directories are available and can respond to queries

7.0 Post Conditions

 * The Electronic Address Consumer’s system has the electronic address and security information required in support of health information exchange.

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** ||
 * Provider Information Directory || Provider Directory || The Provider Information Directory performs the function of processing Provider Information Query to search for providers based on a search criteria received from the Electronic Address Consumer and returns the electronic address, security information, and attributes about the providers returned. ||
 * Electronic Address Consumer || Electronic Address Consumer System || The Electronic Address Consumer actor initiates a Provider Information Query request to the Provider Directory actor indicating search criteria in the request and receives the electronic address, security information and attributes about the providers returned. ||

9.0 Use Case Diagram
The following diagram depicts the query for destination electronic address defined in this use case. **Figure 1: Use Case Diagram**

**Figure 2: Context Diagram**

10.0 Scenario
This Use Case contains one scenario. In the scenario, the Electronic Address Consumer queries to identify the electronic address and security information for a desired destination.

10.1 User Story
The Electronic Address Consumer does not have the electronic address or security information of the desired destination. The consumer initiates a Provider Directory query to locate the electronic address and security information for the desired destination. The Electronic Address Consumer enters basic identifying information, for example name, address, phone number, about the desired destination and sends the inquiry to the Provider Directory. The Provider Directory returns a list of Provider Directory records and their electronic addresses that match the criteria along with demographic information to allow the Electronic Address Consumer to unambiguously determine the correct destination (individual and/or organization) and their electronic address and security information for the appropriate destination’s system. The Electronic Address Consumer selects the desired destination of the message.

The Provider Directory returns the electronic address for the destination(s) and conditionally returns any required security information.

a) If the Provider Directory does not return the required security information for Direct users, the balance of the user story is the same as the User Story of the Query for Digital Certificate Use Case for Direct Project. b) If the Provider Directory does return the security information (at a minimum the digital certificate for the recipient), the provider system verifies that the certificate of the recipient has been issued by the trusted authority.

The provider system is able to use this information for health information exchange.

10.2 Triggers
The consumer has the authority to communicate to the desired destination for the purposes of sharing healthcare information ||  || **Table 3: Triggers**
 * **Triggering Event** || **Specific Pre-Conditions** || **Description** ||
 * A consumer determines that electronic communication with a desired destination is necessary, most often to send or request information || The consumer has the means to communicate 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 || Electronic Address Consumer || Provider Query Sender || Sends provider information query || Provider selection parameters || Query for provider information ||
 * 2 || Provider Information Directory || Provider Query Responder || Sends candidate provider list || Provider query information || Candidate providers matching query parameters ||

**10.3.2 Alternate Flow**
In some instances, the Provider Directory will not return the digital certificate in response to the query. In the case for Direct users, a second query will be sent to retrieve the digital certificate(s). The requirements for this query are defined in the Query for Digital Certificate Use Case for Direct Project and the resulting flow is described as below:

**Table 5: Alternate 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 6: Information Exchange Requirements**
 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Electronic Address Consumer System || Send || Query for provider information || Receives || Provider Information Directory System ||
 * Provider Information Directory System || Send || Providers matching query || Receives || Electronic Address Consumer System ||

**Table 7: System Requirements**
 * 10.4.2 System Requirements**
 * **System** || **System Requirement** ||
 * Electronic Address Consumer System || Form a query for provider information ||
 * Provider Information Directory System || Identify providers that match query parameters ||
 * Electronic Address Consumer System || Receives list of providers that match query parameters along with their electronic addresses and security information (optional) ||

**10.5 Sequence Diagram**


**Figure 4: Sequence Diagram**

=11.0 Issues and Potential Risks= There are a number of issues that will impact the implementation of this use case
 * The limited experience in the healthcare industry with the creation and use of Provider Directories for the intended uses described in this use case.
 * The lack of experience in the implementation of the existing standards
 * There are several potential standards that exist but may not be at a mature state
 * The need to standardize data and messaging for Provider Directories designed for other uses of Provider Directories
 * Ensuring that there are consistent and reliable mechanisms for establishing and updating Provider Directories
 * The inability to determine the correct electronic address for the desired destination because of incompleteness or federation
 * The absence of a mechanism, such as accreditation, to ensure that provider information directories are reliable and have appropriate controls and security
 * Providers are not broadly experienced in acquiring and using provider information from Provider Directories
 * Concerns that providers may have about sharing their information
 * Security risks posed by sharing electronic addresses and security information
 * Capability of provider system to use and manage electronic addresses and security information
 * Potential for misidentification of a desired destination and the inappropriate sharing of information
 * Potential lack of vendor support for the identified solution
 * Potential lack of convergence of HHS or the participants

=12.0 Dataset Considerations=

12.1 Message Content Requirements
The following table lists the expected content of a Provider Directory query message. This must support the following query capabilities.


 * Individual**: A person who is licensed or certified to provide healthcare services

Standard Code Sets for Provider Type and Specialty (example: Healthcare Provider Taxonomy Code Set) For recipient name under Direct Address, this depends on the data model and will be addressed during harmonization phase. || Standard Code Set for Organization type and Specialty || **Table 8: Dataset Considerations for Query Messages**
 * Organization**: A legal entity or part of a legal entity engaged in healthcare related services
 * **Section Description** || **Data Elements (Required if available and applicable to support use case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Individual || * Unique Reference for Individual
 * First Name
 * Middle Name
 * Last Name
 * Prefix
 * Suffix
 * Provider Type
 * Specialty
 * Gender
 * Address (City, State, Country, etc.)
 * Telephone Number
 * NPI
 * Direct address (email address, certificate, recipient name) || For names, suggest support for soundex, partial string, and wild card
 * Organization || * Unique Reference for Organization
 * Name
 * Service Address (City, State, Country, etc.)
 * Organization Type
 * Telephone Number
 * Specialty
 * NPI
 * Direct address (email address, certificate, recipient name) || For name and address suggest support for partial string
 * Individual-Organization Relationship || * Telephone Number
 * Direct address (email address, certificate, recipient name) ||  ||
 * Provider Directory || * Unique Reference for Provider Directory
 * Provider Directory Name || These data elements are not intended to specify a technical solution. They are intended to indicate that the solution must provide a means for a query to be directed to a specific provider directory. ||

The following table lists the expected content of a Provider Directory return messages. This must support the following response to query capabilities.

Prefix should be limited to medical professional degrees such as Sister, Honorable The usage for Email could be for Direct Project || For Organization type from ISO lists Suggest to return record (row) for each organization (with reference to parent) that fills the search criteria. For where individual is included in search, returned organization should be constrained to those organization entries with which the individual has a relationship || Return of this information assumes that the query included information from the Individual Section or a Unique Reference for the individual || These data elements are not intended to specify a technical solution. They are intended to indicate that the solution must provide a means for a response must have a means to indicate the provider directory that is the source of the response || A new unique electronic service should be created for each electronic address in which the data elements differ. Digital Certificate may include the ID of the Certificate, the URL to obtain the certificate, a certificate status, and/or the actual digital certificate || **Table 9: Dataset Considerations for Return Messages**
 * **Section Description** || **Data Elements (Required if available and applicable to support use case but not inclusive of any underlying standards )** || **Additional Notes** ||
 * Individual || * Unique Reference for Individual
 * First Name
 * Last Name
 * Middle Name
 * Prefix
 * Suffix
 * Provider Type
 * Specialty
 * Gender
 * Status
 * Practice Organization
 * NPI
 * Professional Degree
 * Professional Degree Year
 * Certifications
 * State License (State, Issuing Authority, Type, Number)
 * Telephone (Number, Usage)
 * Email (Email, Usage)Digital Certificate (Certificate, Usage) || Return of this information assumes that the query included information from the Individual Section or a Unique Reference for the individual
 * Organization || * Unique Reference for Organization
 * Electronic Service(s) information
 * Status
 * Legal Name
 * DBA Name(s)
 * Alias/Descriptive Name(s)
 * Service Address (City, State, Country, etc.)
 * Organization Type
 * Certifications
 * NPI
 * Telephone (Number, Usage)
 * Email (Email, Usage)
 * Direct address (email address, certificate, recipient name) for Organization || For name and address, suggest support for partial string
 * Individual – Organization Relationship || * Status
 * Practice Organization
 * Direct address (email address, certificate, recipient name) for Individual-Organization
 * Telephone (Number, Usage)
 * Email (Email, Usage) || Information unique to relationship between Individual Provider and Organization service location
 * Provider Directory || * Unique Reference for Provider Directory
 * Provider Directory Name || Unique reference to the Provider Directory from which a set of the data elements are returned
 * Electronic Service Information || * Unique Reference for Electronic Service
 * Electronic Address that includes:
 * Service Type
 * Message Type
 * Payload Type
 * Security Artifacts (including digital certificates) as required for the Messaging Type || An electronic service is a new unique endpoint

**Appendix A: Related Use Cases**
The Use Cases included in this section may be related to the Query for Destination Electronic Address Use Case.
 * IHE Healthcare Provider Directory (HPD) Profile Provider Information Query Transaction Use Cases
 * IHE Healthcare Provider Directory (HPD) Profile Provider Information Feed Transaction
 * HIT Policy Committee Information Exchange Workgroup Entity Level and Individual Level Provider Directory Use CasesHL7/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
 * REST (Representational State Transfer): A transport standard and software architecture style for distributed hypermedia systems such as the World Wide Web.
 * SOAP (Simple Object Access Protocol): This is a specification that enables exchanging of structured information in web services implementation.
 * 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.


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


 * Electronic Address:** A string which identifies the transport protocol and end point address for communicating electronically with a recipient. A recipient may be a person, organization or other entity that has designated the electronic address as the point at which it will receive electronic messages. Examples of an electronic address are an email address (Direct via SMTP) or URL (SOAP / XDR). Communication with an electronic address may require a digital certificate.


 * Electronic Address Consumer:** An individual or organization on the sending side that may have some basic destination attributes and needs to query for the electronic address and security information.


 * Electronic Address Consumer System**: The electronic system used by a provider or entity during the exchange of health data and to query for digital certificates.


 * Organization**: A legal entity or part of a legal entity engaged in healthcare related services


 * Provider**: An individual on the sending or receiving side that may have an electronic 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)


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

Appendix D: References

 * Query for Digital Certificate Use Case
 * IHE Healthcare Provider Directory Profile