Privacy Policy

1. About this policy

DebriefMD is a tool for medical residents and other trainees. A resident records a spoken feedback conversation with their preceptor. DebriefMD transcribes it, removes identifiers, and drafts the structured assessment form the resident's program requires. The resident reviews and edits the draft, and nothing drafted from a debrief is exported, sent or released until the resident has approved it.

Those conversations happen in clinical settings, so they can incidentally contain personal health information about patients. The audio and the raw transcript are collected, stored and processed before any identifier is removed (section 8). This policy explains what DebriefMD collects, why, where it lives, how long it is kept, who receives it, and what you can do about it.

DebriefMD is operated by 1581455 B.C. Ltd., a company incorporated under the Business Corporations Act (British Columbia) and doing business as WhiteCoat Prep. DebriefMD is a product offering of WhiteCoat Prep.

This policy covers the DebriefMD website and web application at debriefmd.ca and app.debriefmd.ca, and the processing pipeline behind them. It does not cover your residency program's own systems, your hospital's systems, or the assessment platform you ultimately submit a completed form into.

2. Who this policy is about

Three groups of people appear in DebriefMD's data.

Residents and trainees. You hold the account. Most of this policy is addressed to you.

Preceptors and supervisors. Your name, email, specialty, and site may be stored in DebriefMD because a resident entered them, and you may receive email from DebriefMD. Section 6 is about you specifically.

Faculty and program staff. Program directors, associate directors, program administrators, site directors and local administrators, faculty who prepare rotation reports, and our own support staff hold accounts with role-specific access. Section 11 says what each role can see; what we hold about them as account holders is described in section 3.

Patients. DebriefMD has no patient-facing feature, and users are asked not to say patient identifiers. A spoken feedback conversation may nonetheless mention a patient or a colleague, and the audio and raw transcript can then hold identifiable information about them until those records are deleted. Sections 7 and 8 explain what we do about that, and where the limits are.

A further group holds no account: visitors to the public demo, who record without signing in. Section 3.13 is about them.

3. What we collect

Everything below is enumerated from the actual database schema. We do not collect categories of information that are not on this list.

3.1 Account and sign-in information

When you create an account:

• Your email address.
• Your name, if your sign-in provider supplies it.
• A profile image URL, if your sign-in provider supplies one.
• An email verification timestamp.

Sign-in is by magic link only. Google sign-in is switched off and is not offered. Accounts created with it while it was available sign in by magic link to the same address; the records Google returned at the time (provider name, provider account identifier, tokens, token expiry and type, and granted scopes) are retained with the account but are not used.

If you sign in with a magic link, we store a short-lived verification token tied to your email address. It expires after 24 hours.

We store an active session record (an opaque session token, your user ID, and an expiry) for as long as you remain signed in, up to 30 days.

3.2 Your resident profile

Collected during onboarding and editable in settings:

• Full name
• Contact email for notifications (see section 3.3)
• Program (for example, UBC Family Medicine)
• Specialty
• Year of training (PGY level)
• Site or location
• Your Competence by Design stage, for Royal College programs only, if you or your program's director sets it. It is only ever set by one of you, never inferred from your record, and it is used to order the form picker.

3.3 Notification email verification

If you ask for notifications at an address different from the one you signed in with, we temporarily store the pending address, a random confirmation token, and an expiry timestamp. Once you click the confirmation link, the pending address becomes your notification address and the token is cleared. This exists so that a notification linking to your assessments cannot be routed to an address you do not control.

3.4 Preceptor records

For each preceptor a resident records with, DebriefMD stores:

• Name
• Email address (optional)
• Specialty (optional)
• Site (optional)
• Which user created the record

Please read section 6, which addresses the fact that this is information about a third party.

If you pin a preceptor as a favourite in the picker, we store that pairing: your account, that preceptor's record, and when you pinned it. It is your own preference, it orders your picker and nothing else, nobody else can see it, and it is deleted with your account.

When you send a preceptor the finished coaching note (section 11), we also store, for that send: the address it went to; the single-use references behind the links in the email; a copy of the note exactly as it was sent, so the view link shows what the email carried rather than a later edit; a copy of the entrustment rating as it stood, for the same reason; a count of how many times the view link was opened, which we treat as telemetry and never as evidence that anyone read anything; and, if the preceptor answers the one-tap question about the rating, their answer and when they gave it. Section 6.3 says what each link does, and section 9.1 how long each of these lasts.

3.5 Recording session metadata

For each feedback session:

• The resident who created it
• The preceptor, rotation, and assessment form template selected
• The date of the session
• The two confirmations the resident gave before recording (section 5.2), the language the consent screen was shown in, a version identifier for the exact consent wording that was displayed, the time the resident's device says recording started, and the time our server received the confirmation. A recording made before the two confirmations existed, including one that waited in a device's queue, keeps the single confirmation and the version it was made under; no second confirmation is inferred for it
• Processing status

3.6 The recording and its transcripts

• The audio recording of the feedback conversation, stored as an object in encrypted cloud storage. If it was captured with no connection, it waits in your browser's storage until it can be uploaded. Section 9.1 covers how long that lasts, and why there is no limit on it.
• The raw transcript: the verbatim speech-to-text output, before identifier removal.
• The de-identified transcript: the same text after automated identifier removal. This is the version shown to you in the app. It is a separate record from the raw transcript.

The audio and the raw transcript are source material: they can contain identifiable information about a patient or colleague who was mentioned, and they are stored in that form until they are deleted (section 9.1).

• Recording duration, detected language, and a speech-recognition confidence score.

3.7 Generated assessments

• The structured form fields the model filled in
• Competency tags
• A narrative summary
• "Did well" and "consider" coaching notes
• Model confidence scores
• The edits you make, whether you have reviewed and approved each note, and when the debrief was first saved, sent or downloaded. Saving, sending or downloading does not make the notes visible to anyone in the app
• What you shared with your program, if you use "Share with program" (section 11): when you shared, a fingerprint of the exact reviewed version you confirmed, and a copy of those reviewed notes taken at that moment. That copy is what authorized program and home-site leadership read. A debrief released under the earlier rule, when saving or downloading also released it, is recorded as released that way, with a copy of its reviewed notes taken when the change was made
• The deliveries made from it: who a finished note was emailed to, and when
• A progress narrative, if you ask for one. From the summary screen you can ask the model for a paragraph that reads your whole record in one program back to you. We store the paragraph the model wrote, the counts it was written from, the number of debriefs it covers, and your year of training at the time. If you choose to release it to your program (section 11), we also store the text you released, which may differ from the model's draft, and when you released or withdrew it.

3.8 Your own self-rating

Before you see the assessment drafted from a debrief, DebriefMD offers you a short private prompt: how you think you handled each competency area. If you answer, we store your chosen level for each area you rated, and the time you answered. If you decline, we store the fact that you declined and when. If you never reach the prompt, nothing is stored.

Two things about this record:

• It is written once and never changed. The point of it is what you believed before you saw anyone else's view, so there is no path in the product to revise it afterwards.
• It is private to you, and it stays that way. It is never shown to your preceptor, your program, or an administrator, and it is not in any PDF, spreadsheet, transcript, or summary. The one place it can appear is a copy sent to you, at your own verified address, when you email yourself a finished debrief. Section 11 lists who receives what.

3.9 Support requests

If you ask us for help through the application, we store what you sent: the subject line and the message you wrote, the category you chose, the status of the request, and when it was filed and last updated. We also store which account filed it, and — as context for whoever picks it up — the program and institution recorded on your profile at the time.

Two things you should know before you type.

• The message box is free text, and we cannot see inside it in advance. You might quote a transcript, name your preceptor, or describe a patient in the course of explaining what went wrong. We do not ask you to, and we would rather you did not, but a box you can type anything into is a box that may end up holding health information. So we treat it as though it does: your message stays in the same encrypted database, in Montréal, as your recordings and assessments, it is never copied into an email, and it never goes to a third-party helpdesk. When a request is filed, the notification that reaches us carries the request's reference number and category — not your subject line, and not a word of your message. The same discipline applies in your direction: when our team changes your request's status, we email you that it changed, and that email carries the category you picked and the new status word — never your subject line and never your message, which stay readable only in the app.
• We attach some technical details automatically, and they are only ever technical. If you arrive at the form from something that failed, we attach a fixed list of reference details about the failure: the internal reference of the affected debrief, its status, an error code, the number of upload attempts, and which step of processing it stopped at. That list is fixed in the software and cannot be widened by what you type. It identifies a failed record; it carries no part of what was said in a debrief. You can see exactly what is attached on the form before you send it.

Who reads it: you, and our support staff. Support staff are a small, separately granted role, and it is the one role in DebriefMD that reads across programs and institutions — a person triaging a broken upload has to be able to see the broken upload, whoever filed it. It is granted directly in the database rather than through any screen in the application, so it cannot be given out by mistake through an ordinary administrator action. Your program director does not get this access by virtue of being a director, and no amount of program or site administration confers it. Section 11 sets out who sees what.

Support staff can also ask the model we use for everything else (section 16) to draft a first reply to your request. What the model receives is your subject line, your message and the attached technical details; what comes back is a draft on the agent's screen, which a person reads, edits and, if they choose, sends to you themselves. DebriefMD has no button that sends it. Nothing about the draft is stored: the only record kept is an audit-log entry that a draft was requested, carrying a count and none of the text. The draft is produced where every other model call runs, on Amazon Bedrock in Montréal, and your message is handed to the model marked as text to be read rather than instructions to be followed.

3.10 Requests to stop receiving email

If you use the "stop sending DebriefMD email to this address" link in the footer of an email we sent you, we store the address, the reason it is on the list (you asked; the address bounced; a complaint came back; or a person here decided), how it got there, and when. Nothing else — no name, no link to any resident, no link to any debrief, and nothing about what the email contained.

We keep it because forgetting it is exactly what would make the emails resume, which is why it is one of the few records that survives the deletion of the account whose activity prompted the email. Section 6.3 describes this from the point of view of a preceptor, who is the person most likely to use it.

The link in each email works by carrying a single random reference that identifies only itself. It is not a login and it grants no access: the page it opens shows the date we wrote to you and nothing more, so an email forwarded to a colleague discloses nothing about the resident or the debrief. It cannot be used to ask us whether some other address is on the list — the page and the underlying request accept no address at all.

This stops notifications; it does not stop sign-in email. If you hold a DebriefMD account, magic-link sign-in emails and confirmations of a change you asked for are outside this list on purpose, because suppressing them would lock you out of the account where all your data is. To stop using DebriefMD altogether, see section 10.3.

3.11 Operational records

• Pipeline logs: for each processing step, the step name, outcome, duration, any error message, and small non-identifying metadata such as redaction counts and model name.
• Audit log: for actions on sensitive resources, such as editing a preceptor or exporting a session, we record who did it, what action, against which record, the outcome, your IP address, and your browser user-agent string. This log is append-only. It exists because health privacy law expects a record of who accessed what.
• Server and infrastructure logs: application logs, load balancer logs, and rejected-connection network logs, retained for one month.
• Which policies you accepted, and when: when you finish setting up your account, we record that you accepted the Terms of Service, this Privacy Policy, and the Acceptable Use Policy, together with the dated version of each that was published at that moment. Each of these documents carries a date at the top, and it is that date we store. The record exists so that "which version did I agree to?" has an answer rather than an assumption. Two honest notes about it. First, if you set up your account before we began keeping this record, we hold a row that says only that you accepted something, without a version or a date, because that is all we know and putting a date on it would be a guess. Second, the record is not a claim that you read anything; it is a record of what was published and shown to you at the moment you continued. You can see your own record at any time under Settings → Policies you've accepted. It is visible to you and to us, never to a preceptor, a program, or an administrator, and it is deleted with your account.

3.12 What we do not collect

We do not ask for or store patient names, health card numbers, medical record numbers, or patient charts. We do not collect payment information. We run no advertising, no tracking pixels, no session replay, and no cross-site tracking.

Analytics collection is paused. No analytics script loads and no analytics request is made, even if you previously opted in. If you saved an analytics preference, the preference itself may remain stored; it currently has no effect. If we turn analytics back on, it could process technical usage information outside Canada, and we will update this policy before it does. /cookies describes browser storage in full.

3.13 The public demo

Anyone can try DebriefMD at /demo without an account. It is not a simulation: the recording you make there is real audio, uploaded to the same encrypted storage and run through the same transcription, identifier removal and extraction as a resident's debrief. Because there is no account, every demo recording is attached to one fixed demo account inside a demo program of its own, so it never appears in any real program's figures and is never linked to you. Nothing is emailed to anyone about a demo recording. When processing finishes the draft appears on the page, and you can download it as a PDF, Word, Excel, CSV or Markdown file. That file is an unreviewed draft: no resident has signed it off, and every format says so inside the file itself. The download carries no transcript.

The page asks you to use made-up names and no real patient or colleague details, because it is public and the draft is nobody's record. Recording stops after 90 seconds, and the page is rate-limited: we count requests per visitor address and in total, per hour, and refuse rather than proceed when the count cannot be read. Your address is held in that counter and deleted after two days of inactivity.

A demo recording is deleted after 30 days, all of it. The audio, the raw transcript, the de-identified transcript and the draft assessment are all removed 30 days after you record, by the same storage rule and the same content-retention routine that apply to everyone else (section 9). Because there is no account here, nothing is kept back: the session is deleted outright rather than emptied out, so 30 days later there is no record that it happened. One limit on that, stated the same way we state it for support requests in section 9.1: the routine is meant to run automatically once a day, and we have not yet confirmed that daily schedule is registered on the live database, so until we have, the deletion may be happening only when we run the routine ourselves. It is a scheduling gap, not a change to the rule. If you would like a demo recording removed sooner, write to hello@debriefmd.ca.

3.14 The closing conversation of a rotation report

Your program's faculty may prepare an In-Training Assessment Report for one of your rotations (section 11 describes what it is and when you see it). To write its comment boxes, the faculty member who will sign it may record the closing conversation of the rotation — a conversation between the two of you, which they record, with your agreement, on their own device. That recording is theirs, not yours, and this section is here because it is a recording of you.

We hold, for each closing conversation: the audio, the raw transcript, the de-identified transcript, the recording's duration and language, a record of the two confirmations the faculty member made before recording (that they understand how the recording will be processed and shared and will avoid patient identifiers, and that you approved the recording and the AI processing and recipients they explained, including that you will not hear it or read its transcript), with its wording version and the moment it was made. A closing conversation recorded under the earlier single-confirmation wording keeps that one confirmation, and the draft comments the model wrote from the transcript, keyed to the report's comment boxes.

Three things about it are decided and stated on the consent screen the faculty member sees before recording:

• You will not hear the recording and will not read its transcript. What you see is the signed report (section 11). The faculty member attests, before recording, that you have agreed to the recording and have been told this.
• It writes prose only. The conversation is used to draft the report's written comments. It never sets a rating, a level or the report's overall assessment; those are entered by the person who signs, at signature, and the software that drafts the comments has no place to put one.
• It is deleted with the faculty member's account, because it is theirs, and with the report, because a recording of you kept after the report about you is gone would be kept for nothing. Its audio and raw transcript expire on the same 30-day clock as everyone's (section 9.1).

