How HL7 Health Information Technology Standards Work

Vitals, test results, prescriptions–there is information everywhere that is critical to providing quality healthcare. Between switching providers, visiting specialists, and receiving emergency care, that information becomes fragmented in several places but must be stitched together to provide an accurate picture of a patient’s condition.

Building interoperable electronic health record (EHR) systems to be able to share this information is an ongoing effort, but the development of new standards is vastly improving the outlook for full interoperability.

What exactly are health information technology standards? Essentially, standards represent the community’s consensus regarding how health data and services should be represented, implemented and behave. They govern the semantics, structure, transmission, and processes for health information; they are created and managed by a variety of organizations, principally Health Level 7 (HL7), an ANSI-accredited standards development organization originally created to serve the US market but now claiming international membership and reach.

Working Groups
An HL7 standard typically begins life as a project sponsored by one or more Working Groups. A working Group at HL7 is a group of members and volunteers that have a common interest in a clinical domain or area, for example, the Service Oriented Architecture (SOA) Working Group. Participants that share an interest in solving a particular problem will propose a Project Scope Statement describing the issue, the proposed approach for creating a solution, how their work relates to other HL7 standards, and what the outcome of their work is to be. Work product might be a position statement, an implementation guide, a data model, or any number of other artifacts.

Service Functional Models
In many cases, the result of a Working Group project is a Service Functional Model (SFM) that describes the desired behavior that a service or technology is to perform. An SFM is essentially a set of functional requirements that should be supported by a vendor implementation. Under an agreement with the Object Management Group (OMG), HL7 focuses on functional requirements, which are then passed to OMG for developing a corresponding technical implementation specification. A truly standards-based health informatics infrastructure confirms to both.

Balloting
Before an SFM will be accepted by the OMG, the HL7 community must approve it. In a process called “balloting,” the work produced by an HL7 work group is presented to the community for informative purposes, for collecting comment, or for acceptance voting to become normative.

A normative standard becomes the preferred model in the community and can be submitted for consideration as an American National Standard recognized by ANSI.

Informative ballots can explain or support HL7 protocol specifications, or provide detailed information on interpretation or implementation of a protocol specification; they require 60% of votes to be affirmative to pass. If passed, informative ballots may be submitted for balloting as a Draft Standard for Trial Use.

Sometimes a work group may wish to put forward proposed content or requirements for comment only. Comment-only ballots are published for 30 days and community members are encouraged to provide feedback but no revision is required.

From DSTU to Normative
The first step in presenting a standard for consideration as normative is balloting as a Draft Standard to ensure interoperability between at least two parties. In this process the content is made available for comment and voting for 30 days. If it receives 60% affirmative votes, the Draft Standard may be submitted as a Draft Standard for Trial Use (DSTU). Once a standard is balloted as DSTU, it goes out to the community for preliminary use and comment (the guideline is a year but most take two).

Once substantive comments on DSTU balloting are addressed, the standard may be submitted to a normative ballot. This ballot must remain open for at least 30 days and requires a 75% affirmative response rate from a representative voting sample with the majority participating for approval. Comments must be reconciled within 10 months of the close of voting. This includes comments from the public collected via ANSI Standards Action publication.

When a normative ballot is approved, the standard may be submitted to ANSI as a candidate American National Standard.

Service Specifications
Standards can be championed and developed as part of the Healthcare Services Specification Project (HSSP) for use as a service specification.

HSSP is a partnership between HL7 and the Object Management Group (OMG), an international non-profit technology standards organization. The goal of HSSP is to establish a collaborative framework for standardizing healthcare interfaces within service-oriented architecture.

Service specifications build on standalone standards by demonstrating interoperability within a technology-neutral, platform-independent model and through preliminary vendor implementation and at least one platform-specific implementation.

When HL7’s Services-Aware Interoperability Framework identifies service functional models eligible for service specification standards, if there is a dedicated champion and at least three organizations willing to participate in the OMG collaborative process, they are developed by committee to achieve independence from any single technology or vendor.

The OMG process for these specifications involves drafting an RFP calling for submission of proposed standards and accompanying implementation specifications, to which the original champion and others will respond. Those parties will then work together on a common revised submission. Standards put forth through HSSP go through the DSTU process but are voted on by OMG member organizations rather than the community at large.

Conclusion
The balloting process may seem complicated, but this comprehensive approach to electronic health information standards put forth by HL7 and OMG ensures that technology and business needs are addressed by a representative group of stakeholders. If you have a product that might make a good standard, knowing the key milestones can help you get started.