Suspected Diagnosis and its place in the OMOP CDM

[Alexdavv (Alexander Davydov)]

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]

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]

Hi,
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.
Robyn

[Chris_Knoll]

a diagnosis of “examination for suspected coronavirus (COVID-19)”.

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

[Chris_Knoll]

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”).

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?

[LeileifromUK (Leilei Zhu (Clinical Data Standards Lead, UCLH, UK))]

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]

suspected condition in the condition table, and mark it in condition_type_concept_id as 42898140 - Referral Record.

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?

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?

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

I would strongly suggest your organisation work towards being able to store diagnosis verification status (discreetly

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]

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

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.

[LeileifromUK (Leilei Zhu (Clinical Data Standards Lead, UCLH, UK))]

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.

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]

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

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.

[LeileifromUK (Leilei Zhu (Clinical Data Standards Lead, UCLH, UK))]

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]

Thank you for your clarification

[MPhilofsky (Melanie Philofsky)]

I agree the Condition Occurrence table should only include an actual diagnosis and not “suspected” diagnoses for the reasons others have stated:

events in the Condition_occurence table are positive facts by the definition

And I agree

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).

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

We don’t need to to make copies of every diagnosis as suspected. As @Chris_Knoll suggested, let’s find/create a concept for “suspected diagnosis”, give it a domain_id = Observation and put the suspected Condition in the Observation.value_as_concept_id field. We already do this to represent Medical History, Surgical History, Family History, etc. Let’s keep our representation of the data consistent.

[LeileifromUK (Leilei Zhu (Clinical Data Standards Lead, UCLH, UK))]

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).

I have explained using examples why disease suspected hierarchy doesn’t cover all suspected diagnoses and what algorism to use to procure a list of suspected conditions in SNOMED CT . some concepts may not be appropriate to map to the concept under that hierarchy. just bear that in mind.

[MPhilofsky (Melanie Philofsky)]

This solution:

let’s find/create a concept for “suspected diagnosis”, give it a domain_id = Observation and put the suspected Condition in the Observation.value_as_concept_id field. We already do this to represent Medical History, Surgical History, Family History, etc. Let’s keep our representation of the data consistent.

Will cover this use case:

some concepts may not be appropriate to map to the concept under that hierarchy.

The direct representation of the suspected disease will remain intact in the Observation.value_as_concept_id (when the Condition maps to a concept_id) or Observation.value_as_string (when the Condition is string format) field. The Observation.concept_id = ‘suspected diagnosis’ or something.

Example:
Observation.concept_id = ‘suspected diagnosis’
Observation.value_as_concept_id = 312327
Observation.value_as_string = Acute Myocardial Infarction

[Chris_Knoll]

I wouldn’t use the string in that way when the concept itself is sufficient. Otherwise, I do like this approach. Tools will have to be modified to support the notion of a ‘concept set’ for specifying the value_as_concept_id values, but that shouldn’t be too much of a problem.

[Christian_Reich]

I wouldn’t use the string

I am with Chris, @MPhilofsky. In the long run, we want to get rid of the strings altogether (except in NOTE). That will make OMOP ultimately anonymized and fully computable.

[Alexdavv (Alexander Davydov)]

Observation.concept_id = ‘suspected diagnosis’

Here you go: 4219847 Disease suspected

I wouldn’t use the string in that way

get rid of the strings altogether

I think this just to preserve the part of the source_value that imply the diagnosis. The observation table doesn’t contain value_source_value filed, while it does exist in the Measurement table. So a kind of workaround to keep the logic consistent for both tables when source_value consists of two elements.

[Christian_Reich]

@Alexdavv: Good try, but no workarounds or usage of fields for a different purpose because “you want to store something” and that field happens to be available. It’s a Common Data Model. Things have to strictly follow the rules, otherwise you cannot do remote queries.

If you think there is a value_source_value field necessary - bring it on as a proposal, please.

[Alexdavv (Alexander Davydov)]

@Christian_Reich

Good try

This is how I gently tried to propose this:

@Christian_Reich

If you think there is a value_source_value field necessary - bring it on as a proposal, please.

What do you and others think?