HIPAA compliance for software: what vendors must actually do

01Covered entity or business associate: where your software sits

HIPAA applies to two groups. Covered entities are health plans, health care clearinghouses and health care providers that transmit health information electronically in connection with standard transactions, as the HHS summary of the Security Rule lists them. Most practice management, dental, clinic and patient-facing software companies sit in the second group: business associates.

The HHS business associate guidance describes a business associate as a person or organization that performs functions for a covered entity involving the creation, receipt, maintenance or transmission of PHI. Its examples include an app developer that runs patient messaging or EHR access for a provider's patients, an EHR vendor or managed service provider with access to ePHI, a cloud service provider that stores or processes ePHI, and a third-party chatbot on a provider's patient portal that handles symptoms, reminders and scheduling.

Three consequences matter for a product team:

• The BAA is a precondition. A covered entity may share PHI with you only after it has satisfactory assurances in a business associate agreement. HHS says the agreement must describe permitted uses and disclosures, bar other uses, require compliance with the Security Rule, and require you to report security incidents, including breaches.
• The chain continues downstream. Any subcontractor that handles PHI for you is also a business associate, and you must sign a BAA with it before disclosing PHI to it.
• Liability is direct. Since the HITECH Act, the Security Rule's safeguards apply to business associates in the same way they apply to covered entities, and HHS can take enforcement action against business associates directly.

Our healthcare work starts by drawing this chain: the covered entities, every vendor that touches PHI, and which agreements are signed.

02What HIPAA compliance for software asks of your team

The Security Rule is flexible, scalable and technology neutral. HHS states that it does not dictate specific measures; each regulated entity weighs its size, infrastructure, costs and the probability and criticality of risks to ePHI. Everything starts from an accurate and thorough risk analysis, and the chosen measures must reduce risk to a reasonable and appropriate level.

Two details trip teams up. First, "addressable" does not mean optional. HHS explains that an addressable specification must be implemented where reasonable and appropriate; if it is not, you adopt an alternative that meets the standard's purpose and document why. Second, documentation is part of compliance: policies and required assessments must be kept for six years from creation or from when they were last in effect.

The rule also ties access to the Privacy Rule's minimum necessary standard. The HHS minimum necessary guidance asks for reasonable steps to limit uses, disclosures and requests of PHI to what the purpose requires, with policies that name which roles need which categories of information. In a product, that means field-level decisions: what a front desk role sees, what an export contains, what an AI feature may read.

HHS has also proposed modifications to the Security Rule, so track them with counsel before you lock long-term architecture.

03There is no HIPAA certification, but breach rules are real

Buyers often ask for "HIPAA certification". The HHS guidance on cloud computing is direct on this point: OCR does not endorse, certify or recommend specific technology or products. Independent assessments can support a hospital's security review, but they are not a federal seal. What a buyer needs is your BAA, your risk analysis, your policies and proof that the controls run.

The same guidance warns that encryption alone does not satisfy the Security Rule, because it does nothing for integrity, availability or the administrative safeguards. Encryption does matter a great deal for breaches, though. Under the HHS Breach Notification Rule, an impermissible use or disclosure is presumed to be a breach unless a risk assessment of at least four factors shows a low probability that the PHI was compromised. Notification duties apply to unsecured PHI, meaning PHI not rendered unusable through methods in HHS guidance, which names encryption and destruction.

For a business associate, the clock is specific: notify the covered entity without unreasonable delay and no later than 60 days from discovery, and identify each affected individual to the extent possible. The covered entity then notifies individuals, the Secretary and, for breaches affecting more than 500 residents of a state or jurisdiction, prominent media. Business associates also carry the burden of proving notifications were made or not required.

That is an engineering requirement in disguise. If you cannot say which patients, in which tenant, were visible to which account, you cannot scope a breach. Audit logs and a data map make a 60-day deadline survivable.

04What changes when you add AI

AI features do not get a separate HIPAA. They add new places where PHI lives and new vendors that touch it. Our article on HIPAA AI compliance covers who owns which part of the program; here is what engineering should trace.

