AI Integration in the Clinical Workflow

Abstract

Machine learning and artificial intelligence (AI) algorithms hold significant promise for addressing important clinical needs when applied to medical imaging; however, integration of algorithms into a radiology department is challenging. Vended algorithms are integrated into the workflow, successfully, but are typically closed systems and unavailable for site researchers to deploy algorithms. Rather than AI researchers creating one-off solutions, a general, multi-purpose integration system is desired. Here, we present a set of use cases and requirements for a system designed to enable rapid deployment of AI algorithms into the radiologist’s workflow. The system uses standards-compliant digital imaging and communications in medicine structured reporting (DICOM SR) to present AI measurements, results, and findings to the radiologist in a clinical context and enables acceptance or rejection of results. The system also implements a feedback mechanism for post-processing technologists to correct results as directed by the radiologist. We demonstrate integration of a body composition algorithm and an algorithm for determining total kidney volume for patients with polycystic kidney disease.

Background

Recently, there has been a proliferation of machine learning and other artificial intelligence (AI) algorithms applied to medical images. These algorithms frequently promise to address important clinical needs in radiology departments, yet the desire to investigate the impact of an AI algorithm in practice can vary between AI algorithm researcher and radiologist. AI researchers frequently do not appreciate the complexity of clinical radiology workflows. Radiology IT systems are very complex, involving modalities, routing layers, picture archiving and communication system (PACS), archives, clinical and mobile viewers, etc. Efficient integration in such an environment can be challenging, yet is crucial, both for algorithm validation and production.

In a prior work, we have addressed the challenge of executing an AI algorithm on the correct imaging data [1]. DEWEY, the DICOM-enabled workflow engine system, receives DICOM images and executes one or more workflows on each series. This workflow orchestration involves determining the type of imaging, i.e., CT abdomen pelvis, MR T2, and execution of an AI algorithm on the series. DICOM outputs of the algorithm may be routed to downstream systems. DEWEY has proven successful in our practice, but has revealed a further need, namely, presentation and review of AI algorithm results by the radiologist.

To be clinically useful, AI algorithms must be integrated into the daily, routine, clinical workflow of a radiologist without adding unnecessary “clicks” or confusion. Given the complexity of modern clinical workflows, any degree of integration may be difficult to achieve. Researchers developing AI algorithms may lack the understanding of technologies such as DICOM, PACS, and VNA and evaluate algorithms in an off-line manner. Offline evaluation may result in a skewed perception of performance, since it is not reflective of how an algorithm will be used in a real clinical workflow.

Additionally, vendors do not always provide the toolsets required for such integrations. Though, valuable, off-line evaluation fails to measure the impact that an algorithm has on patient care, because the radiologist is forced to consult a non-clinical system, breaking the flow of interpretation. In cases where researchers are able to integrate into the radiology workflow, the solutions are typically one-off systems that cannot be re-used or re-targeted to other algorithms.

Currently, companies that deploy AI in clinical practice employ widgets or web apps to allow for review and interaction with the AI results. For example, Aidoc Medical (Aidoc, New York, NY, USA) has several products designed to prioritize cases on a radiology work list. Aidoc utilizes an unobtrusive widget running on the PACS workstation to indicate a finding and display a thumbnail image of the region containing the finding. Other platforms are designed to enable physicians to explore algorithm output and control which results become part of the patient record. These include the Eureka Clinical AI Platform (TeraRecon, Durham, NC, USA), IntelliSpace AI Workflow Suite (Philips Healthcare, Franklin, TN, USA), and AI-Rad Companion (Siemens Medical Solutions, Malvern, PA, USA). These solutions, in some instances, operate outside of the clinically utilized image viewers, posing additional challenges for the clinical integrations.

The degree of integration of AI into the clinical workflow is multifaceted. In some instances, AI results must be prevented from interacting with clinical systems, i.e., research settings. Today’s clinical standard is for algorithm results to be presented as a DICOM secondary capture attached to the primary acquisition and presented in the PACS. Unfortunately, removing or adjusting such results is often not done in the interest of efficiency. Conversely, several of the platforms described above allow a high degree of interaction and engagement from the radiologist, or from a technologist if available in a radiology department. Highly interactive platforms allow results to be adjusted as desired and selectively entered into the patient record but have the drawback of requiring a shifting of focus from patient images to the AI system from interpretation. In this paper, we suggest a middle path of presenting AI results with minimal friction, but enabling the radiologist to accept, reject or request rework of the results.

