Industry guide · Custom Software

Radiology and Imaging Center Software: Fixing the Gap Between PACS and Your Referrers

The short answer

Build when your study volume and referrer count break the workflow tools, not before. A focused first release for a multi-site imaging group, typically a referrer portal plus an orders and results router sitting on top of your existing PACS and RIS, runs $60k to $130k and ships in 12 to 16 weeks. A full platform covering scheduling, prior fetching, radiologist worklist, structured reporting handoff and billing capture runs $150k to $400k phased across 6 to 12 months. If you are running fewer than roughly 30,000 studies a year from one site with a handful of referrers, stay on your PACS vendor's portal and spend the money on techs instead.

Why imaging workflow software makes or breaks a multi-site radiology group

An imaging center does not fail because the scanner is bad. It fails in the eleven feet between the scanner and the referring physician's inbox. You have Sectra or Merge or Fuji Synapse holding the pixels, PowerScribe holding the reports, an Epic or eClinicalWorks instance at the ordering practice you do not control, a RIS that half your staff has learned to distrust, and a fax server that everyone insists is legacy but that is still the only channel some orthopedic groups will accept a report on. Between those systems sits a person. Usually two or three people. They are the actual integration layer.

The version we hear on nearly every discovery call with a group doing 90,000 to 200,000 studies a year runs like this. It is 4:15pm at your Site 3. A tech finishes an MRI lumbar spine without contrast. The order came in on a paper fax from a spine surgeon's office at 9am, someone keyed it into the RIS by hand and guessed at the CPT because the fax said "MRI back pain, r/o disc." The prior study lives at a hospital eight miles away, so the front desk called for a CD, the CD arrived at noon, someone put it in the import workstation, and the import queue silently failed the DICOM push because the accession number format did not match. The radiologist opens the worklist at 5pm, sees no prior, dictates a read with the caveat "no comparison available," and the report goes out. The surgeon's office calls at 9am the next day asking why there is no comparison to the study they specifically referenced. Now a rad has to re-read, a coordinator has to hunt the CD, and you have burned ninety minutes of the most expensive labor in your building on a data-plumbing failure.

Run your own version of that arithmetic before you talk to anyone about software. Take last year's study volume, the share that hit a prior-fetch or order-intake failure, and the coordinator and radiologist minutes each one burned. Most groups cannot produce the middle number, and that is the actual finding: you are paying people to be a human message bus and you cannot size the bill. Then add the part no system logs at all, the referrer who stopped sending because your turnaround felt unreliable.

Problem 1: Order intake is a fax queue pretending to be a data pipeline

Orders arrive four ways: fax, the referrer's EHR sending an HL7 ORM if you were lucky enough to get an interface built, a PDF emailed by a small practice, and a phone call. Only one of those is structured. The other three become manual entry, and manual entry is where the wrong CPT, the wrong laterality and the missing clinical indication enter your system. Missing indication is the one that costs you: it drives the authorization denial three weeks later, after you have already done the scan.

Your PACS vendor cannot fix this because their product starts at the DICOM boundary. Your RIS cannot fix this because RIS vendors charge per interface and price a bidirectional HL7 build with a mid-size referrer at a level that makes no sense for a practice sending you fourteen studies a month. So the long tail of referrers, which is most of your referrer count and a real slice of your volume, stays on fax forever.

What a custom build does: an intake service that treats every channel as the same object. Fax and PDF go through a document extraction model that pulls patient demographics, ordering provider NPI, body part, laterality, contrast flag and the free-text indication, then maps the indication to a suggested CPT and ICD pair with a confidence score. Anything above your threshold auto-creates the order in the RIS via HL7 ORM. Anything below routes to a human queue with the fax image side by side with the extracted fields, so a coordinator confirms in eight seconds instead of keying for two minutes. Faxed requisitions are the right shape for a model: semi-structured input, a visible failure mode, and a human already sitting in the loop. Across the intake builds we have shipped, auto-accept lands around 70 to 80 percent of faxed orders after four to six weeks of correction feedback, with the rest triaged. The build also gives you something your RIS never will: a per-referrer intake quality score, so you can walk into the spine group's office with data showing how many of their faxes arrive without an indication.

Problem 2: Prior study reconciliation is silently broken and nobody owns it

