Learning From Our Interoperability Failures

flying cadeuciiCurrently, when healthcare data moves in this country it does it using fax machines and patient sneaker-nets. Automated digital interoperability is still in its earliest stages, mostly it has a history of being actively resisted by both the EHR vendors and large healthcare providers. We, as an industry, should be doing better, and our failure to do so is felt everyday by patients across the country.

The ONC-defined difference between EHRs and EMRs is that EHRs are interoperable. Yet, as I have said before, we have spent almost a billions of dollars and generally gotten EMRs instead of EHRs.

Comments were due Apr 3 for the ONC Interoperability Roadmap for 2015-2020. This was specifically separated out from the overall ONC Health IT Strategic Plan for which comments have closed.

Both of these plans ignore the lessons in execution from the previous strategic plan for health IT from ONC. The current Interoperability Roadmap mentions the “NwHIN” (Nationwide Health Information Network) for instance, and only covers what it accomplished, which are mostly policy successes like the DURSA (Data Use and Reciprocal Support Agreement). NwHIN was supposed to be a network of networks that connected every provider in the country… why hasn’t that happened?

ONC has forgotten what the actual ambition was in 2010. It was not to create cool policy documents. The plan 5 years ago was to have the “interoperability problem” solved in 5 years. The plan 5 years before that was probably to solve the problem in 5 years. Apparently, our policy makers look at interoperability and say “wow this is a big problem, we need at least 5 years to solve it”. Without any sense of ironic awareness that this is what they have been saying for decades, even before Kolodner was the ONC.

The silliness of this is that we need further planning on this at all. We don’t need a plan for interoperability, we need interoperability. We could just republish the old plan and it would work just as well if ONC executes and just as poorly if ONC does not execute. At what point do we start looking carefully at what has happened before and start saying “Why is this process not working better?” and “What can we do truly differently?”

The alternative to this deep and uncomfortable introspection is self delusion. Our industry has a very bad habit of rebranding rather than rethinking interoperability. Remember Community Health Information Networks (CHINs)? Those were “not sustainable”. So rather than find something that was “sustainable” we rebranded the same basic concepts as Regional Health Information Networks. But they typically failed too. Now the correct term for an unsustainable local exchange networks is a Health Information Exchange. See the problem here? No significant change in thinking or approach, just a rebranding, and the ushering in of a new generation of technology vendors. Swap out the old “bad” technology and protocols, and bring in the new. IHE is bad, we need SOAP. SOAP is bad, we need REST. The Direct Project is bad, we need Argonaut. CCR is bad we need CDA. CDA is bad we need FHIR. See the pattern here? We need to completely step back and ask uncomfortable questions about our overall approach to interoperability.

Patients, nurses and doctors in this country need more than a cursory examination of the issues behind health information exchange. We need to carefully compare and contrast what was said then, and what is being said now. We need to understand why this part of the system continues to fail.

Lets take a brief look at the “in summary our approach is” from the previous plan:

The Nationwide Health Information Network has already demonstrated sharing of patient-health information between the VA, DoD, SSA, and many private sector partners. Extending the Nationwide Health Information Network specifications with additional building blocks such as the Direct specifications will include protocols for provider patient secure messaging, which is a major step towards patient-centered care.

At the time, ONC was backing two protocols, the Direct Project and IHE (as implemented by CONNECT). Here you can see a video of the two protocols being promoted at the 2010 OSCON conference by the two project leaders at the time. Here I am doing essentially the same thing the next year, in 2011. I completely bought into that strategic plan.

Why didn’t those two projects solve the problems over the course of the next 5 years?

From the old strategic document again:

Nationally, the government is developing a standards and interoperability framework (S&I framework) to harmonize existing standards and improve sharing of standards across different organizations and federal agencies, making it easier to broaden interoperability through shared standards for data and services.

The S&I framework, and later Meaningful Use, would deeply endorse the CDA standard as a “harmonized” approach. Now the current roadmap has this to say about CDA:

Though much of the industry has implemented C-CDA as it is required in 2014 CEHRT and subsequently Meaningful Use stage 2, there is significant variability in the implementation of the standard.

Seeing the pattern again? CDA was supposed to be the harmonized standard, and now the industry needs a harmonized standard. This occurs in the “Moving Forward and Critical Actions” section immediately after a discussion of how the industry borked CDA:

HL7’s Fast Healthcare Interoperability Resources (FHIR) effort is one effort that is emerging and exploring ways to accommodate new methods of exchanging information.

