Treatise Presentation

This morning I presented my treatise project before a panel of markers consisting of A/Prof. Simpson and Dr. Li. I managed to finish within the 9 minutes bracket and answered all the questions asked. Questions were asked on how many people were responsible for the project and also what sort of testing was performed on the workflow manager. The speech I have written is copied below for your reference. The speech puts the written treatise in context. The powerpoint presentation accompanying the speech can be downloaded here.

Introduction
Hi, as everybody in this room might be uniquely aware, the lack of efficiency in Sydney hospitals poses a tremendous problem, challenge and opportunity. Inefficiency lies in the interoperability between systems in different departments. This multi-systems-different-vendors configuration causes data and information to stop at each end point. Data or information is usually printed and bundled before it is moved to another department. This inefficiency leads to delays, overhead and lag in patient care and information processing as time is usually wasted in manually routing work. Opportunities are thus available to improve and streamline such interoperability and processes.

This is where the workflow manager, a component developed as part of my research project, comes in. The workflow manager facilitates the management, routing and execution of work items and allow user to refine and define customised workflows. The workflow manager belongs to the Generalised Clinical Information Management System or GCIMS family which I will talk about later on, in the session.

Overview
Hospital processes may be streamlined.
Earlier in the semester, another student and I visited RPA’s ICU and performed a six week analysis on the different workflows. What we found through the analysis was that many of the processes were not streamlined. What do I mean by streamlined? Many of the workflows were not efficient and inhibit time lags, overheads and inefficiencies from manual handling and processing. Paper forms were printed, used, filed and often lost. Patient information gathered piled up over time to an extent that it is no longer manually comprehensible or processable. There were limited inter-departments communication channels, which meant that data and information was simply shifted around the hospital manually.

Workflow manager manage and execute modelled hospital processes.
The workflow manager, attempts to capitalise from such inefficiencies by presenting an environment whereby user may electronically model, manage, execute and route works and workflows. Workflows were modelled using a customised XML schema named Workflow Definition Language. This model is then used by the workflow manager to route and execute work items.

Workflow manager, core component to GCIMS.
As previously mentioned the workflow manager belongs to the GCIMS family and is a core component of GCIMS. It will replace an existing simple workflow engine in the previous version of GCIMS.

Built to conform to industry workflow standard.
The workflow pattern specifications and design patterns used in developing the workflow manager conform to standard currently recognised by the industry. The engine in workflow manager was built in part to recognise and process industry defined workflow patterns including the sequence pattern (a pattern defining work items which are laid sequentially), the simple merge pattern (a pattern defining multiple work items which converge to a single work item) and many more.

The Problem
There are four main problems that are explored by this project.

Number one; there are many inefficient hospital processes.
As I have previously mentioned, one of the problems faced by hospitals is that there are many processes which are inefficient and these processes can be optimised and streamlined.

Number two, there are currently many single process which require the effort from multiple systems and paper forms.
This problem was elicited from the 6 week study at the RPA. The presence and use of multiple systems, not only present inconsistencies in work, but it also increases the chance of systems not being able to inter-operate with each other.

The third problem is the time lag and the high incompletion rate of work items arising from the manual routing of work.
The lack of automation in routing and completing work items mean that the completion of these items are delayed or even worse, not completed at all. An interview with an ICU manager revealed low work items compliance rate and in ICU, where many of the work items are legally binding, such low compliance rate poses a significant problem.

Last but not least, there is, currently the problem of significant overheads in the processing of information.
Medical professionals including doctors and nurses are sometimes forced to manually record data and sift through hundreds of printed pages. For example, on discharge of patient, a nurse is required to record all the medications that have been administered to a patient, on a standardised form. This is a time consuming procedure and the procedure could have easily been done in seconds through some sort of automations in the process. These overheads are significant problems which may be eradicated.

Workflow Manager
The workflow manager consists of four core components. Due to our time constraint, I will briefly talk about them.

To the left is the workflow engine. The workflow engine is core to the workflow manager and it is the component responsible for processing workflow model, routing different work items and facilitating the execution of these work items.

To the right of the workflow engine are the user manager and the workflow instance manager. These two components are helper objects for the workflow manager and the worklist manager. The user manager simply manages the administration of user and user information including user type, username, password, etc. The workflow instance manager is responsible for managing workflow instance related information such as current work items being executed, the user processing that work item and more.

Lastly, the final component in the workflow manager is the worklist manager. The worklist manager is responsible for managing worklist. What is worklist you ask? Worklist is a term often associated with workflows, it is a facility whereby users may retrieve work items and execute them through the workflow engine. In the current version of the workflow manager, the purpose of the worklist manager has been extended to allow for the manager to alter the status of work items and to also allow the manager to disable or enable work items.

Previous Work
In the past year, efforts have been concentrated on the development of GCIMS. GCIMS is series of integrated systems which is able to generate tailored information system for various medical environments at runtime. In the last year, a prototype GCIMS has been devised and it includes a simple workflow engine, a form builder, a form generator, a terminology server and a data analytics engine. The workflow manager will use the form generator to execute work items. A complete overview of GCIMS and its components is beyond the scope of this presentation.

Achievements
Individual achievements made through this project include a simple yet effective, workflow definition language schema, written using World Wide Web Consortium’s XSD definition, which allow users to model various workflows of varying complexities, a workflow engine (the heart of the system which is responsible for managing and executing work items), a user manager, a workflow instance manager and also a worklist manager.

