Agentic FHIR Workflows
AI agents can generate, transform, summarize, and route FHIR. Records gives those workflows a validation layer before agent output becomes downstream healthcare data.
For: AI agent builders, FHIR platform teams, health-data workflow owners, clinical data governance teams
The problem
Agents move faster than manual review. FHIR quality still has to hold.
AI agents are starting to generate mappings, repair OperationOutcomes, summarize bundles, prepare handoffs, and route health-data tasks. Those workflows can be useful only if the FHIR they produce or touch is structurally valid, profile-aware, terminology-aware, and traceable.
The failure mode is simple: an agent emits plausible FHIR that looks right, but carries a deprecated code, misses a required profile element, breaks a reference, or changes quality posture compared with the previous run. Without a validation gate, that output can move into tickets, pull requests, client deliveries, or live workflows unchecked.
How Records solves it
Validation tools for the points where agents create or change FHIR.
Records gives agent workflows the same validation surface as human-operated FHIR delivery: issue groups, terminology checks, reproducible run context, and deltas against previous validation results before output moves downstream.
MCP tools for agents
Agents can call validate_resource, explain_issue, get_quality_score, and compare_runs through the Records MCP server.
8-aspect validation
Structural, profile, terminology, reference, invariant, custom rule, metadata, and anomaly checks before downstream use.
Fast local checks
The open-source TypeScript validator can run inside local workflows and CI without Java or a Records server.
Evidence trail
Records-connected workflows preserve validator version, IG packages, terminology source, thresholds, timestamps, and content hash.
Agent decision surface
agent creates or changes FHIR -> validate_resource -> explain_issue when needed -> compare_runs for regression context -> human or workflow decision: accept, repair, review, or rejectWhere it fits
Records is a guardrail layer, not a replacement for clinical governance.
Use Records for
- validating agent-generated resources
- checking terminology and profile conformance
- explaining validation issues to developers
- comparing runs before accepting agent changes
- producing evidence for review and handoff
Do not use Records as
- a clinical decision engine
- a medical-device safety claim
- a policy enforcement authority
- a substitute for human governance
- a place to store clinical payloads
Frequently asked questions
No. Records is a validation and evidence layer, not a clinical safety system. It checks FHIR structure, profile conformance, terminology bindings, references, invariants, metadata, custom rules, and anomaly signals. Your workflow still decides whether the agent output can be accepted, reviewed, rejected, or routed.
Records supports workflows where agents generate, transform, summarize, inspect, or route FHIR resources and need validation feedback before downstream use. The MCP server exposes validation, issue explanation, quality scoring, and run comparison to compatible clients.
No. Records itself stores no clinical payloads. The local validator and Claude Code plugin can validate resources locally. For hosted Records or agent workflows that process live data, deployment and data-flow controls must match your policy, contract, and regulatory context.
Yes. Records can validate coded elements against configured terminology sources and pinned snapshots, so agents can detect deprecated, unknown, or non-member codes before acting on the resource.
Building agentic FHIR workflows?
We can help you decide where validation belongs in the workflow.