Building HIPAA-safe automation for healthcare, in the open.

This is what it takes to automate a healthcare clinic without ever touching protected health information. Dental is the proving ground, because there the compliance is hardest. Below are the systems, the tools behind them, and what I'm learning getting each one to send safely.

Missed-call recovery · n8n00:00
1Detect missed call+0.3s
2Lookup patient · scrub PHI+0.8s
3Grace window for callback+60s
4Claude drafts SMS+60.4s
5Twilio sends · log to Postgres+60.9s
✓ Shadowed · BAA-eligible stack≈1 min · callback-aware
SD
Synthetic Dental
+1 (480) 555 · 0142
Simulated run
No PHI in the text · §164.502(b)
Synthetic data · shadow mode
Scroll
THE THING THAT STARTED THIS

Most of the AI tools being sold to dentists right now aren't even HIPAA compliant. That gap is the thing I started looking into.

AS OF · 2026-07-12

Right now you can try all four systems yourself in the demo below. They run in shadow mode on synthetic data, wired to real Twilio with the full compliance guardrails, and I'm tightening the details before the first clinic goes live. This is where the build actually is, today.

01About

Who's building this.

INTRO VIDEO · COMING A short walkthrough of what I'm building and why. Recording soon.

I'm Rainier. What I like is the hard kind of building, the systems with a lot of moving parts that still have to run on their own without anyone babysitting them. Getting something complicated to just work, quietly and reliably, is the part I never get tired of.

Healthcare pulled me in for the reason most people avoid it. It's unforgiving. A broken automation somewhere else is an annoyance you fix and forget. Here it's real rules, consent, actual patient records, and plenty of ways to get it wrong. The easy stuff is everywhere. I wanted the parts that genuinely have to be right.

Dental is where I'm proving it out. Independent practices lose people in small, quiet ways, a call nobody returns, a no-show nobody chases, someone who just stops booking. It's a real and messy place to find out whether the systems actually hold. But it's a starting line, not the whole race.

What I care about most tends to be what everyone skips, the compliance, how the data is handled, and what happens the moment something breaks. In this field that isn't a detail, it's the whole point, so I'd rather go slow and get it right. It's early still, and this is just me, building things meant to last.

4 systems built
0 notes posted
0 PHI ever touched

Follow along for what I'm building.

02Stack

The clinic stack.

Not four separate tools, one architecture. The four systems share a single safety spine: the opt-out list, the frequency cap, and the audit trail. They also hand off to each other. Everything runs on synthetic data in shadow mode, no claims past what's real. This is the first stack, built for small clinics, with more as the build grows.

Missed-call text-back

Every unanswered call gets a HIPAA-safe SMS within about a minute. Branded, no PHI, with a callback or booking link.

LOG
MISSED CALL · 11:42 AM Hi! This is Synthetic Dental. Sorry we missed you. Book here: sd.bk/x
PREVIEW

Smart appointment reminders

Two-touch reminder cadence (48h + 2h) with confirmation parsing and auto-reschedule offers. Tuned to each clinic's voice.

LOG
2:00 PM · Tue✓ confirmed
PREVIEW

Review collection on autopilot

Post-visit Google review request, sent once to eligible patients and never the same person twice in six months. One gentle follow-up, then it stops. It asks fewer people, more carefully.

LOG
PREVIEW

Dormant patient reactivation

Identifies patients overdue for recall (6, 12, 18 months) and runs a personalized reactivation cadence per cohort.

LOG
XXXre-engaged · sample
PREVIEW
TAKE IT WITH YOU

The whole stack, as a spec.

One page for the architecture and the shared safety spine, then one page per system. Generated from the same build data this page runs on, so it never drifts. No sign-up, no email.

Download the build spec PDF
See the dashboard →
03Dashboard

See it happen, not the node graph.

This is the dashboard I've been building. My take is that being able to watch the automations run, and see where one could break, beats staring at a complicated graph of nodes. One screen per view, real layout and real field names, on a sample clinic with synthetic data. Open it to step through all four screens.

The layout, the field names, and the gates are the real build. The clinic and the numbers are a synthetic sample, not a real practice. Real data only appears once a clinic goes live and the dashboard sits behind their own login.

04Built on

Built on.

Five tools. Each one picked for a specific reason, usually because it's BAA-eligible, open where it can be, and cheap enough to self-fund.

Tool What it does Notes
n8n Workflow engine. Self-hosted on AWS EC2. Runs every automation. no PHI stored
Twilio SMS infrastructure and phone numbers BAA-eligible
Anthropic Claude The AI that drafts every outbound message BAA-eligible
Google Workspace Email and reports. Any PHI email goes through a BAA-eligible account BAA-eligible
AWS Managed Postgres on RDS for patient records, encrypted at rest, in a BAA-eligible account BAA-eligible
Runs on the five tools above, always on
n8n Twilio Claude Google Workspace AWS
Speaks to Open Dental verified · the rest still being learned
Open Dentalverified Dentrixlearning Eaglesoftlearning Curve Dentallearning Denticonlearning Carestreamlearning tab32learning Dolphinlearning
05Process

