FHIR Validation Doesn't Tell You What to Do Next, So I Built a Decision Layer

A FHIR resource can pass validation yet still be inappropriate for action. A small decision layer has been developed to address this gap. It processes parsed FHIR R4 resources, sends a flattened state to TypeSafe AI's Jev model, and generates responses indicating acceptance, routing, flagging, or requiring human review. On 204 synthetic records, the initial run classified routing incorrectly, achieving 0.814 to 0.922 accuracy, and missed several notifiable diseases.

Both issues stemmed from the developer's own setup, including a serializer bug and a poorly formulated routing query. Following corrections, Jev surpassed the rules in all three decisions on the same records. However, it still fails to meet the latency target. This serves as a proof of concept, running on synthetic data and disconnected from any production system.

Validation alone does not answer what to do with a resource. A patient resource, when parsed as FHIR R4, might have structural problems, such as a 15-digit NIK (Indonesian national ID) instead of the required 16 digits or a Condition coded as dengue with verificationStatus set to refuted. Conformance checking confirms whether a resource meets the specification, while a pipeline must determine the appropriate action to take.

The decision layer answers this question: what should happen to this resource now? Output can be a pass or fail, accompanied by issues, an action, and a confidence level. Defined by the specification and profiles, the workflow and risk tolerance are considered. In cases of uncertainty, the decision falls to a human. FHIRPath invariants can enforce rules like a 16-digit NIK, eliminating the need for a model in such scenarios.

The pipeline utilizes Jev, a decision model that accepts a structured state and a fixed question, returning a typed answer with confidence. It doesn't generate text. The project employs three primitives: Choice (selects an option from a list), Score (returns a number on a scale), and Noul (answers a statement with a probability of being true).

The service is built using FastAPI with Pydantic v2 and provides three decisions: whether the resource is suitable for automatic acceptance, which pipeline should handle the Bundle, and whether a Condition must be reported. Conformance runs first, followed by state reduction. Each serializer parses the resource before extraction, and a failed parsing raises an error, preventing any Jev calls.

This approach is lighter than full profile and terminology validation but maintains a design order: conformance first, decisions thereafter.