Skip to main content

AxonFlow for Healthcare

Healthcare organizations are deploying AI agents that triage patients, authorize procedures, draft clinical communications, and code medical records. Every one of those workflows touches protected health information (PHI), crosses regulatory boundaries, and carries patient safety liability if the agent acts incorrectly. AxonFlow provides the runtime governance layer that sits between your AI agents and the actions they take -- enforcing policies, detecting PHI before it reaches LLM providers, gating high-risk clinical decisions for human review, and producing the audit trail your compliance team and regulators will ask for.

This page maps AxonFlow capabilities to concrete healthcare workflows, regulatory requirements, and deployment patterns. Everything described here is shipped and available today. AxonFlow does not claim to be "HIPAA compliant" -- it provides the technical safeguards that help your team build HIPAA-compliant AI systems within your covered entity or business associate framework.

The healthcare AI governance challenge​

Healthcare is not short of AI use cases. The challenge is that the regulatory environment treats AI failures as patient safety events. HIPAA's Security Rule (45 CFR §164.312) requires technical safeguards for any system that creates, receives, maintains, or transmits electronic protected health information (ePHI). The HITECH Act extends enforcement with breach notification obligations and penalties that scale with the number of affected individuals. An AI agent that leaks a patient's SSN, diagnosis code, or medication history to a third-party LLM provider is a reportable breach under both frameworks.

Beyond HIPAA, healthcare AI faces additional regulatory pressure. The FDA's evolving guidance on AI/ML-based Software as a Medical Device (SaMD) expects documented evidence of how AI outputs are governed, monitored, and subject to human oversight. The EU Medical Device Regulation (EU MDR) imposes post-market surveillance and traceability requirements on any software that qualifies as a medical device. Healthcare organizations deploying AI in clinical workflows must demonstrate not just that the AI works, but that its outputs were governed at every step.

These frameworks share four common demands:

  1. PHI protection at the boundary. Patient names, SSNs, dates of birth, email addresses, phone numbers, and medical record numbers must not leak into LLM prompts, MCP connector payloads, or downstream tool calls. Detection must be accurate, and the enforcement action must be configurable per environment and per data type.
  2. Human oversight on clinical decisions. No regulator or hospital risk committee is comfortable with an unsupervised AI agent authorizing procedures, modifying treatment plans, or releasing clinical communications. The expectation is a deterministic gate: high-risk actions pause for human review before they execute.
  3. Audit trail for every AI decision. Every AI-assisted action that touches a patient, a clinical record, or a billing system must produce a traceable record with decision identity, the policies that were evaluated, the verdict, and a timestamp. This is not optional -- it is a HIPAA Security Rule requirement (§164.312(b): audit controls) and a prerequisite for any FDA submission involving AI.
  4. Data residency and access control. Healthcare data must stay within controlled boundaries. Self-hosted and In-VPC deployment options are not nice-to-haves -- they are requirements for organizations that cannot send PHI to a third-party SaaS.

Generic LLM proxies do not solve this. A proxy that rewrites prompts cannot enforce approval gates on multi-step clinical workflows. A logging layer that captures raw requests cannot produce the structured audit records a HIPAA audit or FDA pre-submission requires. A gateway that detects PII but cannot distinguish between a Social Security Number (format-validated against area/group/serial rules) and a random 9-digit string will either miss real violations or generate false positives that erode clinical team trust.

AxonFlow is purpose-built for this problem. It governs the entire agent execution lifecycle -- LLM calls, MCP connector invocations, multi-step workflows, and external tool use -- with policy enforcement, structured audit logging, PHI detection with checksum validation, and human-in-the-loop approval gates.

Use cases​

1. Prior authorization agent​

What the agent does: An AI agent receives a prior authorization request, pulls patient eligibility data from an EHR connector, checks clinical guidelines, and drafts an authorization decision for reviewer approval.

What could go wrong: The agent includes the patient's SSN or date of birth in a prompt to an external LLM for guideline lookup. Or it auto-approves a high-cost procedure without clinical review. Or the authorization decision is made but no audit record exists to demonstrate that governance was active at the time of the decision.

