Hl7

HL7 Review HL7 – stands for Health Level 7 – level seven refers to the top layer of the OSI object model (application layer). HL7 was originally an adhoc group to help standardize the communication between incompatible healthcare applications. Most were interface programmers. Started as v2.0. Current ANSI accepted version is v2.5. Very backward compatible. The HL7 Version 2 Messaging Standard — Application Protocol for Electronic Data Exchange in Healthcare Environments — is considered to be the workhorse of data exchange in healthcare and is the most widely implemented standard for healthcare information in the world. HL7 also responsible for : 1. CCOW - Clinical Context Object Workgroup a. The context is primarily comprised of the identity of real-world things, such as patients, and real-world concepts, such as encounters, that establish the common basis for a consistent set of user interactions with a set of healthcare applications 2. Arden Syntax a. knowledge bases that are represented as a set of discrete modules. Referred to as a Medical Logic Module (MLM), each contains sufficient knowledge to make a single decision. Contraindication alerts, management suggestions, data interpretations, treatment protocols, and diagnosis scores are examples of the health knowledge that can be represented using MLMs. b. Simplified programming language. Allows non professional programmers to create a module. 3. Clinical Document Architecture a. an exchange model for clinical documents, such as discharge summaries and progress notes. Leverages the use of XML, the HL7 Reference Information Model (RIM) and coded vocabularies, the CDA makes documents both machine-readable, are easily parsed and processed electronically, human-readable. 4. Reference Information Model a. Vocabulary Domains b. Jim Cimino is Vocabulary co-chair. Other standards include DICOM (X-rays), X12 (billing), ACPDP (pharmacy) ASTM (clinical). Each standard is published like a book with chapters. Chapter 2 is the chapter on Control, the section that covers how to encode a message. HL7 designed around the assumption that there is a real world event that triggers the exchange of messages. Examples of trigger event is patient admission and ER visit.. When messages are sent, the recipient application returns an “ACK” message. Say to sender, “I got the message”. The ACK means that the recipient accepts responsibility

for the message. Currently standard is recipient sends a “commit/accept” message. Can be in two stages. Need both to assume responsibility. Not implemented. ACK message contain one of 3 codes 1. AA – application accept - “Got it” 2. AE – application error - “it will never work” 3. AR – Application reject – “I can’t handle it now” Message format 1. <SB> = start block (0x0B) 2. = end Block (0x1C) 4. = carriage return (0x0D) Message defined as atomic unit of data transferred. Information sent in segments, each segment separated with “” Messages have message type, a 3 letter code (MSH, EVN, ADT) Messages have a trigger event Messages are encoded as ER7 (pipes, bars, carat, ampersand) or as XML (<patname>) Message Definition rules (how a message is structured) 1. MSH is always first 2. Order is important 3. “[…]” is optional segment 4. “{…}” is repeat segment Receiving rules 1. Ignore extra stuff that is present in the message but is not expected. 2. If something is missing, assume it is not present. NOT THE SAME A NULL VALUE Trigger events in-patient Management 1. A01 admit (bed assigned) 2. A04 visit (no bed assigned) 3. A03 HL7 v3 is under development that is big departure from v2.x. The flexibility of v2.x also makes it impossible to do conformity testing between vendor products. Version 3 addresses these and other issues by using a well-defined methodology based on a reference information (i.e., data) model. It will be the most definitive standard to date. Using rigorous analytic and message building techniques and incorporating more trigger events and message formats with very little optionality, HL7's primary goal for Version 3 is to offer a standard that is definite and testable, and provide the ability to certify vendors' conformance. Version 3 uses an object-oriented development methodology and a Reference Information Model (RIM) to create messages. The RIM is an essential part of the HL7 Version 3 development methodology, as it provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages

A little more about HL7 based on my observations -- ongoing work, activities, opinions, projects, etc. o

