Adverse reaction risk: the provenance

This week I documented the provenance of our Adverse Reaction Risk archetype – it has been a long & memorable journey from the first iteration in 2006 through to its publication in the international openEHR CKM last November 2015.

In the beginning was Sam Heard‘s original archetype – created way back in 2006 when Ocean Informatics had a .biz email address and before any collaboration – just the initial thoughts of one individual.


This was uploaded to the International openEHR CKM in July 2008.


In 2008 this archetype had its first collaborative review. The results of this were collated and as Editor I revised this archetype significantly to include the review feedback PLUS input from a number of publications available from NHS England, FDA and TGA  drug reporting requirements and the ICH-E2B publications. This was uploaded at the end of August 2009.

In late 2010, Australia’s National eHealth Transition Authority (NEHTA) forked the archetype and brought it into the NEHTA CKM environment and ran a series of 5 archetype reviews during the period through to June 2011. The resulting archetype formed the basis for the adverse reaction data elements in the initial PCEHR CDA documents which are currently being transmitted from Australian primary care clinical systems into the PCEHR (now rebadged as ‘My Health Record‘).

NEHTA starts.jpg

In 2012, there was another review round carried out in the international CKM.

The results from that 2012 review, the outcomes from the June 2011 NEHTA archetype and publications from HL7’s FHIR resource and RMIMs were amalgamated by Ian McNicoll in June 2014 to form a new archetype – initial called ‘Adverse Reaction (AllergyIntolerance)‘ and later, the ‘Adverse Reaction (FHIR/openEHR)’ archetype – with the intent of conducting a series of joint FHIR & openEHR community review of the combined model and at the end of the process generating a FHIR resource AND an openEHR archetype with matching, clinically verified content.hl7.jpg

In August 2014 the first joint openEHR/FHIR review was carried out, with myself (@omowizard, AU, openEHR), Ian McNicoll (@ianmcnicoll, UK, openEHR), Graham Grieve (@GrahameGrieve, AU, FHIR) & Russ Leftwich (@DocOnFHIR, USA, HL7 Patient Care/FHIR) as editors. Nasjonal IKT forked the archetype into the Norwegian CKM at the conclusion of that process.


There was a subsequent joint review between openEHR & FHIR that followed, only rather than the few weeks I had anticipated, we had to wait until the FHIR community completed a full FHIR ballot. This blew out the review period to 7 months for our work.


This really highlights the need to separate the ballot/review process for clinical artefacts like FHIR resources and archetypes from balloting process of complete technical standard or specification within a typical standards organisation. If we use this same glacially slow process for the governance of clinical artefacts then it will take decades to achieve high quality shared clinical models.

And one HL7 participant contacted me and said it would be impossible for them to respond to the archetype review in less than 6 months. <facepalm here>. Just for perspective, our typical review round is open for 2 weeks and it takes anywhere from 10 minutes to 30 minutes for most participants to record their contribution.

But we waited… and fed the FHIR ballot comments back into the next archetype iteration. There were not that many! And then we sent it out for the next review – and this time the Norwegian CKM community participated as well. The Norwegian CKM team (led by Silje Ljosland Bakke, @siljelb, & John Tore Valand, @Jtvaland) translated the archetype into Norwegian &  ran a slightly shorter review period, contributing the collective feedback into the international review.

We did this simultaneous review across the FHIR, international and Norwegian communities twice – once in July 2015 and another in November 2015. One of these reviews resulted in the renaming of the archeytpe  concept to ‘Adverse reaction risk’.


At the end of the November 2015 review round, the editors found that there was a consensus reached amongst the participants. In the international CKM we removed the FHIR-specific components and published the content of the ‘Adverse reaction risk’ archetype. The publication status of original archetype was simultaneously changed in the CKM  to rejected – this rejected archetype remains in the international CKM as part of the provenance/audit trail for the published archetype.


The Norwegian CKM has now taken that international archetype and published it within their CKM and under their own governance. The archetypes are semantically aligned.

The FHIR resource has evolved in keeping with the archetype changes. To be completed honest I’m not sure if the final, published openEHR archetype has been reflected back into the latest FHIR resource, but there is no doubt that there certainly the great majority of the two artefacts are aligned due to the joint review process.


