StudentTempo
Know exactly which students are on site, and when.
Schools request clinical rotation dates. The hospital approves or denies them. Everyone works from the same month schedule — and every change is on the record.
New accounts are reviewed by an administrator before they grant access to anything.
Everything the rotation actually needs
Built around how schools and hospitals already work together — a request, an answer, and a schedule both sides trust.
-
Organizations and programs
Each university or staffing group is its own tenant, owning its programs, students and sites. An MD program, a CRNA program and an AA program sit side by side without ever seeing each other's records.
-
A real student record
Contact details, year of education, hospital badge number, photo and notes — kept in one place so the badge office and the clinical coordinator are reading the same thing.
-
Requests, approved or denied
A school coordinator requests dates at a site; the hospital answers. Two overlapping rotations for the same student are refused outright, so nobody is ever booked in two places at once.
-
The month at a glance
A Gantt-style month schedule with a bar per rotation, coloured by site and striped while it is still pending. Gaps and double-bookings are obvious instead of buried in a spreadsheet.
-
Sharing across organizations
Share one student or a whole schedule with another organization, a named user, or a read-only link for somebody with no account at all. Recipients can request changes, which route back to the owner to accept or decline.
-
Sites the hospital vouches for
Any member can propose a rotation site, but the hospital approves it before a rotation can be booked there. The site list stays a list of places that are genuinely cleared to host students.
Security & privacy
Student data that stays where it belongs
These are not settings somebody has to remember to switch on. They are how the application is built.
-
Per-organization isolation
Every query is scoped to the caller's organization in SQL, not hidden in the interface. A member of one school cannot reach another school's students, rotations or sites even by guessing a URL.
-
Approval before access
People can sign themselves up and pick their organization, but the account grants nothing until an administrator approves it. Registering is a request, not an entry.
-
Share links that expire — and can be cut off
An external read-only link carries an expiry date and can be revoked instantly. Sessions can be revoked live too, so removing somebody's access does not wait for their next sign-in.
-
Exports that hold back by default
A CSV export omits contact details, badge numbers and notes unless somebody deliberately ticks them. The easy path is the one that leaks the least.
-
An audit log worth reading
Sign-ins, denials, exports and every change to a record are written down with who did it and when — so a question about who saw what has an answer.
-
Optional two-factor
Any account can turn on an authenticator app, so a stolen password on its own is not enough to reach a single student record.
How it works
Four steps from a blank account to a schedule the hospital has signed off on.
-
Your organization gets set up
A school or staffing group is added as its own tenant. People sign themselves up and choose it; an administrator approves them.
-
Add programs and students
Create the programs you run, then the students in them — with the year, badge number and contact details the hospital will ask for.
-
Request dates at a site
Pick the student, the site and the dates. The hospital approves or denies it, and an overlap with an existing rotation is refused on the spot.
-
Work from one schedule
The month view shows who is where. Share it with a partner organization or hand out a read-only link that expires — and revoke it whenever you like.
Ready when your next cohort is
Sign in to your organization, or ask an administrator for an account.