Tasks flow with InterSystems IRIS Workflow Engine - Introduction

For some time I have been planning to do some type of proof of concept with the Workflow functionality, which, like so many other functionalities present in IRIS, tends to go quite unnoticed by our clients (and for which I say mea culpa). That's why I decided a few days ago to develop an example of how to configure and exploit this functionality by connecting it with a user interface developed in Angular.

To avoid a very long article and make it more accessible, I am going to divide it into 3. In this first article I will present the functionality of Workflow as well as the example that we are going to solve. The second article will go into detail about the configuration and implementation of the production that will be responsible for managing the Workflow. Finally we will show how to access the information available in our Worflow through a web application.

InterSystems IRIS Workflow Engine

What better way to explain what this Workflow functionality is than to copy the description given in the IRIS documentation.

A workflow management system automates the distribution of tasks among users. Automating the distribution of tasks according to a predefined strategy makes task assignment more efficient and task execution more responsible. A typical example is a help desk application that accepts problem reports from customers, sends the reports to members of the appropriate organizations for action, and, once the problem is resolved, reports the results to the customer.

InterSystems IRIS Workflow Engine provides a much higher level of functionality than traditional, stand-alone workflow management systems.

Where do we find the Workflow functionalities in our IRIS? Very simple, from the Management Portal:

Let's briefly explain each of the available options before getting into the example project.

Workflow Roles

This option refers to roles in which we will classify the users who will use the functionality. The definition of role is somewhat confusing, I particularly prefer to see it more as types of tasks that we can create from our production. The name assigned to these roles must match the names of the Business Operations that we will later declare in our production to create tasks associated with said roles.

Workflow Users

IRIS users who can be assigned to different tasks will be associated with one or more roles. Users must be registered with IRIS.

Workflow Tasks

List of tasks created in the system with their associated information. From this window, tasks can be assigned to the different users corresponding to the task role.

What are these tasks? Very simple, the tasks are instances of the EnsLib.Workflow.TaskRequest class, the object of this type will be sent from the Business Process in which it has been generated to a Business Operation of the class EnsLib.Workflow.Operation and with the name of the role that we have previously created. This action will in turn create an instance of the EnsLib.Workflow.TaskResponse class. The Business Operation will not return a response until the CompleteTask method of the TaskResponse class instance is executed.

Workflow Worklist

Similar to the previous functionality, it also shows us a list of tasks with the information associated with them.

Workflow example

The project that you can find associated with this article presents a simplified example of a solution to a typical problem of health organizations such as the treatment of chronic patients. These types of patients require continuous control and strict monitoring for which in many cases the professionals involved in care do not have the most appropriate means.

In the example we are going to see how we can monitor patients with hypertension. We will assume that patients take their blood pressure daily with a blood pressure monitor that will send the reading to the server on which our InterSystems IRIS is installed. In the event that the blood pressure reading exceeds 140 systolic and 90 diastolic values, the patient will be informed that the blood pressure must be taken a second time after a certain time and, if the reading exceeds the limits again, both the patient and the doctor will be informed of the situation so that they can decide what action to take.

To do this, we will divide this task flow into two stages:

Stage 1: Receiving daily blood pressure reading.

1. Reception in the production of HL7 message with blood pressure measurements.
2. Checking the existence of the user in the system (and creating it if it does not exist), subsequently registering the user in the roles involved in the workflow.
3. Extraction of blood pressure data and comparison with the alert criterion.
4. If the data exceeds the alert criteria:
   1. Creation of a task for the patient informing them of the situation and requesting a new blood pressure measurement.
   2. Creation of automatic task to manage the second blood pressure reading.
5. If the data does not exceed the alert criteria, the process is closed until the next reading is received the next day.

Stage 2: Reception of second reading after the first reading exceeds the alert values.

1. Reception of the HL7 message with the second data reading.
2. Pending automatic task recovery.
3. If blood pressure levels exceed the alert criteria:
   1. The automatic task is closed indicating the warning status.
   2. A manual task is created for the doctor reporting the patient's situation.
   3. A manual task is created for the patient alerting them to the situation and that their doctor has been informed.
4. If levels do not exceed alert criteria:
   1. The automatic task is closed indicating that there is no danger.

In the next article we will go into more detail on the design of our flow chart in charge of reflecting what was stated above.

User interface

As you have seen in the attached screenshots, the user interface that InterSystems IRIS provides for task management is, to say the least, quite spartan, but one of the advantages we have with IRIS is that we can create our own API REST to manage our task flow in a very simple way, we will discuss this point in our last article.

To offer a friendly interface to users, we have developed a small web application in Angular using Angular Material that will allow us to create an interface simulating a mobile application.

This mobile application will connect to InterSystems IRIS using JSON Web Tokens and will make HTTP requests to a specific web application published in IRIS, in such a way that the actions taken by the different actors on the tasks are reflected in the defined task flow.

In the next chapter...

After this introduction to the Workflow functionality, in our next article we will show how to implement the task flow necessary to solve the example that we have presented using a BPL, we will configure the entire production and we will see what the main classes involved in the Workflow are like (EnsLib.Workflow.TaskRequest and EnsLib.Workflow.TaskResponse).

Thank you all very much for your attention!