Where your PHI lives when you pilot a reporting vendor

Before an ACCESS participant runs a single real record through a new reporting tool, someone has to sign off. Usually it is a security, privacy, or procurement reviewer, and their job is to assume the vendor is overselling until proven otherwise. This post is written for that person. It describes exactly where beneficiary data goes during a design-partner pilot, the one narrow channel that ever leaves your walls, and — the section that matters most — what we do not have yet.

We would rather under-claim and be believed than oversell a healthcare buyer. The honesty near the end is the point of the page, not a disclaimer stapled to the bottom of it.

The short answer: your PHI never reaches us

In the design-partner phase you self-host the entire rail. Observations go in, validated submissions come out, and every step — the measure engine, the packager, the gateway, the deadline dashboard — runs on your own infrastructure. There is no vendor-hosted tier in this phase, which means there is no vendor server for your beneficiary data to sit on.

So the reviewer's usual first question — "where does our PHI live in your cloud?" — has a short answer: it doesn't. It lives where it already lives, on your host. That reframes the entire review, because most of the questionnaire is about a hosted data store that, in this phase, does not exist.

The only thing that ever leaves: a nine-field, de-identified extract

If — and only if — you choose to contribute research data, exactly one file type leaves your host: a schema-versioned, de-identified extract. Two design choices make it narrow by construction rather than by policy.

First, every record has exactly nine fields and no others, and none of them accept free text. Prose is the classic accidental leak path — a note pasted into a comment field, a name in a description. If there is no field that accepts free text, prose cannot ship even by mistake. The nine fields carry a partner-held pseudonymous key (the key is generated and kept by you, never transmitted), the measure, whole days since alignment rather than any calendar date, banded values, coded outcomes rather than reason text, a provenance class, an age band top-coded at the high end, and a coarse geographic band that collapses to a suppressed value for small or unknown areas. When in doubt, it fails toward suppression.

Second, the boundary is enforced by a validator, not by good intentions. Every extract runs through a de-identification gate before it can leave your host, and an extract that fails the gate is never written — there is no "ship anyway" path. Without your key file set, the exporter is disabled and writes nothing. You can run the gate yourself and read its findings, and even those findings carry only field names and reason codes, never values.

Because the extract is longitudinal — records for one beneficiary link over time — our contracts fix the de-identification method up front as Expert Determination for this exact schema, rather than leaning on a simpler standard meant for one-off, dateless data. The nine-field design is the technical substrate that a determination evaluates; it is not a standalone legal claim, and none of this is legal advice.

What we do NOT have yet — read this section

Healthcare buyers assume vendors soften the bad news, so here it is un-softened:

No SOC 2, no HITRUST, no third-party security certification of any kind yet. We will not claim one we do not hold.
No live CMS connection. The rail is built to CMS's published draft submission contract and verified against our own mock of it. We say "built to the published contract, verified against our mock" — never "connected to CMS."
No warranty of payment. We work to get your outcome data to a compliant, on-time submission; CMS decides payment. Compliant reporting is necessary, not sufficient.
No named reference customers yet. Nobody is live in production — which is exactly what the first design-partner deals are built to change.
The Expert Determination is committed but not yet performed. The de-identification transforms are shipped and testable today; the formal determination that blesses them is scheduled, not done. We flag it rather than imply it is complete.
The rail is a working slice, not a decade-hardened product — a few build-weeks in, backed by a growing suite of hundreds of automated tests and a does-not-exist list we keep in the open.

If any of these is a hard gate for your organization today, we would rather you know now than discover it mid-pilot.

The parts of trust that don't need a certificate

Some of the posture above is a "not yet." Other parts are already true and are the kind you can check:

BAA-ready. Even though the self-host architecture means we hold no PHI in this phase, the agreement template is drafted — so a covered-entity relationship is a signature, not a project.

PHI-free operational artifacts. The logs and reports you would share with us during support carry no message bodies or diagnostics; they are PHI-free by construction, so you can share them freely.

Enforced credential hygiene. A secrets scan runs as a required check in our commit gate, so any change that would introduce a credential, key, or token into the repository is blocked before it lands. It is a build-hygiene control, not a third-party certification, and we describe it as exactly that.

A bounded support channel. The extract is the only data channel; every other channel is a human one, bounded in the agreement. Bug reports reproduce against a synthetic generator — "send us the failing bundle" is never the ask. Screen-shares run with beneficiary views closed or against synthetic data. And if PHI reaches us by accident, we do not open or forward it: we delete it, notify you in writing, log it, and follow a breach runbook regardless of the no-BAA posture.

Trust you can test beats trust you have to take

The theme running through all of this is the same one behind how we think about data that survives reconciliation: a claim a stranger can check is worth more than a claim you have to accept. You can self-host and read the install steps, run the de-identification gate against your own extract and inspect its findings, read the full boundary spec, and reproduce any reported issue against synthetic data before a single real record moves.

For a security reviewer, that is the useful summary: in this phase, the honest answer to "where does our PHI go" is "nowhere you don't already control," the one narrow channel out is enforced by a validator you can run yourself, and the gaps in our posture are written down where you can see them rather than discovered later.

---

Outcome Rail builds reporting infrastructure for ACCESS participants. If your security or procurement team is working through a vendor review, we're happy to walk through any of the above: [email protected].