FHIR
Page tree
Skip to end of metadata
Go to start of metadata

Short Description

To align FHIR and the OMOP Common Data Model (CDM) for the purposes of building an oncology learning health system that exchanges patient data for large scale observational studies and analytics.

Long Description

The purpose of hosting this Connectathon track is to validate conversions and alignment between a FHIR and the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM). 

FHIR and OMOP do not always have a clear and unambiguous mapping between both information models. Subsequently, we are hoping to achieve a consistency in how these conversions are done. 

Type

Test a FHIR-associated specification

Submitting Work Group/Project/Accelerator/Affiliate/Implementer Group  

OMOP on FHIR Working Group

FHIR to OMOP Oncology Sub-Group


Track Lead(s)

May Terry 

Track Lead Email(s)

May Terry 

Related Tracks


FHIR Version

FHIR R4B

Artifacts of focus

Expected participants

Qi Yang (IMS), May Terry (MITRE), Guy Livne (Ministry of Health Israel), Xuelu Liu (Dana Farber), CIBMTR, Davera Gabriel (Johns Hopkins), Antonio Zaitoun & Ole Utkilen (GE Healthcare), Anna Alloni (Biomeris)

Zulip stream

https://chat.fhir.org/#narrow/stream/302239-omop-.2B.20fhir.20oncology/topic/May.202022.20FHIR.20Connectathon 

Track Kick Off Call

Thursday, April 28, 12:00-1:00pm ET. 

  • Track Kick-off Presentation slides here.
  • Track Kick-off Presentation Recording here.

Track Details

Reference Architecture

System roles:

  • FHIR server containing US Core and mCODE StructureDefinitions and example FHIR instances conformant with mCODE.
  • OMOP CDM database


The following systems are available for the Connectathon.

  • FHIR reference implementation server supporting FHIR v4.0.1, US Core STU4, and mCODE STU2 StructureDefinitions.
  • One OMOP CDM database, configured with a dedicated schema for each organization participating in Scenario #1.
    • a separate schema will have configured the OMOP vocabulary tables is provisioned for each participant in this use case scenario. The ETL logic from each participant will reference this schema to ensure that all participants are using the same vocabulary versions.

The mCODE FHIR server contains:

  • Mock data of 67 mCODE CancerPatient FHIR instances with supporting profile data for PrimaryCancerCondition, CancerStageGroup, and CancerRelatedMedicationAdministration, TumorMarkerTest.


  • Starter guide of example calls to the FHIR test server containing mCODE data.


These are the profiles and elements that will be translated to the OMOP CDM:

FHIR ProfileElementsAdditional Comments
CancerPatientid, race, ethnicity, gender, extension.birthsex, name.family, name.given, birthDateOMOP mapping guidance: Vocab still working on race & ethnicity support in OMOP. mCODE to use source_value fields.
PrimaryCancerConditionid, code, subject, onsetDate, mcode-histology-morphology-behavior

OMOP mapping guidance: Link to CancerStage in OMOP is from the staging profile to the CONDITION_OCCURRENCE condition_id via MEASUREMENT.event

Map onsetDate to CONDITION_OCCURRENCE.condition_start_date.

CancerStageGroupid, code, subject, focus, effectiveDate, method

FHIR test data note: The current CancerStageGroup is represented in PrimaryCancerCondition under Condition.stage.summary as well as a dedicated CancerStageGroup FHIR Observation instance.

OMOP mapping guidance: Link to CancerStage in OMOP is from the staging profile to the CONDITION_OCCURRENCE condition_id via MEASUREMENT.event

CancerRelatedMedicationAdministrationid, medication.code, subject, effectiveDate, reasonCodeFHIR test data note: Scoped to show MedicationAdministration.reasonCode as tied to a cancer-related diagnosis.
TumorMarkerTestid, code, subject, effectiveDateTime, value

FHIR test data note: Biomarkers of interest provided as LOINC codes for the following:

  • Estrogen Receptor (ER) status
  • Progesterone Receptor (PR) status
  • HER2 status (by IHC or FISH)
  • Prostate-specific Antigen (PSA)
  • Carcinoembryonic Antigen (CEA)

Bonus:

The following will support a potential third scenario involving cross-track collaboration with Clinical Genomics: Using/accessing FHIR genetic data - Operations.

FHIR ProfileElementsAdditional Comments
GenomicVariant