The scope of this paper is to describe some of the basic integration requirements as well as to propose solutions that can be leveraged from academic institutions. For this purpose, we will be providing an overview of a system that we developed called “ROCKET” or Records of Computed Knowledge Expressed by neural nets. ROCKET has been designed to bridge the last gap of integration of AI algorithm results into the clinical practice for the purpose of prospective evaluation of algorithms and potential integration of results into reporting systems, like a clinical viewer and archive, in a vendor agnostic approach. Rather than attempt to create a comprehensive system to enable interaction with AI results, ROCKET is designed primarily for rapid review of AI results and acceptance, rejection, or rework of the results. Unlike one-off systems, ROCKET will enable AI results to be reviewed from any PACS or workstation. A new IHE profile, AI Results (AIR), is being drafted to address the increasingly common scenario that ROCKET is designed to address [2]. Where possible, ROCKET aligns to the AIR profile.

Methods

Fundamentally, ROCKET is designed to display AI algorithm results to radiologists in a clinical context and allow actions based on the AI results. Any system adding to the already complex and demanding radiology workflow must be designed with care to have minimal impact on the workflow and deliver maximal value. Systems that do not consider the needs of the radiologist are likely to remain unused, no matter how valuable the AI results, because of the negative impact to the radiologist. To this end, ROCKET was designed around a few key requirements to satisfy several use cases. The use cases consider the interactions between the radiologists, IT, and the AI algorithm.

Use Cases

Use Case: Algorithm Integration

Dr. Alberts, an AI scientist, wishes to integrate a new algorithm into the radiology workflow under a non-production, research-suitable environment. His algorithm produces both a representative image and a report. Dr. Alberts creates a DICOM SR and DICOM secondary capture (SC) images. The DICOM SR object contains the textual report from the algorithm and a reference to the DICOM SC series to be displayed to the radiologist. In the DICOM SR file are the numeric values computed by the algorithm that may be used to automatically populate a reporting template or be entered directly into the EMR. In addition, the DICOM SR contains settings that control the display of the algorithm output and a list of series that should be sent to PACS if the results are accepted. The algorithm is encapsulated as a Docker/Singularity container [3] and deployed to DEWEY with the appropriate image identification and workflow for processing studies by Dr. Alberts’ algorithm.

Use Case: Results Review and Acceptance

Dr. Roberts, a radiologist, wishes to view the AI result within the PACS for the patient she is currently reviewing. Dr. Roberts launches ROCKET by clicking on a shortcut in the toolbar of the PACS interface. ROCKET opens, showing AI results for the current study for the current patient. In the ROCKET user interface (UI), Dr. Roberts sees a list of AI results and by clicking on each result can rapidly review them. Representative images from the algorithm are displayed, along with a textual report produced by the algorithm. Dr. Roberts can quickly review multiple algorithms, marking “Accept,” “Reject” or “Rework” as appropriate.

Use Case: Rework

Dr. Jones, a radiologist, upon review of AI results, wishes that the organ segmentation results are manually corrected. Dr. Jones clicks the REWORK button on the ROCKET UI. The rework dialog opens, pre-filled with patient demographics and series and study information. Dr. Jones enters precise directions for the image post-processing lab staff and clicks send. ROCKET routes the rework information to the proper personnel, establishing a direct connection between the technologist performing the rework and the radiologist. When the manual corrections are performed, the technologist informs Dr. Jones, who dictates the correct results into the report.

Requirements

Requirement: Maintain Patient Context

A critical component of ROCKET is maintenance of the patient context. AI results must be displayed for the current exam of the patient being reviewed by the radiologist. Care must be taken to ensure that “stale” results are not shown, minimizing the possibility of error that can impact patient’s safety. This leads to the requirement that ROCKET shall maintain patient context by launching in context and, when tight tool integration prevents closing in context, using a timeout mechanism to minimize the potential of showing the radiologist results of the wrong patient.

Requirement: Familiar User Experience

