Two radiologists at the same hospital can open the same study in seconds. One PACS, one identity system, one archive: the study is already inside the boundary both of them work in, and the platform already knows who they are. Medical image sharing between two separate organizations is a different problem, because none of that shared infrastructure crosses the boundary with it.
The identity system on one side has no idea who the person on the other side is. Access control stops at the edge of the network it was built for, and the study still has to land somewhere the receiving side can open it.
Why Crossing the Boundary Changes the Problem
Inside one organization, a PACS answers a narrow question: is this authenticated user allowed to see this study. That answer rests on three assumptions about everyone who asks. They share one patient record, they authenticate against one identity system, and they already run software that opens a DICOM study.
Cross an organizational boundary and all three break at once.
- Patient identity does not travel with the study automatically. Two hospitals almost never share a medical record number for the same patient, and there is no universal U.S. patient identifier that lets one system simply ask another, “is this the same person.” Someone or something has to reconcile identity across the boundary, and getting that step wrong risks the wrong study, or a duplicate record, landing on the receiving end.
- Access control does not extend past the network it was built for. A login that works for a hospital’s own staff proves nothing to a system it was never registered with. Whoever controls the sending side has to decide, explicitly, what the receiving side is allowed to do: view once, view for thirty days, download, nothing after a set date.
- The receiving side may not run anything DICOM-literate at all. A referring physician’s office, a specialist across town, or a patient’s own device often has no PACS, no archive, and no compatible DICOM viewer waiting for the study to arrive.
Four real mechanisms exist to solve some or all of that, in different combinations, and none of them clears all three cleanly. Each also answers a fourth question the three assumptions never raise: what record survives of who opened the study, and whether that record would hold up months later.
Four Ways Medical Image Sharing Crosses an Organizational Boundary
Physical Media: Why the Disc Handoff Persisted
A study burned to a CD or USB drive sidesteps every assumption above, which is exactly why it lasted this long. The DICOM standard’s media storage model exists specifically for this. It “focuses on the aspects directly related to data interchange through removable storage media,” language that describes a disc in a patient’s folder as precisely as it describes any other physical format.
A disc built to that specification carries a DICOMDIR file alongside the images. That file is an instance of the Media Storage Directory SOP Class, and instances of that class “are conveyed in the File with a File ID of DICOMDIR.” A compliant reader browses the disc’s contents from it. Neither end needs a network connection or a shared archive.
That self-containment is the entire value proposition, and it is also the whole limitation. Identity travels however the sender writes it onto the label; nothing verifies it against a record on the receiving end. Access control does not exist once the disc changes hands: whoever holds it can open it, indefinitely, on any machine with a compatible reader. The audit trail is effectively nothing past the point of handoff, and revocation is not a real option, because a disc already given cannot be un-given.
What made this tolerable for years was the third assumption from the section above. A disc solves the compatible-viewer problem better than almost anything else.
IHE’s Portable Data for Imaging profile makes that explicit with its Basic Viewer Option. A media creator claiming the option “shall be able to include a viewer on the media,” and that viewer “automatically launches if permitted by the operating system.” A machine with nothing DICOM-aware installed can still open the study, which is the property that kept the disc handoff alive long after network alternatives existed.
Point-to-Point DICOM Transfer Between Known Partners
Direct transfer between two archives looks the most like what happens inside one organization, extended across two. Two systems, one at each organization, establish a direct connection over a known network address, using a known DICOM application entity title on each side. Both have agreed ahead of time to accept studies from the other. A DICOM C-STORE operation then pushes the study directly from the sending archive to the receiving one.
This is not teleradiology, where a study routes to a remote reader inside one working relationship a single platform already manages end to end. Point-to-point transfer is narrower and older than that: two separate organizations, each running its own archive, agreeing in advance to accept each other’s traffic. A standing referral relationship, a second-opinion partner, or a specialty group that reads for several practices are the shapes this usually takes.
Identity is where this mechanism is honest about its limits. Trust exists between the two systems, not between the two patient records. Nothing in the transfer itself reconciles medical record numbers across organizations, so patient matching still depends on whatever manual or workflow-level check the two sides agreed to separately.
Access control lives at the network layer. An IP address and an application entity title are either on the accepted list or they are not, which makes the grant all-or-nothing rather than per-study or time-limited. Auditing happens at each node independently, and neither side automatically sees the other’s log. Revocation means editing a whitelist, which is fast, but it revokes the whole relationship, not one shared study.
Link-Based Sharing With a Browser Viewer
Link-based sharing trades a DICOM-to-DICOM connection for something closer to how most other files move between organizations today. A study gets packaged behind a link, and whoever holds that link opens it in a browser instead of a dedicated viewer. Nothing DICOM-aware has to already exist on the receiving end, which solves the same compatible-viewer problem physical media solved, without shipping a physical object anywhere.
EBM mAIn PACS® offers this path. UDE, its mobile diagnostic workstation, lists QR code, AirDrop, or the network as its own sharing surface. The platform’s broader sharing layer adds secure links and web access that move studies between sites, referrers, and patients. A referring physician or a patient does not need a PACS account to see a study, only a browser, which is a real answer to the viewer-compatibility half of the cross-organization problem.
Link-based sharing, as a mechanism, answers the identity and access questions at the platform level rather than the way a standards body would. A link functions as a credential: whoever holds it can open what it points to. The platform generating the link is therefore the thing enforcing expiry, view limits, and who gets a link in the first place. That puts real weight on the platform’s own access controls rather than on a network-level trust relationship negotiated between two organizations.
A HIPAA distinction sits underneath all of this, and it is worth being precise about. If two treating providers exchange a study directly for a patient’s care, that disclosure falls under the treatment exception in the HIPAA rules. No separate contract is required for a hospital to share a record with the specialist it referred a patient to.
A platform that generates the links, hosts the images, and controls who can open them is a different kind of party. An entity that requires access to protected health information on a routine basis while providing a data transmission service on a covered entity’s behalf is functioning as a business associate, not a mere conduit. That is a contractual and compliance question sitting underneath the technical one.
Standards-Based Exchange: Where IHE XDS-I Lives
Standards-based exchange is the one built for many-to-many participation rather than point-to-point trust or link possession. IHE’s Radiology domain maintains Cross-Enterprise Document Sharing for Imaging, known as XDS-I.b, alongside a related profile for federated access across separate communities, Cross-Community Access for Imaging.
The model is different in kind from the first three. Instead of one organization sending a study directly to another, participating organizations agree to a shared affinity domain. A common registry indexes where studies live. A receiving organization queries that registry rather than the originating hospital, and retrieves the study from wherever it actually lives.
What the profile itself requires is narrower than the affinity-domain framing suggests. IHE’s Radiology Technical Framework is explicit that XDS and XDS-I.b “do not specifically address the patient information reconciliation process necessary between the XDS Affinity Domain and any other local patient identity domains.” Reconciling medical record numbers is a separate IHE profile, Patient Identifier Cross-referencing, that an affinity domain groups alongside XDS-I.b. Security works the same way: the framework states the profile “is not intended to include nor require any specific security model,” while requiring implementers to group XDS-I.b actors with Audit Trail and Node Authentication.
What the structure does deliver is a place to put the identity and audit answers once, for every participant, instead of renegotiating them per relationship. Audit is the clearest case: ATNA grouping is a requirement of the profile, not a property of whichever platform happens to be moving a given study. Identity reconciliation is available on the same terms, as a profile the domain adopts, rather than a check two organizations improvise between themselves.
What it costs is infrastructure. A hospital or health network has to already belong to the affinity domain, run a conformant actor, and participate in the shared identity and audit services before any of this works. That is why this mechanism mostly shows up inside larger health information exchanges and multi-hospital networks, rather than as something a single point product adds on its own. XDS-I and the IHE cross-enterprise profiles are not part of the integration surface EBM offers in this market today, and nothing in this piece should be read as a claim of that support here.
What Each Mechanism Actually Guarantees
| Mechanism | Identity model | What the receiving side needs | Audit trail | Access and revocation |
|---|---|---|---|---|
| Physical media | Whatever the label says, unverified | Any DICOM viewer, or the Basic Viewer Option viewer on the disc | Effectively none after handoff | Not possible once given |
| Point-to-point DICOM | Pre-established trust between two known systems | A DICOM-conformant receiver at a known address | Logged separately at each node | Remove the connection from the whitelist |
| Link-based sharing | Possession of the link is the credential | A browser | Platform-side log of creation and access | Expire or revoke the link |
| Standards-based exchange (XDS-I.b) | Domain-wide, through a grouped identity cross-reference profile | A conformant actor inside the same domain | ATNA grouping required by the profile | Registry-level status change |
None of the four is simply better than the others. A referral to one trusted specialist rarely justifies standing up affinity-domain infrastructure. A patient who needs to hand a study to a new provider once does not need a permanent DICOM connection negotiated between two archives. What changes case to case is which of identity, access, audit, and viewer compatibility matters most for that specific handoff, and no single mechanism clears all four at once.
What This Means for Your Evaluation
For a product or engineering team scoping medical image sharing into a platform, the work starts one level up from the mechanism. Decide first which of the assumptions that break at the boundary the platform will enforce in software, and which it will hand to a partner’s own process. The mechanism follows from that, not the reverse.
What no mechanism settles on its own is which party is the HIPAA business associate. That determination follows from who holds routine access to the data, not from how convenient the sharing mechanism feels.
EBM mAIn PACS® answers viewer compatibility and access convenience directly, with secure sharing via QR, AirDrop, and web links alongside local backup, in a platform designed to support HIPAA compliance. What it is deliberately not positioned as in this market is a stand-in for the affinity-domain infrastructure IHE XDS-I.b is built to provide.
The question to put to any vendor, including this one, is therefore narrower than it looks. Which of the four criteria does the mechanism enforce on its own, and which does it assume the other organization already has? Every mechanism in the table above leaves at least one of the four to somebody else, and the one it leaves is the one you have to cover.