Ocean Case Study: Clinical Engagement

This case study of my experiences in clinician engagement is about to be published on the Ocean website and might be of interest…

Bridging the gap between the clinical experts and software engineers involved in eHealth projects is well known for being difficult and frustrating for both sides. Ocean Informatics has been at the forefront of developing a new approach that gives the clinicians an ability to drive, not just contribute to, eHealth specification development while at the same time satisfying the technical needs of the implementers.

The Northern Territory (NT) is a sparsely populated state in the very north of Australia, with small settlements scattered across the territory and limited access by road. A small, dedicated group of clinicians triage and manage remote patients via phone, and arrange recovery of critically ill patients from remote locations using the ubiquitous Royal Flying Doctor Service.  Their wish: an application that would bring their telephone triage processes into the digital age. Ocean Informatics was engaged to identify the clinical requirements and develop content specifications for a third party vendor to implement in purpose-built software.

This case-study discusses how the pragmatic ‘openEHR methodology’ approach developed by Ocean informaticians has been used to bridge the clinician-to-technologist gap.

It is very rare for this dedicated group of NT GPs to be in the same physical place at the same time, so we needed to leverage our access to their expert knowledge very efficiently. They were gathered in Darwin on two days back in 2012—we had a single opportunity for a face-to-face meeting.  Our modelling team comprised two clinical informaticians – one driving the discussion, the clinical modeller documenting the discussion.

Most of these participating clinicians had no knowledge of electronic health records (EHRs); none had any experience with openEHR. The task: to capture the clinician’s expert knowledge, convert it into computable specifications and then produce an output that could be given to the software developers for implementation.

In a workshop held over one and a half days, we:

  1. Identified and recorded the clinical requirements, workflow and business rules using mind maps. From a blank mind map we gathered and organised the clinical requirements, documented their workflow and the logic that underpinned each data point. In practice we displayed the mind map on screen and used it as a living requirements document, evolving through the discussions and continuous feedback, being reorganised as we identified the complexities, dependencies and relationships of all the components.
  1. Built draft clinical specifications in parallel to the mind map development, directly in front of the clinicians. This involved the clinical modeller aggregating existing openEHR archetypes into templates that accurately represented the clinicians’ mind map as well as identifying the requirements for new archetypes. The clinicians were able to verify each template’s data points and constraints against their mind map—the template was easily interpretable alongside their mind map, so they were able to easily participate. Both the mind map and templates were refined through this process.
  2. Output a draft technical specification at the end of the second morning, potentially implementable.

While further refinement on the specifications was still needed due to addition of new archetypes identified in the mind map process, the project manager reflected observed that what had been achieved in less than two days would normally take them 6 months and the result would have been of a much lesser quality. Re-use of the archetypes is also a critical factor in the speed of specification development using this approach and we will see increases in the proportion of re-use as every project is completed—adding to the pool of clinically agreed archetypes that will be available for use in the next project.

Commencing a project with a face-to-face meeting has been found to be most effective way to create an environment where all participants have a baseline understanding of the process. However, after the initial workshops, further refinement of archetypes and templates can mostly be carried out via web conference, email and online collaboration using the Clinical Knowledge Manager tool (CKM) – http://www.openehr.org/ckm – or national CKM instances.  The online CKM tool enables asynchronous Web 2.0-style collaboration to iterate and refine the archetypes until the clinician consensus recommends them as ‘fit for purpose’!

Despite the Ocean clinical modeller living over 2000 kilometres away from these clinicians, ongoing collaboration was able to continue online, without the need for an expensive sequence of face-to-face meetings that would be disruptive to clinician work commitments and impair the important work-life balance.

This methodology is having great success in bringing the non-technical clinicians along with us on the clinical modelling journey. Even the less technologically savvy ones are able to actively contribute to the ‘pattern’ of the data that they can collect. The overwhelmingly consistent feedback from participants such as these is that the workshop participants enjoy the experience and are keen to be involved in ‘next steps’.

It also has the beneficial side effect that the clinicians have a sense of ownership over the data specifications – it is ‘theirs’ in a way no other clinical requirements gathering process allows. We have seen usually mild mannered clinicians take software engineers to task where their agreed template has been modified for technical reasons, demonstrating an understanding about the data that has not been easy to acquire before this approach. This kind of engagement by clinicians in development of eHealth specifications IS a rare but very fine sight to see!

