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 anassumption: thatthe 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.

Wes Rishel
VP Distinguished Analyst12 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

Thoughts on Simple Healthcare Interop for Easy Applications

Your blog has become a primary blog that we all read. We have an idea of what the Health Internet (or NHIN, or whatever) needs to look like when it is all done. We believe (and have believed for some time now) that it will end up like the Internet Service Provider model did where organizations (like us) get users (providers and patients) directly on the network – no RHIO necessary. This is what we have been building (www.recordnexus.com) and where our hearts have been the entire time – trying not to get side tracked on the current “flavor” of the NHIN (or whatever it will be called). However, this is the first time where we believe that our thoughts will not get us laughed out of the room. It is also the first time we have been “public” about what we have been building. The blogosphere seems to be ready for what we have to say now (because you and others seem to be saying it).

In a nutshell, we have believed for some time that data exchange shouldn’t be any more complicated than the current paper and fax process. Why not just digitize and facilitate that process? We believe that RHIOs create too much overhead and the legal latticework necessary in that model is too much for small organizations to handle. Also, the implementers of the RHIOs are too different in their approach and it takes data islands and just makes them bigger islands. Assuming that all RHIOs will build the necessary interoperability mechanisms to talk to all other RHIOs is just too big of an assumption.

That brings me to Ebay. Where is that model? Every other industry has it, but where is it in healthcare? Ebay doesn’t store my stuff. They just facilitate the transaction and allow me to connect with others that I would have never been able to connect with in the past. I mean, I “could” sell something to someone in France, but I would have to have called them up directly. I probably wouldn’t have reached that person even though they may have wanted my stuff. Relating that to healthcare, everyone seems to want to store records (and I understand why). The vendor system wants to store it. The providers want to store it. The HIEs and RHIOs want to store it. The PHRs want to store it. Fine. That isn’t going to change any time soon (though deep down in my heart, I like the Health Bank model… but that is not ready for prime time). Right now, the problem is “interoperability”. The problem is simply moving the records. Where is the organization that will facilitate the moving of the records? I guess that could be the RHIO or HIE. Or more specifically, it will be the organization that has coded to the NHIN or Google Health, or whatever. Fine. But what if a small town doctor just wants to communicate to another small town doctor and neither really want to join a RHIO that was created by the very vendors that made this problem in the first place (but according to their marketing material, they now solve it since there is much money to be had). These providers just want to be able to communicate with other providers with no more complexity than the “paper and fax” process. But having that process digital and streamlined is what needs to happen. They can swallow this level of complexity.

Yes, you could have every organization implement standards to talk to the NHIN and talk to Google Health and every other endpoint they need to talk to, but what if they don’t have an IT team to build those connections? There needs to be an organization (probably many) that will connect at the vendor level and “route” the information to all other endpoints and “translate” the information as well (CCR vs CCD vs proprietary). This is the reason why no one uses Google Health. I have an account, but I don’t use it because my providers didn’t build the connection to the Google Health API. What a waste. That is where we (and others hopefully too) come in. We code to the vendor systems and then open up their clients to the RecordNexus network (which is national, not regional). Once the information reaches RecordNexus, it can go to anywhere else RecordNexus can reach – including the NHIN (or Google Health, or other providers, or anywhere else the patient wants the record “routed”). The Patient is in control of where the record goes and can also move information to any PHR they choose. This is technically possible with the standards that are out there today (thank you, IHE). However, not all organizations and RHIOs are guaranteed to implement these standards regardless of the perceived (or real) technical or political constraints. It’s just not going to happen.

So, to recap.

