CA2797545A1 - Patient monitoring and alarm system - Google Patents
Patient monitoring and alarm system Download PDFInfo
- Publication number
- CA2797545A1 CA2797545A1 CA2797545A CA2797545A CA2797545A1 CA 2797545 A1 CA2797545 A1 CA 2797545A1 CA 2797545 A CA2797545 A CA 2797545A CA 2797545 A CA2797545 A CA 2797545A CA 2797545 A1 CA2797545 A1 CA 2797545A1
- Authority
- CA
- Canada
- Prior art keywords
- data
- patient
- server
- alarm
- monitoring system
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/0002—Remote monitoring of patients using telemetry, e.g. transmission of vital signals via a communication network
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/103—Detecting, measuring or recording devices for testing the shape, pattern, colour, size or movement of the body or parts thereof, for diagnostic purposes
- A61B5/11—Measuring movement of the entire body or parts thereof, e.g. head or hand tremor, mobility of a limb
- A61B5/1118—Determining activity level
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/02—Detecting, measuring or recording pulse, heart rate, blood pressure or blood flow; Combined pulse/heart-rate/blood pressure determination; Evaluating a cardiovascular condition not otherwise provided for, e.g. using combinations of techniques provided for in this group with electrocardiography or electroauscultation; Heart catheters for measuring blood pressure
- A61B5/0205—Simultaneously evaluating both cardiovascular conditions and different types of body conditions, e.g. heart and respiratory condition
-
- A—HUMAN NECESSITIES
- A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
- A61B—DIAGNOSIS; SURGERY; IDENTIFICATION
- A61B5/00—Measuring for diagnostic purposes; Identification of persons
- A61B5/02—Detecting, measuring or recording pulse, heart rate, blood pressure or blood flow; Combined pulse/heart-rate/blood pressure determination; Evaluating a cardiovascular condition not otherwise provided for, e.g. using combinations of techniques provided for in this group with electrocardiography or electroauscultation; Heart catheters for measuring blood pressure
- A61B5/024—Detecting, measuring or recording pulse rate or heart rate
Abstract
A patient monitoring and alarm system is arranged to track vital sign data of patients from a plurality of heterogeneous monitoring devices. A protocol translation adapter is associated with each monitoring device to translate the heterogeneous data into a standard language for vital sign monitoring, and to wirelessly transmit the translated data to an associated access point of a server for further processing. At the server, the data is analyzed according to a standard vital sign rule set for determining alarm conditions, and alarms are expressed via one or more interfaces to the server in one or more of visual, aural, text and text-to-speech forms. The vital sign rule set accounts for current patient events and conditions in determining an alarm condition. The server also applies an escalation rules base for the escalation of alarms.
Description
Patient Monitoring And Alarm System Cross-Reference to Related Application This application claims priority under 35 U.S.C. 119(e) to U.S. Provisional Patent Application No. 61/174,107, filed on April 30, 2009 and entitled "Open Critical Care Interconnect," which is hereby incorporated by reference herein in its entirety.
Field of the Invention The present invention relates to a patient monitoring and alarm system, and more particularly, to a patient monitoring and alarm system for tracking vital sign data of patients from a plurality of heterogeneous monitoring devices, translating the heterogeneous data according to a standard protocol, analyzing the data according to a standard rule set for determining alarm conditions, and transmitting alarms which are expressed by one or more of visual, aural, text and text-to-speech mechanisms.
Background of the Invention Preventable, in-hospital medical errors account for a substantial number of deaths in the United States. Various studies estimate that such deaths number between 100,000 and 200,000 deaths each year, and in effect constitute a national epidemic.
These same studies suggest that hospitals that invest in information technology for medical care generate fewer errors than those that do not. Estimates suggest that if all patients were admitted to the best performing hospitals in this regard, several thousand lives and several hundred million dollars could be saved annually.
Hospitals use sophisticated equipment to maintain the state of a patient's health. For example, such equipment may include ventilators for moving breathable air into and out of a patient's lungs, infusion pumps for infusing fluids, medication and/or nutrients into a patient's circulatory system, pulse oximeters for measuring the oxygen saturation of a patient's blood, and cardio monitors for monitoring the electrical and pressure waveforms of a patient's cardiovascular system. The equipment is also used to monitor patient health or "vital signs," of which the following are most typical:
1. body temperature,
Field of the Invention The present invention relates to a patient monitoring and alarm system, and more particularly, to a patient monitoring and alarm system for tracking vital sign data of patients from a plurality of heterogeneous monitoring devices, translating the heterogeneous data according to a standard protocol, analyzing the data according to a standard rule set for determining alarm conditions, and transmitting alarms which are expressed by one or more of visual, aural, text and text-to-speech mechanisms.
Background of the Invention Preventable, in-hospital medical errors account for a substantial number of deaths in the United States. Various studies estimate that such deaths number between 100,000 and 200,000 deaths each year, and in effect constitute a national epidemic.
These same studies suggest that hospitals that invest in information technology for medical care generate fewer errors than those that do not. Estimates suggest that if all patients were admitted to the best performing hospitals in this regard, several thousand lives and several hundred million dollars could be saved annually.
Hospitals use sophisticated equipment to maintain the state of a patient's health. For example, such equipment may include ventilators for moving breathable air into and out of a patient's lungs, infusion pumps for infusing fluids, medication and/or nutrients into a patient's circulatory system, pulse oximeters for measuring the oxygen saturation of a patient's blood, and cardio monitors for monitoring the electrical and pressure waveforms of a patient's cardiovascular system. The equipment is also used to monitor patient health or "vital signs," of which the following are most typical:
1. body temperature,
2. pulse rate (or heart rate),
3. blood pressure, and
4. respiratory rate.
Temperature recording gives an indication of core body temperature, which is normally tightly controlled as it affects the rate of chemical reactions.
Blood pressure is recorded with two readings: a high systolic pressure which results from the maximal contraction of the heart, and the lower diastolic or resting pressure.
The difference between the systolic and diastolic pressure is called the pulse pressure.
Blood pressure is typically monitored via a cuff that is placed over the arm.
Blood pulse is evidenced by a physical expansion of the arteries resulting from heart contractions. Its rate is usually measured either at the wrist or the ankle, and is typically recorded as beats per minute. Pulse rate is commonly measured via the radial artery at the wrist.
Respiratory rate varies with age, but the normal reference range for an adult is 12-20 breaths/minute. The value of respiratory rate as an indicator of potential respiratory dysfunction however has been subject to some debate.
For a typical hospital patient, vital sign information is typically provided by a number of "heterogeneous" pieces of equipment produced by a variety of manufacturers, each with its own attendant cabling and data protocols. As the number of these devices per patient grows, it becomes challenging for a caregiver to monitor information provided by each of the different pieces of equipment, and to integrate the information provided by each one to determine an overall state of health for the patient. Moreover, as patient to nurse ratios increase, information monitoring becomes even more challenging, as caregivers attend to a greater numbers of patients, and spend less time at caregiver stations where information for all attended patients may be is available.
Notably, operation of equipment important to patient health can be temporarily suspended during a particular caregiving procedure. For example, ventilation may be suspended during surgery or diagnostic testing. In such cases, it is possible for the caregiver to forget to reapply the equipment after the caregiving procedure has been completed, thereby subjecting the patient to harmful consequences including the risk of death.
It would be of benefit to provide a system which is capable of collecting data from a variety of heterogeneous pieces of medical equipment in a manner that reduces clutter and transforms heterogeneous data into a common language or protocol for integration and analysis. It would also be of benefit to provide a system which is able to intelligently determine an alarm condition according to a procedural status of a patient, and is capable of issuing alarms expressed by one or more of visual, aural, text and text-to-speech mechanisms according to an escalation procedure.
Summary of the Invention The present invention is directed to a system for monitoring patient care that is capable of interfacing with a heterogeneous array of medical care equipment in order to obtain monitoring data. The monitoring data includes data for sensing a set of physiologic conditions of a patient being monitored. The system preferably includes a series of wireless interface devices which acquire data from each piece of medical care equipment in its native form, and translate the native-form data into a standard language for vital signs ("A") that is wirelessly transmitted to an associated access point of a server for further processing. Suitable wireless platforms for providing the wireless transmission include, for example, IEEE's 802.11 WiFi platform, SUN
MICROSYSTEMS' Sun SPOT platform, and emerging Radio Frequency Identification (RFID) platforms. Each interface device preferably includes a middleware component (device driver) which is configured for translating the native form data into the standard language/protocol.
Also in communication with the server are one or more patient attendant's stations (for example, a nurse's station) at which vital sign data and associated alarms are presented. In addition, a secure Internet portal preferably provides remote access to the server for vital sign data and associated alarms.
The standard language A as applied in the wireless interface devices is defined by two entities. The first entity q) defines a communication protocol of the language, and the second entity A defines a data structure of the language. The first entity I is preferably defined according to a finite number of states Q, a receiver base node or server p, a finite set of wireless nodes W, and encryption and decryption functions Enc(A), Dec(A).1 The second entity A is preferably defined by a status data set E and a real time data stream i. The status data set E preferably includes data formed as patient status messages PS and device status messages DS. The real time data stream i preferably includes data records each representing a real time function f (t) and data representing a schema S, in association with one of the wireless nodes W, where the real time function f (t) can be translated into one of the vital signs based on the identified schema.
The real time data stream i may be processed by the server to prepare the patient status messages PS. In this case, the server applies vital sign rules resident in the server to determine whether vital signs data collection is active, and if so, whether the vital signs of any patient indicate an alarm condition. The rules for determining an alarm condition may further depend on a patient event indicator indicating a patient's current condition. For example, the rules may suspend indicating a vital sign alarm for a predetermined period of time if the patient event indicator indicates that the patient is undergoing a surgical procedure.
The data status messages DS may be prepared as a result of system health monitoring activities undertaken by various components of the system. For example, each of the wireless interface devices may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the wireless interface device. If no heartbeat has been received for a given device, the server performs a diagnosis to determine an associated alarm condition. Data status messages DS may then prepared by the server to indicate the status of each of the wireless interface devices, including alarm conditions as warranted.
Additional health monitoring activities may also preferably be undertaken within the system. For example, the nurse's station may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of 1 The encryption and decryption functions are provided so that the wireless data transmission may comply with privacy provisions of the Health Insurance Portability and Accountability Act (HIPAA).
the nurse's station. In addition, the server may also be configured to periodically transmit a heartbeat signal to one or more of the nurse's station or the wireless devices, while the server is in an idle state with reference to the nurse's station in order to confirm the health of the server.
The server also preferably includes an alarm escalation rules base for determining a delivery and escalation procedure for patient and device alarms.
For example, a rule set for a current patient may provide that an alarm condition is initially reported via a display of the nurse's station and via visual and aural alarms located in proximity to the patient's hospital room. If the alarm is not acknowledged at the nurse's station within a predetermined period of time, the rules may preferably provide an escalation procedure that forwards the alarm to a personal communication device of an attending nurse (for example, by creating an associated text-based alarm message and converting the text ro speech for transmission via a Voice over IP
(VoIP) interface of the server to the attending nurse's cell phone).
Brief Description of the Drawings The invention will become more readily apparent from the Detailed Description of the Invention, which proceeds with reference to the drawings, in which:
FIG. 1 shows a schematic block diagram illustrating a physical architecture of a patient monitoring and alarm system in accordance with the present invention;
FIG. 2 illustrates a logical architecture of the patient monitoring and alarm system of FIG. 1;
FIG. 3 illustrates a software architecture of the patient monitoring and alarm system of FIG. 1;
FIG. 4 shows a schematic block diagram illustrating an architecture for a remote translation device of the patient monitoring and alarm system of FIG.
1;
FIG. 5 illustrates a library of protocol translation adapters for use in the remote translation device of FIG. 4;
FIG. 6 shows a flow diagram illustrating an alarm prioritization procedure according to the present invention;
FIG. 7 shows a flow diagram illustrating a system health checking procedure according to the present invention; and
Temperature recording gives an indication of core body temperature, which is normally tightly controlled as it affects the rate of chemical reactions.
Blood pressure is recorded with two readings: a high systolic pressure which results from the maximal contraction of the heart, and the lower diastolic or resting pressure.
The difference between the systolic and diastolic pressure is called the pulse pressure.
Blood pressure is typically monitored via a cuff that is placed over the arm.
Blood pulse is evidenced by a physical expansion of the arteries resulting from heart contractions. Its rate is usually measured either at the wrist or the ankle, and is typically recorded as beats per minute. Pulse rate is commonly measured via the radial artery at the wrist.
Respiratory rate varies with age, but the normal reference range for an adult is 12-20 breaths/minute. The value of respiratory rate as an indicator of potential respiratory dysfunction however has been subject to some debate.
For a typical hospital patient, vital sign information is typically provided by a number of "heterogeneous" pieces of equipment produced by a variety of manufacturers, each with its own attendant cabling and data protocols. As the number of these devices per patient grows, it becomes challenging for a caregiver to monitor information provided by each of the different pieces of equipment, and to integrate the information provided by each one to determine an overall state of health for the patient. Moreover, as patient to nurse ratios increase, information monitoring becomes even more challenging, as caregivers attend to a greater numbers of patients, and spend less time at caregiver stations where information for all attended patients may be is available.
Notably, operation of equipment important to patient health can be temporarily suspended during a particular caregiving procedure. For example, ventilation may be suspended during surgery or diagnostic testing. In such cases, it is possible for the caregiver to forget to reapply the equipment after the caregiving procedure has been completed, thereby subjecting the patient to harmful consequences including the risk of death.
It would be of benefit to provide a system which is capable of collecting data from a variety of heterogeneous pieces of medical equipment in a manner that reduces clutter and transforms heterogeneous data into a common language or protocol for integration and analysis. It would also be of benefit to provide a system which is able to intelligently determine an alarm condition according to a procedural status of a patient, and is capable of issuing alarms expressed by one or more of visual, aural, text and text-to-speech mechanisms according to an escalation procedure.
Summary of the Invention The present invention is directed to a system for monitoring patient care that is capable of interfacing with a heterogeneous array of medical care equipment in order to obtain monitoring data. The monitoring data includes data for sensing a set of physiologic conditions of a patient being monitored. The system preferably includes a series of wireless interface devices which acquire data from each piece of medical care equipment in its native form, and translate the native-form data into a standard language for vital signs ("A") that is wirelessly transmitted to an associated access point of a server for further processing. Suitable wireless platforms for providing the wireless transmission include, for example, IEEE's 802.11 WiFi platform, SUN
MICROSYSTEMS' Sun SPOT platform, and emerging Radio Frequency Identification (RFID) platforms. Each interface device preferably includes a middleware component (device driver) which is configured for translating the native form data into the standard language/protocol.
Also in communication with the server are one or more patient attendant's stations (for example, a nurse's station) at which vital sign data and associated alarms are presented. In addition, a secure Internet portal preferably provides remote access to the server for vital sign data and associated alarms.
The standard language A as applied in the wireless interface devices is defined by two entities. The first entity q) defines a communication protocol of the language, and the second entity A defines a data structure of the language. The first entity I is preferably defined according to a finite number of states Q, a receiver base node or server p, a finite set of wireless nodes W, and encryption and decryption functions Enc(A), Dec(A).1 The second entity A is preferably defined by a status data set E and a real time data stream i. The status data set E preferably includes data formed as patient status messages PS and device status messages DS. The real time data stream i preferably includes data records each representing a real time function f (t) and data representing a schema S, in association with one of the wireless nodes W, where the real time function f (t) can be translated into one of the vital signs based on the identified schema.
The real time data stream i may be processed by the server to prepare the patient status messages PS. In this case, the server applies vital sign rules resident in the server to determine whether vital signs data collection is active, and if so, whether the vital signs of any patient indicate an alarm condition. The rules for determining an alarm condition may further depend on a patient event indicator indicating a patient's current condition. For example, the rules may suspend indicating a vital sign alarm for a predetermined period of time if the patient event indicator indicates that the patient is undergoing a surgical procedure.
The data status messages DS may be prepared as a result of system health monitoring activities undertaken by various components of the system. For example, each of the wireless interface devices may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the wireless interface device. If no heartbeat has been received for a given device, the server performs a diagnosis to determine an associated alarm condition. Data status messages DS may then prepared by the server to indicate the status of each of the wireless interface devices, including alarm conditions as warranted.
Additional health monitoring activities may also preferably be undertaken within the system. For example, the nurse's station may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of 1 The encryption and decryption functions are provided so that the wireless data transmission may comply with privacy provisions of the Health Insurance Portability and Accountability Act (HIPAA).
the nurse's station. In addition, the server may also be configured to periodically transmit a heartbeat signal to one or more of the nurse's station or the wireless devices, while the server is in an idle state with reference to the nurse's station in order to confirm the health of the server.
The server also preferably includes an alarm escalation rules base for determining a delivery and escalation procedure for patient and device alarms.
For example, a rule set for a current patient may provide that an alarm condition is initially reported via a display of the nurse's station and via visual and aural alarms located in proximity to the patient's hospital room. If the alarm is not acknowledged at the nurse's station within a predetermined period of time, the rules may preferably provide an escalation procedure that forwards the alarm to a personal communication device of an attending nurse (for example, by creating an associated text-based alarm message and converting the text ro speech for transmission via a Voice over IP
(VoIP) interface of the server to the attending nurse's cell phone).
Brief Description of the Drawings The invention will become more readily apparent from the Detailed Description of the Invention, which proceeds with reference to the drawings, in which:
FIG. 1 shows a schematic block diagram illustrating a physical architecture of a patient monitoring and alarm system in accordance with the present invention;
FIG. 2 illustrates a logical architecture of the patient monitoring and alarm system of FIG. 1;
FIG. 3 illustrates a software architecture of the patient monitoring and alarm system of FIG. 1;
FIG. 4 shows a schematic block diagram illustrating an architecture for a remote translation device of the patient monitoring and alarm system of FIG.
1;
FIG. 5 illustrates a library of protocol translation adapters for use in the remote translation device of FIG. 4;
FIG. 6 shows a flow diagram illustrating an alarm prioritization procedure according to the present invention;
FIG. 7 shows a flow diagram illustrating a system health checking procedure according to the present invention; and
-5-FIG. 8 shows a flow diagram illustrating an alarm escalation procedure according to the present invention.
Detailed Description of the Invention A preferred embodiment the present invention is described below, with reference to the drawings. This embodiment is provided to illustrate principles of the present invention, and is intended to be non-limiting.
Overview A patient monitoring and alarm system is arranged to track vital sign data of patients from a plurality of heterogeneous monitoring devices. A protocol translation adapter is associated with each monitoring device to translate the heterogeneous data into a standard language A for vital sign monitoring, and to wirelessly transmit the translated data to an associated access point of a server for further processing. At the server, the data is analyzed according to a standard vital sign rule set for determining alarm conditions, and associated alarms are expressed via one or more interfaces to the server in one or more of visual, aural, text and text-to-speech forms. The vital sign rule set accounts for current patient events and conditions in determining an alarm condition. The server also applies an escalation rules base to determine an escalation path for the alarms.
Detailed Description of the Invention A preferred embodiment the present invention is described below, with reference to the drawings. This embodiment is provided to illustrate principles of the present invention, and is intended to be non-limiting.
Overview A patient monitoring and alarm system is arranged to track vital sign data of patients from a plurality of heterogeneous monitoring devices. A protocol translation adapter is associated with each monitoring device to translate the heterogeneous data into a standard language A for vital sign monitoring, and to wirelessly transmit the translated data to an associated access point of a server for further processing. At the server, the data is analyzed according to a standard vital sign rule set for determining alarm conditions, and associated alarms are expressed via one or more interfaces to the server in one or more of visual, aural, text and text-to-speech forms. The vital sign rule set accounts for current patient events and conditions in determining an alarm condition. The server also applies an escalation rules base to determine an escalation path for the alarms.
-6-System Architecture FIG. 1 shows a schematic block diagram illustrating a physical architecture of an exemplary patient monitoring and alarm system 100 in accordance with the present invention. The system includes a centralized application/database server 101, which operates inter alia to receive and manage data received from other devices in the system 100, to determine alarm conditions through an analysis of the received data, and to dispatch alarm notification signals to the other devices. An array of remote translation devices 102 comprise wireless devices in communication with various patient vital sign monitors to collect vital sign data for transmission to the centralized application/database server 101 via wireless access point 103 and network 104.
Although not illustrated, multiple wireless access points are typically provided with capacity for communicating with a large number of remote translation devices geographically distributed over a large area and on multiple floors of an associated hospital or other health care facility.
A plurality of local alarm notification devices 105 (for example, light and sound indicators installed in proximity to a patient room) may preferably be provided and controlled through a conventional dry-contact IP relay 106. A nurse station terminal 107 is typically placed at a nurse's station, and is preferably configured for receiving text to speech vocal alarms, as well as visual alarms and/or alarm reports that appear on a display screen of the nurse station terminal 107. In addition, text to speech vocal alarm messages may be dispatched, for example, via a commercial Voice over IP (VoIP) platform to nurses and staff mobile phones 108 in the possession of nurses and other staff who are not present at the nurse station terminal 107.
The system is also preferably configured to enable remote connection of the system server 101 via a security firewall 109 to a remote client terminal 110 via the Internet 111 or another suitable distributed network. The system also preferably includes an administration terminal 112 for performing various administrative tasks such as authorizing users to the system 100 and maintaining rules bases and data and software stored on the server 101.
Although not illustrated, multiple wireless access points are typically provided with capacity for communicating with a large number of remote translation devices geographically distributed over a large area and on multiple floors of an associated hospital or other health care facility.
A plurality of local alarm notification devices 105 (for example, light and sound indicators installed in proximity to a patient room) may preferably be provided and controlled through a conventional dry-contact IP relay 106. A nurse station terminal 107 is typically placed at a nurse's station, and is preferably configured for receiving text to speech vocal alarms, as well as visual alarms and/or alarm reports that appear on a display screen of the nurse station terminal 107. In addition, text to speech vocal alarm messages may be dispatched, for example, via a commercial Voice over IP (VoIP) platform to nurses and staff mobile phones 108 in the possession of nurses and other staff who are not present at the nurse station terminal 107.
The system is also preferably configured to enable remote connection of the system server 101 via a security firewall 109 to a remote client terminal 110 via the Internet 111 or another suitable distributed network. The system also preferably includes an administration terminal 112 for performing various administrative tasks such as authorizing users to the system 100 and maintaining rules bases and data and software stored on the server 101.
-7-FIG. 2 shows illustrates a logical architecture for the system 100. The logical architecture 100 includes a control layer 120, a hardware platform layer 130 and a presentation layer 140.
In the control layer 120, a service 121 operates monitoring device drivers 122 for operating and communicating with monitoring device equipment 132 in the hardware platform layer 130 that collects the vital sign data from the various patient vital sign monitors (for example, ventilators and infusion pumps). The service receives the vital sign data collected by the monitoring device equipment 132, stores this data in one or more data engines 123, and carries out analyses to uncover alarm conditions. The service 121 operates alert device equipment 134 (for example, light indicators 105 and the nurse's station terminal 107) via alert device drivers 124 to provide alerting indicators of alarm conditions.
The service 121 also engages a web service 125 by which an administration terminal application 143 and/or a nurse station terminal application 144 of the presentation layer 140 may communicate with the service 121 via a server proxy 145.
In addition, a web service 146 is provided at the presentation layer 140 so that the administration terminal application 143 and/or the nurse station terminal application 144 may communicate with the service 121 via a terminal proxy 126 of the control layer.
Control layer 120 may also include, for example, a radio frequency identification (RFID) platform 127 for preparing the middleware components (protocol translation adapters) required to enable communications between the service 121 and RFID monitoring device equipment 132 receiving vital sign data from the patient vital sign monitors. In addition, one or more other device simulation platforms 128 may be provided to prepare middleware components for the monitoring device equipment 132.
Software Architecture FIG. 3 illustrates a software architecture for the system 100 of FIG. 1. The software architecture is presented in a multi-layer (or "three tier") structure. A
Presentation Layer 150 preferably contains three different user interface (UI) modules:
a Nurse Station Terminal user interface 151 for visual and text to speech alerts targeted for staff located at the station, an Administrator Terminal user interface 152
In the control layer 120, a service 121 operates monitoring device drivers 122 for operating and communicating with monitoring device equipment 132 in the hardware platform layer 130 that collects the vital sign data from the various patient vital sign monitors (for example, ventilators and infusion pumps). The service receives the vital sign data collected by the monitoring device equipment 132, stores this data in one or more data engines 123, and carries out analyses to uncover alarm conditions. The service 121 operates alert device equipment 134 (for example, light indicators 105 and the nurse's station terminal 107) via alert device drivers 124 to provide alerting indicators of alarm conditions.
The service 121 also engages a web service 125 by which an administration terminal application 143 and/or a nurse station terminal application 144 of the presentation layer 140 may communicate with the service 121 via a server proxy 145.
In addition, a web service 146 is provided at the presentation layer 140 so that the administration terminal application 143 and/or the nurse station terminal application 144 may communicate with the service 121 via a terminal proxy 126 of the control layer.
Control layer 120 may also include, for example, a radio frequency identification (RFID) platform 127 for preparing the middleware components (protocol translation adapters) required to enable communications between the service 121 and RFID monitoring device equipment 132 receiving vital sign data from the patient vital sign monitors. In addition, one or more other device simulation platforms 128 may be provided to prepare middleware components for the monitoring device equipment 132.
Software Architecture FIG. 3 illustrates a software architecture for the system 100 of FIG. 1. The software architecture is presented in a multi-layer (or "three tier") structure. A
Presentation Layer 150 preferably contains three different user interface (UI) modules:
a Nurse Station Terminal user interface 151 for visual and text to speech alerts targeted for staff located at the station, an Administrator Terminal user interface 152
-8-for system monitoring and for system history reports retrieval, and a Configuration Terminal user interface 153 that facilitates changing the system configuration and calibrating its performance.
A Security and Encryption Layer 155 allows Presentation Layer endpoint components served by UI modules 151 - 153 to connect to OpenCCI Services 171 in an Application Layer 170. The Security and Encryption Layer 155 allows the endpoints to communicate across the network 104, preventing eavesdropping and message tampering. This layer also preferably facilitates authentication and communication confidentiality using cryptographic methods, for example, as further described herein.
A "service" tier is presented through a host layer 160 including web services modules 161 that handle data validation, authentication, authorization, and transactions. Inter Process Communication channels (IPCs) 162 and an Internal Communication Foundation (ICF) 163 regulate and mange the distribution of data between internal services processes.
An application layer 170 includes a services module 171 that contains business objects and associated business rules and procedures which enable execution of system logic. A Data Layer 180 performs database access, and implements data retrieval from the physical devices that acquire patient vital sign data.
The Data Layer 180 preferably allows data storage and retrieval through secured channels. The Data Layer 180 operates to abstract the database system in use, so that any of a variety of underlying database systems (for example, Microsoft SQL, Oracle or XML file structures) can be used. The Data Layer 180 acquires data from devices that support monitoring (input data), sends data to devices that display or generate an alert (output data), and interacts with devices that allow bidirectional control.
External and Third Party Components Layer 190 provides application preferable interfaces for adding additional components to the system that have been developed by third parties. For example, in order to send SMTP emails from the system, a third party-developed API or SDL can be integrated via the External and Third Party Component Layer 190 to facilitate sending SMTP emails.
A Security and Encryption Layer 155 allows Presentation Layer endpoint components served by UI modules 151 - 153 to connect to OpenCCI Services 171 in an Application Layer 170. The Security and Encryption Layer 155 allows the endpoints to communicate across the network 104, preventing eavesdropping and message tampering. This layer also preferably facilitates authentication and communication confidentiality using cryptographic methods, for example, as further described herein.
A "service" tier is presented through a host layer 160 including web services modules 161 that handle data validation, authentication, authorization, and transactions. Inter Process Communication channels (IPCs) 162 and an Internal Communication Foundation (ICF) 163 regulate and mange the distribution of data between internal services processes.
An application layer 170 includes a services module 171 that contains business objects and associated business rules and procedures which enable execution of system logic. A Data Layer 180 performs database access, and implements data retrieval from the physical devices that acquire patient vital sign data.
The Data Layer 180 preferably allows data storage and retrieval through secured channels. The Data Layer 180 operates to abstract the database system in use, so that any of a variety of underlying database systems (for example, Microsoft SQL, Oracle or XML file structures) can be used. The Data Layer 180 acquires data from devices that support monitoring (input data), sends data to devices that display or generate an alert (output data), and interacts with devices that allow bidirectional control.
External and Third Party Components Layer 190 provides application preferable interfaces for adding additional components to the system that have been developed by third parties. For example, in order to send SMTP emails from the system, a third party-developed API or SDL can be integrated via the External and Third Party Component Layer 190 to facilitate sending SMTP emails.
-9-The external components preferably provide modules shared among the other layers including, for example, a set of utilities such as encryption, decryption and system performance logging.
Remote Translation Devices FIG. 4 provides a schematic diagram illustrating an architecture for a remote translation device 102 as depicted in FIG. 1. The architecture is descriptive of a number of suitable devices 102 employing various wireless platforms (for example, IEEE 802.11 and Sun SPOT platforms). The exemplary remote translation device as depicted in FIG. 4 has a processor 401 including a device interface port 402 that is configured to receive a data stream including patient vital sign data from a vital sign monitor 113. A microcontroller 403 includes a protocol translation adapter 405 which, with reference to stored program data in a memory 406, is operative to translate the vital sign data received from the vital sign monitor 113 (which is for example provided according to a data protocol of the manufacture of the vital sign monitor 113) into data formed according to the standard language/protocol for acquisition of vital signs as is described further herein. A communication section 404 of the microcontroller 403 further prepares the translated data (for example, by encrypting and encoding the translated data in an analog signal) for wireless transmission by wireless module 407 via an antenna 408 of the remote translation device 102.
FIG. 5 illustrates a library of protocol translation adapters 505 provided in accordance with the system of FIG. 1. As illustrated in FIG. 5, each of the protocol translation adapters 505 in the library is configured to receive a data signal formed according to one of a plurality of vital sign data protocols 515 associated with the plurality of patient data acquisition devices, and to translate this data to form a translated data signal formed according to the standard language 525 ("A") for vital sign data, the standard language A including a standard communications protocol q) and standard data structures A. The standard language A is further described below.
As illustrated in FIG. 4, the protocol translation adapters 405, 505 are preferably provided in the remote translation devices 102 so that the translation of data to the standard language A can be completed before the data is wirelessly sent by the remote translation device 102 to the wireless access point 103 of the server 101.
Remote Translation Devices FIG. 4 provides a schematic diagram illustrating an architecture for a remote translation device 102 as depicted in FIG. 1. The architecture is descriptive of a number of suitable devices 102 employing various wireless platforms (for example, IEEE 802.11 and Sun SPOT platforms). The exemplary remote translation device as depicted in FIG. 4 has a processor 401 including a device interface port 402 that is configured to receive a data stream including patient vital sign data from a vital sign monitor 113. A microcontroller 403 includes a protocol translation adapter 405 which, with reference to stored program data in a memory 406, is operative to translate the vital sign data received from the vital sign monitor 113 (which is for example provided according to a data protocol of the manufacture of the vital sign monitor 113) into data formed according to the standard language/protocol for acquisition of vital signs as is described further herein. A communication section 404 of the microcontroller 403 further prepares the translated data (for example, by encrypting and encoding the translated data in an analog signal) for wireless transmission by wireless module 407 via an antenna 408 of the remote translation device 102.
FIG. 5 illustrates a library of protocol translation adapters 505 provided in accordance with the system of FIG. 1. As illustrated in FIG. 5, each of the protocol translation adapters 505 in the library is configured to receive a data signal formed according to one of a plurality of vital sign data protocols 515 associated with the plurality of patient data acquisition devices, and to translate this data to form a translated data signal formed according to the standard language 525 ("A") for vital sign data, the standard language A including a standard communications protocol q) and standard data structures A. The standard language A is further described below.
As illustrated in FIG. 4, the protocol translation adapters 405, 505 are preferably provided in the remote translation devices 102 so that the translation of data to the standard language A can be completed before the data is wirelessly sent by the remote translation device 102 to the wireless access point 103 of the server 101.
-10-Alternatively, the protocol translation adapters 505 may be provided within the server 101.
When provided in the remote translation devices 102, the protocol translation adapters 505 are preferably configured to be downloaded by the server 101 to the remote translation devices 102 upon receipt of identification data from the remote translation devices 102 that identifies the manufacturer's data protocols for the associated patient data acquisition devices. In this manner, for example, the system may be easily reconfigured after re-assigning the remote translation devices among the patient data acquisition devices 113.
Standard Language The present invention incorporates a standard language/protocol for acquisition of vital signs, with a domain of standard data structures that is capable of representing all patient vital signs, compatible with conventional Electronic Medical Records schema.
A=((D,A) [1]
The standard language A includes two entities: c which defines the communication protocol within the language, and A which defines the data structures and the strings of data used within the language.
(D = (Q, p, W, 8, Enc, Dec, A) [2]
The communication protocol C is preferably defined by a finite set of states Q, a receiver base node or server p , a finite set of wireless nodes W = (wo, w, = = = w1z) which can communicate with the receiver or with each other using node-to-node based communication, and a communication partial function 6 that defines the communication between the nodes and cryptographic functions Enc, Dec on A for encrypting and decrypting the message.
When provided in the remote translation devices 102, the protocol translation adapters 505 are preferably configured to be downloaded by the server 101 to the remote translation devices 102 upon receipt of identification data from the remote translation devices 102 that identifies the manufacturer's data protocols for the associated patient data acquisition devices. In this manner, for example, the system may be easily reconfigured after re-assigning the remote translation devices among the patient data acquisition devices 113.
Standard Language The present invention incorporates a standard language/protocol for acquisition of vital signs, with a domain of standard data structures that is capable of representing all patient vital signs, compatible with conventional Electronic Medical Records schema.
A=((D,A) [1]
The standard language A includes two entities: c which defines the communication protocol within the language, and A which defines the data structures and the strings of data used within the language.
(D = (Q, p, W, 8, Enc, Dec, A) [2]
The communication protocol C is preferably defined by a finite set of states Q, a receiver base node or server p , a finite set of wireless nodes W = (wo, w, = = = w1z) which can communicate with the receiver or with each other using node-to-node based communication, and a communication partial function 6 that defines the communication between the nodes and cryptographic functions Enc, Dec on A for encrypting and decrypting the message.
-11-pxWxEnc(A), [3]
W x pxEnc(A), S: Qx pxW - Qx pxDec(A), W x Dec(A) w,xw, xEnc(A) where w,, w1 E W and i ~ j.
A = ~E, 2) [4]
A is composed of two main elements, the status data set E and the real time data stream T.
r = (w,, (Schema), f (t)) [5]
2 represents the acquisition of a real time function f (t) from a wireless sensor node wi (where wi e W) . The real time function f (t) can be interpreted to represent a patient vital sign through an identified schema for the vital sign.
(PS, wi,Respiration, {Idle, Alarm{, co) [61 (PS, wi,Cardio, {Idle, Alarm{, c1 ao DS, wl, Idle, jal The status data set E includes two types of status messages, patient status and device status. An initial token in each data string distinguishes between the two types ("PS," "DS"), followed by an identifier wi which indicates the source of the string.
W x pxEnc(A), S: Qx pxW - Qx pxDec(A), W x Dec(A) w,xw, xEnc(A) where w,, w1 E W and i ~ j.
A = ~E, 2) [4]
A is composed of two main elements, the status data set E and the real time data stream T.
r = (w,, (Schema), f (t)) [5]
2 represents the acquisition of a real time function f (t) from a wireless sensor node wi (where wi e W) . The real time function f (t) can be interpreted to represent a patient vital sign through an identified schema for the vital sign.
(PS, wi,Respiration, {Idle, Alarm{, co) [61 (PS, wi,Cardio, {Idle, Alarm{, c1 ao DS, wl, Idle, jal The status data set E includes two types of status messages, patient status and device status. An initial token in each data string distinguishes between the two types ("PS," "DS"), followed by an identifier wi which indicates the source of the string.
-12-In patient status messages PS, a third token identifies the vital sign, followed by a status indicator (for example, "idle" or "alarm") and coefficients {co, ci ...
}. In device status messages DS, the third token represents the status of the device, and the fourth token represents one or more device alarm codes {ao, a, = = *J. The coefficient c;
in the patient status messages PS may preferably be applied in alarm prioritization algorithms based on the coefficient weights.
Security In order, for example, to meet the strict medical information privacy provisions of the Health Insurance Portability and Accountability Act (HIPAA), the present invention preferably provides encryption and decryption for patient information that is wirelessly transmitted between the protocol translation adapters and the access points. A description of a preferred encryption/decryption method follows. For the purpose of describing this method, the protocol translation adapters are described as nodes in a wireless sensor network, and the access points are described as a server base station in this network.
For the purposes of the description, the encryption/decryption method is described with regard to communications between nodes. A similar method is employed for communications between a node and a base station.
In the node-to-node communication, a node wo initiates the communication to a node w, . Also, p is a server base station trusted by both parties, K., is a symmetric key known only to wo and p , K~, is a symmetric key known only to w, and p , N, o and N,, are nonces.
The protocol can be specified as follows:
WO -+p:WO ,wl,N.^
[7]
Node wo sends a message to the server identifying itself and wl, telling the server she wants to communicate with wl.
}. In device status messages DS, the third token represents the status of the device, and the fourth token represents one or more device alarm codes {ao, a, = = *J. The coefficient c;
in the patient status messages PS may preferably be applied in alarm prioritization algorithms based on the coefficient weights.
Security In order, for example, to meet the strict medical information privacy provisions of the Health Insurance Portability and Accountability Act (HIPAA), the present invention preferably provides encryption and decryption for patient information that is wirelessly transmitted between the protocol translation adapters and the access points. A description of a preferred encryption/decryption method follows. For the purpose of describing this method, the protocol translation adapters are described as nodes in a wireless sensor network, and the access points are described as a server base station in this network.
For the purposes of the description, the encryption/decryption method is described with regard to communications between nodes. A similar method is employed for communications between a node and a base station.
In the node-to-node communication, a node wo initiates the communication to a node w, . Also, p is a server base station trusted by both parties, K., is a symmetric key known only to wo and p , K~, is a symmetric key known only to w, and p , N, o and N,, are nonces.
The protocol can be specified as follows:
WO -+p:WO ,wl,N.^
[7]
Node wo sends a message to the server identifying itself and wl, telling the server she wants to communicate with wl.
-13-p -> w0 : {NWO, K,,0 ,I , wl, {KWOWl , w0 }K IP },,Op [8]
The server generates KWOW and sends back to wo a copy encrypted under KWP
for wo to forward to w1 and also a copy for wo. Since wo may be requesting keys for several different nodes, the nonce assures wo that the message is fresh and that the server is replying to that particular message and the inclusion of " w1 "
tells wo who to share this key with.
w0 -> w1 : {KWOWl I WO }K,, [9]
Node wo forwards the key to w1 which can decrypt it with the key it shares with the server, thus authenticating the data.
w1-> w0:{NW}K
[10]
Node w1 sends wo a nonce encrypted under KWOW to show that it has the key.
w0 -> w1 : {NW -1}KwO
[11]
Node wo performs a simple operation on the nonce, re-encrypts it and sends it back verifying that it is still alive and that it holds the key.
wo -> wl : {NWO,DA}K"on [12]
Node wo acquires patient vital sign Pvs from w1, by sending a data acquisition command.
The server generates KWOW and sends back to wo a copy encrypted under KWP
for wo to forward to w1 and also a copy for wo. Since wo may be requesting keys for several different nodes, the nonce assures wo that the message is fresh and that the server is replying to that particular message and the inclusion of " w1 "
tells wo who to share this key with.
w0 -> w1 : {KWOWl I WO }K,, [9]
Node wo forwards the key to w1 which can decrypt it with the key it shares with the server, thus authenticating the data.
w1-> w0:{NW}K
[10]
Node w1 sends wo a nonce encrypted under KWOW to show that it has the key.
w0 -> w1 : {NW -1}KwO
[11]
Node wo performs a simple operation on the nonce, re-encrypts it and sends it back verifying that it is still alive and that it holds the key.
wo -> wl : {NWO,DA}K"on [12]
Node wo acquires patient vital sign Pvs from w1, by sending a data acquisition command.
-14-w1 -> wo : {N Ili , PVS }KNo [13]
Node w1 responds with the patient vital sign Pvs to wo, as a reply to the data acquisition command.
The protocol as described above is however vulnerable to a replay attack. If an attacker uses an older compromised value for K,,ow, , he or she can then replay the message {K ,,,o,,,, , wo}KIP to w1, who will accept it, being unable to tell that the key is not fresh. This flaw is fixed in the Kerberos protocol by the inclusion of a timestamp.
Assuming that node wo has been compromised and moved back to the network, leading to the exposure of K,,,op , an attacking node w2 can perform the following:
p, w0 : {Nw0,K b,,,,w1,{Kwow1,w0}K ^P }K
OP
[14]
Node w2 decrypts the message using K,,,op , and retrieves K,,,o, w, -> w0 : {N,,,,PPS}Kwon
Node w1 responds with the patient vital sign Pvs to wo, as a reply to the data acquisition command.
The protocol as described above is however vulnerable to a replay attack. If an attacker uses an older compromised value for K,,ow, , he or she can then replay the message {K ,,,o,,,, , wo}KIP to w1, who will accept it, being unable to tell that the key is not fresh. This flaw is fixed in the Kerberos protocol by the inclusion of a timestamp.
Assuming that node wo has been compromised and moved back to the network, leading to the exposure of K,,,op , an attacking node w2 can perform the following:
p, w0 : {Nw0,K b,,,,w1,{Kwow1,w0}K ^P }K
OP
[14]
Node w2 decrypts the message using K,,,op , and retrieves K,,,o, w, -> w0 : {N,,,,PPS}Kwon
[15]
Node w2 decrypts the message using K,,, w, , and retrieve the patient vital sign o Pvs=
Taking advantage of the fact that a wireless node will require a battery charge to keep it operating (for example, after a period of two weeks), a base station used for charging the battery of the node can be further equipped to dispose of the current key and refresh the node with a newly generated key. In this case, the server 101 will 2 The Kerberos authentication system, a part of MIT's Project Athena, has been adopted by a number of entities for data encryption/decryption design. Despite Kerberos's many strengths, it has a number of limitations and some weaknesses. Some are due to specifics of the MIT
environment; others represent failures in the protocol design.
reassign and deliver a new key Kwop[t+1] to the base station, and dispose of the key Kwop[t] . Where t represents the current time session and t+1 is the following time session.
P w0 : {Nwo , Kwo i , w1, {Kwow1 I w0}KwoP }KwoPp+t]
Node w2 decrypts the message using K,,, w, , and retrieve the patient vital sign o Pvs=
Taking advantage of the fact that a wireless node will require a battery charge to keep it operating (for example, after a period of two weeks), a base station used for charging the battery of the node can be further equipped to dispose of the current key and refresh the node with a newly generated key. In this case, the server 101 will 2 The Kerberos authentication system, a part of MIT's Project Athena, has been adopted by a number of entities for data encryption/decryption design. Despite Kerberos's many strengths, it has a number of limitations and some weaknesses. Some are due to specifics of the MIT
environment; others represent failures in the protocol design.
reassign and deliver a new key Kwop[t+1] to the base station, and dispose of the key Kwop[t] . Where t represents the current time session and t+1 is the following time session.
P w0 : {Nwo , Kwo i , w1, {Kwow1 I w0}KwoP }KwoPp+t]
[16]
Node w2 cannot decrypt the message using Kwop[t] , and retrieve Kwow, The approach provides a slimmer window of vulnerability. If the attacker compromises node wo fast enough before disposing of the current key Kwop[tI , node w2 will be able to decrypt the message and retrieve K
wows .
Through the life cycle of the key Kwop[t] the message encryption can be done using a mutated version of the key. The mutated version of the key can for example be a permutation of the key string following the Xiaowen Zhang, Zhanyang Zhang and Xinzhou Wei (ZZW) technique, described in their RFID authentication protocol publication, incorporated by reference herein in its entirety.3 P w0 : {Nwo , Kwowt , w1, {Kwow, , w0 }KMP }K(=) "P[t]
Node w2 cannot decrypt the message using Kwop[t] , and retrieve Kwow, The approach provides a slimmer window of vulnerability. If the attacker compromises node wo fast enough before disposing of the current key Kwop[tI , node w2 will be able to decrypt the message and retrieve K
wows .
Through the life cycle of the key Kwop[t] the message encryption can be done using a mutated version of the key. The mutated version of the key can for example be a permutation of the key string following the Xiaowen Zhang, Zhanyang Zhang and Xinzhou Wei (ZZW) technique, described in their RFID authentication protocol publication, incorporated by reference herein in its entirety.3 P w0 : {Nwo , Kwowt , w1, {Kwow, , w0 }KMP }K(=) "P[t]
[17]
Here, KAS[t] -11K S[
Here, KAS[t] -11K S[
[18]
II: {O,1}n - {O, 1}n
II: {O,1}n - {O, 1}n
[19]
represent a permutation starting from the initial secret key K? [t] . That is 3 Xiaowen Zhang, Zhanyang Zhang, Xinzhou Wei: Enhancements to A Lightweight RFID
Authentication Protocol, arXiv:0810.3345v3 [cs.CR], http://arxiv.org/abs/0810.3345.
__ 1T K(~ ~) K(') _ TT (K(o) ) K(2 TT (K(l) ) K~ 11 (K(i 2)K(') wop[t] 1 1 wop[t] ' wop[t] 11 wop[t] '' . '' w0P[t] wop[t] ' wop[t] wop[t]
represent a permutation starting from the initial secret key K? [t] . That is 3 Xiaowen Zhang, Zhanyang Zhang, Xinzhou Wei: Enhancements to A Lightweight RFID
Authentication Protocol, arXiv:0810.3345v3 [cs.CR], http://arxiv.org/abs/0810.3345.
__ 1T K(~ ~) K(') _ TT (K(o) ) K(2 TT (K(l) ) K~ 11 (K(i 2)K(') wop[t] 1 1 wop[t] ' wop[t] 11 wop[t] '' . '' w0P[t] wop[t] ' wop[t] wop[t]
[20]
Node w2 cannot decrypt the message using K K(O) and retrieve Kwow , as the message is encrypted with a mutated version of the key K(') [t] .
While this approach can be used for different types of remote translation devices, it is a best suited for RFID encryption, where limited computational and memory resources are available, because the permutation function does not require large computational resources.
Monitoring Vital Signs The real time data stream i as described above is processed by the server to prepare the patient status messages PS of the status data setE. The server applies resident vital sign rules to determine whether vital signs data collection is active, and if so, whether the vital signs of any patient indicate an alarm condition. The rules for determining an alarm condition may differ according to a patient event indicator indicating a patient's current condition. For example, the rules may suspend indicating a vital sign alarm for a predetermined period of time, or allow more relaxed thresholds, if the patient event indicator indicates that the patient is undergoing a surgical procedure.
A practical example of the applicability of such rules follows. As reported in the Anesthesia Patient Safety Foundation (APSF) Newsletter for Winter 20054, a year-old woman had a laparoscopic cholecystectomy performed under general anesthesia. At the surgeon's request, a plane film x-ray was shot during a cholangiogram. The anesthesiologist stopped the ventilator in order to shoot the film.
After shooting the film, the x-ray technician was unable to remove the film because of its position beneath the table. The anesthesiologist attempted to help the x-ray technician, but found it difficult because the gears on the table had jammed.
Finally, the x-ray was removed, and the surgical procedure recommenced.
4 Sha, L. and Agrawala, A. 2006. Real time and embedded (RTE) GENI. SIGBED
Rev. 3, 3 (Jul. 2006) At some point thereafter, the anesthesiologist glanced at the EKG and noticed severe bradycardia. He realized he had never restarted the ventilator. This patient ultimately expired.
According to vital sign rules as would be applied according to the present invention, a stored rule for "X-Ray Ventilator bypass" could have in this case been defined to provide a period of limited time duration for the procedure (for example, 90 seconds). Applying this rule, the system would mute or ignore ventilator alarms for the period of limited duration, thereby avoiding past practice where surgical staff would likely disable the alarm (as was likely done by the surgical staff in example above) in the to keep the surgical environment quiet. According to the present invention, after the expiration of the time period of limited duration, the patient monitoring and alarm system would allow the muted ventilator alarms to be reinstated and dispatched. As a result, the risk faced by the surgical staff of forgetting to reactivate the muted alarm as described in the example above is eliminated.
In addition, in accordance with the present invention, the server 101 may preferably determine an alarm condition by one or more prioritization algorithms applying coefficients {co, ci ... } as defined in the patient status messages PS as weights. FIG. 6 shows a flow diagram illustrating an exemplary alarm prioritization procedure according to the present invention. This procedure could be important, for example, in a case where a set of "temperature increase" alarms arrive nearly simultaneously at a nurse station terminal 107, together with a cardiac alarm coming from a different patient. In this case, a prioritization procedure for prioritizing the cardiac alarm to make sure that the nurse is dispatched to assist the patient with the cardiac alarm first is critical.
In FIG. 6, a process 600 begins at step 601 with the acquisition of alarm data at one of the remote translation devices 102 or at server 101 from one of the vital sign monitors 113 indicating a patient alarm. At step 602, the remote translation device 102 or server 101 translates the alarm data, analyzes the translated data to determine a severity of the alarm, assigns a coefficient c; according to a determined severity of the alarm, and prepares an alarm data package identifying inter alia the type of alarm and its severity coefficient c;.
At step 603, server 101 analyzes the alarm data package to determine a vital sign alarm type, and in step 604, assigns a type priority value (TPV;) according to the identified vital sign alarm type (for example, cardio, ventilator or oximeter alarm). At step 605, server 101 sorts the alarm data packages according to the values of the coefficients c;, and at step 606, sorts the alarm data packages according to the type priority values TPV; and places the sorted alarm data packages in a buffer.
The server 101 reads an alarm data package of highest priority from the buffer at step 607, generates an alarm notification at step 608, and removes the alarm data package just read from the buffer at step 609. At step 610, the server 101 determines whether the buffer is empty, and if not, returns to step 607 to read a next alarm data message. If the buffer is empty, the server 101 terminates that alarm prioritization process 600 at step 611.
System Health The data status messages DS as described above are prepared based on system health monitoring activities undertaken by various components of the system.
For example, each of the wireless interface devices may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the wireless interface device. If no heartbeat has been received for a given device during a predetermined interval, the server performs a diagnosis to determine an associated alarm condition. Data status messages DS may then prepared by the server to indicate the status of each of the wireless interface devices, including alarm condition as warranted.
FIG. 7 illustrates an exemplary process 700 by which the health of various devices may be monitored by the server 101. The process is initiated in the server 101 at step 701, and then proceeds to step 702, at which the server 101 clears a current status record for each device in the system in order to begin the process of determining the current health of these devices.
Concurrently, the process is initiated in the various devices at step 703, and then proceeds to step 704, at which each device determines whether or not it has access to the server 101 at step 704. If no access is available, at step 705, the device generates a local alert (for example, audio and/or visual alarms discernible at the device) to instigate an appropriate service event. If the device determines that access to the serve 101 is available, the device generates a status data package at step 706 and transmits this package to the server at step 707. After generating the local alert at step 705 or generating the device status package at step 706, the device sets a sleep timer at step 708 to pause the process for a predetermined time period (for example, 5 seconds), and then returns to step 704 to determine whether or not it has access to the server 101.
At step 709, the server 101 receives the transmitted status data package, adds a time stamp to the received status data package and stores the received package. At step 710, the server 101 determines whether a status data package has been received from each device having a time stamp with no greater than a predetermined age (for example, 10 seconds). At step 711, for any device for which the current status data package time stamp exceeds the predetermined age, the server 101 issues a device disconnected alert to instigate an appropriate service event. After the time stamp age of the status data packages for each device has been determined, the process returns to step 702 to clear a current status record for each device and await the arrival of new status data packages from each of the devices.
Additional health monitoring activities may also preferably be undertaken within the system in accordance with the present invention. For example, the nurse's station may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the nurse's station. In addition, the server may also be configured to periodically transmit a heartbeat signal to one or more of the nurse's station or the wireless devices, while the server is in an idle state with reference to the nurse's station in order to confirm the health of the server.
Alarm Escalation The server also preferably includes an alarm escalation rules base for determining a delivery and escalation procedure for patient and device alarms.
For example, a rule set for a current patient may provide that an alarm condition is initially reported via a display of the nurse's station and via visual and aural alarms located in proximity to the patient's hospital room. If the alarm is not acknowledged at the nurse's station within a predetermined period of time, the rules may preferably provide an escalation procedure that forwards the alarm to a personal communication device of an attending nurse (for example, by creating an associated text-based alarm message and converting the text to speech for transmission via a Voice over IP
(VoIP) interface of the server to the attending nurse's cell phone). A commercial example of this technology is AT&T Labs Natural Voices Text-to-Speech a demo available at -http://www.research.att.com.
FIG. 8 illustrates an exemplary process 800 by which the escalation of alarms may be enacted by the server 101. At step 801, the server 101 begins the process of providing a patient alarm notification. At step 802, the server 101 determines a device ID for the device that indicated the alarm, and determines a patient physical location by retrieving stored device physical location information according to the device ID.
The association of a patient monitoring device with a location may be accomplished, for example, by two different methods. In a first "automated"
method, location may be determined by triangulating a radio frequency signal received at several antennas distributed within the territory served by an associated access point, or by localizing the signal according to signal strength at the access point.
In a second "manual" method, medical staff manually admit the patient and the device location information to a physical location record recorded through the Nurse Station Terminal 151. This association information is stored in the Data Layer, specifically in an underlying database system within this layer.
Based on the identified patient information, the server 101 identifies and activates visual and audio alarms in proximity to the patient at steps 803 and 804, respectively. At step 805, the server 101 identifies the nurse station 107 with a primary present responsibility for the patient at the identified physical location, and
Node w2 cannot decrypt the message using K K(O) and retrieve Kwow , as the message is encrypted with a mutated version of the key K(') [t] .
While this approach can be used for different types of remote translation devices, it is a best suited for RFID encryption, where limited computational and memory resources are available, because the permutation function does not require large computational resources.
Monitoring Vital Signs The real time data stream i as described above is processed by the server to prepare the patient status messages PS of the status data setE. The server applies resident vital sign rules to determine whether vital signs data collection is active, and if so, whether the vital signs of any patient indicate an alarm condition. The rules for determining an alarm condition may differ according to a patient event indicator indicating a patient's current condition. For example, the rules may suspend indicating a vital sign alarm for a predetermined period of time, or allow more relaxed thresholds, if the patient event indicator indicates that the patient is undergoing a surgical procedure.
A practical example of the applicability of such rules follows. As reported in the Anesthesia Patient Safety Foundation (APSF) Newsletter for Winter 20054, a year-old woman had a laparoscopic cholecystectomy performed under general anesthesia. At the surgeon's request, a plane film x-ray was shot during a cholangiogram. The anesthesiologist stopped the ventilator in order to shoot the film.
After shooting the film, the x-ray technician was unable to remove the film because of its position beneath the table. The anesthesiologist attempted to help the x-ray technician, but found it difficult because the gears on the table had jammed.
Finally, the x-ray was removed, and the surgical procedure recommenced.
4 Sha, L. and Agrawala, A. 2006. Real time and embedded (RTE) GENI. SIGBED
Rev. 3, 3 (Jul. 2006) At some point thereafter, the anesthesiologist glanced at the EKG and noticed severe bradycardia. He realized he had never restarted the ventilator. This patient ultimately expired.
According to vital sign rules as would be applied according to the present invention, a stored rule for "X-Ray Ventilator bypass" could have in this case been defined to provide a period of limited time duration for the procedure (for example, 90 seconds). Applying this rule, the system would mute or ignore ventilator alarms for the period of limited duration, thereby avoiding past practice where surgical staff would likely disable the alarm (as was likely done by the surgical staff in example above) in the to keep the surgical environment quiet. According to the present invention, after the expiration of the time period of limited duration, the patient monitoring and alarm system would allow the muted ventilator alarms to be reinstated and dispatched. As a result, the risk faced by the surgical staff of forgetting to reactivate the muted alarm as described in the example above is eliminated.
In addition, in accordance with the present invention, the server 101 may preferably determine an alarm condition by one or more prioritization algorithms applying coefficients {co, ci ... } as defined in the patient status messages PS as weights. FIG. 6 shows a flow diagram illustrating an exemplary alarm prioritization procedure according to the present invention. This procedure could be important, for example, in a case where a set of "temperature increase" alarms arrive nearly simultaneously at a nurse station terminal 107, together with a cardiac alarm coming from a different patient. In this case, a prioritization procedure for prioritizing the cardiac alarm to make sure that the nurse is dispatched to assist the patient with the cardiac alarm first is critical.
In FIG. 6, a process 600 begins at step 601 with the acquisition of alarm data at one of the remote translation devices 102 or at server 101 from one of the vital sign monitors 113 indicating a patient alarm. At step 602, the remote translation device 102 or server 101 translates the alarm data, analyzes the translated data to determine a severity of the alarm, assigns a coefficient c; according to a determined severity of the alarm, and prepares an alarm data package identifying inter alia the type of alarm and its severity coefficient c;.
At step 603, server 101 analyzes the alarm data package to determine a vital sign alarm type, and in step 604, assigns a type priority value (TPV;) according to the identified vital sign alarm type (for example, cardio, ventilator or oximeter alarm). At step 605, server 101 sorts the alarm data packages according to the values of the coefficients c;, and at step 606, sorts the alarm data packages according to the type priority values TPV; and places the sorted alarm data packages in a buffer.
The server 101 reads an alarm data package of highest priority from the buffer at step 607, generates an alarm notification at step 608, and removes the alarm data package just read from the buffer at step 609. At step 610, the server 101 determines whether the buffer is empty, and if not, returns to step 607 to read a next alarm data message. If the buffer is empty, the server 101 terminates that alarm prioritization process 600 at step 611.
System Health The data status messages DS as described above are prepared based on system health monitoring activities undertaken by various components of the system.
For example, each of the wireless interface devices may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the wireless interface device. If no heartbeat has been received for a given device during a predetermined interval, the server performs a diagnosis to determine an associated alarm condition. Data status messages DS may then prepared by the server to indicate the status of each of the wireless interface devices, including alarm condition as warranted.
FIG. 7 illustrates an exemplary process 700 by which the health of various devices may be monitored by the server 101. The process is initiated in the server 101 at step 701, and then proceeds to step 702, at which the server 101 clears a current status record for each device in the system in order to begin the process of determining the current health of these devices.
Concurrently, the process is initiated in the various devices at step 703, and then proceeds to step 704, at which each device determines whether or not it has access to the server 101 at step 704. If no access is available, at step 705, the device generates a local alert (for example, audio and/or visual alarms discernible at the device) to instigate an appropriate service event. If the device determines that access to the serve 101 is available, the device generates a status data package at step 706 and transmits this package to the server at step 707. After generating the local alert at step 705 or generating the device status package at step 706, the device sets a sleep timer at step 708 to pause the process for a predetermined time period (for example, 5 seconds), and then returns to step 704 to determine whether or not it has access to the server 101.
At step 709, the server 101 receives the transmitted status data package, adds a time stamp to the received status data package and stores the received package. At step 710, the server 101 determines whether a status data package has been received from each device having a time stamp with no greater than a predetermined age (for example, 10 seconds). At step 711, for any device for which the current status data package time stamp exceeds the predetermined age, the server 101 issues a device disconnected alert to instigate an appropriate service event. After the time stamp age of the status data packages for each device has been determined, the process returns to step 702 to clear a current status record for each device and await the arrival of new status data packages from each of the devices.
Additional health monitoring activities may also preferably be undertaken within the system in accordance with the present invention. For example, the nurse's station may preferably be configured to periodically transmit a heartbeat signal to the server while the wireless interface device is in an idle state with reference to the server in order to confirm the health of the nurse's station. In addition, the server may also be configured to periodically transmit a heartbeat signal to one or more of the nurse's station or the wireless devices, while the server is in an idle state with reference to the nurse's station in order to confirm the health of the server.
Alarm Escalation The server also preferably includes an alarm escalation rules base for determining a delivery and escalation procedure for patient and device alarms.
For example, a rule set for a current patient may provide that an alarm condition is initially reported via a display of the nurse's station and via visual and aural alarms located in proximity to the patient's hospital room. If the alarm is not acknowledged at the nurse's station within a predetermined period of time, the rules may preferably provide an escalation procedure that forwards the alarm to a personal communication device of an attending nurse (for example, by creating an associated text-based alarm message and converting the text to speech for transmission via a Voice over IP
(VoIP) interface of the server to the attending nurse's cell phone). A commercial example of this technology is AT&T Labs Natural Voices Text-to-Speech a demo available at -http://www.research.att.com.
FIG. 8 illustrates an exemplary process 800 by which the escalation of alarms may be enacted by the server 101. At step 801, the server 101 begins the process of providing a patient alarm notification. At step 802, the server 101 determines a device ID for the device that indicated the alarm, and determines a patient physical location by retrieving stored device physical location information according to the device ID.
The association of a patient monitoring device with a location may be accomplished, for example, by two different methods. In a first "automated"
method, location may be determined by triangulating a radio frequency signal received at several antennas distributed within the territory served by an associated access point, or by localizing the signal according to signal strength at the access point.
In a second "manual" method, medical staff manually admit the patient and the device location information to a physical location record recorded through the Nurse Station Terminal 151. This association information is stored in the Data Layer, specifically in an underlying database system within this layer.
Based on the identified patient information, the server 101 identifies and activates visual and audio alarms in proximity to the patient at steps 803 and 804, respectively. At step 805, the server 101 identifies the nurse station 107 with a primary present responsibility for the patient at the identified physical location, and
-21-announces an alarm at the identified nurse station 107 (for example, using a text-based alarm message converted to text-to-speech for reproduction at the nurse station 107).
Next, the server 101 proceeds to generate and deliver alarms to patient caregivers who may not be in physical proximity to the patient. At step 806, the server 101 retrieves a listing 807 of VoIP alarm recipients associated with the patient at the identified physical location. The listing 807 may be developed and maintained, for example, at Nurse Station Terminal 151 by the medical staff. In particular, staff members may associate individual alarm recipients to the patient, and/or may maintain a current location alarm recipients list default listing for each location.
The listing 807 preferably identifies each of the VoIP alarm recipients in association with an escalation level. For example, a "level 1" escalation level may identify recipients designated to receive an alarm for the patient at the identified physical location immediately upon its generation, a "level 2" escalation may identify recipients designated to receive an alarm for the patient at the identified physical location when no acknowledgement of a response to the alarm has been received from any level 1 recipient, and so on.
At steps 808 and 809, the server begins by transmitting a VoIP call to each of the level 1 recipients that provides a text-to-speech translation of the alarm. This is preferably accomplished via a conventional soft phone module and the text to speech conversion module of the server. The speech conversion module converts stored alarm text to speech.
The soft phone module receives the converted speech, input and relays the speech to the other end of each established VoIP call. Some suitable commercial products for implementing the soft phone module include SKYPE, XTEN, EYEBEAM and TUITALK.
At step 810, the server determines whether or not each transmitted VoIP call has been successfully established and whether each recipient has acknowledged the alarm message. If not, at step 811, the server 101 determines whether the current level is a "top most level" (i.e., a "final" escalation level providing no further escalation ), and if so, specifically records the VoIP alarm notification event as an "improper staff response to alarm notification" at step 812. If additional escalation levels are available, the server proceeds at step 813 to a next level of escalation and
Next, the server 101 proceeds to generate and deliver alarms to patient caregivers who may not be in physical proximity to the patient. At step 806, the server 101 retrieves a listing 807 of VoIP alarm recipients associated with the patient at the identified physical location. The listing 807 may be developed and maintained, for example, at Nurse Station Terminal 151 by the medical staff. In particular, staff members may associate individual alarm recipients to the patient, and/or may maintain a current location alarm recipients list default listing for each location.
The listing 807 preferably identifies each of the VoIP alarm recipients in association with an escalation level. For example, a "level 1" escalation level may identify recipients designated to receive an alarm for the patient at the identified physical location immediately upon its generation, a "level 2" escalation may identify recipients designated to receive an alarm for the patient at the identified physical location when no acknowledgement of a response to the alarm has been received from any level 1 recipient, and so on.
At steps 808 and 809, the server begins by transmitting a VoIP call to each of the level 1 recipients that provides a text-to-speech translation of the alarm. This is preferably accomplished via a conventional soft phone module and the text to speech conversion module of the server. The speech conversion module converts stored alarm text to speech.
The soft phone module receives the converted speech, input and relays the speech to the other end of each established VoIP call. Some suitable commercial products for implementing the soft phone module include SKYPE, XTEN, EYEBEAM and TUITALK.
At step 810, the server determines whether or not each transmitted VoIP call has been successfully established and whether each recipient has acknowledged the alarm message. If not, at step 811, the server 101 determines whether the current level is a "top most level" (i.e., a "final" escalation level providing no further escalation ), and if so, specifically records the VoIP alarm notification event as an "improper staff response to alarm notification" at step 812. If additional escalation levels are available, the server proceeds at step 813 to a next level of escalation and
-22-returns to step 809. At step 814, the server determines when each of the alarm notification "threads" (i.e., local visual and audio alarms, and VoIP alarms) have completed, and concludes the process at step 815. If not, the server preferably initiates an additional "last resort" escalation level (for example, by sending e-mail to a staffed emergency station).
Those skilled in the art will readily recognize additional numerous adaptations and modifications which can be made to the present invention which fall within the scope of the invention as defined in the claims. Moreover, it is intended that the scope of the present invention include all foreseeable equivalents to the structures as described with reference to drawings Accordingly, the invention is to be limited only by the scope of the claims and their equivalents.
Those skilled in the art will readily recognize additional numerous adaptations and modifications which can be made to the present invention which fall within the scope of the invention as defined in the claims. Moreover, it is intended that the scope of the present invention include all foreseeable equivalents to the structures as described with reference to drawings Accordingly, the invention is to be limited only by the scope of the claims and their equivalents.
-23-
Claims (22)
1. A patient monitoring system comprising:
a plurality of patient data acquisition devices, each patient data acquisition device being configured to collect vital sign data associated with one of a plurality of vital signs from one of a plurality of patients and to output a data signal representing the collected vital sign data, the data signal being formed according to one of a plurality of vital sign data protocols associated with the plurality of patient data acquisition devices;
a plurality of remote translation devices, each remote translation device being configured to receive the data signal from an associated one of the plurality of patient data acquisition devices, and to apply one of a plurality of protocol translation adapters to translate the received data signal formed according the one vital sign data protocol to form a translated data signal formed according to a standard language for vital sign data, the standard language including a standard communications protocol and standard data structures; and a server comprising:
a data acquisition component configured to receive the plurality of translated data signals from the plurality of remote translation devices and to form data records from the translated data signals, the data records forming standard data structures of the standard language, a data storage unit for storing the data records, and a processing module for processing the data records to determine whether one or more of the vital signs for any one of the plurality of patients indicates an alarm condition for that patient, wherein the alarm condition is determined as a function of the vital sign data represented by the processed data records and a condition indicator for the one patient.
a plurality of patient data acquisition devices, each patient data acquisition device being configured to collect vital sign data associated with one of a plurality of vital signs from one of a plurality of patients and to output a data signal representing the collected vital sign data, the data signal being formed according to one of a plurality of vital sign data protocols associated with the plurality of patient data acquisition devices;
a plurality of remote translation devices, each remote translation device being configured to receive the data signal from an associated one of the plurality of patient data acquisition devices, and to apply one of a plurality of protocol translation adapters to translate the received data signal formed according the one vital sign data protocol to form a translated data signal formed according to a standard language for vital sign data, the standard language including a standard communications protocol and standard data structures; and a server comprising:
a data acquisition component configured to receive the plurality of translated data signals from the plurality of remote translation devices and to form data records from the translated data signals, the data records forming standard data structures of the standard language, a data storage unit for storing the data records, and a processing module for processing the data records to determine whether one or more of the vital signs for any one of the plurality of patients indicates an alarm condition for that patient, wherein the alarm condition is determined as a function of the vital sign data represented by the processed data records and a condition indicator for the one patient.
2. The patient monitoring system of claim 1, wherein:
each of the plurality of remote translation devices comprises a wireless transmitter for transmitting the translated data signal to the server, and the server is coupled to one or more wireless access points for receiving and forwarding the transmitted data signal to the server.
each of the plurality of remote translation devices comprises a wireless transmitter for transmitting the translated data signal to the server, and the server is coupled to one or more wireless access points for receiving and forwarding the transmitted data signal to the server.
3. The patient monitoring system of claim 2, wherein the wireless transmitters and the wireless access points are selected from the group consisting of WiFi transceivers, SUNSPOT transceivers and RFID transceivers.
4. The patient monitoring system of claim 1, wherein each of the patient data acquisition devices is selected from the group consisting of ventilators, infusion pumps, pulse oximeters and cardio monitors.
5. The patient monitoring system of claim 2, wherein the plurality of remote translation devices and the plurality of wireless access points further comprise encryption/decryption modules, and wherein each of the encryption/decryption modules of the plurality of remote translation devices is configured to encrypt the translated data signal before transmission to the one of the wireless access points.
6. The patient monitoring system of claim 5, wherein the encryption/decryption modules apply a symmetric key protocol having at least one of symmetric key replacement at predetermined time intervals and symmetric key mutation.
7. The patient monitoring system of claim 5, wherein the encryption/decryption modules apply an asymmetric key protocol based on elliptic key cryptography.
8. The patient monitoring system of claim 1, further comprising:
a patient attendant's station configured for receiving an alarm condition data signal from the server, the alarm condition data signal including one or more of an alarm indicator for the alarm condition and the vital sign data, wherein the patient attendant's station is further configured for displaying one or more of the alarm indicator and the vital sign data or on a display of the patient attendant's station.
a patient attendant's station configured for receiving an alarm condition data signal from the server, the alarm condition data signal including one or more of an alarm indicator for the alarm condition and the vital sign data, wherein the patient attendant's station is further configured for displaying one or more of the alarm indicator and the vital sign data or on a display of the patient attendant's station.
9. The patient monitoring system of claim 1, wherein the server further comprises:
a secure Internet portal configured for providing remote access to the server for retrieving one or more of an alarm indicator for the alarm condition and the vital sign data.
a secure Internet portal configured for providing remote access to the server for retrieving one or more of an alarm indicator for the alarm condition and the vital sign data.
10. The patient monitoring system of claim 1, wherein the server further comprises:
an alarm escalation module including:
a rules base providing rules for routing information about the alarm condition as a function of one or more of the alarm condition, the one patient and one or more attendants of the one patient, and an alarm condition processor for routing the information about the alarm condition as a function of the rules and of a current status of the alarm condition.
an alarm escalation module including:
a rules base providing rules for routing information about the alarm condition as a function of one or more of the alarm condition, the one patient and one or more attendants of the one patient, and an alarm condition processor for routing the information about the alarm condition as a function of the rules and of a current status of the alarm condition.
11. The patient monitoring system of claim 10, wherein the alarm condition processor is configured for routing the alarm information to one or more devices selected from the group consisting of visual alarms in proximity to the one patient, aural alarms in proximity to the one patient, patient attendant stations, and patient attendant portable communication devices.
12. The patient monitoring system of claim 11, wherein the alarm condition processor is further configured to select text as the alarm information for the alarm condition, perform a text-to-speech conversion of the alarm information, initiate a call to a cell phone of a patient attendant via a voice over IP (VoIP) interface, and transmit the converted speech via the VoIP interface to the patient attendant's cell phone as the selected device.
13. The patient monitoring system of claim 2, wherein each of the remote translation devices is further configured to periodically transmit a heartbeat signal to the server while the remote translation device is in an idle state with reference to the server.
14. The patient monitoring system of claim 2, wherein the patient attendant's station is further configured to periodically transmit a heartbeat signal to the server while the patient attendant's station is in an idle state with reference to the server.
15. The patient monitoring system of claim 2, wherein the server is configured to periodically transmit a heartbeat signal to the patient attendant's station while the server is in an idle state with reference to the patient attendant's station.
16. The patient monitoring system of claim 1, wherein a vital sign data threshold for determining the alarm condition is changed according to the condition indicator for the one patient.
17. The patient monitoring system of claim 1, wherein determining the alarm condition is suspended for a predetermined period of time when the condition indicator indicates that the one patient is engaged in a predetermined event.
18. The patient monitoring system of claim 1, wherein the predetermined event is a surgical procedure.
19. The patient monitoring system of claim 1, wherein the standard communications protocol is defined by:
a finite set of states Q, a receiver base node or server p, a finite set of wireless nodes W=(w0, w1 ... w n) corresponding to the plurality of patient data acquisition devices, and each capable of communicating with the receiver or on a node-to-node basis, a communication partial function 8 that defines the communication between the nodes, and cryptographic functions Enc(.increment.), Dec(.increment.) as applied to the data structures .increment. for encrypting and decrypting the data.
a finite set of states Q, a receiver base node or server p, a finite set of wireless nodes W=(w0, w1 ... w n) corresponding to the plurality of patient data acquisition devices, and each capable of communicating with the receiver or on a node-to-node basis, a communication partial function 8 that defines the communication between the nodes, and cryptographic functions Enc(.increment.), Dec(.increment.) as applied to the data structures .increment. for encrypting and decrypting the data.
20. The patient monitoring system of claim 1, wherein:
the data structures .increment. comprise a status data set .SIGMA. and a real-time data stream .tau., each data record in the status data set .SIGMA. identifying a patient status or a device status in association with one of the wireless nodes W =(w0, w1 ... w n), and each data record in the real-time data stream i including data representing a real time function .function.(t) and data representing a schema S, in association with one of the wireless nodes W =(w0, w1 ... w n), wherein the real time function .function.(t) can be translated into one of the vital signs based on the identified schema.
the data structures .increment. comprise a status data set .SIGMA. and a real-time data stream .tau., each data record in the status data set .SIGMA. identifying a patient status or a device status in association with one of the wireless nodes W =(w0, w1 ... w n), and each data record in the real-time data stream i including data representing a real time function .function.(t) and data representing a schema S, in association with one of the wireless nodes W =(w0, w1 ... w n), wherein the real time function .function.(t) can be translated into one of the vital signs based on the identified schema.
21. The patient monitoring system of claim 1, wherein the status data set .SIGMA.
comprises:
patient status messages PS each identifying one of the wireless nodes W =(w0, w1 ... w n), an associated vital sign, an associated status condition and a coefficient C = (c0, c1, ... c i) for, when the status condition is an alarm condition, determining a priority of the alarm condition; and device status messages DS each identifying one of the wireless nodes W =(w0, w1 ... w n), an associated status condition, and one or more device alarm codes A =(a0, a1, ... a j) when the status condition is alarm.
comprises:
patient status messages PS each identifying one of the wireless nodes W =(w0, w1 ... w n), an associated vital sign, an associated status condition and a coefficient C = (c0, c1, ... c i) for, when the status condition is an alarm condition, determining a priority of the alarm condition; and device status messages DS each identifying one of the wireless nodes W =(w0, w1 ... w n), an associated status condition, and one or more device alarm codes A =(a0, a1, ... a j) when the status condition is alarm.
22. The patient monitoring system of claim 2, wherein each remote translation device comprises:
a processor; and a stored program memory;
a wireless transmitter; and a wireless receiver, wherein:
the remote translation device is further configured to transmit data identifying its associated patient data acquisition device via the wireless transmitter to one of the one or more wireless access points, for forwarding of the patient data acquisition device-identifying data by the wireless access point to the server, the server is further configured to identify and retrieve one of the plurality of protocol translation adapters based on the patient data acquisition device-identifying data, the remote translation device is further configured to receive the retrieved protocol translation adapter from the server via the wireless access point data and store the retrieved protocol translation adapter in the stored program memory of the remote translation device, and the processor and stored program memory are further operative to translate the received data signal to form the translated data signal formed according to the standard language for representing the vital sign data.
a processor; and a stored program memory;
a wireless transmitter; and a wireless receiver, wherein:
the remote translation device is further configured to transmit data identifying its associated patient data acquisition device via the wireless transmitter to one of the one or more wireless access points, for forwarding of the patient data acquisition device-identifying data by the wireless access point to the server, the server is further configured to identify and retrieve one of the plurality of protocol translation adapters based on the patient data acquisition device-identifying data, the remote translation device is further configured to receive the retrieved protocol translation adapter from the server via the wireless access point data and store the retrieved protocol translation adapter in the stored program memory of the remote translation device, and the processor and stored program memory are further operative to translate the received data signal to form the translated data signal formed according to the standard language for representing the vital sign data.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US17410709P | 2009-04-30 | 2009-04-30 | |
| US61/174,107 | 2009-04-30 | ||
| PCT/US2010/031564 WO2010126731A2 (en) | 2009-04-30 | 2010-04-19 | Patient monitoring and alarm system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2797545A1 true CA2797545A1 (en) | 2010-11-04 |
Family
ID=43032743
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA2797545A Abandoned CA2797545A1 (en) | 2009-04-30 | 2010-04-19 | Patient monitoring and alarm system |
Country Status (2)
| Country | Link |
|---|---|
| CA (1) | CA2797545A1 (en) |
| WO (1) | WO2010126731A2 (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023208848A1 (en) * | 2022-04-26 | 2023-11-02 | Implicity | System for monitoring health data acquisition devices |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2014087844A1 (en) * | 2012-12-06 | 2014-06-12 | コニカミノルタ株式会社 | Pulse oximetry system, and subsystem and communication conversion device for constructing said pulse oximetry system |
| CN104157024A (en) * | 2014-07-14 | 2014-11-19 | 上海东方延华节能技术服务股份有限公司 | Local real-time monitoring system |
| CN105125182B (en) * | 2015-10-14 | 2018-01-09 | 北京异度矩阵科技有限公司 | A kind of Intellectual temperature monitoring alarm method and system |
| CN107239499A (en) * | 2017-05-03 | 2017-10-10 | 成都国腾实业集团有限公司 | Analysis method and system based on multidimensional heterogeneous data sources integration and Integrated Models |
Family Cites Families (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7666151B2 (en) * | 2002-11-20 | 2010-02-23 | Hoana Medical, Inc. | Devices and methods for passive patient monitoring |
| US7224281B2 (en) * | 2001-08-31 | 2007-05-29 | Draeger Medical Systems, Inc. | Patient monitoring and alarm processing system and user interface |
| US20060206011A1 (en) * | 2005-03-08 | 2006-09-14 | Higgins Michael S | System and method for remote monitoring of multiple healthcare patients |
| US8070677B2 (en) * | 2005-06-09 | 2011-12-06 | Koninklijke Philips Electronics N.V. | Method and apparatus for distinguishing between clinically significant changes and artifacts in patient physiological information |
-
2010
- 2010-04-19 WO PCT/US2010/031564 patent/WO2010126731A2/en active Application Filing
- 2010-04-19 CA CA2797545A patent/CA2797545A1/en not_active Abandoned
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2023208848A1 (en) * | 2022-04-26 | 2023-11-02 | Implicity | System for monitoring health data acquisition devices |
Also Published As
| Publication number | Publication date |
|---|---|
| WO2010126731A2 (en) | 2010-11-04 |
| WO2010126731A3 (en) | 2011-02-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11464410B2 (en) | Medical systems and methods | |
| US10430552B2 (en) | Distributed telemedicine system and method | |
| US20200206517A1 (en) | Systems and methods for ems device communications interface | |
| US8943168B2 (en) | Remote monitoring systems for monitoring medical devices via wireless communication networks | |
| US9495511B2 (en) | Remote monitoring systems and methods for medical devices | |
| US20150070187A1 (en) | Wireless Relay Module For Remote Monitoring Systems | |
| US20070180140A1 (en) | Physiological alarm notification system | |
| JP2015512175A (en) | Medical device remote monitoring system and method | |
| US20110295078A1 (en) | Systems and methods for collection, organization and display of ems information | |
| US20120191476A1 (en) | Systems and methods for collection, organization and display of ems information | |
| US20100234718A1 (en) | Open architecture medical communication system | |
| EP2090997A1 (en) | Conveying real time medical data | |
| US8589176B2 (en) | Methods and systems for managing communication requests in an institutional setting such as a healthcare facility | |
| CN108348148A (en) | It is a kind of to measure and report integrated form Medical Devices in relation to the important physiological data of patient by tele-medicine and based on the system of family | |
| KR20150067289A (en) | System and method for providing patient care | |
| CN104520893A (en) | System and method for remote encounter and status assessment using parallel data and voice communication paths | |
| CA2797545A1 (en) | Patient monitoring and alarm system | |
| TWM467972U (en) | Telemedicine information system | |
| KR101246667B1 (en) | System and method for integrated anesthesia management | |
| Kumbhare et al. | Wireless body area sensor network authentication using hmac function | |
| Yoshikawa et al. | Secure Buddy System in Highly Managed Medical IoT for Patients with Intractable Diseases | |
| Shen et al. | A Public-Key Protection Scheme Using in the Wireless Module of the Digital Stethoscope | |
| Saad | Secure critical care resource optimization based on heterogeneous vital signs | |
| Al-Qutayri et al. | Framework for secure wireless health monitoring and remote access system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request |
Effective date: 20150309 |
|
| FZDE | Dead |
Effective date: 20180921 |