Testing your upload connection
If an upload keeps failing, especially at the same point or right near the end, the problem may be your network rather than your files. Many hospital networks inspect uploads and stop some kinds of file, most often ZIP files being sent to cloud storage. The upload connection check shows exactly what your network lets through, in a few minutes, and gives you a report to hand to your IT team.
Open the upload connection check (you will be asked to sign in). Any account that can upload imaging can run it.
When to use it
- The same upload fails every time you try it.
- An upload fails at the same percentage each time, or very close to the end (for example 97%).
- The error mentions Failed to fetch, missing ETag, CORS, or a network problem.
- Your IT team has made a change and you want to confirm uploads now work.
How to run it
- Open the check in one of three ways:
- On the Upload screen, click Test my connection in the top right corner.
- When an upload fails, click Keeps failing? Test your connection under the error.
- Use the link at the top of this page.
- Click Start the check. It takes a few minutes and sends about 100 MB in total. Keep the window open until it finishes.
- Read the results. If anything was blocked, click Print or save report and send the PDF to your IT team.
You can run the check as often as you like. Each run is independent and has its own reference.
What it sends
Every test file is made of random data generated in your browser. No patient information and none of your own files are sent, nothing is added to any study, and the test files are deleted as soon as the check finishes.
The tests are grouped by what they reveal:
| Group | What it tells you |
|---|---|
| Controls (random data, plain text) | Whether anything gets through at all |
| ZIP files (complete, incomplete, compressed, password-protected, nested, Word documents) | Whether ZIP files are blocked, and which kinds |
| Other archive formats (gzip, 7-Zip, RAR, tar) | Whether the block covers all archives or only ZIP files |
| Common file types (JPEG, PNG, PDF, programs, DICOM) | Whether other file types are filtered too |
| Content scanning (text with made-up patient identifiers) | Whether your network scans file contents for patient information |
| Where and how it is sent (a replay of a real upload, a ZIP sent as the second part, a different address) | Exactly which part of an upload is stopped, and whether the address matters |
Whether each test "went through" is decided by what Brainstorme actually received, not by what your browser was told, so a filter that quietly drops uploads is still caught.
Reading your results
The results page explains the pattern in plain English. The common outcomes:
| Result | What it means | What to do |
|---|---|---|
| All tests went through | Your network is not the problem. | Check the file itself: see Fixing a corrupt or unreadable zip, then try again. |
| ZIP files were blocked; other archives went through | A security filter is stopping ZIP uploads. | Send the report to your IT team. |
| Only the incomplete ZIP was blocked | A scanner is stopping archives it cannot fully open, which is what the first part of every large upload looks like. | Send the report to your IT team. |
| The replay shows only part 1 blocked | The first part of each upload (the part that starts with the ZIP header) is stopped while the rest gets through. Uploads fail near the end, at the same point every time. | Send the report to your IT team. |
| Everything was blocked, including random data | Uploads to Brainstorme are being stopped entirely. | Send the report to your IT team. |
| Text with made-up identifiers was blocked | Your network scans uploads for patient information. | Mention this to your IT team alongside the report. |
For your IT team
Brainstorme uploads clinical imaging over HTTPS to Amazon S3, in parts of about 8 MB. To allow uploads, exempt these addresses from upload, file-type and archive-inspection policies (and from SSL inspection, if that is how your gateway applies such exceptions):
brainstorme-v2-upload.s3-accelerate.amazonaws.combrainstorme-v2-upload.s3.us-west-1.amazonaws.com
These addresses are specific to Brainstorme's upload storage, so there is no need to allow all of Amazon S3. The exception can be limited to the study team's accounts if you prefer.
The report lists what was blocked, when (with times in UTC), and the first bytes of every test request, which is the information a gateway's file-type rules act on. Blocked requests should appear in your gateway or DLP logs at those times.
Questions
Is any patient information sent? No. Every test file is random data generated in the browser.
Everything went through, but my upload still fails. Then the network is not the cause. Damaged or split ZIP files are the most common reason: see Fixing a corrupt or unreadable zip. If the file is fine, try the upload again, and contact support if it keeps failing.
The check will not start, or shows an error. Your session may have expired: sign out, sign back in and try again. If it still fails, your network may be blocking Brainstorme's servers themselves. Contact support with a screenshot.
Can I use a different network to get the upload through? Please don't move imaging to a personal or guest network to get around your hospital's security. Ask your IT team to allow the addresses above instead.
Who can see my results? Brainstorme support can see a summary of each check (which tests went through and which were blocked) so we can help. It never includes patient information.
Getting help
When contacting support about a failing upload, include the reference shown at the end of your check (and on the report), along with the details listed in Troubleshooting.