This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Introduction to HL7: Content

From HL7Wiki
Revision as of 20:58, 19 December 2019 by JoshP (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

This page is obsolete

eLearning Initiative: Introduction to HL7

Co-developed by Education and Process Improvement Committees

Back to Introduction to HL7 CD Contract Main Page

What will I learn?

  • What are the problems HL7 may solve?
  • What is HL7?
  • What are the standards HL7 creates?
  • Who are the participants?
  • How do HL7 standards get developed?
  • How do I get involved?
  • Where do I go for additional information?
  • How are meetings organized?

What are the healthcare industry challenges that HL7 Standards addresses?

The Healthcare Industry continues to focus on providing healthcare to the patient, based on safety, effectiveness, and cost effectiveness.

Challenges in Healthcare

-Disparate healthcare information needs to be collected and presented at the point of treatment. Patient safety and effectiveness of care can be affected.

-The cost of healthcare is impacted by not having the right information at the right place at the right time. It leads to performing redundant medical tests.

-Transferring paper records is costly in this age of eCommerce.

-New areas of medicine continue to evolve. One example is clinical genomics, using genotype information along with phenotype information to aid in diagnosis and treatment. This means that new types of information need to be available for clinical care.

-A rise in public health issues impact new types of information that need to be shared electronically. For population health, bio-surveillance.

Why Standards help:

Standards are the most efficient way to facilitate the development of cost effective, interoperable systems.

Examples of How HL7 Standards help:

HL7 messages and documents can move healthcare information in a standardized way to the point of patient care.

Hl7 standards assist in moving information beyond the four walls of the hospital and clinics between all healthcare stakeholders.

HL7 standards assist in sharing public health information.

HL7 standards help enable the electronic health record and creation of a National Health Information Network.

The HL7 Clinical Genomics model assists in using genomic data in conjunction with other clinical information.

In sum, HL7 was created over 20 years ago to create healthcare standards to enable interoperability of healthcare information.

What is HL7?

Health Level Seven (HL7) is an international Standards Development Organization (SDO) operating in the healthcare arena. Health Level Seven is one of several American National Standards Institute (ANSI) -accredited SDOs operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data. Health Level Seven has agreements with other SDOs in an effort to gather broad input and harmonize standards development.

Headquartered in Ann Arbor, MI, Health Level Seven is like most of the other SDOs in that it 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 SDOs, Health Level Seven adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. A frequent misconception about Health Level Seven (and presumably about the other SDOs) is that it develops software. In reality, Health Level Seven develops specifications, the most widely used being a messaging standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data. Health Level Seven also publishes non-messaging standards covering system functions, clinical documents utilizing the Clinical Document Architecture (CDA), and Service Oriented Architecture (SOA) models.

Members of Health Level Seven are known collectively as the Working Group, which is organized into technical committees and special interest groups. The technical committees are directly responsible for the content of the Standards. Special interest groups serve as a test bed for exploring new areas that may need coverage in HL7’s published standards. A list of the technical committees and special interest groups as well as their missions, scopes and current leadership is available on this web site.

Types of HL7 Standards

History of HL7 Standards TimeLine.png

HL7 Diversifies.png

HL7 Mission

HL7 is an international community of healthcare subject matter experts and information scientists collaborating to create standards for the exchange, management and integration of electronic healthcare information. HL7 promotes the use of such standards within and among healthcare organizations to increase the effectiveness and efficiency of healthcare delivery for the benefit of all.


HL7's Strategies:

  • Develop coherent, extendible standards that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning.
  • Develop a formal methodology to support the creation of HL7 standards from the HL7 Reference Information Model (RIM).
  • Educate the healthcare industry, policy makers, and the general public concerning the benefits of healthcare information standardization generally and HL7 standards specifically.
  • Promote the use of HL7 standards world-wide through the creation of HL7 International Affiliate organizations, which participate in developing HL7 standards and which localize HL7 standards as required.
  • Stimulate, encourage and facilitate domain experts from healthcare industry stakeholder organizations to participate in HL7 to develop healthcare information standards in their area of expertise.
  • Collaborate with other standards development organizations and national and international sanctioning bodies (e.g. ANSI and ISO), in both the healthcare and information infrastructure domains to promote the use of supportive and compatible standards.
  • Collaborate with healthcare information technology users to ensure that HL7 standards meet real-world requirements, and that appropriate standards development efforts are initiated by HL7 to meet emergent requirements.
  • Develop system functional models to help guide the industry on the essential requirements for electronic health record and personal health record systems.

Interoperability Goal

HL7 has interoperability as a goal. This statement is supported in the mission statement for a number of the HL7 Technical Committees (TC) and Special Interest Groups (SIG) where you will often find the term interoperable or interoperability. Whether or not this goal is being achieved depends on the definition for interoperability that one is using and the level or type of interoperability that is desired.

Interoperability is defined within the HL7 Core Glossary, published August 2, 2006, as:

Core Glossary: In this context, interoperability refers to the ability of two or more computer systems to exchange information. • Main Entry: in•ter•op•er•a•bil•i•ty o Function: noun o Date: 1977 o ability of a system (as a weapons system) to use the parts or equipment of another system o Source: Merriam-Webster web site • interoperability o ability of two or more systems or components to exchange information and to use the information that has been exchanged. o Source: IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990 “Functional” interoperability is the capability to reliably exchange information without error. “Semantic" interoperability is the ability to interpret, and, therefore, to make effective use of the information so exchanged. In our context, "effective use" means that the information can be used in any type of computable algorithm (appropriate) to that information.

One of HL7’s strategies is to: Develop coherent, extendible standards that permit structured, encoded health care information of the type required to support patient care, to be exchanged between computer applications while preserving meaning. The strategy could be interpreted to mean that HL7 will develop coherent, extendible standards that support semantic interoperability in provision of patient care.

The HL7 Co-Chairs Handbook states that a goal of the HL7 Version 3 standards is semantic interoperability.

While the term “interoperability” is frequently used within the HL7 and HIT communities, it is often done with ambiguous or different meanings and contexts which has been a barrier to the ability of the industry to maximize utilization of technology to improve healthcare.

To overcome this barrier, groups within the industry have been working towards establishing a framework for defining, discussing, and measuring interoperability. The HL7 Electronic Health Record (EHR) TC approved the publishing of a paper written by the HL7 EHR Interoperability Work Group titled "Coming to Terms: Scoping Interoperability for Health Care". The paper introduces a framework for the definition of interoperability based upon their review of the literature and a survey of existing uses of the term across all industries. The Australian National E-Health Transaction Authority (NEHTA) has developed and published an Interoperability Maturity Model (IMM) to help e-health organizations improve their ability to use or deliver interoperable e-health systems. The “International Standards Organization (ISO)/TC 20514 Health Informatics – Electronic health records – Definition, scope and context” document discusses at some length the various forms of interoperability ( functional, semantic, etc). You can access this ISO document via your respective ISO national member body.

Within HL7, and possibly other HIT communities, the findings and recommendations in the "Coming to Terms" paper will become an accepted means to discuss and more importantly, understand, interoperability requirements. The following are key excerpts from this paper and if you would like to read the full text of the paper it is recommended that you contact one of the HL7 EHR TC Co-Chairs for information on how to obtain the paper.

Why Define Interoperability? Different assumptions about what interoperability can result in profound differences in what we do, when we do it, how resources are distributed, and which goals are met (if, in fact, they are met at all). Our definitions of interoperability dramatically affect how data is stored and used and how software is designed. If we don't understand the context for the information, how can we use it in the translational or clinical research process? In the May 2005 HIMSS Insider, Ed Larson expressed it this way:

“Why is defining interoperability so important? Certainly, lack of interoperability is commonly cited as the biggest barrier to attaining the promised benefits of HIT investment. One’s definition of interoperability shapes the size and scope of the problem and thus the response in terms of policy, resources and priorities.” [Emphasis added.]

The Work Group’s Consensus As a result of the working group’s research, evaluations, and findings (described above), three interoperability classification types emerged, namely: • Technical interoperability • Semantic interoperability • Process interoperability

Type 1: Technical Interoperability We determined to use the expression “technical interoperability” over “functional interoperability” (and several other expressions) to define the most basic, hardware-based form of interoperability. IEEE-90 defines interoperability as, “The ability of two different systems to exchange data so that it is useful”. When applied to health care, some health care organizations have adopted the term “functional” as in “Functional interoperability is the ability of two or more systems to exchange information so that it is human readable by the receiver.” The problem with the word “functional” is that is has so many possible meanings in health care domain. There are bodily functions, organizational functions, transmission of bits and bytes over a wire, computer software functions. Indeed, each definition reviewed had to be carefully examined in its context to be sure which of the above possible senses of the work “functional” was meant. Therefore, for the rest this paper, (and as our recommendation) we have adopted the term “technical interoperability.” It is quite crisp and narrow in scope: we are referring to hardware, transmission, and closely related functions like access and security management.

The focus of technical interoperability is on the conveyance of data, not on its meaning. Were it not for the fact that computers tend to use written language, this would be similar to the level of interoperability provided by voice communications, e.g., via a telephone. Technical interoperability encompasses the transmission and reception of information that can be used by a person but which cannot be further processed into semantic equivalents by software. Note that mathematical operations can be -- and frequently are -- performed at the level of technical interoperability. A good example is the use of a “check digit” to determine the integrity of a specific unit of transmitted or keyed-in data. The same mathematical formula is performed at each end of a transaction and the results compared to assure that the data was successfully transmitted.

Type 2: Semantic Interoperability To maximize the usefulness of shared information and to apply applications like intelligent decision support, a higher level of interoperability is required. This is called semantic interoperability which has been defined as the ability of information shared by systems to be understood… so that non-numeric data can be processed by the receiving system. Semantic interoperability is a multi-level concept with the degree of semantic interoperability dependent on the level of agreement on data content terminology and the content of archetypes and templates used by the sending and receiving systems.” HL7 also defined a quality that is necessary for optimal semantic interoperability to exist. The quality-based rationale of the HL7 semantic interoperability messaging standard asserts that health information systems will communicate information in a form that will be understood in exactly the same way by both sender and recipient.

Note that the greater the level of software-level semantic interoperability the less “human” processing is required. For some functions, this can provide relief from redundant, error-prone human data entry or analysis. However, it also creates opportunities for the intrusion of misleading information, even misguided policies, into patient care processes, if not thoughtfully and responsibly developed, tested and deployed. Full semantic transparency is indeed the Holy Grail of HIT informatics, but it is also the greatest scientific and ethical challenge. The maturation of the technologies of personalized genomic profiling are expected to allow us to predict the susceptibility of an individual and their offspring to potential difficulty, expense, disability, disease, and premature of painful death. What is to be done with this information? These are huge issues. Semantic interoperability is at the heart of them.

Type 3: Process Interoperability Process interoperability is an emerging concept that has been identified as a requirement for successful system implementation into actual work settings. It was identified during the project by its inclusion in academic papers, mainly from Europe, and by its being highlighted by an Institute of Medicine (IOM) report issued in July 2005 which identified this social or workflow engineering as key to improving safety and quality in health care settings, and for improving benefits realization. It deals primarily with methods for the optimal integration of computer systems into actual work settings and includes the following: • Explicit user role specification • Useful, friendly, and efficient human-machine interface • Data presentation/flow supports work setting • Engineered work design • Explicit user role specification • Proven effectiveness in actual use

If the above is too much verbiage or detailed descriptions of the three types of interoperability utilize the following three descriptions.

Technical Interoperability is concerned with the conveyance of payload. It neutralizes the effect of distance., is domain independent (OSI levels 1-6), and fundamentally based on Information Theory - Shannon (1948)

Semantic Interoperability communicates meaning unambiguously using Codes, Identifiers and Context. It is Domain specific (OSI Level 7) and is needed to understand, interpret and use data.

Process Interoperability enables shared human understanding that is needed to coordinate work processes and enable business systems to interoperate. It is essential if interoperability is to provide any benefits in the work place.

Hierarchy of Interoperability As a general rule, the analysis of definitions indicated that when the three types of interoperability – technical, semantic and process – were mentioned, they were hierarchically related as follows:

• if technical interoperability was mentioned (in the sense of exchange or use), it was mentioned either alone or in combination with the other types of interoperability; • if semantic interoperability was mentioned, technical interoperability was usually also specified; • if process/social interoperability was mentioned, it was typically mentioned along with both technical AND semantic interoperability.

Successful process interoperability relies on successful technical and semantic interoperability because the desired data must be successfully transmitted (technical interoperability) and properly understood (semantic interoperability).


HL7 is an international community of healthcare organizations, healthcare subject matter experts, vendors, developers of healthcare information systems, consultants and system integrators, related public and private healthcare services agencies, and information scientists collaborating to create standards for the exchange, management, and integration of electronic healthcare information. HL7 dedicates its efforts to ensuring concurrence with other United States and International standards development activities.

As an international organization HL7 doesn't have a specific international goal. All its goals (by definition) are international. Only if one explicitly wishes to talk about national vs. international goals does one need to distinguish between the two.

Recognizing that local efforts have to supplemented by a comprehensive international campaign to promote the HL7 standards, HL7 Inc. licenses international HL7 Affiliates to further these goals. International Affiliates are independent entities whose mission is to advance the acceptance and usage of HL7 on a worldwide basis, including the internationalization of the HL7 standards. These Affiliates comprise the HL7 Affiliates Council.

The internationalization of HL7 is represented in the following image showing the HL7 International Affiliates and countries that are in the process of becoming affiliates. At the HL7 January 2007 Working Group Meeting in San Diego, CA (USA) there were 464 participants from all over the world, including 16 countries and 13 affiliates.

File:HL7 International.png

International Mentoring Committee

To facilitate the adoption and implementation of the HL7 standards by the international community the International Mentoring Committee was chartered. The following describes their mission, mentoring methodology, and resource pool.

Mission The International Mentoring Committee will assist potential Affiliate organizations and struggling existing Affiliates with appropriate guidance and education to permit them to improve their processes and procedures sufficiently to become viable Affiliate organizations.

Additionally, assistance and education may be provided at an Affiliate national agency level to renew or strengthen governmental support of the Affiliate organization.

Mentoring Methodology In view of the globally dispersed locations of Affiliates and potential Affiliates, it is anticipated that most mentoring will take place via teleconferences, e-mail and meetings in conjunction with scheduled HL7 Working Group Meetings. Country visits and other international travel, to include bringing delegates to scheduled HL7 events will be dependent upon availability of funds and funding sources.

Examples of mentoring activities include: • Organizational and association strengthening, public advocacy and outreach, encouraging industry membership and stakeholder meetings, and providing or supporting certification training.

• Technical assistance visits and peer-to-peer exchanges to Affiliate or potential Affiliate countries.

• Visits by mentors, HL7 leadership, and key Affiliate Council members to key decision makers and persons of influence in the Affiliate, potential Affiliate or their national agencies.

• Visits to an HL7 Working Group Meeting, and other appropriate HL7 related venues by selected key decision makers and persons of influence from the Affiliate, potential Affiliate, or their national agencies.

Resource Pool The HL7 International Mentoring Committee will develop and maintain a list of individuals, firms, professional organizations, and other agencies who have agreed to assist any potential or struggling Affiliates; or who may be contacted for educating key decision makers and persons of influence as to the value of HL7 and Affiliate organizations.

Resource examples include:

• Names and titles of key decision makers and persons of influence in Affiliate and potential Affiliate countries

• Names of key persons representing current “high visibility” Affiliates who could be called upon to contact or visit key decision makers and persons of influence in struggling and potential Affiliate countries as “match-making” resources

• Individuals and firms who have expressed interest in a particular country, geographic region, Affiliate, or potential Affiliate

• U.S. and international firms who provide HL7-based products and services

• Health care institutions, agencies, and providers who actively use HL7 standards

More information regarding the International Mentoring Committee can be found on the HL7 website at

Who is HL7?

  • Providers, vendors, payers, consultants, government and others who have an interest in the development and advancement of clinical and administrative standards for healthcare
  • Membership is open to:

-U.S. members as organizations or individuals (Varying levels of financial support that provide increasing membership benefits for organizations.)
-Affiliate HL7 chapters and their members from dozens of countries around the world (Under our restructuring plan, the U.S. will become an Affiliate of an international HL7 organization by 2010.)
-Government and Foundation members provide additional perspectives, contracts, grants, and early adoption of draft standards.
-Paid staff provides publishing, conference management, and other services for the membership. HL7 is in transition to a new structure with a paid CEO and staff responsible for the HL7 financial model, marketing and more.


Membership in HL7 is available to everyone interested in the development of a cost-effective approach to system connectivity. Involvement and support from HL7's members is crucial to the ongoing expansion and enhancement of the HL7 standard and the overall success of the organization.

Individual or Organizational Membership:

Individual memberships are geared to those with a personal interest in the standard and should not reflect an affiliation to an organization or employer, while organizational memberships are designed for those who will be using the standard for business purposes.

Organizational memberships include benefits crucial to those who rely on the standard as part of their business plan -- the most critical of these being the right to distribute the standard to clients (i.e., as part of technical documentation or proposals) or to distribute the standard within their organization. An individual member may not use, copy, or distribute the standard for any purpose other than their personal participation in the maintenance and development of HL7 Standards.


HL7 is a volunteer organization, so you can contribute as much, or as little, as you are able to. Because HL7 meetings and activities are “open”; anyone can participate.

Some of the ways people can become involved include:

• Participation in the HL7 Working Group Meetings.

• Participation in the committee conference calls and list server threads occurring between Working Group Meetings.

• Volunteering to work on an identified task by one of the committees.

• Volunteering to become a HL7 mentor, HL7 model facilitator or HL7 vocabulary facilitator.

• Become a HL7 ballot reviewer.

Working Group Meetings

HL7 Working Group Meetings are held three times each year; in January, May and September. These working group meetings serve the following important purposes:

• They give the HL7 Technical Committees and Special Interest Groups a chance to meet face-to-face to work on the standards;

• They give the HL7 Administrative Committees and the Board of Directors a chance to meet face-to-face to conduct their administrative work;

• They provide an invaluable educational resource for the healthcare IT community both through participation in the meetings and the tutorials that are conducted;

• They provide an opportunity for the attendees to network and exchange knowledge and ideas that lead to advancement in healthcare information technology utilization.

The Fall meeting also includes a Plenary session that features presentations on various topics.

Standards Development HL7 has more than 40 technical committees (TCs) and special interest groups (SIGs) dedicated to specialized areas of interest such as Orders and Observations and Electronic Health Records. These technical committees and special interest groups are directly responsible for the content of the standards and spend much of their time at the working group meetings hard at work on standards development. Attending a TC or SIG meeting can be a great way to get a handle on what is going on in a particular area, and everyone attending an HL7 working group meeting is invited to attend any of the TC or SIG meetings.

Educational Sessions This working group meeting will offer numerous educational opportunities. Sessions will cover a full range of HL7-specific topics such as Version 2.x Implementation, Version 3, and the Clinical Document Architecture (CDA) among others. Educational sessions also branch out to cover general interest industry topics such as the Electronic Health Record, XML and Vocabulary Terminology

Schedule Overview Registration opens on Sunday, of the meeting week from 3:00 - 6:00 pm. Meetings and Tutorials are scheduled Monday through Friday, 09:00 am - 5:00 pm.

Online registration along with the working group meeting schedule can be found on the HL7 website at For those who are First Time Attendees you will also find a link to the HL7 First Time Attendee website which will provide information intended to make your attendance a pleasant and productive experience.

The working group meeting day will usually start out with a continental breakfast provided by HL7 which is followed by a general session where specific administrative reports, announcements, and schedule updates will be given. These general sessions occur Monday through Thursday. During the general sessions, the International Report is given on Monday, the Technical Steering Committee (TSC) Report is given on Tuesday, and the Board of Directors Report and Awards are given on Wednesday. Wednesday evening there is a networking reception that is sponsored by HL7 member organizations where beverages and food are provided.

Following the general session, the committee meetings and tutorials will be conducted through the rest of the day. Most of the committees will conduct business based on an agenda that has been developed prior to the meeting itself through committee conference calls or committee list servers. The agenda will usually include standard (s) ballot reconciliation for those committees that just completed a standard(s) ballot cycle. In addition to ballot reconciliation most technical committees will devote time for working on Version 2.x standards and Version 3.x standards. Current ballots normally take priority. Many of the committees will meet jointly during the day to work on interrelated and sometimes dependant standards development efforts.

Committees have defined decision making practices that specify how they run meetings, debate and vote on issues discussed in a meeting. HL7 By-Laws and Policy which are posted on the HL7 website at take precedence and the default conduct is Robert’s Rules of Order.

All of the meetings are open but here is some suggested meeting etiquette:

• Enter and exit as you need

• Seats can be hard to find

• There is an agenda, be prepared to work with the committee co-chairs and the agenda

• Keep your cell phones in “silent” or polite modes. Take calls outside of the room

Here is a HL7 cultural tip:

• Put your tutorial and meal tickets in your name tag pocket included in your registration packet.

You will find most people attending HL7 Working Group Meetings to be friendly, passionate, and helpful. One should feel free to ask anybody a question or seek clarification.

A fun and important part of the work group meeting day are the “Cookie Breaks”. The morning and afternoon cookie break not only provides some historically great cookies but also provides a very important opportunity for you to network with colleagues and become one of the HL7 “family”.

Lunch is provided as part of your registration and once again provides a great opportunity to network with others. On Monday and Tuesday you will find First Time Attendee lunch tables where First Time Attendees will be able to eat with other First Time Attendees and a HL7 volunteer who is there to welcome you and answer questions you may have.

The evenings are usually open for your individual activities unless you want to audit the Technical Steering Committee’s Monday evening meeting or the Board of Director’s Tuesday evening meeting.

The Technical Committees and Special Interest Groups set preliminary agendas for the “next” meeting during the current meeting.

In addition to the Working Group and Plenary Meetings, HL7 also conducts International Meetings, Educational Meetings, and HL7 approved Off Schedule Meetings.


This is the current staff information from the website. You should check the HL7 website at for contact information.

Chief Executive Officer

HL7 Staff

  • Executive Director
  • Associate Executive Director
  • Director of Membership Services
  • Administrative Coordinator
  • Tools Administrator
  • Technical Publications Manager
  • Director of Meetings
  • Director of Communications
  • Meeting Planning Coordinator
  • Director of Technical Services
  • Director, Project Management Office (PMO)


Whilst I understand the need to point out the role of SDOs, and the fact that HL7 is accredited by ANSI as opposed to another national standards institute (e.g. the Japanese, German or Egyptian standards institute), the result (in terms of marketing/positioning) re-affirms HL7 as a pure US-oriented aorganization, something we'd like to avoid. The roles of SDOs and the links to other sibling SDOs can/should be mentioned, but the slide that suggests that certain standards are used to communicate certain categories of data should not be in here. NCPDP, X12N and most ASTM standards are of no relevance outside of the US. Therefore it is recommended to stick to gneric comments about SDOs and relationships between SDOs, preferrably also mentioning that affiliates have relationships with their country's standards institutes and that they cooperate with SDOs relevant to their realm. Rene spronk 22:58, 28 April 2007 (CDT)

Health Level Seven (HL7) is an American National Standards Institute (ANSI) – Accredited Standards Developing Organization (SDO) which focuses on the electronic interchange of clinical, financial and administrative information among independent healthcare-oriented computer systems; e.g., hospital information systems, clinical laboratory systems, enterprise systems and pharmacy systems. Since being accredited HL7 has published many American National Standards (ANS) such as HL7 Version 2.2, HL7 Version 2.3, The Clinical Document Architecture, Release 2, Structured Product Labeling, and the HL7 Reference Information Model (RIM) to name but a few.

The American National Standards Institute (ANSI) coordinates the development and use of voluntary consensus standards in the United States and represents the needs and views of U.S. stakeholders in standardization forums around the globe. ANSI facilitates the development of American National Standards (ANS) by accrediting the procedures of standards developing organizations (SDOs). These groups work cooperatively to develop voluntary national consensus standards. Accreditation by ANSI signifies that the procedures used by the standards body in connection with the development of American National Standards meet the Institute’s essential requirements for openness, balance, consensus and due process. In order to maintain ANSI accreditation, standards developers are required to consistently adhere to a set of requirements or procedures known as the “ANSI Essential Requirements," that govern the consensus development process. Due process is the key to ensuring that ANSs are developed in an environment that is equitable, accessible and responsive to the requirements of various stakeholders. The open and fair ANS process ensures that all interested and affected parties have an opportunity to participate in a standard’s development. It also serves and protects the public interest since standards developers accredited by ANSI must meet the Institute’s requirements for openness, balance, consensus and other due process safeguards. You can find more information about ANSI and the ANSI Essential Requirements at

Like all ANSI-accredited SDOs, Health Level Seven adheres to a strict and well defined set of operating procedures that ensures consensus, openness and balance of interest. HL7 cooperates closely with other standards developers that are developing healthcare related standards such as:

• American Society for Testing and Materials (ASTM)

• Accredited Standards Committee X12N (ASC X12N)

• American College of Radiology (ACR)

• Clinical Data Interchange Standards Consortium (CDISC)

• College of American Pathologists - SNOMED International Division — SNOMED

• Digital Imaging and Communications in Medicine (DICOM)

• eHealth Initiative (eHI)

• European Committee for Standardization (CEN)

• Institute of Electrical and Electronics Engineers (IEEE)

• Integrating the Healthcare Enterprise (IHE)

• International Standards Organization (ISO)

• MedBiquitous

• National Electrical Manufacturers Association (NEMA)

• National Council for Prescription Drug Programs (NCPDP)



For more information about on any of the listed standards developers you can enter their name within your favorite internet search engine and go to their website.

The following slide illustrates where some of the standards developers’ standards would be utilized by a Healthcare Information System. (**Note - the slide may need some correction but is included here as an example of intent. **)

Healthcare Information System Standards Useage.png

Alliances, MOUs, Agreements

HL7 formalizes alliances and joint projects with external organizations through the use of Affiliate Charter Agreements; Associate Charter Agreements; and Memorandum of Understandings (MOUs). They are each a method of documenting an agreement between HL7 and external organizations. The primary distinction between the three forms of agreements is the extent to which rights are granted regarding use of the HL7 Standards and related work products; membership rights and privileges extended; and the degree to which the parties agree to collaborate on standards related projects and initiatives.

An Affiliate Charter Agreement is used to detail an agreement between HL7 Inc. and a national Affiliate organization. An Affiliate is a Country, Group of Countries, or geographic region that operate as independent entities whose mission is to advance the acceptance and usage of HL7 within their jurisdiction, including national extensions of the HL7 data exchange standards. This Agreement governs the rights and obligations of Affiliates. The Affiliate is eligible to be established as an official member organization, at the discretion of the HL7 Inc. Board of Directors, based upon the Affiliate's petition to HL7 Inc. for Affiliate status. HL7 Inc. grants to the Affiliate a nontransferable, royalty-free, non-exclusive right and license to use the HL7 Standard including the related documents and support materials collectively comprising the Standard within the territory and region administered by the Affiliate. The Affiliate is entitled to participate in the governance of HL7 Inc. and shall do so through participating in the election of the Affiliate Representatives on the HL7 Inc. Board of Directors.

An Associate Charter Agreement is used to detail an agreement between HL7 Inc. and an Associate. Associates are independent, nonprofit entities whose mission is to advance, nationally or internationally, the acceptance and usage of standards within healthcare. Such entities include, but are not limited to, other Standards Development Organizations (SDO), industry associations or consortiums, and other groups that share the vision of improved healthcare through standards. This Agreement defines and governs the rights and obligations of Associates. An entity is eligible to be recognized as an Associate organization, at the discretion of the HL7 Board of Directors, based upon the entity's petition to HL7. HL7 will recognize members of the Associate as members of HL7 for the express purpose of participation in working group meetings. In turn, the Associate will recognize HL7 members as Associate participants and extend such privileges as that entails.

A Memorandum of Understanding is used to detail an agreement between HL7 Inc. and an outside entity or entities. MOUs are made with independent, nonprofit entities whose mission is to advance, nationally or internationally, the acceptance and usage of standards within healthcare. Such entities include, but are not limited to, other Standards Development Organizations (SDO), industry associations or consortiums, and other groups that share the vision of improved healthcare through standards. This Agreement defines and governs the rights and obligations of each party. An MOU is established with external entities, at the discretion of the HL7 Board of Directors. An MOU typically outlines a process by which HL7 and the external entity can collaborate on joint projects and initiatives or how work products produced can be shared between the entities. An MOU does not extend membership privileges between the parties.

The HL7 website at has a link to a webpage that contains the current agreements between HL7 and external organizations. The following is a representative list of those agreements as of May 2007.

• Accredited Standards Committee X12 — ASC-X12

• American Dental Association — ADA o ADA Joint Project Statement

• American Society for Testing Materials — ASTM

• CEN/TC 251

• Clinical Data Interchange Standards Consortium — CDISC

• Digital Imaging and Communication In Medicine — DICOM

• eHealth

• Institute for Electrical and Electronic Engineers — IEEE

• Integrating the Healthcare Enterprise — IHE

• Medbiquitous

• National Council for Prescription Drug Program — NCPDP


• Object Management Group — OMG

• University of Nevada Las Vegas — UNLV

• College of American Pathologists - SNOMED International Division — SNOMED

• CHCF Associate Charter Agreement

• Liberty Alliance Project Associate Charter Agreement

• Workgroup for Electronic Data Interchange — WEDI

HL7 / ISO / CEN Collaboration • SDO Plan of Action for Global Health Informatics Standards

• Status of US/SDO Pilot Projects (Agenda Item 7) — ISO

Standards Ballot Process

The graphic came from the Co-chair handbook. The document can be found at: [1]

The end product of a ballot process is a document. The document could stand on its own. However, most balloted documents are a part of a published Standards Document (e.g., HL7 2.6, HL7 3.0, etc.)

Documents can be:

Reference Content is harmonized during HL7 meetings or approved by the HL7 Board. It is not subject to ballot acceptance.

Informative Content is balloted by the general membership. However, it is not considered to be a structural part of the Standard but only supporting information. Informative documents are similar to normative ballots with the exception that they are not submitted to ANSI for approval and thus the balloting rules/procedures are less stringent than those for balloting normative documents. Complete procedures for balloting informative documents are available on the web site at:

Normative Content is balloted by the general membership and is considered a structural component of the HL7 Standard. Negative ballots must be resolved. Normative ballots are reviewed by ANSI auditors every five years. The auditors are very thorough and will check to ensure that every negative balloter/commenter has been advised in writing of the status of their negative vote/comments and that each negative vote has either been withdrawn or the negative balloter informed of the appeals process.

Draft Standards for Trial Use (DSTU) Content is balloted by the general membership as the draft of a future standard which will, following a pre-specified period of evaluation and comment (usually 2 years), be expeditiously incorporated into normative standard.

Ballots normally progress through two or more cycles of “committee – level” ballots.

 •  Ballot pool is limited to declared interested members
 •  Negative votes must be accompanied with a specific reason justifying the negative vote.
 •  Affirmative w/edit change; Abstention with comment.

Committees must resolve negative votes:

 •  Accept the voters comment and recommended solution.
 •  Negotiate with the voter and get them to agree to withdraw their negative.
 •  Declare the vote non-persuasive.
 •  Voters may appeal to the TSC and Board. They can also re-vote their same negative vote
    on the next round of balloting.
 •  Substantive changes to a ballot (either to fix a negative or add new material) merit
    another round of balloting.

When all negatives are resolved at the committee level, a document proceeds to membership level balloting.

Membership ballots are reviewed by the entire membership in context with all other documents in the same release.

Problems uncovered in a membership ballot include inconsistencies across documents (chapters).

When 90% (for normative documents) or the responses are registered as affirmatives…and hopefully all negatives withdrawn, a document is ready for publication as an HL7 Standard.

A graphic of the Membership Level Balloting Process: Membershiplevelballotingprocess.jpg

Describe the picture

The formal balloting process is quite complex; however, a generalization of the process is:

  • A committee will bring forward specific material to be included in a ballot cycle as either a committee level or a membership level ballot.
  • The ballot is open for public comment/vote a predetermined length of time.
  • As part of the standards approval process, upon closure of the ballot cycle, committees must resolve/reconcile the votes.
  • When all negatives are resolved at the committee level, a document proceeds to membership level balloting.
  • Membership ballots are reviewed by the entire membership in context with all other documents in the same release.
  • When 90% (for normative documents) or the responses are registered as affirmatives…and hopefully all negatives withdrawn, a document is ready for publication as an HL7 Standard.

Technical Committees, SIGS, Technical Steering Committee

The Working Group consists of the set of individual Technical Committees (TC) and Special Interest Groups(SIG) that has been approved by the Technical Steering Committee and is focused on particular HL7 protocol specification issues and areas.

Technical Committee

A Technical Committee may be established for any subject domain that is unique in its requirements for data interchange. A Technical Committee (TC) shall be established upon petition by at least five (5) members in good standing to the Technical Chair and affirmation by vote of the Technical Steering Committee and Board of Directors. The Technical Chair shall appoint an acting chair to preside over the first two meetings of the TC, which is to elect co-chairs by majority vote of the meeting participants who shall number at least five (5) members in good standing. Co-chairs may be re-elected for any consecutive number of terms.

Special Interest Groups

A Special Interest Group (SIG) may be established for the purpose of focusing on a particular aspect of the standard or on a particular user requirement. The purpose of the a SIG is to make sure the Standard meets the need of an identified group. A SIG must have a parent TC. The petition for the establishment of a SIG shall be submitted in writing to the parent TC Chair. The petition must include the mission statement, goals and objectives of the proposed SIG. If the parent TC Chair accepts the petition, it is presented to the Technical Steering Committee with a recommendation for approval. Disapproval by the parent TC Chair may be appealed to the Technical Chair, whose decision is final. A SIG may petition the Technical Steering Committee to become a TC upon approval of the parent TC Chair.

Technical Steering Committee

The Technical Steering Committee (TSC) shall determine the appropriateness of petitions to establish a TC or SIG by evaluating its relationship to other TCs and its uniqueness. The TSC also approves or disapproves petitions submitted to them that crosses TC, SIG, and in some cases membership boundaries.

  • Who makes up the Technical Steering Committee

The TSC is comprised of a Technical Chair, Technical Vice-Chair, the Technical Secretary, and one of the co-chairs of each TC and SIG.

How do committees get work done?

  • TCs and SIGs do work through member participation and responsible leadership.
  • If no one is interested in a topic, no work will take place and the group will be disbanded.
  • Active members step-up when the time comes to a leadership role.
  • HL7 work also takes place between scheduled Working Group Meetings.
  • Most Committees and SIGs also conduct some work via email, web page downloads, respective list servers and conference calls.

Formal Committee Structures

  • Mission Statement - each committee has a Mission Statement which defines the purpose and focus of the committee.
  • Charter Statement - each committee has a Charter which outlines strategies and goals of the committee.
  • Decision Making Practices (DMP) - Committees have adopted DMPs (or use the generic DMP)which governs the operations of the committee and includes:
  • Quorum and voting
  • Meeting frequency (workgroup, concalls)
  • Venues of notification, advance agendas
  • Minutes posted and record committee decisions
  • Revising prior decisions
  • Roberts Rules

How do I get involved in a TC or SIG?

  • Review the Mission and Charter
  • Sign up for the listserv
  • Review the minutes for recent committee meetings
  • Attend meetings and conference calls
  • Contact the co-chairs (emails on the committee page)
  • Speak up and volunteer to do work!


What defines a project?

HL7 work effort or work product is considered a project if it:

  • involves a group outside of HL7 (may require Board approval),
  • requires external funding (may require Board approval),
  • is going to be balloted,
  • requires cross-committee participation, or
  • is determined to be a project by the committee

All projects will have a project scope statement.

An HL7 project:

  • has an objective
  • will have a finite existence (the end date to be determined by the resources available and the start date), and
  • will have a budget (though it may be looking for funding to support that budget

What are project criteria?

An HL7 project will:

  • Be consistent with HL7 strategic direction
  • Include appropriate project documentation - project charter, scope, resources, timelines, assumptions, constraints, planned deliverables, etc. per PMO methodology
  • Be aligned with market demand
  • Be sponsored by stakeholders intending to implement the product produced by the project
  • Define a reasonable balloting strategy to meet market demand and implementation timelines
  • Define how the project will engage with other impacted committees
  • Follow project approval protocols to ensure appropriate project socialization and sign-off has taken place

How do they start?

HL7 project process:

  • A request is made to the HL7 Board, an HL7 Board-appointed committee, an HL7 Technical Committee (TC), or an HL7 Special Interest Group (SIG).
Anyone can make a request
A request can be a specific proposal or as a result of cross-domain discussions. There is recognition of a work effort that is needed to be done and a project is needed to be formed (meets the definition of a project), coordinated and exposed to more than those that are doing the work.
  • Obtain approval for request
If this request is within scope of an existing project, the requestor (and other interested parties) should be referred to that project for approval to be included. No new project is formed.
An example of folding a request into an existing project: Proposals for Version 2.7 Chapter 2a. Once a decision is made for a Version 2.7 for Chapter 2a, new proposals might be able to be subsumed in the current committee level ballot preparation work if the committee agrees.
If not part of another project and one or more of the following is true for this request, this request is considered a project:
~involves a group outside of HL7 (may require Board approval)
~requires external funding (may require Board approval)
~is going to be balloted
~requires cross-committee participation
~is determined to be a project by the committee
  • Prepare Project Scope Statement

A graphic of the project lifecycle: Projectlifecycle.jpg

What are some project examples?

A future enhancement will arrive when the PMO tool is rolled out to the membership, estimated to be September 2007.

Why get involved in HL7?

  • Shape the direction of the healthcare standards being created by directly participating in HL7 Committee Meetings. This helps ensure that your organizations' business needs are represented within the standards that are produced
  • Get educated on the healthcare standards that can be implemented today
  • Understand the direction of the healthcare standards (headlights) for where the healthcare standards industry is headed
  • Meet face to face and online with peers in the healthcare standards community in shaping the direction of the global healthcare standards


The HL7 Marketing Committee creates promotional material on HL7 standards which helps educate and position the various HL7 standards. Material available includes press announcements, white papers, brochures for handouts at conferences, and charts about HL7 standards. The HL7 Marketing Committee welcomes input from the healthcare standards community and invites individuals to participate in our projects.

Please visit the HL7 website at for additional information.

HL7 Website

The HL7 website, at, provides general information about the organization, its members, board of directors, committees and staff, along with with online versions of the HL7 newsletter and program brochures. It also offers online access to our bookstore and online registration for membership and upcoming working group meetings.

The members only area contains actual balloted standards, work-in-progress and member directories.

The following screen shots are illustrative of the information or access to information provided by the HL7 Website. ***Note The screen shots are absent but the statement conveys the intent for the content. The screen shots will be included in a subsequent phase of the contract activities. ***

Getting Involved

  • Determine target committee (s)
  • Sign up for the list serve (s) Link to list serve signup
  • Conference call schedule (s) Link to conference call schedule calendar.
  • Register for the next meeting Link to brochure and registration page for the next WGM.

"This is a duplicate slide (Where do I go from here?) with a different title and one should be deleted."

What if I cannot attend meetings?

HL7 work is done at the Working Group Meetings which occur three times a year. While there are many benefits in attending these meetings it is not necessary to become involved.

Responding to ballots about three times a year is critical to shaping HL7. This can be done on-line through the ballots link which you will find on the HL7 website at A lot of work is done on list servers; there are many to choose from and you can sign up for them through the List Servers link found on the HL7 website. Also, regular conference calls are an option; committees and special interest groups often conduct calls weekly. Many collaborative efforts are now taking place on the HL7-focused WIKI hosted by the Mayo Clinic (

Links to Other Standards Developers

If such a list is published, please make sure it is truly an international one and not US-oreinted. This again to re-enforce our marketing message that HL7 is an international organization. Rene spronk 23:00, 28 April 2007 (CDT)
  • ADA (American Dental Association) - for exchanging data processing standards to the dental services of the health care industry
  • ANIA (American Nursing Informatics Association) - for exchanging data processing standards to the nursing services of the health care industry
  • ASTM (American Society of Testing Materials) - for exchanging messages about clinical observations, medical logic, and electrophysiologic signals. There are other standards about healthcare identifiers, system functionality, etc.
  • CEN
  • CDC (Centers for Disease Control and Prevention)
  • CDISC (Clinical Data Interchange Standards Consortium) - is an open, multidisciplinary, non-profit organization committed to the development of industry standards to support the electronic acquisition, exchange, submission and archiving of clinical trials data and metadata for medical and biopharmaceutical product development.
  • CPRI-HOST serving as a neutral forum for bringing diverse interests together to raise issues, exchange ideas, and develop common solutions for management of health information.
  • DICOM (Digital Imaging and Communications in Medicine) - for exchanging clinical images
  • ICCBBA, Inc. - enhances safety for patients by managing the ISBT 128 international information standard for use in transfusion and transplantation.
  • ICD-9-CM Codes (Int'l Classification of Diseases, 9th Revision)
  • IEEE (The Institute of Electrical and Electronics Engineers) - is the world's largest technical professional society. The technical objectives of the IEEE focus on advancing the theory and practice of electrical, electronics and computer engineering and computer science. To realize these objectives, the IEEE sponsors technical conferences, symposia and local meetings worldwide: publishes nearly 25% of the world's technical papers in electrical, electronics and computer engineering; provides educational programs to keep its members' knowledge and expertise state-of-the-art.
  • ISO
  • LOINC (Logical Observation Identifiers Names and Codes) - data base provides a standard set of universal names and codes for identifying individual laboratory results (e.g. Hemoglobin, Serum Sodium concentration),clinical observations (e.g. Discharge Diagnosis, Diastolic blood pressure) and diagnostic study observations, (e.g. PR-interval, Cardiac echo left ventricular diameter, Chest x-ray impression).
  • NCCLS (Clinical and Laboratory Standards Institute) - is a globally recognized, voluntary consensus standards-developing organization that enhances the value of medical testing within the healthcare community through the development and dissemination of standards, guidelines, and best practices.
  • NCPDP (National Council for Prescription Drug Programs) - for exchanging data processing standards to the pharmacy services sector of the health care industry
  • OASIS (Organization for the Advancement of Structured Information Standards) - is a not-for-profit, international consortium that drives the development, convergence, and adoption of e-business standards.
  • SNOMED CT (Systematized Nomenclature of Medicine) - is a dynamic, scientifically validated clinical reference terminology that makes health care knowledge more usable and accessible. SNOMED CT provides a common language that enables a consistent way of capturing, sharing and aggregating health data across specialties and sites of care.
  • X12N - for exchanging insurance, eligibility, and managed care information