Building Software That Supports HIPAA Compliance

Software is not HIPAA compliant on its own. Organizations are: covered entities and their business associates, through their policies, contracts, training, risk analysis and the systems they run. What an engineering team can do is build software that supports that compliance, by making the required safeguards easy to operate and easy to evidence. There is also no official HIPAA certification for products, and HHS does not endorse any. Be wary of any vendor badge that suggests otherwise.

The Security Rule is deliberately technology-neutral. It tells you to “implement audit controls” without saying what to log, and it leaves the choice of measures to a documented risk analysis. That flexibility is why teams either over-build (encrypting the same data three times while PHI sits in application logs) or under-build (assuming the cloud provider’s compliance page covers the application). This guide sets out what the rule says, with citations, and the engineering patterns we use to support it.

This article is general information, not legal advice. Your obligations depend on whether you are a covered entity, a business associate or neither, and a healthcare attorney should confirm that before you rely on anything below.

First, Work Out Whether HIPAA Applies to You

Two questions come before any code. The first is about who you are. HIPAA applies to covered entities (health plans, healthcare clearinghouses, and healthcare providers that conduct standard transactions such as billing electronically) and to business associates: companies that create, receive, maintain or transmit protected health information on a covered entity’s behalf. Subcontractors of business associates are business associates too. A consumer wellness app with no relationship to a provider or plan may fall outside HIPAA altogether, although other rules, such as the FTC’s Health Breach Notification Rule and state privacy laws, can still apply.

The second is about the data. Protected health information is individually identifiable health information held or transmitted by one of those organizations. The identifiers are broader than most teams expect: names, email addresses, phone numbers, IP addresses, device identifiers and most dates all count. An appointment reminder service that stores only a phone number and an appointment time is handling PHI, because the number is linked to the fact of receiving care from a particular provider.

Map the data flows before designing anything: what enters the system, where it is stored, where it is transmitted, who can see it and what leaves. The risk analysis, the vendor list and the architecture all depend on this map, and an investigator or a customer’s security team will ask for it.

How the Security Rule Is Organized

The Security Rule (45 CFR Part 164, Subpart C) groups its standards into administrative safeguards (164.308), physical safeguards (164.310) and technical safeguards (164.312), with documentation requirements in 164.316. HHS publishes a plain-language summary of the Security Rule.

Required and Addressable Do Not Mean Mandatory and Optional

Each standard may have implementation specifications, and each specification is labeled Required or Addressable. Required means you implement it. Addressable is widely misread as optional, and it is not. Under 164.306(d)(3) you must assess whether the specification is reasonable and appropriate for your environment. If it is, you implement it. If it is not, you document why and implement an equivalent alternative measure where that is reasonable and appropriate. Either way there is a written decision on file. For encryption in a modern cloud application, it is very hard to argue that implementing it is unreasonable.

The Technical Safeguards at a Glance

The Proposed Security Rule Update

In January 2025 HHS published a notice of proposed rulemaking to update the Security Rule. Among other things, the proposal would remove the distinction between required and addressable specifications, and would make measures such as encryption and multi-factor authentication explicit requirements with limited exceptions. As far as we can confirm, as of September 2026 it remains a proposal. No final rule has been published, and the text could change or be withdrawn. The rule described in this article is the one currently in force. Check the HHS and Federal Register pages for the current status before planning around the proposal. That said, the controls it names are good practice already, and we build most of them in by default.

Business Associate Agreements

A covered entity needs a Business Associate Agreement with each vendor that creates, receives, maintains or transmits PHI for it, and a business associate needs one with each of its subcontractors that does the same. For a typical stack that means checking:

