What Makes Software HIPAA Compliant

If you are building software that will touch PHI, the practical question is what makes it HIPAA compliant. The short answer is that no badge or certificate does. A product earns that description through technical safeguards built into its architecture, administrative safeguards around how it is built and run, and a signed agreement with the covered entity it serves. We walk through what the rules ask of a builder, the decisions to settle on day one, what can wait, and how to judge a build partner.

What HIPAA Actually Requires of Software

If your product will touch PHI, the first thing to understand is simple. HIPAA compliance is not a feature, a badge, or a certificate. HHS does not certify software as “HIPAA compliant.” What exists instead is a combination of technical safeguards, administrative safeguards, and, in most cases, a signed Business Associate Agreement (BAA) between the covered entity and any vendor that creates, receives, maintains, or transmits PHI on its behalf.

That matters because it changes the question founders should ask. The right question is not “what tool makes us compliant?” It is what makes software HIPAA compliant in practice, and which decisions must be baked into the architecture before the data model is fixed?

For a builder, we see HIPAA as mostly about three things:

• who can access PHI, and under what conditions
• how PHI moves through the system, including logs, backups, analytics, and support workflows
• if the product can prove those controls are operating over time

That last point is the one most explanations skip. HIPAA is not only about securing the data. It is also about being able to show that your system was designed and operated with those safeguards in mind.

The Three HIPAA Rules a Builder Has to Care About

People often reduce HIPAA to “security,” but we find software teams need to think in terms of three rules.

1. Security Rule

This is the core architecture driver. The Security Rule requires administrative, physical, and technical safeguards for electronic PHI (ePHI). For software, that translates into access control, audit controls, integrity controls, transmission security, secure authentication, and operational practices that support those controls. The regulation spells out the technical safeguards by name, including which specifications are required and which are addressable.

2. Privacy Rule

The Privacy Rule is about minimum necessary access. The regulation says a covered entity or business associate must make reasonable efforts to limit PHI to the minimum necessary to accomplish the intended purpose. In product terms, that means the system should expose only the PHI required for the user’s job. This is not just a permission setting in the UI. It is a product design principle that should shape roles, tenancy boundaries, query scopes, and defaults.

3. Breach Notification Rule

If PHI is exposed inappropriately, you need to be able to detect it, investigate it, and notify the right parties within the required timeframes. For a business associate, the regulation requires notifying the covered entity without unreasonable delay and no later than 60 calendar days after discovery of a breach. That makes logging, monitoring, alerting, and incident response part of the product’s compliance posture, not just the ops team’s problem.

Builder’s translation. HIPAA is less about buying “compliance software” and more about designing a system that limits PHI by default, records meaningful access, and can prove what happened when something goes wrong.

Why Adding HIPAA Later Is the Expensive Path

Common advice in founder communities is that designing for HIPAA from the start is dramatically cheaper than retrofitting it, and we agree for a structural reason. The cost is not just in code changes. It is in the shape of the product itself.

Here is why later retrofits get expensive:

• Data models harden early. If PHI, tenant data, user identities, and audit events are mixed together poorly, you end up rewriting schema, queries, and permissions.
• Logs get polluted fast. If the team ships without a logging policy, PHI tends to leak into application logs, error traces, analytics events, and support tools.
• Authorization gets bolted on awkwardly. UI-only permissions are easy to bypass. Real access control has to live in the backend, at the API and data layer.
• Infrastructure choices become constraints. Secrets, backups, key management, and non-production environments are all easier to design correctly than to clean up later.
• Evidence becomes impossible to recreate. HIPAA is an operational discipline. If your SDLC, review process, and test coverage were informal, you can’t invent that history after the fact.

In plain English, every shortcut that touches PHI tends to compound. What starts as “we’ll clean this up before launch” becomes “we need to re-architect the product before we can sell into a regulated buyer.” We would take the up-front cost every time.

The Eight Day-One Decisions That Make Software HIPAA Compliant

These are the choices we would settle before the first line of production code is written. Some can be adjusted later, but all of them are much easier to get right at the start.

1. Map PHI Flows Feature by Feature Before the Data Model Is Fixed

Do not start with tables. Start with flows.

Ask where PHI enters the product, who sees it, where it is stored, where it is transformed, and where it leaves the system. That includes:

• patient intake forms
• provider notes
• messages between staff and patients
• billing and claims data
• exports to third parties
• support workflows
• background jobs and automation

Once you map the flows, you can design the schema around them. This is the most important early decision because it determines where the system must enforce boundaries.

2. Model Tenancy and Roles in the Schema, Not the Interface

In healthcare, “who can see what” is not a presentation-layer question. It is a core data design question.

If your product serves multiple clinics, groups, or care teams, tenancy boundaries must be enforced in the backend and reflected in the schema. Role-based access control should be built around real operational roles such as clinician, care coordinator, front desk, billing, admin, and support. If the database can return the wrong tenant’s data, the UI is not enough to save you.

This is where many products fail quietly. They make permissions a series of front-end filters and later discover that a direct API call, export, or internal tool bypasses the intended boundary.

3. Make Audit Logging a First-Class Immutable Table With Retention

Audit logs are not “nice to have observability.” They are a compliance requirement and a design primitive.

Your logging model should capture:

• who accessed the record
• what they accessed or changed
• when it happened
• from where it happened
• what action was taken

Just as important, logs should be resistant to tampering and stored with a retention policy. That does not necessarily mean you need heavyweight tooling on day one, but it does mean the audit trail must be designed intentionally, not improvised from application logs.

If your developers are “just logging everything” into a generic log stream, that is not a compliance strategy. It is a liability.

4. Treat Encryption and Key Management as Infrastructure, Not Configuration

HIPAA treats encryption as an addressable specification, and in practice encryption in transit and at rest is table stakes. The real decision is broader. Who manages the keys, where are they stored, and how are they rotated?

In a HIPAA product, encryption should be part of your infrastructure-as-code, not a manual checkbox. The same goes for secrets management. You want reproducible environments, versioned infrastructure, and a clear answer to who can access production secrets.

This is one of the areas where shortcuts are especially dangerous. A product can look secure in the app layer and still be fragile underneath if secrets, keys, and storage policies are ad hoc.

5. Build Authentication, MFA, Session Timeout, and No Shared Accounts Into the Product Design

Identity is not just a login page. It is the front door to PHI.

For healthcare software, you should assume the following from the start:

• individual user accounts, never shared logins
• role-based access
• multi-factor authentication for privileged access, and often more broadly
• session timeout and re-authentication for sensitive actions
• account lifecycle controls for onboarding and offboarding

If you wait to add these later, you often end up redesigning workflows around them. That is especially true for care coordination and practice management products, where internal staff access is broad and operational pressure is high.

6. Keep PHI Out of Logs, Analytics, and Non-Production Environments

This one deserves special attention because it is a common failure mode for fast-moving teams.

PHI should not appear in:

• application logs
• error reporting tools
• product analytics events
• session replay tools unless explicitly governed and minimized
• staging databases copied from production without proper controls
• developer laptops and ad hoc exports

If your engineering team uses production-like data in development, that creates immediate risk. The better pattern is synthetic data, masked data, or carefully controlled redacted datasets. In other words, do not let convenience override the data handling model.

7. Design Backup, Restore, Disaster Recovery, and Emergency Access as Tested Capabilities

Availability is part of HIPAA. That means the system should not only store PHI securely, it should also be recoverable and operational when something fails.

Questions to settle early:

• How are backups created?
• How often are they tested?
• How quickly can you restore?
• Who can invoke emergency access?
• What is the audit trail for break-glass access?

Many teams assume backup is a cloud-provider problem. It is not. The provider may offer the primitives, but your product still has to define what gets backed up, what gets restored, and how you prove the process works.

8. Put a Documented, Reviewable SDLC in Place

This is where software founders often underestimate HIPAA. The administrative safeguards effectively require an auditable way of building and changing the product.

That means you need a documented development process that includes:

• mandatory code review
• enforced test coverage thresholds
• change control
• deployment approvals where appropriate
• vulnerability management
• incident response procedures

HIPAA does not dictate your exact engineering workflow, but it does expect you to operate with discipline. In practice, that means your CI/CD pipeline, testing policy, review rules, and release process are part of the compliance story. We cover what that discipline looks like in the gates a production-ready product passes.

This is one reason craft matters. A team that already treats code review, tests, logging, and infrastructure as first-class engineering disciplines is not “adding compliance later.” It is building the product the way healthcare software must be built.

What You Can Safely Defer

Not every control has to be perfect before your first customer. The key is knowing what can wait without forcing a redesign later, and that is the test we apply.

Common items you can defer, depending on scope and buyer expectations:

• advanced security tooling layers
• formal third-party attestations beyond what your market requires
• complex segmentation patterns if the initial product has a narrow user base
• automation for every control, provided the manual process is documented and repeatable

