After reading Health 2.0: Take a Lesson From the Web Peter Basch asked me “exactly what a Provider Health Internet looks like – [and what are] the implications of using it vs. a RHIO / NHIN?” The question has special piquancy because users of EHRs will need to show certain kinds of interoperability to meet anticipated meaningful use requirements in 2011. This includes sending patient summaries from one provider to another, as for care transitions; reporting information to registries; and getting structured lab results into EHRs.
In theory, HIEs or RHIOs provide a basis for interoperability among EHRs and between EHRs and other data sources or users. They provide several important functions.
- They create the technical framework to enable Internet-based connectivity
- They create the social capital necessary to create trust among the participants in the HIE
- They operate the governance to maintain the trust
- They operate a service that correlates the IDs of patients even though the various edge systems use different ID numbers.
- Having correlated IDs, HIEs implement a consent model such as opt-in or opt-out giving consumers control over whether their data is searchable. Some offer a more fine-grained consent model.
- Usually they provide the analysis to create mappings between proprietary codes and standard codes such as LOINC; and then provide the software transformation to make the mappings work.
- Usually they provide a means for storing clinical information that is distinct from the IT system that is the actual source of the data. This may be a centralized data base or it may be a fleet of proxy servers, one per data source.
- They provide support to both the operators of the EHRs and the data sources or recipients (such as labs).
By itself the idea of a regional HIE doesn’t cover some very important edge cases including multi-regional entities that don’t want to have individual business or technical relationships with dozens of HIEs, patients who regularly see providers in multiple regions and the statistically rare case of needing to access information about a patient from a distance location.
The NHIN has been the conceptual approach to gluing together HIEs. It includes the notion that multi-regional providers such as Kaiser or the VHA would connect with HIEs as if the provider were another HIE. The architecture includes technical support for an approach to transitive organizational trust and correlating patient identity across HIEs despite the lack of a national patient or consumer ID. The project was called the “Nationwide Health Information Network” rather than the “National Health Information Network” to emphasize that it was intended to support interconnection as opposed to constructing a singuler, national network.
(Begin soapbox rant.)
It is my personal opinion that the NHIN work has been dissed excessively. Its concepts are in use in production now. They are used to connect the Social Security Administration to MedVirginia which is the HIE connecting to many providers. For applicants for disability in those states where even a single report is found through the NHIN the time for determination by more than 40 percent. The substantial policy challenges necessary to connect a government provider (such as the VHA or DoD) to a private provider are nearly solved and some transfer between those agencies and Kaiser is contemplated soon. The NHIN CONNECT Gateway is an open source project that implements the inter-HIE connection protocols. CONNECT has a robust community. The California eHealth Collaborative was used CONNECT to conjoin five HIEs in California for demonstration purposes. This was accomplished in a matter of a few weeks. Three HIEs downloaded the open source software and two modified their own software to follow the putatively undocumented and hard to implement protocols.
(End soapbox rant.)
Criticisms of the current NHIN approach are that the protocols are poorly documented and the complexity of dealing with cross HIE patient identification and security are complex for small vendors and self-developers to implement. Many feel that the protocols are too big a technological bite to push onto industry in a single gulp. In their view this ignores a fundamental discovery of the Internet, that a simple approach that meets a few requirements catches on way more quickly than a complex approach that has looked farther down the path of evolving requirements.
These issues are valid to varying extents, but the larger concern is that establishing the HIEs and building trust with and across HIEs is a time-consuming process. It is still more art than science, and therefore unpredictable. Without ubiquitous HIEs and the trust model the issue of whether the NHIN protocols could be simpler, better or better documented is moot. The fact is there cannot be a enough work done in 2011 to provide ubiquitous support for EHR users meeting meaningful use criteria. In my own opinion the situation could be a lot better by 2015 but ubiquity would still be a much longer reach.
So, at this point the definition of the NHIN is “under reexamination” and there have been rumor of fulfilling its goal with (and presumably diverting NHIN funds for) the “health Internet”. To the extent it has been described the Health Internet has a strong emphasis on consumer involvement. The health Internet sounds a lot like a PHR or at least the PHRs that are designed to form the basis of an application ecosystem such as the work of Dossia, Google and Microsoft.
The main point of “Health 2.0: Take a Lesson From the Web” was just to point out that PHRs don’t cut it as the sole means for provider-provider communications. I didn’t mean to imply that the “provider Internet” would be a separate entity, just that the proposed “Health Internet” doesn’t meet provider to provider needs.
The real question is this: If the existing NHIN+HIE concept will take too long and if PHRs or a consumer-based Health Internet are not a reasonable alternative, what’s left?
I and others are hoping that we can isolate some important functions of the HIEs + the NHIN and address the simplest use cases with fairly simple, point-to-point communications over the Internet.
This approach relies on an assumption: that the business trust between organizations that use EHRs and the organizations that receive data from them or send it to them can be addressed without the full formal architecture of transitive organizational trust that complicates the HIE+NHIN approach.
Organizations that exchange data would use the postulated simple Internet mechanism to exchange information with other organizations which they had independently determined to trust. They could send information through the Internet using about the same ground rules they use to fax information now. Instead of typing a fax number into one of those infernal machines they might type a URL into their EHR. The actual transaction would contain structured data to the extent needed and that structure would be standards-based. One way this could work is that the exchanges could occur between healthcare organizations that know each other and have physically exchanged the Internet addresses and digital certificates to support authentication and encryption. Another model might be an Internet service that provides that information on-line.
The next question might be what are the limits of health information exchange based on independently-established trust? There is a substantial difference in the policies that various care delivery organizations apply in deciding when to fax information about a patient to someone that calls and claims to be an entity with a legitimate reason to request information about a patient, or when someone faxes a putatively signed consent form. What is different about sending the information by a secure Internet connection rather than the fax?
One clear difference would be if the request for information came in directly to the IT system of a healthcare provider and the response went out automatically. Indeed, supporting “query-response” interactions has significantly upped the need for explicit trust models in and among HIEs. A first cut at how to approach simplified information exchange is to take automated query-response out of the picture. This limited model, which could go along way towards meeting meaningful user requirements for interoperability could be just for pushing information.
There is some work to do to see if this notion is useful and doable at a scale that is appropriate to help with meaningful use.
I am trying to give these ideas a voice in the blogosphere, but the ideas are not exclusively my own The notion has been bubbling in many pots over the summer and many folks are discussing variations of it. I am particularly grateful to David McCallie of Cerner and Virginia Riehl, an independent consultant with whom I have enjoyed many hours developing these thoughts.
Read Complimentary Relevant Research
100 Data and Analytics Predictions Through 2021
Over the next few years, data and analytics programs will become even more mission-critical throughout the business and across industries....
View Relevant Webinars
Digital Business Architecture: From Strategy to Guiding Execution
New techniques have emerged to help CIOs and EA practitioners leverage business architecture to guide investment and execution decisions,...
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.