Introduction to HL7 tutorial session (taught by David John Marotta from DT7Software) clarified some common misunderstandings. HL7 is as an application protocol for electronic data exchange in health care environments. However, many people consider HL7 as a standard just for messaging in the medical domain. The HL7 tutorial explained that the topics covered by HL7 actually go far beyond messaging. For example, Arden Syntax, CCOW, and CDA are all considered as non-messaging HL7 activities. Moreover, HL7 is not just another standard in the medical domain; rather, it acts like a big umbrella that brings together many other healthcare standards such as DICOM, IEEE P1157 Medix, ASTM E31, etc, to facilitate ordering, and ADT (Admission, Discharge and Transfer) scheduling. Regarding messaging, although HL7 version 2.x has more than ten chapters, the tutorial focused on four of them for general audience: Control and query (Chapter 2), Patient administration (Chapter 3), Orders (Chapter 4), and Observation reporting (Chapter 7).

o

In CDS TC (Clinical Decision Support Technical Committee) and CPG SIG (Clinical Practice Guideline Special Interest Group) Working Group Meetings, Bob Greenes (Harvard U.) gave a presentation on updates of Guideline Expression Language (GELLO) in CDS TC Working Group Meeting. GELLO is an object-oriented guidelines procedural language that includes prototypes of expression and query languages. It is designed to be able to record decision logic of existing MLM in Arden Syntax and facilitate the knowledge modeling. GELLO is incomplete yet, and several issues such as the incorporation of some commands, infix operators, and development of IDE (Integrated Development Environment) for writing expressions, statements and queries still need more work.

o

The joint meeting between CDS TC with EHR (Electronic Health Records) focused on the topic of VMR (Virtual Medical Record). VMR aims to find the minimal set of record types and attributes required to achieve semantic interoperability. On the one hand, the benefits of VMR are: first, it makes it possible to reuse the most expensive parts of DSS (Decision Support Systems) such as Guideline Interpreter software component and knowledge base. Second, it decouples these from terminology or schema changes. Third, it facilitates rapid deployment on new clinical systems. On the other hand, appropriate terminology-mapping knowledge and software components are needed and system vendor might have problems with it when mapping their system into VMR format. The discussion about VMR will keep going on and a possible direction is to develop VMR as a subset of platform-neutral EHR model in future HL7 work.

o

In Vocabulary session, topics reviewed include the historical origins of clinical terminology, the strengths and weaknesses of the present terminology alternatives, and basic characteristics that terminologies need if they are to support sophisticated use and re-use of clinical data. In my opinion, the primary lesson is that terminologies, if they are to be really useful, need to be in the form of ontologies, and that this is the direction that newer terminologies are moving. In terms of RIM (Reference Information Model), the current model of HL7 message content, an important concept “realms” is introduced as an

administrative jurisdiction (country, agency, state). To promote interoperability, HL7 Messages in a particular realm prescribe one terminology code set per one type of message usage. o

In Clinical Guidelines Special Interest Group meeting, SAGE Project presented their goal “to develop a standards based sharable active guidelines environment”. Funded by the U.S. Department of Commerce's National Institute of Technology's (NIST) Advance Technology Program, the three-year, $9.2 million grant will support SAGE to create and distribute electronic clinical guidelines-also known as "best medical practices". The project is led by IDX Systems (Nasdaq: IDXC), with Apelon, Intermountain Health Care, Mayo Clinic, Stanford University, and University of Nebraska as research partners. Stanford, Mayo, IHC and the University of Nebraska will provide clinical and academic expertise in the development of guideline models and knowledge representation. Apelon, which specializes in the application of structured medical vocabularies to clinical information systems, will provide software and terminology services to assist in the development and deployment of the guideline knowledge. The core reference terminologies will be SNOMED, LOINC and RxNORM. Deliverables of SAGE include an interoperable guideline model, an interoperable guideline workbench, and a guideline deployment system.

HL7 Technical Committees:

Architectural Review Board This group supports the HL7 mission to create and promote its standards by helping to assure that the body of HL7 standards and recommendations is internally congruent, consistent with appropriate measures of quality and has been prepared according to the appropriate HL7 methodology. Clinical Context Object Workgroup With an emphasis on the point-of-use of applications, this group supports the HL7 mission to create and promote its standards by developing specifications that enable the visual integration of healthcare applications. Applications are visually integrated when they work together in ways that the user can see in order to enhance the user’s ability to incorporate information technology as part of the care delivery process.

Clinical Decision Support Co-chairs:

Robert Greenes MD PhD Partners Healthcare/Brigham & Women's Hospital Phone: 617-732-6281 Email: [email protected] Robert Jenders M.D. Cedars-Sinai Medical Center Phone: 310-423-2105 Fax: 310-423-0112

Email: [email protected] Ian Purves Sowerby Centre for Health Informatics at Newcastle Phone: +44 (0) 191 256 3100 Fax: +44 (0) 191 256 3099 Email: [email protected] R. Matthew Sailors University of Texas-Houston, Dept. of Surgery Phone: 713.500.6192 Email: [email protected]

The Technical Committee will focus on issues related to single-patient-focused health care decision support messaging. The committee will focus on the development of messages independent of any implementation of clinical logic. The TC will also be responsible for the support and development of Arden Syntax for Medical Logic Systems. The Arden Syntax will serve as a test case in the development of general messaging schemes. The role of this TC is to (a) identify the scope and range of data elements required for the functionality of DS applications, (b) work with other SIGs, TCs, or outside organizations to identify appropriate controlled vocabulary for encoding those data elements, (c) identify or define messages (and objects) required to support the specific information exchange needs of DS applications, both as feeders to DS applications and as output from DS applications.

Control/Query The Control/Query Committee is responsible for defining the details of the message transport services including encoding rules and auxiliary protocols, maintenance of common datatypes, definition of the query framework, and definition of the framework for master files support. Vocabulary Co-Chairs Chris Chute Mayo Clinic/Foundation Phone: 507-284-5506 Fax: 507-284-0360 Email: [email protected]

Paul Frosdick NHS Information Authority Phone: 44-121-3330331 Fax: 44-121-3330334 Email: [email protected]

Stan Huff Intermountain Health Care Phone: 801-442-4885 Fax: 801-442-6996

Ted Klein Klein Consulting, Inc. Phone: 631-924-6922 Fax: 631-924-8718

Email: [email protected]

Email: [email protected]

Objective

To identify, organize and maintain coded vocabulary terms used in HL7 messages. Goal

Provide an organization and repository for maintaining a coded vocabulary that, when used in conjunction with HL7 and related standards, will enable the exchange of clinical data and information so that sending and receiving systems have a shared, well defined, and unambiguous knowledge of the meaning of the data transferred. The purpose of the exchange of clinical data includes, but is not limited to: provision of clinical care, support of clinical and administrative research, execution of automated transaction oriented decision logic (medical logic modules), support of outcomes research, support of clinical trials, and to support data reporting to government and other authorized third parties. To achieve this goal, we will work cooperatively with all other groups that have an interest in coded vocabularies used in clinical computing. Some of the groups that we will seek to work closely with include: standards development organizations, creators and maintainers of vocabularies, government agencies and regulatory bodies, clinical professional specialty groups, vocabulary content providers, and vocabulary tool vendors. Definitions Data element Any data field, component, or subcomponent of HL7. Domain The set of all appropriate values for a data element. For a coded data element, the coded domain is the set of all coded vocabulary items that are appropriate values of the coded data element. Coded Value A coded vocabulary item that is a member of a coded domain. This corresponds to a table entry in existing HL7 tables. Background A. There are at least five types of coded domains referenced by the HL7 standard: 1. Domains whose content is entirely controlled by HL7 committees. This category includes tables that enumerate

