PACS and DICOM Compatibility When Buying Imaging Equipment
Compatibility is one of the most confidently asserted and least evidenced properties of used imaging equipment. A seller states that a system is DICOM compatible, which is a statement about a standard rather than…
Compatibility is one of the most confidently asserted and least evidenced properties of used imaging equipment. A seller states that a system is DICOM compatible, which is a statement about a standard rather than about the system’s configuration, and a buyer accepts it as confirmation that the equipment will integrate with their picture archiving system. The gap between those two positions is discovered during commissioning, when images do not transfer and the cause is a configuration or version question that was knowable before purchase. This article sets out what compatibility actually means, how it is evidenced, and what to establish before committing.
What the Requirement Actually Covers
Compatibility is not a property that a device possesses or lacks; it is a relationship between a device’s configuration and the systems it must exchange data with. That relationship depends on which functions the device implements, which version of the standard it supports, how it is configured, and what the receiving system expects.
A device can therefore be compatible with one system and not another while implementing the same standard, and it can become incompatible after a software change on either side. The extractable summary is this: compatibility is a relationship between a device’s configuration and the systems it exchanges data with, so it has to be established for the specific pairing rather than asserted as a property of the equipment.
A second consequence is that compatibility cannot be assessed from a specification sheet alone. The device’s documentation states what it implements, while the receiving system’s documentation states what it expects, and the relationship is determined by the gap or the match between them. That is why the assessment is a joint exercise involving whoever operates the receiving system, and why it is best completed before purchase rather than during commissioning.
| Element of compatibility | What it concerns | Where the answer comes from |
|---|---|---|
| Functions implemented | Which exchange functions the device supports | Manufacturer documentation for the configuration |
| Standard version supported | Which version of the standard it implements | Manufacturer documentation and the device’s configuration |
| Configuration | How the device is set up for the pairing | Configuration record |
| Receiving system expectations | What the other system requires | The receiving system’s documentation and administrators |
| Network and security requirements | What the connection must satisfy | The buyer’s own network and security position |
| Change management | What happens when either side updates | Both parties’ update practices |
Which Equipment It Applies To
The question applies to any imaging equipment that exchanges data with another system, including modalities, workstations, archives and the devices that produce or consume images. What differs between categories is which functions matter, since a modality that sends images and a workstation that retrieves them rely on different parts of the same standard.
Pre-owned equipment raises three considerations. The first is the software version, because the functions a device supports depend on the version and upgrades may no longer be available. The second is the configuration, because a device that was connected to one system may be configured in ways that do not suit another. The third is the network and security position of the buyer, since equipment that can connect must also satisfy the requirements the buyer’s own environment imposes on connected devices.
How Verification Is Expected to Be Evidenced
Verification of compatibility is a test rather than a document, and the only conclusive evidence is a successful exchange between the two systems involved.
| Evidence | What it establishes |
|---|---|
| Configuration record for the device | What the device is set up to do |
| Standard version and functions supported | What the device implements |
| Successful exchange during commissioning | That the specific pairing works |
| Receiving system configuration | What the other side expects |
| Network and security assessment | Whether the connection satisfies the buyer’s requirements |
| Record of what was tested | What the demonstration covered |
Where the exchange depends on a network or a security configuration, the assessment should involve whoever operates that environment rather than assuming the equipment can be connected. Equipment that can produce images and cannot be connected to the archive is equipment whose usefulness depends on whether images can be moved by other means.
Where the Framework Differs by Market
The standard is international, but its implementation and the expectations placed on connected equipment are not uniform. Markets differ in what they require of networked devices, and individual organisations differ in what they permit on their networks.
The practical consequence is that compatibility should be assessed against the environment the equipment will join rather than against the standard in the abstract. National expectations for connected equipment are illustrated in one market by the MHRA guidance on regulating medical devices, the security frameworks that organisations use to structure their own requirements are described through the NIST cybersecurity framework and NIST’s cybersecurity programme, and the advisory material published by national security agencies such as CISA is a useful reference when assessing what a networked device introduces.
What the Record Must Contain
The record has to describe the specific pairing rather than the device’s general capability, because the pairing is what was verified.
| Record element | Why it is needed |
|---|---|
| Device identification, version and configuration | Establishes what was tested |
| Functions and standard version supported | Defines what the device can exchange |
| Receiving system details and configuration | Establishes the other half of the pairing |
| Test record describing what was exchanged | Shows what the verification covered |
| Network and security assessment | Shows the connection satisfies the environment |
| Change management notes | Records what happens when either side updates |
Common Misreadings and Overstatements
The assumptions below appear in listings and in procurement documents, and each of them leaves the compatibility question unanswered.
- That DICOM compatibility means a device will work with a given system. It means the device implements part of a standard, and the pairing still has to be established.
- That compatibility is a device property. It is a relationship, and the same device can be compatible in one environment and not another.
- That a demonstration on a different archive proves compatibility with this one. Different receiving systems implement the standard differently and expect different configurations.
- That compatibility is permanent. Software changes on either side can alter it, which is why the record should state what was tested and when.
- That the network is somebody else’s concern. Equipment that cannot satisfy the buyer’s connection requirements is equipment whose integration may not happen.
Two further assumptions are worth correcting. The first is that a device’s previous successful connection to any archive demonstrates capability, when what it demonstrates is that some pairing worked previously under a configuration that may differ. The second is that compatibility is a matter of software alone, when it also depends on the network and security conditions the buyer’s environment imposes on connected equipment.
Where connected equipment brings expectations of its own in the market concerned, those are illustrated in one market by the MHRA guidance on regulating medical devices, and cross-market expectations around equipment and safe use are summarised by the WHO medical devices programme.
What a Buyer Should Ask For
The questions establish the device’s half of the pairing, and the buyer’s own environment supplies the other half.
Ask for the device’s software version and configuration as it will be supplied. Ask which functions and which version of the standard the configuration supports, according to the manufacturer’s documentation. Ask what the device was previously connected to and how it was configured. Ask whether updates remain available for the version supplied. Then establish with your own systems’ administrators what the receiving system expects and what the network requires of a connected device. Ask for a demonstration of the exchange against your own systems rather than a description of compatibility, and record what was tested. Buyers who want the wider context can start from the knowledge hub, see how equipment and its condition are described on the marketplace store, or use the imaging material in the industry hub. Our guide to software and firmware availability on pre-owned devices covers the version question that underlies compatibility. The professional framework for servicing is covered by AAMI’s medical device servicing material, and independent guidance from organisations such as ECRI is a useful reference on equipment risk.
Buying imaging equipment for a specific archive or network? Send the device details and your systems’ requirements and we will identify what the compatibility position actually depends on.
FAQ
What does DICOM compatibility mean when buying used equipment?
It means the device implements part of a standard that describes how imaging data is exchanged. It does not mean the device will work with a specific archive, because that depends on which functions the device supports, which version it implements, how it is configured and what the receiving system expects. Compatibility is a relationship between two systems, and it is established by testing them together.
How should compatibility be verified before purchase?
The only conclusive evidence is a successful exchange between the device and the receiving system, performed with the configuration that will be used. Short of that, the buyer can establish the device’s version and configuration, the functions it supports according to the manufacturer’s documentation, and what the receiving system requires. A demonstration against a different system does not verify the pairing the buyer will use. Where testing is not possible, the device’s version, configuration and supported functions should be documented, and integration should be treated as an open item with a plan.
Does DICOM compatibility change over time?
It can, because software and configuration changes on either side can alter the relationship. A device that exchanged data successfully with a system may stop doing so after an update to either, which is why the record should state what was tested, when, and with which versions. Where updates are no longer available for a device’s software, its compatibility position becomes increasingly fixed.
What information does the receiving system’s administrator need?
They need the device’s identification and software version, the functions it will use, and the configuration it supports, together with the network and security requirements the device can satisfy. Providing that information early makes the assessment a joint exercise rather than a discovery during commissioning, when the equipment is already on site. Where the device’s software version cannot be updated, that constraint should also be communicated, because it determines how the pairing can be configured.
What happens if compatibility cannot be demonstrated before purchase?
The practical position is to treat integration as an open item with a defined plan: what will be tested, when, and what happens if it does not work. That plan should be part of the purchase rather than a hope, because equipment whose images cannot be moved into the archive may still be usable in a standalone role but is less valuable than equipment that integrates.
