DEWEY: The DICOM-Enabled Workflow Engine System

Abstract

Workflow is a widely used term to describe the sequence of steps to accomplish a task. The use of workflow technology in medicine and medical imaging in particular is limited. In this article, we describe the application of a workflow engine to improve workflow in a radiology department. We implemented a DICOM-enabled workflow engine system in our department. We designed it in a way to allow for scalability, reliability, and flexibility. We implemented several workflows, including one that replaced an existing manual workflow and measured the number of examinations prepared in time without and with the workflow system. The system significantly increased the number of examinations prepared in time for clinical review compared to human effort. It also met the design goals defined at its outset. Workflow engines appear to have value as ways to efficiently assure that complex workflows are completed in a timely fashion.

Background

Workflow is a widely used term to describe the sequence of steps to accomplish a task. Improved workflow should improve efficiency and quality. Reports on the application of information technology (IT) in health care describe the need to adjust workflow to adapt to the electronic tools [1–3]. It would seem better to build optimal workflows and adapt automation to assist in the adoption, implementation, and adherence to those workflows. While there have been some attempts to support health-care workflow with IT, most currently vended radiology IT solutions support only simple linear sequences of steps with little flexibility for exception handling (e.g., support for corrective actions [4]) or more complex forms of interactions with users (i.e., iteration of initial results from either an algorithm or human with refinement by a human expert). Most health-care information systems are driven by databases with a fixed schema, and hence, a fixed workflow. Typically, each step in workflow is represented as an integer status value for that examination/sample/patient. Finding the work to be done is accomplished by querying the database for all entries with a certain status. The database increments the status value when a step is completed. Another query finds the entries with the next step/status. The problem with this approach includes that it does not handle nonlinear workflows well and it can be a challenge to recover processing state when there is an outage. In addition, traditional workflow support has focused on segments of a complete workflow (e.g., inputting the correct parameters for an MRI scan) and not encompassed operations of an entire department let alone enterprise. No commercial health-care IT solutions that we are aware of provide tools for graphically describing and updating workflow and monitor the status of work-in-progress in a department.

In contrast, a workflow engine is a technology designed to coordinate humans and automation to accomplish a task. Workflow engines typically have a database within them, but they also classify work items with one or more meta-tags. Such tags are then used by an “orchestrator” process to direct the work item to one or more work steps, enabling more flexible work patterns, user-friendly descriptions, and superior methods for error recovery. Flexibility is achieved since new tags and algorithms can be created without changing the database schema. One prior study of workflow engines in health care suggested that flexibility was the key and actually proposed a taxonomy of different types of workflow flexibility [5]. Another study pointed to the need for a workflow system to support decisions and activities of humans and not constrain it with inappropriate tools or decision options [6]. This last work also pointed to challenges of existing systems to sense available resources and to match that to business requirements. Another recent description of workflow engine technology being applied to health care (though not imaging) describes using a free/open source software workflow engine for aiding decision support [7]. This system includes tools for graphical creation and maintenance of workflows and an engine that executes the workflow descriptions. It used industry standard language for describing workflow. The focus is very narrow—clinical decision support for one segment of a clinical practice—but it appears that with proper interfaces, it could provide for broader workflow automation.

We have previously described the use of a DICOM-enabled workflow engine in our institution [8]. The advantages included efficient management of study routing, strong support for phased implementation of practice changes, new clinical tools, and a central point for understanding practice data (dashboarding). Unfortunately, the underlying technology (Websphere Process Server©, IBM Corporation, White Plains, NY) made it very difficult and expensive to propagate, particularly for facilities that lacked expertise in WPS. To enable support by our own IT team, that system was replaced with a newly designed system that we describe here.

Methods

Efficient workflow requires the orchestration of multiple IT systems. In an imaging department, this includes imaging devices (typically producing DICOM images), an information manager (the Radiology Information System or RIS), the image display and manipulation system (Picture Archival and Communications System or PACS), and a data archive (also a part of PACS). It is also necessary to communicate requests and results with the electronic medical record. Increasingly, more sophisticated tools like computer-aided diagnosis (CAD) and 3D rendering tools are being used in medical imaging. However, most imaging IT systems were designed at a time when these were not common, and they are not flexible enough to natively support these new processing stages in more complex workflows. Consequently, most departments rely on email or telephone to coordinate the workflow steps, resulting in inefficiency, errors, and poorer quality service. The integration of multiple hospitals in larger health-care networks further drives complex workflows, as individuals attempt to interpret examinations from many locations, with the locations being dependent on time of day, day of week, licensing, and credentials of the physicians. To enable such orchestration, a method for describing these steps becomes critical. Such a description should be standardized so that everyone understands what is being done and to allow comparison between facilities. To our knowledge, the only lexicon devoted to workflow in health care is that being developed by the Society for Imaging Informatics in Medicine [9] which may become a part of RADLex [10]. This lexicon describes standard terms for approximately 100 workflow steps in a medical imaging department. Having a standard lexicon for workflow is important because it enables standardized descriptions of best practices, and it enables practice comparison. The implementation of a workflow engine that can leverage a standard lexicon is an important innovation that will also help improve the ability to compare and identify best practices that can improve both research and health care.