trigger events, message types, segment identifiers, format types, event types, etc. 2. Domains where HL7 committees have included incomplete lists of terms or "starter sets" for a given domain. This category includes tables that enumerate sex, marital status, race, ethnicity, order priorities, etc. 3. Domains that have a specific use, but no data elements are defined, and it is assumed that the coded values used would come from one or more available coding systems such as SNOMED International, CPT, ICD-9CM, ICD-10, UMLS Metathesaurus, LOINC, Read codes, NDC codes, etc. This category includes tables that define Universal Service IDs, Observation IDs, Drug ID, Component Drug ID, etc. 4. Domains that fill the value field in an OBX message for a specific Observation ID. It is assumed that the coded terms used would come from one or more available coding systems. For example, if the Observation ID were set to "Red Cell Antibody" the possible values would be Kell, Duffy A, Duffy B, etc. 5. Domains that are referenced in the HL7 standard, but the structure and contents of the tables are assumed to be locally defined. This category includes, user identifiers, codes that represent clinics or facilities, and identifiers for nursing divisions, rooms, beds, etc. B. The same meaning can often be expressed by a single code, or by a combination of codes. For instance, the description of how a laboratory specimen was collected might be indicated by a single term Midstream-clean-catch, or by two terms urine and clean catch. The ability to know how atomic terms are related to molecular terms is critical to the transformation of data in interfaces. This situation is also known as pre vs. post coordination of terms, or as composition-decomposition. C. HL7 tables do not currently exist to support hierarchical inferencing. Hierarchical inferencing would allow a user or process to send an HL7 query message that asked, "Is the patient taking any penicillin type drugs?" Having a common set of hierarchies that can be referenced by decision support modules is a critical need as the work of the decision support SIG progresses. It is proposed that tables be added to HL7 that support this kind of inferencing. These tables would be specifically focused on capabilities needed by HL7 and there would be no attempt to make these tables a comprehensive knowledge base of medicine. D. HL7 messages exist to update "Master Files" across communicating systems. The vocabulary SIG should investigate suitability of using these messages to update coded domains between systems. HL7 Special Interest Groups:

Arden Syntax Co-Chairs:

Robert Jenders M.D. Cedars-Sinai Medical Center Phone: 310-423-2105 Fax: 310-423-0112 Email: [email protected] R. Matthew Sailors University of Texas-Houston, Dept. of Surgery Phone: 713-500-6192 Email: [email protected]

This group supports the HL7 mission to create and promote its standards by maintenance and further development of the Arden Syntax for Medical Logic Systems, a standard for representing and sharing clinical knowledge in procedural format.

Attachments This group supports the HL7 mission to create and promote its standards. The Attachment Special Interest Group standardizes the supplemental information needed to support health care insurance, and other e-commerce transactions. Our purpose is to encourage the use of HL7 for uniform implementation of this supplemental information. An important effort as guided by the Board of HL7 is to work jointly with ASC X12N (Insurance), to assist in the implementation of the Administrative Simplification provisions of HIPAA mandates, to provide on-going support, and to represent HL7 in the HIPAA Designated Standards Maintenance Organization (DSMO) efforts. This SIG coordinates industry input to produce and maintain guides for HL7 messages that can stand alone or be embedded within ASC X12N transactions.

Clinical Guidelines Co-chairs: Robert Greenes MD PhD

Partners Healthcare/Brigham & Women's Hospital Phone: 617-732-6281 Email: [email protected] Samson Tu Stanford Medical Informatics Stanford University Phone: 650-723-6979 Email: [email protected]

The HL7 GLIF initiative is a special interest group of HL7 formed to create the standard for the specification of clinical practice guidelines to facilitate their integration into health care systems, electronic medical records, and a variety of applications. Participation is open to all parties.

Community Based Health Services

The Community Based Health Services (CBHS) is a special interest group of HL7 . The mission of the CBHS-SIG is to support the message development effort for Community Based Health Services within the framework of HL7 Standards, in order to promote adequate information exchange between Community Based and Acute Care service domains. The scope of the CBHS-SIG includes but is not limited to home health, hospice, long term care, mental health and other community based providers.

Conformance This group supports the HL7 mission to create and promote its standards by providing a consistent mechanism to specify conformance via HL7 V2.x message profiles. The Conformance SIG will also act in an advisory role to the HL7 Modeling & Methodology Technical Committee regarding conformance topics.

