--- title: "OMOP & Interoperability — Master Speaker Notes" subtitle: "Instructor Teaching Guide · 2-Lecture Series" author: "Jonathan D. Stallings, PhD, MS" date: "Summer 2026" format: html: toc: true toc-depth: 3 toc-title: "Lecture Navigator" number-sections: true theme: cosmo --- > **How to use this guide.** Instructor-facing notes for the 2-lecture OMOP & Interoperability series. Audience: trauma registry analysts, informaticists, and data architects. This is an architecture-heavy series — most visuals are conceptual diagrams and tables rather than statistical simulations. The tone should be technically rigorous but grounded in operational consequences. --- # Lecture 1 — OMOP Foundations: Longitudinal Assumptions, Governance & Value-Level Metadata **Posts covered:** 01 (OMOP & longitudinal data), 02 (Interoperability as governance), 03 (Value-level metadata) ## Teaching strategy Open with a provocation: "Has anyone here tried to pool data from two different trauma registries that were both described as 'OMOP-compliant'? What happened when you actually queried them with the same SQL?" The answer, almost always: the results weren't comparable — not because the schema was wrong, but because the value definitions differed. This lecture makes the case that OMOP solves an important problem (schema standardization and vocabulary alignment) while leaving an equally important problem unsolved (value-level definitions, temporal conventions, governance). The audience should leave understanding which problems OMOP actually addresses — and which they still have to solve themselves. ## Key talking points **Slide: What OMOP Was Built to Do** Emphasize OHDSI's scale: 1+ billion patient records globally, federated analytics without data sharing. This is genuinely impressive. OMOP has transformed population health research for chronic disease. The question is not whether OMOP is good — it is — but whether it was built for this problem. **Slide: How Trauma Breaks the OMOP Assumptions** The scatter plot (time span vs. encounter count) is the central visualization. Walk through each point: - Diabetes: 10 years, 48 encounters → OMOP was designed for this - Combat trauma: 72 hours, 8 encounters → OMOP strains here The core tension: OMOP's visit_occurrence table captures individual encounters. Trauma generates multiple encounters at different echelons that constitute a single clinical episode. OMOP has no native "episode" linking mechanism. **Slide: The Episode Fragmentation Timeline** This is the most operationally relevant visualization in the lecture. Walk through each event and its OMOP representation. Then ask: "If I want to know whether a patient received damage control surgery within 6 hours of injury, what query do I write?" The answer requires joining four visit_occurrence records across three institutions — assuming they were linked, which OMOP provides no native mechanism to do. **Slide: The Comfortable Myth — Schema ≠ Interoperability** The key equation: > Schema + Vocabulary ≠ Interoperability > Schema + Vocabulary + Value definitions + Governance + Change control = Interoperability Walk through the concrete examples: "early tourniquet" defined as < 30 min at one site, < 60 min at another. Both OMOP-compliant. Incompatible for pooled analysis. **Slide: Interoperability Layers — Difficulty Scatter** The dot plot of difficulty vs. layer shows: OMOP addresses the two easiest layers reliably (schema, vocabulary). The hard layers — value definitions, temporal conventions, governance — require organizational decisions that OMOP cannot make for you. **Slide: The Value-Level Dictionary YAML Example** Read through this with the audience. Every field in the YAML has a specific function: - `valid_range` → what values are legal for this field? - `missing_codes` → what values signal "missing" vs. "zero"? - `provisional_flag` → can this value change after initial recording? - `temporal_reference` → when was this value collected (admission vs. discharge)? - `site_variations` → how does the meaning differ by care echelon? This is the artifact that makes two OMOP-compliant registries actually comparable. It takes governance infrastructure — not software — to produce and maintain. **Slide: Three-Tier Provenance** Tier 1 (source value) → Tier 2 (OMOP concept mapping) → Tier 3 (value-level metadata). Most implementations stop at Tier 2. The implication: "GSW_ABD_PENET" mapped to SNOMED 417746004 looks complete. But Site A includes blast in "penetrating" and Site B doesn't. That difference lives at Tier 3 — and Tier 2 doesn't capture it. ## Timing - OMOP and longitudinal data: 20 min - Interoperability as governance: 20 min - Value-level metadata: 15 min ## Discussion prompts "You're asked to run a federated query across three trauma registries for penetrating abdominal injury mortality. Both claim OMOP compliance. Before running the query, what five questions do you need to answer?" "What would a minimum viable value-level data dictionary look like for the DoDTR? What are the five most important fields to define — the ones where site variation is most likely to produce misleading pooled analyses?" --- # Lecture 2 — Making OMOP Work: Operational Systems & The Translation Layer **Posts covered:** 04 (Making OMOP trauma-ready), 05 (OMOP as translation layer) ## Teaching strategy Lecture 2 is more operational — how do you actually build an OMOP implementation that works for trauma? The central concepts are: provisional vs. final data, the episode layer above the CDM, latency management, and the civilian-military semantic gap. The civilian-military translation problem is where this lecture connects to the ethics and governance series. The semantic gap is not just a technical mapping problem — it's an accountability problem. When you pool civilian and military trauma data using naive OMOP concept mappings, you may be comparing incommensurable care episodes. If that pooled analysis informs a clinical practice guideline, the guideline is built on a false premise of equivalence. ## Key talking points **Slide: Provisional vs. Final Data Timeline** The dual-phase timeline (provisional at admission, finalized at discharge) is fundamental to trauma OMOP design. ISS may be revised. Mechanism of injury may be clarified. Complication codes may be added. A query run at admission time produces different results than a query run at discharge — the OMOP schema doesn't differentiate by default. Your implementation must. **Slide: Episode SQL Above CDM** This is the technical core of the lecture. The episode linkage logic is written above the OMOP CDM — in a view or application layer that joins visit_occurrence records by person_id and temporal proximity. Show the SQL conceptually (not character by character), and ask: "Where is this logic maintained? What happens when it changes? Is it versioned?" **Slide: ETL Latency Compliance** The compliance chart shows the 24-hour window between care and data availability as the operational target. Most current implementations are days to weeks. The ethical implication: CPG compliance monitoring that runs on 30-day-old data provides feedback too late to correct a pattern of care deviations. **Slide: The Semantic Gap Table** Walk through the civilian-military equivalence table row by row. For each row, ask: "If Site A maps 'Role 2 care' to visit_occurrence and Site B maps 'ED care' to visit_occurrence, what does a federated query for 'hospital encounter' return?" The answer depends on whether the OMOP concept mappings actually capture the same clinical entity — and often they don't. **Slide: The OMOP Capability Map** This is the reference visual for what OMOP does and doesn't handle in a trauma context. OMOP handles: vocabulary standardization, federated query infrastructure, CDM table structure. OMOP does not handle: episode linkage across echelons, provisional data versioning, civilian-military semantic translation, value-level governance. Everything in the second list requires additional institutional investment. **Slide: Governance Artifact List** The governance artifact list is the takeaway for practitioners: what does a complete OMOP trauma implementation governance package look like? Each artifact has an owner, a review cycle, and a version control requirement. If any artifact is missing, the implementation is incomplete — not just from an organizational standpoint, but from a research validity standpoint. ## Timing - Provisional/final data and episode logic: 20 min - Latency and operational requirements: 15 min - Civilian-military semantic gap: 20 min - OMOP capability map and governance: 5 min ## Series-Level Discussion Questions 1. A researcher claims their study is "OMOP-compliant" and therefore their results should be comparable to studies from other OMOP-compliant registries. What three questions would you ask before accepting this claim? 2. Your registry is being migrated to OMOP. You're asked to review the ETL specification. What would you look for in the value-level metadata section? What is the minimum acceptable level of documentation? 3. A federated query across DoDTR, VA, and two Level 1 civilian trauma centers returns mortality rates for penetrating abdominal injury. The DoDTR rate is 12%; the civilian average is 18%. Name three OMOP-level explanations for this difference that have nothing to do with actual differences in care. 4. The governance body for your trauma OMOP implementation needs to approve a change to the definition of "early tourniquet." Who should be in the room? What process should they follow? How should historical records be handled? 5. Your ETL pipeline has a 48-hour latency from care delivery to OMOP availability. A request comes in for daily CPG compliance monitoring. What can you realistically deliver, and what infrastructure changes would be required to meet the request fully?