Package Note to Readers

Responsible Group V3 Publishing Work Group
HL7

View Revision MarksHide Revision Marks

Table of Contents

Foreword
    1.1 Copyright Notice
    1.2 Standards Disclaimer Notice
    1.3 Ballot Questions
    1.4 Contact Us
Welcome
HL7 V3 Ballot Instructions
    3.1 V3 Voting Procedures
    3.2 What do the Colors on the Master Table of Contents Mean?
    3.3 What do the Colored Symbols in the Documents Mean?
V3 Packages
    4.1 Ballotable Documents in this V3 Ballot Package
        4.1.1 Foundation Documents
        4.1.2 Specification Infrastructure, Implementation Technology Specification and Services Documents
        4.1.3 Background Documents
    4.2 Other Foundation and Background Documents in the V3 Package
HL7 Version 3 Overview
    5.1 Why Version 3?
        5.1.1 Difficulties with the Existing Process
        5.1.2 Opportunities to Improve
    5.2 V3 Principles
    5.3 What's New with HL7 V3?
    5.4 Managing HL7 V3 Message Development
        5.4.1 Project Scope Definition
        5.4.2 HL7 V3 Methodology
        5.4.3 Quality Assurance Process
Getting Started
    6.1 New Implementer
        6.1.1 Learn the Basics
    6.2 Management
        6.2.1 Manager
        6.2.2 Project Manager
        6.2.3 Marketer
        6.2.4 Construct Site Agreement
        6.2.5 Sign a Deal
    6.3 Interface Developer
        6.3.1 Interface Analyst
        6.3.2 Interface Programmer
        6.3.3 Develop Interface
    6.4 HL7 Standard Developer
        6.4.1 Develop the Standard
HL7 Organizational Overview
    7.1 Mission
    7.2 What is HL7?
    7.3 Background
Endnotes

The 2018 Health Level Seven V3 Publication is copyrighted by Health Level Seven, International (HL7) and is therefore protected by the Copyright Law of the United States and copyright provisions of various international treaties. The effect of such laws and treaties is that you may not, without a license from Health Level Seven, International, copy or distribute HL7's publication Product.

HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm.

If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material.

  1. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7.

    INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7.

  2. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement.
  3. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part.

    NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7.

Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

Ownership. Licensee agrees and acknowledges that HL7 owns all right, title, and interest, in and to the Trademark. Licensee shall take no action contrary to, or inconsistent with, the foregoing.

Licensee agrees and acknowledges that HL7 may not own all right, title, and interest, in and to the Materials and that the Materials may contain and/or reference intellectual property owned by third parties (“Third Party IP”). Acceptance of these License Terms does not grant Licensee any rights with respect to Third Party IP. Licensee alone is responsible for identifying and obtaining any necessary licenses or authorizations to utilize Third Party IP in connection with the Materials or otherwise. Any actions, claims or suits brought by a third party resulting from a breach of any Third Party IP right by the Licensee remains the Licensee’s liability.

Following is a non-exhaustive list of third-party terminologies that may require a separate license:

Terminology Owner/Contact

Current Procedures Terminology (CPT) code set

American Medical Association

http://www.ama-assn.org/practice-management/cpt-licensing

SNOMED CT SNOMED International http://www.snomed.org/snomed-ct/get-snomed-ct or info@ihtsdo.org
Logical Observation Identifiers Names & Codes (LOINC) Regenstrief Institute
International Classification of Diseases (ICD) codes World Health Organization (WHO)
NUCC Health Care Provider Taxonomy code set American Medical Association. Please see www.nucc.org. AMA licensing contact: 312-464-5022 (AMA IP services)

The content of this document is not intended to be an alternative to, or replacement for, standards mandated for use within any jurisdiction.

If you have urgent questions regarding this publication or the V3 material you may contact the HL7 office at (+1) 734-677-7777 directly. When you call, identify to the operator that you are phoning regarding the V3 Ballot and you will be routed to immediate assistance.

Need further information, please contact us:

Health Level Seven, International. 3300 Washtenaw Avenue, Suite 227, Ann Arbor, MI 48104, USA
(+1) 734-677-7777 (phone) (+1) 734-677-6622 (fax) E-mail HQ@HL7.org

Welcome to the HL7 Version 3 Standard and to this ballot of the Version 3 (V3) messaging standard! This package is the result of many years of work within the HL7 community and an increasingly focused effort with each new ballot cycle. We believe it is a major step forward for global health information standards.

