Automate Patient Recall & Reactivation for Dental Practices with n8n + Claude HIPAA-Aware Step-by-Step Guide

2. System Architecture

Eight components, each replaceable, each in scope of the practice’s HIPAA risk analysis. The orchestration layer is self-hosted n8n on a VM that lives inside the practice’s network or in a HIPAA-eligible cloud account, so PHI never traverses a third-party automation SaaS. Postgres holds the patient feature store, the message log, the audit trail and the consent ledger.

The stack

Cost estimate (3,800-patient practice, ~900 outbound recall messages/month)

Even one recovered $1,400 treatment-plan close per month covers the full stack with $1,200 left over. The ROI math is so favorable that the actual decision criterion is rarely cost; it is whether the practice trusts the workflow to handle PHI without creating a compliance incident. The same orchestration spine fits into our broader AI automation services.

The pipeline starts with a deterministic, idempotent nightly pull at 1:30 AM local time, when the practice management system is quiet and the front-desk computers are off. Open Dental publishes a FHIR R4 endpoint (since v22) which gives a clean, vendor-stable contract. Dentrix exposes a more limited Developer Program API; for older Dentrix installs, a read-only SQL Server replica is the most reliable option.

Data sources

• Patient demographics: first/last name, preferred name, mobile phone, primary email, communication preferences, language preference, opt-out flags.
• Appointment history: last completed visit, last hygiene visit, last hygienist of record, last provider, no-show count in last 24 months.
• Treatment plans: any plan with status “presented” or “accepted, not scheduled” — procedure code, tooth number, presented date, presenting provider, fee.
• Insurance: primary carrier, plan year end, remaining annual maximum (if available — most carriers publish via real-time eligibility).
• Recall: next recall due date as scheduled in the PMS, recall type (perio, prophy, child).

n8n cron + FHIR pull

A single Cron node fires at 01:30 local. A Function node computes the lookback window. A loop of HTTP Request nodes paginates through Open Dental’s FHIR Patient and Appointment resources, normalizing into a flat row schema before insert into Postgres. Every PHI field stays inside the practice’s network or HIPAA-eligible VPC.

{
  "method": "GET",
  "url": "https://opendental.localnet/fhir/v2/Patient",
  "qs": {
    "_lastUpdated": "ge{{ $json.windowStart }}",
    "_count": "200",
    "_sort": "_lastUpdated"
  },
  "headers": {
    "Authorization": "Bearer {{ $credentials.opendental.token }}",
    "Accept": "application/fhir+json"
  },
  "options": {
    "timeout": 15000,
    "retry": { "attempts": 3, "backoffMs": 500 }
  }
}

Patient feature snapshot table

