Wes Rishel

A member of the Gartner Blog Network

Wes Rishel
VP Distinguished Analyst
12 years at Gartner
45 years IT industry

Wes Rishel is a vice president and distinguished analyst in Gartner's healthcare provider research practice. He covers electronic medical records, interoperability, health information exchanges and the underlying technologies of healthcare IT, including application integration and standards. Read Full Bio

Coverage Areas:

Simple Provider Directories for Simple Interop

by Wes Rishel  |  May 27, 2011  |  5 Comments

Last year I blogged intensively in support of a notion of “simple interop.” The blogs were instrumental in the formation of The Direct Project. Direct provides light-weight security for sending protected health information. The simplicity derives from relying on the fundamental infrastructure of the Internet for routing and security. A provider that is a direct user can send information to any other direct user if it knows the “direct address” of that user,  essentially an email-address. In a “simplicity first” approach, we chose not to fold a provider directory into the original product. Since most healthcare is local and most providers have ongoing business relationships with those who will receive the data, we expected that the overhead for learning a new email address and storing it in an address book or EHR table was no higher than keeping track of a fax number. We referred to this as “business-card” discovery of end-point addresses.

Real usage started about ten months after the project started and continues to grow. The next step is providing more widespread discovery of end-point addresses (a 411 service). The ONC S&I framework team has kicked off an intense effort to find a solution that could be included in an NPRM for Stage 2 of Meaningful Use. As with the original Direct project, the hope is to bust through previous expectations of how long something like that would take by “keeping it simple.” One of the complexities one hopes to avoid is creating a single national resource for looking up providers. While that is a valuable goal it is very complex and potentially expensive. One approach is to allow multiple sources (such as the states) to each offer a resource and develop a standards scheme to “confederate” them so that one wouldn’t have to query many different services each with its own user interface.

A Modest Proposal

I have been talking about this with David McCallie, my co-conspirator in the original push for simple interop. We have been looking for a truly fresh approach. We have a modest proposal here. Like the original simple interop approach, this proposal leverages the strengths of the infrastructure that is already in place in support of many non-healthcare usage. It provides for confederation and a uniform user interface in a novel way.

Requirements

On 24 May in A Strawman HIE Directory Solution John Halamka bloggedset forth the longer-term business requirements suggested by the work of the HIT Policy Committee. I am going to restate them in my own language in part to avoid the use of the word “discover.” This word seems to be adding confusion to the email thread that followed his publication.

  • Support directed exchanges (send/receive as well as query/retrieve)
  • Provide basic searching to find an organization  – including demographic information and Direct address. Demographic information may be part of the search criteria or may be returned when a target is found.
  • Having found an organization support retrieving information about exchange services (e.g., lab orders or results reports) and the standards required by the receiving system (e.g., mail, CCD, HL7 2.xx)
  • Having found an organization support retrieving its security information (that is, it’s digital certificate).

The last requirement is a bit controversial. I’ll get that below.

To these stated goals I would add:

  • Provide a reasonable assurance that the information that is found is not bogus.

The Proposal

Anyone can put up a Web page that describes his or her practice. (For reasons explained below small providers will probably rely on their HISP.)

The web page is free-form but contains mircroformat information that identifies various demographics, license level (self-declared), Direct Address and perhaps public cert. (Presumably ONC has the clout to get at least Google and Microsoft/Bing to agree on the Microformats.)

The web page must be protected by an Extended Validation Certificate such as is used for Webtrust. (The HISP can spread the cost of this over numerous small providers.)

The web page is freely available which makes it available to major search engines.

Organizational entities can put as many end-point entities as they want on the web page. (People, systems, common receiving queues, etc.) Or they can use one page per entity. There are no rules other than the use of a specific microformat.

Any person can use a search engine to discover a provider’s direct address and the provider’s public cert.

Presumably various folks would develop free-plugins for browsers that would indicate valid or invalid pages according to the extended validation certificates.

Given a definitive search key, such as a direct address, a HISP can discover the digital certification of a provider. It can validate the source of the information by the extended validation certificate. (It is questionable whether this is necessary, as will be discussed below.)

