Patent ID: 12238489

DETAILED DESCRIPTION

I. Introduction

Alarm reliability is a critical requirement for patient monitors employed in healthcare. An alarm failure may result in patient injury or death. A robust alarm system can provide at least one of redundant alarms, drive circuit integrity checks, or alarm integrity checks to increase alarm reliability. An example approach for addressing alarm reliability is described in U.S. Pat. No. 7,962,188, filed Oct. 12, 2006, titled “Robust Alarm System” (“the '188 patent”), the disclosure of which is hereby incorporated by reference in its entirety.

Many modern patient monitors are portable and may be used in vehicles, such as ambulances and medical helicopters. However, when used in a vehicle, the patient monitor may be inserted into a portion of the vehicle such that the monitor's speaker is blocked, muffling or muting any alarms. Or, the speaker may not be blocked, but the volume may be turned down such that alarm sounds cannot be heard above the noise of the vehicle. Further, the acoustic environment of the vehicle (or any location the monitor is installed) may reflect the alarm sounds in such a manner that destructive interference acts as an unintentional echo cancellation-reducing the alarm volume. Similar problems may occur in a hospital or other clinical setting, for instance, where the monitor is placed in a stack of monitors that may block the monitor's speaker, or where other hospital sounds drown out the alarm sound. Likewise, a wearable patient monitor (for example, on an armband) may become blocked by linens or pillows on the patient's bed, muffling alarms. Any speaker may also malfunction, causing a reduction in its volume output.

To attempt to address these problems, the monitor can diagnose whether its speaker is blocked or otherwise malfunctioning (or at a too-low volume) and can output a visual and/or audible indication of this error. For example, the monitor can include a processor that can diagnose the speaker by recording a microphone input signal. The processor can compare the microphone input signal to an expected alarm signal that should be output by the speaker and/or to the actual alarm signal sent to the speaker. If the two do not match or reasonably correspond to one another, then the processor may increase the volume of the alarm to determine whether doing so can overcome an obstruction, noise, or potential malfunction. The microphone can again detect the speaker output, and the processor can again perform another analysis of the speaker output. If the speaker output as detected via the microphone is still insufficiently loud, then the processor may cause the display of the monitor to output an error or an indication that the speaker has a problem. The processor can also transmit the error over a network to a remote server for distribution to other clinician or technician devices. Further, the processor can cause a second speaker, such as a piezoelectric buzzer, to output an audible alarm.

II. Example Patient Monitors

FIGS.1through4depict an example patient monitoring system100, including an example bedside/portable patient monitor102, which can implement the speaker obstruction detection algorithms described herein.FIG.4Bdepicts another example patient monitoring system400, including an example wearable monitor450, which can also implement the speaker obstruction detection algorithms described herein.

Referring specifically toFIG.1, the example patient monitoring system100includes an example bedside/portable patient monitor102and example sensor(s)142. The patient monitor102, sometimes referred to as a point-of-care device, includes one or more ports118,120for communicating with one or more sensors through sensor cables134,136, respectively. When the sensor(s) are coupled with a patient, the patient monitor102can analyze signals obtained from the sensor(s) to measure one or more of the patient's physiological parameters. The patient monitor102includes a display122for displaying the measured parameters. The patient monitor102can also include one or more speakers, buzzers, or the like (see, for example,FIGS.2-4) that outputs audible alarms when a patient's physiological parameters reach dangerous levels or when other errors occur, such as a sensor falling off the patient.

Algorithms for detecting obstructed or malfunctioning speakers (also called loudspeakers), using an input detected by a microphone132(shown in one example location of many possible locations on the patient monitor102), are described in detail below with respect toFIGS.5-8. Example block diagrams of the patient monitor's102internal systems that can detect an obstructed or malfunctioning speaker are described below with respect toFIGS.9-12.

The port118can enable communicating with a blood pressure sensor142, such as a non-invasive blood pressure (NIBP) cuff. The port120can couple with a sensor (not shown) that can measure at least one of the following physiological parameters: oxygen saturation (SpO2), pulse rate (PR), perfusion index (PI), total hemoglobin (SpHb®), methemoglobin (SpMet®), carboxyhemoglobin (SpCO®), oxygen content (SpOC®), oxygen reserve index (ORi®), pleth variability index (PVi®), acoustic respiration rate (RRa®), respiration rate from pleth (RRp™), fractional arterial oxygen (SpfO2™), rainbow Pleth Variability Index (RPVi™), or signal quality. In addition or alternatively, the patient monitor102can include a port for communicating with a capnography sensor (for example, a CO2sensor) so as to measure or determine parameters such as end-tidal carbon dioxide (etCO2), SpO2, Predictive or Temporal Artery Temperature, Masimo Rainbow® parameters (for example, RRa™, SpCO®, PVi®), electrocardiogram (ECG) (3-lead or other number of leads), combinations of the same, and the like. The patient monitor102can include a port (in addition to or alternative to those shown) for communicating with a biopotential sensor, a respiratory rate sensor, or a glucose sensor. In some cases, the patient monitor102can wirelessly communicate with sensor modules such as a blood pressure module, a pulse oximetry module, or a capnography module. Either port118,120can be optional and may be omitted.

The patient monitor102can also serve as a connectivity hub for multiple third-party or proprietary devices (collectively referred to as remote modules114). For example, the patient monitor can wired or wirelessly, for instance via Bluetooth, aggregate data from each of a plurality of remote modules114. The patient monitor102can communicate with or integrate data from one or more devices such as a weight scale, glucometer, spirometer, stethoscope, a capnograph (such as the EMMA™ Capnograph marketed and sold by Masimo Corporation of Irvine CA (“Masimo”)), a thermometer (such as the Caregiver marketed and sold by Masimo), a hemoglobin sensor (such as the Rainbow® DCI®-mini marketed and sold by Masimo), or a pulse oximeter (such as the MightySat™ Rx marketed and sold by Masimo), combinations of the same, or the like. If implemented as a monitoring hub, the patient monitor102can include any of the features described in U.S. Pat. No. 9,943,269, filed Oct. 10, 2014, titled “System for Displaying Medical Monitoring Data”, the disclosure of which is hereby incorporated by reference in its entirety. Further, the patient monitor102may be battery powered or externally powered.

The display122of the patient monitor102can include touch screen capabilities. For example, a user can adjust a range of a displayed trend time by using intuitive finger gesture (for example, dragging, pinching, or spreading fingers). Further, the display122can be customizable such that a user can choose which information to display on the display122. For example, the user can choose to display one or more of various waveforms, trends, values, timelines, or other data related to a patient's physiological parameters. The user can also customize the display using touchscreen input or optionally by menu-driven commands.

In some cases, the display122can display in portrait mode or landscape mode and can transition between display modes, for example, based on the orientation of the monitor102. For example, the patient monitor can determine its orientation using a gyroscope or an accelerometer. Based on its determined orientation, the patient monitor102can display in landscape or portrait mode. In some cases, the display122can display in portrait mode when oriented vertically and can display in landscape mode when oriented horizontally. In some cases, a user can select landscape or portrait mode, which can cause the display122to lock the display122in the selected mode despite the orientation of the patient monitor102.

In operation, the patient monitor102can receive a sensor signal associated with a sensor. Depending on the sensor, the patient monitor102can provide one or more drive signals to the sensor. The patient monitor102can receive (through wired or wireless connection) the sensor signal and can determines a conditioned signal. The conditioned signal may be transmitted or further processed by a signal processor, such as by buffering, digital filtering, smoothing, averaging, adaptive filtering, frequency transforms, or the like. The signal processor can derive a physiological parameter value responsive to the sensor signal. The resulting physiological parameter value may be a measurement calculated or derived from the conditioned signal, such as any of the physiological parameter values referred to above.

FIG.2depicts an example side perspective view of the patient monitor102ofFIG.1. Among other features, the patient monitor102can include a vent cover101and a speaker grill210. The vent cover101is shown in an open position inFIG.2and in a closed position inFIG.1. The vent cover101can cover one or more ventilation holes203without occluding the ventilation hole(s) and also can provide a stabilization feature to the patient monitor102. The vent cover101can swivel (for example, when rotated by a user) between various configurations (such as the closed and open positions shown inFIGS.1and2, respectively). For instance, in a storage configuration, the vent cover101can fit within indentions of housing of the patient monitor102such that an outer surface of the vent cover101is at least partially flush with an outer surface of the housing. In a stabilizing configuration, the vent cover101(and a protrusion111) can provide support to the patient monitor102when oriented in an upright position.

The speaker grill210is disposed on the top side of the patient monitor102in the depicted example. The speaker grill210can act as a protective cover and opening through which a speaker beneath the grill210may emit alarm sounds and other sounds. An example of such a speaker is described below with respect toFIG.4. Placing the speaker grill210on the upper surface of the monitor102as shown can permit the front of the patient monitor102to be smaller in size and have cleaner lines. The placement of the speaker grill210can also permit the display of the patient monitor102to be larger with a smaller monitor form factor, which can increase the portability of the patient monitor102.

Having a larger display in a smaller device can be beneficial for telemedicine applications where the display can show video of the patient or of a doctor. Also having a larger display in a smaller form factor can provide more information about different physiological parameters, including more parameter values, trends, and/or waveforms.

However, in this and other scenarios, as described above, a speaker may become obstructed, drowned out by noise, or otherwise malfunction. For example, the patient monitor102may be inserted into a portion of a vehicle such that the speaker grill210is blocked, obstructing the sound of any alarm that is emitted by the speaker. A similar effect may occur in a hospital or other clinical setting, for instance, where the monitor102is in a stack of monitors and a monitor above it may block the speaker grill210.

To attempt to address these problems, the monitor102can diagnose whether its speaker is blocked or otherwise malfunctioning and can output a visual indication of this error. For example, the monitor102can include a processor that can diagnose the speaker by recording a microphone input signal using, for example, the microphone132ofFIG.1. The processor can compare the microphone input signal to an expected alarm signal that should be output by the speaker. If the two do not match or reasonably correspond to one another, then the processor may increase the volume of the alarm to determine whether doing so can overcome an obstruction, noise, or potential malfunction. The microphone132can again detect the speaker output and the processor can again make another comparison or analysis of the input with the speaker output. If the speaker output as detected via the microphone is still insufficiently loud, then the processor may cause the display of the monitor102to output an error or an indication that the speaker has a problem. The processor can also transmit the error over a network to a remote server for distribution to other clinician devices.

Although the monitor102is used herein as an example of a patient monitor that can include speaker diagnosis features, the speaker diagnosis features described herein can be implemented with any other type of patient monitor. Some other monitors, for instance, may have a speaker located in a position other than is shown inFIG.2, such as on the front or the side or the bottom of the monitor.

Turning toFIG.3, an example exploded view of the patient monitor102is shown. In this view, the housing106of the patient monitor102is shown separated into two distinct parts. In particular, the housing106is shown including a separate upper housing340and a lower housing330. The upper housing320includes the speaker grill210described above with respect toFIG.2. The lower housing330includes a circuit board340that can include electronic components, such as a hardware processor that can process one or more algorithms for speaker diagnostics discussed herein.

Turning toFIG.4, the upper housing320ofFIG.3is shown except that it is flipped over to reveal its underside, including the underside of the speaker grill210. A speaker410is also shown in an exploded view apart from the upper housing320. The speaker housing410can rest on a raised ridge420that encircles the speaker grill210.

Although a single speaker is shown inFIG.4, there may be multiple speakers in the patient monitor102. For example, there may be two speakers, one of which is redundant to the other so that if one fails, the other continues to operate. Redundant speakers in this manner can continue to provide reliable alarms despite the failure of one speaker.

FIG.4Bdepicts another example patient monitoring system400, including an example wearable monitor450, which can also implement the speaker obstruction detection algorithms described herein. The example wireless monitor450is shown secured to the arm of the patient. The wireless monitor450can be a fully functional stand-alone monitor capable of various physiological measurements. The wireless monitor can be small and light enough to comfortably be secured to and carried around on the arm of a patient. As shown, the example wireless monitor450connects to an acoustic respiration sensor404A on a first side of patient monitor450and an oximeter sensor402on a second side of patient monitor450. This configuration of connected sensors to opposite sides of the monitor can reduce cable clutter and entanglements. The wireless monitor450includes a screen454(which may be omitted in other implementations). The wireless monitor450can couple to and can be held to the arm of the patient by arm band452, although other attachment mechanisms (such as a pocket or adhesive) are possible. The arm band452may, but need not, be an inflatable blood pressure cuff.

The wireless monitor450can be a standalone patient monitor, or it can wirelessly (or wired) transmit data to a bedside monitor using any of a variety of wireless technologies, such as Wi-Fi (802.11x), Bluetooth (802.15.2), cellular telephony, infrared, RFID, or the like.

Although not shown, the wireless monitor450can also have a speaker for outputting audible alarms.

III. Example Alarm Testing Algorithms

Turning toFIG.5, an example speaker error detection process500is shown, which is an example of the speaker diagnosis techniques described above. The speaker error detection process500can detect an error in a speaker, including an obstruction, partial obstruction, or malfunction of the speaker. The speaker error detection process500can be performed by a processor of the patient monitor102(or by the system ofFIGS.9through12, described below, which depict example schematic components of a patient monitor).

At block502, the processor receives a microphone input signal when an alarm is triggered. The alarm may have been triggered by the processor detecting that a patient's physiological parameter (or parameters) have exceeded safe limits (such as low SpO2). The microphone input signal may be received from the microphone132. The microphone input signal may be recorded in memory (for example, in a buffer) prior to further processing, or the signal may be processed in real time, as it is received.

At block504, the processor detects (or attempts to detect) an alarm in the microphone input signal. This detection can include using one or more signal processing techniques to extract an alarm signal from the microphone input signal. Of course, it is possible that the processor may not be able to extract an alarm from the microphone input signal if the speaker is fully obstructed or malfunctioning.

It may or may not be a straightforward operation to obtain or detect the alarm in the microphone input signal. This is because the patient monitor102may be located in a noisy environment. Some examples of noisy environments that the patient monitor may be located in include a hospital room, an ambulance, or a helicopter. Because of the noise that may be inherent in such environments, it may be difficult to distinguish whether the speaker is functioning properly or whether noise is drowning out or otherwise muddling the alarm signal.

Accordingly, the signal extraction technique employed at block504can include filtering. For example, filtering may be employed to look in expected bands of the microphone input signal for identifiable portions of the alarm signal. Filtering may be performed using low pass, band pass, notch, or high pass filters or some combination of the same, such as a filter bank. Another technique that may be used includes cross correlation of an output alarm signal sent to the speaker with the microphone input signal. Further, statistical approaches, noise reduction filtering, envelope detection, smoothing, comb filtering, or harmonic comb filtering may also be performed.

Many alarm signals may have a plurality of beeps in a pulse train which may be detectable in the time domain. Thus, the detection of the alarm input in the microphone input signal could also involve performing time domain analysis, such as searching for a pulse train of beeps.

At block506, the processor compares the detected (purported) alarm signal with one or more alarm output criteria and determines whether the one or more alarm output criteria have been met. The alarm output criteria can include one or more rules, processes, or techniques for analyzing the detected alarm in the microphone input signal. In general, the closer that the detected alarm characteristics match one or more desired alarm characteristics, the more likely the detected alarm is a suitable alarm. If the detected alarm (or purported alarm) does not match the alarm criteria, it is possible that the speaker is blocked or otherwise malfunctioning.

The alarm output criteria may specify, for instance, that a detected (purported) alarm having a volume, loudness, or magnitude lower than a certain threshold may indicate a possible obstruction or speaker malfunction. The alarm output criteria can be evaluated using time domain and/or frequency domain techniques. Some example time domain techniques can include analyzing the magnitudes of pulses in a train of pulses to determine whether those magnitudes are greater than a threshold. Further, another example time domain technique can include analyzing the number of pulses in a pulse train to confirm the correct number of beeps is being reproduced. Example frequency domain techniques can include analyzing magnitudes of spectral peaks, performing cross-correlations, and so forth (see, for example,FIGS.6-8B).

Further, time domain and frequency domain analysis can be performed together by obtaining a spectrogram of frequency spectra corresponding to the detected alarm signal over time. This spectrogram can be constructed with the short time Fourier transform (STFT) or another transform (additional examples of which are described with respect toFIG.6below).

With continued reference toFIG.5, if the alarm output criteria has been met, then the process500ends because the speaker can be determined to be functioning correctly. However, if the alarm output criteria is not met, then at block508the processor can determine whether a maximum volume of the speaker has been reached. If not, then at block510, the processor can increase the volume that is applied to the alarm signal. The alarm volume may be increased at block510in increments, or the alarm volume may be increased at block510to maximum volume immediately. A possible advantage of increasing the volume in increments may be avoiding startling a user who may not be expecting a large change in volume. Conversely, a possible advantage of increasing the volume to the maximum volume right away may be that the problem with the speaker (if there is one) may be detected more quickly. After increasing the alarm volume, the process500can loop back to block504and again detect an alarm in the microphone input signal and again evaluate whether the detected alarm meets one or more alarm output criteria (block506).

Blocks504through510may thus continue in a loop until a maximum volume is reached. If the maximum volume is reached without the one or more alarm output criteria being met, then at block512the processor can output a speaker obstructed or malfunctioning error message on the display of the patient monitor. This message can also be output to a remote server, for example, as a notification or escalation.

Turning toFIG.6, an example frequency domain alarm analyzer600is shown. The alarm analyzer600can be implemented by the processor described herein, or more generally, by any patient monitor. Many alarms may be just a single tone, such as a sine wave played at a specific frequency through a speaker. The frequency domain alarm analyzer600represents one example way to detect an alarm that includes a single tone. Other example analyzers for analyzing multiple alarm tones are described below with respect toFIGS.7-8B.

The single tone alarm analyzer600can receive a microphone input602. The microphone input can be received from the microphone132ofFIG.1. A switch610can determine whether the microphone input is received for processing or is not received. The switch610can be logical, implemented in software, or it can be an actual switch in hardware. For example, if the switch is logical, the ADC630can be placed before the switch610.

The switch610may be actuated by an alarm trigger612. The alarm trigger612can be triggered whenever the processor (or software running in the processor) determines that an alarm condition is present, such as low SpO2. When the alarm trigger612occurs, two things can happen either at the same time or substantially the same time, or one right after the other. The alarm trigger612can cause a tone generator620to output an alarm tone, which may be a waveform corresponding to the alarm sound. The output of the tone generator620can be provided to a gain block670, which can apply a gain to the tone generated by the tone generator620. The gain can be a volume setting (or can be proportional to a volume setting) of the alarm. The output of the gain block670can be an alarm signal that can be provided to a speaker as a speaker output604.

The alarm trigger612, in addition to triggering the generation of an alarm to be output to the speaker, can also generate a signal or logical code that causes the logical switch610to receive the microphone input signal602. Thus, the microphone may be recording when the alarm is sounded but not at other times. An analog to digital converter (ADC)630can receive the microphone input signal and convert the analog microphone input signal to a digital input signal including, for example, by performing preamplification and sampling. The output of the ADC630may be a digital signal that can be supplied to an FFT (Fast Fourier Transform) block640.

The FFT block640can perform a mathematical transform, the FFT, on the digital signal to convert the digital signal from a time domain representation to a frequency domain representation. Other types of transforms may be used instead of or in addition to the FFT, such as the short time Fourier transform (STFT) (which may be implemented by the FFT), a wavelet transform, or the Hilbert-Huang transform. However, the FFT block640can be optional, and instead of performing alarm tone detection in the frequency domain, alarm tone detection can be performed in the time domain (see, for example,FIG.8). Alternatively, alarm tone detection may be performed in a combination of the time domain and the frequency domain (see, for example,FIG.8B). For illustration purposes, the remainder of the specification focuses primarily on frequency domain techniques.

The output of the FFT block640can be a frequency domain representation of the microphone input signal, which is supplied to an alarm tone detector650. There are many different ways to implement detection of an alarm signal, and thus the examples shown inFIG.6(and subsequent Figures) are non-limiting examples of ways to detect the alarm signal. The example alarm tone detector650shown includes a band pass filter652, a peak magnitude finder658, and a threshold detector659.

The band pass filter652may have a center frequency f0that is at the expected location of the alarm tone in the frequency domain representation of the microphone input signal. The band pass filter652may optionally be tuned with a high Q-factor such that the band pass filter is very narrow in bandwidth, so as to focus on a small amount of frequency content around the center frequency of the band pass filter. Since a single tone alarm may have its energy concentrated at or around one frequency, a narrow bandpass filter can focus on that frequency and optionally a small amount of surrounding frequencies. The band pass filter652is optional and may be omitted.

The peak magnitude finder658can identify the magnitude of the peak. The threshold detector659can compare the peak with the threshold to determine whether the peak has a magnitude greater than a threshold.

The speaker error analyzer660can essentially perform blocks506through510of the process500after the alarm tone detector650has performed block504of the process500. For instance, the speaker error analyzer660can determine whether one or more alarm output criteria are met as described above with respect toFIG.5, for example, by determining whether the peak exceeded the threshold and therefore likely corresponds to a sufficiently loud alarm. If not, the speaker error analyzer660can determine whether a maximum volume has been reached, and if not, can increase the volume by outputting an instruction to the gain block670to increase the gain. The tone generator620input to the gain block670—the alarm waveform—can then be amplified further to attempt to detect an alarm sound with the alarm tone detector650.

If the speaker error analyzer660determines that the maximum volume has been reached without the alarm output criteria being met, then the speaker error analyzer660can provide an error output608. The error may indicate that the speaker has been obstructed, or it may be malfunctioning or have some other error. The error output608can be textual in nature or it can be a graphical display or icon, such as an icon depicting a speaker with a line through it in red (potentially flashing) or the like. The error output608may also be a remote notification that the speaker error analyzer660causes to be provided to a remote server so that clinicians can access the information about the error remotely, and so that if a clinician does not respond based on the error then the remote server can cause the error to be escalated as a new alarm to other clinicians or to a technician who can repair the speaker. Further, the error output608may be an audible sound transmitted through a backup speaker installed in the patient monitor, which may be a piezoelectric buzzer or the like.

As described above, there may be a variety of alarm output criteria that the speaker error analyzer660uses either in the time domain or the frequency domain. In this example, the peak magnitude is supplied to the speaker error analyzer660by the peak magnitude finder658. The speaker error analyzer660can analyze the threshold output from the threshold block659. If the peak magnitude meets or exceeds the threshold, the speaker error analyzer660can indicate that the speaker is functioning properly and not increase the gain at the gain block670. Conversely, if the peak magnitude is below the threshold, the speaker error analyzer660can output that the speaker is not functioning properly (at block608) and increase the gain at the gain block670.

In some instances, the speaker error analyzer660can output a more granular indication of a problem (at block608). For instance, the speaker error analyzer660may be able to indicate that the speaker is partially blocked rather than completely blocked. The speaker error analyzer660may determine partial blockage by determining that the peak magnitude received from the peak magnitude finder658is between two thresholds but not so low as to indicate blockage. Other variations are possible.

Turning toFIG.7, another example frequency domain alarm analyzer700is shown. Many alarm signals have harmonics, including alarm signals that are formatted according to certain industry standards, an example of which is described below with respect toFIG.13. The frequency domain alarm analyzer700incorporates much of the functionality of the frequency domain alarm analyzer600ofFIG.6and adds additional functionality to detect multiple harmonic tones.

For instance, a microphone input602can be received. A switch610can selectively supply the microphone input signal602to an ADC630, which can supply a digital signal to an FFT640. (Alternatively, the ADC630can be placed before the switch610, and the switch610may be logical—implemented in software.) The FFT640can output a spectrum to an alarm detector750, which can include features of the alarm detector650but in multiple signal paths. For instance, instead of a single band pass filter, a band pass filter bank752can be used. The band pass filter bank752can be find a fundamental frequency and harmonics of a harmonic alarm signal, or more generally, multiple expected peaks in the signal. Three signal paths are shown, but ellipses indicate that any number of signal paths may be used, including four or more.

The remaining blocks754through758can have the same or similar functionality as the corresponding blocks inFIG.6for the fundamental and each harmonic (note: the fundamental is also sometimes called the first harmonic). For example, the result of the alarm detector750can be that the peak magnitude can be found and thresholded for each fundamental and harmonic in the microphone input signal.

The speaker error analyzer660can analyze the outputs of the peak threshold blocks759and can perform similar criteria as inFIG.6but with multiple tones. For example, the speaker error analyzer660can determine whether each of the peaks is lower than a low threshold (indicating possible full obstruction) or between the low threshold and a higher threshold (indicating a possible partial obstruction). However, other criteria may be used with multiple peaks. For instance, the speaker error analyzer660can compare the relative magnitudes of the peaks. If the peaks are above a threshold, but their relative magnitudes differ too greatly, then the speaker nevertheless may be muffled or garbled due to an obstruction or partial obstruction. For instance, if a speaker is blocked then the higher frequency harmonics are more likely to be attenuated than lower frequency harmonics (including the fundamental frequency). Thus, identifying attenuated higher frequencies can suggest that the speaker is blocked or partially blocked.

If there is little or no evidence of spectral peaks, or if their magnitudes are very small, then the speaker may be malfunctioning. But it may be easier to determine a malfunctioning harmonic alarm versus a malfunctioning single tone alarm. A single tone alarm may be mimicked by noise, but when there are multiple harmonics, it can be more difficult to mimic all of the harmonics with noise. Thus, the speaker error analyzer660may be able to determine whether the speaker is malfunctioning versus obstructed by simply detecting whether there are actual harmonics of the fundamental frequency. Absent harmonics of the fundamental, it is more likely that the speaker is malfunctioning versus merely obstructed. Likewise, if the fundamental is not present but one or two harmonics are present, then that can also suggest that the speaker may be malfunctioning as opposed to being muffled. The speaker error analyzer660can output an appropriate error608accordingly, which may be the same as described above with respect toFIG.6. Other components shown can have the same or similar functionality as described above with respect toFIG.6.

Turning toFIG.8, another example alarm analyzer800is shown. The alarm analyzer800is an example time domain alarm analyzer. The time domain alarm analyzer800can be used to detect single or multiple tone alarms or more complex alarms that may have multiple characteristics including changing frequencies, changing magnitudes and so forth. The time domain alarm analyzer800differs in some respects from the previous alarm analyzers but can include similar components.

The output of the ADC630can be supplied to a correlation block854. The correlation block854can perform a correlation comparison (such as a cross correlation or autocorrelation) of the microphone recorded signal with the output signal sent to the speaker from the tone generator620. Doing so may create a correlation output signal that can be analyzed by a threshold detector858. The threshold detector858can determine whether the correlation between the input signal's alarm and the output signal are sufficiently correlated. For example, the threshold detector858can determine whether a highest peak in the correlation output exceeds a threshold, or the threshold detector858can search for predetermined patterns in the correlation output. Many other pattern matching algorithms are possible besides threshold detection, including algorithms that detect patterns in a spectrogram, clustering algorithms, linear prediction, and the like.

If the detected alarm is sufficiently correlated with the output alarm, then the speaker error analyzer660may determine that there is no error. If not, the speaker error analyzer660may determine that there is an error and perform according to the processes and examples previously provided, adjusting the gain670and/or outputting the error608.

FIG.8Bdepicts an example dual algorithm alarm analyzer890. The example dual alarm analyzer890includes both a frequency domain alarm detector650and a time domain alarm detector850. These detectors650,850can work as described above with respect toFIGS.6-8. The output of these detectors can be provided to the speaker error analyzer660. The speaker error analyzer660can use decision logic to determine whether to output an error608and/or adjust the gain670based on the output of both detectors650,850. For example, the decision logic may determine that if either detector output is below a threshold or otherwise indicates the alarm to be low volume, the speaker error analyzer660can determine that an error has occurred and perform the functions of the process500, blocks506through512. Or, the speaker error analyzer660can determine that an error has occurred only if both the detectors650,850output errors (for example, output below-threshold outputs as described above).

IV. Example Patient Monitor Block Diagrams

FIG.9illustrates an example block diagram of a pulse oximetry system900that can implement these alarm reliability features. The oximetry system900includes a patient monitor902, which is a schematic example of the patient monitor102(but which can also be used in another type of patient monitor). The pulse oximetry system900can measure the oxygen saturation level of arterial blood, an indicator of oxygen supply, as well as any of the other physiological parameters discussed herein. The pulse oximetry system900also includes a sensor901that can provide a sensor signal962to a pulse oximeter902. The sensor901has emitters910and a detector920and can be attached to a patient at a selected tissue site, such as a fingertip, foot, forehead, or earlobe. The emitters910can transmit light having red and IR wavelengths into the tissue site. The detector920can generate the sensor signal962in response to the intensity of the emitter-transmitted light after attenuation by pulsatile blood flow within the tissue site. An example pulse oximetry sensor, which can be used as the sensor901, is described in U.S. Pat. No. 6,088,607, filed Jan. 28, 1997, entitled Low Noise Optical Probe, the disclosure of which is hereby incorporated by reference in its entirety.

The monitor902includes drivers940, a controller950, and a front-end960. The drivers940can activate the emitters910according to the controller950, and the front-end960can condition and digitize the resulting sensor signal962. The monitor902also has a hardware processor970, a display980, and a robust alarm system990. The processor970can be a central processing unit (CPU), a digital signal processor (DSP), or a graphics processing unit (GPU), which can input the conditioned and digitized sensor signal964and calculate oxygen saturation along with pulse rate or other physiological parameters described herein. (Additional examples of types of processors that may correspond to the processor970are described below.) The display980can provide a numerical readout of a patient's oxygen saturation and pulse rate, as well as trends or waveforms. The robust alarm system990can provide an audible indication when oxygen saturation or other physiological parameters are outside of preset limits, as well as self-monitor the health of the alarm system990. An example pulse oximeter or patient monitor, which can be used as the patient monitor902, is described in U.S. Pat. No. 8,942,777, filed May 25, 2007, entitled Signal Processing Apparatus, which is assigned to Masimo Corporation, Irvine, CA, the disclosure of which is hereby incorporated by reference in its entirety.

FIG.10illustrates a pulse oximetry system1000having a robust alarm system1100. The pulse oximetry system1000has a hardware processor1010responsive to an input sensor signal1012and a display1020for presenting the results. For example, the processor1010may be part of a patient monitor that is responsive to an intensity signal from an optical sensor, such as the patient monitor102or902described above. The processor1010can have any of the characteristics of the processor970or other processors described herein. Unlike a conventional alarm, however, the robust alarm system1100can have redundant alarms and alarm system integrity checks, as described above and in additional detail below.

As shown inFIG.10, the signal processor1010can input the sensor signal1012and generates an alarm trigger1014in response, such as when a parameter calculated by the signal processor is outside of predetermined limits. The alarm system1100inputs the alarm trigger signal1014and can activate one or more alarms accordingly, as described below. The alarm system1100can also output a malfunction signal1016, which can indicate that one or more alarm subsystems1101-1103are unresponsive, for example are not generating an alarm in response to the alarm trigger1014. The malfunction signal1016can be output to the signal processor1010, which may trigger a malfunction indication on the display1020or trigger a separate malfunction indicator1030, or both. The malfunction signal1016can also be output directly to the malfunction indicator1030. The malfunction indicator1030may be an audible alert, visual alert or alert signal. An audible alert, for example, may be an alarm, buzzer, recorded or synthesized voice to name a few. A visual alert may be a flashing light or display message, for example. An alert signal may be, for instance, an electronic signal, code or message sent to another system via wired or wireless communication channels, or local area or wide area networks, to name a few.

Also shown inFIG.10, the example robust alarm system1100has an alarm controller1110and one or more alarm subsystems1101-1103. The alarm controller1110can input the alarm trigger1110and can activate an alarm subsystem1101-1103or multiple alarm subsystems concurrently. The alarm controller1110can also receive a subsystem function signal1105that provides feedback to the alarm controller1110as to the integrity of the alarm subsystems1101-1103. The subsystem function signal1105can include circuit function signals1132(FIG.11) or alarm function signals1152(FIG.11) or both, as described with respect toFIG.11, below.

The alarm controller1110can generate the malfunction signal1016if alarm subsystem integrity has been compromised. The malfunction signal1016can be encoded or otherwise configured so as to indicate a particular fault type or fault location or both. The fault location may be subsystem, component, or subcomponent specific. The alarm controller1110may activate or deactivate one or more alarm subsystems1101-1103in response to the subsystem function signal1105so as to work around one or more faulty alarm subsystems1101-1103. In various embodiments, the alarm controller1110may include separate hardware, software, or firmware components or may be integrated with the signal processor1010.

Further shown inFIG.10, the robust alarm system1100can be configured for various self-testing, fault correction and alarm condition response. In monitors having two speakers instead of one, two or more alarm subsystems1101-1103can be concurrently activated so that multiple alarms sound simultaneously and so that failure of any one alarm or alarm subsystem1101-1103will not result in silence during an alarm condition. These multiple alarms may each sound at different frequencies or frequency spectra so as to facilitate alarm failure recognition and troubleshooting. The alarm controller1110can deactivate a failing alarm subsystem1101-1103and can activate one or more redundant alarm subsystems1101-1103in response to the subsystem function signal1105. The alarm controller1110can also initiate alarm subsystem testing in the absence of an alarm condition by intermittently activating the alarm subsystems1101-1103. Intermittent test alarms may be activated only long enough for subsystem function1105feedback or at frequencies outside of a normal hearing range so as to be essentially unnoticeable by caregivers, patients or other personnel operating the pulse oximetry system1000.

FIG.11illustrates a robust alarm system1100having an alarm controller1110, drivers1120, circuit testers1130, alarms1140and detectors1150. The robust alarm system1100is an example of the robust alarm system1100and990. The alarm controller1110can respond to the alarm trigger1014(seeFIG.10) by outputting drive signals1112to one or more drivers1120so as to activate one or more of the alarms1140. The alarms1140may be any of various audible transducers, such as speakers, piezoelectric transducers, buzzers or bells to name a few.

Also shown inFIG.11, alarm detectors1150can interface with the alarms1140so as to verify the integrity of the alarm transducers. Alarm detectors1150can provide one or more alarm function signals1152to the alarm controller1110, which the alarm controller1110can use to indicate and adapt to subsystem malfunctions, as described above.

Each alarm1140can have a corresponding alarm detector1150so that the alarm controller1110can identify a specific malfunctioning alarm. The robust alarm system1100may have one alarm detector1150for multiple alarms1140that each output a unique audio frequency or frequency spectrum so as to distinguish a malfunctioning alarm. The robust alarm system1100may have one alarm detector1150for all alarms1140, where each alarm is sequentially and briefly activated during a periodic or intermittent testing procedure so as to determine the existence of any malfunctioning alarms.

A drive circuit integrity check can also be performed by the circuit testers1130, as described in the '188 patent. A combination of a drive circuit integrity check and an alarm integrity check can increase overall alarm reliability.

FIG.12illustrates an example alarm detector1150(FIG.11) that can verify alarm integrity. An acoustic sensor1250, such as a microphone (seeFIG.1), can detect sound waves1201generated by the alarm transducer1140(FIG.11), such as a loudspeaker (or speaker). An amplifier1210can generate a corresponding alarm function signal1152to the alarm controller1110(FIG.11). If the alarm1240is operative, the alarm controller1110(FIG.11) can detect a corresponding tone waveform in the alarm function signal1152upon activation of the drive signal1112(FIG.11). Otherwise, an alarm malfunction can be determined, and the alarm controller1110(FIG.11) can respond accordingly, such as by generating a malfunction signal1016(FIG.11) or activating a redundant alarm1140(FIG.11), or both.

V. Optional Medical Standards Implementation

FIG.13depicts an example spectrum1300of an alarm signal1302that may be used with any of the features described above. The spectrum1300is plotted according to frequency and sound pressure level (dB). The spectrum1300represents an example spectrum of a medical device alarm that comports with the voluntary standard defined in ANSI/AAMI/IEC 60601-1-8:2006 and A1:2012, “Medical Electrical Equipment—Part 1-8: General requirements for basic safety and essential performance-Collateral Standard: General requirements, tests and guidance for alarm systems in medical electrical equipment and medical electrical systems,” issued 2006, which is hereby incorporated by reference in its entirety. An overview of the standard and the source ofFIG.13is found in D. O'Brien, “Using Audible Alarms in Medical Equipment (IEC 60601-1-8), available from http://www.mallory-sonalert.com/Documents/Articles/Audible%20Alarms%20in%20Medical%20Equipment.pdf, last accessed on Apr. 17, 2018, which is hereby incorporated by reference in its entirety. IEC 60601-1-8 will first be described in general, and then with reference toFIG.13. Example applications of IEC 60601-1-8 to the speaker analysis features described above will then be set forth.

IEC 60601-1-8 is a comprehensive international standard that specifies basic safety and performance requirements and tests for alarm systems in medical equipment. It covers numerous topics, from what kind of medical condition should trigger an audible warning sound to the specific frequency and shape of the audible sound waveform. The IEC 60601-1-8 standard is a voluntary standard, and thus in the context of this specification, it is viewed as an optional and not exclusive implementation of alarms that can be analyzed. Thus, any requirements of IEC 60601-1-8 should be viewed as optional to this disclosure.

IEC 60601-1-8 gives guidance on whether an alarm condition should be assigned a high, medium, or low priority. This guidance is based on the potential result of a failure to respond to the cause of the alarm condition and how fast the potential harm could happen to the patient. For example, a high priority would be assigned if death or irreversible injury could happen quickly, but a low priority would be assigned if only minor injury or discomfort may happen after a period of time.

IEC 60601-1-8 includes three burst requirements (again, all IEC “requirements” are optional herein). As this term is used herein, in addition to having its ordinary meaning, a burst can essentially include a pulse train of individual sounds (for example, beep, beep, beep, pause, beep, beep beep). The three burst requirements can correspond to the three priority conditions discussed in the last section. A high priority condition burst can have 10 fast pulses that repeat, a medium priority condition burst can have 3 slightly slower pulses that repeat, and a low priority condition burst can have 1 or 2 even slower pulses that may optionally repeat. The number of pulses, the shape of the pulse train, and the spacing of the pulses for each of the priority conditions are spelled out in detail in IEC 60601-1-8.

IEC 60601-1-8 requires that an individual sound pulse must have a fundamental frequency somewhere between 150 to 1000 Hz, and there must be at least four harmonic sounds from 300 to 4000 Hz. Again, these requirements are optional and may be varied in the context of this disclosure. The spectrum1300ofFIG.13shows a visible example of an audible sound that meets these requirements. The spectrum1300includes a peak1310to the far left, which is the fundamental frequency of the alarm sound, and four peaks1320to the right of the fundamental peaks that represent harmonics of the fundamental. To the ear, the resulting blended sound would be similar to hearing four different musical notes played at the same time. A final IEC 60601-1-8 requirement for the sound pulse characteristic is that the sound level (measured in dB) of the four harmonic tones (represented by peaks1320) must be within +15 dB of the fundamental frequency tone. These requirements may be relaxed or varied in other implementations.

IEC 60601-1-8 also gives the option of providing more than one set of audible warning sounds that vary the fundamental frequency of the audible warning sound. What this means is that the equipment can play a musical melody instead of just beeping over and over with the same frequency sound. The sequence of musical notes for each melody can vary, but examples are spelled out for several different kinds of medical applications in the standard. For example, a ventilation alarm can be assigned one unique melody while a cardiac alarm can have a different unique melody. By assigning a unique melody for each kind of medical equipment, the possibility is that medical personnel can become familiar with each different kind of melody and more quickly identify the source of an audible warning sound.

The signal1302shown inFIG.13is a non-limiting example of a harmonic alarm that can be detected using the alarm analyzer700or800ofFIG.7or8. For example, the band-pass filters of the alarm analyzer700or800can have center frequencies at the frequencies of the fundamental peak1310and at each of the harmonic peaks1320.

VI. Terminology

Many other variations than those described herein will be apparent from this disclosure. For example, depending on the embodiment, certain acts, events, or functions of any of the algorithms described herein can be performed in a different sequence, can be added, merged, or left out altogether (for example, not all described acts or events are necessary for the practice of the algorithms). Moreover, in certain embodiments, acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially. In addition, different tasks or processes can be performed by different machines and/or computing systems that can function together.

The various illustrative logical blocks, modules, and algorithm steps described in connection with the embodiments disclosed herein can 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, 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 can 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 and modules described in connection with the embodiments disclosed herein can be implemented or performed by a machine, such as 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 can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like. A processor can include electrical circuitry that can process computer-executable instructions. In another embodiment, a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions. A processor can also be implemented as a combination of computing devices, for example, 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. A computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.

The steps of a method, process, or algorithm described in connection with the embodiments disclosed herein can be embodied directly in hardware, in a software module stored in one or more memory devices and executed by one or more processors, or in a combination of the two. A software module can 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 non-transitory computer-readable storage medium, media, or physical computer storage known in the art. An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor. The storage medium can be volatile or nonvolatile. The processor and the storage medium can reside in an ASIC.

Conditional language used herein, such as, among others, “can,” “might,” “may,” “for example,” 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 states. Thus, such conditional language is not generally intended to imply that features, elements and/or states 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 states are included or are to be performed in any particular embodiment. The terms “comprising,” “including,” “having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth. Also, the term “or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in the list. Further, the term “each,” as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term “each” is applied.

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 devices or algorithms illustrated can be made without departing from the spirit of the disclosure. As will be recognized, certain embodiments of the inventions described herein can be embodied within a form that does not provide all of the features and benefits set forth herein, as some features can be used or practiced separately from others.