The questions that change an evaluation.

Records helps teams check FHIR conformance and dataset quality before a release or data handover. It validates selected profiles and terminologies, measures configured quality indicators, supports investigation, and compares compatible runs with a recorded evaluation 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.

No. Records is read-only by default. Its core workflow is validation, investigation, comparison, and reviewable evidence. Delegated editing is optional: a user submits each change explicitly, and the connected FHIR server executes and owns it. The sandbox checks copies and never writes back to a source server. Records does not automatically remediate or silently rewrite source data.

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. Package and terminology coverage are version-specific. R4B preserves its release identity through an R4 maintenance adapter, and R6 remains preview. The Validator page explains the archived comparison results, residual differences, and missing release provenance; those reports are not a conformance score for the current npm package.

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.