A great visual for healthcare IT interoperability

Bart Collet posted a comment to Dr. Rowley’s recent guest article on interoperability – he said the following diagram is a great way to show how inflexible many healthcare IT systems are these days:

Share photos on twitter with Twitpic

I love the picture, thanks Bart.

Too many of our healthcare IT systems look like the device on the bottom – to make matters worse, many vendors don’t even have the three button Bart has in his photo.

Newsletter Sign Up


13 thoughts on “A great visual for healthcare IT interoperability

  1. Actually, I would argue that the top image, with dozens of different connectors, is more emblematic of the problems with the HIT industry in its current state. It represents a ridiculously high number of ways to plug into the system, via hundreds of different ‘standards’. This is the primary cause of years of integration headaches and exception management–all for a provider to simply gain access to a patient’s lab results or other data.

    The bottom view is much closer to what an easy-to-integrate-with system should look like: power, and ideally only two ports: one for incoming, secure, authorized requests to retrieve data and one for well-formed inbound data. And these connectors should be 100% built against web standards that have already been proven in the tech marketplace for at least a decade. This is the future that Dr. Rowley alludes to with his USB analogy–not the other way around.

  2. Good point, Matthew, but I disagree. Our healthcare system is complex because of our payment system (decentralized) and because the people being asked to do data entry (the physicians) do not have their incentives aligned with the people who benefit most from the data entry (payers, government, healthcare IT vendors, etc).

    Because of the inherent business problems created by the complexity in the system as a whole there are many solutions that don’t work well together regardless of how much we try to standardize; and, that’s not something that’s just going to change by simple standardization or just creating simpler solutions. Standardization is achieved when all the participants using the standards have their incentives aligned and benefit together.

    Today the incentives for patients, physicians, payers, government, and other players are not aligned and that’s why having the kind of device shown in the top diagram is helpful: because we’re not going to get standardization anytime soon. Since we won’t have standardization and we still want a pratical and useful system we’ll want as many plugpoints and open/flexible ports as possible.

  3. Shanid,
    In my business we focus on clinical interoperability, allowing applications to exchange relevant clinical information about a patient. When considering the development of a clinical system analogous to the top image it is hard not to cringe. I think that interoperating is a noble and appropriate way to design a system. Super compatibility, as depicted in the top image, introduces a significant amount of complexity. This complexity creates a non-trivial amount of effort, especially if you want to properly validate all of the permutations that can result. Not adequately exercising the permutations creates risk. The more adept systems become in leveraging clinical information, the more the risk is increased.
    Unfortunately, I think the same business incentives that limit the adoption of standards drive against the notion of super-compatibility. The view is not worth the climb.

    That being said, I also agree with your sentiment on standards, they are evolving but convergence is not in the near term. But I would also argue that a super-compatibility approach could result in delaying the convergence of standards for the industry and even promote the spawning of additional connectors. This in turn would force the last generation of super-compatible system to mutate and add the latest mode of connecting, increasing the complexity again. And so on.

    In the short term I think an adapter model, like what you see today with regards to HL7 and the CCR, are a more justifiable, short term fixes to get systems talking. This allows systems that need to interoperate do so. This is also more realistic when you consider the time spans, cost and risk involved with reversioning healthcare software.

    Ultimately, as good standards emerge, technology and domain experts need to resist the ‘not invented here’ syndrome, adopt those standards and work together to evolve them as rapidly and efficiently as possible.

    That’s my two cents and probably more controversy than you expected to be generated on Bart’s picture.

    Thanks for the interesting blog.

  4. My question: The first model is sustainable? Which component is applicable? For the individual components (EHR, etc.) or integration Middleware? Thanks and congratulations for the interesting blog.

  5. The first figure represents a world without standards: complex and expensive. Many standards = no standard.
    The second figure is a world with few standards: systems simple and inexpensive.
    My question: The first model is sustainable? Which component is applicable? For the individual components (EHR, etc.) or integration Middleware? Thanks and congratulations for the interesting blog.

  6. I think perhaps folks aren’t really understanding the analogy of the picture (which is my fault for not explaining). Let me talk through what the first one shows:

    Pointers to A, B, and C refer to RCA standard jacks and S-Video. These are technologies that were invented in the 60’s, 70’s. 80’s which mean if you have a TV from that era it would still work with this device. Think about how many healthcare apps we have from decades ago — we need to get/set data in those systems. These could be CSV files or other structured text files.

    D points to DVI standard input — which comes from a computer, not TV. Imagine that in healthcare the DVI is HL7 3.0. DVI is the most recent video standard (just less than 10 years old).

    E, F, G point to VGA standards — which come from the 80’s and 90’s. This is like HL7 v2.x.

    J points to USB standard — this is a completely different standard than video and audio, it’s about data transfer.

    So, all the slots in the top picture are pure standards — just that the standards are for different purposes (but no better/worse).

    Our healthcare systems need to support all the standards since there can never be “one standard to rule them all.”

    Example: HL7 is a transactional standard for clinical data, X.12 is a transactional standard for financial and management data, CCR/CCD is temporal snapshot of an entire patient record. CDISC is used in transfer of clinical trials information, etc. The list goes on.

    Modern systems need to understand the various standards and why they are used and the implement them in their systems for open communications.

    Hope this helps explain why the top one is far more useful analogy in healthcare than the bottom one.

    I love this thread 🙂

  7. Great comments! Thank you for taking the time to write down your opinions.
    I see HIT as a sum of different applications and devices. These applications differ locally and organizationally. Depending on the situation applications A + K + X might suit you best, whereas G + K + W + X might be better for your neighbor. Point is that both combinations will result in the best possible healthcare in their particular setting.
    In all honesty: how many applications do you know talking fluently to different other apps and devices? How many applications prevent choosing the best possible combination because of the absence of interoperability?

  8. This is an interesting thread, but I believe it is skipping past a major consideration. Not a surprise, as this interop debate continues to do the same thing…and that’s data standardization.

    Everyone wants to get ‘the phones connected together’ but if one of us is speaking French, and the other Chinese, we have a problem.

    Enter semantic standards…LOINC, SNOMED-CT, ICD, etc.

    Focusing on the digital connections in most world’s is fine since everything is base-10. Or in the digital world, binary. But medicine is practiced in ‘base 26’ due to the text-based, narrative collection of data. If I chart ‘BPWR’ and send that over an HL7, or any other standardized interface to another system, the receiving system can capture that, and present it to the recipient. But does the recipient know what it means? [Blood Pressure Within Range]

    Absent that clarity, do they take a blood pressure, wasting time and cost?

    And the biggest challenge is that most EMRs (albeit not all) don’t normalize the data in any way. This is touched-upon in the reference to templates. But if the EMRs were designed properly, the UI would allow flexibility, but the Db would normalize the data. Once thats done, the world is our oyster for interoperability. This is being done in other coutnries, including the UK (started with Read Codes, now onto SNOMED-CT, et al), Netherlands, etc.

    Absent this, we are going to have an explosion of data moving around, none of which means anything to anyone.

    Focus on mobilizing the data in a meaningful way, not the bits and bites.

  9. I would have to agree Shahid, Some folks on here want Uniformity, which is great but it is just not how the world or our health system works. For all intents and purposes the machine on the top allows for many more uses and more connection options. More options is always better simply because the chance of you have the equipment needed to utilize the machine is more likely to be on hand. Also the hospital has a choice of which they would like to use, such as less expensive adapters or more expensive Higher quality adapters. I think the model with simply 3 jacks is sub standard. Not to mention if the utilizer wants to see his display on 2 separate monitors, or simply a computer monitor I imagine he is going to need the top device.

Leave a Reply to Chintan Patel Cancel reply