I spent eight years working on the operations side of health technology before we started ImageAssist. Most of that time was spent close to clinical workflow software: how it was configured, where it broke down, why the people using it had developed workarounds that the system was never designed to accommodate. I learned more about how hospital software actually works from watching the workarounds than from reading any product documentation.
The worklist problem showed up in a lot of different forms across that time. But it took a specific set of conversations in late 2022 and early 2023 to make me understand it clearly enough to think it was worth building a company around.
What I Kept Seeing
The pattern I kept seeing was this: radiology departments had invested heavily in scanner technology, PACS infrastructure, and reading room ergonomics. The equipment was good. The radiologists were skilled. But the process that determined which case the radiologist read next was a FIFO queue sorted by the time the study arrived in the system.
Nobody had decided that queue order was the right policy. It was the factory default. When a PACS is installed, the worklist sorts by arrival time unless someone actively configures it differently. Most departments had never revisited that setting because it worked well enough in the aggregate, and changing it required either manual effort (someone physically reordering cases) or a system integration nobody had prioritized.
The gap between the sophistication of the imaging technology and the crudeness of the workflow that organized how radiologists used it struck me as both obvious and oddly ignored. Everyone in operations knew it. Radiologists certainly knew it. But the standard responses were "we have stat protocols" and "radiologists can escalate manually," which are true statements that address a different version of the problem. Manual escalation requires someone to know a case needs escalating before the image has been read. That is a hard requirement to meet systematically.
The Conversation That Made It Concrete
The conversation that pushed this from "familiar problem" to "company-worth-building problem" happened in early 2023, talking with a body radiologist who worked at a high-volume regional imaging center outside the Boston area. She described her morning routine: coming in, looking at the overnight queue, seeing 40 or 50 studies, and knowing that she was going to work through them mostly in order. The ordering indication column was usually too sparse to tell her much about clinical urgency. So she read the queue.
She said something I have thought about since: "Every morning I open the worklist and I have this moment where I wonder if I should be reading it differently. And then I just start reading."
That moment she described, the habitual suppression of a legitimate clinical concern in the interest of getting through the work, is exactly the kind of thing that workflow software should be solving. Not because the radiologist was doing anything wrong. She was doing exactly what the workflow asked her to do. But the workflow was asking her to accept an assumption that queue order was good enough, and she did not fully believe that assumption, and the system gave her no alternative.
Why the Existing Tools Were Not Solving It
When Marcus and I started working through the problem seriously in mid-2023, we looked at what already existed. There were a few categories of response: stat protocols built into the RIS, PACS-level manual reordering tools, and some early CAD systems that flagged certain finding types but were not designed to feed back into worklist order. There were also radiology AI tools built primarily for detection accuracy, not for worklist integration.
The detection-focused tools were the most interesting to look at closely, because they were the most technically sophisticated. Some of them had strong evidence for detection performance on specific finding types. But most of them were designed as reading aids: they flagged findings in the image for the radiologist who was already reading the study, not before the study reached the radiologist. The worklist order question was outside their scope.
The gap we saw was narrow but important: an AI layer that operates specifically in the interval between DICOM arrival and radiologist open, evaluates the incoming study for urgency signals, and changes the worklist order as a result. That is a different product from a detection aid. It is a triage tool with a PACS integration, not an image analysis overlay.
What We Decided Not to Build
We made some explicit decisions early about what ImageAssist was not going to be. We were not going to build a diagnostic tool. Not because diagnosis is unimportant, but because the bar for diagnostic AI is properly high, the regulatory path is long, and it was not the problem we were trying to solve. We wanted to fix the sequence problem, not the interpretation problem. The radiologist's interpretation is not what was broken.
We also decided not to build a multi-modality system in the first version. The worklist problem exists across all imaging modalities, but chest CT is the volume modality where time-critical findings are most concentrated and where the triage signal is most tractable. Starting narrower meant we could build a product that worked well for one clear use case instead of a product that worked moderately for many cases.
These constraints made the first version of ImageAssist easier to reason about: one modality, a defined set of urgency-associated finding types, DICOM-native integration that does not require workflow changes, and a single output that is a change in worklist order position. Simple to explain. Specific in its claims. Honest about what it is and is not.
Building It Without Outside Money
We built ImageAssist independently. That choice came from a conviction that the first version of a clinical workflow tool needs to earn trust at a pace the clinical environment can absorb, and that pace is not well-served by growth pressure. The radiology departments we work with are evaluating us on whether the prioritization signal is accurate and whether the integration is stable. They are not evaluating us on our ability to scale to 200 sites in 18 months. Those are different things.
Being independently funded also meant we could spend the time that building the training dataset correctly required. The labeling work is the foundation the model rests on, and it cannot be rushed without consequences for model quality. We were not in a position where investor timelines were competing with annotation quality timelines. That mattered.
Where We Are Now
The version of ImageAssist that exists today is the product of two years of working through the specific, concrete problems that sit between "this triage concept makes sense" and "this tool works reliably in a real reading room." Integration with real PACS environments. Threshold calibration that balances sensitivity against false positive rate. Performance stability across different scanner acquisition parameters. Radiologist trust built through consistent accuracy on prioritized cases.
We built it because the worklist problem was real, it was costing real clinical attention every day it was not addressed, and the solution required connecting a technical layer (AI scoring) to a workflow lever (worklist order) that nobody else had made the explicit focus of a product.
The goal has not changed from the morning I talked to that radiologist: the case the radiologist most needs to read next should be at the top of the list when they open the worklist. Not after someone makes a phone call. Not after the radiologist scans the ordering indications. First.
If that matches a problem your department is living with, we would like to talk with your clinical team.