V3 is comprised of many separate documents. The document you are currently reading is the Package Note to Readers. It contains the following sections:

HL7 V3 Ballot Instructions - this section provides information helpful in completing the HL7 V3 ballot. If you plan to submit ballot comments, be sure to review this section.

V3 Ballot Packages - this section lists ballotable documents in this ballot web site. You can use it to quickly identify the location of ballot items. GO HERE FIRST!!!

HL7 Version 3 Overview - review this section to understand what HL7 Version 3 is, why we developed HL7 Version 3, and the principles underlying the Version 3 Standard.

Getting Started - provides guidelines and recommendation on how you can approach the HL7 V3 Publication.

HL7 Organizational Overview - provides a brief overview of the HL7 Organization, its mission and philosophy.

The V3 Publication is composed of two types of documents: Foundation and Domain. The Foundation documents are those documents that are broader in scope and tend to apply to all domain documents. The Version 3 Guide, the HL7 Vocabulary Domain and Reference Information Model, for example, are Foundation documents. Foundation documents also include the documents found in the Specification Infrastructure, the Implementation Technology Specifications and Services areas of the site. Domain documents are produced for a specific domain such as pharmacy or scheduling and contain the messages relevant to that domain. Most of the domain information currently in the V3 site are for the Universal Realm. When they are available, Realm-specific domain content is presented in a section following the Universal Domains section.

Below is a graphical representation of the Foundation documents.
bb_Backbone.gif

Below are two graphical representations of the Domain content. The first graphics displays the various domains with their logical groupings. Please note that the domains are not organized this way in the site, but rather listed alphabetically underneath the Universal Domains section. The second graphic displays common content types you will find in each domain, such as such as storyboards, DMIMs, Rmims, etc.
bb_backbone_3.gifbb_backbone_2.gif

The HL7 V3 Ballot Package is available for download from the HL7 website. The Package will change from ballot cycle to ballot cycle dependent upon the standards being balloted. Due to the size of the V3 ballot material and the availability of extensive supporting materials, it is not necessary to download the entire package. You can choose the parts that are most important to you. Please refer to the ballot cycle download page for a listing of items available for download. (Hint: Please right-click and select "Open in New Window.")

For this ballot cycle, the standard ANSI-required HL7 balloting procedure is followed:

  1. HL7 announces opening of balloting period (at least 30 days prior to ballot period start).

  2. Voters may register to vote in any of the available ballot pools. Voters must sign up for each specific pool in which they wish to participate. Ballot pools are available for sign up on the HL7 Ballot Desktop. (Hint: Please right-click and select "Open in New Window.") Special Note — New Deadline: Please note that the Ballot Pool Sign Up period ends immediately before the Ballot Pool Close deadline. Please be sure to sign up for any pools you are interested in before this deadline.

    (Special Note: If you have signed up for ballot pools and you do not see those ballot pools when you return to the Ballot Desktop, please be sure to click the "January 2018 Ballot Cyle" link in the left-hand navigation; this will resolve most user issues.) There are separate ballot pools for each of the ballot documents. Please note that several domain documents may be included in a single ballot document. You must log on to the HL7 Ballot Desktop in order to vote. All HL7 members can use their HL7 logins and passwords for this purpose. Non-members wishing to vote should contact HL7 to arrange for voting access by emailing Lynn Laakso (ballotmanager@hl7.org) and Linda Jenkins (linda@hl7.org) or calling (+1) 734-677-7777.

    The following apply to Ballot Cycle Voting:

  3. The voting period is open for at least 30 days.

  4. Voters may download ballot documents from the HL7 ballot cycle download page. (Hint: Please right-click and select "Open in New Window.")

  5. Voters may download a template of the ballot comment spreadsheet (a Microsoft Excel (tm) file) from the HL7 Ballot Desktop. (Hint: Please right-click and select "Open in New Window.") The spreadsheet should be used to communicate comments about the draft standards back to the work group when logging a vote.

  6. Upon reviewing a ballot document of interest, a voter logs his or her vote on the Ballot Desktop and has the option of providing a text comment with their vote or uploading a comment spreadsheet. When using the comment spreadsheet, a voter will manually identify the section or sections to which each comment applies and indicate the severity of the comment. Severity levels included:

    • Neg: Negative Vote - all negative votes in normative ballots must be resolved by the work group. However, the reconciliation rules are no longer as strict for STU and Informative ballots, although work groups must consider all Neg votes.

    • A-S: Affirmative Vote with Comment -Suggestion. Use this if the work group is to consider a suggestion such as additional background information or justification for a particular solution.

    • A-T: Affirm Vote with Comment - Typo.. If the material contains a typo such as a misspelled word, enter A-T.

    • A-C: Affirm Vote with Comment

    • A-Q: Affirm Vote with Question

    The ballot comment spreadsheet contains further instructions on completing it to ensure that comments are communicated to the appropriate work group.

  7. Organizational members may compile and combine comments for each pool and one representative from that organization can submit the collated spreadsheet on behalf of the organization to HL7. However, each organizational member must return and log his or her vote on that pool and, in the case of negative votes, indicate in the text comment that this vote refers to the comment spreadsheet already uploaded by another voter. Voters should be aware that if they refer to a voter who has not returned to vote or has not uploaded a comments spreadsheet by the end of that balloting period that their negative votes will be counted as "negative without comment" in accordance with HL7 Policy 14.04.01.

  8. Voters submit their votes via the HL7 Ballot Desktop indicating an overall Affirm or Negative vote. (Hint: Please right-click and select "Open in New Window.") Note: all voters have the option of submitting comments, however, for voters submitting a negative vote, the voter must support that negative by providing a text comment or uploading a completed comment spreadsheet for that ballot document.