Difficulties and Challenges
During the course of the semester I encountered several difficulties and challenges. The first being time and scope. Given that the project only spans around 14-18 weeks, it was difficult to carry out comprehensive and thorough analyses. Additionally, the scope of the development of the workflow manager was also constrained by time and resources. Other difficulties and challenges include the inability to implement reasonable security and user management layer. This was simply due to time constraints and the size of the security and user management domain. Although the workflow manager simply operates underneath services, an interface was still built to test the system’s functions. However, advanced usability factors were not thoroughly implemented. Implementing a user-friendly graphical user interface to test workflow manager’s functionalities was left as an extension.

Results
This project has resulted in a new proof of concept, generalised workflow engine that can be used in any domain and also flexibly adapt to changes in workflow definition language schema. Other results from the project include, a proof of concept worklist manager, user manager and workflow instance manager, each and every one made to work alongside the workflow engine and also integration of the workflow manager with GCIMS, replacing the existing simple workflow engine.

Conclusions and Further Work
Many further works are due to be completed in the next year. The workflow manager, with other components of GCIMS will together help to introduce realisable gains including elimination of overhead time spent in processing information, reduction in lag time from routing work, reduction of loss of information due to manual handling such as printed forms and more. Overtime, these gains will allow medical professionals to achieve information efficiency, help reduce errors in processing information and most importantly, lead to more time spent on patient care. Essential key improvements that can be made include improvements to the workflow engine algorithms, addition of security and user management layers to GCIMS and also improvements to the usability of the system. Lastly, the current proof of concept will be demonstrated at RPA’s ICU using real workflow model based on workflow analysed earlier in the semester. Thank you.

Treatise Submitted

I have submitted the final copy of my treatise. Now it’s off to preparation for presentation on Tuesday. Below is a statement of achievements copied from the treatise. The achievements made can be split into two separate groups of achievements. One is individual achievement and the other shared or joint achievements. Individual achievements are achievement achieved through my own independent work whilst shared or joint achievements are achievements by Richard Ly and I.

Individual Achievements:

• Developed a workflow manager which combines both workflow system methodology and functionalities of documentation management system and allow the processing of abstracted workflows written in WDL.
• Addition of such proof of concept workflow manager into the larger GCIMS project.
• An evaluation and analysis on the strengths and weakness of the current workflow manager prototype which may serve as a grounding for future development.
• Developed an extensible proof of concept workflow engine as part of the workflow manager which can flexibly adapt to changes in workflow definition language schema.
• Proposed and prepared ideas for further work in workflow user manager, worklist manager and workflow instance manager.
• Demonstrated the use of simple flowchart elements and simple XML structure to abstract and describe complex workflows.
• Provided extensions for the GCIMS project including additions to the GCIMS database management system, workflow engine, worklist manager, workflow user manager and workflow instance manager.

Shared or Joint Achievements:

• A system analysis of the Intensive Care Unit at the Royal Prince Alfred Hospital, Camperdown, Sydney demonstrating the inadequacies of their information environment in delivering on time information and workflow support to staff.
• A workflow analysis of the Intensive Care Unit at the Royal Prince Alfred Hospital, Camperdown, Sydney demonstrating how some of their processes have increased in complexity as a result of disparate and old information systems.
• A partial ideal software requirements specification for an intensive care information system that is mainly focused around the care of patient.
• Proof of concept Workflow Management System prototype demonstrating the ability to design form centric workflows that is independent of domain, that is, the workflow has been abstracted and decoupled from being hard coded into the system. This is to be implemented as part of a larger G.C.I.M.S project.

I will post a list of references in the next post

Reference List

Here is a copy of my reference list from my treatise outlining literatures and medias used in my research.

[B1] Abbott, K., R., Sarin, S., K., “Experiences with Workflow Management: Issues for the Next Generation,” 1994 ACM conference on Computer supported cooperative work, pp. 113-120, 1994. 

[B2] Adhikari, N., Lapinsky, S., E., “Medical Informatics in the Intensive Care Unit: Overview of Technology Assessment,” Journal of Critical Care, vol. 18, no. 1, pp.41-47, Mar. 2003

[B3] Anderson, J., G., “Clearing the Way for Physicians’ Use of Clinical Information Systems,” Communications of the ACM, vol. 40, no. 8, pp. 83-90, Aug. 1997. 

[B4] Apkon, M., Singhaviranon, P., “Impact of an electronic information system in physician workflow and data collection in the intensive care unit,” Intensive Care Med, vol. 27, pp. 122-130, Jan. 2001

[B5] Arpinar, I., B., Miller, J., Sheth, A., P., “An Efficient Data Extraction and Storage Utility for XML Documents,” Annual ACM Southeast Conference, pp. 293-295, 2001. 

[B6] Aversano, L., Canfora, G., De Lucia, A., Gallucci, P., “Integrating Document and Workflow Management Tools using XML and Web Technologies: a Case Study,” European Converence on Software Maintenance and Reengineering, vol. 6, 2002

[B7] Baeyen, T., (2004, May). State of Workflow. The Server Side. [Online]. Available: http://www.theserverside.com/tt/articles/content/Workflow/article.html 

[B8] Bondarenko, O., Janssen, R., “Documents at Hand: Learning from Paper to Improve Digital Technologies,” SIGCHI Conference on Human Factors in Computing Systems, pp. 121-130, 2005.

[B9] Bosman, R., J., Rood, E., Oudemansvan Straaten, H., M., Van der Spoel, J., I., Wester, J., P., J., Zandstra, D., F., “Intensive care information system reduces documentation time of the nurses after cardiothroacic surgery,“ Extensive Care Med, vol. 29, pp. 83-90, 2003. 