How AxonFlow prevents it:

  • PII detection catches SSNs (format-validated), dates of birth, email addresses, and phone numbers before they reach an LLM. The action is configurable per path: block, redact, warn, or log. See PII Detection.
  • HITL approval gates pause the authorization decision for human review. The require_approval policy action routes the step to a human approval queue where a clinical reviewer approves or rejects via the API. Unanswered requests auto-expire after 24 hours in Evaluation tier.
  • Audit logging produces a complete decision chain across every step: LLM calls, connector invocations, policy evaluations, and human approvals. Each record includes decision_id, verdict, evaluated policies, timestamp, and caller identity. See Audit Logging.

For a full walkthrough of this pattern with working code, see the Healthcare Prior Authorization with HITL tutorial.

2. Clinical decision support agent​

What the agent does: A clinical decision support (CDS) agent ingests lab results, imaging reports, and patient history via MCP connectors, then suggests differential diagnoses and treatment options to the treating clinician.

What could go wrong: The agent sends patient identifiers to a third-party LLM. Or it suggests a treatment without flagging drug interactions because the connector response containing medication history was forwarded to an unrelated downstream tool. Or the agent's suggestion is treated as a final order without physician review.

How AxonFlow prevents it:

  • MCP connector governance applies three-phase policy evaluation on every connector call: request-phase (before the call to the EHR), response-phase (on the returned patient data), and exfiltration-phase (if data flows to another tool or LLM). This prevents PHI from leaking across connector boundaries.
  • PII detection on every LLM-bound prompt catches SSNs (format-validated), DOBs, phone numbers, and email addresses before they leave your network.
  • HITL approval gates on the treatment-suggestion step ensure a physician reviews and signs off before any suggestion is acted upon. The approval queue API integrates with existing clinical workflow systems.
  • Audit logging records the full decision chain, establishing that governance was active and human oversight occurred at the point of clinical suggestion.
# Policy: require physician approval on treatment suggestions
name: clinical-treatment-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.step_type
    operator: eq
    value: treatment_suggestion
  - field: step_metadata.risk_level
    operator: in
    value: ["high", "critical"]

3. Patient communication copilot​

What the agent does: A patient communication copilot drafts appointment reminders, discharge instructions, test result summaries, and care plan follow-ups. It pulls patient data from EHR connectors and generates personalized messages for review before sending.

What could go wrong: The copilot includes the patient's diagnosis, medication list, or SSN in a message draft that passes through an external LLM. Or it sends a communication without nurse or care coordinator review. Or the SQL query used to pull patient data is vulnerable to injection.

How AxonFlow prevents it:

  • PII detection catches SSNs (format-validated), DOBs, email addresses, phone numbers, and credit card numbers (Luhn-validated) in every governed interaction. Configured via PII_ACTION (LLM path), GATEWAY_PII_ACTION (gateway path), and MCP_PII_ACTION (connector path). See PII Detection.
  • SQL injection scanning on all queries prevents prompt-injection attacks that attempt to extract patient data from backend databases. See SQL Injection Scanning.
  • HITL approval gates on the message-send step ensure a care coordinator reviews every outbound patient communication before delivery.
  • Cost controls prevent runaway generation loops from consuming excessive LLM budget. See Cost Management.
# Decision Mode: check a patient communication draft before it reaches the LLM
curl -s -X POST http://localhost:8080/api/v1/decide \
  -H "Content-Type: application/json" \
  -d '{
    "stage": "llm",
    "caller_identity": {
      "gateway_id": "patient-comms-gw",
      "tenant_id": "cardiology-dept"
    },
    "target": {
      "type": "llm",
      "model": "gpt-4o",
      "provider": "openai"
    },
    "query": "Draft a follow-up message for patient John Smith, DOB 03/15/1962, SSN 078-05-1120"
  }' | jq .
{
  "verdict": "deny",
  "decision_id": "b7e2c4a1-3f8d-4b2e-a1c5-9d8f7e6a5b3c",
  "trace_id": "2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e",
  "stage": "llm",
  "reasons": [
    "PHI detected: SSN pattern (format-validated)",
    "PHI detected: date of birth pattern"
  ],
  "obligations": [],
  "evaluated_policies": ["sys_pii_ssn", "sys_pii_dob"],
  "expires_at": "2026-05-25T12:05:00Z"
}

