[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).
Posted in Computing, FHIR, Health Informatics, openehr, standards
Tagged e-health, fhir, Health Informatics, HL7, ISO, openEHR, standards
[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’.
Posted in FHIR, Health Informatics, openehr, standards
Tagged 13606, API, BRIDG, CCDA, CDA, CDISC, CIMI, fhir, openEHR
Tomaz Gornik from Marand, an innovation obsessive (and rightly so) provides a nice write-up of the evolution of solutions from:
- proprietary => best-of-breed integrated mega-suite => agile, multi-vendor
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.
(on their own)
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.
The European Commission is putting together a position on disruptive innovation in health. Their preliminary opinion paper references Clayton Christensen’s The Innovator’s Prescription a number of times, as I did aeons ago in this post on the Crisis in e-health Standards. It made me think about how to explain openEHR’s innovations.
Sometimes it is hard to see the wood for the trees on this question. As an insider, I’ll try to expose what have turned out to be the true innovations of openEHR, distinct from features that are just ‘its way of doing things’.
A while ago I blogged on why we replaced FrameMaker with Asciidoctor for the technical publishing function of openEHR.org. At around that time I posted on an Asciidoctor mailing list my wishlist for Asciidoctor. I reproduce that list here. As another poster mentioned, some of this is in a tool called AsciidocFx, but a fair bit isn’t as well, so to date, I have not switched to it.