On the V3 Ballot page, there are menus displayed on the left pane. You will notice that six colors are used. The colors determine the type of ballot document. The different types are enumerated below:

Icon Description

book-closed-yellow.gif

Yellow identifies an informative document. Informative documents are balloted according to a procedure outlined by HL7. While calling for consensus, the ballot procedure for informative documents is not as stringent as that for normative documents. Information documents are not submitted to ANSI for approval.
book-closed-green.gif Green identifies a reference document. Reference documents are not balloted and are included with the ballot material to assist with understanding and comprehension. The Glossary, for example, is a reference document.
book-closed-red.gif Red identifies a normative document. Normative documents are balloted according to procedures that adhere to ANSI's procedures. Normative documents must pass a full normative level ballot. Normative documents, once they've passed ballot, are submitted to ANSI for approval.
book-closed-blue.gif Blue identifies a group of documents that fall into one or more of the categories listed above. Many of the domain documents are grouped together under a blue section heading. This is simply an easy way to group documents.
book-closed-gray.gif Gray identifies a draft only document. Ultimately, this document may become normative, informative or reference but at the time of balloting, a gray book means that this document or document group will be draft only and not ballotable.
book-closed-orange.gif Purple identifies a normative document that is (or will be) a Standard for Trial Use (STU, formerly known as Draft Standard for Trial Use, or DSTU).

Within the documents, you may find several icons that are designed or colored in such a way as to introduce the ballot status of that particular item. Most commonly, main headings will have an icon for their ballot status. By hovering over the icons, you will find a descriptive term to better understand what this icon means. Here is a list of the ballot status icons used in these documents.

Ballot Status Icon Descriptions

Ballot Status Icon Descriptions (continued)

In addition to the above ballot documents the following are included in this publication to assist in the comprehension and application of Version 3 (which are not up for ballot):

Package Note to Readers (this document)

This document is the introduction or "home page" of the HL7 V3 publication and includes introductory information relevant to the entire V3 publication. This includes an HL7 Overview, and Introduction to V3, Ballot Instructions, and Getting Started sections.

HL7 Version 3 Guide - This document is a primer of the concepts and artifacts found in V3. This document is recommended reading for all V3 voters.

HL7 Concept Domains - This document includes listing of all vocabularies used in the HL7 standard. This includes structured vocabulary that defines the valid (or invalid) relationships between classes in the RIM and Code Set Vocabularies used to define attribute code sets.

Glossary - The Glossary contains a comprehensive list of terms and acronyms used throughout V3.

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

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 reused in many messages and message definitions are reused for many trigger events. In order to accommodate this extensive reuse, 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 Work Group 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.

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 HL7 Board of Directors chartered an independent task force to establish the broad outline of the approach. In January 1996, the Technical Steering Committee (TSC) agreed to adopt the main features of the approach and take over its management. Planning work continued in the Modeling and Methodology Work Group and the Infrastructure and Management Work Group. At the completion of v2.3, in the spring of 1997, the HL7 Technical Work Groups all began to use the Version 3 process.

