Governance
Guardrails on by default.
Role-based access, patient-anonymous entry points and attributable records keep each user focused on the part of the placement they are authorised to see.
Roles are assigned server-side — students, clinicians and placement teams each see exactly their slice of the placement, and nothing more.
The logbook records conditions, skills and reflections — never patient-identifiable information, and it says so at every entry point.
Attendance, sign-offs and written feedback accumulate into a single placement record — timestamped, attributable, and ready for review.
The access model
Who sees what.
Roles and access are assigned by the platform, not chosen by users. Each role sees its own part of the placement — the same record, seen three ways, never re-typed.
Student
Their own record. Timetable, check-ins, sign-off requests and returned feedback. Students never see another student’s record.
Clinician
Their cohort. Today’s sessions, the live register and the review queue — and supervisors see their named students first.
Placement team
Coverage, not content they don’t need. Attendance coverage, timetable changes and sign-off progress across the cohort.
| Area | Student | Clinician | Placement team |
|---|---|---|---|
| Timetable | Their own week, with site guidance | Today’s sessions for their cohort | The published cohort timetable, and every change to it |
| Attendance | Their own check-ins | The live register for their sessions | Attendance coverage across the cohort |
| Sign-offs | Their own requests and returned feedback | Their review queue, named students first | Sign-off progress across the cohort |
| Notices | Notices for their cohort | Notices for the cohorts they teach | Every notice published to the cohort |
| Placement record | Their own — never another student’s | The students they supervise and assess | Coverage and records across the cohort, for review |
Each view is fixed by role. Discovery conversations cover requirements, governance and timing before any pilot is configured.
The controls
What holds the guardrails in place.
The platform controls, and the commitments made in the privacy policy — stated here as they are stated there.
- Assigned server-side
- Roles and access are assigned by the platform, not chosen by users — elevated roles cannot be self-claimed.
- Patient-anonymous entry
- Free-text entry points restate the rule wherever it applies: no patient-identifiable information, ever.
- Timestamped & attributable
- Every sign-off records who signed, and when. Attendance is recorded at source as it happens.
- Encrypted in transit
- Data is encrypted in transit, as set out in the privacy policy. We make no wider encryption claim here.
- Database security rules
- Access rules are enforced by our database security rules, so the role a person holds decides what their session can read and write.
- Server-side functions
- Sensitive operations run through server-side functions rather than the browser. Accounts require email verification.
- Data controller
- PlacementFlow Limited, a company registered in England & Wales (company number 17142740), is the data controller for the accounts and service operations it determines.
- Lawful bases
- Under UK GDPR: contract, for the core service; legitimate interests, for attributable records, enquiries and security; and consent, for optional features such as push notifications.
- Sub-processors
- Named in the privacy policy: Google Firebase and Google Cloud, Apple Push Notification service, and a configured email delivery provider, under applicable data-processing terms.
- International transfers
- Some service providers may process personal data outside the United Kingdom. The safeguards depend on the provider, destination and legal role.
- Advertising and tracking
- No third-party advertising, no tracking across unrelated apps or websites, and no sale of personal data.
- Age of users
- Users must be at least 16. Medical students aged 16 or 17 may use PlacementFlow where their programme or institution permits it.
Questions placement teams ask
Governance, answered plainly.
Who assigns roles?
The platform, or an authorised institution — never the user. Roles and access are assigned server-side, elevated roles cannot be self-claimed, and accounts require email verification before they are used.
During a pilot, configuration happens with the school team, and no institutional workspace is created automatically.
What about patient data?
PlacementFlow is for educational record-keeping, not clinical documentation. Records must remain patient-anonymous: no patient names, NHS or hospital numbers, dates of birth, addresses or photographs, anywhere in the service.
The rule is restated at every free-text entry point, and it applies to logbook entries, reflections, messages and support reports alike.
Can a student see another student’s record?
No. A student sees their own record — timetable, check-ins, sign-off requests and returned feedback — and never another student’s.
Clinicians see their cohort, with their named students first. Placement teams see coverage across the cohort, not content they do not need.
Where is data processed?
PlacementFlow Limited, registered in England & Wales, is the data controller. The service runs on Google Firebase and Google Cloud; Apple Push Notification service and a configured email delivery provider are also used.
Some of these providers may process personal data outside the United Kingdom, with safeguards that depend on the provider and destination — a UK adequacy regulation or approved contractual safeguards. The privacy policy has the detail, and you can ask us about any specific transfer.
Governance questions? Ask them early.
Discovery conversations cover requirements, governance and timing before any pilot is configured.
Every request is reviewed by a person.