Privacy Policy
Effective 20 September 2026
This describes what ResidentReady actually stores and who actually processes it. It describes the software as built, not an intention.
No patient information, ever
ResidentReady is designed to hold no patient-identifiable information in any field, column or log. Enter topics only. The pipeline refuses input that looks identifiable and scans every generated question.
What we hold, and why
- Your name and email address
- To identify your account. Faculty sign in with Google, so the address is the one Google verified.
- Your training information — specialty, training year, program, expected graduation year
- To target assessments at the right level and to group results by knowledge domain.
- Your mobile number, if you give one
- To send you the secure link to an assigned quiz. Only used for that, and only with your opt-in.
- Your quiz answers, scores, response times and any questions you flag
- To score the assessment, write your study pack, and build your longitudinal view.
- Your program membership and role
- To decide what you can see. Access is checked against this on every request.
- Your consent choices, as a dated append-only log
- So that what you agreed to, and when, is reconstructible rather than a flag someone could change quietly.
- Operational and security logs, and an audit record of access to resident data
- To run the service and to be able to say who looked at what.
Who can see your results
Membership of a program lets its faculty see that you took part and how many assessments you completed. It does not let them see your scores. Individual performance additionally requires your consent, which defaults to off, is read fresh on every request, and takes effect immediately when you change it. De-identified results contribute to comparison groups only if you separately allow that, and only when a group is large enough to be meaningful.
A platform operator can create programs but holds no membership in them and cannot read program or resident data.
Text messages
Your mobile number and your SMS opt-in are used for one purpose: delivering the transactional educational notifications you asked for — the secure link to a quiz your program assigned, and reminders about it.
- We do not sell your SMS consent or your mobile number.
- We do not share SMS consent or mobile numbers with third parties or affiliates for their own marketing or promotional purposes.
- A messaging provider processes your number only as needed to deliver the message on our behalf, and for no purpose of its own.
- Reply STOP to opt out at any time. Opting out stops messages; it does not close your account or withdraw other consents.
- The record we keep of a sent message has the quiz link redacted, so reading that log cannot give anyone access to your assessment.
Service providers
- Sign-in for faculty, program staff and operators (OpenID Connect). Google confirms your identity and email; we store its permanent identifier for your account. We request no access to Gmail, Drive or Calendar.
- Anthropic
- Generates and independently verifies candidate questions from retrieved sources. Prompts contain the topic and the source passages; they do not contain resident identities.
- NCBI / PubMed
- Source retrieval. We query it for published literature on the topic a faculty member entered.
- Railway
- Hosting and the managed PostgreSQL database this deployment runs on.
- Twilio
- Text-message delivery, where a messaging provider is configured on this deployment. It receives your mobile number and the message body in order to deliver it.
Which of these are active on this deployment is reported truthfully and publicly at /api/health/identity. If a provider is not configured, the feature refuses rather than pretending to work.
AI processing boundaries
Question generation sends the topic a faculty member typed and passages retrieved from published literature. It does not send resident names, email addresses, mobile numbers or answers. Study packs are written from the questions and the evidence, not from your identity. Every model call is recorded as metadata — provider, model, prompt version, timing, outcome — with the prompt represented by a hash rather than stored.
Retention and deletion
Account, membership, consent and assessment records are kept while the account exists, because the longitudinal view is the product. Consent events are append-only by design: withdrawing consent adds an event, and the earlier one remains as a record of what was true at the time. Assessment links expire and can be revoked. There is no self-service account deletion in this version; a deletion request goes through your program administrator and the operator of this deployment. We do not promise a deletion window we have not built.
Security, honestly stated
Sessions are opaque tokens stored only as digests, so reading the database cannot mint one. Access to program data is checked against the database on every request. Quiz links are high-entropy, scoped to one resident and one session, expiring and revocable. Traffic is served over HTTPS.
What we do not claim: ResidentReady is not certified under HIPAA, FERPA or SOC 2, has had no external penetration test, and makes no guarantee of encryption at rest beyond what the hosting platform provides by default. No system is perfectly secure, and this one is new.
Changes
The effective date above changes when this policy does. Material changes to how messaging or consent works will be reflected here before they take effect.
Contact
Privacy questions: info@reconstructivetrauma.com.
Related: Terms of Service.