Methods and systems for medical device alarm management

Abstract

A computer system for managing medical device alarms receives an alarm from a medical device monitoring a patient of one or more patients. The computer system also receives clinical contextual information corresponding to clinicians. The computer system further receives patient contextual information corresponding to the one or more patients. The computer system determines, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert. The subscriber list includes identity data identifying a first subset of the clinicians that are associated with the patient. The computer system further sends the alert to endpoints associated with the subscriber list.

Description

Methods and Systems for Medical Device Alarm ManagementTECHNICAL FIELD

[0001] The disclosed embodiments relate generally to alarm management systems, and, in particular, to managing alarms from medical devices via an alarm management system.BACKGROUND

[0002] The development of alarm systems for medical devices in hospitals has increased significantly in recent years. One problem with current existing alarm systems in hospital settings is the constant beeping and non-descript sounds that emanate from medical devices such as vital signs monitors, infusion pumps, and ventilators. Research shows that clinicians can be exposed to as many as 1,000 alarms per shift, yet only about 15% of which are clinically relevant. This results in alarm fatigue and desensitization, increasing the risk of missing critical alarms. Furthermore, the similar sounds produced by different medical devices further complicate the ability of medical clinicians to effectively locate and respond to those alarms. The U.S. Food and Drug Administration has reported about 566 deaths between 2005 and 2010 related to medical device alarms. In addition to causing sensory overload for healthcare workers, the incessant sounds create a hectic and unwelcoming auditory environment for both clinicians and patients.SUMMARY

[0003] Accordingly, there is a need for alarm systems with improved methods for reducing sensory overload and alarm fatigue among clinicians while also decreasing the risk of missing critical alarms. For instance, clinicians should only be exposed to alarms related to their responsibilities based on shift assignments.

[0004] In the disclosed embodiments, methods and systems are provided to reduce or eliminate the above deficiencies and problems associated with the current existing alarm systems. In particular, such methods and systems optionally complement or replace conventional methods and systems for providing alarms from medical devices in hospital settings to clinicians. Additionally, such methods and systems also reduce the likelihood of107513-5055-WO - 1 -alarms being missed, thereby improving the interface between machines (e.g., medical devices) and personnel (e.g., both clinicians and patients).

[0005] To that end, in accordance with some embodiments, a method is provided. The method of managing medical device alarms includes receiving an alarm from a medical device monitoring a patient of one or more patients. The method also includes receiving clinical contextual information corresponding to clinicians. The method further includes receiving patient contextual information corresponding to the one or more patients. The method further includes determining, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert. The subscriber list includes identity data identifying a first subset (e.g., appropriate / responsible clinicians) of the clinicians that are associated with (e.g., assigned to) the patient. The method further includes sending the alert to endpoints associated with the subscriber list.

[0006] In accordance with some embodiments, a computer system is provided. The computer system includes one or more processors and memory storing one or more programs. The one or more programs are configured to be executed by the one or more processors. The one or more programs include instructions for performing any of the methods described herein.

[0007] In accordance with some embodiments, a non-transitory computer-readable storage medium is provided. The one or more programs comprises instructions that, when executed by a computer system that includes one or more processors, cause the one or more processors to perform operations for any of the methods described herein.

[0008] These illustrative aspects are mentioned not to limit or define the disclosure, but to provide examples to aid understanding thereof. Additional embodiments are discussed in the Detailed Description, and further description is provided there.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The embodiments disclosed herein are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings. Like reference numerals refer to corresponding parts throughout the drawings and specification.

[0010] FIG. l is a block diagram illustrating a medical device alert management platform, in accordance with some embodiments.107513-5055-WO - 2 -

[0011] FIG. 2 is a block diagram illustrating a computer system that supports a medical device alert management system, in accordance with some embodiments.

[0012] FIG. 3 illustrates an example MDAM platform 300 in a hospital (or other clinical) setting, in accordance with some embodiments.

[0013] FIG. 4 is a flow diagram illustrating a method of managing medical device alarms, in accordance with some embodiments.DETAILED DESCRIPTION

[0014] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described embodiments. However, it will be apparent to one of ordinary skill in the art that the various described embodiments may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

[0015] It will also be understood that, although the terms first, second, etc. are, in some instances, used herein to describe various elements, these elements should not be limited by these terms. These terms are used only to distinguish one element from another. For example, a first widget could be termed a second widget, and, similarly, a second widget could be termed a first widget, without departing from the scope of the various described embodiments. The first widget and the second widget are both widgets, but they are not the same widget.

[0016] The terminology used in the description of the various embodiments described herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various described embodiments and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and / or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “includes,” “including,” “comprises,” and / or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do107513-5055-WO - 3 -not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0017] As used herein, the term “if’ is, optionally, construed to mean “when” or “upon” or “in response to determining” or “in response to detecting” or “in accordance with a determination that,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” is, optionally, construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event]” or “in accordance with a determination that [a stated condition or event] is detected,” depending on the context.

[0018] FIG. l is a block diagram illustrating a medical device alert management system (MDAM) platform 100, in accordance with some embodiments. In some circumstances, the MDAM platform 100 is implemented in facility settings (e.g., hospitals, healthcare centers, etc.) to manage medical device alarms for patients, clinicians, nurses, and other staff members. As shown in FIG. 1, the MDAM platform 100 includes a MDAM system 102, one or more medical devices 120 (e.g., medical device 120-1 to medical device 120-m, where m is an integer greater than one), and one or more endpoints 130 (e.g., endpoint device 130-1 to endpoint device 130-n, where n is an integer greater than one). In some embodiments, the MDAM system 102 is communicatively coupled to the one or more medical devices 120 and the one or more endpoints 130. The MDAM system 102 further includes a MDAM core component 104 and a MDAM input component 106, which are communicatively coupled to each other. The MDAM input component 106 further includes a plurality of blocks 110 (e.g., block 110-1 to block 110-k, where k is an integer greater than two). In particular, the MDAM system 102 serves as a center of the MDAM platform 100, and utilizes the MDAM core component 104 and the plurality of blocks 110 to communicate and process data for managing alarm(s) and generating alert(s) associated with the alarm(s).

[0019] In some embodiments, the MDAM platform 100 further includes a medical device alarms dashboard (MDAD) terminal 140 (e.g., a dashboard, a workstation, a desktop, a real-time data panel, a user interface, an application, or other type) and the MDAM system 102 further includes a MDAD component 108, which is communicatively coupled to the MDAM core component 104 and the MDAD terminal 140. In some circumstances, the MDAM core component 104 is configured to send instructions to the MDAD terminal 140,107513-5055-WO - 4 -via the MDAD component 108, to display a view of real-time information including the alarm, the subscriber list, and / or the alert at the MDAD terminal 140. In some embodiments, the MDAM core component 104 is configured to send instructions to the MDAD terminal 140, via the MDAD component 108, to charge nurses or unit / department managers (e.g., via a nurses’ workstation) and provide a real-time view of how all alarms in a unit / department are assigned and being responded to. Additionally, in accordance with the instructions received from the MDAM core component 104 and / or the MDAD component 108, the MDAD terminal 140 highlights any alarms that have not been assigned or are considered inadequately assigned by the MDAM core component 104. For example, an inadequate assignment occurs when an assigned clinician is too far from the one or more medical devices 120 given the associated priority / urgency level. In this situation, a user (e.g., a clinician, a nurse, a staff member, etc.) of the MDAD terminal 140 can override existing assignments as needed (e.g., by manually entering additional assignment(s)) to ensure all alarms are properly assigned. In some circumstances, other clinicians (e.g., who may be closer to the one or more medical devices 120 given the associated priority / urgency level) are automatically assigned by the MDAM core component 104 based on the clinicians’ real-time location information. In some embodiments, the MDAD component 108 is optional.

