ORNET: A Network for the Operating Room of the Future
Progress Report: January 1, 2002ŃJune 30, 2002
John Guttag and Hari Balakrishnan
The overall goal of this project is to start to bring the benefits of ubiquitous computing and communications to health care in hospitals, physicianŐs offices, homes, and the field.
Computing already pervades medicine. Processors can be found in electrocardiogram machines, blood pressure monitors, drug pumps, and even stethoscopes. Each device greatly facilitates medicine's fundamental process of gathering information about the state of a patient and then using that information to choose interventions intended to improve the patient's state.
Unfortunately, all of this enabling technology has combined to create a disappointing system in which a large number of excellent but isolated point solutions are often considerably less than the sum of the parts. The problem starts with the architecture of the typical medical device:
á A transducer (the probe) that measures an analog signal (e.g., electrical voltage or reflected sound} emanating from the patient,
á A wire connecting the transducer to,
á Special purpose hardware,
á A program that runs on the special purpose hardware and processes the data gathered by the transducer, and
á A dedicated user interface.
This leads to a number of limitations, including the inability to easily fuse data, share resources, upgrade algorithms, and systematically collect data for further analysis. In short, the devices don't function as a system.
A system links various components together to achieve higher-level goals. The utility of the system, in any give situation, is determined by how well the different components inter-operate to perform the desired tasks. Generally, an efficient system should facilitate and control information flow between components while minimizing any unnecessary replication of resources or functionality. An opportunity exists to re-architect today's inefficient medical system by leveraging new technologies and applying this classical systems viewpoint.
One factor, as mentioned above, is the ubiquity of computing and communication. Each will soon be everywhere. Taking advantage of this opportunity requires a multi-level architecture that makes appropriate use of a variety of communication and computation technologies.
A second factor is the ever-increasing selection of smaller less-invasive sensors that permit extensive gathering of physiological data. Taking advantage of this opportunity requires an architecture that scales in the number of sensors. Clearly, connecting each sensor by a wire to dedicated user interface is not such anarchitecture. Furthermore, the architecture must be plug-and-play.
A third factor is the availability of increasingly sophisticated algorithms for analyzing signals and data. Taking advantage of this opportunity requires an architecture that provides a clean separation between the parts of the system that gather the initial data (i.e., the probes) and the parts of the system that process the data in real time and save the data for subsequent analysis.
A fourth factor is the rapid improvement in the capabilities of commodity hardware for both computation and storage. Taking advantage of this opportunity requires moving away from the special purpose hardware commonly used in today's medical instruments.
This project involves building new system for medical networks of devices that supports a variety of devices in a reliable, yet flexible manner. As part of this project we are developing techniques to facilitate data fusion and increase the reliability of proxy functions and developing protocols for device registration that yield plug-and-play functionality. Finally, we are working with clinicians to build interesting and useful applications of this technology.
Progress Through June 2002
This project evolved from the SpectrumWare project which was funded, in part, by NTT. In SpectrumWare we pushed the boundary between software and hardware in the communications domain. Here we are doing much the same thing in a different domain. A medical device consists of a sensor or actuator connected to an A/D converter and a (usually) low cost low power wireless network interface.
In the first phase of this project, we designed a multi-tiered architecture. Our architecture employs a collection of gateways and software proxies to bring sensors and actuators onto the network. All information processing occurs in the proxies, which are chained together to perform data fusion and create new virtual devices. User interfaces are completely separated from both devices and proxies. This facilitates remote monitoring using user interface devices ranging from large format high resolution displays to 3G telephones.
In the next phase we gathered some experience with all aspects of the system, by building a relatively primitive, but comprehensive, prototype. This included
á A prototype device and network manager. This software is responsible for managing the network. This includes detecting the arrival and departure of devises, connecting proxies to devices and to each other, supplying data to remote monitors, and providing security. The relatively small scale of the network makes it possible to centralize much of the control.
á Communication protocols,
á Several physical devices, including an invasive blood pressure device, a network controlled drug infusion pump and an electronic stethoscope.
á Device proxies for the physical devices and for a number of virtual devices, e.g., a cardiac monitor driven by the Massachusetts General Hospital cardiac data base,
á Synthetic devices, e.g., a robust heart rate monitor, built by connecting proxies for multiple physical devices, and
á Wireless remote monitoring communications and application software.
The experience gathered during this phase helped us to solidify our overall system architecture. We are now confident that we have a framework that will serve us well going forward.
In the most recent phase of the project we made progress in the following areas:
¤ Improved our prototype system
¤ Built a sensor that combines an electronic stethoscope with an ECG and connected it wirelessly to our network
¤ Designed patient-specific algorithms to detect the onset of epileptic seizures
¤ Designed algorithms to analyze cardiac abnormalities
¤ Began work on an alerting system
In order to evaluate our system in more real-world conditions, we are planning to develop proxies to assist clinicians in analyzing EEG data in real-time. This is important in localizing the focus of an epileptic seizure. To this end we looked at EEG signals collected and classified by clinicians at ChildrenŐs Hospital and we implemented several different algorithms for detecting the onset of epileptic seizures. Currently we are testing the algorithms against a database of seizures. These algorithms will be used in proxies to analyze data collected from patients in real-time. When the onset of a seizure is detected our software will notify clinicians and inject radioactive dyes so that the focus of the seizure can be found via SPECT.
Using data collected and classified by clinicians at Massachusetts General Hospital, we are developing algorithms to classify heart murmurs. Murmurs can indicate serious conditions, such as mitral valve prolapse, or less serious conditions, such as aortic stenosis. Current practice requires a relatively costly procedure, echo cardiogram, to distinguish among these murmurs. We are seeking to develop software to distinguish the various classes of murmurs, based on easily collected acoustic and electrical data.
Work on our prototype system included a redesign to make it more robust and the integration of a new acoustic sensor. This sensor is more sensitive than other electronic stethoscopes. We have integrated this stethoscope with a simple ECG so that we can easily map the acoustic signal to parts of the heart cycle. The time correlated data streams from these sensors are sent over a wireless network connection to software proxies.
In order to assure properties related to safety criticality, we started work on a principled and systematic way to build alerting systems. Our software architecture links sensors and actuators with patients and caretakers and provides sophisticated mechanisms for detecting problems and raising alerts. An ideal alerting system would detect every problem, issue no false alarms, provide sufficient advanced notification to allow for preventive interventions, and warn medical personnel when an intervention has the potential to preclude potentially useful future treatments.
A perfect alerting system is not possible. There is always uncertainty about the quality of data, the interpretation of the data, and future events. The detrimental effects of this uncertainty clearly manifest themselves in existing medical alert systems. Most noticeably, false alarms are rampant, as any visit to an ICU makes clear. Missed detections also occur, sometimes with catastrophic results.
We are starting by designing a formal model of the alerting system for a number of medical environments. It is based on an approach devised by Jim Kuchar of MITŐs Astro and Aero Department. It converts the problem to the domain of signal-detection theory, where one must determine if a known signal is present in background noise. He models uncertainties using probability density functions, from which the probabilities of false detections and missed detections can be calculated. This mechanism enables informed decisions on how to set appropriate policies.
Research Plan for the Next Six Months
We do not anticipate receiving funding from NTT for this project during this period.