Nothing is emailed to anyone about a closing conversation.

4. Why we collect it, and our legal basis

The authority for each use of information depends on the activity, the role of the person involved, and the law that applies to that information (section 14). Individual consent, a public body's own authority and an institution's instructions are different mechanisms, and one does not stand in for another. Your acceptance of these documents covers your own use of DebriefMD; it does not authorize the collection of every patient's information, and it does not authorize unrelated research or model training. An institution that adopts DebriefMD for a program needs its own privacy, security and recording approvals and an agreement with us.

For your own account and recordings, DebriefMD relies on your express, informed consent, obtained at two points:

1. At account creation, for account and profile information, by proceeding through onboarding.
2. Before every single recording, by a consent screen with two separate confirmations, both unticked to begin with, both of which you must tick before the microphone is requested. The screen says that cloud audio is encrypted and processed in Canada and that a copy may stay on your device; that automatic identifier removal can miss details; how long audio, transcripts and notes are kept; who is emailed when the assessment is ready; that transcripts and audio are not emailed; and that downloads and email copies do not give your program access, which reads your reviewed notes only if you choose "Share with program". The first confirmation says that you understand how the recording will be processed and shared and will avoid patient identifiers; the second, that your preceptor approved the recording and the AI processing and recipients you explained to them (section 5.2 quotes both). They are permission to record and process the conversation, not approval of an assessment that does not yet exist. The exact wording shown to you is versioned and stored alongside the session, with the language and both answers, so we can later reconstruct what you were shown.

A faculty member recording the closing conversation of a rotation report makes separate confirmations of their own, with their own wording (section 3.14).

We use the information for these purposes and no others:

We do not sell personal information. We do not use it for advertising. We do not use your recordings, transcripts, or assessments to train machine learning models, and neither does the provider that runs the model for us. Amazon's own documentation for Bedrock, the service the model runs on, says that "AWS and the third-party model providers will not use any inputs to or outputs from Amazon Bedrock to train Amazon Nova, Amazon Titan, or any third-party models", that "users' inputs and model outputs are not shared with any model providers", and that content it processes is encrypted and stored at rest in the region where the service is used — for us, Montréal. That is a commitment Amazon publishes to everyone rather than a letter written to us, and we would rather tell you which it is than let it read as the stronger thing.

Speech-to-text is a separate question with a separate answer. Amazon's default across its AI services is that content may be used to improve them, and stored outside the region you are using while that happens; there is a policy that switches it off, and we have applied it to our AWS organization. We have not yet confirmed whether the policy as applied covers every AWS AI service or speech-to-text alone, so we state only that it is applied. A provider's published commitment or service terms can be revised by the provider, and a US health-privacy agreement would not by itself establish compliance with Canadian law. Both answers, with the exact wording and where to read it, are in the sub-processor list: /sub-processors.

5. Consent, and its limits

5.1 Your consent

You may withhold consent by simply not recording. DebriefMD has no function that operates without an explicit per-recording consent step.

You may withdraw consent at any time. See section 10.

5.2 Your preceptor's consent

Your preceptor consents by saying yes, out loud, before the recording starts.

Preceptors do not have DebriefMD accounts. There is no screen anywhere in the product where a preceptor agrees to anything, and DebriefMD never contacts them to ask. The agreement is a conversation between a resident and a supervisor, and it happens before the microphone is on.

What DebriefMD holds is the resident's record of that conversation. Before each recording the resident must tick two separate boxes, both unticked to begin with, and the microphone is not requested until both are ticked:

1. "I understand how this recording will be processed and shared, and I will avoid patient identifiers."
2. "I confirm my preceptor approved this recording and the AI processing and recipients I explained to them."

(The French screen asks the same two questions in French.) These ticks are the resident's attestations, the documentation of the consent rather than the consent itself. They are not the preceptor's signature, and they are not approval of any assessment written later. We store both answers, the version and language of the disclosure wording the resident was shown, the time the resident's device says recording started and the time our server received it, including for a recording that waited offline before uploading. A recording queued before the two boxes existed keeps the single attestation and version it was made under; we do not infer a second one for it.

DebriefMD does not obtain your preceptor's consent, cannot verify it, and does not contact your preceptor to confirm it.

So the practical burden of getting the preceptor's agreement rests entirely on the resident. Recording a person without their knowledge or consent may breach institutional policy and, depending on the circumstances, the law. Do not do it.

There is more residents should say when they ask. The recording is transcribed and processed by AI in the way section 8 describes. By default, DebriefMD emails the resident-reviewed finished note to the preceptor once the resident has approved it; the email carries no transcript and no audio. And if the resident chooses "Share with program", a copy of the reviewed notes becomes visible to authorized leadership of the resident's program and home site; saving, sending or downloading alone does not do that. So the agreement being sought is not only "may I record this", it is also "may I send you the write-up afterwards, and may my program read it". Section 11 sets out who receives what, and the resident controls the email copies in Settings unless their program has set a policy.

A preceptor's optional response to a sent note applies only to the version that was sent. Not responding is not a response, and is never recorded as agreement.

If a preceptor withdraws their agreement, during the conversation or afterwards, the resident must stop recording, discard the recording if it has not yet been uploaded, and otherwise ask us to delete it under section 10.3. A preceptor can also contact us directly under section 6.3.

5.3 Patients

Patients are not asked for consent, because DebriefMD is not intended to capture information about them. The controls in sections 7 and 8 are how we try to keep patient information out of what we store. Those controls are imperfect. That is a reason to be careful about what is said out loud during a feedback conversation, not a reason to rely on the software.

6. Preceptors: information about people who are not our users

This section is deliberately prominent, because it describes a genuine gap.

6.1 What happens today

A resident types a preceptor's name, email, specialty, and site into DebriefMD. That preceptor:

• has not signed up for DebriefMD,
• has not been asked to consent to their information being stored,
• unless the resident turns it off, is sent the resident-reviewed finished coaching note, once the resident has reviewed and approved it — this is the only email DebriefMD sends a preceptor, and
• is told, in the footer of that email, why they are receiving it, given a link to this policy, and given four links that need no account and no sign-in: one that opens the note in a browser, one that lets them confirm the entrustment rating in it with a single tap, a short form to report a problem, and a one-click link that stops the emails outright. Section 6.3 describes each.

Until 2026-08-05 preceptors also received a content-free "an assessment is ready" notification the moment processing finished. That stream is retired: it duplicated the note that followed, and each notification was one more contact with a person who never opted in. The fact of any email still means a person who never opted in is contacted by us.

The note is a written record of what the preceptor themselves said, sent to the preceptor, at an address already on the roster, only after the resident has reviewed it, and the email's footer states that their verbal consent was confirmed by the resident before recording. It carries no transcript and no audio. Sending someone their own words is not the same act as disclosing them to a stranger. Even so, this is content about a person who has no account here, sent on a default they were never shown, so counsel should confirm that consent to being recorded fairly covers being sent the write-up. Section 11 sets out exactly what each recipient gets.

Two kinds of information about a preceptor are involved, and they are not the same. Their name, email, specialty and site are contact details. Their recorded voice and what they said in evaluating a resident are a different and more sensitive kind of information, collected when the resident records.

Under PIPEDA and provincial equivalents, collecting an individual's information from a third party generally still requires notice to that individual and a basis for the collection. DebriefMD now gives that notice, but it gives it in the first email, which is to say after the information has already been entered and stored. Notice at the point of contact is not the same as notice at the point of collection, and an email after collection does not by itself establish that the collection was authorized. We do not claim it does.