[0020] In some embodiments, the MDAM core component 104 is configured to receive an alarm (e.g., auditory alarm, non-auditory alarm, etc.; cardiac monitor alarm, pulse oximeter alarm, infusion pump alarm, ventilator alarm, electrocardiogram (ECG) machine alarm, blood pressure monitor alarm, dialysis machine alarm, and / or other types) for a medical device of the one or more medical devices 120 (e.g., cardiac monitor, pulse oximeter, blood pressure monitor, continuous glucose monitor, capnography monitor, intensive care unit (ICU) monitor, fetal monitor, intracranial pressure monitor, and / or other types) monitoring a patient of one or more patients (e.g., patients in a unit / department, such as emergency department, ICU, neonatal intensive care unit, cardiac care unit, etc.; patients in a room or on the same floor, etc.). The MDAM core component 104 is also configured, via corresponding blocks of the plurality of blocks 110, to receive clinical contextual information (e.g., clinical assignment data, clinical proximity data, and / or other types) corresponding to clinicians. The MDAM core component 104 is further configured to, via corresponding blocks of the plurality of blocks 110, receive patient contextual information (e.g., patient census data and / or other types) corresponding to the one or more patients. The MDAM core107513-5055-WO - 5 -component 104 is further configured to determine, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert (e.g., auditory alert, text alert, push notification, email alert, vibration alert, visual alert, pop-up alert, pager alert, color-coded alert, broadcast alert, and / or other types). The subscriber list includes identity data identifying a first subset (e.g., appropriate / responsible clinicians) of the clinicians that are associated with (e.g., assigned to) the patient. The MDAM core component 104 is further configured to send the alert to endpoints (e.g., alert-capable endpoint devices, such as workstations, desktops, mobile devices, wearables, and / or other types) associated with the subscriber list. In some circumstances, the endpoints associated with the subscriber list include all or a portion of the one or more endpoints 130. The MDAM core component 104 is further configured to forgo sending the alert to endpoints of clinicians who are not associated with the patient. The MDAM core component 104 is further configured to send instructions to a terminal to display a view of real-time information including the alarm, the subscriber list, and / or the alert at the MDAD terminal 140.

[0021] In some embodiments, the MDAM system 102 receives alarm(s) from a medical device of the one or more medical devices 120, electronically along with alarm contextual information via the MDAM core component 104, and the MDAM system 102 receives clinical contextual information (e.g., clinical assignment data, clinical proximity data, and / or other types) and patient contextual information (e.g., patient census data and / or other types) via the MDAM input component 106. In some circumstances, the MDAM core component 104 determines (e.g., generates) alerts based on the alarms, clinical contextual information, and patient contextual information, and conveys the alerts to a subset of the clinicians (e.g., the appropriate / responsible clinicians) via the one or more endpoints 130 (e.g., workstations, desktops, mobile devices, wearables, and / or other types). The appropriate clinicians who are available can use the one or more endpoints 130 (e.g., their own mobile devices) to confirm that they are responding. In this way, the one or more medical devices 120 are not required to sound the conventional built-in auditory alarms, though they can be configured to do so if necessary.

[0022] In some embodiments, the MDAM input component 106 includes the plurality of blocks 110 (e.g., in reference to FIG. 3 for additional details), including an Identity and Governance Administration System (IGA) block, a Clinical Staff Scheduling System (CSS) block, a Time and Attendance System (TAS) block, an Admission, Discharge and Transfer107513-5055-WO - 6 -System (ADT) block, an Identity and Access Management System (IAM) block, a Real-Time Location System (RTLS) block, an Alert Delivery and Response System (ADR) block, and an Alert Endpoints (AE) block. The MDAM core component 104 processes and dispatches the alarm based on the contextual information (e.g., clinical contextual information, patient contextual information, and / or other information) received from the plurality of blocks 110.

[0023] In some embodiments, the alarm includes alarm contextual information, which, for example, includes the medical device’s type (e.g., for identifying a specific medical device), the alarm’s location (e.g., manually configured, automatically provided through the RTLS block), the reason for the alarm, the patient information associated with the alarm, and / or other types of information, accompanied by relevant telemetry.

[0024] In some embodiments, the MDAM platform 100 is a publish / subscribe (pub / sub) messaging system (e.g., in reference to FIG. 3). In some circumstances, the one or more medical devices 120 publish their alarms, and the MDAM platform 100 automatically “subscribes” the appropriate clinicians (e.g., the appropriate clinicians instead of all the clinicians) to each “published” alarm. As a result, only subscribers to a given alarm are presented with (e.g., notified of) the alarm, as opposed to the conventional auditory alarm mechanism, which “publishes” alarms in the form of auditory alarms to everyone within hearing range and thus effectively makes them all “subscribed.”

[0025] In some embodiments, the MDAM platform 100 does not route the alert to all clinicians who are assigned to a patient. Rather, only clinicians who are on the subscriber list, which is determined by the MDAM core component 104 of the MDAM system 102, receive the alert through the one or more endpoints 130. In some embodiments, the MDAM platform 100 automatically routes alarms to a subset of the clinicians (e.g., the appropriate clinicians instead of all the clinicians in a hospital facility) based on the contextual information (e.g., current shift assignments of clinicians), and automatically provides determined (e.g., generated) alerts with sufficient context to help them identify the alarm’s type, cause, priority / urgency levels, and locations of the medical device triggering it. In some circumstances, this capability of the MDAM platform 100 significantly reduces the sensory overload and alarm fatigue among the clinicians, because only a subset of the clinicians (e.g., the appropriate clinicians instead of all the clinicians in a hospital facility) are exposed to the alarms for which they are responsible based on the contextual information (e.g., current shift107513-5055-WO - 7 -assignments of clinicians). Note that, as should be clear from the above, the subscriber list may be dependent upon additional factors (e.g., those included in the clinical contextual information) aside from a patient being assigned to a clinician. Some of these additional factors may be automatically determined, such as a clinician’s location, role, and other relevant information. Thus, a clinician, who is nominally assigned to a patient and may receive some alarm(s) for the patient, may, nonetheless, not receive a particular alarm because of these additional factors.

[0026] In some embodiments, the MDAM platform 100 provides the capability for the clinicians to acknowledge receipt of an alert (e.g., allow the clinicians to provide responses, such as pressing a button, to the endpoints associated with the clinicians), via the one or more endpoints 130, and take ownership for handling the alert. In some circumstances, this capability allows for the clinicians to take ownership of the alarms and minimizes productivity losses caused by multiple responses by different clinicians to the same alarm. In some embodiments, the MDAM platform 100 provides the capability for the clinicians to disable / silence the alarm, via the one or more endpoints 130, once they reach the medical device that triggered it and begin responding to the cause (e.g., a medical issue / emergency associated with a patient) of the alarm.

[0027] FIG. 2 is a block diagram illustrating a computer system 200 that supports the MDAM system 102 (e.g., in reference to FIG. 1), in accordance with some embodiments. The computer system 200 includes one or more central processing units (CPU(s), i.e., processors or cores) 202, one or more communication interfaces 204, one or more network interfaces 206, memory 210, and one or more communication buses 208 for interconnecting these components. The communication buses 208 optionally include circuitry (e.g., a chipset) that interconnects and controls communications between system components.

[0028] In some embodiments, the one or more network interfaces 206 include wireless and / or wired interfaces for receiving data from and / or transmitting data to the one or more medical devices 120, the one or more endpoints 130, the MDAD terminal 140, and / or other devices or systems. In some embodiments, data communications are carried out using any of a variety of custom or standard wireless protocols (e.g., NFC, RFID, IEEE 802.15.4, Wi-Fi, ZigBee, 6L0WPAN, Thread, Z-Wave, Bluetooth, ISAlOO. l la, WirelessHART, MiWi, etc.). Furthermore, in some embodiments, data communications are carried out using any of a107513-5055-WO - 8 -variety of custom or standard wired protocols (e.g., USB, Firewire, Ethernet, etc.). For example, the one or more network interfaces 206 include a wireless interface 207 for enabling wireless data communications with the one or more medical devices 120, the one or more endpoints 130, the MDAD terminal 140, and / or or other wireless (e.g., Bluetoothcompatible) devices (e.g., for displaying data, storing data, processing data, etc.).Furthermore, in some embodiments, the wireless interface 207 (or a different communications interface of the one or more network interfaces 206) enables data communications with other WLAN-compatible components (e.g., devices, servers, clouds, and / or other types) for displaying data, storing data, processing data, or other purposes related to medical device alert management.