The archetype that has finally been published started with the brain dump of a single clinical informatician. At this point in its journey this archetype alone has been shaped by:

  • 13 review rounds
  • 221 review contributions
  • 92 unique individuals
  • 16 countries (top 3 being AU, NO & US)

This has been a very significant block of international work. Getting any kind of consensus on such a clinically significant artefact across different jurisdictions, standards organisations and diverse requirements has not been easy. But we have experienced a great generosity of spirit from all who contributed their time, expertise and enthusiasm to capture an open specification for a single piece of clinical knowledge that can be re-used by others, and potentially improved even more over time.

This is what the published Adverse reaction risk archetype looks like today:


The detail and thought behind each data element and example is significant. Yet we know it is not perfect, nor ‘finished’.

No doubt we will identify new requirements or need to modify it. This journey will then start its next phase…

If you have identified additional requirements… If you disagree with the model…  then register and contribute to the community effort now by registering on the international CKM and make a change request or start a discussion thread.



The art of Clinical Lists

Keeping a clinical list up-to-date in a local EHR current is not a trivial task. Keeping it up-to-date and accurate in a shared environment – well… Read on. It is not easy.

The classic lists are:

  • Allergies/Adverse Reactions;
  • Problem/Diagnosis;
  • Medications;
  • Procedures; and
  • Family History.

At very least, in a shared environment we need common data models and curation, usually by a trusted physician in close consultation with the patient – technical and human factors. For example, the only person who *really* knows what medicines the patient is taking, is the patient themselves. Without the patient front and centre, involved and contributing, a true ‘current’ medicine list is impossible.

And so the data that underpins an accurate list is critical. I’ve already posted once about this – Unambiguous Data: Positive Presence, Positive Absence. The openEHR preferred approach is to record the positive presence of information AND the positive absence of information separately, using specific archetypes for each purpose.

If we use Adverse Reactions as a working example (which we will assume includes allergies, hypersensitivities and intolerances as well), we need to be able to be certain about each of the following types of data:

  • Following enquiry or investigation, we need the ability to record explicit and general statements about the the absence of any adverse reactions, allergies, hypersensitivities or intolerances in the patient’s history to date, using the EVALUATION.exclusion-adverse archetype. For example, “No known adverse reactions” which is only accurate and up-to-date at the exact time of recording. A split second after recording, it may be out-of-date as an adverse reaction to an administered medicine might occur immediately, thus rendering the statement obsolete and triggering recording of the patient’s first ever reaction to a medication. Generic exclusion statements should be reviewed regularly and this can be prompted by the ‘Last updated’ data element in each archetype. Some would argue that generic exclusions should only be recorded in event-based data (for example, as part of a consultation note) as it is only accurate at the time of recording, but it depends on how the persistent lists are managed in the clinical system.
  • Following enquiry or investigation, again, the ability to record explicit and specific statements about absence, using the same EVALUATION.exclusion-adverse archetype. For example, “No known adverse reaction to Penicillin”. As above, regarding accurate only at the time of recording. Again, specific exclusion statements should be reviewed regularly and this can be prompted by the ‘Last updated’ data element in each archetype. Some would argue that this should only be recorded in event-based data as it is only accurate at the time of recording, but it depends on how the persistent lists are managed in the clinical system. As above, some would argue that specific exclusions should also only be recorded in event-based data.
  • Following the occurrence of an adverse reaction from any physiological mechaism, the ability to record specific inclusion statements about the explicit knowledge that a reaction to a known medicine or class of medicines has occurred – no matter if minutes ago, years or decades. For example, a rash in response to administration of Penicillin, using the EVALUATION.adverse_reaction archetype – typically recording the name  or class of the medicine, substance or agent plus supporting details about the reaction manifestation.

Thus, three types of data:

  1. General exclusions
    • No past problems or diagnoses
    • No relevant surgical history
    • No significant family history
  2. Specific exclusions:
    • No history of diabetes
    • No previous appendicectomy
    • No family history of diabetes
  3. Inclusions
    • Diagnosis of diabetes mellitus type II
    • Appendicectomy, 1998
    • Family history of heart disease, epilepsy

Each of these kinds of information clearly needs to be recorded and persisted in an electronic health record as per each of the examples above. A clinical list may be updated automatically by the computer system where it is clinically absolutely safe to do so, but must be curated and updated by a clinician expert where in situations where clinical knowledge or discernment is required.