Legal counsel should determine whether an implied-consent or business-contact-information exemption applies, and whether after-the-fact notice of this kind is adequate or whether something earlier is required. What has changed is that the question is now about the sufficiency of a notice rather than the absence of one.

6.2 Visibility of preceptor records

A resident sees the preceptor records they created themselves, plus the shared roster for their own institution. Only the user who created a record can edit or delete it.

The shared roster is the seeded institutional list. It is readable, email address included, by signed-in users at the same institution, and by nobody else. A record that belongs to no institution is visible only to the resident who created it.

Until 2026-08 there was no scoping at all: every preceptor record, including ones a resident had typed in themselves, was readable by every signed-in user. That is fixed, in two steps. Resident-created records became private to their creator, and the shared tier is now matched against the viewer's own institution rather than being open to everyone with an account.

6.3 If you are a preceptor

You may contact hello@debriefmd.ca to ask what information DebriefMD holds about you, to correct it, to have it deleted, or to ask not to receive further email. We will action these requests regardless of whether the account holder who entered your information agrees.

Only one kind of email reaches you: the coaching note a resident sends you after reviewing it. It carries the note as a PDF and four links, and none of them needs an account or a sign-in. Each link is a single random reference that identifies only itself, is created when that email is sent, and is taken back if the send fails, so the page behind it is reachable only from mail that actually arrived.

• Read the note in your browser. Opens a copy of the coaching note exactly as it was sent to you, for 30 days. It is a copy taken at the moment of sending, not a live view: if the resident later edits the note, this link keeps showing what your email carried, and a re-sent note carries a link of its own. We count how many times the link is opened. That count is telemetry for us and is never treated as evidence that you read anything, not least because mail systems open links on their own. The copy is deleted after the link expires, on the retention routine section 9.1 describes, and at once if the resident's debrief or account is deleted.
• Confirm the entrustment rating. Where the note carries an entrustment rating, the email offers a one-tap question: does the rating match your judgement? The page shows the rating as it stood when the email was sent, from a copy kept with the link rather than read live, and nothing else — no resident name, no rotation, no narrative. "Agree" arrives pre-selected, so every place your answer appears words it as the preceptor did not object rather than as an independent re-rating, and says in as many words that the form arrived with "agree" pre-selected. The page tells you, above the button, where your answer goes: it is recorded beside the debrief as a separate record, shown to the resident, and included in the assessment document the resident exports — their review screen, the PDF and the spreadsheet export. It does not change the note itself, which the resident reviewed before sending. The link works once, for 30 days. There is no reminder, no follow-up and no free-text box, and closing the page is a complete answer. If the ratings are edited after you answer, the surfaces that show your answer say it was about the earlier values rather than dropping it.
• Report a problem. A short form, which a person reads, for "I did not work with this resident" or anything else about the email that concerns you. The page shows the date we wrote to you and nothing else.
• Stop these emails. Immediate, on its own, described below.

Two separate things can stop all of it, and either one alone is enough.

• You can stop it yourself, using the "stop sending DebriefMD email to this address" link in the footer. It takes effect at once: your address goes on a suppression list that every DebriefMD email is checked against before it is sent, whichever part of our system is doing the sending. The page tells you what will stop before you press anything, and it shows you nothing about the resident, the debrief, or even the address it is about to stop — so if the email was forwarded to you, the link discloses nothing.
• You can tell us, at hello@debriefmd.ca or through the report form, and we set a flag on your record. That flag is set on our side rather than yours, which matters because a resident cannot turn it back on — your decision does not depend on the goodwill of the person being assessed.

We keep both because they record different things: one is you acting, the other is us confirming what you told us. Because the note is the only email we send preceptors — the separate "an assessment is ready" notification stream was retired on 2026-08-05 — either one stops all DebriefMD email to you.

What we keep after you unsubscribe is the address itself, together with the fact that it asked not to be emailed and when. We have to: forgetting it is precisely what would make the emails start again. That record holds no clinical content and is not linked to any resident or debrief, and it is not deleted when the resident whose debrief prompted it deletes their account — your decision is not theirs to undo. You can still ask us at any time what we hold about you, or to correct or delete it.

7. Where your data is processed and stored

The hosting, database, storage, queues, transcription and language-model processing that DebriefMD controls are configured in Amazon Web Services' Canada (Central) region, ca-central-1, in Montréal. The table lists each service.

The list above is the same list as the sub-processor page's, which says what each service holds.

That configuration describes DebriefMD's own systems. It does not decide where every copy of your information ends up:

• Your browser and device. A recording waiting to be tagged or uploaded, and the cached lists described in section 9.1, are held on your phone or computer, wherever you are using it — including outside Canada.
• Email. Mail is sent through AWS SES in Montréal, but the recipient's mailbox is held wherever their email provider keeps it. Sending from Montréal does not determine where a delivered message is stored.
• Files you download or send. An exported file, or a copy delivered to a preceptor or program, is held on the device or in the systems of whoever has it.

A Canadian endpoint is not, on its own, proof of where a provider processes a request; what we can state is how our services are configured, and section 4 sets out what the providers say about their own handling.

Sign-in is by magic link, delivered through AWS SES in Montréal. Google sign-in is switched off. If we ever offer another sign-in provider, we will describe its data flow in this policy before it is enabled.

Analytics collection is paused (section 3.12). If it is ever turned back on, it could process technical usage information outside Canada, and this policy will say so first.

The typefaces the site uses are served from our own servers, so loading a page makes no request to a font provider.

Full details are in /sub-processors.

8. How recordings are processed

8.1 The path a recording takes

1. Your browser requests a short-lived, single-purpose upload URL from DebriefMD. The server confirms you own the session before issuing it.
2. Your browser uploads the audio directly to encrypted storage. The audio does not pass through the application server.
   • If you have no connection, step 1 cannot happen, so the recording is held in your browser's storage instead and this step is retried when you are back online. Until then the audio is on your device and nowhere else. See section 9.1.
3. The upload event places a message on a queue. The message contains only the storage location, never the audio.
4. A worker picks up the message and runs five steps in order: speech-to-text, a pattern-based identifier scrub, a contextual identifier scrub by the language model, a second pattern-based scrub, then assessment extraction. The speech-to-text service receives the source audio before any identifier has been removed, and returns the raw transcript, which is stored as it was returned.
5. Results are written to the database, the session is marked ready, and notification emails are sent. Those emails carry no assessment content (section 11).
6. You review, edit and approve the notes. Downloading them or sending email copies sends copies where you choose; "Share with program" is the separate step that lets your program's leadership read them in the app (section 11).

If a step fails, the queue retries up to three times, then parks the message in a dead-letter queue for investigation.

8.2 De-identification, honestly described

Identifier removal runs in three passes.

• Pass 1, patterns. A table of regular expressions covering all 18 HIPAA identifier categories plus Canadian identifiers: SIN, provincial health numbers (BC PHN, OHIP, Quebec RAMQ, Alberta PHN), postal codes, named Canadian hospitals, and room and bed numbers. The exact pattern table is in the code, and we do not quote a count here because the table grows as gaps are found. This runs first, so structured identifiers never reach the language model.
• Pass 2, contextual. The language model removes identifiers the patterns cannot catch: a first name used with no surrounding cue, an implicit reference, an unusual phrasing. The model receives the text as pass 1 left it, so it can receive any identifier pass 1 missed. If this pass does not complete, export and sending are held until it does.
• Pass 3, patterns again. The same pattern pass runs a second time, as a check on the model's output.

Pass 3 can only re-catch what pass 1 could have caught. For a structured identifier, such as a health number, a phone number, or a postal code, that means three independent chances, and a failure of the language model does not by itself result in a leak.

