(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…
I am probably one of the longest time users of Adobe FrameMaker in the world. I started using it at version 2, sometime around 1990, and finished with it a few months ago. For most of this period it was the unbeatable desk top publishing solution for ‘serious’ documents and books (as opposed to magazine articles and the like). It was used by Sun Microsystems, IBM, and still I believe, HP for their technical publishing. The IMIA yearbook was historically published using it. Thousands of software and engineering companies around the world used it to publish manuals. It did a pretty good job of multi-channel publishing, at least to PDF and HTML, using WebWorks (now ePublisher), and was unbeatable for control over fonts, layout, cross references, and most other details of publishing.
Why did I stop using it?
openEHR training session last week at Hospital Sirio Libanes, one of the premiere teaching and research hospitals in Brazil. I delivered the background and theory part, Samuel Frade and Bostjan Lah (both from Marand) delivered the programming part.
We were there at the invitation of Beatriz de Fario Leao (no introduction needed there). Met a great team of business analysts and developers, some in the above photo. Looking forward to working more with them.
Brazil is starting to work a lot with openEHR, and may become one of the premier locations using it. Which would be great – a large country moving to a semantic, model-based technology for the EHR and interoperability.