How do you evaluate a teleradiology provider?

What should your team decide before the first vendor call?

Decide what you are buying before anyone shows you a worklist. Count your studies by modality, body region, hour of day and site. Write down the clinical questions your referrers actually ask. Name the work that will never leave the building. That inventory becomes the measuring stick for every proposal you receive.

Plenty of bad teleradiology contracts start with a good demo. The buyer arrives without a study inventory, watches a clean interface, and ends up negotiating over features instead of over work. Pull twelve months of exam data first and break it down by modality, body region, ordering location, day of week and hour. Look at where the volume concentrates and where it is thin, because a service that handles your Tuesday afternoon comfortably may be the wrong shape for a Saturday at two in the morning. Then look at what your referrers want. An orthopedic group and an emergency department expect different things from the same knee MRI, and only one of those expectations shows up in a modality list.

Write your exclusions down too. Some work stays in house because a physician has to be present or a procedure needs supervision. Some stays because your own radiologists want to keep it, which is a different reason and worth naming as one. Being explicit protects the relationship later. A vendor who learns in month three that a large share of the projected volume was never on the table will re-price, and that conversation goes worse than the one you could have had in week one. The same applies to volume you cannot promise. If a referring group is up for renewal, or a second scanner is only a budget request so far, put that in the document you hand the vendor rather than in the optimistic number at the top of the page.

• Volume by modality, body region, site and hour of day, taken from twelve months of real data.
• The clinical questions your referring services ask most often, in their own words.
• The studies that stay in house, and the reason for each one.
• Peaks, overflow, holidays and the months you are short staffed.
• Which prior studies exist, where they live, and whether they can be retrieved.

How do you confirm who is actually allowed to read your studies?

Ask for the reader roster that would cover your site, not the company headcount. For each name you want current licensure in your jurisdiction, board status, the privileging path through your medical staff, and malpractice coverage. Then ask what happens at three in the morning when the approved reader for that subspecialty is unavailable.

A vendor's total headcount tells you little. What matters is the subset of readers licensed where your patients are, privileged at your facility or eligible through your medical staff process, and acceptable under whatever rules apply to your payer mix. That subset is always smaller than the published figure, and it shrinks further once you filter by subspecialty and by hour. Ask for it in writing. Ask how long privileging takes at your own organization, because your medical staff office is often the bottleneck, and a go live date can slide by months on credentialing alone while everyone in the room blames the vendor.

Subspecialty routing deserves the same skepticism. A long list of specialties on a website means somebody on the roster has that background. It does not mean the routing rules send your pediatric ultrasound to that person, or that the person is awake when the study lands. Ask to see the routing logic. Ask what the system does when the preferred reader is unavailable: does the study wait, fall back to a generalist, or sit in a queue nobody owns? Then find out who maintains those rules once you are live, because a routing table that nobody has revisited since implementation drifts as your case mix changes.

There is one more question people forget. Who reviews the study when your own radiologist disagrees with the report? A second read inside the same vendor is not independent, and if your medical staff bylaws treat a discrepancy as a peer review matter, you need to know whose process governs. Ask whether the vendor will take part in your review, what they will share, and whether their own contract permits it. Some agreements quietly leave the reader with no obligation to your quality committee at all, and you will not find that clause by reading the service description. Settle it before you sign, not during your first serious disagreement.

What does the integration actually cost, and who does the work?

Budget for three connections, not one: images out, the order across, the report back. The vendor builds their side at no visible charge. Your interface engine team bills by the interface and schedules well ahead. The real cost is those engineering hours plus the testing your own staff has to do, and almost nobody budgets the testing.

Here is where projects go sideways. The image path is the easy one: a DICOM send from your PACS or your modality to their endpoint, usually over a VPN or a broker appliance. The order is the second path and it is quieter. If you want the reader to see the ordering question, the priority and the history, that information has to travel with the study or arrive alongside it, which usually means a worklist feed somebody has to build. The report path is the third. The result has to file against the correct order in your RIS or EHR, so the accession number, the order identifier and the patient identifier all have to survive the round trip intact.

If a result returns with an accession that does not match, the message fails and drops into an error queue inside your interface engine. Somebody has to look at that queue. Often that somebody is a single analyst, and when the analyst takes a week off, reports quietly stop filing. The second failure is worse because it makes no noise. A network change, an expired certificate or an edited routing rule stops studies from reaching the vendor. Your modality marks the send as complete. The vendor's worklist shows only what arrived. Nobody compares the two, so nothing alarms until a technologist notices a study days later with no report on it. Ask it directly in the RFI: who reconciles sent against received, how often, and what triggers a call to a human? If the answer is vague, that gap is now yours.

Bring the third party in early. Interface engine work is done by your integration team or an outside consultant, and their calendar rarely has room next week. Get a written estimate of engineering hours and a slot on that calendar before you commit to a go live date. Ask for the interface specification before signature rather than after, and have your analyst read the whole thing. That one document tells you more about a vendor than the demo does. If they will not release it before signature, treat the refusal as information about how the rest of the relationship will run. Ask as well which of your staff has to sit on the test calls and for how many hours, then tell those people now instead of the week before cutover.

