DrBox

Why this exists, who it serves, and what we commit to

The problem

Clinicians are structurally bad at self-advocacy. Not because we lack the capacity for it, but because the work itself trains it out of us. A physician’s attention is supposed to be on the patient in front of them, not on whether the employment contract they signed three years ago contains a non-compete that will follow them through two states. This is how medicine should work, and it is also the reason we are exploitable.

The healthcare employment market does not reward patient-focus with fair treatment. It rewards information asymmetry. Hospital administrators, staffing agencies, and private equity firms know things clinicians don’t: which facilities retaliate against safety reporting, which groups have quietly lost their benefits package, which recruiters ghost after signature, which systems are under investigation, which contracts contain the clauses that will matter in two years. Clinicians walk into these decisions blind and learn the answers after the damage is done.

In a better world, clinicians would unionize. This is legally nearly impossible in most of the country for physicians and structurally difficult for nurses across state lines. It is not going to happen at the scale required to matter in the lifetime of anyone reading this.

DrBox is what we build instead.

What DrBox does

DrBox is a platform for verified clinicians to anonymously review the facilities, health systems, staffing agencies, and recruiters they work with. It combines:

• Structured, specialty-specific ratings of work environment, safety culture, staffing, and retaliation risk
• Structured compensation reports across pay, call structure, benefits, and contract terms
• Pre-populated public data from CMS, NPPES, Census, and BLS for every Medicare-certified facility in the United States
• Location context — cost of living, crime, taxes — alongside employer data

The platform is built around a single question: should I take this job. Every design decision serves that question.

Who we serve

DrBox serves clinicians. Not patients, not hospitals, not payers, not investors. Clinicians.

Specifically: physicians, CRNAs, nurses, AAs, PAs, NPs, and other credentialed providers making employment decisions about where to practice and who to work with.

Who we do not serve

We do not accept money from hospitals, health systems, private equity firms, staffing agencies, or recruiters. Ever.

This is not a market-timing decision. It is a permanent product constraint. The moment an employer can pay us, clinicians can no longer trust us. The platform becomes worthless the day it has hospital-side revenue. We would rather shut down than cross this line.

We do not sell aggregate clinician data to employers, insurers, or private equity firms. We do not display their advertising. We do not partner with them for lead generation. Their relationship with this platform is limited to being reviewed.

What we commit to

These are binding commitments. They are architectural and contractual, not marketing language. When you read a DrBox policy that conflicts with any of these, the commitment wins.

1. We cannot identify our reviewers. Our verification system confirms credentials and then discards them.¹ We store anonymous tokens, not identities. If a court orders us to name a reviewer, the honest answer is that we do not have the information, because we designed the system so that we cannot have it. This is not a policy we could choose to reverse. It is a technical limitation we deliberately built in.²

¹ “Discard” means verification credentials (NPI, nurse license number, name, address returned from NPPES) are not written to persistent storage: not to the database, not to application logs, not to backups. They are briefly present in server memory during the verification call — the seconds between receiving the NPI and returning a verification voucher — and then freed when the request ends. After 2026-04 the platform adopted RFC 9576 Privacy Pass (docs/architecture/PRIVACY_PASS_SPEC.md) for token issuance so the issuer never observes the unblinded reviewer token: even the in-memory exposure window during issuance does not include the value that later identifies a reviewer’s writes. Subpoena of live process memory, and the operational hygiene that prevents log / trace / backup leakage, are addressed in docs/architecture/AUTH_FLOW.md §“Log hygiene” and §“Compelled prospective logging”.

² NPI numbers are themselves public — the NPPES registry is open for lookup by anyone. This means our verify step confirms “this NPI is real and active and belongs to a clinician in role R, specialty S, state X” — not that the person entering the NPI is that clinician. A motivated attacker could look up another clinician’s NPI and submit a review inheriting their credentials. For v0.1 we mitigate this through rate limiting, the Privacy Pass double-spend guard (one NPI yields one token per issuer epoch), a ≥10-respondent floor on public data exports (migration 0014), and mandatory moderation before publication. Before the public repository flip (MANIFESTO §5) we ship v0.2 dual-blind verification: an ephemeral-discarded email step paired with the NPI step, raising attacker cost from near-zero to the ~90 seconds required to obtain a burner email. A v0.3 identity-possession layer (CAQH ProView credentialing lookup, DEA last-4 verification, or state-board license+renewal cross-check) is planned for public launch. We name this gap in docs/architecture/AUTH_FLOW.md §"NPI-borrow threat model" and in the /privacy page because honesty about what we can and cannot protect against is itself commitment #7.

2. We cannot silently alter or remove reviews. Every moderation action — hide, remove, restore, flag — is recorded in a publicly-queryable log with the reason. Users can see exactly what we have moderated and why. We cannot quietly delete an inconvenient review, because our own architecture will not let us.

