A batch Bundle can return dozens of OperationOutcomes — one per failed entry, plus per-entry warnings. Reading them one at a time works for small batches and drowns the reader on large ones. Aggregation is the mechanism that turns "a wall of OperationOutcome JSON" into "here are three problems that cover ninety percent of the failures." The site's OperationOutcome reader does the aggregation when you paste a response Bundle. For the wider FHIR framing, the FHIR fundamentals reference has more.
What Comes Back On A Batch
A batch Bundle returns a response Bundle where each entry carries the per-entry outcome:
- 2xx status codes with the resulting resource
- 4xx / 5xx status codes with an OperationOutcome describing the failure
Batches with fifty entries can produce fifty OperationOutcomes. Reading them serially is not viable at that scale.
Group By Fingerprint
The right first step is grouping. A fingerprint is a tuple of (severity, code, first-diagnostics-line, expression-tail). Group all issues by fingerprint and count. A group of forty issues sharing the same fingerprint is one root cause and thirty-nine occurrences.
Presenting the reader with three fingerprints instead of fifty raw issues is the single biggest win. The tool reader does this by default.
Preserve Per-Entry Context
Aggregation must not lose the entry context. Each aggregated group should carry the list of Bundle entry indexes where the fingerprint fired. That way the reader can drill down from group to affected entries.
An aggregation that flattens away the entry context is useless for triage. Preserve it in the group's payload.
Rank By Impact
Not every group is equal. Rank groups by:
- Highest severity first (fatal → error → warning → information)
- Within severity, highest count first
- Within count, alphabetical for deterministic ordering
That ranking surfaces the "one fatal + forty errors of the same kind + ten warnings" as fatal-first without hiding the pattern.
For the alert-vs-log question at the individual-outcome level, when an OperationOutcome should be an alert vs a log is the entry.
Distinguish Structural From Business
Structural failures (structure, required, invalid, code-invalid) usually indicate a client-side shape problem — the payload is wrong. Business rule failures (business-rule, invariant) usually indicate a domain-rule problem — the payload is well-formed but not acceptable.
Route the two categories to different response surfaces: structural failures back to the client developers, business failures to the domain team. For the base pattern, reading an OperationOutcome for the first time is the entry.
Correlate With The Bundle Entries That Succeeded
Aggregation should also surface the ratio of failed to succeeded entries. Ten failures out of a hundred is a partial-success. Ten failures out of ten is a full failure. Presenting the ratio next to the fingerprints answers "did the operation mostly work?" at a glance.
The Transaction Case
Transaction Bundles either commit all entries or none. A failed transaction returns a single top-level OperationOutcome describing the reason the whole thing failed, plus optionally per-entry outcomes for context.
Aggregation is different for transactions — the single outer outcome dominates. But the per-entry outcomes still matter for diagnosing which entry caused the transaction to fail. Preserve both.
Present For The Consumer
- A developer wants to know what to fix next → surface fingerprints ranked by severity + count
- A support team wants to know what a customer hit → surface fingerprints with per-entry indexes
- An automated retry system wants to know which entries can be retried → surface a machine-readable per-entry map
Different consumers, different presentations, one aggregation upstream. For the support-facing side, OperationOutcome patterns that help your support team is the deep dive.
The Short Version
Group by fingerprint. Preserve per-entry context. Rank by severity and count. Separate structural from business. Show the success ratio. Present per consumer. Aggregation is what makes batch OperationOutcomes readable.
Sources
- HL7 canonical section on batch and transaction Bundle - HL7 canonical section on batch and transaction Bundle response semantics