Fast Healthcare Interoperability Resources (FHIR)

FHIR decomposes all healthcare data into discrete, granular building blocks called Resources. Each resource (e.g., Patient, Observation, MedicationRequest) is a self-contained data unit with a known identity, a defined structure, and explicit metadata. This atomicity allows federated learning nodes to query and extract precisely the data elements needed for model training—such as all Observation resources with a specific LOINC code—without transferring entire, bloated clinical documents. Resources are the canonical data representation, eliminating ambiguity across disparate electronic health record systems.

The base FHIR specification is intentionally generic. Profiling is the mechanism by which specific communities—such as oncology or cardiology—constrain and extend base resources to meet their precise needs. An Implementation Guide (IG) is a published collection of these profiles, value sets, and rules. For federated learning, this is critical: the US Core IG defines the minimum data elements a US-based server must support, ensuring that a model trained on patient demographics from one hospital can be reliably applied to data from another. Profiles guarantee semantic and structural consistency across the decentralized network.

FHIRPath is a path-based navigation language, analogous to XPath for XML, designed specifically for traversing and extracting data from FHIR resource graphs. It enables precise, programmatic access to deeply nested clinical data without custom parsing logic. For example, the expression Observation.value.ofType(Quantity).value reliably extracts a numeric result regardless of the surrounding structure. In a federated learning context, FHIRPath expressions can be distributed to edge nodes as the canonical definition of a feature extraction pipeline, ensuring every site computes the same input features from their local data in a verifiable, deterministic way.

A container resource used to group a collection of other resources into a single unit for transmission. Bundles support multiple interaction types:

• searchset: Results from a search query
• transaction: A set of operations processed atomically
• batch: Independent operations processed sequentially
• document: A signed, persistent clinical document Bundles are fundamental to FHIR's RESTful API, enabling efficient bulk data exchange and transactional integrity across distributed systems.

A mechanism allowing implementers to add custom data elements to standard resource definitions without breaking conformance to the base specification. Every extension must have a canonical URL that uniquely identifies its definition. Extensions can be:

• Simple: Adding a single attribute like a patient's preferred language
• Complex: Nested structures with multiple sub-extensions This extensibility is critical for accommodating local requirements while maintaining interoperability across diverse healthcare ecosystems.

Metadata tags applied to FHIR resources to indicate their sensitivity, confidentiality, and handling instructions. These labels enable automated access control decisions based on patient consent and regulatory requirements. Key use cases include:

• Marking resources as subject to 42 CFR Part 2 (substance abuse treatment)
• Indicating HIV/AIDS-related information sensitivity
• Applying organizational privacy policies Security labels integrate with the Consent Resource to enforce patient-directed privacy preferences at the API level.

A mechanism allowing a client to register interest in specific events or data changes on a server and receive real-time notifications. The subscription framework supports multiple channel types:

• rest-hook: Server sends a POST request to a client endpoint
• websocket: Persistent connection for streaming updates
• email: Notifications delivered via SMTP This event-driven architecture enables real-time clinical decision support, patient monitoring, and data synchronization across federated learning networks.

A specification defining an asynchronous API for exporting large, flat datasets of patient-level data from a server. Designed for population-level analytics and machine learning, it uses:

• Kick-off requests to initiate exports
• Polling endpoints to check job status
• NDJSON format for efficient data streaming This is the primary mechanism for extracting training datasets for federated learning models without overwhelming transactional FHIR endpoints.