OHDSI Home | Forums | Wiki | Github

Incongruent conventions in OMOP Wiki - DISCHARGE_TO_CONCEPT_ID

#1

@clairblacketer @Christian_Reich @ericaVoss @Alexdavv @Dymshyts et al…

I was reviewing the CDM Wiki to advise on the following question from the N3C team:

For discharge dispositions of “EX”, in addition to creating a record in the death table, can we also update the discharge_to_concept_id in the visit_occurrence table to something other than 0?

I asked @cukarthik, what he does at Columbia and he said, they map DISCHARGE_TO_CONCEPT_ID to 4216643 ‘Patient died’. This is consistent with the VISIT_DETAIL wiki.:

Handling of death: In the case when a patient died during admission (VISIT_DETAIL.DISCHARGE_TO_CONCEPT_ID = 4216643 ‘Patient died’), a record in the Observation table should be created with OBSERVATION_TYPE_CONCEPT_ID = 44818516 (EHR discharge status ‘Expired’).

But the problem is that the VISIT_OCCURRENCE wiki has a different convention:

Handling of death: Visits are not used to indicate a patient’s death. If the source data contains death information in a visit context the date should be derived (admission or discharge) and placed into the death_datetime field of the PERSON table. For details, see there.

If N3C is using OMOP V5.3.1… how do I know which convention is appropriate?

Also worth adding… all of the conventions on the Wiki are further incongruent with the OMOP CDM V5.3.1 github IO. (E.g. the Required fields are not consistent.)

I know, you’re all updating documentation so I’ll leave that. Just need the right rule set of what to enforce here.

#2

They are not THAT conflicting. The second may only say that it should not be the only place to document death. It makes no sense to “discharge to somewhere” and then document death.

Simply do the first convention and document death properly (per v5 or v6). We know that there are “legislation errors” :slight_smile:

1 Like
#3

I mean technically, we could “discharge to afterlife”. :wink:

The problem is that 4216643 is not a valid Visit concept. There’s no Visit concept that would be valid to populate DISCHARGE_TO_CONCEPT_ID.

That is my conundrum.

Put a concept id that is incongruent with the precedent to be a Visit concept. Or put 0 - no matching concept since no valid Visit concept exists to populate this field.

1 Like
#4

Why would you do something like that, @Vojtech_Huser? Bad database habits. The VISIT_OCCURRENCE is right, the VISIT_DETAIL needs updating. The discharge_to denotes a Visit, not death.

That one. The actual death lives in DEATH or PERSON depending on the version. We really should make that nullable. @clairblacketer.

#5

@Christian_Reich, I agree the actual death should be stored in the DEATH or PERSON table. However, to me, having discharged to “expired” makes sense, but I’m biased b/c that’s a code that hospitals use when sending HL7 messages.

I agree patient expired may not be the proper semantic concept for discharge to. Maybe it should be discharged to morgue, but we’d need to add this to the visit domain as well. Anyway, I don’t think we should put 0 or null for the field since the patient did end up somewhere.

1 Like
#6

Hm. Two reasons why I would debate that:

  1. In a relational database you want the same information represented only once. Otherwise you will inevitably create contradictions.
  2. Visits are interactions of the patients with the healthcare system. Most of the time, thank God, the patients are not interacting with the system but conduct their lives. Or they are dead. The discharge (and admission) is meant to be there if the care is not over and the patient continues interacting in other ways with the healthcare system (i.e. rehab or hospice).

So, 0 or NULL means patient is left alone for a while. Let them be.

#7

OMOP spec is clearly struggling with meaning of concept_0 and meaning of null.
Even further - think about HL7 flavors of null. We need to fully embrace that world and not avoid it. NullFlavor - FHIR v4.0.1

In my mind, concept_0 means ‘no matching concept’. ATLAS

I my mind, concept_0 situation means that I have some special local concept that I can’t represent. (missing from dictionary).

But in this case, it is in dictionary but column or table specs forbid me to use it or the vocabulary forbids me to use it (non standard). In this spec/standardConcept conflict situations, do I lie and say “no matching concept”? (even if there is a matching concept).

We then need change the definition of concept_0 or improve the specs or use NULL as another scenario similar to concept_0. Well, I just talked myself to OMOP version of HL7 flavors of null. And it is, (wait for it) “flavors of concept_0”. :slight_smile:

#8

I agree with that we don’t want to duplicate information, but we want to know when a patient is expired during a visit b/c visit_id is not a foreign key to the PERSON or DEATH table. Instead we’ll have to infer if a patient expired during a visit (or using the fact_relationship table :frowning: ). To @Vojtech_Huser’s point null and 0 can mean two different things.

@Christian_Reich, why doesn’t discharge to “morgue” (or something like it) not work since that’s a location and indicate death?

#9

What is the use case for that?

#10

I think the concern is capturing this information in two places. This could potentially be a data quality check if we decide to allow ‘expired’ as a discharge status to make sure that they are all represented as death records as well. Just to play devil’s advocate we don’t currently set admitted from to ‘uterus’ if we know a visit represents a baby’s birth :wink:

I think at the least we need to make sure that all deaths are captured in the DEATH table or PERSON.death_date in v6 to support standard analytics. From there I think it could be up to the data owner how they represent death in discharge status. Happy to keep discussing this point though.

@krfeeney thank you for noting those issues. I have a week set aside at the end of September to package up all our document changes and fix these problems.

#11

I do like uterus on the other end of spectrum from morgue :slight_smile:

1 Like
t