Some time in early November, it appears to us that the ‘Maps to Unit’ relationship_id was dropped from the concept_relationship table, which caused all of our Units in the Measurement table to suddenly become unmapped. Was this change done on purpose or is this an error? If by design, can somebody point me to where this was pre-announced since we obviously missed it for over 5 weeks and have been releasing OMOP data sets with this error. I want to make sure that I know where to look so we can be proactive rather than reactive to an investigator’s complaint about their OMOP data set.
Hello, @mgkahn
Sorry for that awkward silence.
The problem is a little bit unclear: can you please provide us some examples of concepts that used to have relationships ‘Maps to Unit’ and now they don’t.
I am looking at older versions of vocab from 2019 and can’t see any ‘Maps to unit’ relationships.
1 Like
The folks who brought this issue to my attention are laying low for the holidays. I’ll ask that they give you the details directly rather than thru me. I also looked at a very old concept_relationship table and did not find any instances of Maps To unit. So maybe I got the story wrong. But something changed in the vocab tables that broke our ETL into this field that was fixed by altering our ETL pipeline. Clearly, I need to get out of the middle of the conversation and have the folks who found and fixed the problem post here directly. Look for something after the holidays.
However, the ETL pipeline that maps into the units field is working again with some change to our ETL logic.
It might be custom relationships, that dropped because target concepts became non-standard or invalid.
There are other options indeed.
Anyway, happy holidays!
OK mystery solved and egg on my face for pointing the finger at Athena releases.
After being told otherwise, upon closer inspection, “Maps to unit” is a custom relationship_id that was used internally but was recently taken down to move our ETL back to the more standard “Maps to” relationship_id. Some of the ETL code however, was still “looking” for the now-gone “Maps to unit” in our custom mappings.
Bottom line – it was a Colorado thing after all and I should not have pointed the finger at Athena.
Bad Michael…
Bad Colorado thing. 
But: The need for “Maps to unit” is not gone. When you need to split up codes like “Cholesterol above 140 mg/dL” for example. We are now preparing to add the wide mapping table for these situations.
Thoughts?
My New Year’s resolution is to not post anything that I myself have not directly validated rather than passing along statements from others…
@MPhilofsky will need to comment on the above proposal for Colorado. We just completed a 100% rewrite of our ETL code so I don’t know how we are addressing the issue above today.