After creating or updating a FHIR resource, POST a Provenance resource that references the affected resource in Provenance.target, identifies the agent (system or user), and records the activity code
For each FHIR API access involving PHI, create an AuditEvent resource with the DICOM/IHE-compliant event type code, agent block identifying the requester, entity block identifying the accessed resource, and a timestamp
Use consistent agent.type codes and agent.role codes from the relevant ValueSets to allow meaningful audit queries
POST AuditEvent resources asynchronously to avoid adding latency to primary operations, but ensure delivery guarantees to prevent audit gaps
Periodically query AuditEvent with date and agent parameters to produce access reports for compliance review
Known gotchas
AuditEvent.recorded must use the time the event occurred, not the time the AuditEvent resource was created; batching audit writes with delayed timestamps misrepresents the access timeline
Provenance.agent.who should reference a Practitioner, PractitionerRole, Organization, or Device resource; using a display-only reference without a resolvable URL breaks provenance chain queries
AuditEvent resources are often write-only from the perspective of clinical systems; ensure the server's access control policy permits the audit writer to POST AuditEvent without requiring read access to the audited resource
Give your agent this knowledge — and 200+ more routes
One MCP install gives any agent live access to the full route map, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp