FHIR Bundle

A FHIR Bundle's behavior is defined by its type element, which dictates how the server must process the collection. Searchset bundles return paginated query results with link elements for navigation. Transaction bundles enforce atomicity—all entries succeed or fail as a unit, using conditional ifNoneExist logic to prevent duplicates. Batch bundles process entries independently, allowing partial success. Document bundles package a clinical document (e.g., a discharge summary) with a required Composition resource as the first entry, signed for integrity. Message bundles support event-driven messaging with a MessageHeader resource directing routing. Each type carries distinct processing semantics critical for federated learning pipelines where atomicity of model updates or patient data submissions must be guaranteed.

The Provenance resource establishes a chain of custody for data within a Bundle, tracking origin, authorship, and transformation history. In federated learning contexts, provenance is critical for auditing which institution contributed specific training data or model weights. Key elements include:

• target: The resource(s) this provenance record describes
• agent: Who or what was involved (practitioner, device, algorithm)
• activity: The action performed (create, update, transform)
• entity: Input or output data used in the process Provenance records embedded in Bundles enable verifiable audit trails across decentralized networks, supporting regulatory compliance and model lineage tracking.

The Bulk Data Access specification defines an asynchronous API for exporting large, flat datasets as ndjson Bundles. Unlike synchronous searchset Bundles, bulk exports are designed for population-level analytics and machine learning training data preparation. The workflow:

• Client initiates an export via the $export operation
• Server returns a polling URL for status checks
• Upon completion, a Bundle of type file is returned containing download URLs
• Each URL points to an ndjson file of homogeneous resources This mechanism is essential for federated learning architectures where local nodes must extract large, standardized datasets for local model training without overwhelming synchronous APIs.

The Subscription resource enables real-time event-driven architectures by allowing clients to register interest in specific data changes. When a matching event occurs, the server delivers a notification Bundle to the designated endpoint. Subscription types include:

• rest-hook: Server POSTs a Bundle to a client URL
• websocket: Persistent connection for low-latency delivery
• email/sms: Simple notification channels In federated learning, Subscriptions can trigger model retraining workflows when new clinical data meeting specific criteria (e.g., new oncology cases matching mCODE profiles) becomes available, enabling continuous learning pipelines without polling.

A StructureDefinition resource defines constraints on how base FHIR resources are used within a specific context, forming the basis for Bundle validation. The FHIR Validator tool checks Bundles against these profiles, ensuring:

• Required elements are present
• Cardinality constraints are satisfied
• Value set bindings are respected
• Invariants (co-occurrence rules) are enforced For federated learning, strict validation ensures that data Bundles exchanged between institutions conform to agreed-upon profiles (e.g., US Core), preventing schema drift and ensuring model compatibility across heterogeneous EHR systems.

Each entry in a Bundle contains a request or response element governing HTTP-level semantics. The request.method determines the operation (POST for create, PUT for update, DELETE for remove), while request.url specifies the target endpoint. Conditional references using ifMatch and ifNoneMatch headers enable optimistic concurrency control. The fullUrl element provides an absolute identity for internal cross-referencing via Bundle.link resolution. Understanding these mechanics is essential for constructing valid transaction Bundles in federated systems where multiple institutions submit model updates or patient data simultaneously, requiring idempotent processing and conflict resolution.