Medical Image Exchange Platform Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does scoping identity reconciliation as an exact match happen so often?

The pain presents as slow imports, so the fix gets written as an import tool. Somewhere in the specification a single line appears: match the incoming study to the patient on name and date of birth, and queue anything that does not match for the film library team to reconcile.

That line is where the project fails, and it fails for a reason nobody in the room is thinking about. The queue is a business hours control. Trauma transfers, cross cover reads and the studies whose absence causes a repeat scan arrive overnight and at weekends. So the design produces exactly the behaviour it was commissioned to eliminate.

Exact matching also fails more often than teams expect. A sending institution puts the surname first, or fills the given name field with a full first and middle name, or hyphenates where you do not, or records a date of birth that was transposed at their registration desk. None of that is unusual and all of it defeats string equality.

What is needed instead is weighted demographic comparison across name, date of birth, sex and any available identifier, producing an explicit confidence score, with three bands. Above the upper threshold, reconcile automatically and log it. In the middle band, route to a queue visible to whoever is actually on shift, including the emergency department, with the images viewable so the decision takes seconds rather than a callback. Below the lower threshold, quarantine, and never let it touch a chart.

The design principle worth writing into the specification is that the system must be willing to say it does not know. Misattributed images are a serious safety event, and a platform that guesses quietly is worse than one that rescans.

What goes wrong when you migrate a legacy archive?

The second failure is that migration gets quoted as a copy. It is not a copy, it is a verification programme, and the teams that treat it otherwise finish with a residual set of studies nobody can account for and a permanent asterisk on the project.

The binding constraint is not your receiving infrastructure, it is the retrieval throughput the legacy archive can sustain while remaining in clinical use. Old archives were not designed to be exited, retrieval is slow, and pushing harder degrades the system radiologists are still reading from. That ceiling sets the schedule, and no amount of parallelism on your side changes it.

The second problem is identity. Old archives contain duplicates, merges that were never completed and studies attached to records that were later corrected somewhere else. The temptation is to clean all of that during the move. Resist it, because cleaning and migrating at once means you can no longer prove that what arrived matches what left, and provability is the entire point.

Three rules. Inventory every study at source before a single one transfers, so you know the denominator and can measure completion against a fixed number rather than a moving one. Verify per study by identifier and image count on arrival rather than sampling. And keep an exception register with a reason on every entry, reviewed weekly, so the residual set shrinks deliberately instead of being discovered at the end.

One practical note. Asking the incumbent archive vendor to help you leave carries an obvious structural conflict, and their migration line item is usually optimistic. Price and schedule it independently.

Why do tag morphing rules and worklist filing break after launch?

Once identity is settled, metadata has to be normalised so studies file and display correctly. Study descriptions, series descriptions, modality and body part all differ between institutions, and this normalisation is per source because every institution has its own habits.

The recurring failure is ownership. In most vendor deployments the rules are vendor managed configuration, so when a new referring facility starts sending studies with an unfamiliar naming convention, adjusting the mapping is a service request. Meanwhile studies file incorrectly and radiologists build workarounds that outlive the fix. A custom build recreates this exact problem if the developer owns the rules after go live, which is worth asking about before you sign.

The second failure is irreversibility. A rule deployed without testing rewrites tags across thousands of studies, and if the original tag values were not preserved there is no way back. Keep the source values, always, and treat morphing as a derived view rather than a destructive edit.

The third failure is the one that wastes the whole investment. A study that lands correctly in the archive but does not appear as a prior alongside the current examination in the radiologist's normal worklist is functionally invisible during a busy shift, which is precisely when a prior matters. Anything requiring a second application and a second login will not be opened.

The fixes are ordinary. Rules as versioned data, scoped per source, testable against sample studies before deployment and editable by your own imaging informatics team on the day a referral relationship starts. Original tags preserved. And an acceptance test that ends at the worklist rather than at the archive, because landing in storage is not the outcome anybody asked for.

What happens when outbound release authorisation is not covered?

Sending studies out is technically trivial and legally particular. Who authorised the release, what was released, to whom, and on what basis are the questions that matter, and information blocking rules have also raised the stakes on refusing legitimate requests.

The common failure is a general purpose share link with no expiry and no access log, created because a specialist needed a study on a Friday afternoon. It works, so it becomes the norm, and eighteen months later nobody can enumerate what has been shared or with whom. The variant failure is creating accounts for external clinicians, which persist long after the episode of care ends and become an access review problem your security team inherits.

The third is pushing patient requests to an in person film library visit. That is not a neutral choice, because when the sanctioned path is inconvenient, clinicians revert to burning discs, and discs are the thing the project existed to eliminate.

What belongs in scope from the start: release as an object with an authorisation attached, carrying requester identity, basis, scope of studies, an expiry and a complete access log. Time limited scoped access for external clinicians rather than accounts. A self service patient path with identity proofing. That audit trail is what lets a privacy office approve an electronic workflow instead of insisting on a manual one.

Should you build custom or configure what you already own?

If you are a single hospital with one archive, one reading system and occasional outside studies, do not build. Ambra Health handles cloud exchange well, Nuance PowerShare has genuine network reach, and a straightforward vendor neutral archive from Sectra or Hyland will serve you. Building infrastructure to solve an occasional problem is not a good use of capital, and we would say so on a first call.

The signals that the arithmetic has flipped are operational. You are a receiving centre for transfers from many facilities and repeat imaging is happening because import is slow. You run several archives after acquisitions and no single view of a patient's imaging exists. Your tag morphing rules require a vendor request every time a referral relationship changes. You are planning an archive migration and want it verifiable rather than asserted. Or outside studies currently sit in a separate viewer radiologists do not open.

An argument against our own interest: stay on an exchange network for the facilities already on it. Membership is worth more than any code you can write for those relationships. Build the layer covering everyone the network does not, which in most health systems is the majority of transfer volume.

How do hidden costs get into the quote?

Four places, all visible at scoping if somebody asks.

Source institutions. Each brings its own naming conventions and its own morphing rules, so a quote priced for ten facilities and a brief covering forty is short by thirty small pieces of work that add up.

Migration throughput. Volume alone does not set the schedule, the legacy archive's sustainable retrieval rate does, and that number is knowable only by testing it. Insist on a measured figure before the timeline is agreed.

Downstream systems. Every additional archive and reading system has its own filing expectations, and each one is a separate acceptance test.

Master patient index quality. Reconciliation accuracy is bounded by the index you match against, and if that index is poor, the confidence bands widen and the exception queue grows. Nobody quotes for this because nobody has measured it yet.

Then the recurring line. Maintenance runs 10 to 20 percent of build cost per year, so roughly $19,000 to $38,000 on a $190,000 first release, covering hosting, storage growth, monitoring and the steady stream of new referring facilities. Ask for the estimate broken out per source institution and per downstream system.

What separates a build that works from one that fails here?

Starting with intake, reconciliation and worklist injection for your top ten referring facilities. That covers most transfer volume and delivers the repeat scan reduction that funds everything else, and it produces evidence rather than a promise.

Then ending the acceptance criteria at the worklist. The measure of success is whether the radiologist ever has to know the study came from outside, and the answer should be no. A project that declares victory when studies reach the archive has stopped one step short of the benefit.

Then two owners, an imaging informatics lead and a radiologist who reads overnight. The informatics lead knows the metadata, and the radiologist knows what is actually usable at three in the morning, which is not the same knowledge.

Then the contract, and the exit question inside it. You should hold the repository, the cloud and storage accounts and the right to hire another firm. Ask before you build how studies and metadata would be extracted in bulk if you replaced this system, because not being locked into an archive again is most of the reason for doing the work at all.