id, subject, component:gene-studied, component:genomic-source-class, component:genomicDNAChange, component:amino-acid-change, component:clinical-significance, component:cytogeneticLocation

only a subset of components are populated; different components are populated depending on the variant found.

Scenarios

Scenario #1 Name: FHIR to OMOP consistency in ETL translation logic

Brief Description: mCODE-conformant FHIR instances are converted to equivalent OMOP CDM tables. 

Actors:

  • Integrators creating Extract, Transform, Load (ETL) logic converting from mCODE FHIR resources to OMOP CDM
  • Informaticists analyzing and confirming structural and semantic maps between FHIR (mCODE) and OMOP CDM  


Action:

Step 1: Connectathon participants will be given a small dataset of mCODE-conformant FHIR resources. Participants must register beforehand to get a schema with the OMOP tables provisioned.

Step 2: Each participant will develop ETL logic to convert to OMOP CDM using ETL logic from FHIR resources conforming to the following mCODE profiles.

Step 3: A review/comparison of schemas will determine if the guidance in translating from mCODE to OMOP CDM was consistent. If so, we can have a higher level of confidence in the guidance provided and higher trust in a federated architecture where there is an implicit understanding of translation to OMOP.


Precondition: Success Criteria: 

Each ETL is able to retrieve an mCODE-conformant FHIR resource.

Each ETL is able to write to an OMOP CDM v5.4 database schema.


Success Criteria:  

FHIR to OMOP ETL converts a pre-defined mCODE-conforming FHIR resources into an OMOP CDM DB schema in a manner that there is no significant difference from a different ETL translator that populates a separate OMOP schema.


TestScript(s):

N/A


Security and Privacy Considerations:

Security considerations is out of scope for this Connectathon track as we will not use PHI data. All data provided will be mock or synthetic data.

Security and Privacy Considerations:

Security considerations is out of scope for this Connectathon track as we will not use PHI data. All data provided will be mock or synthetic data.

Scenario #2 Name: OHDSI application usability of translated FHIR (mCODE)-to-OMOP CDM data

Pre-requisite: 

  • There exists an OMOP CDM database with a cancer-related dataset containing elements that align with mCODE. This CDM can be either a shared one provided by the Connectathon track, or in a federated implementation where the participant has their own OMOP CDM DB.
  • Each participant will have their own access to OHDSI tooling for cohort definitions (e.g.: ATLAS instance, HADES libraries with RStudio, etc.)
  • A study question will be provided ahead of time for participants to implement their cohort definition logic.  The mock study aim and cohort definition SHALL be provided 2 weeks prior to the Connectathon.

Action:

Step 1: Connectathon participants will be given access mCODE-converted to OMOP dataset. This can be through the following means:

  • a connection to the OMOP CDM DB schemas temporarily setup for the duration of the Connectathon.
  • an exported dataset of the relevant tables as CSV files - this option could be offered if there are organizational security concerns regarding access to external data stores.

Step 2: Participants will implement their cohort definition logic within their own instance.

Step 3: Study results will be shared with feedback collected for the following questions:

  • was the data quality of the mCODE data useful for observational research?
  • what worked?
  • what needs improvement - 1) in mCODE, 2) in FHIR (base), 3) in OMOP Oncology CDM?, 4) in OMOP (general), 5) in OHDSI tooling?


Success Criteria: 

At least one participant is able to generate study results using the mCODE-to-OMOP CDM converted data.


Security and Privacy Considerations:

Security considerations is out of scope for this Connectathon track as we will not use PHI data. All data provided will be mock or synthetic data.


Scenario #3 Name: Getting to Know You - Playing with FHIR and OMOP CDM

Pre-requisite: Some basic knowledge of FHIR or OMOP CDM

Brief Description: Learn more about FHIR and OMOP CDM by exploring the environment. Observers can reference the FHIR-OMOP Oncology

Actors:

  • Connectathon participants and observers
  • OHDSI integrators, informaticists, and developers interested in learning about FHIR 
  • HL7 integrators, informaticists, and developers interested in learning about the OMOP CDM

Success Criteria:

Observers will be familiar with how to

  • navigate the mCODE STU2 FHIR IG
  • query a FHIR server for mCODE data
  • query an OMOP CDM database
  • bonus: be able to follow the data flow path from mCODE specification → FHIR server → OMOP CDM translation by querying mCODE examples.