Skip to main content

Implementation Features

Endpoints

Ferrum supports operations at three different levels: Examples:
The $ character in URLs must be escaped as \$ in bash/curl commands.

Built-in Operations

Ferrum includes several built-in operations:

Package Management Operations

Terminology Operations

Administrative Operations

Operation Invocation

GET vs POST

Operations can be invoked using either GET or POST:
  • GET: Parameters passed as query string, automatically converted to Parameters resource
  • POST: Parameters resource in request body (JSON or XML)
GET example:
POST example:

Parameter Conversion

For GET requests, Ferrum automatically converts query parameters to the appropriate FHIR data types:
  • Boolean: true/false (case-insensitive) → valueBoolean
  • Integer: Numeric strings → valueInteger
  • Coding: system|code format → valueCoding
  • String: Everything else → valueString

Parameter Validation

Ferrum validates operation parameters against OperationDefinition resources:
  • Required parameters must be present
  • Parameter types must match the definition
  • Cardinality constraints are enforced
  • Unknown parameters are rejected

Operation Examples

Package Installation

Install a FHIR package from the registry:
Response:

ValueSet Expansion

Expand a ValueSet to get all its codes:

Code Validation

Validate a code against a ValueSet:
Response:

Search Index Rebuild

Rebuild search parameter indexes:

Custom Operations

Defining Operations

Custom operations are defined using OperationDefinition resources. When you create an OperationDefinition, Ferrum automatically:
  1. Registers the operation in the operation registry
  2. Validates the operation context (system/type/instance)
  3. Enables parameter validation
  4. Makes the operation available at appropriate endpoints
Example OperationDefinition:

Implementing Operations

Custom operation logic is implemented by extending the Operation trait:

Asynchronous Operations

Long-running operations use the job queue for asynchronous processing:
  1. Request: Client submits operation request
  2. Acceptance: Server returns 202 Accepted with job ID
  3. Polling: Client polls job status using admin endpoints
  4. Completion: Job completes with success/failure status
Example async operation flow:

Configuration

Operations can be disabled in the server configuration:

Error Handling

Operation errors follow FHIR OperationOutcome patterns:

Performance Considerations

  • Parameter Validation: Cached OperationDefinition metadata for fast validation
  • Content Negotiation: Efficient format conversion using shared formatters
  • Async Processing: Long operations don’t block HTTP threads
  • Resource Cleanup: Automatic cleanup of temporary resources

Limitations

  • Custom Operation Implementation: Requires Rust code changes (no plugin system)
  • Complex Parameters: Nested parameter structures have limited support
  • Batch Operations: Operations cannot be included in batch/transaction bundles