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.

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.

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.

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.
  

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.

Meeting with Jon Patrick & Alan Fekete and Project Scope

Hendy and I had a comprehensive meeting today with our supervisors Jon Patrick, Alan Fekete and Peter Budd (a PhD student who developed G.H.I.M.S and Terminology Server).

Administration

Over the next 6 weeks, Jon Patrick will be away. Temporarily taking his place as thesis supervisor will be Alan Fekete (refer to previous posts). We plan to keep in touch with Jon through regular email and progress updates on the TRAC website. We have also set up weekly meetings with Alan Fekete every Thursday at 12 mid day.

Project as of today

So far, the system analysis phase of the project has been finalised. Only minor changes need to be made which will take no longer than a couple of days. However, we are still perfoming some validation and feedback tests with Angela at the RPA (she has been unavailable this week). With the first half of the project complete, Hendy and I will diverge in our investigations in the remainder of the second phase of the project.

Project Goals for the remainder of the thesis (Project Scope)

Generally, the aim of the project is to develop a working prototype that demonstrates (a proof of concept) a document centric workflow management systems in an ICU environment.

The diagram above depicts the current state of the technology. Essentially, there are two versions of G.H.I.M.S that need to be consolidated. The version of G.H.I.M.S that was developed by Peter Budd contains a form designer with version control using a MySQL database. The second version of G.H.I.M.S, developed by William Chau, contains a workflow management systems (WfMS), written in C#, but does not contain a versioned form designer. The backend operates on an Oracle database.

In order for the system to function, investigation needs to be done to port the WfMS into Perl for it to be compatable with G.H.I.M.S developed by Peter. Open source backend, such as MySQL will also need to be implemented. Using the system and workflow analysis completed in the first half of the thesis, we have to demonstrate the generic generation of an ICU information system. In order to reduce scope, this ICU system will be a component of the ideal system that is complex enough to demonstrate a proof of concept. It is essential that several principals, on which G.H.I.M.S is based upon, are demonstrated. These are (on the top of my head):

• Support for user workflow - adaptive workflow for the main users of an ICU information system; i.e., clinicians, nurses, allied healthcare professionals, administrators, researchers


• Use of terminology (SNOMED-CT)


• Customisation and Interoperability - data transfer between the ICU G.H.I.M.S and a mini (basic) G.H.I.M.S for allied healthcare professionals.


• Extendability - ability for users to effectively define their own systems (and workflow) with the use of the form designer.


• Medical Record storage and retreival.

My Tasks for the next week

For the following week, I plan set up the development environment on my laptop, install Peter's code and experiment with G.H.I.M.S. (I have scheduled a meeting with Peter Budd on Friday). My specific aims is to see what is required in order to make the system (bar the WfMS) to work with CareVue or to be able to mimic CareVue. This requires investigating the paper and electronic document environment surrounding the ICU's workflow and their use with CareVue and possibly, how adaptive their workflow will need to be. I plan to post an entry on adaptive workflows soon as this area is especially useful in the ICU environment.

Draft Treatise Hand In

I have finalised the draft treatised and given a copy to Alan Fekete and Jon Patrick for initial feedback. Over the next two days, I plan to work on the draft treatise extending the system analysis and workflow analysis chapters. I also have to clean up the literature review and continue to add to the literature base as I continue researching.

Workflow Update

The diagram below shows the final draft of the complete work flow of an ICU unit. These diagrams still require some feed back from ICU staff.



Given that my draft thesis is due on the 31st of August (approximately 1 1/2) weeks time, I will be spending majority of the time collating and writing up, at the very least, a outline of my thesis and an initial draft of my literature review. Given that the scope is forever changing, I envisage that the initial draft to be quiet different from the final product.

Weekly Update 06/08/07 - 17/08/07

Project Update:

It has just been two weeks since my last post. Over the past two weeks, I have been updating TRAC (a sub version repository and a wiki) about all the findings that we have gathered during our site visits at the RPA. From there, Hendy and I have been developing workflow diagrams (which seem to get ever more larger and more complex), data flow diagrams, updating an ICU SRS as well as having weekly meetings with my supervisor; Jon Patrick. Furthermore, we have also been returning to RPA to perform follow up meetings with Angela to review our work and confirm work flow diagrams. We have also begun viewing some source code with G.H.I.M.S, however, I have yet to fully look at or experiment with the code.

