The word "readiness" gets used loosely in radiology AI conversations. Vendors ask if you're ready. Department heads ask if they're ready. Neither group usually means the same thing. The vendor is asking whether you have DICOM connectivity. The department head is asking whether the radiologists will cooperate. Both matter, and confusing them is how pilots end up struggling with problems that weren't technical at all.
What follows is the readiness assessment we actually run with sites before we start an integration. It's organized into four areas: infrastructure, workflow documentation, data governance, and organizational buy-in. A site doesn't need to be perfect in all four to proceed, but it needs to know exactly where the gaps are before go-live.
Infrastructure Readiness
The infrastructure questions are the ones most sites have already partially answered by the time they're talking to us. But "partially answered" is different from "confirmed."
PACS version and DICOM conformance. Most modern PACS systems can send and receive DICOM via C-STORE, which is the standard mechanism for routing studies to a pre-reading system. What's less consistent is the version currency and whether DICOM TLS is supported for encrypted transmission. PACS systems running versions that are more than three major releases behind their current version sometimes have conformance gaps that aren't documented anywhere accessible. The right question to ask your PACS administrator before any integration work: can you configure a new C-STORE SCU destination and confirm a successful test push to an external IP? If that question produces a blank look, you have work to do before the AI pilot begins.
HL7 v2 messaging from the RIS. Most AI workflow integrations rely on HL7 v2 ORM messages (order notifications) and ORU messages (result delivery) to move clinical context alongside the DICOM images. The pre-reading system needs to know the study type, referring provider, patient history, and clinical indication to produce a useful draft. DICOM metadata alone rarely carries all of that. If your RIS does not have an active HL7 v2 interface and at least a test receiver you can send messages to, the integration will either be limited or require a workaround. This comes up more often at smaller independent imaging centers than at hospital-affiliated departments.
Network architecture for cloud-based processing. If the pre-reading system processes images in a cloud environment, outbound firewall rules need to allow DICOM traffic to the processing endpoint. Many radiology departments have network policies written for a world where imaging data stayed on-premises, and the policy documentation doesn't anticipate cloud destinations. This is not a blocker, but it typically requires engagement with the IT security team and takes 2-4 weeks to resolve. Starting that conversation early prevents go-live delays.
Dictation platform version. As covered in the post on PowerScribe and MModal integration, the specific version of the dictation platform and its template configuration determines which draft delivery path is available. Knowing the version number and the name of whoever manages the dictation platform templates is step one.
Workflow Documentation
This is the readiness area that most sites underestimate. AI pre-reading integrates into an existing workflow, and the smoother that workflow is documented, the faster and cleaner the integration is.
Report template inventory. Does your site have a written inventory of active report templates, organized by modality and study type? Most sites have templates in their dictation system but no external documentation. Before integration, you need to map which templates the pre-reading draft should populate and how the section headers in the template correspond to the output format of the draft. This mapping is usually done once during initial configuration, but it requires someone who knows the template library well enough to make the judgment calls.
Current escalation path for urgent findings. Before adding an AI flagging layer, document how urgent findings are currently communicated from the reading room to the ordering provider. Who calls? On what timeline? Is there a callback acknowledgment requirement? Is it documented in a policy, or does it exist in informal practice? Sites that can answer these questions clearly are much better positioned to evaluate whether the AI flagging adds to or changes the existing pathway.
Radiologist reading assignment logic. How does the current worklist assign studies to specific radiologists? Is it first-come-first-served by who logs in first, or is there subspecialty routing? Understanding this matters because the pre-reading coverage rate can be affected by how studies flow through the worklist. If subspecialty routing means certain radiologists only see a fraction of the modalities being pre-read, the acceptance rate data needs to be segmented by reading assignment type.
Data Governance Readiness
This area covers the administrative prerequisites that need to be in place before any PHI-containing data is transmitted to an external system.
Business Associate Agreement. A BAA with the AI vendor is required before PHI can be transmitted for processing. This is a standard requirement under HIPAA for any covered entity working with a business associate that handles PHI. Some organizations have standard BAA templates that go through legal review; others accept the vendor's form. Either way, the BAA review process can take 2-6 weeks and should be started before any technical integration work begins. Starting integration without an executed BAA creates compliance exposure from the first test study pushed.
De-identification scope agreement. Even in a production environment where PHI transmission is covered by the BAA, you need to understand and agree on what fields are transmitted, retained, and used in model improvement. This is both a governance question and an operational one: some departments have data use policies that restrict secondary use of patient imaging data even with a BAA in place.
Incident response protocol for AI system errors. What happens if the pre-reading system produces a result that is materially wrong and the radiologist accepts it without modification? This scenario needs to be addressed in policy before deployment. We're not saying it is the expected case, and it's not unique to AI-assisted radiology, but a department that has no documented protocol for AI system error is not in a governance-ready state.
Organizational Buy-in
The non-technical readiness dimension is often the one that determines whether a pilot succeeds, and it's rarely assessed with the same rigor as the infrastructure questions.
Radiologist awareness and opt-in. Have the radiologists who will be in the pilot been informed of the purpose, the metrics being collected, and the expected workflow change? Pilots launched as a surprise or as a top-down mandate from administration typically see lower acceptance rates and more vocal resistance than those launched with radiologist input on scope. This doesn't mean every radiologist needs to enthusiastically endorse the pilot, but it means each participant understands what they're participating in.
A designated workflow champion in the reading room. The most effective radiology AI pilots have a single radiologist who is invested in the outcome, has agreed to actively use and evaluate the tool, and is willing to give direct feedback on draft quality to the vendor. This person becomes the signal amplifier for what's working and what isn't. Without this role, feedback tends to come filtered through layers of administration and arrives too slowly to affect the pilot.
IT and PACS team availability during go-live week. The first week of a new DICOM integration will produce unexpected behavior. The question is not whether something will need adjustment, but whether you have the right technical contact available to investigate quickly when it does. A site that launches a pilot the same week their PACS administrator is on vacation starts with a handicap that's easy to avoid.
The Minimum Viable Readiness Bar
A site can proceed to pilot with infrastructure readiness at 80% (known gaps identified and remediation planned), workflow documentation at 60% (at least template inventory and escalation path documented), data governance at 100% (BAA must be in place before PHI transmission), and organizational readiness at 70% (radiologist awareness and one champion confirmed). Sites that try to pilot below those thresholds are typically not failing because the technology doesn't work. They're failing because the prerequisites weren't in place.