Optionality and Interoperability in Health Care Software

Health care information exchange is one of the elements of health information technology that offers the promise of transforming health care systems to improve patient care. But health information exchange cannot occur without standards-based interoperability. The adoption of standards allows disparate vendors to develop software that collects, stores, and communicates information without change in its integrity and meaning. One of the problems I have seen in working with HITSP and IHE is that many standards contain a lot of optionality when it comes to data elements. I think excessive optionality built into standards makes the goal of interoperability more challenging.

Here is how I encountered the optionality problem. I have worked as a monitor at the last two U.S. IHE Connectathons. As a monitor for the Patient Care Coordination (PCC) domain, I checked on the ability of vendors to use IHE profiles to exchange CDA documents/medical summaries. Before the Connectathon, clinical subject matter experts (SMEs) created the content that vendors were expected to include in their documents. My job started with automated validation of the CDA documents using a tool developed by NIST. A second step required a comparison of the actual data produced versus the script created by the SMEs. It's fair to say that most vendors did not produce and exact copy of the vendor script, even though these scripts contained very basic-information such as problems, medications, allergies, etc. So what is the explanation?

To find part of the answer requires a dive into the IHE profiles. In IHE, there are 3 options for the use of specific data elements. They are R-required, R2-required if known, and O-optional. This opens the door for interpretation by users as what to include in the document, under what circumstances. At the Connectathon this resulted in a lot of consternation for me. I thought if a profile allows so many interpretations in a very restricted testing environment, how would it perform in real world use? Interestingly, HITSP used similar optionality choices in its data definition tables. One of the added values that standards harmonization organizations should bring to the standards world is constraint of the optionality offered by base standards. There must be some use for optionality.

Optionality allows entities of different sizes and needs to interoperate. This enables a one-size-fits-all approach to standards development and interoperability. This enables scaling of applications according to business needs. Organizations with limited needs just don't utilize the built-in optionality. Optionality can also avoid hard stops when information is not initially known but may become know or change at a later time. An example would be a patient registration application that enables the emergency registration of a patient when the only demographic information available may be the patient's "trauma name." A good discussion of hard stops starts on page 13 of "Developing Successful Healthcare Software:10 Critical Lessons"

The down side of optionality is that it may degrade interoperability. Further, based on my experience, it may be more difficult and test software where there many optional data elements. One approach would be for standards development organizations (SDOs) to concentrate on the description of a minimum necessary data set for a given purpose or application and then limit optionality as much as possible.

There may be a number of causes for the optionality problem. SDOs should make sure to engage all the key stakeholders and secure their input when they set about developing new health care technology standards. Also, the democratic approach to the vetting and acceptance of standards in organizations such as SDOs may allow an outspoken majority to overrule the contributions of a minority group that has a better vision of the long-term consequences of some development decisions.