Digital Pathology Workflow Problems: The 7 That Send Pathologists Back to Glass, and How to Avoid Them

Why does a digital pathology project get scoped as a viewer build so often?

Because the viewer is the visible part. It is what the department sees, what the executive demo shows, and what everybody has an opinion about. So the proposal comes back describing pan, zoom, pyramid levels, annotation tools and colour handling, and a large share of the budget goes into rebuilding something that already exists and works.

Reaching parity with a mature whole slide image viewer takes roughly a year of specialised work, and your pathologists will not notice the difference except in the delay. Meanwhile the parts that decide whether the programme succeeds are ingest reconciliation, the worklist engine, latency management, consultation routing and storage policy, and none of those demo well.

The scoping rule is simple and we give it to clients even though it shrinks the engagement. Integrate an existing viewer. Then spend the budget on the join between the image and the case, because that join is where every practical failure sits. Image management products are built around the image. A pathology department runs on the case: an accession with blocks, stains, levels, recuts, a responsible pathologist, a turnaround clock and a report. If a developer proposes to build the viewer, they are either inexperienced or selling you time, and the test is that direct.

What goes wrong when you reconcile 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 a particular immunohistochemical marker, at a specific level. The link is the barcode, and barcodes are the least reliable part of the whole chain.

Labels are printed by different printers with different quality. The laboratory information system formats identifiers differently depending on which module produced the slide, so a recut label does not always look like an original. Tissue overhanging a label, a smudge from a stainer, a slightly skewed label at the edge of the scan field, all produce a read failure or, worse, a partial read that matches the wrong case. And a mixed scanner fleet multiplies it, because each manufacturer emits different metadata, different file formats and its own barcode handling. Laboratories that bought scanners at different times, which is most laboratories, end up with a reconciliation problem owned by nobody.

The symptom is a queue of unmatched images that somebody clears manually every morning. The fix is a vendor neutral ingest layer in front of everything: normalise the output, decode barcodes with fallback strategies, match against the laboratory information system record with a confidence assessment, and send ambiguous matches to a short exceptions queue with the image visible so a human resolves in seconds rather than opening three systems. Run slide quality checks at ingest too, catching out of focus regions, missing tissue and coverslip artefacts before a pathologist opens the case and has to send it back.

Why does the laboratory information system integration break after launch?

Reading from the laboratory information system is straightforward. Everything else about that integration is not, and it is the dependency that most often slips a go live date.

• Write back. Reading accession data is a query. Writing a result or a status change into the system of record touches clinical safety, change control and a vendor whose professional services queue is not yours to schedule.
• Upgrades. A laboratory information system upgrade can change field semantics or interface behaviour, and the pathology module is rarely the first thing tested after one.
• Local conventions. Accession formats, block naming and stain codes carry years of local practice, and an assumption that held for the main laboratory fails for the outreach site that joined after an acquisition.
• Ownership. The integration usually spans your team, the laboratory information system vendor and hospital informatics, and when it breaks, the first hour goes on deciding whose problem it is.

The practical defences are contract tests that run your real extraction against known good records on every upgrade, an integration owner named on both sides, and a rule that the pathology system degrades gracefully rather than blocking sign out when the interface is unavailable.

What happens when validation and algorithm governance are not in scope?

These two gaps are quiet during the build and loud afterwards.

Validation is the first. A deployment supporting primary diagnosis is a different project from a research or education deployment, because documented requirements traceability, change control and validation evidence become project work rather than paperwork. Whole slide imaging is an established diagnostic modality and the regulatory path exists, but that path has to be planned into the schedule. Teams that discover it after the software works lose months and sometimes lose the clinical use case entirely.

Algorithm governance is the second. Model output belongs in the record as an advisory observation carrying the model identifier and version, the region it applied to, the timestamp and the operator context, stored separately from the diagnostic record and clearly labelled in the interface. The pathologist sees it as input and signs out the diagnosis. Systems that blur that line, presenting a model result as a finding or storing it without a version, create a medicolegal problem the department inherits and cannot unwind later, because a year of cases will already carry the ambiguity. Any vendor or developer casual about this distinction should be treated with caution, and the question is worth asking in the first meeting rather than the last.

Should you build custom or configure what you already own?

Buy, and stop there, 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, and there is nothing distinctive about your workflow to protect.

Sectra is also a sound buy if you already run its enterprise imaging estate and want pathology inside the same archive. That is a genuine architectural advantage and building alongside it would be duplicating work. Proscia Concentriq is a reasonable buy where the primary need is image management with configurable worklists and your case routing rules are not unusual.

Where these products stop is expressible and checkable. Their worklists are configurable filters, which is a queue with a saved search. What a multi site department needs is a rules engine it controls: route prior specimen cases to the original reporting pathologist, cap daily complexity units rather than case counts, hold cases requiring a stain until it results, escalate anything approaching the turnaround target, and read service coverage from the rota so somebody covering frozen sections is not assigned a full list. If you can write your assignment rules on one page and your platform cannot express them, that is the line.

How do hidden costs get into the quote?

Five places in this category.

• Scanner fleet diversity. Each manufacturer is a format, a metadata model and its own barcode behaviour. A quote written for one brand does not scale to three.
• Write back to the laboratory information system. Almost always priced as an integration and almost always a separate negotiation with a vendor whose timeline you do not control.
• Validation. Diagnostic scope brings documentation and change control that is real project effort, not overhead.
• Storage. The unit price is not the issue, the retention policy is, and a policy nobody wrote becomes an annual budget surprise that leads departments to reduce scanning.
• Multi institution consultation. Identity federation and legal agreements attach to what looked like an engineering task.

Ask for each of these as a separate line. A single number covering all five will move.

What separates a build that works from one that fails here?

The builds that succeed treat latency as a design requirement with a stated target, not as something infrastructure will sort out. Assignment becomes the prediction signal: 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. That is why the worklist engine and the storage design belong in the same system rather than in two conversations.

They make storage lifecycle an explicit, reviewable policy per image class, so active cases stay warm, recently signed cases stay warm through the realistic amendment and consult window, older cases tier to archive with retrieval cost surfaced before a bulk restore, and teaching collections get their own rule.

They make the consultation a first class object, a scoped and time limited grant to a named external pathologist with the opinion returned as a structured record attached to the case, and a full audit trail of who viewed what and when. That trail is what makes the information security conversation winnable rather than a standoff.

And they settle ownership before kickoff. You should hold the repository, the cloud and storage accounts, and the right to hire another firm. At Digital Heroes the client owns the code from the first commit. Ask about export specifically as well: images should stay readable in standard formats and annotations exportable as structured data, because an annotation set built over several years is a research asset you cannot afford to strand.