Written by:
Last Published:
21 October 2026
•
HIPAA compliant software development is the practice of designing, building and operating software so that electronic protected health information (ePHI) stays confidential, accurate and available, in line with the HIPAA Security Rule. It comes down to documented architecture decisions made early, not a feature added at launch.
This guide is for the people who sign off on architecture and budget: CTOs, product leads and the executives who answer for the risk. No legal tour. We go straight to the decisions that shape your data, audit trails, EHR integrations and cloud vendors, then pull them into one HIPAA compliance checklist your engineers can run in a design review.
Here is the confusion. HIPAA compliance is not a badge your product earns at launch. It is the building code, not the paint colour.
You can repaint a building in an afternoon, but you cannot repaint your way to load-bearing walls. Those get decided early, and they are expensive to move once people are living inside. (None of this is legal advice. Your counsel still gets the last word.)
HIPAA compliant software development means making a small set of architecture decisions early and documenting them: a risk analysis first, then encryption, role-based access, audit logging, controlled integrations and a business associate agreement (BAA) for every party that touches ePHI. Made at design time, these controls cost far less than retrofitting them. They are also the evidence that buyers, investors and insurers ask to see. The points below summarise each decision.
Because the cost lands on the business, not the codebase. Breaches are expensive, regulators issue settlements and penalties in the millions, and retrofitting controls into a live product costs more than designing them in. Compliance decisions are investment decisions, and they are cheapest at the start.
The numbers are not abstract. IBM's Cost of a Data Breach Report 2026 puts the global average at $4.99 million, a record high and 12% up on the previous year.
Regulators are not shy either. HHS publishes its resolution agreements and civil money penalties, and the recent list includes $3 million (Solara Medical Supplies, January 2025), $1.5 million (Warby Parker, February 2025) and $1.19 million (Gulf Coast Pain Consultants, December 2024). All three were Security Rule matters, and two followed phishing or hacking incidents.
Then there is the part nobody budgets for. Compliance turns up in commercial moments long before a regulator does. Healthcare buyers commonly send security questionnaires that ask for your risk analysis, BAA terms, encryption, access control, audit logging and incident response. Investors running due diligence on a funding round tend to look for a completed risk analysis, a register of signed BAAs and evidence that controls are in place.
Cyber insurers join the queue at quote and renewal. They ask about multi-factor authentication, tested backups and a written incident response plan, and gaps there can raise premiums or narrow cover. Plus, a team that can answer all three from documents it already has moves faster than one assembling the evidence under deadline. (Truth be told, that speed is the real return on doing this early.)
Three commercial points follow for anyone planning healthcare software development:
HIPAA applies to covered entities, such as providers and health plans, and to their business associates. If your software creates, receives, maintains or transmits ePHI for one of them, you are a business associate. The Security Rule then requires administrative, physical and technical safeguards, documented and kept current.
The HIPAA Security Rule sets out five technical safeguards in 45 CFR 164.312: access control, audit controls, integrity, person or entity authentication, and transmission security. Some specifications are required. Others are "addressable", and that word trips people up. Addressable does not mean optional.
You implement the measure if it is reasonable and appropriate, or you document why an equivalent alternative works better.
The paperwork matters as much as the code. Under 45 CFR 164.316, required documentation must be kept for six years from its creation or last effective date, whichever is later. If a decision is not written down, an auditor will treat it as if it was never made.
For the wider regulatory picture, including GDPR, our post on digital transformation in healthtech covers what sits beyond HIPAA.
A risk analysis is the required, documented assessment of risks and vulnerabilities to ePHI under 45 CFR 164.308(a)(1)(ii)(A). You identify where ePHI lives, list threats and vulnerabilities, rate likelihood and impact, and record corrective actions. It comes before the architecture, because it tells you which controls the design must include.
The HHS guidance on risk analysis does not prescribe one method, but it describes the elements any credible analysis includes:
The analysis feeds risk management: implementing security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level. Two neighbours sit in 45 CFR 164.308: regularly reviewing records of system activity (a required specification) and performing periodic technical and non-technical evaluation.
Is that just paperwork? Partly. It is also the structural survey you commission before you pour any foundations.
The current rule does not name penetration testing, and the HHS risk analysis guidance does not mention it either. But periodic evaluation and risk management are hard to evidence without technical testing. Scans, dependency monitoring and penetration tests are the usual proof that safeguards work as configured, not just as drawn.
For HIPAA compliant software development, a sensible default is to scan continuously, patch on a defined schedule, and test externally before major releases and after significant architecture changes. Record the findings and the fixes. Those records become part of your documentation.
Five decisions carry most of the weight: where ePHI lives, how it is encrypted, who can see which fields, how environments are separated, and what happens to data when it is no longer needed. Make them early. Retrofitting them into a live product is slower, costlier and riskier than designing them in.
Under the Security Rule, encryption and decryption sit under access control, and encryption for data in transit sits under transmission security. Both are addressable. In practice, skipping them is very hard to justify in 2026.
There is a second reason to encrypt. If ePHI was encrypted to the standard HHS expects, a breach involving that data can fall under a safe harbour, as HHS guidance on cloud computing explains. But encryption alone does not make you compliant. It does nothing for integrity, availability or your administrative safeguards.
A sound default:
Unique user identification and emergency access procedures are required specifications. Automatic logoff is addressable. That gives you the floor: no shared accounts, a documented emergency route, and sessions that do not stay open forever. The emergency route is often called "break glass": a tightly logged override that lets authorised staff reach a record when normal permissions would block them and time matters.
Then comes a design question. The HIPAA minimum necessary standard asks organisations to limit the information used, disclosed or requested to what a given purpose needs (disclosures for treatment are among the exceptions). In software terms, that means role-based access, field-level visibility and screens built around tasks, not around the whole patient record.
It matters most in products built around sharing. Jinga Life, a family health records app where records are shared with doctors while staying private, was built as a set of microservices (Node.js and Ruby on Rails) behind a Swift iOS app.
Splitting a product into services gives you natural places to enforce access rules. It also multiplies the connections you have to secure and log, which is why the access model has to be designed before the service boundaries are drawn. A billing clerk and a clinician should not see the same screen. They should not see the same API response either.
This is where good intentions leak. Production is locked down, then someone copies a database into staging to reproduce a bug. Or an error tracker captures a request body full of patient details. Or an analytics tool receives a free-text field.
Keep real ePHI out of development and test environments. Use synthetic or properly de-identified data instead. Scan logs, error reports and analytics payloads for identifiers, and treat any third-party tool that receives patient data as a vendor that needs its own agreement (more on that below).
HIPAA's six-year rule covers required documentation, such as policies, procedures and risk analyses. It does not replace the retention periods that apply to medical records themselves, which vary by jurisdiction. Define both, and define what deletion actually means for backups, replicas and search indexes. A record that disappears from the interface but survives in last year's snapshot has not been disposed of.
Platforms that hold documents and medical information for families and caregivers need to answer the retention question before launch, not after the first deletion request. VestaConnect, for example, runs on Google Cloud with PostgreSQL as the main database for user data, tasks, schedules and activity logs. Keeping activity logs alongside application data in one relational store is a design choice with retention consequences: any deletion rule you set for one has to be checked against the other.
Audit controls must record and examine activity in systems that hold ePHI. In practice, log who accessed what, when, from where and what they did, including reads, not just writes. Store logs separately from the application, protect them from tampering, and review them on a schedule, not only after an incident.
Good HIPAA audit logs answer one question quickly: who touched this record, and why? Reads matter most.
Most teams log changes to data by habit, because that is what debugging needs. HIPAA cares just as much about who looked. A door log that records renovations but not visitors is not much use.
A useful audit record usually holds:
Make the log append-only and keep it outside the reach of the people it records. Then alert on the patterns that matter: bulk exports, access outside normal hours, repeated denials, break-glass use.
Cloud adds a wrinkle: part of the evidence sits with your provider. HHS notes that HIPAA does not require cloud providers to supply security documentation or allow customer audits, so access has to be agreed in the BAA or service level agreement. Ask for log access and incident reporting terms before you sign, not during an incident.
Detection drives your deadlines too. The Breach Notification Rule expects notice without unreasonable delay and no later than 60 days after discovery. You cannot report what you cannot see. A good audit trail turns "we think something happened" into "here is exactly which records were touched".
On retention, the rule does not name a period for system logs. Many teams align them with the six-year documentation requirement as a conservative default. Confirm that with counsel, and check any local rules that apply.
For a structured way to map all this to controls, NIST SP 800-66 Rev. 2, the cybersecurity resource guide for implementing the Security Rule, is the reference most engineering teams end up using.
In a multi-tenant platform, one codebase and one infrastructure serve several customers, so a single flaw can expose every tenant's ePHI. HIPAA does not prohibit multi-tenancy, but access control and audit requirements apply to each customer's data. The design question is how strongly you isolate keys, data, access and audit trails per tenant.
Four decisions do most of the work:
A multi-tenant product is a block of flats, not a house: shared plumbing, a shared stairwell and a separate lock on every door.
Per-tenant variation is where these products usually struggle. A shared deletion job or log pipeline is simple to build and awkward to reconcile with ten different contracts.
Every EHR integration is a new route for ePHI, so it needs its own threat model. Prefer FHIR APIs with OAuth 2.0 scopes over file drops and point-to-point feeds, limit each integration to the minimum data it needs, and sign a business associate agreement with every party that touches the data.
Think of your product as a building and each integration as a new door. Nobody installs a door without deciding who holds the key and what the door opens onto. Integrations deserve the same question: who can walk through, and into which rooms?
FHIR is the modern default for exchanging health data. The SMART App Launch framework (currently version 2.2.0, built on FHIR R4) adds an OAuth 2.0 authorisation layer. Its scopes let you grant an app exactly the access it needs, for example read and search access to one resource type for the authorising user.
It also defines a Backend Services pattern for server-to-server integrations with no user in the loop. Older HL7 v2 feeds are still common, and they bring their own risk. The MLLP transport that carries them (a simple wrapper that sends HL7 v2 messages over a TCP connection) has no built-in encryption or authentication, so wrap those connections in a VPN or TLS tunnel and restrict them by network and by sender.
For each integration, write down:
Yes. If a cloud provider creates, receives, maintains or transmits ePHI for you, it is a business associate, and HHS states that using one without a business associate agreement (BAA) violates the HIPAA Rules. That holds even when the provider stores only encrypted data and does not hold the key.
A HIPAA compliant cloud setup starts with the agreement, not the architecture diagram.
A BAA is also where responsibilities get divided. HHS describes a shared model: the customer may own user authentication, the provider may own encryption, and the split depends on the agreement and each party's risk management. Write it down. Nobody wants to find out who owns patching in the middle of an incident.
A few practical points follow from that:
HHS publishes sample business associate agreement provisions. A compliant agreement sets out the uses and disclosures the business associate may make, and requires appropriate safeguards, including the Security Rule for ePHI. It requires reporting of unauthorised uses and disclosures, including breaches and security incidents.
It must also bind subcontractors to the same restrictions, require return or destruction of PHI at termination where feasible, and allow the covered entity to terminate for a material breach. Read it as an engineer would: each clause maps to something your system has to do, such as reporting, deletion or subcontractor control.
AI features deserve a special mention. A prompt containing a patient summary is ePHI in transit. Treat language model providers like any other vendor: agreement first, data second.
Use this Imaginary Cloud HIPAA architecture checklist in design reviews of any HIPAA compliant software development project, and as a gap check on products that are already live. The first column is the decision, the second is why HIPAA cares and the third is a sensible default. Required and addressable labels come from 45 CFR 164.312. The rest map to the Security Rule's administrative requirements, the Privacy Rule, the Breach Notification Rule and the documentation rules.
| Decision | Why HIPAA cares | Sensible default |
|---|---|---|
| Risk analysis | Required (164.308(a)(1)(ii)(A)) | Documented analysis before design; reviewed after incidents, vendor changes and major releases |
| Vulnerability and penetration testing | Supports periodic evaluation and risk management | Continuous scanning, scheduled patching, external testing before major releases |
| Unique user identification | Required specification (access control) | Individual identities through SSO; no shared logins; service accounts scoped and rotated |
| Emergency access | Required specification (access control) | Documented break-glass role with extra logging and after-the-fact review |
| Automatic logoff | Addressable (access control) | Short session timeouts; re-authentication for sensitive actions |
| Encryption at rest | Addressable; also supports breach safe harbour | Managed key service, separate keys per environment, scheduled rotation |
| Encryption in transit | Transmission security (encryption addressable) | TLS everywhere, including internal traffic; tunnel legacy HL7 v2 |
| Integrity | Mechanism to authenticate ePHI (addressable) | Versioned records, tamper-evident audit data, tested backups and restores |
| Audit controls | Standard: record and examine activity | Central, append-only logs of reads and writes; alerts on unusual access |
| Minimum necessary | Privacy Rule standard | Role-based access, field-level visibility, task-based screens |
| Development and test data | Part of risk analysis | Synthetic or de-identified data; scanning for identifiers in logs and CI |
| Multi-tenancy | Access control, audit controls and per-customer BAA terms | Per-tenant keys; tenant identifier enforced and tested at the data layer; tenant-scoped audit logs; per-tenant offboarding |
| EHR integrations | Transmission security; BAAs | FHIR with SMART scopes; per-integration threat model; BAA register |
| Cloud and vendors | BAA required | Covered services only; log access and incident terms in the BAA; no ePHI to tools without an agreement |
| Breach readiness | Breach Notification Rule (60 days) | Tested runbook, detection, named owners, contact tree |
| Documentation | Six-year retention (164.316) | Decisions recorded as architecture decision records; risk analysis kept current |
Not a feature. An app is HIPAA compliant when the organisation behind it has assessed its risks, implemented the Security Rule safeguards that apply, signed business associate agreements with every party that handles ePHI, and documented all of it. The code, the hosting and the paperwork all count.
In this order: risk analysis, safeguards, agreements, evidence. Start with a documented risk analysis, then design the safeguards it calls for: encryption, role-based access, audit logging and secure integrations. Sign BAAs with your cloud and tooling vendors, test for vulnerabilities, write down your decisions and review them regularly. That is the sequence behind most HIPAA compliant app development done well.
Short version: ePHI encrypted in transit and at rest, access limited by role and purpose, every read and write logged to protected storage, test environments free of real patient data, integrations scoped to the minimum, and every vendor under a BAA. The checklist above turns each of those into a design-review item.
There is no honest single figure, because cost follows scope. Five variables drive most of it: the number of data stores that hold ePHI, the number of integrations (each needs its own threat model and agreement), the number of testing cycles, the documentation overhead, and whether you are building greenfield or retrofitting a live product. Greenfield concentrates the effort in design. Retrofitting spreads it across every layer, usually while patients depend on the system.
For a scoped estimate, tell us how many of each you expect and we will size it with you through our healthcare technology solutions page.
No. HHS does not endorse or recognise private "HIPAA certifications", and no standard requires you to certify compliance. A vendor can describe a product as HIPAA compliant, but compliance depends on how the system is built, configured and operated, and on the policies and agreements around it. Independent assessments and frameworks such as NIST SP 800-66 help you evidence it.
Almost, but not by name. Encryption is an addressable specification, for data at rest and in transit. That means you must implement it if it is reasonable and appropriate, or document an equivalent alternative and explain why. In practice, it is hard to justify skipping it, and encryption also supports the breach safe harbour.
HHS proposed tightening the Security Rule in December 2024, but the current rule remains in force.
Yes. A cloud provider that handles ePHI on your behalf is a business associate, and HHS says using one without a BAA violates the HIPAA Rules. This applies even if the provider holds only encrypted data.
The rule does not say. It sets no period for system logs, but it does require that required documentation is kept for six years, and many teams use that as a conservative default for logs too. Confirm the right period with your counsel, since local law can differ.
It depends on who you work for. HIPAA applies when you are a covered entity, or a business associate handling ePHI on behalf of one. A consumer app that collects data directly from users may fall outside HIPAA, though other rules, such as the FTC Health Breach Notification Rule and state privacy laws, can still apply. Get legal advice before you assume either way.
Run the risk analysis first. Encrypt properly, give people only the access they need, log every access, test for vulnerabilities, treat every integration and vendor as a door, and write all of it down. Do that and the audit becomes a review, not a rescue. The load-bearing walls are yours to place, so place them early.
If you are planning healthtech software development, or reviewing a product that is already live, we are happy to talk it through. Imaginary Cloud has been building healthcare technology since 2010. Bring us the awkward questions first.
You can see how we work with healthcare teams on our healthcare technology solutions page, or browse examples of our healthtech engineering, such as VestaConnect and Jinga Life.
Alexandra Mendes is Senior Growth Specialist at Imaginary Cloud, a software development and UX/UI design agency with offices in Portugal and the UK. This article is for information only and is not legal advice. It reflects HHS, NIST, HL7 and FTC sources as checked on 21 October 2026.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
People who read this post, also found these interesting:
.webp)
.webp)