[B10] Budd, P., J., “Delivering Knowledge Based Data Representations to Hospital Information Systems, ” School of Information Technology, University of Sydney, pp. 1-87, Nov. 2006.

[B11] Chambrin, M., C., Ravaux, P., Jaborska, A., Beugnet, C., Lestavel, P., Chopin, C., and Boniface, M., “Introduction of knowledge bases in patient’s data management system: role of the user interface,” International Journal of Clinical Monitoring and Computing, vol. 12, pp. 11-16, Jan. 1995 

[B12] Chau, W., “A Product and Process Model for a Document-Centric Workflow Management System,” School of Information Technology, University of Sydney, pp. 1-80, Nov. 2006.

[B13] Chung, P., W., H., Cheung, L., Stader, J., Jarvis, J., Moore, J., Macintosh, A., “Knowledge-based process management – an approach to handling adaptive workflow,“ Knowledge Based Systems, vol. 16, pp. 149-160, 2003. 

[B14] Dourish, P., Bentley, R., Jones, R., and MacLean, A., “Getting Some Perspective: Using Process Descriptions to Index Document History,” Conference on Supporting Group Work, Phoenix, Arizona, United States, pp. 375-384, 1999

[B15] Fraenkel, D., J., “Clinical Information Systems in Intensive Care,” Critical Care and Resuscitation, vol. 1, pp. 173-179, 1999. 

[B16] Friesdorf, M., Konichezky, S., Grob-Alltag, F., Fattroth, A., Schwilk, B., “Data quality of bedside monitoring in an intensive care unit,” International Journal of Clinical Monitoring and Computing, vol. 11, pp. 123-128, 1994.

[B17] Georgakopoulos, D., Hornick, M., Sheth, A., “An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure,” Distributed and Parallel Databases, vol. 3, pp. 119-153, 1995. 

[B18] Hollingsworth, D., “Workflow Management Coalition The Workflow Reference Model,” The Workflow Management Coalition Specification, vol. 1.1, pp. 1-55, Jan. 1995.

[B19] Kappel, G., Lang, P., Rausch-Schott, S., Retschitzegger, W., “Workflow Management Based on Objects, Rules, and Roles,” ACM Computing Surveys (CSUR), vol 32, Iss. 1es, Mar. 2000. 

[B20] Keizer, N., F., Stoutenbeek, C., P., Hanneman, L., A., J., B., W., and Jonge, E., “An evaluation of Patient Data Management Systems in Dutch intensive care,” Intensive Care Med, vol. 24, pp. 167-171, Jan. 1998

[B21] Krishnan, R., Munaga, L., Karlapalem, K., “XDoc-WFMS: A Frameworkf for Document Centric Workflow Management System,” Lecture Notes In Computer Science, vol. 2465, pp. 348-362, 2001 

[B22] Lim, J., Joo, K., “Developing an XML Repository for Workflow Management,” TENCON 2004. 2004 IEEE Region 10 Conference, vol. 2, pp. 318-321, Nov. 2004.

[B23] Madhusudan, T., Zhao, J., L., Marshall, B., “A case-based reasoning framework for workflow model management,” Data & Knowledge Engineering, vol. 50, pp. 87-115, Jan. 2004. 

[B24] Metnitz, P., G., H., Lenz, K., “Patient data management systems in intensive care – the situation in Europe,” Intensive Care Med, vol. 21, pp. 703-715, 1995. 

[B25] Mul, M., Berg, M., and Hazelzet, J., A., “Clinical Information Systems: CareSuite From Picis,” Journal of Critical Care, vol. 19, no. 4, pp. 208-214, Dec. 2004.

[B26] Prins, J., M., Nellena, J., F., J., B., Koopmans, R., P., Langendijk, P., N., J., Bossuyt, P., M., M., and Speelman, P., “Electronic drug ordering system can be helpful to implement iv-oral switch guidelines,” Journal of Antimicrobial Chemotherapy, vol. 46, no. 3, pp. 518-519, 2000.

[B27] Saarinen, K., Aho, M., “Does the implementation of a clinical information system decrease the time intensive care nurses spend on documentation of care?,” Acta Anaesthesiologica Scandinavica, vol. 49, pp. 62-65, 2005.

[B28] Van der Aalst, W., Workflow Patterns, [Online]. Available: http://www.workflowpatterns.com/

[B29] Vlissides, J., Gamma, E., Helm, R., Johnson, R., “Design Patterns: Elements of Reusable Object-Oriented Software,” Addison-Wesley, 1995.

Treatise Submission

I am just preparing for the submission of my treatise. I have sent a copy to my supervisor for review and feedbacks. I am hoping to print and bind by tomorrow. Here is the conclusion I have written for the treatise:

The proof of concept workflow manager is a demonstration on how workflows in a non-business environment can be streamlined and abstracted for electronic processing. It has been shown that complex medical workflows may be abstracted diagrammatically using flowchart and simply as XML using WDL. The abstraction of workflows not only helps medical professionals to identify problems in current workflows but also provides them with the opportunities to streamline workflows. The prototype workflow management system also allows medical professionals to flexibly define, customise and design new or existing workflows.

The workflow manager, with other components of GCIMS will  together help to introduce realisable gains including interoperability between medical systems, elimination of overhead time spent in processing information, reduction in lag time from routing work, reduction of loss of information due to manual handling such as printed forms and more. Overtime, these gains will allow medical professionals to achieve information efficiency, help reduce errors in processing information and most importantly, lead to more time spent on patient care.

