Hello @pflugg,
This is a common lament I hear from healthcare systems who provide datasets to their physician researchers. Many health systems have found employing a dozen Bi-devlopers or report writers to pull one off datasets is not scalable, so they “OMOP” their data. But this also brings the challenges you describe and a few others.
The following also trip up the non-informatics professional:
-
There is the domain change for some source codes. Not all ICD codes are found in the Condition table.
-
The CPT4 code found in the Procedure table last year is now located in the Observation table this year.
-
Some source codes might map to > 1 standard concept.
-
There is the perennial problem of US researchers who speak in ICD9CM and ICD10CM language, which is not standard in the OMOP CDM.
The University of Colorado is actively working on a program comprised of education, dataset derivatives, processes and tools to alleviate the pain of transitioning from delivering Epic datasets to OMOP datasets. However, it will still require Bi-developers to take a customer’s data request, transform it to SQL, pull the data, review the dataset to ensure it meets the customer’s and compliance requirements, then deliver the dataset in an approved format. We envision this process to be less labor intensive than our current process of writing SQL for every new request.
We have tried using Leaf, but it doesn’t meet our needs. Atlas is good, but it doesn’t allow download.
Dataset derivatives
- Our dataset derivatives start with a full PHI dataset and then we employ different methods to create LDS and De-Identified views. We have also extended our standard OMOP tables to include the code, code type (aka vocabulary), and description for every concept_id. We also create data marts derived from the OMOP CDM for some projects. We’ve also changed column names to be more investigator friendly.
Processes & tools
-
We have created an excel workbook for customers to define cohort criteria including inclusion & exclusion criteria; time frames; table and field variables of interest; table and field criteria. These are based upon the most commonly requested variables. We are putting the customer in charge of their data request and trying to gain back time spent in 1:1 meetings with customers defining which data elements they need.
-
We have created a data mart derived from the OMOP CDM which matches the standard project requirement workbook to ease the developers translation from the customer excel input to pulling the data from the tables.
-
We have created two dynamic mapping tools. The stored procedure is a SQL function to take the input of a concept_id or code/code type combination and map it to a standard concept_id. The stored procedure also allows the inclusion of child concepts. And returns the domain for the concept. The stored procedure has a companion process for recurring datasets that flag concepts which have changed domains or been mapped to another concept_id since the last time the dataset was pulled.
-
We employ a Tableau based data exploration tool which is similar to Atlas in its code search function. The user can search for codes or concepts of interest, review hierarchies, view patient record counts and descendant record counts. Data can’t be downloaded from the tool, but codes and concepts of interest can be. This tool sits on top of our De-Id OMOP and patient counts < 10 are masked as ‘< 10’.
Education
- This is a two part process and a work in progress. We have to educate the Bi-developers who have been working in Epic for a long time and we also have to educate the users of the datasets. We are creating documentation, educational videos and will be holding “office hours”.
The Healthcare Systems Interest Group meets every other Monday at 10am Eastern time to support health systems on their OHDSI journey. Please join us. Today is one of the Monday’s we meet. I would be happy to host this topic during one of our future calls.
