OHDSI Home | Forums | Wiki | Github

THEMIS Conventions for Death Table to Allow Multiple Records - Version 5.4

This is an open forum discussion for:
THEMIS issue #79
Multiple Death Records Due to Death_type or Cause - Version 5.4

This issue has been discussed multiple times over multiple years (see Related Posts below). There has even been a THEMIS thread proposing a solution. However, the issue remains, and we’d like to stick a pin in it for good.

Issue Name: Multiple Death Records Due to Death_type_concept or Cause_concept Version 5.4

Issue Type: Duplicate records caused by multiple standard concept_ids for death cause or death type (provenance)

Description: OMOP CDM v5.4
The table description for the Death table has the following: “A person can have up to one record if the source system contains evidence about the Death”. However, an ICD diagnosis code may map to multiple SNOMED codes:

ICD10: J96.21 (Acute on chronic respiratory failure with hypoxia (HCC))
maps to
SNOMED: 389086002 (Hypoxia) and 67905004 (Acute-on-chronic respiratory failure)
This results in two records with the same death date.

Similarly, a person may have death records from multiple systems (provenance), i.e. EHR and death registry.

Suggested Solution: For OMOP version 5.4, allow multiple records in the Death table caused by either the death_type_concept_id and/or cause_concept_id. However the Death_Date(s) must match.

Possible Implications:

  • CDM documentation will need to be modified.
  • The rules of the DQD (Data Quality Dashboard) will have to be adjusted to match. @clairblacketer
  • Question @Chris_Knoll on whether this change will affect Atlas. Does Atlas expect only one death record?

Related forum posts:

Reported By: Roger Carlson
@Chris_Knoll @Christian_Reich @katy-sadowski @MPhilofsky @clairblacketer @lychenus13 @Polina_Talapova @ericaVoss @QI_omop @Mark @hiro-mishima @cukarthik @PriyaDesai @jmethot @Vojtech_Huser @aostropolets @pavgra @Patrick_Ryan


There has been no discussion on this. I’m bumping it. :slightly_smiling_face:

I have another potential solution that may not impact tooling as much.

Preferred Concepts Based on Context (Death)


  • ETL creates multiple records, then drops duplicates keeping the single ‘preferred’ concept_id for the context.
  • Both records must have the same person_id, date, and death_type_id for this drop to occur
  • All dropped records with non-preferred concept-id’s would be retained in cause_source_value as a list VARCHAR[code1, code2, code3]

In the context of cause of death, ICD10(J96.21) maps to SNOMED(67905004 (Acute-on-chronic respiratory failure)) would be the preferred term and used as the cause_id.

Both codes would be included in cause_source_value as a list [67905004, 389086002] with the preferred term being first.


  1. Hypoxia is a disposition (an intrinsic characteristic) of the object(person) in the state of reduced oxygen supply to tissue.
    - This state can be both chronic (e.g., COPD) and emergent (e.g., asphyxiation).
    - This state can be the result of singular or plural system deterioration and is an inherent feature of the object(person) respiratory or circulatory system.

  2. Acute-on-chronic respiratory failure is both a disposition and a role (context dependent) of the object(person) in the state of critically deteriorated respiratory function
    - This state is temporary (it will either be recovered from or be fatal).
    - This state is not an inherent feature of the respiratory system, it is contingent on the current state of the object(person) health.

  3. Acute-on-chronic respiratory failure would be the ‘preferred’ concept_id as a cause of death because it more accurately aligns with a direct cause of death.


  • Increase accuracy for cause of death.
  • Tooling would not need to be adjusted or re-coded.


  • Potentially significant undertaking by the Vocabulary WG to create ‘preferred’ concept lists for cause of death for each vocabulary.
  • We would need to find a feasible way to distribute the ‘preferred’ concept list. This could through using one of the concept tables or establishing a ‘Death’ domain.
  • VARCHAR is a bad way to save lists and not all programming languages and database systems interpret lists the same way (this more of a technical issue for reproducibility or reversing an ETL)