Therapeutic Precautions are the ‘new black’!

Clinical modelling around the concepts of warnings, alerts and notifications is incredibly complex and each of the terms are loaded with confusion. It is not going to be easy to navigate this area and achieve a common understanding that will underpin information models for sensible and cross paradigm decision support.

I’ve talked extensively with Rikard Lovstrom (@rikardlovstrom) and I like his ideas about standardising alert notifications in clinical systems but he hasn’t been able to get traction in ISO to take this further.

Sam Heard (@samheardoi) and I also had some robust discussions about this area back in 2012 and I wrote up an early version of our conversation at that time. I’ve just been sharing it with Lloyd McKenzie, relating to potentially aligning some of the openEHR archetypes and FHIR resources, so decided to tidy it up a little and post it, below, for others to comment.

This document is not attempting to be a final solution by any means – consider it an work in progress – but could be a pragmatic basis for standardising the decision support needs around alerts, precautions, contraindications, notifications etc in clinical systems.

You will also note that I have deliberately avoided naming models as ‘warnings’ or ‘alerts’ because the widespread use within the community causes significant confusion. We need a neutral term that embraces these terms, hence the proposal for Therapeutic Precautions – this is a term that clinicians will understand! However systems could potentially implement these models and call them by whatever name they need.


Assumption: the fundamental data representations that will underpin any decision support ecosystem in an Electronic Health Record system will include:

  • Existing Templates:
    • Adverse Reaction List (curated; persistent; versioned) – containing EVALUATION.adverse_reaction archetypes
    • Current Medication List (curated and/or automatic; persistent; versioned) – containing INSTRUCTION.medication, and potentially some ACTION.medication, archetypes
    • Current Problem List (curated and/or automatic; persistent;versioned)
      • Problems/Diagnoses – containing EVALUATION.problem_diagnosis archetypes
      • Past Procedures performed – containing ACTION.procedure archetypes
  • New Templates:
    • Therapeutic Precautions (curated; persistent; versioned)
    • Nota Bene (curated and/or automatic; persistent; versioned)
    • ?Preferences/Directives (curated and/or automatic; persistent; versioned)

Therapeutic Precautions Template

A persistent Therapeutic Precautions COMPOSITION will contain archetypes that are deemed by the clinicians to warrant highlighted representation in the EHR and will provide the basis for visually informing clinicians of issues of therapeutic importance for consideration when providing direct clinical care and to support automated clinical decision support, especially when initiating clinical management such as ordering medication, vaccinations, or diagnostic tests. The contents of this COMPOSITION will be unique for every individual and their purpose is to flag personalised health-related issues for each individual patient. Archetypes within the Therapeutic Precautions COMPOSITIONS are effectively a type of personalised “clinical or therapeutic alert”.

Potential ENTRY archetypes are allowed to be included in a Therapeutic Precautions COMPOSITION might include, but are not limited to:

  • EVALUATION for Pregnancy and Breastfeeding status
  • EVALUATION.precaution – these archetypes identify conditions or states of the patient that are clinically significant and unique or idiosyncratic for this patient. (Precautions such as administration of a live vaccine in a woman who is pregnant is not appropriate for recording as a Precaution as this is a general rule applicable for all pregnant women.)
    Precautions are evaluative/summary statements; not a diagnosis or a test result. Each precaution can be optionally linked to a diagnosis, test result or medication order that is evidence/rationale for the precaution. Precautions such as administration of a live vaccine in a woman who is pregnant is not appropriate for recording as a Precaution as this is a general rule applicable for all pregnant women and should be flagged by a generic knowledge base if the pregnancy status is known. For example:

    • ?Immunosuppressed/On immunosuppressive therapy – linked to medication order for chemo or steroids; or diagnosis of leukaemia
    • Renal insufficiency – linked to renal function tests and/or diagnosis of Renal Failure.
    • Failed procedure – where the clinician deems it inappropriate to repeat it
    • ?Family member is immunosuppressed – so might reconsider administration of a live vaccine to the subject.
  • EVALUATION.contraindication – these archetypes represent absolute contraindications for management and have been identified by a clinician. The name of the contraindication is the name of a medication or a treatment or procedure, which is not represented in the Adverse Reaction list, Problem List or Medication List. For example:
    • Medication administration – identified by means other than adverse reactions, such as genetic testing eg never administer Drug X because they have gene sequence Y.
    • Procedure – such as performing a MRI in the presence of a pacemaker. Rather than relying on the coding of a Pacemaker insertion being recognized in a Problem List, this explicit contraindication can be an explicit expression of what a clinician has recognized should not be performed. Decision Support systems would need to know to look for this kind of information within this model.
    • Live vaccine – if on immunosuppressant medication. Note: need to set a review date for this contraindication when the patient is no longer likely to be on immunosuppressant medication
  • Archetypes for Patient Preferences/Directives – Directives are formally attested; Preferences are not formally attested. Most of these are clinical; but some, like preferred place of care are not andaremorelikelyto be recorded as ‘nota bene’ – consider whether Preference/Directives may need its own COMPOSITION.
    • Blood transfusion
    • Tube feeding
    • CPR Status
    • Intubation Status
    • Antibiotic Status
    • Near death preferences
    • Natural death preference
    • Palliative care preferences