1.) Paper and Fax process digitized. It doesn’t need to be any more complex than that.
2.) Patient in control of where record needs to go.
3.) Facilitate the transaction only. Don’t store the record. There are plenty of groups that will already do that and won’t change for some time.
4.) Health Internet Service providers (like http://www.recordnexus.com) that get end users (patients or providers) directly on the network and take care of the interoperability from the technical side. You shouldn’t have to be in a RHIO or talk directly to the NHIN to get on. Those can be endpoints too, but it shouldn’t be a requirement for health exchange.

Hopefully I haven’t stepped on anyone’s toes in this post. If I have, that certainly wasn’t the intent. I have nothing but respect for everyone that works on this very important problem.

Thank you to everyone. Let’s keep this health exchange dialog going.

Also, David McCallie, if you are reading this (I am guessing you will), we would love for you to have a conversation with Grady Cason at Cerner about what we are doing.

[…] This post was mentioned on Twitter by Shane Taylor and RecordNexus, Acculence. Acculence said: Finally! The conversation about the #NHIN is getting good in the #HIT world. Wes Rishel is right. http://bit.ly/8Avt7r […]

Thanks, Shane. You can’t “step on anyone’s toes” by posting well-supported comments to a blog. Discourse is “where it’s at.” If I thought the posting was simply an advertisement for a product I would delete it, but as long as it is primarily about the ideas a little pride of authorship certainly should be tolerated.

In the spirit of discourse, I’d like to comment on your reply. The push towards “RHIO-less” inter-provider communication is based on a simplifying assumptions that we can somehow get by without numerous important values currently added by the 57 or so operational HIEs can avoided, at least for a while. These are patient identity matching
transitive trust
patient clinical information lookup
provider-routing (other than what happens though the domain name service of the Internet)

I only argue that the limited point of view (particularly restricting data lookup) is good enough to get started if we limit the scope of interchange to providers that already trust one another or somehow determine to trust each other enough to satisfy an ad hoc request information. I would in no way say this is ideal. It is simply a way to jump start clinical information exchange.

You seem to argue that patient identity mapping, trust and consent issues can all be solved by patient involvement. I would agree but do not advocate patient involvement in the routine flow of data among licensed caregivers because I think it is too much sand in the gears.

I would also say that if an approach adds the overhead of getting the patient involved then it also also should offer the ability to hold information and provided it later to other sources as directed by the patient.

Wes, thank you for responding to my query and clarifying where your thinking is on the consumer health internet, the provider health internet, and HIEs / RHIOs.
In addition to your excellent points regarding what is doable in the near term and providing sufficient interconnectivity for meaningful use, I would like to introduce three additional dimensions to this debate: clinical imperative, duty, and information overload.
#1 – Clinical Imperative. I believe that what Wes describes as the simplest cases for interoperability are also the most common. Getting ordered labs / studies / consults to clinicians is someone most providers struggle with, and is far more complex and expensive than should be. Also, enabling a secure push connectivity is, unlike many HIE scenarios, completely noncontroversial.
#2 – Duty. Many providers are concerned about the duty implications of widespread interoperability (i.e., what do providers need to view / read / integrate into care, if that information is readily available?) While these concerns should be worked thru over time, they are nonexistent in the secure push model.
#3 – Information overload. While some people believe that what makes American healthcare suboptimal is the lack of information, I would challenge that notion, and posit that most providers would argue just the opposite. IMHO, we are inundated with information, and the fact that we as providers dont provide appropriate preventive and chronic care services, or care coordination has more to do with the dysfunctional payment model in the US than lack of information. I am very concerned that a dramatic increase in the amount of information mobilized might even have a paradoxical effect on providers (resulting in more errors).

You are definately onto something important and just in time with an approach to:

” … address the simplest use cases with fairly simple, point-to-point communications over the Internet.”

You wrote …

“A first cut at how to approach simplified information exchange is to take automated query-response out of the picture.”

It seems clear to me that your first cut to “pure push” was made with Ockham’s razor.

I beleive an ad hoc push network for PHI would be one of the first examples of high value-added healthcare interoperability solutions/services that would emerge via the operation of the free market, if we could jump start the creation of a critical mass of some form of electronic PHI artifact that could leverage existing Internet infrastructure and had virtually no barriers to creation and use regardless of the level of technical sophisitication of the producer and consumer of the imagined artifacts.

Picking up Ockham’s razor … I suggest that the way to enlarge the the first cut at how to approach simplified information exchange is to take semantic interoperability out of the picture initially.

Let’s focus on the human users of PHI first. We should be more than happy to improve on the healthcare industry’s Fax-based interoperabiliy status quo in the first cut, so long as the evolution of the environment we create leads to an increase in semantic interoperability over time.

Anyone with a browser can consume CDA documents. Several commercial transcription services can return documents that comply with the CDA standard

and Level 3 CDA documents can meet demanding standards for semantic interoperability while stil being useable by unsophiscated recepients.

The key is to jump start the creation of enough CDA documents to catalyze the growth of market-driven healthare information exchange. In its position as the healthcare market master (by virtue of the size of Medicare and Medicaid and possible future “public options”) CMS could incentivize the creation of a CDA document associated with every healthcare service for which reimbursement is sought.

In January of 2005 a group of volunteers worked out the details on such a HL7 CDA-based, market-driven approach to healthcare information exchange as a response to the ONCHIT’s RFI for a NHIN.

The group’s submission to ONCHIT was entitled the Mt. Washington Vision (named for the location of their collaborative retreat).

Five years ago … optimism was high about a large scale NHIN-RHIO, query/response solution … the Mt. Washington Visual was veiwed as contrarian. … now time is short and reality has set in hard … finally.

Executive Summary
This response subscribes to all of the rationale in the ONCHIT’s RFI for creating a NHIN, but suggests a radically
simplified set of pre-conditions for doing so. In summary, we suggest:

The creation of a critical mass of standard, persistent, application-independent, electronic documents based on Health Level Seven’s (HL7’s) Clinical Document Architecture (CDA) will catalyze the emergence of an array of interoperability mechanisms from which all the benefits that the RFI ascribes to a NHIN will be realized.
Creation of a specialized national network is not required and would be a tremendous drain on scarce resources and attempts to do so could inhibit innovation.
Widespread adoption of electronic medical records (EMR) systems by physician practices is not a pre-condition
and a universal mandate would create a significant entrance barrier to the benefits of interoperable information.
Increasing levels of encoding sophistication for these electronic documents will bring increasing benefit to different stakeholders, fostering incremental growth.

We propose that CMS, the de facto healthcare market master, catalyze the creation of a critical mass of standard,
persistent, application-independent, clinical documents through financial incentives to Medicare and Medicaid
participating providers. Production of HL7 CDA-compliant electronic documents summarizing the healthcare service should be differentially rewarded according to the level of machine-processible encoding. Eventually, baseline compliance will become a condition for reimbursement. This critical mass of interoperable clinical content
in the hands of providers will catalyze the emergence of an array of complementary resources, mechanisms, initiatives, commercial products and stakeholder collaborations that will dramatically increase the exchange of healthcare information within the existing frameworks of the HIPAA privacy and security regulations and thereby deliver the benefits that the RFI attributes to a NHIN.

You have great thoughts on this. I wanted to make sure you read some of the comments on Wes’s other posting. If you haven’t, I think you will be interested in the content. I am especially curious to see someone comment on Liam Davis-Mead’s comment.

About

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.