Giving non-technical clinicians a very real voice and ensuring that the clinical content is appropriate in our eHealth solutions is major innovation enabled by this openEHR methodology. The simplicity and effectiveness of this approach still continues to surprise the team each time they work alongside a new group of clinical experts.

Take off the low-res sunglasses

I found these rather fantastic, if not rather unfeasible, sunglasses during some random internet browsing. They immediately reminded me of a recent meeting between clinicians and software vendors I attended; it felt to me like everyone was wearing these glasses. 

You can buy them here.

We all know that progress in health informatics has been glacially slow. Certainly the incremental innovation over the past 20,or even 30, years has resulted in progress, but lets be honest… the current, entrenched approaches haven’t ‘cracked it’ and probably never will. We don’t have interoperable health information. Sure, we have some limited interoperability, but there is no solution where the data is flowing seamlessly between systems.

Wasn’t it Einstein who said:

We can’t solve problems by using the same kind of thinking we used when we created them.

And I believe it was Albert who also said:

Insanity: doing the same thing over and over again and expecting different results.

There are some very strong parallels between these statements and the world of health informatics. At some point in time we need to face that continuing to innovate in tiny, ‘safe’ increments will not solve the problem. We need to break away from the tired old approaches and to think orthogonally, ‘outside the box’ if you like, to find creative solutions that will accelerate innovation and what we’ve been doing. I think one candidate that will contribute to the radical innovation we need may be the openEHR approach

In this meeting I suggested (enthusiastically, hopefully) that if they could ‘zoom out’ and focus on a good quality data, they could achieve a solid basis for most of the work they wanted to do rather than focus in on achieving small, fragmented projects. Collaboration on a standardised data strategy would provide a foundation to not only achieve the small projects more easily BUT ALSO leverage the data structures to do a whole lot more besides. Unfortunately that message wasn’t well received. They didn’t seem to want to hear about alternative directions.

Personally, I feel like working with the openEHR approach to data standardisation is akin to taking these rather retro-style sunglasses off. The darkness and difficulty to see the way forward is removed. I’m now hopeful that we can make significant progress. The lack of clarity, direction and ‘pixelation’ has gone away – I’m seeing that we can start to achieve things with data that wasn’t possible before. And lastly the narrowed focus is widened with the understanding that if we ‘get the data right’ then almost anything is possible with good quality, unambiguous data.

Clinical modelling, openEHR style

I wrote this document this week for other purposes, but decided that it is worth sharing more broadly. Thanks to Thomas Beale, aka @wolands_cat, for some final tweaking.

1 Background

The open source openEHR architecture specifications have evolved as the result of over 20 years of research and international implementations, including the Good European Health Record (GEHR). The IP of the specifications are held under the auspice of the not-for-profit openEHR Foundation.

The traditional view of an EHR usually refers to a specific vendor application or system with the resulting risk of vendor lock-in of data. In contrast to this, openEHR emphasises that the health record comprises the clinical data itself, and ensures that it is available in a standardised, non-proprietary format.

The technical approach utilized by openEHR is a unique multi-level design paradigm which clearly demarcates between generic, technical models of data, and clinical content. Technicians / engineers manage the software engineering and clinicians manage the clinical content.

One of the key principles in openEHR is that common, coherent and clinician-approved clinical information models are essential for accurate and advanced health-related computing, shared EHRs and coordination of clinical care across clinical systems. Content models agreed at an organisational, regional, national or international level provide a firm basis for establishing technical and semantic interoperability. The broader the level of content model agreement, the greater the potential for unambiguous and detailed health information exchange, decision support and analytics.

The development of a clinician-led library of clinical content specifications will be a foundation piece of national health IT infrastructure, intended to support interoperability of all granular health information, rather than simply exchange a limited selection of inflexible messages or documents as is common today.

Over the past two decades the openEHR clinical modelling methodology has gradually evolved. The strategy underpinning it is one in which engagement and involvement of even the least technical of clinicians is prioritised and their participation supported and encouraged. Active clinician participation is the only means to ensure that the clinical content of our EHRs is clinically safe and fit for both direct patient care and secondary purposes.

2 Approach

