In my last column, I asked you to imagine you had received a grant to acquire an Electronic Healthcare Record (EHR) system, and that you were already using a Practice Management (PM) system. Your billing supervisor says, “I hope the new EHR system we’re getting can trade data with our PM system.” You ask your EHR vendor and he says, “No problem, as long as your PM program can receive and generate HL7.” “Great,” you think. “What’s HL7?”

HL7 – which stands for “Health Level Seven” — is one of a group of standards that guides the sharing of healthcare information among the different automated systems you use to facilitate patient care and revenue generation. It is a good example of a widely accepted standard, and a good one for us to have a closer look at to understand what standards are about, how they are developed and how they promote the goals of data exchange and interoperability.

Before we do that, though, let’s look at standards more generally. Wikipedia defines an information technology standard as a set of universally agreed-upon guidelines generally referring to interoperability among systems or applications. This seems straightforward, except that there are many types of standards and many organizations that develop and promote them. Standards come in two flavors: de jure and de facto. Standards that are developed by universally accepted or accredited standards bodies, like American National Standards Institute or ANSI (www.ansi.org), are said to be de jure, that is they have the ‘authority of law.’ There are several other Standards Developing Organizations SDOs in healthcare, such as the Object Management Group (OMG), Integrating the Healthcare Enterprise (IHE) and the Health Information Technology Standards Panel (HITSP). These organizations, and many like them, either sponsor groups to develop specific standards or form the groups themselves from their membership. In the past 20 years or so, I have participated in the ANSI X3H2 committee that produced the first standardized SQL. I was also the author (along with a review committee) of the OMG Repository and Interoperability standards (IIOP).

Standards that are accepted by a large number of users, even though they have not been developed by an accredited standards body, are said to be de facto, that is they have the ‘authority of fact.’ The program most often cited as a de facto standard is Microsoft Windows. These standards are usually developed by companies. There is one other category that should be mentioned, and it can come in both flavors – that is, open source software (OSS). OSS is a ‘standard’ – not because it is certified as one, but because it is non-proprietary and generally freely usable. It is becoming more of a force in HIT and will be the subject of a future column.

Standards are developed by people like me who have specific technical or professional agendas or who work for companies that have agendas and commercial aspirations. These are people who in general may not be at their best in collaborative settings, as each of them has his own opinion about how to solve the technical problem that the standard addresses. For this and many other reasons, standards are compromises. Often they are good compromises, sometimes they are not. Sometimes the technical issue at hand is so difficult that there are no good compromises. Of course, even the most widely accepted standard only works if there is a product that implements it in a straightforward and usable way, and if it supports data transfer appropriately in a real-world setting.

Following the standards does not guarantee that we can exchange data and create data interoperability –that is, the ability to share data across systems and applications — but it does help facilitate it by giving us guidelines that govern the exchange of information between applications, such as practice management and EHR systems.

So let’s have a look at HL7. The HL7 organization (www.hl7.org) has been certified as a standards developing organization (SDO) by the ANSI. That means that it develops its standards according to guidelines that ANSI administers. HL7 is actually several standards that can be used together to facilitate clinical and administrative data exchange. These include a message protocol, an XML-based clinical document architecture (CDA) that defines the structure of such documents as discharge summaries or clinical notes so they can be exchanged, a clinical context architecture (CCOW) that allows independent applications to interpret function and a syntax for medical logic systems, and the Arden Syntax, which is a language for sharing medical information across individuals and applications.

The primary HL7 standard is the Electronic Data Exchange in Healthcare Protocol. This is a ‘message protocol’ that allows the exchange of patient demographic, financial and clinical data among compatible programs. Message protocols specify the form of the information that is exchanged (but not exactly how the programs actually do the exchange). A standard form is necessary so that each program knows how to interpret the information.

There are many standard message protocols, but HL7 is different in several ways. First, it is not a general standard; it only applies to healthcare data. Also, it defines a form for the data that is human-readable – that is, you or I can look at the data stream and understand it (for the most part). Finally, it is very flexible. It needs to be because the data it deals with is not uniform. For example, not every name or address is 64 characters long, and the programs need enough information to differentiate between similar or identical names, addresses, etc.

HL7 defines messages in 13 areas such as Patient Administration, Scheduling, Financial Management and Observations (diagnosis and treatment). Your EHR system creates HL7 messages that it sends to your PM system which, in turn, interprets them, stores the information (such as the ICD9 codes for billing) in the right place, and can also send messages back to the EHR system. This sounds easy, but it takes real work to get the two systems connected appropriately, often even when they are supplied by the same vendor.

There are currently five versions of the message protocol, three versions of the context architecture and, unless you write your own HL7 system, you need to rely on a vendor to supply you with a system that allows you to use some subset of the HL7 standards. Each vendor has a slightly different implementation of the ‘standard,’ even the messaging standard. Each vendor leaves out certain parts of the data (required or optional fields), structures the messages slightly differently, etc. Finally, HL7, even if we used all of it, addresses how you transfer the information from one system to another, but doesn’t – and can’t – address how the information is organized or maintained by either application. You, your vendor or your consultant has to do a lot of programming to make this work.

I’m not trying to pick on HL7 here. Actually, HL7 is one of the better sets of standards in the healthcare area; but like others, it requires a lot of work to provide even minimal data interoperability.

What are some of the non-HL7-based standards that are important in healthcare?

A short list might include:

  • Continuity of Care Record (CCD) encapsulated in the Clinical Document Architecture, developed by ASTM International
  • Digital Imaging and Communications in Medicine (DICOM) developed by the National Electrical Manufacturers Association (NEMA)
  • National Council For Prescription Drug Programs (NCPCP) for pharmacy data exchange, developed by the group of the same name
  • The Connecting for Health Common Framework (RLS), developed by Connecting for Health sponsored by the Markle Foundation
  • The National Health Information Network (NHIN) developed by a variety of contractors to the Office of the National Coordinator for HIT (ONC) at HHS

OK, enough alphabet soup – the point is there are many standards relevant to healthcare. Most are specialized to provide a certain type of interoperability and not all need to be addressed at once. You (and your vendors) can deal with those standards most relevant to what you are trying to accomplish, and not the whole universe of standards.

What about all those other terms associated with standards? This column has only focused on data interoperability – that is, the ability to exchange data between independent applications. Where does integration and certification fit in? Finally, what do standards, and their associated concepts, mean for healthcare in the short and long term? How do they relate to Nationwide Health Information Networks (NHINs) and Regional Health Information Organizations (RHIOs) in general? What do they mean for CHC operations? Those are more complex topics, ones that I’ll focus on, along with standards and interoperability, in the research project that I’m starting.

What questions, issues or answers do you have about standards, interoperability and integration? We want to include your concerns and experiences in this research project, so please contact me (dhartzband@rchnfoundation.org) and share your thoughts on standards with me. The Foundation will complete this project and publish our findings during the first half of 2008.

David Hartzband, D. Sc. is the Director for Technology Research at the RCHN Community Health Foundation.