Tasks flow with InterSystems IRIS Workflow Engine - Configuration

In our previous article we presented the general concepts as well as the problem that we wanted to solve by using the task engine integrated in InterSystems IRIS, in today's article we will see how we configure an interoperability production to provide a solution.

Workflow Engine Configuration

First we are going to define the roles of the tasks that we are going to manage, in our example we are going to define two types:

• AutomaticBloodPressureRole: to create automatic tasks that will have no intervention from the user.
• ManualBloodPressureRole: to create those tasks that the user must manually validate.

It will not be necessary to assign users to these roles since we will do it later as we go along as we receive HL7 messages from different patients.

We also do not need to add IRIS users to the Workflow since we will do it by code from production.

Production setup

For our example we are going to create a production within a NAMESPACE created ad-hoc and which we have called WORKFLOW. It will be in this production where we will include the business components that we need.

Let's start by explaining the simplest components:

Business Services

• HL7_File_IN: responsible for collecting HL7 files from a specific server path that will simulate receiving messaging from a medical device.

Business Operations

• AutomaticBloodPressureRole:component of the class EnsLib.Workflow.Operation, with the name of one of the defined roles that we will use to generate in our Workflow the tasks that will not involve direct interaction with the user.
• ManualBloodPressureRole: similar to the previous Business Operation, but in this case the tasks we generate will require the user to intervene directly to close them.

Let's now see in detail the Business Process that will manage the flow of information and the creation and management of the tasks involved in our cycle.

Workflow.BP.BloodPressurePlan

This Business Process is of the BPL type and will be responsible for creating the tasks involved in patient care and capturing the response, both from the patient and from the medical device that will send the information related to blood pressure levels.

Start of the process:

In this part the flow does the following:

1. Checking user: checks the user received in the received ADT^A08 message and if it exists, continues moving through the flow, otherwise it creates the user in IRIS and assigns it to the roles defined in the workflow. To assign users to the role, it runs the following command:

   /// Workflow user creation
   set sc = ##class(EnsLib.Workflow.UserDefinition).CreateUser(username)
   /// Assigning Workflow user to the role
   set sc = ##class(EnsLib.Workflow.RoleDefinition).AddUserToRole(role, username)

2. Get automatic task: Since in this flow we are going to manage both automatic and manual tasks, we must check if there are pending automatic tasks for the user for the patient received. This is relevant since if there are pending automatic tasks it means that we have had a previous reading whose values exceed normal levels. We will do the checking directly on the TaskResponse table where all the created tasks are saved, the query will be as follows:

   &sql(SELECT ID INTO :taskId FROM EnsLib_Workflow.TaskResponse WHERE TaskStatus_AssignedTo = :username AND TaskStatus_IsComplete = 0 AND %RoleName = :role)

3. Getting count of OBX: we retrieve the number of OBX segments from our HL7 message.
4. Check OBX values: we go through the OBX segments and extract only the data related to blood pressure.
5. Pending tasks?: As we said in point 2, we check if we have a pending automatic task or not.

First blood pressure reading:

In this part of the flow we will deal with those messages that are not generated by a first reading that exceeds the defined maximum blood pressure levels.

1. Check pressure: We check if blood pressure levels exceed pre-established limits; if they do not, the process will conclude without the need to do anything else. Otherwise it will be necessary to create the necessary tasks.
2. Create manual task: The blood pressure has exceeded the defined safety levels, so it will be necessary to create a manual task in which we will inform the patient of the situation, indicating that they must take a second reading. Let's see the configuration of this activity.

We will invoke the Business Operation ManualBloodPressureRole which will be in charge of generating the task by passing it a message of type EnsLib.Workflow.TaskRequest.

We will define the actions that the patient can perform separated by commas in callrequest.%Actions, in this case we have only defined the "Accept" action.

We configure the message that will be shown to the patient in callrequest.%Message.

We assign the patient the created task by defining her username in callrequest.%UserName.

Finally we will indicate a subject or title in callequest.%Subject and a priority (between 1 and 3) in callrequest.%Priority.

Create auto task: similar to the previous activity configuration, but this time we will send it to the Business Operation AutomaticBloodPressureRole. This task will be the one that will be kept waiting for the patient's second blood pressure reading and will be the one that will cause any new message received by production for this patient not to generate new tasks by obtaining a false in the Pending task? activity.

Wait for tasks: This activity will keep the task flow on hold until the task and manual are completed, that is, until the patient closes the alarm created by ManualBloodPressureRole and the IRIS production receives a second message from the medical device.

Check if warning: We will get to this activity once the previous pending tasks have been closed. At this point we will check if the closing of the automatic task has received a new reading with levels that exceed the maximum configured blood pressure values (the task will be closed with a warning action) or not. If the measurement is less than the maximum values, the process will conclude. If the measurements exceed the maximum values, you will move on to the next activity.

Warning task for doctor: A manual task is created to inform the doctor assigned to the patient that the patient may be suffering a crisis.

Warning task for patient: we inform the patient with a new manual task that his doctor has been informed of the situation.

Second blood pressure reading

This part of the flow will only be accessed when there is a previously created automatic task that has not been completed.

1. Check pressure: We again validate for the message received whether the blood pressure values exceed the limit or not.
2. Close normal task: If the levels do not exceed the maximum values, we will close the pending task with the CompleteTask method provided by the EnsLib.Workflow.TaskResponse class that our task instantiates. The parameter used will indicate the action taken, in this case we will indicate that it is a false alarm by passing the value FalseAlarm, we could define any other one we want.
3. Close warning task:Same as in the previous case, with the difference that in this case the action that we pass to the Workflow engine will be Warning and that it will be the value that the "Check if warning" activity that we have seen previously will check.

As you can see in the following diagram (it is not literal but you can get an idea of how it will work), our task flow will work with 2 "threads" or "processes":

The first thread/process will remain open in case it is necessary to wait for a second reading and it will be the second thread/process that will cause the reactivation of the first open thread upon receiving said second reading, thus concluding the defined task flow.

Conclusion

As you can see, configuring a task flow in a BPL is quite simple, and you can simulate automatic and manual tasks without much complication. In the next and last article we will see how users can interact with their tasks from an external application.

Thank you all for your attention!