HL7 V2.4 Style Guide
ANSI/HL7 V3.0-2001
August, 2001
HL7 V3 Standard:
Backbone, Draft 2.0,
June 2001
Editor: Kathy Blyler
Copyright© 2001 by Health Level Seven,® Inc. ALL RIGHTS RESERVED The reproduction of this material in any form is strictly forbidden without the written permission of the publisher.
Health Level Seven and HL7 are trademarks of Health Level Seven, Inc.
Table of Contents
ANSI/HL7 V3.0-2001 AUGUST, 2001 1
HL7 V3 Standard: Backbone, Draft 2.0, 1
June 2001 1
Table of Contents 2
Welcome 5
Introduction 7
Mission 7
What is HL7? 7
Need for Standards 7
Background 8
GOALS OF THE STANDARD 9
HISTORY OF HL7 DEVELOPMENT 10
Overview 12
Scope 12
Relationship to other protocols 12
Contact Us 13
V3 Introduction 13
Why a Major New Version? 13
Difficulties with the Existing Process 14
Opportunities to Improve 14
Version 3 Principles 14
What's New with HL7 V3? 17
Managing HL7 V3 Message Development 18
Project Scope Definition 18
HL7 V3 Methodology 18
Quality Assurance Process 19
Process Support 20
Management 20
HL7 V3 Ballot Instructions 21
Introduction 21
Ballot Section Options 21
V3 Voting Procedures 22
Ballot Symbol Key 23
Quick Start 25
Introduction 25
HL7 V3 Publication Components 26
Getting StarteD 28
Introduction 28
New Implementer 28
New Implementer 28
Learn the Basics 28
Management 29
Manager 29
Project Manager 29
Marketeer 29
Construct Site Agreement 30
Sign a Deal 30
Interface Developer 30
Interface Analyst 31
Interface Programmer 31
Develop Interface 31
HL7 Standard Developer 33
Standard Developer 33
Develop the Standard 33
Glossary 35
Welcome
WELCOME TO THE HL7 V3 STANDARD SPECIFICATION! THESE PAGES WILL GUIDE YOU THROUGH THE NEXT GENERATION OF HL7 STANDARDS. THIS COMPREHENSIVE GUIDE PROVIDES ALL THE INFORMATION YOU NEED TO UNDERSTAND, BUILD, SELL OR BUY HL7 V3 COMPLIANT SYSTEMS WITH EASE AND CONFIDENCE.
The HL7 V3 Standard Specification is intended for anyone interested in learning about the HL7 V3. Don't forget to look at the Getting Started section for tips to help pinpoint the documents (and even the chapters within those documents) that enable you to gather the HL7 V3 knowledge base you need to succeed in health industry computing.
The HL7 V3 Standard Specification is actually comprised many separate documents. The document you are currently reading is the HL7 V3 Publication Backbone. This backbone contains:
|HL7 Introduction |The Introduction section provides an overview of the HL7 Organization, its mission and |
| |philosophy. Also included is a history regarding the growth and development of the HL7 |
| |Standard. |
|HL7 V3 Introduction |The HL7 V3 Introduction section provides a high level overview of the HL7 V3 Message Develop |
| |Process. This section is your first introduction into HL7 V3. Review this section to |
| |understand what HL7 V3 is, why we developed HL7 V3, and the principles underlying the V3 |
| |Standard. |
|HL7 V3 Ballot Instructions |The HL7 V3 Ballot Instructions section provides the information necessary to complete the HL7 |
| |V3 ballot. If you plan to submit ballot comments, be sure to review this section. This |
| |section is a temporary section that will only be included during the V3 ballot cycle. |
|Quick Start |The Quick Start section provides direct links to each of the documents included within the HL7 |
| |V3 Standard Specification. This section provides only a description of each document along |
| |with the link. If you are already familiar with the HL7 V3 Standard Specification, use this |
| |section. |
|Getting Started |The Getting Started section provides guidelines for what documents you should read based on |
| |your role. Look for the actor that most closely correlates to your business role. Each use |
| |case identifies the recommended materials you should review. |
|Glossary |The Glossary section contains a comprehensive list of terms and acronyms used throughout the |
| |HL7 V3 Specification. |
Figure 1 below depicts the HL7 V3 Publication Backbone in graphical form.
Figure 1 - HL7 V3 Publishing Backbone
Introduction
MISSION
To provide standards for the exchange, management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.
What is HL7?
Health Level Seven (HL7) is one of several ANSI-accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data.
HL7 is a not-for-profit volunteer organization. Its members - providers, vendors, payers, consultants, government groups and others who have an interest in the development and advancement of clinical and administrative standards for healthcare - develop the standards. Like all ANSI-accredited SDO, Health Level Seven adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. A frequent misconception about Health Level Seven (and presumably about the other SDOs) is that it develops software. In reality, Health Level Seven develops specifications, the most widely used being a messaging standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data.
Need for Standards
The organization and delivery of healthcare services is an information-intensive effort. It is generally accepted that the efficiency of healthcare operations is greatly affected by the extent of information management functions automation. Many believe that healthcare delivery agencies that have not automated their information systems are not able to compete effectively in the healthcare market in the millennium.
In the past two decades, healthcare institutions, and hospitals in particular, have begun to automate aspects of their information management. Initially, such efforts have been geared towards reducing paper processing, improving cash flow, and improving management decision making. In later years a distinct focus on streamlining and improving clinical and ancillary services has evolved, including bedside (in hospitals and other inpatient environments) and “patient-side” systems (in ambulatory settings). Within the last few years, interest has developed in integrating all information related to the delivery of healthcare to a patient over his or her lifetime (i.e., an electronic medical record). It has also been envisioned that all or part of this electronic medical record should be able to be communicated electronically anywhere as needed.
It is not uncommon today for the average hospital to have installed computer systems for admission, discharge, and transfer; clinical laboratories; radiology; billing and accounts receivable, to cite a few. Often these applications have been developed by different vendors or in-house groups, with each product having highly specific information formats. As hospitals have gradually expanded information management operations, a concomitant need to share critical data among the systems has emerged. Comprehensive systems that aim at performing most, if not all, healthcare information management are in production by selected vendors. These systems may be designed in a centralized or a distributed architecture. Nevertheless, to the extent that such systems are truly complete, their use would reduce the need for an external data interchange standard such as HL7.
There are, however, many pressures on an institution to develop or acquire individual departmental applications on a modular basis. One source of such pressure is the special departmental needs that may not be addressed well (or perhaps at all) by a comprehensive vendor (i.e., so called “best-of-breed”). Another is the need to evolve the overall systems environment of a hospital through a series of incremental, departmental decisions rather than in a single, revolutionary acquisition. An environment containing one or a few key comprehensive systems supplemented by departmental systems, or one consisting entirely of separate and discrete systems could met these pressures.
Network technology has emerged as a viable and cost-effective approach to the integration of functionally and technically diverse computer applications in healthcare environments. However, these applications have developed due to market structure rather than through a logical systems approach; they are therefore often ad hoc. At the very least, they do not possess common data architecture and their combined data storage actually constitutes a highly distributed and severely de-normalized database. Extensive site-specific programming and program maintenance are often necessary for interfacing these applications in a network environment. This occurs at considerable expense to the user/purchaser and vendor while often keeping vendor staff from other initiatives such as new product development. The need for extensive site-specific interface work could be greatly reduced if a standard for network interfaces for healthcare environments were available and accepted by vendors and users alike.
Finally, the lack of data and process standards between both vendor systems and the many healthcare provider organizations present a significant barrier to application interfaces. In many cases, HL7 V2 becomes an effective template to facilitate negotiations between vendors and users but cannot, by itself, serve as an “off-the-shelf” complete interface. With HL7 V3, vendors and providers will have a comprehensive specification that will greatly reduce the need for site specific negotiations.
In summary, it is important that both vendors and users not be faced with the problem of supporting incompatible transaction/communications structures. Instead, a framework must be developed for minimizing incompatibility and maximizing the exchange of information between systems. It is proposed that HL7 can act as a superstructure in this environment to facilitate a common specification and specifications methodology. It is indeed both practical and economical to develop, and commit to, standard interfaces for computer applications in healthcare institutions.
Background
The term “Level 7” refers to the highest level of the Open System Interconnection (OSI) model of the International Organization for Standardization (ISO). This is not to say that HL7 conforms to ISO defined elements of the OSI’s seventh level. Also, HL7 does not specify a set of ISO approved specifications to occupy layers 1 to 6 under HL7’s abstract message specifications. HL7 does, however, correspond to the conceptual definition of an application-to-application interface placed in the seventh layer of the OSI model.
In the OSI conceptual model, the functions of both communications software and hardware are separated into seven layers, or levels. The HL7 Standard is primarily focused on the issues that occur within the seventh, or application, level. These are the definitions of the data to be exchanged, the timing of the exchanges, and the communication of certain application-specific errors between the applications. However, of necessity, protocols that refer to the lower layers of the OSI model are sometimes mentioned to help implementers understand the context of the standard. They are also sometimes specified to assist implementers in establishing working HL7-based systems.
The HL7 Working Group is composed of volunteers who give their time on a personal basis or under sponsorship of their employers. Membership in the HL7 Working Group has been, and continues to be, open to anyone wishing to contribute to the development and refinement of HL7 Interface Standard for network technology in healthcare.
The Standard currently addresses the interfaces among various systems that send or receive patient admissions/registration, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, clinical observations, billing, master file update information, medical records, scheduling, patient referral, and patient care. It does not try to assume a particular architecture with respect to the placement of data within applications but is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Instead, HL7 serves as a way for inherently disparate applications and data architectures operating in a heterogeneous system environment to communicate with each other.
If we consider the multitude of healthcare information systems applications as well as the variety of environments in which healthcare is delivered, it is evident that there are many more interfaces which could benefit from standardization. The interfaces chosen were considered to be of high priority by the members participating in the standards writing process. HL7’s intent is to prepare a complete standard for these interfaces, built on a generic framework that is sufficiently robust to support many other interfaces. This standard has been put into production and is being used as a basis for extending the existing interface definitions and also adding other definitions.
GOALS OF THE STANDARD
The specifications of this Standard were developed in accordance with specified goals. Future extensions of the Standard should also support these goals.
HL7’s purpose is to facilitate communication in healthcare settings. The primary goal is to provide standards for the exchange of data among healthcare computer applications that eliminate or substantially reduce the custom interface programming and program maintenance that may otherwise be required. This primary goal can be further delineated as a set of goals:
1) the Standard should support exchanges among systems implemented in the widest variety of technical environments. Its implementation should be practical in a wide variety of programming languages and operating systems. It should also support communications in a wide variety of communications environments, ranging from a full, OSI-compliant, 7-level network “stack” to less complete environments including primitive point-to-point RS-232C interconnections and transfer of data by batch media such as floppy disk and tape.
2) immediate transfer of single transactions should be supported along with file transfers of multiple transactions.
3) the greatest possible degree of standardization should be achieved, consistent with site variations in the usage and format of certain data elements. The Standard should accommodate necessary site-specific variations. This will include, at least, site-specific tables, code definitions and possibly site-specific message segments (i.e., HL7 Z-segments).
4) the Standard must support evolutionary growth as new requirements are recognized. This includes support of the process of introducing extensions and new releases into existing operational environments.
5) the Standard should be built upon the experience of existing production protocols and accepted industry-wide standard protocols. It should not, however, favor the proprietary interests of specific companies to the detriment of other users of the Standard. At the same time, HL7 seeks to preserve the unique attributes that an individual vendor can bring to the marketplace.
6) while it is both useful and pertinent to focus on information systems within hospitals, the long-term goal should be to define formats and protocols for computer applications in all healthcare environments.
7) the very nature of the diverse business processes that exist within the healthcare delivery system prevents the development of either a universal process or data model to support a definition of HL7’s target environments. In addition, HL7 does not make assumptions about the architecture of healthcare information systems nor does it attempt to resolve architectural differences between healthcare information systems. For at least these reasons, HL7 cannot be a true “plug and play” interface standard. These differences at HL7 sites will most likely require site negotiated agreements.
8) a primary interest of the HL7 Working Group has been to employ the Standard as soon as possible. Having achieved this, HL7 has also developed an infrastructure that supports a consensus balloting process and has been recognized by the American National Standards Institute (ANSI) as an Accredited Standards Organization (ASO).
9) cooperation with other related healthcare standards efforts (e.g., ACR/NEMA DICOM, ASC X12, ASTM, IEEE/MEDIX, NCPDP, etc.) has become a priority activity of HL7. HL7 has participated in the ANSI HISB (Health Informatics Standards Board) process since its inception in 1992.
HISTORY OF HL7 DEVELOPMENT
The HL7 Working Group has met approximately every three to four months since March 1987 to develop and review this specification. The group is structured into committees to address each of the functional interfaces under development, with additional committees to address the overall control structure and various administrative aspects of the group. These committees have the responsibility to author and maintain the chapters in the HL7 Interface Standard. In addition, from time to time various Special Interest Groups (SIG) are formed within HL7 to develop ideas and sponsor particular perspectives that are not covered by any single existing committee. If a SIG's activities warrant and a new chapter is considered necessary, they may petition the HL7 Technical Steering Committee.
In the initial three meetings, a Version 1.0 draft standard was prepared covering the overall structure of the interfaces, ADT, order entry, and display-oriented queries. Although the patient accounting system was recognized as very important, the time frame did not allow it to be addressed in the first draft. This draft was presented to a plenary meeting of the overall group in Tyson’s Corner, VA, on October 8, 1987.
Version 2.0 was prepared subsequent to Plenary I in Tyson’s Corner and presented at Plenary II in Tucson in September 1988. Since Plenary II, editing and revisions for Version 2.1, 2.2, 2.3, 2.3.1, and 2.4 have been ongoing and the Working Group has grown to nearly 400 individuals, far exceeding its original size of 12 and the following has been accomplished:
1) specifications for the various functional areas have been refined and expanded.
10) formal liaison was developed with several other standards efforts: the ANSI HISPP (Healthcare Informatics Standards Planning Panel) for the coordination of healthcare standards efforts that has since been replaced by the ANSI HISB (Healthcare Informatics Standards Board), the ASC X12N group for external EDI Standards, the ASTM E31.11 group for Clinical Data Exchange Standards, the ACR/NEMA DICOM group for standards relating to imaging and other aspects of Radiology Information Systems, and the IEEE P1157 group for medical data interchange (MEDIX).
11) the generic control structure was modified, on the basis of comments, to be adaptable to a wider variety of communications environments and to facilitate cooperation with other standards groups.
12) a chapter on the interface to a patient accounting system was added in Version 2.2.
13) a chapter on the reporting of ancillary results, clinical trials, product experience and waveform data prepared, harmonized with the ASTM 1238-91 Standard and with the direct, active participation of members of the ASTM E31.11 committee, was added in Version 2.3.
14) a chapter with a set of transactions to support the synchronization of master files between related information systems was added in Version 2.2.
15) a chapter on the interface to applications that support medical record functions including transcription management, chart location and tracking, deficiency analysis, consents and release of information was added in Version 2.3.
16) a chapter on messages to support the communication of various events related to the scheduling of appointments for services or for the use of resources has been added in Version 2.3
17) a chapter defining the message set used in patient referral communications between mutually exclusive healthcare entities was added in Version 2.3.
18) a computerized data dictionary of all data elements and other message components has been created in Version 2.3. Appendix A contains cross references and other information generated from this electronic data dictionary.
19) inconsistencies and mistakes which were discovered in the previous Versions 2.0, 2.1, 2.2 2.3, and 2.3.1 of the Standard have been addressed and documented in Version 2.4.
20) extensive additions have occurred in the Order/Entry and Clinical Observations chapters in Version 2.2, 2.3, and 2.4 to include data element oriented results, pharmacy orders and administrations narrative report labels, clinical trials, product experience, vaccinations, and waveform results.
21) Extensive improvements in the PAFM chapters to support MPI, Merge events, regulatory requirements, and international needs.
22) message acknowledgments have been extended to include a separate enhanced mode that defines the “accept acknowledgment.” While this mode of acknowledgment has always been allowed, it is now obvious how HL7 supports any environment when intermediaries exist in the network with implicit time delays (such as store and forward services, “Interface Engines” that perform fan out services, etc.). Immediate acknowledgments are available to release the sending system from the need to resend the message.
23) distinctions have been documented between the HL7 abstract message definition which is purely a level 7 (application level) definition vs. the HL7 encoding rules for converting an abstract message into a string of characters that comprises an actual message. These encoding rules are actually a suggested potential alternative where a fully defined level 6 (presentation level) definition does not exist (e.g., ISO’s ASN.1 Basic Encoding Rules (BER)).
24) chapters of Lab Automation and Personnel Mgmt were added in Version 2.4.
25) extensive new constructs for conformance based queries were added to Chapter 5 in V2.4.
Overview
SCOPE
It is useful to understand both what HL7 is and what it is not. It is valuable to understand the “edges” or limitation of HL7. While HL7 can, and routinely does, provide a considerable service in everyday use today, there are certainly many areas of healthcare system integration that HL7 does not address or addresses with what may prove to be an inadequate or incomplete solution.
Many of these topic areas are being worked on today by HL7 and will, hopefully, appear in latter versions of this balloted Standard. HL7 may never address some of these topics because they are being handled by some other standards body. Still other areas may never be addressed by HL7 due to a lack of interest, or at least available energy by its members.
In any case, it is certainly useful for the analyst to understand what these boundaries are and to then either choose to solve them in some other way or to merely ignore them if they are deemed not sufficiently important. The following features listed in this section may well be best served by the participating applications themselves. However, it is possible to conceive of an architecture that expects these features to be present in the messaging standard itself. These potential deficiencies are included to give the reader a complete view.
Relationship to other protocols
The Working Group has given considerable attention to the relationship of the HL7 protocol and other protocols. A considerable liaison effort is underway. This is described below:
1) ACR/NEMA DICOM The HL7 Working Group maintains an on-going liaison with the ACR/NEMA DICOM working group. HL7 and ACR/NEMA DICOM are both members of ANSI’s HISB.
2) ASC X12 Standards for Electronic Document Interchange ASC X12 is a family of standards that provides both general and specific descriptions for data interchange within a number of industries. The HL7 Encoding Rules are modeled on the X12 standards, although there are differences. The HL7 Standard needs to accommodate online exchange of individual transactions on LANs. This difference, and certain applications issues, is responsible for the variance from X12. X12 has recently decided to follow the UN/EDIFACT encoding rules for all X12 standards produced in 1995 or later. X12N transactions that facilitate the transfer of healthcare claims and remittance information as well as benefit coordination, enrollment and verification are enjoying dramatically increased use. HL7 has elected to assume that all new business transactions between institutions regarding the interchange of claims, benefits, or other financial information are the responsibility of ASC X12N, the insurance subcommittee of X12, in the United States only.
In February of 1994, HL7 and X12 signed an agreement to “improve coordination efforts and have identified that technical issues must be harmonized. Both groups agree to migrate to the appropriate level of resolution of potentially overlapping work by utilizing user and standards communities’ and anticipated healthcare reform requirements.”
26) ASTM 1238.94 Laboratory Data Reporting An active liaison effort between the ASTM committee and the Working Group has resulted in minor changes in the ASTM specification to enhance compatibility, changes in the HL7 control specifications to enhance compatibility, and the development of the entire Ancillary Data Reporting chapter, developed jointly by the committees and built on the ASTM Standards. This liaison has extended to the point where both groups now have the permission to freely use the contents of each others standards efforts “in whole” within their own published standards.
Some distinctions are more in the terminology chosen than the actual message content. For example, the ASTM “sub-field delimiter” is generally used to separate repetitions of homogenous values. It is called a “repetition separator” in HL7. HL7 and ASTM are both members of ANSI’s HISB.
27) IEEE P1157 (“MEDIX”). The MEDIX committee has defined an application-level protocol similar in scope to HL7 but built strictly on the ISO protocol stack, up to and including the Remote Operation Service Element (ROSE). HL7 varies from this approach by the decision not to depend on ROSE nor use the ASN.1 BER syntax notation. Despite the difference in approaches, the HL7 Working Group has regular liaison with the MEDIX committee. The Working Group has devised a format for the HL7 Standard that is relatively independent of the encoding rules chosen and easily translated into the ASN.1 notation. The transactions defined in this manner should be directly transferable to the MEDIX effort, and transaction messages encoded using the HL7 scheme should be translatable to transactions encoded using the BER. This should facilitate the creation of gateways between the HL7 and future environments.
In addition, HL7 and MEDIX have agreed on a course for convergence. This will occur within the HL7 abstract message definitions. MEDIX has further agreed to use the HL7 abstract message definitions as defined in Version 2.1 as a starting point for the MEDIX message definitions.
HL7, IEEE, and X12 are ANSI approved standards developers.
Contact Us
Need further information, please contact us:
Health Level Seven, Inc.
3300 Washtenaw Avenue, Suite 227
Ann Arbor, MI 48104
734-677-7777 (phone) 734-677-6622 (fax)
E-mail hq@
V3 Introduction
WHY A MAJOR NEW VERSION?
HL7 V3, like V2.x, is a standard for exchanging messages among information systems that implement healthcare applications. However, V3 strives to improve the V2 process and its outcomes. The original process for defining HL7 messages was established in 1987. It has served well since. However, as HL7 membership grew and its standards became more widely used, HL7 has become aware of opportunities to revolutionize health interface computing. HL7 interfaces substantially reduce costs and implementation times when compared to the industry's experience with proprietary interfaces. However, these costs and times vary considerably by vendor, and the industry sees a need for improvement. Substantial optionality in HL7 makes it difficult to specify precise contract terms for HL7 interfaces. This can lead to unrealistic expectations that hurt vendors and buyers equally. The development principles behind HL7 V3 lead to a more robust, fully specified standard.
Difficulties with the Existing Process
The HL7 V2.x development process is entirely ad hoc. There is no explicit methodology. Members receive no formal guidance in constructing messages. Trigger events and data fields are described solely in natural language. The structural relationships among data fields are not clear. Segments are re-used in many messages and message definitions are reused for many trigger events. In order to accommodate this extensive re-use, most data fields are optional. Chapters are inconsistent in their use of trigger events versus status codes. There is no specification as to when a specific kind of healthcare information system should be expected to honor a trigger event or accept a message.
With V2.x, a technical committee creates messages by editing word processing documents directly. The metadata is not available in a structured form until the staff and volunteers tediously extract it from the word processing documents after publication.
In summary, there is substantial need to improve this old process in order to handle the breadth and complexity of the challenges HL7 faces today. Our industry will benefit because this new process results in a more rigorous specification.
Opportunities to Improve
Fortunately, software practitioners have learned a lot since 1987. There are better methodologies. Computer support is far more available and cost effective. However, HL7 cannot take advantage of these developments solely by minor tweaks to the old process.
HL7 spent four years characterizing its revised goals and creating a methodology to adapt modern analysis techniques from system building to message design. Initially the Executive Committee chartered an independent task force to establish the broad outline of the approach. In January 1996, the Technical Steering Committee agreed to adopt the main features of the approach and take over its management. Planning work continued in the Modeling and Methodology Committee and the Control/Query Committee. At the completion of Version 2.3, in the spring of 1997, the HL7 technical committees all began to use the Version 3 process.
Version 3 Principles
The HL7 V3 standard development methodology is based on a set of principles providing a common philosophy for all HL7 V3 standard developers.
• Internationalization - Version 3 shall include mechanisms that support the need for local variants of HL7 messages to be used by HL7 Affiliates. It shall be possible for affiliates to use the messages created by the world-wide HL7 organization. It shall also be possible for affiliates to develop and use localized variants.
• Legacy Systems Support - As with prior versions, Version 3 shall be designed using a technological approach that permits implementation in "legacy systems." These are systems that have been implemented in technical environments that do not necessarily conform to or provide support for recent or pending "open systems" standards, such as those published by ISO, Open Systems Foundation, Object Management Group, etc. Similarly, HL7 will not require proprietary features of any operating system or software vendor. In practical terms, this means that Version 3 shall be able to exchange messages formatted in strings of printable characters, as is the case for all previous versions. This does not preclude HL7 from deciding to develop variants of its specification that make use of the modern technologies provided that 1)System builders will not be required to buy software from a sole source in order to implement Version 3, and 2) Messages generated in these formats have the same data content so that translation between the printable character format and other formats is easy.
• Loosely Coupled Systems - As with HL7 V2.x, V3 shall not be a standard for the functionality of the systems which exchange HL7 messages. However, where Version 3 includes a requirement to accept or send certain data or to send specific messages in response to trigger events or other messages, the application system may have to develop functionality to support those requirements.
V3 messages may be sent using many modes and topologies. Messages may be sent in a manner that requires an immediate response, as unsolicited updates through a store and forward network, or in batches where the manner and timing of message transfer is not specified. V3 includes support for “one-to-many”, store-and-forward distribution of messages by an external software agent.
• V2.x Functional Compatibility - HL7 V3 goals cannot be achieved while maintaining full compatibility with previous versions. However, upon completion, V3 shall cover the information content of the last version in the V2.x series including attributes and trigger events. This should not be construed to mean that all attributes and trigger events shall be included in 3 in exactly the same form as within the V2.x series.
A network that includes a mixture of systems that implement V2 and V3 will require message translation. Because the V2 standards have substantial optionality, the translations will use rules specific to the systems on that network. It is expected that interface engines and other translation software will be able to provide the translations between site-specific interpretations of V2.x and any implementation of V3.
• Upward Compatibility among V3.x - HL7 will provide the maximum degree possible of interoperability among systems operating on older and newer versions of HL7 protocols in the V3 family through compatible enhancement.
-- A message structure that is modified in a newer version of the protocol must be acceptable to a system designed for the prior V3 release. However, a system built for the prior release will only extract the information that was defined for that prior release.
-- A message structure created in accordance with an older version of the V3 protocol must be acceptable to a system designed for a later V3 release. In some cases, this will mean that the system built for the newer release will not receive certain information fields because they were not a part of the older version of the message structure in use by a specific sender.
-- Where compatible enhancement is not possible, HL7 will require evolution in the protocol to happen gradually, so that users can introduce the change into their networks gradually.
-- The messages associated with all interactions that are newly defined in a version of HL7 must not be sent to a receiver that conforms to the older version.
-- A message structure may be declared obsolescent in one release, with a stated alternative message structure. Both the obsolescent message structure and its alternative can be used by all systems supporting that release.
-- The obsolescent message structure may be declared obsolete and dropped when still another HL7 version is issued.
-- An obsolescent message structure may not be declared obsolete for at least two years from the date of the version that first declared it obsolescent.
-- The above notwithstanding, if a new Implementation Technology Specification (ITS) is introduced, HL7 may specify that conformance to the ITS does not require dealing with message structures that are obsolescent when the new ITS is introduced. To the maximum degree possible, these restrictions should not impose limitations on the evolution of the overall reference model. There are no restrictions on making changes to the information model if those changes do not impact the message structures that were described in a prior version of the Standard.
• Determining Conformance - Application Roles shall be the basis for conformance claims. An Application Role is an abstraction that expresses a portion of the messaging behavior of an information system. Application Role Names are expected to be different than the names generally used to describe healthcare information system products, since they describe messaging interfaces as opposed to application behavior. A typical healthcare information system will probably fill several or many such Application Roles. For example, the Functional Committees may define Application Roles such as "lab order sender", "lab order filler", "enterprise patient identification store", etc.
In making a conformance claim, a system developer shall identify the application roles to which it wishes to claim conformance. For these application roles, the V3 specification will state directly the trigger events the system shall recognize, messages that the system shall send in response to trigger events or other messages, and the data content of these messages. The specification also states the messages that a system conforming to the application role shall receive and process.
All conformance claims shall be sufficiently specific to be used as contractual terms in system acquisitions and to be the basis for testing by an independent testing organization.
User sites may contract with vendors to implement deviations from the HL7 conformance claims. Such arrangements are outside the scope of HL7. Such an arrangement will not be considered a failure of the application to conform to HL7.
All sequences of messages in V3 shall be related to a Trigger Event. The Trigger Event shall be clearly identified in a common field in all messages.
• Confidentiality of Patient Information - It is expected that healthcare application systems that implement Version 3 will be required to have significantly more functionality to protect the confidentiality of patient information than has been common in the past. The new functions may include, but are not limited to, limiting the right to view or transfer selected data to users with specific kinds of authorization and auditing access to patient data. V3 will seek out and adopt industry security standards that support conveying the necessary information from one healthcare application system to another, so that these systems may perform the confidentiality functions. The Functional Committees, the Control Group, and the Modeling and Methodology Committee shall consult with the Security & Accountability SIG while developing the HL7 Data Model and Version 3 messages.
• Authenticated Authorization for Services - It is expected that the healthcare application systems that implement Version 3 will be required to have significantly more functionality to authenticate requests for services and reports of data than has been common in the past. The new functions may include, but are not limited to, electronic signature and authentication of users based on technologies more advanced than passwords. V3 will seek out and reference standards such as X.500 and RFC 1510 to support conveying the necessary information from one healthcare application system to another, so that these systems may perform the authorization and authentication functions. The Functional Technical Committees, the Control Group, and the Modeling and Methodology Committee shall consult with the Security & Accountability SIG while developing the HL7 Data Model and Version 3 transactions.
• Security, Privacy, Non-Repudiation and Integrity - It is expected that the technological platforms upon which Version 3 information systems developers implement applications that use HL7 will be required to have significantly more capability to protect the confidentiality and integrity of patient information than has been common in the past. The new functions may include, but are not limited to, public- and private-key encryption, and correspondent system authentication and non-repudiation. The Control Group should monitor these developments to see that Version 3 can be implemented on technological platforms that support these new functions.
What's New with HL7 V3?
• HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles. HL7 employs a completely new approach to develop the HL7 V3 standard. HL7 V3 uses an OO approach that is model and repository-based. This OO approach is supported with trained facilitators, formal education classes, and computerized tools. This approach leads to increased detail, clarity and precision of the specification and finer granularity in the ultimate message. This helps functional committees meet the challenges of de novo interface design, increases functional breadth, and evolution of assumptions. It helps new members become productive in fewer meetings. This is an enormous aid to providing institutional memory and sharing work in progress across committees and to the membership at large.
• HL7 isn't just Level 7 anymore! After years of implementing HL7 V2.x, HL7 standard developers realized it was virtually impossible to develop a comprehensive standard without including other levels of the International Organization for Standardization (ISO) Open Systems Interconnect (OSI) Model. Today, committees exist for XML, Security, Modeling & Methodology, Arden Syntax, Visual Integration and Vocabulary.
• Reduced Optionality. Limiting optionality is a primary goal of HL7 V3. Within HL7 V2.x, almost every field is optional. This optionality is necessary since optionality is defined by segment and segments are re-used in multiple messages. Declaration of a data field as optional within a segment allows that segment to be used in many different messages without any further definition. However, the wide uses of optionality, while helpful in gaining consensus and in writing a somewhat more compact specification, imposes significant costs on interface implementers. In fact, optionality, as a “feature” of HL7 V 2.x, is associated with most of the issues that V3 is trying to solve. Optionality makes it harder to precisely define the semantics of a specific message and makes it virtually impossible to generate conformance claims for messaging.
• Conformance to the HL7 V3 Specification will be testable. It is difficult to measure compliance of HL7 V2.x interfaces. Often vendors claim compliance to HL7 without providing any supporting documentation of how they conform. Terms such as HL7-like or HL7-ish are used to describe HL7 interfaces. With HL7 Version 3, conformance is specified in terms of Application Roles. Application Roles are abstractions that express a portion of the messaging behavior of an information system. A vendor of a healthcare application describes its conformance by asserting that it completely supports all trigger events, messages and data elements associated with one or more Application Roles. This level of specificity allows clearer pre-contractual understanding between vendors and buyers and will serve as a basis for conformance testing.
Managing HL7 V3 Message Development
Here you will learn the procedures used to develop the HL7 V3 messages. These procedures are based on the V3 Methodology and the HL7 Bylaws. The goal is to assure that the standard is developed expediently, appropriately documented, consistent with the requirements for an approval by a balanced consensus, and that it complies with the requirements for certification by the American National Standards Institute (ANSI).
Project Scope Definition
When a functional technical committee undertakes a project to develop new normative material in V3 it shall create a brief description of the project for approval by the Technical Steering Committee. The project scope statement contains a concise description of the needs to be met by the transactions. This project scope statement[1] will also be used for coordination of projects with other standards organizations. In fact, project scope statements must be reported to the American National Standards Institute (ANSI) so that ANSI can fulfill its standards coordination role.
Project Scope Statements is reviewed by the Architectural Review Board and must be approved by the HL7 Technical Steering Committee.
When the work product is published as a draft or for ballot, the project scope statement shall be published with it. HL7 shall maintain and publish from time to time a list of all project scope statement that have been approved but for which the corresponding messages have not been approved.
If, in the course of a project, the technical committee finds its work is exceeding the bounds of the authorizing project scope statement it shall submit an amended statement for approval.
HL7 V3 Methodology
The development of Version 3 messages will follow the methodology specified by the HL7 Modeling and Methodology Committee, and documented within the Message Ballot Framework. HL7 may amend the methodology from time to time. The methodology will include a definition of work products delivered by the technical committees. Portions of these work products shall be designated for three different treatments:
1. included as a normative portion of the eventual standard,
2. included as an informative portion of the eventual standard,
3. not included with the standard, but published with minutes and archived.
The methodology shall meet the following requirements. These are annotated to indicate the work products described in the Message Ballot Framework that meet the requirements. The annotations further state whether the work product is normative or informative.
|Requirement |MBF Construct(s) |Level |
|A means of providing context to the definitions of Trigger Events |Use cases, state diagrams |Informative |
|A means of specifying the information content of the Messages through a common |Reference Information Model |Reference |
|information model that clarifies the definitions and ensures that they are used | | |
|consistently across all Version 3 messages defined by all technical committees | | |
|A means of specifying responsibilities of the senders and receivers of messages |Interaction model |Normative |
|A common description of the exact fields of a message and their grouping, sequence, |Hierarchical Message Definitions |Normative |
|optionality, and cardinality | | |
|Separate syntax specifications, describing the algorithms used to encode and |Implementation Technology |Normative |
|transmit the messages in an XML based character stream syntax. |Specifications | |
The Modeling and Methodology Committee shall not have the right to determine the contents of work products created by the technical committees. It shall serve to facilitate their development, and to negotiate changes among the functional technical committees to ensure standard-wide consistency. If disputes cannot be resolved by the technical committees and/or the Modeling and Methodology Committee, they shall be resolved by the Technical Steering Committee with the approval of the HL7 Board of Directors.
Quality Assurance Process
In order to ensure the highest quality of the work products produced during the course of Version 3 message development, the HL7 Board of Directors has created the Architectural Review Board.
The Architectural Review Board shall work with the Technical Committees and Modeling and Methodology Committee to define measures of quality of the work products of the standard. It shall also ensure that the Version 3 Process is explained in a manner that is clear and well understood by the membership.
The Architectural Review Board shall ensure that the work products are reviewed against such measures of quality, and that adherence to the defined message development process is documented in a manner consistent with HL7 bylaws and procedures. The Architectural Review Board shall not have the right to amend work products or disallow their distribution. It shall have the right to include with any work product a statement describing areas where it has determined that the work product has not met established measures of quality.
As a general matter, the Architecture Review Board is expected to include a statement of its findings in an HL7 general ballot package. However, in order to assist technical committees, and to avoid delaying the balloting process, the Architecture Review Board should attempt to make any significant comments as early in the ballot cycle as possible.
Disputes with the findings of the Architectural Review Board will be resolved through the Technical Steering Committee and, if necessary, the Board of Directors.
Process Support
HL7 should provide reasonable funds to support the Version 3 processes including, but not limited to, acquisition and use of computer-based tools to support the development of work products, document conformance to process and create final deliverables. The Board of Directors will appropriate funds in a manner consistent with the overall financial viability of the organization.
Management
The standards development process shall be governed as defined by the HL7 Bylaws and HL7 Policies and Procedures. All development of procedures called for in this Statement of Principles shall be ratified by the Technical Steering Committee unless the bylaws or Policies and Procedures require different approval.
HL7 V3 Ballot Instructions
INTRODUCTION
The HL7 V3 ballot is available for download from the HL7 website. Due to the size of the V3 ballot and the availability of extensive supporting materials, it is not necessary to download the entire package. You can pick only the pieces that are most important to you.
Ballot Section Options
|Section |Required/Optional |
|Backbone |Required |
|Section: Infrastructure Management |Optional |
| |(Required if Sub-Section is downloaded) |
|Sub-Section: Practice & Operations |Optional |
|Sub-Section: Reasoning |Optional |
|Sub-Section: Records |Optional |
|Section: Health & Clinical Care Management |Optional |
| |(Required if Sub -Section is downloaded) |
|Sub-Section: Administrative Practice |Optional |
|Sub-Section: Financial |Optional |
|Section: Administration Management |Optional |
| |(Required if Sub-Section is downloaded) |
|Sub-Section: Messages |Required |
|Sub-Section: Query |Optional |
|Message Development Framework |Optional |
|Reference Information Model |Optional |
|Data Types Documentation (Primary) |Optional |
|Data types Documentation (Reference Info.) |Optional |
|Vocabulary |Optional |
|Implementable Technology Specification: XML |Optional |
|Implementable Technology Specification: DT |Optional |
Remember, if a Sub-Section is downloaded, the parent Section must also be downloaded.
Because of extensive linking between documents, you may activate a hyperlink to a portion of the package that was not downloaded. If this should occur in the HTML rendition, a screen will appear indicating that the linked material was not downloaded and providing a hyperlink to the HL7 web site where it may be downloaded if required. In the PDF rendition, there will also be hyperlinks between the documents, however, if you activated one, you will be given an informational message indicating where the document may be downloaded. When printing the PDF format a blank page will print indicating the portions of the package that have not been downloaded with an appropriate informational message.
V3 Voting Procedures
For this ballot cycle, the HL7 V2 voting procedures will be followed:
1. HL7 announces opening of voting period (at least 30 days prior to vote period start)
2. Voter must register in the voter ballot pool.
3. Vote period starts and is open for 30 days.
4. Voter may download ballot documents from HL7 web site
5. Voter may download voting MSWord template from HL7 web site
6. Voter reviews ballot and documents votes and comments in MSWord template manually identifying the section to which the comment/vote applies and the severity of the vote/comment. Severity levels included:
a. Affirm - Query
b. Affirm – Comment
c. Affirm – Typo
d. Negative – Minor
e. Negative – Major
7. Organizational members may compile and combine MSWord vote/comments.
8. Voter submits vote in MSWord document to HL7 HQ web site indicating an overall Affirm or Negative vote.
Ballot Symbol Key
The initial release of the HL7 V3 ballot package will include multiple documents. In order to distribute a comprehensive standard, documents included have various statuses. For example, some of these documents, such as the Message Ballot Framework (MBF) are included for reference only. Each document included in a V3 ballot package is assigned one of the five statuses noted in the table below. You can identify the type of document by reviewing icon next to the document title. The status icon tells you whether you can ballot a particular document and, if so, which ballot rules—informative or normative—apply.
Document Status
|Status |Description |Icon |
|Reference |Documents that contain information that | |
| |clarifies concepts or otherwise provides | |
| |additional information to aid understanding| |
| |and comprehension. This material is not | |
| |balloted. Readers may comment, identify | |
| |typographical errors, or provide | |
| |suggestions for improving the document but | |
| |those comments in no way affect a ballot. | |
| |The Message Ballot Framework (MBF) is an | |
| |example of a Reference document. | |
|Informative, Previously Balloted |Document that have already been | |
| |successfully balloted as HL7 Informative | |
| |Documents at the time of the current ballot| |
| |package release. | |
|Normative, Previously Balloted |Document that have already been | |
| |successfully balloted as HL7 Normative | |
| |Documents (submitted for ANSI approval) at | |
| |the time of the current ballot package | |
| |release. For example, for the initial | |
| |release of Version 3, the Clinical Document| |
| |Architecture will have been previously | |
| |balloted as an HL7 Normative document. | |
| |Since these documents have previously been | |
| |balloted, you cannot cast a ballot for them| |
| |in the current ballot package. | |
|Informative Ballot Document |Document that is part of the current ballot| |
| |package and on which HL7 members shall cast| |
| |a ballot following the HL7 procedures for | |
| |Balloting Informative Documents. HL7 | |
| |Informative document are not submitted to | |
| |ANSI for approval. | |
|Normative Ballot Document |Document that is part of the current ballot| |
| |package and which HL7 members shall cast a | |
| |ballot following the HL7 procedures for | |
| |Balloting Normative Documents. HL7 | |
| |Normative document are subject to both | |
| |successful committee and membership votes | |
| |and are submitted to ANSI for approval. For| |
| |the initial V3 ballot package, HL7 users | |
| |will be balloting the domain documents as | |
| |normative documents. | |
Quick Start
INTRODUCTION
This Quick Start section will link you directly where you want to go. Not sure where you want to go? Take a look at the Getting Started section. The Getting Started section will provide more instructions regarding which documents will be most helpful as you begin your journey with HL7 V3.
HL7 V3 Publication Components
|Health & Clinical Management |The Health & Clinical Management Section focuses on the management of the health and clinical |
|Section |care of individuals. This section encompasses all the aspects of its sub-sections: Practices |
| |and Operations, Reasoning, and Records. If you are familiar with V2, this section contains |
| |information analogous to chapters 4 (Order Entry), 7 (Observation Reporting), 12 (Patient Care)|
| |and 13 (Clinical Laboratory Automation). |
|Administrative Management Section |The Administrative Management Section addresses information requirements for the management of |
| |clinical documents. It includes activities of the HL7 Information Management committee and the|
| |development of the information structures surrounding electronic health records. This section |
| |encompasses all the aspects of its sub-sections: Practice, Financial, and Personnel. If you |
| |are familiar with V2, this section contains information analogous to chapters 3 (Patient |
| |Administration), 6 (Financial Management), 10 (Scheduling), and 15 (Personnel Management). |
|Infrastructure Management Section |The Infrastructure Management Section defines the information structures and communication |
| |tools necessary to support the interactions specified by the Clinical and Administrative |
| |domains. It focuses on the logical structures used to convey clinical and administrative |
| |information rather than on the clinical or administrative information itself. This section |
| |encompasses all the aspects of its sub-sections: Message Infrastructure, Query, Structured |
| |Documents, and CCOW. If you are familiar with V2, this section contains information analogous |
| |to chapter 2 (Control) and chapter 5 (Query). |
|Message Ballot Framework |The Message Ballot Framework (MBF) contains critical information to help you read and apply the|
| |V3 Standard. It contains detailed information on the terminology, diagrams, and models used to|
| |present the standard. For example, it explains how to read a Hierarchical Message Definition |
| |(HMD), the structure used to specify the details on objects and data elements included in a |
| |particular message. |
|Reference Information Model |The Reference Information Model (RIM) is the foundation of the HL7 V3 Development Methodology. |
| |The RIM is a coherent, shared information model that is the source for the data content of all |
| |HL7 messages. HL7 is the only Standards Development Organization (SDO) to have a single, |
| |unified model encompassing all the elements of each of its Working Groups. The RIM is |
| |available in two forms: a graphical expression or a literary expression. The RIM graphical |
| |expression displays all the classes, attributes, and relationships in Unified Modeling Language|
| |(UML) notation. The RIM graphical expression is supported within Rational Rose CASE tool. The|
| |RIM literary expression displays the same information as the graphical expression in a textual |
| |representation. |
|HL7 Vocabulary Domains |HL7 Vocabulary Domains are the sets of allowable values for a coded field. For example, if a |
| |message contains a marital status field, then the vocabulary domain for that field would |
| |consist of the allowed values for that field, such as, single, married, divorced, and |
| |separated. Each coded attribute in the RIM will be associated with one and only one vocabulary|
| |domain. |
|Data Types - Part 1 |The HL7 V3 Abstract Data Types - Part 1 document is one of two documents that specify the HL7 |
| |Version 3 Data Types on an abstract layer; that is, independent of their encoded (e.g., XML) |
| |format. |
|Data Types - Part 2 |The HL7 V3 Data Types - Part 2 document conveys much of the same information as HL7 V3 Abstract|
| |Data Types - Part 1 but presented in a very precise format that is tailored to those with a |
| |strong background in Healthcare Informatics and Computer Science. |
|Implementable Technology |The Implementable Technology Specifications describe how HL7 messages are sent using a specific|
|Specifications |method of encoding. |
Getting StarteD
INTRODUCTION
The Getting Started section provides guidelines and recommendation for how you should approach the HL7 V3 Publication. Each diagram below depicts a type of HL7 customer based on his or her relationship to the HL7 standard/organization. Locate the type of user that most closely reflects your experience level. The documentation below the diagram includes recommended reading that will help you build the HL7 V3 knowledge base you desire.
New Implementer
[pic]
New Implementer
A New Implementor is unfamiliar with HL7 terminology, methodology, and organization. A New Implementer may or may not be a member of the HL7 organization.
Learn the Basics
Learning the basics means becoming familiar with the basic terminology and methodology behind HL7. You would expect to learn the basic principles upon which HL7 Version 3 has been constructed. Upon completion of this Use Case, you would be prepared to learn more detailed information about Version 3.
While learning the basics, refer to:
• V3 Backbone Introduction
• V3 Backbone Glossary
• Message Ballot Framework
Management
[pic]
Manager
Managers are responsible for hiring qualified HL7 analysts and programmers. They must supervise interface development and implementation efforts. They do not need to understand all of the details of creating an HL7 message, but they need to understand the concepts enough to review contacts, conformance statements, and assess the skills of their team.
Project Manager
The Project Manager is responsible for ensuring the project is completed within budget, on time, and within scope. Project Managers are not interested in all the details of creating an HL7 V3 message, but he needs to understand the concepts enough to review contacts, conformance statements, and assess the skills of his team.
Marketeer
A Marketeer is responsible for selling HL7 interfaces. He does not need to know the details, but must understand the major concepts and terminology.
Construct Site Agreement
Constructing a site agreement involves creating a specification for two or more parties to communicate using HL7 messages and documents.
When constructing a site agreement, refer to:
• V3 Backbone Introduction
• V3 Backbone Glossary
• MBF Conformance Claims and Organizational Practices
• MBF Interaction Model
Sign a Deal
The deal requires HL7 interfaces, so in order to sign it a basic understanding of trigger events and message types, but not a detailed understanding of message fields, is required.
When signing a deal, refer to:
• V3 Backbone Introduction What's New in V3?
• MBF Conformance Claims and Organizational Practices
Interface Developer
[pic]
Interface Analyst
Interface Analysts review the interface requirements and write detailed interface specifications.
Interface Programmer
Interface Programmers code and test interface based on the interface specifications.
Develop Interface
Developing an interface requires gathering the interface requirements, analyzing those requirements, developing detailed interface specifications, coding, and testing the interface against the interface specifications and defining the conformance statement.
When developing an interface, you must identify the application section you are working within:
Health & Clinical Management Section - The Health & Clinical Management Section focuses on the management of the health and clinical care of individuals. This section encompasses all the aspects of its sub-sections: Practices and Operations, Reasoning, and Records. If you are familiar with V2, this section contains information analogous to chapters 4 (Order Entry), 7 (Observation Reporting), 12 (Patient Care) and 13 (Clinical Laboratory Automation).
Administrative Management Section - The Administrative Management Section addresses information requirements for the management of clinical documents. It includes activities of the HL7 Information Management committee and the development of the information structures surrounding electronic health records. This section encompasses all the aspects of its sub-sections: Practice, Financial, and Personnel. If you are familiar with V2, this section contains information analogous to chapters 3 (Patient Administration), 6 (Financial Management), 10 (Scheduling), and 15 (Personnel Management).
Infrastructure Management Section - The Infrastructure Management Section defines the information structures and communication tools necessary to support the interactions specified by the Clinical and Administrative domains. It focuses on the logical structures used to convey clinical and administrative information rather than on the clinical or administrative information itself. This section encompasses all the aspects of its sub-sections: Message Infrastructure, Query, Structured Documents, and CCOW. If you are familiar with V2, this section contains information analogous to chapter 2 (Control) and chapter 5 (Query).
Once you identify the section you can drill down through the sub-section until you find the messages in your domain.
To complete your message development analysis, you will also need to fully understand:
Implementable Technology Specifications - The Implementable Technology Specifications describe how HL7 messages are sent using a specific method of encoding.
HL7 Vocabulary Domains - HL7 Vocabulary Domains are concepts you are most likely already familiar. HL7 Vocabulary Domains are the sets of allowable values for a coded field. For example, if a message contains a marital status field, then the vocabulary domain for that field would consist of the allowed values for that field, such as, single, married, divorced, and separated. Each coded attribute in the RIM will be associated with one and only one vocabulary domain.
For additional reference, be sure to review:
• V3 Backbone Glossary
• Message Ballot Framework
MBF Creating Message Specifications
MBF Associating Vocabulary Domains with Attributes, Elements and Fields
HL7 Standard Developer
[pic]
Standard Developer
Standard Developer attend HL7 Working Group Meetings and participate in the creation of the HL7 V3 Standard Specification.
Develop the Standard
Developing the HL7 Standards involves an understanding of the HL7 Organization and its development methods.
Before committing to HL7 Standards Development, review:
• the scopes and mission statements of each HL7 Technical Committee and Special Interest Group on the HL7 web site: . This will help you pinpoint to which committee your knowledge and interest will be most compatible.
• Message Ballot Framework
• Reference Information Model
• HL7 V3 Abstract Data Types - Part 1
Identify the section in which you are most interested.
• Health & Clinical Management Section - The Health & Clinical Management section focuses on the management of the health and clinical care of individuals. This section encompasses all the aspects of its sub-sections: Practices and Operations, Reasoning, and Records. If you are familiar with V2, this section contains information analogous to chapters 4 (Order Entry), 7 (Observation Reporting), 12 (Patient Care) and 13 (Clinical Laboratory Automation).
• Administrative Management Section - The Administrative Management section addresses information requirements for the management of clinical documents. It includes activities of the HL7 Information Management committee and the development of the information structures surrounding electronic health records. This section encompasses all the aspects of its sub-sections: Practice, Financial, and Personnel. If you are familiar with V2, this section contains information analogous to chapters 3 (Patient Administration), 6 (Financial Management), 10 (Scheduling), and 15 (Personnel Management).
• Infrastructure Management Section - The Infrastructure Management Section defines the information structures and communication tools necessary to support the interactions specified by the Clinical and Administrative domains. It focuses on the logical structures used to convey clinical and administrative information rather than on the clinical or administrative information itself. This section encompasses all the aspects of its sub-sections: Message Infrastructure, Query, Structured Documents, and CCOW. If you are familiar with V2, this section contains information analogous to chapter 2 (Control) and chapter 5 (Query).
Once you identify the section you can drill down through the sub-section until you find the messages in your domain.
• Implementable Technology Specification - The Implementable Technology Specifications describe how HL7 messages are sent using a specific method of encoding.
Glossary
|TERM |MEANING |
|AD HOC CHOICE |SEE CHOICE, AD HOC. |
|APPLICATION |1. AN ACT OF APPLYING OR PUTTING TO USE; A USE TO WHICH SOMETHING IS PUT (E.G., |
| |“APPLICATION OF HL7”.) 2. A SOFTWARE PROGRAM OR SET OF RELATED PROGRAMS THAT PROVIDE |
| |SOME USEFUL HEALTHCARE CAPABILITY OR FUNCTIONALITY. |
|APPLICATION ROLE |A CHARACTERISTIC OF AN APPLICATION THAT DEFINES A PORTION OF ITS HL7 INTERFACES. IT |
| |IS DEFINED IN TERMS OF THE INTERACTIONS (MESSAGES) THAT THE ROLE THAT THE ROLE SENDS |
| |OR RECEIVES IN RESPONSE TO TRIGGER EVENTS. |
|ASSOCIATION |A TYPE OF RELATIONSHIP. AN ASSOCIATION RELATIONSHIP DEPICTS A REFERENCE FROM ONE |
| |CLASS TO ANOTHER CLASS OR ITSELF. |
|ASSOCIATION COMPOSITION |SEE COMPOSITE AGGREGATION. |
|ASSOCIATION ROLE NAME |AN ASSOCIATION NAME. ASSOCIATIONS HAVE TWO NAMES, ONE ON EACH END OF AN ASSOCIATION. |
| |EACH NAME IS AN ASSOCIATION ROLE NAME. THE NAME IS A SHORT VERB PHRASE DEPICTING THE |
| |ROLE OF THE CLASS ON THAT END OF THE ASSOCIATION. |
|ASSOCIATION, MANDATORY |A MANDATORY ASSOCIATION IS AN ASSOCIATION WITH MINIMUM MULTIPLICITIES GREATER THAN |
| |ZERO ON BOTH ENDS. |
|ATTRIBUTE |ATTRIBUTES ARE ABSTRACTIONS OF THE DATA CAPTURED ABOUT CLASSES. ATTRIBUTES CAPTURE |
| |SEPARATE ASPECTS OF THE CLASS AND TAKE THEIR VALUES INDEPENDENT OF ONE ANOTHER. |
| |ATTRIBUTES ASSUME DATA VALUES THAT ARE PASSED IN HL7 MESSAGES. |
|ATTRIBUTE TYPE |THE LAST PART OF AN ATTRIBUTE NAME (SUFFIX). ATTRIBUTE TYPE SUFFIXES ARE ROUGH |
| |CLASSIFIERS FOR THE MEANING OF THE ATTRIBUTE. SEE ALSO DATA TYPE FOR CONTRAST. |
|BAG |AN UNORDERED COLLECTION OF ITEMS WHICH NEED NOT BE UNIQUE. |
|CARDINALITY |THE NUMBER OF ELEMENTS IN A SET. SEE ALSO MULTIPLICITY. |
|CHOICE BRANCH |ONE OF THE ALTERNATIVE MESSAGE ELEMENTS FOR A CHOICE. |
|CHOICE DUE TO SPECIALIZATION |A CHOICE IN A MESSAGE THAT ARISES WHEN A HIERARCHICAL MESSAGE DESCRIPTION INCLUDES |
| |(A) AN OBJECT VIEW WHICH IS ASSOCIATED WITH A CLASS THAT IS A SUPERCLASS OF TWO OR |
| |MORE OBJECT VIEWS, OR (B) AN OBJECT VIEW WHICH IS A SUPERCLASS OF ONE OR MORE OBJECT |
| |VIEWS AND MAY ITSELF BE INSTANTIATED. UNDER THIS CIRCUMSTANCE DIFFERENT MESSAGE |
| |INSTANCES MAY CONTAIN DIFFERENT OBJECT VIEWS. THE CHOICE STRUCTURE IS USED TO |
| |ACCOMMODATE THE ALTERNATIVES. |
|CHOICE MESSAGE ELEMENT TYPE |A MESSAGE CONSTRUCT THAT INCLUDES ALTERNATIVE PORTIONS OF THE MESSAGE. FOR AN AD HOC |
| |CHOICE, A STATE CHOICE AND A CHOICE DUE TO SPECIALIZATION, THE SENDER PICKS ONE OF |
| |THE ALTERNATIVES AND SENDS IT ALONG WITH A FLAG. FOR A VERSION CHOICE, THE SENDER |
| |SENDS ALL THE ALTERNATIVES, MARKED WITH HL7 VERSION NUMBER. THE RECEIVER PICKS THE |
| |ONE THAT MATCHES THE HL7 VERSION IT IS USING. |
|CHOICE, AD HOC |A CHOICE IN A MESSAGE THAT IS NOT A CHOICE DUE TO SPECIALIZATION OR A VERSION CHOICE.|
|CLASS |1. A KIND OR CATEGORY OF THINGS OR CONCEPTS. 2. A DEFINITION OF OBJECTS, IN TERMS |
| |OF PROPERTIES (ATTRIBUTES, METHODS, AND RELATIONSHIPS) THAT ALL OBJECTS OF THE CLASS |
| |HAVE IN COMMON. |
|CMET |SEE COMMON MESSAGE ELEMENT TYPE. |
|COLLECTION DATA TYPE |A DATA TYPE THAT REPRESENTS AN AGGREGATION OF DATA ELEMENTS, ALL OF WHICH ARE |
| |REPRESENTED BY ONE OTHER DATA TYPE. THE FORMS OF COLLECTION ARE SET, BAG, AND LIST,.|
|COLLECTION MESSAGE ELEMENT TYPE |A MESSAGE ELEMENT TYPE THAT CAN INCLUDE MULTIPLE OCCURRENCES OF SOME OTHER MESSAGE |
| |ELEMENT TYPE. COLLECTIONS ARE DECLARED AS SETS (UNORDERED, NO DUPLICATES), LISTS |
| |(ORDERED, DUPLICATES ALLOWED), OR BAGS (UNORDERED, DUPLICATES ALLOWED). |
|COMMON MESSAGE ELEMENT TYPE |A WORK PRODUCT THAT DEFINES DATA TYPES AND MESSAGE ELEMENT TYPES THAT BECOMES |
| |AVAILABLE TO BE INCORPORATED INTO HIERARCHICAL MESSAGE DEFINITIONS. |
|COMPOSITE DATA TYPE |THIS IS A TYPE ASSIGNED TO A MESSAGE ELEMENT TYPE WHICH TYPE CONTAINS ONE OR MORE |
| |COMPONENTS, EACH OF WHICH IS REPRESENTED BY AN ASSIGNED DATA TYPE. |
|COMPOSITE MESSAGE ELEMENT TYPE |A MESSAGE ELEMENT TYPE THAT CONTAINS A LIST OF OTHER, HETEROGENEOUS MESSAGE TYPES. |
|COMPOSITION AGGREGATION |A TYPE OF RELATIONSHIP. IN A COMPOSITE AGGREGATION RELATIONSHIP THE SOURCE AND |
| |DESTINATION CLASSES ARE ASSOCIATED AS WHOLE TO PART. |
|CONFORMANCE (COLUMN OF THE HMD) |A COLUMN WHEREIN A TECHNICAL COMMITTEE STATES WHETHER A MESSAGE ELEMENT MUST ALWAYS |
| |BE INCLUDED IN AN HL7 MESSAGE. THE COMMITTEE MAY SAY THAT IS REQUIRED (MUST BE |
| |INCLUDED), OPTIONAL (MAY BE LEFT OUT) OR NOT PERMITTED (MAY NEVER BE INCLUDED.) |
| |CONTRAST THIS WITH INCLUSION. |
|CONFORMANCE CLAIM |A SPECIFIC CLAIM THAT IS WRITTEN BY HL7 TO PRECISELY DEFINE THE BEHAVIOR OF AN |
| |APPLICATION WITH RESPECT TO ITS HL7 INTERFACES. FUNCTIONAL CONFORMANCE CLAIMS ARE |
| |SIMPLY A STATEMENT THAT AN APPLICATION CONFORMS TO AN APPLICATION ROLE. TECHNICAL |
| |CONFORMANCE CLAIMS ARE CALLED TECHNICAL STATEMENTS OF PERFORMANCE CRITERIA. THEY |
| |DEFINE THE BEHAVIOR OF AN APPLICATION IN SOME OTHER SENSE THAN THE MESSAGES IT SENDS |
| |OR RECEIVES. THESE MAY INCLUDE THE IMPLEMENTATION TECHNOLOGY SPECIFICATIONS THAT IT |
| |SUPPORTS, THE USE OF SPECIFIC OPTIONAL PROTOCOLS OR CHARACTER SETS, OR MANY OTHER |
| |BEHAVIORS. |
|CONFORMANCE CLAIM SET |A LIST OF THE IDENTIFIERS OF SPECIFIC HL7 CONFORMANCE CLAIMS, USED BY A SPONSOR TO |
| |DESCRIBE THE CONFORMANCE OF ITS APPLICATION. |
|CONSTRAINT |A DEFINITION OF THE DOMAIN OF AN ATTRIBUTE AS A SUBSET OF THE DOMAIN OF ITS DATA |
| |TYPE. CONSTRAINING IMPLIES RESTRICTING A DOMAIN AS DEFINED BY A DATA TYPE OR AN |
| |ATTRIBUTE OF A HIGHER LEVEL MODEL (RIM > MIM > HMD.) |
|DATA TYPE |THE TYPE OF A DATA FIELD. DATA TYPES MAY BE PRIMITIVE, COMPOSITE OR COLLECTION DATA |
| |TYPES. THEY DEFINE HOW A DATA FIELD WILL BE REPRESENTED IN MESSAGES. A MESSAGE |
| |ELEMENT TYPE DEFINITION (MET) WILL BE PROVIDED FOR EACH DATA TYPE. |
|DIM |SEE DOMAIN INFORMATION MODEL. |
|DOMAIN |1. THE PROBLEM OR SUBJECT TO BE ADDRESSED BY A SET OF HL7 MESSAGES OR BY A SYSTEM |
| |(“APPLICATION DOMAIN”.) SEE ALSO DOMAIN EXPERT, DOMAIN INFORMATION MODEL.) 2. THE |
| |SET OF POSSIBLE VALUES OF A DATA TYPE, ATTRIBUTE, OR DATA TYPE COMPONENT. ANY DOMAIN|
| |IS A SUBSET OF THE DOMAIN OF ONE DATA TYPE. THE DOMAINS OF DATA TYPES CAN BE |
| |RESTRICTED THROUGH CONSTRAINTS. 3. MORE SPECIFICALLY “VOCABULARY DOMAIN:” THE SET |
| |OF CODED CONCEPTS THAT ARE ACCEPTABLE FOR A CODED MESSAGE ELEMENT IN A SPECIFIC |
| |MESSAGE ELEMENT TYPE. SEE DOMAIN SPECIFICATION. |
|DOMAIN EXPERT |AN INDIVIDUAL WHO IS KNOWLEDGEABLE ABOUT THE CONCEPTS IN A PARTICULAR PROBLEM AREA |
| |WITHIN THE HEALTHCARE ARENA AND/OR IS EXPERIENCED WITH USING OR PROVIDING THE |
| |FUNCTIONALITY OF THAT AREA. |
|DOMAIN INFORMATION MODEL |A WORKING MODEL SPECIFIC TO A PROJECT USED BY A TECHNICAL COMMITTEE TO CAPTURE |
| |INFORMATION REQUIREMENTS. THE DIM BEGINS AS A SUBSET OF THE RIM. CHANGES APPLIED TO |
| |THE DIM ARE FORWARDED AS CHANGE PROPOSALS FOR THE RIM. |
|DOMAIN SPECIFICATION |THE SPECIFICATION OF A VOCABULARY DOMAIN, I.E. THE SPECIFICATION OF THE APPLICABLE |
| |CODED CONCEPTS FOR CODED MESSAGE ELEMENT INSTANCES. SEE DOMAIN (3.) |
|ENCODING RULES-7 |THE IMPLEMENTATION TECHNOLOGY SPECIFICATION THAT DESCRIBES HOW TO SEND HL7 VERSION 3 |
| |MESSAGES USING STREAMS OF PRINTABLE CHARACTERS. |
|ER7 |SEE ENCODING RULES-7. |
|EVENT |A STIMULUS THAT CAUSES A NOTEWORTHY STATE CHANGE OF AN OBJECT. A SIGNAL THAT INVOKES |
| |THE BEHAVIOR OF AN OBJECT. SEE ALSO TRIGGER EVENT. |
|EVENT CLASS |AN EVENT CLASS REPRESENTS AN ACTIVITY THAT OCCURS AT A LOCATION, AT A DATE AND TIME, |
| |FOR A DURATION, INVOLVING ONE OR MORE PARTICIPANTS, FOR A REASON. |
|FEATURE |A PROPERTY OF A CLASS OR OBJECT. |
|FUNCTION POINT |ANY FUNCTION, USER TRANSACTION, OR OTHER INTERACTION OR EVENT IN THE SPONSOR’S |
| |APPLICATION WHICH, WHEN IT OCCURS, DOES OR MAY CORRESPOND TO AN HL7 TRIGGER EVENT. |
| |USED TO DESCRIBE THE CONFORMANCE OF AN INFORMATION SYSTEM WITH THE HL7 STANDARD. |
|GENERALIZATION |1. THE ACT OF GENERALIZING, I.E. DEFINING A GENERAL CONCEPT OR CLASS THAT SUBSUMES |
| |ONE OR MORE SPECIAL CONCEPTS OR CLASSES. 2. A SO GENERALIZED CONCEPT. ANTONYM: |
| |SPECIALIZATION; SEE ALSO INHERITANCE. |
|GRAPHICAL EXPRESSION |AN EXPRESSION OF A MODEL THAT USES GRAPHIC SYMBOLS TO REPRESENT THE COMPONENTS OF THE|
| |MODEL AND THE RELATIONSHIPS THAT EXIST BETWEEN THOSE COMPONENTS. |
|HIERARCHICAL MESSAGE DEFINITION |THE WORK PRODUCT THAT DEFINES HL7 MESSAGE TYPES. A SINGLE HIERARCHICAL MESSAGE |
| |DEFINITION (HMD) DESCRIBES ONE OR MORE MESSAGE TYPES. AN HMD INCLUDES THE MESSAGE |
| |ELEMENTS, THE CONDITIONS UNDER WHICH THE MESSAGE ELEMENTS WILL BE PRESENT OR REPEAT, |
| |AND THEIR DEFINITION IN TERMS OF THEIR RELATIONSHIP TO ELEMENTS OF THE MESSAGE |
| |INFORMATION MODEL. |
|HL7 CONCEPT ID |A UNIQUE IDENTIFICATION ASSIGNED TO A CONCEPT BY HL7. THERE IS ONLY ONE ID FOR A |
| |CONCEPT ALTHOUGH IT MAY BE RELATED TO NUMEROUS SURFACE FORMS THAT ARE CODE VALUES |
| |THAT REPRESENT THE CODE OR TEXTUAL EXPLANATIONS OF THE CONCEPT. |
|HMD |SEE HIERARCHICAL MESSAGE DEFINITION. |
|IMPLEMENTATION TECHNOLOGY |A METHOD OF ENCODING AND SENDING HL7 MESSAGES. VERSION 3 IMPLEMENTATION TECHNOLOGIES |
| |WILL INCLUDE ER7, OBJECT-ORIENTED, AND, PERHAPS, EDIFACT. |
|IMPLEMENTATION TECHNOLOGY SPECIFICATION |A SPECIFICATION THAT DESCRIBES HOW HL7 MESSAGES ARE SENT USING A SPECIFIC |
| |IMPLEMENTATION TECHNOLOGY. IT INCLUDES, BUT IS NOT LIMITED TO, SPECIFICATIONS OF THE |
| |METHOD OF ENCODING THE MESSAGES, RULES FOR THE ESTABLISHMENT OF CONNECTIONS AND |
| |TRANSMISSION TIMING, PROCEDURES FOR DEALING WITH ERRORS. |
|INCLUSION |THE SPECIFICATION IN THE HIERARCHICAL MESSAGE DESCRIPTION OF WHETHER AN ELEMENT OF A |
| |MESSAGE TYPE MAY BE NULL IN SOME MESSAGE INSTANCES. CONTRAST THIS WITH CONFORMANCE. |
|INFORMATION MODEL |A STRUCTURED SPECIFICATION OF THE INFORMATION REQUIREMENTS OF A PROJECT. AN |
| |INFORMATION MODEL EXPRESSED THE CLASSES OF INFORMATION REQUIRED, AND THE PROPERTIES |
| |OF THOSE CLASSES, INCLUDING ATTRIBUTES, RELATIONSHIPS, AND STATES. |
|INHERITANCE |THE FACT THAT A SPECIALIZATION (SUBCLASS) HAS ALL THE PROPERTIES OF ITS |
| |GENERALIZATION (SUPERCLASS.) SEE ALSO PROPERTIES. |
|INTERACTION |AN ELEMENT OF THE INTERACTION MODEL THAT IS THE CONFLUENCE OF THE SENDING APPLICATION|
| |ROLE, THE RECEIVING APPLICATION ROLE, AND THE TRIGGER EVENT. IT SPECIFIES THE MESSAGE|
| |TYPE, PRECONDITIONS AND POST-CONDITIONS FOR SENDING THE MESSAGE AND RECEIVER |
| |RESPONSIBILITIES. |
|INTERACTION MODEL |THE COMPONENT OF THE MESSAGE DEVELOPMENT FRAMEWORK THAT DEFINES THE SPECIFIC |
| |INTERACTIONS (INFORMATION FLOWS) THAT ARE NEEDED TO SUPPORT THE FUNCTIONAL |
| |REQUIREMENTS DEFINED WITHIN THE USE CASE MODEL. APPLICATION ROLES, TRIGGER EVENTS, |
| |AND SCENARIOS ARE ALSO DEFINED WITHIN THIS MODEL. |
|INTERNAL DATA TYPE |AN HL7 DATA TYPE DEFINED TO SUPPORT THE DEFINITION OF OTHER DATA TYPES, BUT WHICH MAY|
| |NOT BE ASSIGNED AS THE TYPE FOR A DATA FIELD IN A HIERARCHICAL MESSAGE DESCRIPTION. |
|ITS |SEE IMPLEMENTATION TECHNOLOGY SPECIFICATION. |
|LIFO |SEE PUSHDOWN STACK. |
|LIST |A COLLECTION OF ELEMENTS WHOSE MEMBERS ARE ORDERED. |
|LITERARY EXPRESSION |AN EXPRESSION OF A MODEL IN TEXT. THE LITERARY EXPRESSION BALANCES THE DUAL NEEDS FOR|
| |A RIGOROUS, UNAMBIGUOUS EXPRESSION OF THE MODEL AND FOR A RENDITION THAT CAN BE |
| |EASILY READ AND INTERPRETED BY INDIVIDUALS WHO UNDERSTAND THE GENERAL CONCEPTS |
| |UNDERLYING OBJECT-ORIENTED MODELS, BUT WHO MAY NOT BE SCHOOLED IN FORMAL MODEL |
| |DEFINITION LANGUAGES. |
|MANDATORY |SEE INCLUSION. |
|MANDATORY ASSOCIATION |AN ASSOCIATION WITH A MULTIPLICITY MINIMUM GREATER THAN ZERO ON ONE END. |
|MANDATORY, FULLY |AN ASSOCIATION WITH A MULTIPLICITY MINIMUM GREATER THAN ZERO ON BOTH ENDS. |
|MESSAGE DESIGN MODEL |THE COMPONENT OF THE MESSAGE DEVELOPMENT FRAMEWORK THAT, BASED ON THE USE CASE MODEL,|
| |THE INFORMATION MODEL, AND THE INTERACTION MODEL DEFINES THE FORMAT OF HL7 MESSAGES. |
| |MESSAGE INFORMATION MODELS, AND HIERARCHICAL MESSAGE DEFINITIONS ARE DEFINED WITHIN |
| |THIS MODEL. |
|MESSAGE DEVELOPMENT FRAMEWORK |THE COLLECTION OF MODELS, METHODS, AND TOOLS THAT COMPRISE THE METHODOLOGY FOR |
| |SPECIFYING HL7 VERSION 3 MESSAGES. |
|MESSAGE ELEMENT |A UNIT OF STRUCTURE WITHIN A MESSAGE TYPE. |
|MESSAGE ELEMENT INSTANCE |AN ELEMENT WITHIN A MESSAGE INSTANCE. |
|MESSAGE ELEMENT TYPE |A PORTION OF A MESSAGE TYPE THAT DESCRIBES ON OF THE ELEMENTS OF THE MESSAGE. |
|MESSAGE INFORMATION MODEL |A SUBSET OF THE REFERENCE INFORMATION MODEL SPECIFIC TO THE INFORMATION CONTENT OF A |
| |SET OF MESSAGE TYPES. THE MIM MAY SPECIFY CONSTRAINTS ON THE INFORMATION THAT EXCEED |
| |THOSE SPECIFIED IN THE RIM. |
|MESSAGE INSTANCE |A PARTICULAR MESSAGE THAT IS SENT. TWO MESSAGES MAY BE DESCRIBED BY THE SAME MESSAGE |
| |TYPE AND IDENTIFIED WITH THE SAME INTERACTION AND YET VARY IN THE INSTANCE BECAUSE OF|
| |VARIATIONS IN VALUES, PRESENCE OR ABSENCE OF THE DATA BEING SENT AND DIFFERENT |
| |CARDINALITIES OF COLLECTIONS. OTHERWISE IDENTICAL MESSAGES MAY BE DIFFERENT INSTANCES|
| |IF THEY ARE SENT AT DIFFERENT TIMES OR BY A DIFFERENT SENDER. |
|MESSAGE OBJECT DIAGRAM |A TEMPORARY WORK PRODUCT THAT MAY BE USED BY TECHNICAL COMMITTEES AS AN AID TO |
| |DEVELOPING HIERARCHICAL MESSAGE DESCRIPTIONS. THE DIAGRAM THAT ENUMERATES THE OBJECTS|
| |THAT ARE REPRESENTED IN THE MESSAGE TYPES DEFINED BY A HIERARCHICAL MESSAGE |
| |DEFINITION. IT IS DERIVED FROM THE MESSAGE INFORMATION MODEL BUT REPRESENTS OBJECTS, |
| |WHEREAS THE MESSAGE INFORMATION MODEL REPRESENTS CLASSES. |
|MESSAGE TRACE DIAGRAM |A DIAGRAMMATIC REPRESENTATION OF A SCENARIO. |
|MESSAGE TYPE |THE ORGANIZATION OF MESSAGE ELEMENTS THAT IS SPECIFIED IN A HIERARCHICAL MESSAGE |
| |DEFINITION. A MESSAGE TYPE IN EFFECT CONSTITUTES A SET OF RULES FOR CONSTRUCTING A |
| |MESSAGE GIVEN A SPECIFIC SET OF INSTANCE DATA. IT ALSO DEFINES THE RULES FOR PARSING |
| |A MESSAGE TO RECOVER THE INSTANCE DATA. THE MESSAGE TYPE IS INDEPENDENT OF THE |
| |IMPLEMENTATION TECHNOLOGY SPECIFICATION, SO THAT IF THE SAME DATA IS SENT USING THE |
| |SAME MESSAGE TYPE AND DIFFERENT IMPLEMENTATION TECHNOLOGY SPECIFICATIONS IT WILL BE |
| |POSSIBLE TO TRANSLITERATE FROM ONE TO THE OTHER. |
|META-MODEL |A MODEL THAT INCLUDES TYPES WHOSE INSTANCES ARE ALSO TYPES. META-MODELS ARE OFTEN |
| |USED TO SPECIFY OTHER MODELS. FOR EXAMPLE, THE META-MODEL FOR A RELATIONAL DATABASE |
| |SYSTEM WOULD SPECIFY THE TYPES ‘TABLE,’ ‘RECORD,’ AND ‘FIELD.’ |
|MIM |SEE MESSAGE INFORMATION MODEL. |
|MIM WALK |A PORTION OF THE METHOD FOR CONSTRUCTING MESSAGE OBJECT VIEWS FROM A MESSAGE |
| |INFORMATION MODEL (MIM). THIS METHOD IS USED WHEN BUILDING A HIERARCHICAL MESSAGE |
| |DESCRIPTION. |
|MOD |SEE MESSAGE OBJECT DIAGRAM. |
|MODEL |A REPRESENTATION OF A PROBLEM OR SUBJECT AREA THAT USES ABSTRACTION TO EXPRESS THE |
| |RELEVANT CONCEPTS. A MODEL IS OFTEN A COLLECTION OF SCHEMA AND OTHER DOCUMENTATION. |
|MULTIMEDIA-ENABLED FREE TEXT DATA TYPE |THE DATA TYPE USED TO CAPTURE FREE TEXT AND ALL DATA THAT IS PRIMARILY INTERPRETED BY|
| |HUMANS USING RENDERING AGENTS THAT ARE OUT OF THE SCOPE OF HL7. SUPPORTED MEDIA TYPES|
| |INCLUDE PLAIN TEXT (CHARACTERS,) HTML, XML, AND WORD PROCESSOR DOCUMENTS, BUT ALSO |
| |AUDIO, IMAGES, AND OTHER TYPES OF MULTI-MEDIA DATA. |
|MULTIPLICITY |1. IN THE INFORMATION MODEL MULTIPLICITY IS A SPECIFICATION OF THE MINIMUM AND |
| |MAXIMUM NUMBER OF OBJECTS FROM EACH CLASS THAT CAN PARTICIPATE IN AN ASSOCIATION. |
| |MULTIPLICITY IS SPECIFIED FOR EACH END OF THE ASSOCIATION. 2. IN THE HMD, |
| |MULTIPLICITY DEPICTS THE MINIMUM AND MAXIMUM NUMBER OF OCCURRENCES OF A MESSAGE |
| |ELEMENT EXPRESSION IN A COLLECTION. |
|NOT PERMITTED |SEE CONFORMANCE. |
|NULL VALUE |A FAMILY OF VALUES THAT CAN APPEAR IN MESSAGE INSTANCES THAT INDICATE THAT DATA IS |
| |NOT PRESENT IN THE MESSAGE INSTANCE; THE VARIATIONS DESCRIBE ALTERNATE REASONS THAT |
| |THE DATA IS NOT PRESENT. |
|OBJECT |1. A THING OR CONCEPT THAT CAN BE PERCEIVED . 2. AN INSTANCE OF A CLASS. 3. A |
| |PART OF AN INFORMATION SYSTEM CONTAINING A COLLECTION OF RELATED DATA (IN THE FORM |
| |OF VARIABLES) AND METHODS (PROCEDURES) FOR OPERATING ON THAT DATA. THE TERM IS USED |
| |INCONSISTENTLY IN THE LITERATURE, REFERRING SOMETIMES TO INSTANCES AND OTHER TIMES TO|
| |CLASSES. |
|OBJECT IDENTITY |THE FEATURE THAT THE EXISTENCE OF AN OBJECT IS INDEPENDENT OF ANY VALUES ASSOCIATED |
| |WITH THE OBJECT. |
|OBJECT REQUEST BROKER (ORB) |A SOFTWARE MECHANISM BY WHICH SOFTWARE COMPONENTS INTERCHANGE REQUESTS AND RESPONSES.|
|OBJECT VIEW |A CONCEPTUAL ENTITY THAT REPRESENTS A SELECTION OF ATTRIBUTES DRAWN FROM A SINGLE |
| |CLASS OF THE MESSAGE INFORMATION MODEL IN REFERENCE TO A SPECIFIC OBJECT. |
|OBJECT-BASED |ANY METHOD, LANGUAGE, OR SYSTEM THAT SUPPORTS OBJECT IDENTITY, CLASSIFICATION, AND |
| |ENCAPSULATION. AN OBJECT-BASED SYSTEM DOES NOT SUPPORT SPECIALIZATION. ADA IS AN |
| |EXAMPLE OF AN OBJECT-BASED IMPLEMENTATION LANGUAGE. |
|OBSOLESCENT MESSAGE TYPE |A MESSAGE TYPE THAT HAS BEEN MARKED FOR DELETION IN A FUTURE VERSION OF HL7. IN A |
| |SUBSEQUENT RELEASE OF THE STANDARD IT MAY BE DECLARED AN OBSOLETE MESSAGE STRUCTURE. |
|OBSOLETE MESSAGE TYPE |A MESSAGE TYPE THAT HAS BEEN COMPLETELY REPLACED WITH ANOTHER AFTER HAVING FIRST BEEN|
| |DECLARED AN OBSOLESCENT MESSAGE TYPE. |
|POST-CONDITION |A PREDICATE STATEMENT DESCRIBING THE END STATE OF CLASSES AFFECTED BY A USED CASE. |
|PRECONDITION |A PREDICATE STATEMENT DESCRIBING THE REQUIRED STATES OF CLASSES FOR A USE CASE THAT |
| |ENABLES THE USE CASE TO BE PERFORMED. |
|PRIMITIVE DATA TYPE |IS A DATA TYPE THAT IS DEFINED AS A SINGLE ENTITY, AND WHOSE FULL SEMANTIC IS |
| |CONTAINED IN ITS DEFINITION. |
|PREDICATE REFERENCE |IN THE HIERARCHICAL MESSAGE DESCRIPTION, A MESSAGE ELEMENT THAT IS REFERRED TO IN THE|
| |PREDICATE DEFINING THE CONDITIONAL PRESENCE OF ANOTHER MESSAGE ELEMENT. |
|PRIMITIVE MESSAGE ELEMENT TYPE |A MESSAGE ELEMENT TYPE THAT CONTAINS A SINGLE DATUM. EXAMPLES INCLUDE STRING AND |
| |NUMBER. ALL OTHER MESSAGE ELEMENT TYPES ARE COMBINATIONS OF MESSAGE ELEMENT TYPES. |
|PROMOTE (AN OBJECT VIEW) |A TRANSFORMATION ON AN OBJECT VIEW IN A MESSAGE OBJECT DIAGRAM OR HIERARCHICAL |
| |MESSAGE DESCRIPTION IN WHICH THE PROMOTED OBJECT VIEW WHICH WAS ONCE CONTAINED IN |
| |ANOTHER OBJECT VIEW BECOMES A PEER OF THAT OBJECT VIEW. |
|PROPERTY |ANY ATTRIBUTE, ASSOCIATION, METHOD, OR STATE MODEL DEFINED FOR A CLASS OR OBJECT. |
| |PROPERTIES ARE THE SUBJECTS OF CLASS INHERITANCE. |
|PUSH-DOWN STACK |AN INFORMATION STRUCTURE FOR WHICH THE LAST ENTRY ADDED IS ALWAYS THE FIRST ELEMENT |
| |REMOVED. THIS IS ALSO KNOWN AS A “LAST IN-FIRST OUT” (LIFO) LIST. |
|RECEIVER RESPONSIBILITY |AN OBLIGATION ON AN APPLICATION ROLE THAT RECEIVES AN INTERACTION AS DEFINED IN THE |
| |INTERACTION MODEL. |
|RECURSIVE MESSAGE |A MESSAGE TYPE WHERE AN OBJECT VIEW CONTAINS ITSELF. THIS CAN OCCUR WHEN THE MIM WALK|
| |THAT THAT BUILDS A MESSAGE LEADS FROM A CLASS BACK TO THE SAME CLASS. |
|REFERENCE INFORMATION MODEL |AN INFORMATION MODEL USED AS A REFERENCE FOR PROJECT-SPECIFIC DOMAIN INFORMATION |
| |MODELS. THE RIM IS A COMPOSITE OF PROJECT SPECIFIC DIMS WITH DIM CONTENT CONFLICTS |
| |RESOLVED. |
|REFERENCE MODEL |THE MODEL WHICH SERVES AS THE AUTHORITATIVE REPOSITORY OF THE DATA, USE CASES AND |
| |OTHER ITEMS THAT HAVE BEEN DEVELOPED BY HL7. |
|REFLEXIVE ASSOCIATION |AN ASSOCIATION BETWEEN A CLASS AND ITSELF. |
|REQUIRED |SEE INCLUSION. |
|RIM |SEE REFERENCE INFORMATION MODEL. |
|ROLE CLASS |A CLASS THAT DEPICTS A ROLE ASSUMED BY A STAKEHOLDER, PERSON, OR ORGANIZATION. |
|ROLE NAME (OF AN ASSOCIATION) |SEE ASSOCIATION ROLE NAME. |
|ROOT OBJECT VIEW |THE OBJECT VIEW THAT RELATES TO THE SUBJECT CLASS OF A MESSAGE OBJECT DIAGRAM OR |
| |HIERARCHICAL MESSAGE DEFINITION. |
|SCENARIO |A STATEMENT OF HEALTHCARE RELEVANT EVENTS DEFINED AS A SEQUENCE OF INTERACTIONS. THE |
| |SCENARIO PROVIDES ONE SET OF INTERACTIONS THAT THE MODELING COMMITTEE EXPECTS WILL |
| |TYPICALLY OCCUR IN THE DOMAIN. USUALLY, A SEQUENCE DIAGRAM IS CONSTRUCTED TO SHOW A |
| |GROUP OF INTERACTIONS FOR A SINGLE SCENARIO. EACH SCENARIO IS DISPLAYED AS A SUBSET |
| |OF THE INTERACTION MODEL. |
|SET |AN HL7 DATA TYPE THAT CONTAINS AN UNORDERED LIST OF ELEMENTS OF SOME OTHER SINGLE |
| |DATA TYPE. A FORM OF A COLLECTION MESSAGE ELEMENT TYPE. |
|OPTIONAL |SEE INCLUSION. |
|SPECIFICATION |A DESCRIPTION OF A PROBLEM OR SUBJECT THAT WILL BE IMPLEMENTED IN A COMPUTER OR OTHER|
| |SYSTEM. THE SPECIFICATION INCLUDES BOTH THE DESCRIPTION OF THE SUBJECT AND ASPECTS OF|
| |THE IMPLEMENTATION THAT AFFECT ITS REPRESENTATION. ALSO, THE PROCESS OF ANALYSIS AND |
| |DESIGN THAT RESULT IN A DESCRIPTION OF A PROBLEM OR SUBJECT WHICH CAN BE IMPLEMENTED |
| |IN A COMPUTER OR OTHER SYSTEM. |
|SPECIALIZATION |1. THE ACT OF SPECIALIZING, I.E. DEFINING A SPECIAL CONCEPT OR CLASS SUBORDINATE TO A|
| |GENERAL CONCEPT OR CLASS. 2. A SO SPECIALIZED CONCEPT. ANTONYM: GENERALIZATION; SEE|
| |ALSO INHERITANCE. |
|SPONSOR (OF AN APPLICATION) |THE VENDOR, IN-HOUSE DEVELOPER, OR PROVIDER OF PUBLIC DOMAIN SOFTWARE FOR A |
| |HEALTHCARE INFORMATION SYSTEM. |
|STATE |A PROPERTY OF AN OBJECT THAT CHARACTERIZES A STEP IN THE ITS LIFE CYCLE. ALL STATES |
| |ARE REPRESENTED BY STATE FLAGS. AN OBJECT CAN BE IN MULTIPLE PARTIAL STATES |
| |SIMULTANEOUSLY. AN OBJECT HAS ALWAYS ONE JOINT STATE, I.E. THE COMBINATION OF ALL |
| |PARTIAL STATES EFFECTIVE AT A PARTICULAR TIME. |
|STATE ATTRIBUTE |AN ATTRIBUTE OF A SUBJECT CLASS USED TO SPECIFY THE JOINT STATE OF AN OBJECT. IN A |
| |MESSAGE, THE STATE ATTRIBUTE IS A SET OF STATE FLAGS EACH REPRESENTING CURRENTLY |
| |ACTIVE PARTIAL STATES. |
|STATE CHOICE MESSAGE ELEMENT TYPE |WITHIN A MESSAGE TYPE, A SET OF ALTERNATIVE MESSAGE ELEMENTS. IN ANY MESSAGE |
| |INSTANCE. THE SENDER INCLUDES ONE OF THE ALTERNATIVE FORMULATIONS, EACH PRECEDED BY A|
| |TAGS THAT IDENTIFIES THE STATE FLAG WHICH TRIGGERED ITS INCLUSION. |
|STATE DIAGRAM |A GRAPHICAL REPRESENTATION OF A STATE TRANSITION MODEL SHOWING STATES AS VERTICES |
| |(NODES) AND TRANSITIONS AS DIRECTED ARCS (ARROWS) BETWEEN THE NODES. |
|STATE FLAG |A DISCRETE VALUE OF A SINGLE ENUMERATED DOMAIN OF PARTIAL STATES. STATE FLAGS ARE |
| |INCLUDED IN A STATE ATTRIBUTE IN A MESSAGE INSTANCE THAT INDICATES THAT THE JOINT |
| |STATE OF AN OBJECT. |
|STATE TRANSITION |A RECOGNIZED TRANSITION FROM ONE STATE OF A CLASS TO ANOTHER STATE OR BACK TO THE |
| |SAME STATE. THESE TRANSITIONS ARE CLOSELY ASSOCIATED WITH TRIGGER EVENTS. |
|STATE TRANSITION MODEL |A SPECIFICATION FOR THE LIFE CYCLE OF A CLASS. |
|STATEMENT OF CONFORMANCE CRITERIA |A STATEMENT THAT THAT DESCRIBES THE SPECIFICATIONS FOR CONFORMANCE TO SOME SPECIFIC |
| |ASPECT OF AN HL7 SPECIFICATION. |
|STEWARD COMMITTEE |THE TECHNICAL COMMITTEE WITH PRIMARY RESPONSIBILITY FOR SPECIFYING PROPERTIES FOR A |
| |COLLECTION OF CLASSED IN THE RIM. THE STEWARD COMMITTEE MUST BE CONSULTED ON ANY |
| |CHANGES TO THE PROPERTIES OF CLASSES UNDER ITS STEWARDSHIP. |
|STEWARDSHIP REPRESENTATIVE |AN INDIVIDUAL MEMBER OF THE STEWARD COMMITTEE, AUTHORIZED BY THE COMMITTEE TO SPEAK |
| |FOR THE COMMITTEE AND TO REPRESENT THE INTEREST OF THE STEWARD COMMITTEE. |
|STORYBOARD |A STATEMENT OF HEALTHCARE-RELEVANT EVENTS DEFINED AS A SEQUENCE OF INTERACTIONS OR |
| |USE CASES. THE STORYBOARD PROVIDES ONE SET OF INTERACTIONS THAT THE MODELING |
| |COMMITTEE EXPECTS WILL TYPICALLY OCCUR IN THE DOMAIN. USUALLY, A SEQUENCE DIAGRAM IS|
| |CONSTRUCTED TO SHOW A GROUP OF INTERACTIONS FOR A SINGLE STORYBOARD. A STORYBOARD |
| |MAY ALSO BE DISPLAYED AS A SEQUENCE OF USE CASES. |
|SUBCLASS |A CLASS THAT IS THE SPECIALIZATION OF ANOTHER CLASS AND INHERITS PROPERTIES FROM THAT|
| |OTHER CLASS (SUPERCLASS.) ANTONYM: SUPERCLASS |
|SUBJECT AREA |A CONVENIENT AGGREGATION OF MODEL CLASSES USED TO PARTITION LARGE MODELS INTO |
| |MANAGEABLE SUBSETS |
|SUBJECT CLASS |A KIND OF CLASS THAT HAS BEEN DESIGNATED BY A TECHNICAL COMMITTEE AS INTERESTING, |
| |BECAUSE IT IS THE FOCUS OF A SET OF USE CASES AND/OR TRIGGER EVENTS. |
|SUB-STATE |AN IDENTIFIABLE STATE OF A CLASS THAT HAS A MORE SPECIFIC DEFINITION THAT AND IS |
| |ENTIRELY ENCOMPASSED WITHIN THE SCOPE OF ITS SUPER-STATE. |
|SUBSUME |1. TO INCLUDE OR PLACE WITHIN SOMETHING LARGER OR MORE COMPREHENSIVE (E.G., |
| |INDIVIDUAL PERSON AND ORGANIZATION ARE SUBSUMED UNDER THE CONCEPT OF STAKEHOLDER) 2. |
| |A TRANSFORMATION ON OBJECT VIEWS IN A MESSAGE OBJECT DIAGRAM OR HIERARCHICAL MESSAGE |
| |DESCRIPTION IN WHICH THE SUBSUMED OBJECT VIEWS ARE REMOVED AND THEIR CONTENTS BECOME |
| |A PART OF THE SUBSUMING OBJECT VIEW. |
|SUPERCLASS |1. A CLASS WHICH HAS SPECIALIZATIONS, I.E. THAT IS THE GENERALIZATION OF ONE OR MORE|
| |OTHER CLASSES (SOMETIMES CALLED “PARENT”.) ANTONYM: SUBCLASS. |
|SUPER-MOD |AN EXTENSION OF A MESSAGE OBJECT DIAGRAM THAT INCLUDES THE ATTRIBUTES OF THE OBJECTS,|
| |CHOICE STRUCTURES, DECISION TO SUBSUME OR PROMOTE OBJECTS (ACTIONS WHICH FLATTEN THE |
| |HIERARCHY) AND GROUPING OF MESSAGE ELEMENTS. |
|SUPER-STATE |A STATE OF A CLASS THAT ENCOMPASSES TWO OR MORE INDEPENDENT SUB-STATES. |
|SURFACE FORM (OF A CONCEPT) |A CODE VALUE OR TEXTUAL DESCRIPTION THAT REPRESENTS A CONCEPT IDENTIFIED BY AN HL7 |
| |CONCEPT ID. THERE MAY BE MANY DIFFERENT SURFACE FORMS ASSOCIATED WITH THE SAME |
| |CONCEPT ID. |
|TECHNICAL STATEMENTS OF PERFORMANCE CRITERIA|SEE CONFORMANCE CLAIM. |
|TRIGGER EVENT |AN EVENT WITHIN THE PROCESSES OF HEALTHCARE WHICH, WHEN RECORDED OR RECOGNIZED BY A |
| |HEALTHCARE INFORMATION SYSTEM, CREATES THE NEED FOR AN INFORMATION FLOW TO ONE OR |
| |MORE OTHER HEALTHCARE INFORMATION SYSTEMS. THE INFORMATION MAY FLOW MAY BE |
| |IMPLEMENTED BY ONE OR MORE INTERACTIONS. TRIGGER EVENTS ARE CLOSELY ASSOCIATED WITH |
| |STATE TRANSITIONS AND LEAF LEVEL USE CASES. |
|TYPE |A SPECIFICATION THAT LIMITS THE FORM THAT A MESSAGE ELEMENT MAY TAKE. WHEN APPLIED TO|
| |A DATA FIELD IT IS A DATA TYPE. WHEN APPLIED TO A SEGMENT EXPRESSION IT IS A SEGMENT |
| |EXPRESSION TYPE. |
|UNION MESSAGE |A MESSAGE TYPE THAT CONTAINS THE ELEMENTS OF SEVERAL MESSAGE STRUCTURES DRAWN FROM |
| |THE SAME HIERARCHICAL MESSAGE DEFINITION. A UNION MESSAGE INCLUDES ALL THE MESSAGE |
| |ELEMENTS THAT MUST BE SENT FROM ONE APPLICATION ROLE TO ALL OTHER APPLICATION ROLES |
| |IN RESPONSE TO A TRIGGER EVENT. |
|USE CASE |A DESCRIPTION OF A PROCESS BY WHICH ACTORS DO THINGS THAT LEAD TO THE NEED FOR |
| |INFORMATION INTERCHANGE. USE CASES MAY BREAK DOWN INTO COMPONENT USE CASES. A USE |
| |CASE MAY APPEAR AS A COMPONENT IN SEVERAL OTHER USE CASES. WHEN A USE CASE CONTAINS |
| |COMPONENT USE CASES, THE ORDER IN WHICH THEY OCCUR IS NOT SPECIFIED. SEE SCENARIO. |
|USE CASE MODEL |THE COMPONENT OF THE MESSAGE DEVELOPMENT FRAMEWORK THAT INCLUDES DEFINITION OF THE |
| |SCOPE OF AN INDIVIDUAL PROJECT, AND, THROUGH DEVELOPMENT OF USE CASES, PROVIDES A |
| |DESCRIPTION OF THE PROJECT’S BUSINESS PROCESSES. ACTORS AND CANDIDATE SUBJECT CLASSES|
| |ARE ALSO DEVELOPED WITHIN THIS MODEL. |
|USER |1. IN THE CONTEXT OF CONFORMANCE CLAIM, THE ORGANIZATION THAT USES AN APPLICATION. |
| |THIS IS FREQUENTLY THE BUYER BUT IN SOME CASES THE USER AND SPONSOR ORGANIZATIONS MAY|
| |HAVE BE PARTS OF THE SAME ORGANIZATION OR OTHERWISE HAVE A BUSINESS RELATIONSHIP |
| |OTHER THEN VENDOR-BUYER. 2. IN THE CONTEXT OF USE CASES A PERSON WHO INTERACTS WITH |
| |AN APPLICATION TO EITHER ENTER OR OBTAIN INFORMATION. |
|VERSION CHOICE MESSAGE ELEMENT TYPE |WITHIN A MESSAGE TYPE, A SET OF ALTERNATIVE MESSAGE ELEMENTS. IN ANY MESSAGE |
| |INSTANCE. THE SENDER INCLUDES ALL OF THE ALTERNATIVE FORMULATIONS, EACH PRECEDED BY A|
| |TAGS THAT IDENTIFIES IT WITH AN HL7 VERSION. |
|VOCABULARY DOMAIN SPECIFICATION |A COLUMN IN THE HIERARCHICAL MESSAGE DEFINITION THAT SPECIFIES THE VOCABULARY DOMAIN |
| |ASSOCIATED WITH A SPECIFIC, CODED DATA FIELD. THE COLUMN CONTAINS THE IDENTIFIER OF |
| |A VOCABULARY DOMAIN THAT DETERMINES THE VALID CONCEPTS. |
-----------------------
[1] The project scope statement should not be confused with the Technical Committee or Special Interest Group charter to which it is related. The TC or SIG charter defines the scope of an HL7 committee and is subject to approval by the HL7 Technical Steering Committee. The key criteria for a project scope statement is that it should be consistent with the charter of the committee that works on it.
-----------------------
N
I
N
I
R
I
I
I
I
I
I
[pic]
R
R
R
N
I
N
N
N
N
R
R
R
R
R
R
R
R
N
N
N
N
N
N
N
N
N
N
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- apa style guide cheat sheet
- fashion style guide for women
- 11 4 study guide answers biology
- apa citation style guide pdf
- documentation style guide template
- turabian style guide example paper
- gcu apa style guide template
- 4 4 study guide answer key
- gcu style guide template
- apa referencing style guide pdf
- apa style guide pdf
- apa style guide bibliography