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.

Background

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

Anatomy of a Problem… a Diagnosis…

Problem or Diagnosis? Does it really matter?

Representation of the concept of a Problem or Diagnosis is a cornerstone of an electronic health record. Yet to date it seems to have been harder than expected to achieve consensus. Why is this so?

When I first started talking to my colleagues about collaboration on archetypes to specify Problem or Diagnosis in EHRs, one told me that arguments about the difference between a problem, diagnosis, issue, concern etc have been raging within some standards committees for many years and they hadn’t been able to achieve significant consensus. This was a little worrying. Yet on further inquiry it appears that they were stuck largely on the name and differentiation of problem from diagnoses – what was the difference between them? When to use each one in a clinical scenario?  And then what about an ‘issue’ or ‘health concern’? Seems like everyone had slightly different ideas. I can easily see how this can be – every clinician is likely to have a slightly different way to classify problems or diagnoses, which doesn’t impact upon clinical care at all.  So the key question here is… Does it really matter?

What do we need to achieve?

We need to ensure that :

• clinicians can clearly record issues and problems and diagnoses in an EHR;
• clinicians can safely exchange information this information with other colleagues or into a shared health record environment;
• clinicians can create Problem Lists to support their specific domain and style of care; and
• decision support systems can safely utilise this information.

In the initial development of these archetypes the authors created a Problem archetype and specialised it for Diagnoses by adding additional attributes. This was the accepted approach for many years in the international openEHR arena. In recent months there has been a series of collaborative reviews in Australia and the outcome has been to merge the two archetypes into a single Problem/Diagnosis archetype. This appears to be a sensible and pragmatic decision which has allowed the collaboration to move forward.

You can judge for yourself. The latest iteration of this Problem/Diagnosis model has included feedback from more than 40 clinicians, informaticians and other experts from 10 countries.

Drawing from this collaborative and collective work on the Problem/Diagnosis archetype:

Definition:

A problem or diagnosis is “any health care condition which may impact on the physical, mental and/or social well-being of an individual, that may require diagnostic, therapeutic or educational action, and which has been determined by a clinician. A diagnosis is based on scientific evaluation of physical signs, symptoms, history, laboratory tests results, and procedures”.

[Please note: ‘Issue’ has not yet been addressed in these discussions, but may be useful for recording consumer-entered information into the PHR environment, and perhaps could be ‘promoted’ to Problems or Diagnoses after evaluation of a clinician.  In addition, the concept of a ‘Health Concern’ seems to be gaining broad international acceptance as an abstract organising concept used within Problem-Oriented Medical Record (POMR) approaches.]

Purpose and Use:

To record details about a problem or diagnosis by a clinician. There are many uses including: recording a Diagnosis during an Encounter; populating a Problem List or a Summary Statement, such as a Discharge Summary.

Thus the intended use for this model is by healthcare professionals only, and as a conclusion to a process of history taking, examination and investigation. The general feeling has been that consumer-entered information should be structured in a similar way be but be unambiguously differentiated from a clinician-entered problem or diagnosis.

The scope of the model, as always, reflects the commonest use-case requirements – a pragmatic decision in effect. It is well understood that some clinicians or diagnoses may require much more structured data and SLOTs that are identified in the model, in which other archetypes can be inserted if additional detail is required.

Model:

The complete model can be viewed and downloaded from the Clinical Knowledge Manager.

Learnings:

Some of the things we’ve learned, considered, teased out… along the way:

• The single archetype was created because:
• It appeared that consensus on an agreed definitions of problem and diagnosis was unlikely to be achieved, especially in such a way that multiple clinicians could consistently and definitively categorise health issues as either one or the other. It was suggested that in practice there was probably little value in forcing this issue to be resolved and that in clinical practice there is effectively a continuum between ‘problems’ at one end and ‘diagnoses’ at the other. Individual clinicians may place the same health issue at slightly different places on the continuum – closer to one end or the other – but in effect this did not matter, so long as there was an agreed specification for representation in an EHR.
• It was recognised that both have common recording requirements, with optional additional information available to support formal diagnoses, such as diagnostic criteria and statements about clinical staging.

• The representation of the name of the problem or diagnosis should be coded from a terminology, wherever possible – most will agree with this. However considerable thought needs to be given to sensible implementation by providing clinicians with meaningful code sets appropriate to their clinical domain and context of the consultation.
• ‘Severity’ has been very contentious yet again. Making sense of Severity and Anatomy of an Adverse Reaction both outline some of the common issues around clinical use of severity.
• ‘Age at onset’ is occasionally required in addition to ‘Date of onset’ for clinical decision support systems where the infant is less than one year old and approximations of age based on calculations are not sufficiently accurate. This also applies for Date and Age of resolution/remission.
• ‘Related items’ consists of a cluster of attributes that represent causality and sequence of events – that a problem or diagnosis was ’caused by’ or ‘follows’ a related problem, diagnosis, procedure or event.
• Links have been explicitly modeled in this archetype to specific occurrences, presentations, symptoms, findings or supporting clinical evidence stored elsewhere in the health record.
• A ‘Status’ slot has been created as an approach to resolve the tension between the need to record context-or use-case specific labels or workflow-related aspects of the diagnostic process. Examples include active/inactive, primary/secondary, and preliminary/provisional/working/final. There was a lot of discussion about the merit of modelling these within the core archetype itself, but there was concern expressed that inclusion of labels or statuses that are only relevant to a particular use-case, context or process stage might be confusing or even a safety issue if data including this information was inadvertently exchanged or shared outside the original authoring environment. As a result, the core archetype reflects information that can be exchanged or persisted in a shared environment without any of these contextual or process-related qualifiers included, unless it is deemed that it is safe and reasonable to do so, and in this case the additional ‘Status’ archetype can also be exchanged or persisted.

