Degree of Certainty vs Status in problem/diagnosis

Clinical
1

Let’s say that in a use case we are asked to provide the degree of certainty/status for a diagnosis. Functionally, we are asked to reflect these two axes, in a simplified way with three values. Suspected / Confirmed / Refuted.

From openEHR-EHR-EVALUATION.problem_diagnosis.v1 and

openEHR-EHR-CLUSTER.problem_qualifier.v2

.. can I use ? : Refuted (from Diagnostic Status) and Suspected, Confirmed (from diagnòstic certainty).

My concern is that in the description of the “Refuted” element, it is intended to work as a correction to an error in the Health record, but, in the use case I present, could work also as a state after suspected.

A suspected problema/diagnosis could turn into Confirmed or Refuted.

More or less like the aproach of the certainty valueset in the “verification status” element in the openEHR-EHR-EVALUATION.adverse_reaction_risk.v2. Just that instead of “Unconfirmed” there would be “Suspected”, wich i think is semantically close.

I am aware this a messy semàntic area, but any advice would be welcome.

2

This is an Important discussion in the context of IPS and wider openEHR/FHIR mappings @Ian_Bennett and I were discussing this earlier in the week

Here’s my take for Condition

unconfirmed => suspected

provisional => probable

differential => use differential_diagnosis archetype

confirmed => confirmed

refuted => Exclusion - specific archetype

This implies an actual diagnosis where some condition is explicitly ‘ruled out’ as part of the diagnostic process e.g ‘No evidence of meningitis’ . This is not the same as a diagnosis being deleted because of a recording error or diagnostic error

entered-in-error => equates to a record delete so needs to trigger some sort of external handling, automatic or manual. Bear in mind that this almost certainly is also required in most clinical systems on import ,even FHIR native stores

One discussion that we need to consider is the extent to which we are prepared to simplify the mapping process by adopting the FHIR display labels or even valuesets, where appropriate.

e.g can we consider moving to use unconfirmed rather than ‘suspected’ and ‘provisional’ instead of ‘probable’. I appreciate they are not exact synonyms but equally I suspect in real use they could be regarded as interchangable.

2 Likes
3

I think this is such a crucial point for the “semantic interoperability” between FHIR and openEHR that a bit of public semantic nitpicking may be in order? :wink:

As a non-native-speaker I think I have to first clarify how I understand these words, just to make sure nothing is getting lost in translation

  • To me confirmed or unconfirmed reflects a statement about the absence or presence of a confirmation (what “confirmation” means depends on the circumstances)

  • To me provisional reflects a statement on the absence of a final decision (what “final” means depends on the context )

  • To me differential reflects a statement that there is some set of symptoms/signs/other information that may be explained by this or another diagnosis, and it is uncertain which one (or more) is “true” or which one (or more) will be confirmed later.

  • To me refuted means there even though someone first made one statement about the diagnosis, then someone stated that the preceding statement is proven to be untrue.

  • To me entered-in-error reflects a statement that something was entered in error. (but not really what the error was)

  • To me suspected reflects a statement about the presence of a suspicion, but is neutral in regard how “strong” that suspicion is

  • To me probable reflects a statement of a high degree of likelihood that the diagnosis is true.

So the way that I personally understand these terms is different from the FHIR code system definitions:

image
image1146×220 9.76 KB

​And different from definitions in the “Diagnostic Certainty” element.

image
image464×346 13.4 KB

To me a diagnosis can be suspected, probable and confirmed at the same time, because all three refer to completely different dimensions (suspicion/likelyhood/presence of confirmation)

A confirmation of a diagnosis neither makes it “impropable” nor “unsuspected”, it just makes it “not unconfirmed”

Meanwhile, any provisional diagnosis is likely also unconfirmed.

There can be enough evidence to assert the presence of the condition, but if the right person has not gotten round to actually make that call then it is still unconfirmed. The amount of evidence and the presence/absence of a confirmaton are two different dimensions.

This all seems very problematic to me, because it is entirely unrealistic that clinicians will always be aware of how exactly these terms are defined either in the FHIR code system or in the Archetype.

