HL7 Version 3 Statement of Principles
Revised 1/22/98
Introduction
This document gives an overview of the features and benefits of the process for developing HL7 Version 3. It describes the principles that have guided the development of the process. 
Why a Major New Version?
The original process for defining HL7 messages was established in 1987. It has served well since. However, as HL7 has grown in membership and its standards been used more widely, the organization has become aware of opportunities to improve the process and its outcomes. HL7 interface costs and implementation times are substantially better than the industry experience with proprietary interfaces. However, the costs and times are quite variable by vendor and the industry sees a need for improvement. Because of substantial optionality in HL7, it is difficult to specify precise contract terms for HL7 interfaces. This can lead to unrealistic expectations that hurt vendors and buyers equally. Furthermore, there has been no way for buyer to accurately judge the competence of a vendor’s system or staff before deciding on the vendor.
The complexity of the HL7 organization has grown considerably since the days when all the members of all the technical committees could sit together in a room. The number of specialized committees in HL7 and the size of each have grown substantially. These factors challenge the organization to provide improved “institutional memory” and access to the most important shared knowledge.
Difficulties with the Existing Process
The process for building version 2.X messages is entirely ad hoc. There is no explicit methodology. Members receive no formal guidance in constructing messages. Trigger events and data fields are described solely in natural language. The structural relationships among data fields are not clear. Segments are re-used in many messages and message definitions are reused for many trigger events. In order to accommodate the extensive re-use, most data fields are optional. Chapters are inconsistent in their use of trigger events versus status codes. There is no specification as to when a specific kind of healthcare information system should be expected to honor a trigger event or accept a message.
With version 2.x, a technical committee creates messages by editing word processing documents directly. The metadata is not available in a structured form until the staff and volunteers tediously extract it from the word processing documents after publication. 
In summary, there is substantial need to improve the eleven-year-old process to handle the breadth and complexity of the challenges HL7 faces today. The industry will gain if a new process supports specifications that are more rigorous. 
Opportunities to Improve
Fortunately, software practitioners learned a lot since 1987. There are better methodologies. Computer support is far more available and cost effective. However, HL7 cannot gain these improvements by minor tweaks to the old process.
HL7 spent four years characterizing its revised goals and creating a methodology to adapt modern analysis techniques from system building to message design. Initially the Executive Committee chartered an independent task force to establish the broad outlines of the approach. In January 1996, the Technical Steering Committee agreed to adopt the main features of the approach and take over its management. Planning work continued in the Modeling and Methodology Committee and the Control/Query Committee. At the completion of version 2.3, in the spring of 1997, the HL7 technical committees all began to use the Version 3 process.
Here are some features and benefits of the new approach.
•	The process is an explicitly documented methodology supported by training classes, trained facilitators and computerized tools. This helps functional committees meet the challenges of de novo interface design, more functional breadth and evolution of assumptions. It helps new members become productive in fewer meetings. The majority of the development time is spent creating use cases and an information model using the Unified Modeling Language that is rapidly becoming an industry standard. This is an enormous aid to providing institutional memory and sharing work in progress across committees and to the membership at large.
•	The methodology greatly limits the optionality in the HL7 specification. It offers explicit choice constructs in messages and it encourages and supports the development of more messages. The reduced optionality will greatly help HL7 to approach plug and play specificity. The slogan for Version 3 is, “optionality is a four-letter word.”
•	Conformance to HL7 Version 3 is specified in terms of Application Roles. These 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.
Limitations of the New Approach
Nothing is free or perfect. The new methodology has costs and limitations, particularly related to development effort and complexity. These must be balanced against the benefits.
The version 2.x process is more direct than that of Version 3. To change a part of the 2.x standard, one simply edits the change into the appropriate word processing document. In Version 3 one makes changes in the computerized models and then deals with the downstream consequences in the message structures. The disparity between the processes is most noticeable in introducing small changes into existing interfaces. When designing big changes or new interfaces each method requires time to achieve joint understanding and arrive at consensus. The well-documented and facilitated approach in Version 3 is arguably faster than an ad hoc process employed by a committee that changes members from one meeting to the next.
HL7 has added resources to support the more intense process. These include recruitment of a cadre of trained modeling facilitators, provisions for additional training, extension of the Working Group Meetings to five-days, and establishment of interim meetings to harmonize the models developed during the Working Group meetings. HL7 also invests some of its budget in computer software and staff support to assist the version 3 process, and to pay the travel expenses of certain leaders and facilitators to the interim meetings.
More Information
The remainder of this document describes the underlying principles of the Version 3 approach. The most recent version of the Message Development Framework contains much more information on the development methodology.^†
Definitions
The following material defines certain terms when they are written in this document with initial capital letters. Where these terms refer to an organizational unit with specific duties, it is understood that these duties may be assigned to an organizational unit that bears a different name through appropriate changes in HL7 by-laws or procedures.
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 sends or receives in response to trigger events.
Architecture Review Board | An organizational unit within HL7 responsible for assuring that HL7 work products are compliant with pre-established measures of quality and were developed using methods and processes that are consistent with the Message Development Framework, and the HL7 By-Laws and Procedures.
Board of Directors | The organizational unit of HL7 responsible for overall management of the HL7 organization.
Conformance Claim | A specific claim by the developers or vendors of a system with respect to its conformance to a subset of all Version 3 specifications.
Control Group | The Control/Query Technical Committee within HL7 or any future group responsible for developing standards for overall syntax, data types, and other aspects of the standard that are common to all functional areas.
Functional Committee | A Technical Committee of HL7 that is responsible for the development of the functional content of standards for one or more specific functional areas.
HL7 Affiliate | An organization in a country other than the United States that is licensed by HL7 to produce localized versions of its standards.
Informative Material | Material contained in the documents produced by HL7 and its Technical Committees that is not Normative Material. Informative Material may provide assistance in understanding or applying the Normative Material, but failure to comply with the Informative Material is not regarded as non-compliance with the standard.
Message | A group of information described by the HL7 Version 3 Standard that can be exchanged as a unit among healthcare information systems.
Message Development Framework | The document that describes the methodology for developing Version 3 messages.

