Reflections on the HL7 membership model

HL7 country organizations (affiliates) have a life cycle in terms of focus and activities. This life cycle isn't supported that well by the HL7 organization and it's membership structure.

Recently I had some discussions with a few active participants in IHE about the changes that HL7 has made in 2011 to the way it deals with its Intellectual property (IP) rights. Suddenly it seems as if there is a new requirement that one has to become a member of HL7 to use the HL7 standards. From a legal standpoint, nothing has really changed (one has had this obligation all along), it's just that HL7 is now highlighting and enforcing the membership requirement to a higher degree than it has ever done before. Perception is everything, so I'm not sure whether or not it's a good idea to start rigorously enforcing it. In the short run this may lead to additional revenues (especially in the US, where it is relatively easy to enforce ones IP rights), in the long run it may be harmful.

This discussion, and a longwinded negotiation process (during most of 2011) between HL7 International and its country level affiliate organizations reminded me of a discussion I once had with Charlie McCay (who was the chair of HL7 UK at the time) about the 'HL7 affiliate life cycle'.

The HL7 Affiliate Lifecycle

The HL7 country organizations (formally known as HL7 Affiliates) appear to go through a lifecycle, from being founded to effectively being superfluous. The life cycle consists of at least 5 phases, each of which is described below:

I. Raising awareness

In the initial phase the activities are those who as vendors, or as implementers have come across HL7 standards. This includes any pre-affiliate HL7-related activities by those that are considering setting up an Affiliate, and the creation of an affiliate.

During this phase the activities of the affiliate are mostly related to 'increasing awareness' within a country that the use of international interoperability standards, or even interoperability in general, has an added value. The founders of the affiliate are hopefully well connected within their country.

The localized specification of one of the early adopters (mostly a vendor) may be the defacto local standard for the time being. Examples: HL7 Philippines and Puerto Rico (as new affiliates), Hungary and Saudi Arabia (as pre-affiliates) are at phase I. The International Mentoring Committee (a group within HL7 International) was specifically created to support affiliates in this phase.

Exception: T. terminated

This exceptional status may occur if (after phase I) the affiliate fails to gain traction and progress to phase II. At some later phase a new set of volunteers may make a renewed attempt to create an affiliate. Examples: Ireland, Poland, Malaysia, Bulgaria.

Exception: B. Blocking

The affiliate may have been created to block the adoption of HL7. The affiliate is kept alive, and is nominally active, but the sole purpose of having an affiliate is to block others from being interested in creating one. From the outside it appears as if the affiliate never progresses beyond phase I. Example: some of the Scandinavian countries, where the national focus is historically on standards other than HL7.

II. Creating a consensus based localization

During this phase a sizable number of volunteers are working on the creation of a consensus-based localized version of the HL7 standard. The affiliate mostly consists of multiple working groups that each focus on a subset of the specifications. The affiliate is growing in terms of membership. This phase typically ends once there is a reasonably stable localized specification that covers the more common use cases. Example: New Zealand.

III. Paid development

The development of specifications is largely done by paid resources (in the context of regional/national projects) instead of by volunteers (in the context of the affiliate). The resulting specifications may be brought forward to the affiliate for review and formal approval.

The number of volunteers actively involved in the affiliate activities typically dwindles in this phase:

the paid resources have the ability to spend a far larger amount of time on the creation of specifications
why would one create specifications as a volunteer if someone else is paid to create a specification anyway?

As a consequence of the dwindling number of volunteers the number of working groups within the affiliate decreases as well. The meetings of the affiliate are mainly used to exchange experiences, to report on the status of implementation of the regional/national specifications. Example: HL7 Germany is at phase III, HL7 Australia at phases II/III.

IV. Official Endorsement

A national organization (e.g. healthcare ministry, a semi-governmental body, or other national standards setting body) mandates (carrot and/or stick) the use of HL7 standards, using a particular localized version. This organization typically also creates local implementation guides. HL7 International refers to these organizations as 'profiler/enforcers'.