The openEHR clinical modelling approach involves:

  • Development of the clinical knowledge resources thatare used to represent the health data:
    • Archetypes, which are the foundation building blocks at the clinical concept level – one archetype per clinical concept;
    • Templates, which aggregate, combine and constrain the archetypes to create context-specific clinical data sets and documents such as clinical notes, discharge summary documents or messages that will be used in EHR systems;
    • Terminology value-sets, which provide allowable coding for specific data fields, based on underlying terminologies such as SNOMED CT, ICDx, ICPC, and many others.
  • Online collaboration processes for clinicians and other domain experts to ensure that the archetypes and templates are clinically validated, agreed and approved;
  • A governance mechanism that ensures that a cohesive library of archetypes, templates and terminology subsets are developed, maintained, managed and disseminated according to business rules that are transparent, and the entire governance process accountable to the participating modelling community; and
  • Local domain experts – teams of clinicians, health informaticians and engineers – are trained to manage this end-to-end process to meet eHealth programme requirements.

2.1 Archetypes

openEHR archetypes are clinical content specifications that formalise the patterns and requirements for representation of detailed, computable health-related data. Each archetype defines a topic-related set of data groups and elements. For example, there are separate archetypes for recording symptoms, a blood pressure measurement, an ultrasound report and a medication order. Over time, it is expected that low thousands of archetypes will be needed to cover all of mainstream medicine.

Each archetype is intentionally designed to be inclusive of all possible data elements that could be relevant for the topic and for all possible clinical use cases – this is termed a maximal data set for the universal use case. Often there is initial scepticism that this is achievable, however it is easier to start with a pragmatic data set and incrementally grow it as requirements are identified, rather than trying to get agreement on a minimum data set. As a result the Blood Pressure archetype has grown over time to be inclusive of all data elements that are required for:

  • a patient to record their blood pressure using an automatic machine at home;
  • a paramedic to record vital signs for a trauma patient in the field;
  • devices to record intermittent measurements in the Intensive Care Unit; or
  • analysis of multiple records for the purposes of a national population health analysis.

Non-technical clinicians and other domain experts are able to use clinical modelling tools with a ‘drag and drop’ interface to create and edit archetypes without having to understand the full complexity of the technology that underlies it. This is the first methodology that allows typical clinicians to actively and directly engage with EHR content development.
There is no language primacy and all archetypes are potentially multilingual, with original authoring able to occur in any language and be translated into as many languages as required. Archetypes are also terminology agnostic, permitting multiple terminology codes to be bound to each data element, plus potentially binding of structured subsets as valid value sets.

Terminology binding to archetypes may occur over time, and may not even commence until after the archetype has been initially deployed, allowing implementing organisations to get started with data, regardless of the state of terminology preparedness, often a slow, national issue.

Archetypes are regarded as the ‘source of truth’ for representation of data and require rigorous governance. This ensures that provenance, modifications and changes in publication status are transparent to implementers and downstream disruption to software is managed and understood.

Most archetypes used on a project are obtainable from elsewhere – either the international openEHR archetype repository, or one or more other national repositories. Thus, archetypes represent a growing global library of re-usable content models, greatly reducing the amount of work required in any new project or jurisdiction to define needed content. An incremental effort of 15% of the total content models deployed, plus translation where relevant, is a realistic expectation in terms of work for a new project.

2.2 Templates

openEHR templates are more detailed specifications that represent the implementable data sets – the documents, clinical notes, messages and screens required for use within, and between, EHRs. Templates are aggregations of specific elements of one or more archetypes; for example, up to 60 archetypes may be required to represent all of the clinical data elements that are needed for a discharge summary or antenatal record.
Each archetype in the template is constrained for the proposed clinical scenario, hiding non-essential data elements and revealing only the required ones – effectively reducing the authored maximal data set to the ‘clinically relevant’ data set. Templates can also include other Entry-level templates and are where most of the context-appropriate binding to terminology subsets will occur. Critically, Composition templates are the unit of commitment into an EHR.

Templates are extremely important as they allow the expression of clinical diversity, even when using identical archetypes. For example, the same 10 archetypes could be used to represent cardiac examination findings, but differing constraints will enable appropriate levels of detail to be expressed for use by a primary care clinician or for a cardiologist.
As long as the underlying archetypes are tightly governed, governance of the resulting templates can be lightweight, unless the template is representing something that has an official status, such as a formalised and structured data report to government.

3 Tools

3.1 Clinical Modelling Suite

