
However, early
implementations of AI have come across a major obstacle: how to adopt it to the
workflow as it has caused a true “traffic jam” of data to be routed to several
algorithms, and the results from these AI applications, in the form of
annotations, reports, markers, screen saves and other indications, to be routed
to their destinations such as the EMR, PACS, reporting systems or viewers. This
orchestration has to occur synchronized with other information flows for
example, an AI result has to be available either before or at the time of the
reporting of the imaging studies, and has to be available together with lab or
other results, which might need delaying or queuing these other non-AI information
flows to be effective.
What is needed to manage this is an AI
“conductor” that orchestrates the flow of images, results, reports between all
the different parties such as modalities, reporting systems, EMR, and obviously
the AI applications, the latter of which could be on-premise or in the cloud.
Note that the number of AI apps eventually reach hundreds if you take into
account that an algorithm might be modality specific (CT, MR, US etc.), and be
specialized for different body parts and/or diseases. Scalability is a key
requirement of this critical device but also many other features.
A simple “DICOM
router” will not be able to orchestrate this rather complex workflow. To assist
users with identifying the required features, I created three levels of routers
as shown in the figure.

The second level has additional
features as it can perform “fuzzy routing” i.e. based on fuzzy logic, prefetch
information using proxies (i.e. querying multiple sources while giving a single
return), do conversions of data and file formats, anonymize the data and is
scalable.
The third level has all of the level 1 and 2 functionality and
extends it to AI specific routing, can modify images header and split studies,
perform worklist proxies (i.e. query multiple worklists while appearing as a
single thread), and has secure connectivity to meet “zero-trust” requirements.
It supports not only “traditional” DICOM, HL7 but also webservices such as WADO
and FHIR and supports IHE. It can also perform static and dynamic routing, do data
conversions, filter the data, split studies, normalize the data, anonymize it
if so desired, and provide support for several different formats and support
for Structured reports, annotations, to name a few. As a matter of fact, a
fully featured AI conductor requires at least 25 distinctly different functions
as described in detail in this white paper (link).
In conclusion,
there is a serious workflow issue deploying AI, but the good news is that there
are solutions available, some in the public domain with limited features and
some as commercial products. Make sure you know what you need before shopping
around, the link to the comprehensive white paper on this subject has a handy checklist you can use when you
are shopping at your (virtual) HIMSS, SIIM or RSNA trade shows or when “Zooming”
with your favorite vendor. You can download the white paper here.