An abundance of tools

HL7 has made tremendous progress. This move forward has resulted in a whole array of useful tools. Kai Heitmann takes a look at the workshop that never stops.

Health Level 7 (HL7) is probably best known for its Version 2 standard. Version 2 is the messaging standard for the exchange of health information between different healthcare organizations. It supplies subsystems with administrative, medical and billing-related information so that all systems will be up to date. The HL7 organization (hl7.org) has been developing HL7 Version 2.x since 1987, and it has been used by the majority of German hospitals since the mid-1990s.
The Clinical Document Architecture (CDA) standard has been similarly successful. It is an HL7 standard for electronic documents and FHIR (Fast Healthcare Interoperability Resources) that mainly deals with mobile technologies and processes. The functions of CDA and FHIR will be discussed in more detail below.

A standard takes hold
Clinical Document Architecture (CDA)—an HL7 standard for electronic documents—is part of HL7’s family of Version 3 standards. The model-driven message exchange based on it has gained less acceptance than expected, however. CDA as a “family member” was considerably more successful, like the HL7 Version 2.x standards—so much so that many people refer only to CDA in discussions of the second-generation HL7 standards. Electronic equivalents have been defined for typical paper-based documents and forms, such as discharge summaries, infection protection reports, lab reports, radiology reports, and a number of others. Ultimately, electronic patient records can be regarded as a collection of medically relevant electronic documents. In addition to the structured “letterhead” data, which would also be found in something like a discharge letter (patient, physician, next of kin, event, site of service, etc.), the “body” conveys the actual clinical information, such as history, symptoms, medication, allergies, treatment plan, etc. Its main element is free text, which can be supplemented with machine-processable, highly structured components that are usually coded, known as “entries,” e.g. diagnoses, medication, etc.
This opens up a wide range of options from the simple to the complex, which has undoubtedly contributed to CDA’s success. CDA thus defines the contents of electronic documents using structures and semantics, which can be stored and utilized, for example in records systems. There are other established processes for document transport, such as IHE Cross-Enterprise Document Sharing (XDS).

Development fueled by FHIR
As mentioned above, the newest generation of the HL7 standards palette, FHIR (hl7.org/fhir), focuses primarily on mobile applications. It combines the advantages of the established HL7 standard “product lines” of version 2 and CDA with those of the current web standards, with a strong emphasis on simple implementation.
The development of FHIR was influenced by the paradigm shift in healthcare: Patients want to have a say in what is done with their information, and they demand more transparency. Today patients are more likely to be online than offline, and they want to get information in real time according to their needs, for their personal use and analysis.
To that end, FHIR is centered around “resources”: compact, logically discrete units for data exchange, associated with well-defined properties and precise meanings. Examples include “patient,” “procedure,” “medication,” “order,” or “form.” Resources can be modified to fit specific requirements (profiling) and augmented as needed (extensions).
This standard is still under development at present. FHIR has just reached phase 3 of the Standard for Trial Use (STU) stage, and will be fine-tuned by a large community. Now and in the future, FHIR will be used primarily in mobile applications, due in large part to its ease of implementation and associated low cost, as well as its scalability, already familiar from CDA. HL7 Germany (hl7.de) is also working on “basic profiles” to incorporate the unique features of the German healthcare system, such as the eGK (electronic health card) number or LANR (lifetime practitioner number), into FHIR.

 

A well-stocked toolboxkasten

Powerful tools are necessary in order to consistently define standards and the implementation guidelines (specifications) derived from them, and to support software vendors in implementing them. ART-DECOR® (art-decor.org) has become the established tool for developing CDA-based implementation guidelines. Designers can use it to create “building block repositories” (BBRs) and take advantage of component reusability. Software engineers also benefit in the implementation phase of test and validation methods when developing new software. On a larger scale, the tool can work closely with IHE Gazelle, a validation framework. Developed by the ART-DECOR Expert Group and maintained by the ART-DECOR Open Tools organization (art-decor-open-tools.net), ART-DECOR® has been used in over 50 projects to date, mainly in Europe.

Conversely, Forge, a tool created by the Dutch firm Furore (fhir.furore.com/Forge), is used for profiling FHIR resources, and works best in conjunction with the profile management and publication tool Simplifier (simplifier.net). Simplifier itself can also cooperate with ART-DECOR®, so that operations like transitions and mapping from CDA to FHIR and vice versa can be supported.

An alternative to these is the web-based tool ClinFHIR (clinfhir.com), which is not quite as comprehensive in terms of FHIR profiling, but does offer a full array of other features. We will be using HL7 Version 2, CDA, and FHIR for a long time to come. It has only become clear in recent years how important the individual tools are at every stage—from design to implementation to efficient operation.