How should turnaround and critical findings be written into the agreement?

A clock needs a named start event, a named stop event, a time zone and a written list of what pauses it. Urgency labels need definitions that two different organizations apply the same way. For a critical finding, name the recipient and the backup, decide how acknowledgement is recorded, and write the rule for when nobody answers.

Routine, urgent and STAT are not standardized terms. They mean whatever your agreement says they mean, and if the agreement is silent, the two organizations will discover their disagreement on a bad night. Fix the start event: is it when the last image lands, when the study appears on the worklist, or when a reader opens it? Those moments can be far apart when the network is slow or when a study arrives without its order. Fix what happens to the clock when the exam is incomplete, when history is missing, or when the facility changes the priority after the fact. Those exclusions are where reported performance and lived experience separate.

A critical finding is a separate process, not a faster report. A finding that needs a phone call needs a person on the other end of the phone. Ask who the vendor calls at your site overnight, what they do when that number rings out, how long they keep trying, who the second contact is, and what gets documented. Then ask what happens when your phone system is down. If the answer is that they send an email, you have found a gap. Test the escalation path during onboarding with a drill that carries no clinical data, and test it again every time your call schedule changes.

What do you ask about quality review, support and getting your data back?

Ask how a discrepancy is found and who reviews it. Then ask what the vendor does with the outcome, and whether any of it comes back to your quality office. Pin the support model to specifics: a number a person answers, and a named contact who is not a shared inbox. Before you sign, ask what happens to your images, reports and audit logs on the day you leave.

Quality questions attract soft answers, so make them concrete. How does a discrepancy reach the vendor, and how does the outcome reach you? Is there a peer review process, and does it produce anything your quality office can see, or does it disappear into an internal committee? If your medical staff runs ongoing professional practice evaluation, the vendor's readers may have to fit into it, which means data has to come back in a usable form. Ask what that report looks like, how often it is produced and who signs it. Ask for a sample with the identifiers stripped out.

Downtime is the other soft spot. Systems fail, and the question is not whether the vendor has redundancy but what your staff does at two in the morning with an empty worklist and studies stacking up. There should be a documented alternate route, a number a human answers, and an agreed way to move urgent work while the primary path is down. Ask how you will be told an outage has started rather than discovering it yourself. Ask about planned maintenance windows and whether they fall in your busiest hours, because a vendor whose maintenance window is your Sunday overnight is a poor fit for a trauma center.

Exit terms belong in the first draft, not the renewal. Your studies and reports are your records. Establish who holds copies, in what format they come back, how long the return takes, what it costs, and what becomes of the audit logs and any cached images on the vendor's side. Ask whether the data returns as DICOM objects and structured reports or as a pile of PDFs, because that difference decides whether the next provider can use it. Ask how long the vendor keeps your data after termination and whether deletion is confirmed in writing. If a subcontractor holds any part of it, that name belongs in the agreement.

What should a good RFI ask for, and how do you run a pilot?

A good RFI asks for documents and names, not adjectives. Request the interface specification, the escalation procedure, a sample quality report, the downtime plan and the exit clause. Then run a pilot on a bounded slice of work, with a fixed end date and measures you defined before day one.

Too many RFIs ask questions any vendor answers well. Rewrite yours so the answer is either a document or a name. Instead of asking whether the service is reliable, ask for the outage notification procedure and the person who owns it. Instead of asking about quality, ask for the discrepancy workflow and a redacted sample of the report your quality office would receive. A provider who has done this work hands the documents over. A provider who has not sends a capabilities deck, and that is an answer too. Ask for both, and have somebody technical read the specification before the next meeting.

Design the pilot so it can fail informatively. Pick a bounded slice, one modality or one site, and run it long enough to cross a weekend, a holiday and a staffing gap. Define the measures before the first day and agree who calculates them. Include the awkward ones: how many studies arrived incomplete, how many reports failed to file on the first attempt, how long the escalation call took to be answered. Put an end date and a decision meeting on the calendar, because a pilot without an end date turns into a contract nobody negotiated.

• The full interface specification, before contract signature rather than after.
• The critical finding escalation procedure, with named roles and a backup path.
• The reader roster that would cover your site, with licensure and privileging status.
• The routing rules, including what happens when the preferred reader is unavailable.
• A redacted sample of the quality and discrepancy report your office would receive.
• The outage notification procedure, the maintenance windows and the support number.
• The exit clause: data format, timeline, cost and disposition of cached copies.

Sources and scope

• American College of Radiology, practice parameters for teleradiology and for the communication of diagnostic imaging findings
• National Electrical Manufacturers Association, DICOM standard for medical imaging communication
• HL7 International, messaging and interoperability standards for clinical data exchange
• Radiological Society of North America, professional education on imaging informatics
• Federation of State Medical Boards, policy on the appropriate use of telemedicine technologies in the practice of medicine