The HL7 V3 standard development methodology is based on a set of principles providing a common philosophy for all HL7 V3 standard developers.

  • Internationalization: V3 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 worldwide HL7 organization. It SHALL also be possible for affiliates to develop and use localized variants.

  • Legacy Systems Support: As with prior versions, V3 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 V3 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 V3, 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 that exchange HL7 messages. However, where V3 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 will be included in V3 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 SHALL 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 SHALL 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 are 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 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 application roles.

    In making a conformance claim, a system developer identifies 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 V3 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 Work Groups, the Infrastructure and Messaging Work Group and the Modeling and Methodology Work Group shall consult with the Security Work Group while developing the HL7 Data Model and V3 messages.

  • Authenticated Authorization for Services: It is expected that the healthcare application systems that implement V3 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 Work Groups, the Infrastructure and Messaging Work Group and the Modeling and Methodology Work Group shall consult with the Security Work Group while developing the HL7 Data Model and V3 transactions.

  • Security, Privacy, Non-Repudiation and Integrity: It is expected that the technological platforms upon which V3 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 Work Group is monitoring these developments to ensure that V3 can be implemented on technological platforms that support these new functions.

  • HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles. HL7 employs a completely new development approach with V3. 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 work groups meet the challenges of de novo interface design, and increases functional breadth and evolution of assumptions. It helps new members become productive in a shorter period of time. This is an enormous aid to providing institutional memory and sharing work in progress across work groups and to the membership at large.

  • HL7 isn't just Level 7 any more! 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, work groups exist for XML, Security, Modeling & Methodology, Arden Syntax, CCOW 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 reused 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 use 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 v2.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 HL7 V3 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 V3, 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.

This section outlines the procedures used to develop the HL7 V3 messages. These procedures are based on the V3 Methodology, the Governance and Operations Manual (GOM). and the HL7 Essential Requirements. 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).

When a Work Group undertakes a project to develop new material in V3 it creates a brief description of the project for approval by the process defined in the Project Scope Statement Template, at //www.hl7.org/permalink/?ProjectScopeStatement. The project scope statement contains a concise description of the needs to be met by the transactions. This project scope statement is also be used for coordination of projects with other standards organizations. In fact, project scope statements must be reported to the ANSI so that ANSI can fulfill its standards coordination role. [1]

Project scope statements must be approved by the HL7 Technical Steering Committee.

The development of V3 messages follows the methodology specified by the HL7 Modeling and Methodology Work Group. HL7 may amend the methodology from time to time. The methodology includes a definition of work products delivered by the Work Groups. Portions of these work products are 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 specifies the following requirements. These are annotated to indicate the work products described in the V3 Guide that meet the requirements. The annotations further state whether the work product is normative or informative.

Requirement V3 Guide Construct(s) Level
A means of providing context to the definitions of trigger events Storyboards, state diagrams Informative
A means of specifying the information content of messages through a common information model that clarifies the definitions and ensures that they are used consistently across all V3 messages defined by all Technical Work Groups Reference Information Model Reference
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, optionality, and cardinality Hierarchical Message Descriptions Normative
Separate syntax specifications, describing the algorithms used to encode and transmit the messages in an XML based character stream syntax. Implementation Technology Specifications Normative

The Modeling and Methodology Work Group does not have the right to determine the contents of work products created by the Work Groups. It serves to facilitate their development, and to negotiate changes among the functional Work Groups to ensure standard-wide consistency. If disputes cannot be resolved by the Work Groups and/or the Modeling and Methodology Work Group, they shall be resolved by the TSC.

In order to ensure the highest quality of the work products produced during the course of V3 message development, the HL7 Board of Directors has created the ARB.

The ARB works with the Work Groups and Modeling and Methodology Work Group to define quality measures for the HL7 work products, measure the work products again them, and that adherence to the defined message development process is documented in a manner consistent with HL7 bylaws and procedures. The ARB does not have the right to amend work products or disallow their distribution. It does 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 ARB is expected to include a statement of its findings in an HL7 general ballot package. However, in order to assist Work Groups, and to avoid delaying the balloting process, the ARB attempts to make any significant comments as early in the ballot cycle as possible.

