Welcome back! This is the second blog in our series on how AI platforms in healthcare differ from one another. Last time, we looked at positioning and contracting. Today, we are zooming in on functional capabilities, the practical features that decide how a platform fits into clinical workflows.
Choosing a platform is not just about who built it or how the contract is structured. What a platform does day-to-day is just as much part of the selection conversation and arguably where the most meaningful differences between platforms show up. Three areas stand out: how platforms orchestrate data, how results are displayed and reviewed, and how reporting is handled.
Data orchestration: getting the right data to the right algorithm
Before any AI algorithm can run, the platform needs to identify which data to send to it and when. That process, known as data orchestration, looks pretty different from one platform to the next, and those differences can really add up when it comes to workflow efficiency.
Some platforms rely primarily on DICOM metadata to route imaging studies to the appropriate algorithm. Based on e.g. modality, body part, study description, and acquisition parameters, stored in the DICOM metadata, rules can be set to send studies with certain values to certain algorithms. However, often this is not sufficient to have high accuracy of correct orchestration. An example is the use case of fracture detection. Based on the DICOM metadata one can select all skeletal radiographs, but it is not easy to distinguish whether these were acquired with the indication of fracture and whether it is an acute fracture or follow-up scan. For this more information is needed.
Therefore, some platforms incorporate HL7 connections, the messaging standard hospitals use to exchange clinical information between systems like the EMR, RIS, and PACS. Tapping into HL7 lets the platform see additional clinical context, such as the reason for imaging or relevant patient history, and use that to inform the orchestration logic. A smaller number go a step further and use pixel-level data, meaning they peek into the actual image content itself, to help decide which algorithm should run. This can catch cases that metadata alone would miss, for example when a chest CT also covers the upper abdomen. The study description only mentions the chest, but by recognising the anatomy in the images the platform can also route the study to an algorithm for, say, liver or adrenal findings, which metadata-based rules would have skipped.
The practical difference is in how well the platform can handle complexity. A metadata-only approach works well for straightforward, high-volume imaging workflows but may struggle with more nuanced clinical pathways where context matters. HL7 integration adds that context but requires more extensive setup and compatibility with the hospital’s existing systems.
Viewing and interaction: what happens after the algorithm runs?
Once an AI algorithm has processed a study, the platform determines how these results are presented to the radiologist. Here, platforms divide into two broad approaches.
Some platforms have no proprietory viewer. They pass AI outputs straight to clinical systems like the PACS or a reporting system, with no review step in between. That keeps things fast and adds minimal friction, but it also means the clinician cannot inspect, adjust, or interact with the AI output before it becomes part of the record.
Platforms with a unified viewer provide an interface where clinicians can review AI-generated results, make adjustments where needed, and then confirm before the output is sent downstream. This adds a step to the workflow, but the pay-off is more control, which really matters when the AI outputs inform clinical decisions, like measurements used to plan treatment.
Platforms offered by PACS vendors sit somewhere in between. Because the platform is part of the PACS itself, AI results appear directly in the viewer radiologists already use for reading, with no separate application to open, while clinicians can still review and adjust the outputs within that same environment. This combines the low friction of a direct-to-PACS approach with the control of a dedicated viewer, although these benefits are tied to using that vendor’s PACS.
A detail that often gets overlooked is how the platform handles the fact that every AI vendor presents results in its own way, different visual overlays, different ways of showing measurements, different layouts for findings, and different ways of clicking through them. Without a unifying layer that smooths this out, clinicians have to learn a new interface for every AI product they adopt. Platforms that translate these into a single, consistent view make life easier: the clinician learns one interface, no matter which algorithm produced the result. The more algorithms a hospital uses, the more this consistency is worth.
The appropriate choice depends on the use case. For high-confidence, high-volume tasks where AI accuracy is well established, a direct-to-PACS model is efficient. For more complex or lower-volume pathways where results may need interpretation or modification, a viewer adds meaningful value.
Reporting: from output to documentation
The final functional dimension covered for now is how AI outputs connect to clinical documentation. This ranges considerably across platforms.
Some platforms deliver PDF outputs or image overlays. In this case, AI results are presented as standalone files or visual annotations on images. They are handy as a reference, but they sit outside the reporting workflow, so when it is time to write the report, the clinician still has to transfer the numbers provided by the AI solution manually, either by highlighting and copy-pasting them into the report or by dictating them into the speech recognition system.
Other platforms go a step further and load the AI outputs into the reporting template. Findings from each algorithm come through as a pre-filled draft that the clinician can edit and sign off. The result: less manual data entry, more consistent reports, and noticeably faster documentation, especially in departments where reporting time is tight.
A newer generation of reporting capabilities goes further still. Instead of only inserting AI measurements into fixed fields, these solutions let the radiologist dictate in free narrative, while a large language model structures the dictation, places each finding in the right section of the report template, and combines it with the AI outputs. Some also draft the impression, the summarising conclusion of the report, for the radiologist to review and adjust. This moves AI from supplying numbers to supporting the drafting of the report as a whole, but it also raises new questions around validation, oversight, and responsibility for the final text.
These approaches differ meaningfully in terms of workflow impact, and the right fit depends on the specific clinical context in which the platform will be used.
Putting it together
Functional capabilities determine the day-to-day reality of working with an AI platform. A platform that handles data orchestration well, provides appropriate viewing and interaction options, and connects to reporting workflows will integrate more smoothly into clinical practice than one that excels on paper but creates friction in use.
In the third and final post in this series, we turn to the longer-term considerations: how platforms cover post-market surveillance, AI development features, and strategic customisation.