How image data travels between practices
What sits between the scan and the report is rarely medicine. It is the journey in between, and in Switzerland that journey is still, surprisingly often, a burned CD. An ordering of the routes, what they require, and where they are blind.
Route in
-
Modalities on your own network
Direct connection to the devices
The device sends to a fixed destination, like to a printer
-
Institute, hospital, partner practice
Connection to another site
Rules decide which study goes to which requesting physician
-
Referrers, colleagues, patients
Encrypted messaging channel
The study as an attachment, with a way back in the same thread
-
CD, USB stick, DICOM folder
Upload in the browser
For everything that still arrives on physical media
-
Practice and hospital information systems
Programming interface
DICOMweb, for software that hands over studies itself
Archive
Image archive
Point of entry
The study appears and is matched to a person
Archive
Vendor-neutral, in the DICOM standard
Route out
-
The care team
Viewer in the browser
Nothing to install, at every workstation
-
The physician in the consultation
The primary system
Images in the patient record instead of a second programme
-
Colleagues, institutes, referrers
Messaging channel
Question, answer and images in one thread
-
Patients, second opinions, assessments
Link without an account
The recipient needs nothing but a browser
-
Existing archive, backup
Copy on your own premises
Where an internal rule or the regulator requires it
-
Changing provider, your own software
Complete export
In the standard format, without a project and without a fee
- Route in
- Entry and archive
- Route out
A scan takes minutes. Getting it to where somebody reads it and acts on it often takes days. The reason is rarely the acquisition and almost never the reporting. It is the stretch in between.
Technically that stretch was solved decades ago. DICOM, the standard for medical imaging data, is older than the web and describes not only the file format but also how two systems exchange images directly. Swiss radiology still burns CDs every day. That is not a technical oversight; it follows from how the routes are built.
Five patterns, and only one ends in the right place
Almost everything moved between sites today comes down to five patterns. They differ less in speed than in what they demand of the receiving side.
| Route | What it requires | Where it ends |
|---|---|---|
| Physical media, CD or USB | A drive on both sides, and time | On a desk, until somebody reads it in and matches it by hand |
| Nothing but a mailbox | At the attachment limit. A CT series exceeds it many times over | |
| The imaging site's referrer portal | A separate account per site | In a browser, with a download that then sits locally |
| File-sharing service | An account, often outside Switzerland | In a folder with no link to the patient record |
| Direct connection between the archives | A one-time setup on both sides | In the recipient's archive, with the study's own details |
Why the CD survived
The CD is the only route that works without an agreement. The sending site needs to know nothing about the recipient, not which system they run, not whether they run one at all. It burns, it posts, it is done; everything after that is the other side's problem. That asymmetry, not habit, is the real reason it survives.
It carries a cost the sending side never sees. The receiving practice spends a few minutes per disc: read it in, find the patient, match the study, file it. At five discs a week that is a few hours a year; at fifty it is a working day a month. Add the discs that never arrive and the ones that cannot be read.
The other three of the first four routes merely move the same problem elsewhere. A referrer portal is convenient for the institute because it solves distribution; for a practice with four imaging partners it means four accounts, four logins and four places where something might be waiting.
The step that is rarely counted
Every vendor writes about the transfer. What comes afterwards appears on no datasheet: the matching. A study that arrives belongs to a person who already exists in the receiving system — usually spelled slightly differently, with two digits swapped in the date of birth, or duplicated across two appointments.
As long as that reconciliation is done by hand, it makes no difference how fast the images travelled. The bottleneck sits at the destination, not on the route. The most useful question to ask of any delivery route is therefore not how fast it is, but where it ends.
A route that drops images into a folder for somebody to fish out by hand has moved the work, not removed it.
What the choice turns on
The route is not chosen by the technology but by who is on the other side. Most practices end up needing two: one for what arrives regularly and by itself, and one for the single case a person sends. Five questions serve both.
- Does the route end in the archive or in a folder? That question determines the effort.
- What does the other side have to set up? A route that starts a project over there will not be used.
- Do the images arrive as DICOM with all their details, or as exported single images without context?
- Where is the data held, and under which law does the operator sit? Patient data needs a data-processing agreement under art. 9 FADP.
- How does the data get out again? Retention periods for patient records are set by the cantons and run to ten years and more; they outlast most vendor relationships.
The last question is the most awkward and the only one that can be asked before the contract. After that it is a negotiation.
The blueprint behind it
The diagram above shows the pattern by which an image archive is connected, whoever it comes from: several routes in, one point of entry where matching happens, an archive in the standard format, and several routes out. It is a useful thing to hold a system against. Where a part is missing, manual work appears in its place — permanently, not just during roll-out.
