U.S. patent application number 13/625691 was filed with the patent office on 2013-04-18 for systems and methods for storing, analyzing, and retrieving medical data.
This patent application is currently assigned to MASIMO CORPORATION. The applicant listed for this patent is MASIMO CORPORATION. Invention is credited to Bilal Muhsin, Anand Sampath.
Application Number | 20130096936 13/625691 |
Document ID | / |
Family ID | 40134805 |
Filed Date | 2013-04-18 |
United States Patent
Application |
20130096936 |
Kind Code |
A1 |
Sampath; Anand ; et
al. |
April 18, 2013 |
SYSTEMS AND METHODS FOR STORING, ANALYZING, AND RETRIEVING MEDICAL
DATA
Abstract
Medical data obtained from a clinical network of physiological
monitors can be stored in a journal database. The medical data can
include device events that occurred in response to clinician
interactions with one or more medical devices and device-initiated
events, such as alarms and the like. The journal database can be
analyzed to derive statistics, which may be used to improve
clinician and/or hospital performance.
Inventors: |
Sampath; Anand; (Corona,
CA) ; Muhsin; Bilal; (Aliso Viejo, CA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
MASIMO CORPORATION; |
Irvine |
CA |
US |
|
|
Assignee: |
MASIMO CORPORATION
Irvine
CA
|
Family ID: |
40134805 |
Appl. No.: |
13/625691 |
Filed: |
September 24, 2012 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
12249806 |
Oct 10, 2008 |
8274360 |
|
|
13625691 |
|
|
|
|
60979531 |
Oct 12, 2007 |
|
|
|
Current U.S.
Class: |
705/2 |
Current CPC
Class: |
G16H 10/60 20180101;
G16H 40/67 20180101; G16H 15/00 20180101 |
Class at
Publication: |
705/2 |
International
Class: |
G06Q 50/22 20060101
G06Q050/22 |
Claims
1. A method of providing journaled medical data, the method
comprising: by one or more processors: receiving messages from a
plurality of medical devices over a clinical network; processing
the messages to determine a medical event described by each of the
messages, the medical event comprising one or more of the
following: a first device event occurring in response to a
clinician interaction with a selected one of the medical devices,
and a second device event occurring without clinician interaction
with the selected medical device; storing information about the one
or more medical events in a journal database, the journal database
comprising physical computer storage; in response to a request for
a medical events report, obtaining medical statistics about the
medical events stored in the journal database; and generating a
report comprising the medical statistics.
2. The method of claim 1, wherein the first device event comprises
one of the following: an alarm deactivation, changing of alarm
limits, a logon or logging off of a clinician to a nurses' station
system, an admittance of the patient, and a discharge of the
patient.
3. The method of claim 1, wherein the second device event comprises
an alarm.
4. The method of claim 1, further comprising storing one or more
event counters in the journal database, the one or more event
counters operative to store a count of one or more medical
events.
5. The method of claim 4, wherein obtaining medical statistics
about the medical events comprises accessing a selected event
counter.
6. The method of claim 4, wherein generating the report comprises
generating a monitoring report card.
7. The method of claim 4, wherein generating the report comprises
comparing alarm response times among clinicians.
8. The method of claim 4, wherein generating the report comprises
comparing alarm response times among hospitals.
9. A system for providing journaled medical data, the system
comprising: a server system comprising one or more physical
computing devices, the server system configured to: receive
messages from a plurality of medical devices over a clinical
network, the medical devices comprising patient monitors; process
the messages to determine a medical event described by each of the
messages, the medical event comprising one or more of the
following: a first device event occurring in response to a
clinician interaction with a selected one of the medical devices,
and a second device event occurring without clinician interaction
with the selected medical device; store information about the one
or more medical events in a journal database, the journal database
comprising physical computer storage; in response to a request for
a medical events report, obtain medical statistics about the
medical events stored in the journal database; and generate a
report comprising the medical statistics.
10. The system of claim 9, wherein the first device event comprises
one of the following: an alarm deactivation, changing of alarm
limits, a logon or logging off of a clinician to a nurses' station
system, an admittance of the patient, and a discharge of the
patient.
11. The system of claim 9, wherein the second device event
comprises an alarm.
12. The system of claim 9, further comprising storing one or more
event counters in the journal database, the one or more event
counters operative to store a count of one or more medical
events.
13. The system of claim 12, wherein obtaining medical statistics
about the medical events comprises accessing a selected event
counter.
14. The system of claim 12, wherein generating the report comprises
generating a monitoring report card.
15. The system of claim 12, wherein generating the report comprises
comparing alarm response times among clinicians.
16. The system of claim 12, wherein generating the report comprises
comparing alarm response times among hospitals.
17. A system for providing journaled medical data, the system
comprising: a server system comprising one or more physical
computing devices, the server system operative to receive a request
from a user to review journaled medical data and physiological data
corresponding to a period of time, the physiological data being
obtained from one or more patient monitors; and the server system
configured to: retrieve the journaled medical data for the time
period from a journal database, the journal database comprising
first physical computer storage, the journaled medical data
comprising one or more of: first device events occurring in
response to clinician interactions with the one or more patient
monitors, and second device events occurring without clinician
interaction with the one or more patient monitors; retrieve
physiological data for the time period from a database comprising
second physical computer storage; correlate the journaled medical
data with the physiological data with respect to time; and output
the correlated journaled and physiological data as a report for
presentation to the user.
18. The system of claim 17, wherein the first device events
comprise one of the following: an alarm deactivation, changing of
alarm limits, a logon or logging off of a clinician to a nurses'
station system, an admittance of the patient, and a discharge of
the patient.
19. The system of claim 17, wherein the report comprises statistics
regarding alarm response times among clinicians.
20. The system of claim 17, wherein the report comprises statistics
regarding alarm response times among hospitals.
Description
RELATED APPLICATION
[0001] This application is a continuation of U.S. application Ser.
No. 12/249,806, filed Oct. 10, 2008, titled "SYSTEMS AND METHODS
FOR STORING, ANALYZING, AND RETRIEVING MEDICAL DATA," which is a
non-provisional of U.S. Provisional Application No. 60/979,531,
filed Oct. 12, 2007, titled "SYSTEMS AND METHODS FOR STORING,
ANALYZING, AND RETRIEVING MEDICAL DATA," the disclosures of both of
which are hereby incorporated by reference in their entirety.
BACKGROUND
[0002] Hospitals, nursing homes, and other patient care facilities
typically include patient monitoring devices at one or more
bedsides in the facility. Patient monitoring devices generally
include sensors, processing equipment, and displays for obtaining
and analyzing a medical patient's physiological parameters such as
blood oxygen saturation level, respiratory rate, and the like.
Clinicians, including doctors, nurses, and other medical personnel,
use the physiological parameters obtained from patient monitors to
diagnose illnesses and to prescribe treatments. Clinicians also use
the physiological parameters to monitor patients during various
clinical situations to determine whether to increase the level of
medical care given to patients.
[0003] Many patient monitoring devices provide an alarm function
that triggers an alarm when certain physiological parameters exceed
safe thresholds. Situations giving rise to an alarm might include,
for example, decreased heart rate, respiratory rate, or low blood
oxygen saturation levels. Alarms enable clinicians to respond
rapidly to possible life-threatening situations. Alarms may be
audible, visual, or transmitted over a network to locations in a
hospital where clinicians are not in direct view of a patient.
Alarms and other physiological information are often transmitted to
a central nurses' station or the like, where nurses or other
clinicians can monitor several patients at once.
SUMMARY OF CERTAIN EMBODIMENTS
[0004] In a multi-patient monitoring environment having a plurality
of patient monitoring devices in communication with one or more
clinician monitoring stations, a method of storing physiological
information obtained from a medical patient includes, in certain
embodiments: receiving identification information from a patient
monitor over a network, the patient monitor having one or more
processors operative to process physiological data obtained from
one or more sensors coupled to a medical patient; in response to
receiving the identification information, retrieving first
parameter descriptors corresponding to the patient monitor based at
least partly on the identification information, where each first
parameter descriptor can identify a parameter measurable by the
patient monitor; creating a round-robin database (RRDB) file having
a header that has the first parameter descriptors; receiving the
physiological data from the patient monitor, where the
physiological data has second parameter descriptors that can
identify the physiological data; and using the first parameter
descriptors in the header to map the physiological data to
locations in the RRDB file based at least partly on the second
parameter descriptors received from the patient monitor.
[0005] In certain embodiments, a method of journaling medical data
from a plurality of medical devices includes receiving messages
from a plurality of medical devices over a clinical network, where
the medical devices has patient monitors, and where each patient
monitor has one or more processors that can process physiological
information received from one or more sensors coupled to a medical
patient; processing the messages to determine a medical event
described by each of the messages, where the medical event includes
one or more of the following: a first device event occurring in
response to a clinician interaction with a selected one of the
medical devices, and a second device event occurring without
clinician interaction with the selected medical device; storing
information about the one or more medical events in a journal
database, where the journal database has physical computer storage;
in response to a request for a medical events report, obtaining
medical statistics about the medical events stored in the journal
database; and generating a report that includes the medical
statistics.
[0006] Additionally, in various embodiments, a method of
dynamically adjusting types of physiological information obtained
from a medical patient can include obtaining first physiological
data corresponding to one or more first physiological parameters of
a medical patient using one or more processors that can process
physiological signals measured by one or more sensors coupled to
the patient; automatically associating the first physiological data
with first parameter descriptors to generate first associated
physiological data, where the first parameter descriptors can
describe the one or more first physiological parameters in the
first physiological data; providing the first associated
physiological data to a round-robin database, where the first
parameter descriptors can describe the first physiological data in
the round-robin database, and where the round-robin database has
physical computer storage; obtaining second physiological data
corresponding to one or more second physiological parameters of the
medical patient; automatically associating the second physiological
data with second parameter descriptors to generate second
associated physiological data; and providing the second associated
physiological data to the round-robin database.
[0007] Various implementations of a system for storing
physiological information obtained from a medical patient include a
network management module that can: receive identification
information from a patient monitor over a network, where the
patient monitor has one or more processors that can process
physiological data obtained from one or more sensors coupled to a
medical patient; and receive the physiological data from the
patient monitor, where the physiological data includes first
parameter descriptors operative to identify the physiological data;
a round-robin database (RRDB) component operative to, in response
to receiving the identification information from the network
management module: retrieve second parameter descriptors
corresponding to the patient monitor based at least partly on the
identification information, where each second parameter descriptor
can identify a parameter measurable by the patient monitor; create
an RRDB file having a header, the header including the second
parameter descriptors; and use the second parameter descriptors in
the header to map the physiological data to locations in the RRDB
file based at least partly on the first parameter descriptors
received from the patient monitor.
[0008] In certain embodiments, physiological information obtained
from a medical patient can be stored in a dynamic round-robin
database. Parameter descriptors may be used to identify parameter
values in the records. The parameter values can be dynamically
updated by changing the parameter descriptors to provide for a
flexible database. In addition, the size of files used in the
database can be dynamically adjusted to account for patient
condition. In certain implementations, the round-robin database can
be adaptive, such that an amount of data stored in the database is
adapted based on patient condition and/or signal condition.
BRIEF DESCRIPTION OF THE DRAWINGS
[0009] Various embodiments will be described hereinafter with
reference to the accompanying drawings. These embodiments are
illustrated and described by example only, and are not intended to
limit the scope of the disclosure. In the drawings, similar
elements have similar reference numerals.
[0010] FIG. 1 is a block diagram illustrating an embodiment of a
clinical network environment;
[0011] FIG. 2 is a block diagram illustrating a more detailed
embodiment of the clinical network environment of FIG. 1;
[0012] FIG. 3 is a block diagram illustrating an embodiment of a
round-robin database file for storing physiological data in the
clinical network environment of FIG. 1 or 2;
[0013] FIG. 4 is a more detailed embodiment of the round-robin
database file of FIG. 3;
[0014] FIGS. 5A through 5C are flow charts illustrating embodiments
of processes for using a round-robin database for storing
physiological data;
[0015] FIG. 6A is a flow chart illustrating an embodiment of a
process for journaling medical events in a journal database;
[0016] FIG. 6B is a flow chart illustrating an embodiment of a
process for correlating data from the journal database and the
round-robin database; and
[0017] FIG. 7 is a screen shot of an example user interface for
monitoring patients in the clinical network environment of FIG.
1.
DETAILED DESCRIPTION
[0018] In certain embodiments, systems and methods are provided for
rapidly storing and acquiring physiological trend data. For
instance, physiological information obtained from a medical patient
can be stored in a round-robin database. The round-robin database
can store the physiological information in a series of records
equally spaced in time. Parameter descriptors may be used to
identify parameter values in the records. The parameter values can
be dynamically updated by changing the parameter descriptors to
provide for a flexible database. In addition, the size of files
used in the database can be dynamically adjusted to account for
patient condition.
[0019] Additionally, in certain embodiments, medical data obtained
from a clinical network of physiological monitors can be stored or
journaled in a journal database. The medical data can include
device events that occurred in response to clinician interactions
with one or more medical devices. The medical event data may also
include device-initiated events, such as alarms and the like. The
medical data stored in the journal database can be analyzed to
derive statistics or metrics, which may be used to improve
clinician and/or hospital performance.
[0020] As used herein the terms "round-robin database" and "RRDB,"
in addition to having their ordinary meaning, can also describe
improved database structures having unique characteristics and
features disclosed herein. Sometimes these structures are referred
to herein as dynamic RRDBs or adaptive RRDBs.
[0021] FIG. 1 illustrates an embodiment of a clinical network
environment 100. The clinical network environment 100 includes a
multi-patient monitoring system (MMS) 120 in communication with one
or more patient monitors 140, nurses' station systems 130, and
clinician devices 150 over a network 110. In certain embodiments,
the MMS 120 provides physiological data obtained from the patient
monitors 140 to the nurses' station systems 130 and/or the
clinician devices 150. Additionally, in certain embodiments, the
MMS 120 stores physiological information and medical event
information for later analysis.
[0022] The network 110 of the clinical network environment 100 can
be a LAN or WAN, wireless LAN ("WLAN"), or other type of network
used in any hospital, nursing home, patient care center, or other
clinical location. For ease of illustration, the remainder of this
specification will describe clinical environments in the context of
hospitals; however, it should be understood that the features
described herein may also be employed in other clinical locations
or settings. In some implementations, the network 110 can
interconnect devices from multiple hospitals or clinical locations,
which may be remote from one another, through the Internet, a
leased line, or the like. Likewise, the various devices 120, 130,
140, and 150 of the clinical network environment 100 may be
geographically distributed (e.g., among multiple hospitals) or
co-located (e.g., in a single hospital).
[0023] The patient monitors 140 may be point-of-care (POC)
instruments or the like that monitor physiological signals detected
by sensors coupled with medical patients. The patient monitors 140
may process the signals to determine any of a variety of
physiological parameters. One example of a physiological parameter
is blood oxygen saturation (SpO.sub.2). Other examples of
physiological parameters are described below with respect to FIG.
2.
[0024] The patient monitors 140 can provide the physiological
information to the MMS 120. The patient monitors 140 can also
provide information on medical events, such as alarms, to the MMS
120. Alarms can be triggered, for example, in response to a
physiological parameter falling outside of a normal range. Alarms
can also include alerts regarding equipment failures, such as a
probe-off condition where a sensor has fallen off of a patient.
Other examples of medical events are described below with respect
to FIG. 2.
[0025] In various embodiments, the patient monitors 140 provide the
physiological information and medical events to the MMS 120. The
MMS 120 is described in greater detail below. In some
implementations, the patient monitors 140 may provide at least some
of this information directly to the nurses' station systems 130 and
clinician devices 150.
[0026] The nurses' station systems 130 can be desktop computers,
laptops, work stations, or the like that are located at a nurses'
station. One or more nurses' station computers 130 can be located
at a single nurses' station. The nurses' station computers 130 can
receive and display physiological information and alarm data
received from the MMS 120 (or monitors 140). In certain
embodiments, the nurses' station computers 130 use a graphical user
interface (GUI) that provides a streamlined, at-a-glance view of
physiological and medical information. An example of this GUI is
described below with respect to FIG. 7.
[0027] The clinician devices 150 can include any of a variety of
devices used by clinicians, such as pagers, cell phones, smart
phones, personal digital assistants (PDA), laptops, tablet PCs,
personal computers, and the like. The clinician devices 150 are
able to receive, in some embodiments, physiological information and
alarms from the MMS 120 (or monitors 140). Physiological and alarm
data can be provided to a particular clinician device 150, for
example, in response to an alarm. The clinician devices 150 can, in
some instances, receive values and waveforms of physiological
parameters.
[0028] The MMS 120 in certain embodiments includes one or more
physical computing devices, such as servers, having hardware and/or
software for managing network traffic in the network 110. This
hardware and/or software may be logically and/or physically divided
into different servers 120 for different functions, such as
communications servers, web servers, database servers, application
servers, file servers, proxy servers, and the like.
[0029] The MMS 120 can use standardized protocols (such as TCP/IP)
or proprietary protocols to communicate with the patient monitors
140, the nurses' station computers 130, and the clinician devices
150. In one embodiment, when a patient monitor 140 wishes to
connect to the MMS 120, the MMS 120 can authenticate the patient
monitor 140 and provide the monitor 140 with context information of
a patient coupled to the monitor 140. Context information can
include patient demography, patient alarm settings, and clinician
assignments to the patient, among other things. Examples of context
information are described in U.S. application Ser. No. 11/633,656
filed Dec. 4, 2006, titled "Physiological alarm notification
system," the disclosure of which is hereby incorporated by
reference in its entirety. The MMS 120 may obtain this context
information from the nurses' station systems 130 or other hospital
computer systems, where patient admitting information is
provided.
[0030] Upon connecting to a patient monitor 140, the MMS 120 may
receive physiological information and medical events from the
patient monitors 140. The MMS 120 may provide at least a portion of
the physiological information and events to the nurses' station
systems 130 and/or clinician devices 150. For example, the MMS 120
may provide physiological data and alarms for a plurality of
patient monitors 140 to a nurses' station system 130, where nurses
can evaluate the data and/or alarms to determine how to treat
patients. Similarly, the MMS 120 may send wireless pages, emails,
instant messages, or the like to clinician devices 150 to provide
clinicians with physiological data and alarms.
[0031] Advantageously, in certain embodiments, the MMS 120 can
store physiological information obtained from the patient monitors
140 in a round-robin database (RRDB) 124. The RRDB 122 of various
embodiments includes a streamlined database structure that
facilitates rapidly storing and retrieving patient data. The RRDB
122 can therefore be used in certain embodiments to rapidly provide
physiological trend data to the nurses' stations 130 and to the
clinician devices 150. Thus, for example, if a clinician desires to
see a patient's physiological trends over a certain time period,
such as the past hour, the clinician can use a nurses' station
computer 130 or clinical device 150 to query the MMS 120. The MMS
120 may then obtain physiological information corresponding to the
desired time period from the RRDB 122. Advantageously, the RRDB 122
can enable faster acquisition of trend data then is possible with
relational databases currently used by hospital monitoring systems.
Additional uses and optimizations of the RRDB 122 are described
below.
[0032] In certain embodiments, the MMS 120 also archives or stores
information about medical events in a journal database 124. The
medical events can include events recorded by devices such as the
patient monitors 140, nurses' station systems 130, and clinician
devices 150. In particular, the medical events can include device
events that occur in response to a clinician's interaction with a
device, such as a clinician-initiated deactivation of an alarm. The
medical events can also include device events that occur without a
clinician's interaction with the device, such as the alarm itself.
Additional examples of medical events are described below with
respect to FIG. 2.
[0033] The MMS 120 may analyze the medical event information stored
in the journal database 124 to derive statistics about the medical
events. For example, the MMS 120 can analyze alarm events and alarm
deactivation events to determine clinician response times to
alarms. Using these statistics, the MMS 120 may generate reports
about clinician and and/or hospital performance. Advantageously, in
certain embodiments, these statistics and reports may be used to
improve the performance of clinicians and hospitals.
[0034] For instance, in certain situations, the reports might help
hospitals discover the cause of issues with patient monitors 140.
The following example scenario can illustrate potential benefits of
such a report. SpO.sub.2 alarm levels tend to be different for
adults and neonates. However, some clinicians may not know this and
may modify neonate SpO.sub.2 monitors to include adult alarm
levels. These changes can result in many false alarms, which may
cause clinicians to become frustrated and avoid using the patient
monitors 140. By journaling medical events such as clinician alarm
changes, it can be determined by an analysis of the journaled data
that clinicians were inappropriately adjusting alarm settings on
neonate monitors. A hospital could then use this information to
take corrective action, such as by fixing the alarm limits and
training the clinicians.
[0035] Although not shown, administrative devices may be provided
in the clinical network environment 100. The administrative devices
can include computing devices operated by hospital administrators,
IT staff, or the like. Using the administrative devices, IT staff
may, for example, promulgate changes to a plurality of patient
monitors 140, nurses' station systems 130, and the MMS 120. The
administrative devices may also allow IT staff to interface
third-party systems with the MMS 120, such as electronic medical
record (EMR) systems. The third party systems may be used, for
instance, to change alarm settings on a plurality of monitors from
an administrative device. Actions performed by administrators, IT
staff, and administrative devices in general may also be journaled
in the journal database 124.
[0036] FIG. 2 illustrates a more detailed embodiment of a clinical
network environment 200. The clinical network environment 200
includes a network 210, a patient monitor 240, a nurses' station
system 230, an MMS 220, an RRDB 222, and a journal database 224.
These components may include all the functionality described above
with respect to FIG. 1. One monitor 240 and nurses' station system
230 are shown for ease of illustration. In addition, although not
shown, the clinician devices 150 described above may also be
included in the clinical network environment 200.
[0037] The depicted embodiment of the patient monitor 240 includes
a monitoring module 242, an RRDB module 244, and a journal module
246. Each of these modules may include hardware and/or software.
Other components, such as a communications module, are not shown
but may be included in the patient monitor 240 in various
implementations.
[0038] The monitoring module 242 can monitor physiological signals
generated by one or more sensors coupled with a patient. The
monitoring module 242 may process the signals to determine any of a
variety of physiological parameters. For example, the monitoring
module 242 can determine physiological parameters such as pulse
rate, plethysmograph waveform data, perfusion index, and values of
blood constituents in body tissue, including for example, arterial
carbon monoxide saturation ("HbCO"), methemoglobin saturation
("HbMet"), total hemoglobin ("HbT" or "SpHb"), arterial oxygen
saturation ("SpO.sub.2"), fractional arterial oxygen saturation
("SpaO.sub.2"), oxygen content ("CaO.sub.2"), or the like.
[0039] In addition, the monitoring module 242 may obtain
physiological information from acoustic sensors in order to
determine respiratory rate, inspiratory time, expiratory time,
inspiration-to-expiration ratio, inspiratory flow, expiratory flow,
tidal volume, minute volume, apnea duration, breath sounds, rales,
rhonchi, stridor, and changes in breath sounds such as decreased
volume or change in airflow. In addition, in some cases the
monitoring module 242 monitors other physiological sounds, such as
heart rate (e.g., to help with probe-off detection), heart sounds
(e.g., S1, S2, S3, S4, and murmurs), and changes in heart sounds
such as normal to murmur or split heart sounds indicating fluid
overload. Moreover, the monitoring module 242 may monitor a
patient's electrical heart activity via electrocardiography (ECG)
and numerous other physiological parameters.
[0040] In some implementations, the patient monitors 140 may also
determine various measures of data confidence, such as the data
confidence indicators described in U.S. Pat. No. 7,024,233 entitled
"Pulse oximetry data confidence indicator," the disclosure of which
is hereby incorporated by reference in its entirety. The patient
monitors 140 may also determine a perfusion index, such as the
perfusion index described in U.S. Pat. No. 7,292,883 entitled
"Physiological assessment system," the disclosure of which is
hereby incorporated by reference in its entirety. Moreover, the
patient monitors 140 may determine a plethysmograph variability
index (PVI), such as the PVI described in U.S. Publication No.
2008/0188760 entitled "Plethysmograph variability processor," the
disclosure of which is hereby incorporated by reference in its
entirety. The parameters described herein are merely examples, and
many other parameters may be used in certain embodiments.
[0041] In certain embodiments, the RRDB module 244 receives
physiological information from the monitoring module 242 and
transmits the physiological information over the network 210 to the
MMS 220. In response, as will be described in greater detail below,
the MMS 220 may store the physiological information in the RRDB
222. Advantageously, in certain embodiments, the RRDB module 244
associates the physiological information with parameter descriptors
prior to transmittal to the MMS 220. The parameter descriptors may
be identifiers that the RRDB module 244 associates with each
measured physiological parameter value. The MMS 220 may use these
parameter descriptors to identify the types of measured parameters
received from the RRDB module 244.
[0042] The parameter descriptors may be descriptors generated
according to a markup language specification, such as an extensible
markup language (XML) specification. As such, the parameter
descriptors may include tags that enclose measured physiological
values. These tags may be machine readable or human readable. For
instance, the tags may include numerical identifiers (e.g., "0017")
or descriptive identifiers, such as "SPO2" or "SPHB." A simplified
example stream of physiological information from an SpP.sub.2
sensor and an SpHb sensor associated with parameter descriptors
might be as follows: <SPO2>96</SPO2>
<SPHB>14.1</SPHB> <SPO2>97</SPO2>
<SPHB>14.0</SPHB>, and so on.
[0043] In one embodiment, the RRDB module 244 may have stored
(e.g., in a data file) a set of predefined parameter descriptors
available for the patient monitor 240. These parameter descriptors
may correspond to possible parameters that may be measured by the
patient monitor 240. The parameter descriptors transmitted by the
RRDB module 244 may depend on the particular subset of parameters
measured by the patient monitor 240.
[0044] If an additional (or different) parameter is subsequently
measured by the patient monitor 240, the RRDB module 240 may
dynamically update the parameter descriptors that are sent to the
MMS 220. Likewise, if the patient monitor 240 ceases to measure one
of the parameters, the RRDB module 244 may cease to transmit the
corresponding parameter descriptor to the MMS 220.
[0045] The patient monitor 240 also includes a journal module 246
in the depicted embodiment. The journal module 240 may record
medical events related to the patient monitor 240. These medical
events can include clinician-initiated events, such as changes to
alarm settings (e.g., maximum and minimum permitted parameter
values), types of parameters monitored/sensors connected to the
patient monitor 240, and the like. The journal module 246 may
record these events by, for example, acting as a key logger or the
like to record button presses of a clinician. The journal module
246 may also include current-sense circuitry to detect when sensors
or cables are connected to the monitor 240, and so forth. The
medical events may also include non-clinician initiated events,
such as alarms and alerts. The medical events can also include
events from administrative devices (not shown), such as EMR updates
to alarm settings across the network 210.
[0046] The journal module 246 may log these events locally at the
patient monitor 240. In addition, or instead of logging the events
locally, the journal module 246 may transmit information about the
events to the MMS 220. In turn, the MMS 220 can store the event
information in the journal database 224.
[0047] The nurses' station system 230 is shown in the depicted
embodiment having a patient monitoring client 232. The patient
monitoring client 232 can enable the nurses' station system 230 to
receive and display physiological information and alarm
information. The patient monitoring client 232 includes a user
interface module 234. The user interface module 234 may include,
for example, software for displaying physiological information,
patient information, and medical event information for a plurality
of patient monitors 240. The user interface module 234 may also
allow clinicians to admit and discharge patients, remotely modify
device alarm limits, and the like. An example user interface that
may be generated by the user interface module 234 is described
below with respect to FIG. 7.
[0048] The patient monitoring client 232 further includes a journal
module 236. The journal module 236 may include software for
recording medical events related to the patient monitoring client
232. For example, the journal module 236 may record which
clinicians login to and logoff of the patient monitoring client 232
and when these events occur; admit and discharge events; and other
clinician keystrokes, mouse clicks, and interactions with the
patient monitoring client 232. The journal module 236 may log this
event information locally at the nurse's station system 230 and/or
transmit the event information to the MMS 220.
[0049] As shown, the MMS 220 may include a network management
module 221, an RRDB management module 223, and a journal management
module 225, each of which may include one or more software
components. In one embodiment, the network management module 221
receives messages containing physiological information and medical
event data from the patient monitor 240. The network management
module 221 can provide at least a portion of this data to the
nurses' station system 230 and clinician devices 150 of FIG. 1. The
network management module 221 can also provide the physiological
information to the RRDB management module 223 and provide the
medical event data to the journal management module 225.
[0050] In certain embodiments, the RRDB management module 223
stores the physiological information received from the patient
monitor 240 in the RRDB 222. When the patient monitor 240 initially
connects to the MMS 220, or at another time, the RRDB management
module 223 can create one or more RRDB files in the RRDB 222
corresponding to the patient monitor 240. The contents of this file
or files may depend on the type of patient monitor 240, which may
be defined by the patient monitor's 240 serial number, model
number, vendor identifier, combinations of the same, or the like.
Specific examples of the structure and contents of RRDB files are
described below with respect to FIGS. 3 and 4.
[0051] The RRDB management module 223 can also provide
physiological trend data stored in the RRDB to the network
management module 221 for transmittal to monitors 240, nurses'
station systems 230, and/or clinician devices. The RRDB management
module 223 may also provide physiological data from the RRDB 222 to
the journal management module 225 for purposes described below with
respect to FIG. 6B.
[0052] The journal management module 225, in certain
implementations, receives medical event data from the monitor 240
and the nurses' station system 230 and stores this data in the
journal database 224. In an embodiment, the journal database 224 is
a relational database; however, other structures may be used. Each
entry of event data may have a corresponding time stamp that
indicates when an event occurred. This time stamp may be provided
by the journal modules 246 or 236 or by the journal management
module 225. The journal management module 225 may also store event
counters in the journal database 224 that reflect a number of times
medical events occurred. For example, counters could be stored that
count how many alarms occurred within a period of time or how many
times a clinician logged on or logged off of a network device.
[0053] Advantageously, the journal management module 225 may, in
certain embodiments, analyze the medical data in the journal
database 224 to determine statistics or metrics of clinician and/or
hospital performance. The journal management module 225 may provide
an interface to users of the nurses' station system 230 or another
computing device to access these statistics. In one example
embodiment, journal management module 225 can analyze alarm events
and alarm deactivation events to determine clinician response times
to alarms. The journal management module 225 may further determine
the clinician response times in nurses' day and night shifts. The
journal management module 225 may generate reports of these
statistics so that hospital administrators, for example, may
determine which shifts perform better than others.
[0054] More generally, the journal management module 225 may
generate reports about clinician and and/or hospital performance by
analyzing various statistics derived from data in the journal
database 224. One example of a report is a monitoring report card,
which grades a given hospital against other hospitals (or nurses'
station against nurses' station, and the like) based at least
partly on the derived statistics. Advantageously, hospital
administrators, clinicians, and the like may use these statistics
and reports to improve the clinician and hospital performance.
[0055] Some or all of the features of the clinical network
environment 200 may be adapted in certain embodiments. For
instance, either or both of the journal modules 246 or 236 may
perform some or all of the functions of the journal management
module 225. Likewise, one or more journal databases 224 may be
stored at the patient monitor 240 and/or nurses' work station 230.
Similarly, the RRDB module 224 may perform some or all of the
functions of the RRDB management module 223, and an RRDB 222 may be
stored at the patient monitor 240. In addition, in some
implementations, the clinician devices 150 of FIG. 1 may have RRDB
and/or journal modules as well. Many other adaptations,
configurations, and combinations may be made in other
embodiments.
[0056] FIG. 3 illustrates an embodiment of an RRDB file 300 for
storing physiological data in a clinical network environment, such
as the clinical network environments 100 or 200. By virtue of the
configuration of the RRDB file 300, in certain embodiments the MMS
120 or 220 described above can rapidly store and retrieve
physiological data.
[0057] The RRDB file 300 of certain embodiments has a flat file
structure; however, other structures (such as relational
structures) may also be used. In an embodiment, a single file 300
corresponds to one patient; however, many files 300 can be used for
a single patient. In addition, in some implementations, files 300
can be shared by multiple patients. The RRDB writes physiological
information to records 362 in the file 300. In certain embodiments,
each record 362 is one line in the RRDB; however, records 362 can
include multiple lines. For example, each record 362 could include
one or more numbers representing the values of one or more
physiological parameters, waveforms, and the like. In addition, in
some embodiments, alarm limits and other information may be stored
in each record 362.
[0058] Advantageously, in certain embodiments, different levels of
detail may be stored in RRDB files 300. For instance, a file 300
may be allocated for a single patient, for a device, for a single
parameter or technology of the device, or for a channel
corresponding to a parameter. Example criteria for allocating these
files is described below. The channel may be a value or set of
values measured by the device. For example, for an SpO.sub.2
sensor, there may be channels for the different wavelengths of
light used to obtain the SpO.sub.2 reading, e.g., red and infrared
(IR) channels. Other optical sensors may have one channel for each
wavelength of light used by the sensor (which may be more than
two).
[0059] Referring again to FIG. 2, the RRDB module 244 of the
patient monitor 240 may provide different amounts of physiological
information to the RRDB 222, corresponding to the different types
of RRDB files just described. The RRDB module 244 may select a
level of detail based at least partly on a health status of the
patient. If the patient is relatively healthy, for instance, the
RRDB module 244 may send less information to the RRDB 222. In
contrast, if the patient is relatively less healthy (e.g., more
acute), the RRDB module 244 may send a higher granularity of
physiological information to the RRDB 222. In other embodiments,
the RRDB module 244 may also adapt the amount of physiological
information transmitted to the RRDB 222 based on other factors,
such as the degree of noisiness of physiological signals,
variability of the signals, and so on.
[0060] More particularly, in some embodiments the RRDB module 244
may instruct the RRDB management module 223 to open a single file
for a patient. This file may contain a relatively high level of
detail for each device connected to the patient. This setting may
be appropriate in circumstances where the patient is relatively
healthy. If the patient is less healthy, the RRDB module 244 may
instruct the RRDB management module 223 to create a single file for
each device connected to the patient. Each of these files may have
more detail than may be included in a single file for a patient.
Continuing, at lower levels of health, the RRDB module 244 may
instruct the RRDB management module 223 to create a file for each
parameter measured by the patient monitor 240, or a file for each
channel of a sensor (which may include raw data from the sensor).
Thus, greater amounts of detail may be provided as the patient's
health becomes more acute.
[0061] The RRDB module 244 may dynamically adjust the amount of
data sent and/or the frequency that data is sent to the RRDB 222
based on the patient's health. As an example, if the patient's SpHb
level drops below a safe level (e.g., outside of alarm limits), the
RRDB module 244 may send more detailed physiological information to
the RRDB 222 or may send physiological information more frequently.
In response to receiving additional detail, the RRDB management
module 223 may create new files to store the more detailed
physiological information. Once the patient's SpHb returns to
normal, the RRDB module may send a lower level of detail to the
RRDB 222. The RRDB management module 223 may then create a new file
to store the lower level of detail, or use a previously-created
lower-level detail file. Thus, in certain embodiments, the RRDB
module 244 and the RRDB management module 223 may perform adaptive
control of RRDB file storage. Thus, in certain embodiments, the
RRDB may be considered an adaptive or dynamic RRDB.
[0062] Additionally, in certain embodiments, the RRDB module 244
may send multiple streams of physiological data to the RRDB 222.
Different streams may have different granularities of physiological
data and may be stored in different files in the RRDB 222. For
example, each stream of physiological data may include one or more
channels of physiological information. Each stream may correspond
to one or more files in the RRDB 222.
[0063] Referring again to FIG. 3, the RRDB can store a
predetermined number of records 362 in the file 300. After writing
data to the last record 362a in the file 300, the RRDB
automatically loops back to and overwrites the first record
362b--hence the term "round-robin." The records 362 can be stored
at regular (e.g., equal) time intervals, denoted by .DELTA.t in the
FIGURE. As each record 362 is stored in the RRDB, a time stamp can
be applied to the record 362. Thus, .DELTA.t can represent the
difference in value between the time stamps of any two sequential
records 362. Alternatively, a header section of the file 300 (see
FIG. 4) may include a predefined time step that dictates when new
values are recorded in the file 300. In some instances, a patient
monitor may not send data to the RRDB, either because the monitor
ceased to monitor data or because the monitor determines that data
need not be recorded (e.g., because the patient is healthy). To
preserve the time interval structure when the monitor ceases to
send data, zeros or other non-data values (such as NaN--"not a
number") can be stored in one or more records 362 of the file 300
in place of physiological information.
[0064] To read records 362 from the file 300, a pointer or the like
could be instructed to obtain k records, such as the previous k
records (e.g., k.DELTA.t). For example, to obtain the first k
records 362, a file pointer could be advanced over the most recent
k records 362 while the RRDB management module 223 (for instance)
reads the k records 362. Any subset of the records 362 can be
obtained, including a subset of the most recent records 362 or even
all of the records 362. In addition, portions of the records 362
may be read. For example, values for a particular parameter from a
plurality of parameters may be read from the previous k records
362.
[0065] Advantageously, records 362 can be obtained from the RRDB
several orders of magnitude faster than from a relational database.
For instance, in one embodiment, searches in the database can be
performed as zero-order searches. Thus, physiological information
trends can be rapidly streamed or otherwise provided to clinical
devices, nurses' station computers, and the like. In some
implementations, the RRDB can be configured such that physiological
information is read and transmitted to clinical devices fast enough
to comply with certain standards promulgated by the Joint
Commission on the Accreditation of Healthcare Organizations (JCAHO)
for the transmission of alarms. Thus, for example, if a standard
required alarms to be transmitted to clinicians within five seconds
of the alarm occurring, the RRDB can be configured to provide trend
data to the clinician device along with the alarm notification
within the five second period.
[0066] FIG. 4 illustrates a more detailed embodiment of an RRDB
file 400. The RRDB file includes a header 410 and a plurality of
records 420. The header 410 includes data that may be used by the
RRDB management module 223, for example, to read and write to the
file 400, as well as search through the file 400. In the depicted
embodiment, fields in the header 410 are denoted by XML tags. This
is merely one implementation that may be varied in other
embodiments.
[0067] The fields in the example header 410 shown include a start
time, stop time, step interval, number of parameters, and parameter
list. The start and stop times are measured in seconds in the
depicted embodiment (e.g., seconds from Unix epoch--1/1/1970). The
step interval (30 seconds in the embodiment shown) indicates how
frequently the records 420 are written to the file 400. The number
of parameters (in this case, 7) indicates how many physiological
parameters are being monitored. The parameter list includes a list
of parameter descriptors corresponding to the parameters being
monitored. Each of the fields in the header 410 may be adjusted by
the RRDB management module 223. Additional or fewer fields may be
included in certain embodiments.
[0068] Each record 420 in the depicted embodiment is a single line
including parameter values separated by a delimiter character (in
this case, a space). The parameter values in the first record 420,
for example, are 96, 55, 8.9, 14, 14.1, 0.5, and 1.0. These values
correspond to the order of the parameter descriptor in the
parameter list of the header 410. Thus, the value 96 corresponds to
the SPO2 parameter descriptor, the value 55 corresponds to the BPM
(beats per minute) parameter descriptor, and so on.
[0069] Advantageously, in certain embodiments, because the
parameter list in the header 410 includes the parameter
descriptors, the records 420 can be written without including the
parameter descriptors in the individual records 420. As a result,
in certain implementations, the file 400 can have a smaller size
than if the parameter descriptors were embedded in the records
420.
[0070] FIGS. 5A through 5C illustrate embodiments of processes 500
for using an RRDB to store physiological data. Referring to FIG.
5A, an embodiment of a process 500A for providing physiological
data to an RRDB is shown. In one embodiment, the process 500A may
be implemented by any of the MMS's described above (e.g., the MMS
120 or 220). In particular, the process 500A may be implemented by
the RRDB management module 223 of FIG. 2. Alternatively, at least
some of the blocks may be implemented by the RRDB module 244 of the
patient monitor 240. Advantageously, in certain embodiments, the
process 500A enables RRDB files to be created for patient monitors
that communicate with a MMS over a clinical network.
[0071] At block 502, identification information is received from a
patient monitor. The identification information may include, for
example a serial number of the patient monitor, a model number of
the patient monitor, a vendor of the patient monitor,
identification of one or more original equipment manufacturer (OEM)
modules of the patient monitor, combinations of the same, and the
like.
[0072] At block 504, parameter descriptors corresponding to the
patient monitor are retrieved based at least partly on the
identification information. The parameter descriptors for each
monitor may be stored in a file on the MMS 120 or 220. For example,
a set of possible parameter descriptors may be stored for each
monitor serial number, which descriptors correspond to possible
parameters that a given monitor can process. In certain
embodiments, the parameter descriptors are extensible markup
language (XML) descriptors or the like.
[0073] An RRDB file with a header having the identified parameter
descriptors is created at block 506. An example of a header for an
RRDB file is described above with respect to FIG. 4. The parameter
descriptors may be inserted, for example, into the parameter list
shown in FIG. 4. Thus, the parameter list for a given patient
monitor may be determined by the RRDB management module 223. As
will be described below with respect to FIG. 5B, the parameter list
may also be determined at least partly by the patient monitor.
[0074] At block 508, physiological data is received from the
patient monitor. At block 510, the header is used to map the
physiological data to locations in the RRDB file. This mapping may
be performed at least partly by using the descriptors in the data,
as described above with respect to FIG. 4.
[0075] FIG. 5B illustrates another embodiment of a process 500B for
providing physiological data to an RRDB. This process 500B may be
implemented by the patient monitor (e.g., 140 or 240). In
particular, the RRDB module 244 may perform certain blocks of the
process 500B. Alternatively, at least some of the blocks may be
implemented by the RRDB module 244 of the patient monitor 240.
Advantageously, in certain embodiments the process 500B enables
RRDB files to be dynamically created based on changing parameters
monitored by the patient monitor.
[0076] Physiological data corresponding to one or more
physiological parameters of a patient are obtained at block 512.
This block may be performed by the monitoring module 242 described
above. At block 514, parameter descriptors are associated with the
physiological data to produce associated physiological data. This
association may be performed by the RRDB module 244. The
association may take place in one embodiment by inserting XML tags
into the physiological data. The associated physiological data is
provided to an RRDB at block 516.
[0077] In response to the transmission of this associated
physiological data, in one embodiment the MMS can create an RRDB
file having the parameter descriptors identified in the
physiological data. Alternatively, the MMS may have already created
the RRDB file according to the process 500A described above.
[0078] At decision block 518, it is determined whether different
physiological parameters have been measured. If so, at block 519,
different parameter descriptors are associated with the
physiological data, and at block 520, the associated physiological
data is again provided to the RRDB. Blocks 518-520 may be
implemented by the RRDB module 244. As an example, suppose that the
parameters measured in block 512 include SpO.sub.2 and ECG. The
parameter descriptors provided in block 514 might be "SPO2" and
"ECG." If a clinician enabled an SpHb parameter measurement on the
monitor at block 518, the parameter descriptors associated with the
physiological data in block 519 might now include "SPO2" and "ECG"
and "SPHB."
[0079] In response to the transmission of the new associated
physiological data at block 520, the MMS may create a new RRDB file
having the new parameter descriptors identified in the
physiological data. Thus, the patient monitor may be able to
dynamically adjust the physiological data and associated
descriptors provided to the RRDB.
[0080] FIG. 5C illustrates an embodiment of a process 500C for
dynamically adjusting RRDB storage corresponding to a patient
monitor. In one embodiment, the process 500C may be implemented by
any of the MMS's described above (e.g., the MMS 120 or 220). In
particular, the process 500C may be implemented by the RRDB
management module 223. Alternatively, at least some of the blocks
may be implemented by the RRDB module 244 of the patient monitor
240.
[0081] As described above with respect to FIG. 3, the size of an
RRDB file may be predetermined and may not increase. This constant
size therefore can provide a predetermined storage amount for
physiological trend data. The size of the RRDB file may be
configured, for example, upon patient admittance to the hospital.
An example size of the RRDB might correspond to 72 hours worth of
data. For some acute patients, however, additional trend data may
be desired. However, because the RRDB file may have a constant
size, after the example 72 hours, the trend data will be
overwritten. Advantageously, in certain embodiments, the process
500C enables additional trend data to be written to an RRDB. Thus,
in certain embodiments, the RRDB may be considered an adaptive or
dynamic RRDB.
[0082] At block 532, an initial size of an RRDB file is allocated.
The initial file size may be chosen based on a projected length of
stay of the patient, the patient's current health status, or the
like. Alternatively, the file size may be predefined for all
patients. At block 534, physiological data received from a patient
monitor is analyzed to determine the patient's acuity level. The
acuity level of the patient can be determined, for instance, by
analyzing the PVI of the patient, which corresponds to variability
in the patient's plethysmograph. A patient with higher PVI or
variability may benefit from additional trend data. Other values
that may be considered in determining acuity level include the data
confidence indicators described in U.S. Pat. No. 7,024,233,
incorporated above, pulse rate, SpO.sub.2 variability, and
variation of any other physiological parameter. In addition, in
some embodiments, acuity may be determined by examining the
patient's alarm history, such that a history of multiple alarms or
severe alarms may indicate acuity.
[0083] At decision block 536, it is determined whether the patient
has significant acuity. If the patient has significant acuity,
additional storage for RRDB data is allocated at block 538. This
initial storage may be allocated by extending the length of the
RRDB file, but creating a new file, or the like. Otherwise, if the
patient does not have significant acuity, the process 500C
ends.
[0084] FIG. 6A illustrates an embodiment of a process 600A for
journaling medical events in a journal database. In one embodiment,
the process 600A may be implemented by any of the MMS's described
above (e.g., the MMS 120 or 220). In particular, the process 600A
may be implemented by the journal management module 225.
Alternatively, at least some of the blocks may be implemented by
the journal modules 236, 246. Advantageously, in certain
embodiments, the process 600A facilitates the generation of reports
based on the journaled data.
[0085] At block 602, medical events are journaled in a journal
database. In response to requests for report from a user (e.g., a
clinician), at block 604 statistics about the medical events are
obtained from the journal database. The statistics may include the
type, frequency, and duration of medical events, the identity of
clinicians or patients associated with the events, alarm response
times, combinations of the same, and the like.
[0086] A report is generated at block 606 regarding the medical
event statistics. At block 608, the report is used to identify
potential areas of improvement in hospital operations. For example,
the report can be a "monitoring report card" that assigns scores to
the hospital or clinicians of the hospital based on their
performance.
[0087] FIG. 6B illustrates an embodiment of a process 600B for
correlating data from a journal database and an RRDB. In one
embodiment, the process 600B may be implemented by any of the MMS's
described above (e.g., the MMS 120 or 220). In particular, the
process 600B may be implemented by the RRDB module 223 and journal
management module 225. Alternatively, at least some of the blocks
may be implemented by the RRDB module 244 and journal modules 236,
246. Advantageously, in certain embodiments, the process 600B
enables physiological information from the RRDB and medical events
to be correlated in time. Such a reconstruction of events and
physiological data can be akin to aviation "black box" technology,
allowing the user to replay clinical actions leading up to medical
incidents.
[0088] At block 602, the request is received from a user to review
journaled and physiological data corresponding to a period of time.
The user may be a clinician, hospital administrator, or the like,
who wishes to determine the cause of a problem in the healthcare of
a patient. For instance, the user may wish to determine why
clinicians failed to respond when a patient's SpO.sub.2 dropped
below safe levels.
[0089] At block 604, journaled data is retrieved for the specified
period of time from a journal database. This block may be performed
by the journal management module 225. At block 606, physiological
data for the specified period of time is retrieved from an RRDB.
This block may be performed by the RRDB management module 223. The
journal data is correlated with the physiological data with respect
to time at block 608. This correlation may include reconstructing a
timeline of medical events, with values of physiological parameters
(optionally including waveforms) provided in the correct time
sequence on the timeline. In some embodiments, to facilitate this
coordination between the RRDB management module 223 and the journal
management module 225, timestamps in each database 222, 224 may be
synchronized when the data is stored.
[0090] The correlated data is output for presentation to the user
at block 610. The output may include, for example, a graphical view
of medical events superimposed on physiological information (e.g.,
a waveform), or the like. Many display formats may be used for the
correlated data.
[0091] FIG. 7 illustrates an example graphical user interface (GUI)
700 for monitoring patients. The GUI 700 can be provided on a
nurses' station system or the like. The GUI 700 can also be
displayed on a clinician device.
[0092] The GUI 700 includes several display areas. In the depicted
embodiment, the GUI 700 includes a patient status display area 710.
The patient status display area 710 shows the status of multiple
patients in a hospital or other clinical location. In an
embodiment, patient status display area 710 depicts patient status
for patients in a hospital department. Advantageously, in certain
embodiments, the patient status display area 710 provides an
"at-a-glance" view of multiple patients' health status.
[0093] The patient status display area 710 includes a plurality of
patient status modules 712. Each patient status module 712 can
correspond to a patient monitor that can be coupled to a medical
patient. Each patient status module 712 can display a graphical
status indicator 714. An example graphical status indicator 714 is
shown in the screens 700 as a miniature patient monitor icon. The
graphical status indicator 714 can selectively indicate one of
several states of a patient monitor. In one embodiment, four
possible patient monitor states can be depicted by the graphical
status indicator 714. These include an alarm condition, a no alarm
condition, patient context information status, and connection
status.
[0094] In various implementations, the graphical status indicator
714 changes color, shape, or the like to indicate one of the
different patient monitor states. For example, if an alarm
condition is present, the graphical status indicator 714 could turn
red to signify the alarm. If there is no context information
available for the patient (see FIG. 1), then the graphical status
indicator 714 could turn yellow. If the device is not connected to
the patient or the network, then the graphical status indicator 714
could turn gray. And if there is no alarm condition, if there is
context information, and if the patient monitor is connected to the
patient and the network, then the graphical status indicator 714
could turn green. Many other colors, symbols, and/or shapes could
be used in place of or in combination with the above-described
embodiments.
[0095] Advantageously, the graphical status indicator 714 shows at
a glance the status of a patient monitor. Thus, in the patient
status display area 710, several graphical status indicators 714
corresponding to several patients show an at-a-glance view for the
patient monitors corresponding to these patients. A clinician can
therefore readily see the needs that a patient might have with
regards to alarms, connection status, and context information.
[0096] Currently available graphical user interfaces for nurses'
station computers tend to show a plurality of wave forms or
changing physiological parameter numbers for each patient. This
method of displaying patient information can be cluttered,
confusing, and even hypnotic in some situations. Nurses working on
a night shift, for instance, may find it difficult to concentrate
on an alarm when several other patients' indicators on the display
have changing numbers, changing waveforms, or the like. In
contrast, in the graphical interface herein described, when the
graphical status indicator 714 indicates an alarm condition, this
alarm condition can stand out and be immediately recognized by the
clinician.
[0097] Moreover, the graphical status indicator 714 simplifies the
first level of analysis that nurses tend to perform. In currently
available devices, nurses often have to analyze waveforms at the
nurses' station to determine the health status of a patient.
However, using the screens 700, a nurse need not interpret any
waveforms or changing parameters of the patient, but instead can
rely on the graphical status indicator 714 that indicates the
presence of an alarm.
[0098] In certain embodiments, the patient status modules 712 can
be selected by a single mouse click or the like. Selecting a
patient status module 712 in one embodiment can bring up a patient
monitor view area 720. The patient monitor view area 720 shows a
view of a patient monitor corresponding to a selected patient
status module 712. In certain implementations, the patient monitor
view area 720 can show a view of the screen from the actual patient
monitor device at the bedside of the patient. Thus, a clinician can
readily recognize the physiological parameters of the patient in a
format that the clinician is likely familiar with. The patient
monitor view area 720 is currently receiving physiological
information from a patient.
[0099] A history view area 730 in certain implementations can show
medical event data corresponding to a selected patient monitor
status module 712. This medical event data can be obtained from a
journal database for inclusion in the GUI 700. The historical view
730 can show, for example, when a sensor was connected or
disconnected from a patient, when alarms were active, and when a
patient was admitted to the hospital or department. Although not
shown, the history view area 730 can also be configured to show
trend data obtained from an RRDB instead of, or in addition to, the
journaled data.
[0100] Depending on the embodiment, certain acts, events, or
functions of any of the methods described herein can be performed
in a different sequence, may be added, merged, or left out all
together (e.g., not all described acts or events are necessary for
the practice of the method). Moreover, in certain embodiments, acts
or events may be performed concurrently, e.g., through
multi-threaded processing, interrupt processing, or multiple
processors, rather than sequentially.
[0101] The various illustrative logical blocks, modules, circuits,
and algorithm steps described in connection with the embodiments
disclosed herein may be implemented as electronic hardware,
computer software, or combinations of both. To clearly illustrate
this interchangeability of hardware and software, various
illustrative components, blocks, modules, circuits, and steps have
been described above generally in terms of their functionality.
Whether such functionality is implemented as hardware or software
depends upon the particular application and design constraints
imposed on the overall system. The described functionality may be
implemented in varying ways for each particular application, but
such implementation decisions should not be interpreted as causing
a departure from the scope of the disclosure.
[0102] The various illustrative logical blocks, modules, and
circuits described in connection with the embodiments disclosed
herein may be implemented or performed with a general purpose
processor, a digital signal processor (DSP), an application
specific integrated circuit (ASIC), a field programmable gate array
(FPGA) or other programmable logic device, discrete gate or
transistor logic, discrete hardware components, or any combination
thereof designed to perform the functions described herein. A
general purpose processor may be a microprocessor, but in the
alternative, the processor may be any conventional processor,
controller, microcontroller, or state machine. A processor may also
be implemented as a combination of computing devices, e.g., a
combination of a DSP and a microprocessor, a plurality of
microprocessors, one or more microprocessors in conjunction with a
DSP core, or any other such configuration.
[0103] The steps of a method or algorithm described in connection
with the embodiments disclosed herein may be embodied directly in
hardware, in a software module executed by a processor, or in a
combination of the two. A software module may reside in RAM memory,
flash memory, ROM memory, EPROM memory, EEPROM memory, registers,
hard disk, a removable disk, a CD-ROM, or any other form of storage
medium known in the art. An exemplary storage medium is coupled to
the processor such the processor can read information from, and
write information to, the storage medium. In the alternative, the
storage medium may be integral to the processor. The processor and
the storage medium may reside in an ASIC. The ASIC may reside in a
user terminal. In the alternative, the processor and the storage
medium may reside as discrete components in a user terminal.
[0104] Conditional language used herein, such as, among others,
"can," "could," "might," "may," "e.g.," and the like, unless
specifically stated otherwise, or otherwise understood within the
context as used, is generally intended to convey that certain
embodiments include, while other embodiments do not include,
certain features, elements and/or steps. Thus, such conditional
language is not generally intended to imply that features, elements
and/or steps are in any way required for one or more embodiments or
that one or more embodiments necessarily include logic for
deciding, with or without author input or prompting, whether these
features, elements and/or steps are included or are to be performed
in any particular embodiment.
[0105] While the above detailed description has shown, described,
and pointed out novel features as applied to various embodiments,
it will be understood that various omissions, substitutions, and
changes in the form and details of the device or process
illustrated may be made without departing from the spirit of the
disclosure. As will be recognized, certain embodiments of the
inventions described herein may be embodied within a form that does
not provide all of the features and benefits set forth herein, as
some features may be used or practiced separately from others. The
scope of the inventions is indicated by the appended claims rather
than by the foregoing description. All changes which come within
the meaning and range of equivalency of the claims are to be
embraced within their scope.
* * * * *