Thesis Hand In

Over the last two weeks, I have been finalising my treatise preparing it for official submission. Here is a summary regarding the statement of achievements of this treatise:

Individual Achievements:

At the individual level, this treatise has accomplished the following:

• A prototype Workflow Builder enabling clinicians to define abstraction level workflows without prior technical knowledge and/or experience in programming.
• Transformations of abstract level workflow into a WDL file adhering to an XML schema.
• Demonstrated the generic qualities of the Workflow Builder such that its application is domain independent.
• An evaluation of strengths and weaknesses of such a prototype with regards to the overall Workflow Management System and guidelines for a future implementation.

Joint Achievements:

Joint achievements are the result of synergistic benefits of working in a research group. These include the following:

• 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.

Weekly update 12/10/2007

The past week has been relatively quiet on the thesis front as I have been working on assignments for my other subjects.

However, I have managed to solve the problem of generating unique ids for each workflow element. From here on, any changes to code will mainly involve commenting, clean up and testing.

Also, Hendy and I have submitted our joint poster to the Reasearch Conversazione which is held on the last day of the semester.

Research Conversazione 2007

I have just submitted our entry to the Research Conversazione 2007 which is to be held on the last day of the semester. Hopefully these entries will be able to highlight how current information systems in our health industry are inadequate and show the potential of what IT has to offer in this field. Here is what our poster looks like:

Workflow Builder

Below are screen shots of the workflow builder I have been working on. Its has a relatively simple layout true to the design goals I have set. The GUI essentially allows the users to build abstract workflows, save them to a file and save them to a Workflow Management database. It also allows the users to display and retrieve these workflows.



The workflow builder is still incomplete. There are revisions that need to be undertaken; these include:

• Documentation of code - I need to find a way of generating an API (there are certain tools out there that I have yet to investigate).
• Generation of unique IDs for each workflow element -
  
• Testing, testing, testing ...

Quick Demonstration:

The screen shots below shows how user can create an abstract workflow.

The second screen shot shows the program generating the abstract workflow in XML before saving it to a file and storing a copy in the database.

Weekly Update 05/10/2007 - Thesis Consolidation

Today, Hendy and I resumed our weekly meeting with our surrogate supervisor, Alan Fekete. While Professor Jon Patrick is away, we have been in touch through email and online entries onto the TRAC.

During the meeting, I gave an update on my thesis progress. I have almost completed the foundations of the workflow builder. There are minor revisions and testing that needs to be done in order to make the workflow builder functional. I will provide the list of updates in a later entry. According to the agile process, I have completed the first four iterations and up to the fifth iteration.

Upon the outcomes of the meeting, Alan has advised us to finalise the core fundamentals of the thesis and begin the write up. This will involve revising the thesis draft (marks have yet to be released, however, our supervisors have given us feedback on them) , adding and correcting the draft and then documenting the second half of the semester. Roughly additions to the draft thesis will be:

• Documentation of the software methodology/model used
• Documentation of architecture
• Documenting the results
  
• Documenting possible extensions (future work)
• Writing up a conclusion

It will take roughly 1-2 weeks (depending on the load of my other subjects) to write up these sections.

Quick Update 28/09/2007

Just to provide a quick update on the progress of the thesis. The week coming to an end is the mid semester break so I have been working lightly on the design and implementation of the workflow builder as well as thinking conceptually on how the whole design will benefit the GCIMS architecture.

Workflow Builder

The workflow builder processing component, that is building an abstract of the workflow is approximatly 90% complete. Tests scripts can be used to build workflow elements of sequence, parallel split, simple merge and synchronisation and exclusive choice. Slight modifications (dependent on the finalisation of the WDL) and testing needs to be done on the workflow before I can finalise the processing part. I will finalise and present the results of each of the iterations once I have collated and analysed all my output.

Workflow GUI

I have begun researching and designing a simple workflow GUI. The GUI would be simple but allow users to essentially define their workflow and generate the XML output. I have decided not to do any "click and drag" and diagram based GUIs due to the time and scope of the project. Upon email consultation with Alan, he has advised me to focus my time on areas which will add value to the theoretical approach rather than focus on designing a flashy GUI with many 'bells and whistles'.

As a result, the simplified GUI would be designed to show the the core functionality of the workflow builder, that is, allowing users to create their workflow. The program and GUI is designed to be easy to read (i.e. code is well documented), understand (i.e. code is refactored and broken down) and be easily extendable assuming that future programmer has some experience in programming and OO design.

Meeting to Confirm Workflow Definition Language

On thursday the 27th of September, Hendy and I had a brief meeting to finalise the workflow definition language (WDL). We have made the following slight modifications:

