OHDSI Home | Forums | Wiki | Github

PCORNet to OMOP Custom Mapping Concepts needed

Vocabulary Users
,
#1

I am new to this site and new to OMOP CDM! This question may have been asked before, but I’ll give it a shot anyway…

We are currently working on converting our PCORNet data to OMOP cdm. It appears that certain source (PCORNet) values do not map to OMOP concepts. For example, the PCORNet enrollment table has a field called ENR_BASIS. One of the values listed in that field is: “Outpatient prescription drug coverage” referenced by the character ”D”. We can not seem to find an OMOP concept to map to. What is the best method to map this value without any loss of semantics. Would this require a custom mapping on our part?

#2

Your are going to find a lot of items in PCORnet that do not map directly into OMOP. First question should always be, it the item important to what we are plan to use OMOP for. Have you needed to look at the ENR_BASIS values when using PCORnet?
Because the study of drug interactions is critical to most OHDSI studies, there is an assumption that people included in the CDM have prescription benefits (the ETL explicitly exclude people lacking drug coverage). Hence there is no need to have an attribute saying a person has outpatient prescription drug coverage.
All along the way in your PCORnet to OMOP conversion you are going to have to decide, for items that do not map directly into OMOP, is it important, and if so, how to represent the information in OMOP. For you specific example, look at the Payer Plan Period table and see if the Plan Type concepts are sufficient.

#3

Thank you @DTorok
In general, I think the original goal was to have very little data loss in the conversion process, but we are quickly seeing that many pcornet concepts do not map effectively. We’ll plan to reassess needs, but for this question specifically, I believe that we may be able to find something that will suffice from the payer_plan_period table.

In this case, is custom mapping something we would consider?

#4

With this goal in mind, you should ETL directly from your source data to the OMOP CDM. Otherwise, you will have two transformations with the potential for loss during each transformation. One from source to PCORNet and then another from PCORNet to the CDM. If you must go from PCORNet to OMOP, custom mapping is the answer. You will retain the original, PCORNet source value while mapping to a standard concept_id in the OMOP vocabularies. This will allow you to do network research while meeting your institution’s need to retain the source value. I see you have like my other post on custom mapping, but I’ll also link it here for others who read this post.

You might want to ask around the PCORNet community to see if others have a PCORNet to OMOP script.

EDIT: Also, Don is spot on in his above post. Ask yourself if you have a use case for the data. Don’t waste time & resources bringing in data for the “just in case” scenario. You can always bring in more data later. Your source data and the OMOP CDM are continuously evolving.

#5

@MPhilofsky Thank you! This is very helpful and clears up some concerns with this conversion. I believe someone on our team is researching the ETL script PCORNet to OMOP, so we should be on the right track for now! The information from both you and @DTorok have given me great insight. The custom mapping information link is also very helpful. I appreciate your time.

t