Tuesday, May 24, 2011

A Strawman HIE Directory Solution

At the May HIT Standards Committee, we discussed the standards which support entity-level (organization) provider directories (ELPDs) in healthcare information exchanges.

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.

5 comments:

  1. I see many problems with this approach, and it seems that this approach includes things that add no value.

    Here is my alternative. The HIT Standards committee has already recommended to HHS/ONC that there would be great value to Healthcare exchanges (both direct and discovery/retrieve) if the certificates used were issued off of a Certificate Authority that is bridged to the Federal PKI. I will assert that this would result in a small number of Certificate Authorities. This is the good part of your #2, but there is no need for a TLD or restrictions on query.

    What I would augment is #3, very simply with adding that these ELPD suppliers would also be compelled to publish using the LDAP model recommended by the HIT Standards P&S committee. Given that there is only a few of these, they surely could work out federation between them. You will note, I am not against the DNS model as an alternative, I am just against a model that is not supported by off-the-shelf solutions. The community must understand that the DNS model for certificate distribution is not working perfectly for the Direct Project, and has well known issues.

    I am very worried about your approach to discoverability through faith in internet search engines. Your proposal is not any different than what we have today (http://www.bidmc.org/ContactUs.aspx), and I can't find reliable provider contact information. A program surely couldn't find reliable provider contact information from this page. I fail to see how this can be called 'standards' based.

    ReplyDelete
  2. On the issue of finding information about health-care providers (organizations or personel) on the internet: I don't think anyone is suggesting screen scrapping human-readable contact pages. Such stuff would have to be published as structured, linked-data and, for that, tools and know-how are openly (and freely) available (more here: http://www.caregraf.org/datasets )

    Open data - about providers, organizations, procedures, conditions, is easy to publish for re-use, meaning there's no good reason to pass around CCDs laden with details about organizations and personel (or even medication types).

    While it is essential to safe guard the private, successful communication also needs re-usable publication of the public and open, and URIs, internet, RDF, linked-data makes that easy.

    As an aside: one thing I like about talk of URIs etc is that it represents a much needed move away from the "document-motif of exchange" everyone's been fixed on.

    ReplyDelete
  3. I have been advocating a TLD for healthcare for some time (http://ahier.blogspot.com/2009/12/top-level-domain-for-healthcare.html), but Wes seems to think it is a bad strategy (http://blogs.gartner.com/wes_rishel/2009/12/20/simple-interop-why-we-dont-seek-a-top-level-domain-name)

    I still think the idea is worth exploring...

    ReplyDelete
  4. Jon Postel said in the early 80s (when he was helping invent the DNS), "This is a naming system not a general directory assistance system."

    Do we have some people who think Postel was fundamentally wrong on this point?

    ReplyDelete
  5. I think we should investigate leveraging the work of The NPI Registry. The NPI Registry already includes all enumerated providers, enables search and there is no change to use it. The data base is updated daily. CMS contracted with Fox Systems, Inc. to serve as the NPI Enumerator and to develop the data base. It seems that we could work with CMS to add the IP Address and digital certificate to this data base that was a huge undertaking by CMS and Fox, thereby shortcutting our efforts.
    The data currently included is data that is disclosable under the Freedom of Information Act (FOIA) and all of it is disclosed to the public. The addition of a secure portion of the site may be required to accomplish the goals of our effort, however, it is a great starting point and would save time and money. NPI data is available in two forms:
    1.A query-only database, known as the NPI Registry.
    2.A downloadable file.
    Some of the key data elements currently included are:
    •NPI
    •Entity Type Code (1-Individual or 2-Organization)
    •Replacement NPI
    •Provider Name (First Name, Middle Name, Last Name, Prefix, Suffix, Credential(s), OR the Legal Business Name for Organizations)
    •Provider Other Name (First Name, Middle Name, Last Name, OR ‘Doing Business As’ Name, Former Legal Business Name, Other Name. for Organizations)
    •Provider Business Mailing Address (First line address, Second line address, City, State, Postal Code, and Country Code if outside U.S., Telephone Number, Fax Number)
    •Provider Business Location Address (First line address, Second line address, City, State, Postal Code, and Country Code if outside U.S., Telephone Number, Fax Number)
    •Healthcare Provider Taxonomy Code(s)
    •Other Provider Identifier(s)
    •Other Provider Identifier Type Code
    •Provider Enumeration Date
    •Last Update Date
    •NPI Deactivation Reason Code
    •NPI Deactivation Date
    •NPI Reactivation Date
    •Provider Gender Code
    •Provider License Number
    •Provider License Number State Code
    •Authorized Official Contact Information (First Name, Middle Name, Last Name, Title or Position, Telephone Number)
    https://nppes.cms.hhs.gov/NPPES/NPIRegistryHome.do
    Many of the issues that will need to be dealt with such as changes in location, status etc. are already considered in the NPI Registry.
    Thank you for your consideration of this idea.

    Sandra Schafer
    VP Marketing and Business Development
    Holon Solutions
    www.holonsolutions.com
    678-324-2039

    ReplyDelete