Before the checklist, one thing has to be clear, because the industry blurs it constantly: HIPAA is not something software alone can be. It covers your organization's policies, staff training, risk assessments and contracts as much as your code. Software can support those obligations and document how — but certification, audits and business associate agreements sit with your organization, not with a build.
This is an engineering checklist: the technical safeguards a telehealth app should be built with so that it supports HIPAA rather than working against it. It is not legal advice, and it doesn't replace a review by someone qualified to give it. Treat it as the list we work through when we build for regulated healthcare.
Encryption, everywhere
- In transit. All traffic over TLS — the app, the APIs, and the video signalling. No exceptions, no plain HTTP anywhere in the path.
- At rest. Databases, backups, file storage and logs encrypted. A backup is protected health information (PHI) too, and it's the copy people forget.
- Video. Consultation media encrypted end to end where the architecture allows, and never written to disk unencrypted.
Encryption is the cheapest safeguard to design in and one of the most expensive to retrofit, because it touches storage and transport across the whole system.
Access control and the minimum-necessary principle
- Role-based access. A receptionist, a clinician and an administrator see different things. Access is granted by role, not by "everyone who's logged in."
- Minimum necessary. Each role sees only the PHI it needs to do its job — not the whole record because that was easier to build.
- Unique identities. Every user has their own account. Shared logins make audit logs meaningless.
- Strong authentication. Enforced password policies and multi-factor authentication for anyone who can reach PHI.
- Automatic session timeout. An unattended device shouldn't leave a record open.
Access control is the safeguard that most shapes your data model, which is exactly why it has to be designed in from the start — adding it later is close to a rewrite.
Audit logging that answers "who saw what, when"
Every access to PHI — viewed, created, changed, exported — should be logged with the user, the record, the action and the timestamp. The log has to be tamper-resistant and retained. When a question about inappropriate access arises, this log is the only thing that can answer it, and it can't be reconstructed after the fact. Build it in on day one.
Business associate agreements with every vendor that touches PHI
This is the item most often missed, and it's not a software feature — it's a contract. Any third party that stores, processes or transmits PHI on your behalf needs a business associate agreement (BAA) in place. That commonly includes:
- Your cloud hosting provider
- The video infrastructure provider
- SMS and email services that carry appointment or health information
- Analytics or logging services, if PHI could reach them
- Any AI or transcription service processing consultation content
Two practical consequences: choose vendors that will actually sign a BAA (not all will), and keep PHI out of any service you don't have one with — which usually means being deliberate about what your analytics and error-logging tools are allowed to capture.
Data minimization and de-identification
- Collect only the PHI the service genuinely needs.
- Keep analytics and product metrics on de-identified data — you can measure usage without funneling patient identifiers into a general-purpose analytics tool.
- Have a retention and deletion policy, and build the mechanics to honour it.
Breach readiness, backups and recovery
- Breach notification. The technical means to detect and investigate a suspected breach — which comes straight back to your audit logs — and an organizational plan for the notification obligations that follow.
- Backups. Regular, encrypted, and tested by actually restoring them. An untested backup is a hope.
- Disaster recovery. A defined path back to service, because availability of records is part of the obligation too.
The checklist, condensed
| Area | What "built for it" looks like |
|---|---|
| Encryption | TLS in transit; encrypted at rest, including backups and logs |
| Access control | Role-based, minimum-necessary, unique IDs, MFA, timeouts |
| Audit logging | Tamper-resistant record of every PHI access, retained |
| BAAs | Signed with every vendor that touches PHI |
| Data minimization | Collect less; de-identify analytics; retention policy |
| Breach readiness | Detection, investigation, tested backups, recovery plan |
What software can and can't do for you
A well-built telehealth app can enforce these technical safeguards and produce the evidence that you're meeting your obligations. What it can't do is be your compliance: the risk assessments, the workforce training, the policies, and the BAAs are organizational work that no amount of good engineering replaces. The right build makes that organizational work easier to satisfy and easier to prove — which is the honest goal to aim for.
We build telemedicine and health platforms to these technical requirements — encryption, access control and audit trails designed in from the start — while being clear about where software ends and your organization's compliance program begins. Tell us about your telehealth project.
Related: Telemedicine app development · Healthcare software development · Telemedicine app features checklist