Device and method for organizing and guiding treatment in a medical emergency

Abstract

A hardware device (or system of multiple integrated devices) that implements a medical emergency response protocol by receiving input identifying personnel present, assigning roles and tasks to the personnel based on their stored qualifications and capabilities, sending timed alerts to perform tasks specified by the protocol, accepting inputs indicating the tasks have been performed and that certain behaviors have been observed, and tracking and storing the timing, events, treatments, behaviors, and outcomes of the emergency response. The protocol may be a BLS / ACLS / PALS protocol. The device has dedicated timers for the overall procedure, compressions, and various medications. Many common tasks, medications, events, and outcomes have dedicated buttons, counters, and / or indicators. Role assignment involves scanning an ID, then accepting one or more of the task indicators. The underlying method can also be implemented through software on a computing device.

Description

DEVICE AND METHOD FOR ORGANIZING AND GUIDING TREATMENT IN AMEDICAL EMERGENCYREFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority from U.S. provisional application Numbers 63 / 631345, 63 / 631336, 63 / 698218, and 63 / 698222 the entire contents of which are hereby incorporated herein by reference.FIELD OF THE INVENTION

[0002] The present invention relates to a device used during a medical emergency, such as what is commonly referred to as a code blue, which could be any type of emergency resulting in arrest, pulseless, or clinical instability, such as cardiac arrest, pulseless arrest, systole, hypoxic arrest, hypovolemic arrest, neurogenic arrest, shock, or hypotension, in a hospital or outside the hospital, and, more particularly, a device that assigns roles and tasks to attending personnel, communicates with bystanders or treatment teams through the use of audio (verbal or otherwise), visual, motion, and the like, and guides the bystander or treatment team personnel through the correct steps of the medical emergency and directs behavior and medical decision making to improve adherence to known guidelines and reports and catalogs the treatment and procedures administered to a patient during a medical emergency for quality improvement and research initiatives.BACKGROUND OF THE INVENTION

[0003] Less than 10% of people survive an out-of-hospital cardiac arrest, while roughly 10-30% of patients survive an in-hospital cardiac arrest. If a patient suffers an arrest, priorities and roles for treatment by bystander and medical personnel are different depending on the location of the patient. If a patient is found down outside the hospital, and there are very few people around, the priorities are to call emergency medical professionals and start high quality Cardiopulmonary Resuscitation (CPR). On the other hand, if there are many people around, there are extra roles and tasks that could be accomplished and performed that may help the patient survive. If the arrest occurs in a hospital, the medical personnel may call a “code blue” where various hospital personnel immediately attend to the patient’s room. Regardless of the setting, these “code blue” or arrest situations are stressful, chaotic, andchallenging clinical scenarios that pose a significant risk to the patient. The tasks and roles of the responding personnel may seem clear in various best-practice guidelines, but they are challenging to coordinate in real life practice. Currently, strategies rely heavily on individuals supporting resuscitation efforts in whatever method they remember from their training. The assignment of roles or tasks based on the responding individuals’ level of expertise is an important factor in appropriately managing the medical emergency. Yet, tools to facilitate role and task assignment and direct the treatment strategy are not currently in use.

[0004] While attending to a “code blue” situation involving an arrest, medical personnel generally should follow the advanced cardiac life support (ACLS), basic life support (BLS), or pediatric advanced life support (PALS), or similar medical emergency guidelines. These guidelines are relatively straightforward, but due to the nature of the medical emergency, acuity of the patient, the level of verbal communication currently required, vast number of roles and tasks needed to be accomplished, and vast amount of clinical history available in the Electronic Health Record (EHR), following the guidelines is extremely challenging in real world practice. The current practice pattern provides little to no documentation about what actually happens during these emergencies, making it difficult to learn from and improve the outcomes. A key feature to the advancement of medicine in this clinical setting is first understanding what actually happens in these emergency situations, when these things happen, and accurately recording and tracking these events.

[0005] A number of mobile phone apps have been developed that provide some assistance in emergency situations. They typically include CPR counters and timers. Some include medication prompts and logs. At least one is known to provide a summary report. An example software application is U.S. Pat. No. 10,955,995 to Burch et al. which discloses computer software that renders graphical images of cycle timers, progress indicators, and guidance on a single field of view / window of the display device of the computer. It includes some automatic logs, prompts to the user to log events.

[0006] What is needed is a device or tool to address the assignment of roles and tasks, adhere to the medical emergency algorithms, limit the interruptions to compressions and other live-saving interventions, accurately track the emergency procedures, and advance medical knowledge in this clinical setting.SUMMARY OF THE INVENTION

[0007] The present disclosure provides a device to address the chaotic environment during a “code blue” situation. The device may be associated with a “code” cart, or anyemergency medical equipment both in and out of the hospital and used in a hospital when attending to a “code blue.” The device assists all attending personnel to quickly and easily assign roles in a clear, concise, efficient, calm, and effective manner. The device communicates with bystanders or treatment teams and guides the bystander or treatment team personnel through the correct steps of the medical emergency and directs behavior and medical decision making for the attending personnel in a clear, concise, efficient, and calm manner to improve adherence to medical guidelines. The device also reports and catalogs the treatment and procedures administered to a patient during a medical emergency, which is (1) provided to medical professionals to appropriately treat the patient; and (2) aggregated to larger data stores for quality improvement and research initiatives. Thus, all the latest analysis tools, such as artificial intelligence (Al), including generative artificial intelligence, machine learning, advanced neural networks, and the like, can be brought to bear to contribute to and grow the practice of emergency medicine,

[0008] The invention relates to hardware and associated software that allows attending personnel to assign themselves one or more roles upon entering the room during a “code blue” emergency situation and guides the bystander or treatment team personnel through the correct steps of the medical emergency and directs behavior and medical decision making to accomplish the high yield items that make a difference in patient survival. The device encourages appropriate compliance and performance in accordance with ACLS / BLS / PALS guidelines including code processes, medications, interventions, and outcomes. The device records events with minimal user involvement. The hardware includes microprocessor(s) or CPUs, non-transitory memory, and various communications interfaces as needed to carry out the many functions needed. The user interface is primarily a plurality of dedicated physical buttons labeled according to the particular task or role or input or function it is dedicated to, many with illumination options. The buttons are preferably raised from the device’s primary viewing surface for easy viewing from a wide angle and a distance. The user interface also includes dedicated digital / graphic displays for certain counters and functions. Other dedicated visual indicators may be included on the interface as will be described in more detail herein. The device may include user identification input, for example in the form of a badge or ID-card reader. The buttons, indicators, counters and displays are arranged in logical groups or sections of the interface to facilitate usage. Other features will be described herein.

