Building compliant software in healthcare

Healthcare software teams tend to meet HIPAA through a risk assessment document and a business associate agreement, and then treat compliance as a thing that has been handled. The document exists, the agreement is signed, and the engineering work proceeds on the assumption that the compliance question is answered.

The Security Rule does not work that way, and the reason is structural. Most regulation tells you what to do. The Security Rule tells you what to achieve and then, deliberately, leaves most of the how to you based on your size, complexity, and risk. That flexibility is the point: a two-person telehealth startup and a hospital system should not be forced into the same controls.

But flexibility has a cost that causes problems for teams repeatedly. When a rule says "implement a mechanism to encrypt" and marks it Addressable, an engineer reads it as optional, a compliance officer reads it as handled, and nobody writes down which mechanism was chosen or why an alternative was reasonable. The obligation has not been met. It has been passed between two people, each of whom believed the other had it.

What makes healthcare different from other regulated work

Three things, and they change what a build has to do.

The harm from leaked health data lasts longer than with other sensitive data. A leaked card number is cancelled and reissued. A leaked diagnosis is permanent. That asymmetry is why the controls around PHI are less about preventing fraud and more about preventing disclosure, and why read access matters more here than almost anywhere else.

Access is broad by design. A hospital's software has to let a lot of people see clinical data quickly, because restricting access in an emergency causes harm. The Security Rule reflects this: emergency access procedure is a Required specification [1]. That means healthcare permission models cannot simply be strict; they have to be strict with a well-controlled way to open access when needed, and that emergency path is where the audit obligations are concentrated.

Your vendors handle your regulated data. Business associates handle PHI on your behalf, and the arrangement does not transfer the obligation away from you. Every third-party service your application sends data to is a decision with regulatory consequences, which is a different position from ordinary product engineering where adding a service is a technical choice.

Why AI-native development helps here specifically

The argument we make across regulated work applies in a specific way in healthcare.

The Security Rule's flexibility means the specification does not arrive written, the way an SEC recordkeeping requirement does. Somebody has to decide what "reasonable and appropriate" means for this organisation, write that down, and then make the system do it. The writing-down step is where healthcare compliance mostly fails, and it fails because it produces no visible artefact in the product.

That is exactly the step our process makes unavoidable. A check cannot be written against an undecided requirement, so the act of building the check suite forces the decision to exist in a form somebody can review. "Encryption at rest is implemented using this mechanism, here is the assertion that fails if it is turned off" is both the engineering control and the documentation the rule asks for, produced once.

The second half of the argument is the economics. Verifying that every path to PHI produces an audit entry, across every interface, is work across a large number of combinations that no team ever prioritised against clinical features. When implementation is close to free, it stops being a trade-off. Our eval-driven development guide covers the method, and adding eval tests was the best decision we made covers why it matters.

The limit is the same one we state everywhere: generated code is not secure by default. Veracode's spring 2026 testing across more than 150 models found only 55 percent of generations produced secure code while syntax correctness ran above 95 percent [2]. In a system holding PHI, that failure rate affects the paths that matter most, which is why the checks have to be derived from the requirement before the implementation exists and graded independently of it.

What this guide covers

The obligations that reach an application are concentrated in a few places, and each has a page here. The Required and Addressable distinction, which is the concept most often misread, is on Required vs Addressable safeguards. Audit controls are on audit controls under the Security Rule. Minimum necessary, which is a permission-model problem, is on minimum necessary in a permission model. Encryption and the proposed update are on encryption and the proposed Security Rule update.

Then there is the part nobody plans for: where PHI ends up outside the paths you control, covered on where PHI leaks in a working application. Vendors that handle PHI on your behalf are covered on business associates and third-party services, and the newer question of what happens when a model reads or writes clinical data is covered on building AI features on clinical data.

What the naive approach looks like

Almost every healthcare team we talk to has already done the naive version of compliance, and it is worth describing precisely, because the description is the diagnosis.

