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‘).

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.

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 challenge for FHIR: meeting real world clinician requirements

Having just participated in the Melbourne FHIR Clinical Connect-a-thon, I’ve come away with lots of food for thought. My impression is that the ability for clinicians to influence the FHIR process will be limited to those in the Connect-a-thon room and additional engagement via email lists and teleconferences, technical artefact review, and a rigid balloting process – this will be challenging.

Ultimately, the interoperability problem that we (including FHIR) need to solve is no longer primarily a technical one, but one that is socio-technical: with the imperative that it is driven by the clinicians from now on, rather than the techies/engineers.

A couple of the major points here, others will no doubt come later:

• there is a big gap between the mostly generic FHIR resources currently under development and the full scope of clinical data needed by us clinicians, even if only for FHIR’s messaging priority. This can be considered in terms of
  • the sheer number of resources required to cover detailed and specific content for broad clinical coverage of general medicine and specialties cf generic resources such as Observation and Condition;
  • granularity and level of detail of resources;
  • re-use of resources; and
  • the focus on data that is currently in use in existing systems, rather than establishing the data specifications that clinicians want and need in state-of-the-art clinical systems – in effect a roadmap for the existing systems to work towards.
• the design of the current FHIR resources for use in messages vs the possibly/maybe increasing expectations of the FHIR community to use FHIR as the basis for electronic health records and data persistence; and
• the reliance on extensions will produce huge pockets of non-interoperability unless these are governed in the same way as formal FHIR resources, which rather defeats the purpose of local extensions.

The rather extensive image below is a real life example of an openEHR archetype/template specification, based for clinician-identified requirements, that is currently undergoing implementation in a new clinical information system. Some components of this template will also be used for reporting and in messages, so this level of detailed content will need to be considered for real world FHIR implementations as well.

Others may disagree, but I think that FHIR will eventually need to be able to recreate this kind of real world content as specified and agreed by the clinicians themselves…

In this image, keep in mind that the black data elements are active; the greyed out data elements are inactive, ie not required by the clinician for this clinical scenario. But still the sheer number of archetypes that are required to cover the number of clinical concepts that need to be used for a teleotology assessment by a remote ENT surgeon are surprisingly large.

To try to represent the range and level of detail for this clinical purpose by assembling current FHIR resources such as Condition or Observation and making them fit for the clinical purpose will render modellers into a world of pain. And, of course, the risk is that each assembly of the name/value pairs in Observation will be done differently by each modeller, resulting in non-interoperability after all. The resources will need to be governed, including local extensions.

With the increasing burden of technical engagement resulting from the incredible expectations generated by FHIR globally, perhaps the clinical content specification should be outsourced to… the clinicians first of all, ensuring that the clinical content can be represented in a technical format for implementation.

It makes good sense to explore how we can leverage the existing openEHR archetypes and the clinician engagement/asset governance processes in CKM as seamlessly as possible to streamline the FHIR resource development and provide a forward path to interoperability. The potential value of transformations from archetypes directly to FHIR resources could solve a number of the issues I raise above…

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