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.

Planning for HIMSS 11

I recently went online to take advantage of early bird registration for HIMSS 11. This annual HIMSS meeting will take place in Orlando in February. I had put off registering because mostly because I had a really hard time deciding on one of the many pre-conference workshops or symposia offered this winter. Last year I attended the Physician's IT Symposium. There was a lot of good information and I felt I got my money's worth. This year I thought I would try something different. The problem was that there are too many good topics to choose from. I would like to have about 5 clones to attend the conference with me.

There will be a Clinical Decision Support workshop that will focus on CDS and its intersection with quality improvement. I think that innovative developments in CDS will be a focus for vendors of EHR software in the next five years. Use of evidence-based medicine guidelines baked into CDS will inevitably lead to more standardized, high-quality health care across the country.

Another option is the Change Management Workshop. No one can be knowledgeable enough about change management in this era of rapid adoption of technology. As many have discovered, "it's not about technology, it's about people." Despite our best wishes, people are reluctant to change their ways. This is particularly true of many older clinicians who are hoping to retire before all the changes on the horizon in medicine become reality. But, it is also true of people of all ages engaged in the health care enterprise.

One workshop that was hard for me to pass up was Life in the Fast Lane-Privacy and Security in the Age of the Electronic Health Record. Privacy and security issues are among the top concerns of both consumers and clinicians. Health information exchange is mandated in Meaningful Use regulations. Progress will be difficult unless the health IT community can assure the confidentiality, integrity, and availability of personal health information in a framework of trust during information exchange. I will never know as much as I would like about the topic of privacy and security.

The HIE in the Era of HITECH and Health Reform Symposium is another session I would really like to attend. Health information exchange is one of technologies that will revolutionize the practice of medicine in the coming years. Getting it right will not be easy. The technological challenges, though daunting, will take a back seat to issues of governance, policy, and consent. I am in favor of a central approach. The federal government, through the state grant program, is favoring a more federated landscape. Both flavors of information will be supported. Purpose of use will probably determine which method is best in a given situation.

Closely aligned with HIE is the Secondary Use of Data Symposium. I was so interested in the topic of secondary use that I chose to make it a focus of one of the major papers I completed in one of my master's degree classes. My short essay of 35 pages just scratched the surface of this subject that cuts across many domains in health IT.

So I chose the ARRA Usability Symposium of all the possibilities. I made this decision, not because I think it is the most interesting to me. From a clinician's point of view it may be the most important however. Also, it is somewhat difficult to get good information about usability. I believe that usability issues have been a major factor that has slowed the adoption of EHR technology by clinicians. While human factors engineering has been applied with great success in fields such as aviation, it has been under utilized by EHR developers. I think one solution is greater collaboration between clinicians and the engineering community. I hope this symposium will provide some tools to help me pull my weight.