There are still opportunities and challenges that need to be realised and tackled before a full scale hospital implementation of GCIMS can be achieved. Nevertheless, it is hoped that with the introduction of workflow manager, workflow definition language schema and workflow builder into GCIMS, they can provide the grounding for the realisation of the benefits and opportunities described.

Workflow Manager Walkthrough

This workflow manager walkthrough section will use the following abstract workflow definition based on the Allied Health Professional workflow. The purpose of this section is to demonstrate the ability of the workflow engine to direct various works to various users and to also show the mapping between workflow elements and how they are processed in the workflow engine.

The workflow manager accepts a workflow definition XML file that conforms to the WDL. Upon initialising the workflow definition specified (in this case we have a workflow definition defining the Allied Health Professionals Workflow), a Document Object Model (DOM) tree is created from the XML definition file by the workflow manager using XML DOM. The workflow manager uses this DOM tree as a virtual map to navigate around different workflow paths. The current version of workflow manager auto-loads a workflow definition file from either, a database or from a file. The screenshot above is shown to the user upon starting the workflow manager. The user is prompted the choice to start a new workflow processing or continue an existing workflow processing using a unique workflow ID given by the program (see Exit/Continue Workflow Processing).

Processing Sequence Workflow Element

As workflow manager begins traversing through the workflow path, it first arrive at the sequence workflow pattern element ‘Review all ICU patients’. Here a medical history form needs to be reviewed or completed by an ahp (Allied Health Professional). Current prototype implementation of workflow manager does not distinguish between different allied health professionals, i.e. dietician, pharmacist, etc. It is hoped that this feature will be implemented in the near future. Once a form is completed, user may signal such completion to the workflow manager by typing in the status of the form. The workflow manager then moves to the next workflow element(s); in this case the ‘Examine Relevant health information’ sequence element and then the ‘Prepare execution plan’ sequence element.

Processing Exclusive Choice Workflow Element

The processing of an exclusive choice workflow element such as the ‘New ICU Patients’ shown above is similar to the processing of a sequence workflow element, however, with an additional condition processing. In our example, the workflow manager now moves off from ‘Prepare execution plan’ to ‘New ICU Patients’ where it assesses choice condition. Workflow manager prompts the user a question on whether there is a new ICU patient. Similar to form feedback, the user simply returns a true or false response to the workflow manager. Depending on the choice provided by the user, workflow manager will assess on the appropriate workflow path to move onto. The screenshot below shows the workflow manager proceeding to the ‘Patient Assessment’ sequence element upon receiving a true/yes response.

Processing Nested Workflow Elements

The next workflow element is an exclusive choice element ‘Order Medication?’. This workflow element differs from other workflow elements in that it is nested inside the ‘New ICU Patients?’ exclusive choice element. One of workflow manager’s core functionality is the ability to process nested workflow elements. The ‘Order Medication’ workflow element is processed upon the acknowledgement of the previous ‘New ICU Patients?’ workflow element. The screenshot above shows how workflow moves from showing form_patient_assessment for ahp to showing form_care_prescription for ahp, the form in the ‘Order Medication’ exclusive choice element.

Processing Action/Alert

The use of forms in a workflow can be limited in that some work may not require the use of form. As described earlier, WDL allows for extension to be applied to the form element. This extension comes in two forms; an action or an alert. That is a form can be extended to represent a simple action reminded or an alert. Our AHP workflow example include an example of such extension. The sequence workflow element ‘Brief other medical doctors and/or nurses as required’ contains a simple action reminding doctors to brief other doctors and/or nurses. From the screenshot above, we can see how the workflow manager deals with such extension. The workflow manager simply passes the message to the user without prompting the user.

Exit/Continue Workflow Processing

Thesis Structure Update

The following list is an outline of all the sections I propose to include on my thesis. Prof. Jon Patrick has reviewed section 1, 2, 3 and 5. Now I will complete sections 4, 6, 7 and 8 which covers system development related information, project management review and also final words on the project and where its heading in the future. The sections are as follows:

1 INTRODUCTION & BACKGROUND
1.1 OVERVIEW
1.2 RESEARCH PROBLEM & AIM
1.3 RESEARCH QUESTIONS
1.4 MOTIVATION & THEORETICAL GROUNDING
1.5 CONTRIBUTIONS
1.6 THESIS OUTLINE
2 ANALYSIS & DESIGN
2.1 OVERVIEW
2.2 RESEARCH FOCUS
3 METHODS & PARTICIPANTS
3.1 METHODS OF ANALYSIS
3.2 KEY PARTICIPANTS
4 SYSTEM DEVELOPMENT & RESULTS
4.1 EXISTING GCIMS WORKFLOW SYSTEM PROTOTYPE
4.2 CURRENT GCIMS PROTOTYPE
4.3 DEVELOPMENT PROCESS
4.4 TESTING AND EVALUATION
5 PROJECT MANAGEMENT
5.1 PROJECT MANAGEMENT OVERVIEW
5.2 DOCUMENTS PRODUCED
5.3 GENERAL MANAGEMENT
5.4 TIME AND DELIVERABLES MANAGEMENT
5.5 RISK & CONFLICT MANAGEMENT
5.6 QUALITY ASSURANCE
6 PROJECT EVALUATION
6.1 OVERVIEW
6.2 REFLECTION
7 CONCLUSION
7.1 CONTRIBUTIONS
7.2 CONCLUSIONS
8 PROJECTIONS FOR THE FUTURE
9 APPENDICES