Modeling and 
Methodology 
Committee

The organizational unit within HL7 responsible for (a) creating and maintaining the HL7 Version 3 development methodology and facilitating its use, and (b) maintaining a Reference Model that reflects the shared models that are developed and used by the Functional Committees

Normative Material | Material contained in the documents that define HL7 Version 3 that describe aspects that are required in order to be compliant with the standard. Compare to Informative Material.
Project Scope Definition | A brief document prepared by a Functional Committee to the creation or significant extension of the Normative Material included in the HL7 standards.
Technical Committee | Any committee of the HL7 Working Group that is directly involved in producing standards. Some, but not all Technical Committees are Functional Committees. Those that are not functional committees provide overall guidance and support to the process. These include the Control/Query and Modeling and Methodology Committees, and the Architecture Review Board.

Technical Steering 
Committee

The organizational unit charged with operational management of the development of HL7 specifications.

Trigger Event | As in previous versions of HL7, an event in the real world which, when recorded in or recognized by a healthcare application system, generates the requirement to send information to another healthcare application system. Unlike previous versions of HL7, the specification shall provide informative material that clarifies the meaning and context of trigger events.
Version 3 | A family of releases of the HL7 Standard produced according to this HL7 Version 3 Statement of Principles. The first such release will be HL7 Version 3.0.

Version 3 Development 
Process

The procedures followed in the production of Version 3.

