How to Build Healthcare Software That Stays on the Right Side of HIPAA

If you're building HIPAA-compliant software, timing matters more than any single control. Decide your compliance architecture in sprint one, because the controls you can prove close enterprise deals and the ones you retrofit stall them. That decision shapes your cost and whether enterprise buyers can say yes.

Compliance is a design decision you make in sprint one

Most guides present HIPAA as a checklist you finish before launch, and that framing is where teams lose money. Compliance built into your architecture from sprint one becomes part of how the system works. Bolt it on later and you rework your data model and access paths after they reach production.

The HIPAA Security Rule doesn't prescribe a fixed product spec. NIST SP 800-66r2 describes it as flexible and technology-neutral, and it treats risk analysis as an ongoing activity rather than a one-time gate. Compliance lives in how you design and operate the system, and it holds up only when the design supports it.

This matters most in enterprise procurement. A hospital or payer security review asks you to prove specific controls exist, and missing ones stall the deal for months while you retrofit.

Building compliance into a custom SDLC keeps those controls provable from the first sprint. For teams doing custom software development, that means writing access control and logging into the earliest stories, rather than a later hardening phase.

The retrofit cost is not only engineering time. A stalled security review delays revenue you already forecast and gives a competitor with provable controls a clean path to the same buyer. Deciding this early converts compliance from a recurring tax into a durable advantage.

First, decide whether HIPAA applies to your product

Before you build anything, confirm whether HIPAA applies to you. Your obligations follow protected health information (PHI) and your relationship to a covered entity. The app category matters far less.

A covered entity is a healthcare provider or health plan (clearinghouses also qualify). If you build or host software that creates, receives, stores, or transmits PHI on their behalf, you're a business associate. HHS guidance on business associates makes you directly liable under the Security Rule.

PHI is health data tied to an identifier, whether a diagnosis or an appointment time linked to a name. A consumer fitness app with no connection to a covered entity often falls outside HIPAA, though state privacy laws and the FTC may still apply.

Getting scope wrong is expensive in both directions. Build too little and you fail procurement. Build too much and you burden a product that never needed it.

There is no HIPAA certification, so build for provable evidence

There is no federal HIPAA certification. No agency audits your software and issues a certificate. Any vendor claiming to be "HIPAA certified" is describing a third-party assessment rather than a government seal.

Because no certificate exists, enterprise buyers judge you on evidence you can produce on demand. A security review asks for your risk analysis, your executed BAAs, your encryption and access-control documentation, and a per-patient access report.

SOC 2 and HITRUST are the common proxies, and both carry a trap. A SOC 2 report scoped to availability and security says little about HIPAA unless its controls are explicitly mapped to the Security Rule. Buyers who know healthcare will ask for that mapping.

The per-patient access report is the bar that separates real logging from theater. If a patient or regulator asks who viewed a specific record and when, you should be able to answer in minutes. Systems that can't produce that report fail security review even when they technically keep logs.

Treat these artifacts as sales collateral rather than afterthought paperwork. A buyer's security team moves faster when your evidence arrives in the format they expect. A slow or incomplete response signals risk and pushes your deal down their queue.

[ASSET NEEDED: table, "What buyers ask for vs. what actually proves it" (certificate myth vs. SOC 2 mapped to HIPAA, HITRUST, BAA, audit evidence)]

The controls that matter, and what each one buys you

Every control below maps to a risk you carry or a deal you can close. Build them as infrastructure your features inherit, and enforce them in your pipeline through security-first cloud architecture and CI/CD.

Encrypt PHI at rest (AES-256) and in transit (TLS 1.2 or 1.3). Beyond passing review, encryption that meets HHS guidance can move a lost or stolen record out of breach-reportable territory. That safe-harbor effect is the difference between a quiet key rotation and a public breach notice.

Enforce role-based access, unique user IDs, MFA, and automatic logoff. Together these give you least-privilege access and a clean audit trail, which is what a customer's security team looks for first.

Log access to PHI and retain the records for six years, designed so you can generate a per-patient access report on demand. Retrofitting that reporting capability into an existing log store often takes multiple quarters, which stalls pilots you already sold.

