Evidence, not authority.
Records is a FHIR DataOps control plane. It produces evidence signals—you make the decisions.
Why Evidence Matters
FHIR infrastructure produces no inherent proof of correctness. Servers store data; CDRs manage clinical context—but neither emits validation evidence, detects configuration drift, or gates releases. Without a dedicated control plane, teams operate blind.
The core diagnostic question is not “Is our data valid?” but “Will we know when it stops being valid?” Conformance at deployment time proves nothing about conformance tomorrow. At least seven distinct drift vectors can silently degrade data quality after initial validation:
| Drift Vector | Example | Detection Window |
|---|---|---|
| Terminology server update | CodeSystem version change alters ValueSet memberships | Days to weeks |
| IG/Profile revision | New constraints added or cardinality changed | Release cycle |
| FHIR server upgrade | HAPI v6.3→v6.4 changes validation behavior | Immediate |
| Mapping pipeline change | ETL logic drift alters output structure | Hours to days |
| Environment config divergence | Dev uses R4@1.4.0, Prod uses R4@1.5.0 | Silent |
| Data volume shift | Edge cases emerge at scale that never appeared in testing | Weeks |
| Dependency chain update | Transitive profile dependency changes upstream | Silent |
Without continuous validation, these vectors compound silently. Records exists to make each one detectable.
Evidence, Not Authority
Records produces evidence signals. Governance stakeholders make decisions. Records never claims authority over acceptance, approval, or enforcement. It does not block deployments or apply policy—it outputs evidence and you decide.
Every validation run produces exactly one of three deterministic signals. The mapping from signal to operator action is always clear:
All thresholds met
Operator: proceed with confidence
Non-critical thresholds breached
Operator: proceed with investigation
Critical thresholds breached
Operator: investigate before proceeding
Boundary Discipline
Records observes but never controls. Every boundary is testable: if Records ever writes to your server, stores clinical payloads, or makes governance decisions — that is a bug.
Infrastructure Adjacency
Records deploys as a sidecar — adjacent to your infrastructure, never replacing it. Each system retains its single responsibility:
Your FHIR Server
Stores and serves clinical resources. Handles CRUD, search, and access control.
Your CDR
Manages clinical context, workflows, and patient records. System of record.
Records
Reads via GET/HEAD. Produces evidence signals. Never competes — adds value to what you already have.
Operating Model
Records operates continuously, not episodically. Validation runs on every change, not quarterly audits. The release-safety loop is the core operational cycle:
Each step in the loop produces traceable evidence. Baselines establish known-good states. Runs produce signals. Deltas quantify change. Alerts notify. Triage assigns ownership. Fixes resolve. Re-baselining closes the loop and starts the next cycle. The operator controls every transition.
Determinism & Reproducibility
Same inputs produce same outputs. Evidence is comparable across time, environments, and teams. This is the reproducibility contract — seven inputs must be identical for a run to be considered comparable:
| Input | Why it matters |
|---|---|
| FHIR endpoint URL | Identifies the data source |
| Profile set + version | Determines validation rules |
| Terminology server state | Resolves code bindings |
| Validator version | Engine behavior determinism |
| Run configuration | Thresholds, exclusions, scope |
| Environment label | Isolation and comparison context |
| Timestamp | Point-in-time data snapshot |
If any of these inputs change between runs, the resulting evidence is not directly comparable. Records tracks all seven automatically.
Ready to close the loop?
See how the safety loop works on your own FHIR infrastructure — baseline, validate, compare, repeat.