I am not a clinician; although I recently discovered that a friend of many years, who had been chair of the GMC Professional Conduct Committee, thought I was.
In a similar vein, I was once offered the job of medical director by a large health IT supplier, so I've probably spent too much time with clinicians and ought to get out more.
By the end of this column, my IT colleagues may agree with me. In it, I want to address one of the core challenges of interoperability and the creation of an open platform for digital health and social care.
That is “content”, more typically described as “clinical content”. However, as the challenge relates to the whole health and social care domain, I'm interested in more than just clinical content.
And please read my use of the term “clinician” or “clinical” to mean the relevant professional discipline to which a piece of content relates.
Start talking, quit squabbling
If we can agree on a way to define content in a computable, shareable form, the information models this will create will provide the lingua franca we need to link the various technical approaches to interoperability.
It will allow us to stop squabbling about the ever changing technical details: “My FHIR’s better than your CDA.” “No, it's not; my ADLs much better!” (Children, children play nicely together; we're all friends after all.)
What I mean by “content” is the definition – in fine-grained detail – of what we mean by the concepts we want to record, share and process in digital health and social care systems. What do we mean by a concept? What parameters and characteristics do we want to record about it and how do we want to represent them?
Definitions of content take the form of small, modular information models, which can then be used as the building blocks of electronic health records, structured documents and messages, clinical pathways and workflows.
Defining content is a massive task, with estimate of the number of such models required to represent the whole of clinical medicine coming it at around the 4,000 mark.
This number is growing as a result of geonomics and personalised medicine – and it excludes the social care domain, for which nobody has made any estimates.
The point is that the number is large and creating and maintaining all these modules is too big a task even for the largest healthcare vendors or government programmes.
Our only hope of meeting the challenge is to work together with an understanding that IT people can't build health and social care information systems on their own.
The dark arts and openEHR
It's also important to understand that the challenge is a clinical one. Not only does this mean that the process must be clinically led, but that the detailed work needs to be done by clinicians from the front line in both the user and vendor community.
This means it should not be done by professional modellers, distant from actually using systems in the real world. And this creates a challenge for the methodology.
It requires that it is accessible to busy clinicians without them dedicating years of their lives to learning the dark arts of the high priesthood of health informatics and reaching that nirvana where everyone suspects you are saying something very clever – if only they understood WTF you were talking about.
It will come as no surprise to my readers that I think the methodology that has cracked this challenge is openEHR.
OpenEHR can cause some confusion, because it can be used purely as a tool for modelling; with the models then implemented in the technology of your choice.
Alternatively, the models can be used natively in an openEHR compliant data repository. This later approach brings many additional benefits, particularly if you are building a new application.
However, there are many advocates of other approaches and converting an existing system to openEHR will not appeal to many existing system vendors; although some like Cambio and DIPs have chosen to do just this.
When it comes to the process of creating, curating and publishing clinical information models with the tools, community and governance required, though, no other methodology comes close.
Which is why openEHR is increasingly the tool of choice for national and regional IT programmes – for example in Norway and Australia. It has also been reluctanty adopted by our very own Health and Social Care Information Centre (oops, I mean NHS Digital).
A body to lead the way: step forward PRSB
OpenEHR tools are easily accessible to the IT literate clinician with just a few hours’ training. They provide the robust technical artefact developers need, and the latest tools support other technologies; allowing openEHR models to automatically generate the technical artefacts they require.
What we need is to get them used. For me, the obvious place where this should be done is the Professional Records Standards Body or PRSB; an independent organisation with the backing of the medical royal colleges.
The model I suggest has been long applied in the creation of clinical content in the area of drug information with the British National Formulary; also better known by its initials, BNF. The model is: commission the domain experts and leave them to get on with it.
Let them produce the models, handle their peer review and publication, create and then distribute the technical artefacts that developers will need. We don't need teams of modellers, ontologists and terminologists toiling away in ivory towers producing content and standards that nobody wants or understands.
Clearly, the PRSB will need some technical support (and may even need to offer a living to a few priests), but the bulk of the work needs to crowd sourced from the front line with content creation working in a similar way to Wikipedia.
It also has a few other things to think about. It needs to understand that it needs to get into to the detail – what it has is a good start, but only scratches the surface of the interoperability challenge.
It needs to extend its scope to bring in social care and other relevant professional domains. It needs to undertake more effective engagement with vendors – who need to be engaged throughout the content development life-cycle, not least to understand what developers need from them to build compliant, interoperable systems.
It needs to understand where it fits as part of an international effort – because the UK can't do this alone. It needs to revisit governance – because this needs to be fast, light-touch, fast and agile – and business models – because this work will cost money, but its outputs have to be open source and free for all to use.
If we can crack this, we will be well on route to leading the world in creating the open digital ecosystem for health and care; and that would be a good place to be.
Ewan Davis
|