[0009] The complexity of the functions of the device and the underlying software code matches that of the underlying predetermined protocol. Inputs indicating certain observedbehaviors or conditions trigger additional tasks or treatments specified by the algorithm or protocol. The protocol may be very complex, yet the user interface is simple to understand and easy to respond to, being primarily dedicated, labeled buttons, simple counter / timer displays, and lights. Additional buttons for tasks or treatments that may not be specified by the algorithm or protocol may be included on the user interface, as well as a button for “Other” conditions.

[0010] The invention is also related to methods of implementing predetermined guidelines such as ACLS / BLS / PALS guidelines in emergency situations using the device and the underlying software and algorithms to perform the functions described above.BRIEF DESCRIPTION OF THE DRAWINGS

[0011] FIG. l is a view of a device with associated clock, power switch, ACLS / BLS / PALS components, diagnostic assessments, medications, provider roles, and clinical outcomes according to an embodiment of the present invention.

[0012] FIG. 2 is a representation of some ways in which the device of FIG. 1 can be stood, held, or attached during use.

[0013] FIG. 3 is a flowchart of the device coding for a medical emergency protocol.

[0014] FIG. 4 is an alternate flowchart of the device coding for a medical emergency protocol.DETAILED DESCRIPTION

[0015] Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways, including the use of multiple devices, mobile, tablet, or computer software, and the like, voice recognition software and / or video in other embodiments.

[0016] The present invention is directed to a device that attaches to existing emergency medical equipment in the hospital or otherwise and incorporates haptic elements and visual elements, such as clocks / timers, buttons, counters, and lights, that allow for assigning roles / tasks, communicates with bystanders or treatment teams and guides the bystander or treatment team personnel through the correct steps of the medical emergency and directs behavior and medical decision making in adherence to ACLS / BLS / PALS guidelines, and allow for reporting and cataloging timing of treatments and performance, medications, and / orinterventions, encouraging ACLS / BLS / PALS compliance, and collecting de-identified cardiac arrest data through physical interaction with the device, voice recognition software, video, or the like for medical professional review, quality improvement, and research in a clinical setting.

[0017] The conventional process for running a code in a hospital is a high alert system that automatically communicates the patient location to all the code team members on-call at that time. A “leader” generally assigns roles and tasks verbally throughout the process. Outcomes are notoriously very poor for these patients (10-30% survival). Health-care industry attempt to improve the success of these stressful experiences and patient outcomes is centered around specific, detailed, and regular training courses for all providers and staff in the hospital. The cornerstones of this regular training involve: (1) the ACLS / BLS / PALS algorithm; (2) the team members and roles; and (3) clear, closed-loop communication by the code Team Leader.

[0018] In real clinical practice, bystander personnel or even in hospital code team medical providers are not frequently acquainted with one another, the environments are stressful, chaotic, and very loud, and the code team knows very little about the specific patient. All of which interfere with and are barriers to effectively communicating, providing appropriate and timely patient specific diagnostics, treatments, and interventions, and ultimately successfully saving the patient. The role of the Team Leader includes verbal attempts to communicate and assign roles / tasks to the many other team members in the room, attempts to attain clinical knowledge, verbally or otherwise, of the patient while assigning these roles, and attempts to make patient specific clinical decisions in this environment, all while attempting to follow the specific ACLS / BLS / PALS guidelines that involve precise, time sensitive, and urgent clinical decisions from a diagnostic, medication, intervention, and disposition standpoint. While periodic training is undoubtedly helpful, nothing can truly prepare bystander personnel or providers for any specific cardiac arrest situation when we factor in a patient’s risk, extensive medical history, recent medical history, goals of care, etc. Outside of providing periodic training, few people have attempted to improve adherence to the ACLS / BLS / PALS guidelines, tracking of provider decision making, clinical history, and therapeutics during cardiac arrests. Some have attempted to incorporate clinical decision support with the use of devices that track time, patient history, and some clinical data. But none have attempted to solve the largest barrier to success, namely the overall chaos of the situation. The present invention addresses this chaos by limiting unnecessary communication and controlling time sensitive communication by taking the assignment and communicationof assigning roles directly to team members, while providing clinical nudges to direct, guide, catalog, and study appropriate BLS / ACLS / PALS compliance. This quickly relieves much of the responsibility of the Team Leader to allow them to think more about the specific patient and in particular what steps might be most urgent and important in each specific situation. In some embodiments, this device may be utilized in two or even three pieces of equipment which may be attached to other equipment or held as suggested by FIG. 2.

[0019] The devices, systems, and methods disclosed herein help solve the real-world problem of removing unnecessary communication, assignment of roles / tasks, and compliance with BLS / ACLS / PALS guidelines from the working memory and mental load of the bystander personnel or medical providers and allow them to understand which specific steps to take next, focus more on the specific patient at risk in front of them, give the patient the best chance at survival. It also communicates with bystanders or treatment teams and guides the bystander or treatment team personnel through the correct steps of the medical emergency and directs behavior and medical decision making in adherence to guidelines. It catalogs and provides opportunities for research in this challenging area of medicine to research to guide future practice and guidelines.

[0020] The present invention is advantageous over existing solutions because this device is meant to actively guide the bystander or treatment team personnel through the correct steps of the medical emergency and direct behavior and medical decision making of the bystander personnel or medical providers and participate and contribute to assigning roles and running a successful code in adherence to guidelines along with the providers in any environment or clinical situation.

[0021] The device can be used in any medical emergency setting, such as what is commonly referred to as a code blue, which could be any type of emergency resulting in arrest, pulseless, or clinical instability, such as cardiac arrest, pulseless arrest, systole, hypoxic arrest, hypovolemic arrest, neurogenic arrest, shock, or hypotension, in a hospital or outside the hospital. If the patient is outside medical care (e.g., home, restaurant, any nonmedical facility), certain components of the device may or may not be feasible, but if the patient is within medical care (e.g., hospital, clinic, ER, urgent care, ambulance, etc.), more components of the device can and should be used.

[0022] The device includes: a main body housing its CPU, memory, communications (input and output) components, power supply, and control circuitry. It may also include attachment means for mounting or storage with cardiac arrest carts or other emergency medical equipment in and out of the hospital. The main user interface or surface includes dedicatedclocks / timers in accordance with BLS / ACLS / PALS algorithms, dedicated buttons for various diagnostics / medications / interventions / treatments in accordance with BLS / ACLS / PALS algorithms and clinical utility, dedicated buttons associated with roles / tasks to facilitate effective code team behavior in real-world situations, dedicated buttons for patient condition and outcomes and algorithm based on patient condition, visual indicators or light algorithms for guiding care based on the other buttons and clocks / timers in accordance with the BLS / ACLS / PALS guidelines, visible digital counters for the cyclic or frequently repeated components that occur repeatedly throughout a cardiac arrest scenario. The memory and CPU include the capability of storing and reporting de-identified data for further research and a clinical summary to inform the patient’s medical team during the process and for debriefing afterward. Other embodiments may include multiple devices, mobile, tablet, computer or the like, software applications, additional physical interaction with the device, voice recognition software, video, or the like. In some embodiments, in addition to lighting up of the device, sound may be used as well to notify when a particular step is needed or when a particular button is pushed, and in certain embodiments there may be inputs or software with free text capability, may be included voice recognition software, and / or may be included cameras, video, and the like. Such options may be associated with any or all of the buttons, timers, counters, displays, and functions described herein.

[0023] Although some embodiments of the present invention are directed towards in- hospital, cardiac arrest and the use of a cardiac-arrest cart or other emergency medical equipment, in some embodiments, the present invention can be used in any location of a patient or person suffering from any form of arrest / code and in any environment or location.

[0024] FIG. 1 shows a user interface of an example of a dedicated device (or “Code Clock”) according to the present invention. The device may be a single hardware device as shown in FIG. 1, or may be multiple devices integrated together, as long as it contains the described buttons, indicators and functionality. For example, the ID card reader may be an external device, or external displays, input devices, or memory, and the like, may be integrated with the device. It may be controlled by software programmed with the functionality , and in some embodiments the device may include external software to be included in existing devices in the hospital (such as iPads, computers, tablets, etc.) to provide some or all of the functionality described herein. In some embodiments, the device may incorporate patient specific history and information, as well as use artificial intelligence (Al) to add additional diagnostic, medical, or therapeutic strategies or next steps to provide more targeted patient care while operating within and supplementing the BLS / ACLS / PALSalgorithm guidelines. Although real physical buttons and indicators are preferred, in some embodiments the details described herein may be implemented as a touch screen or digital screen with inter-device communication. In some embodiments the functionality described herein may be used with audio or sounds as well as visuals or lighting to guide clinical nudges or prompts. In some embodiments, this device may be used as two or more separate pieces. For example, the clock and BLS / ACLS / PALS portion of the device may be located in every hospital room near the code button in the room, and the roles / tasks portion of the device may be an attachment to medical equipment elsewhere in the room or brought into the room as needed. In some embodiments, some portions of this device may be implemented as software on a separate device, while other functions remain a hardwired portion of this hardware device.

[0025] Turn now to a detailed description of the exemplary embodiment of FIG. 1. Broadly, the device shown is organized in such a way as to categorize different aspects of managing an arrest or “code blue.” For example, in the embodiment demonstrated in FIG. 1., the ACLS guidelines are included on the left (reference numerals 3-7), the main clocks are at the top (reference numerals 2-3), the rhythm or arrest type is on the right (reference numerals 8-13), with the medication section (reference numerals 14-28) next, followed by the roles and / or tasks (reference numerals 29-41), and the patient outcome section and whiteboard is at the bottom (reference numerals 46-49 and 63). In other embodiments the categorization and layout may be changed to facilitate the ease of use of the device for specific emergencies. What follows describes the sections or categories of the embodiment of FIG. 1 to provide more details as to how the buttons are organized and grouped and their respective functions. The function descriptions follow the FIG. 3 flowchart.

[0026] The roles section of the device may include a badge reader 50, (shown as a rectangle since it may be considered internal and touchless, although it could be a slide reader on the side of the device). Any suitable badge reader or identity verification may be used, such as touchless, RFID, magnetic strip, or the like. The device may then quickly look up individuals and determine their qualifications and capabilities. The lookup may be internal to the device memory or from an external database or device. This feature enables the device to assign personnel who are present to specific roles and tasks, but only to those roles or tasks which the specific individual is capable of performing. This feature streamlines and hastens a key aspect of teams treating people in medical emergencies, greatly reducing the chaos of the situation.

[0027] The ON / OFF switch 1 will be used to power the device when an arrest begins., and in certain embodiments this may be a software switch within the EHR.

[0028] In FIG. 1, the upper left side of the device includes the emergency ALGORITHM section, i.e., an implementation of basic life support or CPR (buttons 3-7). After powering up the device and arrest is confirmed, Code Start Button 2a, will be pressed, which will start the Top Clock 2 which starts at 0:00:00 and counts continuously up until the END code button 46 is selected. Each button push and each clock generates data which is collected and stored electronically, for example, in the microchip 64. In accordance with certain embodiments this data storage may be by means of software in the EHR, thus utilizing existing hardware in a patient’s room.

[0029] Once button 2a is pressed and top clock 2 begins time recording, the Pulse Check / Rhythm Check Button 3 will begin to flash red, suggesting to the team to attempt a pulse check / rhythm check as soon as they can with an automated external defibrillator (AED). Once pressed this button will turn colorless until the next pulse check rhythm check is due at 2 minutes. Each time button 3 is pressed, the digital counter keeping track of the number of pulse check / rhythm check occurrences will tally / count an additional occurrence and the total will display on pulse display 3a. At the beginning of the code, the pulse check / rhythm check timer 3b will not start because the first such check should be done as quickly as possible. After the first pulse / rhythm check, 3b timer / clock will start a 2-minute timer. At 90 seconds the pulse check / rhythm check 3 will begin flashing yellow and at 2:00 minutes, this button will begin flashing red, similar to the flashing red at the beginning of the code. Once button 3 has been selected, timer 3b will then start at 10 seconds and count down to 0 seconds to direct and guide the bystander or medical personnel not to stop compressions for longer than 10 seconds (as this has been shown to reduce perfusion). Buttons 8, 9, 10, 11, and 12 will then flash yellow prompting the providers to label the rhythm and / or identify the type of arrest. At the time ANY of these items are selected they will ALL become colorless / stop flashing). After the 10 second timer is up, the compression button 4, shock button 5, and return of spontaneous circulation (ROSC) button 47 will flash red, suggesting to the team to address these concerns right away given the recommendations by the American Heart Association (AHA) for limiting down time between compressions. If buttons 4 or 5 are selected, indicating compressions or shock being administered, respectively, then timer 3b restarts its 2:00 minute timer and the process restarts. Each round and occurrence is time stamped, counted, and stored in the microchip 64 or other memory, in accordance withcertain embodiments. It may be noted that this data storage process applies to any or all of the buttons, timers, counters, displays, and functions described herein.