Priors are where radiologist trust in your systems dies. The patient had a CT chest at a hospital, an MRI at a competitor's center, and a plain film at your Site 1 under a maiden name. Your PACS deduplicates on MRN, which is site-specific. lifeIMAGE, Ambra or PowerShare, if you run one of them, has coverage gaps for exactly the facilities your referrers use most. And when a CD import fails on a tag mismatch, it fails into a log file nobody reads.

Off-the-shelf does not solve this because the master patient index problem is your problem: it lives across your sites, your acquisitions, your legacy PACS from the center you bought in 2021. No vendor will do the identity reconciliation across systems they do not own.

What a custom build does: an MPI service holding a probabilistic match on name, DOB, sex, phone and address across every source, with a confidence band and a human adjudication queue for the small share that land in the gray zone. Every prior-fetch attempt becomes a first-class record with a state: requested, retrieved, matched, failed, reason. That queue surfaces on a dashboard the tech sees at scheduling, not two days later. The rule we implement most often: if a prior is expected and not retrieved 24 hours before the appointment, the system fires a fetch task and pages the coordinator. The measurable outcome is the "no comparison available" rate on your reports, which most groups have never measured because no system reports it.

Problem 3: Results delivery is a per-referrer snowflake you maintain by hand

Every referrer wants results differently. The big orthopedic group wants an HL7 ORU into Epic. The mid-size practice wants a fax. Three surgeons want a text saying the read is done. One neurologist wants a call for anything with an incidental finding. Two practices want the images, not just the report, and their staff cannot use your PACS web viewer, so someone burns a CD.

Your PACS portal exists but referrers hate it, because it makes them log into a fourth system to see one report. Adoption stays under 30 percent at most groups we work with, which means your portal license is paying for a thing your customers do not use, and your staff still fax.

What a custom build does: a delivery router with a per-referrer, per-provider preference record. One report finalizes in PowerScribe, and the router fans it out on the channels that provider actually wants, with delivery receipts. Critical findings get their own path: the rad flags it, the system starts an escalation ladder, text then call then backup contact, and it does not stop until acknowledged, with a timestamped audit trail that survives a malpractice discovery request. Add a lightweight referrer view with no login wall past a magic link, showing report, key images and a one-click "order the follow-up," because the follow-up order is revenue you currently lose to whoever is easier to order from.

Problem 4: Scheduling and authorization leak money nobody is counting

An MRI with contrast that requires prior auth and does not have one is a $1,200 write-off. The patient no-show on a 45-minute MRI slot is roughly $800 of scanner time you cannot resell at 3pm. Your scheduling tool, whether that is the RIS module or something bolted on, does not know your protocol times per magnet, does not know that Site 2's 1.5T runs 20 percent slower on spine protocols, and cannot tell your call center that this specific payer denies this specific CPT without a documented six weeks of conservative therapy.

What a custom build does: a scheduling engine that carries protocol duration per modality per site, a payer rules table your authorization team edits directly instead of filing a ticket with a vendor, and an auth status that blocks confirmation until it clears or a manager overrides with a reason. Two AI jobs pay for themselves here. First, after-hours booking: a voice and SMS agent that takes a call at 8pm, verifies identity, reads real slot availability from the same engine, and books, with a hard handoff to a human on anything involving contrast allergy, implants or pediatric cases. Second, no-show risk scoring on prior behavior, distance, appointment lead time and modality, used to drive reminder intensity and overbook decisions on the specific slots that justify it. Do not let anyone sell you AI protocol selection unless a radiologist signs off on every one.

What this costs and what drives it up

Across 2,000-plus projects, Digital Heroes sees this category land in two bands. A focused first release, which for imaging is almost always intake plus delivery routing plus the referrer view sitting on top of your existing PACS and RIS, runs $60k to $130k and ships in 12 to 16 weeks. A full platform adding MPI and prior orchestration, scheduling with auth rules, radiologist worklist and billing capture runs $150k to $400k phased over 6 to 12 months.

What pushes you toward the top of the band in this category specifically: the number of distinct HL7 endpoints you need on day one, since every referrer EHR interface has its own quirks and its own IT department that answers in three weeks; a legacy PACS from an acquired site that speaks a dialect of DICOM query and retrieve that predates your CTO; HIPAA and any state-level requirement that forces separate infrastructure, audit logging and a BAA chain across every subprocessor including your AI provider; and the volume of historical data you want migrated versus left in place behind a read-only bridge. That last one is the cheapest lever you have. Migrating six years of studies is a project. Bridging to them is a sprint.

Build versus buy: the honest line

