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.