refs/fhir2omop-cookbook.md
lines 160–162
576 lines · md
5- **Project Name:** FHIR-to-OMOP Cookbook 6- **URL:** https://github.com/CodeX-HL7-FHIR-Accelerator/fhir2omop-cookbook 7- **Organization:** CodeX HL7 FHIR Accelerator 8- **License:** Apache License 2.0 12The FHIR-to-OMOP Cookbook is a starter guide for implementers seeking to convert HL7 FHIR resources to the OMOP CDM (Common Data Model). The cookbook compares the purpose and design principles of both FHIR and OMOP CDM, proposes a methodology for mapping with example use cases, and provides patterns for mapping FHIR resources to equivalent OMOP CDM elements. 16The conversion of Electronic Health Record (EHR) data from Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR) to the Observational Medical Outcomes Partnership (OMOP) Common Data Model (CDM) is becoming increasingly standardized for research, though inconsistent in use among implementers. To address this, HL7 and the Observational Health Data Sciences and Informatics (OHDSI) formed a partnership in 2021, focusing on better alignment between FHIR and the OMOP CDM, including mapping minimal Common Oncology Data Elements (mCODE) v2.0 FHIR resources to OMOP CDM v5.4. 20- Holistic mapping approach 21- Starter guide for implementers 22- Step-by-step practical guidelines 23- Example use cases and patterns 24- Guidance for seamless integration of FHIR resources with the OMOP CDM 28The cookbook outlines an 8-step method: 301. **Define the FHIR elements** that are relevant to represent in OMOP 312. **Identify the OMOP concept** that best matches each of the FHIR element 323. **Determine the OMOP CDM table** based on the OHDSI-assigned domain for the OMOP concept 334. **Map related FHIR resources** to the OMOP CDM table required fields 345. **Populate the OMOP CDM records** at the source record level 356. **Apply references and relationships** among the OMOP CDM records, linking back to the original resource where possible 367. **Test OMOP CDM mapping** and completeness 378. **Compare FHIR and OMOP representations** for a known set of patient information for accuracy and identify gaps 41The FHIR-to-OMOP Cookbook methodology was tested in the May 2022 HL7 FHIR Connectathon with mappings from mCODE v2.0 and OMOP CDM v5.4. 45- OMOP CDM 5.4 Database 47## FHIR Resources Covered 49Based on the mCODE (minimal Common Oncology Data Elements) v2.0 focus: 50- Cancer-related FHIR resources from mCODE implementation guide 54- OMOP CDM v5.4 tables (specific tables determined by OHDSI-assigned domains for mapped concepts) 58Over 80% of the mCODE FHIR-based elements were mapped. Gaps and learnings from the mapping and testing process were documented in the FHIR-to-OMOP Cookbook. 62Although FHIR and OMOP are widely adopted standards, their purpose and data modeling differences require further guidance, including a methodology on how to integrate both process and technical transformations. The FHIR-to-OMOP Cookbook is an initial step in providing this guidance, and can be used to inform other interoperability efforts such as the HL7 Vulcan FHIR to OMOP project. 66- Documentation-based (Word document, poster) 67- No specific programming language implementation 68- Methodology and guidance document 721. FHIR to OMOP Cookbook (Word document) 732. FHIR to OMOP Cookbook Poster (PNG image) 77- May Terry, MITRE - mayT@mitre.org 78- Guy Livne, Kineret - Ministry of Health Israel - guy.livne@moh.gov.il 79- Qi Yang, IQVIA - qi.yang1@iqvia.com 81## Contributing Organizations 84- Kineret (Ministry of Health Israel) 90Work in progress - the cookbook will evolve over time to incorporate new insights and community feedback. Contributions are encouraged via: 92- GitHub issues: https://github.com/CodeX-HL7-FHIR-Accelerator/fhir2omop-cookbook/issues 93- GitHub notifications for updates 97## Patient → OMOP Mapping Details 99**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 101The cookbook provides conceptual guidance rather than executable code. Key points from the document regarding Patient→Person mapping: 103### FHIR Patient → OMOP PERSON 105| OMOP PERSON Field | FHIR Patient Source | Notes from Cookbook | 106|-------------------|---------------------|---------------------| 107| `person_id` | (generated) | Need to link from PERSON table with join to Person_Source_Value | 108| `year_of_birth` | `Patient.birthDate` | Direct mapping mentioned | 109| `gender_concept_id` | `Patient.gender` | See gender identity considerations below | 110| `race_concept_id` | (extensions) | OMB Race codes don't have direct OMOP concept IDs | 111| `ethnicity_concept_id` | (extensions) | OMB Ethnicity codes don't have direct OMOP concept IDs | 112| `provider_id` | `Patient.generalPractitioner` | Referenced as Patient.provider | 113| `care_site_id` | `Patient.managingOrganization` | Organization managing the patient | 114| `person_source_value` | `Patient.identifier` | Used for joining back to PERSON table | 116### Patterns Documented 118The cookbook mentions these relevant patterns: 1201. **FHIR Patient, Person, and Practitioner Patterns** - General demographic mapping guidance 1212. **Pattern: Handling person names** - FHIR supports multiple names with qualifiers (legal, birth, etc.) 1223. **Patient-stated Conditions** - Handling patient-reported data 124### Gender Identity Mapping 126The cookbook addresses gender identity mapping challenges: 127- References HL7 Gender Identity ValueSet: https://terminology.hl7.org/5.5.0/ValueSet-gender-identity.html 128- Notes complexity of mapping "Identifies as female gender" and similar values 129- Acknowledges race and ethnicity concepts that are more detailed than existing OMOP vocabulary 133- OMB Race and Ethnicity category codes do not have direct OMOP concept IDs 134- FHIR supports multiple person names; OMOP has single name fields 135- Patient residential addresses (beyond postal/zip code) handling 136- Gender identity vs biological sex distinction 140- This is a **guidance document**, not executable code 141- Mapping methodology is conceptual (8-step process) 142- Tested at May 2022 HL7 FHIR Connectathon with mCODE v2.0 → OMOP CDM v5.4 143- Over 80% of mCODE elements were successfully mapped 147## Observation → OMOP Mapping Details 149**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 151**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The Observation mapping follows the 8-step methodology outlined in the cookbook. 153### FHIR Observation → OMOP (Conceptual Guidance) 155Based on the cookbook methodology: 1571. **Define the FHIR elements**: Identify Observation attributes (code, value, effective date, etc.) 1582. **Identify the OMOP concept**: Map `Observation.code` to OMOP standard concept via vocabulary lookup 1593. **Determine the OMOP CDM table**: Based on concept's domain_id: 160 - Domain = "Measurement" → `measurement` table 161 - Domain = "Observation" → `observation` table 162 - Domain = "Procedure" → `procedure_occurrence` table 1634. **Map related FHIR resources**: Link to Person (via `subject`) and Visit (via `encounter`) 1645. **Populate the OMOP CDM records**: At source record level 166### Expected Mappings (Conceptual) 168| OMOP Field | FHIR Observation Source | Notes | 169|------------|-------------------------|-------| 170| `*_concept_id` | `Observation.code` | Via vocabulary translation | 171| `*_date` | `Observation.effectiveDateTime` | Date component | 172| `*_datetime` | `Observation.effectiveDateTime` | Full timestamp | 173| `value_as_number` | `Observation.valueQuantity.value` | Numeric results | 174| `value_as_concept_id` | `Observation.valueCodeableConcept` | Coded results | 175| `unit_concept_id` | `Observation.valueQuantity.unit` | Unit mapping | 176| `person_id` | `Observation.subject` | Reference to Patient→Person | 177| `visit_occurrence_id` | `Observation.encounter` | Reference to Encounter→Visit | 178| `provider_id` | `Observation.performer` | Reference to Practitioner→Provider | 179| `*_source_value` | `Observation.code.coding[].code` | Original source code | 181### Patterns Documented 183The cookbook addresses laboratory and clinical observation patterns within the mCODE context, including: 184- Cancer-related lab results (tumor markers, etc.) 185- Staging observations 186- Performance status observations 190- The cookbook is conceptual guidance, not executable code 191- Domain-based routing (Measurement vs Observation) follows OHDSI vocabulary 192- Specific mCODE-related observations were tested at HL7 Connectathon 193- Reference resolution (person_id, visit_occurrence_id) requires implementation-specific handling 197## Encounter → OMOP VISIT_OCCURRENCE Mapping 199**Status**: Conceptual guidance (Word document) 203The cookbook provides conceptual mapping guidance for Encounter → VISIT_OCCURRENCE following the 8-step ETL methodology: 2051. **Source Analysis**: Identify Encounter resources in source FHIR data 2062. **Target Analysis**: Review OMOP VISIT_OCCURRENCE table requirements 2073. **Gap Analysis**: Identify mapping challenges 2084. **Value Mapping**: Map class codes to visit concepts 2095. **Business Rules**: Define visit type assignment rules 2106. **Technical Specification**: Document field-level mappings 2117. **Implementation**: Build ETL logic 2128. **Validation**: Test transformed data 214### Key Mapping Concepts 216| FHIR Encounter Field | OMOP VISIT_OCCURRENCE Field | Notes | 217|---------------------|----------------------------|-------| 218| `Encounter.id` | `visit_source_value` | Source identifier | 219| `Encounter.class` | `visit_concept_id` | Via vocabulary lookup | 220| `Encounter.period.start` | `visit_start_date/datetime` | Date extraction | 221| `Encounter.period.end` | `visit_end_date/datetime` | Date extraction | 222| `Encounter.subject` | `person_id` | Reference resolution | 223| `Encounter.participant` | `provider_id` | Reference resolution | 224| `Encounter.serviceProvider` | `care_site_id` | Reference resolution | 225| `Encounter.hospitalization.admitSource` | `admitted_from_concept_id` | Via vocabulary lookup | 226| `Encounter.hospitalization.dischargeDisposition` | `discharged_to_concept_id` | Via vocabulary lookup | 230- The cookbook is conceptual guidance, not executable code 231- Visit type assignment (IP, OP, ER) follows OHDSI vocabulary patterns 232- Reference resolution requires implementation-specific handling 233- Documented as part of mCODE/CodeX FHIR Accelerator project 237## Condition → OMOP CONDITION_OCCURRENCE Mapping 239**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 241**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. 243### Mapping Methodology (8-Step Process) 245Following the cookbook's methodology for Condition: 2471. **Define the FHIR elements**: Identify Condition attributes (code, onset, clinical status, etc.) 2482. **Identify the OMOP concept**: Map `Condition.code` to OMOP standard concept via vocabulary lookup 2493. **Determine the OMOP CDM table**: Based on concept's domain_id: 250 - Domain = "Condition" → `condition_occurrence` table 251 - Domain = "Observation" → `observation` table (for some findings) 2524. **Map related FHIR resources**: Link to Person (via `subject`) and Visit (via `encounter`) 2535. **Populate the OMOP CDM records**: At source record level 2546. **Apply references and relationships**: Link to visit, provider 2557. **Test mapping**: Validate completeness 2568. **Compare representations**: Verify accuracy 258### Expected Mappings (Conceptual) 260| OMOP CONDITION_OCCURRENCE Field | FHIR Condition Source | Notes | 261|---------------------------------|----------------------|-------| 262| `condition_concept_id` | `Condition.code` | Via vocabulary translation (ICD-10, SNOMED) | 263| `condition_start_date` | `Condition.onsetDateTime` | Date component | 264| `condition_start_datetime` | `Condition.onsetDateTime` | Full timestamp | 265| `condition_end_date` | `Condition.abatementDateTime` | If resolved | 266| `condition_end_datetime` | `Condition.abatementDateTime` | If resolved | 267| `condition_type_concept_id` | `Condition.category` | Problem list vs encounter diagnosis | 268| `condition_status_concept_id` | `Condition.clinicalStatus` | Active, resolved, etc. | 269| `person_id` | `Condition.subject` | Reference to Patient→Person | 270| `visit_occurrence_id` | `Condition.encounter` | Reference to Encounter→Visit | 271| `provider_id` | `Condition.asserter` | Reference to Practitioner→Provider | 272| `condition_source_value` | `Condition.code.coding[].code` | Original source code | 273| `stop_reason` | `Condition.abatementString` | Reason for resolution | 275### Category Mapping Guidance 277| FHIR Category | OMOP Type Concept Guidance | 278|---------------|---------------------------| 279| `problem-list-item` | Problem list entry type | 280| `encounter-diagnosis` | Encounter diagnosis type | 281| (other) | Implementation-specific | 285- Clinical status mapping (active, resolved) to OMOP `condition_status_concept_id` 286- Verification status has no direct OMOP equivalent 287- Severity and stage may require separate observation records 288- Body site handling for detailed anatomical location 292- This is a **guidance document**, not executable code 293- Domain-based routing follows OHDSI vocabulary 294- mCODE-specific conditions (cancer staging, etc.) were tested at HL7 Connectathon 295- Reference resolution (person_id, visit_occurrence_id) requires implementation-specific handling 299## Procedure → OMOP PROCEDURE_OCCURRENCE Mapping 301**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 303**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The Procedure mapping follows the 8-step methodology outlined in the cookbook. 305### FHIR Procedure → OMOP PROCEDURE_OCCURRENCE (Conceptual Guidance) 307Based on the cookbook methodology: 3091. **Define the FHIR elements**: Identify Procedure attributes (code, performed date, status, etc.) 3102. **Identify the OMOP concept**: Map `Procedure.code` to OMOP standard concept via vocabulary lookup 3113. **Determine the OMOP CDM table**: Based on concept's domain_id: 312 - Domain = "Procedure" → `procedure_occurrence` table 313 - Domain = "Drug" → `drug_exposure` table (for drug administrations) 314 - Domain = "Device" → `device_exposure` table 3154. **Map related FHIR resources**: Link to Person (via `subject`) and Visit (via `encounter`) 3165. **Populate the OMOP CDM records**: At source record level 318### Expected Mappings (Conceptual) 320| OMOP PROCEDURE_OCCURRENCE Field | FHIR Procedure Source | Notes | 321|---------------------------------|----------------------|-------| 322| `procedure_concept_id` | `Procedure.code` | Via vocabulary translation | 323| `procedure_date` | `Procedure.performed[x]` | Date component | 324| `procedure_datetime` | `Procedure.performed[x]` | Full timestamp | 325| `procedure_end_date` | `Procedure.performedPeriod.end` | End date if period | 326| `procedure_end_datetime` | `Procedure.performedPeriod.end` | End timestamp | 327| `procedure_type_concept_id` | (derived) | EHR, claim, or other source type | 328| `modifier_concept_id` | `Procedure.bodySite` | Body site or other modifier | 329| `quantity` | (derived from extensions) | Number of procedures | 330| `person_id` | `Procedure.subject` | Reference to Patient→Person | 331| `visit_occurrence_id` | `Procedure.encounter` | Reference to Encounter→Visit | 332| `provider_id` | `Procedure.performer[].actor` | Reference to Practitioner→Provider | 333| `procedure_source_value` | `Procedure.code.coding[].code` | Original source code | 334| `procedure_source_concept_id` | `Procedure.code` | Source vocabulary concept | 336### Domain-Based Routing Guidance 338The cookbook methodology indicates procedures may route to multiple OMOP tables: 340| FHIR Procedure Type | Potential OMOP Table | 341|--------------------|---------------------| 342| Surgical procedure | `procedure_occurrence` | 343| Drug administration | `drug_exposure` | 344| Device implantation | `device_exposure` + `procedure_occurrence` | 348- Status mapping (completed, in-progress) - OMOP has no status field 349- Reason/indication handling 350- Complication recording 351- Device used during procedure (usedCode, usedReference) 355- This is a **guidance document**, not executable code 356- Domain-based routing follows OHDSI vocabulary 357- mCODE-specific procedures were tested at HL7 Connectathon 358- Reference resolution requires implementation-specific handling 362## MedicationStatement → OMOP DRUG_EXPOSURE Mapping 364**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 366**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The MedicationStatement mapping follows the 8-step methodology outlined in the cookbook. 368### FHIR MedicationStatement → OMOP DRUG_EXPOSURE (Conceptual Guidance) 370Based on the cookbook methodology: 3721. **Define the FHIR elements**: Identify MedicationStatement attributes (medication code, effective period, dosage, etc.) 3732. **Identify the OMOP concept**: Map `MedicationStatement.medication` to OMOP drug concept via vocabulary lookup 3743. **Determine the OMOP CDM table**: Route to `drug_exposure` table 3754. **Map related FHIR resources**: Link to Person (via `subject`) and Visit (via `context`) 3765. **Populate the OMOP CDM records**: At source record level 378### Expected Mappings (Conceptual) 380| OMOP DRUG_EXPOSURE Field | FHIR MedicationStatement Source | Notes | 381|--------------------------|--------------------------------|-------| 382| `drug_concept_id` | `MedicationStatement.medication` | Via vocabulary translation | 383| `drug_exposure_start_date` | `MedicationStatement.effective[x]` | Start date | 384| `drug_exposure_start_datetime` | `MedicationStatement.effective[x]` | Start timestamp | 385| `drug_exposure_end_date` | `MedicationStatement.effectivePeriod.end` | End date | 386| `drug_exposure_end_datetime` | Same | End timestamp | 387| `drug_type_concept_id` | (derived) | EHR, claim, patient-reported | 388| `stop_reason` | `MedicationStatement.statusReason` | Reason for discontinuation | 389| `route_concept_id` | `MedicationStatement.dosage[].route` | Administration route | 390| `quantity` | `MedicationStatement.dosage[].doseAndRate[]` | Dose quantity | 391| `person_id` | `MedicationStatement.subject` | Reference to Patient→Person | 392| `visit_occurrence_id` | `MedicationStatement.context` | Reference to Encounter→Visit | 393| `provider_id` | `MedicationStatement.informationSource` | Reference to Practitioner→Provider | 394| `drug_source_value` | `MedicationStatement.medication.coding[].code` | Original source code | 396### Drug Type Concepts 398The cookbook references different provenance types: 400| Drug Type | OMOP Concept | FHIR Source | 401|-----------|--------------|-------------| 402| Patient Self-Reported | 44787730 | MedicationStatement | 403| Prescription Written | 38000177 | MedicationRequest | 404| Prescription Dispensed | 38000175 | MedicationDispense | 405| EHR Drug List | 38000178 | MedicationStatement | 409- This is a **guidance document**, not executable code 410- mCODE medication data was tested at HL7 Connectathon 411- Dosage handling requires careful mapping (route, quantity, frequency) 412- Reference resolution requires implementation-specific handling for Person/Visit 416## Immunization → OMOP DRUG_EXPOSURE Mapping 418**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 420**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The Immunization mapping follows the 8-step methodology outlined in the cookbook. 422### FHIR Immunization → OMOP DRUG_EXPOSURE (Conceptual Guidance) 424Based on the cookbook methodology: 4261. **Define the FHIR elements**: Identify Immunization attributes (vaccineCode, occurrence, lotNumber, site, route, etc.) 4272. **Identify the OMOP concept**: Map `Immunization.vaccineCode` to OMOP drug concept via CVX vocabulary lookup 4283. **Determine the OMOP CDM table**: Route to `drug_exposure` table 4294. **Map related FHIR resources**: Link to Person (via `patient`) and Visit (via `encounter`) 4305. **Populate the OMOP CDM records**: At source record level 432### Expected Mappings (Conceptual) 434| OMOP DRUG_EXPOSURE Field | FHIR Immunization Source | Notes | 435|--------------------------|-------------------------|-------| 436| `drug_concept_id` | `Immunization.vaccineCode` | Via CVX vocabulary translation | 437| `drug_exposure_start_date` | `Immunization.occurrenceDateTime` | Administration date | 438| `drug_exposure_start_datetime` | `Immunization.occurrenceDateTime` | Full timestamp | 439| `drug_exposure_end_date` | `Immunization.occurrenceDateTime` | Same as start (single dose) | 440| `drug_exposure_end_datetime` | Same | Same as start | 441| `drug_type_concept_id` | (derived) | 38000179 (Physician administered) | 442| `route_concept_id` | `Immunization.route` | Administration route | 443| `quantity` | `Immunization.doseQuantity` | Dose amount | 444| `lot_number` | `Immunization.lotNumber` | Vaccine lot tracking | 445| `person_id` | `Immunization.patient` | Reference to Patient→Person | 446| `visit_occurrence_id` | `Immunization.encounter` | Reference to Encounter→Visit | 447| `provider_id` | `Immunization.performer[].actor` | Reference to Practitioner→Provider | 448| `drug_source_value` | `Immunization.vaccineCode.coding[].code` | Original CVX code | 450### Drug Type Concept for Immunizations 452| Source Type | OMOP Concept ID | Description | 453|-------------|-----------------|-------------| 454| Physician Administered | 38000179 | Physician administered drug (inpatient setting) | 455| Self-Reported | 44787730 | Patient Self-Reported Medication | 457### Vocabulary Considerations 459- **CVX** (Vaccines Administered): Primary vocabulary for vaccine codes 460- Mapping from CVX to OMOP standard concepts required 461- Some CVX codes may not have direct OMOP mappings 465- This is a **guidance document**, not executable code 466- Immunizations typically map to `drug_exposure` with CVX vocabulary 467- Single-dose vaccines have same start and end dates 468- Reference resolution requires implementation-specific handling 472## AllergyIntolerance → OMOP OBSERVATION Mapping 474**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 476**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The AllergyIntolerance mapping follows the 8-step methodology outlined in the cookbook. 478### FHIR AllergyIntolerance → OMOP OBSERVATION (Conceptual Guidance) 480Based on the cookbook methodology: 4821. **Define the FHIR elements**: Identify AllergyIntolerance attributes (code, category, onsetDateTime, reaction, etc.) 4832. **Identify the OMOP concept**: Map `AllergyIntolerance.code` to OMOP observation concept via vocabulary lookup 4843. **Determine the OMOP CDM table**: Route to `observation` table (allergies are clinical findings) 4854. **Map related FHIR resources**: Link to Person (via `patient`) and Visit (via `encounter`) 4865. **Populate the OMOP CDM records**: At source record level 488### Expected Mappings (Conceptual) 490| OMOP OBSERVATION Field | FHIR AllergyIntolerance Source | Notes | 491|------------------------|-------------------------------|-------| 492| `observation_concept_id` | `AllergyIntolerance.code` | Via vocabulary translation | 493| `observation_date` | `AllergyIntolerance.onsetDateTime` | Onset date | 494| `observation_datetime` | `AllergyIntolerance.onsetDateTime` | Full timestamp | 495| `observation_type_concept_id` | (derived) | 38000280 (Physical examination) | 496| `value_as_concept_id` | `AllergyIntolerance.reaction[].manifestation` | Reaction type | 497| `value_as_string` | `AllergyIntolerance.reaction[].description` | Reaction description | 498| `person_id` | `AllergyIntolerance.patient` | Reference to Patient→Person | 499| `visit_occurrence_id` | `AllergyIntolerance.encounter` | Reference to Encounter→Visit | 500| `provider_id` | `AllergyIntolerance.recorder` | Reference to Practitioner→Provider | 501| `observation_source_value` | `AllergyIntolerance.code.coding[].code` | Original code | 503### Key Design Decision: Observation vs Drug_Exposure 505AllergyIntolerance maps to OMOP **`observation`** table (not `drug_exposure`) because: 506- Allergies are clinical findings/observations, not drug administrations 507- OMOP's `observation` table is designed for clinical findings 508- Consistent with OHDSI conventions for allergy recording 510### Category Mapping Guidance 512| FHIR Category | OMOP Observation Concept Guidance | 513|---------------|-----------------------------------| 514| `food` | Food allergy concepts (e.g., 4188027) | 515| `medication` | Drug allergy concepts (e.g., 439224) | 516| `environment` | Environmental allergy concepts | 517| `biologic` | Biologic allergy concepts | 521- This is a **guidance document**, not executable code 522- AllergyIntolerance maps to `observation` table (clinical finding) 523- Reaction manifestations map to `value_as_concept_id` 524- Reference resolution requires implementation-specific handling 528## DiagnosticReport → OMOP Mapping 530**Source**: `FHIR to OMOP Cookbook.docx` (Word document - not programmatic) 532**Note**: This is a **guidance document** providing conceptual mapping methodology rather than executable code. The DiagnosticReport mapping follows the 8-step methodology outlined in the cookbook. 534### FHIR DiagnosticReport → OMOP (Conceptual Guidance) 536Based on the cookbook methodology: 5381. **Define the FHIR elements**: Identify DiagnosticReport attributes (code, effectiveDateTime, conclusionCode, category, etc.) 5392. **Identify the OMOP concept**: Map `DiagnosticReport.code` to OMOP concept via LOINC vocabulary lookup 5403. **Determine the OMOP CDM table**: Route based on concept domain: 541 - Observation domain → `observation` 542 - Measurement domain → `measurement` 543 - Procedure domain → `procedure_occurrence` 5444. **Map related FHIR resources**: Link to Person (via `subject`) and Visit (via `encounter`) 5455. **Populate the OMOP CDM records**: At source record level 547### Expected Mappings (Conceptual) 549| OMOP Field | FHIR DiagnosticReport Source | Notes | 550|------------|------------------------------|-------| 551| `*_concept_id` | `DiagnosticReport.code` | Via LOINC vocabulary translation | 552| `*_date` | `DiagnosticReport.effectiveDateTime` | Date component | 553| `*_datetime` | `DiagnosticReport.effectiveDateTime` | Full timestamp | 554| `*_type_concept_id` | `DiagnosticReport.category` | Study category type | 555| `*_source_concept_id` | `DiagnosticReport.conclusionCode` | SNOMED conclusion | 556| `*_source_value` | `DiagnosticReport.conclusionCode.coding[].code` | Raw SNOMED code | 557| `person_id` | `DiagnosticReport.subject` | Reference to Patient→Person | 558| `visit_occurrence_id` | `DiagnosticReport.encounter` | Reference to Encounter→Visit | 559| `provider_id` | `DiagnosticReport.performer[].actor` | Reference to Practitioner→Provider | 561### Domain-Based Routing Guidance 563| LOINC Code Domain | Target OMOP Table | 564|-------------------|-------------------| 565| Observation | observation | 566| Measurement | measurement | 567| Procedure | procedure_occurrence | 571- This is a **guidance document**, not executable code 572- DiagnosticReport is a complex container resource 573- Maps to multiple OMOP tables based on LOINC code domain 574- May generate multiple OMOP records per conclusion code 575- Reference resolution requires implementation-specific handling