It's like reading through a framework devised by lawyers and policy makers. I cant wrap my head around healthcare tech to save my life and ive been working the field for 15 years. It's a jumbled mess.
HL7 is what happens when a regulator designs a tech framework.
https://www.hl7.org/fhir/resourcelist.html
Documents both the REST API and JSON and XML formats for every type of resource, with lots of examples, and sufficient detail for anyone to create a compliant implementation. Documentation for all of the datatypes like dates and times, terminologies, identifiers, references, numeric values, and how to serialize and parse them. Cross links everywhere.
It's legitimately one of the best documented and well thought out APIs I have worked with. I think they took all the mistakes made and legacy baggage of the old HL7 specs to heart, and did a great job of replacing them with something much better with very high quality documentation.
There's also so much extensibility that someone implementing it could just throw away all of the default fields in a patient's record and create their own, and we're right back to a mess of records that are useless across systems without having custom handlers.
The health IT domain is simply so large and complex that including every use case in a single comprehensive standard would be totally impractical.
Most specification pages have more shoulds than shalls.
Foundational types are a huge mess. For instance there are countless types of references that look very similar but work differently: absolute references, relative references, contained references and references that are replaced as part of a transaction all use the same field. Literal references suddenly lack the type that is referenced which can be not clear from the context. Then there are references that are just free text. Nothing you would expect to be mandatory actually is: code and system are both 0..1 in Coding for instance. A lot of things are not specified how they work at all but just have examples, for instance slicing or how the serialization actually works. Adhering to profiles from someone else is a huge pain in the ass, xml schemas are easier to understand and work with, you gain nothing from using FHIR. If a FHIR rest server does not understand your conditional requests it might just execute them when the condition would evaluate to false. Types that somehow look similar are shoehorned into one type, like transaction requests and search results. FHIR sits in a sweet spot of modeling Health data: not detailed enough to be useful interoperable on its own, detailed enough to not be compatible with other models without a pain in the ass. It’s like the semantic web again where people tried modeling the world.
FHIR is a bit like JavaScript easy to get something to work at the start but hard to actually get it right.
I have personally participated in quite a bit of HL7 standards development and I can guarantee you that regulators have only minor influence over the process. HL7 work groups have multiple types of participants including providers, payers, vendors, and regulators.
The older HL7 V2 and V3 standards can take a while to learn. FHIR (which is essentially HL7 V4) is a bit easier to understand. But the health IT domain is inherently complex and can never be made simple.
Patient data is not special other than its security requirements. There does not need to be a layer of standards in this space dedicated to handling/transfer of clinical/hospital data between organizations. Private industry & hospitals can solve this without the need for a standards board or HL7 standards. We have enough standards for handling/transfer of sensitive data.
Engineers have already solved that with interoperable data systems dedicated to managing and sorting through large sets of data. Healthcare data is simply data. There are plenty of other types of highly sensitive data that don't need an entire organization dictating bloated standards implementations that are already highly fragmented themselves.
HL7 is an unnecessary abstraction.
HL7v2's problem is that it is 30 years old and probably should have been replaced by something earlier. Then again, so should most X12, mainframes, COBOL, etc. etc. FHIR is good, but the challenge is that the incentives for interoperability are much lower than those for intra-operability.
The annoying part is the QACH CORE Connectivity Rule has finally made interacting with health care partners for X12 transactions suck less by providing standard REST and SOAP interfaces for transaction exchange, but we couldn’t be bothered to implement a less shitty transaction format.
HL7 is a work of art in comparison.
Which they did merge and overal they do seem open to improvements of their systems and standards.