Skip to main content

Implementation Features

Package Sources

Ferrum supports packages from two sources:

1. Registry Packages

Packages from the official FHIR registry (registry.fhir.org):
  • Core FHIR packages: hl7.fhir.r4.core, hl7.fhir.r4b.core, etc.
  • Extension packages: hl7.fhir.r4.extensions
  • Terminology packages: hl7.fhir.r4.terminology
  • Implementation Guides: hl7.fhir.us.core, hl7.fhir.uv.ips, etc.

2. Internal Packages

Packages bundled with the server (from fhir_packages/ directory):
  • Server-specific OperationDefinitions
  • Custom conformance resources
  • Pre-configured profiles and extensions

Package Installation

Installation Methods

Packages can be installed via:
  1. Admin API (recommended for runtime installation)
  2. $install-package Operation (FHIR-compliant)
  3. Startup Configuration (automatic on server start)

Admin API Installation

Install packages using the admin API:
Response:

Operation-Based Installation

Install packages using the FHIR $install-package operation:

Installation Options

Resource Type Filtering

Control which resources are installed:

Package Management

List Installed Packages

List all installed packages:
Response:

Get Package Details

Get detailed information about a specific package:
Response:

List Package Resources

List all resources installed from a package:
Response:

Configuration

Startup Package Installation

Configure packages to install automatically at server startup:

Package Categories

Default packages are categorized:
  • Core: Base FHIR specification (StructureDefinitions, etc.)
  • Extensions: FHIR extensions
  • Terminology: CodeSystems and ValueSets
  • Custom: User-configured packages

Installation Process

Installation Flow

  1. Package Discovery: Load package manifest from registry or filesystem
  2. Dependency Resolution: Recursively load dependent packages
  3. Resource Collection: Gather conformance resources (and optionally examples)
  4. Filtering: Apply resource type filters
  5. Batch Processing: Install resources using FHIR batch operations
  6. Indexing: Index SearchParameters and other indexed resources
  7. Completion: Update package status and resource counts

Installation Status

Packages have the following statuses:
  • loading: Installation in progress
  • loaded: Successfully installed
  • failed: Installation failed (check errorMessage)

Duplicate Detection

Ferrum automatically detects if a package is already installed:
  • Same name and version → Returns existing package ID
  • Different version → Installs as new package
  • Partial installation → Continues from where it left off

Asynchronous Installation

Package installation runs asynchronously via the job queue:

Job Status

Package installation jobs provide progress updates:

Package Resources

Conformance Resources

Packages typically contain:
  • StructureDefinition: Resource and data type definitions
  • ValueSet: Code value sets
  • CodeSystem: Code systems
  • SearchParameter: Search parameter definitions
  • OperationDefinition: Operation definitions
  • CapabilityStatement: Server capabilities
  • CompartmentDefinition: Compartment definitions
  • ImplementationGuide: Implementation guide metadata

Resource Installation

Resources are installed using FHIR batch operations:
  • PUT semantics: Resources preserve their IDs
  • Version handling: Resources are versioned per FHIR spec
  • Indexing: SearchParameters are automatically indexed
  • Hooks: Resource hooks process installed resources (e.g., CompartmentDefinition)

Internal Packages

Server-Provided Packages

Ferrum can include internal packages:
  • Location: fhir_packages/ directory (configurable)
  • Format: Standard FHIR package structure
  • Purpose: Server-specific OperationDefinitions, custom profiles
Example structure:

Internal Package Installation

Internal packages are installed automatically at startup (if enabled):

Best Practices

Package Selection

  • Start with core: Always install core FHIR package first
  • Add incrementally: Install packages as needed
  • Version pinning: Pin specific versions for reproducibility
  • Filter resources: Exclude unnecessary resource types to reduce storage

Performance

  • Async installation: Use async installation for large packages
  • Resource filtering: Filter to only needed resource types
  • Skip examples: Don’t install examples unless needed for testing
  • Dependency management: Let server handle dependencies automatically

Maintenance

  • Monitor status: Check package installation status regularly
  • Review resources: List package resources to verify installation
  • Error handling: Check errorMessage for failed installations
  • Cleanup: Remove unused packages if needed

Error Handling

Common Errors

Installation Failures

Failed installations include error details:

Limitations

  • No Package Removal: Currently no API to remove installed packages
  • Version Conflicts: Multiple versions of same package can coexist
  • Resource Updates: Updating resources requires re-installing package
  • Registry Dependency: Requires internet access for registry packages