본문으로 건너뛰기

Security overview

Orcaton hosts de-identified medical-imaging, pathology and radiotherapy challenge data. 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

Orcaton 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 — challenge datasets, prediction archives, model-run outputs and radiotherapy DICOM 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 — only source-side de-identified data is permitted, followed by automated metadata checks and explicit human review before publication.
  • Browser pre-signed URLs are scoped to a single object and expire after 15 minutes for both uploads and participant downloads. Accepted bytes are promoted to a content-addressed key before publication or scoring.

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. Automated checks cover supported metadata; their stated gaps require human review.

How patient data is handled

The platform is for de-identified, shareable data only. Every contributed case passes through format-specific automated checks and administrator review before publication:

  • 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.
  • Known coverage gap: CSV row values, arbitrary JSON values and image pixels are not automatically scanned. Burned-in text and non-DICOM contents require source-side de-identification and human review.
  • 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: Scored dose, plan and imaging prediction artifacts are retained while the task 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, job and access 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 stored artifacts. 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 submission received its score.
  • Administrator actions on cases are recorded with the reviewer and a timestamp.

What we do not claim

Orcaton 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.

Last reviewed 2026-10-23. Questions about any of this go to dlrkdgns1324@gmail.com.