4. Medical coding automation agent​

What the agent does: A medical coding agent reviews clinical documentation (operative notes, discharge summaries, progress notes), extracts diagnoses and procedures, and suggests ICD-10 and CPT codes for billing submission.

What could go wrong: The agent sends full clinical narratives containing PHI to an external LLM for code extraction. Or it assigns a billing code without coder review, leading to upcoding or downcoding that triggers a payer audit. Or the coding decision has no audit trail linking the AI suggestion to the human reviewer who approved it.

How AxonFlow prevents it:

  • PII detection catches patient identifiers embedded in clinical narratives before they reach the LLM. The redact action strips identifiers while preserving the clinical content needed for accurate coding.
  • HITL approval gates on the code-submission step ensure a certified medical coder reviews every AI-suggested code before it enters the billing pipeline. This directly supports the human oversight requirement for billing accuracy.
  • Audit logging produces a structured record linking the AI suggestion, the policies that were evaluated, the human reviewer's decision, and the final submitted code. This audit chain is the evidence your compliance team needs when a payer questions a code assignment.
  • Evidence export (Evaluation and Enterprise) produces audit packages suitable for payer audits and internal compliance reviews. See Evidence Export.

5. Adverse event monitoring agent​

What the agent does: An adverse event monitoring agent watches clinical data feeds for potential safety signals -- unexpected lab values, medication reactions, device malfunctions -- and escalates flagged events to the safety team for investigation.

What could go wrong: The agent sends patient identifiers to an external LLM for event analysis. Or it fails silently when the LLM provider is down, leaving safety signals unmonitored. Or it escalates so aggressively that the safety team experiences alert fatigue and stops reviewing.

How AxonFlow prevents it:

  • PII detection catches patient identifiers (SSN format-validated, DOB, email, phone, credit card Luhn-validated) in event data before it reaches external LLMs.
  • Circuit breaker and kill switch (Enterprise) provide deterministic fallback when LLM providers are unavailable, ensuring the monitoring pipeline fails loud rather than failing silent. A safety monitoring system that silently stops monitoring is worse than no system at all.
  • Cost controls with warn and downgrade actions prevent runaway monitoring loops from exhausting LLM budgets. Budget limits are configurable per tenant. See Cost Management.
  • Decision Mode lets the safety platform call AxonFlow as a policy decision service without modifying existing monitoring infrastructure. See Decision Mode.

Regulatory mapping​

The table below maps specific regulatory requirements to shipped AxonFlow capabilities. AxonFlow provides the technical safeguards referenced in these regulations -- your organization's policies, BAAs, and administrative safeguards complete the compliance picture.

RequirementRegulationAxonFlow CapabilityDocs
Technical safeguards for ePHIHIPAA Security Rule §164.312PII detection (SSN format-validated, DOB, email, phone, credit card Luhn-validated) with configurable action per path: block / redact / warn / logPII Detection
Audit controlsHIPAA Security Rule §164.312(b)Multi-layer audit logging (Agent, Orchestrator, MCP, Workflow, Plan) with decision_id, verdict, evaluated policies, timestamp, identityAudit Logging
Access controls and authorizationHIPAA Security Rule §164.312(a)Tenant-scoped policy enforcement, caller identity on every decision, HITL approval gates for high-risk actionsHITL Approval Gates
Breach notification readinessHIPAA Breach Notification / HITECHStructured decision records with full PHI-interaction audit chain; evidence export for incident investigationEvidence Export
Data erasureGDPR / state privacy lawsPOST /api/v1/gdpr/delete endpoint for data subject erasure requestsCompliance Overview
AI/ML transparency and documentationFDA AI/ML SaMD GuidanceStructured decision records with evaluated policies, verdict rationale, and W3C traceparent correlation across governed layersDecision Mode
Post-market surveillance traceabilityEU MDRAudit logging with full decision chain across LLM calls, connector invocations, policy evaluations, and human approvalsAudit Logging
Human oversight for high-risk AIEU AI Act Art. 14require_approval action, HITL approval queue, 24h auto-expiry (Evaluation), API-driven approve/rejectHITL Approval Gates
AI system transparencyEU AI Act Art. 13Decision Mode returns verdict, decision_id, trace_id, evaluated_policies, reasons, and obligations for every policy checkDecision Mode

