Skip to content

Security

Canadian hosting.
Clear data boundaries.

Where the service DebriefMD runs is hosted, what that covers and what it does not, how it is protected, what is removed from a transcript, and who can see what. Written for procurement, IT, and privacy officers.

Last updated: November 15, 2026.

Where data is hosted

DebriefMD-controlled hosting is configured in one AWS region, ca-central-1 in Montréal. That covers the application, database, object storage, queues, pipeline compute, transcription, language-model processing and outgoing email.

What the hosting statement covers.

Audio, raw and redacted transcripts, and assessments are stored and processed by services configured in ca-central-1. Transcription and the language model are called in that region, and the model is invoked directly rather than through a cross-region route.

It does not cover copies outside the service. A browser keeps its own copies on the device, wherever that device is used. A downloaded file is wherever it was saved. An email is sent from Montréal, but the recipient’s mail provider decides where the message is stored. Optional analytics is paused, including for anyone who opted in before, and Google sign-in is switched off. The sub-processors page lists every service and what each one handles.

Encryption

At rest

AES-256

Data at rest is encrypted. The database, object storage, and secret store use customer-managed KMS keys with annual rotation; the message queue uses encryption managed by AWS.

In transit

TLS 1.3

Browser connections to the load balancer use a TLS 1.3-only policy, and plain HTTP is redirected to HTTPS. Database connections require TLS and are verified against the Amazon RDS certificate authority. Object storage refuses requests without TLS.

Network isolation

The database sits in a private subnet with no public IP, reachable only from the application and the pipeline worker. Object storage blocks all public access. It is readable only through short-lived presigned URLs, which the application issues after an authenticated, ownership-scoped check.

Source material and redaction

Audio recordings sometimes contain patient-identifying information, even when the intent is to capture feedback about clinical skills. We treat that as expected. Amazon Transcribe receives the source audio before anything is removed, and the audio and the raw transcript are stored as identifiable records until they expire. Identifiers are then removed from the transcript in three stages: a deterministic pattern pass, a contextual pass on a language model in the same region, then the pattern pass again. The contextual pass therefore sees whatever the first pass missed. The raw and redacted transcripts are separate records, and drafting works from the redacted one.

The passes cover all 18 HIPAA identifier categories plus Canadian-specific identifiers (SIN, provincial health card numbers, postal codes). Redactions are inline markers (for example, [REDACTED-NAME]) so reviewers can see what was detected. If the contextual pass did not complete, the debrief cannot be exported or shared until it does.

Automated identifier removal is not perfect and we do not claim it is. The structured identifiers above are caught by pattern matching and by the model; an unusual patient name with no title or context word in front of it rests on the model alone and can survive. Nobody should treat a redacted transcript as certified de-identified, and redaction does not make an assessment about a named trainee anonymous.

A person approves what the software drafts. The resident reviews a coaching note before it can be exported, shared or sent, and faculty sign rotation reports after reviewing them. The software makes no competence, progression or pass/fail decision.

Access control

Residents see only their own sessions, recordings, and assessments. This is enforced at the application layer. Every database query filters by the authenticated user, and API routes verify ownership before returning data or issuing presigned URLs.

A program does not see one thing, it sees two, and the difference matters. A program director, and a site director for the residents based at their site, browse counts and timings with no resident content on them at all, and can open one named resident to read the debriefs that resident reviewed and chose to share with their program. Never a draft, never the audio or a transcript, and never a resident’s own self-ratings.

Personal download does not newly grant faculty access; explicit release does. Saving a reviewed note to your device in any format, exporting it to a portfolio, or using Save and send gives program and home-site leadership no access in DebriefMD. Share with program is a separate action: it names the people who will gain access, asks you to confirm, and shares a copy of the reviewed notes as they stood at that moment. It sends no email. Notes released before this change, when a download also counted as a release, stay released.

A program administrator address, where the program has configured one, is a recipient rather than a viewer. It is emailed a content-free notice that an assessment is ready, and it can be sent the assessment PDF itself, which is identified content. That send is off unless the resident turns it on or the program sets a send policy, it happens only after the resident has reviewed every note and pressed the button, and it never carries the audio, a transcript, or the resident’s own self-ratings. Section 11 of the Privacy Policy lists every recipient and exactly what each one gets.

What happens to the audio

The recording is deleted 30 days after capture. That is a storage lifecycle rule on the bucket rather than a scheduled job we have to remember to run, and it removes prior versions of the object as well as the current one. The transcription service’s output files expire under the same kind of rule. The raw transcript held in the database is cleared on the same 30-day clock by a database routine; we have not yet confirmed that its daily schedule is registered on the live database.

What persists is the redacted transcript and the assessment itself. Nothing expires those. They are the resident’s record, and they stay until the resident deletes the account or asks us to delete them. Deleting the whole account removes every recording, transcript and assessment it holds, including prior object versions in storage. It cannot recall copies already delivered: emails, downloaded files, or anything a program has saved in its own systems.

A recording captured with no signal is on the resident’s own device rather than ours. It stays in the browser’s storage until processing succeeds, the resident discards it, or the browser’s site data is cleared. There is no maximum age. The 30-day clock starts when it reaches us.

Which law applies

Canadian health-privacy law is provincial and it varies materially, so the answer depends on where your program sits. The Privacy Policy names the applicable statutes and sets out what each entitles you to, and the Terms of Service set out how responsibility is divided between DebriefMD and your institution.

DebriefMD holds no security certification, and no independent audit or penetration test has been completed. This page describes the controls we have configured; it is not an attestation.

Vulnerability disclosure

If you discover a security issue, please report it responsibly.

hello@debriefmd.ca

Privacy, data handling, sub-processor and Data Processing Agreement questions go to hello@debriefmd.ca.