How We Protect Patient Data

Patient data doesn't belong to us. It belongs to your patients, and they trust your practice with it. When you submit a case to CadCan, that trust extends to us - so we want to be specific about what happens to that data, where it goes, and what protects it.

This is a plain-language account of the technical controls we run, written for dental offices and anyone reviewing our practices for compliance purposes. It describes how the system is designed and what we've verified. It isn't a legal guarantee, and no technology eliminates risk entirely - but we think you deserve to know the specifics.

Three Independent Layers

We apply three separate encryption layers to every case that moves through the platform. They work independently, which matters: each layer addresses a different threat, and they don't depend on each other to function.

The first layer is the channel. Every connection between your browser and our servers uses TLS 1.3 - the same protocol that protects online banking. Nothing moves between your practice and CadCan without being encrypted in transit.

The second layer is file storage. Every file uploaded to CadCan - 3D scans, X-rays, DICOM files, photographs, prescription PDFs - is encrypted before it reaches long-term storage. We use AES-256-GCM, a symmetric cipher used by government and financial institutions. Each file gets its own randomly generated encryption key. That key is itself encrypted with a separate master key before being written to the database. The result is what's called envelope encryption: the stored file and its key are both ciphertext, stored separately. Someone who obtained the raw file storage would have unreadable data. Someone who obtained the database would have encrypted key material they couldn't use without our server's master key.

The third layer is the database itself. Patient names, dates of birth, clinical notes, tooth numbers, material preferences, and prescription details are individually encrypted at the column level. The encrypted columns store ciphertext tokens, not readable names or dates.

What Happens When You Access a File

When you download a file from your portal, the decryption happens inside our server - not in your browser. We retrieve the encrypted file from storage, look up the encrypted key from the database, decrypt the key using our master key, use that key to decrypt the file, and stream the result to your browser over TLS. The decrypted bytes exist in server memory for the duration of that request and are not written to disk. Your browser receives the file in its original format.

Download links sent by email use a long random capability URL that expires after 72 hours. These links do not require the recipient to log in, which means they function as bearer tokens - anyone who receives the link can use it during that window. Every access is logged with the timestamp, IP address, and file identifier, and the rate is capped at 30 accesses per hour per IP address. For workflows where you want stronger access control on delivery, your portal account provides fully authenticated download with no expiring links.

Who Can See What

Your office can only access its own patients. All case and file queries are filtered by your office's identifier, which comes from your authenticated session token - not from any parameter you supply in the request. The system is designed so that one practice's session cannot retrieve another practice's records.

Lab designers who work on cases see case reference numbers, file counts, and appliance types. Patient names are not included in any designer-facing case view - they are replaced server-side before the response is built. Source files submitted by your practice or scanner may contain patient identifiers depending on how they were exported; we recommend using de-identified file names where your workflow allows. A designer's account cannot access billing, office details, or patient records.

Lab administrators require two-factor authentication to log in. All admin actions are written to an audit log with the actor's identity, IP address, and timestamp. The log covers logins, file uploads, downloads, case updates, and status changes.

Scanner Integrations

When a case arrives through a direct scanner integration like DS Core or iTero, the import connector downloads the scan files to a temporary location on our server, encrypts each file immediately via the same AES-256-GCM path as a manual upload, writes the encrypted copy to storage, creates the database record, and then deletes the temporary file. The deletion step is structured to run even if the encryption or upload step encounters an error, so plaintext scan data is not left on disk after ingestion completes.

We've Reviewed Our Own Work

We conducted a code-level audit of the encryption implementation in March 2026, prior to opening the platform to offices. The audit covered every major path: the cryptographic primitives, the key hierarchy, all four download endpoints, the connector ingestion flow, and the database field encryption layer. It was conducted using synthetic test data only - no real patient information was in the system at the time.

One finding came out of that review. A single audit log endpoint was writing a test case name into its stored event details alongside the case identifier. Because the audit happened before launch, the only data involved was test records we had created ourselves. The issue was corrected before any office submitted a real case, and no patient information was ever affected.

We're sharing this because transparency is part of how trust works. Claiming "we take security seriously" costs nothing. Showing the actual controls, where we found a gap in our own pre-launch testing, and what we did about it is more useful to the practices that rely on us.

Documentation

We've published two reference documents alongside this post. The Patient Data Protection overview covers the full pipeline in plain language - who can access what, how each category of data is protected, and what the controls look like in practice. The Encryption Architecture diagram is a visual flow of the same system - how a file travels from your practice through encryption and into storage, and what happens when you retrieve it.

If you have questions about our data handling practices or need documentation for your own compliance obligations, reach out at work@cadcan.ca.