File handling
How MedImages handles DICOM files
MedImages is not a local-only viewer. Files selected in the browser are uploaded to the application server and stored for the signed-in account. This page separates browser processing, server processing, storage, access, and export behavior.
What happens in the browser
When you select a file, browser code checks whether it appears to be DICOM and enforces the 4 MB client-side size limit. After a successful upload, the browser reads selected metadata fields and passes the file to the Cornerstone3D renderer. Windowing, zoom, pan, rotation, flipping, and inversion happen in the viewer.
Selecting a file is therefore not entirely local processing: the normal workflow continues by sending that file to the MedImages upload API.
What is sent to the server
Uploading requires an authenticated account. The complete file is submitted to the server, which checks the 4 MB limit, verifies the DICOM Part 10 signature, computes a content hash for duplicate detection, and saves the upload when the account is within its image limit.
Where uploads are stored
In the deployed Cloudflare configuration, file bytes are stored in a Cloudflare R2 bucket. A Cloudflare D1 database stores an upload record containing the account ID, original filename, object key, content type, file size, content hash, and creation time. In local development, the equivalent data is stored on the local filesystem and in SQLite.
The repository does not define automatic expiration or a fixed retention period for uploads. Files remain available in the account's image list until a deletion is requested or storage is managed outside the behavior visible in this codebase.
Who can retrieve an upload
The file download endpoint requires a valid session and checks that the upload belongs to the current user. Requests for another user's upload return a not-found response. The current repository contains no public link or authenticated file-sharing feature.
These application checks describe the code path; they are not a certification or a claim that the service meets a particular healthcare privacy or security standard.
Deletion and export
The workspace includes a delete action. The server requests deletion of the stored object and then removes its upload metadata. Object deletion is implemented as a best-effort operation, so this page does not promise immediate or guaranteed erasure from every storage layer, backup, or provider system.
PNG export is different: the browser converts the currently displayed canvas into a PNG and downloads it locally. The export code does not send that generated PNG to a MedImages API. Exporting does not remove or replace the original stored DICOM upload.
Before uploading sensitive information
DICOM files can contain names, identifiers, dates, and other protected health information in metadata or burned into image pixels. Avoid uploading or sharing protected health information unless you understand and accept the relevant privacy implications and are authorized to use the service for that data.
If you only need to understand the product first, review the viewer features and limitations. When you are ready and authorized to proceed, open the viewer.