3. We cannot favor employers. Our policy changes are version-controlled in a public git repository. If the list of known private-equity-owned systems is modified, the change is a public commit. If the review template for anesthesiologists is updated, the change is a public commit. There is no private policy layer where we could quietly accommodate a hospital’s demand.

4. We publish the data. Every 90 days we release an anonymized, aggregated public dataset of all reviews and compensation reports under an open license. If DrBox is destroyed, sued out of existence, or abandoned, the data survives and anyone can rebuild. This commitment is in our Terms of Service. Users contribute knowing their work will outlive the platform.

5. We open-source the code. The entire codebase is public from the first commit. Any clinician with technical skills can fork it and run their own instance. Any researcher can audit how the platform actually works. Any successor can continue the mission.

6. Our revenue only comes from aligned parties. We never accept revenue from hospitals, health systems, private equity firms, staffing agencies, recruiters, or healthcare HR benchmarking services — the entities whose interests compete with clinicians’. We may accept revenue from academic researchers (under Data Use Agreements that prohibit re-identification and resale), medical professional societies representing clinicians, public-interest journalism organizations, government and regulatory bodies, and clinicians themselves (via optional subscription tiers that never gate the core give-to-get mechanic). Every revenue decision is measured against one test: does this increase or decrease our alignment with clinicians? If the answer isn’t clearly “increase,” the answer is no.

7. We tell users what we cannot protect them from. The architecture protects clinicians against most realistic attacks on their anonymity. It does not protect against a clinician who identifies themselves in their own review narrative, against a subpoena of their login email provider, or against correlation with publicly-available information. We say this clearly, in plain language, in the places where users need to hear it. We do not promise perfect anonymity because we cannot deliver it.

Discussion

A review answers what is this place like. A discussion answers what does that actually mean in context. A single HCAHPS drop at a facility could reflect a survey-vendor change, a natural-disaster-driven staffing shortage, or a real safety regression — no aggregation formula can tell those apart. Clinical judgment, pooled across enough credentialed peers, can.

DrBox layers a forum surface on top of both the subjective review stream and the objective data stream. Verified clinicians can discuss a specific review, annotate a specific data card, or contextualize a specific formula output. Patients, family, and the general public can participate in a second, clearly-marked tier — readable and writable but walled off from aggregation and signal ranking.

The forum inherits the anonymity architecture of the review system. Within a single thread, each participant has a deterministic pseudonym derived from a one-way hash of (thread, their anonymous token). Conversations cohere — you know who is replying to whom inside a discussion. Across threads, the same clinician receives different pseudonyms — the public cannot assemble a profile of where a specific clinician has participated, what they care about, or what they have said over time. Full specification in docs/architecture/FORUM_SPEC.md.

The residual trust boundary is the operator: we could, in principle, recompute the hash across threads to correlate a single clinician’s participation. We do not and will not. The cryptographic defenses that would make this impossible in principle (anonymous credentials, zero-knowledge proofs) are substantial engineering work we commit to pursuing after v1. Until then, the defenses are the same ones protecting the review system itself: public code, signed build artifacts, warrant canary, quarterly independent red-team.

Who operates this

DrBox is operated by Ryan Schmoll, an anesthesiologist. The operating entity is an Arizona LLC. The operator’s identity is public because accountability requires identifiability.

Anonymity for the operator would weaken trust, undermine institutional partnerships, and paradoxically reduce legal protection. The platform’s integrity does not come from the operator being hidden; it comes from the operator being architecturally constrained. The rules above are not promises that Ryan will behave well. They are constraints designed so that Ryan cannot behave badly even if he wanted to.

If DrBox ever has other operators, contributors, or successors, they are bound by the same constraints. The constraints are the product. The people implementing them are replaceable.

Why we do this

Because medicine is one of the few remaining professions where the person doing the skilled work is systematically disadvantaged in negotiating with the people who employ them, and because the structural fixes (unionization, collective bargaining, regulatory reform) are not coming.

Because information asymmetry is a solvable technical problem when we choose to solve it.

Because the exploitation of clinicians by private equity, by predatory staffing agencies, by hospital systems that prioritize throughput over safety — this exploitation depends on each clinician being isolated in their own decision. Any tool that lets clinicians pool what they know and make that knowledge available to their peers changes the math.

Because the alternative is continuing to watch colleagues burn out, sign contracts they regret, take jobs with groups that lied to them in recruitment, and discover only afterward that the information they needed was known to other clinicians who had no way to tell them.

Because somebody should build this, and nobody else has.

What this document is

This is the document that wins every future argument about what DrBox is for. When the platform faces a decision — whether to accept a partnership, whether to add a feature, whether to change a policy, whether to respond to a demand letter, whether to monetize, whether to expand — the question to ask is whether the decision is consistent with this document.

If it is, proceed. If it is not, the decision is wrong, regardless of how attractive the short-term reasoning seems.

This document is public, versioned in the repository, and changes to it are themselves public commits subject to scrutiny.

Last revised: 2026-04-20 Operator: Ryan Schmoll, MD Operating entity: [AZ LLC, to be finalized]