Don’t panic – incoherence ain’t all bad!

In November 2014, a paper was published: Developing Large-scale Electronic Patient Records Conforming to the openEHR Architecture –  by Norwegian authors Gunnar Ellingsen, Bente Christensen & Line Silsand.

Part of the final concluding discussion reads:

“…Similarly, the effort of National ICT in Norway to use archetypes from international repositories of archetypes (i.e. CKMs), indicates that there are little coherence among the existing repositories…”

Some of my openEHR colleagues started to panic. How could we allow incoherence? How could we allow divergence? Were we failing in our clinical knowledge governance responsibilities?

My responses:

• Incoherence is not necessarily bad. It is a natural and potentially healthy part of a distributed archetype development process, especially when working at an international level, but we absolutely do need processes in place to manage and mitigate it;
• Divergence will occur. It just will. So we have to learn how to live with it and manage it; and
• Our clinical knowledge governance is strong. That is exactly why the incoherence was noticed in the first place.

Let’s start from the current reality… most of our clinical systems use non-public, proprietary data models, and so is not unreasonable to conclude that we at the atomic data level we actually have maximal non-interoperability and incoherence. Interoperability between these systems only occurs due to mappings and transformations to standardised messages and then reversing this process in the receiving systems.

The openEHR approach is rather orthogonal to traditional clinical system development processes in that it involves sharing clinical archetypes that define the content we require in our electronic health records (EHRs) and the Clinical Knowledge Manager tool is in use as an online archetype repository, collaboration portal and governance vehicle.

Some have said to me that we should only allow one central openEHR Clinical Knowledge Manager (CKM) – effectively a single source of truth for all archetypes. While it is tempting to think that this would solve many aspects of problems with interoperability, it is not realistic. I can fully understand why national eHealth programs feel the need to manage their own national clinical content standards: Australia’s NEHTA CKM; Norway’s Nasjonal IKT CKM; UK’s NHS HSCIC CKM; Slovenia’s eHealth CKM; and Brazil’s CENTERMS CKM are all perfect examples. And there is also value contributed from grassroots collaboration happening within some eHealth projects in UK, resulting in the grassroots UK Clinical Models CKM.

Clinical knowledge governance is complex at the best of times. I think the openEHR approach and the processes built into the CKM product demonstrate that we understand this area better than many. Our approach to clinical knowledge governance is very people-focused, particularly aimed at engaging the true domain experts, grass roots clinicians, rather than technical standards developers. In many situations it is a classic example of herding cats, as effectively suggested in the Norwegian paper – doing anything collaboratively with intelligent humans is like that. But within the openEHR communities we are collaborating successfuly, momentum is building… and good quality, clinically verified archetypes are being published, ready for vendor implementation.

The transparency of the CKM tool allows us to see the true state of our shared information models – both the well designed, coherent ones that we want to see as well as the rather embarrassing ones that are not yet quite right. It is too easy for outsiders to point out the incoherence as evidence that there are problems or flaws with the openEHR governance process. But the reality is actually the opposite – the transparency and openness of each CKM enables us to understand the reality of the current situation, no smoke and mirrors here.

Without the transparency that is offered by each CKM we would be unable to estimate the extent or impact of the incoherence that exists or make informed decisions on how to resolve the issues. Be realistic here – that incoherence may not be obvious in other standards organisations is due to a lack of transparency, rather than that it does not exist.

There are a number of, not unreasonable, causes of archetype divergence between existing CKM repositories:

1. Differing local and jurisdictional requirements – these are commonly imposed on implementers by various levels of government and usually require locally unique archetypes. We have devised an approach that allow for local configuration while still using the broadly applicable interoperable archetypes. These will likely remain with us for the foreseeable future.
2. Uncoordinated or fragmented development of archetypes.
3. The natural evolution of archetype design patterns over time, including differing approaches, scope or focus.

This problem can be largely solved, or at least mitigated, if there is a willingness for collaboration between the administrators of the different CKM instances – over time, islands of incoherence will gradually become less.  It is essentially a human, rather than technical, problem that we can do something about.

Rather than experience that heart-sink moment as someone points out an area of incoherence, dsivergence or error, I welcome that someone has taken the time to look and identify an issue. This knowledge or insight enables improvement, quality control or correction. Individuals or groups can be motivated to tackle and fix the problem; to find the other candidate archetypes; identify other individuals with whom they can collaborate; and contribute the resulting archetype back to all of the CKM communities.

