← Back to Blog

Building an n8n Intake Router for Your Health Practice

A step-by-step guide to building the intake routing workflow that handles waitlist signups, support requests, feature feedback, and clinical inquiries, and how to treat the clinical branch as PHI from the first field.

This article is for educational and informational purposes only. It does not constitute legal, medical, or professional advice. Consult qualified professionals for guidance specific to your situation.

A note before we start. I am a pharmacist, not an attorney, and this is general information about how I built a system for my own practice, not legal advice about yours. Whether you are a covered entity, what counts as PHI in your setup, and which agreements you need are all specific to your arrangement. Have your own counsel or compliance advisor review anything you build from this.

Why n8n for Healthcare Intake

n8n is a self-hosted workflow automation tool that gives you control over your data flows. Unlike Zapier or Make, n8n runs on infrastructure you rent and administer, so your webhook data is not passing through a vendor's shared processing layer. Be clear about what self-hosting does not do. The company renting you the server is still handling your data, and HHS guidance treats a cloud provider that stores or transmits ePHI as a business associate that needs a signed BAA, even when it cannot read the data. Self-hosting narrows the list of companies you need agreements with. It does not empty it.

For healthcare-adjacent applications, this matters. Three of these four intake types can be kept out of PHI territory by design. The clinical inquiry branch cannot, so plan for it to carry PHI and put it behind a BAA. Data minimization is good practice on every branch regardless. The fewer third-party servers your data touches, the lower your exposure.

n8n is also free for self-hosted use. The Docker setup takes about 20 minutes and runs on any cloud provider or even a local machine.

The Four-Submission Architecture

The intake system built for Hunters Holistic Health handles four distinct submission types, each routed to its own Google Sheet tab:

Early Access (Waitlist): Name, email, interests, background, biggest challenge. Routed to the Early Access tab. Email alert contains name, email, and timestamp only.

Support Requests: Name, email, reason for contact (dropdown), preferred contact method, optional message. Routed to the Support Requests tab. Email alert contains name, email, category, and timestamp.

Feature Requests: Feature description, category, importance rating, anonymous flag. Routed to the Feature Requests tab. No email alert (reviewed on a schedule).

Clinical Inquiries: Name, email, phone, service interest, brief description. Routed to the Clinical Interest tab. Assume the description field will contain clinical detail. A notice asking people not to describe symptoms is a request, not a control, and people describe symptoms anyway. Design the branch as if every submission contains PHI, because in practice some of them will. Email alert contains name, email, service interest, and timestamp. No description text in the alert.

Where the Data Piles Up That Nobody Warns You About

The alert email is not the only copy. Three places quietly accumulate submissions, and you have to handle all three.

First, n8n execution history. n8n saves execution data by default on both success and error, and keeps it for 336 hours, which is fourteen days. That is the entire webhook payload, description field included, sitting in your n8n database and visible to anyone who can open the instance. Set EXECUTIONS_DATA_SAVE_ON_SUCCESS to none for the clinical branch, tighten EXECUTIONS_DATA_MAX_AGE, and know that the built in execution data redaction feature is Enterprise only on both Cloud and self hosted.

Second, the Google Sheet. The Clinical Interest tab is a PHI store, not a spreadsheet. It needs restricted sharing, no link access, no personal accounts, and it sits under the Workspace BAA or it does not exist.

Third, sent mail. Every alert you sent is still in the Gmail sent folder, and every alert names a person who contacted a health practice. Set a retention rule.

The Security Rule expects you to record and examine activity in systems that hold ePHI. You cannot do that for stores you never counted.

The n8n Workflow Structure

The workflow uses a single webhook trigger that receives all four submission types. A Switch node routes each submission to the appropriate branch based on the submissionType field.

Each branch has three nodes:

1. A Google Sheets Append node that adds the row to the correct tab

2. A Gmail Send node that sends the alert email (for submission types that require it)

3. A Respond to Webhook node that returns a 200 OK response

The webhook URL is stored as an environment variable in the app (VITE_N8N_WEBHOOK_URL). It is never hardcoded in the source code.

Security: The Webhook Secret Token

Every webhook should have a shared secret token. This prevents anyone who discovers your webhook URL from submitting fabricated data.

In n8n, set a Header Auth credential with a secret token. In the app, include this token in the request headers:

X-Webhook-Secret: your-secret-token-here

Store the token in your environment variables, not in the source code.

The Google Sheet Structure

The master Google Sheet has nine tabs in order:

1. Early Access

2. Support Requests

3. Feature Requests

4. Clinical Interest

5. Appointment Follow-Ups (added when Workflow 10 is built)

6. Triage Log (added when Workflow 12 is built)

7. Protocol Requests (added when Workflow 5 is built)

8. Pre-Session Briefs (added when Workflow 8 is built)

9. Lab Interest (added when Workflow 4 is built)

A note on the BAA before you build any of this. The Clinical Interest tab and the alerts about it hold PHI, so the Google account behind them has to be a paid Google Workspace account with a signed HIPAA Business Associate Addendum, accepted by a super administrator in the Admin console. Gmail and Google Drive, which covers Sheets and Forms, are both listed in Google's HIPAA Included Functionality. A personal Gmail account is not covered by any BAA and cannot be used here at all.

The first four tabs are active from day one. The remaining five are added as each workflow is built.

The Email Alert Rules

Email alerts are intentionally minimal. The rule is: name, email, category, and timestamp only. No description text, no health details, no free-form content from the user.

This rule serves two purposes. First, it applies the minimum necessary principle, so the alert carries the least data that still does the job. It does not make the alert non-PHI. An alert that names a person and says she asked a provider about a service is still protected health information, because a name plus the fact of seeking care is health information about an identified individual. HIPAA recognizes only two routes to de-identified data, Expert Determination and Safe Harbor, and Safe Harbor requires stripping eighteen identifier categories including names, email addresses and any date more specific than the year. Second, it keeps the alerts actionable. An alert that contains a wall of text from a form submission is not useful. An alert that says "New clinical inquiry from Jane Doe (jane@example.com) at 2:14 PM" is immediately actionable.

Testing With Fabricated Data

Before connecting real user submissions, test every workflow branch with fabricated data. n8n has a built-in test execution mode that lets you trigger the workflow manually with a test payload.

Use completely fictional names, email addresses, and content for all test submissions. Never use real client names or real health information in test data, even in a development environment.

The Deployment Decision: Cloud vs. Local

For production use, n8n should run on a cloud server, not a local machine. A $6/month DigitalOcean droplet or equivalent is sufficient for a solo practice with low submission volume.

The alternative is n8n Cloud, the managed version that starts at $20/month. It is simpler to set up, but your webhook data passes through n8n's servers. As of this writing n8n publishes a DPA and SOC 2 alignment and no HIPAA business associate agreement, so n8n Cloud cannot carry the clinical branch. Check n8n's legal page yourself before you decide, because vendor terms change. If there is still no BAA, either self-host the whole router or split the clinical branch out entirely.

The Takeaway

The intake router is the core of the non-PHI automation layer. It takes about four hours to build from scratch, including the Google Sheets setup and the app integration. Once it is running, routing happens automatically.

The architecture is portable. The same workflow structure, with minor modifications to the form fields and Sheet column names, can be deployed for any health educator, wellness practice, or small business.

Related reading