See what your FHIR server can't show you.
Validation state, configuration drift, and release evidence—all adjacent to your CDR.
Release Safety Gate
Validate before pushing an IG/Profile update, FHIR server upgrade, or mapping change to production.
What Records Is / Is Not
Defining the boundaries between clinical storage and validation intelligence.
Records IS
- • A FHIR DataOps control plane
- • A validation orchestrator
- • A drift detection system
- • A release gate surface
- • An evidence producer
- • A vendor-neutral observer
Records is NOT
- • CDR / storage platform
- • EHR / clinical application
- • BI / analytics system
- • Compliance suite
- • System of record
- • Decision-making authority
Hard Invariants
Non-negotiable architectural guarantees for safety and stability.
Adjacency
Runs alongside your FHIR server (sidecar or proxy), not partially.
Evidence
Every validation result is stored as immutable proof.
No Payload Limit
Records stores metadata results, never your patient PHI.
Read-Only
We adhere to a strict read-only policy for your source data.
Non-Blocking
Validation happens asynchronously. Zero latency impact.
Neutral
Works with HAPI, Firely, Aidbox, Azure, Google, AWS.
Who Owns What
Clear delineation of roles between the Host, Records, and Governance.
| Responsibility | FHIR Server / CDR | Records |
|---|---|---|
| Data storage | ||
| Data access control | ||
| Clinical workflows | ||
| Validation evidence | ||
| Drift detection | ||
| Release gates | ||
| Baseline management |
Core Primitives
The fundamental building blocks of the validation engine.
Validation Run
A point-in-time execution of validation rules against a dataset, producing evidence outputs
Environment
A logical separation (dev/test/prod) for evidence comparison
Baseline
A reference validation state against which changes are measured
Delta / Drift
The difference between current validation state and baseline
Threshold → Signal
A boundary condition that produces pass/warn/fail outputs
Evidence Output
An auditable validation result surface (v1: in-app view)
When to Use Records
Five concrete scenarios where Records produces the evidence you need.
Release Safety Gate
Validate before pushing an IG/Profile update, FHIR server upgrade, or mapping change to production.
Drift & Regression Detection
After changes land, compare current validation state against your baseline to catch new errors immediately.
Deep-Dive Investigation
Instantly drill down from high-level metrics to specific JSON resources. See the exact line causing the error with contextual highlighting.
Acceptance & Handover Evidence
When a vendor delivers or a system migrates, produce auditable proof of validation state.
Multi-Server Comparability
Compare validation state across federated servers to identify alignment gaps before integration.
Technical Surface
Inputs, outputs, and integration points.
Inputs
- FHIR EndpointREST API Connection
- ProfilesStructureDefinitions
- TerminologyCodeSystems / ValueSets
- ConfigValidation Rules
Outputs
- SignalsPass / Fail / Warn
- DeltasDrift from Baseline
- EvidenceAudit Reports
Data Handling & Liability
Privacy-preserving architecture by design.
No Clinical Payload Storage
Metadata only: IDs, validation outputs, run configuration.
Evidence, Not Authority
Records produces signals; governance stakeholders decide.
Adjacent to FHIR Server/CDR
No replacement, no competition—value accretion.
No Writes
GET/HEAD only; no write operations to external systems.
Deployment Options
Flexible hosting models adjacent to your infrastructure.
SaaS / Cloud
Fully managed. We host the control plane, you connect your FHIR server securely.
On-Prem / VPC
Deploy Records container in your own infrastructure. Air-gapped ready.
Compatibility
Ensuring interoperability with existing standards and profiles.
| FHIR version | R4, R5 (routing-aware) |
| German profiles | MII, ISiK, KBV |
| Deployment | Hybrid, offline, air-gapped |