Thursday, September 27, 2007

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.

Friday, September 21, 2007

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.

Software Development Methodology

As the project is dividable into small iterations, I am going to adopt the Agile Approach to building the Workflow Builder. A brief summary of the methodology is given below:

Agile Approach

Take an agile approach where we use iterative process to develop the workflow builder.

First Iteration

The first iteration heavily revolves around generating ideas and initial design documents. Once that is completed, I envisage to begin programming and developing a small component of the workflow builder. The iteration is to achieve the following set of tasks:

  • Design and revise the design of the Workflow Builder rigorously and continue to refine the design at later stages of iterations.
  • Create MySQL database to store simple XML workflow documents
  • Create a set of sequence documents
  • Write up program to add sequences only.
  • Convert the sequence into XML and output to the database.
  • Test the individual creation of sequence modules.
  • Create a sample sequence XML document adhering to the WDL. Create this abstract workflow and compare the XML output from the builder with the XML document.
  • Document findings and experimentation on the TRAC and summaries on the blog.

To begin the first iteration, we must research into:

  • Python classes and objects
  • Python arrays and other data structures
  • Python and XML
  • Document findings and experimentation on the TRAC and summaries on the blog.


Second Iteration

The second iteration is mainly focused on extensibility of simple, yet fundamental workflow points. The goal is to achieve the following set of tasks:

  • Extend the sequence and implement Parallel Workflow Element.
  • Ensure that Parallel Workflow can be converted to the XML format as per WDL.
  • Perform testing on the module level (and if possible at the unit level)
  • Create a sample sequence and parallel workflow XML document adhering to the WDL. Create this abstract workflow using the Workflow Builder and compare the XML output from the builder with the XML document.
  • Document findings and experimentation on the TRAC and summaries on the blog.

Third Iteration

The third iteration targets the more complex workflow; namely simple merge, synchronisation and exclusive choice. Exclusive choice is perceived to be the most difficult due to the possibility of large amount of nesting. Hence, third iteration is heavily focused on:

  • Develop Simple Merge and Synchronisation Workflow Elements.
  • Ensure that the Simple Merge and Synchronisation Workflow Elements can be converted into XML on its own basis.
  • Perform testing on the module level (and if possible at the unit level)
  • Extend second iteration sample XML documents to include simple merge and then synchronisation. Ensure that the generated XML will adhere to the WDL.
  • Develop the Exclusive Choice Workflow Element.
  • Ensure that the workflow element can be converted into XML on its own basis, i.e. the most basic case.
  • Perform testing on the module level (and if possible at the unit level)
  • Extend second iteration sample XML documents to include exclusive choice. Ensure that the generated XML will adhere to the WDL. Continue extending the XML document to test the exclusive choice nesting with sequences, parallel, simple merge and synchronisation workflow elements. Examine the outputted XML
  • Document findings and experimentation on the TRAC and summaries on the blog.

Fourth Iteration

The fourth iteration’s main goal is to develop the workflow builder which will manage the creation of abstract workflow. It is envisaged that due to the lack of time, either a basic and simple GUI will be developed or a basic command prompt interface will be developed. The main tasks for the fourth iteration is:

  • Finalise the testing in the first to third iterations.
  • Ensure that the format of the XML adheres to the WDL and make any changes as necessary. There will definitely be changes as the WDL is a constantly evolving piece of work.
  • Develop a basic workflow builder interface design on paper.
  • Research on Python’s GUI packages.
  • Implement a basic design without any bells or whistle
  • Document findings and experimentation on the TRAC and summaries on the blog.

Resources required to successfully complete this iteration includes:

  • Research on basic GUI
  • Experimentation on user interface design


Fifth Iteration
Once the interface has been designed, the fifth iteration will be more involved with testing; ensuring that different types of workflows can be abstractly represented. It is vital that the XML generation is consistent and can be used as input into the Workflow Manager. Also, as experience is gained from this development, documentation of results and more importantly documentation of future development, future direction of this research and a critical analysis of the system be duly noted. This will form the foundation of future work.

Weekly Summary 21/09/2007

As noted in my previous entry, the WfMS is divided into the WfBuilder and WfManager. After lenghty discussions I have decided to build the WfBuilder. The language we will be using is python.


The last week has been spent on familiarising myself with python, helping out with the Workflow Definition Language, designing the workflow builder and beginning the first and second iteration (refer to later post on Software Development Methodology). I will post up the rough design and software methodology after this post.

As Alan Fekete is flying out this week, we had a very brief over the phone discussion of our project to date. As a result, I will need to email him a brief update on my progress.

Update: Workflow Diagram

The updated workflow diagram is shown below. We are still getting some feedback on the diagram.
But early feedbacks are positive.

Friday, September 14, 2007

RPA Site Visit

On Friday afternoon, Hendy and I made our way to the RPA for a meeting with Angela Ryan. We verified all workflow diagrams surrounding the care of the patients. Only minimal changes need to be made. These include:

  • Redefining "Doctor On Call"
  • Nurse workflow additions to admission, discharge and bed management.
  • Extra workflows regarding the requests for tests (e.g. x-rays and blood gas).
  • Routine workflows regarding nurses and doctors
Hendy and I will post the updated workflows once we have updated them.

Meeting with Alan Fekete on 14/09/2007

Hendy and I had our weekly meeting with Alan Fekete today to discuss what was achieved during the last week and what we can in the following week.

