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.
  

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.