In addition, this document uses "shall" and "should" to express specific levels of compliance:
Shall	describes an imperative that is mandatory for conformance with these principles.
Should	describes a suggestion that only is preferred but may be supplanted during the development of Version 3.
Principles of Version 3
Scope, Target Users
Version 3 shall be a standard for exchanging Messages among information systems that implement healthcare applications. 
Internationalization
Version 3 shall be developed to permit HL7 Affiliates to use it or to develop localized variants.
Support for Legacy Systems
As with prior versions, Version 3 shall be designed using a technological approach that permit 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 the International Standards Organization, Open Systems Foundation, Object Management Group. Similarly, HL7 will not require proprietary features of any operating system or software vendor. In practical terms, this means that Version 3 shall be able to exchange messages formatted in strings of printable characters, as is the case for all previous versions.
This does not preclude HL7 from deciding to develop variants of its specification that make use of the modern technologies provided that 
•	system builders will not be required to buy software from a sole source in order to implement Version 3, and
•	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 prior versions of HL7, Version 3 shall not be a standard for the functionality of the systems which exchange HL7 messages. However, where Version 3 includes a requirement to accept or send certain data or to send specific messages in response to trigger events or other messages, the application system may have to develop functionality to support those requirements.
Modes and Topologies
Version 3 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. Version 3 includes support for “one-to-many”, store-and-forward distribution of messages by an external software agent.
HL7 does not require a specific mapping of messages in a one-to-many environment, but the Version 3 notion of application roles strongly suggests one useful paradigm. When a trigger event occurs in a system that is fulfilling one application role it will frequently have an obligation to interact with multiple systems that implement different application roles. The sending system can send a single union message that contains the information for all the application roles that are on the network. These union messages are candidates for one-to-many distribution.
Inter-version Compatibility
Compatibility with Versions 2.X
The goals of Version 3 cannot be achieved while maintaining full compatibility with previous versions. However, Version 3.0 shall be developed to cover the information content of the last version in the 2.x series including attributes and trigger events. This should not be construed to mean that all attributes and trigger events shall be included in 3.0 in exactly the same form.
A network that includes a mixture of systems that implement Version 2 and Version 3 will require message translation. Because the Version 2 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 2.x and any implementation of Version 3. 
Compatibility among Versions 3.X
The goals for upward compatibility in Version 3 are
A.	HL7 will provide the maximum degree possible of interoperability among systems operating on older and newer versions of HL7 protocols in the Version 3 family through compatible enhancement.
a)	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.
b)	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.
B.	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.
a)	The messages associated with all interactions that are newly defined in a version of HL7 must not be sent to a receiver that conforms to the older version. 
b)	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.
c)	The obsolescent message structure may be declared obsolete and dropped when still another HL7 version is issued
d)	An obsolescent message structure may not be declared obsolete for at least two years from the date of the version that first declared it obsolescent.
e)	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.
C.	To the maximum degree possible, these restrictions should not impose limitations on the evolution of the overall reference model. 
D.	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 Role
An Application Role is a named description of a domain-specific way in which a healthcare information system may interact with others through HL7 Messages. The names of the Application Roles should be different than the names generally used to describe healthcare information system products, because they will be more fine-grained. A typical healthcare information system will probably fill several or many such Application Roles. {For example, the Functional Committees may define Application Roles such as "lab order sender", "lab order filler", "enterprise patient identification store", etc.) 
All sequences of Messages in Version 3 shall be related to a Trigger Event. The Trigger Event shall be clearly identified in a common field in all Messages.
Conformance Claims
These Roles shall be a basis for Conformance Claims. In making a Conformance Claim, a system developer shall identify the Application Roles to which it wishes to claim conformance. For these Application Roles, the Version 3 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.
Other Conformance Claims shall be created by HL7 to describe the ability of an information's system to conform to non-functional aspects of the specifications. These may include specific message encoding formats, communications paradigms, or measures to ensure the integrity and confidentiality of messages.
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 Requirements with Respect to Conformance Claims
User sites may contract with vendors to implement deviations from the HL7 conformance claims. Such arrangements are outside the scope of HL7. Failure of a vendor to agree with such an arrangement will not be considered a failure of its application to conform to HL7.
The Version 3 Development Process
The procedures used develop Version 3 shall be documented in the HL7 Policies and Procedures Manual. They shall be consistent with the Version 3 Methodology, assure that the standard is developed expediently, appropriately documented, consistent with the requirements for an approval by a balanced consensus, and compliant with the requirements for certification by the American National Standards Institute.
Project Scope
When a Functional Technical Committees undertakes a project to develop new normative material in Version 3 it shall create a brief description of the project for approval by the Technical Steering Committee. This Project Scope Statement will also be used for coordination of projects with other standards organizations. It shall contain a concise description of the needs to be met by the transactions.
The means by which a Project Scope Statement is approved shall be described in the Message Development Framework. It should include a vote by the Technical Steering Committee. 
When the work product is published as a draft or for ballot, the Project Scope Statement shall be published with it.
HL7 shall maintain and publish from time to time a list of all Project Scope Statement that have been approved but for which the corresponding Messages have not been approved.
If, in the course of a project the Technical Committee finds its work is exceeding the bounds of the authorizing Project Scope Statement it shall submit an amended statement for approval.
Version 3 Methodology
The development of Version 3 Messages will follow a methodology specified by the HL7 Modeling and Methodology Committee. It may amend the methodology from time to time. The primary document for describing the methodology will be the Message Development Framework (MDF). The Version 3 Methodology shall include work products that will be delivered by the technical committees. Portions of these work products shall be designated for three different treatments:
1.	included as a normative portion of the eventual standard
2.	included as an informative portion of the eventual standard
3.	not included with the standard, but published with minutes and archived.
The methodology shall meet the following requirements. These are annotated to indicate the work products described in the Message Development Framework that meet the requirements. The annotations further state whether the work product is normative or informative.
1.	a means of providing context to the definitions of Trigger Events (Use cases, state diagrams; informative)
2.	a means of specifying the information content of the Messages through acumen information model that clarifies the definitions and ensures that they are used consistently across all Version 3 Messages defined by all Technical Committees; (Reference Information Model; informative, but may be subject to a formal comment process)
3.	a means of specifying responsibilities of the senders and receivers of Messages (Interaction model; normative)
4.	a common description of the exact fields of a message and their grouping, sequence, optionality, and cardinality (hierarchical message definitions; normative)
5.	separate syntax specifications, describing the algorithms used to encode and transmit the messages in various implementation technologies including  (a) a printable character stream syntax similar to the current HL7 specification; (b) an object-oriented representation of the messages; and, (c) in the future, a possible representation consistent with the rules of the United Nations EDIFACT syntax. (Implementation Technology Specifications; normative).
The various syntax specifications for a message shall not depart from the common description of its contents, so messages in the different formats shall be functionally interchangeable.
The Modeling and Methodology Committee shall not have the right to determine the contents of the work products of the Technical Committees. It shall serve to facilitate their development and to negotiate changes among the Functional Technical Committees to ensure standard-wide consistency. If disputes cannot be resolved, they shall be resolved by the Technical Steering Committee with the approval of the Board of Directors.
Document Structure
The structure of Version 3 standards documents has not been determined at this time. When it is defined, all normative content will be available in a machine-readable form that is structured for easily assimilation into databases, software configuration tables, or automatically generated software.
Data Field Domains
To the maximum extent practical, the normative specifications shall include precise definitions of the values that a domain may take on. The means of specifying this may include algorithms or enumeration of values. Enumerated values shall be identified with a unique concept ID that can be related to one or more sets of codes. To the maximum extent possible, domain specifications shall make use of published authoritative sources of code values and contents. To the maximum extent possible, coded data fields shall include information to support the systematic release of revisions to the code set.
Quality Assurance Processes
The Architecture Review Board shall work with the Technical Committees and Modeling and Methodology Committee to define measures of quality of the work products of the standard. It shall also ensure that the Version 3 Process is explained in a manner that is clear and well understood by the membership.
The Architecture Review Board shall ensure that the work products are reviewed against such measures of quality, and that adherence to process are documented in a manner consistent with HL7 By-Laws and Procedures. The Architecture Review Board shall not have the right to amend the work products or disallow their distribution. It shall have the right to include with any work product a statement describing areas where it has determined that the work product has not met established measures of quality.
Disputes with the findings of the Architecture Review Board will be resolved through the Technical Steering Committee and, if necessary, the Board of Directors. 
Process Support
HL7 should provide reasonable funds to support the Version 3 processes including, but not limited to, acquisition and use of computer-based tools to support the development of work products, document conformance to process and create final deliverables. Appropriation of funds will be made by the Board of Directors in a manner consistent with the overall financial viability of the organization. 
Management
The standards development process shall be governed as defined by the HL7 By-Laws and Policies and Procedures. All development of procedures called for in this Statement of Principles shall be ratified by the Technical Steering Committee unless the By-Laws or Policies and Procedures require different approval.
Confidentiality and Security
Confidentiality of Patient Information
It is expected that the healthcare application systems that implement Version 3 will be required to have significantly more functionality to protect the confidentiality of patient information than has been common in the past. The new functions may include, but are not limited to, limiting the right to view or transfer selected data to users with specific kinds of authorization and auditing access to patient data. Version 3 should contain the necessary data objects, attributes and transaction contents to support conveying the necessary information from one healthcare application system to another, so that these systems may perform the confidentiality functions. The Functional Committees, the Control Group, and the Modeling and Methodology Committee shall all consider these issues while developing the HL7 Data Model and Version 3 messages. These groups should review the publications of all pertinent works in the healthcare industry.
Authenticated Authorization for Services
It is expected that the healthcare application systems that implement Version 3 will be required to have significantly more functionality to authenticate requests for services and reports of data than has been common in the past. The new functions may include, but are not limited to, electronic signature and authentication of users based on technologies more advanced than passwords. Version 3 should contain the necessary data objects, attributes and message contents to support conveying the necessary information from one healthcare application system to another, so that these systems may perform the authorization and authentication functions. The Functional Technical Committees, the Control Group, and the Modeling and Methodology Committee shall all consider these issues while developing the HL7 Data Model and Version 3 transactions. These groups should review the publications of the pertinent works in the healthcare industry, among others, in making this determination.
Security, Privacy, Non-Repudiation and Integrity 
It is expected that the technological platforms upon which Version 3 information systems developers implement applications that use HL7 will be required to have significantly more capability to protect the confidentiality and integrity of patient information than has been common in the past. The new functions may include, but are not limited to, public- and private-key encryption, and correspondent system authentication and non-repudiation. The Control Group should monitor these developments to see that Version 3 can be implemented on technological platforms that support these new functions.