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 PII and PHI-bearing identifiers before they reach 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 HIPAA certification or compliance by itself -- it provides technical safeguards your team can use within your covered entity or business associate framework.

The healthcare AI governance challenge​

Healthcare is not short of AI use cases. Public health agencies are increasingly deploying AI for epidemiological analysis, disease surveillance, and outbreak response -- workflows that aggregate population-level data but still carry patient identification risk at every step. 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, PII detection for PHI-bearing fields, 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.

6. Public health analysis copilot​

What the agent does: A public health analysis copilot ingests epidemiological datasets -- case reports, syndromic surveillance feeds, lab confirmation results, and demographic breakdowns -- and generates surveillance summaries, trend analyses, and outbreak situation reports for public health decision-makers.

What could go wrong: Population-level datasets still contain patient identifiers: names, dates of birth, addresses, and contact information embedded in case investigation records. The copilot sends these to an external LLM for trend analysis. Or it generates a public health recommendation (quarantine guidance, resource allocation, intervention thresholds) without epidemiologist review. Or the agency cannot demonstrate that AI-generated surveillance outputs were governed and reviewed when a FOIA request or legislative inquiry arrives.

How AxonFlow prevents it:

  • PII detection catches patient identifiers (SSN format-validated, DOB, email, phone) embedded in population datasets before they reach an LLM. The redact action strips identifiers while preserving the epidemiological data needed for trend analysis -- case counts, geographic distribution, demographic breakdowns, and temporal patterns remain intact.
  • HITL approval gates on public health recommendation steps ensure an epidemiologist reviews AI-generated surveillance conclusions, intervention recommendations, and outbreak assessments before they are published or acted upon. The require_approval policy routes recommendations to the approval queue where subject-matter experts approve, reject, or modify.
  • Audit logging produces a structured record of every AI-assisted analysis: the datasets consulted, the policies evaluated, the verdict at each step, and the identity of the reviewer who approved the final output. This audit chain is the evidence an agency needs for legislative oversight, FOIA requests, and internal quality reviews.
  • Decision Mode lets existing public health data platforms call AxonFlow as a policy decision service without rearchitecting surveillance pipelines. The analysis platform makes one POST /api/v1/decide call per governed step, receives a verdict, and enforces it locally. See Decision Mode.
# Policy: require epidemiologist approval on outbreak assessments
name: public-health-recommendation-approval
category: sensitive-data
action: require_approval
conditions:
  - field: step_metadata.step_type
    operator: in
    value: ["outbreak_assessment", "intervention_recommendation", "surveillance_summary"]
  - field: step_metadata.data_scope
    operator: eq
    value: population

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 lawsAudit evidence and PII controls that support customer-owned deletion workflows in clinical and administrative systems; built-in tenant erasure is limited to Community SaaS/plugin tenant recordsTrust 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 PII detection can run on PHI-bearing fields. 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.

Enterprise rollout playbook​

Healthcare teams rarely need a generic chatbot rollout. They need a production operating model for workflows that may touch PHI, clinical operations, patient communications, billing, or public health data. Use this sequence when moving from a pilot to a governed healthcare AI platform.

Capability map for healthcare​

Healthcare needAxonFlow capability
PHI-bearing field controls and redaction policyPII detection and policy management
Review before high-impact clinical, operational, or billing actionsHITL approval gates and WCP
Audit trail and exportable evidenceAudit logging and Evidence export
Provider and model operationsProvider routing and Choosing an Integration Mode
Controlled access to EHR, payer, support, or analytics systemsConnector capability matrix and MCP policy enforcement

Choose the runtime mode by workflow risk​

PatternBest fit
Proxy ModeHighest-governance flows where the AI interaction should be centrally mediated and audited consistently
Gateway ModeExisting clinical or operational apps that already own provider calls and need governance without replacing the runtime path
Decision ModeExisting EHR, FHIR, agent, or LLM gateways that can call AxonFlow as a policy decision service
WCPMulti-step workflows where a clinician, nurse, coder, safety team, or operations team must approve, complete, or replay steps

The important decision is not whether a workflow is "healthcare" in the abstract. It is whether the workflow can expose PHI, influence patient-facing action, affect billing, or produce evidence that security and compliance reviewers will later need.

Deployment and provider decisions​

Healthcare organizations often care about infrastructure posture as much as model quality.

Decision areaWhat to evaluate
SaaS versus In-VPCInternal privacy expectations, procurement constraints, business associate obligations, and platform ownership
Bedrock or another managed providerExisting cloud posture, regional controls, procurement approval, and model availability
Private or self-hosted inferenceWhether especially sensitive workflows require tighter runtime control
Telemetry and audit retentionWhether operational data, audit evidence, and provider metadata stay within the organization's required boundary

If a workload may process PHI, In-VPC or self-hosted deployment paired with customer-approved model and connector paths is usually the cleaner long-term posture.

Connector strategy for healthcare​

The connector question in healthcare is organizational as much as technical. Typical patterns include:

  • controlled access to EHR, EMR, FHIR, or internal clinical APIs
  • payer, authorization, claims, scheduling, or case-management systems
  • operational support data from ticketing or CRM-style systems
  • analytics and warehouse access for internal summarization or reporting
  • custom connectors for internal services that already encode access rules

Keep connector rollout coupled to governance review. A new connector can expand what an assistant can see or do as much as a new model can, so each connector should have an owner, an allowed-user scope, credential rotation expectations, and response-field rules before production use.

Approval and escalation patterns​

Healthcare teams often need more nuance than allow or block. Useful patterns include:

  • requiring review before AI-generated recommendations are operationalized
  • routing sensitive cases through HITL queues
  • using WCP for multi-step workflows where handoff and accountability matter
  • keeping auditable records of who approved, rejected, or changed a workflow path
  • defining an escalation path for safety signals, patient-facing messages, and billing decisions before rollout

These patterns are especially valuable when the AI system supports clinicians or operations staff but does not replace human judgment.

Practical rollout sequence​

  1. Start with an internal or lower-risk workflow such as documentation support, coding assistance, care-operations summarization, or support workflows that do not directly trigger clinical action.
  2. Standardize PHI-bearing data controls: which categories must be blocked, redacted, warned, or logged; which connectors may be used; and what audit evidence must be retained.
  3. Add structured review gates for workflows with higher downstream impact, including HITL steps, WCP review points, and explicit audit review.
  4. Expand to multi-team use only after provider management, connector ownership, shared policy ownership, and audit review practices hold up in the first workflow.

What good looks like: one platform team owns runtime operations, one security or compliance owner defines review expectations, application teams build on standardized provider and connector controls, and reviewers can answer who accessed what, under which policy posture, and with which approval trail.

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. Suitable for PHI workflows when paired with your own network and provider controls.Health systems with on-premises requirements or isolated clinical networks
In-VPCAxonFlow runs inside your AWS VPC. Managed by AxonFlow with your infrastructure controls. Suitable for deployments where PHI must stay inside a customer-controlled network boundary.Health systems that want managed operations without moving PHI to shared SaaS
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 protected data can remain inside the organization's controlled environment and provider path. 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.

Assessment Path​

Use this page as a domain map, then validate the runtime with the same rollout path:

Last updated on