The unknown substance conundrum…

Is it safe and sensible to record that a patient has had an adverse/allergic reaction to an unknown substance?

This is a question that is causing quite a stir in the HL7 Patient Care email list and I have no doubt that it will be a hot topic in the current FHIR/openEHR Adverse Reaction archetype review. Some are advocating to record a reaction without offering a possible causal substance.

I think we can all agree that it makes absolute sense to record the DIAGNOSIS of an obviously <allergic manifestation> (eg urticaria) to an unknown substance as “<allergic manifestation> of unknown origin”. I think most can comfortably agree with that statement.

Now for the controversial bit…

However while a patient can have a reaction to an unknown substance, I will assert that it does NOT make sense to record an ADVERSE REACTION manifestation to an unidentified substance. I am certainly not denying that a clinician who observes a rash that is clearly of allergic origin, such as an urticaria, will absolutely be thinking in terms of ‘this is clearly of allergic origin and I must investigate further to identify the substance’. This is clearly good clinical practice. However, as clinicians, I am suggesting that sometimes we need to differentiate between what we observe or think from what we might record in a health record at the same given point in time .

In all my years of clinical practice, I cannot remember any paper record where I have ever seen ‘urticaria’ or ‘anaphylaxis’ entered into the Allergy List without a proposed substance being associated. I can see absolutely no reason why we should start doing this for electronic health records.

Both the substance and the manifestation are required to enable a clinician to avoid future exposures in future clinical care. That is the logic behind the existence of the ubiquitous Adverse Reaction or Allergy List.

Until one or more causal substances is postulated and/or confirmed, an isolated clinical manifestation of urticaria or anaphylaxis is, in reality, just a simple (maybe allergy-related) sign, symptom or diagnosis of unknown cause. The act of recording a reaction to ‘nothing’ or ‘unknown substance’ adds no absolutely no value to the Adverse Reaction or Allergy List as it cannot trigger any decision support by a clinical system.

I think I can also safely assert that all clinicians ideally want to be able to prevent a future reaction for their patient, especially in the situation where the substance may not be identifiable at the time of the reaction. This is a key clinical activity that we need to be able to record clearly in EHRs – we cannot afford for an identified allergic reaction to be ‘lost’ in the health record before we can identify the substance.

To that end, the HL7 Patient Care approach has been to record a Reaction Event in the absence of a Substance, while the openEHR approach has been to record the manifestation as part of the health record – symptoms, signs, test results, diagnosis etc, of unknown origin. However for both, a clear imperative is that the clinician can able to flag that this patient has an unresolved puzzle: that there has been a known allergic reaction that may cause future harm if the cause is not identified.

So collectively we need to determine a way for this outstanding health puzzle to be tracked and not lost in the depths of a long ago consultation note. This aligns with the design of Lawrence Weed’s Problem Oriented Medical Records (POMR). In HL7, this approach is captured in their concept of ‘Concern Tracker’, and in the draft Contsys standard (ISO 13940) it is known as a ‘Health Issue Thread’. openEHR needs to develop EVALUATION archetype/s that will support this abstract concepts and support the POMR approach.

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 heather.leslie@oceaninformatics.com

Let the harmonisation begin!

 

 

 

Archetype Re-use

Last Thursday & Friday @hughleslie and I presented a two day training course on openEHR clinical modelling. Introductory training typically starts with a day to provide an overview – the “what, why, how” about openEHR, a demo of the clinical modelling methodology and tooling, followed by setting the context about where and how it is being used around the world. Day Two is usually aimed at putting away the theoretical powerpoints and getting everyone involved – hands on modelling.

At the end of Day One I asked the trainees to select something they will need to model in coming months and set it as our challenge for the next day. We talked about the possibility health or discharge summaries – that’s pretty easy as we largely have the quite mature content for these and other continuity of care documents. What they actually sent through was an Antineoplastic Drug Administration Checklist, a Chemotherapy Ambulatory Care Nursing Intervention and Antineoplastic Drug Patient Assessment Tool! Sounded rather daunting! Although all very relevant to this group and the content they will have to create for the new oncology EHR they are building.

Perusing the Drug Checklist ifrst – it was easily apparent it going to need template comprising mostly ACTION archetypes but it meant starting with some fairly advanced modelling which wasn’t the intent as an initial learning exercise.. The Patient Assessment Tool, primarily a checklist, had its own tricky issues about what to persist sensibly in an EHR. So we decided to leave these two for Day Three or Four or..!

So our practical modelling task was to represent the Chemotherapy Ambulatory Care Nursing Intervention form. The form had been sourced from another hospital as an example of an existing form and the initial part of the analysis involved working out the intent of the form .

What I’ve found over years is that we as human beings are very forgiving when it comes to filling out forms – no matter how bad they are, clinical staff still endeavour to fill them out as best they can, and usually do a pretty amazing job. How successful this is from a data point of view, is a matter for further debate and investigation, I guess. There is no doubt we have to do a better job when we try to represent these forms in electronic format.

We also discussed that this modelling and design process was an opportunity to streamline and refine workflow and records rather than perpetuating outmoded or inappropriate or plain wrong ways of doing things.

So, an outline of the openEHR modelling methodology as we used it:

  1. Mind map the domain – identify the scope and level of detail required for modelling (in this case, representing just one paper form)
  2. Identify:
    1. existing archetypes ready for re-use;
    2. existing archetypes requiring modification or specialisation; and
    3. new archetypes needing development
  3. Specialise existing archetypes – in this case COMPOSITION.encounter to COMPOSITION.encounter-chemo with the addition of the Protocol/Cycle/Day of Cycle to the context
  4. Modify existing archetypes – in this case we identified a new requirement for a SLOT to contain CTCAE archetypes (identical to the SLOT added to the EVALUATION.problem_diagnosis archetype for the same purpose). Now in a formal operational sense, we should specialise (and thus validly extend) the archetype for our local use, and submit a request to the governing body for our additional requirements to be added to the governed archetype as a backwards compatible revision.
  5. Build new archetypes – in this case, an OBSERVATION for recording the state of the inserted intravenous access device. Don’t take too much notice of the content – we didn’t nail this content as correct by any means, but it was enough for use as an exercise to understand how to transfer our collective mind map thoughts directly to the Archetype Editor.
  6. Build the template.

So by the end of the second day, the trainee modellers had worked through a real-life use-case including extended discussions about how to approach and analyse the data, and with their own hands were using the clinical modelling tooling to modify the existing, and create new, archetypes to suit their specific clinical purpose.

What surprised me, even after all this time and experience, was that even in a relatively ‘new’ domain, we already had the bulk of the archetypes defined and available in the NEHTA CKM. It just underlines the fact that standardised and clinically verified core clinical content can be re-used effectively time and time again in multiple clinical contexts.The only area in our modelling that was missing, in terms of content, was how to represent the nurses assessment of the IV device before administering chemo and that was not oncology specific but will be a universal nursing activity in any specialty or domain.

So what were we able to re-use from the NEHTA CKM?

…and now that we have a use-case we could consider requesting adding the following from the openEHR CKM to the NEHTA instance:

And the major benefit from this methodology is that each archetype is freely available for use and re-use from a tightly governed library of models. This openEHR approach has been designed to specifically counter the traditional EHR development of locked-in, proprietary vendor data. An example of this problem is well explained in a timely and recent blog – The Stockholm Syndrome and EMRs! It is well worth a read. Increasingly, although not so obvious in the US, there is an increasing momentum and shift towards approaches that avoid health data lock-in and instead enable health information to be preserved, exchanged, aggregated, integrated and analysed in an open and non-proprietary format – this is liquid data; data that can flow.