[0029] Memory 210 includes high-speed random-access memory, such as DRAM, SRAM, DDR RAM, or other random-access solid-state memory devices; and may include non-volatile memory, such as one or more magnetic disk storage devices, optical disk storage devices, flash memory devices, or other non-volatile solid-state storage devices. Memory 210 may optionally include one or more storage devices remotely located from the CPU(s) 202. Memory 210, or alternately, the non-volatile memory solid-state storage devices within memory 210, includes a non-transitory computer-readable storage medium. In some embodiments, memory 210 or the non-transitory computer-readable storage medium of memory 210 stores the following programs, modules, and data structures, or a subset or superset thereof:• an operating system 220 that includes procedures for handling various basic system services and for performing hardware-dependent tasks;• communication module(s) 222 for transmitting data, e.g., between components (e.g., the MDAM core component 104, the MDAM input component 106, the MDAD component 108) of the MDAM system 102, handling protocols (e.g., authenticati on / encry ption), detecting error, and / or other functions;• network module(s) 224 for connecting the MDAM system 102 to the one or more medical devices 120, the one or more endpoints 130, the MDAD terminal 140, and / or other devices or systems, via the one or more network interfaces 206 (wired or wireless);• a MDAM core module 226 associated with the MDAM core component 104;107513-5055-WO - 9 -• a MDAM input module 228 associated with the MDAM input component 106. In some embodiments, the MDAM input module 228 also includes the following submodules (or sets of instructions) associated with the plurality of blocks 110, or a subset or superset thereof: o an Identity and Governance Administration System (IGA) sub-module 230; o a Clinical Staff Scheduling System (CSS) sub-module 232; o a Time and Attendance System (TAS) sub-module 234; o an Admission, Discharge and Transfer System (ADT) sub-module 236; o an Identity and Access Management System (IAM) sub-module 238; o a Real-Time Location System (RTLS) sub-module 240; o an Alert Delivery and Response System (ADR) sub-module 242; o an Alert Endpoints (AE) sub-module 244;• a medical device alarms dashboard module 246 associated with the MDAD component 108;• a user interface module 248 that receives commands and / or inputs from a user via a user interface (e.g., from an input device) and provides outputs for display on the user interface (e.g., to an output device);• a web browser application 250 for accessing, viewing, and interacting with web sites; and• other applications 252, such as applications for word processing, calendaring, mapping, weather, time keeping, virtual digital assistant, presenting, number crunching (spreadsheets), drawing, instant messaging, e-mail, telephony, video conferencing, photo management, video management, and / or other purposes.

[0030] Each of the above identified modules stored in memory 210 corresponds to a set of instructions for performing a function described herein. The above identified modules or programs (i.e., sets of instructions) need not be implemented as separate software programs, procedures, or modules, and thus various subsets of these modules may be combined or otherwise re-arranged in various embodiments. Likewise, although shown as stored in a single memory, the above-identified modules may be stored on physically separate107513-5055-WO - 10 -memories and / or executed on physically separate (e.g., remote) devices. In some embodiments, memory 210 optionally stores a subset or superset of the respective modules and data structures identified above. Furthermore, memory 210 optionally stores additional modules and data structures not described above.

[0031] FIG. 3 illustrates an example MDAM platform 300 in a hospital (or other clinical) setting, in accordance with some embodiments. In particular, the example MDAM platform 300 implements the block diagram of the MDAM platform 100 (e.g., in reference to FIG. 1). As shown in FIG. 3, the example MDAM platform 300 includes the MDAM core component 104 and the plurality of blocks 110, which are part of the MDAM system 102. The plurality of blocks 110 include an Identity and Governance Administration System (IGA) block 310-1, a Clinical Staff Scheduling System (CSS) block 310-2, a Time and Attendance System (TAS) block 310-3, an Admission, Discharge and Transfer System (ADT) block 310- 4, an Identity and Access Management System (IAM) block 310-5, a Real-Time Location System (RTLS) block 310-6, an Alert Delivery and Response System (ADR) block 310-7, and an Alert Endpoints (AE) block 310-8. The example MDAM platform 300 further includes the one or more medical devices 120 (e.g., medical device 120-1 to medical device 120-m, where m is an integer greater than one) and the one or more endpoints 130 (e.g., endpoint device 130-1 to endpoint device 130-n, where n is an integer greater than one). The example MDAM platform 300 further includes an example MDAD terminal 340 (e.g., corresponding to the MDAD terminal 140) and a nurses’ station 341. In some embodiments, the example MDAD terminal 340 is part of the MDAM system 102. In some embodiments, although certain blocks 310 in FIG. 3 are shown as performing unidirectional communication, each block of the plurality of blocks 310 is configured to bidirectionally or unidirectionally communicate with the MDAM core component 104 and / or associated block(s).

[0032] In some circumstances, the MDAM core component 104 is electrically and / or communicatively coupled, via wired or wireless connection(s), to the one or more medical devices 120 (e.g., the MDAM core component 104 is configured to bidirectionally communicate with the one or more medical devices 120). Moreover, the MDAM core component 104 is electrically and / or communicatively coupled to the IGA block 310-1, the CSS block 310-2, the TAS block 310-3, the ADT block 310-4, the IAM block 310-5, the RTLS block 310-6, and the ADR block 310-7 for receiving and sending data relating to107513-5055-WO - 11 -medical device alert management. Furthermore, the IAM block 310-5, the RTLS block 310-6, and the ADR block 310-7 are electrically and / or communicatively coupled to the AE block 310-8 for receiving data from and sending data to the one or more endpoints 130.

[0033] In some embodiments, the MDAM core component 104 is configured to receive an alarm from a medical device (e.g., in an ICU, in a patient room, as shown in FIG.3) monitoring a patient of one or more patients. The MDAM core component 104 is also configured, via the IGA block 310-1, the CSS block 310-2, the TAS block 310-3, the IAM block 310-5, and / or the RTLS block 310-6, to receive clinical contextual information (e.g., clinical assignment data, clinical proximity data, and / or other types) corresponding to clinicians. The MDAM core component 104 is further configured to, via the ADT block 310- 4, receive patient contextual information (e.g., patient census data and / or other types) corresponding to the one or more patients. The MDAM core component 104 is further configured to determine, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert. The subscriber list includes identity data identifying a first subset (e.g., appropriate / responsible clinicians) of the clinicians that are associated with (e.g., assigned to) the patient. The MDAM core component 104 is further configured to send the alert, via the AE block 310-8, to endpoints associated with the subscriber list. In some circumstances, the endpoints associated with the subscriber list include all or a portion of the one or more endpoints 130. The MDAM core component 104 is further configured to forgo sending the alert to endpoints of clinicians who are not associated with the patient. In some embodiments, the identity data identifying the first subset of the clinicians, for example, includes information about names, employee or provider identities, credentials and certifications, and / or contact information of the first subset of the clinicians. In some embodiments, the clinical role data, for example, includes information about clinicians’ job titles, specialties, access permissions, and / or authority levels. In some embodiments, the example MDAM platform 300 provides wired or wireless connections for routing the associated subscriber list and the alert to their corresponding endpoints. This can be achieved by leveraging standard mobile device notification services.

[0034] In some embodiments, the MDAM core component 104 is configured to receive clinical identity data and clinical role data via the IGA block 310-1. The MDAM core component 104 is further configured to add (e.g., integrate) the received clinical identity data and the clinical role data into the clinical contextual information for further data processing.107513-5055-WO - 12 -In some embodiments, the clinical identity data, for example, includes information about clinicians’ names, employee or provider identities, credentials and certifications, and / or contact information. In some embodiments, the clinical role data, for example, includes information about clinicians’ job titles, specialties, access permissions, and / or authority levels.