Project Time Management:
The system analysis phase of the project is taking longer than expected. This is mainly attributed to follow up meetings with Angela as well as the complexity of work flow diagrams (I will post an example later on) in trying to capture the varied and often chaotic work flow of an intensive care unit. Even simple processes such as discharge can be a hurdle due to the numerous legal requirements, reporting processes as well as actual management of the patient. For example work flow thus far (it is still a work in progress) is shown below:



Furthermore, the SRS for an ideal ICU will come from the interviews from RPA personnel as well as a system analysis of CareVue. As a result, we have completed a draft system review of CareVue and from there we are beginning to develop an SRS. We envisage the complete drafted SRS to be finalised by the end of this coming week.

Project Resource Management:
Over the last two weeks, I've had two meetings with Prof. Jon Patrick regarding thesis progress. The first meeting mainly consisted of providing feedback and direction relating to work flow diagrams as well as information in TRAC. The second meeting on 16/08/2007 was to discuss the progress of validating information in TRAC, re-scoping the project and Jon's availability next week. Jon is unavailable next week and will be away for several weeks from the start of September (although he will be able to be contacted via email). To take his place as IT supervisor next week and when Prof. Jon Patrick is away will be Dr Alan Fekete.

I will dedicate a separate post to the re-scoping of the project as it is a significant turning point in the thesis.

Furthermore, we have found out that Angela will be away and consequently unavailable for the next 2 weeks. While this will represents a significant strain in our resources, I see this as an opportunity to fully consolidate our findings before Angela returns. As a result, our contact within RPA for the next two weeks will be Dr. Herkes and Chris.

Task for the following week
Given the significant changes occuring, the tasks for the following week will be to:

• Consolidate TRAC
• Complete Work flow Diagram
• Complete System Review/analysis of CareVue
• Complete SRS
• Complete DFDs
  
• Review source code for G.H.I.M.S as try to get it working (while setting up develop environment on my home computer and uni computer).
• Begin to modify G.H.I.M.S if possible.

Resource wise Hendy and I will have to:

• Contact Dr. Alan Fekete
• Contact Peter Budd regarding his code

ICU General Workflow (Meeting with Angela on 25th and 27th July 2007)

On the 25th and 27th of July 2007, Hendy and I had meetings with Angela Ryan of RPA hospital. Briefly, the core purposes of the meeting were to discuss:

• The ICU structure at the Royal Prince Alfred Hospital
• The flow of patient in a general ICU.
• Brief overview of the “Whiteboard”
• Core users of RPA ICU’s information system; CareVue
• Extension of Functional and Non Functional Requirements

ICU Department at RPA

The ICU at the RPA hospital is divided into three/four sub division/department based on the three types of patient that is administered into the ICU. They are:

1.General ICU – The most generalised ICU unit that is designed to deliver the highest of medical and nursing care to the sickest of patients with non-unique conditions.
General ICU High Dependency Unit (HDU)– deals with patients which need constant care. Often up to two nurses can be assigned to each patient in the High Dependency ICU

2.Cardiothoracic Intensive Care Unit (CICU)/High Dependency Unit (CICU-HDU) - CICU cares for patients who need heart (cardiac) and chest (thoracic) surgery. Surgical procedures may include operations on the heart, the heart’s blood vessels, the chest or the lungs.

3. Coronary Care Unit (CCU) - The Coronary Care Unit or CCU cares for patients who have heart disease and occasionally other medical or surgical problems. In RPA, this unit is more or less combined with CICU.

4. Neurosurgical Intensive Care Unit (NICU)/High Dependency Unit (NICU-HDU) - The Neurosurgical Intensive Care Unit cares for patients with brain or spinal cord conditions and occasionally other medical or surgical problems. (Source)

The General ICU and Neurosurgical ICU/HDU patients are cared by specialist doctors relevant to their area whereas the General ICU HDU and Cariotherastic ICU/HDU care is driven by ICU specific doctors.

Flow of patient in a general ICU

Patients who come into ICU often need constant monitoring and medical care. These are usually patients from lengthy surgery, unconscious and/or require ventilation hookup. A new patient administered into the ICU would follow the procedure:

