Almost every founder who plans a telemedicine product asks the same question first: how do we make it HIPAA compliant? The honest answer is that software on its own is never "HIPAA compliant." HIPAA applies to organizations, specifically covered entities (such as providers and health plans) and their business associates. An app can support compliance or make it very hard, but compliance itself depends on how the whole organization builds, hosts, operates, and documents the system.
This guide explains what that means in practice for a telemedicine app: what the Security Rule requires, how its technical safeguards turn into features, where video and cloud vendors fit, and which mistakes most often put patient data at risk. It is written for founders and product owners in the United States. It is not legal advice, so have a healthcare attorney review your specific situation.
Who HIPAA applies to, and where your app fits
HIPAA's rules apply to covered entities and their business associates. Under the regulation's definition in 45 CFR 160.103, a business associate is a person who "creates, receives, maintains, or transmits protected health information" on behalf of a covered entity. The definition explicitly includes subcontractors that do the same for a business associate.
That produces three common setups:
- A clinic or practice builds an app for its own patients. The practice is the covered entity. Vendors that handle patient data for it, such as hosting, video, and messaging providers, are business associates.
- A digital health company delivers telemedicine on behalf of providers, plans, or health systems. It is often a business associate. If it operates as a health care provider itself, it may be a covered entity.
- A direct-to-consumer wellness product that is neither. It may fall outside HIPAA, but other laws, including FTC rules and state privacy laws, can still apply. This is a question for counsel, not a developer.
The same logic applies to your development partner. Whether a software agency is a business associate depends on whether it creates, receives, maintains, or transmits protected health information. A team that writes code and never touches production data is in a different position from one that also hosts and supports the live system. Settle that in writing before work starts.
What the Security Rule actually requires
The Security Rule protects electronic protected health information (ePHI) through administrative, physical, and technical safeguards. A few points matter most to anyone building the product.
Risk analysis comes first. 45 CFR 164.308(a)(1)(ii)(A) requires an "accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity, and availability" of ePHI. It is labeled Required, and the other safeguard decisions are made in light of it.
"Addressable" does not mean optional. Under 45 CFR 164.306(d), for an addressable specification you must assess whether it is reasonable and appropriate. If it is, you implement it. If it is not, you document why and implement an equivalent alternative where reasonable. Encryption is addressable in the current text, but skipping it in a telemedicine app would be very hard to justify.
The rules may tighten. In January 2025, HHS proposed a Security Rule update that would remove the required/addressable distinction and require measures such as encryption and multi-factor authentication, with limited exceptions. As of mid-September 2026, the published text of 45 CFR 164.312 still lists encryption as addressable, so the proposal has not taken effect. Build to the stricter standard anyway. Adding multi-factor authentication and encryption to a live product is more expensive than designing them in.
Turning the technical safeguards into features
Section 164.312 lists five standards. Here is what each tends to mean in a telemedicine build.
Access control
The rule calls for technical policies that "allow access only to those persons or software programs that have been granted access rights."
- Unique user IDs with no shared logins (Required).
- Role-based permissions that separate patients, clinicians, front-desk staff, and administrators, with each role seeing only what it needs.
- Automatic logoff after inactivity (Addressable), with shorter timeouts on shared or clinical workstations.
- An emergency access procedure (Required), so authorized staff can reach needed data when the normal path fails.
- Encryption of data at rest (Addressable): databases, file storage, and backups.
Audit controls
You need mechanisms that "record and examine activity" in systems that contain ePHI. In practice, log who viewed, created, changed, or exported which patient record and when, along with logins, failed logins, and permission changes. Keep logs tamper-resistant, restrict who can read them, and keep patient data itself out of the log lines.
Integrity
Protect ePHI from improper alteration or destruction. Version clinical notes instead of overwriting them, enforce constraints in the database, verify uploaded documents, and test backups by actually restoring them.
Person or entity authentication
You must verify that the person seeking access is the one claimed. That means strong password rules, multi-factor authentication (especially for clinicians and administrators), and account recovery flows that cannot be abused, since recovery is a common weak point. Patient identity verification should match your clinical workflow.
Transmission security
Guard against unauthorized access to ePHI in transit. Use TLS on every connection, including service-to-service traffic and mobile API calls, keep protocol versions current, and never put patient data in URLs or query strings, because those end up in logs and browser history.
Video visits: the part everyone asks about
Video is the defining feature of a telemedicine app and the source of most vendor questions. There are two realistic approaches.
- Use a video platform or API from a vendor that will sign a business associate agreement (BAA). This is faster, but you rely on the vendor's controls. Review whether it records sessions, what metadata it keeps, and where media is processed.
- Run your own real-time infrastructure, such as WebRTC signaling, TURN, and media servers. This gives full control, and it also makes you responsible for operating and securing a real-time media stack. It only makes sense with a team that can run it.
Either way, make the following decisions on purpose rather than by default: recording should be off unless there is a clinical or legal reason; session links should be single-use and authenticated; and you should know what happens to chat messages and files shared during a call.
One trap deserves a mention. During the COVID-19 public health emergency, HHS's Office for Civil Rights said it would not penalize good-faith telehealth delivered over ordinary consumer video apps. That flexibility ended: the transition period expired at 11:59 p.m. on August 9, 2023. A product built today should not rely on it.
Hosting and vendors: BAAs all the way down
HHS's guidance on HIPAA and cloud computing explains that a cloud service provider that maintains ePHI for a covered entity or business associate is itself a business associate. That holds even when the provider stores only encrypted data and has no decryption key, an arrangement HHS calls "no-view services". So your hosting provider needs a BAA.
So does every other service that could receive patient data. Map your whole vendor chain:
- Cloud hosting and managed databases
- Video and messaging providers
- SMS, email, and push notification services
- Error monitoring, logging, and analytics tools
- Backup, storage, and customer support platforms
A BAA does not make a service compliant. It sets responsibilities, and you still have to configure the service correctly. Cloud providers typically limit a BAA to specific services, so confirm that every service you actually use is covered.
Mistakes that cause real problems
- Patient data in logs and error trackers. A stack trace that captures a request body can copy clinical details into a system that was never meant to hold them.
- Third-party scripts and SDKs in logged-in areas. Regulators and courts are still working out how HIPAA applies to analytics and tracking tools. Treat every script or SDK in a patient-facing app as a data-sharing decision, and either get the right agreement in place or leave it out.
- Clinical detail in push notifications, emails, and texts. Lock screens and inboxes are not secure. "You have a new message" is safer than the message.
- Real patient data in development and staging. Use synthetic data.
- No offboarding. Former staff and contractors keep access longer than anyone realizes.
- Forgotten backups and exports. They need the same encryption, access control, and retention thinking as production.
- No incident response plan. Decide who does what before something happens, not during.
- Treating a vendor's "HIPAA compliant" badge as due diligence. It is a starting point for questions, not an answer.
Compliance is more than code
Software supports compliance, but much of it lives outside the codebase: the risk analysis, written policies, workforce training, vendor agreements, incident response, and documentation. For a practical framework, NIST's SP 800-66 Revision 2, published in February 2024, maps Security Rule requirements to NIST controls and is a solid starting point for a risk analysis.
A pre-launch checklist
- A documented risk analysis that covers the app and its infrastructure
- A BAA with every vendor that can touch patient data, covering the specific services in use
- Role-based access, unique accounts, multi-factor authentication, and session timeouts
- Encryption in transit and at rest, including backups
- Audit logs for record access and administrative actions, with no patient data inside them
- Video settings reviewed: recording, link expiry, and metadata retention
- No patient data in logs, error trackers, analytics, or notifications
- Synthetic data in every non-production environment
- A tested backup and restore process
- A written incident response plan and named owners
- An independent security review before real patients use the product
Questions to ask a development partner
If you are hiring a team to build the app, these questions tell you a lot:
- Will you or your subcontractors ever access production data, and will you sign a BAA if so?
- How do you keep patient data out of logs, error trackers, and test environments?
- How are audit logs designed, and who can read them?
- Which third-party services will the app use, and does each offer a BAA where one is needed?
- How are roles, multi-factor authentication, and session timeouts implemented?
- Who owns the source code and the cloud accounts?
- How will security be tested before launch?
Frequently asked questions
Does a telemedicine app need a business associate agreement?
If a vendor creates, receives, maintains, or transmits ePHI on your behalf, expect to need one. That usually includes hosting, video, and messaging providers. Whether a specific vendor qualifies depends on the facts, so confirm it with counsel.
Is encryption legally required?
In the current text of the Security Rule, encryption is an addressable specification, which means you must assess it and either implement it or document a reasoned alternative. HHS has proposed making it a firm requirement, and in a telemedicine app it is effectively expected either way.
Can we use a consumer video app for patient visits?
Not on the strength of the pandemic-era flexibility, which ended on August 9, 2023. The right choice depends on the vendor's role and whether it will sign a BAA, so evaluate video vendors as business associates.
Does HIPAA apply to a direct-to-consumer telehealth or wellness app?
It depends on whether the company is a covered entity or a business associate. An app that is neither may fall outside HIPAA but can still be subject to other laws, such as FTC rules and state privacy laws. Ask a healthcare attorney early.
Planning a telemedicine product?
If you are scoping a telemedicine app and want a second opinion on architecture, vendor choices, or where to start, you can book a strategy call with Sabyrix to talk through your requirements. Our telemedicine development page describes what we build, our security and HIPAA approach explains how we think about safeguards, and if your product needs to read or write clinical records, see our notes on EHR and EMR integration. Teams starting from an idea can also look at healthcare MVP development.
Sabyrix does not provide legal advice, and HIPAA compliance always depends on your own organization's processes, contracts, and applicable requirements.