RecordsContinuous FHIR validation with audit-ready evidence.
Records runs next to your FHIR server, validates your data continuously, detects drift before release, and produces reproducible evidence without storing clinical payloads.
The problem no FHIR server solves
FHIR implementations pass validation on day one. Then they drift.
No Proof of Quality
You hope your data is compliant, but you can't prove it to auditors or partners.
Upgrades Break Things Silently
Updating your FHIR server or validator is scary because you don't know what might break.
Environments Drift Apart
Dev works, Staging is okay, Prod is failing. Nobody knows why.
How it works
Three steps. No migration required.
Connect
Connect Records to your FHIR endpoint in read-only mode.
Validate
Run profiles, terminology checks, and rules continuously.
Evidence
Compare runs, detect drift, and produce audit-ready evidence.
Validation engine metrics
Fast, deterministic checks designed for continuous runs and reproducible evidence.
~5 ms
Median validation time
CPU-only, no I/O
100%
Test recall
244/244 defects detected
8
Validation aspects
Incl. anomaly detection
~175/s
Engine throughput
CPU-only, no I/O (M1 Max)
Records is not a server. It observes yours.
Zero interference. Engineered for strict healthcare compliance and data privacy.
Read-only
GET/HEAD only. No write operations to your infrastructure.
No PHI stored
Only IDs, metadata, and validation outputs. No clinical payloads.
Neutral measurement
Produces evidence signals. Your team makes the decisions — Records never blocks or enforces.
Vendor-neutral
Works with any FHIR R4/R5 server. No platform lock-in.
EU-based infrastructure
Hosted securely in Frankfurt. Fully GDPR compliant with strict data sovereignty.
On-prem available
Deploy within your own VPC or bare-metal infrastructure for maximum control.
Common Records use cases
Five scenarios where continuous validation turns into release and audit evidence.
Validate before every IG update, server upgrade, or mapping change hits production
Drift & RegressionDetect conformance drift from terminology updates, IG changes, and upstream system changes
Multi-Server ComparisonCompare conformance across servers, suppliers, and environments
Regulatory & Audit EvidenceProduce reproducible quality evidence for regulatory submissions and compliance audits
CI/CD Quality GateAdd FHIR validation to your GitHub Actions or GitLab CI pipeline
Latest notes
Essays on FHIR data quality, validation, and evidence.
The German FHIR Landscape: ISiK, MII, gematik, and Why It's More Complex Than It Looks
Germany has one of the densest and most overlapping FHIR landscapes in Europe. ISiK, MII, DiGA, KHZG — they're not the same thing, they don't share the same profiles, and hospitals may need to work with several of them simultaneously.
Terminology Drift: The Silent Killer of FHIR Data Quality
Your FHIR data was valid when it was created. It may not be valid today. Terminology drift is a common — and often under-monitored — source of FHIR data quality failures.
Three Questions Every FHIR Team Should Be Able to Answer
FHIR teams rarely fail because they lack a validator. They fail when they cannot answer whether production data is valid now, when errors first appeared, and what the conformance state was in the past.
Talk to us about Records.
Share your context, question, or integration idea. We'll help you identify the right next step.