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?

• COMPOSITION.encounter
• EVALUATION.adverse_reaction – one instance per adverse reaction included in a adverse reaction list
• EVALUATION.clinical_synopsis
• EVALUATION.problem_diagnosis – one instance per diagnosis included in a problem list
• INSTRUCTION.request-referral – one instance per referral requested
• ACTION.health_education
• ACTION.procedure – with two instances for different purposes

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

• OBSERVATION.story
• CLUSTER.symptom – with multiple instances for each symptom identified

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.

Warts and all: Reviewing an archetype

During my visit to HIMSS12 in February, I finally met Jerry Fahrni (@JFahrni) face to face - a pharmacist and Twitter colleague I'd had 140 character conversations over some years. We'd also talked on Skype once about some of the clinical archetypes some time ago, and during our HIMSS conversation I managed to persuade him to take a look at the openEHR community's Adverse Reaction archetype and participate in the community review.

He did, and at my further request he has put ink to blog and has recorded his experience as a newbie reviewer so that others might have some sense of what completing an archetype review entails, warts and all.

Jerry's review, reproduced here:

...According to good ol’ Merriam-Webster an archetype is “the original pattern or model of which all things of the same type are representations or copies: also : a perfect example“. Simple enough, but still too vague for my brain so I went in search of a better explanation which I found at Heather’s blog – Archetypical.

According to the Archetypical site ”openEHR archetypes are computable definitions created by the clinical domain experts for each single discrete clinical concept – a maximal (rather than minimum) data-set designed for all use-cases and all stakeholders. For example, one archetype can describe all data, methods and situations required to capture a blood sugar measurement from a glucometer at home, during a clinical consultation, or when having a glucose tolerance test or challenge at the laboratory. Other archetypes enable us to record the details about a diagnosis or to order a medication. Each archetype is built to a ‘design once, re-use over and over again’ principle and, most important, the archetype outputs are structured and fully computable representations of the health information. They can be linked to clinical terminologies such as SNOMED-CT, allowing clinicians to document the health information unambiguously to support direct patient care. The maximal data-set notion underpinning archetypes ensures that data conforming to an archetype can be re-used in all related use-cases – from direct provision of clinical care through to a range of secondary uses.” That gave me a better understanding of what they were trying to do.

Anyway, when Heather asked me to review the Adverse Reaction archetype I was a little hesitant. The projects I’m asked to be involved with are typically much smaller in scale. This was something different and I felt a little intimidated. My gut reaction was to politely decline, but when someone asks you to do something face to face it makes excusing yourself for some lame reason a lot harder. So I agreed with more than a bit of trepidation.

The openEHR project utilizes a system called the Clinical Knowledge Manager (CKM). In the most basic terms, the CKM is an online content management system for all the archetypes being designed by the openEHR project, and it’s impressive. A more in depth description can be found here.

Logging into the system was simple. The email invitation I received to review the Adverse Reaction Archetype contained a link that took me to the exact location I was supposed to be. From there things got a bit more complicated. The CKM is easy enough to navigate, but the amount of information and navigational elements within the system is staggering. It took me a while to figure out exactly what I was supposed to do. Once I figured it out I was able to quickly go through the archetype, read what other comments people had made and make a couple of minor notes myself. One thing I could never completely figure out was how to save my work in the middle and continue later. Sounds simple enough, but for whatever reason it just wasn’t obvious to me. I ended up powering through my “review” in one extended session because I was afraid I’d lose my place. The archetype itself was impressive. It’s clear from the information and detail that people have spent a lot of time and effort developing the adverse reaction archetype. There’s no question that a lot of great minds had been involved in this work. The definition made sense as did the data that was being collected and presented. The archetype offered flexibility for information gathering that included the simplest form of adverse reaction to complex re-exposure and absolute contraindication notation (this is sorely missing in many systems I’ve used over my career). Overall I had little insight to offer during the review, only a couple of minor comments.

I’d say the entire process was pretty straightforward with some minor complications. Like everything else I’m sure the process would get easier over time and multiple uses.

Thanks Jerry. Your independent and honest opinion is much valued. Perhaps next time... !! (Just joking)