“How do we test health IT interoperability?” is a deceptively simple question.
To get to a complete answer, let’s build a definition of “Health IT Interoperability.” To get started, let’s take the advice of Dr. Doug Fridsma at ONC:
The IEEE Standard Computer Dictionary defines interoperability as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” …
That means that there are two parts to the definition of interoperability:
- The ability of two or more systems to exchange information
- The ability of those systems to use the information that has been exchanged
“Health IT Interoperability” can, therefore, be defined as the ability of two or more Health IT systems to exchange information and use the information that has been exchanged.
It would be logical to conclude that testing health IT interoperability simply involves verifying that health IT systems can exchange and use health IT information. This is accurate on the surface, but like anything of substance, the devil is in the details. Nobody would be comfortable if the patient identities and treatment information to be exchanged were not protected by robust encryption and other security measures, so testing health IT interoperability starts with validating the security of the information.
Validating security should test the encryption of the data and the authorization of both the sender and there receiver; this includes detection (and the validation of countermeasures for) “man-in-the-middle” attacks on the information exchange. Entire books can be writhed on this topic alone–and they have. (Stay tuned for articles here which dig deeper.)
Security is vital, but many other standards must also be followed to validate that the “use the information” goal of the information exchange will happen according to expectations.
For the eHealth Exchange (formerly known as the Nationwide Health Information Network – NwHIN or NHIN), there are over 20 specification documents to understand, and these documents reference dozens of baseline specifications by IHE, HL7, OASIS, W3C and more. It can take very smart people years to understand and master this information. (We know this firsthand.) Mastery of this subject matter to the level required for verifying conformance takes it to a completely different level of difficulty.
As daunting as this may sound, we haven’t touched yet on validating that the Health IT exchange partners react as expected to negative conditions, like a revoked SSL certificate, or missing attributes in the security portion of the messages used to package up the data to be exchanged.
This may all sound insurmountable, but it can be done. It’s not always pretty, and it is a long journey, but the mission of protecting the integrity of patient information while getting it to providers when needed for patient care is worth the pain.
In Part 2, we will take a quick tour of the history of health IT interoperability testing (the good, the bad, and the ugly).