Most conversations about radiology AI drafts focus on model performance: sensitivity, specificity, finding detection rates. What gets less attention is the mechanics of what the radiologist actually encounters at the moment they open a study. The delivery path from AI-generated output to a signed report is not trivial, and the experience differs meaningfully between PowerScribe 360 and MModal Fluency for Imaging, the two dictation platforms covering the large majority of U.S. radiology departments.
This is a walkthrough of the technical path and the UX reality in both. We've worked through the integration for both platforms, so what follows is based on what we know from building and testing these connections.
How Draft Delivery Actually Works: Two Approaches
There are two architectural patterns for delivering a draft to a radiologist in a dictation platform. The first is direct field injection, where the pre-reading system writes structured text directly into the report template fields via the platform's API or HL7 result interface before the radiologist opens the study. The second is side-panel or overlay, where the draft appears in an adjacent view and the radiologist manually copies or accepts sections into the dictation field.
Both platforms support variants of both approaches, but the preferred integration path and the user experience are different.
PowerScribe 360: The Auto-Text Insertion Path
PowerScribe 360 (Nuance/Microsoft) exposes a report template system and, for external integrations, typically accepts pre-populated text via HL7 ORM/ORU messaging or through the PowerScribe Reporting API depending on the site's version and licensing.
In the most common integration pattern we've used, the AI draft is delivered as structured text segments that map to specific report sections: Clinical History, Technique, Findings, and Impression. When the radiologist opens the study in their PACS viewer and the PowerScribe dictation window launches alongside it, the report template fields are pre-populated.
What the radiologist sees is not a "suggested draft" notification or a side panel. The text is already in the dictation box. The default behavior in most PowerScribe configurations is that this pre-populated text is visually indistinguishable from text the radiologist has already dictated. This is intentional: the intent is that the draft is a starting point, not an alert. Some sites choose to configure the pre-populated text in a distinct color or append a visible marker like "[DRAFT]" at the start of each section, but this requires customization in the template configuration.
The practical effect: radiologists who are accustomed to the workflow often describe it as "the report writes itself for normal studies." For a standard chest X-ray showing no acute findings, the entire draft may be clinically accurate and require only a review and voice-sign. For studies with findings, the radiologist uses voice correction to modify specific phrases or adds to the Impression. The correction overhead is much lower than dictating from scratch.
One friction point that comes up repeatedly in PowerScribe environments: auto-text macros. Many radiologists have years of personal auto-text libraries in PowerScribe, and when a draft is pre-populated, there can be conflicts between their macro habits and the existing text in the field. This usually resolves with a few weeks of adjusted muscle memory, but it's worth flagging with radiologists during onboarding.
MModal Fluency for Imaging: The Front-End Inference Path
MModal Fluency for Imaging (acquired by 3M, now Solventum) has a different architecture. Fluency has historically built its AI assistance into the front-end dictation experience rather than via backend field injection. The platform's AI features operate on the voice input stream in real time, offering structured suggestions as the radiologist dictates.
Integrating an external pre-reading draft into Fluency follows a different path than PowerScribe. The most common integration approach we've implemented uses Fluency's template pre-population capability, which accepts structured content via an interface that's configured during deployment. The result at the radiologist's UI level is similar to PowerScribe: fields arrive pre-populated when the study is opened.
There's a nuance worth understanding: Fluency's own AI layer continues to operate on top of any pre-populated content. If the radiologist starts editing or re-dictating, Fluency's in-line speech recognition and formatting logic applies. The net experience is that Fluency tends to feel more like a collaborative edit rather than a static draft being reviewed. Whether that's better or worse depends on the radiologist's preference. Some find Fluency's active suggestions helpful when correcting findings language. Others find the two layers of suggestion competing for attention, especially when the pre-populated draft is already accurate.
One technical constraint: Fluency's pre-population interface has stricter requirements around report template structure. The AI draft needs to map to the exact section headers defined in the site's Fluency template. If a site has customized their templates significantly, the mapping requires a configuration step to align draft section names with template section identifiers. This is a one-time setup task, but it often surprises teams expecting a plug-and-play integration.
The Sign-off Flow: Where Liability Becomes Concrete
In both platforms, the radiologist reviews, edits, and signs the report. The signed report is the radiologist's attestation, regardless of what the starting content was. This is not a gray area and we're not saying it should be: the physician review and signature is what makes the report a clinical document, and that responsibility does not transfer to the pre-reading system under any configuration we support.
What the integration affects is the dictation workflow before sign-off. In PowerScribe, the voice-sign command or the physical sign button in the report window finalizes the report. In Fluency, finalization goes through a similar signing step in the Fluency interface. Neither platform logs whether a report began as a pre-populated draft versus a dictated-from-scratch report at the signed output level, which matters for audit purposes. We surface draft-origination metadata in our own system logs separately from the dictation platform's records.
What Changes on Day One vs. Week Four
The first week of using pre-populated drafts in either platform is not representative of steady-state behavior. Radiologists are simultaneously learning a new micro-workflow (review rather than dictate) while adjusting to the draft language style. Acceptance rates in week one are lower than at week four, sometimes considerably.
The inflection point we most commonly see is around week three, when the radiologists have internalized which study types and which sections consistently need editing versus which arrive accurate enough to accept. At that point, the mental model shifts from "reviewing someone else's text" to "checking the normal template and only dictating exceptions." That shift is visible in both acceptance rate metrics and in dictation time per study.
We track both platforms across active deployments, and there's no consistent winner between PowerScribe and Fluency in terms of acceptance rate or time-to-sign. The variable that matters more is template configuration quality: sites that invested time in mapping draft sections cleanly to their existing templates, and that communicated the workflow change to radiologists before go-live, see better outcomes in both systems than sites where the integration went live without preparation.
The underlying message from both platforms is the same: dictation software is where the radiologist's attention lives, and anything that disrupts that context without a clear benefit will be ignored or worked around. The integration path exists. Making it useful requires configuration work and onboarding care that is separate from the AI model's performance.