And responding to the criticism from the article, above: I have absolutely no problem that we currently have different archetypes for tobacco use in various CKMs. There is no doubt that I would much rather that we had a single, super elegant published archetype to represent tobacco use and smoking already, but despite quite a lot of work this has not been possible to date. In reality, tobacco use, and addiction more generally, is a hugely complex clinical area where very little has been standardised, despite it being core clinical content for any paper or electronic health record. The draft archetypes in question have not yet been agreed, verified and published as fit for use by any clinical community – so the content is still up for discussion, anyone can put their hand up to solve this outstanding problem.

And in fact, in recent weeks the Norwegian CKM team have indicated a willingness to lead the collaboration on this family of archetypes – not just tobacco/smoking but the similar patterns required for recording alcohol and other drug use. While I have made a number of previous attempts, the ideal solution has evaded my efforts to date. Hopefully by combining our efforts we can change that. It is now up to a much broader ‘people-power’ to solve the problem – identify a robust modelling pattern, develop the next draft candidate, and review and refine it with the domain experts.

Once this new tobacco archetype is published it will be up to each individual CKM instance to choose to adopt, adapt or manage. Ultimately it is their choice and responsibility – to participate, effectively maximising interoperability, or not, with the real consequences of divergence and reduction in international interoperability. There is a definite tension here, no simple, one-size-fits-all, perfect solution. Some CKM instances collaborate actively – the international and Norwegian CKMs run parallel archetype reviews in an attempt to minimise convergence yet still allow Norway to fulfill their government imposed mandate to manage their archetypes according to well-defined governance rules. Other CKMs may adopt published archetypes from other CKM instances, or use them as the starting point for their own. Others choose to operate completely independently, building their own archetypes from scratch – as time passes, it will be interesting to observe the outcomes of their independent approach.

The openEHR clinical knowledge governance processes are considered world-leading, yet we are all still learning here. Incoherence is not ideal, but it is a realistic part of any work such as this. Transparency and openness can only help to mitigate some of the incoherence but it is certainly not acceptable as a long term solution, but within a governed environment it can be leveraged constructively and collaboratively to improve the quality of future published archetypes.

The openEHR approach and CKM tools enable groups and individuals to actively participate – to make a difference in interoperability, rather than sitting back and complaining about how clinical systems don’t share data! If we truly aspire to shared EHRs the eHealth community need to actively work towards reducing the incoherence and maximising interoperability of atomic health data.

Please note: The Norwegian national governance framework is described in detail here and a must read for those interested in this evolving clinical knowledge domain. I will let that work speak for itself (via Google translate for most of you!)

The challenge for FHIR: meeting real world clinician requirements

Having just participated in the Melbourne FHIR Clinical Connect-a-thon, I’ve come away with lots of food for thought. My impression is that the ability for clinicians to influence the FHIR process will be limited to those in the Connect-a-thon room and additional engagement via email lists and teleconferences, technical artefact review, and a rigid balloting process – this will be challenging.

Ultimately, the interoperability problem that we (including FHIR) need to solve is no longer primarily a technical one, but one that is socio-technical: with the imperative that it is driven by the clinicians from now on, rather than the techies/engineers.

A couple of the major points here, others will no doubt come later:

• there is a big gap between the mostly generic FHIR resources currently under development and the full scope of clinical data needed by us clinicians, even if only for FHIR’s messaging priority. This can be considered in terms of
  • the sheer number of resources required to cover detailed and specific content for broad clinical coverage of general medicine and specialties cf generic resources such as Observation and Condition;
  • granularity and level of detail of resources;
  • re-use of resources; and
  • the focus on data that is currently in use in existing systems, rather than establishing the data specifications that clinicians want and need in state-of-the-art clinical systems – in effect a roadmap for the existing systems to work towards.
• the design of the current FHIR resources for use in messages vs the possibly/maybe increasing expectations of the FHIR community to use FHIR as the basis for electronic health records and data persistence; and
• the reliance on extensions will produce huge pockets of non-interoperability unless these are governed in the same way as formal FHIR resources, which rather defeats the purpose of local extensions.

