HIPAA-Compliant Software Development: What Healthcare Startups Need to Know
What HIPAA actually requires of software systems, which technical safeguards matter most, and what to look for when hiring a development team to build healthcare applications.
HIPAA is one of those regulations that everyone in healthcare knows they need to comply with and almost no one fully understands. That gap is expensive. Healthcare startups have faced fines ranging from $100,000 to over $1 million for violations that a thoughtful development process would have prevented.
This isn't a comprehensive legal guide — get a healthcare attorney for that. But it is a practical look at what HIPAA requires of the software systems you build, and what that means when you're hiring a development team.
What HIPAA Actually Regulates
HIPAA (the Health Insurance Portability and Accountability Act) includes several rules, but the two most relevant for software are:
The Privacy Rule — governs how Protected Health Information (PHI) can be used and disclosed. PHI is any individually identifiable health information: name, address, dates of service, social security number, medical record numbers, and health data tied to a specific person.
The Security Rule — governs how electronic PHI (ePHI) must be protected. This is where most of the technical requirements live.
If your software touches ePHI — stores it, processes it, transmits it, or even just displays it — you're covered. If you're a company that provides software to healthcare organizations and your software handles their patients' data, you're a Business Associate and you need a Business Associate Agreement (BAA) with each covered entity you serve.
The Technical Safeguards That Matter Most
The Security Rule specifies three categories of safeguards: administrative, physical, and technical. The technical safeguards are where development decisions matter most.
Access Controls
Only authorized users should be able to access ePHI. In practice, this means:
- Authentication — verified identity before access is granted. Multi-factor authentication (MFA) is strongly recommended and increasingly considered a baseline expectation.
- Role-based access control — a nurse should see patient records, but not billing data. A billing admin should see financial records, but not clinical notes. Granular access control, enforced in the application layer and not just the database.
- Automatic session timeouts — sessions should expire after a defined period of inactivity. HIPAA doesn't specify a number, but 15 minutes is common in clinical settings.
- Unique user identification — shared logins are not compliant. Every user needs their own credentials.
Audit Logs
You must be able to answer the question: who accessed what data, when, and from where?
This means comprehensive, tamper-evident logging of every access, modification, and deletion of ePHI. Logs should include user ID, timestamp, action taken, and the record affected. They should be retained for at least 6 years. And critically — they should not be modifiable by application users, including administrators.
Audit logging is often an afterthought in development and a nightmare to add later. It needs to be built in from the start.
Encryption
In transit: All ePHI transmitted over networks must be encrypted. TLS 1.2 or higher is the standard. This means HTTPS everywhere, encrypted API calls, and encrypted connections to your database.
At rest: ePHI stored in your database, your file storage, and your backups must be encrypted. AES-256 is the accepted standard. Database-level encryption is necessary but not sufficient — you also need to think about backups, exports, and anywhere else data lands.
Key management: Encryption is only as good as the management of your encryption keys. Keys should be rotated regularly, stored separately from the data they protect, and access to them should be logged and restricted.
Integrity Controls
You need mechanisms to ensure that ePHI hasn't been altered or destroyed improperly. This includes checksums on stored files, database transaction logs, and backup verification.
Transmission Security
Beyond encryption, you need to think about what happens when data is transmitted. This means secure APIs (authenticated, encrypted, rate-limited), secure email handling (don't send unencrypted PHI via standard email), and careful management of any webhooks or third-party integrations that might receive ePHI.
Business Associate Agreements
If any third-party service you use touches ePHI — cloud storage, email providers, analytics platforms, customer support tools — you need a BAA with them.
The major cloud providers (AWS, Google Cloud, Azure) offer BAAs. Some SaaS providers do as well. But many don't, which means you either can't use them for ePHI or you need to architect around them so they never actually see identifiable data.
This has real implications for your tech stack choices. Some otherwise excellent tools are not viable for HIPAA-covered systems because they don't offer BAAs.
What a HIPAA-Compliant Development Process Looks Like
Compliance isn't a feature you bolt on at the end — it's a set of architectural decisions made early that shape everything else.
Threat modeling before writing code. Before a line of code is written, the team should think through: what are the attack surfaces? What data flows where? What happens if a user account is compromised? What does the audit trail look like?
Minimum necessary data. HIPAA requires that you only access, use, and disclose the minimum PHI necessary to accomplish the intended purpose. This should influence your data model — don't collect data you don't need, and don't surface data to users who don't need to see it.
Encryption as a default, not an option. Every database field that might contain ePHI should be encrypted. Every API response that contains ePHI should be transmitted over TLS. This should be built into your data layer from day one.
Audit logging as infrastructure. Audit logs should be a first-class concern, built into the application middleware — not something individual developers remember to add to each endpoint.
Penetration testing. Before launch, and periodically afterward, a security assessment should attempt to find vulnerabilities. This is not optional for patient-facing healthcare applications.
Documented procedures. HIPAA requires documented policies for security incident response, workforce training, and data breach notification. The software team should produce technical documentation that supports these policies.
Red Flags When Hiring a Development Team
Not every development shop is equipped to build HIPAA-compliant software. Some things to watch for:
They're vague about audit logging. If a team can't tell you exactly how they'll implement tamper-evident audit trails, that's a problem. This is not a simple feature.
They suggest using tools that don't offer BAAs. A team that proposes storing ePHI in a service that doesn't sign BAAs either doesn't understand HIPAA or doesn't care.
They treat compliance as a checkbox. HIPAA compliance is not a list of features to implement. It's an ongoing posture — a way of making architectural decisions, handling data, and documenting processes. A team that frames it as "we can make it HIPAA compliant" after the fact doesn't understand what they're agreeing to.
They can't produce prior examples or references. HIPAA-compliant development is specialized work. Ask for references from healthcare clients and check them.
The Cost of Getting It Wrong
HIPAA violations fall into four tiers:
| Tier | Per Violation | Annual Max |
|---|---|---|
| Unknowing violation | $100–$50,000 | $25,000 |
| Reasonable cause | $1,000–$50,000 | $100,000 |
| Willful neglect (corrected) | $10,000–$50,000 | $250,000 |
| Willful neglect (not corrected) | $50,000 | $1.9 million |
Beyond fines, a breach involving PHI requires notification to affected individuals, to HHS, and often to media if more than 500 individuals in a state are affected. The reputational cost of a public breach in healthcare can be existential for a startup.
Building it right the first time is almost always less expensive than remediating it after a breach.
We've built healthcare software and understand what HIPAA-compliant development actually requires. If you're building a healthcare application and want to talk through your architecture, reach out to us.