OHDSI Home | Forums | Wiki | Github

Death mapping to the CDM table

Vocabulary Users
,
#1

The Github issue was raised concerning mapping of duplicative HCPCS concepts “Patients who died from cancer”. In the course of the regular HCPCS update we are going to solve this issue, and we suggest the following proposal.

Currently, we only map between concepts. But according to the CDM 5.4 convention “Death” in itself is not a concept, but a record in the “Death” table of CDM. Thus we suggest mapping of the concepts associated with death of a patient to the CDM table:

1147312 CDM368 death Table Standard Valid Metadata CDM

Essentially, this mapping may be applicable to the concept

4306655 419620001 Death Event Standard Valid Observation SNOMED

and its descendants.

Examples of potential source concepts are provided below:

1314522 G9849 Patients who died from cancer HCPCS Standard Valid Observation HCPCS
4253799 74332007 Death by asphyxiation Event Standard Valid Observation SNOMED
763386 440061000124105 Death in nursing home Event Standard Valid Observation SNOMED
4024541 10588007 Perinatal death Event Standard Valid Observation SNOMED

The cause of death will be additionally mapped to the Condition domain. The ETL team may use this mapping to trigger the creation of records in the “Death” table where applicable and extract the cause of death if the source concepts are mapped to “Death” and the Condition domain.
If a concept has to turn into a different type of record in the data model we also let the ETLer figure that out. What we could do is to start a convention where we link concepts representing tables and fields.

We would be glad to hear the Community’s opinion on this approach.

#2

This is a valid problem in need of a solution. We may need a domain “Death” for this one concept. And it is probably a convention to be legislated by Themis. @MPhilofsky, @clairblacketer?

#3

Yes, this is a Themis issue. BUT, how accurate are these data? We should test the real data before we think about updating the conventions

Did anyone ever compare the ICD9/10CM codes indicating death with actual Death records?

#4

Another use case would be HCPCS/CPT4 Visit concepts that indicate too general visits that can’t be mapped to any of the Standard visit concepts, but still may trigger the creation of the visit_occurence record (instead of the default Observation records).

@Maria_Khitrun Can you please provide a couple of examples with different situations?

@Christian_Reich @MPhilofsky @clairblacketer

Who creates visits from HCPCS codes?
#5

The following HCPCS concepts can illustrate the idea:

44786454 G9249 Patient had a medical visit in the last 6 months HCPCS Standard Valid Observation HCPCS

2720818 Q5009 Hospice or home health care provided in place not otherwise specified (nos) HCPCS Standard Valid Observation HCPCS

43533175 G0454 Physician documentation of face-to-face visit for durable medical equipment determination performed by nurse practitioner, physician assistant or clinical nurse specialist HCPCS Standard Valid Observation HCPCS

915648 G9522 Total number of emergency department visits and inpatient hospitalizations equal to or greater than two in the past 12 months or patient not screened, reason not given HCPCS Standard Valid Observation HCPCS

2721641 T1019 Personal care services, per 15 minutes, not for an inpatient or resident of a hospital, nursing facility, icf/mr or imd, part of the individualized plan of treatment (code may not be used to identify services provided by home health aide or certified n… HCPCS Standard Valid Observation HCPCS

45890698 G9433 Death, permanent nursing home resident or receiving hospice or palliative care any time during the measurement period HCPCS Standard Valid Observation HCPCS

#6

@Maria_Khitrun:

Nice examples illustrating the difficulties you are in. These are clearly not for reporting longitudinal patient data, but generic for justifying payments. The beauty of “or” concepts. Unfortunately.

The first one is useless. If the data don’t contain a visit you cannot create one based on this.
The second could theoretically be used to create a VISIT_OCCURRENCE record, but without a visit_concept_id. Pretty useless.
The third one as well. We don’t know what kind of visit.
The fourth one is like the first one - useless.
The fifth could be turned into a home service visit.
The sixth and last one - useless.

#7

What you’re suggesting @Christian_Reich is that we’ll make them non-Standard and not mapped, correct?

And the VISIT_OCCURRENCE records with 0 visit_concept_id are not better than the Observation records with 0 observation_concept_id.

Another option could be an assignment of the Visit Domain to these poor concepts, but:

  • Then ETL needs to create the Visit records relying only on the source concept Domain which is not happening usually, as far as I know,
  • It’s hard to keep track of the Domains of the source concepts - it’s done in chunks and script-wise. If the concept undergoes a manual review, this mapping to the Visit record would be a means of distinction.

BTW, how would we accommodate the mapping to the table/fields to the wide mapping table design?

t