“Happy Paths”

Low-tech healthcare providers can use Web searches to discover the direct address of providers with reasonable assurance that the provider has managed to convince a HISP of its validity. Existing microformat-based integration with address books seems plausible.

HISPs may compete to improve the workflow for low-tech providers but there is no need for standardization in this area.

EHR-based healthcare providers have access to the low-tech approach, copying and pasting direct-addresses into the EHR equivalent of an address-book. If individual EHR vendors want to improve the workflows they have access to the APIs of the search engines and browsers to build whatever workflow they want. There is no need for standardization in this area as long as it is possible to paste a direct address into an EHR screen for a newly identified provider.

“Unhappy Paths”

In theory anyone can put up a web page with an email address and a digital cert. The extended validation certificate makes this an expensive proposition, but certainly within the budget of an organization that has set out to capture and sell protected health information. This concern can be addressed if there are requirements on the digital certificates that assure that they were issued by a trustworthy organization. The current HIT Standards Committee recommendation is that all certificates be traceable to a certificate authority that is cross-certified with the Federal PKI bridge. Under this or a similar approach, the HISP would refuse to forward Direct traffic to the bogus address because it would not have a qualifying certificate.

Spammers would have easy access to all direct addresses. As above, though, a spammer would only be able to use the direct address if it had its own qualifying digital certificate. Such a certificate could easily be revoked in the light of obvious spam.

Consumers would be confused finding email addresses to which they could not send mail. This can be solved by using a microformat that does not require that the direct address be rendered with the HTML page.

Advantages of This Approach

“Federation” is automatic through search engine technology.

Responsibility for creating listings lies with the provider or the provider’s HISP.

Modest investment and minimal development for HISPs. Virtually no investment required for EHR developers.

Does not require a a top-level domain which, IMHO, would take 1-2 years to get set up if there is serious credentialing associated with the issuance of TLD locations.

Except for some minor microformat work this relies entirely on existing technology that has been deployed at scale. In fact it relies on using the current deployments; there is no need to fund and deploy major new services.

Easily describable for the NPRM.

Easily testable for ATBs (assuming there is something to test).

Future Considerations

ONC could sponsor the development of a simple ontology of types of end points and microformats for describing them. Presumably it would want to address the service offered (e.g., receive lab orders) and perhaps some expression of the incoming standards supported. The actual information would be posted on the Web page by the practice or HISP at their own peril if they get it wrong. However, this is the future (i.e., beyond the NPRM for Stage 2 MU).

At that point standards and certification for EHRs would involve validating that the putative destination for a transaction is valid and can receive a transaction with the purpose and in a format that the EHR can send.

EHRs could also be required to offer compatible targets for inbound transactions.

Filling in Some Details

If the reader is not familiar with microformats please read the link. They are incredibly simple rules for formatting information with a web page so that its content can be understood by programs that accept the  HTML web page as data. Try looking up a few recipes that are referenced on the site or some addresses. You will realize how much your smart phones and search engines have been using this technique to make your Web life easier.

