Setting up Fini for healthcare

Fini is HIPAA-compliant, with a BAA available, 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, 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.

​

Compliance pointers

Put the BAA in place before any PHI reaches the agent, including during pilots and Test Suite runs on real transcripts.

​

Recommended setup checklist

​

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, 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.
• Attribute Filters for location- or plan-specific content, for example state = California or plan = Medicare Advantage. See 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”: Add QA groups that follow the Guardrails (QA) pattern in Tags, 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. 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

Confidential attributes is a value-matching check: it blocks replies that contain the values of the attribute keys you select. It is not blanket detection of all personal or health data, and guardrails are not a fail-closed security boundary. See Guardrails.

​

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. 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).

​

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.

​

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. 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

Bind the Safety & boundaries judge (it covers declining medical advice), the Escalation behavior judge, and Tool use correctness for scheduling Actions. Use de-identified or synthetic scenarios where you can, and use Simulate rule execution or point Actions at a sandbox: Test Suite runs don’t dry-run your Actions, and Execute live actions calls your real APIs. See Test Suite.

​

11. Review in Inbox every week

Filter 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.

​

12. Put dashboard access behind SSO

Set up Okta SSO so dashboard access, and with it access to conversation transcripts, follows your Okta assignments.

​

Intents to automate first, and intents to escalate

​

What to measure

• AI Resolve Rate per rule in the 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