fhir-r6-guardrails
Skill33 starsChanged 4 months agoMITView on GitHub
HealthClaw Guardrails (healthclaw.io) — FHIR agent guardrails for clinical data access via MCP. Supports FHIR R4 US Core v9 (stable) and FHIR R6 ballot3 (experimental). Use when: (1) Reading patient data through MCP tools with automatic PHI redaction, (2) Writing clinical resources with two-phase propose/commit and step-up authorization, (3) Querying observation statistics or recent lab results, (4) Evaluating R6 Permission resources for access control decisions, (5) Auditing agent access to healthcare data. 14 MCP tools.
In this repository13 other files it gives its agents.
- check-sourcesSkill
- curatrSkill
- fasten-connectSkill
- fhir-upstream-proxySkill
- getting-startedSkill
- healthbankoneSkill
- healthex-export-redactedSkill
- healthex-exportSkill
- hermesSkill
- hypertension-coordinatorSkill
- personal-health-recordsSkill
- phi-redactionSkill
- share-health-qrSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 60
Propose: Call fhir.propose_write with the resource and operation (create/update).
- Distinctive: line 63
Review: Check the proposal response:
- Very specific: line 68
Commit: Call fhir.commit_write with the same resource.
- Distinctive: line 123
Not supported in local mode: chaining, _include, _revinclude, modifiers.
- Distinctive: line 152
No historical versioning (version_id increments but old versions not retrievable)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
HealthClaw Guardrails
A healthclaw.io open source project. Reference implementation of security and compliance patterns for AI agent access to FHIR data via MCP.
Supports FHIR R4 US Core v9 (stable) and FHIR R6 v6.0.0-ballot3 (experimental).
This is a runtime guardrail layer, not a knowledge skill. It sits between any AI agent and FHIR data (local or upstream), enforcing PHI redaction, audit trails, step-up authorization, and tenant isolation on every request.
When to Use This Skill
- You need to read, search, or write FHIR clinical resources through MCP
- You need PHI to be automatically redacted before the agent sees it
- You need an immutable audit trail of all agent access
- You need step-up authorization gates on write operations
- You need to evaluate R6 Permission resources for access control
MCP Tools Available (12)
Read Tools (no step-up required)
| Tool | Purpose |
context.get | Retrieve a pre-built context envelope with patient-centric resources |
fhir.read | Read a single FHIR resource by type and ID (auto-redacted) |
fhir.search | Search resources with patient, code, status, date filters |
fhir.validate | Structural validation of a proposed resource |
fhir.stats | Observation statistics: count, min, max, mean over valueQuantity |
fhir.lastn | Most recent N observations per code |
fhir.permission_evaluate | Evaluate R6 Permission for permit/deny with reasoning |
fhir.subscription_topics | List available SubscriptionTopics |
curatr.evaluate | Evaluate a FHIR resource for data quality issues |
Write Tools (require step-up token)
| Tool | Purpose |
fhir.propose_write | Validate and preview a write without committing |
fhir.commit_write | Commit a proposed write (requires X-Step-Up-Token) |
curatr.apply_fix | Apply patient-approved data quality fixes with Provenance |
Two-Phase Write Pattern
Writes always follow propose-then-commit:
- Propose: Call
fhir.propose_writewith the resource and operation (create/update). This validates the resource and returns a preview. No data is changed. - Review: Check the proposal response:
proposal_status: "ready"means validation passedrequires_human_confirmation: truefor clinical resource typesrequires_step_up: truealways for commits
- Commit: Call
fhir.commit_writewith the same resource. Include:X-Step-Up-Tokenheader (HMAC-SHA256 signed, 5-minute TTL)- For clinical resources, a 428 means a human must confirm. Stop and tell
the person; never set
X-Human-Confirmedyourself. Outward actions (calls, texts, forms) go through the action rail's out-of-band approval.
Clinical Resource Types (require human-in-the-loop)
Observation, Condition, MedicationRequest, DiagnosticReport, AllergyIntolerance, Procedure, CarePlan, Immunization, NutritionIntake, DeviceAlert.
Supported FHIR Resource Types
FHIR R4 US Core v9 (Stable)
Patient, Encounter, Observation, AuditEvent, Consent, Condition, Provenance, AllergyIntolerance, Immunization, MedicationRequest, Medication, MedicationDispense, Procedure, DiagnosticReport, CarePlan, CareTeam, Goal, DocumentReference, Location, Organization, Practitioner, PractitionerRole, RelatedPerson, Coverage, ServiceRequest, Specimen, FamilyMemberHistory.
FHIR R6 ballot3 (Experimental)
Permission, SubscriptionTopic, Subscription, NutritionIntake, NutritionProduct, DeviceAlert, DeviceAssociation, Requirements, ActorDefinition.
- Permission — Access control (separate from Consent).
$evaluateoperation. - DeviceAlert — ISO/IEEE 11073 device alarms.
- NutritionIntake — Dietary consumption tracking.
- DeviceAssociation, NutritionProduct, Requirements, ActorDefinition — CRUD only.
Security Guardrails (Always Active)
PHI Redaction
Applied on every read path. Names truncated to initials, identifier values removed (system and type kept), addresses stripped to city/state/country, birth dates truncated to year, photos removed, notes replaced with [Redacted].
Audit Trail
Append-only AuditEvent records for every resource access. Database-level immutability. Logs agent ID, tenant ID, resource accessed, and outcome.
Step-Up Authorization
HMAC-SHA256 tokens with 128-bit nonce, 5-minute TTL, tenant binding. Required for all write operations.
Tenant Isolation
X-Tenant-Id header enforced on every query at the database layer.
Search Parameters (Local Mode)
Supported: patient (reference), code (token), status (token),
_lastUpdated (date with ge/le/gt/lt prefix), _count (1-200),
_sort (_lastUpdated/-_lastUpdated), _summary (count).
Not supported in local mode: chaining, _include, _revinclude, modifiers.
In upstream proxy mode, all query parameters are forwarded to the upstream server.
Setup
# Docker Compose (recommended)
docker-compose up -d --build
# Manual
uv sync && python main.py &
cd services/agent-orchestrator && npm ci && npm startRequired environment variables:
STEP_UP_SECRET— HMAC secret for step-up tokens
Optional:
FHIR_UPSTREAM_URL— Connect to a real FHIR server (e.g., https://hapi.fhir.org/baseR4)FHIR_BASE_URL— Backend URL (default: http://localhost:5000/r6/fhir)MCP_PORT— MCP server port (default: 3001)
Known Limitations
- Local mode uses SQLite JSON blob storage (not indexed search)
- Structural validation only (no StructureDefinition or terminology binding)
- SubscriptionTopic stored but notifications not dispatched
- Human-in-the-loop is header-based, not cryptographic
- No historical versioning (version_id increments but old versions not retrievable)
- Upstream proxy: no response caching, no cross-version translation
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

