# Degree of Certainty vs Status in problem/diagnosis **Category:** [Clinical](https://discourse.openehr.org/c/clinical/5) **Created:** 2025-10-30 11:06 UTC **Views:** 373 **Replies:** 34 **URL:** https://discourse.openehr.org/t/degree-of-certainty-vs-status-in-problem-diagnosis/11561 --- ## Post #1 by @david.alonso 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. --- ## Post #2 by @ian.mcnicoll 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. --- ## Post #3 by @Lars_Fuhrmann 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: ](https://terminology.hl7.org/6.5.0/CodeSystem-condition-ver-status.html) ![image|690x132](upload://ow4J0joWzKS2WwiT449VWCunep9.png) ​And different from definitions in the “Diagnostic Certainty” element. ![image|464x346](upload://vptNW6Hs5i3cSquOZ9bBeQgaA8H.png) 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 --- ## Post #4 by @siljelb 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. --- ## Post #5 by @ian.mcnicoll 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!! [quote="Lars_Fuhrmann, post:3, topic:11561"] 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 [/quote] 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. --- ## Post #6 by @Lars_Fuhrmann @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? --- ## Post #7 by @david.alonso 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 ? --- ## Post #8 by @ian.mcnicoll 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. https://www.hl7.org/fhir/R4/condition.html#9.2.3.5 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](https://chat.fhir.org/#narrow/channel/179166-implementers/topic/negated.20Condition/with/153880961) or https://chat.fhir.org/#narrow/channels/public/search/refuted.20condition but no clear answer, though there is a ‘Condition ruled’ out extension https://www.hl7.org/fhir/extensions/5.1.0-snapshot1/StructureDefinition-condition-ruledOut.html 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. --- ## Post #9 by @thomas.beale [quote="Lars_Fuhrmann, post:3, topic:11561"] So the way that I *personally* understand these terms is different from the [FHIR code system definitions: ](https://terminology.hl7.org/6.5.0/CodeSystem-condition-ver-status.html) [/quote] 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. --- ## Post #10 by @david.alonso Thanks @ian.mcnicoll for your clarification. I think that would work for me. [quote="ian.mcnicoll, post:8, topic:11561"] 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. [/quote] 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 --- ## Post #11 by @ian.mcnicoll Hi David - further thoughts from me!! Outcome of a long early morning walk!! [quote="david.alonso, post:10, topic:11561"] 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. [/quote] 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!! --- ## Post #12 by @david.alonso The change request would be something like this ? Diagnostic certainty: \- Suspected ~~- Probable~~ \- Confirmed \- Refuted * Text --- ## Post #13 by @Lars_Fuhrmann @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 --- ## Post #14 by @ian.mcnicoll [quote="Lars_Fuhrmann, post:13, topic:11561"] “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“No known history of diabetes” [/quote] >> “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. --- ## Post #15 by @Ian_Bennett The current FHIR mappings to Diagnostic Status in FHIR Connect library are outlined [here](https://github.com/SevKohler/FHIRconnect-mapping-lib/blob/main/model/cluster/org.openehr/problem_qualifier.v2.yml). @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” [quote="ian.mcnicoll, post:2, topic:11561"] Here’s my take for Condition unconfirmed => suspected provisional => probable differential => use differential_diagnosis archetype confirmed => confirmed refuted => Exclusion - specific archetype [/quote] --- ## Post #16 by @SevKohler 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? --- ## Post #17 by @ian.mcnicoll 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. --- ## Post #18 by @ian.mcnicoll Thanks Ian, I’ll take a look and make some comments. --- ## Post #19 by @SevKohler 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. https://github.com/SevKohler/FHIRconnect-mapping-lib/issues/13 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. --- ## Post #20 by @ian.mcnicoll 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. --- ## Post #22 by @SevKohler If somebody wants to create a mixed high-fidelity architecture, I’m sure they’re also willing to fund and guide the mapping efforts. We first need to finish the basics like IPS and EHDS, unless this is done its a nice discussion. Documentation is a thing, the data type mappings can fill 20 pages ("simple mapping guidance"), you need to manifest this things into tooling its way to much. Also there is no single place for documentation i spend good amount of time collecting this stuff from everywhere. This is why im pushing here for FHIRconnect also to collect these bits (@Ian_Bennett is currently working on a better integrated documentation). --- ## Post #23 by @ian.mcnicoll I agree - all I’m suggesting is that we make it clear that the current mappings re suitable for low-fidelity scenarios and for ‘sharing out’ but highlight issues which might cause problems importing to high-fidelity envirnments. Important to get the initial work done with a realistic scope but also important that we highlight that is is not fully done (or possibly even doable) for all situations. --- ## Post #24 by @SevKohler Agree, if you encounter this cases, please raise an issue on the FHIRconnect mapping library. We will try to add more documentation for users, i want this "guidances" to just contain the bits that are the edge-cases. So they get a standard set, but also the information how to deal with cases. I will map this status. How do we deal with the case users not having an exclusion and differential archetype in their template. Imagine you map this against a template where people didnt think of an exclusion or differential archetype. What should happen ? No mapping at all ? Mapping it with a different status code ? --- ## Post #25 by @grahamegrieve [quote="thomas.beale, post:9, topic:11561"] 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. [/quote] I enjoy your certainty, but it does have something to do with the clinical process, because the fact that something was wrongly asserted due to record keeping errors is a real fact of clinical relevance if/when it may or did lead to the wrong treatment. In such cases, the fact that it was asserted wrongly is a true fact that remains relevant to the care process. If it was truly wrong and that was never relevant to the care process, then it would just be deleted. This was our real process in the lab where I worked, btw. Grahame --- ## Post #26 by @SevKohler I agree, what tom isnt saying here we have an audit and version process to capture technical "stuff". The VERSIONED_OBJECT as an technical workflow, at least as far as i understand. Which has change_types: https://github.com/openEHR/archie/blob/57a60720b13ac1f2085356c96102d701e5fd0b00/openehr-terminology/src/main/resources/openEHR_RM/en/openehr_terminology.xml#L31 As part of the audit you can also provide a description: https://specifications.openehr.org/releases/RM/Release-1.0.4/common.html#_audit_details_class It might be valuable to add **“entered-in-error”** in a more standardized way, rather than just as free text as part of a deletion. But is deletion even the correct approach here? As Grahame mentioned, an entry marked as entered-in-error could still have resulted in subsequent treatments that are linked to this (now “deleted”) object. I’m also wondering how to handle those treatments, they’re based on something entered in error, but they still happened and shouldn’t be considered non-existent. Is it enough to link them to the "deleted" entered-in-error composition. Also that would need to be made visible to the users. --- ## Post #27 by @ian.mcnicoll and that is true but I think what Graham is saying (and I agree) is that in a disconnected message-driven system there is not necessarily a clean technical approach which can safely say - entered-in-error notification → automatically just create a DELETE/UPDATE in openEHR. Ultimately that is where it will probably land, but I would expect some sort of clinical review in most cases, except in simple secondary uses read-only/registry. So both perspectives are IMO correct. 1. If you want to properly redact an erroneous record reported from elsewhere, it is not as simple as just setting an Entered-in-error attribute on that record if it is going to be used for ongoing care especially if it is some sort of primary record. 2. Re-versioning the record as per openEHR is IMO a much safer way of managing this, but equally in many case re-versioning/logical delete etc is not likely to be a wholly automatic process in the context of what is essentially an external notification of error. And that will also happen in openEHR between CDRs unless they are already very tightly co-governed. --- ## Post #28 by @thomas.beale [quote="grahamegrieve, post:25, topic:11561"] I enjoy your certainty, but it does have something to do with the clinical process, because the fact that something was wrongly asserted due to record keeping errors is a real fact of clinical relevance if/when it may or did lead to the wrong treatment. In such cases, the fact that it was asserted wrongly is a true fact that remains relevant to the care process. [/quote] It’s not that it’s not a real thing (erroneous data entry) it’s just that ‘entered-in-error’ is not a possible value of the status of a clinical diagnosis. It is a possible reason for a new version of some data (i.e. ‘error correction’). The way it is done in the HL7 term set is mixing two completely different aspects of real world activity into the one value space. --- ## Post #29 by @heather.leslie [quote="ian.mcnicoll, post:5, topic:11561"] 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 [/quote] Sorry to be late to the conversation. ’Refute’ - my local FHIRman, Brett Esler, tells me “I think refuted is, like most things, not very well defined so expect it is used in all ways including both stating a negation without a prior assertion or negating a previous assertion...” To make an assumption of mapping our archetype values to one definition or the other seems dangerous and if we don’t clearly know the intent it should probably not be mapped from a clinical safety point of view. openEHR exclusions are only valid at the time of recording and negations of existing data has a whole lot of other implementation/workflow implications. Feels like a red flag moment to me. ’Entered in error’ is something we all need to do all the time. In openEHR systems it is usually part of the implementation ie a reason for ‘removal’ of a record ie effectively inactivated. In messages it is another important piece of information, but feels uncomfortable to conflate to a ‘Status’ as done in FHIR; it has never been modelled in any of the archetypes. --- ## Post #30 by @heather.leslie [quote="ian.mcnicoll, post:2, topic:11561"] 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. [/quote] Another is to align the two approaches. I certainly see inconsistency in our archetypes that could be improved eg Adverse reaction event CLUSTER has values of: * Unconfirmed \[It has not been objectively verified that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’.\] * Confirmed \[It has been objectively verified that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’. This may include clinical evidence by testing, re-challenge or observation.\] * Refuted \[It has been disputed or disproven that the ‘Manifestation’ in this reaction event was caused by exposure to the identified ‘Substance’, with a sufficient level of clinical certainty to justify invalidating the assertion. This may include clinical evidence by testing, re-challenge or observation.\] Diagnostic certainty in EVAL.problem_diagnosis has the values of: * Suspected \[The diagnosis has been identified with a low level of certainty.\] * Probable \[The diagnosis has been identified with a high level of certainty.\] * Confirmed \[The diagnosis has been confirmed against recognised criteria.\] There are others. [quote="Lars_Fuhrmann, post:3, topic:11561"] 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) [/quote] We’ve known these qualifiers are messy for a long time, and put it a lot of work already, but we can probably do even more to improve the situation. Careful documentation of each of these inconsistencies and issue provides us with more context of the problem that needs to be solved. There are many qualifiers/statuses that are used loosely and inconsistently. Here is a chance to align the FHIR/openEHR approaches and to improve future data. I suspect if we can deconstruct these qualifiers, present them in a logical manner with each separate axis identified and defined and justify the differences, clinicians would potentially agree and use these terms more specifically and consistently. It would be a global public good! :face_with_spiral_eyes: I know we’ve tried this previously with the Problem/Diagnosis qualifier and we definitely made progress within that single archetype, but now we’re confronted with similar value sets in other archetypes and in FHIR models. Perhaps we now have the context to make better choices and definitions and offer guidance on how to use the terms better. Then building semantically consistent mappings also become easier. It seems to me that we have a number of choices: 1. Build CLUSTER archetypes that are purpose built for FHIR status integration but will create at least some level of openEHR/clinical semantic/technical debt eg for ‘entered in error’ 2. Long term: Work on better designing this messy data, get clinical consensus, lead by identifying best evidence clinical practice/definitions and potentially influence FHIR resources/profiles. 3. Short term: Map between existing FHIR and openEHR artifacts. Some are clear mappings and clinically sound, some are not. At the moment it feels like we are dealing with a number of square peg, round hole situations and this is a red flag moment for me. Maybe it is a practical short term solution but it comes at a cost. [quote="david.alonso, post:7, topic:11561"] Maybe i am lost in translation in the semantic difference between discarded and refuted ? [/quote] No, I like the way you are thinking. We can do better, I think. --- ## Post #31 by @heather.leslie [quote="Lars_Fuhrmann, post:6, topic:11561"] I think neither of us wants to do semantic haggling [/quote] I think this will give us the best long-term outcome though! --- ## Post #32 by @Lars_Fuhrmann Thanks everyone, I think this discussion is really important and I hope we’ll find the time to draw some conclusions from it. @ian.mcnicoll Just to go back on my suspicions that people may be mapping “Suspected”→ “Provisional”: I suspected this was happening in germany so I had a ook at [HL7 Germany’s base profile](https://ig.fhir.de/basisprofile-de/1.2.0/Ressourcen-DiagnosenCondition.html)s: Translated screenshot: ![image|690x213](upload://wle1Ht6s64lxTstVufTRutOu8GN.png) My point is only to illustrate that depending on the source FHIR’s “provisional” may have been “suspected” before the initial mapping, so at least in germany mapping “provisional” to “probable” is best avoided. I would agree that “entered in error” describes another dimension/axis compared to the other items, but as @heather.leslie said it’s not the only overlap of axes in the same valueset we’re dealing with here These elements with cardinality 0..1 frame these terms as if they are mutually exclusive, even though in reality they are not, and they partially overlap: * Most differential diagnoses are also provisional, and also unconfirmed. * Probable diagnosed are also usually suspected. * Working diagnoses are usually also preliminal, (and provisional, and unconfirmed, and suspected) Having just one element with 0…1 is a bit as if I saw an animal hush past in the night and I would then be asked “did it have four legs OR was it grey OR did it hiss at you?” and I had to pick just one. [quote="heather.leslie, post:30, topic:11561"] I suspect if we can deconstruct these qualifiers, present them in a logical manner with each separate axis identified and defined and justify the differences, clinicians would potentially agree and use these terms more specifically and consistently. It would be a global public good! :face_with_spiral_eyes: [/quote] Seems fun to try! This is my attempt to map out the qualifiers, just aligned to openEHR’s ontology, not to any specific archetype: ![image|690x455](upload://jKzeIxMik9izbF0SIOqZc9R2t6n.png) So the main axes would be: * what has been confirmed? * what is the degree of suspicion? * what does this diagnosis *serve as* in our clinical reasoning? (working/differential) With this perspective if someone were to tell me “our working diagnosis is Meningitis” they are really telling us about three axes: Diagnosis Name: Meningitis Confirmation Status: Unconfirmed Suspicion Status: Suspected (not known if strongly or weakly) Clinical Function: Working DIagnosis I know it’s unusual to think of a diagnosis being “suspected” and a “working diagnosis” at the same time, but the minute I stop suspecting my working diagnosis it stops being my working diagnosis. Plus it was already confirmed I would not call it a working diagnosis. Furthermore the above schema would keep the following concepts apart in the correct entry types: * Opinion that Diagnosis X is not present based on available evidence = “statement of evident absence” = exclusion (strictly speaking) = OK in Evaluation Entry * Statement by somebody or something that there is no *known* history of Diagnosis X = “Observation of absence of evidence” = strictly speaking **not** an exclusion = Observation Entry → Screening-Questionaire Type Archetype Just to clarify I’m not disagreeing with the use of the Exclusion Evaluation Archetypes, my understanding is just that they’re not the right entry type for “no history of X”, even though currently their use statements contain multiple such examples. --- ## Post #33 by @linforest I think it's a good idea to break this problem down into different axes/dimensions to solve it. --- ## Post #34 by @SevKohler I agree with Lars — in general. Apart form that I find the exclusion archetype problematic. It does not really align with the usual modeling approach (i feel). Typically, we want all information related to a clinical concept to be part of the same model. This allows for researchers and clinicians data being process using a single archetype (e.g., *problem_diagnosis*) and expect all relevant attributes to be located there (or as part of clusters). The exclusion archetype instead introduces a terminology-based mechanism. In practice, this means I may not know whether a diagnosis (or any other clinical fact) is explicitly excluded for a patient group unless I know the exact code or unless that exclusion is attached to the exact template I am querying. Otherwise, I have to retrieve and resolve this information separately with the help of an terminology server (find all exclusions having diagnosis codes in SNOMED, ICD ....). This shifts the model toward a terminology-driven representation — similar to what is done in FHIR or OMOP — where meaning depends on code lookups rather than the structural model. In situations where the correct code is unknown, or where access to a terminology server is limited, processing such an archetype becomes difficult and, in my opinion, unreliable to some degree. I rather would have it as an cluster that i can attach in an archetype as an example (something more generic as @Lars_Fuhrmann did, so we can use it everywhere e.g. also to exclude that a patient has a pacemaker, something you do in cardiology). That would at least provide a standardized slot in an archetype where it also resides as part of the archetype in an composition instead of apart of it. Anyhow, this has the downside (apart from going against whats established) that if i just check for diagnosis without looking at the e.g. cluster, i will also retrieve refuted diagnosis. But im sure im also missing something. --- ## Post #35 by @ian.mcnicoll [quote="SevKohler, post:34, topic:11561"] The exclusion archetype instead introduces a terminology-based mechanism. In practice, this means I may not know [/quote] The minute you add some sort of ‘negating flag or structure,‘ to a diagnosis archetype, you run the risk of a negating statement being confused for a positive statement, just because the querying party does not include the negating attribute/structure in the query. So Problem = Meningitis can easily be confused with Problem = Meningitis Negation: True. That is where I think for now, we should be using the specific exclusion archetype: rule-out diagnosis. In almost every other scenario where negation is needed, the screening questionnaire archetypes are now more appropriate. I don’t think we need specific exclusions now, apart from the rule-out diagnosis example. However, I agree in principle that it would be better to handle ‘rule-out diagnoses’ more elegantly. I’ll post separately on an idea I had on this. --- ## Post #36 by @siljelb Just as a heads-up, there is ongoing work to revise the "Exclusion" archetypes. Perhaps @KBarwise could outline which changes are currently suggested? --- **Canonical:** https://discourse.openehr.org/t/degree-of-certainty-vs-status-in-problem-diagnosis/11561 **Original content:** https://discourse.openehr.org/t/degree-of-certainty-vs-status-in-problem-diagnosis/11561