[0030] The CPR section in FIG. 1 includes Compressions button 4, and compression counter 4a. In addition to the above, when button 2a is pressed the compression button 4 starts flashing yellow suggesting someone should start compressions. Every time 4 is pressed, 4a then counts and displays the number of occurrences which is also stored in memory.

[0031] In FIG. 1, Epinephrine (EPI) button 6, and epinephrine counter 6a will be working in association with the top clock 2. From the start of the code (selecting button 2a), the EPI button 6 will flash yellow at 3 minutes, then flash red at 5 minutes. After pressing the EPI button 6, this will restart the 3- and 5-minute timer algorithm. If held down longer, this button will turn blue which means an EPI drip has been started and running. Once pressed, you can continue to press this button for additional doses (also referred to as pushes or boluses) which will be ‘counted’ in the memory for documentation purposes. Every time button 6 is pressed, counter 6a then counts and displays the number of occurrences which is also stored in memory 64. The display may be digital, graphic or lights. In certain computer-implemented embodiments the software may indicate the type of dosing, whether pushes or continuous infusion. It may be noted that for any of the medications and associated medication buttons describe herein, the button-pressing options for pushes or continuous infusion may be present, as well as the display thereof and the data storing process, even if not mentioned explicitly below.

[0032] In FIG. 1, Amiodarone (AMIO) button 7, and amiodarone counter 7a will be working in association with the EPI button 6, VT button 8, VF button 9, and Shock button 5. This button 7 will flash yellow AFTER the EPI 6 button has been selected at least once, EITHER the VT 8 or VF 9 buttons have been selected at least once, AND the Shock button 5 has been selected at least once. Every time button 7 is pressed, counter 7a then counts and displays the number of occurrences which is also stored in memory, and again, this button may indicate either pushes or continuous infusion.

[0033] In FIG. 1, the top right portion (buttons 8-13) of the device is the RHYTHM or ARREST section which is designed to guide the next steps based on the clinical scenario presented, i.e., the type of arrest or rhythm identified. For example, shock button 5 will flash as documented above in accordance with the algorithm or guidelines being followed. Depending on the type of rhythm and other events triggered and on the algorithm being followed, other actions could also be triggered. Every time button 5 is pressed, counter 5athen counts and displays the number of occurrences which is also stored in memory. It may be noted that not all arrests involve abnormal rhythms, so ARREST is the more general term for this section of buttons. Nevertheless, it may be referred to sometimes as the RHYTHM section even though other arrest types are also in this section.

[0034] In FIG. 1, Ventricular tachycardia VT button 8, VT counter 8a, in addition to the above, if selected will result in the Shock button 5 flashing, and will turn off buttons 8, 9, 10, 11, and 12. If selected more than twice, it will result in the Extracorporeal membrane oxygenation (ECMO) button 48 flashing. Each time button 8 is pressed, counter 8a then counts and displays the number of occurrences which is also stored in memory.

[0035] In FIG. 1, Ventricular fibrillation VF button 9, VF counter 9a in addition to the above, if selected it will result in the Shock button 5 flashing, and will turn off buttons 8, 9, 10, 11, and 12. If selected more than twice, it will result in the ECMO button 48 beginning to flash. Each time button 9 is pressed, counter 9a then counts and displays the number of occurrences which is also stored in memory.

[0036] In FIG. 1, Asystole (ASY) button 10, ASY counter 10a, in addition to the above, will flash yellow after every time the pulse check / rhythm check button 3 is pressed. When button 10 is pressed, this will result in Compression Button 4 flashing, and will turn off buttons 8, 9, 10, 11, and 12. Each time button 10 is pressed, counter 10a then counts and displays the number of occurrences which is also stored in memory.

[0037] In FIG. 1, Pulseless electrical activity (PEA) button 11, PEA counter I la will follow the same functionality as the ASY button 10.

[0038] In FIG. 1, Other rhythm (OTHER) button 12, OTHER counter 12a will follow the same functionality as the ASY button 10.

[0039] In FIG. 1, Total arrest / rhythm counter 13, will display the total number of occurrences, which should match the pulse check counter 3a and equal the total of counters 8a, 9a, 10a, I la, and 12a. It can be seen that the interdependencies between the ARREST and CPR have the potential to reduce mistakes and relieve the much of the burden of manually implementing the protocol.

[0040] In FIG. 1, the middle right section of the device is the MEDICATION section of the device (buttons 14-28). Some medications are part of the protocol while others are frequently given depending on the particular circumstances and at the team’s discretion. The protocol medications generally get buttons that have multiple lighting indications as well as counters. The lighting style may indicate whether the medication is pushed or continuous, while the counters may indicate the number of pushes or boluses. Other medications such asCa, Mg, and Narcan are not generally part of the protocol, but have no detrimental side effects, so are primarily recorded with a simple push of their dedicated button, and visible lights or counters are not needed although some will utilize the blue-light indication for a drip. Nevertheless, all events are counted and recorded in the background, even if not displayed.

[0041] Sodium bicarbonate (BICARB) button 14 will remain colorless, but is there to document use of this medication. No total counter will be displayed, but times and number of occurrences will be stored in memory. If held, it will turn blue to represent a drip has been started, as with many other medication buttons.

[0042] Calcium chloride or gluconate (Ca) button 15 will remain colorless, but is there to document use of this medication. No total counter will be displayed, but it will be documented as with other medications. If held, it will turn blue to represent a drip has been started.

[0043] Naloxone (NARCAN) button 16, this will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0044] The Dextrose or the “D50” button 17 (to indicate doses of dextrose or other glucose equivalent), will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0045] The Magnesium button 18 will remain colorless, but is there to document use. If held, it will turn blue to represent a drip has been started.

[0046] The Lidocaine button 19 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0047] The Adenosine button 20 will remain colorless, but is there to document use. No total counter will be displayed. This does not have the drip feature.

[0048] The IV Fluids button 21 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0049] The Blood Products button 22 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0050] The Dopamine button 23 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0051] The Norepinephrine (NOREPI) button 24 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0052] The Vasopressin (VASO) button 25 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0053] The Tissue plasminogen activator (TP A) button 26 will remain colorless, but is there to document use. No total counter will be displayed. No drip feature will not be included in this button.

[0054] The Atropine button 27 will remain colorless, but is there to document use. No total counter will be displayed. No drip feature will not be included in this button.

[0055] The Insulin button 28 will remain colorless, but is there to document use. No total counter will be displayed. If held, it will turn blue to represent a drip has been started.

[0056] In FIG. 1, the middle portion of the device is the ROLES and TASKS section of the device. Upon pressing the Code Start button 2a, Defibrillator Pads (PADS) button 29 will flash yellow until pressed. When pressed, it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task. It may be noted that in some embodiments additional indications or prompts can be implemented in connection with any or all of the role and task assignments and acceptances, such as audio, voice recognition, cameras and video, and the like.

[0057] In FIG. 1, also upon pressing the Code Start button 2a, Backboard button 20, will flash yellow until pressed, reminding personnel assigned to this task to implement a backboard under the patient. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task.

[0058] In FIG. 1, also upon pressing the Code Start button 2a, Pulse checker button 31 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0059] In FIG. 1, upon pressing the Code Start button 2a, AED operator (AED) button 32 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0060] In FIG. 1, upon pressing the Code Start button 2a, Team Leader (LEADER) button 33 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0061] In FIG. 1, upon pressing the Code Start button 2a, Recorder button 34 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0062] In FIG. 1, upon pressing the Code Start button 2a, Airway manager (Airway) button 35 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0063] In FIG. 1, upon pressing the Code Start button 2a, Computer orders member (Orders) button 36 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0064] In FIG. 1, upon pressing the Code Start button 2a, Pharmacy button 37 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0065] In FIG. 1, upon pressing the Code Start button 2a, Medication administrator (MEDS) button 38 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0066] In FIG. 1, upon pressing the Code Start button 2a, Access (IV / IO) button 39 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0067] In FIG. 1, upon pressing the Code Start button 2a, Lab drawer (Labs) button 40 will flash yellow until pressed. When pressed this means a team member has takenresponsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0068] In FIG. 1, upon pressing the Code Start button 2a, Family communicator (FAMILY) button 41 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0069] In FIG. 1, upon pressing the Code Start button 2a, Ultrasound button 42 will flash yellow until pressed. When pressed this means a team member has taken responsibility for that task / role. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0070] In FIG. 1, upon pressing the Code Start button 2a, Intubation button 43 will flash yellow until pressed. When pressed this means this procedure is completed. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this role.

[0071] In FIG. 1, upon pressing the Code Start button 2a, Art Line button 44 will flash yellow until pressed. When pressed this means this procedure is completed. At which time it will time stamp the task completion in the microchip 64 and turn colorless suggesting the completion of this task or assignment of this

[0072] In FIG. 1, upon pressing the Code Start button 2a, Event button 45 will remain colorless, and will only be pressed when an element outside the typical code procedures occurs. It does not need to be pressed, but when pressed it will time stamp an “event” in the microchip 64. These events can be identified along with the other button 12 information using whiteboard 63.

[0073] The patient outcome section and whiteboard are at the bottom of the user interface (reference numerals 46-49 and 63). In FIG. 1, upon pressing the Code Start button 2a, End Code (END) button 46 will remain solid white suggesting that when appropriate the team member should press this. When this button is pressed the Top Clock 2 should stop, the pulse check / rhythm check clock 3b should stop, and the ROSC 47, ECMO 48, and Palliative Cessation (Death) 49 buttons should flash yellow suggesting the selection of one of those outcomes. Again, in certain embodiments this may include free text capability, may include voice recognition software, and / or may include cameras and video, and the like.

[0074] In FIG. 1, in addition to the above, Return of Spontaneous Circulation (RO SC) button 47 will flash yellow only after the End Code button 46 is selected. Once selected this should result in ECMO 48 and Palliative Cessation (Death) 49 to stop flashing and should signal to the microchip 64 to ‘complete’ this instance or process, store the data associated with this specific code, and make it available to upload or upload it to a server for analysis which may include storing in a dedicated database, combining with other data, conventional statistics, or even utilize continuous artificial intelligence (Al), machine learning, or the like for data analysis.

[0075] In FIG. 1, in addition to the above, ECMO button 48 will flash yellow only after the End Code 46 button is selected. Once selected this should result in ROSC 47 and Palliative Cessation (Death) 49 to stop flashing and should signal completion and data upload as with the ROSC button.

[0076] In FIG. 1, in addition to the above, Palliative Cessation (Death) button 49 will flash yellow only after the End Code 46 button is selected. Once selected this should result in ROSC 47 and ECMO 48 to stop flashing and should completion and data upload as with the ROSC button.

[0077] In FIG. 1, as mentioned earlier, there is a badge or RFID reader 50 to assign roles to participating team members as they enter the code environment. When 50 is tapped the available roles will light, prompting the member to choose one or more roles appropriate for their expertise. This information is also stored for quality improvement initiatives as the health system will be able to reach out individuals that were involved in each code and discuss what went well, what could be improved, and debrief which has been shown to improve providers mental health following emergency medical events such as various types of arrests or codes. De-identified data may be uploaded to a server for analysis which may utilize continuous Al for data analysis in certain embodiments.

[0078] In FIG. 1, Audio / Video (AV) and / or USB port 51 or other media connection technology may be provided between the device and any AED to serve for data communication from the AED to our device for identification of rhythms, shock treatments, heart rhythm data, and other aspects of the clinical situation captured by the AED. This data can be transferred to our device for data storage and / or analysis, and subsequently uploaded to a server for further analysis as described above.

[0079] In FIG. 1, a second AV and / or USB port 52, or other media connection technology may be provided between the device and any existing monitors in the patient’s room such as blood pressures, respiratory rates, arterial line pressures, oxygen saturation,heart rates, and any other data captured by monitors and medical technology in the patient’s hospital room. This connection serves for data communication from the monitoring system to our device for data collection, and for subsequently uploading it to a server for analysis as mentioned earlier.

[0080] In FIG. 1, Speakers 53 and / or larger lights 56 may be present along the back and top of the device serving as an audio cue or verbal demand or visual cue when certain BLS / ACLS / PALS steps are crucial to perform or consider. This is one feature that aids in communication to the bystander and / or medical provider in addition to lights to guide and direct them towards the next best step for the patient, and may include voice recognition software, and / or may include cameras and video, and the like.

[0081] In FIG. 1, wireless communication capability 54, such as Bluetooth® capability, may be used to communicate summaries of the clinical event to other devices, including timing of and occurrence of different diagnostics and treatments delivered to the patient, and to upload data to a server for analysis as described above.

[0082] In FIG. 1, Strap or Handle 55 may be constructed from one or more materials, such as plastic, polyester, rayon, poly-para-phenylene terephthalamide (e.g., KEVLAR®), hook-and-loop fasteners (e.g., VELCRO®), leather, polyurethane, and the like and used for storage, transportation, and / or use of the Code Clock and to interface physically with medical equipment and or personal equipment, including but not limited to a patient’s bed, IV poles, a code cart, etc. Any commonly used method of affixing, such as snaps, buttons, hook- and-loop fasteners, zippers, magnets, glue, inserting into a pocket, and the like can be used with or on the device and adjusted to fit larger or smaller sizes.

[0083] In FIG. 1, Display screen 57 with simple text may show or demonstrate information, such as the last action or event performed, in order to provide user(s) with reassurance that the action was registered by the device. Screen 57, can also be used to display summary text when prompted, such as button pushes, totals of the various counters, medical events, medications, and medical interventions, etc. In certain embodiments this may include software with free text capability, may include voice recognition software, and / or may include cameras and video, and the like.

[0084] Some tasks involve multiple occurrences or types of administration and an indication of the number of occurrences and / or the type of administration may be important for the protocol being followed and for the team to know. For example, medications may be administered in doses / pushes / boluses or continuously. Such information displays may be implemented in the device with digital counters, pictorial indicators (icons), or lights. As oneexample, in FIG. 1, Medication Lights 58 include a number of closely spaced lights which can demonstrate how many times a medication has been given by how many are lit. Continuous medication light 59 is spaced apart from lights 58 and thus can show whether a medication is being run continuously. Similar lights are shown in FIG. 1 for each of the Bicarb, Ca, and Narcan buttons, and could be provided for any of the other medication buttons if desired.

[0085] In FIG. 1, Pause / Restart button 60 may be utilized in cases when a person is resuscitated for a short period of time (a Pause of the emergency algorithm) and then suffers an additional cardiac arrest (requiring a Restart of the algorithm) or other possible occurrences leading to temporary pausing of the resuscitation efforts.

[0086] In FIG. 1, View button 61 is to be utilized when teams are attempting to review total amounts given and briefly look at summaries throughout ongoing resuscitation measures. Totals will be displayed on display screen 57 when View button 61 is selected.

[0087] In FIG. 1, Undo Button 62 will be utilized when mistakes are made on the device, and will undo the last action performed and recorded in microchip 64.

[0088] An input device for notes may be implemented in the device or software if desired. In FIG. 1, Whiteboard 63 for documentation, can be used, for example to help document extra-protocol information or events, such as the reason the other Events button 45 is pressed. Thus, the device may have a means for quick recording of notes by a team member, which otherwise are often done in random places in the room, on windows, or on whiteboards. Whiteboard 63 may be a literal, dry-erase whiteboard, an electronic whiteboard, or other form of written input device / technology such that if some "other" behavior (button 12) or something outside the device algorithm is performed it can be noted and documented on the device.

[0089] Item 64 on FIG. 1 represents a memory, microchip, CPU or circuit board (or a system thereof) with all the necessary capability for running the code and for data storage and transfer, which may include data transfer to a centralized database as well as methods to transfer to individuals for summary reports of the specific medical emergency.

[0090] FIG. 2 demonstrates the general use concept of the device as it relates to positioning within the room. The device is adaptable to a wide variety of code / room / patient specific situations and uses. The device can be used in any location or environment. FIG. 2 illustrates specifically use in a room with a stand (1), mounting on an IV pole (2), placement on a crash cart (3), placement with an AED (4), and being hand-held by a team member (5).

[0091] There are many emergency algorithms that could be implemented in the inventive device or in various embodiments thereof. Of particular note are various algorithms taught by the American Heart Association (AHA). One example is the flowchart representing the BLS (Basic Life Support) guidelines from the American Heart Association (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR-Guidelines- F il es / Algorithms / AlgorithmBLS_Adult_200624. pdf) .

[0092] Another example is the flowchart representing the ACLS guidelines from the American Heart Association (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR- Guidelines-Files / Algorithms / AlgorithmACLS_CA_200402.pdf).

[0093] Another example is the additional workflow and flowchart representing the ACLS circular algorithm guidelines from the American Heart Association (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR-Guidelines-Files / Algorithms / AlgorithmACLS_CA_Circular_200612.pdf).

[0094] The inventive device can implement the critical team member roles and tasks of an exemplary 6-person high-performance resuscitation team as depicted in another chart from the American Heart Association (available at https: / / cpr.heart.org / - / media / cpr2-files / course- materials / 2020-bls / 2020-course-materials / team-dynamics-diagram_ucm_506677.pdf).

[0095] Another example is the flowchart and algorithm from the American Heart Association for bradycardia (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR- Guidelines-Files / Algorithms / AlgorithmACLS_Bradycardia_200612.pdf).

[0096] Another example is the flowchart and algorithm from the American Heart Association for tachycardia (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR- Guidelines-Files / Algorithms / AlgorithmACLS_Tachycardia_200612.pdf).

[0097] Another example is the flowchart and algorithm from the American Heart Association for opioid associated emergencies (available at https: / / cpr.heart.org / - / media / CPR-Files / CPR-Guidelines-Files / Algorithms / AlgorithmOpioidHC_Provider_200615.pdf).

[0098] Another example is the flowchart and algorithm representing the PALS guidelines from the American Heart Association. Available at https: / / cpr.heart.org / - / media / CPR- Files / CPR-Guidelines-Files / Algorithms / AlgorithmBLS_Ped_2_Rescuers_200624.pdf.

[0099] FIG. 3 is an example flowchart of the inventive device’s coding of an ACLS medical emergency algorithms which the device is configured to follow.

[0100] FIG. 4 is another flowchart example with some differences from FIG. 3. One difference is that medication buttons in Fig. 4 use a double press to indicate drip instead ofthe longer press used in FIG. 3. Also, a bolus indication or single press of a medication light is indicated with a green light and a drip with a blue light. This illustrates that in general, any desired indicator light color, or button press pattern, could be implemented in order to convey the information to the team or receive the input from the team. The specific examples presented are examples of one possible way to carry out the invention.

[0101] Another difference is that FIG. 4 has a new “flash roles button” branch, including causing it to flash right after the start of the algorithm in order to prompt the team to get their assignments and / or acknowledge assignments. A “scan for button press” branch is also explicitly included in FIG. 4, to distinguish the startup routines “start clocks” and “flash roles button” from the ongoing process branches under the “scan for button press” branch. FIG. 4 also includes a “View or Undo button pressed” branch to implement previously described view button 61 and undo button 62.

