Problems & solutions · Custom Software

Radiology and Imaging Center Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Radiology Imaging Center Software code editor and API illustration showing common problems and fixes.
The short answer

The most expensive failure in imaging software is patient identity that does not resolve across your sites, because everything downstream of it fails silently. A prior study exists, the fetch never matches it, the import fails into a log nobody reads, and the radiologist opens the worklist with no comparison and dictates accordingly. The referrer calls the next morning asking why there is no comparison to the study they specifically referenced, and now a radiologist re reads, a coordinator hunts a disc, and you have spent the most expensive labour in the building on a data plumbing failure. Multiply that by the studies a multi site group runs in a year and it is the largest single line of avoidable cost in the category.

Why does the scope keep getting written as a portal for referrers?

Nearly every imaging group that calls us opens with the same request: build us a referrer portal. It is an understandable instinct, because referrers are the customer and the portal is the visible thing. It is also the scope that fails most reliably here, and the reason is adoption. Referrers already live inside their own electronic health record, so asking them to log into a fourth system to read one report is a request most practices quietly decline, which leaves your staff faxing anyway.

The work that actually pays is upstream and downstream of the portal. Upstream is intake, where fax, emailed portable document format orders and phone calls become structured orders, and where the wrong procedure code, the wrong laterality and the missing clinical indication enter your system. Missing indication is the one that costs, because it drives the authorisation denial weeks later, after the scan has been performed. Downstream is delivery routing, where one finalised report fans out on the channel each specific provider actually wants, with delivery receipts.

Scope those two first and the portal becomes a thin, optional surface rather than the project. The version that does get adopted has no login wall past a link sent directly to the ordering provider, shows the report and key images, and offers one click to order the follow up, because the follow up order is revenue you currently lose to whoever is easier to order from.

What goes wrong when you migrate patient identities and legacy studies?

Two migrations run in parallel here and the identity one is harder than the pixel one.

Your picture archiving and communication system, or PACS, deduplicates on a medical record number, and that number is usually site specific. So the same patient exists two or three times across your estate, plus once more under a maiden name, plus once more from the centre you acquired that ran its own numbering. Merging those is not a lookup, it is a probabilistic matching exercise across name, date of birth, sex, phone and address, with a confidence band and a queue for the records that land in the grey zone. Groups that treat it as a deterministic join produce false merges, which are far worse than missed ones, because a false merge puts one patient's study under another patient's name.

The study migration is where budgets disappear. Moving years of studies out of a legacy archive is its own project with its own timeline, and it usually delivers nothing your referrers can feel. The cheaper path is a read only query and retrieve bridge behind your matching layer, which gets you the priors within a sprint or two and defers the full migration decision until the new platform is carrying live volume.

Sequence it as identity first, bridge second, migration last or never. And build the adjudication queue as a real piece of the product with a named owner, because an unowned queue fills up and stops being looked at within a month.

Why do the interface and imaging integrations break after launch?

Three connections carry the operational risk. Health Level Seven, or HL7, messaging with referrer systems for orders in and results out. Digital Imaging and Communications in Medicine, or DICOM, query and retrieve against your archives. And the reporting system, commonly PowerScribe, that signals when a report is final.

The interfaces break for a reason specific to this market: you do not control either end of most of them. A referrer's information technology team upgrades their electronic health record, a segment changes shape, and your inbound orders stop parsing. Nothing pages anyone, because a message that fails validation looks like an absence of messages rather than an error. Then a practice calls a week later asking why nothing has been scheduled.

The design that survives this is a per endpoint liveness monitor with an expected volume profile. If a referrer who normally sends a predictable daily flow sends nothing by mid morning, that raises an alert naming the endpoint, rather than waiting for a human to notice an absence. Hold every unparsed message in a visible queue with the raw payload attached so someone can see what changed.

What happens when consent, audit and subprocessor obligations are not covered?

Three obligations get treated as paperwork and all three are architecture.