In any modern browser if you open up most bank Web sites (e.g., https://www.bankofamerica.com/) you will see a colored padlock that shows up in the browser’s address bar. This is a visible indicator of the extended value certification. While most people (including providers and their staff) don’t know what that means, it would be easy to make plug-ins available for common browser that provide highly visible flags of specious web pages. A specious web page would be one that included this microformat but wasn’t protected with an extended validation cert.

There is substantial controversy on whether the requirement to return a digital certificate is valid. The current Direct software gets this certificate through the Internet Domain Name System (DNS). The most widely used DNS software, the open source ‘bind’ package, supports the current Direct scheme. However the DNS product offered by Microsoft does not. The Hatfields and McCoys of the Direct world characterize Microsoft’s lack of support as being either an insurmountable stumbling block or of little consequence. The open source .NET implementation of Direct works fine because it relies on bind rather than the Microsoft DNS code. Whatever the conclusion of this issue, the main value of this approach is achieved whether digital certs are stashed in the microformat or retrieved through the DNS.

Amended 27 May 1230 EDT to correct a URL.

5 Comments »

Category: Healthcare Providers Interoperability     Tags: , , , , , , , ,

5 responses so far ↓

  • 1 Dixie Baker   May 27, 2011 at 11:25 am

    Wes,

    Good idea! This also would allow for a nice progression of richness in directory services and content, starting with a simple retrieval of IP address and certificate, to basic demographic information for a small practice, to a rich set of microformatted Web pages containing detailed information about an IDN’s individual providers, their licensures, health plan affiliations, specialties, and whether they’re currently accepting new patients.

    BTW, the Bank of American link should be http://www.bankofamerica.com.

    -Dixie

  • 2 John Moehrke   May 27, 2011 at 2:05 pm

    Wes,

    Very nice discovery and well described option. If I read this correctly you are recommending that the S&I Framework evaluate the use of the microformat which for contacts is hCard which is a way to display vCard formatted information on a web page. Where vCard is a format that holds X.500 directory schema information. This is a potentially good idea and not inconsistent with what I have been recommending. The main difference is that you propose this new flashy graphic format is the method of distribution on a web page (is there an app for that?). the microformat is just a distribution method, what are you distributing?

    Ultimately we need a directory schema that meets the use-case needs. This is where the IHE HPD project spent most of their time. Trying to determine what are the attributes and how would they be encoded. This schema is nothing more than an X.500 directory schema, which can absolutely be distributed by vCard encoded in hCard microformat. The nice part is that this is very much along the right trajectory.

    So what we have is the IHE HPD directory schema as a common schema and various distribution methods including: hCard, vCard, LDAP, DSML, etc.

    My concern, that simply needs some research, is to what level do off-the-shelf e-mail support this? It is all nice that there is an app for an iPhone to view the hCard information; but if it can’t get that hCard information into the e-mail system for use then it isn’t really a useable solution (this is the same problem I see with the DNS model).

    Note: The use of extended-validation-certificates would not be necessary on the web page. The digital certificate must it-self validate to a trusted root, so the trust is self-described. Digital Certificates do not need a trusted distribution method.

    Thanks for bringing this solution up, I have already recommended it to S&I Framework sprint team.

  • 3 Jan Root   May 31, 2011 at 6:10 pm

    Wes: I have never been able to find out exactly the goal of the “authoritative provider directory” being advocated by the feds. Is it to simply create a way to send messages (create a phone book so to speak) or are there other objectives? Your proposal appears to simply create a directory (an address) for every provider. In essence, a phone book. I like that approach. Technically, it is very doable.

    However, when I talk with folks from CMS they appear to be looking for an authoritative way to uniquely digitally identity each (warm body) provider, no matter where they work, multiple jobs, multiple offices, etc. etc. I believe their objective (in part) is fraud detection. They appear to want a ‘phone book’ where each warm body is guaranteed to have only ONE address. This was the goal of the NPI but that approach did not work. State Licenses also do not suffice.

    Do you see Direct fitting into that vision? It’s not hard to create a phone book if you don’t care where the doc works; if they moonlight at a ED in the neighboring state or work 5% of their time in a community health center; if they do locum tenans or any of the other ‘fill the crack’ activities that abound. With a simple phone book approach Individual docs will end up with many addresses (like most people have multiple email addresses) and that’s ok with what you’re proposing. .

    However, if fraud detection is the goal, then a simple phone book will not suffice. What’s the goal of the provider directory? Do you know the answer?

  • 4 Anand Shroff   June 1, 2011 at 3:30 pm

    Wes,

    From an HIE (and now HISP) vendor perspective, this is an elegant approach. It would allow incremental offerings that target the 80% case and then work in successive iterations for use cases that fall outside of the mainstream. The simplicity would allow us to build and deliver offerings as opposed to waiting for a perfect but complicated standard.

    -Anand

  • 5 Sandra Schafer   June 2, 2011 at 2:25 pm

    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
    Vice President Marketing and Business Development
    Holon Solution
    678-324-2039