Buy if you are single-site, under roughly 30,000 studies a year, with under 40 active referrers and no acquisition pipeline. Your PACS vendor's portal, your RIS scheduling module and a good fax server will serve you, and the money is better spent on a second tech. Buy also if your entire referrer base is one hospital system on one EHR: build the interface, take the win, go home.

Build when three signals show up together. One: you have two or more sites on systems that do not share a patient index, so someone is reconciling identities by hand. Two: you have more than one full-time person whose actual job is retyping orders and faxing results, which at your own fully loaded cost is the salary line you should be holding the build quote against. Three: you are buying centers, and every acquisition means another PACS to integrate, which means the integration layer is your permanent business, not a one-time project. If all three are true, the off-the-shelf stack is not saving you money. It is converting your software budget into a headcount budget and hiding it in operations.

How to choose a developer for radiology and imaging software

Ask them to explain the difference between an ORM and an ORU and where an MWL sits in the flow. If they need to look it up on the call, they will learn HL7 on your budget. The people who have shipped this speak it without thinking.

Ask what they do when a DICOM C-FIND returns a study the PACS will not release on C-MOVE. There is no single right answer, but there is a real answer involving AE title configuration and vendor negotiation, and it only comes from someone who has been stuck there at 11pm.

Ask for their patient-matching approach before you ask for a price. If the answer is "match on MRN," they have not worked multi-site. If they talk about probabilistic matching, confidence thresholds and a human adjudication queue, they have.

Ask who owns the code, the repository and the infrastructure accounts on day one, and get the BAA chain in writing covering every subprocessor including whichever model provider touches your intake documents. In this category, the vendor who will not sign that or will not hand you the repo is not selling you software. They are selling you 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. McKinsey argues software developer productivity can be measured by combining system-level metrics (DORA and SPACE) with its own outcome-oriented approach, which it reports deploying across nearly 20 tech, finance, and pharmaceutical companies - a claim that sparked significant debate in the engineering community. Source: McKinsey & Company (2023) →
  2. 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) →
  3. The global point-of-sale terminal market is projected to reach approximately $181.47 billion by 2030, growing at an 8.1% CAGR from 2025 to 2030, driven by digital payment adoption and demand across retail, restaurant, and hospitality sectors. Source: Grand View Research (2025) →
  4. SMS reminders that stated the specific cost of the appointment to the health system reduced missed appointments in Trial One, with the DNA (did-not-attend) rate falling from 11.1% (control) to 8.4% (specific-costs message) - an odds ratio of 0.74 (95% CI 0.61-0.89), i.e. roughly a 24-26% relative reduction - at no additional cost. (Trial Two replicated this at an 8.2% DNA rate.). Source: PLOS ONE (Hallsworth et al.) (2015) →
Rohan Malhotra · Enterprise Software Consultant

Rohan advises mid-market and enterprise teams on ERP, CRM and custom software, and has led delivery on dozens of business-software builds.

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

FAQ

Frequently asked questions

