This document relates to systems and techniques for configuring an Automated External Defibrillator (AED).
Sudden cardiac arrest (colloquially “heart attack”) is a regular killer. The best treatment for cardiac arrest is quick and competent chest compressions to keep blood flowing through a subject's heart. Generally, every minute of delay in treating a cardiac arrest subject lowers the chance of survival by about ten percent. As a result, the ability to provide CPR in a competent manner can be a very important personal skill, and is particularly important for professional healthcare workers such as emergency medical technicians (EMTs).
Various CPR feedback devices are available that indicate to a rescuer whether they are performing CPR chest compressions at an appropriate rate and an appropriate depth of compression, such as dictated by American Heart Association (AHA) guidelines.
In an embodiment, a method for configuring an automated external defibrillator includes sending, to a remote database that includes records associated with automated external defibrillator protocols used to configure automated external defibrillators, a request for available protocols for configuring the automated external defibrillator. The method also includes receiving information about one or more available protocols and sending, to the remote database, a request to download a particular one of the available protocols. The method also includes receiving, from the remote database, configuration information to automatically configure the automated external defibrillator based on the selected protocol.
In an embodiment, a method includes receiving configuration information associated with an automated external defibrillator protocol from a first automated external defibrillator and storing the protocol and the associated configuration information in an automated external defibrillator protocol database. The method also includes downloading the protocol and configuration information to a second automated external defibrillator that is different from the first automated external defibrillator.
In an embodiment, a system includes a protocol database stored in a memory, the protocol database including multiple protocol records each of which includes multiple configurations for an automated external defibrillator. The system also includes a computing device configured to receive configuration information associated with an automated external defibrillator protocol from a first automated external defibrillator, store the protocol and the associated configuration information in the protocol database, and download the protocol to a second automated external defibrillator that is different from the first automated external defibrillator.
In an embodiment, a defibrillator includes a memory configured to store a protocol comprising multiple configurations. The defibrillator also includes a computing device configured to send, to a remote database that includes records associated with automated external defibrillator protocols, a request for available protocols for configuring the automated external defibrillator, receive information about one or more available protocols, send, to the remote database, a request to download a particular one of the available protocols, receive from the remote database, configuration information to automatically configure the automated external defibrillator based on the selected protocol, store the received protocol in the memory, and configure the automated external defibrillator to operate according to the protocol stored in the memory.
The details of one or more embodiments are set forth in the accompanying drawings and the description below. Other features and advantages will be apparent from the description and drawings, and from the claims.
This document describes systems and techniques that may be used to configure an AED The AED is configured according to a protocol that outlines various configurations for the AED and causes the AED to function in a desired manner. As used herein a protocol provides guidelines on how the AED should operate and can include protocol information that provides configurations/settings for the AED such that the AED will perform and operate in a manner that conforms to the set of guidelines on how to operate the AED For example, one portion of a protocol used by the AED can include a CPR protocol which could include protocol information and configurations to set a desired compression depth, compression rate, ventilation rate and volume, and other parameters which outline how the CPR is optimally performed. These configurations will be used to analyze CPR performance and provide feedback to the user. A protocol for the AED could additionally include guidelines regarding when and how to administer a defibrillation shock. For example, the protocol could include algorithms used in analyzing data collected from a subject such as ECG waveforms or other monitored physical parameters, shock voltages, waveforms for the defibrillation energy, timing for defibrillation, and the like. Many of the features of the protocol are stored as configurations on an AED. For example, a protocol could outline a shock voltage and this shock voltage could be stored as a configuration on the AED. Other configurations which are associated with a protocol can include configurations for the AED which do not directly relate to treatment guidelines on which the protocol is based. For example, the language in which prompts are provided to the user is not treatment guideline specific but is still a configuration stored on the AED Protocol information, including stored AED configurations, is provided in a centrally accessible database. AED owners or administrators can store protocols in the database (e.g., by uploading the configurations from a manually configured AED and/or uploading a file with the configurations), and other AED owners or administrators can download the protocols to configure different AEDs. Thus, AED owners can share protocols and their associated configurations with one another.
In certain implementations, the systems and techniques discussed here may provide one or more advantages. For example, by providing an AED owner with a set of available protocols (which include the configurations for operation of the AED), the AED owner is able to select appropriate settings without requiring the owner to manually program the AED. Additionally, once an AED owner selects a particular protocol and downloads the protocol to the AED, updates to the configurations of the AED based on changes to the treatment guidelines on which the protocol is based can be pushed (e.g., automatically sent) to the AED. For example, when the selected protocol is modified, the modifications can be pushed to the AED As such, the AED owner does not have to keep track of advances in treatment but rather any changes to the treatment guidelines on which the protocol is based can be automatically sent to the AED to update the AED's configurations.
This detailed description discusses examples of configuring an AED, according to at least one protocol. Protocol information, including stored AED configurations, is provided in a centrally accessible database. AED owners can store protocols in the database (e.g., by uploading the configurations from a manually configured AED and/or uploading a file with the configurations), and other AED owners can download the protocols to configure different AEDs. Thus, AED owners can share protocols and their associated configurations with one another.
For example, if a company owns five AEDs and want each of the AEDs to function in the same manner, and owner of the five AEDs can configure a first one of the AEDs manually to form a protocol for operation of the AED. The owner can then upload the newly formed protocol, including the manual configurations, as a new protocol which is stored in the central database. Because the protocol is then centrally accessible, the owner can download the protocol on to the remaining AEDs, such that the AEDs all operate using the same protocol.
Separately, a portable defibrillator 112 is shown in a deployed state and is connected to the subject 102. In addition to providing defibrillation, the defibrillator 112 may serve as a subject monitor via a variety of sensors or sensor packages. For example, as shown here, electrodes 108 connected to the defibrillator 112 have been applied to the subject 102 so that electrical shocking pulses may be provided to the electrodes in an effort to defibrillate the subject 102, and electrocardiogram (ECG) signals may be read from the subject 102. Further examples of use of the portable defibrillator are described, for example, in U.S. Ser. No. 13/398,280 filed on Feb. 16, 2012 and entitled “Coordinated Resuscitation Perfusion Support”, the contents of which are hereby incorporated by reference. The defibrillator operates according to a protocol that includes set of configurations stored on the defibrillator.
The defibrillator 112 may include an accelerometer assembly 110 configured to identify a vertical displacement caused by CPR compressions (e.g., to compute the displacement of the subject's breastbone for comparison to American Heart Association (AHA) guidelines). In response to receiving such information from the accelerometer assembly 112, the defibrillator 112 can provide feedback to a rescuer, for example, the defibrillator 112 may generate a metronome to pace such a user in providing chest compressions. In addition, or alternatively, the defibrillator 112 may provide verbal instructions to the rescuer, such as by telling the rescuer that they are providing compressions too quickly or too slowly, or are pushing too hard or too soft, so as to encourage the rescuer to change their technique to bring it more in line with proper treatment guidelines—where the proper treatment guidelines may be any protocol stored on the AED and need not be a protocol based on standard, published treatment guidelines. In addition, similar feedback may be provided visually on a screen of the defibrillator, such as by showing a bar graph or number that indicates depth and another that indicates rate, with appropriate mechanisms to indicate whether the depth and rate or adequate, too low, or too high. Examples of such feedback are described, for example, in U.S. Ser. No. 13/025,348, filed on Feb. 11, 2011 and entitled “Defibrillator Display”, the contents of which are hereby incorporated by reference.
The defibrillator can additionally be provided with a ventilation bag 104 that includes an airflow sensor 106. The airflow sensor 106 may be configured to monitor the flow of air into and out of the subject's mouth, so as to identify a rate at which ventilation is occurring with the victim. In addition, in certain implementations, the airflow sensor 106 may be configured to monitor a volume of airflow into and out of the subject 102. This information can be used to provide feedback to the rescuer about ventilation, for example, as described in U.S. Ser. No. 13/081,217 filed on Apr. 6, 2011 and entitled “Wireless Ventilation Reporting”, the contents of which are hereby incorporated by reference. The feedback provided to the rescuer is based on the protocol stored on the defibrillator.
The defibrillator 112 may communicate through a short range wireless data connection with the laptop computer 116 to provide to the laptop computer 116 status information, such as information received through the electrode assembly 108, including ECG information for the subject 102. Also, the defibrillator 112 can send information about the performance of chest compressions, such as depth and rate information for the chest compressions.
Where described herein, the processing and display of data may occur on the defibrillator 112, the laptop computer 116, or on both. For example, the defibrillator 112 may include a display that matches that of the laptop computer 116, and the two may thus show matching data. In contrast, the defibrillator 112 may have a more limited display than does the laptop computer 116, and might show only basic information about the technician's performance, while the laptop computer 116 may show more complete information such as secondary historic information. Also, the processing of primary information to obtain secondary information may be performed by the defibrillator 112, the laptop computer 116, or a combination of the two, and the two devices may communicate back and forth in various manners to provide to each other information they have received or processed, or to relay commands provided to them by the rescuer 114.
A central server system 120 may communicate with the laptop computer 116, the defibrillator 112, or other devices at the rescue scene over a wireless network and a network 118, which may include portions of the Internet (where data may be appropriately encrypted to protect privacy).
The defibrillator 112 and associated devices can function based on a protocol stored on the system. The configurations included in the protocol can be based on treatment guidelines, for example, based on the American Heart Association Guidelines for Cardiopulmonary Resuscitation (AHA CPR). The defibrillator can initially be installed to operate based on a standard protocol such as the AHA protocol, however, a user or owner of the defibrillator could override the initial configurations to have the device operate using a different protocol or to update the device as the protocols change. In some examples, the new or updated protocol could be downloaded from a central computer server to the defibrillation device. Such an approach may have the benefit of being able to easily update and modify settings/configurations of the AED to implement the desired protocol.
The computing device may then receive information about the performance by the rescuers, such as from wired or wireless transmitters on a defibrillator, an assisted ventilation unit, or other medical device (e.g., blood pressure reader). The computing device may provide feedback or coaching when the performance falls out of line with a defined protocol stored on the AED, or may provide feedback to maintain the performance in line with the protocol. In providing the feedback, the computing device or the defibrillator may generate a number of derived parameters from measured parameters of the subject, and both the measured parameters and the more comprehensive derived parameters may be reported visually or audibly by the computing device, the defibrillator/monitor, or both.
The communication between the defibrillation devices 200a, 200b, and 200c and the central server 206 can occur over a wireless network such as a cellular network. For example, the defibrillation devices 200a, 200b, and 200c can include a wireless transceiver for communicating with a wireless network, such as a 3G or 4G chipset that permits long distance communication over cellular data networks, and further through the internet. In additional examples, a tablet, laptop computer, or other computing device associated with the defibrillation device can include the wireless transceiver for communicating with the wireless network and the defibrillation device can include a short range communication chip to communicate with the tablet, laptop computer, or other computing device. In such an arrangement, the tablet, laptop computer, or other computing device communicates with both the central server 206 and with the defibrillation device.
As shown in
If the user selects to manually update the configurations (e.g., by selecting the manual update option by pressing button 310), the defibrillation device displays the current configurations and options for amending those configurations. For example,
If the user selects to automatically update the configurations (e.g., by selecting the automatic update option by pressing button 312), the defibrillation device displays a listing of available protocols as shown in the user interface 320 shown in
The list of protocols that are available can be filtered to assist a user in identifying a particular protocol. In some examples, the set of protocols is automatically filtered based on the model of the AED And some additional examples, a user can filter the list of available protocols to narrow the number of protocols to select from based on one or more features of interest to the user. For example, key features of protocols (such as key configurations) can be displayed and the user can select from drop-down menus to filter the available protocols based on the setting for a particular configuration. For example, as shown in
In some examples, protocols stored in the protocol database can have associated skill level indicators and the list of available protocols can be filtered based on an anticipated skill level of the rescuer. In some additional examples, a combination of language and skill level can be used to filter the list of available protocols.
The remote server receives the protocol information, including the configurations from the AED and stores the protocol information in the protocol database as a new entry (406). The user can select a name or identifier to associate with the uploaded protocol. Associating a user-selected name can enable the user or another user to later locate the protocol and download the protocol to additional AEDs.
After storing the configurations for the uploaded protocol, the central server sends a request for verification of the configurations for the protocol and a request for information about privacy settings to associate with the protocol (408). The AED receives the request (410), and provides any user-input updates and/or verification of the configurations and the requested privacy settings to the central server (412). The central server receives the user input response and, if needed, updates the stored configurations for the protocol (414). The central server also sets the privacy settings for the protocol (including any downloading restrictions) based on the privacy settings from the AED owner (416). For example, and AED owner may restrict download of their protocols to others within the same Corporation, others having the same hospital affiliation, other AEDs maintained by the same AED servicing group, etc.
In some embodiments, updates to a protocol (e.g., changes to one or more configurations of the protocol) can be automatically pushed to AEDs operating based on the protocol. For example, if an owner of an AED downloads the AHA protocol and the AHA protocol is later updated (e.g., one or more of the configurations is changed) then the updates to the configurations can be automatically sent to the AED As such, the initial protocol is downloaded by the user (e.g., pulled from the database at the central server) and the updates are automatically sent (e.g., pushed to the AED from the central server) to the AED
A number of embodiments have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. For example, much of this document has been described with respect to ICU monitoring with attending physicians, but other forms of patient monitoring and reporting may also be addressed.
In addition, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other embodiments are within the scope of the following claims.
This application is a continuation under 35 USC § 120 to U.S. patent application Ser. No. 15/587,435, filed on May 5, 2017 which is a continuation of U.S. patent application Ser. No. 14/809,378, filed on Jul. 27, 2015 which is a continuation of U.S. patent application Ser. No. 13/558,697, filed on Jul. 26, 2012 and issued as U.S. Pat. No. 9,119,971. All subject matter set forth in the above referenced applications is hereby incorporated by reference in its entirety into the present application as if fully set forth herein.
Number | Name | Date | Kind |
---|---|---|---|
6083248 | Thompson | Jul 2000 | A |
6088616 | Olson et al. | Jul 2000 | A |
6356785 | Snyder | Mar 2002 | B1 |
6370428 | Snyder et al. | Apr 2002 | B1 |
6397104 | Miller et al. | May 2002 | B1 |
6398744 | Bystrom et al. | Jun 2002 | B2 |
6492581 | Bradbury | Dec 2002 | B1 |
6747556 | Medema et al. | Jun 2004 | B2 |
6754526 | Daynes et al. | Jun 2004 | B2 |
6813517 | Daynes et al. | Nov 2004 | B2 |
6937150 | Medema et al. | Aug 2005 | B2 |
7672720 | Heath | Mar 2010 | B2 |
7723310 | Kerrish et al. | May 2010 | B2 |
7769465 | Matos | Aug 2010 | B2 |
7805190 | Chapman et al. | Sep 2010 | B2 |
7810723 | Boardman et al. | Oct 2010 | B2 |
7937146 | Banville et al. | May 2011 | B2 |
7979378 | West et al. | Jul 2011 | B2 |
8081071 | Vaisnys et al. | Dec 2011 | B1 |
8214043 | Matos | Jul 2012 | B2 |
8781577 | Freeman | Jul 2014 | B2 |
8880166 | Tan et al. | Nov 2014 | B2 |
9119971 | Elghazzawi | Sep 2015 | B2 |
9364625 | Silver et al. | Jun 2016 | B2 |
20030028219 | Powers et al. | Feb 2003 | A1 |
20030212311 | Nova et al. | Nov 2003 | A1 |
20030212438 | Nova | Nov 2003 | A1 |
20040064342 | Browne et al. | Apr 2004 | A1 |
20040214148 | Salvino | Oct 2004 | A1 |
20050015115 | Sullivan et al. | Jan 2005 | A1 |
20050085799 | Luria | Apr 2005 | A1 |
20060030891 | Saltzstein et al. | Feb 2006 | A1 |
20060084043 | Weaver et al. | Apr 2006 | A1 |
20060149321 | Merry et al. | Jul 2006 | A1 |
20070032830 | Bowers | Feb 2007 | A1 |
20070108274 | Boardman et al. | May 2007 | A1 |
20080138778 | Eggert et al. | Jun 2008 | A1 |
20090222539 | Lewis et al. | Sep 2009 | A1 |
20100234908 | Didon | Sep 2010 | A1 |
20100250643 | Savage et al. | Sep 2010 | A1 |
20110057082 | West | Mar 2011 | A1 |
20120081230 | Sullivan et al. | Apr 2012 | A1 |
20130012151 | Hankins | Jan 2013 | A1 |
20140025129 | Abbenhouse et al. | Jan 2014 | A1 |
Number | Date | Country |
---|---|---|
2007058835 | May 2007 | WO |
2007089225 | Aug 2007 | WO |
2009136259 | Nov 2009 | WO |
Number | Date | Country | |
---|---|---|---|
20190247672 A1 | Aug 2019 | US |
Number | Date | Country | |
---|---|---|---|
Parent | 15587435 | May 2017 | US |
Child | 16211266 | US | |
Parent | 14809378 | Jul 2015 | US |
Child | 15587435 | US | |
Parent | 13558697 | Jul 2012 | US |
Child | 14809378 | US |