OHDSI Home | Forums | Wiki | Github

Suspected Diagnosis and its place in the OMOP CDM


(Alexander Davydov) #1

While working on Condition Status consolidation, we realized that Suspected stuff handling is still to be discussed and agreed within the community. We already faced this in COVID where we tried two controversial approaches:

  • Store the suspected diagnoses in the Condition Domain as general Condition concepts, but mark them with condition_status_concept_id = ‘Suspected diagnosis’. Then we realized that no analytical methods were able to deal with condition_status_concept_id so you basically can’t distinguish between confirmed and suspected diagnoses. Another issue is that events in the Condition_occurence table are positive facts by the definition and suspected diagnoses don’t look convincing enough to be stored in the same bucket because in every study when you query the Condition_occurance table, you should keep it in mind (and exclude suspected stuff if needed).

  • Store the suspected diagnoses in the Observation Domain using the mapping to SNOMED concepts in the ‘Disease suspected’ hierarchy or post-coordination (if some more specific nosologies are needed).

We finished up with the 2nd approach in COVID, but it will not effectively work in some countries/datasets, where the diagnostic process and its representation in EHR have some peculiarities. @Christian_Reich Can you please explain how every single diagnosis is being treated as preliminary/suspected at some point and being represented in the electronic records.

(Christian Reich) #2

This is not an easy situation. Yes, in some countries, for example the one where I learned that trade, this “suspected diagnosis” is a bigger deal than in others. You get taught that diagnosing a disease is a systematic process of coming up, explicitly declaring and then ruling out possibilities (hence “suspected”, or “rule out diagnosis”), only to develop all necessary diagnostics to either prove or disprove your suspicion. We got drilled in that approach. During ward rounds you have to present patients to the Chief with the full round of suspected diagnoses or the confirmed one.

This is actually not a bad system, but having those suspected diagnoses sitting next to the real ones creates the problems you describe, @Alexdavv. To solve the problem, we indeed have those three options, all of them are ugly:

  1. Keep the s8spected nature in the Condition Status - problem is that every routine query for a Condition will have to make sure you exclude the suspected ones, because usually you don’t want them.
  2. Put them in Observation, let the vocabulary fix it by having a copy of every diagnosis as suspected - problem with this one is sometimes the patient never makes it beyond a suspected diagnosis (dies, gets transferred, leaves against medical advice), and then there would be nothing in Condition
  3. Create a copy of all Conditions in the vocabulary pre-coordinating it with “Suspected” - effectively doubling the Condition Domain in the vocabulary.

My recommendation would be 2) as the least evil, as we keep the CONDITION_OCCURRENCE table clean and don’t have to create silly artificial Concepts (“suspected trauma”).

(Robyn Rubin) #3

We are currently designing the OMOP ETL for 11 general hospitals to be used as a common database for research purposes.
We have that exact predicament.
Diagnosis for patients coming to the hospitals to be tested for COVID19 would have in their records a diagnosis of “examination for suspected coronavirus (COVID-19)”.
What is @Christian_Reich your opinion if we were to regard it as a suspected condition in the condition table, and mark it in condition_type_concept_id as 42898140 - Referral Record.
Upon release the patient will have the appropriate diagnosis in the condition table.
One diagnosis will not have anything to do with the other.

(Chris Knoll) #4

That doesn’t sound like a diagnosis, that sounds like a procedure, no?

(Chris Knoll) #5

I like the idea of keeping the condition_occurrence clean: it’s supposed to record actual findings. I have a suggestion for option #4:

What if there’s a new concept in either measurement or observation for ‘Hypothesis’, and in the value_as_concept you have the thing that is the target of the hypothesis? There may be a way to store if the hypothesis was proven true or false…but maybe it’s just enough to store the hypothesis?

(Leilei Zhu (Clinical Data Standards Lead, UCLH, UK)) #6

Dear all,

this is a perfect example of the diagnosis evolvment process and Bayes’ theorem during clinical decision making. We almost always start off with a “working diagnosis”, aka suspected. Then Bayes’ theory coming into play. The more evidence I have about htat patinent, e.g. lab best, imaging film etc, I either increase the probabliy or decrease the probability of “my working diagnosis”. therefore “Diganosis” is contantly changing.

