The Problem With Most AI Workflow Tutorials
Most AI workflow tutorials are written by developers who have never had to think about HIPAA. They show you how to connect a form to a Google Sheet, route it through n8n, and send a Gmail notification. The tutorial ends. The compliance risk begins.
The core issue is that healthcare professionals are applying general-purpose automation patterns to environments where the rules are fundamentally different. What works for a SaaS company's lead capture form does not automatically work for a clinical intake process.
This post covers the two-layer architecture that makes AI workflows safe for healthcare use, based on what was actually built and deployed at Hunters Holistic Health.
What HIPAA Actually Requires (The Practical Version)
Before any of this: I am a PharmD, not an attorney, and this post is general information about how I built one system. It is not legal advice and it does not create any professional relationship. HIPAA obligations turn on facts specific to your practice, your state, and your vendors. Confirm anything here with your compliance officer or a healthcare attorney before you rely on it, and confirm every regulatory citation against the current text at ecfr.gov and hhs.gov rather than against my summary of it.
HIPAA applies to covered entities and their business associates. A covered entity is a healthcare provider who transmits health information electronically in connection with certain transactions, a health plan, or a healthcare clearinghouse.
The key phrase is "in connection with certain transactions." If you are a cash-pay functional medicine educator who does not bill insurance electronically, you may not be a covered entity under the strict legal definition. This is worth confirming with a healthcare attorney for your specific situation.
That said, the practical approach is to build as if HIPAA applies, because the underlying principle (protect individually identifiable health information) is good practice regardless of your legal status.
Protected Health Information (PHI) has a narrower legal definition than most people assume. Under 45 CFR 160.103, information is PHI when three things are true at once. It was created or received by a health care provider, health plan, employer, or health care clearinghouse. It relates to a person's past, present, or future physical or mental health, to the provision of health care, or to payment for that care. And it identifies the person, or there is a reasonable basis to believe it could be used to identify them. The regulation then carves out four categories that are not PHI even when all three are met: FERPA education records, certain treatment records under 20 U.S.C. 1232g(a)(4)(B)(iv), employment records held by a covered entity acting as an employer, and information about someone who has been deceased more than 50 years. That means a name combined with a health condition, a lab value, a diagnosis, or a treatment plan. A name and email are not automatically PHI. In the hands of a marketing list, they are just contact data. But the definition of individually identifiable health information expressly includes demographic information, so the same name and email become PHI the moment a covered provider receives them in connection with a request for care. A list of people who asked about clinical services is PHI even if not one health detail is attached to it. Assume any identifier that arrives through a clinical intake path is PHI, and design the workflow around that assumption rather than around the presence or absence of a diagnosis. A name, email, and a description of someone's health goals together can be.
The Two-Layer Architecture
The architecture that keeps AI workflows safe is built around a hard separation between two lanes.
Lane 1: The Non-PHI App and Automation Layer
This is where your intake forms, n8n workflows, Google Sheets, and email notifications live. Lane 1 is designed so that PHI has no reason to be there. What it cannot do is guarantee the outcome, because any free-text field can receive something a user was asked not to type, and a disclaimer above a text box is a request rather than a control. So plan for the failure case: review the free-text column on a set schedule, delete anything clinical out of the Sheet and out of the n8n execution log, move the substance into Lane 2, and write down that you did it. A lane that is designed for non-PHI and cleaned when it slips is defensible. A lane you claim in writing never touches PHI is a claim someone will one day check against the actual rows. Forms collect operational and interest data only. Email alerts contain name, email, category, and timestamp. No health narratives, no lab values, no diagnoses. Be precise about what that buys you. Stripping the narrative does not de-identify the alert. HIPAA recognizes only two ways to de-identify: Expert Determination under 45 CFR 164.514(b)(1), where a qualified statistician documents that the re-identification risk is very small, and Safe Harbor under 164.514(b)(2), where all 18 listed identifiers are removed and you have no actual knowledge that what is left could still identify someone. Names, email addresses, and event dates are three of those 18, so an alert that carries all three is not de-identified by any measure. What minimization actually gives you is a smaller blast radius: less sensitive content sitting in a mailbox, and a shorter breach notification if that mailbox is ever compromised. Route the alert to your covered Google Workspace mailbox anyway, and treat it as PHI.
Lane 2: The Clinical Lane
This is where PHI lives. For most solo practitioners and small practices, this is Google Workspace with a signed Business Associate Agreement (BAA) from Google. After someone submits a clinical interest form in Lane 1, you review it manually and move the conversation into Lane 2 via secure Gmail and Google Drive. The full configuration walkthrough is here: how to set up Google Workspace as your HIPAA clinical lane.
The two lanes never merge in code. n8n never touches PHI. The app never stores PHI. Neither does any AI model in this stack, and that is the point of the split. A vendor that creates, receives, maintains, or transmits PHI on your behalf is a business associate, and an AI vendor is no exception. Sending PHI to a model with no signed BAA in place is a disclosure, not an experiment. Most consumer and free AI tiers are not offered under a BAA at all, and the enterprise tiers that are cover only the specific services and plan named in the agreement. Signing one does not finish the job either. A BAA binds the vendor. It does not transfer your own Privacy and Security Rule obligations, and it does not make a tool compliant on its own. The clinical lane is entirely manual and handled through your covered Google Workspace environment.
What This Looks Like in Practice
Here is the actual flow used at Hunters Holistic Health:
1. A client submits a clinical interest form in the app. The form collects name, email, phone, service interest, and a brief description of what they are looking for. The description field has a visible disclaimer: "Please describe your interest in general terms only. Do not include lab results, diagnoses, or private health information."
2. n8n receives the webhook, logs the submission to a Google Sheet tab called Clinical Interest, and sends an email alert to the educator with name, email, category, and timestamp only. No description text in the alert.
3. The educator reviews the submission and decides whether to move forward.
4. If yes, the educator creates a client folder in Google Drive (inside the covered Google Workspace environment) and initiates contact via Google Workspace Gmail.
5. All subsequent clinical communication, lab uploads, and record storage happen inside Google Workspace. The app and n8n never see any of it.
The Form Field Rules
The most common mistake is putting health-related free-text fields in Lane 1 forms. Here is the rule: any field where a user could reasonably type a diagnosis, a lab value, a medication name, or a health condition belongs in Lane 2, not Lane 1.
Lane 1 forms can safely collect:
- Name (first and last only, no DOB)
- Email address
- Phone number (optional)
- Service interest (dropdown, general categories)
- Preferred contact method
- Brief general description with a PHI disclaimer above the field
Lane 1 forms should never collect:
- Health history
- Current medications
- Lab results or values
- Diagnoses or conditions
- Treatment history
The Google Workspace BAA
Before using Google Workspace for actual clinical files, you need a signed BAA with Google. This is done in the Google Workspace Admin Console under Account settings. Google publishes a HIPAA Included Functionality list that defines which services the BAA actually covers. Gmail, Drive, Docs, Sheets, and Meet have been on it, but the list is Google's to revise, so check the current version rather than trusting a blog post from last year. Two limits matter more than the list itself. Third party applications and add-ons are not included in the covered functionality, and neither the BAA nor the Cloud Data Processing Addendum extends to Additional Google Services. That second one catches people, because the Additional Services and AI feature toggles live in the same Admin Console you use to sign the BAA. If you turn one on and PHI flows through it, that traffic is outside your BAA. Google is also explicit that deciding whether you are subject to HIPAA, and whether you intend to put PHI into Google services, is your call and not theirs.
The Workspace configuration steps are:
- Signed BAA in the Admin Console
- MFA enabled on all staff accounts
- Drive sharing set to private by default
- External sharing restricted
- A standard client folder structure
- Basic internal policies for access control
None of this is technically complex. It is administrative work that takes a few hours to set up correctly. It is also not the whole obligation. If HIPAA applies to you, the Security Rule requires more than settings. A risk analysis under 45 CFR 164.308(a)(1)(ii)(A) is a required implementation specification, not an optional one, and 164.316 requires that your policies and procedures be written down and kept for six years. Tightening the Admin Console is the easy half. The documented risk analysis is the half that gets asked for first when something goes wrong.
Why This Matters More Than You Think
The FTC has separate enforcement authority from HHS (which enforces HIPAA). Even if you are not a HIPAA covered entity, the FTC can take action against companies that fail to protect health information under Section 5 of the FTC Act. The FTC Health Breach Notification Rule also applies to vendors of personal health records and related entities.
Building the two-layer architecture from the start protects you under both frameworks. It is not extra work. It is the right foundation.
The Takeaway
The two-layer architecture is not complicated. It is a discipline. Keep PHI in the covered lane. Keep automation in the non-PHI lane. Never let them merge in code. Review any new feature against that rule before building it.
Every workflow covered in this curriculum is built around this architecture. The intake system, the appointment follow-up automation, the supplement protocol builder, and the pre-session brief all run through Lane 1. The clinical lane is separate, manual, and Google Workspace-based.
That is the architecture I would want to be able to explain if someone ever asked me to. Have your compliance officer or counsel review it against your own facts before you trust it with a real client.