Nota Bene Template

A persistent Nota Bene Template contains archetypes that are deemed important for consideration when making administrative and other non-direct care-related decisions about a patient. Archetypes within the Nota Bene COMPOSITION are effectively a type of personalised “administration alert” or precaution.

  • Legal Constraints. For example, custodial orders or mental health orders.
  • ADMIN_ENTRY.nota_bene – these archetypes represent data that is of use to the clinicians and healthcare providers but does not include information that might inform direct care decision-making. NotaBene are effectively “administrative alerts”. For example:
    • Patient requires infection precautions (eg if MRSA/VRE/HepC positive or in isolation for infectious/outbreak reasons)
    • Patient has a vicious dog in the front yard – beware for home visits
    • Patient has violent partner
    • Patient has been violent in past
    • Patient requires chaperone
  • Patient Preferences/Directives – Directives are formally attested; Preferences are not formally attested.
    • Preferred place of care

Inaugural joint archetype review by HL7 & openEHR!

We have movement. We have willingness to try. We have a draft FHIR archetype for Adverse Reaction uploaded onto the openEHR CKM that is undergoing some final preparation before being sent out for joint review by the international openEHR and HL7 communities, hopefully as early as next week.

After calling for some collaboration on modelling between HL7’s FHIR and openEHR archetypes (Stop the #healthIT ‘religious’ wars and Technical/Wire…Human/Content) we have taken some preliminary steps towards exploring if agreement about the clinical content across these two modelling paradigms is possible.

The intended outcome of this will be agreed content that will inform the FHIR Resource/s and a published openEHR archetype. Even if the information models are represented differently there should be a clear mapping possible between the two approaches. This will be a first.

The self-appointed (mainly because we all volunteered or were conscripted) Editorial team consists of:

  • Grahame Grieve (Australia), one of the primary authors of the FHIR specifications;
  • Russ Leftwich (USA), an internist and immunologist who is a co-chair of the HL7 Patient Care Working Group;
  • Ian McNicoll (UK), a clinician and informatician who is a board member of openEHR and co-leading the international CKM Editorial work; and
  • myself (again from Australia).

Our preparation has required consolidating components from the openEHR archetype, the existing FHIR allergy/intolerance models and the HL7 DAM. The archetype you see now on CKM is the immediate result of that process, and over the next few months we intend to conduct a number of public review rounds that will enable anyone/all to provide feedback on the proposed model.

Grahame will inform and invite the HL7 community formally via lists, explaining the process and mappings between the HL7 models and the current archetype. Similarly when the review is ready to be released, there will be similar communications on the openEHR website.

In the meantime, if you are interested in participating there are two ways of registering your interest:

  1. If you have NEVER registered on the openEHR CKM before:
    Please register in the Adverse Reaction Project on CKM. This link will walk you through the Registration wizard and automatically add you as a member of the Project.As soon as the archetype is released for review, you will receive an email invitation that will take you connect you directly to the review process.
  2. If you are ALREADY A REGISTERED USER on the openEHR CKM:
    Please log in to the openEHR CKM and open the Adverse Reaction (FHIR/openEHR) archetype. We need you to clinical on the ‘Adopt Archetype’ button as shown in Step #2 in the diagram below. This will register you as willing to review the archetype and as soon as the archetype is released for review, you will receive an email invitation that will take you connect you directly to the review process.
    Adopt an archetype

None of us are quite sure how this will play out but I’m hopeful that we might look back on this review as a watershed moment in clinical content specification development. It will possibly inform how future harmonisation across a number of clinical modelling approaches might proceed, including broader HL7 efforts and CIMI.

Anyone who is interested to participate is welcome. If you have any problems with registering please email me directly on

Let the harmonisation begin!




#Uncomplexication of Clinical Infostructure

Don’t tie yourself up in knots about the title. There was a story behind it, and it was more interesting than ‘an overview of clinical modelling’. No matter, the content is what matters!

The presentation was delivered today to the Arctic Conference on Dual-Model based Clinical Decision Support & Knowledge Management. The only downside was that the conference was in Tromsø, Norway and I was safely at home in Melbourne.

My task: to present an overview of modelling, current status and lessons learned.

The presentation turned into a bit of a rambling story of my engagement with clinical modelling and experiences with archetypes over the last decade. I was lucky enough to be there at the beginning of the first serious archetype-building activity in the UK in 2007, and to participate in the subsequent evolution of the openEHR modeling community and methodology – now over 1100 people from 80+ countries!. So this presentation is a bit of a ramble down memory lane as well as providing a bit of a summary of how we got here, where we are and what can we see coming?

In particular, I can now safely say that while at times I was ready to jump ship and use the life buoy pictured in the presentation, that is no longer the case.