Clinical Genomics This group supports the HL7 mission to create and promote its standards by enabling the communication between interested parties of the clinical and personalized genomic data. The focus of clinical genomics work is the personalization (differences in individual's genome) of the genomic data and the linking to relevant clinical information.

Electronic Health Records This group supports the HL7 mission to create and promote its standards by defining a high-level architecture to support a variety of interoperability requirements for electronic health records.

Government Projects The goal of the Government Projects SIG is to coordinate the integration of government health informatics requirements into the HL7 standards. The SIG will address Federal, State and local government requirements.

Imaging Integration Imaging Integration collects, reviews, develops and documents use cases, information structures and message content related to ordering and reporting of non-textual data and associated information, including images themselves. Imaging Integration promotes the interoperation of imaging systems, PACS and associated radiological oriented systems with information systems that use HL7.

Java This group will define application programming interfaces (APIs) to HL7 version 3 artifacts for the Java platform. While the group's focus will be the definition of APIs, it will also promote the development of implementations to validate the API, to serve as reference implementations, and as tools. By providing these APIs and promoting implementations, this group will hasten the adoption of HL7 version 3 by healthcare application providers, many of whom want to develop for the Java platform. By doing this

work for the Java platform, the group will also incidentally provide a model for HL7 implementations that assure interoperability in other popular programming languages, further encouraging development of HL7 Version 3-compliant applications.

Laboratory, Automated and Point of Care Testing The goal of the "Laboratory, Automated, and Point of Care Testing SIG" is to meet the needs for communication among automated clinical lab systems, instruments, devices, and information systems in various implementations of clinical lab, point of care, and automated testing by developing interoperable messaging.

Medication Information This group helps to assure that the HL7 messages and models concerning medication related information - including prescribing, dispensing, and administering medication address all of the requirements of the many stakeholders and variations in different countries.

Security and Accountability This Secure Transactions SIG will focus on the use of HL7 in communications environments where there is a need for authentication, encryption, non-repudiation, and digital signature. This group will focus on the mechanisms for secure HL7 transactions and not on standardizing security policies. It will, however, ensure that the mechanisms are present to implement security policies. It will report to HL7 on available options and recommend actions that the organization may take to address these needs. The early activities of the group will include reviewing the work of other standards groups in this area including, but not necessarily limited to, ANSI X3, ASTM, CEN, CPRI, X12, HL7 Germany, U.N. Edifact, and the general Internet community.

Templates This group supports the HL7 mission to create and promote its standards by creating the procedures for creation and management of HL7 Templates. An HL7 template is a data structure, based on the HL7 Reference Information Model, that expresses the data content needed in a specific clinical or administrative context. XML This group supports the HL7 mission through recommendations on use of Extensible Markup Language (XML) standards for all of HL7 's platform- and vendor-independent healthcare specifications.

Question 1. Hospital A has added Information Systems ad hoc. When a department saw a need for a computer app, they made the purchase decision without thought to any other department. As a result they have a hodge-podge of systems. Hospital B also operated the same way. Mega Health Care has decided to buy both hospitals. You have been assigned the job of leading the integration of both hospitals into MegaHealth care. Consider your options on how to accomplish this. Pick your favorite and defend your position. Question 2. You are an Informatics consultant who is brought into a large medical group in order to advise on the group’s IT system. The group has an integrated system from a single vendor that handles all the administrative duties and some clinical information but it is far from a total EMR. The group would like to implement a full EMR. The vendor of the current system cannot give a time frame for when a full EMR implementation will be available. However, they will provide you access to their business object so that you can do a custom add-on. What would you recommend to the group? Question 3. HL7 v2.x is highly backward compatible. This allows great flexibility in messaging between old legacy applications and newer applications. HL7 v3 is a different animal. It is much less flexible based on adherence to a reference model. Describe a scenario in which adherence to v2.x is the preferred answer and why this is the preferred solution. Do the same for v3.