FHIR Validation Passed. Is Your Dataset Ready?

Your team has a FHIR dataset to hand over. The validation run finishes with a Pass. Is it ready?

A validation pass is meaningful in the context of the checks that produced it. Before handing over a dataset, confirm that those checks cover the receiving team's requirements, then review the warnings and unresolved findings.

In a Records test on 6 October 2026, 31 synthetic MedicationAdministration resources received a FHIR Pass with zero errors and eight warnings. A separately selected rule for administration-route coding passed for 27 resources and returned four findings. The useful question is whether those findings breach an agreed exchange requirement and what action follows.

Start with the scope of the checks

Records reported no errors under the checks configured for this run. Eight warnings affecting three resources remained. All 31 selected resources were processed, and all 31 were evaluated by the additional rule.

The public evidence does not identify the validator package version or the exact profiles applied. It therefore cannot reproduce the FHIR verdict or fully explain why the configured checks and the selected route rule produced different results. The route rule's source and terminology versions are documented below.

FHIR validation can check terminology bindings and business rules as well as structure and profiles. Whether it already enforces a particular route requirement depends on the profiles, bindings and configuration in use. This example demonstrates the result of an additional selected requirement; that requirement could also be part of a FHIR validation setup. HL7's validation overview describes these overlapping checks.

Understand what the route rule asks

The selected rule checks whether the coding in MedicationAdministration.dosage.route satisfies membership in a fixed EDQM set of administration routes. An absent route can also pass, so this rule does not establish completeness. Some malformed coding inputs cannot be evaluated and must remain separate from passes and failures.

Here, all 31 resources were evaluable: 27 passed and four returned findings. A finding means that the selected membership requirement was not met. It does not by itself establish a clinically wrong administration route.

Before treating a finding as a source defect, confirm that your exchange actually requires this EDQM set. A route coded only in another system may describe an appropriate route while failing this particular requirement.

The function comes from a fixed revision of DQA-CQL, which describes its assessments as non-official and non-binding. For this test, it was evaluated against the published IPS 2.0.1 EDQM route ValueSet. That terminology selection belongs to this example; the upstream function does not choose this release or make it a requirement for every MII exchange.

Investigate the value before changing it

Consider an illustrative export error, separate from the recorded run. A route contains the code 20053000, but its coding.system is missing. The published IPS expansion lists this EDQM code as “Oral use”. If the source documentation confirms that EDQM is the intended code system, the team can correct the export mapping:

Route coding	Before	After the mapping correction
code	20053000	20053000
system	Missing	http://standardterms.edqm.eu

The selected rule can then recognise the system/code pair. The code's meaning must be confirmed before making that change: a matching code string alone is insufficient evidence of its origin. Passing the membership check still does not establish that the recorded route is clinically correct.

For each finding, inspect the actual code system and code alongside the agreed requirement and terminology version. Decide whether the source mapping needs correction or the selected requirement needs clarification.

In the recorded Records workflow, findings link to the current source with the recorded findings. That source may have changed since the run; it is not a historical snapshot. Compare its present value with the recorded context before deciding what to correct.

Test a change and check coverage

A separate browser exercise tested the same rule on three temporary synthetic resources. With all three evaluated, the result changed from 2/3 passed and one finding to 3/3 passed and zero findings.

The retained preview evidence contains counts and hashes, rather than the edited resource values. It demonstrates how the check responded to a test change; it does not document the illustrative mapping correction above or establish a clinically correct mapping. The four findings from the original run remained unchanged. A source correction needs its own comparable follow-up run.

Compare coverage before comparing results. In a second preview, one of three resources could not initially be evaluated, and only one of the other two passed. Afterwards, all three were evaluable and passed. Because the earlier result was incomplete, Records did not report a complete comparison of resolved and new findings. A higher pass rate alone cannot show what happened to previously unevaluated data.

About the example and its evidence

The downloadable evidence summary records local test run 3672 from 6 October 2026 and the separate temporary previews. The run used synthetic data; its source resources and saved baseline programs stayed unchanged.

The additional program was mii-dqa-cql-medication-administration-route-membership@0.1.0, selected for that run only. Its pinned IPS expansion contains 85 codes from the EDQM code-system version dated 5 February 2025. The check compares the exact system and code. The summary retains the source revision and terminology fingerprints, plus the additional diagnostic counts and the verification that findings linked to the expected resources.

This is an aggregate record, not a replayable dataset or the full run report. Its scope is one membership function and a local workflow exercise. It does not establish full MII-DQA/CQL coverage, MII certification, clinical suitability or public availability of every function exercised.

Make the handover decision explicit

Start with the intended use: which resources, identifiers and terminology does the receiving team need? Agree acceptance criteria, then choose the checks that address them.

Before handing over the dataset, record:

• Purpose and requirements: the intended use and agreed acceptance criteria.
• Check basis: the selected resources, validator, profiles, rules and terminology versions.
• Coverage and results: what was evaluated, what passed and what could not be evaluated.
• Open findings: remaining warnings and failures, their agreed disposition and the responsible person.
• Follow-up evidence: a comparable run for any claimed source correction, clearly distinguished from a temporary preview.

These details let the receiving team make and review a decision against its requirements. A Pass is one piece of that evidence.

The public Records demo offers a separate, small dataset-quality exercise. To evaluate your own permitted dataset, request workspace access with one quality question, the expected profile versions and a person responsible for acting on the result.