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.

2 thoughts on “Ocean Case Study: Clinical Engagement

  1. Heather,
    Could you please do some tutorial videos on OpenEHR modelling using an archetype editor and/or workbench? I am a dentist, currently doing PhD in health informatics. I have played around with archetype modelling, and couldn’t find enough satisfactory tutorial content. I did find some on YouTube, but I feel we need more, in addition to the text content on the OpenEHR website.

    For e.g. I have information models in dentistry in a spreadsheet format that I would like to translate into OpenEHR models. It would be great to see you take a simple information model , and do the same, recording your thought process. It would also be great to see how you create templates and adapt the same archetypes for different clinical contexts.

    Maybe I’m not looking in the right places. There could be others that I have not found yet.

    Thanks
    Gopi

    • Hi Gopi,

      You are right. There is very little information out on the net for free.

      I am currently in the process of developing an online course about clinical modelling. We were hoping to have the intro modules ready for launch at Medinfo next week, but the timeframes might defeat me, and it will take some time to develop modules that will cover what you need.
      You might do better to try to work collaboratively with others directly via the openEHR mail lists if you want to do this quickly – then request an incubator on CKM and let the archetypes grow organically with help from the community.

      Regards

      Heather

Leave a comment