How your anonymity works

DrBox exists to let clinicians speak honestly about their employers without losing their careers. This page explains — in plain language, not legalese — what the platform does and does not do to keep that promise. If anything here ever conflicts with the MANIFESTO, the MANIFESTO wins.

What we verify

To post a review, you prove you are a real credentialed clinician:

• Physicians, CRNAs, and other NPI holders — you enter your NPI. We check it against the public NPPES Registry over the network.
• Nurses (v1 launch, top 5 states) — state board lookup. Other states: manual license upload.

Your browser sends the NPI to our server. Our server sends the NPI to NPPES. NPPES never sees your IP — only our server's IP. We read back your specialty, state, and credential.

What we discard

The moment verification succeeds, the following values exist only in the server's request memory and are gone when the request ends:

• Your NPI
• Your name (if NPPES returned it)
• Your address (if NPPES returned it)
• The exact NPPES response body

None of this is written to our database, our logs, our backups, or our metrics. Subpoenaing DrBox for "who posted this review" returns — truthfully — "we do not have that data, because we built the system so we cannot have it."

What we keep

After verification we issue you two things:

1. A voucher. A short-lived signed token that proves you passed NPI verification. It says only "this session was verified" — it does not name the NPI. Valid for 15 minutes.
2. A Privacy Pass token. An unlinkable credential (per RFC 9576) you redeem when you post a review. The server signs the token without ever seeing the nonce you use to redeem it. Reviews carry the nonce as the identity handle, not your NPI.

We also keep the non-PII dimensions from your verification — specialty, state, credential — so review templates can be role-appropriate. These are stored against your anon_user row, not your name.

What we cannot protect you from

The architecture cannot rescue you from everything. In the spirit of the MANIFESTO, the honest list:

• A motivated attacker borrowing someone else's NPI. NPI numbers are public — anyone can look up any clinician's number at npiregistry.cms.hhs.gov. That means our verification step confirms "this NPI is real and active and belongs to a clinician in role R, specialty S, state X" — not "the person entering the NPI is that clinician." An attacker could look up another clinician's NPI and post a review attributed to that specialty and state without being the real holder. For v0.1 we mitigate this with: a ≥10-respondent floor on every public data export (one fake review cannot move a public number); mandatory moderation before publication; rate-limiting and cooldown between verify and submit; and the Privacy Pass double-spend guard (one NPI yields one token per key-rotation window). Before the public-repository flip we will ship a second verification factor — a dual-blind email challenge that raises the attacker's cost from ~zero to the ~90 seconds it takes to obtain a burner email — and a later layer using CAQH ProView or DEA last-4 as a credentialing signal. We flag this gap because MANIFESTO §7 requires honesty about what the architecture currently does and does not guarantee.
• Self-identification. If you write "I am the only pediatric-trained anesthesiologist at St. Elsewhere," we cannot un-name you. Review narratives carry this risk every time. We front-load warnings in the submission form and auto-screen for common patterns, but the final say is yours.
• Your login email provider. If you verify from an email account that is subpoena-able (work email, small personal provider), an adversary can compel that provider to hand over session cookies, login IPs, or timestamps that correlate to your posts on DrBox. Use a personal email you control.
• Browser compromise. If your device is surveilled, DrBox cannot hide your activity from whoever controls the device.
• Aggregate correlation. If you review ten facilities and each review narrows the set of people who could have written it, the intersection can identify you even without any leak. We limit this by publishing reviews as structured aggregates whenever possible.
• Operator correlation within the forum. Forum pseudonyms are derived deterministically from (thread, your token) so conversations cohere. A public viewer cannot link your participation across threads. The operator of DrBox — technically — could re-compute the derivation offline across every thread to correlate. We don't, and the public repo + signed version manifest + warrant canary + quarterly independent red-team are the defenses. Full cryptographic prevention requires anonymous-credential machinery (Zcash-level work) we commit to pursuing after v1.
• Illegal surveillance. Nation-state-level adversaries or unlawful interception are outside our threat model.

How discussions work

Reviews answer what is this place like. Discussions answer what does that mean in context. We layer a forum on top of both the review stream and the objective data stream so verified clinicians can contextualize specific numbers or pool judgment on a specific review.

• Within a thread, each verified clinician has a stable pseudonym so a conversation is followable. The pseudonym looks like Clinician-7B2F, accompanied by a badge showing your role, specialty, state, and years-band (what you disclosed on your review/thread).
• Across threads, the same clinician's pseudonym is different in every thread. The derivation is one-way (HMAC), so nobody reading the site can assemble a profile of which threads you've participated in.
• Tier 1 vs Tier 2. Verified clinicians are Tier 1. Patients, family, or unverified readers can post as Tier 2 (captcha + ephemeral-email verification; your email is discarded after the verification code clears, same model as NPI). Tier 2 posts are clearly marked Unverified and do not affect data aggregations.
• Same moderation log as reviews. Removed comments show up in the public moderation log with a reason (MANIFESTO §2).

Full technical spec: docs/architecture/FORUM_SPEC.md.

What we publish, no matter what

Per MANIFESTO §§2 and 4:

• Every moderation action (hide, restore, flag) is public. You can query our moderation log. We cannot quietly remove an inconvenient review.
• Every 90 days we release an anonymized aggregated dataset of all reviews and compensation reports under an open license. If DrBox goes away, the data survives.
• Our entire codebase is public. The code that discards your NPI is visible, auditable, and runs the production system. If we ever changed the discard behavior, the diff would be in the public commit log.

Visual diagram

How to verify any of this yourself

The code that implements every claim on this page is in the public repository:

• src/auth/verify-npi.ts — the NPI verification path and its explicit "no mirror, no persistence" comment
• web/src/pages/api/auth/verify-npi.ts — the HTTP endpoint; read the inline comments for what gets discarded
• docs/architecture/AUTH_FLOW.md — the full flow including log hygiene and compelled-logging posture
• docs/architecture/AGGREGATION_LAYER.md §C3 — reader-side protection (what we refuse to collect about how you browse)
• MANIFESTO.md — the commitments that bind us

If you find a gap between what this page says and what the code does, open an issue. That is how we stay honest.

This page is a P0 launch requirement per docs/product/MVP_SCOPE.md §"Privacy Transparency Layer" and MANIFESTO §7. Last revised: 2026-04-20. Copy authored with Ryan Schmoll, MD (operator); final wording subject to his review.