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.

6 thoughts on “Anatomy of a Problem… a Diagnosis…

  1. Pingback: ICMCC News Page » Anatomy of a Problem… a Diagnosis…

  2. I think that a ‘problem’ is something that occurs in a patient requiring attention – according to either or both of the patient and physician. To be debated endlessly. But the most practical meaning of ‘diagnosis’ it seems to me is ‘identification of a problem such that decision(s) regarding intervention can be undertaken’. In other words, it involves a) the physician doing sufficient work to nail down what the problem is so that s/he can pursue a course of action, and b) noting this down, so that it is known from then on that the usual course of action for that diagnosis could in fact be commenced.

    We can further assume that a ‘diagnosis’ has to be taken from a set of currently recognised diagnoses. If not, then ‘diagnosis’ as an activity cannot complete, and no ‘diagnosis’ (noun) can be recorded. In essence, a diagnosis by this reasoning says: ‘now it’s official, the problem is X!’

    • And therin lies the nub of the problem – there are so many points of view about the difference between problem and diagnosis, indeed to be debated endlessly, and the ultimate question is whether it really matter in clinical practice or an EHR.
      There are certainly many clinicians and scenarios where ‘problems’ require a course of action, so this can’t be a simple differentiator.
      Implications are that if clinicians will categorise problems and diagnoses differently then we need to ensure that clinical decision support and querying will be able to identify the problem or diagnosis easily and consistently, no matter what the arbitrary label, and utilising a single model will support this to occur consistently and safely.

  3. In some cases it does matter – triaging and the need to re-triage in Emergency Departments to meet clinical standards for waiting times.

    http://meteor.aihw.gov.au/content/index.phtml/itemId/341404

    and I agree . . there is effectively a continuum ‘problems’ at one end and ‘diagnoses’ at the other, however if as Heather says:

    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.

    Then it is how this ‘model’ is constrained and for what purposes is where the considerable thought needs to be given – some of this work seems to have been done – http://wiki.hitsp.org/docs/C83/C83-3.html#_Toc234720724

  4. Subsumption in the Problem List
    There has been a lot of discussion about the level of granularity that should be in the Problem List. One way of resolving this would be to have a Problem List that can accommodate subsumption. The Problem List as originally described by Larry Weed allowed for organizing individual problems as being related or ‘due to’ another problem. This would be a way of showing that the neuropathy and the kidney disease were not separate problems but that both were due to diabetes.

    Does the Problem/Diagnosis model allow for this through the use of the Related item and the Relationship type?.

    I am interested in finding out if any EMRs support this type of subsumption.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s