Security overview

OrcaDose hosts de-identified radiotherapy planning data for an open educational challenge. This page answers the questions that come up in vendor and institutional security reviews. Anything not yet in place is marked as such.

Who operates the service

OrcaDose is operated by Kanghoun Lee, who is the sole administrator with production access. There are no third-party subprocessors with access to user data beyond the hosting provider and the identity provider named below.

Where data is stored

• Hosting: AWS Lightsail, ap-northeast-2 (Seoul), Zone A. Data does not leave this region. Single instance, 2 vCPU / 8 GB / 160 GB SSD.
• Database: PostgreSQL 16, in a container on the instance — accounts, cases, submissions, scores.
• Object storage: MinIO (S3-compatible), in a container on the instance — DICOM archives and submitted dose files.

Encryption

• In transit: TLS 1.2 or higher for all traffic, including uploads and downloads, which go directly to object storage over pre-signed HTTPS URLs.
• At rest: AWS platform disk encryption; no application-level encryption on top. The control that matters here is not the cipher — it is that no protected health information is stored at all, which is enforced by a gate no administrator can override.
• Pre-signed URLs are scoped to a single object and expire — 1 hour for uploads, 15 minutes for downloads.

Authentication and password policy

The platform stores no passwords. Sign-in is delegated to Google OAuth 2.0, so there is no credential database to breach and no password policy to enforce on our side. A development-only email sign-in exists for local testing and is disabled in production.

Multi-factor authentication

MFA is enforced by the identity provider. A user whose Google account requires a second factor cannot sign in here without it. Because we never see credentials, we cannot weaken that.

Gap:the service does not currently offer its own second factor for the single administrator account beyond Google’s. Administrative access is limited to one account.

What personal information is collected

The complete list is on the privacy page. In short: an email address, a display name, and three optional profile fields. No date of birth, no phone number, no address, no payment details.

Uploaded clinical data is required to be de-identified before upload, and every upload is scanned automatically — see below.

How patient data is handled

The platform is for de-identified, shareable data only. Every contributed case passes through an automated gate before anyone can see it:

• Every DICOM file is scanned for direct identifiers — patient birth date and address, institution name, referring and performing physician, operator name, station name, accession number and others. Any value in these fields fails the case, and it cannot be published.
• Fields that may legitimately carry a study pseudonym (patient name and ID) are checked against a name heuristic; anything that reads as a real person’s name fails.
• Burned-in annotation flags and private tags are reported.
• A case that clears the automated gate still requires explicit administrator approval before publication.

The contributor sees exactly which tags failed and in which files, and can have the server strip them and re-run the same check.

Data retention and deletion

• Accounts: Retained until the account is deleted by the user or on request.
• Submissions: Dose files are retained while the case is published, so score cards stay reproducible. Deleted with the account.
• Cases: Published cases are retained indefinitely as a community resource; the contributor's name can be anonymised on request.
• Logs: Application and job logs are retained for 30 days.

Users can delete their own account from their profile page, which removes the account, their submissions and the associated dose files. Deletion is immediate and irreversible.

Cookies and tracking

One cookie: the session cookie set at sign-in. It is HttpOnly, SameSite=Lax and Secure in production. There is no analytics, advertising or third-party tracking of any kind, which is why you will not see a consent banner — a strictly necessary session cookie does not require one.

Access control

• Unpublished cases are visible only to their contributor and to administrators.
• DICOM downloads require sign-in and are refused for unpublished cases.
• Score cards for published cases are public by design — the value of the platform depends on anyone being able to check why a plan scored what it scored.
• Administrator actions on cases are recorded with the reviewer and a timestamp.

What we do not claim

OrcaDose holds no SOC 2, ISO 27001 or HIPAA attestation, and is not a medical device. It is an educational platform for de-identified data and must not be used for clinical decision-making or with identifiable patient information.