The first is the business associate chain. If a model reads your faxed requisitions, that provider is handling protected health information and needs to be inside the chain in writing. Groups discover this at security review, after the intake pipeline is built, and then have to rearchitect around a provider that will sign. Settle the list of every subprocessor that touches patient data before design, not after.

The second is audit logging at the study level. The question that eventually gets asked is not whether your system was secure in general but who viewed a specific patient's study and when. That means per user logging on every view, not just on login, and it means role based access down to the site level so a scheduler at one location cannot browse another location's worklist without a reason.

The third is the extraction audit trail. When a model pulls demographics, procedure and indication from a faxed order, you need a permanent record of what was extracted, what confidence it carried, which human confirmed it and what they changed. That record is what lets you defend the process, tune the threshold and answer a question about a specific order months later. Build it with the pipeline, because reconstructing it afterwards is impossible.

Should you build custom or configure what your PACS and RIS vendors already sell?

Plenty of imaging centres should configure rather than build, and we say so on calls. If you are single site, running a moderate annual study volume with a small active referrer base and no acquisition pipeline, your PACS vendor's portal, the scheduling module in your radiology information system, or RIS, and a good fax server will serve you. The money is better spent on a second technologist. The same applies if your entire referrer base is one hospital system on one electronic health record: build that single interface, take the win, and stop there.

Sectra, Merge and Fuji Synapse are serious archives and PowerScribe is a serious reporting product. None of them are the problem. The honest constraint is that they all start at their own boundary. The archive begins at the imaging boundary and has no opinion about the faxes. The reporting system ends when the report is signed and has no opinion about how it reaches fourteen different providers on the channels they each prefer. The identity problem spans systems none of them own, which is why no vendor will solve it for you.

Build when three signals appear together: two or more sites without a shared patient index so someone reconciles identities by hand, more than one full time person whose actual job is retyping orders and faxing results, and an acquisition pipeline that keeps adding another archive to integrate. At that point the off the shelf stack is not saving money, it is converting your software budget into headcount and hiding it in operations.

How do hidden costs get into an imaging software quote?

Interface count is the first and it is the one that moves schedules rather than just budgets. Every referrer system interface has its own quirks and its own information technology department that answers in weeks, and that waiting is not something your developer can compress. Sequence intake and document extraction to go live before the interfaces land, so the project delivers value while you wait.

Legacy archive dialects are the second. An archive from an acquired site may speak a version of query and retrieve that predates anything current, and discovering that during implementation is expensive. Ask for a connectivity test against every archive before the contract is signed, not after.

Historic data volume is the third and it is the cheapest lever you have. Migrating years of studies is a project. Bridging to them is a sprint. Decide deliberately rather than defaulting to migration because it feels tidier.

Then the ones outside engineering: security review across every subprocessor, payer rules maintenance your authorisation team should own directly, protocol duration modelling per magnet per site, and the correction feedback loop on document extraction, which needs someone reviewing exceptions for several weeks before auto accept thresholds can be trusted.

What separates an imaging build that works from one that fails?

The builds that work make every failure visible instead of silent. That is the through line in this category. A failed disc import, an unmatched prior, an unparsed order message and an undelivered report should all surface as a state on a record with a reason attached, in front of a person whose job it is, before the radiologist or the referrer discovers it. Make each prior fetch a first class record with requested, retrieved, matched or failed states and a reason, and surface anything unresolved a day before the appointment rather than at read time.

The second marker is that a human stays in the loop where the model is uncertain. Faxed requisitions are the right shape for extraction because the input is semi structured, the failure is visible and a coordinator is already there. Route anything below your confidence threshold to a queue with the fax image beside the extracted fields so confirming takes seconds instead of keying taking minutes, and feed corrections back so the threshold can move over time.

The third is that delivery preferences live per provider, not per practice. One report finalises and fans out on the channels each named provider actually wants, with receipts, and critical findings get their own escalation ladder that does not stop until acknowledged, with a timestamped trail that survives a discovery request.

