How to Build HIPAA-Compliant Software
HIPAA compliance is an engineering problem before it is a legal one. The Security Rule reads like a requirements document once you stop treating it as legal text. Here is how to implement it.
The Security Rule reads like a requirements document once you stop treating it as legal text. Administrative, physical, and technical safeguards are its three categories; risk analysis is the named foundation; what covered entities and business associates must do to protect electronic PHI (ePHI) is spelled out in terms an engineer can act on. The compliance posture follows from treating those specifications as engineering requirements from the start. Off-the-shelf "HIPAA compliance software" does not make a product compliant; the obligations attach to how the system is engineered.
Retrofitting compliance onto a system not designed for it is expensive and structurally incomplete.
The short version
- HIPAA-compliant software is built by implementing the Security Rule as engineering requirements across administrative, physical, and technical safeguards, not by buying an off-the-shelf compliance product.
- The technical safeguards an engineering team owns are encryption (TLS in transit, AES-256 at rest), role-based access with minimum-necessary defaults, automatic session timeout, tamper-evident audit logging, and unique user identification.
- Every vendor that touches protected health information (PHI) needs an executed Business Associate Agreement before data flows, including cloud providers, video SDKs, email or SMS services, and analytics tools.
- There is no official HIPAA certification for software; the HHS Office for Civil Rights audits covered entities against the rules but does not certify products.
- A consumer wellness app with no provider, plan, or claims flow in the data path is often outside HIPAA, and the FTC Health Breach Notification Rule may apply instead.
- A formal risk analysis is the named foundation, and it is a living document that must be updated whenever the system changes.
Who HIPAA actually covers: the honest carve-out
HIPAA applies to covered entities (healthcare providers that conduct electronic transactions, health plans, and healthcare clearinghouses) and to business associates: vendors and contractors who create, receive, maintain, or transmit protected health information (PHI) on behalf of a covered entity.
The carve-out worth stating clearly: a consumer wellness app with no provider, plan, or claims flow in the loop is often not a covered entity and not a business associate. A meditation app, a step counter, or a symptom journal that stores data locally or in a user-controlled account, without any data flowing to a covered entity or being used for healthcare transactions, may not be subject to HIPAA at all. The FTC Health Breach Notification Rule likely applies instead for apps in that category that collect personal health records. Knowing whether HIPAA applies to a specific product is the first question, and the answer is not always yes.
When a covered entity does enter the picture (the app exchanges data with a provider, supports clinical workflows, receives insurance-adjudicated data, or operates within a health system's ecosystem), the HIPAA obligations are real and the engineering work to meet them is significant.
Three safeguard categories, read as requirements
The Security Rule organizes requirements into three safeguard categories, which fall to different owners in a cloud build.
| Safeguard category | What it protects | Who owns it in a cloud build | Representative controls |
|---|---|---|---|
| Administrative | Organizational processes and people | Security officer and leadership | Risk analysis, workforce training, access-management policy, incident evaluation |
| Physical | Facilities, servers, workstations, and media | Cloud provider for the data center, your team for workstations and credentials | Facility access controls, workstation security, media disposal |
| Technical | The software and the data it holds | Engineering team | Encryption, access controls, audit logging, automatic session termination, unique user IDs |
Administrative safeguards are the organizational layer: a designated security officer, a workforce training program, documented access management policies, a process for evaluating security incidents, and a formal risk analysis that is reviewed and updated on a defined schedule. The risk analysis is not a one-time document; it is a living artifact that evolves as the system changes.
Physical safeguards cover physical access controls for servers and devices that handle PHI, including workstations. For cloud-hosted applications, the cloud provider's physical controls cover the data center layer, but the engineering team still owns policies for developer workstations, where production credentials are stored, and how media is disposed of when decommissioned.
Technical safeguards are the engineering team's primary domain: encryption, access controls, audit logging, automatic session termination, and unique user identification. These are software requirements.
Technical safeguards in practice
Encryption means TLS for everything in transit (including internal service-to-service communication, not only client-facing endpoints) and AES-256 (or equivalent) for data at rest: databases, backup files, object storage buckets, and any export files that leave the system. Encryption at rest on a shared database where all application roles have full read access is a misconfiguration that satisfies the letter but not the purpose.
Role-based access with minimum-necessary defaults means a clinician role can read patient records for their care panel; an admin role can manage user accounts but not access clinical data; an audit role can read logs but not PHI. The minimum-necessary standard in HIPAA translates directly to least-privilege in system design. Default-allow access models are wrong for PHI.
Automatic session termination means enforced idle timeouts on clinical sessions, beyond cookie expiry alone. A 15-minute inactivity lock is standard in clinical environments; session termination must be enforced server-side, not only at the browser layer.
Tamper-evident audit logs record every access to PHI: who made the request, which patient record was accessed, what operation was performed, and when. The log must be write-once; application code should not be able to modify or delete audit entries. Read events matter as much as write events; the purpose of audit logs is to detect both unauthorized access and data exfiltration.
Unique user identification means no shared accounts. Every user must have an individual credential. Without it, the audit trail is meaningless.
BAAs and the vendor chain
Every vendor that handles PHI on behalf of a covered entity must have an executed Business Associate Agreement before PHI flows through their systems. The major cloud providers all offer BAAs: AWS, GCP, and Azure sign BAAs for their healthcare customers, but the scope matters. Not every service in a cloud provider's catalog is covered by that BAA, and the specific services handling PHI must fall within the covered scope.
Video SDK vendors for telemedicine (Vonage Video, Zoom Video SDK, Daily) require BAAs before PHI appears in session metadata or recording storage. Email delivery and SMS services that carry PHI-bearing content follow the same logic.
The analytics SDK trap catches teams often. A crash reporter or product-analytics SDK ships event data to a third-party server and can transmit PHI via indirect paths: session IDs tied to user accounts, user properties set during login, or custom events that include health-adjacent fields. If the analytics vendor does not offer a BAA, that is an unauthorized disclosure. A few analytics vendors offer BAAs on enterprise plans (e.g. Mixpanel, Amplitude); Google Analytics, at any tier, does not, so it cannot sit in a PHI path. The fix: vet and execute a BAA, use a self-hosted analytics tool, or strip PHI-adjacent fields before transmission.
For a deeper look at the vendor chain in telemedicine specifically, including video SDKs and HIPAA obligations per session component, see telemedicine app development.
Process obligations
Risk analysis is the required foundation. It must identify PHI the organization creates, receives, maintains, or transmits; assess threats and vulnerabilities; evaluate controls; and determine risk levels, reviewed whenever the environment changes.
Policies and procedures must document how each safeguard is implemented; OCR audits ask for it. Training must reach every workforce member who handles PHI, including developers with production access.
Incident response and breach notification. When a breach of unsecured PHI occurs, the covered entity has 60 days from discovery to notify affected individuals. Breaches affecting 500 or more individuals in a state require media notification in that state. All breaches must be reported to HHS; those under 500 individuals may be logged and reported annually.
A build checklist
- TLS on all connections, including internal service-to-service; reject TLS 1.0/1.1
- AES-256 encryption at rest for databases, object storage, and backups
- Role-based access with least-privilege defaults; no shared accounts
- Automatic session idle timeout enforced server-side (not only client-side)
- Tamper-evident audit logs: every PHI access logged with user, record, operation, timestamp
- BAA executed with every vendor that may receive PHI: cloud provider (service-scope verified), video SDK, email/SMS, error tracking, analytics
- Analytics and crash-reporting SDKs reviewed for PHI transmission paths; PHI-adjacent fields stripped or self-hosted alternative used
- Unique user identification enforced; no service accounts with human-user access
- Formal risk analysis document written and in version control
- Documented access management policy and workforce training record
- Incident response plan defining breach detection, containment, 60-day notification timeline
AddMed: compliance through pilot deployments
AddMed, a medication management platform connecting patients with care teams, ran HIPAA and GDPR compliance requirements in parallel throughout its pilot deployments. The platform handles medication schedules, adherence data, and bidirectional EMR sync via HL7/FHIR. Full HIPAA and GDPR compliance was maintained throughout pilot programs with zero data incidents, including the bidirectional sync path where PHI moves between the app and clinical systems. The bidirectional sync architecture is covered in the AddMed case study.
For teams scoping a healthcare software build (whether the build runs as a standalone product or a custom software development engagement), our approach to healthcare software development starts with the same foundation: identify the PHI the system will handle, map the vendor chain, and design the access and audit layers before the first line of application code.
Frequently asked questions
HIPAA-compliant software implements the Security Rule's three safeguard categories: administrative (documented policies, workforce training, designated security officer), physical (physical access controls for servers and devices, media disposal), and technical (encryption, access controls, audit logging, automatic session termination, unique user identification). It also operates under executed Business Associate Agreements with every vendor that handles PHI on the covered entity's behalf.
No. There is no government-issued HIPAA certification and no official certification body. The HHS Office for Civil Rights audits covered entities and business associates against the rules; it does not certify products. Third-party assessors offer HIPAA readiness audits that evaluate whether a system's controls are consistent with the Security Rule, but these are not certifications in the regulatory sense. Any vendor claiming to sell 'HIPAA-certified software' is using the term loosely.
HIPAA applies when a covered entity (a healthcare provider that conducts electronic transactions, a health plan, or a healthcare clearinghouse) or a business associate creates, receives, maintains, or transmits protected health information. A consumer wellness app with no provider, plan, or claims flow in the data path is often not a covered entity and not a business associate. The FTC Health Breach Notification Rule may apply instead. The analysis turns on whether the data flowing through the application is PHI and whether the entity handling it falls within HIPAA's definitions.
A Business Associate Agreement (BAA) is a contract required by HIPAA between a covered entity and any vendor that handles PHI on its behalf. The BAA establishes what the vendor may do with PHI, requires them to implement appropriate safeguards, and sets obligations around breach notification. Cloud providers (AWS, GCP, Azure), video SDK vendors, email services, and analytics platforms that receive PHI all need executed BAAs. A vendor that does not offer a BAA cannot be used in a context where PHI may flow through their systems.
If a vendor that has an executed BAA experiences a breach, the Breach Notification Rule requires the business associate to notify the covered entity without unreasonable delay and no later than 60 days from discovery. The covered entity then has 60 days from discovery to notify affected individuals, and for breaches affecting 500 or more individuals, must notify HHS and the media in the affected states. If the vendor did not have a BAA, the covered entity is directly exposed for the unauthorized disclosure; a vendor that was in fact functioning as a business associate can face direct liability as well under HITECH.
More from the journal
Clinical Trial Management Software: How It's Built
Clinical trial management software runs the operational side of a trial. Here's where it sits among EDC and eTMF, the data model, CDISC integration, 21 CFR Part 11, and what it takes to build.
Healthcare Data Analytics: Architecture and How to Build It
Healthcare data analytics turns clinical, claims, and device data into decisions. Here's the four types, the reference architecture, HL7/FHIR integration, HIPAA de-identification, and the ML pipeline behind it.
EHR vs EMR: The Difference and Why It Matters
EMR is a single practice's digital chart. EHR is a longitudinal record designed to move between organizations. Here is how the terms differ, where PHRs fit, and why the distinction shapes every patient-facing integration.