How every system actually gets built.

The same four stages, every time. Whether it's missed-call recovery, reminders, reactivation, or reviews, the shape of the build is the same. Compliance is not the last step. It's the design constraint. Each stage carries its own safety breakers so nothing ships without them in place.

01 · Intake and discovery

Catch the event. Verify before any side effect.

Every system starts when something real happens. The event lands at a webhook, identifiers get normalized and hashed, the right practice config loads, duplicates are silently dropped. Nothing else runs until the event is confirmed and routed to the correct tenant.

Breakers active webhook idempotency key event dedup by source ID phone hash, HMAC SHA-256, peppered multi-tenant routing by practice
02 · Compliance gates

Run the gates. Fail closed.

Before any outbound action, the candidate runs through a unified safety check. Opt-out, frequency caps across all systems, per-practice cost cap, quiet hours, patient-history branch. If a check errors, the system fails closed: the default is opted out, not opted in. Same gate, every system, no exceptions.

Breakers active unified send-gate sub-workflow opt-out check spam-number list cross-system frequency cap per-practice daily cost cap quiet-hours deferral fail-closed defaults
03 · Generate, scrub, deliver

Draft, sanitize, send. Shadow mode covers new practices.

Anything the AI produces is constrained to a tight token budget. A regex scrubber strips PHI the draft might have introduced. Required language (STOP for SMS, opt-out for email) is injected at generation time and verified post-AI. A hardcoded PHI-safe fallback fires if the AI times out or returns malformed output. Shadow mode keeps the first batch of messages from any new practice from ever reaching a patient.

Breakers active PHI scrubber (regex) required-language injector AI fallback (hardcoded) shadow mode for new practices outbound message log dashboard event log
04 · Attribution and feedback

Match outcome to event. Dispute path open from day one.

Outcomes are tied back to the original event so the system can measure itself. Confirmed actions only count when they actually happen in the source of truth, not when a message was sent. The practice can dispute any attribution from the dashboard, and disputed ones are excluded from KPIs. PHI is purged at 90 days. The error handler catches every unhandled exception, scrubs PHI, and writes the incident to an error log.

Breakers active outcome-to-event matching PHI incident audit log 90-day nightly PHI purge unified error handler dispute path with RLS phone-hash pepper rotation
Two checkpoints I never skip on any system: a pre-deploy compliance audit across five dimensions (structure, secured, protected, solid, requirements), and a shadow-mode test before any real patient gets a message.
06Compliance

How I handle PHI and compliance.

The part most automation builders skip, and the part a healthcare team screens for. Compliance is the design constraint here, not the last step: every system scrubs PHI and honors opt-out and consent before anything sends, all on synthetic data in shadow mode. The practices I interview are HIPAA covered entities, so I document what they do under HHS Safe Harbor anonymization, and never request, accept, or store patient-identifying information.

Read the full protocol

Notes.

From inside the build. Some are my own observations. Some are quotes from dentists I've interviewed. Some are research worth flagging. New ones go up when there's something worth saying.

Loading notes...

08Try it

Try what I've built. Yourself.

One patient, one inbox. Fire a missed call, a reminder, a reactivation, or a review, and watch all four systems land in the same thread, sharing one opt-out and one frequency cap, with the compliance steps running behind every message. Synthetic data, shadow mode, no real PHI, no real numbers.

Open the full demo in its own tab
Behind the scenesSee how it works on the backend

One system, up close: the missed-call recovery workflow, node by node. A deterministic re-enactment of the teaching workflow, sanitized and safe to share. The same node sequence runs today in shadow mode, with real Twilio wiring and the full compliance guardrails, until a clinic goes live. The sanitized JSON lives on GitHub.

SIMULATED · teaching-missed-call.json · v1.1
TRY A SCENARIO A known patient, they get a text back to rebook.
workflow / missed-call.json Hover any node for details · click to jump
SMS Webhook 01 · TWILIO Verify 02 · HMAC Log Call 05 · POSTGRES Opt-Out 07 · TCPA GATE Claude 09 · DRAFT Sanitize 10 · PHI SCRUB Send 11 · TWILIO
· Idle
Idle · waiting for trigger
09Follow

Where the work shows up.

The build lives across a few channels. Each one carries something different. System walkthroughs on YouTube. The texture of building on Instagram. Written notes right here on the site. No mailing list. No follow-up sequences. Read what's useful, ignore the rest.

RSS for Notes → hello@rainierbuilds.com · research correspondence, I read everything