A data supplier delivers a FHIR dataset and a green quality report. Your team needs to decide whether to accept the data for reporting, research or another exchange. Start with the receiving requirements: what was the supplier expected to deliver, and what does the report actually show?
A supplier can run quality checks. The receiving team needs control over the acceptance criteria and access to the evidence behind the result. That responsibility matters whether the checks run inside the FHIR server, in a separate service or in the recipient's own tooling.
A 100 percent result can leave a delivery incomplete
Consider a hypothetical monthly exchange: three agreed laboratory sources, each expected to supply 100 Observation resources. Two sources arrive, producing 200 resources. Every received resource contains the required code.
| Check | Result |
|---|---|
| Required code (200 received resources) | 200/200 · 100% |
| Source deliveries (three expected) | 2/3 |
The code-presence result (200/200) is correct for the 200 received resources. The delivery still fails the agreed source-coverage requirement. A report that shows both results makes the next action clear: investigate the missing source before accepting the delivery.
These numbers illustrate a defined scope; they are not a measured validation result. In practice, expected volumes may vary. Agree the sources, time windows and tolerances for the actual exchange.
Finding the absent source requires the agreed source inventory. Another validator examining the same received resources cannot supply that missing expectation on its own.
An acceptance report should distinguish the expected delivery, the received data and the evaluated data. Put excluded and not-evaluable cases beside the score. A result means more when the reader can see which question it answers and which data it covers.
Running the checks and accepting the data are separate responsibilities
Digital quality measures calculate indicators of care quality. Data-quality checks examine their inputs, including completeness, plausibility and conformance. The calculation and the input data each need their own checks.
NCQA's Data Quality Solutions distinguish rule implementation from data validation. Vendors can embed HEDIS Data Quality Specifications; prevalidation assesses that implementation, rather than an organization's data or results. These solutions complement existing audit and data-aggregation validation programs.
For a receiving team, the practical question is whether its particular delivery meets the agreed requirements. The allocation of responsibilities below is an operational recommendation; it does not describe a NCQA requirement to buy a separate validation product.
Independence starts with control over the criteria
A supplier knows its platform and can investigate findings close to their source. Agree the acceptance basis with that supplier before delivery: expected sources, periods, data selection, profile and terminology versions, quality rules and thresholds.
The supplier can execute the checks. The receiving team needs to inspect the rules, exclusions and findings, and request a re-check. Its decision owner agrees which remaining deviations are acceptable for the intended use, including applicable reporting or audit obligations.
Record approval for changes to scope, thresholds or the treatment of findings. Otherwise, the score can stay green while the meaning of the result changes.
Independent review depends on controlled criteria and inspectable execution. Checks inside a server can support that review. A separate tool can add another implementation or reviewer, but it must expose its own scope and limits. The consequences of the decision determine whether additional execution or source verification is needed.
Five questions to ask before signing off
Use these questions in the next delivery review or supplier discussion:
- What did we expect, and what arrived? Reconcile agreed sources, periods and populations. Record any sampling or access restrictions.
- What exactly produced this score? Name the rules, versions and thresholds. Show how many resources passed, how many were evaluated, and what was excluded or not evaluable.
- Can we investigate the findings? Retain appropriate links to affected resources and fields, rule context and the responsible team. A summary percentage should lead to an explanation.
- What would demonstrate a correction? Agree a completed follow-up under a comparable basis. A smaller selection or disabled check must not be presented as a corrected source.
- Who can accept the remaining deviations? Name the receiving decision owner and retain the justification. A tool's pass signal cannot settle every question about intended use.
These questions apply across platforms. Supplier comparison also needs compatible data scope and evaluation conditions; using the same rule names alone does not make two scores comparable.
What Records can contribute to the review
Records supports validation and data-quality evaluation of selected FHIR resources. Its evaluations use versioned indicators and show the defined scope, rules, thresholds, evaluated population and not-evaluable cases. Findings and recorded run context help a team investigate the result and review a comparable follow-up.
Your team supplies the expected source inventory and receiving requirements, and retains the acceptance decision. A repeated check needs the corresponding data and outcome-relevant dependencies. The report documents the selected checks and their limits; clinical correctness requires its own evidence.
The three questions every FHIR team should answer offer a related framework. After a mapping or profile change, a comparable check in operation helps establish what the new delivery shows.
For the next exchange, start with one receiving requirement and decide what evidence would satisfy it. Ask the supplier to show how its result connects to that requirement, including what remains unknown. The useful outcome is an acceptance decision your team can explain and revisit after a change.
