• Stateframe Engine implemented as a .NET object which can be installed on one or more servers and/or clients run against a shared UDP.
• Application Programming Interface (API) which has methods for the three main objects: case, process object, and activity. There is a separate API for the organisation compon- ents.
• Reusable Components these are held externally to the system to make it usable and ease the customisation.
• Automation Agents working asynchronously as hidden users for task automation, not ne- cessarily as a direct reaction to a user’s input.
• Time Keeper (also called overdue scanner) which synchronises the processes and ensures continuity of the flow.
• Security Client maintains the groups, users, rules, and roles.
• Process Mapping tool uses Microsoft Visio with a custom template. The mapped maps are dynamically stored in Stateframe’s database.
• Administration Tools deal with the UDP configuration, versioning and case investigations. • Code Generation tool is used to interpret the map into code which can be run by the user. • Web Client this is provided through a web based ASP.net client. It is an interface through
which a user can access the following: – Intray of the user with awaiting tasks – Case Viewer of progress
– Activity Frame – Case Search
9.5
How Stateframe Work
This section explains how the WFMS/Stateframe system operates. The process to map the workflow logic into the system, what happens when a process is activated, and how actions are activated. This links back to the architecture of the WFMS engine (figure 9.4) and to the components in the physical architecture in figure 9.3.
96 9.5 How Stateframe Work
Figure 9.4: Stateframe’s Engine.
9.5.1
Process Map
To map the processes into the workflow engine, the logic needs to be mapped into the process map. This will automatically be translated into a web client (figure 9.4) page using the code generator. It will also be mapped automatically to the workflow engine’s database UDP which in this stage will contain information about the processes flow logic. Security and administra- tioninformation settings should be assigned to each process. Security will involve authorising organisations, roles, and/or users to deal with case information, while administration involves authorising users to deal with the workflow engine’s settings at the administration level. A pro- cess undertaken by a certain role will be associated with its role to be linked later to the case in progress. Moreover, processes within the logic that might involve this action will be coded to call the action appropriately. The application’s case specific information will be stored in the WffICP database.
In the healthcare scenario, the logic will be the clinical guidelines, as given in an ICP represent- ing the treatment flow. This is mapped into the system through the process mapping tool. The process mapping tool will dynamically translate the information about the process map into the UDP. Stages within the treatment journey involving a care team professional will be associated with the person to keep a track of the carers involved in the treatment process of the patient. At some points in the treatment flow an action may be needed. At these points, the logic of the action will be programmed to ensure the actions execute as expected.
9.5 How Stateframe Work 97
9.5.2
Active Process
When a process is activated, the process connects to the workflow engine’s UDP to read the case information and its related actions. This might also involve a scan into the healthcare information system’s related database (see figure 9.3) to collect additional details about the case. Moreover, if the process is associated with a role, the system links the role and the professional to the patient and keeps a record of this linkage. Processes can be either a web client page, automatic agent, and/or reusable components. Web client pages provide the users with access to their own intray which shows their received messages and awaiting tasks. Users also can view and search their cases. Automatic agents are usually not visible to the users as being automatic it is a hidden process that performs a certain task without the need for a user’s input.
In the healthcare scenario, at the different treatment stages some actions might be required to support a patient’s care coordination. At each treatment stage, the system fetches the required actions. This action can be directly related to the treatment stage or related to a combination of the treatment stage and the treatment history , which requires access to the healthcare in- formation system’s related database. Moreover, some treatment stages, such as clinics and tests must be run by an appropriate care team professional member. In this case, the system adds the profession and the exact care team professional to the patient’s related part in the WffICP’s database. Other stages of the treatment process, such as referrals and scheduling can be done automatically through the automatic agents.
9.5.3
Active Policy
When a policy trigger is activated, the system identifies the appropriate action to be processed and the affected professional role (if any). In this case the system takes actions with consid- eration of the involved roles and the exact professional, as appropriate. Policies can start also when a trigger of an automatic agent or a time keeper is activated. Actions can be either an automatic process or a prompt which requests a user’s input. These usually affect the routing flow direction.
In the healthcare scenario, policies such as referrals, notifications and alerts will need to be sent to a particular role or professional. These will be identified in the patient related data. Some of these actions such as a referral will most probably be initiated by a healthcare professional, while others such as alerts might start automatically due to a change happening in the flow or the data. Overdue tasks can start a policy without being initiated by a healthcare professional, as a reminder of tasks or messages that have not yet been selected or processed and in some cases this is the result of a waiting time set initially by a healthcare professional being exceeded.
99
Chapter 10
Implementation and Design of WffICP
Overview
This chapter introduces the selected scenario, breast cancer diagnostic and treatment options. This is followed by an identification of the stages within the selected scenario that need sup- port. The mapping process of the scenario into the selected WFMS (Stateframe) will also be explained. This will include the process of mapping processes and activities as well as defining process objects and cases. Furthermore, the coding that is incorporated into the system and how the system is programmed to meet the ICPs requirements will be clarified.