OHDSI Home | Forums | Wiki | Github

Condition_occurrence, Death diagnoses

CDM Builders
#33

thats a breaking change to our model conventions, so i think we should
discuss it on the cdm workgroup to make sure we have community consensus.

1 Like
#34

Are you checking on us? :smile:

2 Likes
#35

Our source data contains up to 11 fields for acme codes. These acme codes are ICD-10-CM and ICD-9 codes with the decimal removed. I read about acme codes here “ACME Automates the underlying cause-of-death coding rules. The input to ACME is the multiple cause-of-death codes (ICD) assigned to each entity (e.g., disease condition, accident, or injury) listed on cause-of-death certifications, preserving the location and order as reported by the certifier. ACME then applies the World Health Organization (WHO) rules to the ICD codes and selects an underlying cause of death.”

Has anyone used this code system and tool? Is it accurate? It seems to be inline with what the WHO expects for mortality reporting. Would this help solve the multiple cause of death issue?

It looks like we will still have use cases for the preservation of the underlying cause/s of death code/s. But the above may help determine which code should be used for the cause of death.

#36

Hi all,
And what if suicide is reported as cause of death?
I’ve found concept

440925	Suicide	Observation	SNOMED	Clinical Finding	S	44301001

BUT

I’d like to change domain of Suicide from Observation to Condition.

#37

Well, that’s interesting

  1. Suicide (obdservation) leads to Brain Injury (Condition) for example

  2. Depression leads to Suicide.
    and if somebody makes a study on Depression, they wouldn’t really care about classical Causes of death like “Brain Injury” or “loss of blood” or whatever people can make to kill themselves.
    In this case they need to know about Suicide itself.

So I see two options here:

  • put Observations as a cause of Death
  • make Suicide a Condition

@Christian_Reich?

#38

Yeah, suicide is an interesting one. Let me think.

#39

Could you point me whether there was any further discussion and a decision written down? Storage of several records per a single death just because of different causes, as @Christian_Reich proposes, goes against simplest forms of DB normalization and therefore against good database design.

#40

Hi @pavgra as far as I know there was no decision made here. There was no proposal created so we haven’t discussed it in the CDM workgroup. For now, the DEATH table can only have one record per person.

#41

@pavgra:

Why does having several records of something that’s a plurality go “against the simplest forms of DB normalization”? If we have more than one cause of death we need more than one record. What are you proposing?

#42

It’s a THEMIS decision. Will be published soon.

#43

@Christian_Reich, what plurality do you have? Do you have plural deaths, or plural death dates, or plural death types? As I understand, no. You have multiple causes. And it’s, of course, OK to have multiple records for multiple causes. But it’s not OK to duplicate all other data just because of multiple causes. All other data remains the same. Why not to duplicate? Because of https://en.wikipedia.org/wiki/Database_normalization

What I propose is to have a separate table for death causes with following columns:

  • id
  • death_id
  • cause_concept_id
  • cause_source_value
  • cause_source_concept_id
#44

I agree with @pavgra that our DEATH table should be unambigious in its definition of death. Just as the PERSON table can only have one record per person, because you only live once, so too should the DEATH table only allow up to one record per person, because you can only die once.

If there are data that contain multiple causes of death, then we need an appropriate data model solution to preserve this information and disambiguate it from the death itself. @pavgra’s proposal to have a separate CAUSE_OF_DEATH table is consistent with what the FDA Sentinel CDM has done (just without a standardized vocabulary): https://www.sentinelinitiative.org/sentinel/data/distributed-database-common-data-model/sentinel-common-data-model

Perhaps when we develop the Feline Data Model, we can allow for up to nine records in the DEATH table. But as long as we narrow our focus to people, one should suffice:)

1 Like
#45
#46

Let’s firstly decide whether we are OK with multiple causes of death. And for this we need to collect use cases of how people want to analyze death.

We have now that the death domain contains the clinical event for how and when a Person dies.

I.e if person committed suicide we store ‘Suicide’ as the cause. It’s OK from some social and/or clinical
perspective. But any pathology report contains ‘suicide’ as cause of death: it can be asphyxia, cerebral edema, intoxication etc.
So what I think is that we definitely need to allow multiple causes of death because we may be interested in different levels of granularity. And when we are speaking about how to store - I agree with @pavgra but would like to see also something similar to condition_status_concept_id from CONDITION_OCCURRENCE table

#47

Oh boy. Where were you guys when the issue was listed out for debate?

Here is my pragmatic approach to this:

  1. You want to allow more than one cause of death, for the reasons @Eldar listed.
  2. This problem really is not common. On the contrary. We usually badly lack information about death. To create two tables for reasons of ideological modeling purity appears to be a complete overkill to me.

So, tell me if there is a use case that would suffer from one table with repetitive death records. Unless there is one let’s keep it the way the community has decided.

#48

Why don’t we modify the current Death table so that it will store the causes of death and put the fact that a person died in Person table? I feel like in two years it will be hard even to remember all the names of CDM tables.

1 Like
What to do with NULL Death dates in OMOP?
#49

Fabulous idea, @aostropolets!

We have death data from the state registry and it contains multiple contributing factors. Most of this data sits outside our CDM because of the restrictions. This idea would allow us to add in all the contributing factors while still maintaining the “cause” of death without duplicating the data.

#50

@aostropolets, so what you propose is to have the discussed cause_of_death table, but get rid of the original death table (logically; not focusing here on naming). Although the solution lacks the ideological modeling purity which for some reason @Christian_Reich doesn’t like, not favoring fundamentals stated by Computer Science, it is better than storing multiple death facts per a person in the death table.

#51

Friends:

That indeed is a wonderful idea. Even purist @pavgra should also carol this, since it abolishes the formerly parallel table with a one-to-one relationship to PERSON. Not sure why this is wrong again. :slight_smile:

Can you put it as a proposal into the CDM WG?

#52

@Christian_Reich, I was misled by the death_type_concept_id field which I assumed to be a characteristic of death fact and treated as a single record per person. But, thanks for your clarification, the type concept is, in fact, represents a source of death cause, so clearly it goes into the cause of death table because it has 1:1 relation with cause. Now the picture is clear for me and causes no more confusion. The only negative consequence is that we lose the link between the death date and the cause which the date was based on.

t