FHIR R4 · Documentation

Build your bridge to FHIR.

Deploy the verification-first foundation, validate FHIR R4 resources, and understand what FHIR at Will implements today.

Current release: M0–M1. Validation is implemented. Narrative ingestion and AI generation are intentionally planned, not presented as production capabilities.

Project status

FHIR at Will is the project; fhirbridge is its Python package and HTTP service. The current platform provides an authenticated FHIR R4 validation service and the infrastructure required to operate it safely.

Available today

  • FHIR R4 resource and Bundle validation
  • Profile checks against preloaded implementation guides
  • Terminology validation and ConceptMap translation
  • FHIRPath invariants and configurable plausibility rules
  • FHIR OperationOutcome and native JSON reports
  • API-key authentication, tenant isolation, metrics, and tracing hooks

Planned

  • Narrative and document ingestion
  • BYOK/BYOM provider routing and LLM calls
  • Clinical extraction, assembly, repair, fidelity, and coverage scoring
  • Human review queues and delivery workflows

Quickstart with Docker

You need Docker with Compose v2, at least 4 GB of available memory, and network access during the validator image build.

1. Configure the stack

Clone the main project, then create your environment file.

git clone https://github.com/Safwanmahmoud/FHIR-It-Will.git
cd FHIR-It-Will
cp .env.example .env

On Windows PowerShell, use Copy-Item .env.example .env. Set distinct owner and application database passwords:

POSTGRES_PASSWORD=choose-an-owner-password
APP_DB_PASSWORD=choose-a-different-app-password

2. Bootstrap and start

docker compose --profile setup run --rm bootstrap
docker compose up -d
docker compose ps
Save the API key. Bootstrap prints it once. Only its Argon2id hash is stored, so a lost key cannot be recovered.

3. Confirm readiness

curl http://localhost:8000/livez
curl http://localhost:8000/readyz
curl http://localhost:8000/version

The API runs at http://localhost:8000. Interactive OpenAPI documentation is available at /docs.

Validate a resource

Every compute endpoint requires a Bearer API key. A non-conformant resource returns a successful validation report; it is not treated as an HTTP transport error.

curl -X POST http://localhost:8000/v1/validate \
  -H "Authorization: Bearer fhirb_..." \
  -H "Content-Type: application/json" \
  -d '{
    "resource": {
      "resourceType": "Patient",
      "id": "example",
      "name": [{"family": "Shaw", "given": ["Amy"]}],
      "gender": "female"
    }
  }'

Requests may select profiles, validation layers, severity overrides, and terminology-check limits. A bare resource is also accepted with Content-Type: application/fhir+json.

API reference

Health and discovery

GET/livezProcess liveness
GET/readyzDependency and row-level-security readiness
GET/versionCode, FHIR, IG, and validator version pins
GET/v1/capabilitiesImplemented and planned platform capabilities
GET/fhir/R4/metadataFHIR CapabilityStatement

Validation and terminology

POST/v1/validateDetailed native validation report
POST/v1/validate/outcomeValidation as a FHIR OperationOutcome
POST/fhir/R4/$validateFHIR-native validation operation
POST/v1/terminology/validate-codeCode and ValueSet validation
POST/v1/terminology/mapConceptMap $translate passthrough
Translation routes for HL7 v2, C-CDA, tabular data, and narrative conversion currently return 501 with guidance. They do not pretend to work.

The validation cascade

Every report includes all eight layers. A layer that did not run is explicitly marked skipped or not_applicable; absence never looks like a pass.

LayerQuestionStatus
L1 · StructuralIs this a parseable, allowed FHIR R4 resource?Implemented
L2 · ProfileDoes it conform to declared or requested profiles?Implemented
L3 · TerminologyAre codes valid and in their bound ValueSets?Implemented
L4 · InvariantsDo applicable FHIRPath invariants hold?Implemented
L5 · PlausibilityIs the value physiologically or temporally possible?Implemented
L6 · FidelityIs each generated element supported by source spans?M3
L7 · CoverageWhich clinical mentions were omitted?M3
L8 · RoutingCan this auto-accept or does it require review?Validation mode
Conformant does not mean correct. A heart rate of 44,000/min can be valid FHIR and still be impossible. Plausibility checks address that gap without flagging values merely because they are clinically abnormal.

Architecture

Clients authenticate to a FastAPI service. The service orchestrates typed FHIR models, the private HL7 validator sidecar, a terminology service, versioned plausibility rules, routing decisions, and tenant-aware PostgreSQL storage.

  • The API uses a least-privileged database role subject to row-level security.
  • The validator remains private because it has no authentication and can fetch referenced resources.
  • Readiness fails closed when a required verification dependency is unavailable.
  • JSON logs, Prometheus metrics, and OpenTelemetry hooks support operations.

Configuration

VariablePurpose
DATABASE_URLLeast-privileged PostgreSQL connection
REDIS_URLRedis connection for future jobs
VALIDATOR_URLPrivate validator sidecar URL
TERMINOLOGY_URLFHIR terminology server
DEFAULT_IG_PACKAGESIG coordinates stamped into reports
FHIRBRIDGE_ENVDevelopment, staging, or production mode
REQUIRE_RLS_ENFORCEMENTRefuse readiness if tenant isolation does not apply

Production mode rejects insecure transport and unsafe dependency defaults. For the complete settings reference, see .env.example in the main repository.

Security and privacy

  • API keys are stored as Argon2id hashes.
  • Tenant-scoped tables enforce PostgreSQL row-level security.
  • Submitted validation resources are scored and dropped rather than persisted.
  • Validation responses use Cache-Control: no-store.
  • Logs record decisions and counts, not resource bodies or clinical values.
  • Secrets and known sensitive fields pass through centralized redaction.
Self-hosting is not compliance by itself. Operators remain responsible for access controls, encryption, backups, retention, licensing, agreements, incident response, and the infrastructure handling PHI.

Roadmap

MilestoneGoalStatus
M0Config, storage, auth, errors, OpenAPI, health, containersImplemented
M1Validation cascade, terminology, and plausibilityImplemented
M2BYOK/BYOM provider gateway and qualification probesPlanned
M3Narrative ingestion, generation, fidelity, and coveragePlanned
M4Human review workflowsPlanned
M5–M6Calibrated routing, integrations, and hardeningPlanned

Development

Python 3.12 and uv are the supported development path.

uv sync
uv run pytest -q -m "not integration"
uv run ruff check .
uv run ruff format --check .
uv run mypy

Integration tests require real PostgreSQL, Redis, validator, and terminology dependencies:

uv run pytest -m integration

See the main repository for contributing rules, full API examples, and source layout.