Secondary Use FHIR Server Implementation Guide
0.1.0 - ci-build
Publish Box goes here
This page is non-normative. It explains how the current service implements the public behavior described in this guide.
The application starts two Ktor/Netty servers:
MockFhirServerBulkAdapterServerBoth use Jackson for HTTP JSON handling. FHIR resource parsing and serialization are handled through HAPI FHIR R4.
The mock server:
DatasetStore/fhir/{resourceType}/{id}/fhir/{resourceType}/fhir/$export/fhir/bulk-status/{jobId} and /fhir/bulk-files/{jobId}/{file}DELETE /fhir/bulk-status/{jobId}Search matching is implemented in code against the generated in-memory resources.
The adapter:
BulkCriteriamode values_summary=count is presentFhirSearchBackendPrivacyTransformernotification-url is presentThis keeps the front API Bulk-shaped even when the backend only supports ordinary FHIR searches.
FhirSearchBackend owns the translation from front cohort criteria to backend FHIR searches.
It deliberately fans out multi-code filters into one search per code and merges results. This avoids relying on repeated-parameter semantics in a simple backend.
When several filter families are present, patient sets are intersected. That means a broad code family can be combined with a demographic or date filter without changing the output API.
BulkStore groups resources by resourceType, assigns a random job ID, and can write job payloads to disk.
The status response contains one output entry per resource type with a download URL and stable bulk:// storage location. NDJSON output is generated by serializing each stored resource on its own line.
Named dataset runs persist mock and adapter Bulk jobs below:
<data-dir>/bulk-jobs/
The jobs still complete synchronously. Persistence and delete support exist for local repeatability, restart inspection, and cleanup, not production scheduling.
PrivacyTransformer works on typed HAPI R4 resources.
The pseudonymized mode:
Patient resourcesThe minimized mode:
When runtime behavior changes, update these pages together: