PD+-+Query+for+Electronic+Service+Information+including+Electronic+Address++Use+Case




 * Thank you all for your participation! **
 * As of August 9th, 2011 the content of the //Query for Electronic Service Information including Electronic Address Use Case//, 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 ElectronicService Information including Electronic Address Use Case// click here**
 * To access the Microsoft Excel version of the //Query for ElectronicService Information including Electronic Address Use Case//** **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 ElectronicService Information including Electronic Address Use Case, please click the Consensus Page.**

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

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 Service Information (including electronic address and any required security information). The Electronic Service Information (including 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 Service Information to facilitate secure exchange of health information
 * 2) Core set of data elements to support queries to Provider Directories to retrieve Electronic Service Information including electronic addresses that can be adopted by EHR vendors, State HIEs, HISPs and other mediators of exchange
 * 3) Users of Direct Project implementations may use the Provider Directory to discover Direct Addresses and digital certificates

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

2.1 In Scope

 * Requirements and core data set for the messaging between the Electronic Service Information Consumer and the Provider Directory that are needed to support queries to Provider Directories to retrieve Electronic Service Information to support electronic health information exchange including sending one message to one recipient
 * Support for the development of certification criteria for EHR systems to enable Provider Directory queries

2.2 Out of Scope

 * Data elements and attributes, beyond what is necessary for discovering the desired destination’s correct Electronic Service Information
 * Validation of Electronic Service Information and how the consumer system selects the correct Electronic Service Information when multiple electronic addresses are returned
 * The manner in which the consumer uses the Electronic Service Information when received
 * The transport mechanism, between the Electronic Service Information 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 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 an Electronic Service Information from a Provider Directory.

The Provider Directories Initiative and the Query for Electronic Service Information including 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 Service Information including Electronic Address Use Case. These include:
 * Architecture: An architecture across national, state, regional, and local levels that will support the Provider Directories 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: Provider Directories will need to have the capability to comply with local, regional, and national policies regarding discoverability, privacy, and security.

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 Service Information associated with the ordering or “copy to” provider associated with at lab order. ||
 * Pharmacies || Pharmacies may need to discover the Electronic Service 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, Hospital Ambulatory Centers, and Provider Practices. These individuals or organizations may be the owners of Electronic Service 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 Electronic Service Information 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 Service Information) ||
 * 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 Service 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 Service 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 Service Information maintained in Provider Directories and may need to query Provider Directories to obtain the Electronic Service 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 Service Information. HIEs may utilize Provider Directories for the discovery of Electronic Service 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 Service Information. Health Associations may utilize third party Provider Directory for the discovery of Electronic Service 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 Service Information. Health Information Service Providers may utilize Provider Directories for the discovery of Electronic Service 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 Service Information and may need to query to obtain Electronic Service Information. Public Health Agency (State/Local) may create and maintain Provider Directories that can be queried for Electronic Service Information. ||

= 3.0 Challenge Statement = Health information exchange requires a mechanism to obtain Electronic Service Information (see glossary) 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 Service 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 Service Information is needed to facilitate secure exchange of health data. Currently, there is no widely available functionality that enables an Electronic Service Information Consumer to electronically obtain the Electronic Service Information. A scalable and standardized method to enable consumers to query and obtain Electronic Service Information will facilitate secure health information exchange. = = = 5.0 Use Case Assumptions =
 * Electronic Service Information Consumer systems can access the external Provider Directory
 * Electronic Service Information Consumer systems will be able to receive responses from Provider Directories
 * Electronic Service Information Consumer systems will be able to interact with users to resolve ambiguous selections
 * Electronic Service Information Consumer systems will be able to send information for Provider Directory searches
 * Electronic Service Information Consumer systems will be able to receive and use Electronic Service Information from Provider Directories
 * ‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍ Provider Directories have algorithms for identifying providers that match the query parameters
 * A relying party agreement specifying legal and governance policies, data access authorizations, data ownership, and the data use is in effect
 * All applicable Federal, State, & local regulations are supported

= 6.0 Pre-Conditions =
 * The Electronic Service Information Consumer or Consumer system has identified need of an Electronic Service Information for a destination
 * The Electronic Service Information Consumer or Consumer system has sufficient information on the destination to be searched for
 * The Electronic Service Information Consumer system has the ability 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 Service Information Consumer’s system has the Electronic Service 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 destinations based on a search criteria received from the Electronic Service Information Consumer and returns the Electronic Service Information about the destinations returned. ||
 * Electronic Service Information Consumer || Electronic Service Information Consumer System || The Electronic Service Information Consumer actor initiates a Provider Information Query request to the Provider Directory actor indicating search criteria in the request and receives the Electronic Service Information about the destinations returned. ||

