What is the most common way data are exchanged between systems in a hospital today?

HL7—Standard for exchanging healthcare data

Health Level 7 (HL7, https://www.hl7.org/) is a standard development organization. It develops specifications to structure, encode and exchange patient healthcare information. The underlying objective is to facilitate exchange between healthcare systems. Several standards have been developed by HL7, for example:

HL7 v2.x, text encoding of HL7 messages, to exchange messages between systems,

HL7 Clinical Document Architecture (CDA) as part of HL7 v3, to describe clinical documents,

Fast Healthcare Interoperability Resources (FHIR).

HL7 v2.x is a standard series of predefined logical formats for packaging healthcare data in the form of messages to be transmitted among computer systems. The HL7 v2.x protocol is the most widely implemented standard for exchanging clinical data between systems including data from patient administration, financial management, and materials management to patient care, clinical laboratory automation, and scheduling. It is based on messages and uses an event trigger model that causes the sending system to transmit a specified message to the receiving unit, with a subsequent response by the receiving unit. Messages are defined for various trigger events. In contrast, HL7 v3.0 is object-oriented and based on a Reference Information Model (RIM) developed by HL7. The RIM comprises subject areas, scenarios, classes, attributes, use cases, actors, trigger events, interactions. It allows to represent the information needed to specify HL7 messages (Hammond and Cimino, 2006).

The Clinical Document Architecture (CDA) is HL7’s standard for representing structured clinical documents on patients for the purpose of health information exchange (https://www.hl7.org/). It is based on XML and is a document markup standard that specifies the structure and semantics of clinical documents.

FHIR is a platform specification that defines a set of capabilities used across the healthcare process, in all jurisdictions, and in lots of different contexts (https://www.hl7.org/fhir/). Basic building blocks of FHIR are so-called resources. A resource is a collection of information models that define the data elements, constraints and relationships for the “business objects” most relevant to healthcare. FHIR resources are represented in XML or JSON. They are increasingly used to make healthcare data accessible and transferable. For example, the health data platform MIDATA (see Section “Open Personal Health Data”) allows data input and export using FHIR.

Emerging Technical Standards

HL7 FHIR (Fast Healthcare Interoperability Resources) is an emerging innovative standard for exchange of information. As we explained in previous sections, HL7 members developed a very comprehensive standard in version 3 and addressed many of the gaps in HL7 v2, however, because of its complexity still now majority of health-care organizations and HIEs utilize v2 messages instead v3. FHIR standard first introduced in 2011 to overcome the complexity of the RIM standard and hide all of those complexities from developers’ sight. FHIR is designed to be compatible with previous versions of HL7 standard (v2 and v3) to enable legacy systems to function in HIE. Since FHIR is much simpler to be implemented and uses straightforward RESTful technology, it is very promising standard for future of HIE.

Data exchange and standards

LIS were once largely standalone systems where laboratories managed data generated within the laboratory. This is no longer the case with the LIS being highly connected and involved in all phases of the diagnostic testing process, from test ordering to interpretation. The current generations of LIS are an integral part of the healthcare system and must interact with numerous other systems to function effectively (Fig. 18.3). The LIS must exchange data with practice management systems, hospital information systems, electronic medical record systems, and billing systems.

The connection of the laboratory to the rest of the hospital relies on standardized message formats and communications. Data exchange between these various information systems occurs via application interfaces. These interfaces include the software, protocols, and connections that enable electronic data exchange from one system to another. Common messaging formats and communication protocols serve to standardize data exchange between applications. The recent development of interface engines, which serve as “traffic cops” to route data between applications, has also improved communication in healthcare organizations.

Health Level 7 standards

HL7 is a standard messaging format for data exchange between information systems. HL7 is commonly used to send orders from an order entry system to the LIS and to send LIS results to a clinical information system. It also is used for ADT systems to transmit relevant demographic and patient status information (e.g., ADT-A01 is the code for admitting a patient). HL7 defines the types of messages that can be sent as well as the data that can be exchanged in each message. The use of extensible markup language (XML) for the encoding of data for storage, display, and transmission has become standard in many industries. Recently, healthcare has begun to utilize XML to supply the framework for clinical data, and XML-compatibility has been incorporated into newly developed HL7 standards.

HL7 message types include messages for test orders, test results, and ADT notifications. In addition, HL7 defines how the messages are to be exchanged and provides error communication guidelines. Each HL7 message is divided into segments [e.g., message header (MSH) segment and result/observation (OBX) segment] and the segments are further divided into fields (separated by the vertical bar character, “|”) that contain the data to be exchanged (Fig. 18.8). For example, in the OBX (result) segment of the message, the OBX-3 field contains the test name and the OBX-5 field contains the test result value. In the example, the test name field in OBX-3 is divided by the caret character (“^”) into two data elements, the test code, and the test name (e.g., 4498-2^Complement C4).

Figure 18.8. A sample Health Level 7 message. The message is a result message sent for a sodium result, with a value of 138, which is below the reference interval.

3.4.3. HL7

Health Level Seven (HL7) is the most important US health informatics standard organization. In the last four years, its membership has tripled to over 1600 health industry members including most of the major healthcare information systems consultants and vendors and 90% of the healthcare system vendors. The HL7 standard, supported by most information system vendors, is at present being used in the majority of large US hospitals and in many other countries (HL7, 2005). In the beginning it was concerned only with messaging standards, but in the recent years it also became involved in standardization of decision support tools, terminology and ontology.

HL7 is an ANSI-accredited not-for-profit voluntary organization, whose mission is to provide standards inside healthcare organizations for the exchange, integration, sharing and retrieval of electronic health information; support clinical practice; and support the management, delivery and evaluation of health services. This standard makes possible the transfer of laboratory results, pharmacy data and other information between heterogeneous computer systems.

HL7 standards domain is within clinical and administrative data, while other standard developing organizations are involved in other areas like medical devices, imaging, pharmacy, etc. As a not-for-profit organization, its members (providers, vendors, payers, consultants, government groups and others) develop the standards. A frequent misunderstanding about HL7 is that it produces and develops software. The most widely used HL7 standard is a messaging standard that enables heterogeneous healthcare applications to exchange clinical and administrative data (HL7, 2005).

The name “Health Level Seven” is related with the application level of Open System Interconnection (OSI), the highest level of the ISO communications model. The OSI model is a layered model that explains how information travels from two different applications running on two different networked computers. Fundamentally, the OSI model regulates the steps to transfer data over a transmission channel between two network devices. The seventh layer or the application layer provides network services to the software (end users). It should be remembered that normal computer applications are not on this layer, but programs such as browsers, file transfer protocol (FTP) clients, and mail clients are.

There are several SDO efforts currently underway to develop standards to healthcare domain, but HL7 has a particular speciality, it is focused on the interface requirements of the entire health-care organization, instead of being focused on the requirements of a particular department. Being stakeholder oriented, the definition of standard within HL7 is fast because its members develop, analyse and ballot the ongoing standards.

The HL7 functional model consists of a set of functions and their associated functional descriptors. These functions are divided into three main sections: direct care, supportive and information infrastructure (see Fig. 2).

HL7 defines the Clinical Document Architecture (CDA), as a document markup standard that specifies the structure and semantics of a clinical document, such as a billing summary or progress medical note, for the purpose of exchange. A CDA document is an object-oriented document that can include text, images, sounds and other multimedia content. Although it is not strictly an EHR standard it forms an important sub-component of an EHR which has already been integrated with the equivalent structures in CEN 13606 and open EHR. CDA is encoded as Extensible Markup Language (XML) documents based on the HL7 Reference Information Model (RIM) attached with terminology.

CDA release 1.0 became an ANSI-approved HL7 Standard in 2000, representing the first specification derived from the HL7 RIM. The major difference between the CDA R1 and the new R2 (released in 2005) is that CDA R2 model is richly expressive, enabling the formal representation of clinical statements (observations, medication administrations and adverse events) such that they can be interpreted and acted upon by a computer (Dolin et al., 2006).

HL7 messages were developed for several years using a bottom–up approach to reach each individual problem. Thus, such an ad hoc methodology created the HL7's success due to its flexibility. It contains many optional data elements and data segments, making it adaptable to almost any application. While providing great flexibility in its version 2, the different options available made the design of reliable conformance tests of any vendor's implementation quite difficult, and also forced implementers to use more time analyzing and planning their interfaces to guarantee that both parties were using the same optional features. To overcome this, the HL7 version 3 was released in 2005 using a well-defined methodology based on a reference information model mainly because objectivity is mandatory for reliable conformance tests. With fewer options vendors would have their conformance certification, because the primary goal of HL7 was to offer a standard that is objective and testable. This very limited-options version was reached by the use of message building techniques, adding more trigger events and limiting message formats. This new version for creating messages uses a development of object-oriented methodology and a Reference Information Model. RIM is an essential part of the new version, because it provides a clear illustration of the semantic and lexical connections that exist between the diverse information carried in the HL7 message fields.

RECOMMENDED RESOURCES

Health Level 7. (2007). Technical committees and special interest groups. http://www.hl7.org/Special/committees. This Web page provides links to committees within the HL7 standards development organization, which is playing an active role in standardization efforts related to genomic medicine and the use of CDS to support this approach to health care. Committees of particular interest may include the HL7 Clinical Genomics Special Interest Group and the HL7 CDS Technical Committee. Each committee's Web site includes a link to register for the committee's list service.

Kawamoto, K. and Lobach, D.F. (2007). Proposal for fulfilling strategic objectives of the US roadmap for national action on decision support through a service-oriented architecture leveragingHL7 services. J Am Med Inform Assoc 14, 146–155. This article outlines a standards-based approach to CDS that could form the basis of a national strategy for enabling the widespread deployment of effective CDS systems. The recommendations made in this chapter draw from the approach proposed in this article.

Greenes, R.A. (2007). Clinical Decision Support: the Road Ahead. Elsevier, Inc., USA. This book provides a comprehensive overview of CDS, including lessons learned from past implementations and state-of-the-art approaches to managing CDS systems and their underlying knowledge bases. This book is recommended for the reader who wishes to obtain an in-depth understanding of CDS from a single authoritative source.

4.3.2 Health level 7 version 3.x

The use of HL7-v2 was widespread by the mid-90s. In the late 90s, the HL7 organization decided to address the limitations of HL7-v2 and thus commenced the development of a new standard—HL7-v3. The first version of HL7-v3 was released in 2005. HL7-v3 was an attempt to eliminate the semantic inconsistencies of HL7-v2 and develop a plug and play technology for easy use across sites without the need for customization. To achieve this, HL7-v3 introduced a well-defined data model that helped to eliminate semantic inconsistencies. This data model was called the reference information model (RIM). It formed the backbone of HL7-v3 and was used to represent all clinical data in a standard format. The RIM is based on Unified Modeling Language and comprises a collection of classes that model all clinical information. The core classes of RIM are as follows:

Role—for example, a patient/doctor/employee

Entity—a person playing a role

Act—of monitoring or recording vitals

Participation—a role participates in an act

HL7-v3 also introduced the Clinical Document Architecture standard, which was used to create a patient discharge summary. While it provided a good way to transfer a static document containing information between two systems, the summary level record lacked granularity and did not expose individual elements, contained in it, for examination and querying.

Adoption of the RIM in HL7-v3 introduced uniformity by defining data models and eliminated the drawbacks of HL7-v2 but overextended in achieving its goal of standardization and turned out to be too inflexible for practical use. In particular HL7-v3 required application users to understand the RIM to effectively use the tools for data exchange. The regulatory changes required to implement the standard and training programs to educate users made the adoption of HL7-v3 complex and expensive. This proved to be antithetical to the goal of HL7 organization, which was to develop cheap and simple solutions for healthcare information exchange. These shortcomings motivated the development of the latest HL7 standard FHIR.

Common electronic standards

FHIR is a standard developed by HL7 to improve the exchange of data [22]. This standard combines ideas of prior HL7 products, and also new technologies, such as web standards. The standard allows the seamless communication of electronic health records with mobile applications, essentially connecting Patient-Generated Health Data (PGHD) directly with the EHR, with other electronic health records, among many other opportunities around the web. The goal of FHIR was to build a standardized framework to access data in multiple electronic health record environments–completely agnostic of the electronic health record system.

The ability of some remote monitoring devices to have a two-way conversation already exists in some minor markets. One could imagine an electrophysiology device such as an implantable cardioverter-defibrillator, capable of self-interrogation and rhythm assessment. This device could seamlessly use a wireless connection (via Bluetooth or wireless cell signal), to feed the found rhythm to a cardiologist that resides miles away from the patient’s site.

16.3.2 Other CIG modeling methods

The Arden Syntax (see Chapter 15) is a standard of HL7 and ASTM suitable for representing individual decision rules in self-contained units called Medical Logic Modules (MLMs), which are usually implemented as event-driven single-step alerts or reminders. Arden Syntax was not meant to be used for encoding complex guidelines that involve multiple decisions or process flow sequences and there is no support to aid in human understanding of the way in which MLMs interact with one another; only an if-then-else representation of decision rules is possible. Nonetheless, since rules can have action parts that invoke other rules, MLMs can be combined to represent computable guidelines.

GASTON (de-Clercq et al., 2001) represents CIGs using primitives and ontologies to represent the medical domain (e.g. entities such as drugs, diseases, and treatments, and relationships among them) and problem-solving methods (PSMs). The primitive classes are based on version 2.0 of GLIF: action, decision, branch and synchronization steps. PSMs contain a high-level description that details a strategy for solving a problem. An example is the selection PSM that reports conflicts (e.g. drug interactions) resulting from a user’s choice of an action (drug prescription) or a decision. A guideline is associated with a task it has to solve. The task can be specified as a set of primitives or as an appropriate PSM. For the former, the guideline’s structure is specified in terms of primitives and sub-guidelines, where decision criteria refer to concepts defined in the domain ontology. When a guideline is to be executed by a PSM, its control structure does not have to be specified. GASTON is supported by an authoring tool and an execution engine (GASTINE).

Seroussi, Bouaud, and colleagues (Seroussi et al., 2005) proposed a method for representing guidelines halfway between formal knowledge representation and textual reading. Guideline knowledge is represented formally as decision trees. However, instead of automatically executing the decision tree, the user browses it as hypertext and flexibly interprets both patient data and guideline content, thus controlling the interpretation of the guideline knowledge in the specific context of a patient situation. The decision tree is built from clinical parameters that are identified in the guideline narrative and given labels chosen from standard classifications. All theoretically possible clinical situations are represented. This approach has been first applied to breast cancer therapeutic management with OncoDoc. Handling chronic diseases, such as hypertension, involves considering the patient’s therapeutic history (e.g. inadequate response to past treatment, or adverse effects), to select relevant patient-specific therapy among the recommendations. Therefore, the original knowledge base represented as a decision tree of clinical parameters was extended (Seroussi et al., 2005) by introducing a therapeutic level, structured along lines of therapy and levels of therapeutic intention. For each theoretical clinical situation, a range of pharmacological treatments is recommended. Matching patient’s therapeutic history elements along with recommended therapies allows the system to rule out nontolerated or nonefficient past treatments to finally select the best ones.

Electronic Medical Record Adoption and Interoperability

In order to facilitate clinical and administrative data being transferred between software applications, especially with AI-related work, health level-7 (HL7) denotes the seventh (application) level of the International Organization for Standardization seven-layer communications model for open systems interconnection. The HL7 vision is “a world in which everyone can securely access and use the right health data when and where they need it,” so AI work in a health-care organization mandates HL7 as it promotes interoperability of EHRs. Interoperability, according to Health care Information and Management Systems Society (HIMSS), is “the ability of different information systems, devices, or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange, and cooperatively use data amongst stakeholders with the goal of optimizing the health of individuals and populations.” This interoperability can be foundational, structural, semantic, or organizational. This aspect of health-care data is vital to multiinstitutional collaborations in AI projects. The Fast Health care Interoperability Resources, developed by HL7, is an application programming interface that functions as a standard for data formats for exchanging EHR to promote interoperability.

HL7 is sometimes confused with the HIMSS EMR Adoption Model and its stage designations (see Table 4.1): stage 7 is an environment where paper charts are no longer used (complete EHR), whereas stage 6 is its precursor when health-care organizations are at the forefront of EHR adoption with interpretable EHR and just prior to stage 7.

Table 4.1. Health Care Information and Management Systems Society Electronic Medical Record (EMR) Adoption Model (EMRAM).

CDR, Clinical data repository; CDS, Clinical decision support; CDSS, clinical decision support systems; CPOE, computerized physician order entry; HIE, health information exchange; PACS, Picture Archive and Communication System.

Newer Standards and Approaches

Over the last decade the maturation of data standards, technologies, and policies have made interoperable systems more commonplace. HL7 (Health Level Seven International) Version 3 has emerged as a comprehensive reference implementation model capable of providing clinical data in a comprehensive clinical context. For clinical activities, it declares three types of classes (Entity, Role, and Act) and a number of relationships defining these acts. HL7 Version 3 is the basis for the Clinical Document Architecture (CDA) (HL7, 2016). Returning to the spirit HTTP, the CDA is based on eXtensible Markup Language (XML). XML is a highly flexible representation form that can be parsed by machines and read by the human eye. As is the case with HTML, XML allows for both syntactic constraints and the flexibility for expressions ranging from free-form text to highly structure data. Each element in turn can refer to the specifications defining its use as data standards evolve. Increasingly, clinical communications are represented using the CDA. Complementing these efforts, organizations like Integrating the Healthcare Enterprise (IHE) bring together key stakeholders to develop a consensus on systems requirements. These organizations do not develop standards, but instead describe how standards may be used effectively. Their recommendations are expressed as “profiles” that help assure interoperable use of the CDA.