It could be argued that simple business rules in a standalone clinical system could ensure that in a new record for a new patient, and where no entries are stored regarding the presence or absence of any adverse reactions, that the system:

  • can reasonably infer no information is available;
  • should display some kind of clear message to the clinician that there is “no information available”, neither present or absent, about the patient’s adverse reaction status; and
  • prompt the clinician to record appropriate explicit statements of presence or absence during the next clinical consultation.

‘No information available’ is quite a different statement to previously noted assertion that there are “No known adverse reactions” which follows careful inquiry and evaluation by a clinician.

It is probably good practice that a new patient record in a clinical system should start with a default statement such as “No information about adverse reactions is available”, rather than just inferring that no information is available based on no recognised data entries about explicit presence or absence. This is therefore the fourth type of list that is relevant to persistent clinical lists

There is a ‘grey zone’ when information needs to be exchanged between systems or aggregated into a central system. To receive in a message an explicit statement that there is ‘no information about adverse reactions available’ enables the receiving system to understand the adverse reaction data situation unambiguously and reflect that in the receiving record appropriately. If no explicit information is sent in the message, the receiving system does not actually know if that reflects a true absence of data; a positive exclusion of data; or that there is an error in the message. The apparent absence of data for the clinician, no matter if not available or missed in error, will not change their clinical practice – they will still need to ask about adverse reactions prior to prescribing. If the patient can provide the information, then inappropriate medicine administration is averted, but if not, then there is a potential clinical safety risk to the patient.

Other arguments for explicitly stating that there is no known information occur in situations where the patient is not able to answer, for example if unconscious. Clinical management will still proceed, based on whatever information can be gleaned and with the clinicians needing to be prepared for anything! A slightly more complicated scenario ,which is medicolegally significant, occurs when an uncooperative patient, will benefit from the recording/exchange of ‘no information available’ as data plus the corresponding ‘reason for no information’. Similarly, other knowledge related activities, such as clinical decision support, will also benefit from explicit and consistent use of statements of inclusions/presence, exclusions and absence/no information.

Anatomy of Anatomical Location

Some time ago I intended to start blogging about clinical modelling insights and conundrums. It hasn’t happened for a while but, with recent reviews and publication of archetypes occurring as part of the openEHR Industry archetype sprint, we have started to make some clear progress.

Anatomical location seems pretty simple at first glance. In terms of scope though, it is huge and complex. In terms of use cases it is ginormous.

As a result of a number of reviews, the Anatomical Location archetype has recently been published – this means that the content is regarded as stable and fit for use in clinical systems. You can find the latest version here on the openEHR CKM.

In a mind map form, the archetype has the following data elements:


It’s intended use is described as:

Use to record structured and consistent details about a single identified physical site on, or within, the human body.
This archetype is specifically designed to be used within the context of any appropriate ENTRY or CLUSTER archetypes which supply the context of the anatomical location.
As a fundamental part of clinical practice, clinicians can describe anatomical locations in a myriad of complex and variable ways. In practice, some archetypes carry a single data element for carrying a simple description of body site – for example, OBSERVATION.blood_pressure and CLUSTER.symptom when describing ear pain. In this situation, where the value set is predictable and simple to define, this single data element is a very accurate and pragmatic way to record the site in the body and to query at a later date. However in the situation where the anatomical location is not well defined or needs to be determined at run-time, it may be more flexible to use this structured archetype. For example, in the situation where any symptom can be recorded without any predefined scope of the type of symptom, then allowing the use of this archetype to specifically define an anatomical location in the body may be useful. In this case the CLUSTER.symptom archetype also carries a SLOT for ‘Detailed anatomical location’ which can include this archetype to support maximal flexibility in recording anatomical location data.
This archetype supports recording complex structured anatomical sites. For example, the apex beat of the heart is typically found at the fifth left intercostal space in the mid-clavicular line, tenderness at McBurney’s point on the abdominal wall or a laceration on the palmar aspect of the proximal right thumb.
A combination of the data elements in this archetype can be used to individually record each component of a post-coordinated terminology expression that represents the anatomical site.
The ‘Alternative structure’ SLOT allows inclusion of additional archetypes that provide an alternative structure for describing the same body site, such as CLUSTER.anatomical_location_relative or CLUSTER.anatomical_location_clock, should this be required. In the situation where this archetype can only be used to name a large and/or non-specific body part, the additional use of the CLUSTER.anatomical_location_relative archetype will support recording of a more precise location – for example, 2 cm anterior to the cubital fossa of the left forearm or 4 cm below R costal margin on the chest wall in the mid-clavicular line.
If this archetype is used within other archetypes where the specified subject of care is not the individual for whom the record is being created, for example a fetus in-utero, then the anatomical location will be identifying a body site on or within the fetus.