• Your cloud provider. The major providers offer BAAs, but they cover a defined list of services. AWS, for example, publishes its HIPAA-eligible services. Keep PHI on covered services only.
• Email and SMS providers. Standard plans from many messaging vendors are not offered with a BAA. You may need a specific plan, or a vendor that focuses on healthcare.
• Error tracking, logging and analytics tools. Stack traces and request logs pick up PHI easily. Get a BAA, or strip PHI before data leaves your infrastructure. Preferably do both.
• Your AI provider, if any AI feature touches PHI. Several vendors offer BAAs for particular products or tiers. Confirm exactly which product is covered. An agreement for an enterprise API does not cover staff pasting patient notes into a consumer chat app. The same care applies to retrieval pipelines and chat assistants, which we cover in what breaks in production RAG and the AI chatbot launch checklist.

The working rule: no PHI goes to a third party until the agreement is signed and the specific service is confirmed as covered. Keep a register of each vendor, the agreement date and the services in scope. As a development partner, we can sign a Business Associate Agreement where we handle PHI.

Technical Safeguards in Practice

Encryption

Both encryption specifications are addressable, and we treat both as implemented by default. In transit that means TLS 1.2 or later on every connection, including internal service-to-service traffic. At rest it means the provider’s managed encryption for databases, object storage and disks. The parts that need thought are the ones people forget: backups and snapshots, message queues, caches (PHI in a cache is still PHI at rest), exports, and key management through a key management service with rotation instead of keys in environment variables.

There is a second reason to do this well. The Breach Notification Rule applies to unsecured PHI. PHI encrypted in line with HHS guidance, where the keys were not also compromised, is not “unsecured”, so a lost or stolen encrypted dataset may not be a reportable breach.

Access Control

Unique user identification is required, so every person gets their own account, and shared administrator logins go. Beyond that, grant each user and each service the minimum access necessary. Clinicians see their own patients, enforced in the queries and not only in the interface. Engineers have no standing read access to production PHI. For debugging, use de-identified data, or access that is time-limited, approved and logged.

The emergency access procedure is also required, and it is often missing. Decide how authorized staff obtain ePHI during an outage or an emergency, and build it. A common design is a break-glass role that grants temporary elevated access, notifies a supervisor and writes a prominent audit entry.

Automatic Logoff

Automatic logoff is an addressable specification (164.312(a)(2)(iii)), not a required one. In clinical settings with shared workstations it is nearly always reasonable to implement. The rule sets no timeout; your risk analysis does. Idle timeouts of 10 to 15 minutes for clinical users, and shorter ones for administrative screens, are common choices. Preserve work in progress through re-authentication, or users will find ways to keep sessions open.

Authentication and Integrity

The rule requires you to verify that a person or system seeking access is who they claim to be. It does not currently name multi-factor authentication, though the 2025 proposal would. We enable it for every account with production or PHI access, because compromised credentials feature in many reported breaches and it is among the cheapest controls available. For integrity, use checksums or signatures where records move between systems, and database constraints and versioning so that improper changes can be detected.

Audit Logging and the Six-Year Question

The audit controls standard requires mechanisms that “record and examine activity” in systems containing ePHI. Separately, 164.308(a)(1)(ii)(D) requires regular review of records such as audit logs and access reports. The rule does not list the events to record. A defensible implementation logs every access to PHI, reads included, with who, which record, what action, when and from where.

• Emit structured events at the data-access layer, not in individual controllers, where a new endpoint can forget them.
• Write them to append-only storage that is separate from the application database, so that a compromised application cannot rewrite history.
• Log record identifiers, not the PHI itself. An audit log full of patient names is a second PHI store to protect.
• Alert on anomalies: one user opening hundreds of records in an hour, access at 3 am from a new location, repeated failed attempts.

A common misstatement is that HIPAA requires audit logs to be kept for six years. The six-year requirement in 164.316(b)(2) applies to required documentation: policies, procedures, and records of actions, activities and assessments the rule requires you to document. It does not name audit logs as such. Many organizations still choose to keep audit logs for six years, because the logs support that documentation and help in investigations. Treat the retention period for logs as a decision from your risk analysis, write it down, and check state law and customer contracts, which may set their own periods.

Read logging is the requirement that breaks naive architectures. If an ORM lazily loads patient rows from many places in the codebase, access logging cannot be bolted on later without touching all of them. Put PHI behind a repository layer from the first sprint. It costs little then and a great deal as a retrofit.

