Directory services are an important component of HIE and a key component of many HIE architectures. Many types of directory services are useful, including lookup of

  • Users or individuals (sometimes called “White Pages”)
  • Organizations and organization locations (sometimes called “Yellow Pages”)
  • Data services offered by organizations or service providers
  • Semantics or terminology, along with translation services if appropriate (we won’t deal with this topic here)

The national discussion is focused primarily on entity-level provider directories (i.e., directories about organizations) and individual-level provider directories (i.e., directories about individuals) that might be made available to facilitate interoperability.

Potential Sources of Directory Data

Many State-level HIE projects consider directory services to be one of the elements of common infrastructure that are required to promote HIE within (and even between) states, even if statewide infrastructure goes little beyond that. Requirements for Meaningful Use especially encourage the deployment of provider directories to facilitate those transactions. There are no ready-made directories, however, of potential state health information exchange participants, though there are a number of potential candidate sources of directory information. In some cases these are entity-level directories, in some cases individual, and in some cases both:

  • Licensure databases: Many states maintain on-line – and sometimes even searchable – databases of licensure for clinicians and other professions.
  • Medicaid directories: Most state Medicaid offices maintain directories of established Medicaid providers and their organizations.
  • Public Health Information Network (PHIN) Health Alert Network (HAN) contacts: Most states have a Public Health Information Network HAN which is established to send out rapid alerts of public health emergencies to clinicians, first responders, and others. The HAN typically has an online directory of participant information, including affiliations and methods of communication (e-mail, FAX, telephone, SMS).
  • Public health registry user databases: Some public health agencies have information systems that are targeted to providers broadly in the community, like Immunization Information Systems (IIS). An established system of users and credentials could be leveraged for more general-purpose directory service.
  • REC registration: Regional Extension Centers registration databases provide a potential source of accurate directory data.
  • National Provider Identifier (NPI): This unique registration for providers and hospitals was instituted by HIPAA. Entries reside in the National Plan and Provider Enumeration System (NPPES) which is searchable through an interactive web interface. An extract of this system could certainly provide a useful basis for a statewide directory.
  • National Level Repository (NLR) and state-level Registration/Attestation Systems: These systems are being established by CMS and State Medicaid agencies to support the incentive program’s administration and payment disbursement. As states determine how meaningful use attestation and compliance will be accomplished, new sources of directory information may emerge as providers have a strong incentive to keep these up-to-date to ensure that incentive payments are sent to the right place.
  • Electronic death registries: Not really a source of directory information, but this might yield a more accurate directory by ensuring deceased providers are in fact removed from the active registry.

Directory Technologies

There are a number of technologies already in use which may offer some opportunities to standardize directory services, though they do not all provide equivalent functionality and no clear winner has yet emerged:

  • Universal Discovery and Description Interface (UDDI): Used by the Integrating the Healthcare Enterprise (IHE) Cross-enterprise Document Sharing (XDS) and the Nationwide Health Information Network (NwHIN), UDDI provides a way for a provider of web services to describe the exact services that the organization offers. Potential users of those services can query via UDDI and obtain this information. But its use is limited to SOAP-based Web Services, and UDDI does not provide a general purpose directory of either people or organizations. Support for UDDI appears to be waning – it is no longer under active development and will likely fade from use.
  • Domain Name System (DNS): DNS is the low-level directory service used by the Internet to translate a host name (like into an IP address (like Its primary purpose was to allow alphanumeric, easier to remember host names to be used instead of hard to remember numbers, though those numbers are what is required by the various software protocols underlying the Internet to move data between locations. Several special types of DNS records also exist, like those used to create host synonyms and those to store digital certificates (or CERTS) associated with a hostname, its organizations and even its people. Though a robust directory of participants is out of scope for the Direct project, Direct is using DNS CERT records to store digital certificate for participants to enable encryption and identity management. It is also worth noting that tools to maintain DNS CERT records (you need to actually deposit the certificate into a DNS database) are not very well developed or easy to use.
  • Lightweight Directory Access Protocol (LDAP): The LDAP protocol represents an Internet standard for querying directory information of almost any type. The problem, though, is that each use of LDAP defines its own schema, or database structure, for the directory itself, including what data elements to include and how they are used. So, LDAP is fairly simple to use, and quite flexible, but agreement has to be reached between organizations on the directory’s exact structure and contents. It is worth noting that the IHE IT Infrastructure Healthcare Provider Directory (HPD) Technical Framework Supplement Trial Implementation (August 2010) relies on LDAP for its transactions, though it is not clear whether this profile is yet in active use. There is an effort within the S&I Framework Provider Directory Project to define this data set as it relates to HPD. And many off-the-shelf e-mail clients allow the user to look up addresses in an externally-defined LDAP directory.

Planning Considerations

“Push” transactions may have stronger requirements for both entity-level and individual-level directories, as one needs to not only be certain as to the destination of a transaction, but also the security of that transaction needs to be assured. The Direct Project excluded directory services explicitly from its scope of activities. It is expected that Health Information Service Providers (HISPs) will increasingly become important points of intermediation for HIE transactions as they function as secure “surrogates” for participants whose technical infrastructure cannot support authenticated, encrypted information exchange. Though there is no “white pages” directory for insecure e-mail today, use of e-mail is fairly ubiquitous, though not without its problems (misdirected messages, SPAM).

A set of directory services to support push transactions securely (with certificate authority and encryption) would certainly assist the growing HIE community. HIE participants would be able to query a Service Registry to identify what services are available for a particular trading partner. Once the service (and its corresponding destination) is selected, an Entity Registry might then enable the secure “push” of data through its certificate and authentication services. Note that Direct Project reference implementations do not yet incorporate service or entity directory lookup. While many states are focusing on entity-level directory services first, individual-level directory services may be more important to enable “push” transactions in a practical way.

“Pull” transactions, or query through an HIE, allow for a participant to provide patient identifying information and ask the HIE to discover and provide any information it might know about the patient. Directory service are less relevant for this function as the HIE products themselves know where data might be located and how to retrieve it. More so, the participant requesting information does not know the specific source of the information so directory services are of limited use.

One key challenge to directory services is maintenance and upkeep if the directory information. It is important that entries are up-to-date, but it is also important that only authorized persons enter or change information both for entities and for individuals. In addition, changes to entries that now interfere with the potential synchronization with information sources also need to be considered (for instance, if a directory is fed by a licensure database, what happens if a directory update is requested or done that now makes an entry out of sync with the underlying licensure database entry?).