Names sit in between. A name with a title ("Dr. Okonkwo"), or one next to a word identifying it as the patient's ("the patient, Marguerite", "the patient's daughter Sarah"), is caught by the pattern passes like any other identifier. A name with neither cue, someone referred to by first name alone in a sentence that never says "patient", is recognised only by pass 2, and there is nothing behind it.

That asymmetry is the most important thing to understand about this design. It is why the review step below is not a formality.

It is also why the pattern passes do not simply redact every capitalised word. Your preceptor's name and your own are meant to survive, because they are who the assessment is about. So are drug names, conditions named after people, and hospitals. A rule that removed all of them would destroy the record it exists to protect.

Removed content is replaced with visible markers such as [REDACTED-NAME], so you can see what was taken out.

8.3 What this does not guarantee

Automated de-identification is best-effort. It is not a guarantee. We are stating this plainly because a privacy policy that implied otherwise would be misleading.

Known limits:

• Pattern matching only catches what matches a pattern. A name with neither a title nor a nearby word marking it as the patient's can pass through, as can an unusual identifier format or a misspelling introduced by speech-to-text.
• The language model is probabilistic. It can miss an identifier, and it can behave differently on different inputs.
• Indirect identification is largely untouched. "The gentleman from Tuesday's clinic with the unusual presentation" identifies no one by name, but it may identify someone to a reader who was there. No automated system reliably catches this.
• Speech-to-text errors can obscure an identifier from the scrubber while leaving it recognisable to a human.
• The de-identification quality has not been independently audited or formally validated, and we publish no accuracy figure. A completed check is not a certification that a transcript is anonymous.
• Removing patient identifiers does not make an assessment anonymous. The assessment is about you, by name, and stays personal information about you.

You are the final check. DebriefMD shows you the de-identified transcript and the generated assessment, and requires you to review them before export. If you see something that should not be there, edit it or delete it. That review is a real control, not a formality.

8.4 The raw transcript, and how long it lasts

DebriefMD stores both the raw transcript and the de-identified transcript. The raw transcript is the verbatim speech-to-text output and may contain identifiers.

It is never displayed in the application and never sent in email. It is protected by the same access controls and encryption as everything else. It is kept so that a de-identification failure can be investigated.

It is deleted 30 days after capture, on the same schedule as the audio. The two dates are deliberately the same. After 30 days, what remains of a recording is the de-identified transcript and the assessment generated from it. The audio and the unredacted transcript are both gone.

Reprocessing does not depend on this copy. It re-runs from the audio recording, so it is bounded by the audio's 30 days rather than by anything kept here.

9. How long we keep things

9.1 Stated retention

A note on the two device rows. Every other row in this table is a limit we enforce on our own systems. Those two describe data sitting in your browser's storage, on your phone or computer, and the 30-day audio clock in the first row does not start until a recording reaches our storage. /cookies §4 explains both rows in full: why there is no limit on how long a recording is kept on your device, when it is removed, and why the cached lists are cleared when you sign out.

A note on the support-request row. Because your message may quote an assessment, we classify it with the assessment content it may quote and give it that shorter clock rather than treating it as an ordinary operational record kept indefinitely. There is now a routine that carries this out: 30 days after a request is closed, its subject, its message and the reference details attached to it are deleted, leaving only the fact that a request was filed, in which category, and how it was handled.

Two limits on that, stated plainly rather than left for you to assume. First, the routine is meant to run automatically once a day, and we have not yet confirmed that daily schedule is registered on the live database; until we have, the deletion may be happening only when we run the routine ourselves. It is a scheduling gap, not a change to the rule, and the rule is what the row above commits us to. The same caveat applies to the two other rows that point here, the pipeline logs and the demo recordings: it is the one schedule, and it is unconfirmed for all three. Second, nothing yet deletes the assessment content this clock was borrowed from — for an account, the de-identified transcript and the generated assessment are still kept until you delete your account or ask us, as their own rows say. (A demo recording is the exception and is deleted outright, because there is no account it could wait on.) So for the moment the support-request rule is stricter than the rule it inherits, not looser.

Separately from any of that, a support request is deleted when you delete your account, which removes it outright rather than anonymising it, precisely because of what it may quote.

9.2 How the audio limit is enforced

The 30-day audio deletion is performed by a rule on the storage bucket itself, which also expires earlier versions of a file a day later; the database routine that clears the stored path afterwards is bookkeeping, not the deletion. The raw transcript expires on the same schedule, keyed off the same timestamp (section 8.4). Earlier drafts of this policy recorded where the deployed system once fell short of these rows and how that was closed; that history is kept in our working notes rather than here.

10. Your rights

Which rights apply, and on what terms, depends on the law that governs the particular information and your role (section 14). The rights below are the ones that law generally gives. To exercise any of them, contact hello@debriefmd.ca.

10.1 Access

You can ask for a copy of the personal information we hold about you, and an account of how it has been used and to whom it has been disclosed. Much of it is already visible to you in the app, but what the app shows you is not the limit of what you can ask for. For example, you are not shown the recording or transcript of a rotation report's closing conversation (section 3.14), and you can still make an access request for it; we will assess it under the applicable law and give you our reasons if we withhold anything. We will respond within 30 days, or the period the applicable law sets, unless an extension is permitted and we tell you why.

10.2 Correction

You can correct your profile directly in settings. For anything you cannot edit yourself, contact us. If we disagree that a correction is warranted, you may require that a note of your requested correction be attached to the record. A signed rotation report is corrected by voiding it rather than rewriting it, so its signed history stays attributable (section 11).

10.3 Deletion

You can ask us to delete a specific recording session, or your entire account and everything attached to it.

You can delete your account yourself, in the application, under Settings → Delete account. You will be asked to type a confirmation phrase, because it cannot be undone.

Deleting your account removes, immediately and in one step: your profile, every recording session, the audio recordings and both transcripts, every generated assessment, your self-ratings, your progress narratives and their releases, rotation reports about you (with any closing-conversation recording behind them), the preceptor records you created, and any support requests you filed. Program and home-site leadership lose access to your released notes at the same time, because the records they read are gone. The audio and transcript files are deleted from storage at the same time as the database rows, not left behind to expire later.

Your support requests are deleted outright rather than anonymised. Stripping your name off one and keeping it would be the wrong answer here: the message may quote the very assessment content the deletion exists to remove, so what has to go is the message, not the link to you.

You can still contact hello@debriefmd.ca instead, if you would rather someone did it for you, or if you want only part of your data removed, such as a single recording session rather than the whole account.

Four limits on deletion:

• Copies already delivered cannot be recalled. Deleting your account removes what DebriefMD holds. It cannot reach an email already delivered, a file you or anyone else downloaded, or a copy already entered into a program's own systems.

• Requests to stop receiving email survive (section 3.10), including one recording that your address should not be emailed. This is the standard carve-out every mailing system makes, and it exists for the person on the other side of it: a preceptor who asked us to stop must not start receiving email again because the resident whose debrief prompted it later deleted their account. Their decision is not yours to undo, and ours is not to forget it. What remains is an address, a reason, and a date — no clinical content, no link to any debrief, and no link to the account that has been deleted.

• The audit log is intentionally append-only and survives account deletion. It records that actions occurred and in what order, which is the point of having it, and retaining it is standard practice under health privacy regimes. It does not keep your name or your email. The link from an entry to your account is removed, and what remains is an internal reference code that keeps the log internally consistent, so a reviewer can still tell that a series of actions was one person acting in sequence. Once your account is deleted, nothing in DebriefMD maps that code back to you.

• Database backups roll off on a 7-day cycle. Deleted data can persist in backups until that window passes.

10.4 Withdrawal of consent

