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

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.

If you would rather scope this before committing budget, Digital Heroes has delivered more than 2,000 projects with a named team you can speak to before you sign, rather than a bench you meet in month two. Nothing about that commits you to the build.