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)

CIMI… one of many crossroads

Grahame Grieve posted CIMI at the Crossroads recently. I can’t disagree with a lot of the content, but maybe I’m a bit more of an optimist as I draw some slightly different conclusions.

Grahame is totally right about what it has achieved so far:

  • a significant membership roll that has never been achieved before
  • a significant agreement of an initial approach to clinical models – a primary formalism of ADL 1.5/AOM with a commitment to support transformation to isosemantic UML models in a spirit of inclusivity and harmonisation.

And as he points out, the notion that the modelling methodology was chosen independently of the Reference Model is somewhat disconcerting.

“…the decision to choose ADL/AOM as the methodology, while deferring the choice of reference model. While I understood the political reality of this decision, choosing an existing methodology (ADL/AOM) but not the openEHR reference model committed CIMI to building at least a new tooling chain, a new community, and possibly a new reference model.

The cost of this is high; so high that the opportunity created by the foundation of CIMI may likely founder if we see another attempt to reinvent the health IT wheel, yet again.

There are many opinions, and everyone at the CIMI table has their own bias, history, experience. Organisational and personal investment in each existing solutions are high. No one wants to throw away their efforts and ‘start again’; everyone wants their work to be the successful and sustained.

The CIMI community do need to make an objective decision if it is to move forward. It may not be result which wins a popularity contest. It is very likely that some members will walks away and keep working as they always have; maybe intending to return when a more mature solution is on offer.

In his paragraph on the pros and cons of openEHR, Grahame very eloquently states:

This is the first choice: pick the least worst established clinical modelling paradigm.

:)

“Least worst” – Thanks Grahame! You could turn that around: the ‘best’ available so far, where there is no perfect solution!

But it’s not a bad principle – to take the least worst and make it better!

The chair of the openEHR board, Sam Heard proposed the following to the openEHR community back in October 2011:

“If the CIMI group chooses to use ADL as the formalism then the openEHR community is prepared to explore the Foundation governance arrangements with the CIMI group and align the two efforts using the structures that are mutually agreed.

Changes to ADL and the openEHR Reference Model may be part of the process to meet the collective needs, and alignment of the shared RM and a reviewed RM for ISO 13606 would also be a major goal. ADL 1.5 would be submitted to ISO as part of this alignment.”

Seems sensible to me – start with a robust candidate and modify/enhance it to meet the collective needs. The latest version of the openEHR RM is clearly one candidate. It has evolved significantly from the 2005 version which forms the basis of ISO 13606. Given that ISO 13606 (parts 1-5) is due for revision this year, perhaps we have a great opportunity for harmonisation. The openEHR community is already starting to develop a proposal for the revision, but a greater achievement would be to align all of these efforts into a new 13606/openEHR/CIMI specification.

This is a difficult task that we are trying to solve. We know that because it has not been solved before.

This is definitely not the first crossroad that CIMI has encountered – don’t underestimate the effort that has brought the group to this point – and it will definitely not be the last. What will determine success is keeping the end goal front and centre in CIMI’s decision-making; cutting ruthlessly through the political and personal agendas; putting pragmatism ahead of perfection; and a willingness to compromise in order to move forward.

It may not be possible. It could be a hell of a ride. I still think it has the potential make a hell of a difference.

Modelling pregnancy

How to go about using openEHR archetypes to model a shared pregnancy record?

Step 1:  Analyse the existing resources; identify each of the discrete clinical concepts that contribute to the whole record.



24 clinical concepts have been identified within this example Pregnancy Health Record.

Step 2: Map clinical concepts to archetypes

Map them to existing archetypes or determine which new ones we need. Determine the state of the existing archetypes – do we need to modify or enhance with additional requirements? Consider all possible use cases for each archetype – the end result will be better if we can be as inclusive as possible for all clinical scenarios.

The archetypes identified for this Pregnancy record are:

Clinical Concept Comment

Corresponding archetype concept name
NOTE: is linked to the
actual archetype in a CKM instance

Antenatal Plan An overarching plan for the patient’s antenatal care Antenatal Plan <INSTRUCTION.antenatal_plan>
Information Provided Details of each piece of health education information discussed or provided to patient Information Provided
<ACTION.health_education>
Social Summary Social Summary
<EVALUATION.social_summary>
Adverse Reaction List Adverse Reaction list is made up of multiple Adverse Reaction entries Adverse Reaction
<EVALUATION.adverse_reaction>
Family History List Family History list is made up of multiple Family History entries Family History
<EVALUATION.family_history>
Diagnosis Problem lists, whether current or past are made up of multiple Problem/Diagnosis entries – the same data pattern will be used in all instances Problem/Diagnosis
<EVALUATION.problem_diagnosis>
Problem/Diagnosis List
Recent Problem/Diagnosis List
Procedure list Procedure list is made up of multiple Procedure entries Procedure
<ACTION.procedure>
Smoking consumption Tobacco use
<OBSERVATION.substance_use-tobacco>
Alcohol consumption Alcohol consumption
<OBSERVATION.substance_use-alcohol>
Obstetric Summary Obstetric summary
<EVALUATION.obstetric_summary>
Pregnancy Summary An evolving summary of key data about a single pregnancy – either current or past Pregnancy summary
<EVALUATION.pregnancy_summary>
Examination Findings Examination Findings
<OBSERVATION.exam>
Examination of the uterus
<CLUSTER.exam-uterus>
Examination of the fetus
<CLUSTER.exam-fetus>
Current Medication List Medication list is made up of multiple Medication instruction entries Medication instruction
<INSTRUCTION.medication>
Medication administered Medication action
<ACTION.medication>
Height Height/Length
<OBSERVATION.height>
Weight Body weight
<OBSERVATION.body_weight>
Body Mass Index Body Mass Index
<OBSERVATION.body_mass_index>
Blood Pressure Blood Pressure
<OBSERVATION.blood_pressure>
Fetal Movements Fetal Movements
<OBSERVATION.fetal_movements>
Fetal heart sounds Heart rate and rhythm
<OBSERVATION.heart_rate>
Urinalysis The pattern for urinalysis is identical to the pathology test results, and in some cases will be performed in the lab, so the same pattern will be used Pathology test result
<OBSERVATION.pathology_test>
Pathology Test results
Ultrasound results Imaging examination result
<OBSERVATION.imaging_exam>

KEY:
Pink archetype names indicate those that are early drafts.
Green archetype names indicate those that are reasonably mature – through previous reviews within CKM
Red archetype names indicate those yet to be developed.

Step 3: CKM Review

Within CKM each archetype will undergo review rounds by a range of clinicians, terminologists, software engineers, informaticians and other interested experts. The purpose of each review round will be to fine-tune each archetype so that it meets the requirements for each stakeholder group.

CKM Videos:

Step 4: Create an openEHR template

Once community consensus is reached within CKM, the archetypes will be aggregated and constrained in a template to accurately meet the specific use-case requirements for this particular Pregnancy Health Record. Each bold, black heading in the the following screenshot represents an archetype. The Pregnancy Summary archetype has been opened up to see the details. Black text indicates data elements that will be utilised in this use case; grey text indicates inactive data elements.

Other groups may use the same archetypes aggregated in a different order and constrained in a different way to represent their version of the Pregnancy Health Record. As the data in both Pregnancy Records is being recorded according to the same pattern, dictated by the underlying archetype, the information can be exchanged without ambiguity or loss of meaning.