Digital Pathology Workflow Software: How Do You Get a Multi Gigabyte Slide in Front of the Right Subspecialist Without Making Them Wait?

Why digital pathology breaks the workflow it was meant to fix

It is 7:40am. A pathologist opens the first case of the day from home. The whole slide image is over two gigabytes, and the viewer is fetching tiles across a virtual private network. Ten seconds pass. Then the next slide in the case does the same. Multiply that by a 40 case day and the practice has traded a microscope for a progress indicator. Meanwhile the case itself was assigned by a rule that says gastrointestinal cases go to whoever is on the gastrointestinal list, which does not know that one of the three people on that list is covering frozen sections in the operating room today.

The stack is usually a scanner fleet from one or two manufacturers, an image management product such as Proscia Concentriq, Sectra Digital Pathology or a scanner vendor's own platform, a laboratory information system holding the accession and the block and stain records, a reporting module in that same laboratory information system or in the electronic health record, and storage provisioned by a hospital infrastructure team who were told the number would be large.

Those products are real and some are excellent, and whole slide imaging as a diagnostic modality is established: Philips IntelliSite was the first whole slide imaging system granted marketing authorisation in the United States for primary diagnosis, and DICOM Supplement 145 defines a standard representation for these images. The problem is not the imaging. The problem is that image management products are built around the image, and a pathology department runs on the case: an accession with blocks, stains, levels, recuts, a responsible pathologist, a turnaround clock and a report. The join between those two models is where every practical failure sits.

Problem 1: reconciling scanner output to accession, block and stain

A scanner produces a file. That file has to become slide 3 of block B of accession S25-0041, stained with an immunohistochemical marker, at a specific level. The barcode on the slide is the link, and barcodes are read imperfectly, printed by different label printers, and formatted differently by the laboratory information system depending on which module produced the slide.

With one scanner brand and one laboratory information system, vendor ingest handles this acceptably. With a mixed fleet it degrades quickly, because each manufacturer emits different metadata, different file formats and different barcode handling. Leica Aperio, Philips and other ecosystems all assume their own end to end path. A laboratory that bought scanners at different times, which is most laboratories, ends up with an ingest reconciliation problem owned by nobody, and the symptom is a queue of unmatched images someone clears manually every morning.

A custom build puts a vendor neutral ingest layer in front of everything. Scanner output is normalised, barcodes are decoded with fallback strategies, and the resulting slide is matched against the laboratory information system record with a confidence assessment. Ambiguous matches go to a short exceptions queue with the image visible so a human resolves in seconds rather than opening three systems. Slide quality checks run at ingest as well, catching out of focus regions, missing tissue and coverslip artefacts before a pathologist opens the case and has to send it back for rescanning. That last check is a narrow, concrete use of automated image analysis, and it removes a real irritation from the sign out day.

Problem 2: case assignment is a scheduling problem, not a queue

Assigning cases well requires knowing subspecialty competence, current workload, who is on service versus on research time, who is covering frozen sections, case complexity, urgency, and whether the case has a prior specimen that a specific pathologist already reported. Getting this wrong shows up as one person with 60 cases and another with 12, and as turnaround times that miss because a complex case sat behind routine ones.

Image management platforms offer worklists with configurable filters, which is a queue with a saved search. What they generally cannot express is a rule set specific to a department: route prior-specimen cases to the original reporting pathologist where possible, cap daily complexity units per person, hold cases requiring a specific stain until it resulted, escalate anything approaching the turnaround target.

A custom build makes assignment a rules engine your department controls. Rules combine subspecialty, prior case history, workload measured in complexity rather than case count, service coverage from the schedule, and turnaround risk. The output the department feels immediately is a balanced day and a visible escalation list. The output leadership feels is that turnaround targets become manageable rather than reported after the fact.

Problem 3: the wait is the product, so pre-fetch is not an optimisation

A pathologist's tolerance for latency is roughly the time it takes to move a slide on a stage. Any digital workflow that is slower than glass gets resisted, correctly. Tile serving on demand from cold object storage over a remote connection will not clear that bar.

Vendor platforms leave this to infrastructure, which means an institution's experience of digital pathology is largely determined by decisions a storage team made without a pathologist in the room. The result is a department that adopted digital pathology and quietly went back to glass for anything urgent.

