“You’ve got to be very careful if you don’t know where you’re going, because you might not get there.” – Yogi Berra

A few weeks ago, I described the differences between the concepts of interoperability and health information exchange, both important goals of ONC. In this week’s discussion, I want to dive a little deeper into the characteristics of interoperability and why I believe the solutions are not black and white, but rather a shade of gray.

Understanding what interoperability is (and what it is not) will help us chart a path to achieving nationwide health information exchange and interoperability.

Interoperability is Complicated

Although we tend to talk about health care interoperability in terms of absolutes (“system A doesn’t interoperate with system B”), in reality, interoperability is not as simple as that.

Part of interoperability is technical: it may be that I can exchange information, but the information is not computable – it’s a scanned image, a fax, or a PDF.

While this may not technically be an interoperable system (some call them “operable” systems), there is value for a provider to get data even if it is not interoperable.

It may prevent an allergic reaction, reduce duplicate tests or x-rays, or improve the quality of the care delivered. But this is a place to start, not a place to end.

Is Creating New Standards the Answer?

While it would seem easier, the reality is that in some cases, the exchanged data is computable, but system A uses a different standard (or non-standard) than system B. Health IT has been blessed (or some might say plagued) by a propensity to develop new and different standards.

Often, it seems easier in the short term to develop a new data standard than to do the hard work of agreeing on a single way of doing things.

However, rather than create new standards, we need to work together (as a community) to reach agreement on a common set of standards.

Is Creating a Common Set of Standards the Answer?

The challenge with reaching consensus (even with Meaningful Use (MU) standards) is that we often reach a common standard only if we include different “options” in how those standards are expressed.

This can (and will) create the situation in which two systems, both certified to a particular MU standard may NOT be able to interoperate.

• Certified sender A may have implemented the standard with option A. Certified receiver B may have implemented the standard with option B.
• So product B, can’t receive interoperable data from product A.

Highly Constrained Standards Are not the Answer Either

Of course one of the ways to reduce optional elements in standards is to develop very tightly-constrained standards. While this can reduce optionality in standards, it can actually cause more difficulty with implementation because these tightly constrained standards are intended to be used in very specific situations.

For all the variations in information exchange, you might need a different, separate standard for that exchange.

The end result is that you have a proliferation of highly-constrained standards that are more challenging to maintain and keep consistent with other standards than using a health information exchange standard that can be used in different situations based on different optional fields.

Creating the right balance between providing options and constraining choices is an art, not a science, and we will likely need both kinds of standards.

Developing Standards based on common context or workflow

Not all of interoperability is based on the syntax of the data. More sophisticated ways of creating interoperability require sharing a common meaning for data or a common context (or workflow) in which the data is collected or used.

Even if both systems use the same standard, they may use different vocabularies or value sets. Or the data may come at different times in the work process.

Each of these scenarios can affect the ability of two systems to use the information that has been exchanged.

For example, a diagnosis collected in the emergency room on admission is often very different from the diagnosis that is determined at the time of discharge. Pooling these two important (but different) diagnoses, without considering when the data was collected can lead to inaccurate analysis.

Health Care interoperability is not black or white; it’s a shade of gray

So interoperability is something that is not black or white, but exists in the shades of gray between “not able to exchange anything” to “comprehensive ubiquitous data fluidity.” Also, we aren’t going to get to there in one giant step.

Given that we are proceeding incrementally, DIRECT gives us the ability to exchange information. Standardized structures (like the consolidated CDA) help computers break information into re-usable chunks and incorporate them into the EHR.  Standardized vocabularies allow computers to “understand” the meaning of the data, and support clinical decision support and more intelligent use of the data.

Two Things to Keep in Mind to Support Meaningful Use Stage 2

These are great first steps, much of it captured in the standards to support Meaningful Use Stage 2.  But there are two things we must keep in mind:

1.     We will get some of it wrong.

• Certified products may not interoperate without human intervention.
• Optionality in standards, while helping us achieve consensus among different stakeholders, makes it harder for systems to interoperate easily.
• Through experience, we will learn what works and what doesn’t work.
• We will need to update, improve, and refine our standards, implementation guides, and testing strategies to get us closer and closer to interoperability.

2.     This means that interoperability is not a destination, but rather a journey: a process of continuous refinement and learning.

•  Interoperability is in the details, not the abstract, and it will be through implementation and refining the details that we learn about what we need to make interoperability a reality.
• In some cases, it will mean we need to create better testing harnesses that test sending data differently from receiving data.
• In other cases, we need to reduce optionality in the implementation guides or refine the use cases to which we apply those implementation guides.
• Or perhaps we will need new attributes or new structures in our standards to support our goals.
• It will be an ongoing, collaborative process.

Health IT Certification is Good Starting Point

But bear in mind, certification of health IT is not the end of interoperability, but a good starting point.

We will need to iteratively and incrementally develop better and better solutions.

It’s Similar to Installing an Operating System on your Own Computer

If you have ever installed an operating system, or a new software application, you know that after you install the operating system, you aren’t done. The next step is where you download and install new patches, software updates, and security. These patches are the result of experience in the initial build of the software and are an ongoing part of keeping your software working and up-to-date.

We may need to Adjust our Approach Over Time

We may need to think about Meaningful Use standards and implementation guides in the same way. Certification is the first step. And we will learn from the implementation and use of the standards in MU to get us closer and closer to the goal of more ubiquitous interoperability. We are committed to helping implementers use MU2 standards, and learning what works and what doesn’t so that we can improve what we do.  Over the coming months, we will be exploring ways that we can help implementers working to achieve meaningful use, and creating ways to have an ongoing conversation with implementers and standards organizations that share the goal of getting to better interoperability.

We would love your feedback to our iterative approach to health information exchange standards. Please share your thoughts below.

Next week: Ultra large-scale systems

Read other blogs by Dr. Fridsma on standards development and harmonization, coordination of federal and private efforts toward interoperability and health information exchange, and health IT innovations.