Why hl7 is used

Their prior experience and training include engineering, IT, medical technologies, biology, nursing, and medical practice.

All rely on HL7 to accomplish a specific purpose whether system design or writing a request for purchase. Some students have extensive programming skills while others have limited computer skills. All have the same objective to achieve better healthcare and mastering HL7 is a must for all of them. We are interested in enabling students with diversified backgrounds to quickly learn and use HL7.

The standard documentation is written to be a complete reference, but not necessarily to be easy to read or to be used for quick learning. The HL7 v3 documentation is structured and constructed to be mainly navigated using a browser. The message names as well as the names of the other artifacts are very hard to be remembered by a human.

The presence of hyperlinks allows non-sequential navigation; however, it is very common to get lost especially for a novice reader. Other resources and documentations, such as the primer book [ 4 ], concentrate on the information model along with some general concepts.

They are not very helpful for quickly implementing something useful with the standard, such as exchanging information. On the other hand, active learning is increasingly attracting interest as it enhances learning [ 5 ]. Amongst the various active learning strategies [ 6 ], problem-based learning appears to be well adapted to help us achieve our pedagogical goals in a short time, mitigating the difficulties discussed above.

In this paper, we describe a problem-based strategy to learn the HL7 standard. Following the method of [ 7 ] to guide the design of the learning activities, we present and discuss the problem definition, and the support provided to the students. In the next section, we present our method: problem definition in terms of learning objectives, clinical scenarios, and required work as well as resources to support the learning activities such as clinical data, scaffolding documentation to navigate the standard text, and validation software.

The software used by the students was developed specifically to help those with no software development experience, get familiar and use HL7 v2 and v3 in a short time. First, we defined the problems that enable achieving the learning outcomes and engage the students in activities presenting challenges from the real world.

We defined two complex problems articulated around clinical scenarios. The first scenario is taken from a radiology environment and is used to learn HL7 v2. In addition to the main learning outcome, which is getting familiar with the HL7 standard, we articulated the problems to achieve secondary larger objectives: 1 introducing interoperability, 2 and getting familiar with EHR workflows.

Second, we developed the support material to enable active learning. Several criteria have guided this development: 1 the learning objectives need to be achieved by students with no programming skills; therefore, we have developed a complete software infrastructure allowing students to concentrate strictly on data and information. This is the opposite of how normally HL7 is presented as we did not cover the complete data model.

In the following sub-sections, we present the clinical scenarios. For each scenario, we describe and discuss 1 the learning objectives, 2 the clinical data provided to the students, 3 the scaffolding introduction to the HL7 standard, 4 the work required from the students, and 5 the software that was provided to the students to help them achieve their work.

A typical scheduled radiology image acquisition is performed upon receiving an order from an order placer system. The order message is an HL7 Order Message ORM that communicates the patient demographics and the ordering physician information, as well as information about the imaging procedure to be performed.

When the imaging acquisition equipment is integrated with the RIS, a modality worklist query, using the DICOM standard, is sent from the acquisition equipment to the RIS in order to obtain a list of imaging acquisition steps to perform. The human operator at the acquisition equipment console typically chooses one item from the list and performs the imaging acquisition on the patient. The worklist fields are initially copied from the received ORM.

After the acquisition is completed, the radiologist interprets the image and generates a diagnostic report [ 8 ] that may be communicated to a third-party system by means of an HL7 Observation Result ORU message. The data flow of this simplified radiology process is depicted in Fig. The interpretation step needs the image in order to generate the results. The order, the image, and the result all correspond to the same radiology process and belong to the same patient.

Therefore, they need to contain the same patient and procedure information. This later objective introduces the student to the larger domain of interoperability and the consistency of information. We ask them to generate:. After pointing to the students where to get the standard documentation [ 9 ], we explore all functional domains covered by the standard by quickly browsing its various chapters.

Following this overview, a sample message—registering a new patient—is examined in detail in order to grasp the encoding syntax: segments, segment delimiter, segment name, special header segment MSH , special event segment EVN , fields, field separator, and field numbers. Sub-components and their separator are introduced by examining an example of an observation request segment OBR and by studying the Principal Result Interpreter field OBR. Special attention is given to the MSH segment and its fields.

