Health IT Standards - Evolution or Intelligent Design?

October 11, 2010

Healthcare reform has stimulated interest in standardizing data and EHRs. It is politically correct to repeat the mantra, but is there evidence that people understand the message and reflect it in their actions? In my opinion, unfortunately, the answer is no.

Healthcare reform has stimulated interest in standardizing data and EHRs. It is politically correct to repeat the mantra, but is there evidence that people understand the message and reflect it in their actions? In my opinion, unfortunately, the answer is no. 

Some standards arise as a result of Darwinian forces; they provide more tangible value when pitted against competitors or a state of total chaos. Sometimes, there is no clear winner, but a consensus develops that standardization is essential. One of the contenders is selected or is perhaps mandated by government, e.g. digital TV.

Examples of standards that have undergone a period of natural selection include: VHS video tape, the configuration of gasoline pump nozzles, driving on the right side of the road, and the worldwide spread of the English language. One strength of standards that arise via natural selection is that the process is gradual, often imperceptible and rarely onerous. Survival depends on continued utility, not on an administrative or committee edict (unless legally mandated in which case the requirement may persist long after it ceases to be useful.)

Other "standards" begin as theoretical, idealistic proposals. They are debated and massaged by committees. Vendors are vocal participants as great advantage attaches to getting one's existing technology adopted as a standard.

An example of this process is HL7, the standard that set about to define the communication of healthcare information between systems and organizations. HL7 standards have achieved wide acceptance in concept. Every serious vendor claims to be HL7 compliant or something to that effect. Vendors may, however, choose which chapters of the standard, which messages in each chapter and which optional fields in each message they will implement. Latitude is afforded in defining the information that goes into many fields. Each interface actually implemented requires fine tuning and testing to resolve residual incompatibilities between the participating systems. Organizations often find that information critical to their operations is not part of the "standard" messages or is part of a chapter their vendor chose to ignore forcing them to create "custom" segments, if they can get their vendors to agree.

The federal government has accepted the assertion that HL7 and similar standards will solve the problem of data access and interoperability. As a result they have anointed these standards and have begun to mandate their adoption.

A look at actual implementations reveals a less rosy picture. Although these standards provide a common vocabulary, you cannot simply pull up to the vendor's gas pump and fill your tank with their data. It is time consuming and costly to implement even a single HL7 interface. There are typically three parties involved in each implementation: vendor A, vendor B, and the customer. It can take weeks or months to complete the testing of a new or modified interface. Once an interface is finished, it almost never gets touched. New versions of the "standard" appear but they are rarely applied to existing interfaces. As time passes, the individuals who did the original implementation leave the organization. Their replacements have no idea what is really going on; they just hope it doesn't break.

When the number of interfaces that each organization needed was relatively small, the test-and-tweak approach worked reasonably well. Don't misunderstand: Conventions like HL7 can be very effective if used for simple messages like a clinic arrival or billing transaction. They break down in the arena of medical records where the content can be infinitely variable and constantly changing.

Few users implement the complete HL7 standard now. In the future the sheer volume and complexity of the information that people are expecting to exchange will simply overwhelm this methodology. There will be insufficient time, money, and personnel to do the job. All the while the committees will still be cranking out more proposed standards.

Standards such as HL7, being the product of a top-down theoretical process, bear little resemblance to the simple, elegant standards that have repeatedly established themselves through the process of natural selection. It is easy to imagine that they will rapidly lose their relevance as their inherent complexity and bureaucracy prevent them from evolving in Internet time. The solution must lie elsewhere.

Daniel Essin, MA, MD, FAAP, FCCP, will be a regular contributor to the Practice Notes Blog. He has been a programmer since 1967 and earned his MD in 1974. He has worked at the Los Angeles County and USC Medical Center where he developed a number of internal systems, chaired the Medical Records Committee, and served as the director of medical informatics. His main research interests are electronic medical records, systems architecture, software engineering, database theory and inferential methods of achieving security and confidentiality in healthcare systems