A Web-Services Architecture Designed for Intermittent Connectivity to Support Medical

Response to DisastersSteven Brown <swbrown@ucsd.edu> MS

California Institute for Telecommunications and Information Technology, San Diego Division and the University of California, San Diego, School of Medicine.

Funding: National Library of Medicine

Introduction

To support WIISARD (Wireless Internet Information System for Medical Response to Disasters), a data architecture must be built to gracefully handle an environment with frequent network failures, multiple writers, and support rapid dissemination of updates which could be critical to the safety of responders. This is accomplished by allowing for a subset of the overall information available in a disaster scene to be cached locally on a responder's device and locally modified with or without network access, also allowing for hiding of network latency from the user interface. When the network is available, the local subset of the model is opportunistically synchronized with a server that contains the full model, and any conflicts resolved. When changes from a device are committed, the changes are instantly sent to any connected devices where the local subscribed subset would be modified by the changes.

Client LibraryClient Library

Command QueueCommand Queue

Local (partial) ModelLocal (partial) Model

SOAP Conduit

SOAP Conduit

ServerServer

SOAP Conduit

SOAP Conduit App ServerApp Server DatabaseDatabase

Server

The server consists of a standard SQL database (PostgreSQL) and a WIISARD application server process. The database appears as a normal database to clients that wish to use an SQL interface to the data, but also supports logging of all modifications made to data in shadow tables to allow for rollback, and raising events to notify listeners of modifications. The application server's role is to provide for publish/subscribe access to the data, and to send updates to subscribers when it is notified by the database of modifications to the subscribed data. In this way, regardless of update method, updates are pushed to the application server's clients as soon as they occur. The application server also uniquely identifies each update and records its result in order to manage issues presented by command replay due to a loss of connection having left a command in an unknown state (for example, when an application goes out of range of the network).

Components

The three key pieces of the software architecture of WIISARD are the applications, the client access library, and the server. The server is present at the scene as to not depend on any external link for operation. If there is such an external link, it can be replicated remotely to provide stable access to the data by hospitals. The client access library exists on the responder's device and acts as the gateway between the applications and the server, greatly reducing the complexity of the applications. The applications are users of the client access library, and need little to no knowledge of the origin or state of the data they are working on, simply that they are working with local objects.

Client Library

The client access library is responsible for taking care of the details associated with opportunistic connection to the server, synchronization, subscription, persisting of the data model and local modifications, and notifying applications of changes to the data model and conflicted local modifications. Its three main pieces are a SOAP conduit for connecting to the server, a local subset of the full data model on the server, and a command queue for recording local commands that are not yet known to be committed on the server. The command queue contains command objects that are instances of command pattern. As the local data model is modified by the application, command objects are generated and added to the queue. While there is a network connection, these command objects are sent to and executed on the server and removed from the queue when they are acknowledged committed. When updates are sent from the server to the client due to modifications made by others, any locally queued (uncommitted) commands are rolled back, the updates are merged, then the queued commands are rolled forward, all transparently to the application. Failures in this step signal a conflicted local modification in a manner similar to version control systems and can be resolved by the software in some cases, or user intervention.

Models

Models are the fundamental unit of data to applications using the client library. These represent relational tables in the database in an object-oriented way, as well as acting as subjects in observer pattern, notifying observers of changes to data as well as the object's state. Models appear to applications to be in one of four states: deleted, unsubscribed, subscribing, subscribed. Initially, an application would have knowledge of a remote model in an unsubscribed state, and must subscribe and wait for the model to become subscribed to access the data. Such a subscribed model might reference more unsubscribed models, effectively allowing traversing a tree of models one level of depth per round of subscriptions without requiring subscribing to the whole tree. Models that are created locally are initially in the subscribed state.

Additional info

See the website and mailing lists at http://wiisard.org

ClientsThe provider device is carried by first responders and handles the initial triage of a patient as well as administering treatments. It is expected to be in and out of network coverage often and used where time is of the essence, so needs to be capable of working offline and opportunistically synchronizing as the provider moves into network coverage, which is handled by the client library.

The patient tag provides for tracking patient location throughout the scene, as well as reporting the patient's current triage status. The hardware on the tag itself is rather thin, so sends a UDP stream to a tagadapter process which uses the WIISARD client library to handle geolocation of the device. The tagadapter subscribes to all the locations of access points so is kept up to date whenever an access point changes its location and checks a list of access points and their signal strengths provided by the tag against those locations. If it has at least one access point in the list with a known location, it can attempt to geolocate the tag's position. That position is written into a model corresponding to that tag. Similar to these tags, pulse ox devices record the patient's vitals as they change.

The access points serve two purposes, to dynamically create a mesh network, and to act as location beacons to aid geolocation of patients and providers. On the location

beacon side of things, they contain a GPS device which is periodically polled by a gpsadapter process running locally on the access point. The adapter uses the WIISARD client

library to report this location, so keeping the correct location and/or recording a location trail even when unable to reach

the server is handled transparently, and will have that information rapidly pushed to any subscribed device.

The midtier device is intended for the triage and transport unit leaders, and is expected to be connected more often than

provider devices due to it being kept at a specific station. It makes use of the client library to subscribe to patients and their

locations to provide awareness of newly triaged patients, patients whose condition is changing and need treatment, and

if patients are at the right station or are unaccounted for. By subscribing to the locations that are being pushed by the tags,

the midtier can display a map of patient locations that is updated as soon as new location data is available.