• Merge and Synchronisation workflow elements are the same but only differ in the fact that synchronisation must wait for all workflows to merge before moving onwards.
• There is no longer a need to store the previous or next element. This is implicitly done by the structure of the XML
• Each workflow element (Seq, merge, sync, exc choice, par split) must have an attribute name and unique id. The name corresponds to the workflow name (e.g. Set Up Bed, "Administer Medication"). Each element must have a form and and a corresponding attribute "name". This form name corresponds to the name of the form from the form database. In my prototype workflow builder, i have made the assumption that the forms are valid and exists. But in a fully functional and operational program, the builder will interface directly with the forms database to ensure that the form exists.
• In merge and synchronisation work elements, there is no need to have form as an element. The reason is that the merge/synchornisation only acts as a medium in which workflow elements come together and feed into another workflow element.

Hendy and I have also discussed the overall architecture of the WfB and WfM in the WfMS. We have also discussed how we can each improve our own parts and how we can possibly demonstrate the idea. Currently, we are having issues integrating our parts into the GCIMS, especially the form builder. There are some font compatability issues in python going from a Mac to a PC environment which we have been trying to nail out. We may investigate the possibility of setting one of the uni computers to run all our applications if time permits.

Workflow Builder Design

• The Workflow Builder provide users with the ability to define their own workflow. It is based on the idea of document centric workflow system.

• Prototype is designed to be a simple workflow builder that would be used to build the basic definitions of workflow but allow extensions for more complexes multiple user based workflow. Supported workflow includes the following fundamentals

1. Sequence - An activity in a workflow process is enabled after the completion of another activity in the same process. A sequence point in the workflow is represented by a square followed by an arrow pointing to the next workflow element.
2. Parallel Split - A point in the workflow process where a single thread of control splits into multiple threads of control which can be executed in parallel, thus allowing activities to be executed simultaneously or in any order. A parallel split is represented by a single workflow element with two or more arrows pointing to other workflow elements.
3. Synchronisation - A point in the workflow process where multiple parallel sub processes/activities converge into one single thread of control thus is synchronizing multiple threads. It is an assumption of this pattern that each incoming branch of a synchronizer is executed only once.
4. Exclusive Choice - A point in the workflow process where, based on a decision or workflow control data, one of several branches is chosen.
5. Simple Merge - A point in the workflow process where two or more alternative branches come together without synchronization. It is an assumption of this pattern that none of the alternative branches is ever executed in parallel.

Source: http://www.workflowpatterns.com/

Workflow Builder Requirements

• The primary goal of the Workflow Builder is to allow Users to build basic workflows using a simple user interface. The abstract workflow defined by users is converted into XML and then stored in a database.
• The XML is saved into a MySQL database.
• The workflow builder should be able to open saved workflow documents but may not necessarily offer modifications in the prototype.

Workflow Builder Prototype Goals

• Design a simple user interface to allow users to construct workflow in abstract form. Initially the user interface will be a DOS type interface. A GUI may be developed if there is time.
• This abstract workflow is then converted to XML in accordance with the WDL schema and stored in a MySQL database.
• Allow read-only retrieval of workflow to show demonstrate the reconstruction of XML into run time instance of the workflow.
• At this stage, modifying workflow, fancy GUIs and other bells and whistles are currently out of scope. They may fall into scope if time permits.

Basic Design Architecture

• Separate GUI from underlying programs. Therefore develop a class for the workflow and a class for the GUI which will be a command prompt at the moment. In this prototype a test class will replace the GUI. The GUI will be developed when there is time available. The main focus should be on the computation and creation of abstract workflow and conversion of this abstract into XML.

OO Design

• Work Element – is the individual workflow element; an atomic activity of some sort that does work using resources of the company. A series of work elements linked together make up a workflow. For example, “Prepare Bed” is a work element which is part of the “Admission” workflow. They are usually represented as squares or rectangles on the workflow diagram. In the workflow definition language (WDL), every work element is a form. Its behaviour is distinguished by its attributes and the flow of work to the next work element is determined by a relationship variable.

• Relationships – are the linkages between the work elements which make up the workflow. The linkages or “relationships” between the work elements

• Workflow – is a series of work elements and their relationships. It is essentially a container of workflow elements and their relationships

Work Element is a hierarchy with differing types. These types define the type of work element it is and also determines the relationship attribute, i.e. the relationship attributes is what distinguishes the different type of work element. Otherwise work elements devoid of relationships is the most basic and atomic object.


Simplified UML Diagram

Note: Diagram needs to be updated.