;
};
Fini (usefini.com) is HIPAA-compliant and BAA-eligible for enterprise customers, and setting it up for healthcare means configuring the agent so it sees and repeats as little protected health information (PHI) as each workflow needs: identify patients through a signed widget token, expose only the attributes a rule uses, never ask for health details a workflow doesn't need, keep PHI-bearing values out of replies with the **Confidential attributes** guardrail, and route clinical questions and PHI-sensitive requests to your team. Fini then resolves the administrative volume, such as scheduling, portal access, billing questions, and office information, while Reply Rules, Escalation Topics, and Guardrails keep clinical judgment with people.
This page is the configuration playbook. The recommendations below are configuration choices you make in your workspace, not a description of HIPAA obligations; have your privacy officer review them against your own policies. For what Fini does for healthcare as a product, see [usefini.com/industries/healthcare](https://www.usefini.com/industries/healthcare).
```mermaid theme={null}
---
title: Recommended configuration layers for healthcare
---
flowchart LR
BAA["BAA in place before any PHI reaches the agent"]
subgraph WHO["Who is asking"]
JWT["Identify logged-in patients server-signed JWT"]
ATTR["Minimum necessary attributes Visible to AI off by default"]
end
subgraph FIRST["Routing signals"]
TAGS["Clinical or PHI Intent tags"]
ET["Escalation Topics emergencies, self-harm, clinical"]
end
subgraph USE["What the agent can use"]
KN["Scoped knowledge no PHI in articles, review on"]
ACT["Least-privilege Actions read and write split"]
end
subgraph SEND["How the reply goes out"]
RB["Reply Rules Internal Comment, No Reply"]
GR["Guardrails Confidential attributes, no medical advice"]
end
PAT(["Patient"])
HUM(["Your team"])
subgraph AROUND["Around every change"]
TS["Test Suite before publish"]
INB["Weekly Inbox review"]
SSO["SSO for the dashboard"]
end
BAA --> WHO --> FIRST --> USE --> SEND --> PAT
ET -.->|"escalate"| HUM
RB -.->|"internal note"| HUM
classDef source fill:#F7F7F7,color:#131415,stroke:#E8E8E8
classDef agent fill:#131415,color:#FFFFFF,stroke:#131415,stroke-width:3px
classDef surface fill:#FFFFFF,color:#131415,stroke:#131415
classDef human fill:#C3EE5E,color:#131415,stroke:#131415,stroke-width:2px
class BAA,JWT,ATTR,TS,INB,SSO,PAT source
class TAGS,ET,KN,ACT agent
class RB,GR surface
class HUM human
```
## Compliance pointers
| Topic | Page |
| - | - |
| HIPAA compliance and putting a BAA in place | [HIPAA and BAAs](/en/security/hipaa) |
| Security program, certifications, and the Trust Center | [Security overview](/en/security/overview) |
| Encryption, data residency, and model training | [Data handling](/en/security/data-handling) |
| Controls for complaints and other regulated workflows | [Regulated industries: disputes and complaints](/en/security/regulated-industries-disputes-complaints) |
Request the BAA through your Fini account team; typical turnaround is about one week, and Fini's template or your own both work. Put it in place before any PHI reaches the agent, including during pilots and Test Suite runs on real transcripts.
Fini automatically masks sensitive data, including card numbers and health details, everywhere it stores conversation data (transcripts, Inbox and AI Steps traces). Fields you hide from the AI are also redacted in AI Steps. Don't ask patients for health details the workflow doesn't need. The Guardrails in step 6 are an extra layer on what the agent says.
## Recommended setup checklist
| # | Area | Recommended setting | Where |
| - | - | - | - |
| 1 | Minimum necessary attributes | Expose only fields a rule needs; **Visible to AI** off by default | [Attributes](/en/api-reference/attributes) |
| 2 | Knowledge scoping | Separate agents for patients and providers; folder **Attribute Filters** by plan, location, or state | [Articles](/en/knowledge/articles) |
| 3 | Sensitive-intent tags | A custom `Clinical or PHI Intent` group, plus QA groups such as *Guardrail \| PII Redaction* | [Tags](/en/configuration/tags) |
| 4 | Escalation Topics | Medical emergencies and self-harm (defaults), plus symptoms, results, medications, records requests | [Prompts](/en/configuration/prompts) |
| 5 | Reply Rules | **Internal Comment** for PHI-sensitive intents; **No Reply** when a human is assigned | [Reply Rules](/en/automations/reply-behavior) |
| 6 | Guardrails | **Confidential attributes**, **URL allowlist**, **Banned terms**, a no-medical-advice custom rule | [Guardrails](/en/configuration/guardrails) |
| 7 | Identity | Widget **Identify logged-in users** with a server-signed JWT | [Widget](/en/deploy/widget) |
| 8 | Actions and keys | Least-privilege credentials, read and write split | [Actions](/en/api-reference/actions), [API Keys](/en/deploy/api-keys) |
| 9 | Knowledge review | Keep review on; generate articles from conversations with **Suggest for Review** | [Review Queue](/en/knowledge/review) |
| 10 | Regression testing | A Test Suite collection run before every publish | [Test Suite](/en/testing/test-suite) |
| 11 | Review | Weekly Inbox review of guardrail hits and clinical tags | [Inbox](/en/testing/inbox) |
| 12 | Dashboard access | SSO for your team (Okta, Google, Slack or Microsoft Entra ID) | [Okta SSO](/en/sso-login) |
### 1. Expose the minimum necessary attributes
User Attributes are the main way patient data enters the agent's context. For each collected field, choose the switches deliberately:
* **Use in Rulebooks** only for fields a Check or Tool input needs, such as `patient_id` or `has_upcoming_appointment`.
* **Visible to AI** only for fields the agent must mention in a reply, such as the date and location of the next appointment. Leave it off for identifiers, diagnoses, medications, and insurance member numbers.
* **Don't collect what no rule uses.** Fields that never appear in a rule or reply don't belong in the Save From Response mapping.
See the switch-by-switch pattern in [End-to-end: cancellation flow](/en/walkthroughs/cancellation-flow), where the internal `customer_id` is used in rules but kept out of the model's view.
### 2. Scope knowledge
* **Separate agents for separate audiences.** A patient agent and a provider or partner agent should retrieve from different folders. See [Knowledge → Agent-specific scoping](/en/knowledge/overview#agent-specific-scoping).
* **Attribute Filters** for location- or plan-specific content, for example `state = California` or `plan = Medicare Advantage`. See [Articles → Attribute filters](/en/knowledge/articles#attribute-filters).
* **No PHI in articles.** Articles are shared across every conversation the agent handles. Write them as general policy and procedure, never with patient examples.
### 3. Tag clinical and PHI-sensitive intents
Create a custom group with **Tag Group available in Rulebooks** on and **Tag Selection** set to "Multiple tags can be selected":
| Tag | Example description (when to apply) |
| - | - |
| `symptoms_or_clinical` | The customer describes symptoms, asks whether something is normal, or asks for clinical guidance. |
| `results_or_diagnosis` | The customer asks about test results, a diagnosis, or what a result means. |
| `medication` | The customer asks about dosing, side effects, interactions, or changing a prescription. |
| `records_request` | The customer asks for, or asks to correct, their medical records. |
| `proxy_or_caregiver` | Someone is asking on behalf of another person (a parent, caregiver, or representative). |
| `complaint` | The customer asks for a complaint or grievance to be recorded or reviewed. |
Add QA groups that follow the Guardrails (QA) pattern in [Tags](/en/configuration/tags#custom-groups), such as *Guardrail | PII Redaction* (did the agent reveal personal data it shouldn't have?) and *Guardrail | Knowledge Restriction Compliance*, and assign them to every agent.
### 4. Escalate clinical questions in the Planning Prompt
The default *Escalation Topics* in the Planning Prompt's **Knowledge Search – Decision Logic** section already include medical emergencies and self-harm. Add your clinical patterns: symptoms, test results, medication questions, and requests on behalf of another person you can't verify. The planner routes matching conversations to a human and skips knowledge search. See [Prompts → Controlling when the agent escalates](/en/configuration/prompts).
For emergency language, add the exact wording your clinical team approves to **Main Guidelines → Predefined Replies**, so the agent uses it verbatim every time.
### 5. Route PHI-sensitive intents to an internal note
On **Rulebook → Reply Rules**:
* **Internal Comment:** `Clinical or PHI Intent In records_request, proxy_or_caregiver, complaint`. The agent drafts; your team verifies and sends.
* **No Reply:** `Human Agent Assigned Equals True`, so the agent never talks over a care coordinator or nurse.
Reply Rules hold only the final reply; Tools in an Intent Rule still run. Don't put Actions that disclose or change health records in a tree that Internal Comment is meant to hold.
### 6. Configure guardrails
| Check | Healthcare configuration |
| - | - |
| **Confidential attributes** | Patient identifiers, member numbers, and any clinical attribute your rules read. Replies that contain those values are rewritten or escalated. |
| **URL allowlist** | Your patient portal, scheduling, and website domains only. |
| **Banned terms** | Terms your compliance team prohibits, such as diagnostic language or outcome promises. |
| **Custom rule** | For example: "Fail if the reply offers a diagnosis, interprets a test result, or recommends a medication, dose, or treatment." Add pass and fail examples. |
| **Internal reasoning leak** | On. |
**Confidential attributes** is a value-matching check: it blocks replies that contain the values of the attribute keys you select. Guardrails are an extra layer on top of Fini's automatic masking, which masks sensitive data, including card numbers and health details, everywhere Fini stores conversation data. Guardrails are not a fail-closed security boundary. See [Guardrails](/en/configuration/guardrails) and [Data handling](/en/security/data-handling#masking-sensitive-data).
### 7. Identify patients before account-specific answers
Embed the widget in your authenticated patient portal and pass a JWT as `customerToken`, signed server-side with the widget's **Signing Key** (HS256). Include only the identifiers your attribute lookups need in `user_attributes`, and set `collectEmail` to `false` when your portal already verified the email. See [Widget → Identify logged-in users](/en/deploy/widget#identify-logged-in-users).
On unauthenticated channels, such as a public website chat or inbound email, limit the agent to general answers from Knowledge and to flows that send information only to contact details already on file (the pattern in [Fini for password reset and account access](/en/use-cases/password-reset)).
### 8. Give Actions least privilege
* **Credentials Fini uses to call your systems** (scheduling, practice management, billing) live in the Data Step Headers of each Attribute and Action. Issue dedicated service credentials: read-only for lookups, and write access limited to the specific endpoints a workflow needs, such as booking or cancelling an appointment.
* **Fini API keys your systems use to call Fini** are created under **Deploy → API Keys**. Uncheck **Write** for export jobs, use one key per system, and revoke on offboarding. Interaction exports contain conversation content, so treat the systems that receive them as in scope for PHI. See [API Keys](/en/deploy/api-keys).
### 9. Keep knowledge review on
Fini's background AI and Inbox feedback turn conversations into proposed articles. Leave the workspace "require review" setting on so user-created drafts pass a reviewer in the [Review Queue](/en/knowledge/review). When you generate an article from an Inbox conversation, choose **Suggest for Review** rather than **Live**, which makes the article available immediately. Check each conversation-derived draft for patient details before approving. Background AI drafts always land in review.
### 10. Run the Test Suite before every publish
Create test cases from conversations with de-identified or synthetic data where you can, and keep them in one collection. Put the shared checks in criteria groups: an AI judgement that the agent declines medical advice, an exact check for the handoff on clinical intents, and exact checks that scheduling Actions run. Test Suite uses recorded or mock Action responses and never calls your APIs; for live end-to-end checks, point Actions at a sandbox environment or run a controlled pilot. See [Test Suite](/en/testing/test-suite).
### 11. Review in Inbox every week
Filter [Inbox](/en/testing/inbox) by the **Guardrail** filter under **Quality**, by your clinical and QA tags, and by **Feedback: Thumbs down**. Open **AI Steps** to see each guardrail verdict and every Tool input and output. The **Guardrail** filter also matches failures recorded in replays of a conversation, so check the replay's AI Steps before attributing a hit to the live reply.
### 12. Put dashboard access behind SSO
Fini supports single sign-on with Okta, Google, Slack and Microsoft Entra ID, so dashboard access, and with it access to conversation transcripts, follows your identity provider. The setup guide covers Okta: [Okta SSO](/en/sso-login).
## Intents to automate first, and intents to escalate
| Automate first | Hand to your team |
| - | - |
| Booking, rescheduling, and cancelling appointments through your scheduling API | Symptoms, clinical questions, and anything urgent |
| Office hours, locations, directions, and what to bring | Test results and diagnoses |
| Patient portal login and access ([password reset pattern](/en/use-cases/password-reset)) | Medication, dosing, and prescription changes |
| Billing statements and payment questions ([billing pattern](/en/use-cases/billing-and-invoices)) | Records requests and corrections |
| Insurance accepted and coverage policy from Knowledge | Requests from caregivers or representatives you can't verify |
| Form and intake reminders | Complaints and grievances |
## What to measure
* **AI Resolve Rate** per rule in the [Analytics](/en/analytics) **Intent rule breakdown**, and per tag with the **Tags** filter. Report **Resolved by AI**; deflection rate also counts conversations **Waiting for Customer**.
* **Escalation reasons.** On clinical tags, escalation is the intended outcome. On administrative intents, **Missing API Access** and **Missing Knowledge** show where to add an Action or article next.
* **Guardrail activity** over **7d** and **30d**, especially the Confidential attributes and no-medical-advice policies. Open every hit.
* **CSAT and sentiment** on scheduling and portal-access intents.
## Related
The attribute, Action, rule, and Reply Rules pattern most scheduling flows follow.
Fini's HIPAA compliance and how to put a BAA in place.
Confidential attributes, custom rules, and guardrail activity.
Escalation Topics and Predefined Replies.
The Use in Rulebooks and Visible to AI switches.
The same checklist for financial services.
## Related topics
- [Setting up Fini for fintech and banking](/en/industry-setup/fintech.md)
- [Fini FAQ](/en/faq.md)
- [Fini Scout](/en/fini-scout.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.