99% of the time clinicians will only see (suspected/unconfirmed/probable/etc) and will interpret the meaning of these terms in their own way, so I think all of these long-form definitions are inheritely ineffective in designating the clinical meaning that these terms will carry in the real world.

But wait, it gets worse!

When you offer clinician A a choice of of “suspected” or “confirmed”,
and clinician B a choice of “suspected”, “probable” or “confirmed”,
Then you cannot expect that both of them would use “suspected” in the same way, it’s meaning has changed by “probable” being an option.

What we need is:

  • Terms that are defined in the most obvious ways possible (confirmed means presence of a confirmation)

  • Valuesets being reused in their entirety, picking and mixing changes the meaning.

  • Re-use of definitions across FHIR and openEHR? how is that ever going to work? The current definitions seem to be woven deeply into either base resources or key archetypes

So I agree @ian.mcnicoll ‘s point to try and use a term like “unconfirmed” in both

2 Likes
4

I generally agree with the points made above. Speaking only for the Problem/diagnosis archetype, the “Diagnostic certainty” element was added after review round #3 in April/May 2015, and our modelling patterns have evolved somewhat since then. If we’re changing this at some point (it’ll be a breaking change!), I’d prefer removing both “suspected” and “probable”, and adding “unconfirmed”. If anyone needs other value sets, they can still add replace this one with their own using the “text” data type.

1 Like
5

I can’t disagree with your semantic analysis Lars but I suspect by the time you add in translation, personal interpretation and the fact that most clinical people do not care too deeply about the subtle difference between ‘unconfirmed’ and ‘suspected’ in the moiddle of a busy clinic, and it becomes IMO a bit of a fruitless discussion.

There was some really good work done some years ago on the inter-rate reliability of clinical allergy ‘certainty/ severity’ recording and frankly it was hopeless.

So I’m happy to accept the FHIR definition of refuted, which I take to mean - this was an active ‘rule-out’ diagnosis, not correction of an incorrect diagnosis

so Suspected meningitis→ Meningitis ruled-out ‘refuted’, which equates to our idea of Exclusion of diagnosis.

Perhaps we need to reframe the discussion in terms of expected behaviour, especially in terms of decision support, ‘normal querying’ especially for unconfirmed/suspected/confirmed’ i.e the terms are not semantic as such but actionable.

Unconfirmed meningitis=> The system should not normally treat this patient as ‘having meningitis’ in terms of CDSS and other actionability
Probable meningitis => The diagnosis is unconfirmed but it is strong enough that we should ‘assume’ that they have meningitis until proven otherwise

So less haggling about the meaning of the ords and more agreement on the impact of the words. At least for diagnosis, the difference between suspected and conformed has real consequences for the patient e.g insurability.

Sorry a bit off track!!

