What does HIPAA AI compliance mean for software vendors?

01Who carries what under HIPAA

Healthcare founders often expect their engineering partner to carry compliance from end to end. The regulation does not work that way, and knowing why makes scoping much easier.

HIPAA applies to covered entities, such as healthcare providers, and to their business associates. Under the federal definition, a business associate is a person or organization that creates, receives, maintains or transmits protected health information on behalf of a covered entity. The definition also includes subcontractors that handle that information on behalf of a business associate.

For a company selling clinical software to practices, that usually means:

• The clinics are covered entities.
• Your company is their business associate, and signs a business associate agreement with each clinic or under your terms of service.
• Your cloud provider, your AI model provider and any vendor that touches protected health information are your subcontractors, and you need agreements with them.
• Your engineering partner is in that chain only if it handles protected health information. If the partner works without access to real patient data, much of the compliance burden never reaches it.

That last point is a design choice, not a legal technicality. We plan our work so engineers do not need standing access to client production data, which keeps the boundary clear and the security conversation short.

This article explains how we scope engineering work. It is not legal advice, and your counsel should review your agreements.

02What stays with you and what the engineering team builds

A clear split saves weeks of back and forth. This is the split we write into scope:

NIST Special Publication 800-66 Revision 2 is a useful companion here. It is a practical guide to implementing the HIPAA Security Rule, written for regulated organizations of any size, and it helps a founder understand what the technical safeguards are meant to achieve.

03How we approach HIPAA AI inside a healthcare product

AI adds one specific risk to a healthcare product: patient data flowing to a model provider. Our approach is to design that risk out wherever we can, rather than relying on contracts alone.

1. 01

   Decide what the model actually needs.

   Clinical summaries need symptoms, history and medications. They rarely need a patient's name or date of birth.

2. 02

   Strip identifiers before any data reaches the model.

   Names, dates of birth and similar identifiers are removed in your own backend, before the request leaves your environment. The HIPAA de-identification standard lists the identifiers that matter, including names and all elements of dates except the year, and it is a good checklist even when you are not aiming for full de-identification.

3. 03

   Keep one system of record.

   Every extra platform that stores patient data is another system to secure, document and cover in an agreement. One database in one cloud is easier to defend.

4. 04

   Isolate tenants from the start.

   Each clinic's data stays separate, and only a defined super admin role sees across clinics.

5. 05

   Keep a human in the loop for clinical judgment.

   The AI drafts, a clinician reads and decides. The AI does not diagnose.

6. 06

   Put secrets in a managed vault.

   API keys and credentials never live in code or plain configuration.

7. 07

   Say plainly what you are not doing.

   Write in the scope that the business associate agreements and audits stay with the product company. Honest scope shortens security reviews.

04What we see in production

We designed and built an AI patient intake product for pain clinics, from a first version used in one practice to a multi-clinic commercial product. The first version, built for the founder's own clinic, asked patients an adaptive questionnaire covering pain, medical and surgical history, medications with doses and intervals, and treatments tried, and wrote a clinical summary for the physician. Patients could also answer by voice. The client used it on about 100 of their own patients before we turned it into a product.

The second phase turned that proof into software clinics could buy on their own: self-service onboarding, per-provider billing, multi-clinic and multi-provider support with role-based access for super admin, clinic admin and provider, template customization and a physician dashboard. The hard constraints were written down early. Patient identifiers such as name and date of birth must never be sent to the AI model provider, even once the commercial version collects them. Each clinic account must be fully separate, with only the super admin seeing all clinics. Everything had to follow HIPAA practice, and the business associate agreement and the third-party audit stay with the client.

Some of the most useful decisions were about what not to build. The client had built a landing page and sign-up on a separate platform with its own database. Keeping it would have split patient-adjacent data across two systems, created sync problems with billing and account checks, and added a second system to cover for HIPAA. We recommended one database on Azure for everything, with the separate tool used only for front-end screens.

We stripped patient identifiers before any data reached the model, kept secrets in Azure Key Vault and ran HTTPS throughout. Patients do not need accounts: they answer on a clinic tablet or through a unique clinic link. The AI drafts a structured summary for the physician to read, and it does not diagnose.

Because the scope said clearly what stayed with the client, the security conversation focused on controls we could actually show, rather than on promises nobody could keep.

05Questions to settle before your first AI feature in healthcare

• Which of your vendors will create, receive, maintain or transmit protected health information, and do you have agreements with each?
• Does your AI model provider offer an agreement for the service you plan to use, and does your design even need to send it identifiers?
• How many systems store patient data, and can that number be one?
• Who can see data across tenants, and is that role logged?
• Where do secrets live?
• What does the AI decide on its own, and what does a clinician approve?

For more on keeping sensitive data out of AI pipelines in another regulated setting, see our piece on AI for K12 software without touching student data. The same pattern, keeping identifiers inside your boundary and sending the model only what it needs, applies well beyond education.

Frequently asked questions