Frequently Asked Questions
Common questions about Records, data handling, deployment, and compatibility.
Records is a continuous FHIR validation and drift detection tool. It connects to your FHIR server via standard REST API, validates resources against your configured profiles and terminologies, and produces deterministic PASS/WARN/FAIL signals. It runs adjacent to your infrastructure — it observes, never modifies.
No. Records is not a Clinical Data Repository, an EHR, or a FHIR server. It is a validation and evidence layer that runs alongside your existing infrastructure. It adds capability without replacing anything.
Records stores resource IDs, validation outcomes (PASS/WARN/FAIL), issue counts, run metadata, and configuration snapshots. It never stores clinical content, patient data, or resource payloads.
No. Records connects via GET and HEAD requests only. It never writes, modifies, or deletes data on your FHIR server or any external system.
Nothing happens to your infrastructure. Records is adjacent — it has no write access, no data pipeline dependency, and no integration point that could affect your FHIR server's operation. If Records is unavailable, your systems continue exactly as before.
Yes. Records is available as a Docker container for on-prem deployment. It supports air-gapped environments with no outbound internet required. Your data never leaves your network.
Records supports FHIR R4 and R5, with R6 preview capabilities. It has been tested against 6 different FHIR server implementations (HAPI, Firely/Vonk, Blaze, Spark, Medplum, SMART Health IT).
Yes. Records has been tested against MII Kerndatensatz, ISiK Basismodul, and KBV profiles. It also supports international profiles including NHS UK, IPS, US Core, Swiss EPR, Dutch Nictiz, and HL7 Europe.
Not yet. We are transparent about this. Records is designed with privacy-preserving architecture (read-only access, no PHI storage, EU-based infrastructure), but we have not completed formal certification processes. We do not claim certifications we do not have.
Records uses an 8-aspect validation engine: Structure, Profile, Terminology, Reference, Invariants, Custom Rules, Metadata, and Anomaly. Each aspect can be enabled or disabled per server. The engine is deterministic — same inputs always produce the same outputs.
Yes. Records supports custom FHIRPath-based rules that go beyond standard FHIR profile validation. You can define project-specific or site-specific constraints and test them against sample resources before activation.
Records produces data quality evidence — timestamped, reproducible validation results — which is relevant context as health data ecosystems move toward secondary-use and cross-site sharing requirements. However, Records does not claim EHDS compliance or readiness. EHDS requirements are still evolving.