Procedure Resource Considerations

OMOP CDM Domain Assignment

There may be variability in source EHR data representation, where each EHR may represent the same clinical activity differently when exported to FHIR. For instance, some procedures in FHIR are represented in the Measurements or Observations domains in OMOP, such as lab orders and diagnostic imaging. It is a mapping challenge in deciding whether to map individual activities to the OMOP Procedure Occurrence, Measurement, or Observation domains. This is determined by domain assignment of the target OMOP concept_id(s) for any given procedure represented on FHIR. An evaluation of each source procedure that differentiates true procedures (e.g., surgeries) from diagnostic activities is necessary to avoid FHIR procedure resource data misclassification. Activities should be mapped to the appropriate OMOP measurement or observation tables rather than procedure_occurrence through evaluation of the underlying concepts and which domain each is represented withtin the OHDSI Standardized Vocabularies. (See: OMOP Domain Assignment Logic for additional infomration)

Temporal Context and Encounter Linkage

The performedDateTime or performedPeriod fields should map to procedure_date in OMOP, with the start date serving as the primary temporal reference. When a performedPeriod includes an end date, this may optionally map to procedure_end_date to capture procedure duration. The associated Encounter should map to visit_occurrence_id, establishing the contextual relationship between the procedure and the healthcare visit.

Provider Attribution

When available, the Performer field should map to provider_id in the procedure_occurrence table. While not all data sources provide specific performer information, including this mapping when possible enhances analytical capabilities for provider attribution studies.

Status and Type Considerations

Procedure Status Handling

Only completed procedures should be mapped to the OMOP procedure_occurrence table. Transformation should filter out planned, cancelled, or incomplete procedures to ensure data integrity. This filtering criterion should be clearly documented in ETL specifications.

Procedure Type Classification

The procedure type should be mapped to procedure_type_concept_id based on the healthcare setting context, such as inpatient surgery or outpatient diagnostic procedures. This classification helps differentiate care settings and supports research into distinctions between venues of care delivery.

/// url = 'http://hl7.org/fhir/uv/omop/StructureMap/ProcedureMap'
/// name = 'ProcedureMap'
/// title = 'Mapping Procedure resource to Procedure Occurrence OMOP Domain'
/// status = 'draft'

uses "http://hl7.org/fhir/StructureDefinition/Procedure" alias Procedure as source
uses "http://hl7.org/fhir/uv/omop/StructureDefinition/ProcedureOccurrence" alias ProcedureTable as target

group ProcedureOccurrence(source src : Procedure, target tgt : ProcedureTable) {
  src.code as s -> tgt then {
    s.coding as sc -> tgt then {
      sc.code as a ->  tgt.procedure_concept_id,  tgt.procedure_source_value,  tgt.procedure_source_concept_id = a;
    };
  }; // src.id as id -> tgt.procedure_occurrence_id = cast(id, "integer");
  src.occurrence : dateTime as edt ->  tgt.procedure_datetime = cast(edt, 'dateTime'),  tgt.procedure_date = edt;
  src.occurrence : Period as s -> tgt then {
    s.start as start ->  tgt.procedure_datetime = cast(start, 'dateTime'),  tgt.procedure_date = start;
    s.end as end ->  tgt.procedure_end_datetime,  tgt.procedure_end_date = end;
  };
}