In the time since I left Ocean Informatics (the company I started with Dr Sam Heard and others in the late 1990s), I have been working with Intermountain Healthcare as well as various other openEHR vendor companies, notably DIPS (Norway) and Marand (central/south-east Europe). With both groups I am working on what could be described as the next layer of the open EHR: process.
Recent discussions on the FHIR chat forum with various HL7 people around the topic of how openEHR and other architectural frameworks (e.g. VA FHIM, CDISC) could work with FHIR led to a realisation that some people in HL7 at least don’t understand some of the technical basics of openEHR. This might simply because they have not been involved enough to learn them, but now that we appear to be in the era of FHIR, in which no e-health solution can be without FHIR (according to the now pervasive FHIR hype), I would argue that HL7 now needs to understand some of the basics of the other major architectural frameworks and model-based platforms in e-health – all of which precede FHIR.
[a monk’s retreat near Thalori village]
I just spent a few days in Crete at an experts workshop of the European e-Standards project that aims to bridge well-known gaps in e-health standards and SDOs. I’ll comment on that effort in another post, for now I will just say thanks to Catherine Chronaki for the invitation, wonderful choice of venue and excellent workshop.
As is usual in these situations, being present in a beautiful place (Thalori village, southern Crete) with many interesting people (some old friends, others new acquaintances) and especially that vital ingredient: a world-class traditional band of musicians who played the paint off the walls of the Taverna until 3:30 am Saturday morning led to some new thoughts on standards (as well as a vastly improved appreciation of Cretan music).
[image: (c) 2014 Imogen Brand Rakers Photography]
I have argued for an open platform approach in e-Health for some years now, as have others (Ewan Davis’s Nobody Can Own the Platform post is a nice summary of the issue). It’s clear that the idea is starting to resonate in some places like the NHS, bits of ONC thinking, the VA, and in some other countries. But how can governments and other fund-holders go about realising an e-Health platform?
FHIR is the HL7’s modern approach to connecting components in the health computing space. Unlike the HL7v2 message approach, FHIR is oriented to enabling applications connect to back-ends. It has been running for a few years now, and is doing good work on how to use REST, terminology, and generally make the application programmers experience better.
It is also over-hyped. That’s not mainly the fault, as far as I can tell, of the core developers but more of an industry exhausted by attempts to make HL7v3 work, but still desperate for solutions. Some of the hype would have you believe that FHIR solves all health informatics problems; common sense says this is not true. A lesser version of the hype would have you believe that FHIR solves all interoperability problems in health. A superficial inspection shows this is also not true. Both versions of the hype are leading some vendors, providers and even some government programmes astray.
My point here is not to criticise FHIR, it’s to encourage those trying to solve the problems of e-health to take a step back, have a good look at the list of problems we know about, and then understand which of those FHIR is going to help with.
This post takes a look at what FHIR’s scope is today, and makes a proposal to significantly extend its capability, in a way that could even help to end the ‘health informatics wars’.
Tomaz Gornik from Marand, an innovation obsessive (and rightly so) provides a nice write-up of the evolution of solutions from:
The last is the new world of innovative, agile, mostly cloud-based and multi-vendor solutions. This is what Gartner calls “Postmodern”. Have a read.
Every so often I remember how we were taught to build information systems and software. One of the steps is called ‘requirements capture’. The IT people are supposed to go and interrogate domain experts, in a step called ‘use case modelling’, obtaining those diamonds of information that will allow them to build the system those experts want.
There’s only one problem with that. In all real domains, the IT people and domain experts have no clue what each 0ther is saying. And yet the IT people still go and build a system. Any system. And that’s why most information systems are a) semantically broken and b) can’t keep up to date with new requirements.
wolandscat