mapping range measurements to OMOP

[Leon_Derks]

We are working on the ICUdata project in the Netherlands (https://www.icudata.nl/). Within ICUdata we are currently in the process of mapping our model to OMOP. One issue we are struggling with is that in our current data model we have some range measurements (see data concepts with range measurements below). The main issue is how to map those range measurements to OMOP. We discussed two options which both do not seem ideal. One option is to map the range measurements as single timestamps to OMOP Measurements. However, in this case there is no end_timestamp field in OMOP. For some data concepts an option would be to map range signals to procedure_occurence table. The issue here is that there is no value column. We found this old thread on a OMOP forum that seems to suggest using single timestamps for fluids.

Contacting Renske Los she suggest looking at device_exposure tabel, based on this part of the forum (Mapping Transfusion Data - #8 by bailey).
She also suggested to start a discussion here, and tagging. @Christian_Reich and @RenskeLos

The ICUdata concepts that have range signals:

• transfusion_volume
• fluid_in_cvvh_dialysis
• fluid_intake_intravascular_measured
• fluid_intake_parenteral_feeding
• total_parenteral_nutrition
• enteral_feeding

Looking forward to your input/suggestions/experiences!

[Christian_Reich]

@Leon_Derks:

Very valid inquiry. I am surprised we haven’t had this much more often.

The problem is regression to the current situation: All Measurements have one amount, not two, and most tools expect that. And it makes sense, in >99% we have just one measurement. So, adding a lower_range and upper_range will require all of this to change. Also, it is not clear what the analyst would do with those two values when the use case is to, say, produce an overall average in a population.

The solution we discussed (but never implemented) is to add an error value. So, instead of upper and lower you record the mean in the value_as_number and the ± (=(upper-lower)/2) in a new field plusminus or value_error. That way, the analytic can treat the records exactly the same as the other precise ones. But it is possible to to pay attention to the uncertainty of the values.

We would have to propose that field as an “Extension” (change to the CDM which will be adopted in a future release, but can be implemented today) to @clairblacketer’s CDM WG.

Thoughts?

[MPhilofsky (Melanie Philofsky)]

Welcome to OHDSI, @Leon_Derks!

@Leon_Derks

The ICUdata concepts that have range signals:

• transfusion_volume
• fluid_in_cvvh_dialysis
• fluid_intake_intravascular_measured
• fluid_intake_parenteral_feeding
• total_parenteral_nutrition
• enteral_feeding

These don’t look like OMOP Measurements which are defined as “structured values (numerical or categorical) obtained through systematic and standardized examination or testing of a Person or Person’s sample”. These look like volumes of blood, blood products, fluids and nutrition. When you say “range measurements” what is the range? Time, amount of substance or something else?

[Mark (Mark Seal)]

@Christian_Reich

The solution we discussed (but never implemented) is to add an error value. So, instead of upper and lower you record the mean in the value_as_number and the ± (=(upper-lower)/2) in a new field plusminus or value_error.

This is used in other fields(engineering, financial) to great success, so I see no reason it cannot here.

[Leon_Derks]

Hi, thanks for your quick replies. To answer @MPhilofsky . I should maybe indeed have clarified what we mean with range in this case. For these values range relates to time. Basically we miss the end_timestamp field in OMOP to calculate the amound giver per hour over a number of hours.

[MPhilofsky (Melanie Philofsky)]

@Leon_Derks

The first thing you do when you OMOP your data is map the source codes/values to standard concept_ids. The domain_id for the standard concept_id will tell you which table your data live in the OMOP CDM. Read The Book of OHDSI, specifically chapters 4 - 6, to learn about the OMOP CDM and how to ETL your data.

Of the clinical event tables, only the Drug Exposure table has an end_date which is mandatory. The conventions for how to populate the drug_exposure_end_date when there isn’t an end date in the source are located here.

[Prathiksha_Singh]

Hello all,
I’m Prathiksha Singh - a colleague of @Leon_Derks and a Data Engineer also working on the ICUdata project.
Thank you all for your responses, thus far.

@MPhilofsky, we have implemented the ETL for many OMOP tables, including Drug Exposure and Measurements, however, there are still aspects of the mapping of range measurements to OMOP that remain unclear.

The uncertainty we’re facing with regards to range measurements (and to clarify, this includes measurements such as fluid intake/output that we categorise as measurements quantified over a range of time ) is that these values should be stored within a data model that closely resembles OMOP Measurements but also includes an end_timestamp column.

In another channel discussion, it was mentioned that the OMOP Device Exposure table is sometimes used for these use cases (i.e. measurements/signals taken over a range of time) - can this be confirmed?
Or is there an alternative solution that is otherwise used?

[MPhilofsky (Melanie Philofsky)]

Hello @Prathiksha_Singh and welcome to OHDSI,

@Prathiksha_Singh

In another channel discussion, it was mentioned that the OMOP Device Exposure table is sometimes used for these use cases (i.e. measurements/signals taken over a range of time) - can this be confirmed?

The forum thread you mention is specific to blood transfusion data. And blood transfusions have domain_id = Device. So, these data live in the Device Exposure table. The examples @Leon_Derks listed above look to be blood transfusion, iv fluids, and various nutritional fluids given via intravenous or GI route. All are liquids, but have very different mechanisms of action and purposes when used as a treatment on the human body.

If the standard concept_id representing the row of data has domain_id = ‘Device’, then yes, these data can be stored in the Device Exposure table. If the domain_id = ‘Measurement’, then the data must go to the Measurement table. This is rule of the OMOP CDM. The analyst using the data won’t know you broke the rules. Atlas won’t know data aren’t where they are supposed to be. So, we always follow the rules. But designations and rules can be changed and the OMOP CDM can be extended.

So, here’s what you do. First, you map the source values/codes to standard concept_ids. If these source values/codes don’t map to one of the clinical event tables with an end_date, then you have a few ways to resolve this issue. If you believe the standard concept_id is assigned to the wrong domain, then contact the Vocabulary team (either via their GitHub issues or ping them on the Vocabulary forum) to discuss the issue. If you think the domain assigned to the standard concept_id is correct, but you need an end_date to do your research, bring the issue and your use case to the CDM work group. They are in charge of changes to the data model.

[Prathiksha_Singh]

Thanks so much for your reply @MPhilofsky.