A custom build treats latency as a design requirement. When a case is assigned, its images move to warm storage and the low magnification pyramid levels pre-cache to the pathologist's edge, so the first view is instant and higher magnifications stream as they navigate. Assignment is the prediction signal, which is why the worklist engine and the storage design belong in the same system. The measurable target we work to is that opening the next slide feels like moving a slide, and if the architecture cannot hit that, nothing else in the project matters.

Problem 4: consultations cross institutional boundaries and nothing handles identity

Second opinions and subspecialty consultations go outside the institution. Today that frequently means physically mailing glass, or granting an external pathologist an account in an internal system, which information security dislikes for good reason. Digital pathology's clearest clinical benefit is exactly this case, and it is the workflow least well served by the products.

A custom build makes the consultation a first-class object: a scoped, time limited grant of access to a specific case for a named external pathologist, with their annotations and opinion returned as a structured record attached to the case rather than as an email. Institutional identity federation where it exists, and a controlled external identity path where it does not. The audit trail records who viewed what and when, which is what makes the security conversation winnable.

Problem 5: retention is measured in years and nobody wrote the cost policy

Whole slide images are large and retention expectations are long. At meaningful scan volumes the annual storage growth is a budget line that surprises finance every year, and the reflex response is to reduce scanning, which defeats the programme.

A custom build applies lifecycle policy per image class. Cases under active sign out stay warm. Recently signed cases stay warm for the period during which amendments and consults realistically occur. Older cases tier to archive with retrieval cost surfaced before a bulk restore happens. Educational and research collections get their own policy, because they are accessed differently. The policy becomes explicit and reviewable rather than emergent from whatever the storage team could afford that year.

What this costs and how long it takes

Across the projects Digital Heroes has delivered, a focused first release covering vendor neutral ingest with accession reconciliation, slide quality checks, the subspecialty worklist engine and pre-fetch backed viewing runs $100,000 to $200,000 and ships in 14 to 20 weeks. A full platform adding external consultation workflow, structured annotation, algorithm result governance, storage lifecycle tiering and laboratory information system write-back runs $280,000 to $700,000 phased over 9 to 15 months.

What drives cost up in this category specifically:

• Scanner fleet diversity, since each manufacturer brings its own format, metadata and barcode behaviour
• Laboratory information system integration depth, where reading accession data is straightforward and writing results back is not
• Whether the deployment is diagnostic rather than research, because validation documentation and change control become project work
• Network and storage topology, particularly if pathologists sign out remotely across sites with uneven connectivity
• Multi-institution consultation, which adds identity federation and legal agreements to an engineering project

What keeps cost down: use an existing viewer. Building a whole slide image viewer from scratch is a year of work to reach parity with something you can integrate in weeks, and we tell clients this even though it reduces the size of the engagement.

Build versus buy, and when buying is the right call

Buy if you run a single site with one scanner brand, primarily for research, education or archival rather than primary diagnosis. The vendor platform that came with your scanners will be cheaper and better integrated than anything custom at that scope. Sectra is also a sound buy if you already run its enterprise imaging estate and want pathology inside the same archive.

Build when two or more of these hold. You run scanners from more than one manufacturer and ingest reconciliation is a daily manual task. Case assignment needs rules your platform cannot express. Pathologists sign out remotely and latency is driving them back to glass. You route consultations between institutions regularly. Or you are adding algorithm results to the workflow and need governance over how they are recorded, which pathologist saw them and what version produced them.

Our position on algorithms is deliberately conservative. Algorithm output belongs in the record as an advisory observation with its model version, the region it applied to and the time it ran, visible to the pathologist and never presented as a finding. A system that blurs that line creates a medicolegal problem your department will inherit, and any vendor or developer who is casual about it should be treated with suspicion.

How to choose a developer for digital pathology software

Ask how they reconcile a scanned file to an accession, block, stain and level. If they describe filename parsing, they have worked with one scanner and one naming convention and will not survive your second manufacturer.

Ask what latency target they design to and how they achieve it. You want to hear pre-fetch triggered by assignment, pyramid level caching at the edge and a specific target for first view. Anything vaguer means your pathologists will be waiting.

Ask how algorithm results are stored and displayed. The right answer includes model version, applied region, timestamp and explicit advisory framing separated from the diagnostic record.

Ask whether they will integrate an existing viewer or build one. A developer proposing to build a viewer is either inexperienced or selling you time.

Ask who owns the code and get it in writing before kickoff. You should hold the repository, the cloud and storage accounts, and the right to hire another firm. At Digital Heroes the code is yours from the first commit, and your images and annotations must remain exportable in standard formats rather than trapped in a proprietary store.