Semantic Validation
Validate clinical and workflow context after FHIR generation and before downstream delivery.
A FHIR Bundle can be structurally valid and accepted by the target server while still carrying the wrong patient, encounter, timing, or workflow context. FireSonic semantic validation is designed to detect these operational inconsistencies before the Bundle is delivered.
Why semantic validation matters
Reliable HL7 v2 → FHIR transformation is necessary, but successful transport and valid FHIR syntax do not guarantee that the resulting data is operationally correct. A message may be transformed successfully while being associated with incomplete, stale, or incompatible clinical context.
These are not transport failures. They are clinical-context integrity problems that must be evaluated using information from the generated Bundle and, when required, organization-specific workflow knowledge.
Clinical context integrity
Semantic validation can enforce context-aware checks that go beyond structural FHIR validation. Typical checks include:
- verify that an Observation references the expected patient and active Encounter context;
- detect delayed or late-arriving results associated with stale or closed Encounters;
- detect Appointments or workflow resources created for patients in an incompatible clinical state;
- require the Encounter, treatment context, supporting evidence, or other workflow information required before delivery;
- enforce organization-specific data-quality and workflow policies.
FireSonic combines deterministic core mapping, Groovy-based workflow customization, and semantic validation rules so these checks can run inside the integration layer before data is committed to downstream FHIR systems.
Where validation runs
after mapping and postConvert() · before FHIR deliveryRule scope
Semantic rules are defined using the FireSonic Groovy DSL. Rules may be global or scoped to specific HL7 message families and trigger events, allowing validation to follow the workflow that produced the Bundle.
Typical rules can validate patient and Encounter relationships, timing and lifecycle consistency, required supporting context, or organization-specific policy before delivery.
Severity model
| Severity | Behavior |
|---|---|
| INFO | Processing continues and the Bundle can be delivered. The issue remains available for operational visibility. |
| WARNING | Processing continues and the Bundle can be delivered. The issue indicates a condition that should be reviewed. |
| ERROR | Delivery is blocked and the message moves to REJECTED. |
Validation lifecycle
evaluate clinical context before deliveryAutomatic rule hot reload Commercial
Commercial editions can detect semantic-rule changes, compile and validate a new rule generation, and activate it without restarting the FireSonic runtime. A failed reload does not replace the currently active rule generation.
For rule syntax, rule scope, examples, and SDK development guidance, see Developer SDK: Semantic Rules.