As pointed out above, an initial prototype relied on complex and expensive solutions to implement the orchestrator. Building on lessons learned, we determined that certain properties were essential to an effective workflow management system: reliability, scalability, “auditability,” and flexibility. We have now implemented a new system that achieves those design goals. This system provides such functions as: DICOM send/receive, GUI-based workflow authoring and maintenance, the ability to launch compute-intensive image manipulation tasks as part of a workflow, the ability to create human task lists and launch tools to perform that enable a manual human task, management consoles that allow operators to see the status of exams, and tools for monitoring and managing the system.

The conceptual architecture of the system is shown in Fig. 1. That diagram shows five major components: DICOM receiver and sender, a message queue, a database, a workflow engine, and a compute server. The fifth component is more variable in order to enable flexibility: the compute nodes (e.g., supporting the CAD applications, analytic calculations, measurements, etc.) that are launched by the workflow engine using a variety of methods, which are loosely federated via a grid architecture. In particular, we are able to utilize a mixture high-performance GPU-based compute nodes, grid computing, and more traditional Windows© or Linux© applications, depending on the specific needs of the algorithm.

Fig. 1.

High-level architecture and communications of DEWEY. In step 1, the DICOM receiver submits a message to the queue indicating it has received an image and its filename. The DICOM receiver writes the image to a cache in step 2. In step 3, the workflow engine retrieves the message of a new image, and a “classifier” determines the properties of the image and applies a tag and puts that on the message queue. Another part of the workflow engine waits for images tagged with its tag and launches a workflow for the examination that has images with that tag. A compute server uses the image data on the cache to compute a result. The workflow engine then collects those results and typically would send them out using the DICOM sender

The DICOM receivers we have implemented are based on the open-source DCM4CHEE [11] code base. The architecture allows any number of receivers to be implemented as required to scale to large image volumes. In our current implementation, a single receiver is able to sustain image receive rates of 25 CT images per second. A cluster of N receivers behind a load-balancing switch scales the cluster performance approximately by N except when the communication pathway to the image storage cache became saturated. Testing has borne out this nearly linear scalability.

The message queue receives the DICOM UID from the DICOM receivers and enables all “subscribers” for DICOM notifications to become aware of new objects. By design, the message queue does very little in order to assure high performance and reliability.

The database stores the image pointers and associated metadata for a configurable amount of time. In clinical practice, the images and results are stored elsewhere, and we have configured our store to last only 30 days to maintain performance. A JDBC database connection allows us to use any popular database including MySQL, Postgresql, or commercial databases like Oracle or DB2.

