Trust & Security
Nightingale solves a hard problem: data is only useful if it comes from real people with real knowledge, but those people need a guarantee of anonymity before they will share sensitive information. Here is how we do both.
All three verification paths follow the same principle: collect evidence, confirm status, destroy evidence. After verification completes, we have no record of what you submitted — only that verification succeeded.
We send a 6-digit code to your work email address at a recognized healthcare domain. The email is immediately deleted after the code is confirmed. Sets your health system affiliation.
We look up your license number against your state Board of Nursing registry in real time. Your name and license number are compared, then permanently deleted. Sets your nursing role (RN, LPN, etc.).
We query the NPPES National Provider Registry with your NPI number and confirm a nursing taxonomy code. Your NPI is deleted after lookup. Sets your nursing role and specialty.
Verification artifacts (email, license number, NPI) are stored only in a temporary schema during the verification window. They are permanently deleted on completion or expiry. There is no long-term record linking your account to your real identity.
Every verification event is recorded in an append-only audit log with no UPDATE or DELETE permissions at the database level. This ensures our records cannot be altered after the fact — critical for accountability without compromising privacy.
Aggregating compensation data to protect individual contributors is a core architectural goal. At launch, facility pages display seed data from primary sources (union CBAs, CMS, BLS). User-submitted entries are not yet displayed in public aggregates — this protects early contributors while the contributor base grows.
Access control is enforced at the PostgreSQL layer via Row-Level Security policies — not application code. Even if application logic has a bug, the database enforces that users can only read what they are permitted to read.
Every compensation, benefits, and working conditions data point carries a source attribution: union CBA, CMS data, BLS statistics, state law, or nurse-reported. You always know where the data comes from and how specific it is.
The verification schema has no foreign keys to the public schema. There is no database path from a compensation entry back to a real identity. This is enforced at the schema design level, not just policy.
The majority of our compensation data comes from primary sources that do not depend on user contributions: union collective bargaining agreements, CMS hospital records, Bureau of Labor Statistics occupational wage surveys, and state nurse licensing databases.
User-contributed data is layered on top of this foundation. Every source is labeled. You can always see whether a figure comes from a union contract, a government survey, or a verified nurse. We never blend sources without attribution.
Read our detailed Privacy Policy or contact us with security questions.