Surgical FHIR Pipeline

The big picture: a translation & customs checkpoint

🤖 World A — the operating room

A surgical robot emits rich data in the manufacturer's private shorthand — e.g. RAS-CHOL-01. It's high-frequency, denormalised, nullable, and coded in a vocabulary no receiving system has ever heard of.

🏥 World B — the medical record

EHRs, surgical registries and safety-surveillance systems only accept the FHIR standard, using global vocabularies (SNOMED, LOINC). Like filing a legal document instead of passing a handwritten note.

The core idea 💡

This is not mainly a technical problem — it's a semantics & governance problem. The pipeline's value isn't "we produced FHIR." It's: "we know exactly what gets destroyed in translation, we refuse to hide it, and we prove it with numbers."

That 80% exchangeability figure is the whole point. A pipeline that reports 100% is either being fed clean data or lying to you.

Three moves, end to end

1 · Translate map private codes → standard codes, each stamped with a trust level (Verified / Provisional).

2 · Reshape + Gate restructure into FHIR resources; reject dangerous records rather than degrade them.

3 · Publish honestly serve clean data over a FHIR API and emit a governance quality report.

The workflow, step by step

Click any step to expand the detail.

The 7 interoperability failure modes

Each card is a real failure the pipeline hits. Click to flip and see the decision.

Case Simulator — apply the pipeline's rules

Configure a synthetic case and run it through the decision engine. This mirrors mapping.py's logic: drop, don't degrade.

⚖️ Governance policy — flip a rule, watch the cohort move

Drop on unmapped codeoff → emit text-only (keeps 8% volume, arguably unsafe) Drop on missing lateralityoff → emit with dataAbsentReason on bodySite

Sample cohort of 25 cases —

Clean Exchangeable (flagged) Dropped

Procedure code Requires laterality? (e.g. hernia repair) Laterality provided? SpO₂ sensor reading (%) Temperature unit declared? Raw telemetry points

Awaiting input…

Configure a case and press run to see whether it becomes exchangeable, gets flagged, or is dropped.

Check your understanding

Score: 0 / 0

Glossary

FHIR (R4B): Fast Healthcare Interoperability Resources — the standard exchange format for clinical data. R4B is the maintenance release of R4. It is an exchange format, not a raw data store.
Resource: A structured FHIR object: Patient, Encounter, Procedure, Device, Observation, etc. The pipeline emits 953 of these across 20 cases.
SNOMED CT: A comprehensive clinical terminology (procedures, findings). Licensed content — here procedure bindings are marked PROVISIONAL because they weren't validated against a licensed release.
LOINC: Codes for lab & vital-sign observations (e.g. 8867-4 heart rate). Freely published → bindings marked VERIFIED.
UCUM: Unified Code for Units of Measure. Prevents the "37°C vs 37°F" catastrophe — unknown units raise an error rather than pass silently.
Binding trust status: Every code translation carries VERIFIED (stand behind it) or PROVISIONAL (plausible but unconfirmed by a clinical informaticist). Turns a hidden risk into a tracked field.
MappingIssue: A logged record of every lossy decision made during transformation — the raw material of the quality report.
Transaction Bundle: A batch of resources submitted together. Uses idempotent PUT so retries/backfills don't create duplicate clinical records.
CapabilityStatement: Served at /metadata — a machine-readable description of what the FHIR API supports.
entered-in-error / dataAbsentReason: FHIR mechanisms to record that a value should not be trusted — the failure survives, the bad number doesn't.
Exchangeable: A case that survived every quality gate and can be safely handed to a receiving system. 20 / 25 here.