Current openEHR tools for clinical modelling consist of:

  • Archetype Editor – an open source tool with a ‘drag and drop’ user interface that enables local authoring and editing of archetypes. The complex technical attributes of the openEHR Reference Model and Archetype Definition Language (ADL) that underpin the archetypes is largely hidden to clinician authors. The Editor enables all classes of archetypes to be created: Compositions; Sections; all types of Entries, including Observation, Evaluation, Instruction, Action and Admin Entry; and Cluster and Elements.
  • Template Designer – a free tool with a ‘drag and drop’ user interface that enable local authoring and editing of templates. In addition, the Template Designer is used in production contexts to generate template-specific downstream software artefacts, including Template Data Objects (TDOs), which are programming facades, and also Template Data Schemas (TDSs), which are XML Schemas that define an XML payload that can be used in a message, document or other communication. These downstream artefacts allow non-openEHR trained developers to immediately use openEHR semantic models to build and deploy software.

3.2 Clinical Knowledge Governance

As openEHR archetypes and templates were developed by the international community, it rapidly become apparent these clinical models required a formal publishing and governance support to be able to achieve the goal of semantic interoperability. Development of an online knowledge repository commenced testing in late 2008, and is known as Ocean’s Clinical Knowledge Manager (CKM). It holds and manages archetypes, templates and terminology subsets as primary assets, as well as associated documentation.

CKM has also been developed to leverage the notion of collective intelligence, where “individuals decide to mutualize their knowledge, know-how and experience in order to generate a higher individual and collective benefit than if they remained alone ”. By combining a crowd sourcing approach with the collaborative power of the internet CKM supports a shared online community to collaborate together to define high quality, well reviewed clinical archetypes and templates for use in patient care. There are no barriers to participation, anyone interested can volunteer to join in archetype reviews or submit a candidate archetype to the community.

The third key aspect of CKM is about rigorous but transparent governance – guaranteeing appropriate processes for the management, maintenance and dissemination of the clinical resources. Clinical Knowledge Administrators are responsible for the operations of the CKM tool, management of the participating community and management of a coherent and high quality library of clinical content resources – minimising any gaps between archetype concepts as well as avoiding potential overlaps between archetypes. Editors coordinate community reviews of archetypes and templates, gradually refining each resources until they are fit to be published as stable artefacts ready for implementation. Translators are able to submit translations and terminologists add terminology bindings, once archetypes are stable and published. Grassroots clinicians require minimal training in order to participate in archetype or template reviews – they contribute where they have domain expertise, ensuring the clinical content is appropriate – while informaticians and engineers can contribute their expertise to ensure that the archetype is technically valid, and appropriate for implementation.

The openEHR Clinical Knowledge Manager (CKM), under the auspice of the openEHR Foundation, is used as an international source of excellence. As of July 2014 there are over 1100 experts registered on the openEHR CKM from 83 countries, with many archetypes translated into multiple languages to enable cross country sharing of health data. Norway, Slovenia and Australia have established CKM instances for their national eHealth programs. Negotiations are underway with Brazil for a national instance. The UK instance currently serves Scottish NHS, and is being proposed for use for NHS England.

4 Training & Mentoring

In order to establish a new CKM, Ocean Informatics offers a flexible program of training and mentoring designed to rapidly upskill a local team of domain experts to manage all aspects of archetype and template authoring as well as clinical knowledge governance of all the resulting clinical content models. The program usually lasts 12 months and will support the local core experts to be self-sustaining in as short a time as possible. Introductory training will provide basic levels of understanding to a broad range key stakeholders and decision-makers. Intensive training and workshops will benefit the core team who will deliver clinical content authoring, editorial and governance services. Ongoing remote mentoring to the core team will ensure rapid problem solving and accelerate independent clinical modelling competency.

5 Summary

In essence:

  • The openEHR clinical content specifications will be defined, reviewed and declared fit for purpose by clinicians and domain experts, not just software developers/engineers.
  • The archetype and template development, quality control, standardisaton and governance processes should be managed by expert health informaticians who understand health data and how it will be implemented and used in the clinical environment.
  • The end users will be the vendors and organisations building clinical information systems and applications and organisations who need to utilise quality health data for secondary purposes.
  • The overall project governance should be led by clinical professional groups +/- a potential consortia with appropriate political/industry groups etc.
  • Clinical professional and government organisations can endorse the resulting clinical models as fit for use.
  • openEHR Solutions can be deployed at any time with respect to the development of clinical content models – including before any are complete. The release and deployment of each model (template) requires no changes at all to openEHR-based EHR back-end implementations, i.e. services and database; changes / additions are limited to user screens and content-specific logic.

The outcome of such a program of coordinated clinical content standardisation provides a long term and sustainable national approach to developing, maintaining and governing jurisdictional health data specifications. It can form the backbone for a national health data strategy and is a key way to ensure that clinicians contribute their expertise to jurisdictional eHealth programs.