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.

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.

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.