Showing posts with label GCIMS/GHIMS. Show all posts
Showing posts with label GCIMS/GHIMS. Show all posts

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.




Friday, August 31, 2007

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.

Thursday, July 19, 2007

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.