Expand description
FHIR Validator - Three-phase, pipeline-based validation architecture
§Architecture
The validator separates configuration, planning, and execution:
ValidatorConfig (declarative) → ValidationPlan (executable) → Validator (reusable)§Phase 1: Declarative Configuration
Define validation behavior via ValidatorConfig:
- What aspects to validate (schema, profiles, invariants, terminology, etc.)
- Strictness levels and policies
- Preset-based or fully custom
- Serializable (YAML/JSON)
§Phase 2: Compiled Validation Plan
Configuration compiles into a ValidationPlan:
- Ordered list of stateless validation steps
- Validates configuration correctness
- Eliminates unused features
- Minimal, executable pipeline
§Phase 3: Reusable Validator & Stateless Execution
Validator<C> owns the plan and FHIR context:
- Generic over context type (e.g.,
DefaultFhirContext) - Reusable across many validations
- Each
validate()call creates a short-livedValidationRun - Returns structured
ValidationOutcome
§Key Properties
- No combinatorial explosion: Capabilities selected via configuration, not chained APIs
- FHIR-context driven: All profile/terminology resolution delegated to
fhir-context - Extensible: New validation steps added without breaking public API
- Reusable & performant: Heavy initialization once, cheap execution
Structs§
- Bundle
Config - Bundle
Plan - Constraint
Id - Constraint
Level Override - Constraints
Config - Constraints
Plan - Exec
Config - Fhir
Config - Profiles
Config - Profiles
Plan - References
Config - References
Plan - Report
Config - Schema
Config - Schema
Plan - Terminology
Config - Terminology
Plan - Validation
Issue - Individual validation issue
- Validation
Outcome - Validation result for a single resource
- Validation
Plan - Compiled validation plan - list of steps to execute
- Validator
- Reusable validator - owns plan, context, and FHIRPath engine
- Validator
Config - Validator
Config Builder