This has a major effect on the affiliate: volunteer numbers decrease; everybody effectively leans back, waiting for the national organization to create the specifications. The meetings of the affiliate are mainly used to exchange experiences, to report on the status of implementation of the national specifications. Examples: HL7 US is at phases III/IV, HL7 Netherlands and UK are at phase IV.

V. Standards collaborative

Once the national organization and the affiliate realize that the support of healthcare workflows requires the combined use of multiple standards (e.g. HL7, DICOM, IHE, and terminologies) they come to the realization that the standards bodies (and/or their local representation, e.g. HL7 affiliates) themselves need to be tightly integrated.

This effectively dissolves the HL7 affiliate, its activities are tightly integrated/coordinated with other standards bodies. Example: HL7 Canada is at phase V.

Al interesting question is: How does HL7 support the progression of affiliates through the life cycle? Does it support the affiliates at each phase in their life cycle? The current affiliate agreement, having been essentially created in the early days of HL7, mainly focuses on phases I and II. There has been some thinking about changing the IP structure for 'profiler/enforcers' (phase IV and V) but that has never come to fruition. At phases IV and V it makes sense to start thinking about a 'country membership model', whereby at the national level one purchases the right to use HL7's IP - allowing for potential sublicensing to organizations if countries wish to use such a licensing model (this is akin to the model used by IHTSDO). At phases I and II any licensing model should be geared towards increasing adoption, potentially based on free use of HL7's IP for a certain period of time.

I could pose an more philosophical and fundamental question: When will HL7 itself be at phase V ? (according to the spoof IHMSDO website it'll be in 2012). That's unlikely to actually happen any time soon .. but one never knows. The mission of HL7 (curiously enough) should IMHO be to make itself superfluous - which means we have working healthcare interoperability and standards alignment.

There are some members of the HL7 board that are openly advocating that the principle of having 'national affiliates' should be abandoned. The deployment of HL7's standards is based on localization - which means one has to have some national body that defines what the localized standard should be. At phases IV and V one could potentially come up with an alternative for the affiliate structure. For countries at phase I and II, depending on volunteer effort, I don't see a real alternative.

All the best for 2012!

-Rene

PermaLink to this page: http://www.ringholm.com/column/HL7_membership_model.htm

Index of columns:

HL7 Version 3 Tooling (Nov 16, 2022)
Bye bye IHE XDS and CDA. (Sep 01, 2021)
Combining the best of IHE XDS with HL7 FHIR (Jun 27, 2019)
FHIR DevDays and the year in review (Dec 27, 2018)
Creation and Curation of FHIR Profiles - process and governance (Dec 14, 2017)
Impact of the GDPR on the use of interoperability standards (Jun 27, 2017)
Next XDS Release (Oct 27, 2016)
Five years of FHIR (Aug 11, 2016)
Update from the trenches on CDA R2.1/R3 and HL7v2. (Oct 15, 2015)
Most often implemented IHE Profiles (Jun 08, 2015)
Mapping HL7v2 messages to FHIR. (Apr 13, 2015)
Recent and Future developments of the DICOM standard (Mar 06, 2014)
Documenting the history of HL7 (Sep 03, 2013)
Interoperability Standards - the no-sales pitch (Jul 09, 2013)
CDA Implementation Guides - (not) invented here (Apr 17, 2013)
Usage of IHE Profiles (Feb 25, 2013)
10 year anniversary - Dutch Ringholm HL7 v2 training courses. (Feb 19, 2013)
HL7 Connectathons (Sep 09, 2012)
Frequency of use of HL7 message types (Jul 24, 2012)
Reflections on the HL7 membership model - the affiliate life cycle (Dec 28, 2011)
RFH (Resources for Health): HL7 version 3 taken to the next step (Aug 18, 2011)
Timezone Hotel (Mar 29, 2011)
The changing role of HL7 country organizations (Jul 16, 2010)
How to lower the hurdle for HL7 v3 implementers (Jan 21, 2010)
The HL7 roadmap for CDA R3 and the CCD (Jan 17, 2009)
HL7 based Tree inventory system (Jan 30, 2007)
Workflow Bribery (Sep 15, 2006)

About Ringholm bv

Ringholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.