CREATE TABLE patient_snapshot (
  patient_id              text PRIMARY KEY,
  pms_source              text NOT NULL CHECK (pms_source IN ('open_dental','dentrix')),
  preferred_name_enc      bytea,        -- pgcrypto pgp_sym_encrypt
  mobile_e164_enc         bytea,
  email_enc               bytea,
  language_pref           text DEFAULT 'en',
  consent_sms             boolean DEFAULT false,
  consent_recorded_at     timestamptz,
  opt_out_at              timestamptz,
  last_visit_date         date,
  last_hygiene_date       date,
  last_hygienist_name     text,
  last_provider_name      text,
  no_show_count_24mo      int DEFAULT 0,
  open_tx_plan            jsonb,        -- procedures + fees + presented_at
  insurance_year_end      date,
  remaining_annual_max    numeric(8,2),
  recall_due_date         date,
  snapshot_taken_at       timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX idx_snapshot_recall_due ON patient_snapshot (recall_due_date)
  WHERE opt_out_at IS NULL AND consent_sms = true;

A deterministic SQL query can identify “patients overdue for hygiene” trivially. The harder problem is sorting that list into cohorts that justify a different message, a different time of day to send, and a different escalation path. Claude reads each patient’s snapshot row, applies the practice’s documented recall policy, and returns a structured classification with a one-sentence rationale. This pattern shows up in our adjacent work for medical clinics and healthcare automations.

The 4 segmentation cohorts

Claude segmentation system prompt

The prompt encodes the practice’s actual recall policy. Tunable per practice by editing the policy block. PHI in the user message is the minimum necessary — only the fields the prompt actually consumes.

You are a recall segmentation engine for a US general dentistry
practice operating under HIPAA.

PRACTICE RECALL POLICY:
- Hygiene cadence: 6 months for healthy adults, 3-4 months for
  active perio maintenance, 12 months for medically compromised
  with documented exception.
- Treatment-plan reactivation window: 30-180 days post-presentation.
  After 180 days, plan must be re-discussed with the dentist.
- High-value threshold: open plan total >= $500.
- High-no-show threshold: 2+ no-shows in trailing 24 months.

INPUT: a single patient_snapshot JSON object containing minimum
necessary PHI - preferred_name (do not echo back), last_hygiene_date,
last_hygienist_name, no_show_count_24mo, open_tx_plan summary,
insurance_year_end, remaining_annual_max, recall_due_date.

DISQUALIFY signals (do not classify into any send cohort):
- consent_sms = false
- opt_out_at is not null
- patient is a minor without parent on file
- mobile_e164 missing or invalid

OUTPUT - strict JSON, no prose, no PHI echoed:
{
  "cohort": "overdue_6mo" | "overdue_12mo_plus" | "tx_plan_pending"
          | "high_value_no_show" | "skip",
  "send_channel": "sms" | "front_desk_call" | "none",
  "priority": 1-5,
  "rationale": "one sentence, no patient name, no phone",
  "year_end_lever_applies": true | false
}

Rules:
- if no_show_count_24mo >= 2 AND open plan total >= 500,
  cohort = "high_value_no_show", send_channel = "front_desk_call".
- if multiple cohorts apply, choose the one with highest expected
  reactivation impact (tx_plan_pending > overdue_12mo_plus >
  overdue_6mo).
- year_end_lever_applies = true only if remaining_annual_max > 0
  AND insurance_year_end within 75 days.
- never invent fields not in the input.

Expected output for a typical row

{
  "cohort": "tx_plan_pending",
  "send_channel": "sms",
  "priority": 4,
  "rationale": "Plan presented 47 days ago, ~$1,840 of insurance benefit unused, plan year ends in 61 days.",
  "year_end_lever_applies": true
}

A second Claude call drafts the actual message. The drafting prompt is constrained heavily — message length budget, no medical advice, no hard sell, no fee quotes, no insurance benefit numbers in the message body (the patient sees those in the practice portal, not in SMS), and a hard requirement to include the practice name and an opt-out path. The personalization comes from referencing the last hygienist by first name, the last visit timing in plain English, and the procedure type by lay term, not the CDT code.

Drafting constraints by cohort

Drafting prompt

You draft SMS recall messages for {{ practice_name }}, a US
general dentistry practice operating under HIPAA.

ABSOLUTE RULES:
1. Never include diagnosis, procedure CDT codes, fee amounts,
   insurance balances, dental conditions, or anything that would
   constitute PHI beyond the patient's first name.
2. Always include the practice name.
3. Always include an opt-out instruction: "Reply STOP to opt out".
4. Maximum 280 characters total. Hard cap.
5. No emojis except a single optional smile or wave at the end.
6. Use the patient's preferred first name once, never the last name.
7. Reference the last hygienist by first name only and only if
   provided in the input.
8. Use lay language for procedures: "the crown we discussed",
   "your cleaning visit", never "D2740" or "perio maintenance".
9. Sign off with a real human name from the practice (provided in
   input) - never "the team" and never "automated message".

INPUT contains:
- patient first name (preferred), cohort, last hygiene timing
  in plain English ("about 9 months ago"), last hygienist first
  name (optional), procedure lay term (optional), two specific
  slot offers (cohort-dependent), practice phone, signer name.

OUTPUT - strict JSON:
{
  "message": "the SMS body, complete and sendable",
  "char_count": integer,
  "phi_audit": "none" | "review_required",
  "tone": "friendly" | "warm" | "gentle"
}

If the message would require any PHI beyond first name to be
useful, return phi_audit = "review_required" and a generic
message that asks the patient to call.

Sample outputs (PHI-redacted in this guide)

// overdue_6mo
"Hi Sarah, it's Maple Family Dental. Your cleaning with Jess
is due. We have Tue 11:30 or Thu 2:15 next week - reply with
the one that works, or call (614) 555-0142. Reply STOP to opt
out. - Megan, Front Desk"

// tx_plan_pending (year_end_lever_applies = true)
"Hi James, Maple Family Dental here. The crown we talked about
is still on your chart. We have a slot Wed 10:30 next week if
you'd like to wrap it up before your benefits reset. Reply YES
to confirm or call (614) 555-0142. STOP to opt out. - Megan"

Standard Twilio is not HIPAA-eligible without specific configuration and a signed BAA, and even then it requires field-level care about what enters the message body. The cleanest path is a vendor explicitly built for healthcare messaging — TigerConnect for in-network secure messaging or RingCentral with a healthcare BAA for standard SMS to patient mobile phones. Either way, three rules drive the integration: BAA in place, message body free of any PHI beyond first name, and every send written to the audit log before the API call returns.

Send-time guardrails

1. Quiet hours: never send between 21:00 and 09:00 in the patient’s local timezone, even if the workflow runs at 02:00 — queue and release at the local window opening.
2. Day-of-week throttle: Tuesday/Wednesday/Thursday default; Monday and Friday are noisy and convert worse.
3. Daily volume cap: 250 outbound recalls per day per practice number. Caps protect the carrier reputation score and prevent runaway sends if the segmenter misbehaves.
4. Pre-send opt-out check: re-read the consent ledger inside the same transaction that issues the API call. Stale snapshots cause TCPA exposure.
5. Idempotency key: the n8n workflow run ID + patient ID. Replay-safe sends are non-negotiable.

RingCentral SMS API call

{
  "method": "POST",
  "url": "https://platform.ringcentral.com/restapi/v1.0/account/~/extension/~/sms",
  "headers": {
    "Authorization": "Bearer {{ $credentials.ringcentral.token }}",
    "Content-Type": "application/json",
    "X-Idempotency-Key": "{{ $execution.id }}-{{ $json.patient_id }}"
  },
  "body": {
    "from": { "phoneNumber": "+16145550142" },
    "to":   [ { "phoneNumber": "{{ $json.mobile_e164 }}" } ],
    "text": "{{ $json.message }}"
  },
  "options": {
    "timeout": 8000,
    "retry": { "attempts": 2, "backoffMs": 1000 }
  }
}

Audit log write — same transaction as the API call

INSERT INTO message_log (
  message_id, patient_id, direction, channel, vendor,
  cohort, message_body_enc, char_count,
  phi_audit_flag, segment_rationale,
  consent_state_at_send, sent_at, vendor_message_id
) VALUES (
  gen_random_uuid(), $1, 'outbound', 'sms', 'ringcentral',
  $2, pgp_sym_encrypt($3, current_setting('app.col_key')), $4,
  $5, $6,
  $7, now(), $8
)
RETURNING message_id;
-- Trigger app_audit_after_insert writes a tamper-evident row to
-- the immutable audit_trail table partitioned by year for 6yr
-- retention per HIPAA section 164.530(j).

A recall SMS has three meaningful response shapes: a booking intent (“YES Tuesday works”), a non-booking question (“Can I bring my husband too?”), or an opt-out signal (“STOP” / “remove me”). The reply parser is a Claude Haiku call — cheap, fast, well-suited to short-text classification with high confidence — that returns a structured intent plus the slot the patient committed to, if any. Anything ambiguous routes to the front-desk handoff queue rather than guessing.

Reply intent classifier prompt

You classify SMS replies to a dental recall message. The original
message offered up to two appointment slots in plain English
(e.g., "Tue 11:30" and "Thu 2:15") and a phone number.

INPUT contains:
- the original outbound message
- the patient's reply text
- the two slot strings that were offered (if any)

OUTPUT - strict JSON, no prose:
{
  "intent": "book" | "question" | "opt_out" | "reschedule_request"
          | "wrong_number" | "ambiguous",
  "selected_slot": "slot_a" | "slot_b" | "neither" | null,
  "needs_human": true | false,
  "opt_out_phrase_detected": true | false,
  "confidence": 0.0-1.0
}

CRITICAL:
- Detect any STOP / UNSUBSCRIBE / REMOVE / DON'T TEXT ME variant
  with high recall. Set opt_out_phrase_detected = true and
  intent = "opt_out". TCPA non-negotiable.
- Any reply that asks a clinical question (pain, symptoms,
  medication, bleeding, swelling) is "question" with
  needs_human = true regardless of confidence.
- Confidence below 0.75 -> needs_human = true.
- Never invent a slot the patient did not name.

Routing matrix from parser intent

When the parser returns intent = "book" with high confidence, the workflow re-checks slot availability against the live schedule (the offered slot may have been claimed by another booking in the interval) and creates the appointment via the Open Dental Appointment FHIR resource. If the slot is no longer available, the workflow falls back to drafting a 3-alternative response rather than booking the patient blind into something else.

Slot revalidation query

{
  "method": "GET",
  "url": "https://opendental.localnet/fhir/v2/Slot",
  "qs": {
    "schedule": "{{ $json.hygienist_schedule_ref }}",
    "start_ge": "{{ $json.slot_start_iso }}",
    "start_lt": "{{ $json.slot_end_iso }}",
    "status": "free"
  },
  "headers": {
    "Authorization": "Bearer {{ $credentials.opendental.token }}"
  }
}

Appointment create call

{
  "method": "POST",
  "url": "https://opendental.localnet/fhir/v2/Appointment",
  "headers": {
    "Authorization": "Bearer {{ $credentials.opendental.token }}",
    "Content-Type": "application/fhir+json",
    "X-Idempotency-Key": "{{ $execution.id }}-{{ $json.patient_id }}-book"
  },
  "body": {
    "resourceType": "Appointment",
    "status": "booked",
    "appointmentType": {
      "coding": [{
        "system": "http://opendental.com/codes/apt-type",
        "code": "PROPHY_ADULT",
        "display": "Adult Prophy + Exam"
      }]
    },
    "start": "{{ $json.slot_start_iso }}",
    "end":   "{{ $json.slot_end_iso }}",
    "participant": [
      { "actor": { "reference": "Patient/{{ $json.patient_id }}" },
        "status": "accepted" },
      { "actor": { "reference": "Practitioner/{{ $json.hygienist_ref }}" },
        "status": "accepted" }
    ],
    "comment": "Booked via recall workflow. Source: SMS reply."
  }
}

Confirmation SMS draft (returns to step 4 send path)

Once the Appointment resource creates with HTTP 201, the workflow drafts a short confirmation SMS, runs it through the same PHI guardrails, and sends. The confirmation includes the date, time, hygienist first name, parking note (a short practice-defined string from a config table), and a “reply C to cancel” path so the patient never has to call to reschedule. The cancel handler is the same intent classifier in reverse.

Around 18% of replies will need a human — clinical questions, pre-op anxiety, billing disputes, “can I move it because my mom is in town.” The Slack handoff is the seam between the workflow and the office manager. Critical: the Slack message contains zero PHI in the channel itself. The patient name is replaced with a token; clicking the token opens the practice’s internal mini-app where the full thread is rendered, server-side, behind SSO.

Slack alert payload (PHI-redacted)

{
  "channel": "#recall-handoff",
  "blocks": [
    {
      "type": "header",
      "text": { "type": "plain_text",
                "text": ":speech_balloon: Patient question - needs reply" }
    },
    {
      "type": "section",
      "fields": [
        { "type": "mrkdwn",
          "text": "*Patient*n#PT-{{ tokenized_id }}" },
        { "type": "mrkdwn",
          "text": "*Cohort*n{{ cohort }}" },
        { "type": "mrkdwn",
          "text": "*Confidence*n{{ classifier_confidence }}" },
        { "type": "mrkdwn",
          "text": "*SLA*nReply within 1 business hour" }
      ]
    },
    {
      "type": "section",
      "text": { "type": "mrkdwn",
                "text": "Classifier intent: *question* - clinical-language detected. Workflow paused on this thread until front desk replies." }
    },
    {
      "type": "actions",
      "elements": [
        { "type": "button",
          "text": { "type": "plain_text", "text": "Open thread" },
          "style": "primary",
          "url": "https://practice-intranet.local/recall/thread/{{ tokenized_id }}" }
      ]
    }
  ]
}

Pause the workflow on the thread until human reply

When a thread escalates to handoff, the n8n workflow flips a human_in_loop = true flag on the conversation row. Subsequent inbound SMS on that thread bypass the auto-classifier and surface in the same Slack channel as a follow-up message. The human stays in the loop until they explicitly close the thread from the intranet view, at which point the workflow can resume — useful when the patient comes back two weeks later asking to reschedule.

HIPAA’s documentation requirement under section 164.530(j) is six years from the date of creation or last effect. The audit log is not optional and not something to bolt on later — it is the practice’s single most defensible artifact in any breach investigation. Every event the workflow takes (segmentation result, prompt hash, message sent, reply received, slot booked, opt-out honored, BAA-bearer touched) writes one row to an append-only audit table.

Audit trail schema

CREATE TABLE audit_trail (
  audit_id        bigserial PRIMARY KEY,
  event_at        timestamptz NOT NULL DEFAULT now(),
  event_type      text NOT NULL,
  patient_id      text,
  actor           text NOT NULL,        -- 'workflow:n8n_run_' or 'human:'
  workflow_run_id text,
  prompt_hash     text,                 -- sha256 of system prompt at run time
  model_id        text,                 -- 'claude-sonnet-4-5' / 'haiku'
  vendor_call_id  text,
  payload_summary jsonb,                -- non-PHI summary only
  source_ip       inet,
  user_agent      text
) PARTITION BY RANGE (event_at);

REVOKE UPDATE, DELETE ON audit_trail FROM PUBLIC;
GRANT  INSERT, SELECT ON audit_trail TO recall_app;
GRANT  DELETE         ON audit_trail TO retention_purger;
-- retention_purger runs once per quarter; deletes only rows
-- older than 6 years and only with a corresponding deletion
-- record written to the long-term archive.

Cold archive to S3 with Object Lock

After 90 days, audit rows ship nightly to a HIPAA-eligible S3 bucket with Object Lock in compliance mode and the bucket policy denying delete by anyone, including the root account, until the 6-year retention expires. Encryption at rest with KMS, access logging on, MFA-delete on the bucket itself. The local Postgres copy stays online for the most recent 18 months for fast investigation; older queries hit the archive.

HIPAA, TCPA & Privacy by Design

Three regulatory regimes touch this workflow: HIPAA (PHI handling), TCPA (consent for autodialed messages to mobile phones), and state-level analogs like CMIA in California or SHIELD in New York. Treat compliance as a design constraint baked into every step, not a checklist at the end.

HIPAA Privacy Rule — minimum necessary in practice

The minimum necessary standard says you disclose only the PHI required for the purpose. In this workflow that means: Claude never receives full date of birth, full address, full clinical history, x-rays, or any non-essential identifier. The segmenter sees a feature row that is enough to classify, not a profile that lets it reconstruct a patient. The drafter sees first name, last hygienist first name, plain-English visit timing, lay procedure term, and slot strings — nothing more.

BAAs you must execute before any send

• Anthropic: enterprise tier with executed BAA and zero-data-retention turned on for the API key used by the workflow.
• SMS vendor: RingCentral healthcare BAA or TigerConnect BAA. Confirm in writing that PHI in message bodies is in scope.
• Cloud host: AWS, GCP or Azure HIPAA-eligible account with executed BAA before any PHI lands in compute or storage.
• Monitoring: Grafana Cloud / Datadog HIPAA tier; PHI must be filtered at the n8n boundary before logs ship.
• Backup: S3 with BAA in place, Object Lock for retention.

TCPA — consent and opt-out

Recall SMS to a mobile phone is a covered call under TCPA. The patient must have given prior express consent — usually as a checkbox on the new-patient form, captured in the PMS as a boolean and synced to the snapshot table. Every outbound message contains “Reply STOP to opt out”. An opt-out is honored within seconds, recorded in the consent ledger, and propagated back into the PMS so the front desk doesn’t accidentally send another reminder from a different surface. Statutory damages for TCPA violations start at $500 per message; this is the part of the system you do not optimize for cost.

Encryption posture

• In transit: TLS 1.2+ on every external API call; mTLS on the link between n8n and the PMS API where the PMS supports it.
• At rest: AES-256 disk encryption on the VM volume + column-level encryption with pgcrypto on PHI fields (name, mobile, email).
• Key management: AWS KMS or GCP Cloud KMS with key rotation every 365 days. The application key is never written to a developer’s laptop.
• Backups: encrypted at rest, separate KMS key, restore-tested quarterly.

Breach response

A documented runbook is part of the deliverable. The first action on suspected breach is to revoke the n8n service account credentials and the Anthropic API key, freeze the workflow, snapshot the audit trail to read-only storage, and convene the breach assessment within 24 hours. The 60-day notification clock under HIPAA’s Breach Notification Rule starts on discovery, not on confirmation; over-prepare on day one and you’ll be fine on day twenty.

Common Failures & Fixes

Three failure modes recur across deployments. All three are cheap to design around on day one and expensive to retrofit after a regulator has questions.

Failure 1: Stale phone numbers triggering wrong-number sends

Symptom: A patient’s number changed two years ago. The new owner of that line keeps getting reminders for someone else’s hygiene visit. They eventually forward the screenshot to their state Attorney General. Statutory exposure plus reputation damage.

Fix: Run a CNAM/HLR lookup on every mobile number in the snapshot before any first send to that number, and again every 12 months. Mark numbers that fail validation as do_not_send until the front desk verifies on the patient’s next visit. The classifier’s wrong_number intent feeds into the same disposition.

Failure 2: Drafting prompt regressions that leak PHI

Symptom: A well-meaning prompt edit (“be more specific”) causes the drafter to start including procedure descriptions or fee numbers in message bodies. By the time anyone notices, 200 messages went out.

Fix: A second-stage PHI scanner runs against every drafted message before send. Regex + a tiny Haiku check that returns phi_audit. Any flagged message is held for human review rather than sent. Drafting prompts live in git with a CI-gated test suite — 50 known-good patient profiles, 50 known-tricky ones, every PR runs the suite.

Failure 3: Quiet-hours violation from server timezone drift

Symptom: The server runs UTC but the practice is in Phoenix (no DST). A patch to the cron expression accidentally fires the send queue at 02:00 local. Twenty patients receive a recall SMS in the middle of the night before the on-call engineer notices.

Fix: Quiet-hours enforcement happens at the per-message level, not the workflow level. Each row carries the patient’s timezone and the send node consults the patient’s local clock at decision time, not the workflow’s. A separate watchdog asserts no send timestamps exist outside 09:00–21:00 local in the last 24 hours; alert on the first violation.

Measured Results — 90 Days In

Numbers from a real implementation at a 4-chair general dentistry practice (3,800 active patients, 2 hygienists, 2 GPs) after the first full quarter on the new pipeline. No change in patient base during the test period — every gain comes from prioritization, message quality and speed of follow-up.

The headline metric inside the practice was the front-desk experience: the team stopped dreading recall day. Outbound calls dropped from ~150 per week to fewer than 30 (the genuinely complex cases), and the calls that remained were warmer because the patient had already been touched by a friendly SMS. Production from the recall channel went from a noisy, hard-to-attribute trickle to a line item the practice could plan against.

Implementation Timeline & Cost

FAQ