hl7 v2.4 style guide - health level seven … · web viewdon't forget to look at the getting...

ANSI/HL7 V3.0-2001AUGUST, 2001

HL7 V3 Standard: Backbone, Draft 1.0,

March 2001Editor: 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, Version 3.0 © 2001. All rights reserved

Health Level Seven and HL7 are trademarks of Health Level Seven, Inc.

TABLE OF CONTENTSANSI/HL7 V3.0-2001 August, 2001................................................................................................................1

HL7 V3 Standard: Backbone, Draft 1.0, March 2001.....................................................................................1

Table of Contents.............................................................................................................................................2

Welcome...........................................................................................................................................................4

Introduction......................................................................................................................................................6

Mission.........................................................................................................................................................6

What is HL7?................................................................................................................................................6

Need for Standards.......................................................................................................................................6

Background...................................................................................................................................................7

GOALS OF THE STANDARD...................................................................................................................8

HISTORY OF HL7 DEVELOPMENT........................................................................................................9

Overview....................................................................................................................................................10

Scope......................................................................................................................................................10

Why a Major New Version?.......................................................................................................................12

Version 3 Principles...................................................................................................................................12

What's New with HL7 V3?.........................................................................................................................12

Contact Us..................................................................................................................................................12

HL7 V3 Ballot Instructions............................................................................................................................13

Introduction................................................................................................................................................13

Ballot Symbol Key.....................................................................................................................................13

Quick Start......................................................................................................................................................15

Introduction................................................................................................................................................15

HL7 V3 Publication Components..............................................................................................................16

Getting Started................................................................................................................................................18

HL7 Version 3 Standard: HL7 Style Guide, Release 1.0, March 2001. © 2001. All rights reservedDraft #1

Introduction................................................................................................................................................18

New Implementor.......................................................................................................................................18

New Implementor...................................................................................................................................18

Learn the Basics.....................................................................................................................................18

Management...............................................................................................................................................19

Manager..................................................................................................................................................19

Project Manager......................................................................................................................................19

Marketeer................................................................................................................................................19

Construct Site Agreement.......................................................................................................................20

Sign a Deal.............................................................................................................................................20

Interface Developer....................................................................................................................................20

Interface Analyst....................................................................................................................................20

Interface Programmer.............................................................................................................................20

Develop Interface...................................................................................................................................21

HL7 Standard Developer............................................................................................................................22

Standard Developer................................................................................................................................22

Develop the Standard.............................................................................................................................22

Glossary..........................................................................................................................................................24


WELCOMEWelcome 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:

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 culminating with a high level HL7 V3 introduction.

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.


INTRODUCTION

MissionTo provide standards for the exchange, management and integration of data that support 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 (SDO) operating in the healthcare arena. Most SDO 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 SDO) 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 StandardsThe organization and delivery of healthcare services is an information-intensive effort. It is generally accepted that the efficacy 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 mitigate 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. These pressures could be met by an environment containing a comprehensive system supplemented by departmental systems, or one consisting entirely of separate and discrete systems.

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 and idiosyncratic. At the very least, they do not possess a 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 some 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 eliminate 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.

BackgroundThe 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 implementors understand the context of the Standard. They are also sometimes specified to assist implementors 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 Level 7 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 STANDARDThe specifications of this Standard were developed in accordance with a priori 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 delineated as a set of goals:

a) 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.

b) immediate transfer of single transactions should be supported along with file transfers of multiple transactions.

c) 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).

d) 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.


e) 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.

f) 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.

g) 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 a priori 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.

h) 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).

i) 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 HISPP (Health Information Systems Planning Panel) process since its inception in 1992.

HISTORY OF HL7 DEVELOPMENTThe 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 are formed within HL7 to develop ideas and sponsor particular perspectives that are not covered by any single existing committee. If a special interest group’s activities warrant and a new chapter is considered necessary, they may petition the HL7 Technical Committee Chair and the Executive Committee to form a Technical 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:

a) specifications for the various functional areas have been refined and expanded.

b) formal liaison was developed with several other standards efforts: the ANSI HISPP (Healthcare Information Standards Planning Panel) for the coordination of healthcare standards efforts that has since been replaced by the ANSI HISB (Healthcare Information


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).

c) 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.

d) a chapter on the interface to a patient accounting system has been added.

e) a chapter on the reporting of ancillary results, clinical trials, product experience and waveform data has been prepared, harmonized with the ASTM 1238-91 Standard and with the direct, active participation of members of the ASTM E31.11 committee.