[0102] The invention may be a dedicated hardware device or software utilizing or implemented on an organization’s existing hardware, comprising a checklist of needed roles, tasks to handle a medical emergency such as an arrest or code. The device implements an algorithm such as the BLS / ACLS / PALS algorithm. It may communicate through the use of audio (verbal or otherwise), visual, vibration or other motion, and the like with bystanders or medical providers. It communicates with bystanders or treatment teams and guides the bystander or treatment team personnel through the correct steps of the medical emergency response algorithm. It directs behavior and medical decision making through the complex logistical and algorithmic details of an arrest. It can thus help alleviate the team members of much of the mental workload, improve communication through cues by the use of audio (verbal or otherwise), visual, vibration or other motion, and the like during the chaotic code environment, improve adherence to the best practices of algorithms like the BLS / ACLS / PALS algorithms that are known to improve patient survival. It can report and catalog data of events and timing to provide summaries to the patient’s medical team, and compile de-identified aggregated data for quality improvement and research endeavors. The need for help in this space is large, as survival for OOH (out-of-hospital) arrest is <10%, and in-hospital arrest is 10-30%. This device is meant to run a code more effectively by driving the assignment of team members to roles / tasks upon entering the room, minimizing human errors in running a code, limiting non-essential communication, emphasizing early communication with family, streamlining decision-making by allowing the team to focus on patient specific risk factors and potential arrest etiologies, obtaining needed clinical tools, such as ultrasound, to aid in early diagnostic accuracy, and capturing real-time data foraccurate documentation and assessment. As a dedicated hardware device, it may be attached to existing emergency medical equipment and / or code / crash carts. It provides for a variety of storage and use capabilities to match the device to any particular code situation or environment. As software, implemented on a computing device or other common hardware, it may do much of the same functions using screen graphics and various input devices. Either way, it may include voice recognition software, and / or may include cameras and video, and the like. Its use is not limited to hospitals, as using any specific portions of the device would be helpful in any in- or out-of-hospital arrest.

[0103] It should also be noted that depending on the algorithm, various buttons could be interacting with each other, dependent or independent of other buttons, lights or timers, and may trigger an alert via audio, visual, or otherwise, as well as communicate with the microchip or other data transfer software, and participate in the artificial intelligence, data storage, or analysis. The buttons may include lights / icons / or indicators on the button itself, near the button, on the display screen, or there may be the use of lights, sounds, and other alert techniques that notify the user of successful use of the button.

[0104] Functional Summary of the device:

[0105] Once a code process is started, one of the critical functions involves the roles of the personnel present and the tasks required by the protocol. The device thus receives input for identifying personnel and assigns roles and tasks to appropriate personnel. By following the protocol, it prioritizes roles and tasks in order of urgency / importance, and identifies and prioritizes next roles and tasks needed. Prioritization takes into account previously assigned roles and personnel who have already checked in. It guides the behaviors of personnel by providing alerts for the next roles and tasks to be completed. It also accepts inputs for roles and tasks needed, assigned, completed, or performed. The input is done by simply pressing the appropriate button(s), and the prompting is done by illuminating the appropriate button(s) or associated lights. Urgency may be indicated by light color and / or flashing pattern. A button is also provided to make the device summarize or communicate needed roles or tasks to be done, and those that are completed. The device tracks and stores the amounts and timing of events, treatments, behaviors, and outcomes of the emergency response. It can display the most recent, total count, and timing of all inputs. If implemented on a display screen, virtual buttons and lighting graphics may be used. In addition, the device could be equipped to recognize voice commands, use audio, vibrations, video or pictorial or other inputs and prompts.

[0106] It is important to note that the inputs indicating certain behaviors observed trigger additional tasks specified by the algorithm or protocol. The complexity of the device’s functions thus matches that of the underlying protocol. The protocol may be complex, yet the user interface is simple to understand and easy to respond to, being primarily dedicated, labeled buttons, simple counter / timer displays, and lights, albeit lots of them. In addition, common therapies that may be outside of current protocols may be provided for with dedicated buttons and tracked. A button for “Other” conditions and other “Event” is provided.

[0107] The process of running the code is the primary function of the device. Once the device receives input notifying of medical emergency and assigns an appropriate emergency response algorithm, it starts a series of clocks and / or timers, some of which are dependent on other clocks / timers or inputs, others are independent of other clocks / timers or inputs in accordance with guidelines / algorithm. The clocks and timers guide personnel behaviors, medical treatments, and medical interventions for an emergency response in accordance with the protocol, guidelines or algorithms assigned. The device receives inputs of emergency response actions taken and guides / alerts / triggers / assigns other clocks / timers / alerts to change, reset, pause, or end, in accordance with the guidelines. Received inputs may trigger / alert / assign other roles or tasks or behaviors to be completed, started, or re-done in accordance with guidelines / algorithms. The device may trigger / alert / assign additional medical interventions or therapies to be started / completed / redone in accordance with guidelines. It may then display medical therapies or interventions, including indications of boluses or continuous drips of medications and totals thereof, compressions, shocks, and the like with the use of display windows, lights, tallies, and the like. As mentioned above, the primary means of input and prompting are the dedicated buttons for roles, tasks, and medical therapies or interventions. Likewise, the amounts and timing of events, treatments, behaviors, and outcomes of the emergency response are stored in memory. Clocks and timers may pause, restart, and continue timing in the background until the emergency response has ended. Clocks / timers may change based on inputs in accordance with guidelines. The device can display most recent, total, and timing of all inputs. Such documentation is important for improving medical technology. Therefore, the device also includes a whiteboard or other electronic writing capability to document other events, interventions, therapies, outside the device’s capability.

[0108] Finally, the outcomes of the process are reached and documented. When the end of the code response is indicated, the device prompts for input of the outcome. Again,dedicated, labeled buttons are used for this. The device may pause the display though continuing to run the main timer in the background in case the response must be restarted. If restarted, the display will update to the total time and keep the algorithm running in accordance with guidelines. If not restarted, an input finalizing the emergency response will complete this event / occurrence on the device and finalize the stored summary report.

[0109] Other features include the ability to attach the device to existing medical equipment for storage or in use. It may also communicate with other medical equipment such as monitoring devices. It may utilize and transfer information and patient specific data, such as risk factors from monitoring devices to the device. It may synthesize input from other monitoring systems and guide medical therapy or interventions based on these inputs and the protocol or guidelines.

[0110] Finally, data storage, data transfer, and data analysis are provided with the device. All events, clocks, inputs, interactions are stored in the device memory. All individuals present are stored in the device based on their unique ID / badge / card. The device may incorporate microchip / USB / QR code / Bluetooth™ or other wired or wireless communication. A complete summary report is retrievable for use of the emergency response team with a unique report ID. A complete summary report can be uploaded / stored in a central database for analysis. Events will then be retrievable, based on the unique report / emergency ID. One can utilize artificial intelligence and machine learning algorithms to facility data analysis and guideline recommendations.

Claims

CLAIMS1. A hardware device that implements a predetermined medical emergency response protocol, the device comprising: a housing in which resides a computer system comprising CPU, memory, input circuitry and output circuitry, said computer system adapted to carry out all functions of the device; and a user interface comprising a plurality of buttons, lights and displays mounted on the housing, the buttons, lights and displays organized into logical sections including an arrest-type section, a CPR section, a medication section, a roles and tasks section, and a outcomes section.

2. The hardware device of claim 1 wherein each said button, light and display is labeled with and dedicated to a particular purpose within the protocol.

3. The hardware device of claim 1 further comprising an ID reader.

4. The hardware device of claim 3 wherein presenting a valid ID to said ID reader initiates a lookup of the ID owner’s qualifications and illumination of buttons in the roles and tasks section corresponding to roles and tasks which the ID owner is qualified for.

5. The hardware device of claim 4 wherein pressing one or more of said illuminated buttons in the roles and tasks section is recorded as acceptance of said corresponding roles and tasks by said ID owner.

6. The hardware device of claim 1 wherein the arrest-type section comprises a plurality of lighted buttons labeled with different arrest types and adapted for indicating and recording an arrest type observed during a medical emergency.

7. The hardware device of claim 6 wherein selecting one arrest type by pressing its lighted button turns off the buttons for the other arrest types and lights up one or more task buttons to prompt for the associated tasks in accordance with the protocol.

8. The hardware device of claim 1 wherein the CPR section comprises a Pulse and Rhythm check timer and display, a compression button and timer, a shock button, and an EPI button and timer.

9. The hardware device of claim 1 wherein the medication section comprises a plurality of medication buttons, each labeled and dedicated to prompting for and recording the administration of a particular medical therapy according to the protocol.

10. The hardware device of claim 9 wherein the device is adapted to accept two types or durations of button presses of at least one of the medication buttons, one of which type of press is interpreted by the device as indicating a bolus and the other as indicating a drip, and wherein lighting associated with the at least one medication button is adapted to display one of two different colors to correspond to the indication of bolus or drip.

11. The hardware device of claim 1 adapted to: receive input identifying personnel present; assign roles and tasks to the personnel; send timed alerts to perform tasks specified by the protocol; accept inputs indicating the tasks have been performed and that certain patient behaviors have been observed; and track and store the timing, events, treatments, behaviors, and outcomes when employed during a medical emergency response.

12. The hardware device of claim 1 wherein the inputs indicating certain behaviors observed trigger one or more additional tasks specified by the protocol, wherein said trigger comprises turning on a light or starting a timer associated with the one or more additional tasks.

13. The hardware device of claim 1 wherein a plurality of the alerts comprise lights, at least one timer comprises a clock display, and a plurality of the inputs comprise buttons.

14. The hardware device of claim 1 wherein a card or badge reader is integrated into or with the device and receives said input identifying personnel.

15. The hardware device of claim 1 wherein the hardware device comprises a system of multiple integrated devices.

16. The hardware device of claim 1 wherein the user interface is a single display, and the buttons, lights and displays are virtual buttons, lights and displays rendered graphically on the display.

17. A software product stored in a non-transitory computer-readable medium storing executable instructions that, when executed by a processor, controls the functions of the hardware device of claim 11.

18. A method of responding to a medical emergency in accordance with a predetermined protocol, the method carried out by a hardware device comprising a housing in which resides a computer system comprising CPU, memory, input circuitry and output circuitry, said computer system adapted to carry out all functions of the device, and a user interface comprising a plurality of buttons, lights and displays mounted on the front of the housing, the buttons, lights and displays organized into logical sections including an arrest-type section, a CPR section, a medication section, a roles and tasks section, and a outcomes section, the method comprising: receiving input identifying personnel present; assigning roles and tasks to the personnel; sending one or more timed alerts to perform tasks specified by the protocol; accepting inputs indicating the tasks have been performed and that certain patient behaviors have been observed; and tracking and storing the timing, events, treatments, behaviors, and outcomes.

19. The method of claim 18 wherein said receiving input uses an ID reader integrated with the device.

20. The method of claim 19 wherein said assigning roles and tasks includes lighting one or more of said buttons in said roles and tasks section which are dedicated to the roles or tasks to be assigned.

21. The method of claim 18 wherein said sending timed alerts to perform tasks comprises turning on lights associated with a dedicated button for the task to be performed.

22. The method of claim 18 wherein said accepting inputs indicating a task has been performed comprises detecting the pressing of a dedicated button for said task.

23. A method of response to a medical emergency comprising: employing the hardware device of claim 5; pressing a start button on said device, which begins a free-running timer display; receiving input from a personnel ID card; assigning roles and tasks to the personnel; sending one or more timed alerts to perform tasks specified by the protocol; accepting inputs indicating the tasks have been performed and that certain patient behaviors have been observed; and tracking and storing the timing, events, treatments, behaviors, and outcomes.

24. A computer program product for implementing a method of controlling a user interface of a hardware device, the product comprising a non-transitory computer- readable medium storing executable instructions that, when executed by a processor in a hardware device, cause the hardware device to perform a method comprising: receiving input identifying personnel present; assigning roles and tasks to the personnel; sending one or more timed alerts to perform tasks specified by the protocol; accepting inputs indicating the tasks have been performed and that certain patient behaviors have been observed; and tracking and storing the timing, events, treatments, behaviors, and outcomes.

25. The computer program product of claim 24 wherein said assigning roles and tasks includes causing the lighting of one or more buttons on said hardware device that are dedicated to said roles and tasks.

26. The computer program product of claim 25 wherein said accepting inputs indicating a task has been performed comprise detecting the pressing of a dedicated button on said hardware device for said task.

27. The computer program product of claim 26 wherein the dedicated buttons and lighting are virtual buttons and lighting rendered graphically on a display device.

28. A hardware device that implements a predetermined medical emergency response protocol, the device comprising: a computer system comprising CPU, memory, input circuitry and output circuitry, said computer system adapted to carry out functions of the device; anda user interface comprising a plurality of visual and haptic elements organized into logical sections including an arrest-type section, a CPR section, a medication section, a roles and tasks section, and a outcomes section.

29. The hardware device of claim 28 wherein the haptic elements include buttons, and the visual elements include lights and displays.

30. The hardware device of claim 28 adapted to: receive input identifying personnel present; assign roles and tasks to the personnel; send timed alerts to perform tasks specified by the protocol; accept inputs indicating the tasks have been performed and that certain patient behaviors have been observed; and track and store the timing, events, treatments, behaviors, and outcomes when employed during a medical emergency response.

Images