Disputes with the findings of the ARB are resolved through the TSC and, if necessary, the Board of Directors.

The Getting Started section provides guidelines and recommendation for how you should approach the HL7 V3 Publication. Each section 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 includes recommended reading that will help you build the HL7 V3 knowledge base you desire.

A New Implementer is unfamiliar with HL7 terminology, methodology, and organization. A New Implementer may or may not be a member of the HL7 organization.

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 V3 was constructed. Upon completion of this use case, you would be prepared to learn more detailed information about V3.

While learning the basics, refer to:

  • The Overview sections in the Backbone (this document)

  • Glossary

  • HL7 Version 3 Guide

 6.2.1Manager

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.

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.

 6.2.3Marketer

A Marketer is responsible for selling HL7 interfaces. He does not need to know the details, but must understand the major concepts and terminology.

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:

  • Backbone (this document)

  • Glossary

  • Refinement, Extension and Conformance to Version 3 document.

  • The Interaction Model chapter in the Version 3 Guide

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:

  • The What's New in V3? section of the Backbone (this document)

  • Refinement, Extension and Conformance to Version 3 document.

Interface Analysts review the interface requirements and write detailed interface specifications.

Interface Programmers code and test interface based on the interface specifications.

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 - This includes the Blood Bank, Care Provision, Clinical Document Architecture, Clinical Genomics, Laboratory, Medical Records, Medication, Pharmacy, Public Health Reporting, Regulated Studies, Specimen, Therapeutic Devices domain documents.

Administrative Management Section - This includes the Accounting and Billing, Claims & Reimbursement, Patient Administration, Personnel Management, Scheduling domain documents.

Specification Infrastructure / Messaging Section - This includes the Master File / Registry, Message Control Act, Query and Transmission Infrastructure domain documents.

Common Domains Section - This include the Common Message Element Types, Shared Messages and Clinical Statement Pattern domain documents.

Once you identify the section you can drill down through to the domain messages.

To complete your message development analysis, you will also need to fully understand:

XML Implementation Technology Specification - The Implementation Technology Specification describes how HL7 messages are sent using a specific method of encoding.

HL7 Concept Domains - HL7 Concept Domains are concepts you are most likely already familiar with. HL7 Concept 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:

  • Version 3 Glossary

  • The Vocabulary chapter and the HL7 Message Components section of the Version 3 Guide.

Standard Developers attend HL7 Working Group Meetings and participate in the creation of the HL7 V3 Standard Specification.

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 Work Group on the HL7 web site: http://www.hl7.org. This will help you pinpoint to which work group your knowledge and interest will be most compatible.

  • Version 3 Guide

  • Reference Information Model

  • HL7 Version 3 Data Types: Abstract

Identify the section in which you are most interested.

  • Health & Clinical Management Section - This includes the Blood Bank, Care Provision, Clinical Document Architecture, Clinical Genomics, Laboratory, Medical Records, Medication, Pharmacy, Public Health Reporting, Regulated Studies, Specimen, Therapeutic Devices domain documents.

  • Administrative Management Section - This includes the Accounting and Billing, Claims & Reimbursement, Patient Administration, Personnel Management, Scheduling domain documents.

  • Specification Infrastructure / Messaging Section - This includes the Master File / Registry, Message Control Act, Query and Transmission Infrastructure domain documents.

  • Common Domains Section - This include the Common Message Element Types, Shared Messages and Clinical Statement Pattern domain documents.

Once you identify the section you can drill down to the domain messages.

XML Implementation Technology Specification - The XML Implementation Technology Specification defines the representation of HL7 Version 3 data types and messages in XML, including the method to derive XML Schemas plus additional processing rules from HL7 V3 Hierarchical Message Descriptions (HMDs).

 7.1Mission

HL7's mission is 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.

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 clinical data, 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, pharmaceutical 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 SDOs, HL7 adheres to a strict and well-defined set of operating procedures that ensure consensus, openness and balance of interest. A frequent misconception about HL7 (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 key sets of clinical and administrative data.

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 the HL7 standards.

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

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.

  1. [source] The project scope statement should not be confused with the Work Group charter to which it is related. The WG charter defines the scope of an HL7 work group and is subject to approval by the HL7 TSC. The key criterion for a project scope statement is that it should be consistent with the charter of the work group that works on it.

View Revision MarksHide Revision Marks Return to top of page