f) a chapter with a set of transactions to support the synchronization of master files between related information systems has been added.

g) 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.

h) 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.

i) a chapter defining the message set used in patient referral communications between mutually exclusive healthcare entities has been added.

j) a computerized data dictionary of all data elements and other message components has been created. Appendix A contains cross references and other information generated from this electronic data dictionary.

k) inconsistencies and mistakes which were discovered in the previous Versions 2.0, 2.1, 2.2 and 2.3 of the Standard have been addressed and documented in Version 2.3.1.

l) extensive additions have occurred in the Order/Entry and Clinical Observations chapters to include data element oriented results, pharmacy orders and administrations interface.

m) 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.

n) 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)).


Overview

Scope

It is useful to understand both what HL7 is and what it is not. This chapter, up to this point, represents some effort to give the reader an overall understanding of HL7 by looking at purpose, history, and some of its overall features and architecture. It is also of value 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. Some others of these topics may never be addressed by HL7 because they are being addressed 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:

j) 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.

k) 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 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.”

l) 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.

m) 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.

n)

1.1.1.1 Local Extensibility

Why a Major New Version?MDF Section 1.4

Version 3 PrinciplesMDF Chapter 2

What's New with HL7 V3?

Contact UsNeed further information, please contact us:

Health Level Seven, Inc.3300 Washtenaw Avenue, Suite 227Ann Arbor, MI 48104734-677-7777 (phone) 734-677-6622 (fax)E-mail [email protected]


mailto:[email protected]

HL7 V3 BALLOT INSTRUCTIONS

Introduction

Ballot Symbol KeyThe 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 Development Framework (MDF) are included for reference only; others, like the Version 3 Data Types Document, have already been balloted as an HL7 Normative document. Each documents 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 IconReference 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 Development Framework (MDF) 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. For example, for the initial release of Version 3, the Version 3 Data Types Specification will have been previously balloted as an HL7 Informative document. Since these documents have previously been balloted, you cannot cast a ballot for them in the current ballot package.

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 Version 3 Data Types Document and the Clinical Document Architecture will have been previously balloted as an HL7 Normative document. Since these documents


R

I

N

Status Description Iconhave 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 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. No documents are expected to have this status in the initial V3 ballot package.

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 informative document.


N

I

QUICK START

IntroductionThis 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 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

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.

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.

Message Development Framework

The Message Development Framework (MDF) is the cornerstone of the HL7 V3 Development Methodology. This document will help you understand why HL7 V3 is needed, all the pieces that comprise the HL7 V3 development process, and how each of these pieces are constructed. Everyone interested in HL7 V3 should review this document. Many of you will find the information invaluable as you proceed on your HL7 V3 adventure.

Reference Information Model

The Reference Information Model (RIM) is the foundation of the HL7 V3 Development Methodology. The RIM is a coherent, share 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 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.

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.


R

R

N

N

N

N

N

I

Implementable Technology Specifications

The Implementable Technology Specifications describe how HL7 messages are sent using a specific method of encoding.


N

GETTING STARTED

IntroductionThe Getting Started chapter 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 Implementor

Learn the Basics

New Implementor

New Implementor

A New Implementor is unfamiliar with HL7 terminology, methodology, and organization. A New Implementor 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. One would expect to learn the basic principles upon which HL7 Version 3 has been constructed. Upon completion of this Use Case, one would be prepared to learn more detailed information about Version 3.

While learning the basics, refer to:

- V3 Backbone Introduction

- V3 Backbone Glossary

- Message Development Framework Introduction


Management

Marketeer

Project Manager

Sign a Deal

Construct Site Agreement

Manager

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


- MDF Conformance Claims and Organizational Practices

- MDF 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:

- Cliff Notes (does not currently exist)

Interface Developer

Interface Analyst

Interface Programmer

Develop Interface

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.

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.

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.

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, 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:


- Message Development Framework

MDF Creating Message Specifications

- MDF Associating Vocabulary Domains with Attributes, Elements and Fields


HL7 Standard Developer

Develop the Standard

Standard Developer

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: http://www.hl7.org. This will help you pinpoint to which committee your knowledge and interest will be most compatible.

- Message Development Framework

- Reference Information Model

- HL7 V3 Abstract Data Types - Part 1

- Identify the section 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.

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.

Infrastructure Management Section - The Infrastructure Management Section defines the information structures and communication tools necessary to support the interactions specified by the Clinical and


http://www.hl7.org/

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.

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.
