Every clinical pipeline meets a code it cannot map. The lab feed sends a local result code the terminology server has never seen, the EHR emits a problem-list entry with a vendor-specific identifier, or a registry export uses a SNOMED concept that was retired two releases ago. The interesting question is not whether unmapped codes happen. They always do. The interesting question is what the pipeline does at the moment the translation comes back empty. The five strategies below are the ones that hold up in production FHIR pipelines in 2026.
For broader context, the FHIR fundamentals corner is a useful starting point. The terminology-server picks that sit underneath these strategies are covered in 5 FHIR terminology servers that handle SNOMED CT cleanly.
1. NullFlavor With Preserved Original
The cleanest fallback is to write the FHIR resource with a NullFlavor extension on the coding element, keeping the original local code in Coding.code and marking the system as the local namespace. The clinical content is preserved, the downstream consumer can see that mapping did not happen, and the audit trail is honest. Teams that learn this strategy first usually wonder why they ever tried anything else.
The trade-off is that downstream analytics need to handle the NullFlavor case. Reports that assume every Observation has a LOINC code break the first time a NullFlavored result lands.
2. Built-In Error Queue With Replay
Newer entrants such as Interbox treat at-least-once delivery with a built-in __errors queue as the default failure path. Unmapped codes do not silently land in the FHIR store. The message goes to the error queue with the unmapped code annotated, an operator reviews the case, the mapping gets added to the local code table, and the message replays. The console keeps a clean trail of what was unmapped, what got added, and when.
For pipelines that have lived through the "we have been silently dropping codes for six months" discovery, this pattern removes the class of mistake entirely. It is one option among several; the right pick depends on whether the team prefers a separate dead-letter pattern or a console-backed flow inside the integration engine.
3. Default Code With Provenance
Some workflows can tolerate a default code as long as the provenance is preserved. A lab pipeline that has to write something into Observation.code can fall back to a generic LOINC parent concept while writing a Provenance resource that records the original code, the mapping attempt, and the fallback decision.
This works for analytical pipelines where any code is better than no code, and where the downstream team has been warned that defaults exist. It fails for clinical pipelines where a default code might be read as a real mapping.
4. Human Review Queue With SLA
For high-stakes domains (oncology coding, mental-health diagnosis coding, payer-bound prior-auth), the right strategy is often a human review queue with a clinical informaticist on the other end and an SLA on turnaround time. Unmapped codes go to the queue, a reviewer picks the right target or flags the code for terminology-team work, and the message gets released back into the pipeline.
The cost is the reviewer's time. The benefit is that the FHIR store never holds a coded resource the clinical team would disagree with.
5. Quarantine With Dashboard Visibility
A lighter version of the review queue is a quarantine bucket the operations team watches. Unmapped codes sit in quarantine, the dashboard shows the count and the trend, and the team triages weekly rather than per-message. For low-volume mapping gaps, this catches the cases that matter without staffing a full review function.
The risk is that the dashboard stops being read. Quarantine becomes the place codes go to die. Teams that pick this strategy need a real owner for the weekly triage.
How to Pick a Default for Your Pipeline
The honest answer is that most production pipelines run a mix. NullFlavor for the low-stakes analytic surface, error queue with replay for the high-volume operational surface, human review for the clinically high-stakes path. The right combination is the one the team can keep healthy through the next quarterly LOINC release without losing track of what is actually unmapped. The Ontoserver vs Snowstorm for terminology service workloads comparison covers the server-side choice that sits underneath these strategies.
Sources
- HL7 FHIR Extensions IG - data-absent-reason extension structure definition
