FHIR Server

Exposes a standards-compliant RESTful interface where each FHIR Resource is an addressable URL endpoint. The server must support standard HTTP verbs: POST for creation, GET for reading and searching, PUT for updates, and DELETE for removal. This uniform interface is the foundation of plug-and-play interoperability, allowing any authorized client to interact with clinical data without custom connectors.

• Supports conditional creates and updates to prevent duplicates
• Returns appropriate HTTP status codes (201, 200, 404, 422)
• Enables versioned reads via _history endpoint

Implements the FHIR Search specification, allowing clients to locate resources based on defined Search Parameters. The server must parse complex query expressions, handle chained parameters (e.g., Patient?organization.name=Acme), and support composite search criteria. Efficient indexing of clinical data is critical for sub-second response times.

• Supports _include and _revinclude to fetch related resources in a single query
• Implements pagination via _count and bundle links
• Handles token, date, quantity, and reference parameter types

Validates incoming resources against the base FHIR specification, specific Implementation Guides (like US Core), and server-defined Profiles. This engine checks cardinality, data type constraints, terminology bindings to ValueSets, and custom invariants. Rejecting non-conformant data at the API boundary ensures data integrity across the ecosystem.

• Generates detailed OperationOutcome resources on failure
• Validates terminology codes against bound ValueSets
• Enforces profile-specific slicing and extension requirements

Hosts or connects to an internal terminology server to manage CodeSystems and ValueSets. This service performs code validation ($validate-code), concept lookup ($lookup), and subsumption testing. It ensures that clinical codes like SNOMED CT or LOINC are used correctly, enabling semantic interoperability beyond simple data transport.

• Translates between code systems using ConceptMap resources
• Expands ValueSets to generate lists of permissible codes
• Supports batch validation for high-throughput ingestion pipelines

Processes FHIR Bundles of type transaction or batch to handle multiple operations in a single HTTP request. A transaction bundle ensures atomicity: all interactions succeed or fail as a single unit, maintaining referential integrity. This is essential for submitting a complete clinical document with all its supporting references.

• Resolves temporary internal references within a bundle
• Returns a response bundle detailing the outcome of each entry
• Supports batch operations for high-volume, non-atomic processing

Implements the FHIR Subscription framework to push real-time notifications to clients when data changes. The server monitors for events matching a defined topic (e.g., a new Observation for a specific patient) and delivers notifications via channels like REST hooks, websockets, or email. This enables reactive, event-driven architectures.

• Supports topic-based subscriptions for workflow triggers
• Manages subscription lifecycle: creation, status tracking, and expiration
• Delivers payloads containing the changed resource or just an identifier

The fundamental atomic unit of data stored and managed by a FHIR server. Each resource represents a discrete clinical or administrative concept—such as a Patient, Observation, or MedicationRequest—with a defined structure, mandatory elements, and optional extensions. A FHIR server exposes these resources as RESTful endpoints, allowing clients to perform CRUD operations. The server is responsible for ensuring that every stored resource conforms to its base definition and any applied profiles.

A container resource used by a FHIR server to group multiple resources into a single unit for transmission or persistence. Key bundle types include:

• searchset: Results returned from a search operation
• transaction: A set of operations processed atomically—all succeed or all fail
• batch: Independent operations processed sequentially
• document: A signed, persistent clinical document Servers must parse, validate, and process bundles according to their declared type, ensuring transactional integrity where required.

A software tool that verifies whether resources and profiles conform to the FHIR specification's rules, constraints, and terminology bindings. A production-grade FHIR server typically integrates a validator to reject non-conformant data at ingestion. Validation checks include:

• Structure: Required elements present, correct data types
• Cardinality: Element counts within allowed ranges
• Terminology: Codes present in the bound ValueSet
• Invariants: Custom constraints expressed in FHIRPath
• Profiles: Compliance with all applicable profile constraints

A mechanism that allows a client to register interest in specific events on a FHIR server and receive real-time notifications when matching data changes. The server monitors create, update, and delete operations against a defined FHIR Search Parameter query. When a new or updated resource matches the criteria, the server pushes a notification to the subscriber's endpoint. This enables event-driven architectures for clinical decision support, alerting, and data synchronization across systems.

A specification for exporting large, flat datasets of patient-level data asynchronously from a FHIR server. Unlike real-time RESTful queries, bulk data access initiates a long-running export job that generates NDJSON files. This is essential for population health analytics, machine learning training pipelines, and data warehousing. The server must support:

• Group-level export: All data for a defined cohort
• System-level export: All data across the entire server
• Patient-level export: All data for a single patient

A dedicated API specification within a FHIR server for interacting with coded terminologies. It enables operations such as:

• $validate-code: Check if a code exists in a ValueSet
• $lookup: Retrieve display name and properties for a code
• $subsumes: Test hierarchical relationships between concepts
• $translate: Convert codes between different CodeSystems A robust FHIR server uses this service to enforce Terminology Binding constraints, ensuring that clinical data uses valid codes from systems like SNOMED CT, LOINC, and RxNorm.