You may withdraw consent at any time. Withdrawing consent stops future processing and, on request, triggers deletion of what has already been collected, within the limits in section 10.3. It does not recall copies already delivered. It also means you can no longer use DebriefMD, because there is no version of the product that functions without it.

10.5 Complaints

If you are not satisfied with how we have handled your information or your request, you can complain to us first, and then to a regulator:

• Office of the Privacy Commissioner of Canada (federal, PIPEDA): priv.gc.ca
• Information and Privacy Commissioner of Ontario (PHIPA): ipc.on.ca
• Office of the Information and Privacy Commissioner for British Columbia (PIPA/FIPPA): oipc.bc.ca
• Or the equivalent commissioner in the province where you practise.

You do not need our permission to complain, and you do not need to come to us first. Nothing in our Terms or Acceptable Use Policy restricts a complaint to a regulator, a report the law protects, or a response to lawful process.

11. Who can see your data

This table is the complete list of who receives or can see assessment information, and what each gets. Our other documents point here rather than repeating it. No email DebriefMD sends attaches or links to a transcript or the audio, and no recipient in this table receives an audio recording. Your private self-rating reaches only you, unless the law compels us to disclose it (see "Law enforcement and courts" below).

Your program may lock your email-copy preferences with a send policy; the Settings toggles then show as locked. A notification address is not an access grant: being emailed a notification gives no in-app access.

What sharing with your program means in practice. Your program's leadership reads the copy taken at the moment you shared, not your live note: if you edit the note afterwards, they keep seeing the version you shared until you share again, which replaces their copy, and the review screen tells you when your program's copy is behind. Sharing again never withdraws an earlier release. The preview names the people who hold those roles when you share; someone appointed to one of the roles later can also read what you shared. There is no button to un-share a debrief: if something you shared needs correcting or withdrawing, contact your program, or us at hello@debriefmd.ca. A debrief that was released under the earlier rule, when saving or downloading also released it, stays released, and what leadership reads is a copy of its reviewed notes taken when the rule changed. Downloading a debrief does not revoke a release. Deleting your account removes what DebriefMD holds, including shared copies, released notes and reports, but cannot recall a message or file already delivered (section 10.3).

The rest of this section explains each row.

You can see your own sessions, recordings, de-identified transcripts, and assessments. You cannot see any other user's.

Other residents cannot see your sessions or assessments. Every user-scoped database query filters on the authenticated user's ID, and every API route verifies ownership before returning data or issuing a link to a stored file. The one exception is the shared institutional tier of the preceptor roster, described in section 6.2.

Your preceptor has no DebriefMD account, cannot sign in to view your session, and is not emailed when your assessment is ready (that notification stream was retired on 2026-08-05). The one email a preceptor receives is the finished note you send them, by default, under "Sending your finished note" below. It carries the PDF and the four account-free links section 6.3 describes: a 30-day view of the note as sent; the one-tap rating question, whose answer comes back to your review screen, your PDF and your spreadsheet export worded as "the preceptor did not object"; a report form; and a one-click stop link. If your preceptor uses either objection route, your next send will skip them and tell you it did.

Your program's office may be configured to receive its own copy of the assessment-ready notification, addressed to each program-level contact your program has configured — a director, an associate director or an administrator; the role makes no difference. It contains no transcript and no clinical content: the debrief's date, your name, the preceptor and the rotation. Each contact chooses how to receive it: at once, or rolled up into a daily, weekly, monthly or quarterly digest that lists the same four facts for every debrief that became ready in the period and nothing more. The addresses are set per residency program, so it is your program's office and not another's: a director of a different program at the same university does not receive your notifications, and an address your program configured for one hospital site receives none of them. If your program has configured no address, no copy is sent at all. Every copy, immediate or digest, carries the same one-click stop link, because a program address never opted in either; if it is used, sends to that address are skipped from then on.

Our support staff can read the support requests you file. They see the message you wrote, the reference details attached to it, and — so they can reply and know where to look — your name and email address, and your program and institution. This is the one role in DebriefMD that reads across programs and institutions. That breadth is the job: someone triaging a failed upload cannot be restricted to one program's failures.

It is deliberately a separate grant, made directly in the database, and it is not implied by any other role — a program director or site director has no access to support requests, and no administrative action inside the application can hand it out. The access is also limited to the requests themselves: it does not open your recordings, transcripts, assessments or self-ratings, which stay behind the same per-user checks that apply to everyone. Section 3.9 describes what a request contains.

Sending your finished note. When you have reviewed a debrief, the review screen's main action is "Save and send". It builds the assessment as a PDF and emails it to the people your send preferences in Settings name: you, at your verified profile address (on by default); your preceptor, at the address on their roster record (on by default); and your program's office (off by default), meaning every program-level contact your program has configured — director, associate directors and administrators alike, the same set that receives the "debrief ready" notification, and never an address configured for one hospital site. For a single send you may add one more of those program-level contacts, chosen from a picker rather than typed; they receive the PDF only, and the send refuses rather than silently dropping them if that contact has since been removed. What each recipient's email carries is in the table at the top of this section: the PDF for everyone, your self-rating in your own copy only, and no transcript or audio for anyone.

What a director sees in the app is set out under "Your program's director" below. No email copy reaches a director unless their address is one of the configured program-level contacts, and pressing "Save and send" gives them no access in the app, whatever copies it sends. Only "Share with program" does that.

Six things about this are deliberate:

• Nothing is sent until you send it. The button is the trigger. There is no schedule and no standing request.
• You must have reviewed every note in the debrief first. Until then DebriefMD refuses and tells you what to tick. This is the same gate that applies to downloading a PDF or sending a summary.
• The audio is never sent to anyone, on any of these paths. It stays in encrypted storage and is scheduled for deletion 30 days after upload (section 9.1).
• Your self-ratings never reach anyone but you. Your own copy may include them, because they are yours. No other recipient ever receives them, whatever your send preferences say: they are not in the PDF, not in the transcript, not in a summary, and not in any export that leaves for somebody else. Section 3.8 explains what the record is.
• You cannot type in a recipient. Every address is looked up on our side, from your verified profile, the preceptor's roster record, or your program's configured program-level contact addresses. An address in the request is ignored.
• Your program may decide this for you. A program can set a send policy, usually because a coaching note is part of its assessment record. When it does, that policy replaces your own preferences completely and the Settings toggles show as locked. If your program has not set one, the choice is yours.

A preceptor can stop these emails by either route section 6.3 describes. From then on sends skip that preceptor, you see them listed as skipped rather than sent, and neither route is yours to override.

Summaries you send yourself. You can also build a summary across your own debriefs, covering what keeps coming up, over a date range, within one program, and send it to that program's administrator address. Five things about it are deliberate:

• Only you can cause one to be sent. An administrator cannot ask DebriefMD for summaries about you, subscribe to them, or arrange to receive them regularly. A summary about you leaving the app is always an act you took — either you pressed send, or it was sent by a schedule you set up yourself. Scheduled sends exist as of 2026-08-15 and only you can create one: you pick the recipient from the same list, choose monthly or quarterly, and the schedule is listed in the app, revocable by you at any time, and expires after a year unless you renew it. Each scheduled send re-checks the same rules as a manual send on the day it fires — if any debrief is unreviewed, or you have left the program, nothing is sent and you are emailed the reason instead. The email a recipient receives says it came from a schedule you created, when you created it, and that you can revoke it.
• One program at a time. A summary covers a single program, and DebriefMD refuses to send one that spans more than one. If you have trained in two programs, each recipient only ever receives the debriefs recorded in their own program.
• You choose who receives it, from a list you can see. Your program can appoint several people to receive summaries: its program director, associate program directors, its administrator, and the site director or local administrator at any of its hospital sites. You pick one, and the screen shows you their exact address before you send. You cannot type an address of your own, and DebriefMD never picks one for you.
• You must have reviewed all of it first. If any debrief in the summary is unreviewed, or has no assessment at all, DebriefMD refuses to send it. This is the same rule that applies to exporting a single assessment, applied to the whole set.
• It carries assessment content, like a sent note does. It quotes your coaching notes as they were recorded, because a summary with them removed is a table of counts and no use to a committee. It carries no recording, no transcript, no link to either, and none of your self-ratings, and it says so in the email, so the recipient knows what they have not been given.

The rule underneath all of this: assessment content leaves DebriefMD by email only by your own act — a button you pressed, or a summary schedule you yourself created and can revoke. The notification emails, the ones that say a debrief is ready, go to you and, where configured, your program's contacts — never to your preceptor — and deliberately carry none of that content. Those notifications, the scheduled summary sends you have set up, and a status update when our team moves one of your support requests (section 3.9 — the status word and your chosen category, never your message), are the only mail we send without you pressing a button at that moment.

Sending to a site director shows them more than they can normally see. A site director's aggregate view is limited to their hospital site, and unless it is your home site they cannot open debriefs you recorded elsewhere. A summary is not limited that way. It covers your whole record for that program, because a review of your training is about all of it and not a third of it. So if you send a summary to a site director and some of it was recorded at other hospitals, the screen tells you how many debriefs that is before you send, and the email tells the recipient the same thing. You can narrow the summary to one site first if you would rather not include the rest. It is your record and the choice is yours. What DebriefMD will not do is let that choice be a silent one.

Before you send, the screen shows you the exact address the summary will go to. You cannot send a summary to a program you have left; those debriefs stay yours to read, but there is no longer anyone there to send them to. If your program has never set an administrator address, no summary can be sent to it at all. The summary itself is never stored. It is assembled at the moment you send it, and afterwards exists only as the email in the recipient's inbox, plus an entry in our audit log recording that you sent it, to which program, and when.

Your program's director, together with any associate director or administrator your program has appointed in DebriefMD, can see three things about you. The third is the one to read carefully.

First, aggregate counts and timings for their own program: how many debriefs were recorded and how long they took to process. Which program a debrief counts towards is fixed when you record it, so transferring between programs does not move your past debriefs into a new director's view.

Second, entrustment levels across a group, never per resident. Where your program has adopted EPA forms, the metrics screen shows how entrustment levels were distributed for each EPA, quarter by quarter. A distribution is printed only when it rests on at least five rated observations from more than one resident; below either floor the screen prints the count and says which floor stopped it. On the cohort screen, where residents are named beside the figures, the floor is three residents. No average, score or rank is ever computed from an entrustment scale.

Third, since 2026-08-12, the debriefs you have shared with your program, one resident at a time. The cohort list a director browses names residents but carries no assessment content, no entrustment level and no rating. Opening a named resident is a second, deliberate act, and the page it opens shows the coaching notes from debriefs you have shared with your program using "Share with program", or that were released under the earlier rule (above). What it shows is the copy of your reviewed notes taken when you shared, not your live note. Downloading a debrief, or sending email copies of it, does not put it on this page. Four things are never shown there, whatever the debrief's state: the transcript; your self-assessment; the model's explanation of why a form was not covered; and anything you have not marked reviewed. Beside the list the page states how many of your debriefs are withheld and why — for example awaiting your review, reviewed but not shared, produced no notes, still processing, or failed — so a director never reads three debriefs as your whole record.

A progress narrative, if you release one. On the summary screen you can ask for a paragraph reading your whole record in one program back to you, and you can choose to release it to your program. Nobody can ask you for one: there is no faculty path that requests, generates or prompts for it. What a director reads is the stored text you released, never a fresh generation, so you may edit the paragraph before releasing it and what they see is what you approved. Beside it they see whether the released text differs from the model's draft — a fact the database computes from the two texts, not a box you tick — together with the counts it was written from, the number of debriefs it covers, and your year of training. Your year is shown to the reader and is never given to the model: a paragraph judging your record against a year would be a competence judgement invented from a number. A release covers your whole record in one program and cannot be narrowed to a rotation or a period. You can withdraw it at any time. Nothing is emailed when you release or withdraw, so a withdrawal reaches everyone a release reached. It is deleted with your account.

A rotation report, once it is signed. Your program's faculty may prepare an In-Training Assessment Report for one of your rotations. Its rated items are drafted from the debriefs you have shared with your program — the same released record described above, and nothing you have not released — and an item no released debrief spoke to is drafted as not observed, never guessed. Its written comments may be drafted from a closing conversation the signing faculty member records with you (section 3.14); you will not hear that recording or read its transcript. The overall assessment of the rotation is never drafted by software: the person who signs enters it, at signature, and the report cannot be signed without it. You see the report at the moment it is signed and not before — there is no draft you are shown and no separate release step — and what you see is exactly what the program sees, with the signer's name and title as they stood when they signed. A report the program later decides was wrong is marked void and kept, so that a report you have already read is never made to disappear. It is deleted with your account.

A site director, where your program has appointed one, holds a grant that names both a program and a hospital site, and neither alone is enough. Their aggregate view covers their own program at their own site, for example Family Medicine at Vancouver General. Two limits are deliberate, and are enforced by the database rather than by convention:

• It is not everything recorded at that hospital. A site director appointed for Family Medicine sees nothing about Internal Medicine residents, even though both programs teach in the same building. Their authority names a program and a site, and both must match.
• It is never more than your own program's director already sees. A site director is shown a slice of that same picture, not a new one. No debrief becomes visible to anyone whose program could not already see it.

Since 2026-08-14 the director, or local administrator, of your home site — the site on your profile — can also open the debriefs you have shared with your program and read a narrative you released, exactly as your program director can, for the residents based at their site; that includes debriefs you recorded on rotation elsewhere. This grant is derived from your own profile at the moment they look, so moving to a different hospital changes who holds it, and a released narrative you would rather they did not read is yours to withdraw. What was captured at a site is a different question with a different answer: which site a debrief counts towards in the aggregate view is fixed when you record it, from the site on your profile at that moment, so moving does not move your past debriefs into a different site director's counts. If no site is set on your profile, your debriefs count towards no site, and no site director holds the home-site grant over you.

Because a site is a smaller group than a program, a site's counts can be based on very few debriefs, sometimes only one resident's. The figures still name nobody and contain no content, but a small count is inherently less anonymous than a large one, and you should read this section with that in mind.

The consent screen names this before you record. It tells you that you and, if your program has any configured, your program's contacts are emailed when the assessment is ready; that your preceptor is not emailed at that step, only when you send them the finished note; that transcripts and audio are not emailed; and that downloads and email copies do not give your program access, which reads your reviewed notes only if you choose "Share with program". The review screen repeats that last point beside the "Share with program" action. Confirm with your program whether administrator notification is enabled for you.

DebriefMD staff can access production systems for operations and support. Access is limited to those who need it. There is no formal, documented access-control policy or periodic access review; establishing one is an outstanding item.

Sub-processors process data only as needed to deliver their service. See /sub-processors.

Law enforcement and courts. We will disclose personal information where legally compelled. Where we are permitted to do so, we will tell you.

12. Security

Technical measures currently in place:

• Data is encrypted at rest with AES-256. The database, object storage, secrets, and the container registry use a customer-managed key with automatic annual rotation. The processing queue uses AWS-managed AES-256 encryption; its messages contain only file locations, not content.
• All data is encrypted in transit with TLS. The load balancer enforces a TLS 1.3 policy and redirects plain HTTP to HTTPS. Database connections are encrypted and verified against the Amazon RDS certificate authority for the Montréal region, so the application will not talk to anything else answering for the database.
• The database has no public address. It sits in a private network segment reachable only from the application and the processing workers.
• Object storage blocks all public access. Files are reachable only through short-lived signed links, issued after an authenticated ownership check.
• Access to stored secrets is scoped per role.
• Network rejection logs and an append-only application audit log are retained.

These are the measures as configured. Section 9.1 says where a scheduled clean-up has not yet been confirmed to run, and section 11 says where staff access is not yet governed by a documented policy.

What we do not claim. DebriefMD holds no third-party security or privacy certification and has had no completed independent third-party security audit. Internal reviews have been performed. No penetration test has been completed. Nothing in this policy should be read as a certification.

13. Breach notification

If personal information under our control is lost, accessed without authorisation, or disclosed without authorisation, and the breach creates a real risk of significant harm, we will:

1. Notify affected individuals as soon as feasible, describing what happened, what information was involved, what we are doing, and what you can do.
2. Report to the Office of the Privacy Commissioner of Canada as required by PIPEDA, and to the relevant provincial commissioner where a provincial health privacy statute applies.
3. Notify the applicable health information custodian, typically the hospital, health authority, or university program, where the breach involves personal health information and we are acting on their behalf.
4. Where PIPEDA applies, keep a record of every breach of security safeguards for at least 24 months, as it requires, including breaches we assess as not meeting the notification threshold.

Where an institution has an agreement with us covering its program, we notify it promptly under that agreement, whether or not a breach reaches the threshold for notifying a regulator or individuals.

To report a suspected breach or a security vulnerability, contact hello@debriefmd.ca.

14. Which law applies

This is genuinely unsettled and depends on facts a lawyer needs to determine.

• PIPEDA (federal) applies to personal information handled in the course of commercial activity across Canada.
• PHIPA (Ontario) governs personal health information in Ontario. Whether it applies to DebriefMD depends on whether DebriefMD is an agent of a health information custodian, or an electronic service provider under s.10(4), or neither. That determination is (health information custodian relationship, to be confirmed).
• Provincial health privacy statutes differ meaningfully. Which one applies to you depends on where you practise, not where we are. DebriefMD's initial deployment is with a British Columbia program (UBC Family Medicine), which means BC's PIPA and, if a public body such as a health authority or university is involved, BC's FIPPA may apply, including FIPPA's specific rules on disclosure and storage. Alberta's HIA, Quebec's Law 25, and other provincial regimes impose their own requirements.
• Your residency program and hospital almost certainly have their own policies on recording clinical encounters and handling patient information. Those apply to you independently of anything in this policy, and they may be stricter.

Which law applies is decided per kind of information and per role — a resident's own account, a preceptor's contact details, a program's assessment records and incidental patient information can each fall under a different statute — rather than by one law for everything. We commit to complying with the law that applies to each. We do not claim to have completed a jurisdiction-by-jurisdiction compliance assessment, and a Privacy Impact Assessment has not been performed.

15. Children and minors

DebriefMD is for medical residents, fellows, and comparable trainees, all of whom are adults. It is not directed at children, we do not knowingly collect information from anyone under the age of majority, and there is no feature that would sensibly be used by a minor. If we learn that we have collected information from a minor who used the service, we will delete it.

That is about who may use the service. It is separate from information about patients who are children, which can be mentioned in a clinical feedback conversation like any other patient information; sections 5.3, 7 and 8 apply to it, and the instruction to avoid patient identifiers applies with the same force.

16. Automated processing

DebriefMD uses a language model to draft assessment content from a transcript. This is automated processing of information about you, and you should understand what it does and does not do:

• The model drafts. It does not decide. It makes no decision about your competence, progression, or whether you pass, and nothing is filed automatically in any other system.
• Each kind of output has its own human approver. A coaching note reaches your program, your preceptor or anyone else only after you review and approve it and then send it, download it or share it with your program. A preceptor's optional response applies only to the version sent to them, and no response is not a response. A rotation report reaches you and your program only when a faculty member signs it after reviewing it, and the overall assessment in it is entered by that person, never drafted.
• Model output can be wrong. It can misattribute, overstate, understate, or invent. You are expected to check it.
• You can edit any field before export, and the system records whether you reviewed and whether you edited.

The same model is used for six things, and it is worth being exact about what it receives for each:

• De-identification: the raw transcript, before identifiers are removed. This is the one pass in which unredacted text reaches the model, and it runs after the first pattern pass has already taken out structured identifiers (section 8.2).
• Extraction: the de-identified transcript together with the form template, once per form you chose.
• EPA suggestions: the de-identified transcript together with the list of EPA forms you are entitled to use, only when you ask which further forms the conversation supports. Nothing about the answer is stored.
• Progress narratives: the counts and recurring themes computed from your coaching notes — never the transcripts, and never your year of training — only when you ask for one on the summary screen.
• Support-reply drafts: the subject, message and attached technical details of a support request, only when our support staff ask for a draft (section 3.9).
• Rotation-report comments: the de-identified transcript of a closing conversation, together with the report's draft as labels, levels and counts with no names, to draft the report's written comments for the signing faculty member to review (section 3.14). It cannot set a rating, level or overall assessment.

Whether this processing happens at all is not a setting, and there is no plan to make it one. Transcribing the conversation and drafting the form from it is what DebriefMD is. A version with the model switched off would not be a more private DebriefMD; it would be a voice recorder. So the processing is agreed to by using the service: as the Terms put it in section 1, creating an account or using DebriefMD is your agreement to them and to this policy, and where we hold a record of the dated version you accepted you can read it in your settings (see section 3.11).

The control you have is the one section 5.1 already describes, and it is a real one: you may withhold consent by simply not recording. Nothing here processes a debrief until you start a recording and tick both confirmations on that recording's own consent screen. There is no background processing of anything else you do.

What we do instead of offering a switch is bind where the processing can happen. Every model call in the list above is configured to run in Montréal, on a model invoked directly in that region (section 7), and section 4 sets out what the provider says it does and does not do with what we send. That is the safeguard: not an option to decline the processing while continuing to use the product, but a limit on where the processing can go and what may be done with it.

If you believe a DebriefMD-generated assessment has been used to your detriment, contact hello@debriefmd.ca.

17. Changes to this policy

If we make a material change, meaning anything that changes what we collect, why, who we share it with, or how long we keep it, we will notify account holders by email at or before the time the change takes effect, and never later than the day it is published, and update the date at the top of this document. The notice says what changed, in a sentence, and which version of the document it applies to. Non-material changes, such as clarifications and typo fixes, will be made with the date updated but without individual notice.

A change that uses information for a new purpose, discloses it to a new kind of recipient, or uses recordings in a new way needs whatever fresh consent or institutional authorization the law requires for it. Continuing to use DebriefMD is not a substitute for that, and we will ask for it where it is needed.

After we have notified you of a material change, continuing to use DebriefMD once it takes effect indicates your acceptance of it. If you do not accept it, you may withdraw consent and request deletion under section 10. Where we hold a record of the version you accepted, you can see it in your settings.

18. Contact

For any privacy question, access request, correction, deletion, or complaint:

Privacy Officer The Privacy Officer is the role accountable for how DebriefMD handles personal information. Requests to this role go to a monitored inbox: hello@debriefmd.ca

1581455 B.C. Ltd. dba WhiteCoat Prep 1130 East Broadway, Vancouver, British Columbia

For security vulnerability reports: hello@debriefmd.ca

---

Related documents

• /sub-processors: every third party that processes data on our behalf
• /cookies: cookies and browser storage