"HIPAA-compliant" is one of the most overloaded phrases in healthcare software. Marketing pages slap it on landing copy; clinics ask for it without a clear picture of what it means; vendors interpret it however they need to. So let's be specific.
This is the checklist we used to ship SmileLink — a dental patient app and clinic dashboard — and that we use as the baseline for every healthcare product we build. It's not a substitute for legal counsel or a third-party audit. But it's the engineering reality of what production HIPAA alignment looks like.
1. The legal scaffolding (before any code)
Business Associate Agreement (BAA)
If your app processes Protected Health Information (PHI) on behalf of a covered entity (the clinic), you are a Business Associate. That requires a signed BAA with the clinic and, separately, BAAs with every downstream subprocessor that touches PHI — your cloud provider, your database host, your email vendor, your push notification service, your error tracker.
What gets forgotten: a single subprocessor without a BAA can break your whole compliance posture. Inventory them all before you ship.
Data Processing Inventory
Document, in writing:
- Every PHI field you collect (name, DOB, treatment, photos, messages)
- Where it's stored, and in what region
- Who can access it, and through which interface
- How long it's retained
- How it's deleted on patient request
2. Encryption — in transit, at rest, in messages
The HIPAA Security Rule doesn't prescribe specific algorithms, but in 2026 there's a clear baseline:
- In transit: TLS 1.3 everywhere. No fallback to TLS 1.0/1.1. HSTS enabled on every PHI-bearing surface.
- At rest: AES-256 column-level encryption for PHI fields, not just disk-level. Disk encryption alone is not enough for "in the wrong hands" scenarios like dev access.
- Messages: patient ⇄ clinic chat needs end-to-end encryption — meaning the server can't decrypt content even if compromised. This is the bar SmileLink ships at.
- Keys: KMS-managed, rotated, with separate keys per environment.
3. Authentication and access control
Patient-side
- Per-account login, never a shared "clinic kiosk" account for patient access
- MFA available, mandatory for password reset
- Session timeouts (30 min idle is a reasonable default)
- Device-level biometric unlock on the mobile app
Clinic-side
- Role-based access control (RBAC) with minimum required scope per role — front-desk doesn't need access to clinical notes
- SSO support for clinic networks
- Forced MFA for any role that can read PHI in bulk
- Per-clinic data isolation enforced at the database level, not just the application layer
4. Audit logging
HIPAA requires you to know who accessed what PHI, when, and from where. In practice:
- Every read of a PHI field is logged with user, timestamp, IP, and the specific record ID
- Every write is logged with before/after diffs (or pointers to versioned data)
- Logs are immutable — append-only storage, separate from the operational database
- Retention typically 6 years to align with the HIPAA Privacy Rule
5. Data minimization in practice
"Collect the least PHI you need to do the job" sounds obvious; it's the easiest principle to violate at scale. A few concrete patterns:
- Don't store insurance card scans on the app server if your downstream PMS already has them — pass through
- Strip PHI from error tracking. Sentry-style services see your stack traces; make sure they don't see patient names
- Pseudonymize PHI in analytics. Aggregate counts are fine; individual identifiers don't belong in a BI tool
- Don't log full request bodies in production. Log enough to debug, never more
6. Patient rights — the operational side
HIPAA gives patients real rights: access to their data, correction, an accounting of disclosures, and the right to revoke consent. Your app needs operational workflows for each:
- A documented process for fulfilling access requests within 30 days
- A "delete me" path that actually works end-to-end, including in backups (typically a tombstone strategy, since immediate hard-delete fights audit retention)
- An accounting log of who saw what, including any third-party disclosures
7. The breach response plan
You will, at some point, have an incident. The Security Rule requires:
- A documented incident response process
- Defined roles — who decides if it's a breach, who notifies the clinic, who contacts patients
- Breach notification within 60 days (typically faster in practice)
- Annual tabletop exercises
8. Vendor / subprocessor list (the part nobody publishes)
A practical production stack we've used:
- Cloud: AWS or GCP — both offer signed BAAs and HIPAA-eligible services
- Database: Postgres on a HIPAA-eligible managed service
- Email: a HIPAA-aligned transactional email provider (not the consumer-grade default)
- SMS: Twilio with their HIPAA-eligible configuration and a BAA
- Push: APNs / FCM — neither carries PHI in payloads, only pointers, since neither provider signs BAAs at this layer
- Observability: a HIPAA-aligned error tracker with PHI scrubbing
9. What "HIPAA-aligned" means at Leyoxa
We use the phrase "HIPAA-aligned" rather than "HIPAA-compliant" deliberately. Compliance is a status that comes from the operator side — the covered entity, their policies, their training, their physical safeguards. We can build infrastructure that supports compliance end-to-end. Calling it "aligned" keeps that line honest.
10. The Canadian counterpart: PHIPA
For our Toronto partners, PHIPA (Ontario's Personal Health Information Protection Act) is the equivalent framework. Most of the operational controls above carry over — the differences are mostly in terminology and in the data residency preference for Canadian health information custodians. We host Canadian-bound workloads in Canadian regions.
Where Leyoxa fits
The checklist above is the engineering side of what we shipped with SmileLink. If you're a clinic operator or healthcare-adjacent founder and you want a patient app you can actually defend in a security review — not a marketing claim — book a 30-minute discovery call. The session is with the engineer who builds it.