Most HIPAA guides for developers are written by people who have never had to decide whether a Redis instance holding session data is in scope. They give you the three-safeguard taxonomy, tell you to encrypt everything, and stop. This is the checklist we work from when we architect a system that will hold PHI.
Two caveats before the detail. This covers the Security Rule — the engineering half; the Privacy Rule, workforce training, policies and your risk analysis are organizational work no codebase satisfies. And there is no such thing as a HIPAA-certified app, developer, or cloud. What exists is a system built to satisfy the safeguards, operated by an organization that can evidence it. If a vendor sells you the word "certified", they have told you something useful about the vendor.
If you are not sure HIPAA applies to you at all, start with do fitness and wellness apps need HIPAA compliance — building these controls when you are not a business associate is expensive and pointless.
Scope first: draw the PHI boundary before you write code
The most valuable hour in a HIPAA build is the one where you draw the line around which components touch PHI. Everything downstream — cost, complexity, which vendors you can use — follows from how tightly you draw it.
Work component by component and label each one in scope, adjacent, or out. In scope means identifiable health data lives there or passes through it. Adjacent means it could see PHI under some failure mode. Out means it provably cannot.
The components teams forget:
- Logs and log aggregation. A request body logged at debug level is PHI in a third-party log service.
- Error and crash reporting. Stack traces carry local variables. Breadcrumbs carry screen names and IDs.
- Message queues, caches and search indexes. Ephemeral is not out of scope. Redis holding a serialized patient object is in scope, and a search cluster with patient names is a second PHI store with its own access model.
- Backups, snapshots, and read replicas. Including the database dump on someone's laptop from the migration.
- Email and SMS providers. An appointment reminder naming a clinic and a procedure is a disclosure.
- Support tooling. The admin panel where support can impersonate a user is the highest-risk surface in most products.
- CI/CD. If test fixtures came from a production dump, your CI system is in scope.
- AI/LLM providers. Sending a clinical note to a model API is a disclosure to a vendor who needs a BAA and terms that exclude training on your data.
The engineering goal is to make this list shorter, not to secure a long one. Every component you can move out of scope removes a BAA, a control, and an audit finding.
Which cloud services are actually in scope
AWS, Google Cloud, and Azure all offer BAAs. None of them cover their entire catalog. Each publishes a list of services eligible under its BAA, and using an ineligible service for PHI is a straightforward violation regardless of how you configured it.
The rule for engineers is simple and worth enforcing in review: before a new managed service enters the PHI boundary, check it against the provider's current eligible-services list. This is a five-minute check that prevents a rearchitecture. The services that most often trip teams up are newer AI/ML offerings, edge and preview products, and anything in a region the BAA does not cover.
Firebase deserves its own paragraph because so many health MVPs start there. Google offers BAA coverage for a subset of Firebase services and explicitly not for others, and the popular ones are split across that line. Firebase Analytics in particular is the classic finding: it is in the app by default, it ships identifiers, and it is not somewhere PHI belongs. If you build on Firebase, check the current covered-products list service by service, and configure rather than assume.
A BAA with your cloud provider covers the provider's obligations. Everything above the hypervisor — your IAM policy, your network design, your application logic, your operational practices — is yours. Signing a cloud BAA is the beginning of the work.
Encryption: in transit, at rest, and the third one
In transit. TLS 1.2 minimum, 1.3 where you can. Enforce it end to end, not just at the edge — internal service-to-service traffic inside a VPC still counts, and "it's a private subnet" is not an argument that survives a risk analysis. HSTS on web. Certificate pinning on mobile if your threat model includes hostile networks, with a plan for rotating pins that does not brick shipped clients.
At rest. Platform-native encryption on databases, object storage, snapshots, and backups. Customer-managed keys where the client requires key control. Encrypt the backups specifically — the unencrypted nightly dump in a second bucket is a recurring finding.
Application level, for the fields that warrant it. This is the one teams skip and the one that changes the blast radius of a compromise. Envelope-encrypting the small set of genuinely sensitive fields — free-text clinical notes, messages, uploaded documents — with keys held in a KMS means a database compromise yields ciphertext. It costs you the ability to query those fields, which is exactly the design conversation worth having early.
For Patient Talker the requirement went further: end-to-end encryption on patient communication, so the server holds ciphertext it cannot read, with a third-party security assessment as a condition of release. That is a real constraint, not a marketing line — E2E means no server-side search over message content, no server-side moderation, and a key-recovery design you have to get right or users lose their history. Decide in week one; it is not a feature you add later.
On mobile: use the platform keystore (iOS Keychain with an appropriate accessibility class, Android Keystore) for tokens and keys. Do not put PHI in UserDefaults, SharedPreferences, or an unencrypted SQLite file. Set the correct data protection class on files, and redact screens showing PHI in the app switcher.
Audit trails: log the read, not just the write
Most application logging records mutations. HIPAA cares about access. Every read of one person's data by another person is an event you need to be able to reconstruct.
A workable audit record contains: who (authenticated principal, not a shared service account), what (record type and identifier), when (server time, UTC), where from (IP, client), what action (view, export, print, share), and the outcome. Append-only storage, separate from the application database, with retention matching your client's policy.
Design consequences that follow from that:
- No shared credentials. If your admin panel authenticates as
admin, your audit log is worthless. - Service accounts need attribution. When a background job reads patient records, log the initiating user or the job identity, not just "system".
- Exports and downloads are the highest-value events. A bulk export is what matters in an investigation. Log it loudly and alert on it.
- Do not put PHI in the audit log. Log the record ID, not the record. Otherwise the audit log is a second PHI store with weaker controls.
- An unlogged read of patient data is a defect. We treat it as one in code review, and we say so on our trust page.
This is easiest to enforce at the data-access layer — a repository wrapper that emits the audit event as a side effect of the read — rather than as something each endpoint remembers to do. If you are retrofitting audit logging into an existing product, that is worth a conversation before you start; the pattern you pick determines how much of the codebase you have to touch.
Access control and session handling
Role-based access with least privilege, scoped to the minimum necessary for the function. In a clinical product this usually means more than roles: a clinician can see their patients, not all patients, which is row-level authorization and needs to be enforced server-side on every query. Client-side filtering is not access control.
Session handling specifics that come up in every security review:
- Automatic logoff. The Security Rule expects sessions to terminate after a period of inactivity. There is no single mandated duration; pick one justified by your risk analysis and your users' environment — a shared clinic workstation warrants a much shorter timeout than a patient's personal phone — and document why.
- Short-lived access tokens with refresh, and server-side revocation. A stolen token that cannot be revoked is an incident you cannot contain.
- Re-authentication for sensitive actions. Bulk export, permission changes, viewing a record outside the user's normal scope.
- MFA for anything with administrative or multi-patient access. This is now an expectation in every questionnaire we see, whatever the rule technically requires.
Also: production access for engineers. The honest position is that break-glass access sometimes has to exist. Make it deliberate — time-bound, approved, logged, alerted, and reviewed — rather than pretending nobody has it.
De-identification, and why your analytics probably are not
Safe Harbor de-identification requires removing eighteen categories of identifier and having no actual knowledge that what remains could re-identify someone. The categories engineers underestimate: IP addresses, device identifiers and serial numbers, URLs, biometric identifiers, full-face images, and all date elements finer than year.
Which means: a product-analytics event containing a device ID and a timestamp is not de-identified data. Neither is an "anonymous" user ID that maps back to a user in your own database — that is pseudonymized, a useful engineering control and not the same legal category.
If you need analytics on a PHI system, the workable patterns are a self-hosted stack inside your compliance boundary, an aggregate-only pipeline where identifiers are stripped before export, or expert determination if the data genuinely needs to be granular. Pick one deliberately. The default — dropping a third-party SDK into an authenticated health surface — is the most common serious finding we see, and third-party tracking on authenticated patient pages has been an active litigation area.
The three places PHI actually leaks
After the database is encrypted and the roles are right, incidents come from:
- Logs. Debug logging left on, verbose error handlers, request/response logging middleware, an SDK that captures network bodies by default. Fix: structured logging with an explicit field allow-list, and a redaction layer you test, not one you assume works.
- Support and admin tooling. Impersonation features, CSV exports, screenshots pasted into ticketing systems and chat. Fix: scope impersonation, log it, alert on export volume, and train the humans — this one is not solvable in code alone.
- Third-party SDKs. Analytics, session replay, ad attribution, crash reporting, chat widgets. Session replay on a clinical form is a catastrophic default. Fix: inventory every SDK, put each behind a flag, and exclude authenticated surfaces explicitly.
None of these are exotic. All of them are more likely than the attacker in your threat model.
What a build like this actually involves
The engineering work above is a scope change, not a plugin. In our experience it lands in the $25,000 full custom build band rather than the $12,000 MVP band, and the difference is mostly audit infrastructure, access-control depth, environment separation, and the QA and documentation that a customer's security review will ask for. We scope it in a planning sprint first — the Healthtech MVP Blueprint at $1,999 over seven days produces the sensitive-data inventory, the intended-use boundary, and the architecture options — because guessing at this scope produces a number that is wrong in both directions.
Ongoing matters as much as the build. Dependency updates, certificate rotation, log review, and access reviews are continuous obligations; that is what an app maintenance retainer from $1,000/mo and ongoing QA from $799/mo are for. A system that was secure at launch and unpatched for eighteen months is not a compliant system.
We build HIPAA-aware applications and we sign BAAs before touching a PHI environment. We do not issue certifications, we do not provide legal or regulatory sign-off, and we do not determine whether your product is a regulated medical device. Where a question needs a specialist, we say so in week one.
This is engineering guidance, not legal advice. The Security Rule is deliberately flexible and the correct implementation depends on a risk analysis specific to your organization. Have counsel and a qualified assessor review your program before you rely on it.
Bring us your architecture diagram and your vendor list and we will tell you which parts are in scope and what it takes to close the gaps. Get in touch.
Frequently asked questions
Is AWS or Google Cloud HIPAA compliant?
Neither is compliant on your behalf. Both will sign a BAA covering a specific list of eligible services, which is narrower than their full catalog. Everything you build on top — IAM, network design, application logic, logging, operations — remains your responsibility. Check the current eligible-services list before adding any managed service to a PHI system.
Can we use Firebase for a HIPAA app?
Partly. Google covers a subset of Firebase services under its BAA and explicitly excludes others, and the split does not follow intuition — Firebase Analytics in particular does not belong anywhere near PHI. If you build on Firebase, verify each service against the current covered-products list rather than treating the platform as a unit.
What session timeout does HIPAA require?
The rule requires automatic logoff but does not specify a duration. You pick one justified by your risk analysis and document the reasoning. A shared clinic workstation warrants minutes; a patient's personal phone with biometric unlock warrants considerably longer. Being able to explain the choice matters more than the number.
Do we need to encrypt data at the field level, or is disk encryption enough?
Disk and database encryption is the baseline. Field-level or envelope encryption for the genuinely sensitive fields — clinical notes, messages, documents — is what limits the blast radius if the database itself is compromised. It costs you queryability on those fields, so decide early rather than retrofitting.
How do we do product analytics without breaking compliance?
Either keep analytics inside your compliance boundary with a self-hosted stack, or build an aggregate-only export pipeline where identifiers are removed before data leaves the boundary and the aggregation is coarse enough to prevent re-identification. Dropping a third-party SDK onto authenticated health screens is the pattern that produces findings and lawsuits.
Does using an LLM API break HIPAA?
Sending PHI to any third party requires a BAA with that party and terms that prevent your data being used for model training. The engineering discipline that matters is not sending more than the task needs — de-identify or minimize the prompt rather than passing the whole record.
How long does it take to make an existing app HIPAA-ready?
It depends almost entirely on how the app was built. Apps that already separate identity from health data, avoid PHI in logs, and have server-side authorization take weeks. Apps with shared admin accounts, third-party SDKs everywhere, and no audit trail are usually a partial rebuild. An App Rescue assessment at $2,500 over ten days is the honest way to find out which one you have.