The Workflow Management System (WfMS)

The diagram above shows the basic architecture of the WfMS for the G.H.I.M.S project. Each part is described below:

XML Schema
The XML schema describes the rules for which workflow can be instantiated in XML. The Workflow Definition Language (WFD) has been completed.


Workflow Builder
  • 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 should be a simple workflow builder used to build the basic definitions of workflow but allow extensions for more complex multiple user based workflow. Simple workflow includes sequence, parallel split, synchronisation, exclusive choice and simple merge.
  • Users would be able to build basic workflows using a simple user interface. Then when the user saves the workflow, it should generate an xml output which is stored in a MySQL database.
  • The workflow builder should be able to open saved workflow documents but may not necessarily offer modifications in the prototype.

The Workflow Builder Prototype Goals

  • Design a simple user interface (possible GUI based) to allow users to construct workflow in abstract form.
  • 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

Workflow Manager

  • The workflow manager takes the abstract workflow and instantiates it. Its main responsibilities include
  • Routing the workflow by delivering appropriate forms to users, requesting users to fill out forms and presenting information when requested.
  • Able to notify users at which point of the workflow they’re in.
  • Able to deliver what needs to be done
  • The workflow manager would have to obtain workflow instances from the MySQL workflow database, instantiate it and execute the workflow. In order for this to work, workflow manager must reside in the G.H.I.M.S server and interface with the Form Builder database.

Workflow Manager Prototype Goals

  • Demonstrate the construction of workflow instance from XML instance.
  • Route the appropriate forms, documents, alerts etc. to the users

Upon discussion with supervisor and the team, I have decided to attempt to build a simple Workflow Builder while Hendy will attack the Workflow Manager.

Task for the following week
For the following week, I plan to do the following:
  • Rigorously plan the design of the workflow builder - what it should ideally do, how it should do it and what resources will be needed.
  • Scope down the requirements and implement a subsection of the workflow builder. By the end of this week I hope to have the workflow builder being able to basic sequences using command prompt.

Friday, September 7, 2007

Meeting with Alan Fekete - Project rescope

Today Hendy and I had a meeting with Alan Fekete and Peter Budd to report our findings for the previous week and discuss how we could divide up the treatise into two meaningful segments.

Investigation into the use of CareVue in G.H.I.M.S ICU

The following segment describes the findings describing whether the G.H.I.M.S ICU system will rely or use CareVue.

CareVue Database Environment

  • Data is recorded by CareVue and stored into two separate databases; real time database and an historical database. The difference in both databases is that the real time database records and displays live data for recent ICU patients whereas, the archival database stores data for all ICU patients.
  • The historical database is called the Information Support Mart (ISM); a clinical data management information support mart that interfaces with CDA to create a set of approximately 30 tables from 300 tables.
  • The real time database is called the Clinical Data Archive (CDA) contains over 300 tables


Extraction of Data from CareVue for the ICU G.H.I.M.S

  • Currently, there is code written (from another project called the Ward Round System) to extract data from the historical database. As a result, we envisage that investigation into extracting data from CareVue and inputting it into an ICU G.H.I.M.S would be trival.
  • While extracting data from CareVue would be achievable, inputting the data into the database is live or archival database is problematic because:
  • We will be manipulating
  • There is a resource constraint on the access of the database.
  • Furthermore, it is envisaged that the complete ICU G.H.I.M.S would serve as a replacement to the hospitals current information system setup. Instead, de-identified CareVue data could be used as a base for data requirements analysis (as per system analysis completed) and as sample data to enter into a prototyped ICU G.H.I.M.S.

Workflow in the ICU

  • CareVue currently does not support a workflow management system.
  • There are really no standardised forms that CareVue uses during throughout the workflow in the ICU. There are certain stages and activities (e.g. automated recording of vital signs, recording of nurse discharge summaries) where there are computerised forms which are later printed out. A significant portion of clinician notes a rerecorded in free text, however some entries follow standard template (such as the Ward Round Templates).
  • Some paper forms are used during certain ICU workflows. For example, during the discharge process, medication data in CareVue is transferred by the nurse and doctors to standardised forms which are used hospital wide.

Conclusions
Considering that the proposed G.H.I.M.S would effectively be a replacement (with greater functionality and support) to any hospitals electronic or non – electronic system, CareVue should be used as a base line for which the minimal type of information could be stored on a G.H.I.M.S ICU IS. CareVue de-identified data coupled with the workflow analysis can be used as a test bed for the prototype (and full) implementation of the G.H.I.M.S. ICU IS.


The Workflow Management System




The workflow management system (shown in diagram above and in previous post) can be divided up into two independent sections - a workflow builder and a workflow manager. The workflow builder will allow users to create abstract workflow representations which then can be instantiated by the workflow manager. The workflow manager will then require to route the workflows to the appropriate users at the appropriate time. The workflow builder and workflow manager becomes the foundation for the proposed workflow management system.

The need for a workflow managment system, workflow builder and workflow manager requires some form of common ground for communication between each segments. Therefore a workflow definition language written in XML would need to be devised. This would be served as a set of rules used to describe workflows in XML much like the FDL (Forms Definition Language).

Task for the following week

For the following week, I plan to do the following:
  • Hendy and I are to work on the workflow definition language.
  • Investigate requirements and scope for the workflow builder and workflow manager.