Healthcare data can be sparse, heterogenous, making the integrated analysis difficult. There are growing efforts to harmonize the multimodal data to enable cross talk between various informatics systems in healthcare. 

The two of the main interoperable standards are Fast Healthcare Interoperability Resources (FHIR https://www.hl7.org/fhir) and Observational Medical Outcomes Partnership (OMOP https://ohdsi.org/omop/). They are developed for different real-world usage and needs. 

FHIR

FHIR is a health information exchange standard that defines a specification of API based exchange of health information content in a standard, simplified data model to facilitate information sharing between health information systems such as EHRs (electronic health record), PHRs (professional health record), payer systems, personal medical devices, etc. 

FHIR allows on-demand access to componentized patient health data along with cross references to other related information. FHIR systems typically support transaction-oriented tasks or processes. 

OMOP

OMOP provides similar capabilities for the sharing of health research data using a common data model (CDM) for relational databases. The OMOP CDM allows for the systematic analysis of disparate observational databases and supports analytical tasks or processes.

FHIR based systems usually provide capabilities on an individual basis (Patient) basis. OMOP works at a cohort level.

Data from systems like FHIR end up in OMOP databases through data pipelines. And OMOP allows for analyzing this data as a whole. FHIR systems can be viewed as transactional in nature (storing day to day data as it happens) and OMOP databases are more like data warehouses that aid in reporting and analyzing the data after the fact.

The primary objective of this project is to model clinical data for the entire hospital record in FHIR to OMOP CDM standards and apply analytics on this standard data format to answer several questions relevant to research and patient care. 

Data is stored in different formats in FHIR and OMOP systems. There needs to be some kind of transformation. We need to convert data in one format to another.

Once the data is published to OMOP CDM, the focus will be to make use of a tool like Atlas (https://atlas-demo.ohdsi.org/) or custom R or Python applications to perform observational analyses to generate real world evidence from patient level observational data.

• Assess the cross talk of data between FHIR - OMOP vocabularies using available open-source libraries
• Deploy a translational API/Batch process in a sandbox that converts FHIR to OMOP CDM
• Test the API/Batch process on a real-world EHR data based in FHIR format and evaluate the data conversion quality
• Implement analytics over the OMOP data to test the pipelines validity

FHIR: https://www.hl7.org/fhir

OMOP: https://ohdsi.org/omop/

Tasks completed

• OMOP CDM was set up in CAMH and loaded with the standard data
• Patient data from CAMH data mart to OMOP CDM was completed
• Encounter data from CAMH data mart to OMOP CDM was completed
• Extracted all the conditions data in CAMH data mart to provide input data for Usagi tool
• Used the Usagi tool to generate source to standard mapping for all the conditions relevant to CAMH
• Updated source to standard mapping table for all different source vocabularies (ICD10CA, DSM5CA, DMSIVTR, SNOMEDCT)
• Condition data from CAMH data mart to OMOP CDM was completed
• Extracted MULTUM vocabulary from Athena for loading into OMOP CDM

Learnings

• While I have worked in healthcare sector previously, I did not know anything about FHIR or OMOP. The project provided a great opportunity to learn and understand the challenges faced by the research community due to the disparity of systems in the healthcare domain
• In the initial months of the project, researched FHIR protocol and spun up a FHIR instance on Azure with sample data. It gave me an opportunity to learn about FHIR
• Got to dabble with Bluebrain Nexus as well in the initial stages and gained an understanding of the RDF data format
• Explored JSON-LD formats for extracting data from Bluebrain Nexus
• Had not previously worked with Postgresql database and this project gave me an opportunity to familiarize myself with the Postgres related tools and use them to set up the entire OMOP CDM on it
• Set up an OHDSI in a Box on AWS to familiarize myself with all the tools without data concerns as the set up came pre-populated with the data
• Started with building a .NET app using this project (https://github.com/OHDSI/FhirToCdm) which is .NET based, but in the end did not come to use it

Challenges

• Getting familiar with OMOP terminology took time
• CAMH conditions were unique to mental health but the information around mental health vocabularies was quite limited. While there is a Psychiatry working group, it was hard to find any information relevant to this work
• OHDSI ecosystem and the tools under its umbrella are significant in terms of scope of functionality and did consume time to understand what they do and how they need to be configured
• Had to watch several videos on OMOP to understand the database relationship model and some of the reasoning behind the structure
• Identifying the different vocabularies (standard and non-standard) and how to map those that are not provided by OHDSI with the standard ones proved very challenging. Even though there was documentation, it still required scouring the OHDSI discussion boards for validating if I was on the right track with my approach
• Spent a lot of time in the initial months to decide on what is the right source for data. If this decision could have been much earlier on, we could have just focused on the OMOP CDP part of it rather than a FHIR source