Health Standards Community Membership Archetypes: Who uses HL7?

One of the largest HL7 policy shifts I’ve seen in 20 years within the HL7 community is the decision to release much of the HL7 intellectual property (IP) at no cost.

HL7 logoDuring the past year I’ve been a member of the HL7 Board Membership Taskforce studying how to rework membership benefits and structure given the shift in IP policy. Part of that work had me deeply thinking about the types of organizations and individuals who are members of the broad HL7 community.

I’d like your feedback and refinement on a proposed list of HL7 member archetypes. Once we know who is a member of the community, we’ll have a clearer path on how to continue funding the standards development process. Keith Boone wrote a great overview of the healthcare funding challenge back in late 2010.

Here are my five classes of health standards community members:

End Users

A user of a software application that directly produces or consumes standardized data. An End User knows that data flows between applications but does not understand nor care about the technical details. For example, a primary care physician knows the patient’s lab results are sent from the reference lab to the EMR yet he or she is uninterested in how that happens.


An entity that directly (and generally greatly) benefits from the standards existence, yet does not necessarily participate in the creation, curation, or maintenance of the standards or the technical infrastructure. Examples include insurance companies, health plans, governmental bodies/departments, pharmaceutical developers, clinical researchers, etc.


A software vendor (or in-house development team) that adds or maintains the import/export functionality of a clinical application that is generally used by End Users. Implementers choose the standards (HL7, X12, DICOM, etc.) that match the workflow needed by their customers, who are typically Integrators. Generally, an Implementer makes choices about the depth of implementation and how (or if) an application will support a standard and to what depth. The choices made by an Implementer massively limits or expands the deployment options for Integrators.


A hospital, lab, outpatient clinic, etc., (collectively “providers”) who buy, configure, and maintain interfaces from software vendors (Implementers). The interfaces purchased are scoped by agreement between the Integrators and the Implementers. Depth of knowledge by Integrators varies dramatically – some have as much (or more) knowledge than Implementers, while others effectively ask their vendor (Implementer) to provide all services and knowledge on required standards.


An active participant in the creation of the standard itself. They are a subject-matter expert on a clinical domain; a healthcare informatics specialist who develops/delivers infrastructure for care within a political realm, or a specialized technical resource dedicated to creating the standard. Generally, a member in this category has a “day job” as a Beneficiary, Implementer or an Integrator. In the context of HL7, a Creator is an active member of a committee, attends HL7 Working Group Meetings, participates in conference calls, and votes in relevant standards ballot pools.

Given this mix of community members, there are many challenges as it relates to funding the standards development process:

1. Historically neither End Users nor Beneficiaries are willing to directly fund the standards development organization. Clearly, a small percentage of these community members are also Creators, though most are not. The decision on the part of an End User to not directly fund the standards body is pretty reasonable: they consider the standard’s existence, configuration, and maintenance part of the cost of the application itself.

This attitude is much like an automobile driver or bicycle rider not directly paying for the development of the ANSI standard for the reflectivity of paint used to write the letters “S-T-O-P” on a stop sign. The decision by some Beneficiaries to not fund the standards organization is more problematic to explain. Again, clearly some Beneficiaries directly fund the process or pay individual Creators (e.g., technical staff from NIST, NEHTA, Infoway, etc.) but they are not a huge source of standards funding.

2. Implementers are the primary consumers of the standards. While the Integrators certainly configure and pay license fees for interfaces, the key choices about what part of a standard will be implemented are made by the vendors supplying the interfaces. For example, if an application supports a single external identifier per patient or has a restriction that only a single visit can be open for a given patient at a time, it does not matter what the HL7 standard says. The limitation will be “baked into” the interface because it is “baked into” the application.

3. Integrators have a dramatic range in skill sets and desires. Some work for small critical access hospitals where they almost know how to spell H-L-7 and others are members of a team of 50 who maintain a health system’s dozen integration engines. The mix of time demands across a typical Integrator’s day is huge; often integration is only a part of what they do each day.

4. The primary need of the Creators in the community is “low friction communication and processes.” Generally, Implementers and Integrators want free-and-correct content and answers to questions as opposed to “expensive and wrong” or “free and fuzzy.”

Ultimately, someone in the healthcare food chain needs to pay for the Creators to collaborate and create the standard. Why? Because standards provide huge benefits to a wide mix of organizations; the cost savings and opportunities enabled via standardized data exchange are extensive. The key is that the benefits of HL7 are often enjoyed by parts of the food chain that do not directly fund its development. Of course, that’s a different topic for a different future posting. :-)

The following two tabs change content below.
Dave Shaver is the CTO for Corepoint Health. Dave has more than 20 years experience in training, consulting, and software development. He’s deeply involved in the HL7 standards community, including co-chair of HL7 Infrastructure and Messaging committee and co-chair of the HL7 FHIR Governance Board.

, , ,