Anatomy of an Adverse Reaction

Discussion about how to represent some of the commonest clinical concepts in an electronic health record or message has been raging for years. There has been no clear consensus. One of those tricky ones – so ubiquitous that everyone wants to have an opinion – is how to create a computable specification for an adverse reaction.

In the past few years I have been involved in much research and many discussions with colleagues around the world about how to represent an adverse reaction in a detailed clinical model. I’d like to share some of these learnings…

The latest iteration of this Adverse Reaction model has included feedback from more than 40 clinicians, informaticians and other experts from 8 countries.

Drawing from this collaborative and collective work:

Definition:

An adverse reaction is “a harmful or undesirable effect associated with exposure to any substance or agent, including food, plants, animals, venom from animal stings or a medication at therapeutic or sub-therapeutic doses”.

Scope:

“To record information about any adverse reaction, including:

• immune mediated reactions Types I-IV (including allergic reactions and hypersensitivities), and
• non-immune mediated reactions (including pseudoallergic reactions, side effects, intolerances, drug toxicities (eg Gentamycin), drug-drug interactions, food-drug interactions, drug-disease interactions and idiosyncratic reactions).”

As a result we have created one model for all types of adverse reactions, including allergic reactions, intolerances or side effects.

The scope of the model reflects the commonest use-case requirements – a pragmatic decision. It is well understood that others, including immunologists, will require much more structured data for their assessment and imputation activities. Similarly formal reporting to jurisdictions may require more structured data. Further detailed models designed for these purposes can be nested in the SLOTs that are identified in the model, below.

Intent:

“Use to provide a single place within the health record to record a range of clinical statements about adverse reactions, including:

• Record cumulative information about each exposure to a known substance, class of substance or agent; and
• Record a clinician’s opinion that administration of, or exposure to, a substance or agent is absolutely contraindicated.”

It will record information about adverse reaction that can be both stored in the EHR and be exchanged with other systems, including as one component of a multi-faceted Adverse Reaction Report sent to statutory authorities.

Model:

Learnings:

Some of the things we’ve learned along the way:

• There is a need to represent multiple reaction events per adverse reaction substance.
• There is a need to represent a generic substance or class of substance PLUS specific substances on a per exposure basis. For example the class of penicillins AND exposure to amoxycillin and/or phenoxymethylpenicillin.
• Severity has been very contentious. Making sense of Severity outlines some of the common issues around clinical use of severity. The specific issues about use of ‘Severity’ in the context of Adverse reaction follow:
  • In discussion with clinicians we have had a lot of pushback about attributing a consistent way of describing ‘severity’ to the ‘reaction event’, and in fact, whether it added any value at all. As a result we removed it from the model. Other qualitative descriptors have been considered including clinical impact on the patient etc but there has been no consensus. Our approach is to continue deliberations on these and add them as a part of a revision in the future if necessary.
  • More importantly, we concluded that it is a serious safety risk to attribute a ‘Severity’ to the ‘adverse reaction’ itself. What does a ‘severe adverse reaction’ actually mean? If we are trying to describe the propensity or risk of a reaction if the person is exposed to the substance or agent next time then we are attempting to predict the future a la ‘crystal ball gazing’. We cannot reasonably predict a risk of reaction being mild or moderate. A mild reaction this time does not imply a mild reaction next time and cannot preclude the potential for anaphylaxis at next exposure. Persisting this ‘guess’ in the record can potentially dangerously influence future clinical decision-making. However, conversely, some reactions observed can indicate that the next exposure are potentially catastrophic eg anaphylaxis.
    Our premise is that by adding an adverse reaction entry to an EHR the clinician is effectively flagging a relative contraindication. We have not (based on clinician feedback) included a ‘Severity’ of either the adverse reaction itself or the reaction event. We have included a flag for a clinician to mark only as true if they regard that there is an absolute contraindication (ie unacceptable risk for deliberate future exposure) for that substance/agent.
• ‘Manifestation’ has been included specifically to allow recording of ‘the clinical manifestation of the adverse reaction expressed as a single word, phrase or brief description, e.g. nausea or rash’.
• Based on some UK NHS CUI guidelines, it would seem reasonable that first line information available for a clinician in a system will include the same of the substance/agent, the manifestations at each reaction event, source of information. We are suggesting adding the absolute contraindication flag. No mention of severity. Second line information will include the other information in the model, plus potential links to the specific reaction events recorded elsewhere in the record, if available.