Mapping Diabetes Data Model to OMOP

Implementers
1

Hi everyone,

I am currently working on mapping type I diabetes data specifications to the OMOP Common Data Model (CDM) as part an initiative known as the Rising T1DE Alliance. The goal is to enable diabetes technology data integration into EPIC. However, I have encountered some challenges:

This project aims to integrate diabetes technology data into EPIC by mapping type I diabetes data specifications to OMOP.

Challenges I have 33 fields in the diabetes data model that do not have equivalent concepts in OMOP. Additionally, there are 103 allowed values in a field that also lack equivalent concepts.

Validation Needed:

Examples: Here are a few examples of the fields and values I’m struggling with:
Field 1: ins_pump_model is the insulin pump’s model. I mapped this field to the observations table and the following fields: 1) observation_concept_id 2) value_as_string 3)value_as_cocnept_id.

  • For the observation concept, there is no concept that represents a universal concept of insulin pump models.

Field 2: hypo_sym, defined as the patient’s ability to self-identify hypoglycemia presence of symptoms. I mapped this field to the observations table and the following fields: 1) observation_concept_id 2) observation_date 3) value_as_concept_id 4) observation_source_value

  • For the observational_concept_id there is no concept for a self-observed hypoglycemia event

Allowed Value 1: In the Providers table of the type I diabetes data specifications, the field named “provider_type” has multiple allowed values.

The following allowed values for this field do NOT have equivalences: 1) CDE - Certified Diabetes Educator 2) OD - Optometrist 3) OT - Occupational Therapist 4) OTH - Other Person

Questions:

  1. Has anyone faced similar challenges? How did you resolve them?
  2. What are the best practices for handling fields and values with no direct OMOP equivalents? Are there any recommended strategies or tools that could help bridge these gaps?

Next Steps and Suggestions:

So far, I have:

  • Conducted a thorough review of the OMOP vocabulary to find equivalences. Any experiences, resources, or tools that could help would be greatly appreciated. For example, how do you handle fields with no direct matches? Are there any community standards or workarounds that you recommend?

  • I would love to connect with someone from the OHDSI team to review all of my mappings for validation as we move forward with enhancing the quality of care delivered to people living with diabetes.

Thank you in advance for your help!

Best regards,
Eric

2

Hi @Ekwillj: Welcome to the family.

An insulin pump is a medical device, to be recorded into DEVICE_EXPOSURE. Any reason you wouldn’t want to use that?

You need the ability to self-detect, or you need the fact of self-detection? The former is tough, I can’t think there is any definition what that would look like. The latter is easy: All you have to do is to record Hypoglycemia in CONDITION_OCCURRENCE and place the Patient self-report into the condition_type_concept_id field. That’s how the OMOP tables work. They record facts and the source of that information in two separate fields.

We call that field provider_concept_id, and the concepts that go in there have the domain_id=‘Provider’: Registered Diabetes Educator Nurse, Optometry, Occupational Therapy (I know, grammatically they are inconsistent, sometimes denoting a specialty and sometimes denoting a carrier of a specialty. Comes with the source vocabularies).

“Other” is evil and meaningless. OMOP is mostly a Closed-World data model. We record facts. Lack of a record means the fact did not happen. There is no need to record “Information not there”, or as we call it, Flavors of NULL. If you don’t know who did XYZ, don’t record anything, just drop the record.

3

Hi @Christian_Reich ,

Thank you for your response.

For field 1, you are absoluteley correct. However, rather if we decided to use either the observation or device_exposure table, there is no conceptual equivalent available that represent the general ideology of an insulin pump model.

For field 2, the variable hypo_sym is defined as the fact of the patient reporting a self-detected hypoglycemia episode. I will make adjustments based on your recommendation.

Would you or anyone a part of the OHDSI team be able to further connect with me to review the entire data model’s mappings to OMOP?