@robyn.rubin “Examinatoin for suspected COVID-19” is a working diagnosis. That diagnosis should have been updated after the test result comes up. this working diagnosis is going to be changed to either “COVID-19 confirmed by COVID-19 confirmed by laboratory test” or “COVID-19 confirmed using clinical diagnostic criteria”. This may not always be possible as clinicans may not always change it promptly. Or, patients might be transferred elsewhere.

If we merely want to create a research database, then to me, store the data as its native form is important. @Alexander Davydov Disease suspected hierarchy is not going to help you because SNOMED CT is not going to author “suspected” concept for every condition.

in addition, FHIR has clearly stipulates that Diagnosis verification status is a mandatory messaging standard.
e.g. Provisional (or Suspected) is one of them and the definition is: This is a tentative diagnosis - still a candidate that is under consideration. (https://www.hl7.org/fhir/valueset-condition-ver-status.html)

I would strongly suggest your organisation work towards being able to store diagnosis verification status (discreetly). the analytical tool shouldn’t be a problem if we use the SNOMED CT expressions.

(Christian Reich) #7

So, the whole debate is because we want to revise the Condition Status Concepts, and the question is should there be a Status Concept “Suspected” or not. Has nothing to do with referral. Has to do with the fact that during care the diagnosis starts with a suspicion and beomes more and more refined, as @LeileifromUK pointed out. Where do we draw the line and make the assumption that the diagnosis is good enough to be a fact in the CONDITION_OCCURRENCE table?

Yes. That would be a good one too. Why Measurement and not Observation?

We usually don’t have that clout, @LeileifromUK. We get the data collected for primary purposes. Our job is to represent it in such a way that we all agree what it means, since this is a Common Data Model. So, if a data asset has suspected diagnoses we need to come to a consensus to where to put it and how to represent it.

(Chris Knoll) #8

Observation was one of the choices, I don’t have a bias one way or another, but if you consider a hypothesis something ‘measured’ maybe it fits into measurement, otherwise observation makes sense.

(Leilei Zhu (Clinical Data Standards Lead, UCLH, UK)) #9

If this is the case, I don’t think we have an option but to fully represent the suspected verification status as a discreet field. Only in this way, we can maintain coverage and consistency, never mind drive the future direction for travel to be inline with FHIR.
For the EHR system that configured this as a discreet field, it is straightforward and we can model this using the qualifier value. For the EHR system which hasn’t got this field configured as a discreet field, we can use the SNOMED CT modelling to derive the attribute that insinuating “suspected” condition and auto populate in the table. The two major attributes are: Medical examination for suspected condition (procedure) and Finding context (attribute) - Suspected (qualifier value)
Reality is, if the clinician entered a condition “suspected xxx”, they shouldn’t have to enter “suspected” again in the diagnosis verification field to avoid duplication. We should be able to use SNOMED CT modelling tools to derive that element at the backend.

This is how we handle it. Happy to explain further if needed, unless I completely misunderstand the whole discussion topic! (-:

(Robyn Rubin) #10

I see your point and agree with you, however this is the reason for which the patient was referred to the hospital, that was my thinking with regards to condition.

(Leilei Zhu (Clinical Data Standards Lead, UCLH, UK)) #11

In the EHR system, there is normally a field (or several fields) called Health issues or problems or visit diagnosis which the clinicans are expected to enter the information in a structured way. How each field is configured differs from system to system. The content underpins these fields also differs. There is nothing wrong to allow “Examinatoin for suspected COVID-19” to be entered. our Trust just didnt prefer that way. We strictly restricted the list to two domains: Clinical Finding and Situsation with explicit context.
However even this is the concept entred, using the SNOMED CT model, we shoud still be able to know easily it is a suspected “condition” as one of the attribute for this concept clearly states “Medical examination for suspected condition (procedure)”, one of the two main “suspected” attributes I provided in this discussion trail.

(Robyn Rubin) #12

Thank you for your clarification