Clinical Trial Imaging Core Lab Software: Why Blinded Independent Review Breaks a Generic PACS

Why blinded independent review is not a PACS problem

A subject in an oncology trial has a baseline CT and four follow-up scans. Under the imaging charter, two independent radiologists read all five time points without knowing each other's results, without knowing the treatment arm, and without seeing the site investigator's assessment. If their response calls differ, a third reader adjudicates by selecting one of the two reads rather than producing a new one. Every measurement, every selected target lesion, every call must be reconstructable years later, along with which charter version governed it and which reader was certified for that criteria set on that date.

Point a hospital PACS at that and it will store the images beautifully and solve none of it. A PACS is built to give every clinician the fullest possible view of a patient. A core lab system is built to give a specific reader a deliberately constrained view of a de-identified subject in a defined order, and to prove afterwards that the constraint held. Those are opposite design goals, which is why generic imaging infrastructure never survives contact with a blinded independent central review.

Problem 1: images arrive as a mess and PHI hides in the pixels

Hundreds of sites send data by DICOM push, portal upload, SFTP and physical media that someone still has to load. Acquisition drifts from the imaging manual: slice thickness wrong on one scanner, contrast timing inconsistent, a series missing, a subject imaged on a different scanner at follow-up which quietly invalidates comparison. And patient identifiers turn up in three places: the DICOM header, the file structure, and burned into the pixel data on ultrasound captures, scanned reports and secondary capture series where no tag-level anonymisation will ever find them.

De-identification therefore has to be two mechanisms, not one. Tag-level rules that strip and replace identifiers while preserving the temporal and spatial relationships the read depends on, and pixel-level detection for burned-in text with a human confirmation queue for anything uncertain. This is one of two places where a model does honest work here, because burned-in text detection is a genuinely good machine vision task and the failure cost of missing one is a privacy incident. The other honest job is technical quality control: comparing headers against the charter, flagging missing series, scanner changes between time points and out-of-specification parameters, so a QC technologist reviews exceptions rather than opening every study.

Problem 2: the read paradigm is the product, and it changes per protocol

Independent double read with adjudication. Sequential locked read where a reader cannot revise an earlier time point. Global read where all time points are presented together. Different criteria: RECIST 1.1 in most solid tumour work, iRECIST where immunotherapy pseudoprogression matters, Lugano in lymphoma, RANO in neuro-oncology, PCWG3 in prostate, and a long list of non-oncology scoring systems in rheumatology, hepatology and ophthalmology. Each brings its own target lesion rules, measurement constraints and response logic.

Calyx, Median Technologies, Clario and ICON Medical Imaging all handle this competently, and every one of them is a service organisation first. A sponsor contracting them buys the read, with the platform included. That is a perfectly good arrangement for a sponsor running one imaging endpoint, and it is precisely the wrong arrangement if you are trying to be a core lab, or a sponsor who wants to run reads with an in-house or contracted reader network across a portfolio. You cannot buy their operating system, because it is not what they sell.

What a custom build does: it implements the paradigm as configuration over a common measurement model rather than as a hard-coded workflow. Criteria definitions carry target and non-target lesion rules, measurement types, response derivation and the conditions that trigger adjudication. Then a new protocol is a charter configuration reviewed by your medical lead, not an engineering release, which matters because sponsors amend imaging charters mid-study and your read cannot wait for a deployment window.

Problem 3: blinding constraints are the entire security model

Reader one must not see reader two's measurements. Neither may see the site read or the treatment arm. The adjudicator sees both reads but usually not the reader identities. A reader who read a subject in an earlier study should not read them again if the charter forbids it. In some paradigms a reader must not see subsequent time points before completing the current one. These are not user interface preferences. They are the scientific validity of the endpoint.

Enforce them at the query layer, so a reader session physically cannot fetch what it must not see, and make the constraint set testable. Then extend the same discipline to the places blinding actually leaks: export files, error messages, notification emails, worklist counts that inadvertently reveal another reader's progress, and support staff accounts with broad access. A partner who has not thought about what a support engineer can see has not finished the design.

Problem 4: the read has to be reconstructable, not just recorded

Two years after a submission a reviewer asks how the target lesion in the liver was measured at week 24. You need the exact image and series, the annotation geometry, the measured value, the reader, the timestamp, the charter version, the criteria version, the reader's certification status at the time, and whether that time point was later re-read under a re-read directive.

