Observational clinical research is emerging as a major source of clinical evidence and discovery; we cannot afford to learn all society needs to know from discrete, randomized clinical trials (though that remains the gold standard of evidence). Generating research data warehouses as a basis for analysis remains an expensive and laborious process; many academic medical centers make such investments, virtually no other healthcare providers do. The ubiquitous emergence of reliable FHIR APIs in EHR systems (increasingly required in the US by HHS/ONC regulation) supports a scalable export of EHR content to research data warehouses. OMOP (Observational Medical Outcomes Partnership) is the most common data model for EHR data warehouses and a standard, reusable FHIR to OMOP mapping would dramatically reduce the cost and effort to generate and maintain research data warehouses for all care delivery settings, including rural health settings. This in turn would substantially increase the scale and scope of observational analytics for clinical outcomes, best evidence discovery, and disease monitoring in pandemic circumstances, among other uses. As a coordinating body for the effort proposed, Vulcan would function as a strategic consolidator of effort and use-case mediator, maximizing value to the broadest possible research constituency. Furthermore, cataloging and analysis of prior work in and of itself will provide valuable contributions to communities in addition to research. Identify and catalog preliminary work 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. To-date, 22 distinct projects that have mapped FHIR to OMOP have been identified, in-scope for this project. The preliminary list of these projects can be found in the worksheet. The project as proposed will include a report of results from the environmental scan identifying in-scope, FHIR to OMOP transformation projects, and an evaluation of as many FHIR-to-OMOP map / transformation artifacts as can be obtained from prior work. Project Scope and deliverables The project aims to support selection of a canonical gold standard for only the US Core Data for Interoperability and the SNOMED CT International Patient Summary sub-ontology. Analysis and selection of the exact version of both FHIR IGs representing the core, in-scope data elements and OMOP target CDM will ensue. The question of which version(s) of the available FHIR implementation guides (IGs) would be followed, and in what sequence additionally will be determined. An overlap / gap analysis of the US Core and IPS elements will be conducted, which will simplify map evaluation and curation work in the iterative cycles planned. The content focus for each iterative work cycle will be based upon dividing up the core data classes, or domains into groups. Each content group will be assembled, examined and any gap mapping curated in a serial fashion. In this way the core content processing is broken-up into repeating cycles. An evaluation of the options for publication of the project work products will be conducted, and one or more publishing mechanisms will be selected that maximize both available production resources and reach to the broader OMOP & HL7 communities. To support analysis of prior work, a standard format will be developed to which prior map artifacts will be transformed. By utilizing this standard format, many map artifacts for a single common data element in scope can be compared across source projects. In addition to mapping content alignment, available tools which perform data comparisons (or “diffs”) will be leveraged to support our analyses. Once analysis of available prior work for a class of data elements is complete, the best approach for mapping each data element will be selected from prior work, or curated based on consensus or criteria developed by the project team. These examples of “best practice” maps will be collated for testing / review and publication. This proposal will be more sophisticated terminologically than prior IG activities, because the context / intellectual effort required to develop maps used in IGs will be preserved with the maps themselves. Thus, we hope to raise and establish a new “gold standard” for transformation artifacts and maps. Aligned with the HL7 publication process, cycles will include Connectathon validation activities for the “gold standard” content identified in each cycle by the project team. Testing and evaluation configuration scenarios and the supporting Connectathon infrastructure will be developed as a component of the initial project cycle. Issues surfaced as a result of Connectathon activities will be addressed in the subsequent development cycle.