The same FHIR resource can produce a different terminology result when the evaluation basis changes. A ValueSet definition, CodeSystem version, expansion parameter or terminology service can affect the answer.
The investigation starts by identifying which input changed. A changed result alone does not show whether the source data needs correction.
Record the terminology requirement
FHIR elements can bind to ValueSets with different binding strengths. The applicable profile, binding strength and terminology context determine what a check requires. FHIR R4 terminology bindings.
Keep the canonical identifiers and available versions with the evaluation. If a service resolves an unversioned request against changing content, record that limitation. A later request to the same URL may not recover the same basis.
Four sources of changed results
Code status. A code may become inactive in a later release. The effect on a resource depends on the applicable version, historical-use rules and validation policy. Inactivity does not by itself establish that every historical use is invalid.
ValueSet content. An explicit code list can be revised. A rule-based expansion can change when the CodeSystem or expansion parameters change. Compare the actual versions and inputs used.
Version selection. A resource, profile and terminology service may name different versions or leave a version unspecified. Resolve that context before interpreting an apparent disagreement.
Validator or service behavior. A software update can fix a bug or change supported behavior. A timeout or missing dependency can also leave a check unverified. Keep these cases separate from a confirmed invalid code.
An illustrative investigation
Consider an invented example, not a measured customer incident. A team checks a selected delivery against a pinned profile and terminology basis. Later, a partner evaluates the same resource bytes under a newer terminology configuration and reports a binding failure.
The team first preserves both results and checks their contexts. It determines whether the requirement changed, whether one service lacked required content, or whether an implementation defect caused the disagreement.
Only then does it decide whether to update a source value, change an incorrectly selected terminology version, or correct the validation setup. Repeating the accepted check provides evidence for that decision. Choosing an older version solely to obtain a green result would not establish compliance with the receiving team's agreed requirement.
Configure a check that observes the relevant change
A pipeline that checks fixtures only on an application commit may miss a terminology change affecting another data selection. That is not an inherent limitation of CI: a scheduled job or dependency-triggered evaluation can examine the agreed scope and retain the result.
Use representative inputs and deliberate negative controls. Preserve completion, unresolved dependencies and coverage so an unavailable check cannot look like an improvement.
For a source-data comparison, keep the evaluation basis compatible. When testing a new terminology release, hold the selected data steady and explicitly compare the two contexts. That is a migration assessment; it should not be labelled a verified data correction.
Keep the result useful for the next person
Record the affected field, requirement, resource selection, terminology versions and the responsible owner. State the intended action and how its effect will be checked.
Records can retain available terminology context and compare compatible runs. Mutable or unavailable dependencies limit the conclusion. Recurring checks provide observations at their execution times; they do not establish the state of every resource between runs.
The three review questions help structure the handover. The quality-loop example shows how a source correction and comparable follow-up result can be inspected together.