1. Upon arrival (or even before arrival) a new patient is created in CareVue. Given the MRN, a linkage to the hospital’s patient administration system automatically uploads all other administrative (not medically relevant) data.

2. The patient physically arrives to the ICU department, usually accompanied with several nurses and doctors. During the setup procedure, necessary equipment (such as ventilator, machines measuring vital signs) are attached and linked to the patient. Once linked some of these medical equipment automatically update data into CareVue.

3. Nurses and/or doctors then create a care plan for the patient. (Different depending on diagnosis or investigation).

4. Nurses and doctors perform their duty in caring for the patient (To be investigated next week).

ICU Whiteboard

In almost all hospital departments, exist a whiteboard used to record and keep track of patients, nurses and doctors on shift. The RPA’s ICU uses a whiteboard as a tool to map patients to nurses and to record which doctors are on shift.

Core Users of CareVue

• Doctors – heavy user
• Nurses – heavy user
• Physios – medium user
• Dieticcian – heavy user
• Social workers – light users
• Visiting Medical Teams – medium users
• Speech Pathologist – medium users

Note: Physios, Dieticians, Speech Pathologists and Pharmacists are usually referred to as Allied Healthcare professionals. These set of users have limited use in CareVue. They often view CareVue information and only enter notes compared to Doctors or Nurses whom extensively use CareVue.

Meeting with Jon Patrick 26/07/07 - Workflow of ICU

On the 26th of July 2007, Hendy and I had a meeting with Jon Patrick to discuss project update. We covered project planning, disambiguation of the project, system analysis of CareVue and where we are heading theoretically.

One important note we got out of the meeting is to focus more on the workflow of the different users in an ICU environment. We must capture the entire workflow, (not necessary how they interact with the information systems around them). By doing so we can then apply the a form based mythology to design a future proofed, interoperable system that exceeds current functionality provided by current products. This is especially interesting as we no longer see information systems used as a data repository but as a tool to facilitate and aide patient care at every level. For example, by providing extensive decision support to nurses and doctors, improve workflow productivity and simplify and streamline tedious and often time consuming administrative events.

It must be noted that the system analysis and interviews are to be done with Hendy as there is so much to cover. The following week’s aim is to perform a more detailed functional analysis of CareVue while gathering data from RPA interviews.

Project Definition and Demonstration of CDAL

As discussed in my previous post, I will give a more detailed summary of the meeting and site visit.

Meeting on 18/07/2007

The objective of the meeting was to meet with 2 other students (David Ding, Victor Chan and Peter Budd) who will be working on extending and developing the Clinical Data Analytical Language (CDAL), discuss how the projects were to be monitored and managed, and increase the understanding of the scope of how all different aspects of the project fit in as a whole.

Administration and Management of projects

In conjunction to this blog, Trac (a project management software) is to be used to record my progress, documentation, code and subversion tool. There may be some redundancies between the blog and information contained in Trac but I do not anticipate that this will poise a significant problem.

Overall Project Picture

The figure above shows the overall picture of how a generalised clinical management information system can be used to develop department specific IS, yet still retain its interoperability across systems.

CDAL is essentially a restricted natural language allowing analytical procedures to be expressed as a query such that it can be computationally executed. It is similar to SQL except it is less restricted and more closely resembles human language. In the above figure, it can be seen how Victor and David's work on CDAL will fit into the IS. An initial prototype of this (developed by YuZhong) was demonstrated at the RPA site visit.

Task

Following the meeting and site visit, our initial tasks has become a lot clearer. These include:

1. System Analysis of ICU - A comprehensive system analysis of ICU is to be undertaken in order to gain an understanding of what an ICU IS should be fundamentally be achieving, data capture requirements (design of forms) and overall functional and non functional requirements. Incorporated in this system analysis is a SRS for an ideal ICU IS (SUICUIS). ICU work flow analysis. If possible, system analysis would be conducted at the RPA ICU and two other hospital departments to gain a greater understanding of how hospital information systems differ from department to department.
2. Extending previous thesis work on G.H.I.M.S (now referred to as G.C.I.M.S) - particularly on the generation of forms and form version control.
   
3. Develop a functional ICU IS - using methodology in G.C.I.M.S and incorporating the use of medical terminology server to deliver (in this case) SNOMED-CT terms to instantiate and record data.
   

While we are undertaking these tasks, we will likely be using all open source software if possible.