[0035] In some embodiments, the MDAM core component 104 is configured to receive clinical assignment data via the CSS block 310-2. The MDAM core component 104 is further configured to add (e.g., integrate) the received clinical assignment data into the clinical contextual information for further data processing. In some embodiments, the CSS block 310-2 of the MDAM system 102 is optional. In some embodiments, the clinical assignment data, for example, includes information about clinician assignments / shifts (e.g., which clinicians are on shift, their specific roles, and / or patient assignments related to responding to alarms).

[0036] In some embodiments, the MDAM core component 104 is configured to receive clinical presence data via the TAS block 310-3. The MDAM core component 104 is further configured to add (e.g., integrate) the received clinical presence data into the clinical contextual information for further data processing. In some embodiments, the TAS block 310-3 of the MDAM system 102 is optional. In some embodiments, the clinical presence data includes physical presence of the clinicians (e.g., actual presence of the clinicians in a hospital). In some embodiments, the TAS block 310-3 is superior to the CSS block 310-2, because TAS block 310-3 receives actual presence of the clinicians while the CSS 310-2 block receives planned presence of the clinicians.

[0037] In some embodiments, the TAS block 310-3 is configured to remove a portion of the clinical presence data associated with a second subset of the clinicians. In some circumstances, the TAS block 310-3 is configured as a filter to dynamically remove subscribers. For example, the TAS block 310-3 can limit the number of subscribers to one or two clinicians. In some embodiments, the first subset of the clinicians includes (i) the second subset of the clinicians and (ii) additional clinicians who are not part of the second subset of the clinicians.

[0038] In some embodiments, the MDAM core component 104 is configured to receive, via the IAM block 310-5, the AE block 310-8, and the one or more endpoints 130107513-5055-WO - 13 -associated with the clinicians, first clinical proximity data corresponding to access information. The MDAM core component 104 is further configured to add (e.g., integrate) the first clinical proximity data into the clinical contextual information. In some embodiments, the first clinical proximity data, for example, includes the distance of clinicians from the medical device. In some embodiments, the IAM block 310-5 receives (e.g., monitors) the clinicians’ logins / logouts (e.g., badging in / out) through endpoints (e.g., workstations at known locations). In particular, the IAM block 310-5 monitors the presence of clinicians at various endpoints, either fixed or mobile, by overseeing logins to personal / shared workstations and checkouts from mobile devices. For example, the IAM block 310-5 receives a clinician’s login, such as “Preston logged into workstation 123 in room 23 at 12:36 pm,” through a workstation. In another example, the IAM block 310-5 receives a clinician’s mobile device scan, such as “Preston performed a mobile device scan at med cart 456 at 1 :23 pm,” through a mobile device.

[0039] In some embodiments, the MDAM core component 104 is configured to receive, via the RTLS block 310-6, the AE block 310-8, and the one or more endpoints 130 associated with the clinicians, second clinical proximity data corresponding to real-time location information. The MDAM core component 104 is further configured to add (e.g., integrate) the second clinical proximity data into the clinical contextual information. In some embodiments, the RTLS block 310-6 of the MDAM system 102 is optional. In some embodiments, the proximity awareness of the clinicians is determined based on a combination of the first clinical proximity data and the second clinical proximity data. In some embodiments, the RTLS block 310-6 receives (e.g., monitors, tracks) real-time locations of the clinicians through endpoints (e.g., mobile devices). In some embodiments, the RTLS block 310-6 receives and verifies locations of the medical devices associated with the alarms. In some embodiments, the RTLS block 310-6 is configured to project a clinician’s travel time based on historical data tracked by the RTLS block 310-6.

[0040] In some embodiments, the MDAM core component 104 is configured to receive, via the ADT block 310-4, patient census data. The MDAM core component 104 is further configured to add (e.g., integrate) patient census data into the patient contextual information. In some embodiments, the patient census data, for example, includes a patient census. The patient census includes patient identity data and also maps patients to specific rooms and beds. In another example, patient census data includes relationship between107513-5055-WO - 14 -patients and clinicians (e.g., attending physicians) as well as medical unit / department assignments, which enables the MDAM core component 104 to identify which clinicians are responsible for the patient. In yet another example, patient census data includes status of patients in a facility at a given time (e.g., workload requirement, resource allocation, patient- to-clinician ratio, care prioritization, medical / operational decisions, etc.). This information helps the MDAM core component 104 determine, based on the alarm, which clinician is best suited to provide the appropriate follow-up care / treatment.

[0041] In some embodiments, the MDAM core component 104 is configured to provide a predetermined model configured to synthesize predefined rules. The MDAM core component 104 is further configured to determine, based on input data including the alarm, the clinical contextual information, and the patient contextual information, the subscriber list and the alert using the predetermined model. In some embodiments, the predefined rules that govern the prioritization and routing / distribution decisions made by the MDAM core component 104 can draw from both industry norms / standards and organization-specific guidelines. The organization-specific guidelines can be implemented through a mixture of configuration settings and machine learning tailored to the specific deployment of a given organization. Moreover, the predefined rules can also draw from the manuals of medical devices and / or human protocols to determine which situations associated with the alarms require intervention. In this way, critical alarms can be distinguished from non-critical ones. Furthermore, the predefined rules can also draw from role(s) (e.g., respiratory therapist, nurse, physician) that are deemed most suitable for responding to a specific alarm. In some embodiments, the predetermined model can be built by synthesizing various rules, such as guidelines and / or knowledge bases including guidelines provided by medical device vendors, guidelines provided by the medical institution, medical knowledge base data that outlines the effects of delays in responding to specific types of alarms, patients’ medical histories, and / or other types of information. In some embodiments, determining appropriate clinicians (e.g., the appropriate clinicians instead of all the clinicians) for the subscriber list is based on the synthesized predefined rules (as discussed above) as well as the contextual information received from the plurality of blocks (e.g., 110-1, 110-2, . . . 110-k, FIG. 1; 310-1, 310-2, . . ., 310-8, FIG. 3) of the MDAM input component 106 (in reference to FIGS. 1 and 3), such as: (i) roles (e.g., respiratory therapist, nurse, physician) that are deemed most suitable for responding to the alarm, based on the predefined rules and the data from the IGA block 310-107513-5055-WO - 15 -1, (ii) patient-clinician relationship and / or unit / department assignments, based on the data from the ADT block 310-4, (iii) projected clinicians’ travel time based on historical data from the RTLS block 310-6, (iv) most likely locations of potential responders, based on a combination of data from the CSS 310-2, TAS 310-3, LAM 310-5, and RTLS 310-6 blocks, and (v) awareness of a likely activity and consequence of interrupting it (e.g., a clinician who is currently responding to another emergency or located in an operating room can be placed lower on the subscriber list).

[0042] In some embodiments, the MDAM core component 104 is configured to determine, based on the input data including the alarm, the clinical contextual information, and the patient contextual information, a priority level of the alarm from a plurality of predefined priority levels using the predetermined model. The MDAM core component 104 is further configured to add (e.g., integrate) the priority level of the alarm into the alert. In some embodiments, the MDAM core component 104 implements a predetermined model with various forms of intelligence to determine the urgency / priority of a specific alarm as well as the appropriate clinicians (e.g., the appropriate clinicians instead of all the clinicians) to target. In particular, the predetermined model allows the MDAM core component 104 to determine the urgency / priority of a specific alarm, based on rule-based decisioning, artificial intelligence (Al), and / or human intervention (e.g., human inputs, human instructions). In some embodiments, the plurality of predefined priority levels include, for example, a high- priority (e.g., critical) level, a medium-priority (e.g., warning) level, and a low-priority (e.g., informational) level.

