A Lingua Franca for e-health takes shape with GraphiteHealth

Colleagues in e-health often say to me: why don’t you make openEHR easier to map to <insert popular interop standard> (used to be HL7v3, then HL7 CDA, now, HL7 FHIR… DSTU2/3/4/5?).

To which I usually reply: if you are implying there is any easy way to connect to today’s favourite message formalism, there’s not, there are only moderately difficult ways – which is why no-one has an automatic converter.

There are at least two reasons for this:

  • easy mappings are not available because the industry refuses to agree on the principle of a single source of clinical models, and the necessary underlying terminologies and ontologies; instead standards organisations publish standards frameworks and downstream profiling efforts (HL7 FHIR profilers Argonaut, DaVinci etc) create their own standards from them (‘profiling’ = creating a new standard) and we are back to non-interoperability;
  • the main incumbent e-health standards body (HL7) is still working on the basis of manually defined message (aka ‘resource’) content, to which all systems must map, in order to obey the standard. However, today, systems have their own models – and major paradigms e.g. patient-centric EHR – which are different and usually better than the lowest common denominator standard, so this forced mapping is just a cost. NB: other industries don’t use the manual message approach; they agree models instead, and systems just serialise their data in and out of them.

While these two conditions remain true in e-health, the only ‘easy’ thing you can do is obey today’s message standards, and limit your interoperability to about 5% of the content richness inside your systems.

There is a third major reason for lack of progress to keep in mind: HL7 FHIR is not a standard, it is a standards-building framework. The concrete standards are the result of profiling and creation of ‘Implementation Guides’ (IGs). The result of this has turned out to be ‘profile proliferation’ (someone at ONC even came up with the neologism ‘profiliferation’). The reason isn’t because ‘profiling doesn’t work’ (it’s technically not bad), it’s because there has been no sectoral effort to impose any control or governance on separately created profiles. Try searching in simplifier.net for any vital sign and see what you get.

(At this point I will insert my usual caveat that the above is not intended specifically as criticism of FHIR; on the contrary, the two points above are mathematically inevitable truths of our domain, which is dysfunctional.)

The only way out of this, as I have said many times (e.g. in this post entitled Why the platform will replace today’s interoperability standards in healthcare), is a model driven platform, where the ‘models’ are from a common, domain-developed library – in other words, a lingua franca for health.

These reasons are why GraphiteHealth was recently created in the US by major provider partners including Intermountain Healthcare and Kaiser Permanente. Funding: O(USD100m). Have a look at their white paper (navigate on the site, then supply your email address). Here’s a quote:

It is clear from the highlighted text that GraphiteHealth’s founders have very much the same view on the two key points above.

Here is a slide from one of their presentations.

That bit marked ‘CEM Model Library’ within the ‘Graphite Standard’ is Graphite’s archetypes. CEM standards for Clinical Element Models, created by Stan Huff and his team over decades at Intermountain Healthcare. Note that it’s upstream from the interop standards: the latter are treated as a generated translation of the clinical models.

Stan Huff has had this vision for at least 30 years, as we in openEHR have had for 20. I’ve no doubt that many others entertain the idea but have not known how to realise it.

The providers that put GraphiteHealth together appear to have finally gotten sick of the fact that 30 years of messages has made almost no material difference to the core interoperability problems in e-health. The size of the effort and calibre of the partners tells us that US e-health may be about to experience an earthquake.

About wolandscat

I work on semantic architectures for interoperability of information systems. Much of my time is spent studying biomedical knowledge using methods from philosophy, particularly ontology and epistemology.
This entry was posted in FHIR, Health Informatics, openehr, standards and tagged , , , . Bookmark the permalink.

5 Responses to A Lingua Franca for e-health takes shape with GraphiteHealth

  1. Mark Kramer says:

    Steve Posnack of ONC should be credited for coining “profiliferation”. I just repeat it as often as possible, because I like clever neologisms.

  2. wolandscat says:

    Good to know – I saw it in your doc containing a statistical study on it.

  3. Have started following this space recently but doesn’t this sound more like this xkcd situation? would love to know more.. https://xkcd.com/927/

    • wolandscat says:

      Good question, but not really. There are levels of standards. Most ‘standards’ compete in the same functional / information space, e.g. HIT system interop message / data specifications. But a level upstream from that is domain models, which act as an ontology of information. This is a universal project, not a competitive one. The downstream standards of tomorrow will – we can hope – be derived from these models. Then the semantics of the domain will finally appear in application software in the way that healthcare professionals want.

  4. MD says:

    Interesting and well thoughtful article. It reminds me of a project/platform I drove from scratch to several releases in early 2002 for Utah department of health. (https://charm.health.utah.gov/pdf/UtahSuccessStory-Using%20HIE%20to%20Improve%20Care%20Coordination%20for%20Newborn%20Hearing%20Screening.pdf)

    The platform offered an inter-operating and real-time on-demand mapping, and sharing across health information systems based on following core concepts.

    I think the core concepts of a platform in todays’ lingo essentially boils down to a canonical model, Data mesh and market place of add-ons/capabilities built on top.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s