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. |
Type | 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:
|
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
All other participants may need yet to be determined system and software requirements |
Track Lead(s) | Davera Gabriel Davera Gabriel |
Track Lead Email(s) | davera@jhu.edu |
Specification Information | N/A |
Zulip stream | https://chat.fhir.org/#narrow/stream/306130-OMOP-.2B-FHIR-Terminologies |
Track Kick off Call | |
Specification Information | N/A |
System Roles | Map Validator (using CAMP FHIR) Optional: Terminology Server |
Testing Scenario: | Preparation 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 TestScript(s):
Security and Privacy Considerations: TBD |
Overview
Content Tools
Apps