A passing FHIR check is useful only in relation to the data and requirements it examined. A pipeline that validates a small fixture set can catch regressions in those examples. It cannot establish the state of resources it never reads.
That boundary is a configuration question. CI platforms can also run scheduled jobs, examine an approved data scope and retain detailed reports. The useful distinction is between checking a controlled example and operating a repeatable review of the data your team needs to assess.
Start with the question your gate answers
A pull-request gate might ask whether a mapping change breaks known examples. Include valid cases and deliberately invalid cases so the gate demonstrates both acceptance and defect detection.
A release check might examine a selected delivery. A recurring check might revisit a server selection after new data arrives or a dependency changes. Each needs an explicit scope and enough context to interpret its outcome.
The same pipeline platform can coordinate these tasks. GitHub Actions, for example, supports scheduled and externally triggered workflows. A separate scheduler is an operating choice, not a prerequisite for collecting useful evidence.
Cover changes outside the application commit
The data can change when a partner sends a new delivery. A team can adopt a different profile package or terminology release. A validator update can alter behavior, including fixing a defect in the validator itself.
A job triggered only by application commits will not necessarily observe these events. Choose a trigger that matches the question: a delivery event, dependency update, release step or recurring schedule.
Keep the requirement version explicit. Data accepted under one profile is not automatically defective because a newer profile imposes a different requirement. A comparison across those contexts needs to explain the changed basis.
Select data the decision actually concerns
Fixtures are valuable because their expected behavior can be reviewed. Include difficult cases, regression examples and representative combinations. They still have a defined coverage boundary.
For a delivery decision, examine the agreed delivery or a clearly described sample. For a server assessment, record the selected resource types, filters, time window and limits. Production data requires an appropriate operating arrangement and access controls.
Check completion as well as finding counts. Missing terminology, failed requests, omitted resources and truncated results can narrow what the evaluation establishes. An unavailable check is not a passing check.
Preserve enough context for a later review
A useful report connects its findings with the source and selection, validation time, validator and settings, profile packages, terminology context, completion and coverage.
A CI system can preserve such artifacts. A green build indicator alone carries less information. The question is what your configured workflow records and retains.
Records provides durable run context and reports for these reviews. Missing or mutable validation inputs remain limitations. Repeating an evaluation later also requires the corresponding source data and dependencies; a stored hash does not reconstruct them.
Turn a finding into a verified correction
Assign the investigation to a responsible person. Check whether several findings share a cause, record the intended source change and define the follow-up check.
After the correction, compare completed runs only where the selection and evaluation basis support the comparison. If the profile, terminology or validator changed, review that separately. A reduced count could otherwise reflect a different check or narrower selection.
Recurring validation produces observations at particular times. It does not cover every resource between runs or catch every possible issue. Record the latest checked scope and time alongside the result.
Improve the workflow you already have
Start with the GitHub Actions validation guide for a file-based gate. Then decide which additional data, triggers and retained context your operating question needs.
Records' quality loop shows an executed source correction, comparable recheck and recorded report. Use that example to assess whether your team can follow a finding through to a reviewable outcome.