Research Conversazione Poster

Today, Richard and I submitted our project into the research conversazione. Below is the poster we composed and the sections within. From the event, we hope to raise awareness on the feasibility of applying workflow system concept to the health informatics domain. We would also hope that from the event, we would be able to extend our networks. Here is the poster (click to view larger PDF version).

1. Aims of the Project

• To empower users to develop workflow centric information systems that exhibit interoperability, flexibility, customisability, knowledge support in a critical data intensive environment.
• To extend the Generalised Clinical Information Management System (G.C.I.M.S) architecture with a user focused workflow management system.

2. Introduction
Health Information Systems have traditionally been passive and are mainly used for administrative tasks. Many are still paper based and/or are inadequate as health information and workflow requirements are ever growing and changing. Major issues surrounding current clinical information systems include:

• Lack of departmental interoperability
• Lack of decision support system
• Lack of workflow support/guidance
• Lack of effective data analytics

3. Architecture
The Generalised Clinical Information Management System (G.C.I.M.S) is designed to allow domain users to tailor information systems to their needs. One does so by first defining workflow and corresponding forms as inputs. Using existing forms as a medium for user interface design, the resulting systems are highly tailored to specific workflow needs; yet exhibit potential for data sharing, change management and data analytics.

The components of the G.C.I.M.S include:

• Workflow Management System
• Generic Forms Builder/Generator
• Data Analytics Engine
• Terminology Server

4. Approach and Methodology
A six week intensive study of workflows for various individuals was performed at the Royal Prince Alfred (RPA) Hospital Intensive Care Unit. The purpose was to analyse the advantages and deficiencies of CareVue; RPA’s current information system.

The outcome of the study include an ideal ICU software requirement and results and documentation necessary for the further exploration of the application of G.C.I.M.S in the context of an intensive care unit.

5. WfMS Design
The workflow management system (WfMS) in G.C.I.M.S is designed to instantiate abstract workflow at run time and route work to appropriate users. The WfMS is broken down into two sub systems; the workflow builder and workflow manager. The workflow builder and workflow manager communicates through the workflow definition language; an xml document describing the abstract workflow (e.g. Admission).

6. Application in the Real World
While acceptance of users being able to define their own systems have been positive, we acknowledge that many hospitals are still dedicated to their current clinical information systems. However, the G.C.I.M.S architecture is so flexible that it can be designed to work alongside existing systems, while still having the power to replace these systems if necessary.

7. Conclusion
This project aims to explore the application of workflow system ideology in streamlining work within the health informatics domain. It is hoped that the concept may give way to a more integrated and flexible health information system which may improve the overall patient care while generating productivity gains.

8. Future Work

• Implementation of G.C.I.M.S beyond the Intensive Care Unit department.
• Complex form design such as spreadsheet charting
• Portable device implementations (i.e. PDA, mobile phone, etc)

Workflow Builder
The purpose of the workflow builder is to allow domain users to simply build and define their own abstract document centric workflow. These abstract workflows are a streamlined representation of how “work” is completed in the hospital environment. Each workflow instance is made up of a series of interlinked core workflow elements; sequence, parallel split, exclusive choice, simple merge and synchronisation. When the user saves the workflow, it automatically generates an XML instance adhering to the rules set out in the Workflow Definition Language. It saves it to a file and database were it becomes ready for the Workflow Manager.

Workflow Definition Language
The Workflow Definition Language (WDL) is the set of definitions allowing the expression of workflow in XML. It serves as the main communication medium between the Workflow Builder and Workflow Manager describing the recipients of the workflow, which forms to use and the decision path. The WDL adopts common industry standard workflow patterns that are widely used and understood. These are:

• Sequence
• Parallel Split
• Exclusive Choice
• Simple Merge
• Synchronisation