During the Health IT ONC annual meeting (Feb 2015), the current ONC specifically held out hope that the Argonaut program was going to really address interoperability issues. (For those that do not know, Argonaut is a project to implement OAuth for a REST API based on SMART that delivers healthcare data using the FHIR standard).

So everybody now loves REST and FHIR.

And they are not wrong, FHIR embraces JSON rather than just XML and REST/OAuth has proven itself as the best way to do moder API implementations.

But FHIR and REST will not solve the problem of interoperability. They are just todays shiny toys that will end up having exactly the same problems that Direct and IHE currently face. The hard parts of interoperability have never been about technology, it has always been about forcing and industry that has substantial disincentives to do interoperability to do it anyway.

The problem is this: The Meaningful Use (MU) incentives have no realistic protocols in place for EHR vendors and EHR users to prove that they are generating compliant versions of the current standards. There are no real meaty required tests for compliance to existing standards. There are no meaty requirements to actually exchange data.

You need to maintain a three pronged approach to interoperability testing in order to ensure that interoperability is going to work.

  1. Require extensive pass-fail interoperability testing for MU3 EHR certification, using simulated exchange scenarios. Ensure that those tests still work in the wild during attestation.

  2. Require that MU attestation force end users of EHR systems to detail who they exchange data with and how, allow them to subjectively rate their EHR vendors support of their interoperability efforts during attestation.

  3. Develop a “tattle tell” interoperability endpoint that can accept and automatically de-identify forwarded CDA/FHIR/whatever files that are the result of real health information exchange, so that “standards bad actors” can be detected in the wild.