The naive approach treats HIPAA as a project with an end date. Someone runs a risk assessment, usually once a year, sometimes tied to a renewal or a funding round. A vendor or consultant produces a document identifying risks and recommending mitigations. The team implements the mitigations that are cheap and defers the ones that are not. A business associate agreement gets signed with each vendor that touches PHI, usually a standard template neither side reads closely. The result is filed, and everyone moves on to product work until the next cycle.

This feels sufficient, and it is worth being honest about why. The document exists and can be shown to an auditor, an enterprise customer's security team, or an investor doing diligence. Each individual step was reasonable: the risk assessment was thorough for the system as it existed on the day it was written, the mitigations were sensible, and the business associate agreements are real contracts with real obligations in them. Nothing about the naive approach involves anyone being careless. It fails for a structural reason that has nothing to do with effort.

Why it fails in practice

The failure is that a risk assessment is a snapshot and a codebase is a video. The document describes the system as it existed at a moment. The system then keeps changing, feature by feature, and nothing in the naive process notices when a change moves the system away from what the assessment described.

Consider a concrete version of this. A risk assessment in January correctly notes that the application logs writes to patient records and recommends no change, because the logging looks adequate against the system as it existed that month. In March, the team adds a reporting dashboard that lets support staff look up a patient's history to answer a billing question. The dashboard reads PHI. Nobody updates the risk assessment, because nobody thinks of a support tool as a compliance event, and the audit trail requirement now has a gap that will not surface again until the next annual review, if it surfaces then at all. Most annual reviews re-examine policy documents rather than actually tracing what each interface in the running system does, so the gap can persist for years.

This is the default outcome of doing compliance as a periodic project rather than as a property of the system, because periodic review has a natural blind spot: it catches what existed when the reviewer looked and nothing that was added after. The Security Rule's own text anticipates this by requiring periodic technical and non-technical evaluation, but "periodic" in most organisations means annual, and a year is a long time for a codebase to drift.

What a correct approach requires instead

The correct approach treats each Security Rule obligation as a property the running system either has or does not have, checked continuously rather than assessed periodically. This is the same idea as the eval-driven development we build every product with, applied specifically to compliance obligations rather than to feature behaviour.

Concretely, this means three things that the naive approach skips. First, every obligation gets translated into an assertion that can run automatically: "every read of a patient record through any interface produces an audit entry naming a person" is a sentence a machine can check on every deployment, not just a sentence a human can nod along with in a review meeting. Second, the assertion runs on every change, not once a year, so the March reporting dashboard either satisfies the audit control the day it ships or fails a check the day it ships, and either way somebody finds out immediately rather than in the next annual cycle or after a complaint. Third, the assertions are kept next to the code they describe and reviewed when that code changes, the same discipline covered in depth on Required vs Addressable safeguards, so the decision travels with the system rather than living in a folder nobody in engineering opens.

None of this replaces the risk assessment. Somebody with the right expertise still has to decide what is reasonable and appropriate for your organisation, and that judgment does not come from a test suite. What changes is what happens after the judgment is made: instead of producing a document that ages the moment it is signed, the judgment produces a check that keeps verifying itself against a system that keeps changing.

How this plays out across a build's lifecycle

The gap between the naive and the correct approach shows up differently at each stage of building software, and it is worth walking through where.

At design time, the naive approach asks "does our plan satisfy HIPAA," answered once, informally, often by whoever is most senior in the room rather than whoever has actually read the Security Rule text. The correct approach asks the same question but produces a written obligation list with the regulatory text quoted next to each item, the method covered in depth on the cross-industry hub at compliance is a specification problem. The difference matters at the next stage, because only one of those two produces something an engineer can build against.