How much does custom radiology imaging center software cost for a group doing 150,000 studies a year?
A focused first release, usually order intake plus results routing plus a referrer view on top of your existing PACS and RIS, runs $60k to $130k over 12 to 16 weeks. A full platform adding patient matching, prior orchestration, scheduling with authorization rules and billing capture runs $150k to $400k phased over 6 to 12 months. At your volume the main cost driver is the number of distinct referrer EHR interfaces you need on day one, not the study count itself.
Should we build custom software or just use the portal that came with our PACS?
Use the vendor portal if you are single-site with under roughly 30,000 studies a year and a small referrer base. Build when you have multiple sites without a shared patient index, more than one full-time person whose job is retyping orders and faxing results, and an acquisition pipeline that keeps adding new PACS to integrate. Vendor portals typically stay under 30 percent referrer adoption in the groups we work with, because they force referrers into a fourth login, so your staff keeps faxing anyway.
Can custom software integrate with Epic, eClinicalWorks and our existing Sectra or Merge PACS, or do we have to replace them?
You do not replace them. The right build sits on top: HL7 ORM in from referrer EHRs, HL7 ORU out with results, DICOM C-FIND and C-MOVE against the PACS, and a document extraction path for the fax and PDF orders that will never have an interface. The PACS keeps the pixels, PowerScribe keeps the reports, and the RIS keeps the system of record. The custom layer owns the routing, the matching and the referrer experience.
How long does it take to ship the first useful version?
Twelve to sixteen weeks for a focused first release, assuming your PACS vendor and at least one referrer IT contact respond within a normal timeframe. The single biggest schedule risk in this category is not development, it is waiting on a referrer's IT department to configure their side of an HL7 interface, which routinely takes three weeks per endpoint. Sequence the build so intake and fax extraction go live before the interfaces land.
Do we own the code if we pay a firm to build this?
You should own the code, the repository and the cloud infrastructure accounts from day one, and it should be in the contract before the first sprint. In this category also require a written BAA chain covering every subprocessor, including whichever AI provider processes your faxed orders. A vendor who will not hand over the repo is selling you a subscription with extra steps.
How does HIPAA compliance work for custom imaging software with AI document extraction?
PHI never leaves infrastructure you control without a signed BAA, and that includes the model provider reading your faxed orders. Practically this means encryption at rest and in transit, per-user audit logging on every study view, role-based access down to the site level, and a documented data retention and deletion policy. The AI extraction path needs its own audit trail showing what was extracted, what confidence it had, and which human confirmed it.
Where does AI actually help an imaging center, versus where is it just a sales pitch?
It helps in three places: extracting structured orders from faxed and emailed requisitions with a human confirming anything below a confidence threshold, after-hours voice and SMS booking against real slot availability, and no-show risk scoring to drive reminder intensity and overbooking. It is a sales pitch when someone offers AI protocol selection or autonomous reading without radiologist sign-off. The rule is simple: AI where the failure is visible and a human is already in the loop.
What do we do about our old PACS from the center we acquired?
Bridge to it, do not migrate it, at least not first. Migrating six years of studies out of a legacy PACS is its own project with its own budget, and it usually delivers nothing your referrers can feel. A read-only query and retrieve bridge behind your patient-matching layer gets you the priors within a sprint or two, and you can decide about full migration once the new platform is carrying live volume.
Our biggest problem is missing priors. Can software actually fix that or is it a staffing issue?
The staffing pain is downstream of a data problem. Missing priors usually trace to patient identity not matching across sites and to CD or image-share imports failing silently into a log nobody reads. The fix is a master patient index with probabilistic matching and a human adjudication queue, plus making every prior-fetch attempt a tracked record with a state and a reason for failure, surfaced to a coordinator 24 hours before the appointment rather than discovered by the radiologist at read time.
How do I calculate whether custom software will pay for itself?
Divide the build cost by the monthly benefit, where benefit is hours saved times loaded hourly cost, plus subscription fees replaced, plus any revenue the software unlocks. Three staff saving 10 hours a week each at a $40 loaded rate is about $62,000 a year, which pays back a $60,000 build in roughly 12 months. Across Digital Heroes internal-tool projects, 12 to 24 months is the normal payback range, and anything projecting under 6 months usually means the spreadsheet is hiding costs.
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 hire a freelancer or an agency for my software project?
A skilled freelancer is the right call for a single-discipline scope under roughly $15,000, like a website, a plugin, or one integration. Above that, projects need design, backend, testing, and project management at once, and a solo builder becomes the single point of failure: if they get sick or take a bigger client, your project simply stops. Agencies bill 20-40% more per hour but carry continuity, code review, and someone to escalate to, which is what you are actually buying.
How many people should be working on my software project?
A typical $40,000 to $150,000 build runs on three to five people: a technical lead, one or two developers, a designer, and someone owning QA and project communication, often as overlapping part-time roles. More bodies do not make software arrive faster; past a point they slow it down with coordination overhead. The question that matters more than headcount is whether one named senior engineer is accountable for the outcome.
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.
Will custom software work with the tools we already use, like QuickBooks and Stripe?
Yes, and this is one of custom software's genuine advantages: QuickBooks, Stripe, Shopify, and most mainstream business tools publish documented APIs built for exactly this. Expect each standard integration to add one to two weeks of build time, and be suspicious of any quote that lists five integrations without asking what data flows in which direction. The hard cases are legacy systems with no API, which is a question to raise in discovery, not in week nine.
How many SaaS seats do we need before building custom becomes cheaper?
The crossover usually shows up between 20 and 50 seats on premium tiers. Salesforce Enterprise lists at $165 per user per month, so 40 users cost about $79,000 a year in subscriptions, which is real money against a custom system you would own outright. Run the comparison over three years: if subscription spend beats the build cost plus 15-20% annual maintenance, custom wins on price before you even count workflow fit.
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?