What you should not defer:

• access control architecture
• PHI data-flow mapping
• audit logging design
• encryption and key management choices
• non-production data handling
• backup and recovery basics
• the SDLC itself

The practical test is simple. If changing the control later would force a data-model rewrite, an API redesign, or a rework of how users authenticate and access records, it belongs in version one. When a buyer asks for an attestation, our write-up on why SOC 2 is won in the codebase covers how the same engineering habits produce the evidence.

How HIPAA Changes the Way Version One Gets Scoped

For non-technical founders, the most useful mental shift, in our view, is to think in terms of foundations, not features.

A healthcare product often needs a smaller feature set and a deeper technical base than a consumer app at the same stage. That usually means:

• fewer integrations at launch
• tighter user roles
• fewer “quick export” paths
• more explicit product boundaries
• more time spent on workflow and less on surface area

The trade is real. You may ship one or two features later than you would in a non-regulated product. But you avoid the far larger delay of discovering, after launch, that your schema, permissions, or logging architecture cannot support the market you are trying to enter. If integrations are the first thing you are tempted to add, we lay out which ones pay first in our EHR integration guide.

That is the central founder decision. Would you rather spend time up front on the foundations, or spend much more time later unwinding a product that cannot safely handle PHI?

Choosing a Build Partner for a HIPAA Product

If someone is going to build this for you, you need to evaluate their engineering standards, not their compliance vocabulary. We would expect any partner, including us, to answer these questions in concrete terms.

• Can you show me how PHI flows through the system?
• Is tenancy enforced in the schema and API, or only in the UI?
• What does the audit log capture, and is it immutable?
• How are keys and secrets managed?
• How do you prevent PHI from reaching logs and analytics tools?
• What is your non-production data policy?
• Is code review mandatory for every change?
• What test coverage is enforced in CI?
• How do you document the SDLC and incident process?
• Who owns the codebase and infrastructure definitions?

The right partner should answer these with examples from the architecture, pipeline, and repository. If the answer lives in slides but not in the codebase, treat that as a warning sign. Experience in healthcare software development helps here, because the regulated-data patterns repeat from product to product.

This is also where disciplined engineering practice becomes visible. In a serious build, the data model and architecture are settled first, code review is mandatory from day one, automated tests have enforced coverage, CI/CD is standard, logging and observability are intentional, and infrastructure is defined as code. That is not a compliance performance. It is ordinary engineering discipline applied where the stakes are high.

What to Do Before You Write the First Line of Code

If you are building a telehealth product, patient portal, practice management system, or care coordination platform, the work before coding is the important work. Decide where PHI will live. Decide who can touch it. Decide how you will prove access, contain risk, and recover from failure. Then build the data model, permissions, logs, and infrastructure around those decisions.

That is what actually makes software HIPAA compliant. It is not a checklist you paste onto the end of a project but an architecture that treats PHI as a design constraint from day one. If you want a second set of eyes on that architecture before it hardens, we at Better Software are glad to look at it.

Frequently Asked Questions

Is There Such a Thing as HIPAA Certification?

No. HIPAA does not certify software or organizations. We design a product to support HIPAA compliance, and independent assessments can evaluate its controls, but there is no government-issued “HIPAA certified” badge for software that a buyer can verify.

What Is a BAA and Who Has to Sign One?

A BAA is a Business Associate Agreement. It is the written contract that sets responsibilities for any vendor that creates, receives, maintains, or transmits PHI on behalf of a covered entity. If your SaaS platform handles PHI for a provider or payer, we would expect a BAA to be required.

Does HIPAA Require Encryption?

HIPAA treats encryption as addressable in the Security Rule, which means you must implement it or document why an equivalent alternative is appropriate. In practice, for modern healthcare software, we treat encryption in transit and at rest as the norm and assume it from the start of the architecture.

Is Our Cloud Provider’s Compliance Enough?

No. Your cloud provider may offer compliant infrastructure, but your application design still determines whether PHI is exposed, logged, shared, retained, or mishandled. We treat cloud compliance as necessary, not sufficient, because the product layer carries its own obligations.

What Isn’t Protected by HIPAA?

HIPAA does not protect all health-related information in every context. It applies to PHI handled by covered entities and business associates in regulated workflows. We would check scope before assuming coverage, because consumer wellness apps and general-purpose tools may fall outside HIPAA unless they work with PHI on behalf of a covered entity.