This article is a general introduction to HL7 data format versions - readers are assumed to be developers and other technically-oriented people, possibly with a background in web programming, who need a gentle overview, a refresher or a guide to keep at hand.
The article covers what versions to learn, in what order and why to do it at all. All the code examples are given in Python.
Assuming that you already know what a REST API endpoint and JSON are, the plan for learning HL7 is this:
Quick results can be achieved in a few days but do allow for at least several weeks before you can confidently use HL7 in your work. This guide will serve you best during the initial orientation period, before you really know what to learn in depth.
If you already have experience in integrating systems from other industries you will note that in health care a new proper noun to use, the crucial keyword, is interoperability.
This is a term that does not exist at all in other industries with high software integration needs but it does exist in industries built around hardware, appliances and other physical objects, thus revealing the medical roots of the terminology.
Simply keep in mind that what elsewhere is called integrations, automation or orchestration, in health care will typically involve the term interoperability although the noun integrations will also we encountered. The goal remains the same, to efficiently and effectively connect computer systems.
HL7 is a set of protocols, data formats and models that help people build and connect health care-related systems.
It is convenient to use HL7 to integrate such systems because some conventions are always needed anyway in work of this sort so it does make sense to use a format that has been vetted by thousands of companies and organizations already. At the end of the day, you will simply need to settle on a format of some sort, no matter how big your project or initiative is, so why reinvent the wheel? Would you rather not focus on what new value your work brings?
As an example, let's say you are building a vaccination platform that connects two ministries - that of health and agriculture. As an architect, engineer, product manager, developer or programmer, you will need to, in one way or another, express in your software concepts such as patients, cases or lab samples.
In theory, even if you are new to the field, you could go about it by inventing your own data model - after all, most of this will be fairly self-explanatory initially. If you ever designed or implemented a typical web system with online clients and their usual workflows, things will look easy. But as you keep adding more and more capabilities that are truly to do with medicine and health you will, and this is natural, keep stumbling more and more because you will be veering off what you already know from previous works. This is inevitable so why let it happen in the first place?
And what if a neighboring government would like to share information with you, given that diseases rarely honor borders that exist on maps only? Why should they need to learn a format that only you know, why should they not expect to use something that is already an international standard? What if this kind of a delay means suffering because of the lack of interoperability? Remember that this is health care so consequences can be disastrous.
Note that the example above was constructed in a context that everybody could relate to (Covid-19 pandemic) but the scale does not really matter - the same principle applies everywhere, no matter if your integrations are big or small.
Also note that complete interoperability is a win-win situation for every party, vendors and manufacturers including.
The above is, fundamentally, a description of the ideal situation - the reality, though, and one of the reasons why Zato exists in the first place, is that health data is kept in a myriad of places, in all kinds of silos of mainframes, databases, file servers, clouds, applications or mobile devices, not to mention the actual medical appliances, and few people are really going to change what works reliably solely because of noble strategic goals. This is why, while the direction towards achieving the interoperability is clear, it is also clear that getting there will take years and years.
Observe too that this is one of the specific cases when institutional intervention from governments is justified because otherwise it would be difficult to overcome the reluctance of vendors towards the interoperability as it is not something that brings quick dividends from quarterly or yearly sales plans, instead requiring a truly deep perspective that pays off only in a very long term. This is why