Build it as an append-only event record where annotations are objects with provenance, not overlays saved into a file. Store the derived response separately from the measurements that produced it so the derivation can be re-run and compared. Keep the charter and criteria as versioned artifacts referenced by every read session. This is the difference between a system that can answer an inspection question in a minute and one that triggers a forensic exercise across three teams.

Problem 5: reader supply is the real operational constraint

The bottleneck in a core lab is rarely infrastructure. It is that you have eleven qualified readers, four of them are also practising radiologists with clinics, sponsors have contractual turnaround expectations, and studies do not arrive evenly. Assignment therefore has to respect certification per criteria set, conflict rules, blinding history for the subject, current workload and availability, then produce a forecast rather than a backlog.

Include reader certification as a first-class record: training completed, criteria qualified for, refresher due dates, and evidence retained for audit. Track inter-reader discordance rates by study, because a rising adjudication rate is usually a signal about charter clarity or reader training rather than about the drug, and it is a number sponsors will ask about. Turnaround dashboards should show ageing by study and by time point, ordered so an operations manager can act this morning rather than report next month.

Storage, and the cost nobody models until year two

Imaging volume is not like other clinical data. A single oncology subject with five time points of contrast CT is substantial, and a multi-year study across hundreds of subjects becomes serious infrastructure. Design tiering from the start: fast storage for studies under active read, cheaper tiers for completed reads still within retention, archive for closed studies whose retention obligation continues for years. Retrieval time from archive is a business decision that has to be agreed with sponsors rather than discovered when someone requests a re-read. Also decide early whether images ever leave your storage boundary for reader viewing, because a viewer that streams rather than downloads is a materially different security posture and a different engineering problem.

What this costs and how long it takes

A first release with multi-channel intake, two-mechanism de-identification, charter-driven technical QC, reader assignment, a blinded read workspace with measurement tooling, one criteria implementation and adjudication runs $120,000 to $240,000 and ships in 16 to 22 weeks, based on Digital Heroes delivery experience. A full platform adding further criteria, reader certification and discordance analytics, sponsor turnaround dashboards, storage tiering, re-read directives and an EDC or RTSM feed runs $320,000 to $750,000 phased over 10 to 16 months.

What drives price up in this category specifically: the number of criteria implementations, since each one is a real body of rules and needs medical review, not just coding. Viewer capability, because a diagnostic-grade multi-planar viewer with registration and segmentation is a different order of work from a measurement tool for a single modality. Modality breadth, as PET with standardised uptake values, MRI with multiple sequences and ophthalmic imaging each bring their own handling. Physical media intake, if you still receive discs. And validation, because a system producing endpoint data falls under 21 CFR Part 11 with a qualification burden to match. What keeps it down: launching with one modality and one criteria set on a live study before widening.

Build versus buy, and when contracting the read is right

Contract the read, and do not build, if you are a sponsor with one imaging endpoint in one study. Calyx, Clario, Median Technologies and ICON Medical Imaging will deliver an endpoint with the regulatory familiarity and the reader network already assembled, and replicating that for one study is not a rational use of capital. The same holds if your imaging is exploratory rather than a registrational endpoint.

Build when two or more of these are true. You are or are becoming a core lab and the platform is your operating capability rather than a tool. You run imaging endpoints across a portfolio and per-study service fees have become a large recurring line. You have your own reader network and want to control assignment, certification and turnaround. You work in a therapy area with a scoring system the service providers treat as bespoke, which means you pay a premium every time. Or you need imaging results to flow directly into randomisation or an interim analysis on a timeline that a service handoff cannot support. The tipping point is when the read workflow becomes something you sell or something your science depends on, rather than something you buy.

How to choose a developer for imaging core lab software

Ask how they detect PHI burned into pixel data. If the answer is only DICOM tag anonymisation, they will leak an identifier on an ultrasound capture and you will be reporting a privacy incident.

Ask them to describe the blinding model at the query layer, then ask what a support engineer can see in a production incident. The second question is the one that separates people who have run this from people who have designed it.

Ask how a charter amendment mid-study is handled without a code release, and how the system records which charter version governed a completed read. Ask what their viewer is built on and whether measurements are stored as provenance-bearing objects rather than baked overlays. Then get in writing before kickoff that you own the repository, the image storage accounts, the infrastructure and the validation package. Image data has retention obligations that outlast software vendors, so portability is not a negotiating point. At Digital Heroes all of it is the client's from the first commit.