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.

http://blogs.gartner.com/wes_rishel/2009/11/22/on-ebay-the-fax-and-healthcare-interop/

” … 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.

To get specific … What PHI artifacts should we push? Answer = HL7 CDA release 2 documents. Level 1 CDA documents are easy to produce and consume.

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).

It is downloadable at: http://www.intersystems.com/mt_washington_vision.pdf

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.

Anyone else who things that Wes’ first cut makes sense, should definately review the Mt. Washington Vision.

At significant excerpt from the Executive Summary has been pasted below:

Key Features:

* Radical simplification of the prerequisites for interoperability

* Minimal involvement of government at any level

* Optimal involvement by the consumer (patient) constituency

* Market-driven approach to interoperability

* Interoperable content-driven, based on HL7’s Clinical Document Architecture (CDA) standard

Key Proposals:

* Information-based, rather than application-based, interoperability

* CMS create a progressive incentive structure for providers to produce progressively more useful electronic documents

* Patient-designated personal health record banks receive copies of electronic documents produced by providers

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.

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.

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.