= 9.0 Use Case Diagram = The following diagram depicts the query for desired destination's Electronic Service 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 the scenario, the Electronic Service Information Consumer queries to identify the Electronic Service Information for a desired destination.

10.1 User Story
The Electronic Service Information Consumer does not have the Electronic Service Information of the desired destination. The consumer initiates a Provider Directory query to locate the Electronic Service Information for the desired destination. The Electronic Service Information 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 Service Information that match the criteria along with demographic information to allow the Electronic Service Information Consumer to unambiguously determine the correct destination (individual and/or organization) and their Electronic Service Information for the appropriate destination’s electronic service. The Electronic Service Information Consumer selects the desired destination of the message.

The Provider Directory returns the Electronic Service Information for the destination(s) and conditionally returns digital certificate(s) for Direct Addresses.
 * 1) If the Provider Directory does not return the required digital certificate(s) for Direct Addresses, the balance of the user story is the same as the User Story of the Query for Digital Certificate Use Case for Direct Project.
 * 2) 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 destination 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 Service Information Consumer || Destination Query Sender || Sends destination information query || Destination selection parameters || Query for destination information ||
 * 2 || Provider Information Directory || Destination Query Responder || Sends candidate destination list || Destination query information || Candidate destinations 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 Project 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 Interchange Requirements**
 * **Initiating System** ||  || **Information Interchange Requirement Name** ||   || **Receiving System** ||
 * Electronic Service Information Consumer System || Send || Query for destination information using query data elements (Table 8) || Receives || Provider Information Directory System ||
 * Provider Information Directory System || Send || List of destination data elements (Table 9) matching query || Receives || Electronic Service Information Consumer System ||

10.4.2 System Requirements
**Table 7: System Requirements**
 * **System** || **System Requirement** ||
 * Electronic Service Information Consumer System || Form a query for destination information ||
 * Provider Information Directory System || Identify destinations that match query parameters ||
 * Electronic Service Information Consumer System || Receives list of destination dataelements(Table9) that match query parameters ||
 * Provider Information Directory System || Have controls to ensure that destination information is maintained in a secure manner and that information is shared only with authorized users ||
 * Provider Information Directory System || Can support a relying party agreement which may address accurate, timely, and complete data, legal and governance policies, data access authorizations and audit trails, data ownership, and data use ||
 * Provider Information Directory System || Will provide at least one secured and guaranteed delivery transport mechanism ||

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

= 11.0 Issues, Obstacles, and Potential Risks = There are a number of issues that will impact the implementation of this use case and that would need to be resolved:
 * 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 Service Information 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 Electronic Service Information from Provider Directories
 * Concerns that providers may have about sharing their information
 * Security risks posed by sharing Electronic Service Information
 * Capability of provider system to use and manage Electronic Service Information
 * Potential for misidentification of a desired destination and the inappropriate sharing of information
 * Potential for expired information if consumer system caches destination and electronic service information
 * Potential lack of vendor support for the identified solution
 * Potential lack of convergence of HHS or the participants
 * The lack of a transport mechanism, between the Electronic Service Information Consumer and the Electronic Service Information Provider, that will provide guaranteed delivery and error handling
 * The absence of mechanisms for queries or Exchanges between Provider Directories themselves could limit the availability of Electronic Service Information and limit the ability of a the query to return a response with the requested information

= 12.0 Dataset Considerations = The following are definitions for Individual and Organization.
 * **Individual**: A person who is licensed or certified to provide healthcare services
 * **Organization** : A legal entity or part of a legal entity engaged in healthcare related services

12.1 Message Content Requirements
The following table lists the data elements that are available within a Provider Directory query message. The optional/required nature of each data element is not specified in the use case and is deferred for discussion during harmonization. Each data element in the table is necessary for some aspect of the use case, but the table does not specify exactly how they may be used together or which mix of content makes sense and which mix does not. All data elements may contain multiple values unless otherwise stated.

