Step into OMOP with a single line
tl;dr
You can visit our Github repository to easily spin up a containerized version of OMOP’s common data model with flyway migrations.
What is OMOP?
I am continually impressed by the offerings from the Observational Health Data Sciences and Informatics program. In particular, their Observational Medical Outcomes Partnership’s Common Data Model (CDM) promises to standardize the pain we feel in dealing with different healthcare source data systems. I have worked with data from electronic medical records, health level seven feeds, and almost always some form of medical claims.
Harmony sounds well and good, but why is it useful?
Most of my recent projects required training a machine learning model on a different source system than it needed to be deployed on.
For example, at Vituity we build a model to estimate the probability a patient presenting with chest pain in the ER was experiencing acute coronary syndrome. This started with a direct feed from the electronic medical record but had to be deployed on top of HL7 messages in order to be useful at the point of care. The common data model makes this transition seamless.
A single line?
OMOP maintains a thorough repository of its common data model with every flavor of SQL you could need. I wrapped their PostgreSQL flavor into a containerized database with Docker. This means to get started you just execute a single command.
Voila! You have a common data model to start playing with. In the backend, all the SQL is structured specifically so Flyway can easily execute all the commands.
If you want to shut down your database, don’t worry! All your data will be persisted outside of your container.
Future Work
We’ll use this infrastructure as a launching pad for several more posts. Next, we’ll demonstrate how you can banish mapping tables for medical concepts from your database by deriving them from the Athena vocabulary.