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.
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.
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 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.)
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.
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).
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.
Comments or opinions expressed on this blog are those of the individual contributors only, and do not necessarily represent the views of Gartner, Inc. or its management. Readers may copy and redistribute blog postings on other blogs, or otherwise for private, non-commercial or journalistic purposes, with attribution to Gartner. This content may not be used for any other purposes in any other formats or media. The content on this blog is provided on an "as-is" basis. Gartner shall not be liable for any damages whatsoever arising out of the content or use of this blog.