CaNaMED — Privacy Policy

How we use your data, and your rights

Notice version PIS v12 · 2026-10. ← Back to the platform

This page is the full privacy policy for the CaNaMED platform (https://canamed-69785.web.app), delivered as a layered notice to satisfy GDPR Article 13 for participants in France and APPI Article 17, 21, 27(5), 28 for participants in Japan. The short summary shown on the join screen is for quick reading; this longer page is the legally binding text. If anything below contradicts the short summary, this text governs.

1. Who is the data controller

For the session you are joining, the controller is the institution named on the join screen, before the consent boxes. A facilitator names their own institution when they create a session, and that is the organisation responsible for your data in it. Where that institution is one of the two below — the sessions the CaNaMED team itself runs — the joint-controller arrangement described here applies.

The CaNaMED platform is run jointly by:

The two universities are joint controllers under GDPR Art. 26 and conduct joint use (共同利用) under APPI Art. 27(5). The single point of contact for data-subject rights is Université de Caen Normandie's DPO. A summary of the joint-controller arrangement is available on request.

2. Why we collect your data

We use your data for the following purposes only. New purposes require a new consent notice.

  1. Running the live workshop — placing you in a balanced inter-university room, showing your name and contributions to others in that room, and computing the team scores.
  2. Facilitator debriefing — at the end of the session your facilitator downloads a copy of every group's work (the "archive") for that day's debrief.
  3. Education-research analysis and publication — if you ticked the optional second consent box on the join form, your contributions are recorded linked to you (your name and university, and — if you sign in with Google — your email) for analysis by the named CaNaMED study team. Other participants never see your identity; only the study team does. Published outputs (medical-education journals, PhD theses) report aggregated findings and do not identify you.

3. Legal basis

Under GDPR: Art. 6(1)(a) explicit consent; Art. 9(2)(a) explicit consent for special-category data; Art. 9(2)(j) scientific research with Art. 89 safeguards. Under APPI: Art. 17/21 purpose specification; Art. 20(2) prior opt-in consent for sensitive personal information (要配慮個人情報); Art. 27(5) joint use.

4. What we collect

From you, on the join form: first name, university, year of study, self-rated English (CEFR). From your activity: free-text answers, votes, reveals, presence, points. From your device: a random per-tab client ID in sessionStorage. From Google (if you sign in): email, display name, optional profile picture.

From Google Firebase Authentication, for every visitor: when the platform opens, your browser is signed in anonymously — before you enter a session code or tick any box. That gives it a random technical identifier. The identifier carries no name and no e-mail address, but it is kept in this browser's storage and stays the same from one visit to the next. The platform needs it to tell one participant's contributions from another's, and the database uses it to decide what each browser may read and write. If you later create an account, that identifier becomes the account's.

If you use the simulated-patient chat, the number of messages you send per hour and per day is counted against that identifier, and the number sent per hour in your session is counted against the session, to enforce usage limits.

5. Sensitive personal information

The workshop scenarios cover opioid prescribing, breaking bad news, end-of-life disclosure, and family-vs-autonomy ethics. Free-text answers may disclose health-related, religious or philosophical opinions — special-category data / 要配慮個人情報 processed only on your explicit consent.

6. Recipients and processors

Data is held on Google Firebase Realtime Database, Google acting as our processor under the Firebase DPA and EU SCCs. Within the universities: the named CaNaMED research team, your facilitator, and the platform administrator.

Sessions are held by video conference on Microsoft Teams, under the university's subscription. Microsoft acts as our processor for the conference itself, for the written transcript the tool generates automatically, and for the audio/video recording of the session. The transcript carries each speaker's name against each utterance.

Module A includes a simulated patient voiced by a language model. What you type into that chat leaves the platform. It goes first to Scaleway SAS (Paris, France), which relays the request and stores nothing; then through Hugging Face, which routes it to a model provider; and finally to OVHcloud (Gravelines, France), which runs the model and writes the reply. All three act for us as processors or sub-processors. Scaleway additionally receives your sign-in token and the session and room names, used only to check that you belong to the room; these are not passed on. Hugging Face and OVHcloud receive the conversation and the scenario's instructions, and nothing else. Please type only what you would ask in a real consultation.

The platform's scheduled maintenance jobs run on GitHub Actions (GitHub, Inc., United States). Apart from the two full copies described at the end of this paragraph, the jobs that run every day do not read your session content. They read a list of session identifiers and, for each session, the two dates that decide when it is deleted; one also reads the certificate records. Requests to withdraw consent or to have data erased are read too, with the record of those already carried out: for each, the session's identifier, the person's technical identifiers, a date and what was asked, and for a request already carried out the operator's note of the reason. A further job, which deletes technical identifiers that are no longer in use (section 8), reads: the list of those identifiers with the dates they were created and last used; the identifiers of the members and the creator of each current session; whether a profile, a session history or authored scenarios are stored under an identifier, but not what they contain; the operator's lists of approved facilitators and moderators; and, for each of the chat's usage counters, which identifier or session it belongs to and its time slot. It receives no name and no e-mail address — for an account you signed in with, only its identifier, its dates and the name of the sign-in method. Until 2026-09-01 two of these jobs copied the whole live session database onto a GitHub machine every day — one to decide what to delete, one to weigh how large the database had become. Neither needed the contents to do its work, and neither does it any more. A third job, which watches for erasure requests that have gone unanswered, did the same from 2026-09-04 to 2026-10-07, although it needed only the requests; it has been corrected. These jobs report only counts and dates — no personal data is written into their logs. Two further jobs that copy the session database in full, a backup and the pseudonymised research export, are running again as of 2026-09-01. They write to Scaleway object storage in Paris, the same processor that relays the AI chat; the copies stay inside the EEA and are readable only by the platform administrator. To make them, each of these two jobs reads the whole live session database on the same GitHub machines as the other jobs, once a day, and the content is on that machine for as long as the job runs. From 2026-08-27, when the platform left Google's paid plan and the storage they used stopped accepting writes, they still ran each day but could store no copy; they were switched off on 2026-08-31.

7. International transfers

The database is hosted in Belgium (Google europe-west1). For Japanese participants this is a cross-border transfer under APPI Art. 28, protected by the 2019 EU–Japan mutual adequacy decision (PPC).

The simulated-patient chat travels a separate path. The relay (Scaleway, Paris) and the model that writes the reply (OVHcloud, Gravelines) are both in France, inside the EEA. The Hugging Face routing step between them is outside the EEA, so what you type in that chat crosses that border and comes back. Until 2026-08-31 the relay ran on Google Cloud; it moved to Scaleway when the platform left Google's paid plan.

Those maintenance jobs are still a transfer outside the EEA. For all but two of them, what crosses is session identifiers, two dates per session and the certificate records, rather than your session content. The two that copy the session database in full (section 6) are the exception: they read all of it on a GitHub machine, so your session content does cross, once a day for each, while the job runs. The technical identifiers described in section 4 cross with them, together with their dates and the time slots of their usage counters. So do the requests to withdraw consent or to have data erased, and the record of those carried out. GitHub, Inc. is established in the United States, and the jobs run on Microsoft Azure machines whose region GitHub does not publish and which we cannot choose. The safeguard for this transfer is the EU–US Data Privacy Framework: GitHub, Inc. is a certified participant, active since 2017 and re-certified to August 2027, and its certification expressly covers the data of free-account users. Transfers to a certified organisation are covered by the European Commission's adequacy decision of 10 July 2023, so no additional contract clauses are required. (An earlier version of this notice said this check was still outstanding; it was completed on 2026-09-01.) For Japanese participants this is a cross-border transfer under APPI Art. 28 to a country outside the EU–Japan arrangement described above.

8. Retention

9. Your rights

Access, rectification, erasure, restriction, portability, objection, consent withdrawal (GDPR Art. 15-21, 7(3); APPI Art. 33-35, 38). To exercise: canamed-ethics@unicaen.fr. Acknowledged within 5 working days; response within 30 days. No effect on your grades, university standing, or workshop participation.

10. Withdrawing consent

You can withdraw consent for research use at any time. Press Leave at any time to exit the workshop. Already-submitted contributions remain in the room's record for facilitator debriefing unless you also request deletion at the contact above.

11. Right to complain

12. Automated decision-making

The platform awards points based on team text + clinical choices. Scores are in-session pedagogy only, no profiling, no legal effects (GDPR Art. 22; APPI Art. 26-3).

13. Security

HTTPS, access-control rules per-session, PBKDF2-SHA256 password hashes (100,000 iterations). Breach: CNIL within 72h (GDPR Art. 33-34); PPC preliminary 3-5 days, final 30 days (APPI Art. 26 2022 amendment).

14. Children

Intended for adult medical students aged 18+. If under 16 (GDPR Art. 8) or under 20 (Japanese university norms), contact your facilitator before joining.

15. Ethics-committee approvals

This study has been reviewed and approved by the Caen ethics committee and the Nagoya bioethics committee (numbers + dates filled in per cohort).

16. Versioning

Version PIS v12 · 2026-10. Material changes since PIS v11: section 4 now describes the technical identifier your browser is given when the platform opens — before any consent — and the usage counters of the simulated-patient chat. Earlier versions mentioned neither. Section 8 states how long each is kept: until October 2026 neither was deleted at all; the identifier is now deleted after 90 days without use and the counters within about three days. Sections 6 and 7 say what the job that does this reads, and that it runs outside the EEA. Separately: until 2026-08-25 a programming error recorded, under that identifier, the code of each session joined, with the workshop and scenario names and the time — including for participants who never created an account. The error was corrected on 2026-08-25, and what it left behind is deleted by the same job. Section 6 now also says that the daily jobs read requests to withdraw consent or to have data erased, which earlier versions did not mention, and that one of them copied the whole live session database to a GitHub machine every day from 2026-09-04 to 2026-10-07 without needing to. Sections 6 and 7 also say, for the first time, that the backup and the research export read the whole live session database on a GitHub machine once a day, so that session content crosses the border while they run; earlier versions said it did not. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v10, carried forward: section 1 no longer states that Université de Caen Normandie and Nagoya University are the controllers of every session. Any facilitator can run a session on this platform, and theirs is the institution responsible for your data in it — it is named on the join screen, before the consent boxes. The two universities remain joint controllers for the sessions the CaNaMED team itself runs. Nothing about how your data is handled changed; the notice was naming the wrong organisation for sessions run by anyone else. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v9, carried forward: we have corrected what section 8 says about deletion. Live session data is still purged 30 days after a session closes (90 days if it is never closed), but a copy remains in our nightly backups, which delete themselves 90 days after they are taken — so the last copy of a session disappears about 120 days after it closes, not 30. Nothing about our practice has changed: this was always the case and the notice did not say so. Backups are used only to restore the service after an incident. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v8, carried forward: the nightly backup and the pseudonymised research export are running again, and they now write to Scaleway object storage in Paris rather than to Google (section 6). Scaleway was already handling the AI chat, so this is an existing processor doing an additional job, not a new recipient; the copies stay in the EEA. Between 2026-08-27 and 2026-09-01 no backup was being taken at all, while old sessions continued to be deleted on schedule. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v7, carried forward: the outstanding question about the safeguard for the GitHub transfer is answered. GitHub, Inc. is an active participant in the EU–US Data Privacy Framework and its certification covers free-account users' data, so the transfer rests on the European Commission's adequacy decision rather than on contract clauses (section 7). Nothing about the transfer itself changed; only what we can tell you about it. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v6, carried forward: no scheduled maintenance job reads your session content at all now. The storage monitor was the last one that did — it read the whole database each day only to measure its size — and it no longer does; it watches the number of sessions instead. What still crosses to the United States is session identifiers, two dates per session and the certificate records (sections 6 and 7). Like the v6 change below, this reduces what leaves the EEA. Corrected in v12, above: the backup and the research export do read session content. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v5, carried forward: the job that deletes old sessions no longer reads your session data at all. It now reads only a list of session identifiers and two dates for each, so the daily copy of the whole database onto a machine in the United States is gone; the storage monitor still makes one (section 6). This reduces what leaves the EEA rather than adding to it, and is recorded here because section 6 said "two" jobs and now says one. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v4, carried forward: disclosed that the platform's scheduled maintenance jobs run on GitHub Actions in the United States, that two of them read the whole live session database onto a GitHub machine daily, and that this is a transfer outside the EEA whose safeguard is still being confirmed (sections 6 and 7). Like the v4 change below, this processing was already running and had simply never been described. Material changes are issued under a new version with re-consent on next join. Material changes since PIS v3, carried forward: disclosed the simulated-patient chat in Module A and the three recipients it passes through — Scaleway (Paris), Hugging Face and OVHcloud (Gravelines) — together with what each of them receives (section 6), and recorded that the Hugging Face routing step sits outside the EEA (section 7). That processing was already running: it was not described in earlier versions of this notice, and this version corrects the omission. Material changes are issued under a new version with re-consent on next join. Older versions on file at canamed-ethics@unicaen.fr.

17. Local data on your device

sessionStorage: per-tab client ID (cleared on tab close), error-log buffer (cleared on tab close). localStorage: session code, resume details, sound preference, UI language, facilitator's last workshop setup (never any password). No third-party cookies, no tracking pixels.

The browser also stores the sign-in credential behind the technical identifier described in section 4 (in IndexedDB, or in localStorage where IndexedDB is unavailable). That is what keeps the identifier the same from one visit to the next. Clearing this site's data in your browser removes it from your device; the identifier itself is then deleted on the schedule in section 8.

18. Certificate verification

So that a third party who is given your certificate of attendance can confirm it is genuine, every certificate is independently verifiable by default. Only a one-way hash of your name and session is ever stored — never your name itself — and you can have your entry removed at any time (see "Removal / opt-out" below).

How it works. Your certificate is stamped with a verification ID and a QR code. The third party (for example, an employer, a university, or yourself) visits a public page on the CaNaMED site and enters BOTH the verification ID printed on the certificate AND the name printed on it. The page replies "valid" or "no match". We do not publish your name: the page only confirms a match when both inputs are supplied.

Data stored for this purpose. A separate registry holds, per participant, the verification ID, a one-way hash of your name + session, the session label and the issue date. No free-text content, no contact details, no email, no contributions, and not your name in clear. The registry is read by the verification page only via an exact-ID lookup; it cannot be listed or browsed.

Legal basis. GDPR Art. 6(1)(f) legitimate interests — issuing a certificate of attendance that can be trusted — with the balancing safeguards that only a one-way hash is stored (never your name), the registry cannot be browsed, and removal is available on request; APPI Art. 17/18. This is a distinct processing purpose from the workshop run, the facilitator debrief and the education-research analysis (see sections 2 & 3).

Retention. Verification entries are retained for up to 5 years after issue so that the certificate remains checkable over the typical professional time-frame of an attestation of attendance. You may request earlier removal at any time (see "Removal / opt-out" below); the already-printed certificate is unaffected, but the public page will no longer confirm it.

Removal / opt-out. Email canamed-ethics@unicaen.fr with your verification ID and we remove the registry entry within 5 working days. This has no effect on your participation, the research dataset (governed by its own consent in sections 2–10), your grades or your university standing.

← Back to the platform  ·  canamed-69785.web.app