Workflow Manager
The workflow manager serves to enable abstract workflow definitions to be instantiated and used for workflow processing. Core to the workflow manager is the workflow engine, the workflow engine uses XML Document Object Model technology to map out XML based workflow definition into a tree structure in memory. The workflow engine works alongside three components, a user manager (used for workflow user management, a workflow instance manager (used to keep track of workflow instances and also a worklist manager (used to keep track of work).

Formal Definition for the Workflow Definition Language

Workflow Definitions

Workflow: Order in which specific work is performed, workflow describes all of the elements needed to achieve each step in the work process.
Workflow Element: A workflow element refers to a single workflow pattern unit i.e. sequence, parallel split, etc.
Form: A single user-defined non-active/active form for various purposes.
WDL: Workflow Definition Language.

Formal Definition

Form
The workflow Definition Language assumes that all work within a workflow can be represented as a form. With the current version of WDL, there are 3 types of form:

• form (form) - A form is a simple document which allow users to input and process information accordingly. Workflow designer can implement form with WDL using the form tag.
• action (action) - An action is a different type of form. An action is merely a simple non-interactive document which reminds user of an action.
• alert (alert) - TBA

Sequence
A sequence workflow element is representative of a sequential processes and is based upon the sequence workflow pattern. The Sequence pattern serves as the fundamental building block for processes. It is used to construct a series of consecutive tasks which execute in turn one after the other. Two tasks form part of a Sequence if there is a control-flow edge from one of them to the next which has no guards or conditions associated with it (*). In the example below Nurse Discharge Summary is a sequence point. If Nurse Discharge Summary were to be represented using WDL then it would take the form shown in the example below. The form corresponding to the Nurse Discharge Summary workflow would be wrapped in the sequence tag and labelled accordingly. Note the id=xxxx attribute assigned to the sequence workflow element, this is a unique ID given to this particular workflow element by the workflow builder.

Tags:

• <sequence> - XML tag for the sequence workflow element
• <form> - XML tag representative of individual form.
• <action> - this XML tag is used to indicate if a form is simply an action.
• <alert> - this XML tag is used to indicate if a form is simply an alert.

Example:

<sequence name="Nurse Discharge Summary" id="xxxx">

  <form name="form_discharge_nurse" majorRevNo="1" minorRevNo="0" recipient="nurse" />

</sequence>

<sequence name="Doctor Discharge Summary (Filemaker and Progress Notes)" id="xxxx">

  <form name="form_discharge_doctor" majorRevNo="1" minorRevNo="0" recipient="doctor" />

</sequence>

Parallel Split
Parallel Split describes a parallel split process workflow where a task diverges into multiple tasks. Parallel split is based upon the parallel split workflow pattern where a single thread of execution is split into two or more branches which can execute tasks concurrently. These branches may or may not be re-synchronized at some future time (*). In the image below, we can see an example of a parallel split where after recording notes onto the progress notes, the workflow then diverges/splits into two other workflows, namely print flowsheets/drug charts/progress notes and an exclusive choice workflow decision point (see definition below). Using WDL, we can see below, the one-to-one transformation between the workflow diagram and the workflow definition XML.

Tags:

• <parallel> - XML tag for the parallel split workflow element
• <parallelElement> -
• <form> - XML tag representative of individual form.
• <action> - this XML tag is used to indicate if a form is simply an action.
• <alert> - this XML tag is used to indicate if a form is simply an alert.

Example:

<parallel name="Record in Progress Notes (Doctor and Nurse)" id="xxxx">

  <form name="form_progress_note" majorRevNo="1" minorRevNo="0" recipient="doctor" />

  <parallelElement>

    <sequence name="Print Flowsheets/Drug Charts/Progress Notes" id="xxxx">

      <form name="null" majorRevNo="1" minorRevNo="0" recipient="wardclerk">

        <action description ="Print Flowsheets/Drug Charts/Progress Notes" recipient="wardclerk" interval="600"/>

      </form>

    </sequence>

  </parallelElement>

  <parallelElement>

    <exclusiveChoice name="Patient last Op <= 24hr? (or suspicious)" id="xxxx">

       ...

    </exclusiveChoice>

  </parallelElement>

</parallel>

Exclusive Choice
Exclusive choice is based upon the exclusive choice worflow pattern, where a thread of control is directed to a specific (subsequent) task depending on the outcome of a preceding task, the values of elements of specific data elements in the process, the results of an expression evaluation or some other form of programmatic selection mechanism. The routing decision is made dynamically allowing it to be deferred to the latest possible moment at runtime (*). In the case of an emergency workflow (see image below), the decision is made upon the assessment on whether the situation is an emergency or not an emergency. Based on the outcome of the assessment, the flow either proceeds to medico assessment or to defer procedure. The one-to-one mapping between the workflow diagram and the workflow definition XML is also shown below.

Tags:

• <exclusiveChoice> - XML tag for the exclusive choice workflow element
• <choice> - the choice tag encapsulates the sub-tags condition, true, false
• <condition> - the encapsulating tag for condition.
• <description> - the description of the condition that is to be satisfied before workflow can resume (this is a DRAFT tag)
• <true> - a tag to indicate the target workflow element when condition stated is true.
• <false> - a tag to indicate the target workflow element when condition stated is false.
• <form> - XML tag representative of individual form.
• <action> - this XML tag is used to indicate if a form is simply an action.
• <alert> - this XML tag is used to indicate if a form is simply an alert.

Example:

<exclusiveChoice name="Is Emergency?" id="xxxx">

  <form name="Form" majorRevNo="1" minorRevNo="0" recipient="doctor" >

    <action description="Asses patient status" recipient="doctor" interval="120"/>

  </form>

  <choice>

    <condition>

      <description>EMERGENCY_PROCEDURE REQUIRED</description>

    </condition>

    <true>form_medico_assessment</true>

    <false>form_null_defer_assessment</false>

  </choice>

</exclusiveChoice>

Synchronisation
Synchronisation describes a workflow based on the synchronisation workflow pattern. Synchronisation provides a means of reconverging the execution threads of two or more parallel branches. In general, these branches are created using the Parallel Split (AND-split) construct earlier in the process model. The thread of control is passed to the task immediately following the synchroniser once all of the incoming branches have completed (*). The diagram below shows an example of synchronisation. Here two workflows (Print Forms and Record in Progress Notes) which have diverged earlier are synchronised or merged back into one workflow - Nurse Discharge Summary. It is important to note that there is a distinguishable difference between synchronisation and simple merge (defined in the next section below). Synchronisation requires all previous workflows to be satisfied or completed, whereas with Simple Merge, any one of the previous workflows may be completed for the workflow to proceed.

Tags:

• <synchronisation> - XML tag for the synchronisation workflow element.
• <synchronisationElement> - this tag can be used more than twice to represent the multiple elements to be synchronised and merged.
• <elementID> - the elementID tag represents the unique ID from different workflow elements to be synchronised and merged.

Example:

<synchronisation name="Nurse Discharge Summary" id="xxxx">

  <synchronisationElement>

    <elementID>xxxx</elementID> <!-- Action - Print Forms -->

    <elementID>xxxx</elementID> <!-- Action - Record in Progress Notes -->

  </synchronisationElement>

</synchronisation>

Simple Merge
Simple merge is based upon the Simple Merge pattern where two or more distinct branches are merged without synchronising them. As such, this presents the opportunity to simplify a process model by removing the need to explicitly replicate a sequence of tasks that is common to two or more branches. Instead, these branches can be joined with a simple merge construct and the common set of tasks need only to be depicted once in the process model (*). An example of simple merge is shown below where the workflow record progress notes is dependent on either fill out admission summary on filemaker or set up patient. The two later workflows can either be true or at least one of them be true for the workflow to proceed to record progress notes. The mapping of such simple merge example in WDL is shown in the XML excerpt below.

Tags:

• <simpleMerge> - XML tag for the simple merge workflow element.
• <synchronisationElement> - this tag can be used more than twice to represent the multiple elements to be merged.
• <elementID> - the elementID tag represents the unique ID from different workflow elements to be merged.

Example:

<simpleMerge name="Record Progress Notes" id="xxxx">

  <mergeElement>

    <elementID>xxxx</elementID> <!-- Action - Fill out Admission Summary on FileMaker -->

    <elementID>xxxx</elementID> <!-- Action - Set up Patient -->

  </mergeElement>

</simpleMerge>

Workflow Definition Language (WFD) Notes

Assumptions

• Every process in the workflow is considered as a form with the following attributes:
  1. Form - This is the template in which information is gathered or presented.
  2. Action - A physical action that is performed. E.g. Bed Preparation
  3. Alert - An alert to the user.

Rules Regarding Forms:

• A Form’s name is always unique but does not necessarily corresponds to the workflow instance (this implies that many workflow elements can refer to the same form. ). Each workflow element will have its own unique name which will serve as its ID.
• A Form can be an Action (a physical execution of work) and/or an Alert (something to be aware of during execution of work or just an alert).

Rules for Sequence Objects

• Sequence represents a point in the workflow where work is linearly connected.
• In the XML schema, a sequence represents an instance of work in the workflow similarly to how the forms represent a point in the workflow. Therefore, each sequence object can only contain one form.
• Sequence instances is represented abstractly by the <sequence> tags

Development Methodology & Design

In my last meeting with A/Prof. Alan Fekete, he advised us on the type of development methodology that is appropriate to the timeframe available. He suggested the use of Iterative and Incremental development methodology. The Iterative and Incremental development methodology is part of the extreme programming and agile development framework and allow for rapid, incremental and successive development.

Iterative and Incremental Development Methodology

Iterative and incremental development methodology works hand in hand. Incremental development is the process of building various parts of a system at different rates throughout different times. Parts of system are continuously and incrementally integrated. Iterative development is also known as a rework scheduling strategy. Iterative development involves an ongoing process to continuously revise and improve parts of the system. Parts of system would be completed and then modified to include new enhancements such as graphical user interface, new algorithms, new functions, etc. A summary on the iterative and incremental development methodology is shown in the diagram below.

Processes in the Development of Workflow Manger using Iterative and Incremental Methodology

The development process of the workflow manager (described in the previous post) will include the following iterative sub-processes:

• Initial planning of the various components that make up the workflow manager. The initial planning will also take into account design issues and technological decision. Initial planning and design will look at
  • The various components required to manage an operational workflow catering various users
  • How different components interact with each other
  • The design and the processing of the Workflow Definition Language (WDL)
  • The management of workflow in a dynamic environment
  • The management of user and task with regards to workflow
  • What technologies are appropriate to the implementation of the design (i.e. database, platform, etc)
  • Database design (tables, fields, relationship mapping, data dictionary)
• Revision of design and plan to include enhancements (this is part of the iterative development methodology)
• Coding and implementation of design (and revised design); this might include the creation of database elements (tables, fields, data)
• Testing of coded and implemented design
• Evaluate appropriateness of implementation and test results
• Rinse, lather and repeat the development process by revising the plan and design again.

Component Design, Analysis and Development

The four components that make up the workflow manager, namely:

• The workflow engine
• The workflow user manager
• The workflow instance/status manager
• The worklist manager

are developed incrementally piece, by piece. I initiated the development by first developing the workflow engine. The workflow engine, as described in my previous post, is responsible for the overall processing of the workflow definition file. Without the workflow engine, the other three components would be rendered useless.

The next step upon completing the initial implementation of the workflow engine is the implementation of the other three components beginning with the workflow manager. Before I can begin the development of the three components, I would need to design and implement a database structure that can serve the components. The database design I drafted consists of the following elements:

• Table: User
  • Field: userID
  • Field: userFirstname
  • Field: userSurname
  • Field: userType
  • Field: userUsername
  • Field: userPassword
• Table: Workflow
  • Field: workflowID
  • Field: workflowName
  • Field: patientMRN
  • Field: patientFirstname
  • Field: patientSurname
  • Field: curWorkflowElementID
  • Field: curFormName
  • Field: curUserID
  • Field: prevWorkflowElementID
  • Field: prevFormName
  • Field: prevUserID
• Table: Worklist
  • Field: worklistID
  • Field: userID
  • Field: workflowID
• Table: Task
  • Field: worklistID
  • Field: workflowElementID
  • Field: taskName
  • Field: taskType
  • Field: taskMajorRevNo
  • Field: taskMinorRevNo
  • Field: taskStatus
  • Field: taskEnabled

The design above is shown in the E-R diagram below. The E-R diagram also shows the relationship between the different entities. This design is a preliminary design and I will update on any future revisions.

Entity-Relationship Diagram

In the next few days, I will integrate the database with the user manager, the worklist manager and also connect the workflow engine with the workflow instance/status tracker. With due respect to the iterative and incremental development methodology, I will also revise and enhance the workflow engine.

Progress Update - Workflow Manager

Development of the Workflow Manager and Builder have now began and I will discuss the various components that make up the workflow manager and also the workflow builder.

Workflow Definition Language (WDL)

As seen from the previous post, the draft of the workflow definition language or more commonly known as WDL has now been completed. It features commonly used workflow pattern including the sequence workflow pattern, parallel split workflow pattern, exclusive choice workflow pattern and also the simple merge workflow pattern. Other workflow patterns which are less commonly used such as the synchronise workflow pattern are yet to be implemented and will be implemented in the near future. The WDL stands as a middle-ground between the two components assigned for development by Richard and I.

Workflow Manager

After a series of discussion, Richard and I have come to a consensus that he will develop the workflow builder - a component responsible for generating workflow definition file according to the workflow definition language (WDL). The workflow builder will start of as a simple non-GUI, non-interacting workflow builder and progress overtime to be a rich GUI, interacting workflow builder which one may envisage as an application which allow end user to drag, drop and inte-relate workflow elements.

On the other hand, I am responsible for the other component which stands on the other side of the workflow definition point - the workflow manager. The workflow manager reverses what the workflow builder stands to do. The workflow manager takes a workflow definition (written in XML and constrained with WDL), instantiates it, parses it and processes the various workflow elements within. The existence of the XML Document Object Model (DOM) favour remarkably for such operations. The document object model takes a worfklow XML file such as the one shown below:

<?xml version="1.0" encoding="utf-8"?>

<workflow>

  <hospital>Royal Prince Alfred</hospital>

  <department>Intensive Care Unit</department>

  <participant>ICU Staff</participant>

  <description>Sample XML</description>

  <definition>

    <sequence name="Admission" id="2131">

      <form name="admission" majorRevNo="1" minorRevNo="2" recipient="doctor" />

    </sequence>

    <sequence name="Record Patient Belonging" id="5620">

      <form name="patient_belongings" majorRevNo="1" minorRevNo="0" recipient="doctor" />

    </sequence>

    <parallel name="Preliminary Examination" id="3">

      <form name="preliminary_examination" majorRevNo="1" minorRevNo="2" recipient="doctor" />

      <parallelElement>

        <sequence name="Blood Test" id="4489">

          <form name="blood_test" majorRevNo="1" minorRevNo="1" recipient="nurse">

          </form>

        </sequence>

      </parallelElement>

      <parallelElement>

        <sequence name="Blood Test" id="5365">

          <form name="blood_test" majorRevNo="1" minorRevNo="1" recipient="nurse">

          </form>

        </sequence>

        <sequence name="Blood Gases Test" id="7601">

          <form name="blood_gas_test" majorRevNo="1" minorRevNo="1" recipient="nurse">

          </form>

        </sequence>

      </parallelElement>

    </parallel>

  </definition>

</workflow>

and instantiates it into memory using XML DOM. The resulting abstract representative model is of the tree model similar to the tree diagram below. Once the workflow definition has been instantiated and transferred to memory, moving between workflow elements (i.e. from node to node) becomes a trivial task. XML DOM allow us to move between siblings (moving on the horizontal level) and also to move between parent and child nodes (moving vertically through different levels).

The workflow manager keeps track of the current node and have different set functions to process different workflow elements. For example, in the early prototype of the workflow manager, once the workflow definition has been parsed, the engine of the workflow manager then moves through the workflow elements in memory. If it encounters a sequence point element, the element is then passed to a corresponding function named processSequence which, in turn, processes any sequence point workflow element. The function recursively processes one or more sequence point workflow element until it reaches another non-sequence point workflow element or a None (null in Python). Processing of other workflow elements are done in similar fashion with a more higher degree of complexity with more complex workflow patterns.

XML DOM Tree Model of Workflow Definition

Following the design of the workflow manager and its engine, three other components were devised to complement its operation. The first being a user manager. The second is a workflow instance/status manager. The final component is the worklist manager.

The User Manager

The user manager manages operations related to the management of workflow user. These operations include the addition and removal of workflow users (i.e. doctor, nurse and patient), the authentication of these users (excluding patient) into the workflow system, the mapping of users and workflow instances and more.

The Workflow Instance/Status Manager

The workflow instance/status manager manages the various workflow instances. To truly understand workflow instance and the managing of workflow instance, I will use the following example. Say, a patient is admitted into the Intensive Care Unit. Doctors and nurses will then use the workflow system and instantiate an admission workflow instance. The doctors and nurses will then complete the tasks specified by the workflow instance. Additionally, say, another patient arrives whilst the previous is in the progress of being admitted, other doctors and nurses will then use the same system and instantiate the same admission workflow instance. How does the workflow system distinguish between the two instances, they are both admission. Therefore, there is the need to identify various instances of the same workflow and have a facility to manage these instances. In the early design of the workflow instance manager, it has been decided that each workflow element in memory have a unique ID and name associated to it. The unique ID will then be mapped to the patient ID and the uniqueness of the combination of both ID can serve as an individual workflow instance.

The Worklist Manager

The worklist manager is, in general, a portal for workflow user to oversee tasks that require attention and completion. The worklist manager shows for each user various tasks categorised by workflow instances. The user can then select the invidual task that needs to be done and operate on it.

I will provide further update on my progress as new development arises.