[0043] In some embodiments, the predetermined model includes at least one of the group consisting of (i) a rule-based decisioning model and (ii) an intelligence model. In some embodiments, based on the combination of synthesized predefined rules and / or guidelines and Al / machine learning, the MDAM core component 104, upon receiving an alarm published by a medical device, determines where the medical device is located, which patient is involved, which clinicians need to be notified, which clinicians are most likely to respond considering the urgency / priority level, and the most effective way to reach those clinicians.

[0044] In some embodiments, the predetermined model includes the rule-based decisioning model configured to execute a rule-guided decision-making process (e.g., an automated credit scoring based on structured criteria rules / guidelines). In some embodiments,107513-5055-WO - 16 -the predetermined model includes the intelligence model configured to execute a trained classifier based on machine learning (e.g., decision trees, support vector machines, convolutional neural networks, etc.). In some embodiments, the intelligence model processes inputs of the auditory alarms of medical devices and is able to identify their sounds, such that the MDAM core component 104 can be built upon the existing alarm infrastructure (e.g., of the example MDAM platform 300 in a hospital (or other clinical) setting), leveraging what is already in place to enhance the functionality of the MDAM platform 100.

[0045] In some embodiments, the MDAM core component 104 is configured to receive, from a respective clinician of the clinicians, a user input (e.g., a human intervention) including human instructions. The MDAM core component 104 is further configured to add (e.g., integrate) the user input into the input data for determining the subscriber list and the alert using the predetermined model. In some embodiments, a user input / intervention is required for a specific type of alarm. For instance, when an infusion pump detects air in an intravenous line, an alarm is triggered. To resolve the issue and continue delivering medication, a clinician intervenes by manually stopping the pump, removing the air from the intravenous line, and confirming via an associated medical device (e.g., the infusion pump) and / or endpoint (e.g., the clinician’s mobile device).

[0046] In some embodiments, the MDAM core component 104 is configured to send instructions corresponding to the alert to the endpoints associated with the subscriber list to display the alert. In some circumstances, in some embodiments, the endpoints associated with the subscriber list include all or a portion of the one or more endpoints 130. In some embodiments, the MDAM core component 104 is configured to generate context (e.g., the alarm’s type, cause, priority / urgency levels, and locations of the medical device triggering it) within an alert and instructs the one or more endpoints 130 (e.g., the endpoint devices corresponding to the subscriber list that includes identity data identifying the clinicians who are associated with (e.g., assigned to) the patient) to display the context to the assigned clinicians, thereby reducing the chances of alarms getting missed. In some circumstances, the assigned clinicians who receive the alert are given significantly more context than what typical auditory alarms, like beeping, can provide. This enables the assigned clinicians to locate the source of the alarm, assess its urgency / priority level, and get mentally prepared while enroute to the medical device and / or the patient. In some embodiments, the MDAM core component 104 is configured to generate an alert that integrates the corresponding107513-5055-WO - 17 -clinical and / or patient contextual information with the alarm contextual information received from (e.g., published by) the one or more medical devices 120, and automatically subscribes the appropriate clinicians (e.g., appropriate clinicians instead of all the clinicians) to that alert. The MDAM core component 104 is further configured to send the associated subscriber list and the alert to the ADR block 310-7, which in turn, routes them to the subscribed clinicians via their endpoints (e.g., alert-capable endpoint devices) that they are logged into. These endpoints (e.g., endpoint device 130-1 to endpoint device 130-n) include shared or personal desktops (e.g., devices logged in via the IAM block 310-5), shared or personal mobile devices (e.g., devices checked out via the IAM block 310-5, personal wearables, personal smart watches).

[0047] In some embodiments, the MDAM input component 106 of the MDAM system 102 includes the AE block 310-8. The AE block 310-8 includes an alert processing software 360 (e.g., an app-integrated software). The alert processing software 360 is responsible for notifying its recipient / user (e.g., a clinician) in a way that is likely to capture their attention and clearly communicate the associated context of the alert. In some embodiments, the alert processing software 360 of the AE block 310-8 includes a few aspects. First, the alert processing software 360 is configured to send instructions to the associated endpoint to convey the alert in accordance with different priority levels based on the urgency of the alarm (as determined by the MDAM core component 104). For example, the alert processing software 360 can instruct the associated endpoint to present the alert at a specific priority level based on the corresponding type and intensity of the auditory (e.g., loud sounds) and visual (e.g., bright flashing lights) signals of the alarm. Moreover, the alert processing software 360 is configured to send instructions to the associated endpoint to display relevant alert information, including the reason for the alarm, the priority / urgency level, the location of the medical device, and / or the patient’s name. The alert processing software 360 can also instruct the associated endpoint to display auditory alarms that match (e.g., are identical to) the sound the medical device would produce. This helps clinicians quickly identify the type of the alarm because of their familiarity with the sound.Furthermore, the alert processing software 360 is configured to send instructions to the associated endpoint to display a context-rich version of an auditory alarm associated with the alert. For example, this context-rich version can be generated using a text-to-speech process and / or an audio rendering of the original alarm sound (e.g., beeping) to make it easier for107513-5055-WO - 18 -recipients / users to recognize based on their familiarity with the sound. Additionally, the alert processing software 360 is configured to provide a recipient / user (e.g., clinician) with an option to respond to the alert (e.g., by tapping a soft or hard button), as an indication that they are taking ownership and responsibility. Last but not least, depending on the type of the alarm, the alert processing software 360 is configured to send instructions to the associated endpoint to cancel or suppress the alert, once at least one of the target clinicians (or more than one clinician if so required) has taken ownership. For high-priority alarms, the app-integrated software can instruct the associated endpoint to postpone suppression until the recipient / user has indicated completion of the task (e.g., through the AE block 310-8). Alternatively, if the alert is suppressed, it can be reactivated if it is not addressed beyond a specified time limit. In some embodiments, the example MDAM platform 300 provides wired or wireless connections for routing the associated subscriber list and the alert to their corresponding endpoints. This can be achieved by leveraging standard mobile device notification services. In some embodiments, the alert processing software 360 is loaded (e.g., installed) and executed by an endpoint (e.g., a mobile device) and is part of the endpoint.

[0048] In some embodiments, the AE block 310-8 serves as a nexus for bridging bidirectional and / or unidirectional communication between the LAM block 310-5, the RTLS block 310-6, the ADR block 310-7, and the one or more endpoints 130. In some embodiments, the AE block 310-8 is configured to communicate with and send instructions to a nurse call system (e.g., badging system(s), other mobile application(s), etc.; not shown in Figure 3) for distributing alerts to the one or more endpoints 130. In some circumstances, the communication between the AE block 310-8 and the nurse call system is achieved via application programming interfaces (APIs). In some embodiments, the nurse call system is part of the ADR block 310-7, and the communication between the ADR block 310-7 and the AE block 310-8 is achieved via APIs (e.g., a second standardized API 362 as discussed below).

[0049] In some embodiments, the endpoints associated with the subscriber list include shared workstations, desktops, personal devices (e.g., mobile devices, wearables), and / or other types. In some embodiments, the endpoints associated with the subscriber list include all or a portion of the one or more endpoints 130.107513-5055-WO - 19 -

[0050] In some embodiments, the MDAM core component 104 is configured to send instructions to the example MDAD terminal 340 through the nurses’ station 341 to display a view of real-time information including the alarm, the subscriber list, and / or the alert at the example MDAD terminal 340. In some embodiments, the MDAM core component 104 is configured to send instructions to the example MDAD terminal 340 through the nurses’ station 341 to charge nurses or unit / department managers and provide a real-time view of how all alarms in a unit / department are assigned and being responded to. Additionally, in accordance with the instructions received from the MDAM core component 104, the example MDAD terminal 340 highlights any alarms that have not been assigned or are considered inadequately assigned by the MDAM core component 104. For example, an inadequate assignment occurs when an assigned clinician is too far from the one or more medical devices 120 given the associated priority / urgency level. In some embodiments, a user (e.g., a clinician, a nurse, a staff member, etc.) of the example MDAD terminal 340 can override assignments as needed. In some embodiments, the MDAM system 102 includes the MDAD component 108, which is configured to drive the example MDAD terminal 340. In some embodiments, the MDAD component 108 is optional.

