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!)

Archetype Re-use

Last Thursday & Friday @hughleslie and I presented a two day training course on openEHR clinical modelling. Introductory training typically starts with a day to provide an overview – the “what, why, how” about openEHR, a demo of the clinical modelling methodology and tooling, followed by setting the context about where and how it is being used around the world. Day Two is usually aimed at putting away the theoretical powerpoints and getting everyone involved – hands on modelling.

At the end of Day One I asked the trainees to select something they will need to model in coming months and set it as our challenge for the next day. We talked about the possibility health or discharge summaries – that’s pretty easy as we largely have the quite mature content for these and other continuity of care documents. What they actually sent through was an Antineoplastic Drug Administration Checklist, a Chemotherapy Ambulatory Care Nursing Intervention and Antineoplastic Drug Patient Assessment Tool! Sounded rather daunting! Although all very relevant to this group and the content they will have to create for the new oncology EHR they are building.

Perusing the Drug Checklist ifrst – it was easily apparent it going to need template comprising mostly ACTION archetypes but it meant starting with some fairly advanced modelling which wasn’t the intent as an initial learning exercise.. The Patient Assessment Tool, primarily a checklist, had its own tricky issues about what to persist sensibly in an EHR. So we decided to leave these two for Day Three or Four or..!

So our practical modelling task was to represent the Chemotherapy Ambulatory Care Nursing Intervention form. The form had been sourced from another hospital as an example of an existing form and the initial part of the analysis involved working out the intent of the form .

What I’ve found over years is that we as human beings are very forgiving when it comes to filling out forms – no matter how bad they are, clinical staff still endeavour to fill them out as best they can, and usually do a pretty amazing job. How successful this is from a data point of view, is a matter for further debate and investigation, I guess. There is no doubt we have to do a better job when we try to represent these forms in electronic format.

We also discussed that this modelling and design process was an opportunity to streamline and refine workflow and records rather than perpetuating outmoded or inappropriate or plain wrong ways of doing things.

So, an outline of the openEHR modelling methodology as we used it:

  1. Mind map the domain – identify the scope and level of detail required for modelling (in this case, representing just one paper form)
  2. Identify:
    1. existing archetypes ready for re-use;
    2. existing archetypes requiring modification or specialisation; and
    3. new archetypes needing development
  3. Specialise existing archetypes – in this case COMPOSITION.encounter to COMPOSITION.encounter-chemo with the addition of the Protocol/Cycle/Day of Cycle to the context
  4. Modify existing archetypes – in this case we identified a new requirement for a SLOT to contain CTCAE archetypes (identical to the SLOT added to the EVALUATION.problem_diagnosis archetype for the same purpose). Now in a formal operational sense, we should specialise (and thus validly extend) the archetype for our local use, and submit a request to the governing body for our additional requirements to be added to the governed archetype as a backwards compatible revision.
  5. Build new archetypes – in this case, an OBSERVATION for recording the state of the inserted intravenous access device. Don’t take too much notice of the content – we didn’t nail this content as correct by any means, but it was enough for use as an exercise to understand how to transfer our collective mind map thoughts directly to the Archetype Editor.
  6. Build the template.

So by the end of the second day, the trainee modellers had worked through a real-life use-case including extended discussions about how to approach and analyse the data, and with their own hands were using the clinical modelling tooling to modify the existing, and create new, archetypes to suit their specific clinical purpose.

What surprised me, even after all this time and experience, was that even in a relatively ‘new’ domain, we already had the bulk of the archetypes defined and available in the NEHTA CKM. It just underlines the fact that standardised and clinically verified core clinical content can be re-used effectively time and time again in multiple clinical contexts.The only area in our modelling that was missing, in terms of content, was how to represent the nurses assessment of the IV device before administering chemo and that was not oncology specific but will be a universal nursing activity in any specialty or domain.

So what were we able to re-use from the NEHTA CKM?

…and now that we have a use-case we could consider requesting adding the following from the openEHR CKM to the NEHTA instance:

And the major benefit from this methodology is that each archetype is freely available for use and re-use from a tightly governed library of models. This openEHR approach has been designed to specifically counter the traditional EHR development of locked-in, proprietary vendor data. An example of this problem is well explained in a timely and recent blog – The Stockholm Syndrome and EMRs! It is well worth a read. Increasingly, although not so obvious in the US, there is an increasing momentum and shift towards approaches that avoid health data lock-in and instead enable health information to be preserved, exchanged, aggregated, integrated and analysed in an open and non-proprietary format – this is liquid data; data that can flow.

Clinical Knowledge Repository requirements

I’ve been hearing quite a lot of discussion recently about Clinical Knowledge Repositories and governance. Everyone has different ideas – ranging from sharing models via a simple subversion folder through to a purpose-built application managing governance of combinations of versioned knowledge assets (information models, terminology reference sets, derived artefacts, supporting documentation etc) in various states of publication.

It depends what you want to achieve, I guess. In openEHR it became clear very quickly that we need the latter in order to provide a central resource with governance of cohesive release sets of assets and packages suitable for organisations and vendors to implement.

In our experience it is relatively simple to develop a repository with asset provenance and user management. What is somewhat harder is when you add in processes of collaboration and validation for these knowledge assets – this requires development of review and editorial processes and, ideally, display transparency and accountability on behalf of those managing the knowledge artefacts.

The most difficult scenario reflects meeting the requirements for practical implementation, where governance of configurable groups of various assets is required. In openEHR we have identified the need for cohesive release sets of archetypes, templates and terminology reference sets. This can be very complicated when each of the artefacts are in various states of publication and multiple versions are in use in ‘on the ground’ implementations. Add to this the need for parallel iso-semantic and/or derived models, supporting documents, and derived outputs in various stages of publication and you can see how quickly chaos can take over.

So, what does the Clinical Knowledge Manager do?

  1. CKM is an online application based on a digital asset management system to ensure that the models are easily accessed and managed within a strong governance framework.
  2. Focus:
    1. Accessible resource – creation of a searchable library or repository of clinical knowledge assets – in practice, a ‘one stop shop’ for EHR clinical content
    2. Collaboration Portal – for community involvement, and to ensure clinical models that are ‘fit for clinical use’
    3. Maintenance and governance of all clinical knowledge and related resources
  3. Processes to ensure:
    1. Asset management
      1. uploading, display, and distribution/downloading of all assets
      2. collaborative review of primary* assets  to validate appropriateness for clinical use
        1. content
        2. translation
        3. terminology binding
      3. publication life cycle and versioning of primary assets
      4. primary asset provenance, differential and change log
      5. automatic generation of secondary**/derived assets or, alternatively, upload and versioning when auto generation is not possible
      6. upload of associated***/related assets
      7. development of versioned release sets of primary assets for distribution
      8. identify related assets
      9. quality assessment of primary assets
      10. primary asset comparison/differentials including compatibility with existing data
      11. threaded discussion forum
      12. flexible search functionality
      13. coordinate Editorial activity
      14. share notification of assets to others eg via email, twitter etc
    2. User management
    3. Technical management
    4. Reporting
      1. Assets
      2. Users
      3. Editorial activity support

In current openEHR CKM the assets, as classified above, are:

  1. *Primary assets:
    1. Archetypes
    2. Templates
    3. Terminology Reference Set
  2. **Secondary assets:
    1. Mindmaps
    2. XML transforms
    3. plus ability to add transforms to many other formalisms, including CDA
  3. ***Associated assets:
    1. Design documents
    2. References
    3. Implementation guides
    4. Sample data
    5. Operational templates
    6. plus ability to add others as identified

While CKM is currently openEHR-focused – management of the openEHR artefacts was the original reason for it’s development – with some work the same repository management, collaboration/validation and governance principles and processes, identified above, could be applied for any knowledge asset, including all flavors of detailed clinical models and other clinical knowledge assets being developed by CIMI, or HL7 etc. Yes, CKM is a currently a proprietary product, but only because it was the only way to progress the work at the time – business models can always potentially be changed 🙂

It will be interesting to see how thinking progresses in the CIMI group, and others who are going down this path – such as the HL7 templates registry and the OHT proposed Heart project.

We can keep re-inventing the wheel, take the ‘not invented here’ point of view or we can explore models to collaborate and enhance work already done.