HIT consultant's matrix challenges interoperability

Some people protest with a picket sign, others with a bullhorn. For health information technology consultant Gary Dickinson, his mode of protest is the matrix.

Right now, he said, what the Office of the National Coordinator for Health Information Technology is calling interoperability shouldn't be called that, at least not yet. “We need to acknowledge as we go forward that the real benchmark (on interoperability) is still ahead of us,” he said.

Dickinson's matrix (PDF) walks the movement of various component parts of an EHR message through four basic steps to create, format, reformat and use a clinical message. His matrix highlights in colors green (good to go), yellow (proceed with caution) and red (unfit) for clinical use in a “typical interoperability scenario.”

The steps are: a clinician creates a record in an EHR, then, becoming the sender, the EHR converts the data into a message format to be exchanged and sends it on to its destination. On the receiving end, a clinician's EHR receives that message and translates it from the communications format to a data format used for storage by the receiving EHR, and then that message is retrieved by the receiving clinician and used for clinical care.

Dickinson's matrix has 26 transaction elements that are given green lights, but another 20 elements that are flagged with cautionary yellow and three that are marked red.

To be deemed eligible for use in the federally funded EHR incentive payment program under the American Recovery and Reinvestment Act of 2009, EHR systems have to be tested and certified under a program established by the ONC, and some interoperability issues are addressed, but not to Dickinson's full satisfaction.

In the certification process, Dickinson said, “we're not testing through that full path. We're not certifying that full path. We're only certifying that it can put data into those fields and as far as the receiver goes, generally, it is they can consume that. We're not testing that end-to-end trust,” that the messages that come through are not mis-translated, but mean what the sender intended.

“Many of the organizations that have been doing exchange for years, it has been within their own systems,” Dickinson said. “Or if you're using varied vendors, you're using an interface engine that's carefully tuned. You'll specify the same data types and code sets on both sides of the exchange.”

“Now, with meaningful use,” Dickinson said, “instead of that carefully managed and screened kind of exchange environment, we're wanting every receiver to trust what's being exchanged from any sender.”

To Dickinson's mind, it opens the door for a situation “fraught with issues that are easily glazed over by ONC and the CMS.”

What does he propose doing about it?

“We're plunging ahead with this, and we should at least acknowledge the issues, and what you get on the other side may not be in fidelity to the source,” Dickinson said. One short-term coping mechanism, he says, would be to send the original data along with the transformed data, then, “the receiver knows they have, at least, the source” data and can use it to audit the message if necessary. As a data user, “It gives me extra assurance,” he said.

In addition, the ONC could recognize an addition set of voluntary EHR certification criteria that would include this source-data carrying capacity.

Dickenson said he's shared a copy of the matrix with Dr. Doug Fridsma, director of the Office of Standards and Interoperability at ONC, as part of his dialogue with him.

“When data comes in from an outside source, are we going to trust it to the extent that we're gong to make decision on it?” Dickinson asked. The more that we can ensure the trust of data coming in from external sources, the better, he said.

Follow Joseph Conn on Twitter: @MHJConn