[0051] In some embodiments, the medical device (e.g., the medical device 320) that monitors the patient of the one or more patients includes a medical device software 350 and a first standardized application programming interface (API) 352. In some embodiments, the AE block 310-8 includes the alert processing software 360 and a second standardized API 362. In some embodiments, the operations of the MDAM system 102 is performed through an application and / or a user interface, based on different modules of memory 210 (e.g., in reference to FIG. 2) such as the operating system 220, the user interface module 248, the web browser application 250, and / or the other applications 252. In some circumstances, the application and / or the user interface are communicatively coupled to the medical device (e.g., the medical device 320) through the first standardized API 352, and the application and / or the user interface are communicatively coupled to the endpoints associated with the subscriber list through the second standardized API 362. In some embodiments, the MDAM core component 104 and the MDAM input component 106 of the MDAM system 102 are software components. The MDAM core component 104 acts as a principal component and is electronically and / or communicatively coupled to the one or more medical devices 120 through the first standardized API 352. In particular, the first standardized API 352 of those107513-5055-WO - 20 -medical devices are incorporated into their operating software (e.g., medical device software 350). Additionally, the MDAM core component 104 is also electronically and / or communicatively coupled to the one or more endpoints 130 (e.g., endpoint devices) through the second standardized API 362. In particular, the second standardized API 362 of those endpoints are also incorporated into their operating software (e.g., alert processing software 360). Alternatively, in some embodiments, the second standardized API 362 is part of the ADR block 310-7.

[0052] In some embodiments, the MDAM system 102 includes fail-safe mechanisms. In particular, in accordance with a determination that at least one clinician of the first subset of the clinicians responds to the alert within a predetermined time limit, the MDAM core component 104 is configured to instruct the medical device to disable an auditory alarm of the medical device. In accordance with a determination that no clinician of the first subset of the clinicians responds to the alert within the predetermined time limit, the MDAM core component 104 is configured to instruct the medical device to enable the auditory alarm of the medical device. In some embodiments, the MDAM system 102 is configured in two approaches. First, the auditory alarm of a medical device can be suppressed by default. In some circumstances, instead of sounding an auditory alarm, the medical device relies on the MDAM system 102 to send the determined (e.g., generated) alert associated with the alarm directly to the appropriate set of clinicians. This ensures that the alert reaches the corresponding clinicians without adding additional noise to the environment (e.g., a hospital facility) for reducing alarm fatigue. Second, the auditory alarm of the medical device can be left on. In some circumstances, the medical device sounds the alarm in addition to the operation of the MDAM system 102. This approach is useful in situations where the clinical considerations require an auditory alarm, ensuring that the alarm is heard locally while still notifying the clinicians through the MDAM system 102.

[0053] In some embodiments, the example MDAM platform 300 allows the capability of assigning a backup staff member (e.g., unit / department manager, nurse) to be notified of unanswered alarms and ensure the unanswered alarms will be handled and responded to. For example, if the medical device is configured to suppress auditory alarms (as discussed above), the auditory alarm is enabled / activated as a fail-safe to prevent the alarms from being missed in situations such as monitoring gaps (e.g., shift assignment gaps) or system failures (e.g., system malfunctions at a nurses’ workstation). Furthermore, in one of107513-5055-WO - 21 -fallback (e.g., default) settings, the MDAM system 102 is configured to instruct a medical device to generate a conventional auditory alarm if neither a member of the assigned clinicians nor a backup staff member (e.g., unit / department manager, nurse) responds within a predetermined time limit (e.g., a designated / configurable time limit, such as several seconds or several minutes), depending on the alarm’s severity. In another fallback (e.g., default) setting, the MDAM system 102 is configured to instruct a medical device to generate a conventional auditory alarm if the alarms are determined to be within a predefined category (e.g., severe / critical alarms). For example, certain alarms that require a swift response may benefit from being widely broadcasted (e.g., loudly spread) to ensure prompt attention and action from a member of the assigned clinicians and / or a backup staff member (e.g., unit / department manager, nurse).

[0054] In some embodiments, when a medical device alarm remains unassigned or inadequately assigned, the MDAM system 102 is configured to instruct the medical device to keep its auditory alarm activated (e.g., enabled). In some embodiments, a medical device has an option to continue visually displaying the alarm, though the associated alarm has assigned and their auditory signal has suppressed. In some embodiments, for higher-priority alarms, the MDAM system 102 requires a confirmation (e.g., an acknowledgement from an appropriate / responsible clinician) that an associated task triggered by the alarm has been completed before suppressing the auditory alarm. In some embodiments, a medical device allows its authorized users to disable the alarm once they arrived and start addressing it. In this circumstance, the MDAM system 102 is configured to notify other subscribers that the alarm is being handled and / or suppress the auditory alarm. Additionally, medical devices that require authentication can optimize this process by prefilling the username or providing a picklist of usernames corresponding to subscribers who have responded.

[0055] FIG. 4 is a flow diagram illustrating a method 400 of managing medical device alarms, in accordance with some embodiments. The method 400 may be performed at a computer system (e.g., the computer system 200, FIG. 2) having one or more processors and memory storing instructions for execution by the one or more processors. In some embodiments, the method 400 is performed by executing instructions stored in memory (e.g., memory 210, FIG. 2) of the computer system.107513-5055-WO - 22 -

[0056] Referring now to FIG. 4, in performing the method 400, the computer system receives (402) an alarm from a medical device monitoring a patient of one or more patients. For example, as shown in FIG. 3, the MDAM core component 104 is configured to receive alarms from one or more medical devices 120, which are located in different units / rooms in a hospital facility. In some embodiments, the alarm includes alarm contextual information, which, for example, includes the medical device’s type (e.g., for identifying a specific medical device), the alarm’s location (e.g., manually configured, automatically provided through the RTLS block 310-6, FIG. 3), the reason for the alarm, the patient information associated with the alarm, and / or other types of information, accompanied by relevant telemetry. In some embodiments, the medical device includes a cardiac monitor, a pulse oximeter, a blood pressure monitor, a continuous glucose monitor, a capnography monitor, an ICU monitor, fetal monitor, an intracranial pressure monitor, and other types. In some embodiments, the medical device monitors a patient of one or more patients (e.g., patients in a unit / department, such as emergency department, ICU, neonatal intensive care unit, cardiac care unit, etc.; patients in a room or on the same floor, etc.).

[0057] The computer system receives (404) clinical contextual information corresponding to clinicians. For example, as shown in FIG. 3, the MDAM core component 104 is configured to receive the clinical contextual information via various blocks (e.g., the IGA block 310-1, the CSS block 310-2, the TAS block 310-3, the IAM block 310-5, the RTLS block 310-6) of the MDAM input component 106. In some embodiments, the clinical contextual information includes clinical identity data, clinical role data, clinical assignment data, clinical presence data, first clinical proximity data, and / or second clinical proximity data.

[0058] The computer system receives (406) patient contextual information corresponding to the one or more patients. For example, as shown in FIG. 3, the MDAM core component 104 is configured to receive the patient contextual information via one or more blocks (e.g., the ADT block 310-4) of the MDAM input component 106. In some embodiments, the patient contextual information includes patient census data. For example, the patient census includes patient identity data and also maps patients to specific rooms and beds. In another example, patient census data includes relationship between patients and clinicians (e.g., attending physicians) as well as medical unit / department assignments, which enables the MDAM core component 104 to identify which clinicians are responsible for the107513-5055-WO - 23 -patient. In yet another example, patient census data includes statuses of patients in a facility at a given time (e.g., workload requirement, resource allocation, patient-to-clinician ratio, care prioritization, medical / operational decisions, etc.). This information helps the MDAM core component 104 determine, based on the alarm, which clinician is best suited to provide the appropriate follow-up care / treatment.