Standard Code Sets for Provider Type and Specialty (example: Healthcare Provider Taxonomy Code Set) Electronic address can include Direct Address. Security Information can include digital certificate For recipient name under Electronic Address, this depends on the data model and will be addressed during harmonization phase. || Standard Code Set for Organization type and Specialty Electronic address can include Direct Address. Security Information can include digital certificate || Security Information can include digital certificate || **Table 8: Dataset Consideration for Query Messages**
 * **Section Description** || **Data Elements** || **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
 * Electronic address (electronic address, security information, 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
 * Electronic address (electronic address, security information, recipient name) || For name and address suggest support for partial string
 * Individual-Organization Relationship || * Telephone Number
 * Electronic address (electronic address, security information, recipient name) || Electronic address can include Direct Address.
 * 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 data elements that are available within a Provider Directory return message. The optional/required nature of each data element is not specified in the use case and is deferred for discussion during harmonization. All data elements may contain multiple values unless otherwise stated.

Prefix should be limited to medical professional degrees such as Sister, Honorable The usage for Email could be for Direct Project Status refers to active or inactive || For Organization type from ISO lists Suggest to return record (row) for each organization that fills the search criteria. For where an individual is requested by the query, returned organization should be constrained to those organization entries with which the individual has a relationship Status refers to active or inactive Policy Information may contain elements related to the presence or absence of a DURSA or other policy related agreements || Status refers to active or inactive || Return of this information assumes that the query included information from the Individual Section or a Unique Reference for the individual Status refers to active or inactive || 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 || **Table 9: Dataset Consideration for Return Messages** = = = Appendices =
 * **Section Description** || **Data Elements** || **Additional Notes** ||
 * Individual || * Unique Reference for Individual
 * First Name
 * Last Name
 * Middle Name
 * Prefix
 * Suffix
 * Provider Type
 * Specialty
 * Gender
 * Status
 * 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
 * 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)
 * Policy Information
 * Electronic Service Information (see definition below) for Organization || For name and address, suggest support for partial string
 * Organization – Organization Relationship || * Unique Reference for the "from" Organization
 * Unique Reference for the "to" Organization
 * Status
 * Description
 * Type of Relationship || Information unique to relationship between the "from" Organization and the "to" Organization
 * Individual – Organization Relationship || * Unique Reference for Individual
 * Unique Reference for Organization
 * Status
 * Type of Relationship
 * Electronic Service Information (see definition below) for Individual-Organization
 * Telephone (Number, Usage)
 * Email (Email, Usage) || Information unique to relationship between Individual Provider and Organization
 * 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 Information
 * Electronic Service Information includes:
 * Electronic Address (see definition in glossary (Appendix C)) || Electronic Service Information describes a unique endpoint ||

Appendix A: Related Use Cases
The Use Cases included in this section may be related to the Query for Electronic Service Information including 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 certificates 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 Service Information:**All information reasonably necessary to define an electronic destination’s ability to receive and consume a specific type of information (e.g. discharge summary, patient summary, laboratory report, query for patient/provider/healthcare data). The information should include the type of information (e.g. patient summaryor query) the destination’s Electronic Address (see definition above), the Messaging Framework supported (e.g. SMTP, HTTP/SOAP), Security information supported or required (e.g. digital certificate) and specific payload definitions (e.g. CCD C32 V2.5). In addition, this information may include labels which help identify the type of recipient (e.g. medical records department).


 * Electronic Service Information** **Consumer:** An individual or organization on the sending side that may have some basic destination attributes and needs to query for the Electronic Service Information.


 * Electronic Service Information 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 for Direct Project 
 * IHE Healthcare Provider Directory Profile <[]>
 * ONC State HIE Community of Practice Materials

Appendix E: Needs and Issues to be Addressed During Harmonization Phase

 * There may be a need to enhance search capabilities through a nickname, vanity cities, and first and middle name reversals
 * The inclusion of “recipient name” under Electronic Address as captured in the query message table of the Dataset Considerations (Section 12.0) depends on the data model
 * When determining query response information, organization-organization relationships must be considered and assumptions made
 * The “Type of relationship” data element for organization may not have a defined code set. During the harmonization phase, there is a need to determine the purpose of this code set and if a code set exists to meet this requirement. If no codeset is found, then the data element should be changed to a free form description of the relationship
 * The concept of zero, one, or many values for data elements captured under the Dataset Considerations (Section 12.0) would be discussed in the harmonization process