FAQ
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.
Regulation (EU) 2025/327 — the European Health Data Space — entered into force in March 2025. Implementing acts covering the technical exchange format are expected by March 2027. Records validates against the HL7 Europe Base IG (the foundational EHDS FHIR layer, published November 2025) using the same reproducibility contract as national profiles. It produces timestamped, auditable evidence that can accompany data submissions to EU secondary-use infrastructure. Records does not claim EHDS certification — no such certification process exists yet — but it provides the continuous conformance evidence that cross-border health data sharing will require.
CI validation catches regressions you introduce through code changes. FHIR data quality degrades in three ways that CI never sees: (1) profiles update between your commits — a new cardinality constraint or must-support element invalidates resources without any code change; (2) terminology changes independently — SNOMED CT retires codes twice a year, ICD-10-GM updates annually, and your CI fixtures don't contain the affected production data; (3) CI validates test fixtures, not live production data. Records runs continuously against your actual FHIR server, compares each run against a baseline, and produces a timestamped evidence artifact — not just a pass/fail signal that disappears after the build.
Terminology drift happens when FHIR data becomes non-conformant because an external terminology source changed — not because your code changed. SNOMED CT publishes major releases twice a year and retires codes. ICD-10-GM updates annually. ValueSet expansions shift when the underlying hierarchy is updated. Your CI pipeline passes because your test fixtures don't include the affected codes. Production data fails silently. Records detects this by running validation continuously against live data and comparing runs against a pinned baseline — surfacing exactly which resources changed conformance status and whether the cause was a data change or a terminology update.
Yes. Records validates against all ISiK profile sets (currently Stage 3; Stage 5 in preparation). The ISiK Bestätigungsverfahren is a point-in-time snapshot — it confirms what your system produced at the time of the audit. Records fills the gap between certification cycles: it validates continuously against your production data, detects when a gematik profile patch or ICD-10-GM update changes your conformance posture, and produces reproducible evidence that your conformance holds between Bestätigungsverfahren snapshots.
Yes — and the MII context is one of the most demanding FHIR validation environments that exists. 38 university hospitals and 3 non-university sites each implement the MII Kerndatensatz independently, with different ETL pipelines, different source systems, and different update cycles. Records addresses two specific MII challenges: cross-site consistency (validating the same KDS module across multiple DIZ environments and comparing results) and research-grade evidence (producing validation reports that document which profile version the data was validated against, at what conformance rate, and with what known issues — evidence that can accompany research datasets submitted to the Forschungsdatenportal).