The response message is introduced and the structure of the acknowledgement message ACK is detailed. This quick introduction is achieved by browsing the standard documentation and by analyzing samples of real messages. They have to manually write both messages using information available in the header of a single DICOM image that is provided to them.

The messages generated by students need to contain semantically meaningful information that is consistent with the medical image. Students can use the software that is also provided to them in order to validate their work and to correct any data inconsistency that is detected by the validation software. We provide the students software that was built specifically to help them succeed with the required task.

The software is built using open-source libraries. The software is executed by the students as a simple command that takes three input files in a specific order: the HL7 messages and the image. It displays the result of the verification to the students in a tabular form where each row contains the data that is supposed to be consistent from the three sources.

Obviously, to succeed in this work, students do not need any software development skills. A patient may be identified with several identification numbers, when known to a multi-site facility or at a regional level.

Therefore, the EHR infrastructure comprises a system that is responsible for identifying a patient described with a combination of demographic parameters or with an identification number local to a specific institution. Identifying a patient requires querying this system using a HL7 v3 transaction. The objective is to become familiar with the HL7 v3 message structure and documentation as well as with several IHE integration profiles that are defined and detailed in the IHE Infrastructure Technical Framework, more specifically, the integration profiles that are needed to search for a patient in an EHR.

We point out to the students how to acquire the latest version of the HL7 standard [ 9 ]. The standard documentation is so large that one can get quickly lost. We introduce a top-down approach to navigate it: the functional domains are presented first; then we study a specific message in detail; we analyze its structure and we examine the data types that compose the message. We do not explore the complete data model nor all data types; to the contrary, we cover only what is needed to construct a specific message.

Our strategy is to learn the standard by constructing a message. One can get back to it when a detailed definition or explanation is needed.

The HL7 standard v3 defines messages that are used to exchange information in many domains such as patient administration, pharmacy, laboratory, immunization, reimbursements, reporting, and scheduling. Each domain is covered by a chapter. This is the chapter that we use to introduce the HL7 structure, messages, and data model. To construct a message, a D-MIM is not needed in its entirety. We encourage the students to come back to this section and search for the definition of concepts and their relationships, when needed.

We are interested in registering a new patient. Obviously, the name of this artifact is not human friendly. It defines the classes, the attributes, and the associations needed to construct the message of interest.

The HMD constitutes the content of the message content or its payload. It can be represented in various equivalent ways: graphical, tabular, or XML schema. At this stage, students are encouraged to build a message using a specialized XML editor and the message schema. To send a message, it needs to be wrapped with control and transmission information. The transmission wrapper includes information to assemble and send the interaction to a receiving application. It also specifies the level of acknowledgement that is expected from the receiving system.

We focus on the levels recommended by IHE: the accept-level acknowledgement and the immediate response for a query response. These standards define how information is packaged and communicated from one party to another, setting the language, structure and data types required for seamless integration between systems.

HL7 standards support clinical practice and the management, delivery, and evaluation of health services, and are recognized as the most commonly used in the world.

For more information about the HL7 standards process, please read Understanding the Standards Process. HL7 standards are grouped into reference categories: Section 1: Primary Standards - Primary standards are considered the most popular standards integral for system integrations, inter-operability and compliance. Our most frequently used and in-demand standards are in this category.

Share Related Blogs Stephan Rubin. FHIR Fast Healthcare Interoperability Resources was initially envisaged purely as an interoperability standard, but as its use has grown and the community has grown, it has expanded into other parts of healthcare.

According to the Office of the National Coordinator for Information Technology ONC , nearly 95 percent of hospitals and 90 percent of office-based physici. Skip to content Blog Category. Lyniate Team What is HL7? April 3, Another layer of problems arises when two healthcare providers need to share information. These are the primary standards and possibly the most popular among the categories.

Section Two : States the foundational standards that users can build and helps define the standards and technology infrastructure they plan to use. Section Three : Helps link messaging and document standards for providers.

Section Four : Details how electronic health records EHR are constructed and managed using profiles and models. Section Five : Outlines the methods used for implementation and includes support documents for other categories. This section may also serve as the supplemental section for other standards categories.

Section Six : Explores the rules and references used to develop programming structures for software and aids in standards development as well.