The workflow engine we have selected is Activiti (http://Activiti.org). As is true for other components, the modular design allows substitution of other workflow engines into the system, but we prefer to use this workflow engine because it is mature, reliable, scalable, has good graphical workflow design tools, and uses standard workflow descriptions (BPMN [12]). The workflow engine subscribes to the message queue, and when an image is received, it retrieves the appropriate meta-information from the database to classify the study and determine which workflow(s) should be applied to the image(s). This architecture is essential to achieving its desired properties. The message queue is central and is a potential bottleneck. Consequently, the messages are very “light” and simply indicate the presence of an image, along with any “tags” that have been assigned. When an image is first received by one of the DICOM receivers, it has no tags.

A classifier controls which tasks are to be done. It enables workflow orchestration whether by humans or computers by tagging a work item with numerous features. When the classifier receives the message of a new image, it looks at its properties and adds tags to it. For instance, for our MRA aneurysm detection algorithm [13], we have a classifier that looks for DICOM tags that indicate that the modality is MR, that the pulse sequence is a Time-Of-Flight MRA, that the Head Coil was used, that the slice thickness was less than 2 mm, and that there are at least 100 images within the series. If all tests are true, it adds the tag “DoAneurysmDetection” to the ImageIdentifier and places that on the message queue. The aneurysm detection algorithm is monitoring the queue, and when it sees the tag, it will call the database, asking for the directory where the images are stored and begin the aneurysm detection algorithm. When it is complete, it will place a message on the queue with the new images and tags indicating these are new CAD images. For the simpler case of a CT, if the exam was acquired with thin slices and obtained with a certain low radiation technique (i.e., below a certain tube current), the classifier will tag the item with a “low-dose” tag which enables a CT denoising algorithm to recognize it. The workflow engine supports linear, branching, and looping workflows based upon the studies' properties and defined protocols. At present, only DICOM information is available to the classifier, but we are planning to add an HL7 receiver, which will give it access to the additional information present in the RIS order.

Once the workflow engine identifies the compute task(s) to be done, it executes the appropriate process with appropriate inputs (usually the directory where they are stored) and monitors it for completion. When complete, the results are collected and the next step in the workflow is executed. For interactive tasks, an entry is typically sent to a web page worklist; after the human completes the required task, the item resumes automated execution with the proper context.

Results

The Activiti engine allows drag-and-drop style workflow development allowing nonprogrammers to develop and maintain workflows. An example workflow shown in Fig. 2 was developed by one author after 1 h of training on Activiti. This particular workflow implements the CT Denoiser process alluded to in the “Methods”.

Fig. 2.

An example workflow developed for processing of low-dose CT exams

Because the system is an infrastructure, it is somewhat difficult to measure its full value. Anecdotally, we know that it is much easier to build and maintain complex workflows compared to traditional routing tables. We also know that it is fairly easy to implement new workflows as new tools or practices come into play. The impact is most noticeable when the workflows are complex but well-defined.

One example workflow for which we have more data is as follows. It has been demonstrated that image registration and subtraction can improve both the efficiency and accuracy of radiologists in assessing changes in disease [14–16]. We have also described a more sophisticated change detection algorithm for brain tumors in MR imaging [17, 18]. However, the penetration of registration/subtraction or other forms of change detection into clinical practice has been low. This is likely because the registration must be done on the correct pairs of images (e.g., the post-contrast T1 images) from each examination, and the resulting images must be conveyed to the PACS quickly to avoid negative impact on the clinical practice. The alignment calculation can be slow, and doing more sophisticated change detection can take several minutes. Efficiency is significantly reduced if these computations are not performed before the image interpretation step. The challenges of this task are therefore several: identify that an exam is a candidate for change detection, find the correct matching series on a prior examination, register the two series, perform the subtraction, publish the result to PACS, and do this all quickly without slowing the practice. It takes knowledge of the image archive tools and imaging (e.g., MR series or CT series properties) to accomplish this task. There must also be rules about what constitutes a match—TR and TE time ranges, slice thickness ranges, and orientation computation (many series are now called “oblique” requiring calculation of directional cosines). In all examples, we are aware of where this is performed; a human relies on the series description to find a “match.” In the example, we describe here an automated brain tumor change detection algorithm requires axial T1, T2, and post-contrast T1 images from a current and prior examination.

We collected baseline compliance to the change detection protocol when routing was performed manually. During that time, the technologist running the MRI scanner would send the series noted above to the change detection server. We asked the desk support personnel to retrieve the prior brain MRIs on these same patients from the image archive system to avoid loading too many tasks on the MRI technologist. Once old and new examinations had been sent to the change detection server, it would require about 15 min of compute time to create the change images. These were then made available to the interpreting radiologist.

During the second phase, the workflow engine would classify the images from the MRI scanner and create a “tag” indicating that an examination was a “brain tumor protocol” (that is it was scanned in a way that we use for brain tumors). It would then query the image archive for brain MRIs on that same patient and determine if there was a prior brain tumor MRI. If so, it would send both the current and old examinations to the change detection server.

In a review of the number of examinations submitted for the change detection algorithm, we found that only 89 of 306 cases (29 %) had results available in time for the radiologist interpretation over a 4-week period prior to implementation of the workflow engine. During the 4-week period after workflow engine implementation, 291 of 298 cases (98 %) were available (the seven cases failed due to the algorithm either crashing or taking too long to retrieve old cases and compute the result).

During the manual phase, radiologists found that they we both slowed and often did not have results available. Consequently, most reverted to the prior interpretation process and estimating tumor progression “by eyeball.” With automated workflow, compliance was nearly total.

Conclusions

The US health-care system is facing a crisis of high-cost care delivered in a one-off fashion. It is possible to deliver a high-quality product at a low cost, but only if there is an appropriate effort to determine the optimal process, deploy system to assure that best practices are followed, and use humans only when humans are required. Personalized medicine to individual patient needs is entirely possible and desirable, but requires a system that properly leverages all available information in a reliable and timely manner. The complexity of medical care makes it infeasible for a human to execute an optimized care plan for each patient perfectly and quickly. Workflow engines appear to be a useful adjunct to human caregivers providing a mechanism to (1) document the optimal care process and the required information, (2) provide a way to assist and assure that the optimal care process is adhered followed, and (3) assist in the communication between the health-care team members.

We have implemented a workflow engine and extended it to work well with medical images. This has improved efficiency and quality in our department. We believe it represents an important new tool for health-care facilities. We hope to apply it more broadly by adding the ability to process other medical information such as HL7 messages.