BAAs with model and cloud providers. HHS says a cloud provider that processes or stores ePHI for a business associate is itself a business associate, even if it only holds encrypted data without the key, and that using one without a BAA violates the HIPAA Rules. The conduit exception covers transmission-only services, not processing. Read hosted model APIs, transcription services, vector databases and tracing tools with the same lens: if PHI reaches them, confirm with counsel whether a BAA is needed, and check which of the provider's services its BAA actually covers.

Prompts, outputs and logs. A prompt with a patient's history is ePHI. So is the retrieved context, the model's answer, the stack trace that captured both, and the analytics event that stored the first 500 characters. We map every place prompt text is written before launch; observability tools are the usual leak. Our piece on AI data leakage lists the common paths.

De-identification, done properly. The HHS de-identification guidance recognizes two methods: Expert Determination, or Safe Harbor, which removes 18 kinds of identifiers, including names, geographic units smaller than a state, all date elements except the year, phone numbers, email and IP addresses, device identifiers, voice prints and full-face photos. HHS adds that identifiers in free text must be removed too. Stripping the name from a prompt is not de-identification if the visit date, ZIP code and a note mentioning the patient's employer remain. Properly de-identified data is no longer PHI, though HHS notes the risk of re-identification is small, not zero.

Access per user and per tenant. Retrieval must apply the same role and tenant filters as the rest of the product before the model sees anything. A model cannot unsee a record it should not have received. Our guide to tenant isolation covers the patterns.

Retention. Decide how long prompts, transcripts, embeddings and caches live, and how they are destroyed. The HHS cloud guidance notes that service agreements can address retention limits and how data is returned when a service ends. Deleting a patient's record but keeping their embedding is a common gap.

Evaluation data. Test sets built from real cases are PHI unless de-identified. Keep them in the same controlled environment as production, and record who ran which evaluation on which data.

05What we see in production

For Datascape, a Denver data consultancy that works as a HIPAA business associate for healthcare organizations, we built a RAG pipeline that reads physician employment contracts and extracts 13 compensation fields. Everything runs in the client's own HIPAA-aligned AWS account, with public traffic denied at the network level, under a signed business associate agreement. We used only the AWS permissions the client granted, and all code went to the client's repository. A term the contract does not state comes back empty, never guessed.

For MIRA, an AI patient intake tool for pain physicians, the first version stored no patient names or birth dates: each intake received a generic ID. Each of the three practices ran on its own Azure deployment and domain, and the AI drafts a summary for the physician and never diagnoses. Collecting less is the cheapest control there is.

For a dental documentation product, the AI drafts a structured clinical note during the appointment from live transcription and patient history, and nothing reaches the patient record until the dentist approves it. That approval gate protects the integrity of the record, which is a Security Rule goal as much as a clinical one.

06A HIPAA checklist for engineering teams adding AI

1. 01

   List every covered entity you serve and every vendor that touches PHI, with a BAA for each link.

2. 02

   Update the risk analysis for the AI feature before launch, not after. HHS says entities must assess the need for a new evaluation when, for example, new technology is adopted.

3. 03

   Draw the feature's PHI flow

   inputs, retrieval, model calls, outputs, logs, caches and evaluation sets.

4. 04

   Enforce role and tenant filters in the backend before retrieval, and limit context to the minimum necessary.

5. 05

   Decide where de-identification applies, which method you rely on, and how free text is handled.

6. 06

   Scrub or block PHI in observability and analytics tools that are not covered by a BAA.

7. 07

   Log access to PHI by user, tenant and process, and review the logs. See our guide to AI audit trails.

8. 08

   Set retention and deletion for prompts, transcripts, embeddings and backups.

9. 09

   Keep evaluation data inside the controlled environment.

10. 10

    Rehearse a breach

    can you name affected individuals per tenant within days, not weeks?

11. 11

    Document every decision, including why an addressable specification was handled another way, and keep it for six years.

Have counsel review your BAAs and your reading of each rule; this list is engineering practice, not legal advice. If you are planning AI inside a healthcare product, we start with a two-week Planning Sprint for $5,000 that ends in a plan and a fixed quote, and the fee counts toward the build. If the AI is already built, the AI Scorecard tests it on 50 of your own cases over two weeks, for $5,000.

Frequently asked questions