Healthcare is one of the few industries where the software decision is also a legal decision. Build on an architecture that mishandles Protected Health Information (PHI) and you are not just looking at poor software — you are looking at HHS breach notifications, OCR investigations, and fines that in 2024 ranged from $100 per violation to $1.9 million per violation category per year. The compliance requirement is not a layer you add to a finished system. It is a set of architectural requirements that must be embedded from the first line of code.

For healthcare organizations — specialty clinics, group practices, telehealth platforms, care coordination tools, behavioral health apps — custom software offers something off-the-shelf EMR vendors cannot: software designed around your actual workflow, not the other way around. But the flexibility advantage disappears immediately if the HIPAA architecture is wrong. This guide covers the technical requirements a healthcare software build must satisfy before it handles a single patient record.

PHI: what it is and what the handling rules actually require

Protected Health Information is individually identifiable health information — any data that can be linked to a specific person's past, present, or future health condition, healthcare provision, or payment. The definition is broad: it includes not just diagnosis codes and treatment records but names, addresses, dates (including birth dates), phone numbers, email addresses, and any device identifier that could identify a person in a health context. Software that touches any of it is in scope for HIPAA.

The technical safeguards under HIPAA's Security Rule require: encryption of PHI at rest and in transit, audit controls that log who accessed or modified each record and when, automatic session timeouts on systems containing PHI, unique user identification with no shared credentials, and integrity controls that can verify data has not been altered or destroyed. These are not aspirational guidelines — they are minimum requirements, and OCR audits assess them specifically.

Business Associate Agreements and your infrastructure stack

Every vendor that touches PHI on your behalf is a Business Associate (BA), and every BA must sign a Business Associate Agreement (BAA) before PHI flows to their systems. This is not a formality — it is a legal precondition for using cloud infrastructure, managed databases, email services, or analytics tools with patient data.

AWS, Google Cloud, and Microsoft Azure all offer HIPAA-eligible services and will sign BAAs. Not every service within those platforms is HIPAA-eligible, however — the BAA covers specific services and those services only. A healthcare software build on AWS must be designed to keep PHI exclusively within BAA-covered services: HIPAA-eligible EC2, RDS, S3 configurations, and so on. Logging PHI to a service not covered by the BAA — even an AWS service — is a potential breach.

Third-party services that are common in software development — Slack, Zapier, standard email providers, non-healthcare analytics tools — typically will not sign BAAs and cannot receive PHI. Any integration that might expose PHI to a third party must go through a vendor evaluation before the integration is built, not after it is discovered in a security review.

Architecture patterns that make HIPAA defensible

A PHI service layer — a dedicated backend service that owns all PHI access and enforces authorization before returning any health data — is the cleanest pattern for HIPAA compliance in custom software. All other services that need patient data make a request to the PHI service; they never query the PHI database directly. This centralizes the access control and audit logging, makes the compliance surface predictable, and makes the audit much simpler: one service owns PHI, one team owns the PHI service, one set of logs to produce for OCR.

De-identification, where feasible, dramatically reduces compliance scope. HIPAA's Safe Harbor method removes 18 specific identifiers; if your analytics, reporting, or machine learning use cases can operate on de-identified data, those pipelines can use standard infrastructure without HIPAA controls. Build de-identification into the data pipeline early, even if the immediate use case doesn't require it — the analytics infrastructure you build for product metrics will eventually need to touch patient cohorts.

A healthcare software system that was not built for HIPAA can be hardened — but the cost is usually a near-complete rewrite of the data layer. It is cheaper to build it right than to fix it under regulatory pressure.

TTGC's approach to healthcare software builds

Ravve Jay Prevendido and the TTGC development team approach healthcare software with compliance as a first-class requirement, not an afterthought. The architecture review that opens every healthcare engagement covers PHI boundaries, BAA stack selection, audit log architecture, and access control modeling before a line of product code is written. The result is software that passes security reviews and enables growth without a compliance retrofit. For healthcare organizations exploring custom builds — telehealth platforms, specialty EMR modules, patient engagement tools — see building an MVP that scales for the scoping framework, and then connect at /growth-assessment.