# Records — FHIR Validation and Data Quality

Records helps a FHIR team answer three questions:

1. Does this delivery meet the selected conformance and data-quality checks?
2. What changed after a correction under a compatible evaluation basis?
3. Can the receiving team review the findings, captured inputs, and remaining limits?

## Explore resources and investigate findings

Start in Browse with a resource list, open the validation findings for the selection, then inspect an affected resource and its marked field. Profiles and requirements stay connected to the source. Follow references to understand related resources.

For an already known problem, start in Issues and follow the issue to its affected resources. The [workflow library](/records/workflows) provides separate Browse and Issues walkthroughs.

## Data quality alongside conformance

Data Quality Management (DQM) evaluates versioned indicators over a bounded dataset. Examples include completeness, identifier uniqueness, and reference integrity. Each result needs its scope, policy, evaluated population, numerator, denominator, and not-evaluable cases.

Records includes independently defined, non-normative MII-oriented indicators. These operational checks complement profile and terminology validation. They do not establish MII certification or clinical fitness for a study.

## Release-quality loop

- **Define the basis:** Select the server or dataset, resource scope, FHIR release, profile packages, terminology sources, rules, and thresholds.
- **Run and compare:** Execute the validation contract and compare the result with a pinned baseline or another compatible run.
- **Investigate:** Move from the aggregate signal to the affected resource, field, rule, profile, or terminology binding.
- **Preserve evidence:** Keep the result with its scope, versions, timestamps, configuration fingerprints, and integrity metadata.

Missing or mutable run inputs remain explicit. Repeating an evaluation also requires the corresponding source data and outcome-relevant dependencies. A report-content hash verifies content consistency against a reference; it does not establish the clinical truth of the source data.

## Representative decisions

- Release safety after profile, mapping, terminology, or server changes.
- Drift and regression detection between comparable runs.
- Multi-server or supplier comparison under one explicit validation basis.
- CI/CD quality gates with machine-readable output.
- Reporting, research, handover, and audit-readiness evidence.
- Deterministic validation boundaries around agent-generated or transformed FHIR.

## Product boundary

Records emits PASS, WARN, and FAIL signals. It does not decide whether a warning is acceptable, whether data is clinically correct, whether a system is compliant, or who has approval authority.

Validation is read-only by default. Records processes selected FHIR resources transiently and does not retain source clinical resource payloads as its system of record. Derived findings, run metadata, configuration context, audit events, evidence records, and integrity hashes can persist according to the deployment policy.

## FHIR compatibility

- **R4:** supported; the dated cross-version Java-parity report includes R4 alongside R5, R6, and unversioned JSON cases.
- **R4B:** supported entry points with an explicit compatibility boundary.
- **R5:** supported; coverage depends on the exact packages, terminology, and validation aspects used.
- **R6:** preview; accepted against a pinned ballot package and not presented as production-equivalent coverage.

See [Compatibility](/compatibility) for the current matrix and review date.

## Ways to use Records

- [Try Records](/records/demo) — Choose public-server browsing or the synthetic-resource sandbox, with examples and an illustrated guide.
- [Open public demo](https://records.medvertical.com/demo) — Browse public FHIR servers; no account required.
- [Sandbox walkthrough](https://medvertical.com/records/demo#sandbox) — Inspect and validate a temporary synthetic resource.
- [Plan your evaluation](/hosted-access) — One delivery, agreed conformance and quality checks, findings to investigate, and a repeat run after a correction. Scope, timing, operating model, and terms are agreed before starting; workspace access is staged.
- [Customer-managed Enterprise](/deployment) — Qualification for operation inside a controlled customer environment.
- [Open-source validator](/developers/validator) — Embed the Apache-2.0 TypeScript engine.
- [Records CLI](/developers/cli) — Validate local files or run a CI gate.
- [Records Agent Tools](/developers/claude-code) — Add local FHIR validation to Claude Code or Codex.
- [Records MCP server](/developers/mcp) — Expose tenant-scoped validation and run context to compatible agents.