The camera gets four pages in the tender and the workstation gets one line. What to specify instead: acquisition control, reconstruction you can see inside, the clinical module set, DICOM behaviour with your PACS, and quantification you can defend in a report.
In most tenders the camera runs to four pages of detector, collimator and gantry detail, and the workstation gets a single line saying "with acquisition and processing software". Six months later the department discovers that the renal module does not present relative function the way its nephrologists expect, that the cardiac package was quoted but never licensed, or that the PACS is receiving screen captures rather than data anyone can reprocess.
The workstation is what the technologist and the reporting physician touch every day. It deserves a specification of its own, and the specification is not a list of adjectives.
On most systems the acquisition console and the processing workstation are the same software family, and the protocol library lives there. That library is a clinical document. It defines matrix size, zoom, frame duration, number of projections, orbit type, energy windows, gating parameters and whole body scan speed for every study the department runs.
Two things matter and are rarely asked about. First, whether protocols can be locked, so that a validated acquisition cannot be quietly altered by whoever is on the evening list, and whether changes are attributed to a user. Second, whether the console pulls patient demographics from a modality worklist. Retyped names and hospital numbers are the most common reason a nuclear medicine study never reaches the right folder in PACS, and the fix is a worklist connection, not a memo about spelling.
A department needs to know what its reconstruction is doing and be able to change it. Ask what is offered and how it is controlled:
The commonest reconstruction problem in a working department is not a missing feature. It is a filter cut-off left at a default that suited the count statistics of a demonstration study and not those of a real patient. If the software will not let the physicist see and set that number per protocol, it is the wrong software.
Modules are usually licensed individually, and this is where quotations diverge quietly. Build the list from your own case-mix rather than from the vendor's bundle. A general department typically needs whole body and three-phase bone, bone SPECT, dynamic renal with renogram curves and split function, static renal cortical imaging, thyroid uptake with a percentage calculation, parathyroid, hepatobiliary, gastric emptying, lung ventilation and perfusion, and lymphoscintigraphy. A department doing cardiac work needs perfusion quantification with polar maps, gated wall motion and ejection fraction. A department doing radioiodine therapy needs whole body iodine imaging and the tools to compare pre-treatment and post-treatment studies.
For every module on the list, ask the same three questions. Is the licence perpetual or a subscription that stops working when a payment is missed? Can it be added later, and at what price, or does adding it require a platform upgrade? And does it run on the hardware being quoted, or does it need a larger workstation?
Buying every module available is a waste. Buying only the ones needed on day one, on a platform that cannot take the others later, is worse.
Any number that goes into a report has to be reproducible by a second operator on a second day. That is a software property as much as a training one.
Ask how each quantitative module defines its regions of interest and its background subtraction, whether regions can be saved, named and re-applied to a follow-up study, and whether the underlying counts and curve values can be exported rather than only displayed. For cardiac perfusion, ask which normal database the polar map comparison uses, and be realistic in reporting about how well that reference population matches your patients. A quantitative result whose provenance nobody in the department can explain is a liability in a clinical meeting.
Every vendor says the system is DICOM compatible. Ask for the DICOM conformance statement as a document, and have your physicist or IT lead read it. The distinction that matters is between displaying another vendor's reconstructed images, which is generally straightforward, and reading another vendor's raw projection data and reprocessing it, which often is not.
That difference becomes concrete in three situations, and all three arrive eventually. A department replaces an old camera and wants its historical studies to remain readable and comparable. A department runs two systems from different makers and wants one reporting seat. A patient returns with a prior scan from another hospital and the physician wants to compare rather than repeat. Establish before purchase which of those the workstation can do, and get it written into the offer.
Ask specifically what happens to the existing database at replacement time: whether it is migrated, converted, or simply left on an old machine in the corner that nobody is allowed to switch off.
Decide early what actually gets sent to PACS, because the default is often less than you think. Reconstructed slices and screen captures of curves and polar maps usually go. Raw projection data frequently does not, and once the local workstation database is purged, a study that was archived only as screen captures cannot be reprocessed, ever. If the department wants the ability to re-reconstruct an old study, that has to be an explicit archiving decision with storage allocated for it.
The mechanics matter as much as the policy: whether the workstation waits for a storage commitment response from PACS before it considers a study safely archived, how failed transfers are queued and retried, and whether numeric results reach the report as text a physician can paste or only as a picture. Local database backup belongs in the same conversation, and a backup that has never been restored is not a backup.
Systems such as the SCINTRON platform from MiE GmbH of Germany are sold with acquisition and processing modules that can be configured to the department's case-mix, which is helpful, but it also means the module list is a decision the buyer has to make rather than one that arrives by default. Make it deliberately, with the reporting physician in the room.