OMOP on FHIR
EHR FHIR & OMOP
Observational Medical Outcomes Partnership (OMOP)
what are difference to FHIR, what implementations are there e.g. python API?
- OMOP CDM is an open community data standard, designed to standardize the structure and content of observational data and to enable efficient analyses that can produce reliable evidence.
- The OMOP is no longer maintained, and OHDSI is carrying forward the OMOP legacy.
- OMOP mainly focus on Observational data (structured data). FHIR supports multiple resources (Patient, Observation, ImagingStudy) structured and non-structured data.
- For the dicom images, they have a solution: Oncology-CDM extension. park et al. employed this approach [5]
- The key to OMOP CDM is its standardized vocabularies.
- FHIR focuses on providing a secure interoperable environment for health service providers to exchange data and for application resources to access it in place while OHDSI and the OMOP CDM create an environment to support data research [1].
- Analysis tools for OMOP CDM [2]:
- Achilles: It is a R tool to generate report based on OMOP CDM data.
- Atlas: It is a webapp(js) uses webapi to generate visualizations and reliable evidence based on Achilles reports.
- Population-Level Estimation: enable comparisons between cohorts at the treatment level.
- Patient-Level Prediction: predict outcomes from features extracted from the patients, for example, by training Deep Learning models.
- Implementation:
- convert EHR to a database file via different database platforms (MySQL, Oracle, PostgreSQL)
- Using restful API, OHDSI WebAPI has a server that allow user deploy it locally.
- Seems no python API/tools be designed to connect their server.
What is it used for - which domain - clincial/research?
It is a standard and framework for EHR Data holders, to improve both the quality of healthcare data analytics as well as the usefulness of healthcare data to these stakeholders.
Researchers (epidemiologists, statisticians, biomedical informaticists, computer scientists, and clinicians ) -> generate evidence from observational health data.
Four steps to convert data to OMOP Common Data Model (CDM):
Data experts and CDM experts together design the ETL(Extract, Transform, Load)
To achieve this can use two tools: White Rabbit and Rabbit-in-a-Hat designed by OHDSI team.
People with medical knowledge create the code mappings
The OMOP has its own Vocabulary, if the source data (EHR) uses different coding system, the designer should mapping the EHR stuffs to OMOP vocabulary manually via a tool Usagi.
A technical person implements the ETL
All are involved in quality control
ETL:
How extensively is it adopted?
- FHIR is intended for the exchange of data between different institutions. Whereas OMOP provides a common data format to unify data from different databases [3]. - Github stars: 117
OMOP on Fhir[1]:
Architecture: [OHDSI environment: WebAPI] -> [OMOP on FHIR: HAPI FHIR Server + OMOP v5 data repository + FHIR DSTU2(quite old) seems move on v3 now?] -> [SMART on FHIR]
Platform architecture Fig1:
issues:
- Some key FHIR elements: patient demographic information, not in OMOP CDM.
Data Mapping [1]: - OMOP to FHIR (DSTU 2)
FHIR to OMOP:
- Because the FHIR covers a lot of information than OMOP CDM, so they decide to ignore the elements that cannot be mapped to the OMOP CDM unless FHIR requires these in the first version[1].
Relevant study:
Data infrastructures for AI in medical imaging: a report on the experiences of five EU projects [4].