Case · 02
From MRI upload to a reviewable clinical result
Redesigning the clinical operation around the viewer — upload, QA, worklist, recovery.
VoxelBox does not begin when the radiologist opens the viewer.
Before a result can be interpreted, imaging data needs to be uploaded correctly, checked against protocol requirements, processed successfully and presented to the right clinician with enough context to act.
I redesigned this path as one connected clinical workflow.
The problem
The product supported structural MRI, diffusion MRI and resting-state fMRI. Each modality had different requirements, processing stages and reasons for failure.
When something went wrong, users often saw a status without understanding:
- what had failed
- whether the case could still proceed
- whether new data was required
- who needed to act
- where to return after the issue was resolved
This created friction for technicians and uncertainty for radiologists.
My role
I led the design across upload, QA/QC, patient worklists, processing states and access to results.
The work required coordinating clinical expectations, technical constraints and operational realities across hospitals with different levels of imaging and infrastructure maturity.
Key decisions
Design around the person who can resolve the issue
A radiologist may need to know that a scan failed quality checks, but the technician is usually the person who can upload a corrected sequence. The worklist therefore needed to show not only the status of a case, but the reason, the affected modality and the next available action.
Separate acquisition quality from processing status
A dataset can upload successfully and still fail protocol or processing checks. I separated these states so users could distinguish:
- whether the required files were present
- whether the imaging quality was sufficient
- whether processing had begun
- whether networks or tracts were ready
- whether the result required review
This reduced the ambiguity of a single generic progress state.
Make failure recoverable
Incomplete uploads and partial conversions created a difficult edge case. A failed dataset could later be identified as a duplicate, blocking the corrected upload.
I worked through the failure and re-upload model so the system could differentiate between:
- a complete duplicate
- a partial upload
- a failed conversion
- a corrected re-upload
- a new clinical case
The aim was to protect data integrity without trapping users in an unrecoverable state.
Use the patient list as an operational surface
The patient list was not treated as a simple table of cases. It needed to support the daily work of technicians and clinicians by exposing scan and upload dates, uploaded modalities, QA status, processing status, result readiness, report availability and the next required action.
This allowed many issues to be understood without opening every case.
Preserve depth without making the list dense
I separated the experience into two levels. The first level supported scanning and action across cases. The second provided the full protocol summary, QA findings, processing details and result preview. This kept operational work fast without hiding the information needed for investigation.
What changed
The workflow became easier to reason about from the point of upload to the point of clinical review.
Technicians had clearer recovery paths. Radiologists had better visibility into whether a result was ready and how much confidence to place in the underlying data.
Why this work matters
A sophisticated viewer cannot compensate for weak data handling.
In clinical imaging, trust begins before the model runs.