Short Description

The Vulcan FHIR to OMOP project aims to develop a referenceable FHIR to OMOP data transfer best practice through curation and adoption of a canonical set of maps from FHIR to OMOP to support consistent transformations of clinical data for research in for core, commonly generated EHR data.  This track will leverage CAMP FHIR to validate maps curated in the Vulcan FHIR to OMOP project, customized to support OMOP target transformations. 

Long Description

Prior OMOP + FHIR transformation projects have aimed to address the needs of one or two types of organizations, typically also focused on a single clinical domain. This substantial previous work was done by many groups; thus, much tedious semantic mapping has been established, reducing the overall time-to deliver a viable work product. As a component of the Vulcan FHIR-to-OMOP Outreach and Reporting Task Team activities, an environmental scan has identified dozens of projects that have mapped between FHIR and OMOP.  This underscores the value of developing an identified set of maps reflecting 'best practices" from FHIR to OMOP for core, commonly collected Real World Data.  FHIR-to-OMOP map/transformation artifacts collected from prior work will be reviewed and curated by the Vulcan FHIR-to-OMOP Curation Team to identify best practices reflected in prior work for the data included in the US Core and SNOMED IPS IGs. 

This track will use CAMP FHIR (Clinical Asset Mapping Program for FHIR), employing a repeatable workflow to validate transformation maps curated and proposed as reflecting "best practice" from FHIR to OMOP by the Vulcan FHIR to OMOP Curation Task Team.  This track aims to establish the viability of the testing workflow and use of the CAMP FHIR platform as a sustainable approach for subsequent Connectathons, validating the balance of the best practice maps identified and / or developed in this project. 

In prior projects, CAMP FHIR has demonstrated clinical data transformations to FHIR for supporting source-agnostic CDM-to-FHIR mapping.  Supporting the Vulcan FHIR-to-OMOP project, CAMP FHIR will be employed in a reverse process, ingesting curated FHIR-to-OMOP maps from the Vulcan project, and transforming FHIR-based test data to OMOP compliant data.  Established, expected transformations for test data using curated maps will be compared to the CAMP FHIR conversion results. Any differences between the expected and actual transformed data will be recorded as FHIR-to-OMOP map "failure."  Both successful and "failed" data transformations must be generated to achieve robust testing of the proposed curated map validation process, using CAMP FHIR.   


Test the design of a testing workflow, utilizing CAMP FHIR configured to be used to validate a set of curated FHIR to OMOP map resources in future Connectathons

Related Tracks?

Potential cooperation with Vulcan RWD track: TBD

Call for participants

Ideal candidates to participate in this track would be:

  • Participants in the Vulcan FHIR to OMOP project
  • Members of the OMOP + FHIR collaboration subgroups
  • Developers and implementers of FHIR to OMOP transformations
  • Developers of terminology servers and services

Track Prerequisites

Developers and implementers of FHIR to OMOP transformations who wish to test the platform and workflow with their own "native" maps will need to declare their intention to participate in the track prior to the kick off meeting and bring

  • FHIR R4 compliant data reflecting the map sources in JSON or XML files (potential to access source data from a Server)
  • Transformations / maps in the track standard testing format

All other participants may need yet to be determined system and software requirements

Track Lead(s)

Davera Gabriel Davera Gabriel 

Track Lead Email(s)

Specification Information


Zulip stream

Track Kick off Call

Link to kick off call recording is HERE

Specification Information


System Roles

Map Validator (using CAMP FHIR)

Optional: Terminology Server

Testing Scenario:


Prior to the Connectathon, a CAMP FHIR instance will be configured to ingest FHIR-based data resources and Vulcan FHIR-to-OMOP maps.  An OMOP CDM (v5.3.1) compliant relational data store that will receive the transformed FHIR data as a component of the CAMP FHIR set-up is also be required. CAMP FHIR can be installed on local machines or made available via web services. Transformation "maps" to be ingested are available via local files or remote downloading.  A potential additional scenario would be to access the maps via calls to ConceptMap Resources on a FHIR Terminology Server.  A set of expected transformation results are created for each source FHIR record to be used.  

CAMP FHIR Map Validation

A Map Validator will access CAMP FHIR and input both a selected source FHIR-compliant data resource and a related transformation/map artifact.  Running CAMPFHIR will create records in an OMOP CDM-compliant relational datastore.  Expected conversion results prepared in advance are compared with the actual results of the conversion.  Review of any differences between the actual and expected results will indicate translation success or failure. Both expected successful and expected failed transformations are necessary to complete the platform validation testing. 

Successful Transformation

Action: Retrieve FHIR data resource and its related transformation/map, and run CAMPFHIR to create a records in an OMOP database

Precondition: FHIR-compliant data, transformation map artifacts and OMOP expected transformation result record pairs

Success Criteria:  no differences between the expected result record and the transformed data record(s) in the OMOP CDM data store

Failed Transformation

Action: FHIR-compliant data and OMOP expected transformation result record pairs

Precondition: FHIR-compliant data, "flawed" transformation map artifacts  and OMOP expected transformation result record pairs

Success Criteria:  identified, expected differences between the "successful" result record and the transformed data record(s) in the OMOP CDM data store

Bonus point:

In either scenario, there may be use of a FHIR Terminology server to query for and retrieve a ConceptMap resource reflecting the test map/transformations 


  1. There may be utilization of a script which "selects" both the source data and map/ transformation artifact to be input into CAMPFHIR platform
  2. There may be utilization of an automated "diff" evaluation of the expected and actual transformations which would indicate transformation success or failure

Security and Privacy Considerations: