您的当前位置:首页正文

IMPROVING PATIENT MONITORING AND TRACKING IN EMERGENCY RESPONSE

2024-01-18 来源:伴沃教育
IMPROVING PATIENT MONITORING AND TRACKING IN EMERGENCY RESPONSE

Tia Gao1, Dan Greenspan2, Matt Welsh3

1,2

The Johns Hopkins University Applied Physics Laboratory

3

Division of Engineering and Applied Sciences, Harvard University, MA, USA

1,2

11100 Johns Hopkins Rd, Laurel, MD 20723, USA

3

233 Maxwell Dworkin, 33 Oxford St.m Cambridge, MA 02138, USA

Tel: 11-240-228-3475, 21-240-228-7490, 31-617-495-3311

1

tia.gao@jhuapl.edu, 2daniel.greenspan@jhuapl.edu, 3mdw@eecs.harvard.edu

Abstract: Patients at disaster scenes can greatly benefit from technologies that continuously monitor their vital status and locations until they are admitted to the hospital. We have designed and developed a patient monitoring system that integrates vital signs sensors, location sensors,

ad-hoc networking, electronic patient records, and web portal technology to allow remote monitoring of patient vital-sign status. This system shall facilitate collaboration between providers at the disaster scene, medical professionals at local hospitals, and specialists or

experts who might be available for consultation from distant facilities.

Introduction

Steady advances in wireless networking, medical sensors, and interoperability software create exciting possibilities for improving the way we provide emergency care. The Advanced Health and Disaster Aid Network (AID-N), being developed at The Johns Hopkins University Applied Physics Laboratory, explores and showcases how these advances in technology can be employed to assist victims and responders in times of emergency. The scope of this paper covers a subset of the technologies in AID-N.

We have developed a system that facilitates collaborative and time-critical patient care in the emergency response community. During a mass casualty disaster, one of the most urgent problems at the scene is the overwhelming number of patients that must be monitored and tracked by each first responder. The ability to automate these tasks could greatly relieve the workload for each responder, increase the quality and quantity of patient care, and more efficiently deliver patients to the hospital. Our system accomplishes this through the following technologies:

Wearable sensors to sense and record vital signs into an electronic patient record database. This dramatically improves the current time-consuming process of manually recording vital signs onto paper pre-hospital care reports and then converting the reports into electronic form for the hospitals.

Pre-hospital patient care software with algorithms to continuously monitor patients’ vital signs and alert the first responders of critical changes.

A secure web portal that allows authenticated users to collaborate and share real-time patient information.

AID-N uses open-standard software and best-of-breed hardware to deliver a scalable, open, and reliable infrastructure that paves the way for the development of new capabilities and the extension of existing technologies.

In order to understand user needs, we collaborated with physicians and nurses at Suburban Hospital Emergency Department (Bethesda, Maryland), physicians and bioinformatics experts at the Johns Hopkins Pediatric Trauma Center (Baltimore, Maryland), and first responders in the local area.

Methodology

During health emergencies, when time is of the essence, there is little tolerance for system errors and poor usability designs. The goal for our design is to identify existing hardware and software solutions that meet user needs and combine them with open-standard software to provide an integrated solution with an effective user interface.

The wearable sensors we selected were designed by the CodeBlue project at Harvard University [1]. CodeBlue is a distributed wireless sensor network for sensing and transmitting vital signs and geolocation data. Figure 1 illustrates our current prototype. A wearable computer attached to the patient’s wrist, commonly known as smart dust or mote, forms an ad hoc wireless network with a portable tablet PC. A GPS device on the mote provides the patient’s geolocation. A pulse oximeter sensor on the patient’s finger measures heart rate (HR) and blood oxygenation level (SpO2) of the patient. The tablet PC is harnessed to the first responder in a weatherproof and anti-glare casing. This packaging allows it to be used during rainy days or under bright sunlight.

As in Fig. 1, the mote regularly transmits vitals in real-time to the first responder’s tablet device. The transmission uses the TinyOS Active Message protocol, which is based on the IEEE 802.15.4 standard [2]. The mote was originally developed at the University of California Berkeley in the late 1990’s. Since then, it has gained significant interest from academia and industry for its ability to provide low-power, cost-effective, reliable wireless networks for monitoring applications. Our mote prototype uses the MICAZ platform from Crossbow Technology. It is powered by 2 AA batteries and consumes roughly 20 mA when active, resulting in a battery lifetime of 5–6 days of continuous operation. It uses a single-chip radio, with a maximum data rate of 76.8 kbps and practical indoor range of approximately 20–30 m.

The system is designed to require little setup time. Each medic carries many mote packages and distributes them to the patients. Each mote comes with a pre-attached paper triage tag. When the patient is first triaged, the medic straps the mote wristband on the patient, places the finger sensor on the patient’s finger, and tears the

FIGURE 1. Information flow of AID-N system.

triage tag to patient’s triage category (red/yellow/green). The mote automatically starts transmitting data to the medic’s tablet PC.

We integrated these wearable sensors with a pre-hospital patient care software package (MICHAELS) created by the OPTIMUS Corporation. MICHAELS runs on the first responder’s tablet PC. We modified MICHAELS to automatically record and analyze the patients’ vital signs and alert the first responder of abnormal changes. MICHAELS also transmits patients’ information in real time to a central server that hosts the patient record database. The tablet PC requires a network connection to communicate with the central server. In our implementation, we take advantage of Verizon’s EVDO coverage in the Washington, D.C., Metropolitan Area. Our tablet PCs use EVDO wireless cards to attain network connectivity at high data rates from anywhere in the greater Washington area.

We’ve built a web portal to connect with the patient record database and make the real-time patient information accessible to users from Internet browsers. This web portal will be used by different participants in the emergency response team, such as the emergency department personnel who need this information to prepare for the incoming patient.

Effective healthcare requires access to patient data that are generally stored on heterogeneous database systems. Integration of patient data is a significant challenge faced by the healthcare community. In our implementation, we are able to connect two disparate systems, that is, the patient record database and the web portal, through the use of well defined web services. Patient information is transmitted over SOAP, a secure and encrypted form of XML. The WSDL (Web Service Definition Language) for these web services is published to a community of authorized users. This web service-based approach for intersystem communication gives our software the flexibility to interoperate with third-party software systems in the future.

Implementation

Vitals Monitor Algorithm

Software on the tablet device receives live patient data from the mote and processes them to detect anomalies. If the patient has a medical record that has been previously entered, information from the medical record is used in the alert detection algorithm. Table I shows a partial list of physiological conditions that cause alerts. The algorithm uses additional information such as patient age, disease state (e.g., fever, congenital heart failure, anemia), smoking history, and the environment (e.g., altitude) to adjust its thresholds. If additional information is not available, the algorithm uses a set of default values. Pre-hospital Patient Care Software

MICHAELS is integrated with an electronic patient record database server hosted at OPTIMUS Corporation. The tablet PC regularly transmits vitals data and alerts for multiple patients to the

TABLE I ALERT DETECTION PARAMETERS [3, 4, 5] Alert Type Detection Parameter Low SpO2 SpO2 < 94%* Bradycardia HR < 55bpm* Tachycardia HR > 140bpm* HR change ∆HR5min>15bpm * These are defaults values, and are adjusted based on additional input from the patient medical record. electronic patient record database via a wireless network. If network connectivity is unavailable, the patient monitor and alert system on the tablet PC continue to operate.

When an anomaly is detected, the medic’s software application generates an alert in the user interface, and an LED on the patient’s mote turns on. Figure 2 shows an alert in the software application. The medic can locate the patient by selecting to view a map of the disaster scene marked with the GPS location of each patient. The medic can also select a “sound alert” feature that will sound a buzzer and blink an LED on the mote. The medic can choose to dock the alerts so that all alerts appear inside a side panel of the software program, making them easier to track.

When a patient boards the ambulance, the paramedic onboard can load the patient record into his or her MICHAELS software and indicate the hospital to which the patient is being transported. MICHAELS also has the capability of writing the patient medical record onto the mote. This allows the patient record to be stored locally with the patient. The information can be later read from the mote when the patient arrives at the hospital. Web Portal

An effective emergency response information system should support the need for multiple parties to share information about patients’ status and locations. Our web-based information portal allows different types of users to access the patient information in real-time. When a user logs in, the information displayed to that particular user is managed by group-level permissions. The portal has four groups of users.

1. Emergency department personnel log in to the portal to retrieve information about the patients who are being transported to their hospital. Figure 3 shows a page in the portal for this group of users. 2. Incident commanders log in to the portal to see summaries of patients at

Figure 1: MICHAELS showing an alert

Figure 3: Web portal for emergency room personnel

particular disaster scenes. This allows them to make informed requests for additional medical supplies and personnel and to properly allocate available resources.

3. Medical specialists, often located at distant facilities, may be called on to give treatment instructions to the medics at the scene. They log in to view real-time medical data of the patient. They can then provide instructions to the medics over a variety of communication methods, including the PSTN, IP video conferencing, or IP telephony. 4. The general public can view public information about the health disasters. No login is required for this class of users.

Conclusion and Future Work

The AID-N system has great potential in improving problems in today’s emergency response system, especially in plans to deal with mass casualty disasters. While designing our system, our team collaborated extensively with medical professionals in the area and built a prototype to meet their greatest needs.

The key activities which could be improved using technology are: patient monitoring, record generation and remote record review. AID-N has constructed hardware and software prototypes to address these areas, and shows promise in improving the efficiency of emergency personnel for these activities.

All technologies have limitations, and cannot provide their benefits under all circumstances. When new technology is introduced into the emergency response arena, it is important to note its limitations as well as its capabilities. Due to the chaotic nature of emergencies, our system faces the challenge of operating in situations that challenge instrumentation designed for use in the controlled environment of a clinical situation. For example, the pulse oximeter sensor used by AID-N cannot function on patients with finger nail polish. In cold temperatures and/or high altitudes, the body responds through vasoconstriction in the peripherals; in this case, blood flow to the fingers is restricted and does not register accurately on the pulse oximeter.

The patient monitoring feature will not be useful in all situations. In a mass casualty disaster, when the medics must triage many casualties quickly, they will not have time to respond to alerts until all patients have been triaged. Medics expect the monitoring system to be most useful for patients who have been triaged and are waiting for ambulances. They can then use our system to prioritize the patients who need to be transported by ambulance.

In addition to pulse oximeter data, non-invasive blood pressure monitoring was identified as a highly desirable feature, and will be considered for integration into the next version of our system.

Pilot exercises are being conducted at Suburban Hospital, Johns Hopkins Pediatric Trauma Center, and an auxiliary care center in Silver Spring, Maryland. Lessons learned from these trials will be used to improve the next version of our system.

Acknowledgments

This research is supported by a contract with the National Library of Medicine. Thanks to Steve Babin, Tag Cutchis, and Brian Feighner for their medical expertise; Ron Stickley and

Marty Sikes for insight into first responders’ line of work, and Jeffrey Chavis and David White for their project guidance.

References

[1] Lorincz, K., et al. (2004). Sensor Networks for Emergency Response: Challenges and

Opportunities. IEEE Pervasive Computing, 3(4), 16-23. [2] Hill, J., et al. (2000). System Architecture Directions for Networked Sensors. In Proc. 9th Int’l

Conf. Architectural Support for Programming Languages and Operating Systems (pp. 93-104). Cambridge, Massachusetts, United States. [3] Palatini, C. (1999) “Need for a Revision of the Normal Limits of Resting Heart Rate,” Journal

of Hypertension, Lippincott Williams & Wilkins, 33(2), 622-625. [4] Schwartz, G.R. (1999) Principles and Practice of Emergency Medicine. King of Prussia, PA:

Rittenhouse Book Distributors. [5] Behrman, R. E. (2000) Nelson Textbook of Pediatrics. Philadelphia, PA: W.B. Saunders

Company.

因篇幅问题不能全部显示,请点此查看更多更全内容