A practical HIPAA checklist for app architecture
A working checklist for HIPAA-ready software: encryption, role-based access, audit logs, minimum necessary data, vendor BAAs, backups, de-identification and PHI-free logging.
A HIPAA-ready architecture limits who can see protected health information (PHI), records every access, encrypts the data everywhere it lives or travels, and keeps PHI out of places it does not belong, such as logs and analytics. This post turns that into a checklist you can work through. It is engineering guidance, not legal advice, so involve qualified counsel or a compliance advisor before you rely on it.
What HIPAA covers for software
HIPAA is a US law with several rules. Three matter most to software teams.
| Rule | What it governs | What it means for your app |
|---|---|---|
| Privacy Rule | How PHI may be used and disclosed | Minimum necessary data, clear access purposes |
| Security Rule | Safeguards for electronic PHI | Encryption, access control, audit logs, risk analysis |
| Breach Notification Rule | What to do when PHI is exposed | A tested response runbook and notification owners |
The rules apply to covered entities (providers, health plans, clearinghouses) and to their business associates, which includes most vendors that touch PHI on their behalf. If your app creates, stores or transmits PHI for a covered entity, you are likely a business associate with direct obligations.
How PHI should move through your system
- 01Collectonly what the task needs
- 02TransmitTLS on every hop
- 03Storeencrypted, keys separate
- 04Accessrole-checked on the server
- 05Recordappend-only audit event
Every control below attaches to one of these steps. If you cannot say which step a piece of PHI is at, you cannot protect it.
The checklist
1. Encrypt in transit
- TLS on every connection that carries PHI: browser to API, service to service, API to database, calls to vendors
- Legacy protocol versions and weak cipher suites disabled, plain HTTP redirected
- No PHI sent in clear text after a load balancer terminates TLS
2. Encrypt at rest
- Encryption on databases, object storage, file volumes and backups
- Keys held in a dedicated key service and rotated
- Permission to use keys kept separate from permission to read data
- Device encryption for any laptop or phone cache of PHI, or no local cache at all
3. Control access by role
Role-based access control with least privilege gives a front-desk user, a clinician, a billing analyst and an on-call engineer different views.
- Roles enforced on the server for every request, not only in the interface
- Unique user IDs and multi-factor authentication
- Automatic session timeouts
- A break-glass path for emergencies that is loud and reviewed afterward
- Access removed promptly when people change roles or leave
4. Keep an audit trail
An audit trail answers who accessed which record, when, from where and what they did.
- Reads logged as well as writes, since a snooping employee only reads
- Audit events written to an append-only store that application admins cannot edit
- A scheduled review of the logs, because an unreviewed log protects no one
5. Apply the minimum necessary standard
For most uses and disclosures, HIPAA expects you to limit PHI to what the task needs. A scheduling screen needs a name and a time, not a diagnosis.
- Narrow API responses and field-level permissions
- Separate views for separate jobs
- Pseudonymous IDs in reporting tables instead of full patient records
6. Sign a BAA with every vendor that touches PHI
A business associate agreement is required before a vendor handles PHI for you. That includes your cloud provider, email and SMS tools, error trackers, support desks and AI services.
- A BAA signed before any PHI reaches the vendor
- Only services the vendor lists as covered under its BAA, since many providers cover some services and not others
- An inventory of every place PHI flows, so a new tool cannot join the stack unnoticed
7. Plan backups and breach response
- Scheduled, encrypted backups with restores that you actually test
- A disaster recovery plan with named owners and a way to keep operating when systems fail
- A breach runbook covering detection, containment, assessing what was exposed, and who decides on notification
8. Use de-identification where you can
Data that is properly de-identified is no longer PHI under HIPAA. The Privacy Rule describes two methods: removing a defined list of identifiers (Safe Harbor), or having a qualified expert determine that the re-identification risk is very small.
- De-identified data for analytics, model training and test environments
- No copy of production PHI in staging
9. Log without PHI
Logs, traces, error reports and analytics events spread quickly and are rarely locked down like a database.
- Identifiers and event types logged, not names, dates of birth, notes or free text
- Request bodies scrubbed before they reach an error tracker
- A sample of real logs reviewed for leaks
How this looks at Techdome
We treat these controls as day-zero design work, not a pre-launch scramble. Our US and UK telehealth platform for the GLP-1 space is a multi-tenant clinical operating platform built on PostgreSQL and AWS HIPAA infrastructure, with HIPAA and UK GDPR architecture from the start. It covers synchronous and asynchronous EMR, e-prescribing, pharmacy routing and split billing.
Our compliance work also includes BAA execution. For more on how we approach clinical software, see healthcare software and HIPAA.
Takeaways
- HIPAA is technology-neutral. Document a risk analysis for your own system and involve counsel.
- Encrypt PHI in transit and at rest, and manage keys separately from data.
- Enforce role-based access on the server, and keep an append-only audit trail you actually review.
- Limit data to the minimum necessary, de-identify for analytics and testing, and keep PHI out of logs.
- Sign a BAA with every vendor that touches PHI, and test your backups and breach runbook before you need them.
Have a project like this? Talk to our engineers.