Reference architecture​

The diagram below shows AxonFlow in a typical healthcare stack. The pattern applies whether your AI agents are clinical tools, patient-facing copilots, or back-office billing automation.

Every interaction between an agent and an LLM provider passes through the Orchestrator, where policies are evaluated and PHI detection runs. Every interaction between an agent and a healthcare data source passes through the MCP Gateway, where three-phase policy evaluation (request, response, exfiltration) applies. High-risk clinical steps route to the HITL queue. All decisions produce structured audit records.

Decision Mode for healthcare infrastructure teams​

Large health systems and healthtech platforms typically run existing integration layers: an agent gateway that routes clinical AI traffic, an MCP or tool gateway that governs EHR connector access, and an LLM gateway that manages provider calls. Asking these teams to rearchitect their traffic flow through a new proxy is not realistic, especially in environments that have already passed security review.

Decision Mode solves this. AxonFlow runs as a standalone policy decision service. Each gateway makes one inline POST /api/v1/decide call per request, receives a verdict (allow, deny, or require_approval), and enforces it locally. AxonFlow is never on the traffic path -- it is consulted, not traversed. This is the PDP/PEP pattern used across the industry by policy engines like OPA, XACML, and Cedar.

Each gateway passes a stage identifier (llm, tool, or agent) and a caller_identity with its gateway_id and tenant_id. AxonFlow evaluates the same policy hierarchy for all three and returns a verdict with a trace_id that correlates decisions across layers using W3C traceparent headers. The result: one audit trail, one policy engine, enforcement at every layer, and zero changes to your existing gateway code beyond the HTTP call.

For the full API reference, request/response schemas, and curl examples, see Decision Mode. For guidance on when to use Decision Mode versus Gateway Mode, Proxy Mode, or Workflow Control Plane, see Choosing an Integration Mode.

Deployment options for healthcare​

Healthcare organizations have strict requirements around data residency, network isolation, and PHI handling. AxonFlow supports three deployment modes:

ModeDescriptionBest for
Self-HostedYou run AxonFlow on your own infrastructure. Source-available under BSL 1.1. Full control over data, network, and upgrades. PHI never leaves your environment.Health systems with on-premises requirements or air-gapped clinical networks
In-VPCAxonFlow runs inside your AWS VPC. No data leaves your network boundary. Managed by AxonFlow with your infrastructure controls.Health systems that want managed operations without PHI leaving their VPC
SaaSManaged by AxonFlow in us-east-1. Fastest path to production.Healthtech startups and non-clinical workflows that do not involve PHI

All three modes support the same feature set. For organizations handling PHI, Self-Hosted or In-VPC deployment is strongly recommended so that protected data never leaves your controlled environment. See Deployment Mode Matrix for the full comparison and Licensing for tier details.

Getting started​

Step 1: Run locally. Follow the Getting Started guide to run AxonFlow on your machine in under 5 minutes.

Step 2: Try the healthcare example. The Healthcare Example shows PII detection, HITL gates, and audit logging configured for clinical workflows.

Step 3: Follow the prior authorization tutorial. The Healthcare Prior Authorization with HITL tutorial walks through building a prior authorization agent with human approval gates and full audit trail.

Step 4: Map your regulatory requirements. Use the compliance pages for your regulatory context:

Step 5: Evaluate with real workloads. Request a free Evaluation License for self-hosted validation with HITL approval gates, evidence export, and higher limits. If you need enterprise features, direct rollout support, or managed deployment inside your VPC, apply for the Design Partner Program.

Last updated on