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.

Making sense of ‘Severity’

‘Severity’ is a pretty simple clinical concept, isn’t it?

I thought so too until I first sat down to create a single, re-usable archetype to represent ‘Severity’. I soon discovered that I had significantly underestimated it – the challenge was greater than appeared at first glance.

The archetype development process is usually relatively straight forward – a brain dump of all related information into a mind map, followed by rearranging the mind map until sensible patterns emerge. They usually do, but not this time.

However, the more I investigated and researched, the more I could see that clinicians express severity in a variety of ways, sometimes mixing and ‘munging’ various concepts together in such a way that humans can easily make sense of it, but it is much harder to represent in a way that is both clinically sensible and computable.

The simple trio of ‘Mild’, ‘Moderate’ and ‘Severe’ is commonly used as a gradation to express the severity of a condition, injury or adverse event. Occasionally these are defined for a given condition or injury, however most often these are subjective and there should be concern that one clinician’s mild might be another’s moderate. Some also include intermediate terms, such as ‘Mild-to-moderate’ and ‘Moderate-to-severe’, but one has to begin to be concerned if these more subtle differences make the judgement even more unreliable, especially if we need to exchange information between systems.

Others add ‘Trivial’ – is this less than ‘Mild’? By how much? Is there a true gradation here? And what of ‘Extreme’? Still others add ‘Life-threatening’ and ‘Death’ – but are these really expressing severity? Or are they expressing clinical impact or even an outcome?

When exploring severity I found examples of severity expressed by clinicians in many ways. This list is by no means exhaustive:

• Pain – expressed as intensity, often including a visual analogue scale as a means to record it ie rate from 0-10
• Burns – describing percentage of body involved e.g. >80% burns
• Burns – describing the depth of burn by degree e.g. first degree
• Perineal tears – describe the extent and damage by degree – e.g. second degree tear
• Facial tic – expressed in using frequency e.g. occasional through to unrelenting
• Cancer – expressed as a grade, clinical or pathological
• Rash – extent or percentage of a limb or torso covered.
• Minor or major
• Mild, disabling life-threatening
• Relative severity – better, worse etc
• Functional impact – ordinary activity, slight limitation, marked limitation, inability to perform any physical activity
• Short or long term persistence
• Acute or chronic

In practice, clinicians can work interchangeably with any of these expressions and make reasonable clinical sense of it. The challenge when creating archetypes, and other computable models, is to ensure that clinicians can express what they need in a health record, exchange that information safely with other clinicians, allow for knowledge-based activities such as decision support.

In addition, there also needs to be a clear distinction between ‘severity’ and other, related qualifiers that provide additional context about ‘seriousness’ of the condition, injury or adverse reaction. These sometimes get thrown into the mix as well, including:

• Clinical impact (or significance);
• Clinical treatment required; and
• Outcomes.

Clinical impact/significance might include:

• None – No clinical effect observed
• Insignificant – Little noticeable clinical effect observed.
• Significant – Obvious clinical effect observed
• Life-threatening – Life-threatening effect observed
• Death – Individual died.

Immediate clinical treatment required might include:

• No treatment
• Required clinician consultation
• Required hospitalisation
• Required Intensive Care Unit

Outcomes might include:

• Recovered/resolved
• Recovering/resolving
• Not recovered/resolved
• Fatal

Then there are those that recovered or the condition resolved but there were other sequelae such as congenital anomalies in an unborn child…

Severity ain’t simple.

Over time, and repeatedly returning to it when modelling it in various archetypes including Adverse Reaction and Problem/Diagnosis, I’ve come to the conclusion that I don’t think it is useful or helpful for us to model ‘severity’ in a single, re-usable archetype. It seems to work better as a single qualifier element within archetypes – then we can bind it in to terminology value sets that are useful for that specific archetype concept and for the use-case context.

When a clinical knowledge pattern is easily identified, creating an archetype is easy – the archetype almost writes itself! So over time I’ve learned not to try to force the modelling. Some archetypes ‘work’; some, like this one, just don’t.