Here are the steps required to do extensive pass-fail interoperability testing for MU3 EHR certification, using simulated exchange scenarios.:

  1. Create 1000 different correctly formed CDA and FHIR files.

  2. Design 100 different “treatments” that can be broadly applied to all 1000 profiles. (i.e. “add content showing the patient just had a new HIV test come back positive”, or “add content showing the patient has a new blood pressure reading of whatever/whatever”

  3. Create 100,000 “end states” that represent how the 1000 start states should be transformed by the 100 “treatments”.

  4. In order to achieve MU3 certification, an EHR vendor must demonstrate the ingestion of all 1000 start states encoded in CDA, and properly model all 100 “treatments” on each profile, generating 100,000 different end states, which are then exported to CDA and run through a testing engine that accepts one and only one CCA configuration per test.

  5. During attestation, EHR users will have to inject 6 simulated patient records, and perform 6 “treatments” properly and then send those 6 to the MU testing portal. Those simulated patients should both delivered and retrieved under all approved HIE transfer protocols, including Direct, IHE and Argonaut.

Then, during attestation, the MU portal should leverage the latest version of the DocGraph referral dataset to determine which 10 NPIs the submitting provider has the most shared patients with, who also have MU certified EHRs. Then simply ask who among those 10 providers they are exchanging data with, and how.

Attestors should also be asked to rate their vendors support of their interoperability efforts (from 1-6…provide no option for “neutral”, cause we all know that is a cop-out and if it is available every attestor will choose it).

If attestors are not communicating with the providers they share patients with, then they should not be given Meaningful Use dollars.

If vendors are constantly resisting their customers efforts to exchange data their certifications should be revoked.

You cannot police whether interoperability is functioning without measuring it in the real world, and attestation is your primary tool for measuring what is happening in the market.

This proposal will be unpopular with providers, who will lament that their MU dollars are now dependent on the willingness of others to exchange data with them. But if HHS wants to ensure that its billions of dollars in EHR investment are resulting in Health Information Exchange, it needs to ensure that the exchange is actually working.

It is critical that neither vendors nor users be in a position to “either/or” their way out of real interoperability. Providers choose not to allow patients to communicate with them using Direct, because they could “either/or” give them access to patient data using a portal. All of the HL7 standards have more ‘ors’ than a viking warship.

But “options” is only part of the problem. Even when options have been narrowed and standards are explicit, “in the wild” variation is still common and problematic. As a result, the third component of a “real” interoperability system is a “tattle tell system”. ONC should create a mechanism for providers to upload actual CDA/FHIR/Whatever files that they have gotten from their partners. They should be able to tag those files as being sent from specific EHR systems and version numbers, as well as tagging them with which healthcare providers sent them.

The tattle tale system should immediately de-identify the relevant files, and then pass them through the standards compliance guantlet. ONC has already invested in solid technology to test compliance, and these should be leveraged here. You should publish report cards showing standards compliance by both provider and EHR vendor basis. There should be a “self-testing mode” that is not publicly reported that will allow EHR vendors and providers to test their own file generation process, without fear of repercussion. Vendors and providers should be able to rely on the deidentification logic of this testing service to ensure that they are able to test accurately without sharing PHI unnecessarily.

Part of me feels silly spelling out the details of how these systems should work at this level of detail. Indeed, my specific technical recommendations might need to be tweaked in order to work. But I am providing the detail to illustrate that what I am suggesting is technically possible. But technically possible and bureaucratically viable are two different things.

If ONC wants to support six transport protocols and five data standards, then ALL of those need to supported by ALL end users of EHR systems. If that seems unrealistic (hint.. it is unrealistic) then ONC needs to make tough decisions regarding supported protocols. Because of the walled garden problem (which I have commented on before and will again), Argonaut cannot be a lone transport protocol. You need to support both freedom to move data at patient preference (Direct) and support ease of development against EHRs as a platform (Argonaut). I see no reason why ONC needs to support more than two interoperability standards.

Make no mistake, ONC can either be popular or it can solve the interoperability problem. If you want to be popular, continue to use the word “or” a lot. There are “ors” all over the current implementation standards. In fact, I would like to give the award for “Captain Understatement” to whoever wrote the phrase there is significant variability in the implementation of the standard. That is some priceless phrasing…

Yet within the document, I take most issue with this paragraph:

In some cases the implementation guides provide sufficient clarity, specific implementation instructions and reduce the potential for implementation variability to a minimum. In other cases, further work is necessary among SDOs [Standards Development Organizations] to further refine implementation guidance as well as to develop best practices to improve implementation consistency among health IT developers.

It is clear that no amount of implementation guides are going to get this problem solved. Our industry ignores good implementation guides right along with bad implementation guides. As long as the EHR industry has the opportunity to flub interoperability, it will. EHR vendors and healthcare providers both have a huge motivation to not have interoperability work; as interoperability makes them both vendors and providers fireable. Patients who can move healthcare records around can switch doctors. Doctors who can move healthcare records around can switch EHR vendors. The Health IT industry needs to have comprehensive pass/fail testing that both the EHR vendors and their users have to conform to. ONC needs an ACID test for every interoperability standard it promotes. Then it needs to find a way to inject that ACID test into the real world as much as possible


We do not need more standards or better standards. We need ONC to arbitrarily enforce one single interpretation of the current standards. If ONC wants to change standards, go crazy with that, but in the end we need one single interpretation of those new standards.


If you want to make something change in the real world, it must be measured in the real world. The EPA spends lots of energy getting water samples in the real world. ONC needs to find ways to do the same thing. If the EPA changes its standards for what water quality should be in lakes and rivers, it then enforces those standards by measuring in the wild to ensure that they are properly enforced. The previous philosophy of the ONC has been so hands-off regarding testing that it would be equivalent to the EPA saying “we are going to totally change the standards for water quality in the United States, but we are going to halt our measuring program”. Obviously that would not work, and that is precisely why previous standards have not worked.


Some people feel that ONC does not have a congressional mandate to do the kind of  interoperability testing that I am suggesting. But it does. ONC has a congressional mandate to get interoperability to work, and the only way to get interoperability to work is to do extensive, real-world testing. That is the only reasonable interpretation of this mandate.


Congress has also made it clear that it wants more from ONC in this area. I think it’s time to recognize that it’s not Congress that is the problem here (I am pretty shocked that I just wrote that…).


Don’t spend any more money on EMRs and data silos. Our country’s patients were promised interoperability, and they so desperately need it.

-Fred Trotter


As per always, I prefer to end my comments with a good joke (as usually stolen from reddit), which is my contribution towards those who have the dull task of reading all the comments:


A minister dies and is waiting in line at the Pearly Gates. Ahead of him is a guy who’s dressed in sunglasses, a loud shirt, leather jacket, and jeans.

Saint Peter addresses this guy, “Who are you, so that I may know whether or not to admit you to the Kingdom of Heaven?”

The guy replies, “I’m Joe Cohen, taxi-driver, of New York City.”

Saint Peter consults his list. He smiles and says to the taxi-driver, “Take this silken robe and golden staff and enter the Kingdom of Heaven.” The taxi-driver goes into Heaven with his robe and staff, and it’s the minister’s turn.

He stands erect and booms out, “I am Joseph Snow, pastor of Saint Mary’s for the last forty-three years.”

Saint Peter consults his list. He says to the minister, “Take this cotton robe and wooden staff and enter the Kingdom of Heaven.”

“Just a minute,” says the minister. “That man was a taxi-driver and he gets a silken robe and golden staff. How can this be?”

“Up here, we work by results,” says Saint Peter. “While you preached, people slept; while he drove, people prayed.”


14 replies »

  1. I have read your entire blog which is about Learning From Our Interoperability Failures.It is quite useful to gain immerse knowledge about Interoperability.In the mean time i also read about FHIR: A New Path Towards Healthcare Interoperability which is same as your blog that gives detailed information about FHIR.Thanks for sharing it

  2. There’s another piece you didn’t touch on here. The data MUST be available where it’s needed at 2am. HIPAA EXPLICITLY allowed this, specifying for the first time that NO specific consent is required to share PHI needed for treatment. HIPAA specifies that providers who need PHI to treat have a RIGHT to that data.
    The HL7 standards/ONC group REFUSED to understand this, and insisted on imposing a much higher, illegal standard for PHI, requiring offices holding data to specifically release (‘push’) the data instead of making it available when and where needed (‘pull’.) The group trapped themselves in a Through-the-Looking-Glass fantasy world where Covered Entities (CEs) needed to ‘prove their trustworthiness’ in some undefined way (counter to the law) to receive PHI. Since this was too difficult, they made it impossible to get the information when and where needed.

    To put it simply, they didn’t understand the use case or the HIPAA law, or thought they had a divine right to change HIPAA to what they thought it ought to be rather than what the medical community had laboriously pounded out with CMS.
    HIPAA SPECIFICALLY allows the data to be warehoused by the EHR company, or an HIE (pick your alphabet soup), because they’re acting as the sending providers’ agent, and would be a BA or CE themselves. The receiving CE is responsible for how they use the data, NOT the originating office.

  3. Amen Fred. We’ll still be in the same place 100 years from now unless we require vendors to interchange as a requirement for staying in business.

  4. Fred,

    I very much agree with your statement of the problem. I am less clear that your solution would actually break the problem.

    As I see it the problem is due to the political winds. Every political season the winds change. Each new administration is required to declare the former administration a failure, and re-invent anew. This is why they never continue anything for more than 5 years (actually 4, 6, or 8 years which looks like 5).

    This is what you get when you let politics drive the industry. What should happen is for Medical Professional societies to take responsibility. This is what has happened in Radiology , where interoperability is so much a success that we simply don’t think about it anymore. And they are using OLD standards. It is not the age of the standard that matters, it is the commitment by those with Money to spend. This history can be found in the founding of IHE by RSNA.

    One must follow the money… In the case of Radiology, it is a part of the commitment to interoperability. Outside Radiology it is used to line politicians and consultants pockets.

    Yes I work for a vendor. From within that vendor, I assure you we would far prefer interoperability would be like Radiology. This is why we have tried to duplicate Radiology success through expansion of IHE. The problem is that the medical professional societies are not doing what RSNA did for Radiology.

    ONC refuses to focus on a small number of high-value use-cases. Rather choosing to ‘let a thousand flowers bloom”. This is the root cause. No focus, and actually disincentive to focus.

    I like FHIR, have profiled it within IHE as an interface to XDS/XCA; but I do agree with you that this is simply the latest shiny thing. It will not solve the problem.


  5. Opacity = Margin. In a “perfectly economically efficient” private market, margin is zero.

    Moreover, healthcare data, being way more complex and voluminous than other types of consumer data, are much more expensive to originate and manage. Why we should concomitantly expect the originators of those data to simply freely provide them to competitors seems more than just a bit naive.

    Even under HIPAA, notwithstanding that you nominally “own” your PHI (the right of access, more precisely), the curating providers can charge you “reasonable costs” for obtaining them (see 45 CFR 164.524).

    As to the techie stuff: “HL7® FHIR®”


    We’ll see. At least we’ll continue to have a thriving Standards Promulgation Industry — one, IMO, content to gloss over inconvenient yet relevant data mapping minutia and paying lip service to the IEEE definition of “interoperability.”

  6. Wow, a lugubrious outlook.

    It appears as if providers are going to have to leave it up to the vendors. If the networks are not being used and the standards are being hassled forever, the providers only have one place to send their data ( that is destined for someone else) and that is back to their own vendor. Therefore, the vendors must have data portals and be data nodes themselves and must work together to create their own network. They have to step up and manage the entire interoperability problem.

    Put these requirements in the EHR sales contracts and charge them if it doesn’t work or if it is not secure or speedy and facile. The providers should not have to worry about this. It is essentially a mailing system.

  7. At least now there is something patients can do to help their own cause. I recently entered the following information on my iPhone 6 through its Health App: my drug list, allergies, diseases and conditions, surgical procedures I’ve had over the last 20 years including month, year and hospital, whether or not I’m an organ donor, emergency contacts, including two of my doctors, and where my living will is located. If I wind up incapacitated in the ER, it should give the docs there a good amount to go on while additional records can probably be faxed if needed. Full records interoperability would be great if we ever get it but entering some basic records in health apps is a heck of a lot better than nothing.

    I understand that there are also smart cards that some people carry that have information they choose to include embedded on a magnetic strip or electronic chip. Of course, like the health app data, it needs to be kept reasonably up to date.

  8. Wow Fred is that the longest healthcare blog post ever are you thinking of applying for a government job soon? 😉

    The problem has little to do with policy or technology it is just a business case challenge. (easily solved when government as payer vs tech lead or policy maker steps in)

    Not sure where you live but in Washington State we are already exchanging records between every single ER in the State and between most clinics as well. Are they a limited data set to start? Sure – does it work – Yes

    How did this happen? The State Governor told the hospitals she was going to cut their funding if they didn’t find a way to reduce readmissions and frequent flyers and with that as the business case the Hospital Association stepped in held a couple of seminars and a private HIE implemented a solution in less than 6 months at ALL of the hospitals in the state.

    Phase 1 Adopt statewide electronic health information system to coordinate care plans of patients with high needs (five or more visits to ER per year) with emergency rooms, payers, mental health clinics and primary care providers.

    Results The rate of emergency department visits declined by 9.9%.
    The rate of “frequent visitors” (five or more visits annually) dropped by 10.7%.
    The rate of visits resulting in a scheduled drug prescription fell by 24%.
    The rate of visits with a low-acuity (less serious) diagnosis decreased by 14.2%.
    A savings of $33.6 million in Medicaid fee-for-service emergency care costs.


    The system includes every ER in the State (99) and although targeted at one population it tracks everyone

  9. Healthcare does not play by the rules of the sharing economy, it reflects the realities of the U.S. economy. It’s unfair to single out healthcare.

    Indeed, the tech industry, an early adopter of transparency, doesn’t like transparency so much when it comes to its own house. Ask Apple to share customer data. Ask Google to open its data warehouse.

    This is a fundamental cultural shift we’re asking for.


    Health plans
    Pharma companies
    Academic researchers
    Government agencies
    Ordinary consumers

    All have their own reasons for not wanting to grant access to data

    We need an information amendment for the Constitution.

  10. So what are the incentives that you mention that are changing the dynamics for sharing this data? Details, please.

  11. I hate to dither, but lots of industries share data in the interests of consumers. Airlines share flight information to ensure that customers crossing airlines can get where they need to go. Banks share information with every electronic transfer of information.

    The credit system as a whole is a way for businesses to communicate data about consumers. The communication in the credit system, no matter how flawed, helps both consumers and businesses.

    But in healthcare even healthcare providers who team together to deliver care to the same patient populations have failed to become interoperable. If healthcare providers were consistently sharing data with their collaborators, but refusing the share data with their competitors, then you might have a point… but historically no one shares data with anyone. Only the very largest systems attempt integration and even then it is typically only internal to those organizations.

    Your point that not sharing data is a rational business decision is well-taken, however. Those incentives are changing now, and as a result there is light at the end of the tunnel.


  12. This is not a technical or policy problem. It is simply a business problem.

    What industry do you know where organizations are asked to share their sources of revenue (i.e customers) with each other? You are asking healthcare organizations to share their sources of revenue (i.e. customers\patients) with each other. You are asking vendors to make data portable so their customers (i.e. healthcare organizations) can more easily switch to another vendor.

    Banks don’t share their customer data with other banks. Airlines do not share their customer data with other airlines. Retail stores do not share their customer data with other retailers.

  13. This refrain was recited and prayed for by the great Brailer and company. After $ billions made by the vendors, what do we have? Zilch, zero, meaningful ruse, and a more wealth obstructionisr HIM$$.