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.
Today saw the release of a new openEHR whitepaper, which provides a nice summary of open platforms thinking for e-health. From the executive summary:
The key elements of openEHR’s strategic value to future development are:
- Technically it is a platform approach, rather than a ‘set of standards’ or monolithic specification or product;
- It offers the most comprehensive semantic framework available in e-health, combining formal clinical modelling, terminology, and a services infrastructure;
- It deals directly with the very difficult challenges of e-health, including semantic scalability – handling complex and constantly changing information and clinical workflows, forever;
- It supports the establishment of a platform-based economic ecosystem, in which the customer retains control of purchasing at a component level, using platform specifications (information models, APIs, clinical models etc) as conformance points for procurement;
- This in turn prevents lock-in on the basis of data format, or any other technical element;
- It also ensures that the customer retains control and ownership of the data, ensuring it does not incur unexpected costs in the future for its long term use.
- It provides a direct way for clinical experts to be involved in the specification and steady state development of the system into the future.
The growing list of openEHR suppliers as well as government-led programmes like Norway and the UK NHS producing clinical models and terminology artefacts for openEHR constitute a good basis for the ecosystem, providing diverse products, services and expertise, all guaranteed to interoperate according to openEHR and other relevant standards such as IHE, HL7 and ISO.
The paper will be useful for those advocating for an open platform, incremental based approach to e-health solutions, in which the customer organisations (providers) own the interfaces, and the patients (ultimately) own the data, via the clinical professionals.
Recently HSCIC and NHS England published an Interoperability Handbook, intended to help provider CIOs and others steer the difficult waters of obtaining interoperable health IT solutions. The target audience is listed as:
CCG Clinical Leaders, Chief Clinical Information Officers, Chief Information Officers, Directors IMT
so the publication can be understood primarily as an aid to procurement and in-house planning and development of EHR and other clinical information solutions.
I won’t provide a proper analysis of the document here, other than to say that it is likely to be a useful resource for its audience, and a good starting point for ongoing conversations and education in the e-health solutions area within the NHS (even just establishing standard nomenclature in the NHS for talking about the relevant concepts is a worthwhile exercise). Interoperable solutions are a huge engineering enterprise, so hopefully it will be understood that documents like this one act as useful reference points, but in no way replace the needed human resources and competencies to plan and deliver actual solutions.
However, I do have some comments…