LayBuild is not HIPAA compliant and we don't sign business associate agreements. If you are a covered entity or a business associate under HIPAA, don't let protected health information flow through LayBuild. This post explains what HIPAA expects from a vendor that handles PHI, where LayBuild falls short of that today, and how healthcare and medtech teams can still use it for support questions that involve no patient data.
This is an engineering guide, not legal advice. Whether HIPAA applies to your product, and what counts as PHI in your conversations, is a question for your compliance lead or counsel.
What HIPAA expects from a vendor that touches PHI
Protected health information is individually identifiable health information in any form: a person's past, present or future health condition, their care, or payment for it, linked to something that identifies them (45 CFR 160.103). In a support chat that's easy to produce. A customer who gives their name and writes "my insulin pump alarm keeps going off" has just sent PHI, if the chat belongs to a covered entity or its vendor.
A business associate is anyone who creates, receives, maintains or transmits PHI on a covered entity's behalf, and the definition explicitly includes subcontractors of a business associate (same section). For an AI support tool, that chain runs past the tool itself to the LLM provider, the hosting provider and anyone else the text passes through.
The business associate agreement
Before PHI goes to a business associate, there has to be a contract with specific terms. 45 CFR 164.504(e) requires the agreement to, among other things:
- set out what the vendor may use and disclose PHI for, and bar anything beyond that
- require appropriate safeguards and compliance with the Security Rule for electronic PHI
- require the vendor to report uses or disclosures outside the contract, including breaches of unsecured PHI
- require the vendor's subcontractors to agree to the same restrictions
- make PHI available for patients' access, amendment and accounting-of-disclosures rights
- open the vendor's practices and records to HHS on request
- require return or destruction of PHI when the contract ends, where feasible
The technical safeguards
The Security Rule's technical safeguards (45 CFR 164.312) cover access control (unique user IDs and an emergency access procedure are required; automatic logoff and encryption at rest are "addressable"), audit controls, integrity protection, person or entity authentication, and transmission security, including encryption in transit as an addressable specification. "Addressable" doesn't mean optional. It means you assess whether the measure is reasonable for your environment, implement it or an equivalent, and document the decision.
Where LayBuild falls short
Not signing a BAA settles the question for the hosted service on its own. The engineering gaps are worth knowing too, because they're the same gaps you'd have to close yourself if you ran LayBuild in a regulated environment:
- Conversations and messages are stored in Postgres without application-level encryption. Stored API keys, SMTP passwords, widget keys and uploaded files are encrypted with AES-256-GCM; chat text isn't.
- The customer's message goes to the LLM provider unredacted. For PHI, that provider would itself need a BAA with you or your vendor.
- PII redaction is four regular expressions (16-digit card numbers, US SSNs, emails, phone numbers) applied to the AI's answer only. There's no detection of names, conditions, medications, dates of birth or record numbers. Our PII post shows what it catches and misses.
- The learning loop publishes "learnable" exchanges to the knowledge base automatically, with no human approval. A patient's question can become the title of a knowledge document that feeds answers to other people.
- Outbound webhooks send message text as typed to every subscribed endpoint.
- Two-factor login is available per user but can't be enforced for a workspace, and dashboard sessions last 7 days by default.
- LayBuild holds no HIPAA, SOC 2 or ISO 27001 attestation or certification.
Self-hosting changes who operates the system; it doesn't close these gaps. You would still need a model you run yourself or a provider that signs a BAA, encryption for stored conversations, your own risk analysis and your own policies. We haven't done that work, so we can't tell you a self-hosted LayBuild is fit for PHI.
What LayBuild can safely handle
Plenty of healthcare and medtech support volume contains no patient data at all: how to reset a password, where to download the app, what the clinic's opening hours are, how billing cycles work, how to pair a device with a phone, which browsers the portal supports. That's what LayBuild is built for: it answers only from your knowledge base, and when it can't find support there it sends a fixed "I do not have specific information about that..." reply instead of guessing.
The work is keeping PHI out, both from your knowledge base and from what customers type.
Keep the knowledge base free of patient data
Upload product docs, policies and public FAQs. Don't upload support ticket exports, call notes or anything drawn from real patient interactions. Review the auto-learned documents regularly and delete any whose title contains personal or clinical details.
Tell people what not to share, before they type
Your widget's welcome message is the first thing a visitor sees. Use it:
Hi, I can help with accounts, billing and using the app. Please don't share medical details, medications or your date of birth here. For questions about your care, use the patient portal or call us. In an emergency, call your local emergency number.
This won't stop everyone, which is why the next step exists.
Refuse clinical topics instead of answering them
Admins can add blocked terms in the guardrail settings. A message containing one is refused before it reaches the model, with your refusal message. Set that message to point to the right channel, and add terms that signal clinical content: for example "dosage", "prescription", "diagnosis", "side effect", "lab result", "symptom". It's a plain substring match, so expect some false positives ("prescription" also blocks "how do I update my prescription delivery address"), and tune the list against real messages.
Hand off out of the chat, not inside it
LayBuild's human handoff (off by default; turned on with ALLOW_HUMAN_HANDOFF) moves the conversation to a human agent in the LayBuild inbox. For a patient who needs help with their care, that keeps the PHI in LayBuild. The safer pattern is a handoff that moves the person to your compliant channel: the AI's answers, the refusal message and your agents' replies should send them to the patient portal or phone line rather than asking for details in chat. See safe handoff and escalation for how handoff works.
Don't wire patient systems to it
Don't attach API tools that read from EHR, scheduling or patient databases. LayBuild's tools don't receive customer identity anyway, so they couldn't return one patient's data safely, and anything a tool returns is shown in the chat.
Frequently asked questions
Will LayBuild sign a BAA?
No, not today. If that changes, we'll update this post. Until then, treat LayBuild as a system that must not receive PHI.
We're a wellness app, not a provider. Does HIPAA apply?
It depends on whether you're a covered entity or work on behalf of one, and other US and non-US rules can apply to health data even where HIPAA doesn't. That's a question for counsel, and worth answering before you pick any chat vendor.