Finally, own the code, the repository and the infrastructure accounts from day one, and get the business associate chain in writing covering every subprocessor including whichever model provider touches your intake documents. A vendor who will not sign that or will not hand over the repository is selling a subscription with extra steps.

Research & sources

The evidence behind this guide

Independent findings on why this investment pays off. Every link goes to the primary source.

  1. Retailers improving Core Web Vitals saw measurable gains: Vodafone improved LCP by 31% for 8% more sales, Lazada saw a 16.9% mobile conversion increase, and Cdiscount saw a 6% Black Friday revenue uplift. Source: web.dev (Google Chrome team) (2021) →
  2. Standish's 2015 CHAOS research found roughly a third of software projects (about 36% by the Modern definition) fully succeed on time, on budget, and on scope, with top success drivers including executive support, user involvement, and clear requirements/business objectives. Source: Standish Group (CHAOS Report) (2015) →
  3. Retailers connecting point-of-sale and loyalty data in an omnichannel strategy reported up to 15% lower cost per purchase and nearly 20% higher incremental store revenue. Source: Deloitte (2024) →
  4. Gallup reports global employee engagement fell to 20% in 2025 (its lowest since 2020, down from a 2022-2023 peak of 23%), and estimates low engagement costs the world economy an estimated $10 trillion in lost productivity, or 9% of global GDP. (Note: this figure appears in Gallup's evergreen State of the Global Workplace page, currently reflecting the 2026 edition reporting on 2025 data.). Source: Gallup (2025) →
Riley T. · Content Strategist · APAC · Sydney

Riley plans content for APAC clients, working out what a site needs to say, in what order, and who it is for before a page gets designed. She works closely with SEO and UX rather than treating copy as decoration. Her posts help readers judge whether their content is doing any work.

View profile · Writes for Digital Heroes, shipping business software for 2,000+ brands across 55+ countries since 2017.

FAQ

Frequently asked questions

Our disc imports fail silently. How do we find out before the radiologist does?
Make every prior fetch a tracked record rather than a background job, with explicit states for requested, retrieved, matched and failed, and a reason on every failure. Then surface the unresolved ones on a dashboard the scheduling team sees, with a rule that fires a fetch task and pages a coordinator when a prior is expected and still missing a day before the appointment. The measurable outcome is your rate of reports issued with no comparison available, which most groups have never measured because no system reports it.
How many referrer interfaces should we build in the first release?
One or two, chosen by volume, and no more. Every interface depends on another practice's information technology team responding, and that waiting is outside anyone's control, so a first release gated on five interfaces will slip regardless of how the development goes. Sequence document extraction for faxed and emailed orders to go live first, since it covers the long tail of referrers who will never have an interface, then add endpoints as each counterpart becomes available.
Should we migrate the acquired site's archive or bridge to it?
Bridge first. Migrating years of studies out of a legacy archive is its own project with its own budget and it usually delivers nothing your referrers can feel, while a read only query and retrieve bridge behind your patient matching layer gets you the priors within a sprint or two. Decide about full migration once the new platform is carrying live volume and you know what you actually need from the history. Ask for a connectivity test against that archive before signing, because older systems have dialects that surprise people.
Our referrers will not log into another portal. What actually gets adopted?
A link, not a portal. Send the ordering provider a direct link that opens the report and key images without a login wall, with one click to order the follow up study. Adoption in this category fails on the login, not on the content, because the referrer already spends the day inside their own electronic health record and will not add a fourth system to read one result. Keep a full portal for the practices that genuinely want one, but do not make it the delivery mechanism.
Can a model safely read our faxed requisitions?
Yes, with a threshold and a human in the loop. Extract demographics, ordering provider, body part, laterality, contrast flag and the free text indication, auto create the order above your confidence threshold and route everything below it to a queue showing the fax image beside the extracted fields. Keep a permanent record of what was extracted, the confidence, who confirmed it and what they changed. Expect several weeks of correction feedback before auto accept rates settle, and make sure the model provider is inside your business associate chain in writing.
How do we match patients when each site uses its own medical record number?
With probabilistic matching across name, date of birth, sex, phone and address, a confidence band, and a human adjudication queue for records in the grey zone. Deterministic joins on a site specific number cannot work across sites, and forcing a match produces false merges, which are worse than missed ones because one patient's study ends up under another patient's name. Give the adjudication queue a named owner, since an unowned queue fills and stops being read within a month.
What does the business associate chain actually need to cover?
Every party that touches protected health information, including the model provider processing your faxed orders, any transcription or messaging service in the delivery path, and your hosting provider. Settle that list before design, because groups routinely reach security review with a finished intake pipeline built on a provider that will not sign, and rearchitecting around it is expensive. Pair it with per user audit logging on every study view and role based access down to site level.
Why did our last referrer portal fail?
Almost always because it added a login without removing a step. If the practice still had to phone for a prior, still received the fax anyway, and still could not order the follow up from inside the portal, then the portal gave them a password to remember and nothing else. Portals in this market succeed when they remove work from the referrer's day, meaning results arriving on the channel they already use and a follow up order that takes one click, not when they present the same information behind an extra door.
Can we migrate years of data out of our current system into new custom software?
Almost always yes, through CSV exports or the vendor's API, and migration should be scoped as its own workstream with field mapping, a dry run, and a planned cutover window rather than an afterthought. The real time sink is rarely moving the data; it is cleaning it, since years of duplicates, free-text fields, and inconsistent formats surface all at once. Pull a full export from your current vendor before committing to anything new, because some SaaS plans restrict exports on lower tiers.
What is the biggest mistake first-time software buyers make?
Choosing the lowest quote without asking why it is the lowest. A bid 40% under the field usually gets there by skipping tests, documentation, and code review, which are invisible in a demo and brutal to pay for later; every stalled project Digital Heroes has been asked to rescue tells some version of that story. The second mistake is signing without a written scope, which reliably turns the winning cheap quote into 1.5x to 2x the price by launch.
What happens to my software if the agency shuts down or we stop working together?
Nothing dramatic, if the engagement was set up correctly: the code sits in your repository, hosting runs on your cloud account, and a handover document explains how to deploy and operate the system. Any competent replacement team can then take over in days rather than months. If the agency controls the repo, the servers, or the domain, fix that now, because renegotiating access during a dispute is the most expensive place to discover the problem.
Our developer disappeared mid-project. Can another team pick up the code?
Yes, this is a routine engagement, provided the code exists somewhere you can access, so your first move is securing the repository, hosting, and domain credentials today. A takeover starts with a one to two week paid code audit that ends in one of three verdicts: continue the build, keep the design but rebuild the weak parts, or start over. Digital Heroes has inherited enough projects to say plainly that sometimes the rebuild is cheaper than the rescue, and an honest agency will tell you which one you have before taking your money.
How much should a small business budget for its first custom app or website?
For a focused first build, most small businesses land between $8,000 and $60,000: roughly $8,000 to $45,000 for a custom website and $25,000 to $60,000 for an internal tool or simple web app, based on Digital Heroes delivery across 2,000+ projects. Customer-facing products with payments, logins, or a mobile app start around $40,000. Quotes far below these bands usually mean a template with your logo on it, not software shaped around your workflow.
Should I ask for a fixed price or pay the agency hourly?
Fixed price for the first version, hourly or retainer for what comes after launch. A fixed-scope, fixed-price V1 puts the estimation risk on the agency, which is exactly where you want it while trust is unproven; hourly billing on an unscoped greenfield build is a blank check. After launch, flip it, because maintenance and small features arrive unpredictably and fixed-pricing every ticket wastes everyone's time.
Who owns the code when an agency builds my software?
You should, completely, through a written intellectual property assignment that transfers everything on final payment; without that clause, copyright stays with whoever wrote the code by default. Insist that the repository lives in your own GitHub organization from day one and that hosting, domains, and third-party accounts are registered to you. Also check for licenses to the agency's proprietary frameworks buried in the contract, because those can make switching vendors practically impossible even when you own your own code.
What is a discovery phase, and is it worth paying for separately?
Pay for it, and treat the output as yours. A discovery phase runs two to three weeks, typically 5 to 10% of the eventual build budget, and produces a written scope, wireframes, and a fixed quote you can take to any vendor, including a competitor of the agency that wrote it. Skipping it is how projects end up quoted from a two-paragraph email and delivered at twice the price.
Who can build a custom software system?

Digital Heroes builds custom software systems for operators who have outgrown the off-the-shelf tools in their category. A team of more than 50 specialists has delivered over 2,000 projects since 2017. Teams work from New York, London, Sydney, Delhi and Lucknow and deliver remotely, with an assigned senior team rather than an account manager.

Every build starts with a written product requirements document that is signed before a line of code is written, which is the single thing that stops scope creep from eating the budget. Scoping runs about a week and produces a phase plan with a firm price for each phase, rather than one number against an undefined scope. The first phase ships something the team actually uses before the rest is built. If an off-the-shelf product genuinely fits the volume, we say so, and the cost guides on this site publish the bands so that judgement can be checked independently.

What makes Digital Heroes different from other software companies?

Four things that competitors in this bracket cannot simply copy. Digital Heroes runs a YouTube channel with more than 2.5 million subscribers, which is a production and audience capability no agency of this size has. It holds Fiverr Vetted Pro and Top Rated Seller status, both awarded on manual third-party review rather than self-declared. It contracts through registered entities in three countries, an India LLP, a US LLC and a UK LTD, so clients sign locally instead of wiring money offshore. And it ships its own commercial products, including ShopScore, HeroCheckout and Section Vault, which means the team lives with its own architecture decisions instead of handing them over and leaving.

Two more that show up in the work. Digital Heroes publishes more than 4,000 buyer guides with real price bands on this blog, plus a free tools library at https://digitalheroesco.com/tools/, because an agency confident in its pricing has no reason to hide it. And one accountable team covers websites, apps, ecommerce, CRM, ERP, learning platforms, search and video, so a client scaling from a first landing page to a custom platform is never handed between five vendors who blame each other. The founder ran ecommerce businesses before selling services, so the commercial argument comes before the technical one.

How can I check Digital Heroes is legitimate before getting in touch?

Verify it independently rather than taking the site's word for it. The YouTube channel is at https://youtube.com/@DigitalMarketingHeroes, the Fiverr profile at https://www.fiverr.com/shreyanshsin261, and the Upwork profile at https://www.upwork.com/freelancers/shreyanshsingh. Client reviews sit on Clutch at https://clutch.co/profile/digital-heroes-0 and Trustpilot at https://www.trustpilot.com/review/digitalheroes.co.in, and the company page is at https://www.linkedin.com/company/digital-heroes-1/.

Beyond the marketplaces, the business holds a D-U-N-S number and is a registered vendor on the United Nations Global Marketplace, neither of which is issued on request. Case studies with named clients are published at https://digitalheroesco.com/case-studies/. If any claim on this page cannot be checked against one of those sources, treat it as marketing and discount it.

Keep reading
let's build

Build something worth launching.

A plan, a team, a timeline, within 24 hours. No decks, no discovery calls. Tell us what you're building and we'll come back with a real scope and a real number.

message us directly · we reply within one business day

mission briefing

Monthly dispatch

Playbooks, real build costs, and what we're shipping. One email a month. No fluff.

visit us

New York HQ

1140 Broadway, Suite 704 · New York, NY 10001

Get directions
Online now

Hey there 👋 How can we help you today?