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)
Deterministic Signals
Every validation run produces one of three signals. Records produces signals — you decide and act.
All thresholds met
Operator: proceed with confidence
Non-critical thresholds breached
Operator: proceed with investigation
Critical thresholds breached
Operator: investigate before proceeding
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
What goes in, what comes out, and why it matters.
Inputs
- FHIR EndpointOne or more server URLs — Records reads via GET/HEAD only
- Profile Set + VersionStructureDefinitions that define your conformance target
- Terminology StateCodeSystem/ValueSet bindings from your terminology server
- Run ConfigurationThresholds, exclusions, environment label, baseline reference
Outputs
- SignalsDeterministic PASS / WARN / FAIL per validation run
- DeltasNew errors, resolved warnings, and regressions vs. baseline
- Evidence MetadataRun ID, timestamp, config fingerprint, environment, profile version
- Conformance ScorePercentage-based quality indicator per resource type and environment
Data Handling & Liability
Privacy-preserving architecture by design.
No Clinical Payload Storage
Records stores resource IDs, validation outcomes, issue counts, and run metadata — never clinical content, patient data, or resource payloads.
Evidence, Not Authority
Records outputs PASS/WARN/FAIL signals. Your governance team decides whether to ship, investigate, or block. Records never enforces policy.
Adjacent to FHIR Server/CDR
Deploys alongside your existing infrastructure as a sidecar. No replacement, no migration — pure value accretion to your current stack.
Read-Only Access
Connects via GET and HEAD requests only. Records never writes, modifies, or deletes data on your FHIR server or any external system.
Deployment Options
Flexible hosting models adjacent to your infrastructure.
On-Prem / VPC
Deploy the Records container in your own infrastructure. Full data sovereignty.
- •Air-gapped ready — no outbound internet required
- •Docker / Kubernetes deployment with standard orchestration
- •Your network, your rules — data never leaves your perimeter
SaaS / Cloud
Coming soonFully managed. We host the control plane, you connect your FHIR server securely.
- •Zero infrastructure overhead — we handle updates and scaling
- •TLS-encrypted connections to your FHIR endpoints
- •Multi-tenant isolation with per-environment separation
Compatibility
Ensuring interoperability with existing standards and profiles.
| FHIR version | R4, R5, R6-ready (routing-aware) |
| German profiles | MII, ISiK, KBV |
| International profiles | US Core, UK Core, IPS, AU Base |
| Supported servers | HAPI, Firely, Aidbox, Azure, Google, AWS |
| Terminology servers | tx.fhir.org, Ontoserver, custom |
| Authentication | OAuth2, API Key, Basic Auth, Open |
| Resource types | 146+ (auto-discovered) |
| Validation aspects | Structural, Profile, Terminology, Reference, Metadata, Business Rules |
| Deployment | Hybrid, offline, air-gapped |
See it on your own data.
We'll connect Records to your FHIR server and run a validation — live, in 30 minutes. No slides, no sandbox.