The rather extensive image below is a real life example of an openEHR archetype/template specification, based for clinician-identified requirements, that is currently undergoing implementation in a new clinical information system. Some components of this template will also be used for reporting and in messages, so this level of detailed content will need to be considered for real world FHIR implementations as well.

Others may disagree, but I think that FHIR will eventually need to be able to recreate this kind of real world content as specified and agreed by the clinicians themselves…

In this image, keep in mind that the black data elements are active; the greyed out data elements are inactive, ie not required by the clinician for this clinical scenario. But still the sheer number of archetypes that are required to cover the number of clinical concepts that need to be used for a teleotology assessment by a remote ENT surgeon are surprisingly large.

To try to represent the range and level of detail for this clinical purpose by assembling current FHIR resources such as Condition or Observation and making them fit for the clinical purpose will render modellers into a world of pain. And, of course, the risk is that each assembly of the name/value pairs in Observation will be done differently by each modeller, resulting in non-interoperability after all. The resources will need to be governed, including local extensions.

With the increasing burden of technical engagement resulting from the incredible expectations generated by FHIR globally, perhaps the clinical content specification should be outsourced to… the clinicians first of all, ensuring that the clinical content can be represented in a technical format for implementation.

It makes good sense to explore how we can leverage the existing openEHR archetypes and the clinician engagement/asset governance processes in CKM as seamlessly as possible to streamline the FHIR resource development and provide a forward path to interoperability. The potential value of transformations from archetypes directly to FHIR resources could solve a number of the issues I raise above…

Oil & water: research & standards

The world of clinical modelling is exciting, relatively new and most definitely evolving. I have been modelling archetypes for over 8 years, yet each archetype presents a new challenge and often the need to apply my previous experience and clinical knowledge in order to tease out the best way to represent the clinical data. I am still learning from each archetype. And we are still definitely in the very early phases of understanding the requirements for appropriate governance and quality assurance. If I had been able to discern and document the ‘recipe’, then I would be the author of a best-selling ‘archetype cookbook’ by now. Unfortunately it is just not that easy. This is not a mature area of knowledge.

I think clinical knowledge modellers are predominantly still researchers.

In around 2009 a new work item around Detailed Clinical Models was proposed within ISO. I was nominated as an expert. I tried to contribute. Originally it was targeting publication as an International Standard but this was reduced to an International Specification in mid-development, following ballot feedback from national member bodies. This work has had a somewhat tortuous gestation, but only last week the DCM specification has finally been approved for publication – likely to be available in early 2014. Unfortunately I don’t think that it represents a common, much less consensus, view that represents the broad clinical modelling environment. I am neither pleased nor proud of the result.

From my point of view, development of an International Specification (much less the original International Standard) has been a very large step too far, way too fast. It will not be reviewed or revised for a number of years and so, on publication next year, the content will be locked down for a relatively long period of time, whilst the knowledge domain continues to grown and evolve.

Don’t misunderstand me – I’m not knocking the standards development process. Where there are well established processes and a chance of consensus amongst parties being achieved we have a great starting point for a standard, and the potential for ongoing engagement and refinement into the future. But…

A standards organisation is NOT the place to conduct research. It is like oil and water – they should be clearly separated. A standards development organisation is a place to consolidate and formalise well established knowledge and/or processes.

Personally, I think it would have been much more valuable first step to investigate and publish a simple ISO Technical Report on the current clinical modelling environment. Who is modelling? What is their approach? What can we learn from each approach that can be shared with others?

Way back in 2011 I started to pull together a list of those we knew to be working in this area, then shared it via Google Docs. I see that others have continued to contribute to this public document. I’m not proposing it as a comparable output, but I would love to see this further developed so the clinical modelling community might enhance and facilitate collaboration and discussion, publish research findings, and propose (and test) approaches for best practice.

The time for formal specifications and standards in the clinical knowledge domain will come.  But that time will be when the modelling community have established a mature domain, and have enough experience to determine what ‘best practice’ means in our clinical knowledge environment.

Watch out for the publication of prEN/ISO/DTS 13972-2, Health informatics – Detailed clinical models, characteristics and processes. It will be interesting to observe how it is taken up and used by the modelling community. Perhaps I will be proven wrong.

With thanks to Thomas Beale (@wolands_cat) for the original insight into why I found the 13972 process so frustrating – that we are indeed still conducting research!