Critical Team, LLC^†

Organization:
Critical Team is (was) located in Boulder, CO.

Role:
Dir. of Engineering / Senior Architect: January 2002 — November 2002

Project description:
[Excerpted from a separate document.]

This project was initially started at the behest of the Director of Nursing for Women’s Services for a local hospital.  The department of Women’s Services includes Labor & Delivery and Mom & Baby (i.e., post-birth recovery.)

After labor and delivery mothers and their babies are moved into private or semi-private rooms to bond (e.g., feed, interact) with their newborn; recover from the birthing process; and be observed and attended by hospital personnel.  During the post-birth recovery period nurses are especially busy attending to the care of these new mothers and their babies.  There is considerable paperwork, and like many hospital processes, the creation and completion of forms requires hand-copying information from one form to another form.  In several health care studies the volume of paperwork (in general) in the health care scenario coupled with the hand-copying of duplicate information between different paper-based forms leads to considerable errors.  In addition to the obvious accounting and administration errors, these studies found more serious results to include reduced patient care, patient injury, and sometimes, patient fatality.

A particularly critical ‘form’ that nurses utilize in the Mom & Baby department is called a Care Path.  Computationally speaking, Care Paths are a rather complicated form, as forms go.  It includes simple things like patient demographic data (e.g., age, weight, etc.) but also observations and treatments (i.e., actions).  Physiologically normal observations and common treatments are simply noted on the form with time and appropriate statistics, terminology and/or symbols.  Physiologically abnormal observations require special actions and documentation criteria.  For example, to observe that a mother has not yet breast-fed their infant after an hour (or two, or three) must not only be documented using specific terminology but also include what actions and protocols where followed.  Furthermore, for safety and legal considerations, this documentation cannot be incomplete or fragmented.  The user must be guided to properly complete a Care Path.

Taken together, the computational implementation of a Care Path requires the features of a form with context-sensitive terminology verification, treatment protocol and workflow domain knowledge (similar to a rules based expert system), and an alarm/timer based event mechanism which prompts/reminds the user to action (some observations and treatments are required to occur within certain time periods after birth.)

The goals of the project were to allow nurses, utilizing a handheld device and a desktop docking/synchronization system, to make and record observations and actions directly, at the point-of-care, onto the handheld device and later synchronize the date with the desktop system.  Data in the desktop system would be shared with other relevant processes and personnel to facilitate a record-once workflow and minimize or eliminate the data-duplication errors.

Architecture/Implementation

In keeping with the marketing buzzwords of the day this project had the working title of e-CarePaths.

e-CarePaths were implemented on Palm handhelds utilizing Sun Microsystems MIDP for Palm implementation.  The actual design of the form was done on a desktop system using a text editor and XML as a Form Definition Language (FDL).  This canonical XML representation was then compiled into objects that represented the presentation and behavior of the form on some target device.  The initial target devices were MIDP (for Palm OS based handhelds), AWT (for PocketPC devices), and a web browser (for testing and for entering data at the nurses station).  Using this approach allowed us to to write reusable form interpreters, or engines, for individual devices instead of having to write very specific user interfaces for each unique CarePath (did I mention there were at least four) for each device.

Engineering Issues

The User Interface

The user interface available for MIDP devices is very limited and leaves much to be desired when compared to AWT or Swing.  Although Palm OS devices are very powerful PDA’s and not as-resource-constrained as other devices for which the MIDP was intended, Personal Java and (a full) AWT doesn’t exist on Palm OS because of two major reasons: 1) the native interface is so dissimilar as to be unusable as a basis for implementing the AWT; and, 2) the native OS does not support native threads.   Therefore, it was decided to implement a kind-of AWT-like subset to MIDP to provide user interface components common to our intended target devices.

Sharing Objects, Synchronizing Data

Another issue was how to share or synchronize data with the desktop.  At the time the best-practices approach was to send and receive data in text form, usually XML, to/from the MIDP device via a HTTP dialogue.  This approach implies that the desktop and the device need an XML parser library.  This is more important with-respect-to the resource constrained device in that the XML library occupies valuable space and increases the computational requirements of parsing and encoding XML.  Furthermore, data would have to be stored locally on the device and these computational objects would be stored in a native object form (MIDP does not support the Serialization interface but it does have the core facilities to do object serialization) because it makes no sense to store them any other way, especially not in a bloated form such as a markup language.