A raw DICOM transfer moves pixels from one archive to another. It does not know whether the person opening the study on the far end is who the link or the login claims, or whether that access should still work in three weeks. It also has no answer to who you would ask if the study turned up somewhere it should not have. An image exchange platform is the layer built to answer those questions, plus one more: what the recipient actually opens the study with.
Evaluating an image exchange platform means evaluating that layer, not the transfer underneath it. The transfer itself was never the hard part. For a product team choosing or building the exchange layer, a working DICOM connection between two systems is table stakes, not the deliverable.
Point-to-point transfer between two known partners has existed for decades. It answers almost none of what a partner asks at contract time: who can see this, for how long, from what, and can we prove it later. What follows is what an exchange platform has to get right across four problems, plus what changes when the study lands on a PACS the sending side does not control.
What an Image Exchange Platform Has to Solve That a Raw Transfer Does Not
A point-to-point DICOM transfer between two archives works because both sides agreed in advance to trust each other’s network address and DICOM application entity title. That agreement does not scale to a platform meant to serve many partners, most of whom the sending organization has never dealt with before a given study needs to move. The platform has to replace a standing bilateral agreement with something that works the first time, for a recipient the sender may never transact with again.
Four problems sit underneath that requirement, and a platform’s real job is answering all four rather than the one a demo tends to show first. The first is confirming identity across a boundary neither side controls. The second is deciding what access looks like and when it stops, and the third is giving a recipient with no PACS of their own a way to open the study. The fourth is keeping a record of who touched it in a form that survives being checked months later.
Identity Across an Organizational Boundary
Identity here is really two separate questions, and a platform that only answers one of them has not answered either. The first is patient identity: does the study arrive under a name, birthdate, and accession number that actually correspond to the same person on the receiving end. The second is requester identity: is the person or system asking for the study who they claim to be. A platform also has to say how the sending organization knows that, beyond the fact that someone clicked a link.
IHE’s answer to the first question is Patient Identifier Cross-referencing. The profile defines how a shared manager reconciles identifiers across separate identifier domains, so two systems that never shared a medical record number can still agree they mean the same patient. The profile is specific about what it is built for: it supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains through a shared manager both sides feed into and query against. Cross-referencing answers patient identity at scale, and it is also a piece of standing infrastructure: it assumes both organizations already participate in the same cross-reference domain, which most bilateral exchange relationships do not.
A platform that does not join a shared cross-reference domain still has to answer both questions, more lightly. Patient identity becomes a manual check against name, date of birth, and accession number before a recipient can open anything. Requester identity becomes an account the receiving organization was provisioned into ahead of time, or, on the lighter end, nothing beyond possession of a link. None of those answers is wrong by itself, and each is worth asking about specifically, because marketing language rarely distinguishes reconciling identity against a shared registry from trusting whoever holds the credential.
Access Models: Link, Account, and Federation, and When They Expire
Three access patterns are worth telling apart, because each carries a different guarantee.
- Link-based access. The link itself is the credential, so control lives entirely in how the platform issues and retires it. Ask whether it expires on a fixed schedule or stays open indefinitely, whether it can be revoked before it expires, and whether opening it once burns it or leaves it valid for repeat access.
- Account-based access. The receiving organization is provisioned into the platform ahead of time, with its own login and its own permissions. Heavier to set up than a link, but it gives the sending side a real identity to grant, restrict, and revoke, rather than a bearer token anyone holding it can use.
- Federated access. The two organizations’ identity systems trust each other directly, so a user authenticated at their own organization needs no separate account on the platform. This one carries a precondition the other two do not: an identity federation agreement has to be in place before a single study moves. That is standing infrastructure, which a one-off exchange relationship rarely justifies.
Expiry is the detail that separates a platform built for controlled sharing from one that just moved the disc-handoff problem onto a server. A link or an account that never expires by default behaves like a permanent copy handed over once: indefinitely accessible, impossible to claw back. A platform worth evaluating makes expiry a default rather than a setting a partner has to remember to configure correctly every time. It also treats revocation as something that removes access immediately, not something that only stops new links from being issued.
The Recipient-Side Viewer Question
None of the identity or access work matters if the person on the other end has nothing to open the study with. The recipient is often a referring practice, a specialist down the road, or the patient’s own phone, none of which keeps a PACS or a DICOM viewer on hand. An exchange platform that assumes the recipient already owns compatible software is really only solving the problem for organizations that could have solved it themselves.
That is the case for shipping a browser-based viewer alongside the transfer: the recipient then needs nothing more than the link and a browser. Worth asking specifically: is the viewer that opens on the recipient side the same rendering quality used internally, with real windowing and measurement? Or is it a lighter preview, meant for a referring provider to confirm receipt rather than to read from diagnostically? A platform built for referral sharing and one built for diagnostic-grade remote reading are solving genuinely different problems, even when both call themselves an image exchange platform.
Audit and Attribution
A study crossing an organizational boundary needs a record of who requested it, who retrieved it, who actually opened it, and when. The sending and receiving systems are no longer one system logging its own internal access. DICOM’s own audit trail profile is specific about what that record has to contain: the data includes records of who accessed healthcare data, when, for what action, from where, and which patients’ records were involved. That is the standards-level definition of a defensible log, and it sets a higher bar than a generic access log that only shows successful sign-ins.
For a platform handling exchange rather than internal PACS access, the practical test is narrower. Can it produce, on request and without a support ticket, a report of exactly who touched a specific study, from what location, and through which access method (link, account, or federated login)? A complete PACS build already treats audit logging as its own subsystem for exactly this reason, and a teleradiology workflow answers a version of the same question for its own remote readers. An exchange platform has to answer it for recipients the sending organization does not employ and, in many cases, has never met.
What Happens When the Receiving Side Runs a Different PACS
A partner evaluating an exchange platform is rarely moving studies into a system it controls. More often the receiving end is a different PACS entirely, built by a different vendor, with its own interpretation of the DICOM standard. That is where a platform’s actual DICOM conformance matters more than its marketing page does.
Every DICOM implementation publishes a conformance statement describing which services and transfer syntaxes it supports. Two systems that both claim DICOM compliance can still fail to interoperate if their statements do not overlap on the service classes a given transfer needs.
That leaves three paths when the receiving side is not one the platform was built for. The first is a direct push into the foreign PACS over a classic DICOM association, which depends on that PACS accepting an unfamiliar sender and negotiating a compatible transfer syntax. The second is to serve the study through a link and a browser viewer, which asks nothing of the receiving side except a browser.
The third is DICOMweb, the REST web services the DICOM standard defines in PS3.18 for managing and distributing DICOM information objects over HTTP. In the Studies Service, the Store Transaction is also known as STOW-RS, the Retrieve Transaction as WADO-RS, and the Search Transaction as QIDO-RS. Where the receiving side exposes those endpoints, a study can move without either end negotiating a classic DICOM association.
One caveat is written into the standard itself: security considerations, including access control, authorization, and auditing are beyond the scope of PS3.18. DICOMweb answers transport and leaves the rest to whatever sits around it.
Of the three, the link-and-browser path is the one that does not depend on a stranger’s PACS behaving the way the sender expects. EBM mAIn PACS® publishes native DICOM services, C-STORE, Query/Retrieve, Modality Worklist, and Storage Commitment, alongside link-based sharing for a recipient with nothing DICOM-aware to receive on. Which of those a specific destination will actually accept is a conformance question to settle per partner, against both conformance statements, rather than something any vendor can answer in the abstract.
Standards-Based Exchange Versus a Proprietary Platform
IHE’s Cross-Enterprise Document Sharing for Imaging profile, XDS-I.b, solves identity, access, and audit at a scale no bilateral platform reaches. How the affinity-domain model does that is covered in detail elsewhere in this series. The short version is that XDS-I is a different architecture, not a larger version of the proprietary one. It is built for a multi-hospital health information exchange with dozens or hundreds of participants, not for a single referral relationship or a one-off transfer to a specialist.
XDS-I and the IHE cross-enterprise profiles are not part of the integration surface EBM offers in this market today. What EBM mAIn PACS® does offer is a link-based sharing layer (secure sharing via QR, AirDrop, and web links) designed to support HIPAA compliance. A partner evaluating exchange at affinity-domain scale is evaluating a different problem than a partner sharing a study with one referring physician. The two are worth keeping separate during vendor evaluation, rather than treating an exchange platform as a smaller version of an XDS-I deployment.
Questions to Put to a Vendor
- Does patient identity get reconciled against a shared registry, or verified manually against name, birthdate, and accession number before access opens?
- For link-based access: does a link expire by default, can it be revoked before it expires, and does opening it once end its validity?
- For account-based access: who provisions a new recipient, and how long does that take?
- Does the recipient-side viewer render the same quality the sending side uses internally, or a lighter preview?
- Can the platform produce a report of every access to a specific study, on request, without a support ticket?
- When the receiving side runs a different PACS, does the platform push over a classic DICOM association, expose DICOMweb endpoints, serve a link, or some combination?
- What happens to an already-shared study if a recipient’s access needs to be revoked after the fact?
What This Means for Your Evaluation
None of these four problems, identity, access and expiry, the recipient’s viewer, and audit and attribution, gets solved by the transfer mechanism itself. They get solved, or left unsolved, by the platform layered on top of it, and a vendor’s answer to each one is checkable, not a matter of trusting the word “secure” on a landing page. A partner that tests each of the four separately, rather than accepting the platform as a single checkbox, knows what happens the day a study has to leave the network it was acquired on.