{"paper_id":"36e99085-49a1-449a-921d-c2d077f11d23","body_text":"1 \nMENDS-on-FHIR: Leveraging the OMOP common data model and \nFHIR standards for national chronic disease surveillance  \n \nShahim Essaid,1 Jeff Andre,2 Ian M Brooks,1,3 Katherine H Hohman,4 Madelyne Hull,3 \nSandra L Jackson,6 Michael G Kahn,1,3 Emily M Kraus,6,7 Neha Mandadi,1,3 Amanda K \nMartinez,4 Joyce Y Mui,1,3 Bob Zambarano,2 Andrey Soares8 \n \nAffiliations \n1. Department of Biomedical Informatics, University of Colorado Anschutz Medical \nCampus, Denver CO \n2. Commonwealth Informatics Inc, Waltham MA \n3. Health Data Compass, University of Colorado Anschutz Medical Campus, Denver \nCO \n4. National Association of Chronic Disease Directors (NACDD), Decatur GA \n5. National Center for Chronic Disease Prevention and Health Promotion, Centers for \nDisease Control and Prevention (CDC), Atlanta GA \n6. Kraushold Consulting, Denver CO \n7. Public Health Informatics Institute, Decatur, GA \n8. Department of Medicine, University of Colorado Anschutz Medical Campus, Denver \nCO \n \n \n \nCorresponding Author \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \nNOTE: This preprint reports new research that has not been certified by peer review and should not be used to guide clinical practice.\n\n2 \nMichael G Kahn MD \nDepartment of Biomedical Informatics \nUniversity of Colorado Anschutz Medical Campus \nAnschutz Health Sciences Building \n1890 N. Revere Court, Mailstop F600 \nAurora, CO 80045 \nMichael.Kahn@cuanschutz.edu \n+1 303.324.2829 \n \nKey Words [MESH term if available] \n1. Health Information Interoperability [L01.470.813] \n2. Public Health Surveillance [N06.850.780.675.487] \n3. Health Level Seven [N03.540.630.480] \n4. Electronic Health Records [N06.850.520.308.940.968.625.250] \n5. HL7 Fast Healthcare Interoperability Resources (FHIR) \n \nWord Count: Abstract: 246 / Main text (no captions): 3806 \nTables: 4 \nFigures: 5 \n \n \n  \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n3 \n \nABSTRACT \nObjective \nThe Multi-State EHR-Based Network for Disease Surveillance (MENDS) is a population-\nbased chronic disease surveillance distributed data network. Current data partners \ncreate institution-specific extraction-transformation-load (ETL) routines. MENDS-on-\nFHIR provides a standards-based ETL approach using Health Language Seven’s Fast \nHealthcare Interoperability Resources (HL7® FHIR®) and US Core Implementation \nGuide (US Core IG) compliant resources derived from the Observational Medical \nOutcomes Partnership (OMOP) Common Data Model (CDM). \nMaterials and Methods \nThe input data source was a research data warehouse (RDW) containing clinical and \nadministrative data in OMOP CDM Version 5.3 format. OMOP-to-FHIR transformations, \nusing a unique JavaScript Object Notation (JSON)-to-JSON language called Whistle, \ncreated FHIR R4.0.1/US Core IG V4.0.0 conformant resources that were stored in a \nlocal FHIR server. A REST-based Bulk FHIR $export request extracted FHIR resources \nto populate a local MENDS database. \nResults \nEleven OMOP tables were used to create 10 FHIR/US Core compliant resource types. \nA total of 1.13 trillion resources were extracted and inserted into the MENDS repository. \nA very low rate of non-compliant resources was observed. \n  \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n4 \nDiscussion \nOMOP-to-FHIR transformations passed validation with only minimal non-compliance \nissues. These resources provided the clinical and administrative data elements required \nby the MENDS surveillance use case. The Bulk FHIR application programming interface \n(API) enabled population-level data exchange using interoperable FHIR resources. The \nOMOP-to-FHIR transformation pipeline creates a FHIR “facade” for accessing OMOP \ndata.  \nConclusion \nMENDS-on-FHIR successfully replaced custom ETL with standards-based \ninteroperable FHIR resources using Bulk FHIR. The OMOP-on-FHIR transformations \nprovide an alternative mechanism for sharing OMOP data. \n \n \n \n  \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n5 \n \n1 INTRODUCTION \nPublic health networks that collect, harmonize, and report on acute diseases have \ntraditionally relied on manual health surveys and local data collection methods. \nExpanding these networks to a national scale that reaches a wide range of populations \nand settings has significant technical and sustainability challenges. Chronic disease \nsurveillance has additional challenges, given the need for diagnostic, therapeutic, and \nobservational longitudinal data over many years. The Multi-State EHR-Based Network \nfor Disease Surveillance (MENDS) pilot project focuses on harmonizing clinical data \nfrom electronic health records (EHRs) to support chronic disease monitoring at scale \nand across disparate clinical settings [1]. Focusing on data elements and measures \nrelated to hypertension, smoking, statin use, diabetes, and obesity, MENDS aims to \ninform local and national health departments regarding chronic disease burden and \noutcomes at the population level. The MENDS data infrastructure is built using \nElectronic Medical Record Support for Public Health (ESP), an open-source software \nsuite [2–5]. A detailed description of the MENDS governance, technical structure, and \ndata elements has been published previously [6]. \n \nCurrently, MENDS data are imported using several custom extraction-transformation-\nload (ETL) processes. Detailed specifications describe the format and content for each \nMENDS data element. MENDS data contributors write custom ETL routines, resulting in \nsignificant technical burden[7]. The MENDS team partnered with Health Data Compass \n(HDC)—the data custodian for a multi-institutional clinical research data warehouse \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n6 \n(RDW)—to create an ETL process using interoperable data standards based on Health \nLanguage Seven’s Fast Healthcare Interoperability Resources (HL7® FHIR®), resulting \nin MENDS-on-FHIR. Combined with the US Core Implementation Guideline (US Core \nIG) and HL7 Bulk FHIR export, this data exchange environment could significantly \nreduce the technical effort by enabling access to standardized data that are \nindependent of underlying database structures and supported by commercial EHR \nvendors.  \n \nHL7 FHIR is an extensive international health data exchange standard [8]. It is based on \nunits of data exchange, called Resources, that must conform to explicit standards for \nstructure (data formats), content (allowed terms), and operations (queries, updates, \ndata exchanges). The health information technology (HIT) industry's implementation of \nFHIR-based interfaces and applications has increased dramatically [9]. In addition to \nresponding to traditional marketplace forces, in the United States, EHR vendors must \ncomply with the 21st Century Cures Act. It contains regulatory mandates with \nimplementation deadlines, certification criteria, and penalties for non-conformance \nrequiring implementation of FHIR Version 4.0 and US Core IG Version 4.0.0 by \nDecember 31, 2022 [10,11]. \n \nTwo additional elements of the FHIR specification are FHIR Profiles [12] and \nImplementation Guides (IGs) [13]. FHIR Profiles define additional specifications that \nnarrow or expand the scope of a FHIR base resource definition. For example, a Profile \ncan specify additional data fields, alter fields from optional to mandatory, define \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n7 \nrelationships between data elements, or declare alternative or expanded terminologies \nor value sets in a FHIR resource. An IG is a collection of Profiles that defines a specific \nuse case for the use of a resource. The US Core IG is widely deployed in the United \nStates because it is closely aligned to the data domains and terminologies defined in \nthe US Core Data for Interoperability (USCDI) Version 1. USCDI V1 defines the set of \nmandatory elements for data exchange required by legislation to certify commercial \nEHR systems.  \n \nFHIR-based data exchange occurs using two basic models: real-time single-patient and \nbatch-oriented bulk data queries. For the MENDS population surveillance use case, \nonly the batch-oriented bulk data exchange method is used. FHIR Bulk Data Access \n(also called Bulk FHIR and Flat FHIR), uses the same data and coding formats (FHIR \nResources, Profiles, IGs) but returns data for all patients in a cohort in a single \nasynchronous batch-oriented operation [14]. Bulk FHIR is designed to enable \npopulation-focused use cases, such as public health surveillance, clinical quality \nassessment, and health services research [15]. The Bulk FHIR standard is in early \ndevelopment and is less widely deployed than single-patient FHIR. Mandatory \nconformance certification for Bulk FHIR data standards was delayed until December 31, \n2023. However, a few Bulk FHIR public health applications have been developed [16]. \nFor example, VACtrac is a public health use case that uses Bulk FHIR to exchange \nvaccine data between health institutions and a state immunization registry [17].  \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n8 \nBecause production-ready EHR Bulk FHIR interfaces are not yet widely available, \nMENDS-on-FHIR is implemented using an RDW that contains EHR data [18]. \nTransformation routines produce conformant FHIR Resources from patient-level data \nstored in an Observational Medical Outcomes Partnership (OMOP) common data model \n(OMOP CDM) format [19,20]. It is supported by the Observational Health Data Sciences \nand Informatics (OHDSI) collaborative, an international research data network [19,21]. \nBy implementing a Bulk FHIR interface based on the OMOP CDM, other institutions that \nhave implemented OMOP can use the OMOP-to-FHIR transformations directly to \nprovide Bulk FHIR access to their OMOP RDW. As institutions deploy US Core IG \nconformant Bulk FHIR interfaces in their certified EHRs, MENDS can use the same Bulk \nFHIR import interface to obtain more timely data directly from clinical systems without \ncreating institution-specific ETL programs, reducing the technical lift to onboarding new \ndata contributors. \n \nThis report presents the MENDS use case and one technical approach for enhancing \ninteroperable data exchange in chronic disease surveillance efforts; this implementation \ncan inform how others could apply FHIR-based standards, especially those using the \nOMOP CDM. \n2 METHODS \nFigure 1 illustrates the data processing pipeline that begins with EHR data stored in an \nOMOP CDM Version 5.3 data mart (Marker 1) and creates a set of US Core IG V4.0.0 \ncompliant FHIR resources in a FHIR Server (Marker 2). A new ESP Bulk FHIR import \nplugin extracts the FHIR resources via a Bulk FHIR REST call (Marker 3a) and inserts \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n9 \nthem into the MENDS database (Marker 3b). Although the MENDS team initially \nleveraged software developed in a proof-of-concept project [22], the new tooling work \nrequired a substantial level of technical effort. A prototype OMOP-to-FHIR data \ntransformation pipeline (processing steps in green) with synthetic data in OMOP JSON \nformat is freely available on GitHub (https://github.com/CU-DBMI/mends-on-fhir). \n \n \nFigure 1. Overall flow diagram. Yellow components are existing systems. Green \ncomponents are available on GitHub. Green components with asterisk \nextended an existing open-access proof-of-concept GitHub project.  \n2.1 OMOP-to-OMOP JSON \nANSI-standard SQL statements query OMOP CDM V5.3 tables and columns to \ngenerate output rows that create FHIR resources. Because the transformation engine \ncannot perform additional SQL operations, all data elements required for a FHIR \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n10 \nresource must be included in the SQL output. For example, the OMOP DEATH table is \nLEFT JOINed with the OMOP PERSON table so that a death date, when available, is \nincluded in the query. OMOP concept_names, concept_codes, and vocabulary_ids for \nall concept_id fields are also included.  \n \nA Python script executes each SQL statement and outputs the results as a single \n“OMOP JSON” object. Figure 2 illustrates this file where the JSON key = \n“Condition_Occurrence”. The key represents an OMOP table or domain. Each element \nin the JSON array is a database row. All keys and values are represented as JSON \nstrings, irrespective of the native data type. Because of memory limitations in the \ntransformation engine, SQL results are partitioned across multiple JSON files. \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n11 \n \nFigure 2. Structure of “OMOP JSON” extracted from OMOP CDM V5.3 queries \nusing synthetic data based on the OMOP Condition_Occurrence table. The \nperson_id, provider_id, condition_ start/end dates fields do not refer to actual \nvalues. \n \n2.2 OMOP JSON to FHIR R4 Bundle JSON (OMOP-to-FHIR) \nOMOP JSON is transformed into FHIR R4 Bundle JSON format using an open-source \nJSON-to-JSON transformation engine that implements a functional language called \nWhistle [22]. Additions to the original project include configuration files to support \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n12 \nOMOP JSON input, MENDS resources output, and conformance to FHIR R4.0.1 and \nUS Core IG 4.0.0. \n \nFigure 3 illustrates a portion of the Whistle specification for transforming an OMOP \nPERSON record into a FHIR PATIENT resource. Elements on the left side of a colon \nare either internal variables (declared with VAR) or FHIR JSON keys. Elements on the \nright side of a colon are OMOP fields, Whistle functions that modify OMOP fields, or \nconstants. \n \nA top-level Whistle function matches the JSON Key (e.g., “Person”, “Observation”, \n“Condition_Occurrence”) and routes the JSON data array to the relevant \nimplementation function that converts OMOP JSON into FHIR JSON resource(s). The \ntransformation functions are applied to each row in the OMOP JSON array, creating one \nor more FHIR resources. A terminal function wraps the array of FHIR resources into a \nsingle FHIR Bundle resource. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n13 \n \nFigure 3. Whistle transformation specification for creating FHIR R4 Person \nresource from OMOP CDM V5.3 Patient record. Functions such as \nUSCore_Birthsex() use a unique feature of the Whistle transformation language \nthat calls FHIR concept maps to convert OMOP-specific concept_ids into US \nCore IG-compliant CodeableConcepts. \n \nOne unique feature of the Whistle mapping language is a built-in function focused on \ncode harmonization using local FHIR ConceptMap resources or remote FHIR \nterminology services. For example, the Whistle function USCore_Birthsex() in Figure 3 \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n14 \n(red box) uses the local FHIR ConceptMap shown in Figure 4 to translate OMOP \nconcept_ids into US Core IG conformant values. Network restrictions on PHI-containing \ndata sets prohibit use of remote terminology services. All OMOP-to-FHIR terminology \nmappings use local ConceptMap files. Utility programs enable bulk mappings from \nspreadsheets/CSV files into FHIR ConceptMaps. \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n15 \n \nFigure 4. FHIR ConceptMap maps OMOP-specific concept_ids for patient sex \ninto FHIR US Core compliant values. \n \nWhen the FHIR Resource specification allows, MENDS-on-FHIR includes nonstandard \nsource values and codes in addition to the required FHIR and US Core codes. For \nexample, the Medication.code field accepts an array of Coding objects. The US Core IG \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n16 \nrequires one Coding object to be a RxNorm code but allows additional non-RxNorm \nCodings. Figure 5 illustrates the inclusion of the mandated RxNorm code mapped from \nthe drug_concept_id  (red box) and the original nonstandard National Drug Code (NDC) \ncode (green box). The same approach enabled FHIR Condition resources to contain \nboth nonstandard ICD9CM/ICD10CM source codes along with US Core-required \nSystematized Nomenclature of Medicine (SNOMED) codes. \n \n \nFigure 5. Multiple JSON Codings in a FHIR code element enable inclusion of \nboth local source and FHIR-required values. In this example, both FHIR-\nrequired RxNorm (red box) and local NDC source codes (green box) are \nincluded in two Coding objects in the Medication.code JSON object. \n \n2.3 FHIR R4 and US Core IG Validation \nFHIR validation tools examine the structure and content of FHIR resources for \nconformance to FHIR Profiles and IGs. Two settings used the open-source HL7 FHIR \nValidator [23]: \n● FHIR resources that contain full PHI use the HL7 FHIR Validator without access \nto terminology services. This setting checks conformance to the FHIR structural \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n17 \nspecifications and any additional structural constraints or extensions in the US \nCore IG. \n● De-identified versions of the same FHIR resources use the HL7 FHIR Validator \nwith access to the HL7 public-domain terminology server. This setting checks \nconformance with terminologies and permitted values. \nThe validator uses FHIR R4.0.1 and US-Core IG V4.0.0. \n2.4 Bulk FHIR Import \nEach FHIR Bundle JSON file created in Step 2.2 is uploaded to a FHIR Server \nconfigured with base FHIR R4 and the US Core IG v4.0.0 using a FHIR $import call. \nThe FHIR Server is configured to not perform referential integrity checks on data import \noperations and to produce server-generated Resource IDs. Import errors are logged for \ninspection after all resources are loaded. A full data refresh is performed with each \nFHIR $import. \n2.5 Bulk FHIR Extract \nFHIR resources are requested by the ESP server using a small Python script that \nmakes FHIR $export calls to the FHIR server. The $export API initiates an \nasynchronous export process that returns an OPERATION_ID tag that is used to \ndetermine when bulk extractions have been completed. All instances of a FHIR \nresource type (Patient, Condition, MedicationRequest, Medication, Immunization, \nObservation) are exported in one large NDJSON file. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n18 \n2.6 ESP FHIR Import \nAfter completing the Bulk FHIR extract, a second Python script in ESP imports FHIR \nNDJSON into the ESP database. The load process initially copies the NDJSON files \ninto temporary tables as JSONB objects. Data in the temporary tables are then inserted \ninto the ESP relational data tables. \n3 RESULTS \nTable 1 shows the alignment among the clinical and demographic data domains \nrequired by the MENDS database, the FHIR resources that contain these data \nelements, and the OMOP table(s) used to construct the FHIR resources. The 10 FHIR \nresources needed by MENDS required data extracted from 10 OMOP tables plus the \nOMOP CONCEPT table for codes and text labels. OMOP Observation rows were \ntransformed into one of three different FHIR Observation Profiles defined by the US \nCore IG: Observation (Smoking), Observation (Non-Smoking) and Observation \n(Laboratory). Three separate transformations were used to create Profile-conformant \nvariants of the Observation Resource. Although the OMOP CDM can map to additional \nFHIR resources, only those required to meet MENDS chronic disease surveillance use \ncases were deployed. \n \n \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n19 \nTable 1. Alignment of MENDS, FHIR R4, and OMOP data models. \nMENDS data \ndomain \nFHIR R4 resource(s) required OMOP CDM V5.3 table(s) used \nPatient Patient Person, Location, Death, Concept \nEncounter \nEncounter Visit_Occurrence, Concept \nCondition Condition_Occurrence, Concept \nCoverage Payer_Plan_Period, Concept \nObservation (all) Observation, Concept \nPrescription \nMedicationAdmininstration \n \nDrug_Exposure, Drug_Strength, \nConcept \nMedicationDispense \nMedicationRequest \nMedication \nLab Result Observation (laboratory) Measurement, Concept \nSocial History Observation (non-smoking) \nObservation (smoking) Observation, Concept \nImmunization Immunization Drug_Exposure, Drug_Strength, \nConcept \n \n \nTable 2 provides basic statistics about the MENDS cohort and the FHIR resources \ngenerated.  \n \n \n \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n20 \nTable 2. Patient and OMOP row counts versus FHIR Resources. OMOP and \nFHIR counts are for the MENDS cohort only. \nCohort Counts \nUnique Patients – OMOP RDW (total) 4.38M \nUnique Patients – OMOP MENDS Cohort 3.24M \nOMOP Table \n(Figure 1 – Tag 1) \nRows FHIR Resource Resources \n(Figure 1 – Tag 2) \nPerson 3.24M Patient 3.24M \nVisit_Occurrence 141M Encounter 141M \nCondition_Occurrence 189M Condition 189M \nPayer_Plan_Period 162M Coverage 162M \nObservation (smoking) \nObservation (non-smoking) 138M \nObservation 411M \nMeasurement (labs) 399M \n \nDrug_Exposure 221M \nMedicationAdministration 102M \nMedicationDispense 8.4M \nMedicationRequest 109M \nMedication 55K \nImmunization 640K \n \nTable 3 provides timing results from a recent end-to-end run for a complete data refresh \nacross the entire MENDS cohort. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n21 \nTable 3. Representative processing times. See Figure 1 for the data processing \nsequence. \n Processing step Wall time* \n OMOP BigQuery to OMOP JSON GCS* export 30 minutes \nOMOP JSON GCS to FHIR server import (includes OMOP-to-\nFHIR transformation in pipeline) 39 hours \n FHIR server Bulk to FHIR NDJSON GCS export 30 minutes \nFHIR NDJSON GCS to PostgreSQL FHIR NDJSON import 2 hours \nPostgreSQL FHIR NDJSON to PostgreSQL ESP CDM ETL 80 hours \n*GCS = Google Cloud Storage \n Wall time = The actual elapsed time to complete a task as would be seen using a wall clock or chronometer. \n4 DISCUSSION \nThe COVID-19 pandemic highlighted the urgent need for rapid access to clinical data \nfrom diverse settings to assess risk factors and treatment outcomes [24–29]. Chronic \ndisease surveillance registries also need access to linked clinical, administrative, and \nsocial determinants of health data across diverse healthcare settings [30]. Although \nEHR systems capture detailed clinical data in health-seeking populations, these data \nare difficult to extract and harmonize to common data structures and terminologies [31]. \nThe base FHIR standard and the additional specifications of an IG address many data \ninteroperability issues. MENDS-on-FHIR illustrates how Bulk FHIR access to US Core \nIG conformant FHIR resources can support a large-scale population-level chronic \nOMOP CDM to \nFHIR Server \nOMOP CDM to \nFHIR Server \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n22 \ndisease surveillance database replacing one-off, institution-specific custom ETL \nprogramming. \n \nMENDS-on-FHR creates FHIR resources using the OMOP CDM. The EHR data \ncontained in the HDC OMOP CDM contains sufficient clinical data to meet MENDS \nrequirements. The same ESP Bulk FHIR import interface could be used in EHR \nsystems when regulatory mandates result in broader commercial implementations.  \n \nA secondary benefit is enabling population-level data access to a RDW via a Bulk FHIR \n“facade.” Sites that have deployed the OMOP CDM can use the MENDS-on-FHIR \ntransformations to generate US Core conformant FHIR resources. The OHDSI \ncommunity, which supports the OMOP CDM, currently contains “over 3,200 \ncollaborators in 80 countries across 21 time zones in 6 continents” \n(https://ohdsi.org/who-we-are/collaborators/; accessed 23-May-2023). A Bulk FHIR \nextraction capability opens this expansive data network to even more data sharing \npossibilities.  \n \nPropelled by regulatory mandates and certification requirements, FHIR data exchange \ncapabilities are present in nearly all U.S. commercial EHR systems. Data aggregators \ndo not have the same regulatory pressures and therefore have been slower to \nincorporate FHIR capabilities. They have implemented FHIR importing functions to \nconsume new data sources. However, aggregators generally have not developed FHIR \nexporting functions to share interoperable data with others. External data reporting \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n23 \nrequirements that use FHIR-based query tools, such as electronic clinical quality \nmeasurement reporting, may provide the impetus for data aggregators to add Bulk FHIR \nexport features [32,33]. MENDS-on-FHIR demonstrates one mechanism for adding \nFHIR features to a clinical data warehouse. \n \nThe Whistle language enabled implementation of OMOP-to-FHIR transformations as a \nbatch conversion using a functional JSON-to-JSON programming model. Other batch-\noriented OMOP-to-FHIR conversion programs include the original Google Data \nHarmonization proof-of-concept project [22], CAMP FHIR [34], and FHIR-Ontop-OMOP \n[35]. VACtrac [17] performed batch conversion of HL7 Immunization messages rather \nthan OMOP as its data source. An alternative approach, using dynamic real-time \nconversion during query execution, has been implemented by OMOP-on-FHIR [36,37]. \nBoussadi et al. created a similar dynamic FHIR conversion program using the i2b2 CDM \nas the underlying data source [38]; Kasthurirathne et al. used OpenMRS [39]. A batch \nconversion process does not incorporate new data additions or updates that occur \nbetween batch runs. However, a batch transformation, once completed, does not incur \ntransformation overhead during query execution or data extraction. The processing \noverhead in dynamic translation may go unnoticed when extracting data for a single \npatient (e.g., mobile apps). However, when executing a query that extracts and \ntransforms multiple FHIR resources in a large cohort as illustrated in Table 2, dynamic \ntransformation is simply not tenable. \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n24 \nA second distinction is the choice of data transformation languages. Whistle is a \ntemplate-based functional JSON-to-JSON conversion language that allows \ntransformation functions to be combined into higher level functions. Whistle implements \nfunctions that operate on FHIR ConceptMaps to support terminology mappings. \nMENDS-on-FHIR created functions for US Core IG compliant Code mappings, \nmanipulating Coding arrays, mapping Code_Systems, converting measurement units, \nand reformatting Date and DateTime fields into FHIR standard formats. Whistle \ntransformations are stored in configuration-like text files rather than being embedded in \nprogram code. \n4.1 Limitations \nMENDS-on-FHIR limited the scope of OMOP-to-FHIR transformations to OMOP tables \nand fields required to meet the MENDS data requirements and conform to the US Core \nIG. The only exception was including local source codes as additional FHIR Coding \nobjects when allowed by the FHIR specification. Including source values aided \ndebugging when original provenance was needed. \n4.1.1 Data model challenges \nOMOP, FHIR, and ESP define data elements and allowed values differently. Thus, \ntranslating from OMOP into FHIR and then into ESP entails a field-by-field analysis to \nidentify how a field required by ESP could be represented in FHIR and found in OMOP \n(backwards translation). With any data translation, mapping fidelity is a concern [40], \nalthough mapping errors may have smaller-than-anticipated impact on analytic results \n[41–43]. FFor example, OMOP associates insurance coverage over an interval of time \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n25 \nthat is not tied to clinical events. ESP links a primary payer to each clinical encounter. \nFHIR defines a Coverage Resource that directly maps to the OMOP interval-based \nrepresentation. The ESP FHIR importer converts FHIR Coverage Resource intervals \ninto an encounter-based representation using a configurable hierarchy to select a \nprimary payer when there are overlapping coverage periods. \n4.1.2 Mapping challenges \nIncomplete transformations occurred when field values could not be directly aligned \nbetween OMOP and FHIR. Inferred values were used when semantically justified. \nOtherwise, field values were left blank, even if this decision caused validation errors. \n4.1.2.1 Medications \nSome mandatory FHIR data elements do not have an equivalent data value from \nOMOP and were inferred. For instance, the FHIR MedicationRequest.status was set to \n“stopped” if the OMOP Drug_exposure.stop_reason was present, and set to “unknown” \notherwise. For MedicationAdminstration.status and MedicationDispense.status, if an \nend date existed, the status was considered “completed”, or otherwise “in-progress”. \n \nThe MedicationRequest.requester is a mandatory data element, but this information is \nnot always present in the OMOP Drug_Exposure table. When absent, the \nDrug_Exposure.provider_id was used. If both were absent, the requester field was left \nblank. When the requester field is blank, the HL7 Validator correctly identifies the \nresource as being US Core IG non-conformant. Although non-conformant, these \nresources are still stored in the FHIR Server and are available for Bulk FHIR extracts.  \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n26 \n \nFHIR medication-related resources contain a doseQuantity field to record the amount of \na medication per dose. OMOP has defined methods for calculating drug dose from the \nmedication ingredient (https://ohdsi.github.io/CommonDataModel/drug_dose.html). \nHowever, due to the complexity of calculating drug doses for multi-ingredient \nmedications, doseQuantity in a FHIR resource is included only when the OMOP \nDrug_Exposure.quantity field is available. Future work is needed to properly calculate \ndrug dosages in multi-ingredient medications. \n4.1.2.2 Smoking \nOMOP smoking information represents a class of clinical data where multiple OMOP \nrows represent answers to a survey instrument. In the HDC OMOP CDM, up to 10 rows \nwere entered from the smoking survey. The FHIR transformer requires all information \nabout a resource to be available in a single row. For the FHIR smoking observation \nresource, a SQL query was created that concatenated all responses to the smoking \nquestionnaire in an encounter into a single \"source value\" string. For example, nine \nseparate smoking responses were concatenated into a single \"value\" that was used to \ndetermine the correct SNOMED code in the FHIR smoking observation resource.  \n(Chew:No) – (CigarettePacksPerDay:<20) – (Cigarettes:No) – (Cigars:No) – \n(Nicotine dependence, cigarettes, uncomplicated) – (Pipes:No) – (Snuff:No) – \n(TobaccoUse:Yes) – (TobaccoUseInYears:+) \n \nThe combination of smoking responses generated thousands of unique combinations. \nWhile SNOMED-CT contains several dozen smoking related codes, the US Core IG \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n27 \nonly allows six valid codes. MENDS-on-FHIR maps the concatenated strings to one of \nthe six valid FHIR codes and also keeps the concatenated \"value\" in the \nCodableConcept.text field to retain the raw survey selections made by a patient. \n4.1.3 Execution challenges \n4.1.3.1 Memory \nThe Whistle Transformation Engine reads and transforms the entire OMOP JSON file \ninto memory before writing the final transformed FHIR structure. Thus the execution \nenvironment requires sufficient memory to hold the OMOP JSON file plus the output \nFHIR Bundle resource. The Python program that creates OMOP JSON accepts a \nparameter, called CHUNKSIZE, that partitions the OMOP query results into separate \nOMOP JSON files containing exactly CHUNKSIZE number of OMOP rows. This \nvariable is adjusted according to the memory size of each processing node instantiated \nin the parallel processing pipeline. \n4.1.3.2 Validation \nSeveral validation issues were identified that could not be rectified using existing OMOP \ndata, FHIR ConceptMaps, or Whistle transformations. Table 4 lists these unresolved \nvalidation errors. Collectively, the error rate was ~1%.  \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n28 \nTable 4. FHIR/US Core IG validation errors that could not be resolved. \nValidation \nissue \nExplanation and examples \nError: \nElement \ncardinality \n“MedicationRequest.requester” is a required element in US-Core. In rare \ncases, the OMOP PROVIDER_ID field was blank. By design, a “fake” \nentry was not created to meet the cardinality requirement. \nError: Code \nnot from \ncode \nsystem \nA small number of valid SNOMED-CT codes were flagged as not valid by \nthe terminology server. On manual verification, these were noticed to be \nUS-only SNOMED-CT codes. Examples include condition and smoking \nrelated codes. Similarly, a small number of valid RxNorm codes were not \nrecognized as RxNorm codes by the terminology service. Manual \nverification showed them to be influenza or remapped codes. \nError: \nViolations of \nFHIR \ninvariant \nrules) \nOn very rare occasions, OMOP data contained datetime values where \nthe start date was later than the end value in the \nMedication.validityPeriod field. These resources were kept “as is” \nbecause this is an accurate representation of the original data, and it had \nno impact on the immediate use case. \nWarning: \nCode not \nfrom value \nset.  \n \n \nUS-Core binds the “Medication.code” element to a “Medication Clinical \nDrug” value set derived from RxNorm. Validation indicated RxNorm \ncodes that did not belong to this value set. Manual examination revealed \nvalid RxNorm codes for the package form, but the value set does not \ninclude package related codes.  \nWarning: No \ncoding from \nthe value \nset. \nValidation indicated certain records did not contain any RxNorm codes \nwhen one was required. These DRUG_EXPOSURE records contained \nHCPCS (J1200) and OMOP RxNorm extension codes (OMOP1088103), \nCVX, CPT but no RxNorm code. \nWarning: \nLabel not \nmatching \nfrom \nterminology \nserver \nThe validator verifies code label text and warns if there is not an exact \nmatch with the label string in the terminology service. A few of the OMOP \nconcept labels had variations from the original labels, such as additional \nspaces around hyphens. OMOP also truncates all labels at 256 \ncharacters. \nInfo: \nUnknown \nextensions \nA FHIR Bundle extension was added to hold the OMOP-specific \nmetadata found in the OMOP CDM_SOURCE table. This extension was \ncorrectly flagged as an unknown extension. \nInfo: \nUnknown \nTerminologies not known to the terminology server but that are still \nassigned URLs by HL7 are present in OMOP source values and source \ncodes. The data elements holding these codes could not be verified \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n29 \nValidation \nissue \nExplanation and examples \ncode \nsystems \nbecause the code system is not available at the terminology server. \nExamples are HCPCS, OMOP RxNorm extension, and CPT. \n \nOne additional validation challenge involved the inability to detect very low frequency \nerrors using small test sets during validation testing (10,000 resources per resource \ntype). Low frequency errors were detected only at run-time when the full data set was \nprocessed. Thus, resources that passed validation testing still had rare run-time errors. \n4.2 Future Work \nMENDS-on-FHIR limits the scope of FHIR resources to include only those required by \nthe MENDS project and the FHIR/US Core IG. The OMOP CDM contains clinical and \nadministrative data across a broad range of data domains, such as clinical procedures, \ndevices and notes, that could create more FHIR resources.  \n \nEven within the included domains, the OMOP CDM has many data elements that \nMENDS-on-FHIR does not use. For example, the OMOP drug_exposure table includes \ndata on patient-informed medications, which could be used to create FHIR \nMedicationStatement resources. Another opportunity for future expansion is \nimmunization records. FHIR specifies immunization data coded in the CVX \nCodeSystem, but OMOP allows immunizations to also be coded using the RxNorm \nCodeSystem. The current Immunization Whistle transformation template only includes \nCVX records. Mapping RxNORM immunization records into CVX is possible with the \nexisting OMOP Concept_Relationship table, but was not done with the current \nimmunization transformation template. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n30 \n5 CONCLUSION \nThe MENDS-on-FHIR pipeline makes two related but distinct contributions: \n● Replacing a CSV-based data import with US Core IG compliant FHIR resources \nand Bulk FHIR data access demonstrates the viability of using existing FHIR \nstandards to support a national chronic disease public health surveillance use \ncase. \n● Transforming the OMOP research data warehouse into US Core IG compliant \nFHIR resources expands standards-based data access methods to research \ndata. \nBoth contributions add to the growing landscape of interoperable data exchange using \nFHIR-based standards. Using Bulk FHIR as a standards-based data source for \npopulation-level surveillance could greatly expand the reach of public health use cases \nas certified EHR systems meet the 21st Century Cures Act requirements. Linking a \nFHIR-based interface to an EHR could also improve data timeliness. One limitation of \ncurrent Bulk FHIR interfaces is the absence of incremental data extracts, which includes \nonly data elements added or revised since a previous extract request. However, as the \nBulk FHIR standard and implementations mature, incremental data extractions may be \npossible. \n \nThe OHDSI community has established practices that enable data sharing across \nOMOP sites using OMOP-specific tools. Enabling access to OMOP data via FHIR \nresources expands data access options for OMOP data use in broader settings. For \nexample, tools for executing and visualizing population-specific clinical quality measures \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n31 \nusing FHIR resources is an area of active development that could leverage OMOP data \nvia a Bulk FHIR interface. Given the high level of innovation and commercial activities \nusing FHIR-based data access, providing FHIR access to OMOP data increases an \ninstitution’s return-on-investment in implementing and maintaining this international \nRDW data asset. \n6 ACKNOWLEDGMENTS \nThe authors acknowledge the contribution of MENDS partner sites and project team \nthat participated in the creation of the MENDS data network \n(https://chronicdisease.org/page/MENDSinfo/). \n \nThe authors also acknowledge the open-source contribution by the Google Healthcare \nData Harmonization proof of concept project [22], which created the Whistle \ntransformation engine and example templates. \n \nHL7®, and FHIR® are the registered trademarks of Health Level Seven International \nand use of these trademarks does not constitute an endorsement by HL7. \n7 STATEMENT OF AUTHORS CONTRIBUTIONS \nSE, JA, MH, MGK, NM, BZ, and AS developed the software and GitHub site. SE, MGK, \nAS, KHH, SLJ, and AKM created the initial draft manuscript. IMB, MH, EMK, JYM, and \nBZ provided additional input to subsequent manuscript versions. All co-authors \napproved the final manuscript prior to submission. \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n32 \nAuthor ORCID \nShahim Essaid 0000-0003-2338-255 \nJeff Andre 0009-0007-2654-6764 \nIan M Brooks 0000-0003-2724-936X \nKatherine H Hohman 0000-0003-1552-4010 \nMadelyne Hull 0000-0002-1387-5004 \nSandra L Jackson 0000-0003-4810-0572 \nMichael G Kahn 0000-0003-4786-6875 \nEmily M Kraus 0000-0002-2966-6936 \nNeha Mandadi 0009-0008-8317-4327 \nAmanda K Martinez 0000-0001-5549-7788 \nJoyce Y Mui 0000-0002-4952-5735 \nBob Zambarano 0009-0003-5723-748X \nAndrey Soares 0000-0003-4319-9411 \n \n8 HUMAN PARTICIPANT COMPLIANCE STATEMENT \nCDC provided a written determination that MENDS operates within the public health \nauthority pursuant to the Health Insurance Portability and Accountability Act. As a public \nhealth surveillance project, MENDS does not require institutional review board approval. \n9 COMPETING INTERESTS \nBZ and JA are affiliated with an organization that has funding from the Massachusetts \nDepartment of Public Health for support and development of Electronic Medical Record \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n33 \nSupport for Public Health (ESP) and MDPHnet, which is the underlying technology of \nMENDS. All other authors declare no competing interests. \n \nNo copyrighted materials were used in this article. \n10 FUNDING \nThe “Improving Chronic Disease Surveillance and Management Through the Use of \nElectronic Health Records/Health Information Systems” project is supported by the \nCenters for Disease Control and Prevention (CDC) of the U.S. Department of Health \nand Human Services (HHS) as part of a financial assistance award totaling $2,500,000 \nwith 100 percent funded by CDC/HHS. Disclaimer: The contents are those of the \nauthors and do not necessarily represent the official views of, nor an endorsement, by \nCDC/HHS, or the U.S. Government. \n \nAdditional funding from “A phenomics-first resource for interpretation of variants” \nproject, supported by the National Human Genome Research Institute \n(5RM1HG010860-03: PI: Melissa Haendel).  \n \nInstitutional funding was provided by Health Data Compass and the Chief Research \nInformatics Office from the University of Colorado Anschutz Medical Campus. \nAndrey Soares was partially funded by the Harvard/STSI/NIH All of Us Program (Project \n#U24OD023716), project title: Technology to Empower Changes in Health (TECH) \nNetwork Participant Technologies Center – Sync for Science (S4S). \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n34 \n \n  \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n35 \n11 REFERENCES  \n[1] National Association of Chronic Disease Directors. Multi-State EHR-Based Network \nfor Disease Surveillance (MENDS) 2023. \nhttps://chronicdisease.org/page/mendsinfo/ (accessed June 29, 2023). \n[2] Lazarus R, Klompas M, Campion FX, et al. Electronic Support for Public Health: \nValidated case finding and reporting for notifiable diseases using electronic medical \ndata. J Am Med Inform Assoc JAMIA 2009;16:18–24. \nhttps://doi.org/10.1197/jamia.M2848. \n[3] Klompas M, McVetta J, Lazarus R, et al. Integrating clinical practice and public \nhealth surveillance using electronic medical record systems. Am J Public Health \n2012;102 Suppl 3:S325-332. https://doi.org/10.2105/AJPH.2012.300811. \n[4] Birkhead GS, Klompas M, Shah NR. Uses of electronic health records for public \nhealth surveillance to advance public health. Annu Rev Public Health 2015;36:345–\n59. https://doi.org/10.1146/annurev-publhealth-031914-122747. \n[5] ESPHealth. ESP: Electronic Medical Record Support for Public Health n.d. \nhttps://www.esphealth.org/ (accessed May 2, 2023). \n[6] Hohman KH, Martinez AK, Klompas M, et al. Leveraging electronic health record \ndata for timely chronic disease surveillance: The Multi-State EHR-Based Network \nfor Disease Surveillance. J Public Health Manag Pract 2023;29:162–73. \nhttps://doi.org/10.1097/PHH.0000000000001693. \n[7] Ong TC, Pradhananga R, Holve E, et al. A framework for classification of electronic \nhealth data extraction-transformation-loading challenges in data network \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n36 \nparticipation. EGEMs Gener Evid Methods Improve Patient Outcomes 2017;5. \nhttps://doi.org/10.13063/2327-9214.1295. \n[8] HL7. HL7 FHIR: Home n.d. http://hl7.org/fhir/ (accessed April 20, 2023). \n[9] Posnack S, Barker W. The heat is on: US caught FHIR in 2019. Health IT Buzz \n2021. https://www.healthit.gov/buzz-blog/health-it/the-heat-is-on-us-caught-fhir-in-\n2019 (accessed June 15, 2023). \n[10] Office of the National Coordinator. 2015 Edition Cures Update Overview 2015. \n[11] Actionable ways to meet the 2015 Edition Cures Update requirements. Health IT \nBuzz 2022. https://www.healthit.gov/buzz-blog/healthit-certification/actionable-\nways-to-meet-the-2015-edition-cures-update-requirements (accessed June 17, \n2023). \n[12] HL7. Profiling - FHIR v4.0.1. HL7 FHIR Release 4 n.d. \nhttps://www.hl7.org/fhir/R4/profiling.html (accessed June 5, 2023). \n[13] HL7. ImplementationGuide - FHIR v4.0.1. HL7 FHIR Release 4 n.d. \nhttps://www.hl7.org/fhir/R4/implementationguide.html (accessed June 5, 2023). \n[14] HL7. HL7 FHIR: Bulk Data Access IG n.d. https://hl7.org/fhir/uv/bulkdata/ \n(accessed April 20, 2023). \n[15] Mandl KD, Gottlieb D, Mandel JC, et al. Push button population health: The \nSMART/HL7 FHIR Bulk Data Access Application Programming Interface. NPJ Digit \nMed 2020;3:151. https://doi.org/10.1038/s41746-020-00358-4. \n[16] Jones J, Gottlieb D, Mandel JC, et al. A landscape survey of planned SMART/HL7 \nBulk FHIR data access API implementations and tools. J Am Med Inform Assoc \n2021;28:1284–7. https://doi.org/10.1093/jamia/ocab028. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n37 \n[17] Lenert L, Jacobs J, Agnew J, et al. VACtrac: Enhancing access immunization \nregistry data for population outreach using the Bulk Fast Healthcare Interoperable \nResource (FHIR) protocol. J Am Med Inform Assoc JAMIA 2022;30:551–8. \nhttps://doi.org/10.1093/jamia/ocac237. \n[18] Kahn MG, Mui JY, Ames MJ, et al. Migrating a research data warehouse to a public \ncloud: Challenges and opportunities. J Am Med Inform Assoc 2022;29:592–600. \nhttps://doi.org/10.1093/jamia/ocab278. \n[19] Hripcsak G, Duke JD, Shah NH, et al. Observational Health Data Sciences and \nInformatics (OHDSI): Opportunities for observational researchers. Stud Health \nTechnol Inform 2015;216:574–8. \n[20] Kahn MG, Batson D, Schilling LM. Data model considerations for clinical \neffectiveness researchers. Med Care 2012;50 Suppl:S60-7. \nhttps://doi.org/10.1097/MLR.0b013e318259bff4. \n[21] Reinecke I, Zoch M, Reich C, et al. The usage of OHDSI OMOP – A scoping \nreview. In: Röhrig R, Beißbarth T, König J, et al., editors. Stud. Health Technol. \nInform., IOS Press; 2021. https://doi.org/10.3233/SHTI210546. \n[22] Google HCLS Data Harmonization 2023. \n[23] Using the FHIR Validator - FHIR - Confluence n.d. \nhttps://confluence.hl7.org/display/FHIR/Using+the+FHIR+Validator (accessed April \n20, 2023). \n[24] DeSalvo K, Hughes B, Bassett M, et al. Public Health COVID-19 impact \nassessment: Lessons learned and compelling needs. NAM Perspect 2021. \nhttps://doi.org/10.31478/202104c. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n38 \n[25] Kadakia KT, Howell MD, DeSalvo KB. Modernizing public health data systems: \nLessons from the Health Information Technology for Economic and Clinical Health \n(HITECH) Act. JAMA 2021;326:385–6. https://doi.org/10.1001/jama.2021.12000. \n[26] Quintana Y, Cullen TA, Holmes JH, et al. Global Health Informatics: The state of \nresearch and lessons learned. J Am Med Inform Assoc 2023;30:627–33. \nhttps://doi.org/10.1093/jamia/ocad027. \n[27] Acharya JC, Staes C, Allen KS, et al. Strengths, weaknesses, opportunities, and \nthreats for the nation’s public health information systems infrastructure: Synthesis \nof discussions from the 2022 ACMI Symposium. J Am Med Inform Assoc \n2023:ocad059. https://doi.org/10.1093/jamia/ocad059. \n[28] Dixon BE, Staes C, Acharya J, et al. Enhancing the nation’s public health \ninformation infrastructure: a report from the ACMI symposium. J Am Med Inform \nAssoc 2023;30:1000–5. https://doi.org/10.1093/jamia/ocad033. \n[29] Lee P, Abernethy A, Shaywitz D, et al. Digital Health COVID-19 impact \nasssessment: Lessons learned and compelling needs. In: Adams L, Ahmed M, \nBailey A, et al., editors. Emerg. Stronger COVID-19 Priorities Health Syst. \nTransform., Washington, D.C.: National Academies Press; 2023, p. 177–234. \nhttps://doi.org/10.17226/26657. \n[30] Casey JA, Schwartz BS, Stewart WF, et al. Using electronic health records for \npopulation health research: A review of methods and applications. Annu Rev Public \nHealth 2016;37:61–81. https://doi.org/10.1146/annurev-publhealth-032315-021353. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n39 \n[31] FitzHenry F, Resnic FS, Robbins SL, et al. Creating a common data model for \ncomparative effectiveness with the Observational Medical Outcomes Partnership. \nAppl Clin Inform 2015;06:536–47. https://doi.org/10.4338/ACI-2014-12-CR-0121. \n[32] McClure RC, Macumber CL, Skapik JL, et al. Igniting harmonized digital clinical \nquality measurement through terminology, CQL, and FHIR. Appl Clin Inform \n2020;11:023–33. https://doi.org/10.1055/s-0039-3402755. \n[33] Lin AM, Schwab A, Abolhassni R, et al. From authoring to evaluating an electronic \nhealth quality measure – Applying logic to FHIR® with CQL for calculating \nimmunization coverage. In: Pfeifer B, Schreier G, Baumgartner M, et al., editors. \nStud. Health Technol. Inform., IOS Press; 2023. \nhttps://doi.org/10.3233/SHTI230004. \n[34] Pfaff ER, Champion J, Bradford RL, et al. Fast Healthcare Interoperability \nResources (FHIR) as a meta model to integrate common data models: \nDevelopment of a tool and quantitative validation study. JMIR Med Inform \n2019;7:e15199. https://doi.org/10.2196/15199. \n[35] Xiao G, Pfaff E, Prud’hommeaux E, et al. FHIR-Ontop-OMOP: Building clinical \nknowledge graphs in FHIR RDF with the OMOP common data model. J Biomed \nInform 2022;134:104201. https://doi.org/10.1016/j.jbi.2022.104201. \n[36] Marteau BL, Zhu Y, Giuste F, et al. Accelerating multi-site health informatics with \nstreamlined data infrastructure using OMOP-on-FHIR. 2022 44th Annu. Int. Conf. \nIEEE Eng. Med. Biol. Soc. EMBC, Glasgow, Scotland, United Kingdom: IEEE; \n2022, p. 4687–90. https://doi.org/10.1109/EMBC48229.2022.9871865. \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n40 \n[37] OMOP on FHIR. GitHub n.d. https://github.com/omoponfhir (accessed May 26, \n2023). \n[38] Boussadi A, Zapletal E. A Fast Healthcare Interoperability Resources (FHIR) layer \nimplemented over i2b2. BMC Med Inform Decis Mak 2017;17:120. \nhttps://doi.org/10.1186/s12911-017-0513-6. \n[39] Kasthurirathne SN, Mamlin B, Kumara H, et al. Enabling better interoperability for \nhealthcare: lessons in developing a standards based application programming \ninterface for electronic medical record systems. J Med Syst 2015;39:182. \n[40] Hersh WR, Weiner MG, Embi PJ, et al. Caveats for the use of operational \nelectronic health record data in comparative effectiveness research. Med Care \n2013;51:S30-37. https://doi.org/10.1097/MLR.0b013e31829b1dbd. \n[41] Matcho A, Ryan P, Fife D, et al. Fidelity assessment of a clinical practice research \ndatalink conversion to the OMOP common data model. Drug Saf 2014. \nhttps://doi.org/10.1007/s40264-014-0214-3. \n[42] Hripcsak G, Levine ME, Shang N, et al. Effect of vocabulary mapping for conditions \non phenotype cohorts. J Am Med Inform Assoc 2018;0:8. \n[43] Papez V, Moinat M, Payralbe S, et al. Transforming and evaluating electronic \nhealth record disease phenotyping algorithms using the OMOP common data \nmodel: A case study in heart failure. JAMIA Open 2021:ooab001. \nhttps://doi.org/10.1093/jamiaopen/ooab001. \n \n \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint \n\n41 \n \n . CC-BY 4.0 International licenseIt is made available under a \n is the author/funder, who has granted medRxiv a license to display the preprint in perpetuity. (which was not certified by peer review)\nThe copyright holder for this preprint this version posted August 15, 2023. ; https://doi.org/10.1101/2023.08.09.23293900doi: medRxiv preprint","source_license":"CC-BY-4.0","license_restricted":false}