At the heart of our clinical information requirements lies Health Level Seven (HL7) International and the HL7 family of interoperability standards. Simply put, standards are a prerequisite to functionality, and HL7 protocols drive the flow of clinical information needed to enable today’s electronic health records (EHR). But while we as computer users may not directly influence the next design of the microprocessor, as clinicians we certainly have the capacity to shape HL7’s direction.
In one of my favourite childhood books, The Phantom Tollbooth, by Norton Juster, there is a boy named Milo who is in search of rhyme and reason. He encounters a strange land, where wizards repeat what they’ve heard, each wizard restating in a different way. "Well, then," said Milo, not understanding why each one said the same thing in a slightly different way, "Wouldn’t it be simpler to use just one? It certainly would make more sense."
Imagine trying to implement decision support, drug-drug interaction checking, or automated clinical reminders, if everyone communicated data in a different way. Simply stated, standards are a prerequisite to functionality, and clinicians play a key role in standards development.
What is HL7?
HL7 is, first and foremost, an international community, working together towards a common goal of improving patient care through technology. Founded in 1987, HL7 is a not-for-profit standards development organisation dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services.
HL7’s 2,300+ members include approximately 500 corporate members who represent more than 90% of the information systems vendors serving healthcare.
HL7’s vision is to create the best and most widely used standards in healthcare. Our mission is to provide standards for interoperability that improve care delivery, optimise workflow, reduce ambiguity and enhance knowledge transfer among all of our stakeholders. This includes healthcare providers, government agencies, the vendor community, fellow SDOs and patients. In all of our processes, we exhibit timeliness, scientific rigour and technical expertise without compromising transparency, accountability, practicality, or our willingness to put the needs of our stakeholders first.
HL7 interoperability protocols include messaging standards, decision-support standards, clinical document standards, EHR functional requirements, drug product labelling standards, and more.
Our messaging protocols enable different applications and different systems to communicate in a standardised way – for example, enabling lab results to be communicated from a lab system to an EHR, or prescription information to be sent from an EHR to a pharmacy. Today’s HL7 messages can piggy back onto the same protocols used to support the internet.
Decision-support standards define the interactions that occur between an EHR and a decision-support application – for example, so that an EHR can automatically request a resource from an electronic library that gives further information about a patient’s condition. These standards also define a common way to represent decision support rules, such that they can be written once, and then shared across institutions, thereby enabling greater consistency in the care process. For instance, one can write a rule such as "alert the clinician when a patient’s potassium level is dangerously high" in a standard and shareable way.
Decision support standards also enable consistent quality reporting by formalising the logic and population criteria for healthcare quality measures. For instance, HL7’s eMeasure standard can be used to express "for measure X, the denominator population are those patients admitted to the hospital with pneumonia, the numerator population are those patients given antibiotics within 24 hours of admission" in a standard and shareable way.
The HL7 clinical document architecture (CDA) provides an exchange format for clinical documents (such as discharge summaries and progress notes) – and brings the healthcare industry closer to the realisation of an electronic medical record. By leveraging the use of XML, the HL7 reference information model (RIM) and coded vocabularies, the CDA makes documents both machine-readable – so they are easily parsed and processed electronically – and human-readable, so they can be easily retrieved and used by the people who need them.
CDA documents can be displayed using standard internet browsers or wireless applications such as cell phones. CDA retains the simplicity of rendering and clear definition of clinical documents formulated, and provides state-of-the-art interoperability for machine-readable coded semantics. CDA is thereby capable of driving decision support and other sophisticated applications, while retaining the simple rendering of legally-authenticated narrative.
Several CDA-based implementation guides have been developed by HL7. Perhaps most relevant to this readership are the Public Health Case Reporting and the Healthcare Associated Infection Reporting guides, both developed in collaboration with the US Centers for Disease Control and Prevention.
These implementation guides define exactly how to communicate relevant data around particular infectious diseases or patient safety events.
EHR and personal health record (PHR) functional requirements are standardised in the HL7 EHR and PHR system functional models. These models provide a reference list of functions that may be present in an EHR. The function list is described from a user perspective with the intent to enable consistent expression of functionality. These models, through the creation of functional profiles, enable a standardised description and common understanding of functions sought or available in a given setting.
Let me pause here a minute to consider the implications of an EHR system functional model, whose focus is more on EHR requirements than on technical implementation details. In the earlier days of HL7, it might be said that participants were largely technical folks, folks that had a need to communicate with others. They came together to seek agreement on a common format, so as to lower the overall cost of interface development. But consider this: Who decides what data needs to be in a lab message? Who decides what data needs to be communicated to the public health agency when confronted with a case of tuberculosis? Who decides what decision support rules need to be built?
The answer is that content decisions and functional requirements require input from clinicians and clinical managers – from pharmacists, lab technicians, physicians, nurses, and others. In recent years, and certainly as catalysed by the EHR system functional model, we’ve seen a tremendous positive change in the makeup of the HL7 membership, from one that was predominantly technical, to one that is now balanced across technical experts and domain experts.
Going back to our "Intel Inside" comparison, the implication to the reader is that while a computer user may not directly influence the next design of the microprocessor, clinicians and clinical practice managers will certainly shape HL7’s direction. In the sections that follow, I’ll discuss exactly how readers can be a part of this direct influence.
The HL7 structured product labelling (SPL) specification standardises what is often known as "product labels", "package inserts", or "prescribing information". The SPL standard defines how to create package inserts that contain the authorised published information that accompanies any medicine licensed by a medicines licensing authority. SPL defines a standard representation for drugs, and for drug side effects, indications, and contra-indications. As such, they can be harvested and consumed by decision support and patient safety applications.
Many other HL7 standards exist, spanning the gamut of healthcare, from clinical genomics to billing and claims.
Our new generation of EHRs and our ability to aggregate and use national and global data for the improvement of patient care, depend on it.