PACS systems often have commonly used shortcuts, i.e., to maximize the viewing window, to window/level, to scroll through images… ROCKET shall provide a mechanism to review images following the user experience of PACS to a reasonable degree, including color schemes.

Requirement: Feedback on AI Algorithm Performance

AI algorithms generally benefit from feedback loops on performance and can be retrained at specific intervals with new data. Such retraining keeps the algorithm results from drifting by, helping to adapt to changes in input or patient populations. Radiologist feedback shall be in the form of a binary “Accept” or “Reject” of the algorithm results.

Requirement: Requests for Manual Intervention

AI algorithms are not perfect and may fail in the presence of unusual anatomy or disease. To address failures, ROCKET shall provide a mechanism to request the image post-processing lab staff to manually correct algorithm failures. For instance, an AI algorithm may fail to include a cyst when segmenting a kidney for a patient with polycystic kidney disease. In such a case, the system shall enable the radiologist to communicate with the technologist and provide instructions for correction of the failure. The ROCKET system must add appropriate patient context to the message.

Requirement: Multiple AI Results

The interface must provide an intuitive way to display results from multiple AI algorithms or versions of the algorithm. Additionally, the interface must enable rapid review of many results. For instance, a single abdomen pelvis CT exam may have a body composition algorithm, kidney and liver volume algorithms, a pancreatic cancer detection algorithm, and an automated liver lesion measurement algorithm. In addition, each series in the exam may also contain results and the system must enable easy navigation across results, series and exams.

Requirement: Vendor Agnostic

The tool must provide an application programming interface (API) to enable integration with a variety of image viewers. Deep integration with a particular vendor is valuable, but imaging departments may not desire vendor lock-in and wish to be free to replace components of their workflow as needed.

Requirement: Standards Conformance for Integrations with Clinical Systems

The tool must follow common standards for integration with clinical systems. DICOM support is mandatory, and HL7, Fast Healthcare Interoperability Resources (FHIR) and DICOM-WEB conformance is desirable for communication between clinical systems. The emerging Integrating the Healthcare Enterprise (IHE) AI Results profile should be consulted and followed. An example of desirable integration is sending measurements from an AI result to a dictation system for inclusion in the final report, without need of manual entry.

Requirement: Record Maintenance (HIPAA Compliant)

Conformance to privacy standards such as HIPAA and GDPR is required. The IHE Audit Trail and Node Authentication profile [4] specifies these requirements and ought to be implemented in a system. Implementation must include user authentication, user authorization, event logging, and encryption.

Requirement: Support Multiple Type of AI Algorithms

Broadly, radiology-oriented AI algorithms fall into several classes: segmentation (predicting a label for each input pixel), classification (predicting a label for an image or sub-region), detection (predicting regions of interest in an image), and measurement (linear, area or volume measurements, such as the Response Criteria in Solid Tumors). Tooling should support different classes of AI algorithms with different UI components. For instance, detection results may be presented with a ROI displayed over regions of the image, segmentation results may depict the organ overlaid with a semi-transparent color, and classification results may be displayed with the class confidence, and a colored map showing the region most contributing to the classification. In this way, the tooling facilitates rapid review of results.

Requirement: Enable Validation Studies

A validation study is usually required before an AI algorithm is put into the routine radiology workflow. The best validation studies are performed in the same context for the radiologist and do not require switching to a different workstation. Such validation studies provide a comprehensive view of how an algorithm impacts the radiologist’s work. A tool should provide a method of displaying “alpha” or “beta” versions that are under investigation, and, alternatively, hiding the results when used in clinical work. This requirement is critical for obtaining algorithm performance and user experience feedback early in the clinical implementation process, by uncovering possible integration problems when they can be easily addressed, rather than finding out after implementation.

Requirement: Notify AI Failures to Provide Results

The workflow from modality to orchestration engine to display tooling is complex and has many points of failure. For instance, the routing system may fail, or the DICOM tags may not match the orchestration engine rules to trigger execution of a particular AI algorithm. Such failures prohibit the AI algorithm from being executed, and no results are available to the radiologist. Other failures include execution errors in the algorithm, or lack of findings. The tool ought to present status information to the radiologist, when possible. If the algorithm was invoked by the orchestration engine but encountered an unexpected error, a notification should be presented to the radiologist. The radiologist then knows the algorithm executed, but could not produce results, rather than waiting for a result that will never come.

