Building HIPAA-Compliant AI Applications: Lessons from 40+ ProjectsBuilding HIPAA-Compliant AI Applications: Lessons from 40+ Projects

Building HIPAA-Compliant AI Applications: Lessons from 40+ Projects

Healthcare AI is one of the highest-impact applications of artificial intelligence. From clinical decision support to automated medical coding to patient communication, AI can meaningfully improve patient outcomes while reducing clinician burnout. But healthcare AI comes with a constraint that most industries do not face: HIPAA.

At Obaro Labs, we have built more than forty AI systems that handle protected health information (PHI). We have navigated BAA negotiations with every major cloud provider and LLM vendor. We have passed compliance audits and helped clients avoid violations that could have cost millions in penalties.

This post shares the practical lessons we have learned - the things that are not in the HIPAA regulation text but that you discover only through building real systems.

Understanding What HIPAA Requires for AI Systems

HIPAA was written long before AI existed, but its principles apply directly. The core requirements for any system that processes PHI are:

1. Privacy Rule: PHI can only be used or disclosed for specific purposes (treatment, payment, healthcare operations, or with patient authorization).
2. Security Rule: Technical, administrative, and physical safeguards must protect electronic PHI (ePHI).
3. Breach Notification Rule: If there is an unauthorized disclosure of PHI, affected individuals and HHS must be notified.
4. Business Associate Agreement (BAA): Any third party that handles PHI on behalf of a covered entity must sign a BAA.

For AI systems, this means every component in your architecture that touches PHI needs to be covered by a BAA and configured to meet the Security Rule requirements.

The BAA Chain: Every Link Matters

This is where most teams stumble. Your AI system does not exist in isolation - it relies on cloud providers, LLM APIs, vector databases, logging services, and monitoring tools. Every service that could potentially access PHI needs a BAA.

The typical BAA chain for a healthcare AI system:

• Cloud provider (AWS, GCP, or Azure) - all three offer BAAs
• LLM provider (OpenAI offers a BAA for their API; Anthropic offers one for Claude; Azure OpenAI is covered under the Azure BAA)
• Vector database (if managed - Pinecone offers a BAA; self-hosted options avoid this need)
• Logging and monitoring (this is frequently overlooked - if your logs contain PHI, your logging provider needs a BAA)
• Email or notification services (if you send notifications that contain PHI)

Lesson learned: We had a client whose AI system was fully compliant except for their error logging service. When the AI system encountered an error processing a patient record, the error log included the patient's name and medical record number. That logging service did not have a BAA. This was a compliance gap that would have been a reportable breach if the logs had been accessed by an unauthorized party. We caught it during our pre-launch compliance review.

Architecture Patterns for HIPAA-Compliant AI

Over forty projects, we have converged on three architecture patterns that balance compliance with performance.

Pattern 1: De-identification Before AI Processing

The safest approach is to remove all PHI before sending data to an AI model. If the model never sees PHI, the model provider does not need a BAA for that specific data flow.

How it works:

1. Patient data enters your system
2. A de-identification service removes or replaces all 18 HIPAA identifiers
3. De-identified data is sent to the LLM for processing
4. Results are returned and re-associated with the patient record in your HIPAA-compliant environment

Pros: Minimizes compliance surface area. You can use any LLM provider. Cons: De-identification is imperfect and can remove clinically relevant context. Not suitable for all use cases.

// De-identification pipeline for clinical text
interface DeidentifiedResult {
  cleanText: string;
  replacements: Map<string, string>; // mapping of placeholders to original values
}

const HIPAA_IDENTIFIERS = [
  // Names
  /[A-Z][a-z]+s[A-Z][a-z]+/g,
  // Dates (more specific than YYYY format)
  /d{1,2}/d{1,2}/d{2,4}/g,
  // Phone numbers
  /d{3}[-.]d{3}[-.]d{4}/g,
  // SSN
  /d{3}-d{2}-d{4}/g,
  // MRN patterns (facility-specific)
  /MRN[:s]?d{6,10}/gi,
  // Email addresses
  /[w.-]+@[w.-]+.w+/g,
];

function deidentify(text: string): DeidentifiedResult {
  const replacements = new Map<string, string>();
  let cleanText = text;
  let counter = 0;

  for (const pattern of HIPAA_IDENTIFIERS) {
    cleanText = cleanText.replace(pattern, (match) => {
      const placeholder = "[REDACTED_" + counter++ + "]";
      replacements.set(placeholder, match);
      return placeholder;
    });
  }

  return { cleanText, replacements };
}

function reidentify(
  text: string,
  replacements: Map<string, string>
): string {
  let result = text;
  for (const [placeholder, original] of replacements) {
    result = result.replace(placeholder, original);
  }
  return result;
}

