Skip to main content
For:Security and compliance reviewers · Site IT (firewall allowlist)
All communication between AitriumOS and Aitrium/Google cloud services is HTTPS/TLS over port 443, always initiated outbound by the application. The only non-443 traffic is the transfer of the prepared dataset to the investigator’s endpoint (typically SFTP over TCP 22), whose destination is defined by the investigator — not by your Site.

​
Submission sequence

Interactive version

Open the full, interactive submission data-flow diagram.

​
Firewall allowlist

Permit outbound HTTPS (TCP 443) to the following destinations:
The most important address to allow is api.aitriumos.com: if it is blocked, users can sign in but trials and patient data will not load, and no data can be submitted. AitriumOS shows an in-app “Can’t reach Aitrium” message in this state pointing the user to this guide. storage.googleapis.com only affects automatic app updates and never blocks a submission.
Testing these addresses in a browser does not validate the application. A browser (and AitriumOS’s own sign-in window) follows the machine’s proxy configuration, while AitriumOS’s background connections use their own route — so a destination can open fine in a browser and still be blocked for the application, or the reverse. Validate from inside the application: Settings → Network lists each Aitrium service with its status and names the route AitriumOS used.
The structure-standardization and audit-logging destinations are Aitrium-operated services on Google Cloud Run (HTTPS/443). If your release uses different endpoints, your IT team is told which ones: [email protected]. Settings → Network in AitriumOS also lists each service with its status.
Prefer to route this traffic through a corporate HTTP proxy instead of allowing direct egress? See Corporate HTTP proxy.

​
Transfer to the investigator

Allowing this connection differs from the HTTPS destinations above:
  • No proxy. The SFTP transfer always connects directly from the workstation. It cannot be routed through a web (HTTP) proxy, so the workstation’s firewall must permit outbound TCP to the investigator’s host and port.
  • Allow the program, not just the port. Endpoint-security and per-application firewall rules can block AitriumOS while allowing other programs on the same port. Allow the executable NewLeaf.exe: C:\Program Files\AitriumOS\NewLeaf.exe for the per-machine (MSI) installer, or %LOCALAPPDATA%\AitriumOS\NewLeaf.exe for the per-user installer.
  • Validate from AitriumOS. A successful ssh, sftp or Test-NetConnection from the same workstation only shows that the port is open for that program. Use Settings → Network → Upload destinations → Check now, which tests the connection AitriumOS itself uses without signing in or transferring data.
The transfer originates from the site’s public egress IP address. If the investigator’s SFTP server restricts sources by IP, give the investigator’s organization that address — there is no fixed Aitrium relay address.
See Upload connection troubleshooting for what each connection message means, and SFTP server compatibility for the SSH algorithms and authentication methods AitriumOS supports.

​
Data residency — where patient data lives

  • Raw patient DICOM (pixel data) is processed entirely on the local workstation and is never uploaded to Aitrium’s cloud.
  • Patient files leave the workstation only via the transfer to the investigator’s destination, connecting directly from the workstation. No patient imaging is routed through Aitrium-controlled infrastructure.
  • Aitrium’s cloud stores only non-sensitive metadata and metrics that AitriumOS extracts or computes from the local dataset — never the original images:
    • Dataset structure / metadata — the DICOM hierarchy (studies, series, modalities, instance counts) and references to supplementary files, used to confirm a submission is complete against the protocol.
    • Derived quality metrics — for radiotherapy, dose-volume-histogram curves (computed summaries, not original images).
    • Platform configuration — trial definitions, policies, automations, and integration settings.
In short: structure and derived metrics go to Aitrium; the imaging itself goes only to the investigator’s destination.

​
Transfer credentials

Your Site does not enter, hold, or manage the credentials used to transfer data to the investigator. The recipient (investigator/sponsor) organization configures and permits the transfer integration at the user level. Credentials are stored encrypted at rest using Google Cloud KMS keys — scoped to the owning recipient organization and to each participating site — and those keys never leave Aitrium’s servers. When an authorized Site user performs a transfer, Aitrium decrypts the credentials server-side and re-encrypts them for delivery using a short-lived session key tied to that user’s authenticated session, transmitted over TLS. AitriumOS then decrypts them in memory, uses them only for that transfer, and discards them — they are never written to the workstation’s local storage. Which users may transfer data for a given trial is controlled by a per-user permission (see Access management).