At implementation time, the naive approach lets engineers infer the requirement from the ticket, which usually describes the feature and rarely describes the compliance property the feature has to preserve. A ticket that says "add a reporting dashboard for support staff" says nothing about audit logging, minimum necessary, or transmission security, so an engineer without healthcare context builds exactly what was asked and nothing else. The correct approach attaches the relevant assertions to the ticket before anyone writes code, so the audit logging requirement is a stated part of the work rather than something to be discovered later.

At review time, the naive approach relies on a human reviewer noticing that a new code path touches PHI and remembering which Security Rule provisions apply, which is a lot to ask of someone reviewing a pull request against a deadline. The correct approach lets the checks do that noticing: a change that adds a new read path without a corresponding audit entry fails automatically, regardless of whether the human reviewer happened to think of it. This is also where the rule that the checker cannot be the same context that wrote the code matters most, because a model or a person grading their own work will tend to find their own work acceptable.

In production, the naive approach has no ongoing signal until something goes wrong: a complaint, a breach, an audit. The correct approach has the check suite running continuously, so a regression, someone widening a role's permissions, someone routing a new export around the data access layer, gets caught the day it happens rather than discovered eighteen months later when a patient asks who looked at their record.

How to tell if your own team is at risk

A few honest questions surface whether an organisation is running the naive version without realising it.

Ask whether anyone can currently answer, for the application as it exists today rather than as it existed at the last review, which interfaces produce an audit entry on read and which do not. If the honest answer requires someone to go check the code rather than being already known, the audit control is being assessed periodically rather than continuously.

Ask when the risk assessment was last updated relative to the last time a new feature touched PHI. If a feature shipped that reads or writes PHI and the assessment was not revisited, the document and the system have already diverged, and the size of that divergence only grows with time.

Ask whether the Addressable specifications have a written decision with a date and an owner, or whether the honest answer is "we think we do that" without anyone being able to point at where the decision is recorded. As covered on Required vs Addressable safeguards, a considered decision that was never written down is, for compliance purposes, close to indistinguishable from one that was never made.

And ask what happens when a developer who was not in the room for the original risk assessment builds a feature six months from now. If the answer depends on that developer independently rediscovering the compliance requirements from first principles, the organisation is one busy sprint away from a gap nobody notices until it matters.

A worked example, start to finish

It helps to see the whole chain in one place rather than as separate concepts, so here is a single feature traced from request to production.

A product manager asks for a feature letting care coordinators see a patient's recent visits across departments in one screen, because coordinators were previously switching between four systems to assemble the same picture. Read as a feature request, this is unremarkable and clearly useful. Read against the obligation list, it touches at least three Security Rule provisions at once: it is a new read path that has to produce audit entries, it aggregates PHI a coordinator may not need in full for every visit, which raises a minimum necessary question, and if the visits span departments with separate systems, it may introduce a new internal transmission of PHI between services that did not previously talk to each other.

None of those three things appear in the product ticket, because the product manager who wrote it was solving a workflow problem, not reading 45 CFR 164.312. Under the naive approach, the feature ships, coordinators are happy, and the compliance gap sits quietly until the next annual assessment, if anyone thinks to trace this specific screen during it. Under the correct approach, the three obligations are attached to the ticket before implementation starts: the read path must produce an audit entry naming the coordinator, the screen must be scoped to visits within the coordinator's assigned patients rather than a hospital-wide query, and the inter-service call carrying the aggregated data must run over an encrypted internal channel with its own audit entry. Each of those becomes an assertion the check suite verifies on every future change to the screen, so a fourth department added next year inherits the same protections automatically rather than depending on someone remembering the original review.

That is the difference this guide is arguing for, made concrete: a shorter path from what the regulation says to what the code enforces, one that survives the people who built it moving on to other work.

Nothing here is legal advice, and which obligations apply to your organisation is a question for counsel rather than for engineers. What this guide does is take the obligations once somebody has scoped them and turn them into things a system can be tested against. If you are building or reviewing a healthcare product, our healthcare work is the place to start, or get in touch and we will look at what you have.

A risk assessment describes what you decided. Only the running system decides what actually happens.