Pattern 2: BAA-Covered End-to-End

When de-identification is not feasible (for example, when the AI needs to understand patient names for record matching, or when clinical context would be lost), we use a fully BAA-covered architecture.

Typical stack:

• AWS or Azure for compute and storage (BAA in place)
• Azure OpenAI or Anthropic Claude API (BAA in place)
• Self-hosted vector database (Qdrant or pgvector on your own infrastructure)
• Self-hosted logging (ELK stack or Grafana Loki on your infrastructure)

Key configuration requirements on AWS:

• Enable CloudTrail for all API calls
• Enable S3 server-side encryption (AES-256 or KMS)
• Enable RDS encryption at rest and enforce SSL for connections
• Configure VPC with private subnets for all PHI-processing services
• Enable GuardDuty for threat detection
• Configure IAM policies following least-privilege principle
• Enable AWS Config for continuous compliance monitoring

Pattern 3: Hybrid (De-identify Where Possible, BAA Where Necessary)

This is our most common pattern. We de-identify data for tasks where it does not affect quality (summarization, classification, coding), and use the BAA-covered path for tasks that require full patient context (clinical decision support, patient communication).

The Pre-Launch Compliance Checklist

Before launching any healthcare AI system, we walk through this checklist:

BAA Coverage:

• Cloud provider BAA signed and on file
• LLM provider BAA signed and on file
• All third-party services that touch PHI have BAAs
• BAA chain is documented with responsible parties

Encryption:

• Data encrypted at rest (AES-256 minimum)
• Data encrypted in transit (TLS 1.2 minimum)
• Encryption keys managed through a key management service
• Key rotation policy in place

Access Control:

• Role-based access control implemented
• Multi-factor authentication for all administrative access
• User access reviewed quarterly
• Terminated employee access revoked within 24 hours

Audit Logging:

• All PHI access logged with timestamp, user, and action
• Logs stored for minimum 6 years (HIPAA requirement)
• Log integrity protected (tamper-evident)
• Automated alerting on suspicious access patterns

Incident Response:

• Incident response plan documented
• Breach notification procedures defined (72-hour window for HHS notification)
• Incident response team identified with contact information
• Tabletop exercise conducted at least annually

Common Compliance Mistakes We See

Mistake 1: Sending PHI to LLMs without a BAA. This is the most common and most serious mistake. If you send patient data to OpenAI without a BAA, that is a HIPAA violation, period. It does not matter that OpenAI "does not train on your data" - you still need a BAA.

Mistake 2: PHI in logs and error messages. When your system throws an error while processing a patient record, the stack trace and error message often contain PHI. If those logs go to a service without a BAA (or are accessible to unauthorized personnel), that is a violation.

Mistake 3: Developer access to production data. Developers debugging issues in production should not have access to real PHI. Build your system so that developers can diagnose issues using de-identified data, synthetic data, or anonymized logs.

Mistake 4: Forgetting about model outputs. Even if your input data is de-identified, the model might generate PHI in its output (for example, by inferring a diagnosis that could identify a patient in context). Output filtering is as important as input filtering.

Mistake 5: No data retention policy. How long do you keep patient data in your AI system? In your vector store? In your cache? You need explicit retention policies and automated deletion processes.

Working with Compliance Teams

One of the most valuable lessons we have learned is to involve compliance teams early - not as a gate at the end, but as a collaborator from the start.

We schedule a compliance review at three points in every healthcare AI project:

1. Architecture review (before development starts): Ensure the proposed architecture can meet compliance requirements.
2. Pre-launch review (before the system goes live): Walk through the compliance checklist, review configurations, and validate BAA chain.
3. Post-launch audit (30 days after launch): Review access logs, confirm monitoring is working, and verify that real-world usage aligns with the compliance plan.

The Future: AI-Specific Healthcare Regulations

HIPAA is the baseline, but the regulatory landscape is evolving. The FDA is increasing oversight of AI-based clinical decision support tools. The ONC is pushing for algorithm transparency. Several states are proposing AI-specific healthcare regulations.

We recommend building your AI systems with more transparency and auditability than HIPAA currently requires. Document your training data sources, your model selection rationale, your evaluation methodology, and your ongoing monitoring approach. This documentation will become mandatory - building it now is an investment in future compliance.

Conclusion

HIPAA compliance for AI is not a checkbox exercise - it is a design discipline. The teams that build compliance into their architecture from the start move faster and more confidently than those who try to retrofit it later.

At Obaro Labs, every healthcare AI project starts with a compliance architecture review. If you are building AI for healthcare and want to ensure you are doing it right, reach out. We have navigated this landscape enough times to help you avoid the pitfalls that catch most teams.