So, our team has supported large public insurance analytic systems (CMS Data Warehouses). We have looked into the usefulness of OMOP’s data however, the layout has always been problematic. (The way you get benefit from it is to move your claims into the OMOP model, which is cost prohibitive for our customer) So, we have taken on the challenge of re-modeling the vocabulary data into a more Traditional BI-Centric model. (One Table per concept wide) Something that can link directly to a medical claim. I would love to get the opinions of folks out there. Sparksoft Corporation: Healthcare Reference Data. The data should be free for the first 20 days, but if you wanted extended free access as an individual, I’m sure we could get that taken care of for you.
Welcome to the family.
If I understand correctly, you took the normalized OMOP vocab tables and joined them to create purpose-built lookup tables for the use cases you typically have, right?
Couple points:
- Consider making this stuff Open Source. It’s the OHDSI way. You won’t make money with this, anyway.
- There is a OMOP query library, consider adding your queries.
On another note: You are saying you are integrating OMOP into claims processing and analytics. This has been a long-ongoing question for folks. And we have always turned them down saying “OMOP is a patient-centric model, not an institution-centric one”. I am problably one of the worst propagandists. However, if you have tables or vocabularies or use cases how to fix that problem there might be a ton of people interested in collaborating. Just a thought.
How would this approach handle vocabulary updates, provenance, and concepts with multiple hierarchies?
I view OMOP as a semantic model that incorporates both OLTP and OLAP design elements, yet it is optimized for neither.
The vocabulary model preserves semantics. Concepts can have multiple relationships, hierarchies, mappings, and sources of provenance. Denormalization can simplify consumption, but it obscures the semantics that make OMOP valuable.
Modern storage technologies such as graph databases and data lakes did not exist when OMOP was originally designed. These technologies may provide better ways to improve usability and performance without sacrificing the model’s semantic richness. Semantic layers built on top of OMOP than in replacing its vocabulary structures with flattened dimensions would be my personal approach.