OHDSI Home | Forums | Wiki | Github

Conventions on storing ventilation data

CDM Builders
#1

Hi all!

I am working with the ventilation data and was wondering if there are any established conventions on how it should be stored (which CDM tables should be populated and at which level).

In source data there is an information on the device, oxygen therapy, associated device parameters and etc. I am attaching below a simple data example to hear your feedback on populating CDM tables.

Source:

Record 1:
source value = O2 therapy Device nasal cannula
date = 2020-01-01 09:00:00

Record 2:
source_value = O2 oxygen therapy 3 L/min
date = 2020-01-01 09:00:00

Record 3:
source value = O2 therapy Device nasal cannula
date = 2020-01-01 10:00:00

Record 4:
source_value = O2 oxygen therapy 2 L/min
date = 2020-01-01 10:00:00

Record 5:
source value = O2 therapy Device nasal cannula
date = 2020-01-01 11:00:00

Record 6:
source_value = O2 oxygen therapy 2 L/min
date = 2020-01-01 11:00:00

Procedure_occurrence:

Record 1:
procedure_concept_id = 4239130 (Oxygen Therapy)
procedure_datetime = 2020-01-01 09:00:00

Record 2:
procedure_concept_id = 4239130 (Oxygen Therapy)
procedure_date = 2020-01-01 10:00:00

And etc.

Measurement:

Record 1:
measurement_concept_id = 4141684 (Delivered oxygen flow rate) or 3005629 (Inhaled oxygen flow rate)
measurement_datetime = 2020-01-01 09:00:00
value_as_number = 3
unit_concept_id = 8698 (liter per minute)

Record 2:
measurement_concept_id = 4141684 (Delivered oxygen flow rate) or 3005629 (Inhaled oxygen flow rate)
measurement_datetime = 2020-01-01 10:00:00
value_as_number = 2
unit_concept_id = 8698 (liter per minute)

And etc.

Device_exposure:

Device_concept_id = 4224038 (Oxygen nasal cannula)
device_start_datetime = 2020-01-01 09:00:00
device_end_datetime = 2020-01-01 11:00:00

Drug_exposure:

Drug_concept_id = 19025274 (Oxygen)
drug_exposure_start_datetime = 2020-01-01 09:00:00
drug_exposure_end_datetime = 2020-01-01 11:00:00
route_concept_id = 45956874 (inhalation)

Open questions:

  1. Would it be better to have individual Device and Drug exposure records instead of aggregated?
  2. If the approach above of populating CDM tables is correct?.
  3. Any other CDM tables/ fields to be populated?

I am tagging people who answered in other posts on ventilation data. Hope you don’t mind :slight_smile:
@cukarthik, @Christian_Reich, @MPhilofsky, @Dymshyts, @Vlad_Korsik, @Alexdavv
Any feedback is welcome!

2 Likes
ETL High-Level Ventilator, Dialysis, CVVH Data
#2

For v5.3, I think this is the best and most correct way to store all the relevant facts for supplemental oxygen. I really like the addition of oxygen to the Drug Exposure table! This allows researchers to use the Drug Era table for supplemental oxygen use.

I’m not intimately involved in the N3C research for COVID. I wonder if they have modeled supplemental oxygen use for the CDM? Adding @krfeeney

1 Like
#3

You know, I was really hoping if I sat still long enough someone else would tell me the answer so I didn’t have to write the mapping myself :wink:

We haven’t tackled this (yet) in N3C. We want to. We’re planning to host a panel around data elements that we want to bring in even though they’re hard to ETL.

My thinking is this: can you think of a clinical question that can be answered by going for an individual approach? Or are more of your researchers asking for the aggregate?

I don’t know the answer yet. People are pounding the table for vent data but no one seems to like to write fully specified protocols. :smiley:

#4

Friends:

Oxygen is a drug. Not a procedure. Ventilation or intubation are procedures. Question is how to represent the 2 L/min. Sounds like we need to add RxNorm Extension for this.

#5

oxygen is a drug?

#6

Is it not? It’s a substance that is exerting a biomedical effect on the organism.

1 Like
#8

Most CMDs are not reporting it in the Drug domain.

#9

@Christian_Reich
Despite this seems to be not obvious, I like this idea.
And we can look into patient data and see what is the min - max range and create concepts with dosage step of 0.1 L/min.

#10

What’s that?

#11

what I meant was if patient is receiving oxygen, it is not reported as a drug.

#12

I also have another question. If source data has immunization records with CVX code and manufacture information, where can I store the manufacture information in the Drug domain?

#13

