HL7 International<\/a>\u00a0started in the 1980\u2019s in an attempt to standardise the exchange of key information within a hospital \u2013 patient registrations, laboratory tests and medications. The first \u2018official\u2019 standard was HL7 version 2 \u2013 which remains in use to this day! If you want to learn more about the early days of HL7 read\u00a0Rene Spronk\u2019s blog<\/a>.<\/p>\n\n\n\n There have been a number of updates since then, and this is a remarkable achievement especially as we don\u2019t expect HL7 version 2 to be going away any time soon.<\/p>\n\n\n\n HL7 organised itself into a number of committees (or workgroups) each of which has responsibility for a particular domain within healthcare. For example, \u2018Patient Administration\u2019 deals with the purely administrative aspects of healthcare such as patient encounters and scheduling, \u2018Orders and Observations\u2019 is \u2013 well \u2013 Orders and Observations, and \u2018Pharmacy\u2019 deals with medications. You can see a complete list of the committees\u00a0here<\/a>.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Since it started HL7 has expanded considerably with a number of new interoperability standards and has added other standards such as the\u00a0EHR functional model<\/a>\u00a0and decision support like the\u00a0Arden syntax<\/a>.<\/p>\n\n\n\n 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, \u2018re-using\u2019 part of a message for a different purpose, which meant that each implementation needed to be \u2018fine-tuned\u2019 before it could be used. And the consequence of this was it often wasn\u2019t possible to just pick up one implementation and use it at another site without some customisation.<\/p>\n\n\n\n Recognising this, HL7 started work on the next version \u2013 imaginatively called \u2018version 3\u2019. 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 \u2018top down\u2019 modelling effort by modelers rather than a \u2018bottom up\u2019 effort by implementers.<\/p>\n\n\n\n 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\u2019s possible to have a valid CDA document where all the clinical content is text.<\/p>\n\n\n\n One implementation of CDA in particular \u2013 Consolidated CDA or C-CDA has gained widespread adoption in the United States.<\/p>\n\n\n\n But even CDA wasn\u2019t 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.<\/p>\n\n\n\n Recognising this, in 2011 HL7 formed a taskforce call the \u2018fresh look\u2019 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: \u201cHow do other industries share data? Health is not that different really\u2026\u201d. Others agreed with him, and FHIR<\/strong> was born. The rest \u2013 as they say \u2013 is history.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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 \u2013 it\u2019s fair to say that these standards are in \u2018maintenance\u2019 mode. The main focus of the various internal committees is on FHIR development.<\/p>\n\n\n\n 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\u2019re also seeing new standards associated with FHIR, such as\u00a0SMART<\/strong>,\u00a0CDS-Hooks<\/strong>\u00a0and\u00a0FHIRCast<\/a> 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\u00a0t<\/a>he ecosystem<\/strong>\u00a0of co-operating systems actually comes into being.<\/p>\n\n\n\n HL7 is considering how best to meet these needs, whether expanding its role from the more \u2018traditional\u2019 role as a Standards Development Organisation to be more directly implementer supportive or to have an associated organisation like the FHIR Foundation<\/strong> take on that responsibility in conjunction with HL7.<\/p>\n\n\n\n However, it works out the next few years will be exciting indeed!<\/p>\n\n\n\n To learn more about FHIR and the digital ecosystem read my white paper – Enabling the ecosystem with FHIR<\/a>, how can healthcare information be made available where and when it is needed?<\/p>\n\n\n\nHL7 expands with new interoperability standards<\/strong> <\/h3>\n\n\n\n
How was FHIR\u00ae born?<\/strong><\/h3>\n\n\n\n
What does the future hold for HL7?<\/strong><\/h3>\n\n\n\n