This is a clinical specification identifying a single location on the body, and is never used stand-alone, but nested within other CLUSTER archetypes – for example: CLUSTER.exam_skin to define the area of skin that is being examined, or CLUSTER.symptom to define where the symptom was experienced.

You will also note that this archetype alone may not be enough. We have created the ‘Alternative structure’ SLOT in which other anatomical location archetypes can also be nested, allowing for description of relative anatomical location and also referencing a clock face, typically used to describe the position of haemorrhoids! We anticipate that other CLUSTER archetypes (yet to be developed) will be used for specific situations such as inside the mouth for describing locations for oral medicine/dentistry, where there are unique ways to describe anatomical structures.

I received a question by email recently asking about why we specifically excluded unilateral/bilateral occurrences of an anatomical feature. Remember that this archetype is recording ‘where it was’ not the number of occurrences of a something.

My answer:

An anatomical location for a clinical condition is not usually recorded bilateral (or both sides) in its own right.  For example, something might have bilateral occurrence AND be located in the cubital fossa but it will not be recorded in the health record as located in the “bilateral cubital fossae”.

When we talk we often have to qualify a statement made about a bilateral ‘something’ as it is not exactly the same on both sides, and we probably wouldn’t record it as we say it, but record the subtleties of each side separately.

Do they bilateral anatomical sites or body locations exist? Yes, there are 42 results when searching for ‘bilateral’ in SNOMED CT body structures – bilateral lens, bilateral ears, bilateral eyes, bilateral breasts etc. But do clinicians refer to a lesion in the bilateral lens, ears, eyes or breasts – not in my experience!

Similarly, there are 136 results when searching for ‘both’ in SNOMED CT body structures – both legs, both eyes, both ears, both feet etc. We are still not likely to refer to a lesion in both breasts, rather describe each lesion in separate locations within one breast and then separately describe them in the other breast.

A rash could be on left & right (i.e. both) wrists. We may talk about a bilateral rash on the wrist but this is not usually recorded in data as a rash on ‘bilateral wrists’, rather a rash with a common morphology present to ‘x’ extent on the right wrist and to ‘y’ extent on the left wrist! In a similar way,  recording the rash observed on both wrists, shoulders, elbows and ankles really needs the ability to record each site and extent specifically.

An injury to the ankles might be bilateral but the site of the injury will not usually be recorded as “bilateral ankles” – the injuries on each ankle need to be described individually as the location might be lateral ligament on one and medial on the other. And further, even if it were lateral ligament damage for both, it would be weird to describe the location as bilateral lateral ligament of the ankle or, worse, lateral ligaments of bilateral ankles.

This reasoning is why ‘bilateral’ is specifically excluded from anatomical location and the scope of the archetype is restricted to a single site in a single archetype instance.

Most commonly when we use the term bilateral, we refer to bilateral conditions – for example “bilateral hemiplegia, worse on the right”. A diagnosis. This could be the diagnosis value recorded against the ‘Diagnosis name’ data element in the Problem/Diagnosis archetype but the more accurate recording will again be Hemiplegia on the left has ‘x’ attributes and Hemiplegia on the right side of the body has ‘y’ attributes. They occur as a result of different events and the effect on the body will not be mirrored.

Hearing problems could be experienced in both ears – the value set for the ‘Ear examined’ could be left ear, right ear and both ears, but again, I’m not convinced that this is good history taking. However, testing for hearing may validly have the value sets for ‘ear examined’ as left ear, right ear and bilateral as this reflects how the test was conducted  – specifically where the earphone or headset would be delivering the stimulus. Bilateral testing in a sound field is common in young kids and as a consequence the results for each ear cannot be differentiated  – a valid use for bilateral, even bilateral ears, although ears is somewhat redundant under the circumstances.


It is not simple. We need to carefully identify where we need to record ‘bilateral’ and ensure that this is accurate.