[0059] The computer system determines (408), based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert. The subscriber list includes (410) identity data identifying a first subset (e.g., appropriate / responsible clinicians) of the clinicians that are associated with (e.g., assigned to) the patient. In some embodiments, the first subset of clinicians are appropriate / responsible clinicians instead of all the clinicians in a facility (e.g., a hospital or other clinical setting, FIG. 3). In some embodiments, the identity data identifying the first subset of the clinicians, for example, includes information about names, employee or provider identities, credentials and certifications, and / or contact information of the first subset of the clinicians. The computer system further provides (412) a predetermined model configured to synthesize predefined rules. For example, as shown in FIG. 3, the predetermined model is part of the MDAM core component 104. In some embodiments, the MDAM core component 104 implements the predetermined model with various forms of intelligence to determine the alert as well as the appropriate clinicians to target. In some embodiments, the predefined rules include, for example, organization-specific guidelines, manuals of medical devices, human protocols, guidelines provided by medical device vendors and / or other types. The computer system further determines ( 14) based on input data including the alarm, the clinical contextual information, and the patient contextual information, the subscriber list and the alert using the predetermined model.

[0060] The computer system sends ( 16) the alert to endpoints associated with the subscriber list. For example, as shown in FIG. 3, the MDAM core component 104 is configured to send the alert to endpoints (e.g., all or a portion of the one or more endpoints 130) associated with the subscriber list through wired or wireless connection(s). In some embodiments, the endpoints are alert-capable endpoint devices, such as workstations, desktops, mobile devices, wearables, and / or other types. The computer system sends (418) instructions corresponding to the alert to the endpoints associated with the subscriber list to display the alert. In some embodiments, displaying the alert on an endpoint notifies its107513-5055-WO - 24 -recipient / user (e.g., a clinician) in a way that is likely to capture their attention and clearly communicate the associated context of the alert.

[0061] The computer system, in accordance with a determination that at least one clinician of the first subset of the clinicians responds to the alert within a predetermined time limit, instructs (420) the medical device to disable an auditory alarm of the medical device. The computer system, in accordance with a determination that no clinician of the first subset of the clinicians responds to the alert within the predetermined time limit, instructs (422) the medical device to enable the auditory alarm of the medical device. For instance, as shown in FIG. 3, the MDAM system 102 includes fail-safe mechanisms. In some embodiments, the MDAM system 102 is configured to suppress the auditory alarm of a medical device suppressed by default. In some circumstances, instead of sounding an auditory alarm, the medical device relies on the MDAM system 102 to send the determined (e.g., generated) alert associated with the alarm directly to the appropriate set of clinicians. This ensures that the alert reaches the corresponding clinicians without adding additional noise to the environment (e.g., a hospital facility) for reducing alarm fatigue. The MDAM system 102 is also configured to leave the auditory alarm of the medical device on. In some circumstances, the medical device sounds the alarm in addition to the operation of the MDAM system 102. This approach is useful in situations where the clinical considerations require an auditory alarm, ensuring that the alarm is heard locally while still notifying the clinicians through the MDAM system 102.

[0062] In some embodiments, the computer system receives, via an IGA block (e.g., the block 310-1, FIG. 3), clinical identity data and clinical role data. The computer system further adds (e.g., integrates) the clinical identity data and the clinical role data into the clinical contextual information. The computer system further determines, based on the alarm, the clinical contextual information including the clinical identity data and the clinical role data, and the patient contextual information, the subscriber list and the alert. In some embodiments, the clinical identity data, for example, includes information about clinicians’ names, employee or provider identities, credentials and certifications, and / or contact information. In some embodiments, the clinical role data, for example, includes information about clinicians’ job titles, specialties, access permissions, and / or authority levels.107513-5055-WO - 25 -

[0063] In some embodiments, the computer system receives, via a CSS block (e.g., the block 310-2, FIG. 3), clinical assignment data. The computer system further adds (e.g., integrates) the clinical assignment data into the clinical contextual information. The computer system further determines, based on the alarm, the clinical contextual information including the clinical assignment data, and the patient contextual information, the subscriber list and the alert. In some embodiments, the clinical assignment data, for example, includes information about clinician assignments / shifts (e.g., which clinicians are on shift, their specific roles, and / or patient assignments related to responding to alarms).

[0064] In some embodiments, the computer system receives, via a TAS block (e.g., the block 310-3, FIG. 3), clinical presence data. The computer system further adds (e.g., integrates) the clinical presence data into the clinical contextual information. The computer system further determines, based on the alarm, the clinical contextual information including the clinical presence data, and the patient contextual information, the subscriber list and the alert. In some embodiments, the clinical presence data, for example, includes physical presence of the clinicians (e.g., actual presence of the clinicians in a hospital). In some embodiments, the computer system removes, via the TAS block, a portion of the clinical presence data associated with a second subset of the clinicians. In some embodiments, the computer system dynamically removes subscribers via the TAS block that acts as a filter. For example, the TAS block can limit the number of subscribers to one or two clinicians.

[0065] In some embodiments, the computer system receives, via a IAM block (e.g., the block 310-5, FIG. 3) and endpoints associated with the clinicians, first clinical proximity data corresponding to access information. The computer system further adds (e.g., integrates) the first clinical proximity data into the clinical contextual information. The computer system further determines, based on the alarm, the clinical contextual information including the first clinical proximity data, and the patient contextual information, the subscriber list and the alert. In some embodiments, the first clinical proximity data includes, for example, distance of clinicians from the medical device, the clinicians’ logins / logouts (e.g., badging in / out), and / or presence of clinicians at various endpoints, either fixed or mobile.

[0066] In some embodiments, the computer system receives, via a RTLS block (e.g., the block 310-6, FIG. 3) and endpoints associated with the clinicians, second clinical proximity data corresponding to real-time location information. The computer system further107513-5055-WO - 26 -adds (e.g., integrates) the second clinical proximity data into the clinical contextual information. The computer system further determines, based on the alarm, the clinical contextual information including the second clinical proximity data, and the patient contextual information, the subscriber list and the alert. In some embodiments, the second clinical proximity data includes, for example, real-time locations of the clinicians through various endpoints (e.g., mobile devices). In some embodiments, a combination of the first clinical proximity data and the second clinical proximity data forms the proximity awareness of the clinicians.

[0067] In some embodiments, the computer system receives, via an ADT block (e.g., the block 310-4, FIG. 3) patient census data. The computer system further adds (e.g., integrates) the patient census data into the patient contextual information. The computer system further determines, based on the alarm, the clinical contextual information, and the patient contextual information including the patient census data, the subscriber list and the alert. In some embodiments, the patient census data includes, for example, a patient census (e.g., patient identity data, patient mapping, etc.), relationship between patients and clinicians (e.g., attending physicians), and / or medical unit / department assignments.

[0068] In some embodiments, the computer system receives, determines, based on the input data including the alarm, the clinical contextual information, and the patient contextual information, a priority level of the alarm from a plurality of predefined priority levels using the predetermined model. The computer system further adds (e.g., integrates) the priority level of the alarm into the alert. In some embodiments, the plurality of predefined priority levels include, for example, a high-priority (e.g., critical) level, a medium-priority (e.g., warning) level, and a low-priority (e.g., informational) level.

[0069] In some embodiments, the predetermined model includes at least one of the group consisting of (i) a rule-based decisioning model and (ii) an intelligence model. In some embodiments, the predetermined model includes the rule-based decisioning model configured to execute a rule-guided decision-making process (e.g., an automated credit scoring based on structured criteria rules / guidelines). In some embodiments, the predetermined model includes the intelligence model configured to execute a trained classifier based on machine learning (e.g., decision trees, support vector machines, convolutional neural networks, etc.).107513-5055-WO - 27 -

[0070] In some embodiments, the computer system receives, from a respective clinician of the clinicians, a user input including human instructions. The computer system further adds (e.g., integrates) the user input into the input data for determining the subscriber list and the alert using the predetermined model. In some embodiments, a user input / intervention (e.g., turn on / shut down a medical device) is required for a specific type of alarm.

