By Vvon Engineering Team | Published | Updated
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.
Nuclear medicine RFQ checklist (TXT)
Specify acquisition, processing, licensing and data exchange separately in a nuclear-medicine purchase. A single line promising software can leave uncertainty about clinical modules, quantitative methods and future access to patient data.
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:
Request enough documentation and authorised controls to understand and validate reconstruction for the clinical task. Some validated packages use protocol presets rather than exposing every numerical parameter. Assess transparency, reproducibility and change control; the absence of a particular filter control alone does not prove a package unsuitable.
Build the module list from the service's approved examinations. Examples include bone, renal, thyroid, hepatobiliary, lung and cardiac processing. Modules may be licensed individually or within bundles, so confirm the exact entitlement and versions rather than assume every named function requires a separate licence. A software module does not by itself establish clinical capability.
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.
Quantitative outputs need validated methods, reproducibility and stated uncertainty. Some observer variation is expected; identical numbers from a second operator are not a universal acceptance condition. Assess the software together with acquisition and staff competence.
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. Where the second is required it has to be bought as such, for example SCINTRON Processing Multivendor.
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.
Specify successful storage confirmation, failure handling, retention and tested recovery for the required image and raw-data objects. DICOM conformance statements support comparison, but interoperability must be tested with the actual PACS and workstations. Storage commitment is not a substitute for a complete retention and backup policy.
Confirm concurrent acquisition and processing capability, user licences and authorised remote access. Include supported operating systems, cybersecurity updates, manufacturer-approved software, backups and power protection in the hospital IT plan. A second workstation may help throughput, but one console does not always prevent concurrent work, and an abrupt shutdown has no predictable one-time recovery allowance.
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.
Share your application, equipment requirements and procurement timeline. Our engineers can help clarify the configuration and scope for your enquiry.