PHI Handling Patterns

Segregate PHI in the schema. Keep identifiers and clinical data in clearly marked tables or a separate database. This shrinks the surface to protect and lets you answer “where is all our PHI?” quickly.

Pass opaque IDs between services, queues and URLs, not names or medical record numbers. Anything in a URL ends up in browser history, proxy logs and analytics.

Scrub logs and error reports at the source. Redaction middleware should strip known PHI fields before anything reaches log aggregation, and code review should reject PHI in log statements. Plaintext patient data in application logs, shipped to a vendor with no BAA, is an easy mistake to make and a serious one.

De-identify for analytics and lower environments. Staging systems seeded with production PHI are hard to defend. Use synthetic data, or de-identify under one of the two methods in 164.514(b): Safe Harbor, which removes the 18 listed identifier types and requires no actual knowledge that the remainder could identify someone, or Expert Determination.

Infrastructure and Administrative Safeguards

Several administrative requirements turn into infrastructure work. The contingency plan standard (164.308(a)(7)) requires a data backup plan, a disaster recovery plan and an emergency mode operation plan. Testing those plans is an addressable specification, and we recommend a restore test at least once a year, because a backup nobody has restored is unproven.

Keep PHI databases in private subnets with no public route, reachable only from the application services that need them. Define environments as infrastructure as code, so that you can show what your configuration was on a given date from version history. The risk analysis itself (164.308(a)(1)(ii)(A)) is required and must be documented. NIST’s SP 800-66 Revision 2 is the standard public guide to carrying one out and to implementing the Security Rule generally.

Breach Notification: Know the Clock Before You Need It

Under the Breach Notification Rule, an impermissible use or disclosure of unsecured PHI is presumed to be a breach unless a documented risk assessment shows a low probability that the PHI was compromised. The deadlines:

• Affected individuals must be notified without unreasonable delay and in no case later than 60 calendar days after discovery of the breach. Sixty days is the outer limit, not a target.
• For a breach affecting 500 or more individuals, the covered entity must also notify HHS without unreasonable delay and no later than 60 days after discovery. If more than 500 residents of one state or jurisdiction are affected, it must notify prominent media outlets serving that area within the same limit.
• Breaches affecting fewer than 500 individuals are logged and reported to HHS annually, no later than 60 days after the end of the calendar year in which they were discovered.
• A business associate must notify the covered entity without unreasonable delay and no later than 60 days after discovery. Many BAAs set a much shorter contractual deadline, often a few days.

For engineering, this means detection and evidence. You need to establish quickly which records were touched, by whom and when, which is exactly what the audit log is for. Write the incident runbook, name the owners and rehearse it.

Common Mistakes

1. Assuming “HIPAA-ready hosting” covers the application. A cloud BAA covers the provider’s side of a shared responsibility model. Access controls, logging and session handling are yours.
2. No written risk analysis. Good engineering without documented reasoning fails reviews that the engineering alone would have passed.
3. PHI in tools nobody considered. Calendar invitations with patient names, support tickets with screenshots, chat messages quoting a record. Policy and tooling have to cover people as well as servers.
4. Treating “addressable” as “skip”. Every addressable specification needs a documented decision.
5. Treating compliance as a launch milestone. Each new feature, vendor and integration reopens the question. A five-minute PHI impact check in every design review catches a lot.

What It Costs

We do not quote a percentage, because it depends on the product. The pattern is consistent, though. The audit layer, access control, environment separation and vendor checks are modest work when designed in from the start, and expensive to retrofit, because a retrofit touches every feature that reads or writes PHI. If there is a fair chance your product will handle PHI within two years, build the repository layer, the audit log and the data map now. Our article on what a custom web app costs explains how compliance fits among the other cost decisions.

We build healthcare software on these patterns. We can build your product on them, or carry out a technical review of an existing system against the safeguards above. A technical review is an engineering assessment. It is not a certification, and it does not replace your own risk analysis or legal advice. Request a call to discuss either.