Build vs Buy: Medical Image Exchange and Vendor Neutral Archive Platforms

Buying wins wherever the network already covers the relationship

An exchange network is worth more than any code you can write for the facilities that are already on it. If your three highest-volume referrers all sit on the same platform you do, studies arrive without a disc, without a courier and without a film library technician, and no custom build improves on that. Pay for membership and stop.

The same logic holds for a single hospital with one picture archiving system, one reading environment and outside studies arriving a few times a week. A cloud exchange service plus a straightforward vendor neutral archive from Sectra or Hyland will serve you, and building infrastructure to solve an occasional problem is a poor use of capital that could go into a reading room.

Buy too if your imaging informatics function is one person. Somebody has to own morphing rules, reconciliation thresholds and retention policy after go-live, and a custom platform with no internal owner degrades into a black box within a year. Products at least come with a support number.

There is one more case for buying that people talk themselves out of. If your organisation is mid-way through consolidating onto a single reading platform, defer. Every downstream filing convention you would encode this year changes when the consolidation lands, and you would be building against a target that moves twice. Join a network, absorb the friction for eighteen months, and start the build from a settled architecture.

And be honest about what your incumbent already does well. Vendor neutral archives all support tag morphing, exchange platforms all offer a reconciliation queue, and both work. The question is not capability. It is who controls the rules and who is awake when the rules need changing.

Building wins at the boundary, which is where the money leaks

It is ten past two in the morning and a trauma transfer is inbound. The referring facility scanned the patient ninety minutes ago. The images are on a disc in a bag or theoretically in a network the referring site may not have pushed to. The receiving team can spend twenty minutes trying to import and reconcile an outside study, or rescan. They rescan. The patient takes a second dose, the health system absorbs the cost, and everyone involved knows it was avoidable.

That gap exists because reconciliation is a human queue that runs during business hours. An outside study arrives carrying the sending institution's medical record number, accession number and naming conventions, and matching it to your patient is the one decision that determines whether the study is useful or dangerous. Build when you want high-confidence matches reconciled automatically against your master patient index, the ambiguous band routed to whoever is genuinely on shift with images viewable, and anything below the lower threshold quarantined so it never touches a chart.

Build when your tag morphing rules are vendor-managed configuration. This is the detail buyers underestimate: when a new referring facility starts sending studies with unfamiliar series descriptions, adjusting the mapping is a service request, and while it sits in a queue the studies file incorrectly and radiologists build workarounds that outlive the fix. A rule set that your own informatics team versions, tests against sample studies and deploys the day a referral relationship starts is a different operating posture entirely.

Build when you run multiple archives after acquisitions and no single view of a patient's imaging exists, and build when outside studies live in a separate viewer that nobody opens during a busy shift. A study that requires a second application is functionally invisible exactly when a prior matters most.

What each path really costs

Exchange services generally price per member site or per study transferred, sometimes both, with the archive priced on stored volume. That structure is fine while your transfer volume is modest and uncomfortable once you become a regional receiving centre, because your bill rises with precisely the activity you were trying to make cheaper. Ask any vendor to quote at double your current study volume before you sign.

On the build side, Digital Heroes delivery experience puts a focused first release at $90,000 to $190,000 shipping in 12 to 20 weeks. That covers multi-channel study intake including discs and network sources, identity reconciliation with an explicit confidence model and an on-shift exception queue, and a tag morphing engine your team controls. A full platform adding worklist injection, routing by service line, retention policy by modality and body region, outbound sharing with authorisation, and legacy archive migration runs $250,000 to $700,000 phased across 9 to 18 months.

Storage and egress are a separate line on both paths and deserve modelling over five years, not one. So does the run rate: 15 to 20 percent of build cost annually covers hosting, monitoring, morphing rule maintenance and interface upkeep. The way to keep the first number down is to start with intake, reconciliation and worklist injection for your top ten referring facilities, which usually covers most transfer volume and produces the repeat imaging reduction that funds everything after it.

The costs that ambush this project

Migration is the one. Legacy archives are never designed to be exited gracefully, and the schedule driver is almost never your new platform. It is the retrieval throughput the old system can sustain while remaining in clinical use. Measure that rate before you commit to a date, because a quoted twelve-week migration against an archive that can only serve a fraction of your daily volume is arithmetic that will not work.

There is a structural conflict of interest in asking your incumbent archive vendor to help you leave, and it shows up as migration services quoted as a modest line item, delivered late, and finished with a residual set of studies nobody can account for. Inventory every study at source before transfer so you know the denominator, verify per study by identifier and image count, and keep an exception register. Anyone who describes migration as a copy has not done one.

The second ambush is master patient index quality. Reconciliation accuracy is bounded by the index you match against, so if your index carries duplicate and overlaid records, budget remediation work that has nothing to do with imaging.

Third, outbound release. Patient-directed sharing adds identity proofing and a support path for people who are not employees, which is a small product in its own right. Information blocking rules also raise the stakes on refusing legitimate requests, so this is not scope you can defer indefinitely.

Fourth, the discs themselves. Small imaging centres still burn media, and those discs carry inconsistent directory structures, occasional missing metadata and study descriptions written by whoever was on the console. A build that assumes clean network transfers will meet reality in its first month. Automated classification has one honest and narrow use here: proposing a modality or body part when the tags are missing or plainly wrong, for a human to confirm rather than to accept silently.

The 2am transfer test

Run this on a real week rather than a hypothetical one. Take every outside study your organisation received in the last seven days and answer four questions.

How many arrived outside business hours, and what happened to them? If the honest answer is that they waited for the film library to open, and some patients were rescanned in the meantime, you have quantified the leak.

How many required a human to decide which patient they belonged to, and how long did that decision take? Anything above a small minority means your matching is manual by default rather than by exception.

How many came from facilities that are not on your exchange network? That share is the part of the problem membership will never solve, and in most health systems it is the majority of transfer volume.

Finally, ask two radiologists how often they open the outside viewer during a shift. If the answer is rarely, then whatever you have bought is not being used, and buying more of it will not change that.

Two uncomfortable answers justify a build scoped to intake and reconciliation. Four justify the full platform, and probably a migration alongside it.

The first two moves

Measure the two numbers that decide everything: your legacy archive's sustained retrieval rate, and the share of inbound studies from non-member facilities. Both are obtainable in a fortnight and both will change the shape of any proposal you receive.

Then interview on specifics. Ask a candidate how they decide a study belongs to a patient, and expect weighted demographic comparison across name, date of birth, sex and available identifiers with an explicit threshold, not exact matching. Ask who owns the morphing rules after go-live, because if the answer is the developer you have recreated the vendor queue with a new logo. Ask what they will do to verify a migration. Ask about DICOM specifically: query and retrieve behaviour, DICOMweb services, study instance identifier handling and the realities of discs burned by small imaging centres.

Digital Heroes runs this work PRD-first, so the confidence thresholds, the quarantine behaviour and the rule ownership model are written and agreed before code exists, which matters in a category where a quiet wrong guess is a patient safety event. The team is 50-plus people across 2,000-plus delivered projects, holds Fiverr Vetted Pro status, and works in public, including a YouTube channel with 2.5 million subscribers. Contracting runs through an India LLP, US LLC or UK LTD so IP assignment sits under your own law. Keep the exchange network for the relationships it covers. Build the layer that handles everyone it does not.

If you want a second opinion before signing anything, Digital Heroes writes a product requirements document before any code exists, so the scope is fixed and priced rather than discovered later at a day rate. You keep the specification either way.