• Industry News
  • Law & Malpractice
  • Coding & Documentation
  • Practice Management
  • Finance
  • Technology
  • Patient Engagement & Communications
  • Billing & Collections
  • Staffing & Salary

Define EHR Interoperability First, Then Solve It

Article

An open letter to Congress about interoperability, including some questions it should ask the vendor community.

Dear House Subcommittee on Communications and Technology:

Some say that the purpose of EHR interoperability is to give practitioners (I dislike the word providers as it suggests the notion of interchangeable automatons) the ability to exchange patients' health information in a seamless way. Others say the purpose is to allow EHRs themselves to exchange data. There's a big difference between information and data. Exchanging information, person to person, can be remarkably straightforward whereas exchanging data between machines is endlessly difficult. In fact, because the number of medical data items is virtually infinite and each data item in isolation is virtually meaningless, it's a job that cannot neither be done "right" nor ever finished.

I believe that what is important is getting patient information from one physician to another. That involves a transfer of information, not raw data. If this is so, and I can prove that it is, hell will freeze over before data exchange ever helps patients on a large scale. Thank God for fax machines!

The experts have assured you and your colleagues in Congress that both the need for interoperability and its definition are self-evident. All that is necessary is to require it. If interoperability were that simple, we wouldn't still be talking about it; we would have it.

Interoperability is conceptually different from interfacing, a laborious, expensive but effective method of sending specific agreed messages from one system to another, triggered by specific events like admission, vaccine administrations, or booking an appointment. Interfacing requires that the "parts," the systems exchanging messages, be custom fitted to mate correctly. There is no interface that is so generic that it can just be "plugged in" or "swapped out."

Interoperability, on the other hand, is an outgrowth of the idea of interchangeable parts, introduced to Congress in 1801 by Eli Whitney. Without it, guns, cars, and practically everything would be bespoke, handmade, crafted one at a time, and different in some way. Parts don't have to do anything to be interchangeable, they simply must be identical. Thus, interoperability works whenever it is possible to develop precise, detailed specifications that define exactly what something is to be.

The flaw in interoperability as it is currently being approached is that is expected to do something while, as yet, there is no clear definition of what it is supposed to be and you can't attain something that you can't define.

It is reasonable to conclude that the first step toward significant progress on interoperability is to start asking questions and to keep asking them until the goals, objectives, definitions, and mechanisms have been clearly articulated. Only then will a system developer be able to tell how to implement the concept.

It's very reassuring that you (the committee members) are finally asking questions.

Here are some questions to consider:

• Of all things that information exchange might do, what is the single most important one, and for that one, what will be sent and who/what is expected to use it?

• What percentage of encounters will benefit from or require information exchange?

•What percentage of the need for information exchange cannot be satisfied by getting one practitioner's note to another practitioner so that they can read it?

• If that percentage is small, as I suspect it is, is the added cost and complexity of exchanging data justified?

•What is supposed to happen to information when it arrives?
      • Is a practitioner alerted so they can review it?
      • Is it in a format that they can read?
      • Is it filed in a database where it will wait to be discovered by someone?
      • If so, is it a separate database, or is the intent to merge the incoming information/data with data that was generated by the receiving site? Either approach has drawbacks.

• If merging is the intent, what are the implications for medical errors and medical liability?

• Who or what is supposed to act on the material arriving from external sources? Are the actions supposed to be automatic, or must the new material be assessed for relevance by a practitioner before it can trigger an action?

Any attempt to answer questions like these will quickly reveal how poorly defined the concept of interoperability is.

Related Videos
Three experts discuss eating disorders
Stephanie Queen gives expert advice
David Lareau gives expert advice
Dana Sterling gives expert advice
David Cohen gives expert advice
David Cohen gives expert advice
David Cohen gives expert advice
Dr. Reena Pande gives expert advice
Dr. Reena Pande gives expert advice
Dr. Reena Pande gives expert advice
© 2024 MJH Life Sciences

All rights reserved.