There is Always Another Way

There's more than one way to skin a cat, or route to a solution. When presented with a problem, a good software engineer can usually think of at least two ways to solve a problem.  And most often, the next thing we do is pick one and invest time and effort into it.  The choice selected may not be the best one, it may be a compromise based on competing factors.

So then, let me unpack this tweet (shown below from Thomas Beale, a well-regarded expert in OpenEHR):

"What we should have: a universal health content model library. What the message people always do: impose their own content 'standard' rather than cooperate with mature approaches to modelling. What we get: dissonance."

There's a little bit of sour grapes in this because of the long-standing competition between HL7 (the message people) and OpenEHR.  These are competing standards in the Health IT spectrum that take different approaches, for which there are pros and cons for each.  HL7 focuses more on exchange and OpenEHR more on data modeling.  Both have their target markets for adoption which overlap to some degree.  HL7 has a significant (order of magnitude) advantage in general adoption, OpenEHR has a significant advantage in existing clinical models, their physician engagement model and clinical validation of content (models which HL7 CIMI workgroup and the AMA (separately) are also developing).

Thomas goes on further in blog post he links to the above statement to say (emphasis mine):

My view is that the only scalable way to create the semantic specifications is for them to be artefacts outside of both vendor products and outside of specific communications formats.

∶

∶

Where healthcare computing needs to go is a complete separation of models of semantics of healthcare and the technologies used to implement solutions at any given time.

You can see where I'm going here when I highlight "the only scalable way" and "complete separation".  As soon as one starts talking about the "only way", the discussion has been elevated from one at layer 7 of the protocol stack, to layer 8 or 9.  Absolutist statements such as these don't allow for compromise.  When the rubber hits the road, compromises are needed, because to a working solution is by definition one that has shipped, and perfection is the enemy of the good.  FHIR R4 has shipped, FHIR is already available in Health IT products covering better than 87% of the US hospital market and 69% of the ambulatory market (the numbers are surely better given the age of my reference and the data it used [it's at least 6 months out of date]).

I generally agree with Tom's statement about separation of model semantics and technologies, but I don't come to the same conclusion about completing the separation between models and technologies.  FHIR is a new technology that is meant to make Health IT software deliverable, and it seems to be delivering on that promise. R4 shipped in late December (a couple of days after Christmas).  IHE just completed updating three profiles to R4 and published those specifications for public comment last week.  HAPI on FHIR is on track to deliver an implementation of R4 in a few more weeks.  The US Core for R4 is out for ballot. That's delivery.

Back to the original tweet, FHIR specifies a content standard for resources, it takes some aspects of the semantics into the implementation of the technology to make life easier for developers.  That's OK, I'm willing to live with that compromise in order to ship.

   Keith

P.S. If I wanted to be snarky, I'd point out that there are probably better words than "mature" to describe well-established or proven methods in technology, preferably ones that don't imply lack of change.