Radiology Systems

PACS Software: How to Evaluate One

We do not sell a PACS. We integrate with dozens of them, which is why we can write the interface questions a PACS buyer should ask and a PACS vendor would rather you did not.

ADThe AbbaDox Team
Updated 18 August 20265 min read
The short answer

Evaluate PACS software on four things. How fast can a radiologist open a study with its priors? How completely does it integrate with the systems either side of it? What happens to your images if you leave? And what does the vendor commit to after go-live? Viewer feature lists rarely separate the finalists. These four do.

An imaging center IT director at a table, mid-thought, during a software evaluation
Key takeaways

  • Time-to-first-image is the metric radiologists actually feel. Measure it on your own studies.

  • Ask what happens to your data if you leave. The answer tells you a lot about the vendor.

  • Integration depth is the whole game, and "integrates with your RIS" is not a specification.

  • Involve the radiologists who will read on it every day, not only IT.

We do not sell a PACS

It is worth saying plainly where we stand. AbbaDox builds a radiology information system, which integrates with whichever PACS you run. That means we have no product to push here, and it also means we have spent years on the receiving end of these integrations across many vendors. The questions below come from that.

The four things that decide which PACS software you buy

Time to first image, with priors. Not the demo dataset. Ask to load a large study of your own with several priors, on a connection like the one your readers use. Everything else is negotiable; this is what a radiologist experiences fifty times a day.

Integration depth, specifically. Which standards, in which direction, maintained by whom.

Exit terms. How images are exported, in what format, over what period, at what cost. A vendor comfortable with that question is telling you something.

After go-live. Migration of existing studies, support hours, and who owns the interface when it breaks at seven in the morning.

The integration questions to ask, and what a good answer sounds like
Comparison
AskA good answerA warning sign
How do you receive the worklist?DICOM modality worklist, live from the RIS"We import a schedule file nightly"
How are priors matched?On accession and patient identifier, with configurable rules"It usually works"
How does the report get back?HL7 or FHIR result message to the RIS"The radiologist copies it across"
Who maintains the interface?Named, with an SLA"It depends"
What happens if we leave?Full DICOM export, defined timeline and costHesitation
Can we talk to a customer on our RIS?Yes, with an introduction"Our references are confidential"

The last row is the most useful question on the list. A vendor who has genuinely integrated with your RIS before can prove it in one call.

What is a DICOM conformance statement, and why ask for one?

Any serious vendor publishes one, and it is the single most useful document in an evaluation. The DICOM standard defines the conformance statement as the formal declaration of exactly which services and object types an implementation supports. It tells you what a system genuinely does rather than what a datasheet claims, and comparing two of them side by side settles most integration arguments before they start. A vendor who will not give you one has answered the question.

Why is the exit clause the most valuable paragraph in the contract?

The images are yours. Whether you can actually take them is a contractual and technical question you settle before signing, because afterwards you have no bargaining position at all.

The lock-in mechanism is rarely stated openly. It is that some archives keep studies in a proprietary database layout rather than as standard DICOM objects, so leaving means an extraction project rather than a copy. The difference at contract end is measured in months of engineering time, and the party who pays for it is whoever failed to write it down.

Four things to get in writing, specifically:

  • Export in standard DICOM, not a proprietary format and not a viewer screenshot. Name the format in the contract.

  • Open web access. DICOMweb, meaning STOW-RS to store, QIDO-RS to query and WADO-RS to retrieve, gives you a documented path to your own data that does not depend on the vendor's goodwill.

  • A documented migration plan, including how long a full export takes at your data volume and who bears the cost.

  • The right to exercise it. A promise you have never tested is not a capability.

Then actually run it during the pilot. Export a real subset, re-import it somewhere else, and time it. A migration path that has never been executed is a paragraph, and paragraphs do not move terabytes.

A vendor neutral archive is the architectural version of the same idea: keep the storage layer separate from the viewer and workflow layer, so changing the viewer does not mean moving the images. Whether that is worth its own project depends on how likely you are to change, and how much you already hold.

How to do it

  1. 1

    Write down what is broken today.

    Retrieval speed, missing priors, remote reading, storage cost. That list, not a feature matrix, is your scorecard.

  2. 2

    Test on your own data.

    Your studies, your priors, your connection.

  3. 3

    Interrogate both interfaces.

    The one into the PACS from the RIS, and the one back out.

  4. 4

    Get exit terms in writing

    before you sign, not when you leave.

  5. 5

    Have the radiologists read on it.

    A viewer that IT likes and radiologists resent will be re-procured within three years.

Answers

Frequently asked questions

What should you look for in PACS software?

Time to first image with priors, integration depth in both directions, exit terms, and after-sale support. Test all four on your own data.

How much does PACS software cost?

It varies too widely to quote usefully. Ask for storage growth, interfaces and migration as separate lines, because those are where quotes diverge.

What is the difference between PACS and a viewer?

The PACS stores and manages the studies. A viewer displays them. Some viewers are sold separately, including zero-footprint ones that run in a browser.

Can a hospital and an imaging center share a PACS?

Yes, and it is common in affiliated groups. Access control and the identity of the patient across both organizations are the hard parts.

What happens to your images if you change PACS vendor?

That depends entirely on what the contract says. If studies are held as standard DICOM and the vendor supports DICOMweb, a migration is a large copy. If they are in a proprietary layout, it is an extraction project measured in months of engineering time.

What is DICOMweb, and why does it matter when buying?

The web version of the DICOM services: STOW-RS to store, QIDO-RS to query, WADO-RS to retrieve. It matters because it gives you a documented, vendor-independent route to your own data.

Should you buy PACS and RIS from one vendor?

It simplifies support and it means choosing both on the strength of whichever is weaker. Integrated separates can be better if the interfaces are genuinely maintained.

Sources

Evaluating a PACS and wondering how it will sit with your RIS? That half we do know.

Bring your own numbers and we will walk through them with you.

Keep reading

Related
ArticleHow a PACS worksArticleChoosing a RIS vendorCapabilityIntegrations