The Procedure part of oxygen deliver is implicit, correct? Similar to the injection is implicit to the vaccine. There isn’t a need to record the Procedure of continuous oxygen delivery. I like it. We should add it to the conventions.

Oxygen: drug_concept_id at the ingredient level. Oxygen is dosed in liters per minute and/or at a percentage. We can convert liters per minute to a percentage. Then put the numeric to the quantity and the % to the dose_unit_source_value. Probably should bring back the dose_unit_concept_id we keep talking about in the CDM WG.

Device used to deliver the oxygen will live in the Device table.

#14

Doesn’t blood in a transfusion exert a biomedical effect on an organism? Yet blood is a device.

#15

@Christian_Reich, @roger.carlson makes a good point on that. The more I’ve looked at transfusions, the more I’m thinking it fits in the drug table based on the attributes (fields) the table captures

#16

Hello everyone!

I have a different question in the topic, about conventions on storing ventilation data. In our HIS the ventilation data for more days is stored as a quantity for a ventilation procedure, without exact dates.

For example:
Intermittent positive pressure mechanical ventilation with endotracheal intubation (days of care), quantity: 15
It means the patient was at the hospital and was intubated and mehcanically ventilated for 15 days, but if the patient stayed in the hospital for more than 15 days (it is usually the case), the exact date of the ventilation is unknown.

We have two ideas about mapping this:

Prodecure occurence table:
procedure_concept_id = 44790095 Invasive ventilation
quantity = 15

Observation table:
observation_concept_id = 4163858 Ventilation
value_as_number = 15
unit_concept_id = 8512 day

The problem with the first one, that no one will know, that the quantity represents the days. The problem with the second one, that there is no standard concept in the observation domain, which represents the invasive ventillation, and also there is no unit_source_value in our system.

Do you have any ideas or other solutions?

The use case is, that maybe someone would want to do a research about lenght of ventillation among COVID patients.

Thank you in advance! :slight_smile:

Source data fields that cannot be mapped to OMOP fields
#17

Oh, neither option is any good. How would you know the ventilation is related to your Covid use case and not drug overdose, surgery or some other reason people are ventilated?

The inner @Christian_Reich in the back of my head says “maybe someone would want” isn’t a use case. See his post about the “attic” approach.

A use case is a well defined question. Wait until you have one, then dig deep into the source data to find and ETL all relevant data to the CDM. We’ll be here to help :slight_smile:

1 Like
#18

Thank you @MPhilofsky!

I must have misunderstood the definition of “use case”, I’m still new here. I read the discussion about the attic approach, thank you, it helped a lot. :slight_smile:

I think for us it means that this approach to mapping these procedures it going to be good enough.

Prodecure occurence table:
procedure_concept_id = 44790095 Invasive ventilation
quantity = 15

It does not contain false information, and if anyone wants to know what quantity means, they can look it up in procedure_source_value.

Do you also think this is a good enough solution for mapping these types of procedures? We have quite a few of these.
There is no use case yet, we are currently in the process of joining EHDEN.

#19

Welcome to OHDSI and the journey :slight_smile:

In this case, leave the data in the source instead of trying to push it into the CDM for the following reasons:

  1. In order to have a clinical event, you must have a date. procedure_date is a required field. Your data lacks a date. You can’t do research on something if you don’t know when it happened.
  2. All network research is conducted using persons, dates, and standard concept_ids. No one will know or have access to your source_value fields.
  3. IF EHDEN needs ventilation data for a study, they will work with you on properly ETLing the data to the CDM so it is accurately represented and useful in the CDM. Currently, a quantity = 15 will be interpreted as 15 procedure_concept_id = 44790095 Invasive ventilation. When ventilation data are properly ETL’d to the CDM, the difference between the procedure_date and procedure_end_date will signify the number of days the person had the ventilation procedure.

ETLing the data is the most difficult part of the OHDSI journey. Once the data are in the CDM, the analysts and researchers using the data shouldn’t have to guess what, where or how the data got into the CDM. The data need to be semantically harmonized to standard concept_ids and structurally standardized. They need to be able to trust the results of the aggregated results you provide when a study is run at your site. Therefore, we all have to do it the same. ETLing to the CDM is a continuous journey. Start with the clean, obvious data and then ETL more as the use cases are defined and the data are needed. You don’t and shouldn’t try to do it all at once.

You’re using CDM version 5.4, correct?

#20

Welcome to OHDSI and the journey :slight_smile:

Thanks, we are happy to join :grinning:

You’re using CDM version 5.4 correct?

Yes, I think we are using CDM version 5.4, but I work with another organisation with a similar problem, and I think they are using 6.0. Does it make any difference?

t