Databases, including that of a RIS, are fine for managing simple, linear workflows: Think scheduling, completing and interpreting exams. If you add in a step that makes things just a bit more complex—even something as seemingly basic as checking if the patient is in hospital or at home and needs an appointment reminder—then the works can quickly gum up.

Enter workflow engines, which can keep things humming even when the work steps get a lot more intricate. As Bradley Erickson, MD, PhD, put it so succinctly at RSNA last fall: “Databases are designed for, and do a great job of, storing and retrieving data. Workflow engines are designed for workflow.”

Erickson, a Mayo Clinic radiologist and researcher—and something of a workflow engine pioneer and evangelist—laid out the basics of adopting workflow-engine technology in radiology-specific settings.

In its plainest form, a workflow engine (WFE) is software that manages, executes and monitors business processes, step by step. Importantly for radiology, it also can capture and prompt human attention to error states. Best of all, Erickson said, a WFE is a computer language that can represent itself graphically and engage users intuitively—and try getting a database to do that.

WFEs are widely used in manufacturing, banking and other major industries, but in healthcare, not so much—yet.

“There are great workflow engine technologies out there,” Erickson said. “They just haven’t made their way into the radiology space or the hospital space. [Off the shelf], they don’t understand things like DICOM and HL7. We need to go knocking on the doors of our vendors and push them to use this technology for our sorts of workflow matters.”

Erickson described how his department built its own WFE using an open-source platform called Activiti. “We put in the various DICOM tags that are important for making decisions,” he said, giving as an example signal weightings for MRI such as echo time and repetition time. “We put that on a message bus that goes to the workflow engine, and the workflow engine is monitoring that message bus.”

 “You do need to have somebody who can do a little bit of DICOM plumbing and then can connect it to the workflow engine in a way they choose,” he said. “We did it using a message queue, but you could also email the DICOM tags.”

Spin control

One way to use a WFE in a radiology practice is to apply it to managing people and processes. The technology is a natural for that, Erickson said, because it excels at handling exceptions to rules.

“When you can handle error-bound conditions without breaking a sweat, that’s when you know you have a top-performing department,” he said. Having an agreed-upon way of handling errors, one that can be presented as a process diagram, “gets much better buy-in. And the workflow engine keeps you on the rails when errors actually happen. People don’t spin out of control because of some concern or some unexpected condition.”

Erickson touched on some other benefits of WFE adoption. He said they:

• illuminate details of error-bound situations as they cause exceptions, pointing the way to proper responses;
• recover quickly and completely from fault conditions, including scary situations like computer crashes;
• improve productivity because they allow automation of everything that potentially can be automated; and
• facilitate workers and managers who need to see, agree and document business processes.

“Most people can understand a flow diagram,” Erickson said, expounding on that last point. “Most people probably could not understand an SQL query that accomplishes the same thing.”

WFEs “make you more nimble,” he added, “because they allow your business to change and your processes to update much faster and much more efficiently.”

Finally, WFEs improve accountability. “Data is consistently acquired,” said Erickson. “That means everybody can see how their steps are being performed.”

WFEs also should be able to assist in measuring and improving efficiency, gathering and presenting data showing “where all the events actually happen and what the delays are between those steps,” Erickson added. “And they should minimize errors, because they kind of force the humans to be on rails. Your workflow engine is going to say, ‘This is the next step. You’re not allowed to go left, you’re not allowed to go right. Here is the right next step. Please hit Go.’”

Less work, better results

Erickson next discussed how his department set out to apply its homegrown version of the technology. This they dubbed DEWEY, for DICOM-Enabled Workflow Engine System. (To keep things fun as well and functional, they are developing HEWEY and LEWEY, for, respectively, HL-7 and natural-language-processing versions).

Currently, DEWEY is monitoring the output of about 26 MR scanners and 20 or so CTs at the Mayo Clinic, where a CAD-type de-noising algorithm is applied to low-dose CT studies and a brain tumor change-detection algorithm is applied to brain MRI.

If DEWEY sees that an MR study with the three required sequences has been output, it queries the PACS to see if there is a prior study with the three sequences. If so, DEWEY sends the two examinations to the change-detection server.

Prior to enlisting DEWEY’s assistance, technologists and front desk people had to intervene to send the studies and requisite priors (with specific pulse sequences) to the change-detection server.

“Ultimately, we were missing a large number of examinations. I knew that we’d been missing some, but I didn’t know how many,” Erickson said. Everything from simple forgetfulness by desk staff to incomplete handoffs by technologists during shift changes could potentially disrupt the flow of data into the database for change detection.  

DEWEY now has a significant operational achievement under its belt: The department went from sending fewer than 20 exams per week into the change-detection system to more than 50.

“We’re reducing the workload on people to zero,” said Erickson, “yet we’re actually getting better quality because now all the results are there in the most time-efficient fashion.”

Erickson concluded with an analogy.

“If an earthquake hit Minnesota, we probably don’t have an earthquake response plan,” he said. “In that case I wouldn’t want to have a workflow engine tell me what to do. Humans need to deal with the totally unexpected stuff that happens. But workflow engines should be dealing with the expected exceptions.”