HIPAA and the press.

Why a healthcare-specific bench

Relay’s general-purpose bench serves builders across most industries from one substrate. Healthcare is the exception. The difference is not technical; the press technology is the same. The difference is regulatory. A press that touches Protected Health Information, or could plausibly touch it, lives inside a different contract envelope than every other press we run.

We made the call early to operate a HIPAA-segmented bench rather than train every engineer to a healthcare bar. Three reasons. The first: training has to be specific to be useful, and a sub-bench can be trained more deeply than the entire bench could be. The second: routing is cleaner when the segmentation is structural, not procedural. The third: the additional cost of segmentation is smaller than the cost of a single privacy incident, by orders of magnitude.

What HIPAA actually asks of a service

HIPAA is sometimes treated as a single rule. It isn’t. The three pieces a business associate has to think about are the Privacy Rule, the Security Rule, and the Breach Notification Rule. The Privacy Rule defines what counts as PHI and the permitted uses. The Security Rule defines the administrative, physical, and technical safeguards. The Breach Notification Rule defines what to do when something goes wrong.

The Security Rule, in three lists

The Security Rule defines safeguards in three categories. We map our controls to each. Below is the public-facing summary; the full mapping is in our Trust center.

The bench: training, certification, segmentation

The HIPAA-segmented bench is a subset of our general bench. To join it, an engineer signs the additional agreements, completes the additional training, and is added to the routing tag that health-touching presses route to.

What the additional training covers

The training is six modules of roughly forty minutes each. The first two are HIPAA fundamentals: what counts as PHI, who is covered, what permitted uses look like. The next two are operational: how to recognize PHI in a customer session, what to do if PHI surfaces unexpectedly, when to pause a session for a privacy review. The final two are technical: defensible architecture patterns for clinical workflows, common AI-build failure modes (over-sharing identifiers, weak boundary discipline, log-fields-as-PHI mistakes).

We refresh the curriculum quarterly. The refresh is mandatory; a sub-bench engineer who lapses on training is removed from the routing tag automatically and reinstated on completion.

How segmentation works at routing time

Every customer account is flagged at signup with a PHI-likely / PHI-not-likely tag. Customers in regulated industries self-declare; the flag is tightened during the BAA conversation if signed. A press from a flagged account routes only to the sub-bench. The router enforces this at the route step, not at the engineer’s discretion. An engineer outside the sub-bench cannot, by construction, be assigned a PHI press.

Inside the session: how PHI is handled

The default posture is: PHI does not leave the customer’s environment. The engineer joins the customer’s tooling , their IDE, their staging environment, their database console with the engineer’s read access scoped to the minimum required , and works there. We do not pull data into our own systems. We do not paste PHI into shared chat. We do not copy fields out of the session into our own notes.

What the engineer can see, by stack

A typical clinical-operations stack, an EHR-adjacent internal tool, say, gives the engineer read-only access to a sandbox that has been scrubbed of PHI by the customer. If the sandbox cannot be scrubbed (the bug only reproduces against real data), we move the session to a screen-share posture: the engineer guides; the customer drives; PHI never leaves the customer’s screen.

What we do when PHI surfaces unexpectedly

The protocol is short. Pause. Tell the customer what surfaced. Decide together whether the session can continue, or whether we need to escalate to a privacy review. Document the moment. The customer’s privacy officer is the decider; we are the flagger.

The record: what we keep, what we don't

Every Relay session is recorded with consent, chat transcript, screen, and the changes made. For HIPAA-flagged accounts the record is held differently than for general accounts. Two options the customer chooses between at BAA signing.

Option A: customer-tenanted record

The record is stored in the customer’s own cloud account, via their own KMS key, with us as a service-account writer. We can read the record we wrote, when we are inside an active session. We cannot read it after the session ends without an access request that the customer logs. This is the posture most enterprise covered entities choose.

Option B: Relay-held HIPAA-eligible record

The record is stored in our HIPAA-eligible cloud account, under the BAA. Encryption at rest with per-customer keys. Strict retention (default 18 months, customer-configurable). Audit log of every internal access. This is the posture smaller covered entities choose, because it does not require them to operate a HIPAA-eligible cloud account themselves.

The BAA we sign, in plain English

The BAA is a contract between the covered entity and Relay as business associate. Six things it says, in plain language.

One. We use PHI only for the permitted purposes, which is to provide the engineering services the customer has asked for, and nothing else. Two. We have safeguards in place. Three. We will tell the customer if we discover a breach, within the timeframes HIPAA defines. Four. We will help the customer with their own obligations, providing access, accounting for disclosures, supplying documentation. Five. We will return or destroy the PHI when the relationship ends. Six. We are responsible for our subcontractors as if their actions were ours, and they sign flow-down agreements that match.

The full text is a few pages and the customer’s privacy officer should read it. We send it on request.

What we will not press for, by policy

Some presses we decline to take, in advance. We document them here so customers know before they need to.

We do not press for clinical-decision-support code paths that will be deployed without separate clinical sign-off. We do not press for patient-facing software that bypasses the customer’s identity stack. We do not press for changes to consent-capture flows that have not been approved by the customer’s privacy officer. We do not press for direct modification of clinical records. We do not press for anything regulated as a medical device under FDA jurisdiction unless the customer has a quality-management system and we are working inside it.

The line is not we cannot help. The line is this press needs people who are not us in the room. We will recommend partners.

Outcomes from year one

We ran 1,140 healthcare presses in our first twelve months across thirty-one covered-entity customers. Selected outcomes, aggregated:

Two patterns are worth highlighting. The refused-to-ship rate is meaningfully higher than our general bench (which sits below 1%). That is the sub-bench doing its job. The privacy-pause rate, eleven events in 1,140 sessions, is the rate at which something surfaces in-session that requires a beat. None of those events became a breach, because the pause worked. We treat that as the right number; zero would suggest we’re not pausing often enough.