HL7 interfaces are used to connect different health IT systems. HL7 interfaces allow data to be exchanged between systems, allowing information to flow in both directions. They can also send messages and receive them. For example, one system may send a patient’s medical record to another for billing purposes.
What does HL7 mean in healthcare?
Active Learning of the HL7 Medical Standard Department of Electrical Engineering, École de Technologie Supérieure, 1100 Notre-Dame West, Montreal, QC H3C 1K3 Canada Find articles by © The Author(s) 2018 Open Access This article is distributed under the terms of the Creative Commons Attribution 4.0 International License (http://creativecommons.org/licenses/by/4.0/), which permits unrestricted use, distribution, and reproduction in any medium, provided you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons license, and indicate if changes were made.
- Health Level Seven (HL7®) is a standard for exchanging information between medical information systems.
- It is widely deployed and covers the exchange of information in several functional domains.
- It is very important and crucial to achieve interoperability in healthcare.
- HL7 competences are needed by all professionals touching information technology in healthcare.
However, learning the standard has always been long and difficult due to its large breadth as well as to large and complex documentation. In this paper, we describe an innovative active learning approach based on solving problems from real clinical scenarios to learn the HL7 standard, quickly.
- We present the clinical scenarios used to achieve learning.
- For each scenario, we describe and discuss the learning objectives, clinical problem, clinical data, scaffolding introduction to the standard, software used, and the work required from the students.
- We present and discuss the results obtained by implementing the proposed approach during several semesters as part of a graduate course.
Our proposed method has proven that HL7 can be learned quickly. We were successful in enabling students of different backgrounds to gain confidence and get familiar with a complex healthcare standard without the need for any software development skill.
- Eywords: Active learning, Healthcare, Medical informatics, HL7 standard, Problem based, Learning, Interoperability The Health Level Seven (HL7®) standard is very important to achieve interoperability in healthcare.
- It is widely used for communicating medical information between various information systems ; it is therefore a cornerstone to implement the Electronic Health Record (EHR).
EHR improves healthcare decisions by allowing access to the patient’s relevant clinical information at the decision-making point. EHR is a distributed system that results from the interactions and cooperation of various independent information systems to achieve a specific healthcare process.
Therefore, deploying EHR requires the successful exchange of information between several systems. Without HL7, there is no interoperability and no EHR. Although HL7 is crucial for achieving EHR, learning it has been achieved ad hoc, after long exposure to interoperability problems, sometimes combined with specialized training provided outside of the academic structure.
By introducing HL7 in a graduate course on distributed systems in healthcare, we have faced several problems. These problems are the following: (1) the domain is multidisciplinary, (2) the breadth of required healthcare processes knowledge is large, (3) the standard documentation is huge and formal introductory texts are not available, (4) the students’ background is extremely diversified.
HL7 is at the intersection of healthcare, engineering, and Information Technology (IT). It covers almost all functional domains encountered in healthcare including patient management and administration, order management, and observation reporting. In order to achieve interoperability, many other standards are needed.
Some are not specific to healthcare such as the ones that pertain to security or to indexing. Others are specific to healthcare such as the Digital Imaging and Communication in Medicine (DICOM). All these standards are used in practice. Their cooperation is defined either site-specifically, or according to formal international integration profiles described by the Integration Healthcare Enterprise (IHE),
Several versions of the HL7 standard exist. HL7 v2 is largely implemented and deployed in almost every healthcare hospital or clinic. HL7 v3 is adopted by many governments and agencies as a standard required for EHR and is used in many of the IHE integration profiles, HL7 has very recently proposed a new framework, the Fast Healthcare Interoperability Resources (FHIR®), which combines features of HL7 v2 and HL7 v3 with the latest web technologies such as the Representational State Transfer (REST) architecture to facilitate implementation.
All versions co-exist and it is common to have several versions of the standard deployed simultaneously and cooperating at the same institution. HL7 is needed by almost every professional involved with healthcare processes. Knowing HL7 is needed by engineers not only to design and implement interoperable medical systems but also to maintain them.
It is needed by clinicians and IT specialists to implement healthcare workflows. Administrators need HL7 to manage the purchase processes of such systems. Companies need HL7 to develop, test, and deploy healthcare systems. It is needed by hospitals and clinics to purchase their clinical applications and to manage and maintain them.
HL7 is also needed by governmental agencies so they can provide specifications and regulations to enable the integration of healthcare information at the regional and national levels. This large range of dependence on HL7 is reflected in the students’ background.
- 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, 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, Amongst the various active learning strategies, 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 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.
- Results from our experience teaching both versions of the HL7 standard are presented and discussed in the “” section.
- We also describe students’ interests and results.
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.
- The second scenario is taken from an EHR environment and is used to learn HL7 v3.
- 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.
- 2) Students’ confidence regarding the navigation of the complex and large standard documentation needs to be increased; therefore, we have developed a scaffolding document describing how to read and navigate strictly those parts of the standard needed to successfully solve the problems.
- This is the opposite of how normally HL7 is presented as we did not cover the complete data model.
(3) Students’ confidence regarding their ability to successfully complete the educational work needs to be increased; therefore, we developed validation software that provided feedback to students and helped them self-assess their work. 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.
- The ORM is received by the Radiology Information System (RIS) that generates a modality work item on its worklist.
- 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. It results in the generation of a DICOM image whose patient’s demographic and procedure information are automatically copied from the modality worklist fields into the DICOM image header.
- The worklist fields are initially copied from the received ORM.
- The mapping between the ORM fields and the image DICOM header fields are detailed in the IHE technical framework,
- After the acquisition is completed, the radiologist interprets the image and generates a diagnostic report that may be communicated to a third-party system by means of an HL7 Observation Result (ORU) message.
In addition to the patient’s demographic and procedure fields, the ORU message contains the impressions and interpretation of the radiologist. The data flow of this simplified radiology process is depicted in Fig. The acquisition step needs the patient’s demographics and procedure information in order to generate an image.
How does HL7 integration work?
Instead of the Last Word – Are you still hesitating whether you need healthcare data integration standards? They are a must if you aim to ensure interoperability, streamlined health data collection and exchange, better decision-making, improved patient treatment, and cost-efficiency.
When opting for HL7 integration, you can use several approaches to tackle this task. You may want to implement these standards through available APIs or interface engines or build a custom HL7 interface. Developing a custom HL7 interface undoubtedly requires experts in this niche. In case you’re looking for some, Softermii has got you covered.
With our proven record of successful healthcare projects using HL7, some of which include and, our team can effortlessly deliver HL7 interfaces for you. Feel free to for more details. Our company often uses HL7 interface standards in the development of healthcare products, and can with you. First of all, the HL7 integration can be a complex, costly, and time-consuming process. It requires tracking every healthcare system you aim to integrate your interface with to ensure full compatibility.
Another challenge you may face is inconsistent data semantics before HL7 implementation, which may cause misinterpretation. The HL7 interface standards help medical facilities access standardized data from various healthcare systems. They also allow for smooth data collection and sharing between hospitals, doctors, and patients.
Such interfaces serve as a viable solution for increasing interoperability between various medical organizations. Yes, you can use HL7 integration engines. They offer reasonable pricing and allow for fast deployment. You should opt for HL7 software integration services to establish a proper data collection and transfer process.
Experienced developers will help you segment your data and ensure the seamless connection of various electronic health systems. Custom HL7 interface standards offer extensive flexibility and scalability, and you can make them compatible with any healthcare system. They also allow for advanced data governance.
Standard HL7 interfaces come with plenty of helpful features, yet they need to catch up when it comes to customization. : HL7 Integration: Use Cases & Implementation Benefits
What protocol does HL7 use?
HL7 messages are sent via a variety of TCP/IP transports, some of which include: LLP (Lower Layer Protocol) FTP (File Transfer Protocol) SOAP (Simple Object Access Protocol)
Is HL7 a data format?
HL7 Messages are used to transfer electronic data between disparate healthcare systems, each sending information about a particular event such as a patient admission. HL7 messages are in human-readable (ASCII) format, though they may require some effort to interpret.
Which data type is HL7?
HL7 data types define the kind of data that can be included in a field, and are used throughout the HL7 message structure. Examples would be a string, formatted text, timestamp, address, or coded element. Each data type may contain additional data types that are referenced as components or subcomponents.
Complex data types use other data types to define the kind of data they can contain. Certain data types cannot reference each other due to the nature of the components. For instance, a data type cannot reference data types that already reference multiple components, because there is no way to code the information at that level.
Below is a list of the HL7 data types:
| DATA TYPE CATEGORY/ DATA TYPE | DATA TYPE NAME |
|---|---|
| Alphanumeric | |
| ST | String |
| TX | Text data |
| FT | Formatted text |
| Numerical | |
| CQ | Composite quantity with units |
| MO | Money |
| NM | Numeric |
| SI | Sequence ID |
| SN | Structured numeric |
| Identifier | |
| ID | Coded values for HL7 tables |
| IS | Coded values for user-defined tables |
| HD | Hierarchic designator |
| EI | Entity identifier |
| RP | Reference pointer |
| PL | Person location |
| PT | Processing type |
| Date/Time | |
| DT | Date |
| TM | Time |
| TS | Time stamp |
| Code Values | |
| CE | Coded element |
| CF | Coded element with formatted values |
| CK | Composite ID with check digit |
| CN | Composite ID number and name |
| CX | Extended composite ID with check digit |
| XCN | Extended composite ID number and name |
| Generic | |
| CM | Composite |
| Demographics | |
| AD | Address |
| PN | Person name |
| TN | Telephone number |
| XAD | Extended address |
| XPN | Extended person name |
| XON | Extended composite name and ID number for organizations |
| XTN | Extended telecommunications number |
| Specialty/Chapter specific | |
| CD | Channel definition |
| MA | Multiplexed array |
| NA | Numeric array |
| ED | Encapsulated data |
| CP | Composite price |
| FC | Financial class |
| Extended Queries | |
| QSC | Query selection criteria |
| QIP | Query input parameter list |
| RCD | Row column definition |
| Master Files | |
| DLN | Driver’s license number |
| JCC | Job code/class |
| VH | Visiting hours |
| Medical Records/Info Mgmt | |
| PPN | Performing person time stamp |
| Time Series | |
| DR | Date/time range |
| RI | Repeat interval |
| SCV | Scheduling class value pair |
| TQ | Timing/quantity |
Is HL7 a database?
In a typical HL7 database, the structure may include tables for storing patient demographic information, laboratory results, clinical notes, medication orders, and other types of health information.
Does HL7 use HTTP?
2.0 – Specification – HL7 over HTTP uses the standard HTTP/1.1 protocol ( RFC 2616 ) as a mechanism to transfer a raw HL7 message using standard HL7 encoding (i.e. “vertical bar” or XML) encoding to a destination, and then to receive a response to that message.
Does HL7 use TLS?
Some HL7 integration engines support using LLP with the SSL or TLS cryptographic protocol. This is the standard developed and supported by Integrating the Healthcare Enterprise (IHE).
What port does HL7 use?
Use port 5555 where the port number is not provided. Check the Acknowledge receipt checkbox to enable indications that HL7 messages are received. Within the Outgoing Partner IP field, set the IP address and port number specified by the HL7 company.
What does the 7 stand for in HL7?
HL7 (Health Level Seven International) is a set of standards, formats and definitions for exchanging and developing electronic health records (EHRs ). HL7 standards, developed and promulgated by the healthcare IT standard-setting authority HL7 International are the de facto standards in healthcare IT, though some HL7 users have called on Congress to create stronger legal interoperability standards for the healthcare IT industry.
A nonprofit organization with members in more than 50 countries, HL7 was founded in 1987 and accredited by the American National Standards Institute in 1994. It develops new standards using a multi-year balloting system in which members vote and add commentary in successive balloting rounds until negative comments are eliminated and draft standards and draft standards for trial use (DSTU) are commonly agreed upon.
HL7 also promotes global interoperability in healthcare IT by providing guidance about how to implement its standards. The “7” in the organization’s name refers to Layer 7 in the Open Systems Interconnection (OSI) reference model. Layer 7 is the final layer – the application layer – in the communication model the International Organization for Standardization developed for OSI.
Health Level 7 standards define and provide formats for messaging and data exchange, decision support, rules syntax and common health data definitions in clinical documents and EHR and personal health record (PHR) claims attachments, quality reporting, product labels for prescription medications and clinical genomics.
Several HL7 standards – including Clinical Document Architecture (CDA) and Continuity of Care Document (CCD) – are referenced in federal regulations associated with the U.S. Department of Health and Human Services ‘ program for meaningful use of electronic health records.
HL7 Version 2, the most widely used messaging standard for exchange of patient care and clinical information. It is a database query language that enables healthcare providers to send messages requesting and containing health data. CDA, an ISO-approved standard that constitutes an exchange model for clinical documents such as discharge summaries and progress notes. Associated with the CDA are the CCD, a record of patient discharge and admission among separate facilities, and the Consolidated CDA (C-CDA), which is used in ONC meaningful use -certified EHRs to consolidate nine previous CDA templates into one document. EHR-PHR System Functional Models provide common language parameters for developing EHR systems and their components. The PHR Functional Model is a draft standard for functions that should be in a PHR and for data exchange between PHRs and EHRs. Fast Health Interoperability Resources (FHIR), a DSTU that underwent its first balloting round in spring 2015. It is a Web-based exchange language that makes interoperable healthcare applications faster, simpler and easier to write.
This was last updated in June 2015
What is the difference between HL7 and API?
API is More Efficient & Secure – APIs define security rules and transmissions more clearly and easily, enabling better connectivity between EHRs and other platforms. This helps EHR platforms avoid siloing their data in closed infrastructures and encourages seamless data integration with third parties.
APIs are also far more efficient as they allow data consumers to request information “on-demand”, as opposed to the HL7 model of subscribing to a feed that shares all data, regardless of whether it is immediately needed or not. By pulling data only when needed, the amount of information sent back and forth is reduced and focused on the task at hand.
This, in turn, helps systems implement a “principle of minimum access”, not taking on more PHI than is absolutely required. The API approach also lets the requester authenticate as a specific user, providing accountability and transparency as to which specific user-requested or accessed a given piece of PHI. 
The Adoption of APIs in The World of EHRs APIs are seeing increased adoption across the healthcare industry, particularly among newer entrants like Amazon and Apple. And the adoption will continue to become more widespread with the new FHIR (Fast Healthcare Interoperability Resources) standards and CMS (The Centers for Medicare and Medicaid Services) including APIs in its path towards overhauling Meaningful Use.
In the last couple of years, there’s been an increasing push of larger EHR vendors such as athenahealth, Greenway, and Allscripts stepping back from attempting to offer every single service themselves. They’re emulating retail commerce models like Target, who don’t attempt to re-invent the coffee shop within their stores, but rather partner with Starbucks, who are the experts in coffee.
SMART on FHIR – Apps for Healthcare
Similarly, these EHR vendors recognize that they reign supreme on the clinical side of data management, but invite smaller specialty partners like Surgimate to provide high-quality add-ons in their own sphere of excellence. By building their own proprietary API into their platforms, these EHR companies are creating healthcare app marketplaces that present the best of breed surgical and medical apps across the board.