🏥 Healthcare

Deploy clinical AI agents with HIPAA-grade governance

Kynara gives healthcare organizations per-action policy enforcement, mandatory human approval for patient-data actions, and a tamper-evident audit log that satisfies HIPAA, HITRUST, SOC 2, and state-level privacy laws.

Book a demo Try the policy sandbox

HIPAA BAA (Enterprise) HITRUST CSF mapping SOC 2 Type II Minimum necessary access PHI access audit trail Break-glass JIT grants

The challenge

Healthcare AI agents face unique compliance requirements

HIPAA's minimum necessary standard, state privacy laws, and clinical safety requirements mean healthcare AI agents need stricter governance than any other industry. Kynara enforces this at the infrastructure level.

Without Kynara

✕ AI agent accesses full patient record when only a lab result was needed
✕ Clinical decision support agent makes a recommendation with no physician review
✕ PHI accessed from outside approved geographies or after hours
✕ No audit trail when a patient requests access logs under HIPAA
✕ Agent acting for a medical assistant can access data above their clearance

With Kynara

✓ Minimum-necessary enforcement: agents granted only the specific fields required
✓ Clinical recommendations require attending physician approval before delivery
✓ PHI access restricted to approved facilities and business hours by policy
✓ Every PHI access is hash-chained — complete audit log for HIPAA requests
✓ Agent permissions intersect with the clinician's own access level

Use cases

Built for clinical and healthcare AI workflows

🩺

Clinical decision support

Require attending physician approval before any AI-generated clinical recommendation reaches a patient. The agent pauses until a licensed clinician approves, with a mandatory justification logged.

📋

Patient record access

Enforce minimum-necessary: agents can only access the specific fields the workflow requires. A scheduling agent cannot read lab values; a billing agent cannot read diagnoses.

💊

Medication management

Block medication write actions outside approved hours and require pharmacist approval above defined dosage thresholds. Every interaction is logged for DEA and state board audits.

📊

Population health analytics

Allow de-identified population queries freely. Gate any query returning identifiable records behind MFA verification and a declared purpose string — logged in the audit chain.

🔐

EHR & FHIR integration agents

Agents connecting to Epic, Cerner, or FHIR APIs are scoped to exactly the resource types and patient populations they need. Cross-patient queries require explicit approval.

🚨

Emergency break-glass access

JIT grants enable emergency elevated access for on-call clinicians, with mandatory justification, automatic expiry, and full audit trail — satisfying HIPAA break-glass requirements.

Policy example

Enforcing minimum necessary in code

This policy allows a clinical AI agent to read basic demographic fields but requires attending physician approval before accessing diagnosis or medication records:

{
  "display_name": "PHI access — require approval for clinical data",
  "effect":       "require_approval",
  "priority":     100,
  "actions":      ["ehr.read"],
  "condition": {
    "op": "in",
    "args": [
      "ctx.resource.attrs.record_type",
      ["diagnosis", "medication", "lab_result", "imaging"]
    ]
  }
}

// Second policy: allow demographics freely
{
  "display_name": "PHI access — allow demographics",
  "effect":       "allow",
  "priority":     200,
  "actions":      ["ehr.read"],
  "condition": {
    "op": "eq",
    "args": ["ctx.resource.attrs.record_type", "demographics"]
  }
}

In your clinical AI agent:

from kynara_sdk import permission_required

@permission_required(
    "ehr.read",
    resource_arg="patient_id",
    resource_type="patient_record",
    resource_attrs=lambda patient_id, record_type: {
        "record_type": record_type,
        "patient_id": patient_id,
    }
)
def read_patient_record(patient_id: str, record_type: str):
    return ehr.get_record(patient_id, record_type)

# Diagnosis access → pauses for physician approval
# Demographics → proceeds immediately
# Every call → recorded in audit chain

HIPAA minimum necessary: The policy engine enforces that agents only access what the current workflow actually requires — not what they technically could access.

Compliance

HIPAA and HITRUST requirement mapping

HIPAA / HITRUST Requirement	Kynara Feature	Status
Minimum necessary standard (§164.514(d))	Per-action ABAC conditions on resource type and field	Built-in
Access controls (§164.312(a)(1))	RBAC roles + ABAC conditions, non-escalation guarantee	Built-in
Audit controls (§164.312(b))	SHA-256 hash-chained audit log, append-only, CSV export	Built-in
Person/entity authentication (§164.312(d))	JWT + API key auth, Okta/SAML/OIDC SSO	Built-in
Emergency access procedure (§164.312(a)(2)(ii))	JIT grants with justification + auto-expiry	Built-in
Workforce supervision of automated systems	require_approval as first-class policy outcome	Built-in
Business Associate Agreement (BAA)	HIPAA BAA available	Enterprise
Data residency (state laws)	Residency middleware, regional endpoint enforcement	Built-in

Deploy clinical AI agents with HIPAA-grade governance

Healthcare AI agents face unique compliance requirements

Built for clinical and healthcare AI workflows

Enforcing minimum necessary in code

HIPAA and HITRUST requirement mapping

Ready to deploy HIPAA-compliant AI agents?