[0071] In some embodiments, the endpoints associated with the subscriber list include shared workstations (e.g., medical workstations, shared desktops, co-working spaces, call centers, public terminals, etc.) and / or personal devices (e.g., mobile devices, wearables, tablets, laptops, smart speakers, consoles, portable devices, augmented reality / virtual reality headsets, etc.).

[0072] In some embodiments, the computer system sends instructions to a terminal to display a view of real-time information including the alarm, the subscriber list, and / or the alert. For example, as shown in FIG. 3, the MDAM core component 104 is configured to send instructions to the example MDAD terminal 340 through the nurses’ station 341 to charge nurses or unit / department managers and provide a real-time view of how all alarms in a unit / department are assigned and being responded to. In another example, as shown in FIG. 1, the MDAM system 102 includes the MDAD component 108, which is configured to send instructions to the MDAD terminal 140 to charge nurses or unit / department managers (e.g., via a nurses’ workstation) and provide a real-time view of how all alarms in a unit / department are assigned and being responded to.

[0073] In some embodiments, the operations of the computer system (e.g., receiving the alarm, receiving the clinical contextual information, receiving the patient contextual information, determining the subscriber list and the alert, sending the alert, and other operations) are performed through an application and / or a user interface. The application and / or the user interface are communicatively coupled to the medical device through a first standardized API. Moreover, the application and / or the user interface are communicatively coupled to the endpoints associated with the subscriber list through a second standardized API. For example, as shown in FIG. 3, the MDAM system 102 can execute an application and / or a user interface such that the application and / or the user interface are communicatively107513-5055-WO - 28 -coupled to the one or more medical devices 320 through the first standardized API 352, and also coupled to the one or more endpoints 130 through the second standardized API 362.

[0074] Although FIG. 4 illustrates a number of logical stages in a particular order, stages which are not order dependent may be reordered and other stages may be combined or broken out. Some reordering or other groupings not specifically mentioned will be apparent to those of ordinary skill in the art, so the ordering and groupings presented herein are not exhaustive. Moreover, it should be recognized that the stages could be implemented in hardware, firmware, software, or any combination thereof.

[0075] The foregoing description, for purpose of explanation, has been described with reference to specific embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The embodiments were chosen and described in order to best explain the principles and their practical applications, to thereby enable others skilled in the art to best utilize the embodiments and various embodiments with various modifications as are suited to the particular use contemplated.107513-5055-WO - 29 -

Claims

What is claimed is:

1. A method of managing medical device alarms, comprising: receiving an alarm from a medical device monitoring a patient of one or more patients; receiving clinical contextual information corresponding to clinicians; receiving patient contextual information corresponding to the one or more patients; determining, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert, wherein the subscriber list includes identity data identifying a first subset of the clinicians that are associated with the patient; and sending the alert to endpoints associated with the subscriber list.

2. The method of claim 1, wherein receiving the clinical contextual information corresponding to the clinicians includes: receiving clinical identity data and clinical role data; and adding the clinical identity data and the clinical role data into the clinical contextual information.

3. The method of claim 1, wherein receiving the clinical contextual information corresponding to the clinicians includes: receiving clinical assignment data; and adding the clinical assignment data into the clinical contextual information.

4. The method of claim 1, wherein receiving the clinical contextual information corresponding to the clinicians includes: receiving clinical presence data; and adding the clinical presence data into the clinical contextual information.

5. The method of claim 4, including: removing a portion of the clinical presence data associated with a second subset of the clinicians.

6. The method of claim 1, wherein receiving the clinical contextual information corresponding to the clinicians includes:107513-5055-WO - 30 -receiving, via endpoints associated with the clinicians, first clinical proximity data corresponding to access information; and adding the first clinical proximity data into the clinical contextual information.

7. The method of claim 1, wherein receiving the clinical contextual information corresponding to the clinicians includes: receiving, via the endpoints associated with the clinicians, second clinical proximity data corresponding to real-time location information; and adding the second clinical proximity data into the clinical contextual information.

8. The method of claim 1, wherein receiving the patient contextual information corresponding to the one or more patients includes: receiving patient census data; and adding the patient census data into the patient contextual information.

9. The method of claim 1, wherein determining, based on the alarm, the clinical contextual information, and the patient contextual information, the subscriber list and the alert includes: providing a predetermined model configured to synthesize predefined rules; and determining, based on input data including the alarm, the clinical contextual information, and the patient contextual information, the subscriber list and the alert using the predetermined model.

10. The method of claim 9, wherein determining, based on the input data including the alarm, the clinical contextual information, and the patient contextual information, the subscriber list and the alert using the predetermined model includes: determining, based on the input data including the alarm, the clinical contextual information, and the patient contextual information, a priority level of the alarm from a plurality of predefined priority levels using the predetermined model; and adding the priority level of the alarm into the alert.

11. The method of claim 9, wherein the predetermined model includes at least one of the group consisting of (i) a rule-based decisioning model and (ii) an intelligence model.107513-5055-WO - 31 -12. The method of claim 11, wherein the predetermined model includes the intelligence model configured to execute a trained classifier based on machine learning.

13. The method of claim 9, including: receiving, from a respective clinician of the clinicians, a user input including human instructions; and adding the user input into the input data.

14. The method of claim 1, wherein sending the alert to the endpoints associated with the subscriber list includes: sending instructions corresponding to the alert to the endpoints associated with the subscriber list to display the alert.

15. The method of claim 1, wherein the endpoints associated with the subscriber list include shared workstations and / or personal devices.

16. The method of claim 1, including: sending instructions to a terminal to display a view of real-time information including the alarm, the subscriber list, and / or the alert.

17. The method of claim 1, wherein: the receiving the alarm, the receiving the clinical contextual information, the receiving the patient contextual information, the determining the subscriber list and the alert, and the sending the alert are performed through an application; the application is communicatively coupled to the medical device through a first standardized application programming interface (API); and the application is communicatively coupled to the endpoints associated with the subscriber list through a second standardized API.

18. The method of claim 1, including: in accordance with a determination that at least one clinician of the first subset of the clinicians responds to the alert within a predetermined time limit, instructing the medical device to disable an auditory alarm of the medical device; and107513-5055-WO - 32 -in accordance with a determination that no clinician of the first subset of the clinicians responds to the alert within the predetermined time limit, instructing the medical device to enable the auditory alarm of the medical device.

19. A computer system, comprising: one or more processors; and memory storing one or more programs, wherein the one or more programs are configured to be executed by the one or more processors, the one or more programs including instructions for: receiving an alarm from a medical device monitoring a patient of one or more patients; receiving clinical contextual information corresponding to clinicians; receiving patient contextual information corresponding to the one or more patients; determining, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert, wherein the subscriber list includes identity data identifying a first subset of the clinicians that are associated with the patient; and sending the alert to endpoints associated with the subscriber list.

20. A computer system, comprising: one or more processors; and memory storing one or more programs, wherein the one or more programs are configured to be executed by the one or more processors, the one or more programs including instructions for performing the method of any of claims 2-18.

21. A non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions that, when executed by a computer system that includes one or more processors, cause the one or more processors to perform operations comprising: receiving an alarm from a medical device monitoring a patient of one or more patients; receiving clinical contextual information corresponding to clinicians; receiving patient contextual information corresponding to the one or more patients;107513-5055-WO - 33 -determining, based on the alarm, the clinical contextual information, and the patient contextual information, a subscriber list and an alert, wherein the subscriber list includes identity data identifying a first subset of the clinicians that are associated with the patient; and sending the alert to endpoints associated with the subscriber list.

22. A non-transitory computer readable storage medium storing one or more programs, the one or more programs comprising instructions that, when executed by a computer system that includes one or more processors, cause the one or more processors to perform the method of any of claims 2-18.107513-5055-WO - 34 -

Images