The HIPAA Security Rule organizes these into administrative, physical, and technical safeguards, with risk analysis as the central artifact that justifies each choice. Wiring the controls into your pipeline is where devops best practices pay off: policy-as-code and deployment gates that block any release lacking encryption or logging.

[ASSET NEEDED: decision matrix mapping each control to its HIPAA basis and the business consequence if skipped]

The regulatory floor is moving: the 2025 Security Rule NPRM

Some Security Rule specifications are labeled "addressable," which teams misread as optional. Addressable means you must implement the specification or document why an equivalent measure is reasonable. Skipping encryption because it is addressable is a common and costly mistake.

In January 2025, HHS proposed changing this. The January 2025 Security Rule NPRM would remove the addressable-versus-required distinction and make specifications like encryption and MFA explicitly required, with limited exceptions.

This is a proposed rule, not current law. The HHS fact sheet on the proposed rule summarizes the changes. Nothing here is in force yet, and the final rule could differ from the proposal.

For a roadmap, treat the proposal as a design target. Build to mandatory encryption, MFA, network segmentation, and vulnerability scanning now. That hedges against a rule that may land during your product's lifetime, and it costs less than reworking later.

Where teams silently break HIPAA: the vendor and AI stack

The failure that most often blocks a deal is a vendor or AI endpoint touching PHI without a signed BAA. It rarely shows up as a missing encryption library. It shows up in procurement, months after you thought the work was done.

Direct business-associate liability means every subcontractor that touches PHI needs a BAA, and that obligation flows down your whole chain. One analytics tool or email provider without a BAA is a finding a buyer's security team will catch.

Run a full inventory of the tools in your data path before procurement runs it for you. Many teams find services they forgot handle PHI, and some vendors only offer a BAA on a higher pricing tier or refuse one entirely. That inventory turns a surprise procurement blocker into a budgeted line item you can plan around.

A signed cloud BAA doesn't cover every service. AWS HIPAA-eligible services are a specific subset, and putting PHI through a non-eligible service violates HIPAA even under a signed agreement.

AI features raise the same question in a newer form. Sending PHI to an LLM endpoint without a BAA breaks the chain the same way any unmapped vendor does. A model that trains on your inputs is the same violation in a new package.

Two quiet leaks catch teams late: PHI written into application logs or analytics, and real PHI copied into test environments. Engineering PHI-handling systems inside clinical workflows means designing PHI minimization in from the architecture stage, so sensitive fields never reach a log or test environment. Keep real PHI out of test environments and use synthetic data instead.

A sequential build path for HIPAA-compliant software

The controls above are decisions, and order matters. Run the work in this sequence, validating each step before the next one depends on it:

 
1. Confirm scope before writing code, identifying your covered-entity or business-associate role and every PHI type you touch.
 
2. Run a HIPAA Security Rule risk analysis, and record the risks you accept and the ones you mitigate.
 
3. Design the architecture around PHI minimization, encryption, access boundaries, and audit logging before feature work begins.
 
4. Sign BAAs with every vendor and subcontractor that will touch PHI, before any PHI moves.
 
5. Build the controls as shared infrastructure, then verify them with security testing against your design.
 
6. Confirm you can produce a per-patient access report and a complete audit trail on demand.
 
7. Prepare incident response so you can meet the Breach Notification Rule and its 60-day window.

Risk analysis is not a one-time gate. Rerun it whenever your architecture or data flows change, and keep the record current so a buyer's review finds a living program.

[ASSET NEEDED: checklist or flow diagram of the 7-step build path with a validation gate at each step]

Decide compliance in sprint one, then prove it

The teams that win enterprise healthcare deals decide their compliance architecture in sprint one and can prove every control on demand. The ones that treat it as a pre-launch checklist spend the next year retrofitting under procurement pressure. Provable controls are the asset; retrofits are the liability.

If you're weighing how much compliance to engineer before launch, a focused architecture review is worth more than another checklist. Scaylar's healthcare engineering team works across HIPAA-compliant AI, EHR integration, secure cloud, and custom software. Bring your architecture, and we'll pressure-test where PHI moves and what a buyer's security review will ask for.