The business requirements suggested by the HIT Policy Committee's work (the table below) require federated query/response transactions to a single, nationwide enterprise level provider directory, specifically
1) Support directed exchanges (send/receive as well as query/retrieve)
2) Provide basic “discoverability” of entity – including demographic information
3) Provide basic “discoverability” of exchange services (e.g., CCD, HL7 2.xx)
4) Provide basic “discoverability” of entity’s security credentials
When we presented the currently available standards - DSML for the schema, LDAP/ISO for the query vocabulary, REST/SOAP for the transport, and LDAP for the query language, the response from the HIT Standards Committee was that the combination of these standards as specified in the IHE HPD profile was largely untested in production.
Our conclusion was to revisit the business requirements with the HIT Policy Committee with the hope that we could devise a workflow enabling existing, mature standards, such as DNS, to be used for provider directories.
The presentation by the Privacy and Security Workgroup included this summary of how the existing NwHIN exchanges – Direct and Exchange – provide the required services.
One possible avenue for moving forward might be to build upon the Direct Project’s work to enable the Domain Name Service (DNS) to be used as the federated service for discovering entities and their security credentials. I recently learned about an idea that Paul Egerman has suggested to the ONC: the possibility of creating a top-level domain for the health industry. Putting those two ideas together,
here is a strawman that would move us forward.
1. The ELPD should be a single, national data structure that is accessible by EHR systems. Accessibility needs to include the capability to have a local cache.
2. A national ELPD could be achieved through the use of a top-level domain for the health industry (e.g., .HEALTH), instead of GOV, EDU, COM, MIL, ORG, and NET to designate entities participating in healthcare information exchange.
With a .HEALTH top-level domain there could be a defined set of registrars who are authorized to issue .HEALTH domain names. The benefits of doing this include:
Financial - The business model for registrars is already established, while there is no business model for other approaches being explored.
Leverages Existing Software Capabilities - The software for registering entities and making updates for domain names is well established. The use of DNS is well-known and can easily handle a national entity directory. DNS (along with "WhoIs") can be used by EHR systems.
Security - We could restrict query of the .HEALTH domain to other members of the .HEALTH domain, reducing its vulnerability to denial of service attacks and spamming.
3. The ELPD would embrace the Direct Project's implementation guide for storing digital certificates in, and retrieving digital certificates from, DNS.
As for the HIT Policy Committee’s request for standards supporting the discovery of demographic information and exchange capabilities, that functionality could be achieved using a decentralized approach. For example, the Standards Committee could specify that each organization needs to have a Uniform Resource Identifier (URI) where they list additional information about their organization, including their health information exchange send and receive capabilities (e.g. http://www.bidmc.HEALTH/services). Such an approach would be easy to maintain and would be extensible.
Thus, rather than try to invent new standards, processes, and business models, let's leverage the basic standards of the internet -a top-level domain, DNS, and URIs to create the Directory Services we need to enable Health Information Exchange.
As a next step, the Privacy and Security Workgroup will consider the possibilities of this strawman.
Based on the guiding principles for the HIT Standards Committee articulated in the first meetings of the committee - keep it simple, do not let perfection be the enemy of the good, design for the little guy, leverage the internet, and keep the burden/cost of implementation low, I'm convinced the notion of using a top-level domain, existing DNS standards and URIs to support health information exchange directories is worthy of serious consideration.