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)
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|codeformat →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:ValueSet Expansion
Expand a ValueSet to get all its codes:Code Validation
Validate a code against a ValueSet: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:- Registers the operation in the operation registry
- Validates the operation context (system/type/instance)
- Enables parameter validation
- Makes the operation available at appropriate endpoints
Implementing Operations
Custom operation logic is implemented by extending theOperation trait:
Asynchronous Operations
Long-running operations use the job queue for asynchronous processing:- Request: Client submits operation request
- Acceptance: Server returns 202 Accepted with job ID
- Polling: Client polls job status using admin endpoints
- Completion: Job completes with success/failure status
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