HL7 Survival Guide - Chapter 12 – Definitions
Download as PPTX, PDF1 like658 views
Chapter 12 of the HL7 Survival Guide focuses on key definitions related to HL7 standards, including concepts like anonymization, data types, and message encoding. The chapter emphasizes the importance of clear communication between different healthcare systems through standardized messaging protocols to improve data exchange. It also provides an overview of Caristix software, which streamlines interfacing processes in healthcare organizations.
HL7 Survival Guide - Chapter 12 – Definitions
- 1. HL7 SURVIVAL GUIDE CHAPTER 12 A supplement to the HL7 Survival Guide, available at http://caristix.com/blog/category/hl7-survival-guide/ A publication of
- 2. HL7 SURVIVAL GUIDE CHAPTER 12 ABOUT CARISTIX Caristix software brings your whole interfacing process together in a single, powerful platform. CUT TIME-TOGO-LIVE NO MORE TRIAL AND ERROR Up to 50%. Scope it right. Manage requirements. VENDORAGNOSTIC Work with any interface engine. CLEAR YOUR INTERFACING BACKLOG Simplify dramatically. Align teams. REQUEST A DEMO http://promo.caristix.com/demo/ WWW.CARISTIX.COM DECK SHARE THE SLIDE 2
- 3. CHAPTER 12: Definitions WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 4. HL7 SURVIVAL GUIDE CHAPTER 12 Definitions WWW.CARISTIX.COM DECK SHARE THE SLIDE 4
- 5. HL7 SURVIVAL GUIDE CHAPTER 12 5 Definitions: A - C • Anonymization This is another way of saying “de-Identification” where all sensitive data is removed. See definition in the following slides. • Code set Also referred to as HL7, vocabulary or code table. It is a list of codes and their meanings used to codify information included in HL7 messages. Codes could be defined by the HL7 standard itself or information systems. For instance, here is the list of suggested values for patient gender as proposed by HL7 v2.6. Code Value M Male F Female U Unknown A Ambiguous O Other N Not Applicable WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 6. HL7 SURVIVAL GUIDE CHAPTER 12 Definitions: C - D • Component The basic building block used to construct a data type. In the case of complex data types, each data element is a component. Example: Patient Family Name (PID.5.1) is a component of Patient Name (PID.5) • Conformance profile A description of the data and messages that an interface sends and/or receives. The description covers the data format, data semantics and acknowledgment responsibilities. The description must be clear and precise enough so that it can act as a set of requirements for data exchange. • Data Type From the Health Level Seven International (HL7) official site: “The basic building block used to construct or restrict the contents of a data field.” In other words, a data type will describe the format of field data elements (components). Example: Personal names are constructed using several pieces of information and should maintain the same structure across the board. The XPN data type describes such structure. WWW.CARISTIX.COM DECK SHARE THE SLIDE 6
- 7. HL7 SURVIVAL GUIDE CHAPTER 12 7 Definitions: D - E • De-Identification De-Identification occurs when all identifiers and quasi-identifiers (IDs, names, addresses, phone numbers, genders, etc.) are removed from the information set. This protects patient identity while most of the data remains available for sharing with other people/organizations, or for related uses. • ER7 Encoding This is a representation of an HL7 message using message, segment, field, component and sub-component delimiters. This encoding is usually referred to as a “pipe delimited” message. Example in Ch.12 of the HL7 Survival Guide PDF download WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 8. HL7 SURVIVAL GUIDE CHAPTER 12 8 Definitions: F - G • Field According to Health Level Seven International (HL7), a field is a string of characters. Fields for use within HL7 segments are defined by HL7. A field is the basic building block used to construct a segment. By default, fields are delimited by the “|” character (see the above example) and are built with one or more components. • Gap analysis Gap analysis is the phase in a deployment project where analysts map the data elements between the product they are installing to the elements in the hospital’s existing information systems therefore detailing the gaps existing between the two sources. The result is usually a list of differences between data definitions. This list should then be used to configure/develop data transformation routines. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 9. HL7 SURVIVAL GUIDE CHAPTER 12 9 Definitions: H • HL7 HL7 is an international community of healthcare subject matter experts and information scientists collaborating to create standards for the exchange, management and integration of electronic healthcare information. The name "Health Level-7" is a reference to the seventh layer of the ISO OSI Reference model, also known as the application layer. Hospitals and other healthcare provider organizations typically maintain many different computer systems for everything from billing records to patient tracking. All of these systems should communicate with each other (or "interface") when they receive new information but not all do so. HL7 specifies a number of flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with each other. Such guidelines or data standards are a set of rules that allow information to be shared and processed in a uniform and consistent manner. These data standards are meant to allow healthcare organizations to easily share clinical information. Theoretically, this ability to exchange information should help to minimize the tendency for medical care to be geographically isolated and highly variable. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 10. HL7 SURVIVAL GUIDE CHAPTER 12 10 Definitions: H (full definitions with examples here) • HL7-XML Encoding This is a basic XML representation of an HL7 message where XML elements represent HL7 messages constructs like segments, fields and components. The other allowed encoding is ER7. Example:(view in Ch.12 of the HL7 Survival Guide) • HL7 v2.x Message (source) HL7 version 2 defines a series of electronic messages to support administrative, logistical, financial and clinical processes. The v2.x standards are backward compatible (e.g., a message based on version 2.3 will be understood by an application that supports version 2.6). Sample of a v2.2 message with customized segments: (view in Ch.12 of the HL7 Survival Guide) WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 11. HL7 SURVIVAL GUIDE CHAPTER 12 11 Definitions: H - I • HL7 v3 Message V3 is the latest version of the HL7 message standard. It is not backward compatible with the v2.x standard. Instead it implements a completely new top-down design approach based on the Reference Information Model (RIM) for better consistency and extensibility. HL7 v3 messages are XML documents exchanged between systems. Tags are defined through a suite of modeling mechanism. We see some adoption of this message standard around Clinical Document Architecture (CDA). However, most systems continue to exchange data using v2.x messages. • Integration engine Middleware built specifically to connect systems by using a standard messaging protocol. The integration engine is responsible for mediating protocols, orchestrating message workflow, transforming message formats and guaranteeing message delivery. Integration engines simplify system interoperability by allowing message feed management. In other words, you don’t need to manage system-to-system connection. Instead, messages are sent to the integration engine. Messages will be forwarded to any system(s) meant to receive those messages. If needed, transformation can be applied so a message is translated to the expected message format. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 12. HL7 SURVIVAL GUIDE CHAPTER 12 12 Definitions: I • Interface Hospitals and other healthcare provider organizations typically maintain many different computer systems for everything from billing records to patient tracking. All of these systems should communicate with each other (or "interface") when they receive new information but not all do so. HL7 specifies a number of flexible standards, guidelines, and methodologies by which various healthcare systems can communicate with each other. Such guidelines or data standards are a set of rules that allow information to be shared and processed in a uniform and consistent manner. These data standards are meant to allow healthcare organizations to easily share clinical information. Theoretically, this ability to exchange information should help to minimize the tendency for medical care to be geographically isolated and highly variable • Integration as a Service Based on the SaaS model, this is a delivery model where a provider provides all required infrastructure to interface systems. Usually, instead of charging for licenses and hardware, the provider will charge per message. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 13. HL7 SURVIVAL GUIDE CHAPTER 12 13 Definitions: M - P • Message A message is the atomic unit of data transferred between systems. In the HL7 world, it comprises a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example the ADT Message type is used to transmit portions of a patient's Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies its type. • Optionality According to Health Level Seven International (HL7), optionality refers to whether the field, segment or segment group is required, optional, or conditional in a segment. • Point to point Direct integration between two systems where system A and system B directly exchange information without an intermediate system or middleware. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 14. HL7 SURVIVAL GUIDE CHAPTER 12 14 Definitions: P - R • Pseudonymization This process replaces data-element identifiers and quasi-identifiers with new data elements so that the relationship to the initial object is replaced by a completely new subject. After the substitution, it is no longer possible to associate the initial subject with the data set. In the context of healthcare information, we can “pseudonymize” patient information by replacing patient-identifying data with completely unrelated data. The result is a new patient profile. The data continues to look complete and the data semantics (the meaning of the data) is preserved while patient information remains protected. • Repeatability According to Health Level Seven International (HL7), repeatability refers to whether the segment or field may repeat. The value set is the maximum number of allowed occurrences; if unspecified, there is only one occurrence, i.e., it cannot repeat. WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 15. HL7 SURVIVAL GUIDE CHAPTER 12 15 Definitions: S • Segment A segment is a logical grouping of data fields. Segments of a message may be required or optional. They may occur only once in a message or they may be allowed to repeat. Each segment is given a name. For example, the ADT message may contain the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1). Two or more segments may be organized as a logical unit called a segment group. A segment group may be required or optional and might or might not repeat. As of v 2.5, the first segment in a newly defined segment group will be required to help ensure that un-parsable messages will not be inadvertently defined. This required first segment is known as the anchor segment. • Sub-Component The basic building block used to construct a component. In the case of complex data types using complex data type as components, each data element of the component is a sub-component. Example: Patient Own Surname (PID.5.1.1) is a sub-component of Patient Name (PID.5) WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 16. HL7 SURVIVAL GUIDE CHAPTER 12 16 Definitions: T Trigger event • Health Level Seven International (HL7) defines a trigger event as “A real-world event creating the need for data to flow among systems. For example, the trigger event a patient is admitted may cause the need for data about that patient to be sent to a number of other systems. The trigger event, an observation (e.g., a CBC result) for a patient is available, may require that observation to be sent to a number of other systems. When the transfer of information is initiated by the application system that deals with the triggering event, the transaction is termed an unsolicited update.” WWW.CARISTIX.COM DECK SHARE THE SLIDE
- 17. HL7 SURVIVAL GUIDE CHAPTER 12 UP NEXT: CHAPTER 13 • Chapter 13 in the HL7 Survival Guide: Resources and Contributors – A reference including the resources and contributors used in developing the HL7 Survival Guide. – Blog link: http://caristix.com/blog/2013/06/hl7-survivalguide-chapter-13/ WWW.CARISTIX.COM DECK SHARE THE SLIDE 17
- 18. HL7 SURVIVAL GUIDE CHAPTER 12 QUESTIONS? FEEDBACK? Is a recommendation unclear? Disagree with something we said? Let us know! We thrive on feedback. Contact Us support@caristix.com 1-877-872-0027 WWW.CARISTIX.COM DECK © Caristix 2013. All rights reserved. SHARE THE SLIDE 18