ROCKET Architecture

The ROCKET application is implemented as a standard three-tier web application, i.e., Angular JS front end,.NET backend, and SQL Server database, as shown in Fig. 1. In addition, the ROCKET backend interacts with a DICOM-WEB-enabled DICOM image storage service class provider to retrieve AI results and initiate C-MOVE commands to the PACS system.

Fig. 1.

ROCKET architecture

Figure 2 shows the ROCKET main interface. The Angular JS [5] front-end UI displays AI results in a web browser. The UI has 4 major components: (1) display of the display series, (2) corresponding text report, (3) “Report Navigator” listing all available results in the event of multiple AI results for a given Accession, and (4) “Accept” and “Reject” controls. Authentication is handled by OAuth2 connected to Microsoft Azure Active Directory. Display of images uses cornerstone.js [6] to load and display DICOM images and includes simple scrolling and window level functions. All image interactions are patterned after the PACS interface.

Fig. 2.

ROCKET main interface

The Report Navigator is populated with DICOM SR Series for the accession number. To support the multiple AI results use case, the report navigator interface lists all available AI results related to the accession number in an easy to navigate list. Each report element can be independently reviewed and accepted/rejected. The report and UI elements are controlled as described above.

DICOM SR

DICOM SR [7] specifies a mechanism for recording results independent of display. DICOM SR is a natural choice to store results from AI algorithms, because measurements and predictions from the algorithm can be coded within the DICOM SR. Such values can be extracted by other processes for reporting, conversion, data mining, etc. DICOM SR may cross-reference images including the location of findings and store lists of related series. ROCKET associates AI results from DICOM SR both by study instance UID and accession number. AI algorithm developers seeking to use ROCKET as an entry point into the clinical workflow must simply construct their results and create a DICOM SR. Algorithm developers usually produce a visual representation of the results as a DICOM SC Series and a DICOM SR Series to control ROCKET. Typically, the DICOM SR Series instructs ROCKET to display the DICOM SC for review, which UI components to display and which, if any, algorithm produced DICOM SC to send to PACS. By following the DICOM SR standard, algorithm developers do not need to use private tags, external files, etc. to integrate with the clinical workflow. The ROCKET server extracts values from the DICOM SR to control the information presented to the radiologist, including options for sending result images into downstream PACS systems.

The relevant values include:

• A title for the result, typically including the series description and algorithm identifier. This is shown in the “Report Navigator” list to identify the results.

• A short description of the algorithm result as text. ROCKET displays the description below patient demographics on the right side, as shown in Fig. 2.

• A Boolean flag, indicating if algorithm results can be sent to PACS. This flag is useful to prevent results from preliminary algorithms from being accidentally transferred to PACS. This flag controls the label on the “Accept” button, and the red warning banner is displayed when results will not be sent to PACS.

• A Boolean flag indicating if the “Rework” button should be shown in the interface.

• A reference list of series that ROCKET should display as a visual representation of the algorithm results. Frequently, algorithms produce a color overlay as a DICOM SC or a heatmap showing the degree of contribution by image regions to the prediction. This list contains the Series Instance UIDs for display.

• A reference list of series that ROCKET should send to PACS if the results are accepted by the radiologist. This list is distinct from the list of series for display (though they may be the same).

• A set of numeric or textual values representing the results generated by the AI algorithm. DICOM SR’s coding schemes are particularly relevant to provide measurement units and types of these measurements. Values may be used to populate a dictation macro for easy reporting. The values also may be extracted for data mining purposes.

ROCKET Workflow

The ROCKET workflow is shown in a sequence diagram in Fig. 3. Images acquired at the modality are transferred to the orchestration engine. The orchestration engine is responsible for routing the images to the correct set of AI algorithms and monitoring the execution of the algorithm. Generated results are sent via DICOM networking to the ROCKET storage, a DICOM image storage service class provider. Ideally, this initial transfer and processing occurs before the exam is finalized and interpretation begins for the radiologist.

Fig. 3.

Sequence diagram

