decision

Provider and facility identity is kept, permanently — and saying so is the control

2026-07-19 · WASH-107b

The question

The payload washer replaces patient identity with synthetic equivalents. Should it do the same to practitioners, organizations and facilities?

Constraints

  • Provider and site data is public reference data, not protected health information. It is published in a national registry and validating it against that registry is a product feature.
  • A user moving a washed payload into their own system substitutes their own identifiers for the provider ones, so washing them removes something the recipient replaces anyway.
  • Provider to site to group rollups must survive intact, or the payload stops exercising the relationships it was collected to exercise.
  • The nominative risk is real: a reader sees the word 'wash' and reasonably assumes it covers everything in the payload.

Alternatives considered

  • Wash provider and facility resources too.

    Rejected — Destroys the rollup relationships that make the payload useful as a test artefact, and removes real reference data in exchange for a privacy benefit that does not exist — these are not people whose privacy is at stake in the way a patient's is.

  • Add an opt-in 'wash providers too' policy for the cautious case.

    Rejected — Rejected explicitly and permanently, not deferred. An opt-in mode implies the default is a compromise, and it doubles the golden-fixture surface for a mode whose output is strictly less useful.

  • Keep provider data and disclose it prominently instead.

    Chosen.

The decision

Provider, practitioner, organization and facility resources are never washed — no opt-in mode, now or later. The nominative risk is handled by SAYING SO plainly on every surface that describes the tool, rather than by changing behaviour. The rationale is recorded here specifically so it is not re-litigated.

The interesting move: disclosure as the control

Most privacy decisions in this project resolve toward removing data. This one resolves toward keeping it and being loud, and the reasoning generalises.

The washer's real promise is format-preserving synthetic test data — a payload that still exercises the code paths the original exercised. Provider identity is load-bearing for that promise in a way patient identity is not: strip a practitioner and the referral relationship it anchored stops being testable, and the recipient gains nothing, because they were going to substitute their own identifiers anyway.

So the honest control is not behavioural. It is that every surface describing the tool states, without being asked, that washed output can still carry real provider and facility identity.

What "permanently" is doing in that sentence

It is doing real work, and it is the part most likely to be quietly undone.

"Not yet" invites a future contributor to add the mode as an obvious improvement, and a mode that exists gets used. Naming it as closed — with the reasoning attached — means the next person to propose it has to argue against a recorded position rather than fill a perceived gap.

The cost of being wrong here is bounded and visible: if the decision is ever revisited, the golden fixtures shift, which is a loud event.

What this decision does NOT cover

It says nothing about whether washed output is appropriate to share with a third party. Retained provider identity, retained facility addresses and retained financial detail are all commercially and relationally sensitive even when every patient field is synthetic. That is a separate question, and it belongs to whoever decides who the output is for.

Where this is canonical

docs/backlog/PLAYBOOK_DERIVED_BACKLOG_CANDIDATES_2026-07.mdDecided 2026-07-19; the register entry was ported and re-keyed to WASH-107b on 2026-07-22 after the original filing was orphaned on an unmerged branch. This record carries the DECISION date, not the landing date.