The questions that change an evaluation.

Records is a FHIR release-quality product. It validates resources against configured profiles and terminologies, compares contract-compatible runs with baselines, supports issue investigation, and produces PASS/WARN/FAIL evidence with a captured validation context. Automated validation is read-only by default.

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 processes FHIR resources transiently for validation but does not persist source clinical resource payloads. It stores derived validation outcomes, issue counts, run metadata, configuration context, fingerprints, and evidence according to the selected operating mode.

Automated validation is read-only. Optional delegated submissions are available only through an explicitly enabled edit mode, must be initiated by a user, and are executed and owned by the connected FHIR server.

Records is adjacent to the connected FHIR server, so an unavailable Records instance does not stop that source system. Whether a deployment pipeline waits, warns, or fails when its Records check is unavailable remains an external workflow policy. Optional delegated submissions are separate user actions and are unavailable while Records is down.

Enterprise supports private-managed and on-prem deployment qualification, including restricted-connectivity environments. The exact networking, profile-package, terminology, update, and support model is defined for the deployment.

Records public entry points accept R4, R4B, R5, and R6. The pinned 23 July 2026 report recorded 536/536 in-scope R4, R5, R6, and unversioned JSON resource comparisons; it is a dated measurement, not an R4-only, package-coverage, or live score for every later build. R4B preserves its release identity through an R4 maintenance adapter, package coverage remains version-specific, and R6 remains preview with explicit limited-support findings.

Not yet. We are transparent about this. Records uses read-only-by-default validation, avoids source clinical payload retention, and supports controlled deployment modes, but MedVertical does not currently claim ISO 27001, SOC 2, or HIPAA certification.

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. Reproducing one result requires the same resource set, locked validation inputs, and resolvable dependencies. Comparing two runs requires compatible validator, configuration, package, terminology, scope, environment, and threshold context while allowing the measured resource state to differ.

CI validation catches regressions introduced through controlled code changes. Profiles, terminology, source data, and infrastructure can also change outside that boundary. Records can run recurrently against an approved FHIR scope, compare contract-compatible runs, and preserve a timestamped evidence artifact with the validation context. Production data requires a separately qualified operating mode.