US
CA
GB
NZ
We all use HL7® standards, especially those of us in the Health IT industry, but have you ever wondered about the organisation behind them?
HL7 International started in the 1980’s in an attempt to standardise the exchange of key information within a hospital – patient registrations, laboratory tests and medications. The first ‘official’ standard was HL7 version 2 – which remains in use to this day! If you want to learn more about the early days of HL7 read Rene Spronk’s blog.
There have been a number of updates since then, and this is a remarkable achievement especially as we don’t expect HL7 version 2 to be going away any time soon.
HL7 organised itself into a number of committees (or workgroups) each of which has responsibility for a particular domain within healthcare. For example, ‘Patient Administration’ deals with the purely administrative aspects of healthcare such as patient encounters and scheduling, ‘Orders and Observations’ is – well – Orders and Observations, and ‘Pharmacy’ deals with medications. You can see a complete list of the committees here.
Each committee meets weekly or fortnightly via teleconference to monitor and develop the standards and there are also at least 3 face to face meetings per year which are called Working Group Meetings (WGM). 2 of these are in the US, and 1 per year is outside the US. The locations can vary from Canada, Europe, South America and Australia to name a few locations as HL7 is international in scope.
HL7 expands with new interoperability standards
Since it started HL7 has expanded considerably with a number of new interoperability standards and has added other standards such as the EHR functional model and decision support like the Arden syntax.
Although highly successful, the biggest issue with the HL7 version 2 standard was because it was so flexible, quite often individual implementations would use it in slightly different ways to meet their own needs. For example, ‘re-using’ part of a message for a different purpose, which meant that each implementation needed to be ‘fine-tuned’ before it could be used. And the consequence of this was it often wasn’t possible to just pick up one implementation and use it at another site without some customisation.
Recognising this, HL7 started work on the next version – imaginatively called ‘version 3’. The idea was, rather than each implementation deciding how to use the specification, HL7 would define a common model called the Reference Implementation Model (RIM) from which all other artifacts would be derived through a series of intermediate models. In this way, the artifacts should all be consistent and re-useable across implementations. In effect, version 3 was a ‘top down’ modelling effort by modelers rather than a ‘bottom up’ effort by implementers.
The development effort took 10 years, with the first release being in 2005. However, while version 3 was embraced in a number of countries it never really gained wide spread adoption. This was largely because it was complex to implement and required specialised knowledge to do so. Having said that, one variant of version 3 that defined clinical documents – Consolidated Document Architecture (CDA) has gained wide spread acceptance, I suspect substantially because it supported human readability from the beginning. It’s possible to have a valid CDA document where all the clinical content is text.
One implementation of CDA in particular – Consolidated CDA or C-CDA has gained widespread adoption in the United States.
But even CDA wasn’t really meeting the emerging needs to share clinical information in a computable way. Extracting data from a CDA document to populate clinical databases is not an easy task, and there is still widespread variability in its use. In addition, CDA documents tend to be bulky and complex, and are hardly suitable for use by the emerging mobile market.
How was FHIR® born?
Recognising this, in 2011 HL7 formed a taskforce call the ‘fresh look’ which asked the question: If we were creating a healthcare interoperability standard today, what would it look like? This task force was headed up by Grahame Grieve who asked a simple question: “How do other industries share data? Health is not that different really…”. Others agreed with him, and FHIR was born. The rest – as they say – is history.
At the same time that FHIR was being initially developed, HL7 made a very brave move. Previous versions of HL7 Standards (v2, v3 and CDA) were all licensed by HL7. To use them required paying a license fee to HL7, which is how it funded the development efforts. However, the decision was made to make FHIR and the other standards open source. Anyone could use it without paying a fee, though the ownership remained with HL7 to ensure that it continued to be developed in an open way. While this has no doubt contributed to the wide spread adoption of FHIR, it has come at a (literal) cost to HL7, as a large part of its income had come from license fees, and alternative revenue sources were needed.
One of the areas where this has occurred is in training, HL7 has greatly increased the range and frequency of training that is offered whether in person at Working Group Meetings or through the increasingly on-line webinars. This has allowed HL7 to not only generate income needed to run the organisation (and do note that HL7 is a not-for-profit organisation) but has also allowed it to ensure the quality of the training, as well as provide a channel of feedback from the implementer community.
What does the future hold for HL7?
There is no doubt that FHIR has had a huge impact on the organisation. Despite its youth, FHIR is the pre-eminent standard that is receiving most of the attention of HL7 members. While version 2 and CDA remain important – it’s fair to say that these standards are in ‘maintenance’ mode. The main focus of the various internal committees is on FHIR development.
FHIR is bringing in large numbers of people from new areas. People who are not necessarily interested in developing the standard, more in using it for implementations. We’re also seeing new standards associated with FHIR, such as SMART, CDS-Hooks and FHIRCast which are created directly by the implementer community (but under the auspices of HL7). This is in response to real-world needs and a desire to ensure that the ecosystem of co-operating systems actually comes into being.
HL7 is considering how best to meet these needs, whether expanding its role from the more ‘traditional’ role as a Standards Development Organisation to be more directly implementer supportive or to have an associated organisation like the FHIR Foundation take on that responsibility in conjunction with HL7.
However, it works out the next few years will be exciting indeed!
To learn more about FHIR and the digital ecosystem read my white paper – Enabling the ecosystem with FHIR, how can healthcare information be made available where and when it is needed?
