US20130096936A1 - Systems and methods for storing, analyzing, and retrieving medical data - Google Patents

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.

Description

RELATED APPLICATION
• 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
• 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.
• 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
• 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.
• 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.
• 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.
• 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.
• 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
• 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.
• FIG. 1 is a block diagram illustrating an embodiment of a clinical network environment;
• FIG. 2 is a block diagram illustrating a more detailed embodiment of the clinical network environment ofFIG. 1;
• FIG. 3 is a block diagram illustrating an embodiment of a round-robin database file for storing physiological data in the clinical network environment ofFIG. 1 or2;
• FIG. 4 is a more detailed embodiment of the round-robin database file ofFIG. 3;
• FIGS. 5A through 5C are flow charts illustrating embodiments of processes for using a round-robin database for storing physiological data;
• FIG. 6A is a flow chart illustrating an embodiment of a process for journaling medical events in a journal database;
• 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
• FIG. 7 is a screen shot of an example user interface for monitoring patients in the clinical network environment ofFIG. 1.
DETAILED DESCRIPTION
• 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.
• 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.
• 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.
• FIG. 1 illustrates an embodiment of aclinical network environment100. Theclinical network environment100 includes a multi-patient monitoring system (MMS)120 in communication with one ormore patient monitors140, nurses'station systems130, andclinician devices150 over anetwork110. In certain embodiments, the MMS120 provides physiological data obtained from thepatient monitors140 to the nurses'station systems130 and/or theclinician devices150. Additionally, in certain embodiments, theMMS120 stores physiological information and medical event information for later analysis.
• Thenetwork110 of theclinical network environment100 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, thenetwork110 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, thevarious devices120,130,140, and150 of theclinical network environment100 may be geographically distributed (e.g., among multiple hospitals) or co-located (e.g., in a single hospital).
• The patient monitors140 may be point-of-care (POC) instruments or the like that monitor physiological signals detected by sensors coupled with medical patients. The patient monitors140 may process the signals to determine any of a variety of physiological parameters. One example of a physiological parameter is blood oxygen saturation (SpO₂). Other examples of physiological parameters are described below with respect toFIG. 2.
• The patient monitors140 can provide the physiological information to theMMS120. The patient monitors140 can also provide information on medical events, such as alarms, to theMMS120. 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 toFIG. 2.
• In various embodiments, the patient monitors140 provide the physiological information and medical events to theMMS120. TheMMS120 is described in greater detail below. In some implementations, the patient monitors140 may provide at least some of this information directly to the nurses'station systems130 andclinician devices150.
• The nurses'station systems130 can be desktop computers, laptops, work stations, or the like that are located at a nurses' station. One or more nurses'station computers130 can be located at a single nurses' station. The nurses'station computers130 can receive and display physiological information and alarm data received from the MMS120 (or monitors140). In certain embodiments, the nurses'station computers130 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 toFIG. 7.
• Theclinician devices150 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. Theclinician devices150 are able to receive, in some embodiments, physiological information and alarms from the MMS120 (or monitors140). Physiological and alarm data can be provided to aparticular clinician device150, for example, in response to an alarm. Theclinician devices150 can, in some instances, receive values and waveforms of physiological parameters.
• TheMMS120 in certain embodiments includes one or more physical computing devices, such as servers, having hardware and/or software for managing network traffic in thenetwork110. This hardware and/or software may be logically and/or physically divided intodifferent servers120 for different functions, such as communications servers, web servers, database servers, application servers, file servers, proxy servers, and the like.
• TheMMS120 can use standardized protocols (such as TCP/IP) or proprietary protocols to communicate with the patient monitors140, the nurses'station computers130, and theclinician devices150. In one embodiment, when apatient monitor140 wishes to connect to theMMS120, theMMS120 can authenticate the patient monitor140 and provide themonitor140 with context information of a patient coupled to themonitor140. 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. TheMMS120 may obtain this context information from the nurses'station systems130 or other hospital computer systems, where patient admitting information is provided.
• Upon connecting to apatient monitor140, theMMS120 may receive physiological information and medical events from the patient monitors140. TheMMS120 may provide at least a portion of the physiological information and events to the nurses'station systems130 and/orclinician devices150. For example, theMMS120 may provide physiological data and alarms for a plurality of patient monitors140 to a nurses'station system130, where nurses can evaluate the data and/or alarms to determine how to treat patients. Similarly, theMMS120 may send wireless pages, emails, instant messages, or the like to cliniciandevices150 to provide clinicians with physiological data and alarms.
• Advantageously, in certain embodiments, theMMS120 can store physiological information obtained from the patient monitors140 in a round-robin database (RRDB)124. TheRRDB122 of various embodiments includes a streamlined database structure that facilitates rapidly storing and retrieving patient data. TheRRDB122 can therefore be used in certain embodiments to rapidly provide physiological trend data to the nurses'stations130 and to theclinician devices150. 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 computer130 orclinical device150 to query theMMS120. TheMMS120 may then obtain physiological information corresponding to the desired time period from theRRDB122. Advantageously, theRRDB122 can enable faster acquisition of trend data then is possible with relational databases currently used by hospital monitoring systems. Additional uses and optimizations of theRRDB122 are described below.
• In certain embodiments, theMMS120 also archives or stores information about medical events in ajournal database124. The medical events can include events recorded by devices such as the patient monitors140, nurses'station systems130, andclinician devices150. 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 toFIG. 2.
• TheMMS120 may analyze the medical event information stored in thejournal database124 to derive statistics about the medical events. For example, theMMS120 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. Using these statistics, theMMS120 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.
• For instance, in certain situations, the reports might help hospitals discover the cause of issues with patient monitors140. The following example scenario can illustrate potential benefits of such a report. SpO₂alarm levels tend to be different for adults and neonates. However, some clinicians may not know this and may modify neonate SpO₂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 monitors140. 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.
• Although not shown, administrative devices may be provided in theclinical network environment100. 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 monitors140, nurses'station systems130, and theMMS120. The administrative devices may also allow IT staff to interface third-party systems with theMMS120, 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 thejournal database124.
• FIG. 2 illustrates a more detailed embodiment of aclinical network environment200. Theclinical network environment200 includes anetwork210, apatient monitor240, a nurses'station system230, anMMS220, anRRDB222, and ajournal database224. These components may include all the functionality described above with respect toFIG. 1. Onemonitor240 and nurses'station system230 are shown for ease of illustration. In addition, although not shown, theclinician devices150 described above may also be included in theclinical network environment200.
• The depicted embodiment of the patient monitor240 includes amonitoring module242, anRRDB module244, and ajournal module246. 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 monitor240 in various implementations.
• Themonitoring module242 can monitor physiological signals generated by one or more sensors coupled with a patient. Themonitoring module242 may process the signals to determine any of a variety of physiological parameters. For example, themonitoring module242 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₂”), fractional arterial oxygen saturation (“SpaO₂”), oxygen content (“CaO₂”), or the like.
• In addition, themonitoring module242 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 themonitoring module242 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, themonitoring module242 may monitor a patient's electrical heart activity via electrocardiography (ECG) and numerous other physiological parameters.
• In some implementations, the patient monitors140 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 monitors140 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 monitors140 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.
• In certain embodiments, theRRDB module244 receives physiological information from themonitoring module242 and transmits the physiological information over thenetwork210 to theMMS220. In response, as will be described in greater detail below, theMMS220 may store the physiological information in theRRDB222. Advantageously, in certain embodiments, theRRDB module244 associates the physiological information with parameter descriptors prior to transmittal to theMMS220. The parameter descriptors may be identifiers that theRRDB module244 associates with each measured physiological parameter value. TheMMS220 may use these parameter descriptors to identify the types of measured parameters received from theRRDB module244.
• 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₂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.
• In one embodiment, theRRDB module244 may have stored (e.g., in a data file) a set of predefined parameter descriptors available for thepatient monitor240. These parameter descriptors may correspond to possible parameters that may be measured by thepatient monitor240. The parameter descriptors transmitted by theRRDB module244 may depend on the particular subset of parameters measured by thepatient monitor240.
• If an additional (or different) parameter is subsequently measured by the patient monitor240, theRRDB module240 may dynamically update the parameter descriptors that are sent to theMMS220. Likewise, if the patient monitor240 ceases to measure one of the parameters, theRRDB module244 may cease to transmit the corresponding parameter descriptor to theMMS220.
• The patient monitor240 also includes ajournal module246 in the depicted embodiment. Thejournal module240 may record medical events related to thepatient monitor240. 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 monitor240, and the like. Thejournal module246 may record these events by, for example, acting as a key logger or the like to record button presses of a clinician. Thejournal module246 may also include current-sense circuitry to detect when sensors or cables are connected to themonitor240, 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 thenetwork210.
• Thejournal module246 may log these events locally at thepatient monitor240. In addition, or instead of logging the events locally, thejournal module246 may transmit information about the events to theMMS220. In turn, theMMS220 can store the event information in thejournal database224.
• The nurses'station system230 is shown in the depicted embodiment having apatient monitoring client232. Thepatient monitoring client232 can enable the nurses'station system230 to receive and display physiological information and alarm information. Thepatient monitoring client232 includes auser interface module234. Theuser interface module234 may include, for example, software for displaying physiological information, patient information, and medical event information for a plurality of patient monitors240. Theuser interface module234 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 theuser interface module234 is described below with respect toFIG. 7.
• Thepatient monitoring client232 further includes ajournal module236. Thejournal module236 may include software for recording medical events related to thepatient monitoring client232. For example, thejournal module236 may record which clinicians login to and logoff of thepatient monitoring client232 and when these events occur; admit and discharge events; and other clinician keystrokes, mouse clicks, and interactions with thepatient monitoring client232. Thejournal module236 may log this event information locally at the nurse'sstation system230 and/or transmit the event information to theMMS220.
• As shown, theMMS220 may include anetwork management module221, anRRDB management module223, and ajournal management module225, each of which may include one or more software components. In one embodiment, thenetwork management module221 receives messages containing physiological information and medical event data from thepatient monitor240. Thenetwork management module221 can provide at least a portion of this data to the nurses'station system230 andclinician devices150 ofFIG. 1. Thenetwork management module221 can also provide the physiological information to theRRDB management module223 and provide the medical event data to thejournal management module225.
• In certain embodiments, theRRDB management module223 stores the physiological information received from the patient monitor240 in theRRDB222. When the patient monitor240 initially connects to theMMS220, or at another time, theRRDB management module223 can create one or more RRDB files in theRRDB222 corresponding to thepatient monitor240. The contents of this file or files may depend on the type ofpatient monitor240, which may be defined by the patient monitor's240 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 toFIGS. 3 and 4.
• TheRRDB management module223 can also provide physiological trend data stored in the RRDB to thenetwork management module221 for transmittal tomonitors240, nurses'station systems230, and/or clinician devices. TheRRDB management module223 may also provide physiological data from theRRDB222 to thejournal management module225 for purposes described below with respect toFIG. 6B.
• Thejournal management module225, in certain implementations, receives medical event data from themonitor240 and the nurses'station system230 and stores this data in thejournal database224. In an embodiment, thejournal database224 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 thejournal modules246 or236 or by thejournal management module225. Thejournal management module225 may also store event counters in thejournal database224 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.
• Advantageously, thejournal management module225 may, in certain embodiments, analyze the medical data in thejournal database224 to determine statistics or metrics of clinician and/or hospital performance. Thejournal management module225 may provide an interface to users of the nurses'station system230 or another computing device to access these statistics. In one example embodiment,journal management module225 can analyze alarm events and alarm deactivation events to determine clinician response times to alarms. Thejournal management module225 may further determine the clinician response times in nurses' day and night shifts. Thejournal management module225 may generate reports of these statistics so that hospital administrators, for example, may determine which shifts perform better than others.
• More generally, thejournal management module225 may generate reports about clinician and and/or hospital performance by analyzing various statistics derived from data in thejournal database224. 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.
• Some or all of the features of theclinical network environment200 may be adapted in certain embodiments. For instance, either or both of thejournal modules246 or236 may perform some or all of the functions of thejournal management module225. Likewise, one ormore journal databases224 may be stored at the patient monitor240 and/or nurses'work station230. Similarly, theRRDB module224 may perform some or all of the functions of theRRDB management module223, and anRRDB222 may be stored at thepatient monitor240. In addition, in some implementations, theclinician devices150 ofFIG. 1 may have RRDB and/or journal modules as well. Many other adaptations, configurations, and combinations may be made in other embodiments.
• FIG. 3 illustrates an embodiment of anRRDB file300 for storing physiological data in a clinical network environment, such as theclinical network environments100 or200. By virtue of the configuration of theRRDB file300, in certain embodiments theMMS120 or220 described above can rapidly store and retrieve physiological data.
• TheRRDB file300 of certain embodiments has a flat file structure; however, other structures (such as relational structures) may also be used. In an embodiment, asingle file300 corresponds to one patient; however,many files300 can be used for a single patient. In addition, in some implementations, files300 can be shared by multiple patients. The RRDB writes physiological information torecords362 in thefile300. In certain embodiments, each record362 is one line in the RRDB; however,records362 can include multiple lines. For example, each record362 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 eachrecord362.
• Advantageously, in certain embodiments, different levels of detail may be stored in RRDB files300. For instance, afile300 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₂sensor, there may be channels for the different wavelengths of light used to obtain the SpO₂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).
• Referring again toFIG. 2, theRRDB module244 of the patient monitor240 may provide different amounts of physiological information to theRRDB222, corresponding to the different types of RRDB files just described. TheRRDB module244 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, theRRDB module244 may send less information to theRRDB222. In contrast, if the patient is relatively less healthy (e.g., more acute), theRRDB module244 may send a higher granularity of physiological information to theRRDB222. In other embodiments, theRRDB module244 may also adapt the amount of physiological information transmitted to theRRDB222 based on other factors, such as the degree of noisiness of physiological signals, variability of the signals, and so on.
• More particularly, in some embodiments theRRDB module244 may instruct theRRDB management module223 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, theRRDB module244 may instruct theRRDB management module223 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, theRRDB module244 may instruct theRRDB management module223 to create a file for each parameter measured by the patient monitor240, 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.
• TheRRDB module244 may dynamically adjust the amount of data sent and/or the frequency that data is sent to theRRDB222 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), theRRDB module244 may send more detailed physiological information to theRRDB222 or may send physiological information more frequently. In response to receiving additional detail, theRRDB management module223 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 theRRDB222. TheRRDB management module223 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, theRRDB module244 and theRRDB management module223 may perform adaptive control of RRDB file storage. Thus, in certain embodiments, the RRDB may be considered an adaptive or dynamic RRDB.
• Additionally, in certain embodiments, theRRDB module244 may send multiple streams of physiological data to theRRDB222. Different streams may have different granularities of physiological data and may be stored in different files in theRRDB222. 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 theRRDB222.
• Referring again toFIG. 3, the RRDB can store a predetermined number ofrecords362 in thefile300. After writing data to thelast record362ain thefile300, the RRDB automatically loops back to and overwrites thefirst record362b—hence the term “round-robin.” Therecords362 can be stored at regular (e.g., equal) time intervals, denoted by Δt in the FIGURE. As each record362 is stored in the RRDB, a time stamp can be applied to therecord362. Thus, Δt can represent the difference in value between the time stamps of any twosequential records362. Alternatively, a header section of the file300 (seeFIG. 4) may include a predefined time step that dictates when new values are recorded in thefile300. 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 ormore records362 of thefile300 in place of physiological information.
• To readrecords362 from thefile300, a pointer or the like could be instructed to obtain k records, such as the previous k records (e.g., kΔt). For example, to obtain the first k records362, a file pointer could be advanced over the mostrecent k records362 while the RRDB management module223 (for instance) reads the k records362. Any subset of therecords362 can be obtained, including a subset of the mostrecent records362 or even all of therecords362. In addition, portions of therecords362 may be read. For example, values for a particular parameter from a plurality of parameters may be read from the previous k records362.
• Advantageously,records362 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.
• FIG. 4 illustrates a more detailed embodiment of anRRDB file400. The RRDB file includes aheader410 and a plurality ofrecords420. Theheader410 includes data that may be used by theRRDB management module223, for example, to read and write to thefile400, as well as search through thefile400. In the depicted embodiment, fields in theheader410 are denoted by XML tags. This is merely one implementation that may be varied in other embodiments.
• The fields in theexample header410 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 therecords420 are written to thefile400. 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 theheader410 may be adjusted by theRRDB management module223. Additional or fewer fields may be included in certain embodiments.
• Eachrecord420 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 thefirst record420, 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 theheader410. Thus, thevalue 96 corresponds to the SPO2 parameter descriptor, thevalue 55 corresponds to the BPM (beats per minute) parameter descriptor, and so on.
• Advantageously, in certain embodiments, because the parameter list in theheader410 includes the parameter descriptors, therecords420 can be written without including the parameter descriptors in theindividual records420. As a result, in certain implementations, thefile400 can have a smaller size than if the parameter descriptors were embedded in therecords420.
• FIGS. 5A through 5C illustrate embodiments of processes500 for using an RRDB to store physiological data. Referring toFIG. 5A, an embodiment of aprocess500A for providing physiological data to an RRDB is shown. In one embodiment, theprocess500A may be implemented by any of the MMS's described above (e.g., theMMS120 or220). In particular, theprocess500A may be implemented by theRRDB management module223 ofFIG. 2. Alternatively, at least some of the blocks may be implemented by theRRDB module244 of thepatient monitor240. Advantageously, in certain embodiments, theprocess500A enables RRDB files to be created for patient monitors that communicate with a MMS over a clinical network.
• Atblock502, 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.
• Atblock504, 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 theMMS120 or220. 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.
• An RRDB file with a header having the identified parameter descriptors is created atblock506. An example of a header for an RRDB file is described above with respect toFIG. 4. The parameter descriptors may be inserted, for example, into the parameter list shown inFIG. 4. Thus, the parameter list for a given patient monitor may be determined by theRRDB management module223. As will be described below with respect toFIG. 5B, the parameter list may also be determined at least partly by the patient monitor.
• Atblock508, physiological data is received from the patient monitor. Atblock510, 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 toFIG. 4.
• FIG. 5B illustrates another embodiment of aprocess500B for providing physiological data to an RRDB. Thisprocess500B may be implemented by the patient monitor (e.g.,140 or240). In particular, theRRDB module244 may perform certain blocks of theprocess500B. Alternatively, at least some of the blocks may be implemented by theRRDB module244 of thepatient monitor240. Advantageously, in certain embodiments theprocess500B enables RRDB files to be dynamically created based on changing parameters monitored by the patient monitor.
• Physiological data corresponding to one or more physiological parameters of a patient are obtained atblock512. This block may be performed by themonitoring module242 described above. Atblock514, parameter descriptors are associated with the physiological data to produce associated physiological data. This association may be performed by theRRDB module244. 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 atblock516.
• 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 theprocess500A described above.
• Atdecision block518, it is determined whether different physiological parameters have been measured. If so, atblock519, different parameter descriptors are associated with the physiological data, and atblock520, the associated physiological data is again provided to the RRDB. Blocks518-520 may be implemented by theRRDB module244. As an example, suppose that the parameters measured inblock512 include SpO₂and ECG. The parameter descriptors provided inblock514 might be “SPO2” and “ECG.” If a clinician enabled an SpHb parameter measurement on the monitor atblock518, the parameter descriptors associated with the physiological data inblock519 might now include “SPO2” and “ECG” and “SPHB.”
• In response to the transmission of the new associated physiological data atblock520, 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.
• FIG. 5C illustrates an embodiment of aprocess500C for dynamically adjusting RRDB storage corresponding to a patient monitor. In one embodiment, theprocess500C may be implemented by any of the MMS's described above (e.g., theMMS120 or220). In particular, theprocess500C may be implemented by theRRDB management module223. Alternatively, at least some of the blocks may be implemented by theRRDB module244 of thepatient monitor240.
• As described above with respect toFIG. 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, theprocess500C enables additional trend data to be written to an RRDB. Thus, in certain embodiments, the RRDB may be considered an adaptive or dynamic RRDB.
• Atblock532, 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. Atblock534, 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₂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.
• Atdecision block536, it is determined whether the patient has significant acuity. If the patient has significant acuity, additional storage for RRDB data is allocated atblock538. 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, theprocess500C ends.
• FIG. 6A illustrates an embodiment of aprocess600A for journaling medical events in a journal database. In one embodiment, theprocess600A may be implemented by any of the MMS's described above (e.g., theMMS120 or220). In particular, theprocess600A may be implemented by thejournal management module225. Alternatively, at least some of the blocks may be implemented by thejournal modules236,246. Advantageously, in certain embodiments, theprocess600A facilitates the generation of reports based on the journaled data.
• Atblock602, medical events are journaled in a journal database. In response to requests for report from a user (e.g., a clinician), atblock604 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.
• A report is generated atblock606 regarding the medical event statistics. Atblock608, 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.
• FIG. 6B illustrates an embodiment of aprocess600B for correlating data from a journal database and an RRDB. In one embodiment, theprocess600B may be implemented by any of the MMS's described above (e.g., theMMS120 or220). In particular, theprocess600B may be implemented by theRRDB module223 andjournal management module225. Alternatively, at least some of the blocks may be implemented by theRRDB module244 andjournal modules236,246. Advantageously, in certain embodiments, theprocess600B 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.
• Atblock602, 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₂dropped below safe levels.
• Atblock604, journaled data is retrieved for the specified period of time from a journal database. This block may be performed by thejournal management module225. Atblock606, physiological data for the specified period of time is retrieved from an RRDB. This block may be performed by theRRDB management module223. The journal data is correlated with the physiological data with respect to time atblock608. 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 theRRDB management module223 and thejournal management module225, timestamps in eachdatabase222,224 may be synchronized when the data is stored.
• The correlated data is output for presentation to the user at block610. 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.
• FIG. 7 illustrates an example graphical user interface (GUI)700 for monitoring patients. TheGUI700 can be provided on a nurses' station system or the like. TheGUI700 can also be displayed on a clinician device.
• TheGUI700 includes several display areas. In the depicted embodiment, theGUI700 includes a patientstatus display area710. The patientstatus display area710 shows the status of multiple patients in a hospital or other clinical location. In an embodiment, patientstatus display area710 depicts patient status for patients in a hospital department. Advantageously, in certain embodiments, the patientstatus display area710 provides an “at-a-glance” view of multiple patients' health status.
• The patientstatus display area710 includes a plurality ofpatient status modules712. Eachpatient status module712 can correspond to a patient monitor that can be coupled to a medical patient. Eachpatient status module712 can display agraphical status indicator714. An examplegraphical status indicator714 is shown in thescreens700 as a miniature patient monitor icon. Thegraphical status indicator714 can selectively indicate one of several states of a patient monitor. In one embodiment, four possible patient monitor states can be depicted by thegraphical status indicator714. These include an alarm condition, a no alarm condition, patient context information status, and connection status.
• In various implementations, thegraphical status indicator714 changes color, shape, or the like to indicate one of the different patient monitor states. For example, if an alarm condition is present, thegraphical status indicator714 could turn red to signify the alarm. If there is no context information available for the patient (seeFIG. 1), then thegraphical status indicator714 could turn yellow. If the device is not connected to the patient or the network, then thegraphical status indicator714 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 thegraphical status indicator714 could turn green. Many other colors, symbols, and/or shapes could be used in place of or in combination with the above-described embodiments.
• Advantageously, thegraphical status indicator714 shows at a glance the status of a patient monitor. Thus, in the patientstatus display area710, severalgraphical status indicators714 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.
• 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 thegraphical status indicator714 indicates an alarm condition, this alarm condition can stand out and be immediately recognized by the clinician.
• Moreover, thegraphical status indicator714 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 thescreens700, a nurse need not interpret any waveforms or changing parameters of the patient, but instead can rely on thegraphical status indicator714 that indicates the presence of an alarm.
• In certain embodiments, thepatient status modules712 can be selected by a single mouse click or the like. Selecting apatient status module712 in one embodiment can bring up a patientmonitor view area720. The patientmonitor view area720 shows a view of a patient monitor corresponding to a selectedpatient status module712. In certain implementations, the patientmonitor view area720 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 patientmonitor view area720 is currently receiving physiological information from a patient.
• Ahistory view area730 in certain implementations can show medical event data corresponding to a selected patientmonitor status module712. This medical event data can be obtained from a journal database for inclusion in theGUI700. Thehistorical view730 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, thehistory view area730 can also be configured to show trend data obtained from an RRDB instead of, or in addition to, the journaled data.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.

Claims (20)

What is claimed is:

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 ofclaim 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 ofclaim 1, wherein the second device event comprises an alarm.

4. The method ofclaim 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 ofclaim 4, wherein obtaining medical statistics about the medical events comprises accessing a selected event counter.

6. The method ofclaim 4, wherein generating the report comprises generating a monitoring report card.

7. The method ofclaim 4, wherein generating the report comprises comparing alarm response times among clinicians.

8. The method ofclaim 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 ofclaim 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 ofclaim 9, wherein the second device event comprises an alarm.

12. The system ofclaim 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 ofclaim 12, wherein obtaining medical statistics about the medical events comprises accessing a selected event counter.

14. The system ofclaim 12, wherein generating the report comprises generating a monitoring report card.

15. The system ofclaim 12, wherein generating the report comprises comparing alarm response times among clinicians.

16. The system ofclaim 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 ofclaim 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 ofclaim 17, wherein the report comprises statistics regarding alarm response times among clinicians.

20. The system ofclaim 17, wherein the report comprises statistics regarding alarm response times among hospitals.

Images