When the exam is completed, the radiologist begins to review the case on the PACS workstation. At the discretion of the radiologist, possibly triggered by the imaging order, the ROCKET web application may be invoked through PACS using a UI element, often a button. ROCKET is given the accession number of the study being reviewed and requests the DICOM SR from the ROCKET storage, parses the relevant fields outlined in above, and displays the appropriate patient demographics and list of results, and loads the first result for radiologist review.

ROCKET accommodates multiple AI results per study by listing each separate results in the “Results Navigator” section (see Fig. 2, item #3). The Results Navigator enables rapid review of multiple algorithm results by showing a list of results. The title presented in Results Navigator is provided by the algorithm via DICOM SR and aids the radiologist in reviewing relevant AI results. As more and more AI algorithms are developed, a single chest abdomen pelvis exam could hypothetically have results for kidney volume, liver volume, detection of early-stage pancreatic cancer, body composition, etc. ROCKET’s Results Navigator would display each result separately and enable rapid review of different results.

There are three major pathways for the radiologist to choose, “Accept,” “Reject,” or “Rework”. Because multiple AI results can be associated to a single accession number, the radiologist may choose to accept or reject each result (or may completely ignore results). If the AI results are rejected, ROCKET simply records the rejection, noting time and user. If the radiologist provides the reason for the rejection from a list or free text, ROCKET stores the reason for rejection for later review by an AI scientist. Reject feedback is optional for the radiologist. In the case of acceptance, ROCKET records the acceptance decision and, then, issues a DICOM C-MOVE to the ROCKET storage to initiate the sending of the AI results to PACS. Only series contained in the DICOM SR reference list are sent to PACS.

Algorithms set a flag in the DICOM SR, indicating if the Rework feature should be enabled in the interface. Some algorithms may not have a valid Rework option, for instance, a tumor classification algorithm, and the algorithm would simply disable the Rework feature. Likewise, for radiology departments without a dedicated team to Rework segmentation or measurement algorithm results, the Rework option can be disabled for the entire ROCKET interface. The Rework path is invoked by the radiologist when the AI results require adjustment. For instance, a segmentation algorithm is missing a small region of tissue. ROCKET displays patient demographics, study and series information with a free text field for the radiologist to enter specific instructions to the image post-processing lab staff. This establishes a direct connection between the reading radiologist and the technologist performing the corrections. Such a connection is frequently lacking in other asynchronous communication methods.

To evaluate the utility of ROCKET, the system will be integrated into a PACS system and applied to the evaluation of several existing AI algorithms. The body composition algorithm is processed by DEWEY with results stored as DICOM. ROCKET is integrated into PACS and made available to a group of radiologists. The radiologists are asked to evaluate the DEWEY-PACS-ROCKET workflow in an Institutional Review Board (IRB)-approved study.

Results

The ROCKET system has been implemented, as described above, using an agile software development approach. During each sprint, the product owner guided and refined product features. Significant stakeholders reviewed the progress, including feature demonstrations of use cases and requirements. Initial development of ROCKET was completed over the course of 3 months in 6 2-week sprints by a team of developers. The development process required significant involvement of radiology IT support to ensure DICOM WEB connectivity between ROCKET and the DICOM archive.

Development (DEV), integration (INT), and production (PROD) environments were configured, each with a separate instance of ROCKET: the ROCKET database, DEWEY, DICOM storage, and computational resources. The DEV environment was provisioned with minimal compute and storage. The INT environment was provisioned with sufficient compute and storage to enable load testing of ROCKET under near-production level loads. For clinical utilization, the PROD environment was scaled to handle the computational and storage demands of a large radiology department. The PROD environment resides on a high-performance computing cluster of 2 head nodes, 3 CPU only compute nodes with 24 cores and 386 G of RAM, and 2 GPU compute nodes with 4 32 G GPU cards, 24 cores, and 386 G of RAM. Primary and hot-spare DEWEY instances run on the two head nodes and use a cluster scheduler to distribute AI algorithm executions across the compute nodes. Algorithms are routed to CPU or GPU compute nodes based on their processing requirements. Where possible, algorithms are processed on CPU nodes, reserving the limited GPUs for more demanding algorithms.

Currently several algorithms are deployed on the PROD environment. Algorithms are queued for execution on the compute nodes immediately after the DICOM is available. Our current compute capacity is sufficient for the current workload and is easily scaled horizontally to address future loads. Many of the algorithms are highly specific for particular series and execute infrequently (10–100 studies per day), while others such as the body composition, process high volume studies (abdomen-pelvis CT, 1000 per day). Due to efficient DICOM routing, DEWEY and ROCKET received images concurrently with PACS. Turnaround time for algorithms is largely limited to actual processing time on the compute cluster, ranging from 1 to 2 min for the polycystic kidney algorithm, 5 to 7 min for body composition, and approximately 1 h for more complex algorithms (not yet published).

The body composition AI algorithm that performs automated abdominal tissue segmentation on CT images [8] has been adapted for use within ROCKET. The algorithm identifies several tissue types within a single CT image at the inferior/superior midpoint of the L3 vertebral body. Only a skeletal muscle area was chosen for initial implementation (Fig. 4). The original algorithm implementation was modified to construct DICOM images and DICOM-SR files according to the ROCKET specification. A DEWEY workflow was constructed to process abdomen pelvis CT exams, using a containerized body composition algorithm. Approximately 1000 CT exams per day are processed by the algorithm, each job is allocated 8 cores and 16 G of RAM and requires roughly 5 min of CPU time. CT exams arrive roughly uniformly through a 12-h timeframe corresponding.

Fig. 4.

Body composition AI algorithm results

ROCKET was used to measure the rate of acceptance of the body composition AI algorithm. In an IRB-approved prospective study, results were made available to a group of radiologists. Radiologists were provided training on the use of ROCKET via recorded video and training on the algorithm via a two-page quick reference guide. The radiologists were able to access the body composition AI results in ROCKET by launching via a PACS workstation, as shown in Fig. 5. Cases were reviewed in ROCKET at the discretion of the radiologist. Participants were asked to mark AI results as acceptable or to reject. Eight radiologists participated over a 10-week trial period and accepted 180 results, rejected 9, and viewed without action in 69 cases. Many of the 69 views without action were acceptable to the radiologist, but not marked as such. Unfortunately, without action by the radiologist to accept or reject, ROCKET can only record a view. Some of the reasons for viewing without action include several bugs that prevented the recording of results, initial unfamiliarity with ROCKET, demonstration of the system to fellow radiologists and misunderstanding that an action was requested. The bugs were fixed and training material created to assist the radiologist in using ROCKET effectively. These results are summarized in Fig. 6 and are a useful gauge for the clinical acceptance rate of the algorithm, when deployed clinically. While direct timings of ROCKET interaction were not available, radiologists reported that ROCKET opened quickly and interactions generally lasted less than 1 min.

Fig. 5.

ROCKET integration with PACS. White arrow indicates the button on PACS to launch ROCKET in the patient context

Fig. 6.

Values collected by ROCKET during an initial trial of an algorithm

An AI algorithm for automated segmentation of kidney tissue from patients with polycystic kidney disease [9] has been interfaced with ROCKET (Fig. 7. The total kidney volume algorithm provides automated measurement of kidney volumes for patients with polycystic kidney disease. The algorithm has been shown to be robust and accurate; however, when patients have additional cysts in the liver, the algorithm may mistakenly include liver cysts in the kidney. In this case, the Rework pathway is used to inform 3D Lab technologists to manually correct the AI results and return the case to the radiologist. The kidney volume workflow is being transitioned to ROCKET and has been applied to MR images of over 300 patients to date.

Fig. 7.

Polycystic kidney segmentation AI algorithm results displayed in ROCKET

Discussion

Integration of AI algorithms into today’s complex radiology practice remains challenging. A significant challenge lies in bridging the gap in domain knowledge between AI researchers developing AI algorithms and IT engineers responsible for translation into the clinical practice. The knowledge of researchers usually does not extend into the DICOM standard, system architecture, and engineering required to build scalable, robust systems necessary to deliver AI to radiologists. The use cases and requirements presented in this work are an attempt to capture the essence of such a system; ROCKET is the implementation designed with the express purpose of easing the translation of algorithms into routine care. Custom solutions have several disadvantages. Frequently, the team responsible for the initial development is disbanded after the initial release, causing knowledge and familiarity with the code and architecture to be lost. The cost of maintenance and enhancement is correspondingly high as new developers learn the code base sufficiently well to make changes. Because custom solutions stay in-house, they do not benefit from input and feedback from multiple users at other institutions. Releasing such software as open-source projects is an option, but it may require significant time commitments to support other institutions. Likewise, vended solutions have disadvantages. Vended solutions may be costly to purchase and maintain and vendors may go out of business, leaving the practice with an unsupported product. Enhancements and bug fixes typically require long release cycles, unlike a custom solution that can be fixed immediately, and the practice may need to wait for several releases for fixes in vended solutions. Vended solutions are developed to serve many customers and may not be a perfect fit for the radiology department’s local workflow.

Development of a custom solution has many advantages. ROCKET has been built to fit and function seamlessly in our radiology practice. Its feature set is minimal, yet it is capable of integration with a wide range of AI algorithms via simple DICOM SR. ROCKET is able to capture and record algorithm validation data in production. The same familiar tool is used for validation of new algorithms before they are released into the practice. Rapid validation of “alpha” or “beta” algorithms enables AI researchers to quickly iterate on both algorithm performance and presentation. Evidence for FDA submission may be acquired using the same mechanism (see “Requirement: Enable Validation Studies” above).

While use of ROCKET is beginning to expand, initial radiologist feedback is very promising. Radiologists chiefly comment on the ability to decide on correctness of results. In many workflows, scanner or 3D Lab technologists post-process images and save directly into the patient record. Correction or removal of incorrect results is time consuming and detracts from the radiologist’s workflow, while ROCKET enables the radiologist to decide to allow results into the record, simply review for reference, or request changes before entering results into the record. Secondly, radiologists are pleased with the integration into the PACS and rapidity of reviewing results, finding ROCKET an intuitive and rapid means to quickly review AI results.

ROCKET has several limitations. As a display-only solution, radiologists are not able to interact with regions of interest for correction or adjustment of results. To address this limitation, segmentation algorithms produce DICOM segmentation or DICOM GSPS objects that may be edited in vended, advanced visualization applications. The design also prohibits dynamic execution of algorithms. ROCKET must be employed in conjunction with an orchestration engine to select Series and Studies for inference by AI algorithms, only then is ROCKET able to display cached results. In practice, this is not a severe limitation as inference on large datasets may require several minutes of processing time and inference by the algorithm, prior to reading the study, is the preferred workflow.

ROCKET addresses only a small subset of potential AI applications. Specifically, ROCKET displays algorithm results and functions as a “tollgate” for the radiologist to rapidly incorporate images into the record (Accept), flag or ignore unusable results (Reject), or request manual correction if possible (Rework). While this functionality is very useful, it is limited and was chosen for ease of implementation and ease of integration into the workflow. More complex AI applications would require a greater degree of interaction with image data and present an obstacle to implementation. For instance, consider an AI algorithm that augments tracing of contours for radiotherapy. Such an algorithm would require a deep integration with the user interface, careful consideration of user experience, and study of time efficiencies gained and lost. Development and implementation of universal image editing and segmentation algorithms remain an open problem.

Conclusion

We have presented our use cases and requirements for a system for rapid review of AI results in a clinical workflow. ROCKET has been successfully implemented and integrated into our radiology workflow and serves as the interface for radiologists to access AI results. While simple in scope, ROCKET has proved to be a useful tool for integration of AI results into the workflow. Future work includes development of tools to enable continuous learning, measuring workflow impact of AI, and exploration of simple methods to interact with and correct AI results.

Author Contribution

Concept and design: D. Blezek, P. Korfiatis, L. Olson-Williams, Drafting the manuscript: D. Blezek, P. Korfiatis, Software development: L. Olson-Williams, Revising the manuscript critical for important intellectual content: P. Korfiatis, L. Olson-Williams, A. Missert, Approval of the manuscript to be published: D. Blezek, P. Korfiatis, L. Olson-Williams, A. Missert.

Funding

This work was funded by internal departmental resources.

Data and/or Code Availability

Code referenced in this paper is not available for dissemination.

Declarations

Ethics Approval

This study did not involve human research and no ethics approval was required.

Consent to Participate

This work did not involve human research and, thus, not consent to participate was required.

Consent for Publication

This work did not involve human research and, thus, not consent to publish was required.

Conflict of Interest

The authors declare no competing interests.