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.