I suspect this is a change that could be made without major consequences - in many cases the selection (both our choices as modellers and clinical users will have been quite arbitrary. Especially if we could tie the terms to behaviours not to linguistic subtlety, I think any disruption would be a small price to pay.

1 Like
6

@ian.mcnicoll thanks for your reply, I think neither of us wants to do semantic haggling, I was mostly trying to unpack these terms to see if I understand them correctly.

I’m all in favour of discussing them in terms of intended behaviour, but I think that adds even more complexity, because the expected behaviour is extremely context-dependent. Plus we would need to consider the behaviour they induce in clinicians, too, not just right CDS-Systems, right?

In Meningitis “probable” may have to induce behaviour like “confirmed” because withholding treatment until a definitive confirmation could be fatal.

In most cancers, “probable” may have to induce the behaviours similar to “suspected”, because for both a closer confirmation, rather than treatment, would be the next step.

If we imagine that these qualifiers were originally not “suspected” and “probable” but rather “unconfirmed” and “provisional”. In which contexts are we sure we would feel comfortable to have behaviours induced by “suspected” when the original value was “unconfirmed? (Same with provisional-probable).

I’m sure in the vast majority of cases that would be OK, and in a tightly controlled context I would not have any qualms about the mapping you suggested.

But if we are talking about this mapping in general FHIR/openEHR terms the we are considering rules that will be applied for millions of interactions and a variety of contexts. I think at that point it is worth asking “What’s the worst that could happen?”.

I don’t have an answer to that, but I think the safest approach which would be to maintain the exact source values. It seems to me that is what @david.alonso tried to do by keeping refuted as refuted even if it is not within the Diagnostic Certainty element.

I may be a extra careful here because I am assuming that what we get from a FHIR resource might not be identical to the original. value, right? Don’t we have to assume these values have already been through a mapping to FHIR?

What if there is a source (non-openEHR) system that only had “suspected” and “confirmed”?

They might map “suspected” to “provisional”, which does align with the FHIR definition of “provisional” (tentative, candidate under consideration). Not saying this should be done but let’s assume someone does. If on import to openEHR “provisional” gets mapped to “probable”, then we have just gone all the way from “suspected” to “probable”, even though these would be mutually exclusive in the Archetype.

I worry any mapping of these nasty in little terms can be a step in a game of telephone where I can’t predict the consequences of it is played at scale. I know I’m stepping out of my area of expertise here so I would love it if I’m wrong.

I’ll try and suggest some things anyway:

  • Mappings that are ok if the context is controlled, the provenance of the data is precisely known, and behaviour is predictable might not be ok in other scenarios

  • Show humans the qualifiers exactly as they were entered by other humans wherever possible because human behaviour is unpredicteable

  • CDS-Systems need the ability to group sets of qualifiers and then link each group to a specific behaviour within the confines of a specific clinical context.

  • @siljelb if the element is only unconfirmed/confirmed, maybe rename to “confirmation status? Refuted might actually make sense there as well as a confirmation of absence. If there is a common need to semi-quantitatively express a degree of suspicion/likelihood maybe a seperate element would be better for that specific dimension?

7

Acording to “Diagnosic Statuts”, as another prespective to model the use case.

Lets say i have a diagnostic in status “Preliminary” (the clinician suspect it). Later on the clinical evidence discard the diagnosis. There was no error. It is a confirmed and -.

I understand that the diagnostic Status “Refuted” can not be used, as it was never an error.

Maybe I would need a “Discarded” atribut if it comes from an unconfirmed diagnosis.

Could it be added to the value set via change request?

Maybe i am lost in translation in the semantic difference between discarded and refuted ?

8

That’s not my reading of ‘refuted’ which says

This condition has been ruled out by subsequent diagnostic and clinical evidence.

Generally, electronic records do not contain assertions of conditions that a patient does not have. There are however two exceptions:

  • It is appropriate to capture a “refuted” Condition record if the patient or anyone else had reason to believe that a patient did have a condition for a period of time and subsequent evidence has demonstrated that belief was mistaken. In this case, a concrete statement acknowledging the belief as well as the refutation of it is useful.

  • It is common as part of checklists prior to admission, surgery, enrollment in trials, etc. to ask questions such as “are you pregnant”, “do you have a history of hypertension”, etc. This information should NOT be captured using the Condition resource but should instead be captured using QuestionnaireResponse or Observation. In this case, the combination of the question and answer would convey that a particular condition was not present.

None of this advice really supports e.g a discharge diagnosis of ‘No evidence of meningitis’ or warns against something like ‘meningitis’ refuted

I’ve hunted through Zulip and not found this discussion
#implementers > negated Condition

or Public view of FHIR Community | Zulip team chat

but no clear answer, though there is a ‘Condition ruled’ out extension HL7.FHIR.UV.EXTENSIONS\Condition Ruled Out - FHIR v5.0.0

The big problem we are trying to avoid with our Specific exclusion archetype, is to prevent a ruled-out exclusion being confused with an actual diagnosis.

I think all of us are a bit lost in translation, and I think practically, I would set a rule that forced an incoming Condition with refuted or entered-in-error set, to be handled manually, and not automatically imported into the EHR.

I think we are clear and correct that a ‘negative diagnosis’ should be handled quite separately, as relying on terminology to differentiate pos/neg is just too risky. So handle ‘refuted’ on case-by case basis.

9

While the individual definitions might (or might not) be acceptable, the inclusion of ‘entered-in-error’ in the same code set as the other codes is just an error, and unfortunately a common one in HL7. Entered-in-error relates to human / IT interaction, application error and similar things, and has nothing whatever to do with the clinical process. It should never be a possible value for a data point that could be coded with the remaining values, and in openEHR it isn’t.

Refuted is an interesting question. It’s presumably aimed at handling the ‘wrong diagnosis’ situation, which is real and all too common. I think we do need to represent that clinical opinion has changed on a Dx, so this code should be a reasonable value on diagnostic status. I don’t know that it is automatic that an exclusion is going to be created (as per @ian.mcnicoll ) - we can imagine a Dx of ‘autism’ being changed to ‘neurological trauma’ based on some new evidence, but I don’t know that a separate note excluding autism would be right, since that is a process in itself, and probably not what the doc is trying to solve right now.

The most important thing in all of this is that computational use of the Dx field does not fail to look at the status field, since the value of the latter is essential in determining if this patient actually has the condition. Refuted is essentially a negation, from a logic point of view.

Entered-in-error needs to be handled completely differently, and cannot be computed with a Dx, i.e., even if a Dx was entered in error, it doesn’t mean it isn’t true. Maybe it was entered on the wrong patient, but the intended patient does in fact have the condition.

1 Like
10

Thanks @ian.mcnicoll for your clarification. I think that would work for me.

If I understood it correctly, that is the main point the intiative is trying to represent. A diagnosis that can evolve from: “SUSPECTED” to “REFUTED” because of clinical evidence (and NOT for error involved in the process).

I was not certain to be able to use “REFUTED” when i read the definition of the element on openEHR-EHR-CLUSTER.problem_qualifier.v2.

” Refuted [The previously recorded diagnosis has been clinically reassessed or disproved with a high level of clinical certainty. This status is used to correct an error in the health record.]”

Once clarified, I think it could work like this:

Preliminary –> Suspected

“Preliminary [The initial diagnosis made, usually associated with a low level of clinical certainty. It may change as test results or advice become available.

Established –> Confirmed

Refuted –> Refuted

11

Hi David - further thoughts from me!! Outcome of a long early morning walk!!

In current opnEHR terms, I think that is correct. The proper action for a corrected confirmed diagnosis, is probably to logically delete or update the original. Now there may be some benefit to setting the refuted flag before that update/delete.

But where refuted means ruling out a suspected diagnosis, the correct behaviour in current openEHR is to create a Specific Exclusion Entry, and not create a Problem/diagnosis at all.

The problem here is fundamentally that FHIR is carrying a message about the status of the Condition, but that does not necessarily map cleanly into how any target system handles negations/ exclusions/corrections etc. This is not unique to opnEHR, nor even to FHIR-native CDRs where how you handle ‘refuted’ may be very implementation-specific.

So there is simply no clean mapping solely at term-level or even structure that we can apply here in a universal way.

Preliminary –> Suspected

“Preliminary [The initial diagnosis made, usually associated with a low level of clinical certainty. It may change as test results or advice become available.

Established –> Confirmed

Refuted –> Refuted, where this is a correction to an ‘existing diagnosis’ (that may or may not have been confirmed!) and in openEHR, you have to decide what to do with the original diagnosis entry - update / delete/ flag. I don’tthink this can be done automatically

Refuted → as ‘Rule-out diagnosis’. Normally where a suspected diagnosis has been ruled out after investigation but no other accurate diagnosis is offered. e.g the Problem was a child with headache, rash and fever but is discharged with the diagnosis of ‘meningitis excluded’ , In openEHR cirrent advice is to import this as a Specific Exclusion.

@Lars - definitely not wanting to dodge the necessary semantic wrangles!! They are fun in their own way. Just cautioning against having agreement as necessarily solving the problem. We have to get into the expectation of what the recipient should understand and how to behave e.g should probable be rgarded as a working diagnosis from the pov of ongoing mgt/ AI / CDSS .

I think there is some value in setting the refuted flag in openEHR, but that should not be the only action - I think I would insist on any incoming FHIR ‘refuted’ conditions being queued for human review, if they are being imported into any kind of CDR where data quality and clinical safety is significant.

BTW I think the refuted term is probably in the wrong place. Currently it is on ‘Diagnostic status’ in the qualifier archetype. Diagnostic status was intended to capture the status of the diagnostic process leading to ‘Final diagnosis’ i.e all investigations exhausted vs Diagnostic certainty in the main archetype, which is about confidence in the diagnosis - you can have a Final diagnosis which remains unconfirmed. TBH this was probably over-engineered, but was an attempt to resolve where terms like final and working diagnosis fit. I donlt think refuted fits here but would do on Diagnostic certainty.

I’ll make a CR on CKM to see if it can be moved.

TBH I don’t think we have this ‘rule-out diagnosis’ issue sorted, either on the FHIR or on the openEHR side. Possibly something to chew over in the collaboration efforts. I am quite intrigued by the FHIR ‘Conditions excluded’ extension but I’ll post on that separately!!

12

The change request would be something like this ?

Diagnostic certainty:

- Suspected

- Probable

- Confirmed

- Refuted

  • Text
13

@ian.mcnicoll I think I need one of those long walks as well :smiley:

It makes perfect sense to me to not handle negation with a “tag”, because there is a risk that it may be confused with a real diagnosis. So let me retract my my earlier suggestion to do put refuted into “Diagnostic Certainty”, @siljelb

In the German ICD modification we use the letter “A” for “Ausschlussdiagnose”=Excluded Diagnosis”, mostly the purpose is to justify billing an outpatient diagnostic procedure.

An example would be a patient getting an MRI because of a suspicion of a brain tumor, but there is then no evidence of one in the MRI and the suspicion is therefore dismissed. It can then be coded with the code for “Brain tumor” plus the letter “A” to denote that that was excluded.

Anecdotally this can be cause for confusion, including for patients.

I like the idea of the separate Exclusion entry, it does seem like the safest option.

I wonder if we need to differentiate between two different types of statements:

  1. “No History of Brain Tumors” = Absence of evidence.
  2. “We did an MRI that showed no evidence of a brain tumor” = also absence of evidence - but functionally , within a limited contex, this can also be assessed to be an “Evidence of Absence”. (Depends on the sensitivity or the observation etc)

To me 1 is historical and concerns the absence of evidence in a given history or observation while 2 also includes an opinion of exclusion or refutation.

It might be because I am trying to understand openEHR’s ontology at the moment, but to me it seems we need to split the concepts of an absence of evidence in the history from an opinion on whether a given set of clinical evidence is sufficient for an assertion of refutation or exclusion.

That might render the examples used in the exclusion entry (no known history of… ) suboptimal, because it would be a historic content in an Evaluation Archetype?

“No known history of diabetes” = History

“I don’t think this patient has ever had diabetes” = Opinion

“I refute the suspicion of a brain tumor based on the MRI” = Opinion

14

“No known history of diabetes” = History

Definitely - this is where the Diagnosis screening archetype comes in nicely, and FHIR advice is broadly similar about using Questionnaire

“I don’t think this patient has ever had diabetes” = Opinion

2 variations both opinions

a) This person has been diagnosed as having diabetes but we now think that is incorrect (Refutation on openEHR)
b) This person was suspected as having diabetes but this was never confirmed and we want to report ‘ Diabetes excluded’ as the outcome of the diagnostic process i.e the diagnosis - Specific exclusion in openEHR

“I refute the suspicion of a brain tumor based on the MRI” = Opinion
I probably agree but I would hope that ‘suspected tumour on MRI’ would not have made it to the level of suspected brain tumour’ as a diagnosis without other evidence, but if it had, this would might well be a discharge diagnosis i.e a rule-out diagnosis and therefore a Specific exclusion.

In future terms, I do quite like the idea of in FHIR of allowing excluded conditions to be flagged as part of a problem statement i.e in a problem-diagnosis archetype.

So

Problem name: ‘Indicental finding on Brain MRI’ (as text)
Excluded conditions:

  1. Brain tumour

  2. Brain abscess

    These could be coded as they are structurally not part of querying for problem name, so can;t mix up the excluded conditions from the underyling problem that was being investigated.

    I don’t like FHIR version of this that references actual Condition resources as we then get back into the same problem of inadvertently including excluded conditions via a naive search.

1 Like
15

The current FHIR mappings to Diagnostic Status in FHIR Connect library are outlined here. @SevKohler has put a lot of effort into the mappings. I think there is perhaps a wider conversation as to how these are clinically ratified especially given FHIR Connect syntax is not familiar to everyone. In the current mapping, entered-in-error is essentially ignored (i.e. not mapped). Will see about updating this to reflect your take below Ian.The mapping currently has “provisional” mapping to “working” rather than “probable”

16

We might still need to correct that, but we discussed this in the mapping WG and think it’s sufficient to map the parent classes from FHIR, which also align quite well with openEHR.
I haven’t seen much usage of the level 2 codes so far.

As it seems you’ve already figured out, we’ll need to assess how feasible it is to map to the differential diagnoses.
That would mean every mapping template from FHIR would need to include this archetype.
The same applies to the exclusion (which I agree is important); the problem is where the exclusion should reside within the composition.
If you have the ability to model an ingest template, this becomes feasible.

For mapping concepts like entered-in-error, we usually handle that in the VERSIONED_OBJECT.
I don’t see any value in ingesting faulty data.
Refuted should go into exclusion, if possible.

@yampeku — did I forget anything?

2 Likes
17

Largely agree for simple use-cases but ‘refuted’ can have 2 meanings in FHIR, one which maps to Exclusion (rue0out) but the other requires a correction to an existing diagnosis, and whilst it may be correct ot route entered-in-error via a VERSION, I’m not sure I would trust thta to happene automatically in a system handling front-line data.

I think we may have to issue 2 sets of guidance.

  1. For simple imports where some loss of accuracy is acceptable as there is no need ot support direct care, and e.g there is no real underlying concept of problem lists or other constructs.

  2. Where there is an attempt to maintain high-quality data to support direct care, we do have to be a lot more careful and accept that many of these refuted/ entered-in-error situations will need to be routed into a queue where a human being can assess the correct action. We are probably not in a position to define this clearly but in defining the correct behaviour for (1), we do no need ot be very careful to limit the cope of where we think that simple approach is safe.

This is a new ground for everyone, FHIR and openEHR - there is a reason why most FHIR servers are largely read-only, and it is almost certainly not a tech issue, it is a semantics/ info quality issue.

1 Like
18

Thanks Ian,

I’ll take a look and make some comments.

19

Okay, so for our mappings we proceed as proposed above.
I think this decision layer is something that has to be implemented internally by each side.
In the end, it could be reflected in the tooling and the specification tho.
Anyhow, having such a lossless integration for high quality of care, is something that requires additional implementation and so on, i see this up to vendors if they really want to have such a detailed integration with human support.

I think we first need to establish a stable base of mappings and then start adding features like this (e.g., a callback from FHIR Connect to an endpoint, or similar) on top.
It’s important that we document these decisions for now.

I would also like to ask for people to make an issue on FHIRconnect mapping lib, currently im trying to collect this mappings stuff but there are topics everywhere which will stay “theoretical” unless we document and persist them somehow.
You can just link this discussion here in an issue as i did now.

Even if not using FHIRconnect this helps at least to have some documentation.
We are also thinking to attaching documentation to each of this mappings or the decisions.
@Ian_Bennett is currently working out something for that.

20

I’d be fairly certain that differential diagnosis would not appear in any usual ‘import’ activity for persistence, other than perhaps in a special case of an internal handover of care document, when it should definitely be mapped to the diff_diagnosis archetype.

I’d never expect to see a diff diagnosis in a patient summary or formal discharge document, and would prevent it being imported automatically to ‘my system’ in most circumstances.

I agree we can’t boil the ocean on this but I wouldn’t frame these as ‘academic’ questions - they are actually likely to be quite real, quite soon in ‘high-fidelity’ scenarios. What we can do is issue simple mapping guidance for ‘low-fidelity’ scenarios - reporting/ registry/ read-only patient summaries where accurate transfer of info is not critical.

1 Like