Medical treatment system with companion device

Abstract

The medical treatment system includes a medical treatment device for monitoring a patient and providing treatment to the patient, and an auxiliary device communicatively coupled to the medical treatment device. The medical treatment device can display case information, including physiological information visually plotted based on physiological sensor input, in a first display format, and transmit the case information and medical data to the auxiliary device. The auxiliary device may include a device interface having a display screen for receiving user input commands to the medical treatment device during a medical event. The auxiliary device can process the case information and medical data received from the medical treatment device and also enables the display of multiple data display views at the device interface, wherein each of these display views can be selected via a corresponding display view selection unit of the device interface.

Description

[0001] Related applications

[0002] This application claims priority to U.S. Provisional Patent Application Serial No. 63 / 167,312, filed March 29, 2021, and U.S. Provisional Patent Application Serial No. 63 / 074,874, filed September 4, 2020. Each of these applications is incorporated herein by reference in its entirety. Background Technology

[0003] In medical situations (e.g., emergencies), multiple medical devices may be used. These devices may be used by different personnel. For example, an automated external defibrillator (AED) may be used by an untrained medical device personnel, such as a first responder. Additionally, emergency medical technicians (EMTs) may use different or additional devices (which may differ from those used in the hospital) to respond to an emergency. Furthermore, one or more information display devices may be present, such as liquid crystal display (LCD) panels, portable computing devices like tablets, mobile communication devices (e.g., iPhones), smartwatches (e.g., iPads, Apple Watches provided by Apple Inc.), or other types of wearable computing and display devices, on which information from one or more medical devices may be displayed.

[0004] In one example, the medical condition is cardiac arrest, a common cause of death. One approach to cardiac arrest is rapid, forceful chest compressions to maintain blood flow from the patient's heart to vital parts of the body. Along with chest compressions, rescuers can ventilate the patient by providing positive pressure breathing through the mouth or nose or using devices that push air into the patient's lungs. Rescuers (such as non-professional responders, emergency medical technicians (EMTs), rescue team leaders, paramedics, doctors, or other rescuers) can benefit from feedback related to the performance of cardiopulmonary resuscitation (CPR) and from information about the patient's medical condition during treatment. Sensors can be used to collect information about the patient's health status, physiological data, and information related to the treatment delivered to the patient. Summary of the Invention

[0005] The foregoing general description of the exemplary implementations and the following detailed description of the exemplary implementations are merely exemplary aspects of the teachings of the present invention and are not limiting.

[0006] This document describes various systems and methods for monitoring treatments delivered by one or more medical treatment devices during an emergency medical event via an accessory device communicatively coupled to a medical treatment device (e.g., a defibrillator or shock delivery device, a patient monitor, a ventilator). In one aspect, the invention relates to a medical treatment system comprising: a medical treatment device configured to monitor a patient and provide treatment to the patient, the medical treatment device including: at least one physiological sensor input configured to generate a patient-related physiological signal during the medical event; a medical treatment device screen for presenting medical information based on the generated physiological signal; and at least one first processor operatively coupled to the at least one physiological sensor input and the medical treatment device screen. The at least one first processor is configured to: receive and process the patient-related physiological signal; generate medical data based on the processed physiological signal; display case information on the medical treatment device screen in a first display format, the case information including physiological information visually plotted based on the generated medical data; and transmit the case information and the generated medical data to an accessory device. In some embodiments, the supporting device is communicatively coupled to the medical treatment device via a communication link and includes a device interface having a display screen configured to allow a user to input one or more commands to the medical treatment device during the medical event. The supporting device may include at least one second processor operatively coupled to the device interface and configured to process case information received from the medical treatment device and generated medical data. The at least one second processor may also cause a real-time device view of the case information, including the physiological information, displayed on the medical treatment device screen to be shown at the device interface in a second display format. The second display format can provide a visual reproduction of the first display format and, in response to detecting at least one user input at the device interface, transmit one or more command signals to the medical treatment device.

[0007] In some implementations, visual reproduction of the first display format in the second display format includes providing a copy of the first display format.

[0008] In some implementations, providing a visual reproduction of the first display format in the second display format includes adjusting one or more visual aspects of the case information presented in the second display format based on the case information displayed in the first display format. In some implementations, the one or more visual aspects include one or more of the following: layout, color, font, magnification, resolution, size, and screen position of the case information.

[0009] In some implementations, providing a visual representation of the first display format in the second display format includes adding or subtracting one or more items of the case information displayed in the second display format based on the case information displayed in the first display format.

[0010] In some implementations, the communication link is a wireless communication link. In some implementations, the wireless communication link is at least one of a Wi-Fi link and a Bluetooth link. In some implementations, the wireless communication link is a pre-configured pairing between the medical treatment device and the companion device. In some implementations, the at least one first processor is further configured to: detect a wireless communication signal associated with the pre-configured pairing for the companion device via the wireless communication link, and connect to the companion device via the wireless communication link in response to detecting the wireless communication signal. In some implementations, transmitting the generated medical data to the companion device includes: automatically initiating the transmission of the generated medical data upon connection to the companion device. In some implementations, the at least one first processor is further configured to: detect the companion device disconnecting from the medical treatment device based on the loss of the wireless communication signal, and suspend the transmission of the generated medical data to the companion device in response to detecting the disconnection. In some implementations, the at least one second processor is configured to: detect the proximity of the medical treatment device via the wireless communication link, and connect to the medical treatment device via the pre-configured pairing for a proximity-based connection.

[0011] In some implementations, the at least one second processor is further configured to display a verification input at the device interface, which, when actuated, causes the connected medical treatment device to generate a pairing indication between the mating device and the medical treatment device. In some implementations, the at least one second processor is further configured to, in response to detecting actuation of the verification input at the device interface, transmit an instruction signal to the medical treatment device to generate the pairing indication between the mating device and the medical treatment device. In some implementations, the pairing indication at the medical treatment device is at least one of a visual indication and an audio indication. In some implementations, the visual indication is a flashing light. In some implementations, the audio indication is a toned sound pulse.

[0012] In some implementations, the accessory device is one of a plurality of accessories capable of connecting to the medical treatment device. In some implementations, the at least one first processor is further configured to simultaneously transmit at least a portion of the generated medical data to each of the plurality of accessories for display at a corresponding device interface of each of the plurality of accessories.

[0013] In some implementations, the display screen of the device interface is a touchscreen for receiving user input corresponding to the generated input signals.

[0014] In some implementations, the at least one user input includes an input for providing an instruction signal to the medical treatment device for one or more instruction signals.

[0015] In some implementations, transmitting one or more instruction signals to the medical treatment device includes: in response to detecting a selection of one of the at least one user inputs, transmitting an instruction signal among the one or more instruction signals for updating at least one of patient information, treatment information, and diagnostic information of the medical event.

[0016] In some implementations, the at least one user input includes patient information input. In some implementations, the at least one second processor is further configured to display a patient information input interface at the device interface in response to detecting a user input signal associated with the patient information input. In some implementations, the patient information input interface includes a patient information input field for entering patient background information. In some implementations, the patient information input field includes at least one of a patient age input field, a patient gender input field, a patient name input field, a patient weight input field, a patient height input field, and a patient identification input field. In some implementations, the patient information input field includes a case identification input field. In some implementations, transmitting the one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting the submitted patient information to the medical treatment device when submitting patient information at a portion of the patient information input field.

[0017] In some implementations, the at least one first processor is further configured to link the submitted patient information with the patient's medical record information in response to receiving the submitted portion of the patient information. In some implementations, the at least one first processor is further configured to transmit a link confirmation signal to the accompanying device in response to linking the submitted patient information with the patient's medical record information. In some implementations, the at least one second processor is further configured to display a patient information transmission confirmation message at the device interface in response to receiving the link confirmation signal from the medical treatment device.

[0018] In some implementations, the at least one first processor is further configured to, in response to receiving the submitted patient information, store the submitted patient information together with the patient's medical record information in the data storage area of ​​the medical treatment device. In some implementations, the at least one first processor is further configured to, in response to storing the submitted patient information together with the patient's medical record information, transmit a storage confirmation signal to the accompanying device. In some implementations, the at least one second processor is further configured to, in response to receiving the storage confirmation signal from the medical treatment device, display a patient information transmission confirmation message at the device interface.

[0019] In some implementations, the device interface includes at least one sensor configured to scan patient information from a document, and the at least one second processor is further configured to automatically populate various input fields of the patient information input fields with the scanned patient information. In some implementations, the at least one sensor is a camera. In some implementations, the document is a government-issued identification card.

[0020] In some implementations, the at least one user input includes a disposal marker input. In some implementations, the at least one second processor is also configured to display a disposal marker input interface at the device interface in response to detecting a user input signal associated with the disposal marker input.

[0021] In some implementations, the treatment tag input interface includes a treatment tag selector for tagging patient treatment events at the medical treatment device. In some implementations, the treatment tag selection includes at least one of medication, oxygen, anticoagulant, and Recovered Circulatory System (ROSC). In some implementations, the treatment tag selection includes a customizable treatment tag selection for manually entering a treatment name. In some implementations, the treatment tag selection includes transmitting one or more instruction signals from the at least one second processor to the medical treatment device, including transmitting treatment tag instruction signals for recording the one or more treatment tag selections to the medical treatment device upon submission of the treatment tag selection.

[0022] In some implementations, the at least one first processor is further configured to, in response to receiving the treatment mark instruction signal, record one or more treatment mark selections in the data storage area of ​​the medical treatment device. In some implementations, the at least one first processor is further configured to, in response to starting recording of one or more treatment mark selections, transmit a treatment mark recording confirmation signal to the supporting device. In some implementations, the at least one second processor is further configured to, in response to receiving the treatment mark recording confirmation signal from the medical treatment device, display a treatment mark recording confirmation message at the device interface. In some implementations, the at least one first processor is further configured to, in response to the completion of recording one or more treatment mark selections, transmit a treatment mark recording completion confirmation signal to the supporting device.

[0023] In some implementations, the at least one second processor is further configured to display a treatment mark recording completion confirmation message at the device interface in response to receiving a treatment mark recording completion confirmation signal from the medical treatment device. In some implementations, the device interface includes at least one audio sensor configured to receive audio input of one or more treatment mark selections, and to transmit the one or more instruction signals from the at least one second processor to the medical treatment device, including: upon receiving the audio input, transmitting a treatment mark instruction signal to the medical treatment device for recording the one or more treatment mark selections. In some implementations, the at least one audio sensor includes a microphone.

[0024] In some implementations, the at least one user input includes a 12-lead ECG analysis input. In some implementations, transmitting the one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting the selection of the 12-lead ECG analysis input, transmitting a 12-lead analysis instruction signal for initiating a 12-lead ECG analysis at the medical treatment device. In some implementations, the at least one first processor is further configured to perform a 12-lead ECG analysis at the medical treatment device in response to receiving the 12-lead analysis instruction signal. In some implementations, the at least one first processor is further configured to transmit a 12-lead analysis in progress confirmation signal to the accompanying device in response to starting the 12-lead ECG analysis.

[0025] In some implementations, the at least one second processor is further configured to display a 12-lead analysis confirmation message at the device interface in response to receiving the in-process 12-lead analysis confirmation signal from the medical treatment device. In some implementations, the at least one first processor is further configured to transmit a 12-lead analysis completion confirmation signal to the accompanying device in response to the completion of the 12-lead ECG analysis. In some implementations, the at least one second processor is further configured to display a 12-lead analysis completion confirmation message at the device interface in response to receiving the 12-lead analysis completion confirmation signal from the medical treatment device.

[0026] In some implementations, the 12-lead ECG analysis input provides a user selection of a previously performed 12-lead ECG analysis for viewing at the device interface of the accompanying device. In some implementations, the at least one second processor is also configured to, in response to detecting a selection of a previously performed 12-lead ECG analysis for viewing, issue an instruction signal to the medical treatment device to obtain 12-lead ECG analysis data associated with the previously performed 12-lead ECG analysis. In some implementations, the at least one second processor is also configured to, in response to receiving the 12-lead ECG analysis data from the medical treatment device, display the 12-lead ECG analysis data of the previously performed ECG at the device interface of a customized accompanying device.

[0027] In some implementations, the at least one user input includes a defibrillator snapshot input. In some implementations, transmitting the one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting the selection of a medical treatment device snapshot input, transmitting a snapshot instruction signal for initiating the capture of a snapshot of the medical treatment device screen.

[0028] In some implementations, the at least one first processor is further configured to capture a snapshot of the medical treatment device screen in response to receiving the snapshot instruction signal. In some implementations, the at least one first processor is further configured to transmit a snapshot in progress confirmation signal to the supporting device in response to capturing a snapshot of the medical treatment device screen. In some implementations, the at least one second processor is further configured to display a snapshot in progress confirmation message at the device interface in response to receiving the snapshot in progress confirmation signal from the medical treatment device. In some implementations, the at least one first processor is further configured to transmit a snapshot completion confirmation signal to the supporting device in response to the completion of capturing a snapshot of the medical treatment device screen. In some implementations, the at least one second processor is further configured to display a snapshot completion confirmation message at the device interface in response to receiving the snapshot completion confirmation signal from the medical treatment device.

[0029] In some implementations, the at least one user input includes a case event summary input. In some implementations, the at least one second processor is further configured to display an event summary interface at the device interface in response to detecting a selection of the case event summary input. In some implementations, the event summary interface includes a chronological list of events associated with patient care recorded at the medical treatment device. In some implementations, the at least one second processor is further configured to obtain a chronological list of events from the medical treatment device in response to detecting a selection of the case event summary input. In some implementations, the at least one second processor is further configured to display details associated with the selected event in response to selecting an event from the chronological list of events at the event summary interface. In some implementations, the displayed details of the selected event include a snapshot of the medical treatment device screen at the time associated with the selected event.

[0030] In some implementations, the at least one user input includes an alarm summary input. In some implementations, the at least one second processor is further configured to display an alarm interface at the device interface in response to detecting a selection of the alarm summary input. In some implementations, the alarm interface includes a list of one or more alarm-causing events at the medical treatment device. In some implementations, the alarm-causing events include physiological alarm events and technical alarm events. In some implementations, the at least one sensor input includes at least one physiological sensor input, and the physiological alarm event includes a threshold limit associated with at least one physiological sensor. In some implementations, the technical alarm event includes a technical problem associated with the medical treatment device.

[0031] In some implementations, the at least one user input includes a noninvasive blood pressure initiation input, i.e., an NIBP initiation input. In some implementations, transmitting the one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting the selection of the NIBP initiation input, transmitting an NIBP instruction signal for initiating an NIBP measurement at the medical treatment device.

[0032] In some implementations, one or more additional physiological sensor inputs are communicatively coupled to the accompanying device, and the one or more additional physiological sensor inputs are configured to generate one or more additional physiological signals corresponding to the patient during the medical event. In some implementations, the at least one second processor is further configured to: receive and process the one or more additional physiological signals corresponding to the patient, generate additional medical data based on the processed one or more additional physiological signals, and display additional medical information at the device interface, the additional medical information including additional physiological information visually rendered based on the generated additional medical data. In some implementations, the at least one second processor is further configured to: transmit the additional medical information to the medical treatment device for display on the medical treatment device screen. In some implementations, the one or more additional physiological sensor inputs include at least one of a continuous NIBP sensor, an ultrasound imaging sensor, and a laryngoscopy sensor.

[0033] In some implementations, the at least one second processor is further configured to: receive from the medical treatment device an amount of electric shock energy available at the medical treatment device; and to display at the device interface an amount of electric shock energy stored at a high-voltage capacitor.

[0034] In some implementations, the at least one second processor is further configured to: receive from the medical treatment device the number of electric shocks applied to the patient by the medical treatment device; and display at the device interface the number of electric shocks applied to the patient by the medical treatment device. In some implementations, the device view displayed at the display interface is one of a plurality of views for display at the display interface of the accompanying device, and the at least one second processor is further configured to display a portion of the view at the display interface.

[0035] In some implementations, the view to be displayed at the display interface includes a trend view that presents trend data based on medical data generated in association with patient care during the medical event.

[0036] In some implementations, the at least one sensor input includes at least one physiological sensor input, and the trend data includes physiological values ​​from the at least one physiological sensor input over time. In some implementations, the trend data includes at least one of SpO2, EtCO2, systolic blood pressure, diastolic blood pressure, mean arterial pressure, and heart rate values ​​over time. In some implementations, the trend view includes a graphical display of a portion of the trend data. In some implementations, the trend view includes a tabular display of a portion of the trend data.

[0037] In some implementations, the at least one second processor is configured to display a plurality of data display views at the device interface, wherein each display view can be selected via a corresponding display view selection unit of the device interface. The display views may include: a real-time device view of case information including the physiological information displayed on a medical treatment device screen, and a working view including one or more customized display portions. The display portions may, for example, be customized for various caregiver roles.

[0038] In some implementations, the medical treatment device further includes: at least one caregiver performance sensor input configured to generate a caregiver performance signal associated with a corresponding caregiver role during the medical event; and the at least one first processor further configured to: receive and process the caregiver performance signal, and generate caregiver performance data based on the processed caregiver performance signal. The case information may also include caregiver performance information visually plotted based on the generated caregiver performance data.

[0039] In some implementations, the at least one caregiver performance sensor input includes chest compression sensor input, and the caregiver performance information includes chest compression information. In some implementations, the chest compression sensor input is a motion sensor input. In some implementations, the chest compression information includes chest compression feedback during the medical event, and the chest compression feedback includes at least one of compression depth feedback, compression rate feedback, and release speed feedback. In some implementations, the compression depth feedback includes a visual indication of the corresponding depth of each chest compression applied to the patient. In some implementations, the visual indication of the corresponding depth of each chest compression applied to the patient is displayed relative to a target range of chest compression depth.

[0040] In some implementations, the corresponding caregiver role is performing chest compressions on the patient during the medical event.

[0041] In some implementations, the at least one caregiver performance sensor input includes at least one ventilation sensor input, and the caregiver performance information includes ventilation case information derived from the at least one ventilation sensor input.

[0042] In some implementations, the at least one ventilation sensor input includes an airflow sensor input.

[0043] In some implementations, the ventilation case information includes ventilation feedback during the medical event, and the ventilation feedback includes at least one of tidal volume, ventilation rate, and minute volume.

[0044] In some implementations, the corresponding caregiver role is administering ventilation to the patient during the medical event.

[0045] In some implementations, one or more custom data sections of the working view include a ventilation performance data section that displays the ventilation case information.

[0046] In some implementations, the ventilation case information includes a summary of ventilation performance during the medical event. In some implementations, the summary of ventilation performance includes a display of at least one of mean tidal volume, mean tidal rate, mean minute volume, and percentage of ventilation within a target volume range or target rate range.

[0047] In some implementations, the at least one second processor is configured to display a summary of the ventilation performance in the working view in real time during the medical event. In some implementations, the at least one second processor is configured to display a summary of the ventilation performance in the working view when the medical event is completed.

[0048] In some implementations, the chest compression information includes a summary of chest compression performance during the medical event. In some implementations, the summary of chest compression performance includes at least one of the following: average compression depth, average compression rate, average release rate, pre-shock pause, post-shock pause, and percentage of compressions within a target compression depth range. In some implementations, the at least one second processor is configured to display the summary of chest compression performance in the working view in real time during the medical event. In some implementations, the at least one second processor is configured to display the summary of chest compression performance in the working view when the medical event is completed.

[0049] In some implementations, the medical treatment device is a ventilator. The accompanying device may be coupled to the ventilator via a network communication and may include: a device interface having a display screen configured to allow a user to input one or more commands for the ventilator during the medical event; and at least one second processor operatively coupled to the device interface, the at least one second processor being configured to: process case information and medical data received from the ventilator, display a real-time view of the processed case information and medical data received from the ventilator at the device interface, and transmit one or more command signals to the medical treatment device in response to detecting at least one user input at the device interface.

[0050] In some embodiments, the ventilator is a portable ventilator for providing pre-hospital ventilation to a patient. The portable ventilator may weigh no more than 10 pounds, no more than 5 pounds, between 5 and 10 pounds, or between 7 and 12 pounds. The ventilator display interface of the portable ventilator may include a plurality of indicator lights configured to indicate that the case information falls within a range defined by one or more thresholds. The plurality of indicator lights may be configured to display a plurality of colors, wherein each of the plurality of colors is associated with one of the ranges of the case information. The ventilator display interface may include a screen having a display area of ​​no more than 4 square inches, between 3 and 6 square inches, or between 2 and 5 square inches. In some embodiments, the surface area of ​​any side of the portable ventilator is no more than 25 square inches, no more than 20 square inches, or between 15 and 25 square inches. In one or more examples, the display area of ​​the display screen of the accompanying device is larger than the display area of ​​the screen of the ventilator display interface.

[0051] In some embodiments, the ventilator includes: an oxygen inlet configured to supply oxygen to provide positive pressure ventilation to a patient; and a ventilation outlet configured to be pneumatically coupled to the oxygen inlet and to deliver positive pressure ventilation with the supplied oxygen to the patient. The one or more command signals may include one or more control signals used by the ventilator to administer positive pressure ventilation to the patient.

[0052] In some embodiments, the one or more instruction signals may include one or more control signals for adjusting one or more ventilator control settings. One or more ventilator control settings may include at least one of the following: fractional oxygen concentration (FIO2) setting, positive end-expiratory pressure (PEEP) setting, and tidal volume (V) setting. t Settings include the inspiratory:expiratory ratio (I:E) setting, ventilator mode setting, and peak inspiratory pressure (PIP) threshold setting.

[0053] In some embodiments, the physiological information may include airway pressure (P). AW Waveform, tidal volume (V) t The physiological information may include at least one of the following waveforms: peripheral capillary oxygen saturation (SpO2) waveform, and invasive blood pressure (IBP) waveform. In some embodiments, the physiological information may include graphs of at least one of the following over time: end-tidal carbon dioxide (ETCO2), noninvasive blood pressure (NIBP), fractional oxygen concentration (FIO2), pulse rate (PR), respiratory rates per minute (BPM), minimum respiratory rate (VPR), and minimum volume of oxygen (VV). min ), platform pressure (P) PlatThe physiological information may include the current value of at least one of the following: fractional oxygen concentration (FIO2), peak inspiratory pressure (PIP), and tidal volume (V). In some embodiments, the physiological information may include the current value of at least one of the following: fractional oxygen concentration (FIO2), peak inspiratory pressure (PIP), and tidal volume (V). t ), respiratory rate per minute (BPM), end-expiratory carbon dioxide (ETCO2), noninvasive blood pressure (NIBP), invasive blood pressure (IBP), heart rate (HR), and ventilator mode.

[0054] In some embodiments, the at least one user input may include an input for providing an instruction signal from the one or more instruction signals to the ventilator. Transmitting the one or more instruction signals to the ventilator may include: in response to detecting a selection of one of the at least one user input, transmitting an instruction signal from the one or more instruction signals to update at least one of patient information, treatment information, and diagnostic information for the medical event.

[0055] In some embodiments, the at least one user input may include patient information input. The at least one second processor may also be configured to display a patient information input interface at the device interface in response to detecting a user input signal associated with the patient information input. The patient information input interface may include multiple patient information input fields for entering patient background information. The multiple patient information input fields may include a patient gender input field and a patient height input field. Transmitting the one or more instruction signals from the at least one second processor to the ventilator may include transmitting the corresponding patient gender and corresponding patient height to the ventilator upon submission of the corresponding patient gender in the patient gender input field and the corresponding patient height in the patient height input field. The at least one first processor may also be configured to automatically adjust the tidal volume setting (V) at the ventilator based on the corresponding patient gender and corresponding patient height upon receiving the corresponding patient gender and corresponding patient height. t set up.

[0056] In some embodiments, the at least one user input may include a ventilation setting input. The at least one second processor may also be configured to display a ventilation setting interface at the device interface in response to detecting a user input signal associated with the ventilation setting input. The ventilation setting interface may include multiple ventilation setting inputs for adjusting multiple ventilation settings on the ventilator. The multiple ventilation settings may include at least one of the following at the device interface: positive end-expiratory pressure (PEEP) setting, tidal volume setting (V... tThe ventilation settings include: breaths per minute (BPM) setting, inspiratory:expiratory ratio (I:E) setting, peak inspiratory pressure (PIP) threshold setting, peripheral capillary oxygen saturation (SpO2) setting, fractional oxygen concentration (FIO2) setting, and ventilation mode adjustment settings. In response to detecting a selection of one of the ventilation setting inputs at the ventilation setting interface, the at least one second processor can be configured to display a setting adjustment interface for the corresponding ventilation setting. The setting adjustment interface may include an interface for inputting a numerical value for the corresponding ventilation setting. Transmitting one or more instruction signals from the at least one second processor to the ventilator may include transmitting a ventilation setting adjustment for the corresponding setting to the ventilator upon submission of a ventilation setting adjustment at the corresponding ventilation setting adjustment interface. The at least one first processor may also be configured to automatically adjust the corresponding setting on the ventilator based on the ventilation setting adjustment received for the corresponding setting. In response to receiving a confirmation signal from the ventilator acknowledging an adjustment of a corresponding setting, the at least one second processor may be configured to display an event marker associated with the adjustment of the corresponding setting at the ventilator in one or more selectable display views at the accessory device. The confirmation signal may include the time at which the adjustment of the corresponding setting occurred at the ventilator. The event marker may be displayed at a location in one or more selectable display views related to the time at which the adjustment of the corresponding setting occurred. In response to detecting a selection of a ventilation mode adjustment setting at the ventilation setting interface, the at least one second processor may be configured to display a mode selection interface at the device interface. The mode selection interface includes multiple ventilation mode inputs, each associated with a corresponding operating mode of the ventilator. The multiple ventilation mode inputs may include at least one of the following: assist / control mode (AC mode), synchronized intermittent forced ventilation mode (SIMV mode), continuous positive airway pressure mode (CPAP mode), and bilevel mode (BL mode). Transmitting the one or more instruction signals from the at least one second processor to the ventilator may include: transmitting a corresponding ventilation mode input to the ventilator upon detecting a selection of a corresponding ventilation mode input at the mode selection interface. The at least one first processor may also be configured to automatically adjust a corresponding operating mode at the ventilator in response to receiving a corresponding ventilation mode input. In response to receiving a confirmation signal from the ventilator confirming the adjustment of the corresponding operating mode, the at least one second processor may be configured to display an event marker associated with the adjustment of the corresponding operating mode at the ventilator in one or more selectable display views of a plurality of selectable display views in the accessory device view.The confirmation signal may include the time when the corresponding operating mode adjustment occurred at the ventilator. The event marker may be displayed at a location in one or more selectable display views related to the time when the corresponding operating mode adjustment occurred.

[0057] In some embodiments, the at least one user input includes an alarm summary input. The at least one second processor may also be configured to display an alarm interface at the device interface in response to detecting a selection of the alarm summary input. The alarm interface may include a list of one or more alarm-causing events at the defibrillator. The list of one or more alarm-causing events may include, for each listed alarm-causing event, at least one of a corresponding alarm trigger time, a corresponding alarm description, a corresponding alarm type, and a corresponding alarm priority. The corresponding alarm type may be one of a patient safety alarm, a self-test alarm, and a use and environment alarm.

[0058] In some embodiments, the at least one second processor may be configured to display alarm markers associated with each alarm condition detected at the defibrillator within one or more selectable display views in the companion device view. At least one of the colors and shapes of the displayed alarm markers is based on a priority associated with the corresponding detected alarm condition. The alarm markers may be displayed at a location in one or more selectable display views related to the time at which the corresponding operating mode adjustment occurs.

[0059] In some embodiments, the ventilator display interface may include a screen configured to display the case information in a first display format. The at least one second processor may be configured to display a real-time device view of the case information, including the physiological information, displayed on the ventilator screen at the device interface in a second display format, wherein the second display format provides a visual reproduction of the first display format. Providing a visual reproduction of the first display format in the second display format may include adjusting one or more visual aspects of the case information presented in the second display format according to the case information displayed in the first display format. The one or more visual aspects may include one or more of the layout, color, font, magnification, resolution, size, and screen position of the case information. Providing a visual reproduction of the first display format in the second display format may include rotating the display orientation of the case information presented within the display screen.

[0060] In some implementations, the at least one second processor may be configured to display a plurality of data display views at the device interface, wherein: each of the plurality of display views is selectable via a corresponding display view selection unit of the device interface; and the plurality of display views include: a real-time view of case information including physiological information stored in the memory of the ventilator, and a working view including one or more customized display portions for a corresponding caregiver role. The ventilator may also include: at least one caregiver performance sensor input configured to generate a caregiver performance signal associated with a corresponding caregiver role during the medical event, wherein the at least one first processor is further configured to: receive and process the caregiver performance signal, and generate caregiver performance data based on the processed caregiver performance signal, and wherein the case information includes caregiver performance information visually plotted based on the generated caregiver performance data. The at least one caregiver performance sensor input may include at least one CPR sensor input, wherein the caregiver case information includes CPR case information derived from the at least one CPR sensor input. The at least one CPR sensor input includes a chest compression sensor input, wherein the CPR case information includes chest compression information. The chest compression sensor input may be a motion sensor input. Chest compression case information may include chest compression feedback during the medical event, wherein the chest compression feedback includes at least one of compression depth feedback, compression rate feedback, and release rate feedback. The at least one first processor may be configured to: detect the compression rate of the compressions delivered to the patient from the processed chest compression sensor input; and synchronize the delivery of positive pressure ventilation to the patient with the delivered compressions based on the detected compression rate. The at least one second processor may be configured to display a visual depiction of the synchronization between the delivered positive pressure ventilation and the delivered compressions. The working view may be displayed separately from the device view on the interface screen of the device interface. The one or more customized display portions may not be available for viewing in the one or more device view display portions. The working view may be a scrollable interface to provide more information than that displayed in the device view. A portion of the one or more customized display portions may be manually selectable by the caregiver. In one or more general examples, the at least one second processor is configured to display a working view at the device interface, including one or more customized display portions, wherein the one or more customized display portions are selected by the user to include selected medical data or physiological information. In one or more examples, the one or more customized display portions of the working view are customizable based on user input during a medical event.

[0061] In one aspect, the present invention relates to a method for providing resuscitation care to a patient during a medical event, the method comprising: receiving and processing, using at least one first processor of a medical treatment device, a patient-corresponding physiological signal generated by at least one physiological sensor input communicatively coupled to the medical treatment device; generating medical data based on the processed physiological signal using the at least one first processor; displaying case information on a screen of the medical treatment device in a first display format using the at least one first processor, the case information including physiological information visually plotted based on the generated medical data; and transmitting the case information and the generated medical data to an auxiliary device communicatively coupled to the medical treatment device using the at least one first processor, the auxiliary device comprising: a device interface having a display screen configured to allow a user to input one or more commands for the medical treatment device during the medical event; and at least one second processor operatively coupled to the device interface. The method may include: using the at least one second processor to process case information received from the medical treatment device and generated medical data; using the at least one second processor to display a plurality of data display views at the device interface in a second display format, wherein each display view can be selected via a corresponding display view selection unit of the device interface, and one of the display views is a case type view including one or more case type display units customized to be associated with the case type of the medical event.

[0062] In some implementations, the case type view is one of a plurality of case type views, each selectable for viewing via corresponding user input at the device interface.

[0063] In some implementations, the case type view includes two or more of the following: basic monitoring case type view, advanced monitoring case type view, cardiac arrest case type view, traumatic brain injury (TBI) case type view, respiratory distress case type view, and critical care monitoring case type view.

[0064] In some implementations, a method for providing resuscitation treatment to a patient during a medical event includes: receiving and processing patient-related physiological signals generated by at least one physiological sensor input communicatively coupled to the ventilator using at least one first processor of a ventilator; generating medical data based on the processed physiological signals using the at least one first processor; displaying case information, including physiological information visually plotted based on the generated medical data, on a ventilator display interface using the at least one first processor; and transmitting at least a portion of the generated medical data and the case information via a network to an auxiliary device communicatively coupled to the ventilator using the at least one first processor. The supporting device includes: a device interface having a display screen configured to allow a user to input one or more commands for the ventilator during the medical event; and at least one second processor operatively coupled to the device interface; processing case information received from the ventilator and generated medical data using the at least one second processor; displaying a real-time view of the processed case information and medical data received from the ventilator at the device interface using the at least one second processor; and transmitting one or more command signals to the ventilator in response to detecting at least one user input at the device interface using the at least one second processor.

[0065] In some implementations, the at least one user input includes an input for providing an instruction signal among the one or more instruction signals to the ventilator. The at least one user input may include patient information input. The at least one second processor may also be configured to display a patient information input interface at the device interface in response to detecting user input associated with the patient information input. The patient information input interface may include multiple patient information input fields, which in some examples include a patient gender input field and / or a patient height input field. Transmitting the one or more instruction signals from the at least one second processor to the ventilator may include transmitting the corresponding patient gender and corresponding patient height to the ventilator when the corresponding patient gender is submitted at the patient gender input field and the corresponding patient height is submitted at the patient height input field. The at least one first processor may also be configured to automatically adjust the tidal volume setting (V) at the ventilator based on the corresponding patient gender and corresponding patient height in response to receiving the corresponding patient gender and corresponding patient height. t )set up.

[0066] In some embodiments, a medical treatment system for providing resuscitation care to a patient during a medical event may include: a plurality of medical treatment devices configured to monitor and provide treatment to the patient, each of the plurality of medical treatment devices including: at least one physiological sensor input configured to generate a patient-specific signal during the medical event; a medical treatment device screen for presenting medical information based on the generated signal; and at least one first processor operatively coupled to the at least one sensor input and the medical treatment device screen. The at least one first processor may be configured to: receive and process the patient-specific signal; generate medical data based on the processed signal; display case information on the device screen of the corresponding medical treatment device, the case information including physiological information visually plotted based on the medical data; and transmit at least a portion of the generated medical data and the case information to an auxiliary device. The supporting device can be coupled to each of the plurality of medical treatment devices via network communication. The supporting device includes: a device interface having a display screen configured to allow a user to input one or more commands for the plurality of medical treatment devices during the medical event; and at least one second processor operatively coupled to the device interface. The at least one second processor can be configured to: process case information and medical data received from each of the plurality of medical treatment devices, such that one or more real-time combined device views of case information from each of the plurality of medical treatment devices are displayed at the device interface, the case information including a portion of physiological information displayed on the corresponding medical treatment device screen of each of the plurality of medical treatment devices; and, in response to detecting at least one user input at the device interface associated with the corresponding medical treatment device of the plurality of medical treatment devices, transmit one or more command signals to the corresponding medical treatment device. In other examples, the system may include one or more medical treatment devices.

[0067] In some embodiments, a first medical treatment device among the plurality of medical treatment devices may include a ventilator, and a second medical treatment device among the plurality of medical treatment devices may include a defibrillator. The defibrillator may include: a high-voltage capacitor configured to store and release charge to provide electrical therapy to a patient, and electrode outputs configured to be electrically coupled to the high-voltage capacitor and to transfer at least a portion of the charge from the high-voltage capacitor to the patient. The one or more command signals may include one or more control signals for the defibrillator to administer the electrical therapy to the patient. The physiological information may include an ECG waveform, a pulse oximetry (SpO2) waveform, and a CO2 waveform. The physiological information may include the current pulse oximetry (SpO2) value, the current end-tidal carbon dioxide (ETCO2) value, the current blood pressure value, and the current heart rate (HR) value.

[0068] In some embodiments, the ventilator includes: an oxygen inlet configured to supply oxygen to provide positive pressure ventilation to a patient; and a ventilation outlet configured to be pneumatically coupled to the oxygen inlet and to deliver positive pressure ventilation to the patient. The physiological information may include graphs of at least one of the following over time: end-tidal carbon dioxide (ETCO2), noninvasive blood pressure (NIBP), fractional inspired oxygen (FIO2), pulse rate (PR), respiratory rates per minute (BPM), minimum respiratory rate (VPR), and minimum volume (VV). min ), platform pressure (P) Plat The physiological information may include current values ​​of at least one of the following: fractional oxygen concentration (FIO2), peak inspiratory pressure (PIP), tidal volume (V) and peak inspiratory pressure (PIP). t ), respiratory rate per minute (BPM), end-expiratory carbon dioxide (ETCO2), noninvasive blood pressure (NIBP), invasive blood pressure (IBP), heart rate (HR), and ventilator mode.

[0069] In some embodiments, one of the one or more real-time combined device views includes a work view comprising one or more customized display portions for a corresponding caregiver role. The corresponding caregiver role may be a supervisor role.

[0070] In some embodiments, at least one of the medical treatment devices may further include: at least one caregiver performance sensor input configured to generate a caregiver performance signal associated with a corresponding caregiver role during the medical event. The at least one first processor may also be configured to: receive and process the caregiver performance signal, and generate caregiver performance data from the processed caregiver performance signal, wherein the case information further includes caregiver performance information visually plotted based on the generated caregiver performance data. The at least one caregiver performance sensor input includes at least one CPR sensor input, wherein the caregiver case information includes CPR case information derived from the at least one CPR sensor input. The at least one CPR sensor input may include a chest compression sensor input, wherein the CPR case information includes chest compression information. The chest compression sensor input may be a motion sensor input. The chest compression case information may include chest compression feedback during the medical event, wherein the chest compression feedback includes at least one of compression depth feedback, compression rate feedback, and release speed feedback. The at least one first processor may be configured to: detect the compression rate of compressions delivered to the patient from processed chest compression sensor input; and synchronize the delivery of positive pressure ventilation to the patient with the delivered compressions based on the detected compression rate. The at least one second processor may be configured to display a visual depiction of the synchronization between the delivered positive pressure ventilation and the delivered compressions.

[0071] In some embodiments, one of the one or more real-time combined device views may include a trend view for presenting trend data based on medical data generated from one or more medical treatment devices in relation to patient care during the medical event. The at least one sensor input may include at least one physiological sensor input, wherein the trend data includes time-evolved physiological values ​​from the at least one physiological sensor input. The trend data may include at least one of time-evolved pulse oxygen saturation (SpO2), end-expiratory carbon dioxide (EtCO2), systolic blood pressure, diastolic blood pressure, mean arterial pressure, and heart rate values. The trend data may include pulse rate (PR), respiratory rate / respiratory speed (RR / BR), pulse perfusion variability index (PVI), respiratory rates per minute (BPM), inspiratory:expiratory (I:E) ratio, and tidal volume (V). tThe trend view may include at least one of the following: fractional oxygen concentration (FIO2) setting, peak inspiratory pressure (PIP), and positive end-expiratory pressure (PEEP). The trend view may include a portion of the trend data displayed in tabular and / or graphical format. The at least one second processor may be configured to display an event marker at the trend view associated with at least one of an adjustment to a corresponding setting and an alarm status at one of the medical treatment devices. The event marker may be displayed at one or more trend graphs in the trend view at locations related to the time at which the adjustment to the corresponding setting or the alarm status occurred.

[0072] In some embodiments, the at least one user input includes input for providing one or more instruction signals to the plurality of medical treatment devices. The input for providing the instruction signals to the plurality of medical treatment devices may include patient information input. The at least one second processor may also be configured to display a patient information input interface at the device interface in response to detecting a user input signal associated with the patient information input. The patient information input interface may include a plurality of patient information input fields for inputting patient background information. Transmitting the one or more instruction signals from the at least one second processor to the plurality of medical treatment devices may include transmitting the corresponding patient background information to the plurality of medical treatment devices upon submission of the corresponding patient background information.

[0073] In some embodiments, a method for providing resuscitation care to a patient during a medical event includes: receiving and processing patient-related signals generated by at least one physiological sensor input communicatively coupled to the plurality of medical treatment devices using at least one first processor of each of the plurality of medical treatment devices; generating medical data based on the processed signals for each of the plurality of medical treatment devices using the corresponding at least one first processor; displaying case information in a first display format on a screen of the medical treatment device using the corresponding at least one first processor, the case information including physiological information visually plotted based on the generated medical data; and transmitting at least a portion of the generated medical data and the case information via a network to an accessory device communicatively coupled to the corresponding medical treatment device using the corresponding at least one first processor, the accessory device including: a device interface having a display screen, the... The display screen is configured to allow a user to input one or more instructions for a corresponding medical treatment device during a medical event, and at least one second processor operatively coupled to the device interface; using the at least one second processor to process case information received from the respective medical treatment devices and generated medical data; using the at least one second processor to display at the device interface one or more real-time device views of case information from each of the multiple medical treatment devices, including a portion of the physiological information displayed on the respective medical treatment device screens of each of the multiple medical treatment devices; and using the at least one second processor to transmit one or more instructions to the respective medical treatment device in response to detecting at least one user input at the device interface associated with the respective medical treatment device among the multiple medical treatment devices.

[0074] In some embodiments, a first medical treatment device among the plurality of medical treatment devices includes a ventilator, and a second medical treatment device among the plurality of medical treatment devices includes a defibrillator. One of the one or more real-time combined device views may include a work view containing one or more customized display portions for a corresponding caregiver role. The corresponding caregiver role may be a supervisor role.

[0075] In some embodiments, one of the one or more real-time combined device views includes a trend view for presenting trend data based on medical data generated from one or more of the plurality of medical treatment devices in association with patient care during the medical event. The at least one user input includes input for providing an instruction signal from one or more instruction signals to the plurality of medical treatment devices. The input for providing the instruction signal to the plurality of medical treatment devices may include patient information input. In another aspect, the present invention relates to a medical treatment system comprising medical treatment devices configured to monitor a patient. The medical treatment device may include: at least one sensor input configured to generate a signal corresponding to at least one physiological condition of the patient during the medical event; a medical treatment device display interface for presenting medical information based on the generated signal; and at least one first processor operatively coupled to the at least one sensor input and the medical treatment device display interface, the at least one first processor being configured to: receive and process the signal corresponding to at least one physiological condition of the patient; generate medical data based on the processed signal; display case information at the medical treatment device display interface, the case information including physiological information visually rendered based on the medical data; and transmit at least a portion of the generated medical data to an auxiliary device. The auxiliary device may be coupled to the medical treatment device via a network communication and may include: a device interface having a display screen; and at least one second processor operatively coupled to the device interface, the at least one second processor being configured to provide at least one display of information based on the received medical data or to provide an interface for user input to control the medical treatment device. This other aspect of the medical treatment system may be provided in combination with any one or more of the functions described herein (such as the display of device views, working views, control of settings of medical treatment or monitoring devices coupled to the device, provision of trend information, alarms and / or provision of their settings, event recording, display of events or other functions, etc.).

[0076] In another aspect, the present invention relates to a computer program that can be embodied as a computer program product executed by an accessory device, wherein the accessory device, when executing the computer program, is configured to form a medical treatment system having a medical treatment device configured to monitor a patient. The accessory device can be configured to form a communication coupling to the medical treatment device via a network. The medical treatment device may include: at least one sensor input configured to generate a signal corresponding to at least one physiological condition of the patient during the medical event; a medical treatment device display interface for presenting medical information based on the generated signal; and at least one first processor operatively coupled to the at least one sensor input and the medical treatment device display interface, the at least one first processor being configured to: receive and process the signal corresponding to at least one physiological condition of the patient; generate medical data based on the processed signal; and display case information at the medical treatment device display interface, the case information including physiological information visually drawn based on the medical data. The accessory device may also be configured to receive at least a portion of the generated medical data. The computer program may cause the accessory device to provide one of the following: displaying information on a display screen of the accessory device based on the received medical data, or providing an interface for user input to control the medical treatment device. For example, the user of the accessory device can submit user input used by the medical treatment device to adjust one or more treatment protocols. Attached Figure Description

[0077] The accompanying drawings, which are included in and form part of this specification, illustrate one or more embodiments and, together with the specification, serve to explain these embodiments. The drawings are not necessarily drawn to scale. Any values ​​or dimensions shown in the accompanying diagrams and figures are for illustrative purposes only and may or may not represent actual or preferred values ​​or dimensions. Where applicable, some or all features may not be illustrated to aid in the description of the basic features. In the drawings:

[0078] Figures 1A to 1D A schematic diagram of an emergency care scene according to some embodiments is shown;

[0079] Figure 2 An example environment is shown for using a set of devices within a medical treatment system to provide and monitor patient treatment;

[0080] Figure 3 This is a flowchart of an example method for configuring the connection between a medical treatment device and its associated devices;

[0081] Figure 4A and Figure 4B A flowchart illustrating an example method for displaying medical event case information at an accessory device;

[0082] Figures 5A to 5H A flowchart illustrating an example method for managing user input at an accessory device;

[0083] Figures 6A to 6C This shows a sample graphical user interface screen for display on the accompanying device;

[0084] Figure 6D An exemplary working view user interface screen showing the accessory device associated with the corresponding medical treatment device;

[0085] Figure 6E A display interface at a medical treatment device according to various embodiments is shown;

[0086] Figure 6F A display interface at a medical treatment device according to various embodiments is shown;

[0087] Figure 7A This shows an exemplary user interface screen for inputting patient information and the associated confirmation message;

[0088] Figure 7B This illustrates an exemplary user interface screen for handling marked input and the associated confirmation message;

[0089] Figure 7C-1 An exemplary confirmation message is shown for recording a snapshot at a medical treatment device;

[0090] Figure 7C-2 An example confirmation message for performing a 12-lead ECG analysis is shown;

[0091] Figure 7D This shows an example of a 12-lead ECG analysis user interface screen;

[0092] Figure 7E This shows an example user interface screen summarizing alerts;

[0093] Figure 7F This shows an example user interface screen summarizing case events;

[0094] Figure 8A This shows an example user interface screen for selecting case type;

[0095] Figure 8B This shows an exemplary user interface screen for a basic monitoring case type view;

[0096] Figure 8C-1 and Figure 8C-2 This shows an example advanced monitoring case type view user interface screen;

[0097] Figure 8DThis shows an example user interface screen displaying the view of cardiac arrest case types;

[0098] Figure 8E This shows an exemplary user interface screen displaying the case type view of traumatic brain injury;

[0099] Figure 8F This shows an example user interface screen displaying a view of respiratory distress case types;

[0100] Figure 8G This shows an exemplary user interface screen for critical care monitoring case type views;

[0101] Figure 9 An exemplary schematic block diagram showing the components of various devices in a medical treatment system;

[0102] Figure 10 An exemplary ventilator used in a medical treatment system is shown;

[0103] Figures 11A to 11E An exemplary graphical user interface screen is shown for display on an accessory device;

[0104] Figures 12A to 12B An exemplary graphical user interface screen is shown for display on an accessory device;

[0105] Figure 13A This shows an example user interface screen summarizing alerts;

[0106] Figure 13B This shows an example user interface screen for patient information input;

[0107] Figure 13C An exemplary ventilation settings input user interface screen is shown; and

[0108] Figure 13D-1 and Figure 13D-2 An example user interface screen for setting adjustments is shown. Detailed Implementation

[0109] The following description, set forth in conjunction with the accompanying drawings, is intended to illustrate various exemplary embodiments of the disclosed subject matter. Specific features and functions are described in conjunction with various exemplary embodiments; however, it will be apparent to those skilled in the art that the disclosed embodiments can be practiced without some of these specific features and functions.

[0110] Throughout this specification, references to "an embodiment" or "an embodiment" mean that a particular feature, structure, or characteristic described in connection with an embodiment is included in at least one embodiment of the disclosed subject matter. Therefore, the phrases "in one embodiment" or "in an embodiment" appearing in various places throughout the specification do not necessarily refer to the same embodiment. Furthermore, these particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. Moreover, embodiments of the disclosed subject matter are intended to cover modifications and variations thereof.

[0111] It must be noted that, as used in the specification and appended claims, the singular forms “a,” “an,” and “the” include plural references unless the context explicitly states otherwise. That is, unless otherwise explicitly stated, as used herein, the words “a,” “an,” and “the,” etc., have the meaning of “one or more.” Furthermore, it should be understood that terms such as “left,” “right,” “top,” “bottom,” “front,” “back,” “side,” “height,” “length,” “width,” “up,” “down,” “inner,” “outer,” “middle,” and “outer” that may be used herein describe reference points only and do not necessarily limit embodiments of the invention to any particular orientation or configuration. Moreover, terms such as “first,” “second,” “third,” etc., identify only one of the various parts, components, steps, operations, functions, and / or reference points disclosed herein, and again do not necessarily limit embodiments of the invention to any particular configuration or orientation.

[0112] In addition, the terms “approximately,” “about,” “close to,” “minor variation,” and similar terms generally refer to a range of identification values ​​that include, in some embodiments, a margin of 20%, 10%, or preferably 5%, as well as any values ​​between these ranges.

[0113] Except as expressly stated or unless a feature or function is incompatible with the additional embodiments described below, all functions described in connection with one embodiment are intended to be applicable to those additional embodiments. For example, where a given feature or function is expressly described in connection with one embodiment but not expressly mentioned in connection with alternative embodiments, it should be understood that unless the feature or function is incompatible with the alternative embodiments, the inventors intend that the feature or function can be deployed, utilized, or implemented in connection with the alternative embodiments.

[0114] Various aspects of the present invention relate to systems and methods for monitoring treatments delivered by one or more medical treatment devices during an emergency medical event via an accessory device communicatively coupled to a medical treatment device (e.g., a defibrillator or shock delivery device, a patient monitor, a ventilator) via a wireless communication link. The accessory device can be fully customizable based on the type of medical event and the role / preference of the device user (e.g., a medical team member, a CPR provider performing chest compressions and / or ventilation, a supervisor, a recorder, or a medication injector). In some embodiments, enabling the accessory device to connect to the medical treatment device provides the technical advantage of allowing users to view real-time sensor data associated with patient treatment, thereby providing enhanced treatment flexibility and supervision for healthcare professionals. For example, the size and / or location of the display area of ​​the medical treatment device is no longer limited to the ability of a caregiver to monitor the treatment. In another example, users with different roles or responsibilities at the treatment site can view customized information in some embodiments. The customized information presented at the accessory device may, for example, differ at least partially from the information being presented at the medical treatment device, thereby providing the technical advantage of presenting a team of caregivers with more information than could reasonably be displayed in the screen area of ​​the medical treatment device. Additionally, in some embodiments, each companion device can be paired with a single defibrillator, ventilator, or other medical treatment device and receive real-time data via a secure link. This allows historical patient data to be securely stored at the medical treatment device without requiring any patient-related medical data to be locally stored on companion devices 110, 111, 119, and 204. This provides technical advantages in security and patient information privacy during data review by multiple healthcare personnel. In various embodiments, (one or more) companion devices are pre-configured to be associated with a specific medical treatment device (e.g., defibrillator, patient monitor, ventilator) to streamline wireless communication pairing without the time-consuming query and response negotiation required to establish a secure connection.

[0115] In some embodiments, an adjunct device configured to operate in conjunction with a medical treatment device may be used by trained emergency responders in an emergency medical services (EMS) environment at the scene of an emergency or during pre-hospital transport. The adjunct device may also be used in the EMS during ground and air transport of patients between medical facilities. In some examples, the adjunct device may also be used in hospital emergency rooms, general medical and surgical and intermediate care floors, cardiac care units, electrophysiology (EP) laboratories, operating rooms, and other similar areas in hospitals and / or for intra-hospital patient transport.

[0116] In one example scenario, during the treatment of a cardiac arrest victim (“Code”), emergency department (ED) healthcare personnel (such as nurses or doctors) introduce medical intervention devices (such as defibrillators / monitors) and apply electrocardiogram (ECG) diagnostic electrodes and / or therapeutic defibrillation electrodes along with other physiological sensors (such as pulse oximeters, carbon dioxide plethysmography, blood pressure, near-infrared spectroscopy, etc.) to the patient. Additionally, there are sensor inputs for measuring caregiver performance, such as motion and flow sensors for measuring caregiver performance during both diagnostic and intervention activities. For example, a motion sensor (e.g., an accelerometer) may be placed on the patient’s sternum during chest compressions and may be used to measure parameters indicating chest compression performance (such as compression depth, rate, release rate, etc.); and / or a flow sensor may be placed along the patient’s airway during ventilation and may be used to measure parameters indicating ventilation performance (such as tidal volume, ventilation rate, etc.). To reduce the size and weight of medical treatment devices and enhance portability and usability, the size of information displays on defibrillators / monitors (such as LCD or LED displays) is often reduced to the point where the display area is too small to simultaneously show all medical device data (including sensor information collected from the patient and all information collected regarding diagnosis, treatment, device performance, caregiver performance, etc.). In fact, in many cases, the defibrillator / monitor may be only less than 0.5 ft. 3 Furthermore, its display size is only 8.5” (diagonal length), but the amount of information collected and generated by the defibrillator / monitor at any given time can easily fill an entire display screen of 36” (diagonal length) or larger. This presents a dilemma for clinicians using medical devices: selecting which information to display is often difficult, and displaying one parameter comes at the cost of losing visibility for another. Additionally, frontline caregivers, such as nurses in hospitals or emergency medical technicians (EMTs) in pre-hospital settings, are often trained in highly standardized protocols, making it difficult for them to determine what information should be viewed on the monitor (and therefore, to identify information that is not visible or missing on the monitor); as a result, potential clues are sometimes missed in patient diagnosis and treatment, leading to misdiagnosis and sometimes ineffective or harmful medical interventions.

[0117] Returning to an example of a nurse treating a patient experiencing cardiac arrest in a hospital, it would be desirable for the ED (Emergency Medical Examiner) supervisor to be able to view various medical device data in a way independent of what the caregiver is viewing on the medical treatment device. Ideally, this independent viewing of medical device data should not cause the supervisor's viewing behavior to interfere in any way with the caregiver's operation of the medical treatment device. This is achieved by having at least one companion device 110, 111, 119, 204, through which the supervisor or other medical personnel can access the medical device data. Companion devices 110, 111, 119, 204 can be portable computing devices such as tablets, personal displays / digital assistant devices, or telephones. Companion devices 110, 111, 119, 204 can also be large wall-mounted touchscreen displays mounted on the walls of the patient's room. Companion devices 110, 111, 119, 204 enable the supervisor to display a larger set of medical device data available on the medical treatment device compared to what can be viewed on the limited display area of ​​the medical treatment device. By viewing a larger set of medical device data on companion devices 110, 111, 119, and 204, supervisors will be able to better assess the appropriateness of caregivers' diagnostic and treatment decisions for patients. However, even for supervisors, and for those who neglect caregivers' treatment plans and strategies, it is easy to "get lost" among all the data. This difficulty can be addressed by providing a display mode on companion devices 110, 111, 119, and 204 that provides a visual representation of the medical treatment device (e.g., defibrillator / monitor) display, referred to as a device view. In some examples, the visual representation may include an exact copy of the data displayed at the medical treatment device. In other examples, the visual representation of case information at companion devices 110, 111, 119, and 204 may include data and format variations that can enhance the companion device user's viewing and understanding of the case information. In some examples, the display layout, magnification of individual data sections, physiological waveform selection, physiological digital readout selection, resolution, waveform duration, waveform size, text size, font, and / or display color may differ from the content displayed at the medical treatment device. In one example, the font and size of one or more items of displayed case information can be enlarged and / or highlighted to draw the user's eye to the relevant case information on the accessory devices 110, 111, 119, 204. In this important manner, supervisors can understand the scope of medical device data upon which caregivers are making sometimes flawed decisions. At least one additional display mode can be utilized on the accessory devices 110, 111, 119, 204, allowing for a customizable display format referred to as a working view. In one or more examples, the ability to provide a working view at the accessory device can form an aspect of the invention.Therefore, in another aspect, the present invention relates to a medical treatment system comprising a medical treatment device configured to monitor a patient. The medical treatment device may include: at least one sensor input configured to generate a signal corresponding to at least one physiological condition of the patient during a medical event; a medical treatment device display interface for presenting medical information based on the generated signal; and at least one first processor operatively coupled to the at least one sensor input and the medical treatment device display interface, the at least one first processor being configured to receive and process the signal corresponding to at least one physiological condition of the patient, generate medical data based on the processed signal, display case information including visually rendered physiological information based on the medical data at the medical treatment device display interface, and transmit at least a portion of the generated medical data to an accessory device. The accessory device may be coupled to the medical treatment device via a network communication and may include a device interface having a display screen and at least one second processor operatively coupled to the device interface, the at least one second processor being configured to process the medical data received from the medical treatment device such that a working view is displayed at the display interface. In one or more examples, the working view provides a customizable view of physiological information based on portions of the medical data received from the medical treatment device. The work view can be customized in real time during a medical event based on user input.

[0118] If, after reviewing the work view and device view, the supervisor deems specific medical device data relevant to the caregiver's decision-making process, and the device view lacks that relevant medical device data, an instruction can be sent to the medical treatment device to modify its operation. In some embodiments, the change in operation may include a command to initiate one or more measurements or to collect data related to the patient's condition. In some embodiments, if the supervisor notices that more time has passed since the last blood pressure reading, the change in operation may take the form of a command to initiate a blood pressure reading via an oscillometric blood pressure cuff. In another embodiment, in the case of a heart attack victim, a 12-lead initiation may be made from companion devices 110, 111, 119, 204. Alternatively, the change in operation may be a change in the display format of the medical treatment device. For example, when treating a patient with dyspnea (asthma), the caregiver may choose not to include a carbon dioxide waveform or EtCO2 value on the display of the medical treatment device. The supervisor sees a carbon dioxide waveform in the work view indicating obstructive pulmonary disease and switches to the device view, seeing that no carbon dioxide information is displayed (based on which potentially flawed medical decisions by the caregiver are made). Based on this, the supervisor can issue instructions from the supporting devices 110, 111, 119, and 204 to the medical treatment device to change its display format and display carbon dioxide chromatogram information. Alternatively, the instruction can take the form of a request to change the display format. This request can be in the form of a text request to the caregiver operating the medical treatment device (e.g., "Important patient information: Please display the carbon dioxide chromatogram").

[0119] The accompanying display device allows supervisors to conveniently access various medical device data as a medical event progresses. For example, upon first arriving at the patient's room during an emergency, the supervisor can retrieve the accompanying devices 110, 111, 119, and 204 from a pocket in their clothing (in the case of an iPhone) or from a storage compartment, such as next to the patient's bedside (a bag or storage shelf for accompanying devices 110, 111, 119, and 204) (in the case of a tablet). The supervisor can then choose to immediately see a visual reproduction of the medical treatment device's screen through the device view capabilities of accompanying devices 110, 111, 119, and 204. In some examples, the visual reproduction may include an accurate copy of the data displayed at the medical treatment device. In other examples, the visual reproduction of the case information at accompanying devices 110, 111, 119, and 204 may include data and format variations that enhance the viewing and understanding of the case information by the accompanying device user. In some examples, the display layout, the magnification of each data section, the selection of physiological waveforms, the selection of physiological digital readouts, the resolution, waveform duration, waveform size, text size, font, and / or display color may differ from what is displayed on the medical treatment device. The supervisor can also set up a work view to customize the presentation. Because the work view provides a page that does not limit what can be displayed, the supervisor can add additional display cards or data sections (such as specific trend information, 12-lead ECG data, CPR performance summaries, etc.) not shown on the device view for easy access to more information. As a result, the supervisor can then switch between the device view and the work view. As the code progresses, the caregiver (e.g., a nurse, emergency technician) begins chest compressions and gazes at the medical treatment device's screen to view the chest compression dashboard. To assess the caregiver's performance, the supervisor can view a summary of chest compression performance displayed in real time on the work view of the companion devices 110, 111, 119, 204, and can also periodically navigate to the device view to see what the caregiver is looking at to determine how best to guide the caregiver.

[0120] In some embodiments, a user at the auxiliary devices 110, 111, 119, 204 can control one or more functional operations and / or provide one or more inputs to the medical treatment device, thereby providing the technical advantages of easy access to the user input screen and avoiding interruption of treatment being provided to the patient by other caregivers. In one example, the auxiliary devices 110, 111, 119, 204 include a user-friendly touchscreen, keyboard, or other control interface for submitting information and / or commands. This information and / or commands can be used by the medical treatment device to adjust one or more treatment protocols, thereby providing the technical advantages of quickly and easily customizing patient treatment, such as providing the patient's age or size for use in the treatment algorithm of the medical treatment device.

[0121] In some embodiments, a supervisor or other medical personnel (e.g., a document administrator) can load treatment tags from accessory devices 110, 111, 119, 204, instead of having to initiate a record of treatment tags on the medical treatment device. In this case, instructions can be sent from accessory devices 110, 111, 119, 204 back to the medical treatment device to load event tags into its treatment record, and potentially back to a cloud server storing the medical device data. Therefore, the treatment record can be stored on the medical treatment device itself, without needing to be stored on accessory devices 110, 111, 119, 204. Alternatively, in some cases, instructions to load event tags can be sent from accessory devices 110, 111, 119, 204 not only to the medical treatment device but also to the cloud server storing the treatment record. Alternatively, the cloud server can poll the medical treatment device for the latest treatment record without requiring direct communication between the cloud server and accessory devices 110, 111, 119, 204. Medical treatment devices can preferably be operated undisturbed by only the person immediately using the device, rather than being moved or otherwise engaged with by others. Furthermore, as codes progress, supervisors may wish to proactively review existing cases to see events of interest, such as ECG rhythms present when shockability was previously determined, or the effects on certain vital signs once medication is delivered. If more than one accessory device 110, 111, 119, 204 is paired with and available to the medical treatment device, the operational view of accessory devices 110, 111, 119, 204 can be set using only the chest compression dashboard to provide chest compression feedback related to the performance of manual compressions. Additionally, a ventilation dashboard can be displayed at accessory devices 110, 111, 119, 204 to provide ventilation feedback, thus using one or more of accessory devices 110, 111, 119, 204 as dedicated feedback devices. Therefore, the working view of the accessories 110, 111, 119, 204 can be set using only the ventilation instrument panel to provide ventilation feedback related to the performance of manual ventilation.

[0122] In some implementations, the supporting devices 110, 111, 119, and 204 can display sensor data from one or more physiological sensors connected to the medical treatment device in real time. In some examples, the supporting devices 110, 111, 119, and 204 can display a visual reproduction of the information displayed at the medical treatment device in a first display view. This first display view (referred to as the device view) allows additional medical team members to participate in patient treatment without having to be physically present at the medical treatment device. For example, a rescue team supervisor overseeing and coordinating patient treatment during a critical care event (e.g., chest pain, cardiac arrest, traumatic brain injury (TBI), respiratory distress, or critical care monitoring) can view the same waveforms and patient data displayed at the medical treatment device in real time. This allows the supervisor or other medical team members to simultaneously observe both the rescuer's actions and the patient data, enabling the supervisor to provide recommendations to further enhance patient treatment and coordinate treatment by multiple rescuers. In some examples, the device view displays a visual reproduction of the case information displayed at the medical treatment device. The medical device data displayed in the device views of the supporting devices 110, 111, 119, and 204 is a visual reproduction of the information displayed at the display interface of the medical treatment device 202 when one or more of the following visual elements are reproduced in the device view: display layout, magnification of each data section, physiological waveform selection, physiological digital readout selection, resolution, waveform duration, waveform size, text size, font, and display color. In some examples, the visual reproduction of the display screen of the medical treatment device 202 at the supporting devices 110, 111, 119, and 204 can accurately replicate the content displayed at the medical treatment device 202, or one or more of the visual elements can be modified relative to the content displayed at the medical treatment device 202. In one example, the font and size of one or more items of the displayed case information can be enlarged and / or highlighted to draw the user's eye to the corresponding case information. A particular type of waveform or other data can be magnified in a specific way or color-coded. For example, ECG waveforms can be magnified similarly (such as in a 12-lead analysis), or certain waveforms can be emphasized in terms of resolution, color, or other reproduction methods. Alternatively, in some embodiments, values ​​representing discontinuous physiological measurements (e.g., NIBP, SpO2, HR, EtCO2) can be displayed in a similar font size or layout. In some cases, for example, visual reproduction can be a copy of information presented on a display interface of a medical treatment device, or alternatively, with minor variations thereof.

[0123] Rescuers and other medical team members may also wish to view additional information compared to what is provided in the device view. In some implementations, companion devices 110, 111, 119, and 204 may also display one or more patient data dashboards tailored to the user preferences or treatment roles of companion devices 110, 111, 119, and 204 in a second display view, referred to as the “working view,” which is separate from the device view and accessible to the user (e.g., via a selection tab or other user input) on the same companion devices 110, 111, 119, and 204. In some examples, the data dashboard displays physiological sensor data such as ECG waveforms, pulse oximetry waveforms, and CO2 waveforms. In some examples, the pulse oximetry waveform may include one or more of the following waveforms: peripheral capillary oxygen saturation (SpO2), carbon monoxide saturation (SpCO), methemoglobin (SpMet), total hemoglobin (SpHB), oxygen saturation (SpOC), pulse perfusion variability index (PVI), and perfusion index (PI). In some examples, the working view may be a scrollable display screen including a data dashboard, which displays treatment-based sensor data associated with the treatment device or method, in addition to or in addition to the information displayed within the device view. For example, the CPR data dashboard may display real-time CPR information, such as chest compression depth and chest compression rate. The displayed CPR information can provide rescuers delivering CPR chest compressions to the patient with real-time feedback regarding whether the depth of each chest compression is within the target range and the target compression rate. In some cases, rescue team members delivering CPR chest compressions to the patient may choose to make the chest compression dashboard more prominently displayed within the working view than other dashboards to more easily view feedback associated with the delivery of CPR chest compressions. Similarly, in some embodiments, the ventilation dashboard may display real-time ventilation information, which in some examples includes ventilation rate, tidal volume, and minute volume. In some cases, rescuers delivering ventilation to the patient may choose to display the ventilation dashboard within the working view to more easily view feedback associated with delivering ventilation to the patient. Users of the companion devices 110, 111, 119, and 204 can add or remove any dashboards to suit their viewing preferences. In some cases, working views can be temporarily created and customized during medical procedures by providing viewers of the companion devices 110, 111, 119, and 204 with controls that allow them to format medical device data according to their wishes.

[0124] Additionally, in some embodiments, the companion device user can view case information for a specific type of medical event in another implementation of the working view (referred to as a "case type view"). Providing a "case type view" at the companion device in one or more examples may include an aspect of the invention. For example, certain types of medical events may have certain waveforms, data dashboards, and information more relevant to the type of care being delivered to the patient, and each case type view may be pre-configured with these most relevant data dashboards. The "case type" view may include a "basic monitoring" view displaying ECG and SpO2 waveforms, as well as heart rate, blood pressure, and SpO2 trends. The TBI view may display ECG, EtCO2, and SpO2 waveforms, heart rate and respiratory rate trends, and a TBI dashboard. The "advanced monitoring" view may display ECG, EtCO2, and SpO2 waveforms, as well as heart rate, 12-lead results, ST trends, blood pressure, SpO2, EtCO2, and respiratory rate trends. The “Respiratory Distress” view displays ECG, EtCO2, and SpO2 waveforms, heart rate, blood pressure, SpO2, EtCO2, and respiratory rate trends, as well as a ventilation (BVM) dashboard. The “Cardiac Arrest” view displays ECG and SpO2 waveforms, SpO2 and EtCO2 trends, as well as a CPR and ventilation dashboard. The “Critical Care Monitoring” view displays ECG, EtCO2, SpO2, and invasive blood pressure (IBP) 1 / 2 / 3 waveforms, as well as heart rate (HR), respiratory rate (RR), NIBP, EtCO2, SpO2, and IBP 1 / 2 / 3 trends. By providing pre-configured display views tailored to different types of medical intervention events, the companion devices 110, 111, 119, and 204 offer caregivers the technical flexibility to quickly view user-friendly displays of case information relevant to a given event. In some implementations, case information may include physiological information derived from physiological sensors, medical intervention data derived from treatment delivery sensors and / or manual input, and caregiver performance data derived from caregiver performance sensors. In some examples, the accessory devices 110, 111, 119, and 204 can also display work views tailored to the roles of each caregiver in the rescue team. For example, the CPR work view can automatically make the chest compression dashboard prominently displayed on accessory devices 110, 111, 119, and 204 for the rescuer performing CPR to view.

[0125] In some implementations, users of the supporting devices 110, 111, 119, and 204 can also view data trends during a medical event in a third display view (referred to as a "trend view") of the supporting devices 110, 111, 119, and 204. The trend view (which can be a view selectable separately from the device view and the operational view) can display trends in physiological sensor values ​​over time during the medical event (e.g., ST trend, SpO2, EtCO2, blood pressure, heart rate). In some cases, trend data can be displayed in graphical or tabular format.

[0126] In some examples, doctors and other medical personnel who may not be directly involved in the rescue effort may use customized companion devices 110, 111, 119, and 204 to monitor the patient's condition and provide treatment recommendations based on the case information displayed at the companion devices 110, 111, 119, and 204. In some cases, doctors with companion devices 110, 111, 119, and 204 may communicate with the medical treatment device via the Internet (such as via Wi-Fi) to receive real-time case information from a workstation or office location, rather than in the immediate vicinity of the patient and the rescue team administering treatment.

[0127] Various aspects of the invention also relate to enabling a user to provide input to a medical treatment device via an input displayed on the user interface screen of the companion devices 110, 111, 119, 204. During the treatment of critically ill patients, rescuers close to the patient are often busy meeting the patient's medical needs, whether this includes administering defibrillation or ventilation, chest compressions, or wound treatment via a medical treatment device. Furthermore, local user input interfaces (e.g., keyboards and other buttons for inputting information) for medical treatment devices can be cumbersome to operate in time-sensitive situations. Conversely, in some examples, users at companion devices 110, 111, 119, 204, which may not provide direct patient care, can control one or more functions and / or provide one or more inputs at a user-friendly touchscreen on companion devices 110, 111, 119, 204 without interfering with patient treatment. In some examples, users of companion devices 110, 111, 119, 204 can input patient information, record treatment markers, initiate 12-lead ECG analysis, or record device snapshots. Therefore, users are able to provide instructions via the accompanying devices 110, 111, 119, 204 to activate one or more operations of the medical treatment device. This provides enhanced technological flexibility that is not available when operating locally at the medical treatment device, by enabling supervisors or other personnel at the scene of the medical event to observe in real time how the medical event is progressing without having to remain in the treatment area (which could interfere with patient care).

[0128] In response to receiving user input at accessory devices 110, 111, 119, 204 associated with one of the control operations at a medical treatment device, in some implementations, accessory devices 110, 111, 119, 204 transmit instruction signals to cause a corresponding operation to occur at the medical treatment device. In some examples, the instruction signals sent from accessory devices 110, 111, 119, 204 to the medical treatment device may instruct the medical treatment device to update patient information, treatment information, or diagnostic information for a medical event. In response to receiving the corresponding signal, the medical treatment device performs a corresponding operation associated with the instruction signal, which may include storing provided information (e.g., transmitting patient information for updating at the medical treatment device) or recording treatment markers (e.g., transmitting treatment / event markers for the medical treatment device to record in a patient care record) or initiating a snapshot (e.g., transmitting an instruction signal for the medical treatment device to initiate a snapshot of an ECG associated with the time of the instruction input) or activating analytical features at the medical treatment device (e.g., an instruction signal for the medical treatment device to perform a 12-lead analysis). In some embodiments, the command signal may further include a control signal for initiating electrotherapy or applying another treatment by the medical treatment device (defibrillator). When the medical treatment device is a ventilator, the command signal may include a control signal for applying positive pressure ventilation to the patient. In some examples, upon initiation and / or completion of the corresponding operation, the medical treatment device transmits a notification signal to the companion devices 110, 111, 119, 204. In response to receiving the notification signal from the medical treatment device, the companion devices 110, 111, 119, 204 may cause a notification message indicating that the corresponding action is in progress to be displayed at the companion devices 110, 111, 119, 204; and subsequent notification signals from the medical treatment device to the companion devices 110, 111, 119, 204 may then display a notification message indicating that the corresponding action has been performed. Therefore, the systems and methods described herein provide a technical solution to the technical problem of enabling control of a medical treatment device by more than one user providing input at one or more companion devices 110, 111, 119, 204 located remotely from the medical treatment device. For example, prior to the development of the improvements described in this invention, personnel were limited to providing input or control operations directly at the interface of the medical treatment device. Due to the inconvenience of this technology, treatment markers, 12-lead analysis, and snapshots could not be recorded at prominent treatment points, which reduced the effectiveness of event reporting, personnel assessment, and patient condition analysis. Therefore, the systems and methods described herein provide a solution to the clinical and technical problem of providing patient care in real time during critical medical events based on all available information, such as how treatment was delivered and how patients responded to all types of treatments administered.Furthermore, the systems and methods described in this paper address clinical and technical challenges that enable supervisors to provide real-time treatment feedback to rescuers and others providing direct medical care, creating a more beneficial training environment for both new and experienced rescue teams and individuals.

[0129] refer to Figure 1A At an emergency care scene 100a, rescuer 104 performs cardiopulmonary resuscitation (CPR) on the victim or patient 102 (these terms are used interchangeably herein to refer to a person who is the subject of anticipated or actual CPR and related or other medical treatment) (such as an individual who has clearly experienced cardiac arrest). An emergency care scene 100a may be, for example, at the scene of an accident or health emergency, in an ambulance, in an emergency room or hospital, or in another type of emergency. Rescuer 104 may be, for example, a civilian responder with limited or no training in lifesaving techniques; a first responder, such as an emergency medical technician (EMT), police officer, or firefighter; or a medical professional, such as a doctor or nurse. Rescuer 104 may act alone or with the assistance of one or more other rescuers (such as a partner EMT 106). Figure 1A In the example, rescuer 104 can deliver chest compressions to patient 102, and rescuer 106 can deliver ventilation to patient using ventilation device 112 (e.g., bag mask).

[0130] In this illustration, rescuers 104 and 106 may deploy a defibrillator 108 (such as an automated external defibrillator (AED), a specialized defibrillator, or another type of defibrillation device) to treat patient 102. The defibrillator 108 is connected via one or more cables to an electrode pad 113 intended to be placed on the patient's chest. The electrode pad 113 can acquire signals indicative of the patient's ECG, and the defibrillator 108 can analyze these signals and, if these signals determine that the patient requires defibrillation, appropriately deliver defibrillation treatment to patient 102 via the electrode pad 113. In some examples, the defibrillator 108 may instruct one or more of rescuers 104 and 106 to provide CPR or other treatment to patient 102.

[0131] Rescuers 104 and 106 may use companion devices 110 and 111, such as smartphones, tablets, or wearable devices (e.g., watches or glasses), to assist in the treatment of patient 102. For example, companion devices 110, 111, 119, and 204 may provide prompts to assist rescuers in delivering chest compressions, ventilation, mouth-to-mouth resuscitation, defibrillation, or other treatments to patient 102. Supervisor 118 may use companion device 119 to coordinate treatments provided by multiple rescuers 104 and 106. Additional computing devices (such as laptops or computing devices integrated in ambulances) may be used to analyze patient-related health data or data indicating treatments to be delivered to the patient, or to communicate this data to remote locations (e.g., dispatch centers, emergency rooms, or remote servers).

[0132] One or more sensors (e.g., Figures 1A to 1C Sensors 122 and 126 in the example can be used to monitor patient 102. For example, sensors 122 and 126 monitor parameters indicating the patient's health status (e.g., bodily parameters such as the patient's heart rate, electrocardiogram (ECG), blood pressure, temperature, respiratory rate, blood oxygen level, end-tidal carbon dioxide level (EtCO2), lung function, blood glucose level, etc.) or other parameters indicating the patient's health status. Some sensors, such as heart rate or ECG sensors, may be included in the pad 110 of defibrillator 108. One or more sensors monitor the treatment delivered to patient 102. For example, when rescuer 104 performs CPR by detecting the rate, depth, or duration of compressions delivered to patient 102, the compression disc may be positioned under the rescuer 104's hand. Additionally, airflow sensor 122 on ventilation device 112 can monitor the volume and rate of ventilation delivered to patient 102 by rescuer 106. Some sensors can monitor both parameters indicating the patient's health status and parameters indicating the treatment delivered to the patient. For example, ventilation sensor 122 can provide information related to the patient's health status or the treatment delivered to the patient to one or more of the defibrillator 108, accessory devices 110, 111, 119, or other computing devices at the emergency care site 100a, or to remote computing devices 115, such as cloud servers hosting data storage or portals used by medical treatment systems.

[0133] Figure 1B and Figure 1C Alternative examples of emergency scenarios 100b, 100c are shown, including multiple medical treatment devices 108, 130 communicating with one or more accessory devices 110, 111, 119. For example, Figure 1BThe emergency scenario 100b shown illustrates a defibrillator 108 communicating with a companion device 110 used by rescuers 104 to assist in providing defibrillation to patient 102. A ventilator 130 (in one example) Figure 10 The ventilator 1000 shown communicates with an accessory device 111 used by rescuer 106 to assist in providing ventilation to patient 102. In some implementations, the ventilator 130 is a portable ventilator that can be used in hospital and / or pre-hospital settings (such as airmedic and ground transport), mass casualty situations, and extreme environments. In one example, the ventilator 130 weighs less than 10 pounds to provide easy transport at the emergency site, enabling delivery of pre-hospital ventilation to the patient. In some implementations, sensor data obtained from one or more sensors 122, 126 associated with the respective medical treatment devices 108, 130 can be transmitted to the correspondingly connected accessory devices 110, 111 for display within one or more user interface views. Although the user interface screen at accessory devices 110, 111 can display some of the same sensor data (e.g., SpO2, HR, blood pressure values), in some implementations, the displayed data can be associated with the correspondingly connected accessory devices 110, 111. For example, accessory device 110 can display ECG and defibrillator shock information received from defibrillator 108, and accessory device 111 can display processed ventilator sensor data, such as airway pressure (P). AW Platform pressure (P) Plat Peak inspiratory pressure (PIP) or fractional inspiratory oxygen (FIO2), etc.

[0134] Additionally, each of the accompanying tablet computers 110, 111 can transmit command signals to the corresponding medical treatment devices 108, 130 in response to user input received at the accompanying tablet computers 110, 111. The transmitted command signals can provide information and / or initiate one or more functional operations of the corresponding medical treatment devices 108, 130. For example, in response to user input, the accompanying device 110 can transmit a command signal to the defibrillator 108 to perform a 12-lead ECG analysis. Furthermore, in response to receiving user input to change the operating mode of the ventilator 130, the accompanying device 111 can transmit a command signal to the ventilator 130 to change the operating mode (e.g., Assist / Control (AC) mode, Synchronized Intermittent Mandatory Ventilation (SIMV) mode, Continuous Positive Airway Pressure (CPAP) mode, or Bilevel (BL) mode).

[0135] In some implementations, patient treatment information and caregiver performance data associated with the two medical treatment devices 108 and 130 can be displayed within the same user interface at a single accessory device 110, 111, or 119. For example, Figure 1CThis illustration shows another example of an emergency scenario where medical treatment devices 108 and 130 communicate with an accompanying tablet computer 119 via a wireless communication link. In some examples, the supervisor 118 can monitor patient treatment information received from the defibrillator 108 and ventilator 130 at the accompanying device 119. In some examples, the patient treatment information can be displayed in one or more selectable views at the accompanying device 119 or in a single user interface view. Additionally, the user interface view at the accompanying device 119 can include user inputs that enable the supervisor to transmit instruction signals to provide data or issue commands to control one or more functions of the medical treatment devices 108 and 130. Providing a single caregiver with the ability to view case information from multiple medical treatment devices 108 and 130 offers a technological solution to clinical and technical problems, as caregivers and / or supervisors using the accompanying device 119 can provide enhanced guidance and support to other rescuers 104 and 106 regardless of the environment providing emergency care, and enables control over one or more of the multiple treatment devices in terms of their operation or the content they display. Furthermore, in certain emergency care situations where patient access or rescue personnel are limited, the ability to provide a single caregiver with the ability to simultaneously monitor case information from multiple medical treatment devices 108, 130 and transmit instruction signals to control the operation of the medical treatment devices 108, 130 enables patients to receive advanced medical care in remote or non-traditional care settings.

[0136] Figure 1D Another embodiment of an emergency scene 100d is shown, which includes a medical treatment device 108 that communicates directly wirelessly with the companion device 119 (e.g., without communication via a local area network (LAN), wide area network (WAN), Internet, cloud services, or other intervention network). For example, the wireless communication may include Wi-Fi, Bluetooth, near field communication (NFC), Zigbee, or other wireless communications. In some implementations, the wireless communication channel is a secure channel. For example, the wireless communication channel may be password-protected, encoded, or otherwise protected against connections from unauthorized devices. Although illustrated as communicating only with a single companion device 119, in other embodiments, two or more companion devices may communicate directly wirelessly with one or more medical treatment devices.

[0137] Local wireless communication channels can be established between two or more devices at an emergency medical scene to enable secure and accurate data sharing between these devices. For example, see reference... Figure 2Health data related to the patient, data instructing the delivery of treatment to the patient, or other types of data can be exchanged via wireless communication channel 200. Exchanging data via wireless communication channel 200 enables the efficient and accurate coordination of treatment by multiple rescuers. In some examples, the wireless communication channel is established only between some of the devices involved in the patient's treatment (e.g., between two of these devices). In some examples, the wireless communication channel is established between all the devices involved in the patient's treatment.

[0138] Go to Figure 2 In some implementations, an example environment 200 for customizing the display of case information at an accessory device includes a medical treatment system having a set of devices for providing treatment to a patient during a medical event. The system may include a medical treatment device 202 (e.g., medical treatment devices 108, 130) and one or more accessory devices 204 (e.g., accessory devices 110, 111, 119) communicatively coupled to the medical treatment device 202 via a communication link 206. In an exemplary example, the devices 202, 204 of the medical treatment system may coexist at a treatment delivery location (such as a hospital, medical clinic, or ambulance). In other implementations, one or more accessory devices 204 may be added to the system at some point during or after the delivery of medical treatment. Conversely, at least one accessory device 110, 111, 119, 204 may be removed from its common location during or after the delivery of treatment. These devices can be configured to communicate data in a wired or wireless manner to transmit information between certain devices 202, 204 of the system during and / or after the delivery of treatment.

[0139] In some implementations, the wireless communication link 206 for connecting the medical treatment device 202 and the supporting devices 110, 111, 119, 204 may, in some examples, be a Wi-Fi network, other short-range wireless communication networks or near-field communication (NFC) networks, local area networks (LANs), wide area networks (WANs), or the Internet. In other examples, devices 202, 204 may be configured to communicate over a longer communication range, such as within a cellular communication network. In some implementations, the medical treatment device 202 may be used as a wireless access point to provide direct wireless connectivity with the supporting devices 110, 111, 119, 204. In other examples, the wireless communication link 206 may be provided via a Bluetooth personal area network.

[0140] In some embodiments, different devices 202, 204 can be configured to communicate with each other via different types of communication links 206. In some implementations, devices 202, 204 can be configured to transmit data to a receiver via a short-range wireless communication transmitter (e.g., a Bluetooth beacon). In one example, first companion devices 110, 111, 119, 204 can communicate with medical treatment device 202 via a Wi-Fi communication link, while second companion devices 110, 111, 119, 204 can communicate with medical treatment device 202 via a Bluetooth communication link. In some implementations, companion devices 110, 111, 119, 204 can connect to medical treatment device 202 via a wireless communication link without physically accessing or interacting with medical treatment device 202. In some examples, Transport Layer Security (TLS) is used at the application layer to provide a secure (encrypted) connection between devices 202, 204. As a second layer of protection, encrypted Wi-Fi or encrypted Bluetooth can be used at the physical layer.

[0141] In some implementations, when the wireless communication link 206 is a cellular communication link, the functionality of the medical treatment device 202 can be extended to clinicians who are not on-site and / or are conducting telemedicine. For example, while EMS is transporting a patient to the hospital in an ambulance, the medical team waiting for the patient to arrive at the hospital can stream real-time case information at the supporting devices 110, 111, 119, and 204 at the hospital via a cellular link. In some examples, the wireless communication link 206 may include a combination of multiple wireless communication networks based on the proximity of the medical treatment device 202 to the supporting devices 110, 111, 119, and 204.

[0142] In some implementations, the medical treatment device 202 and its supporting devices 110, 111, 119, and 204 each include corresponding wireless communication engines 224 and 236 for enabling wireless communication between devices 202 and 204 via a wireless communication link 206. For example, the wireless communication engine 224 of the medical treatment device 202 may be configured to transmit messages generated by the message configuration engine 220 to the supporting devices 110, 111, 119, and 204. The wireless communication engine 236 of the supporting devices 110, 111, 119, and 204 may be configured to transmit command signals generated by the signal generation engine 230, which, in some examples, can be used to control one or more functional operations of the medical treatment device 202. In some examples, the wireless communication engines 224 and 236 are configured to apply encryption protocols to outgoing signals transmitted to other devices 204 and 202. Similarly, the wireless communication engines 224 and 236 can decrypt incoming signals from other devices 204 and 202.

[0143] In some embodiments, the wireless communication engine 224 of the medical treatment device 202 may be configured to detect that the corresponding companion devices 110, 111, 119, 204 are within communication range, and in response, initiate one or more actions to connect to the companion devices 110, 111, 119, 204 via the wireless communication link 206. In some implementations, the companion devices 110, 111, 119, 204 that can be paired with the medical treatment device 202 may be pre-configured to automatically connect to the medical treatment device 202 via the wireless communication link 206 when within communication range, without having to distinguish other devices that happen to be within range and / or negotiate wireless communication connections. Furthermore, instead of requiring users to potentially spend a significant amount of time manually configuring the systems of each of the companion devices 110, 111, 119, and 204 to connect to the medical treatment device 202 or accessing a screen to view and then selecting from possible device connections, companion devices 110, 111, 119, and 204 located at the emergency site can be pre-configured to dynamically join and / or leave the security network or pair with the medical treatment device 202 (e.g., automatically and / or using one or more simple actions (e.g., switch actuation, button press, near-field communication connection, radio frequency, location / proximity recognition, gesture code, tap / bump recognition, motion activation, sound / vibration, voice command / recognition, etc.) and / or simply by physically approaching each other, such as via Bluetooth proximity connection). Figure 6A When icon 601 is selected, the device user can view all available pre-configured wireless communication links that companion devices 110, 111, 119, and 204 can use to connect to medical treatment device 202. The user can also view other available networks not pre-configured for connection. In some examples, companion devices 110, 111, 119, and 204 may be pre-configured for pairing with other medical treatment devices, and these pre-configured networks may also be displayed when icon 601 is selected.

[0144] Once such a connection is established via wireless communication link 206, patient information (e.g., physiological data, patient history, rescue information) can be reliably and securely transmitted between the connected devices 202, 204 using any suitable type of communication, despite the presence of many other nearby devices. This can be done in an erroneous manner (e.g., according to the HIPAA standard, 802.11i protocol). Properly paired companion devices 110, 111, 119, 204 with the corresponding medical treatment device 202 can help avoid the risk of transmitting erroneous patient information that could be detrimental to patient prognosis between medical devices. In some embodiments, to maintain accurate and secure communication, proximity-based interactions can invoke authentication protocols (such as using encryption keys, vector initialization, hash encryption, digital certificates, etc.) to ensure that data transmission between devices is not lost and / or leaked. Additionally, the wireless communication engine 224 of the medical treatment device 202 can be configured to simultaneously stream data to multiple companion devices 204 in real time via separate wireless communication links 206 for each companion device 110, 111, 119, 204.

[0145] In some implementations, numerous additional security-oriented design elements may be implemented for the medical treatment system to ensure the security of data exchanged between medical treatment device 202 and its companion devices 110, 111, 119, 204. For example, medical treatment device 202 and / or companion devices 110, 111, 119, 204 may use certificate-based authentication to ensure the authenticity of the respective paired devices. In some examples, during initial connection and setup, devices 202, 204 may perform association processing to bind specific companion devices 110, 111, 119, 204 to a single medical treatment device 202, such that only companion devices 110, 111, 119, 204 (and any other similarly paired companion devices) can interoperate with medical treatment device 202. In some embodiments, any Representational State Transition (REST) ​​or WebSocket communication may require an authenticated connection to enable data exchange between devices 202, 204. In some examples, the medical treatment device 202 disables connections used to open Wi-Fi communication links and can only connect to manually defined (e.g., supervisor-defined) Wi-Fi networks. As an additional security measure, when the wireless communication link 206 is a Bluetooth connection, the device pairs during initial setup when configuring the initial connection settings. Furthermore, the data and computer architecture of the medical treatment device 202 can be designed for additional security, which may include separating communication and clinical controls onto separate microprocessors.

[0146] In some examples, when more than one companion device 110, 111, 119, 204 is paired with medical treatment device 202, one of companion devices 110, 111, 119, 204 can be pre-designated as the primary companion device. The primary companion device can be designated by medical treatment device 202 during device setup, pairing, and configuration by receiving and storing an encrypted token from medical treatment device 202. The encrypted token can be sent to medical treatment device 202 along with each instruction from the primary companion device 110, 111, 119, 204.

[0147] In some implementations, the supporting devices 110, 111, 119, and 204 can be displayed in the view of the supporting devices 110, 111, 119, and 204. Figures 6A to 6C and Figures 8B to 8G The status information of the medical treatment device 202 may be displayed in one or more locations. For example, such as... Figure 6A As shown, the device view 600 may include a status bar 603 that displays the battery life, connectivity status, and unique name of the medical treatment device 202.

[0148] Additionally, in some implementations, companion devices 110, 111, 119, and 204 include controls for confirming the connection between the companion device and a specific medical treatment device. This provides the technical advantage of confirming wireless pairing between the companion device and one of multiple medical treatment devices deployed in the same location. Providing user input at the companion device, such as through actuating user interface options, can be configured to provide one or more signals to the paired medical treatment device, wherein the one or more signals include a request for the medical treatment device to identify itself. In response to receiving one or more signals, the medical treatment device can be configured to provide output to the user of the companion device for self-identification. The medical treatment device can be configured to provide a predetermined indication on its display to indicate that it has received a request for self-identification. In other examples, the output may include an audible output for self-identification. In one or more examples, the connection confirmation feature may include a key aspect of the companion device's functionality. In an exemplary example, status bar 603 may include verification input (e.g., Figure 6A The input selector 618 in the device view user interface verifies the input, enabling the accessory devices 110, 111, 119, 204 to cause an indicator to flash at the medical treatment device 202 to confirm that the accessory devices 110, 111, 119, 204 are connected to the correct medical treatment device 202 during use. For example, one or more display views of the accessory devices 110, 111, 119, 204 (e.g., Figure 6AThe device view UI screen 600 may include a pairing device verification input 618, which enables the pairing device user to verify which medical treatment device 202 is connected to pairing devices 110, 111, 119, 204. In some examples where multiple medical events are occurring simultaneously (such as in a hospital trauma ward or at the scene of a mass casualty incident), multiple rescue teams may operate multiple medical treatment devices within close proximity to each other. In such cases, it can be easy to confuse pairing devices paired with corresponding medical treatment devices. Therefore, in some implementations, when verification input 618 is selected, pairing devices 110, 111, 119, 204 may generate instruction signals that cause the connected medical treatment device 202 to generate an indication that it is paired with pairing device 110, 111, 119, 204. In some implementations, upon receiving a verification signal from pairing devices 110, 111, 119, 204, medical treatment device 202 may output visual and / or auditory indications connected to pairing devices 110, 111, 119, 204. In some examples, the indicator may be a flashing light and / or a tonal sound pulse.

[0149] Go to Figure 3 In some implementations, an example method 300 is shown for configuring the connection between medical treatment device 202 and companion devices 110, 111, 119, 204. In some examples, method 300 begins by the medical treatment device 202 (such as a defibrillator) detecting the presence of companion devices 110, 111, 119, 204 via wireless communication network 206 based on companion devices 110, 111, 119, 204 (302). If the medical treatment device 202 and the detected companion devices 110, 111, 119, 204 have established a pre-configured pairing (304), then in some examples, the medical treatment device 202 and companion devices 110, 111, 119, 204 establish a wireless connection (306). In some embodiments, previously paired medical treatment devices 202 and companion devices 110, 111, 119, 204 can automatically connect to each other. In other examples, upon detection of a corresponding device, medical treatment device 202 and / or companion devices 110, 111, 119, 204 may present a notification to the user at a display interface requesting user authorization to connect to the other device 202, 204. In response to presenting this notification, if one or both of devices 202, 204 receive input confirming connection to the other device 202, 204, a wireless communication link is established between devices 202, 204.

[0150] If no pre-configured pairing has been established between the two devices 202 and 204, it can be determined in some respects whether to establish a wireless connection between devices 202 and 204 (306). In some examples, only devices 202 and 204 that have passed the initial setup and pairing process are allowed to wirelessly connect to each other. In another example, an authorized supervisor or system administrator can configure pairing between the medical treatment device 202 and the companion device prior to the initial connection (310) between devices 202 and 204 (308). In one example, the initial pairing may include one or more types of wireless communication links, such as Wi-Fi, Bluetooth, or Zigbee connections.

[0151] In some embodiments, if a credentialed user (312) is authenticated at the companion device, in some examples, as further discussed below, companion devices 110, 111, 119, 204 may customize one or more companion device display views (316) based on stored role data 258a and customization data 260a for user preferences or user's role of action. In some examples, if the amount of time elapsed between uses of companion devices 110, 111, 119, 204 is less than a threshold amount of time, companion devices 110, 111, 119, 204 may automatically authenticate the previous user to use companion devices 110, 111, 119, 204. Otherwise, if a threshold time period has elapsed and / or a new user is logging in to use the companion device, in some implementations, companion devices 110, 111, 119, 204 may authenticate the user using received credentials such as username / password input, at least one biometric input provided at a biometric input interface (e.g., fingerprint, iris recognition, facial recognition), and / or badge scanning via a scanning sensor on the companion device (e.g., RFID scanning or computer-readable codes such as QR codes, etc.). In some examples, during authentication, the user can provide one or more inputs confirming or modifying the user's treatment role in the associated medical event. Based on the indicated treatment role, companion devices 110, 111, 119, 204 04 The display views at the accessory devices 110, 111, 119, and 204 can be further customized for the user's designated role. In some embodiments, based on the customized display interface screen presented at the accessory device and the user input received at the display interface, the medical treatment device 202 can transmit requested sensor data in a customized format for display at the accessory device (318). In some implementations, in response to the establishment of a connection between the accessory devices 110, 111, 119, and 204 and the medical treatment device 202 and / or the authentication of the device user, the medical treatment device 202 can automatically begin streaming case information via the wireless communication link 206 for display at the accessory devices 110, 111, 119, and 204 without any user intervention.

[0152] Although described as a specific series of steps, other embodiments may include more or fewer steps. For example, the medical treatment device 202 may connect only to paired devices 110, 111, 119, 204 that have established a pre-configured pairing. On the other hand, if it is determined that a predetermined pairing exists between the medical treatment device 202 and the detected paired devices 110, 111, 119, 204, one or more additional steps related to ensuring data security of the wireless connection may be performed. In other embodiments, some steps may be performed in a different order, or two or more steps may be performed in parallel. For example, user authentication may be performed at paired devices 110, 111, 119, 204 before a connection is established between the medical treatment device 202 and paired devices 110, 111, 119, 204. Other modifications to method 300 are possible while remaining within the scope and purpose of method 300.

[0153] Return to Figure 2 In some implementations, the supporting devices 110, 111, 119, and 204 include a signal generation engine 230 that generates command signals, data requests, and other data signals for transmission to the medical treatment device 202. In some examples, in response to receiving user input (e.g., selection at a touchscreen on the supporting devices 110, 111, 119, and 204) for viewing case information at a customized user interface screen on the supporting devices 110, 111, 119, and 204, the signal generation engine 230 may generate a data request message for transmission to the medical treatment device 202. In some examples, the data request may be one or more data request types based on the type and amount of data being requested. For example, one type of data request may include a request for a single type of data from the medical treatment device (e.g., trend data) or for a relatively small amount of data (e.g., ventilation data used to generate a ventilation dashboard). Another type of data request may include a request for complex data grouping (such as recreating all case information required for a device view or a requested case type view). Generating specific data requests for medical treatment device 202 allows the supporting devices to flexibly modify their subscribed data sets at any time. In some examples, the data subscriptions of supporting devices 110, 111, 119, and 204 correspond to all data requested by supporting devices 110, 111, 119, and 204 to be displayed at any given time. Requesting data from the medical treatment device as a data subscription set provides supporting devices 110, 111, 119, and 204 with the ability to display different types of data on demand, and minimizes the bandwidth used by avoiding the transmission of unnecessary data that the supporting device users do not want to be displayed.

[0154] In some embodiments, the signal generation engine 230 may also generate instruction signals to cause one or more functional operations to occur at the medical treatment device 202. In some examples, one or more functional operations may include linking and storing certain submission data associated with a medical event (e.g., patient information or treatment marker data) and / or capturing or analyzing certain medical event data (e.g., generating a 12-lead ECG analysis or recording a defibrillator snapshot). For example, the signal generation engine 230 may respond to the patient information input interface of the companion devices 110, 111, 119, 204 (see...). Figure 7A The patient information signal is generated upon receiving submission of patient identification information at interface 700. The patient information signal may include the submitted patient information, and in response to receiving this signal, the medical treatment device 202 can link the received patient information 246 with the patient's medical record information 242 and store it in the data storage 208. Additionally, in response to the treatment mark input interfaces (see...) of the supporting devices 110, 111, 119, and 204... Figure 7B Upon receiving one or more treatment marker inputs at interface 712, signal generation engine 230 can generate a treatment marker signal, which may include submitted treatment marker data. In response to receiving this signal, medical treatment device 202 stores the submitted treatment data 252 in data storage 208. In some implementations, in response to detecting the selection of a snapshot input selector (e.g., at accessory devices 110, 111, 119, 204), Figure 6A In response to the snapshot input selector 616 in the medical device, the signal generation engine 230 can generate a snapshot command signal, which is transmitted to the medical device 202 to cause the medical device 202 to capture snapshots (e.g., ECG records of the patient within a period of time (e.g., 9 to 12 seconds) before and after the command to capture a snapshot, physiological signals captured by another physiological sensor within a period of time before and / or after the command to capture a snapshot, a single capture frame of the medical device interface, or a predetermined number of seconds of recording of the medical device screen) and store them in the data storage 208 as snapshot data 248 for each patient. In response to the detection at the companion devices 110, 111, 119, 204 that the 12-lead ECG analysis input selector (e.g., ...) is selected, the signal generation engine 230 can generate a snapshot command signal. Figure 6A In some examples, the signal generation engine 230 can generate a 12-lead analysis instruction signal that causes the medical treatment device 202 to perform 12-lead analysis, which can be stored in the data storage 208 as 12-lead data 250 for each patient.

[0155] In some implementations, the medical treatment device 202 may include a message configuration engine 220 for generating messages to be sent to companion devices 110, 111, 119, and 204. In one example, in response to a data request received from companion devices 110, 111, 119, and 204, the message configuration engine 220 may package the requested data for transmission in one or more predetermined message configurations or formats. In some implementations, real-time or near-real-time data (e.g., case information derived from physiological sensors 212 and caregiver performance sensors 215) may be transmitted as streaming data in JavaScript Object Representation (JSON) format sent via WebSocket. In some examples, historical and bulk data transmission may be transmitted as Representational State Transition (REST) ​​data in JSON-formatted messages. Both types of message communication (streaming data and REST data) can occur over a Transport Layer Security (TLS) connection using the TCP / IP protocol. The TCP / IP protocol can be provided via Wi-Fi or Bluetooth physical media. When data transmission occurs in real time or near real time, the case information is simultaneously displayed at the supporting devices 110, 111, 119, 204 and the medical treatment device 202, or the delay in displaying the case information at the supporting devices 110, 111, 119, 204 is less than a predetermined threshold.

[0156] In addition to configuring messages for sending real-time case information to be displayed at accessory devices 110, 111, 119, and 204, in some implementations, the message configuration engine 220 may generate one or more confirmation messages when an action is taken at the medical treatment device 202 in response to receiving an instruction signal from accessory devices 110, 111, 119, and 204. For example, in response to associating and storing submitted patient information provided by accessory devices 110, 111, 119, and 204, the message configuration engine 220 may generate a message confirming that the submitted patient information has been linked to the corresponding case information in the database 208. The message configuration engine 220 may also generate a treatment mark record confirmation message, which confirms that the recording of the submitted treatment mark at the medical treatment device 220 has begun and / or been completed (see [link to relevant documentation]). Figure 7B The system responds to receiving a treatment mark recording message by displaying notifications 714 and 718 at accessory devices 110, 111, 119, and 204. A snapshot recording confirmation message may also be generated, acknowledging that the recording and storage of snapshots at medical treatment device 220 has begun and / or been completed (see [link to relevant documentation]). Figure 7C-1The system responds by displaying notification messages 724 and 726 at accessory devices 110, 111, 119, and 204 upon receiving a snapshot recording confirmation message. It can also generate a 12-lead ECG analysis confirmation message confirming that the 12-lead ECG analysis has started and / or completed (see [link to documentation]). Figure 7C-2 In response to receiving a snapshot record confirmation message, notification messages 728 and 730 are displayed at the supporting devices 110, 111, 119, and 204.

[0157] In some implementations, the accessory devices 110, 111, 119, and 204 may also provide caregivers with the ability to view and scroll through past case information 242 on the accessory devices 110, 111, 119, and 204. In some examples, while viewing past case information 242, the accessory devices 110, 111, 119, and 204 may provide users with the ability to jump to the current (real-time) view at any time during a medical event. In one example, the accessory devices 110, 111, 119, and 204 may indicate on the display screen whether a real-time view is being displayed. In some embodiments, the accessory device user may be able to jump forward and backward in time within discrete time intervals (e.g., 5, 10, 15, 20, and 30 seconds) to view patient physiological status and caregiver performance data at different points in time during a medical event. In one example, the accessory device display interface may provide touch points for each waveform, which provide playback of the corresponding waveform. Additionally, the supporting devices 110, 111, 119, and 204 can replay past medical event data at different speeds (e.g., 0.5x, 1x, 2x) to gain a better perspective on how the treatment progressed. In some examples, the supporting devices 110, 111, 119, and 204 can display past medical data for multiple different monitored physiological sensor inputs (e.g., ECG, SpO2, CO2), vital sign data, and caregiver performance data. Furthermore, even when non-real-time data is being displayed at the supporting devices 110, 111, 119, and 204, the medical treatment device 202 continues to transmit real-time streaming case information to the supporting devices 110, 111, 119, and 204. In one example, the supporting devices 110, 111, 119, and 204 can also provide a review feature with limited time increments (e.g., 10, 20, 30 seconds), allowing the user to quickly view waveform data in review increments. In this example, the review feature can be activated via touch points on the individual waveforms.

[0158] In some implementations, the medical treatment device 202 may include an input / output (I / O) engine 226 that can collect information from multiple sensors (e.g., physiological sensor 212, caregiver performance sensor 215) built into and / or communicating with the medical treatment device 202. The I / O engine 226 may also receive user input at a user input interface (e.g., keyboard or touchscreen) on the medical treatment device 202. In some examples, raw sensor data from sensors 212, 214, 215 may be processed and analyzed by a sensor data processing engine 222, which generates multiple clinical indicators and trends (e.g., for clinician use) relating to various aspects of the treatment session that can be output by the medical treatment device 202 (e.g., displayed on a screen of the medical treatment device 202 or printed as a report). A data loading and storage engine 218 may store the generated indicators and trends as indicator data 254 and trend data 244 for each patient and / or medical event in a data repository 208. In some embodiments, the GUI rendering engine 228 causes data processed and analyzed by the sensor data processing engine 222 to be displayed on the display interface screen of the medical treatment device 202.

[0159] In some examples, sensor processing engine 222 also processes the raw ECG sensor data into first ECG information and second ECG information. The first ECG information is provided to GUI rendering engine 228 for display at medical treatment device 202, and the second ECG information is provided to GUI rendering engine 238 for display at auxiliary devices 110, 111, 119, and 204. In some examples, since the display interfaces at medical treatment device 202 and auxiliary devices 110, 111, 119, and 204 can have different sizes, sensor processing engine 222 can time-slice the first and second ECG information differently based on the display device. In one example, the local display of medical treatment device 202 receives the first ECG information at shorter intervals (e.g., 8 ms at a time) more frequently, while auxiliary devices 110, 111, 119, and 204 receive the second ECG information at longer intervals (e.g., 120 ms at a time) less frequently. This configuration of the first and second ECG information allows the supporting devices 110, 111, 119, and 204 to display ECG information in real time, while also improving data transmission efficiency, as sending larger data messages is more efficient than sending smaller ones. Furthermore, even if the content of the first and second ECG information is the same, they can be represented in different ways. For example, the first ECG information displayed at the medical treatment device may include a binary data record, while the second ECG information received by the supporting devices 110, 111, 119, and 204 may be a JSON representation as a WebSocket stream. Additionally, both the first and second ECG information signals can carry additional information such as per-sample bit flags representing specific detection conditions associated with the processed ECG data sample (e.g., QRS detection, lead failure, implanted pacing detection, internal pacing blanking, defibrillator shock information such as the energy and number of shocks applied) Additional information such as cable type and filter settings can be provided to the GUI rendering engines 228 and 238 as additional messages separate from the ECG waveform sample data.

[0160] In some aspects, the data processing engine 234 of the supporting devices 110, 111, 119, and 204 can be configured to process case information 242 received from the medical treatment device 202 in one or more received data messages. The GUI rendering engine 238 can display the processed medical event data on one or more display portions of the device interfaces at the supporting devices 110, 111, 119, and 204. The I / O engine 240 can receive and process user input at a device interface such as a touchscreen interface, where the user makes selections to customize the display of data at the supporting devices 110, 111, 119, and 204 and to cause one or more functional operations to occur at the medical treatment device 202. In some implementations, the GUI rendering engine 238 displays data processed and analyzed by the data processing engine 234 and configured by the customization engine 232 on the display interface screen of the supporting devices 110, 111, 119, and 204.

[0161] In some embodiments, the customization engine 232 can be configured to control and manage the display screens rendered by the GUI rendering engine 238 at the display interfaces of the supporting devices 110, 111, 119, 204 based on user roles and / or data presentation preferences. In some examples, instead of the data store 208 of the medical treatment device 208, or in addition to the data store 208 of the medical treatment device 208, the data storage area 210 of the supporting devices 110, 111, 119, 204 can store role data 258a and customization data 260a. In some examples, role data 258a defines which data or data dashboards are displayed in one or more device display views on the supporting devices 110, 111, 119, 204, and the format used to display these data and data dashboards. In some examples, roles may include field clinicians (chest compression team members, ventilation team members, medication injectors, supervisors, document administrators), off-site clinicians (attending physicians), or non-clinical physicians (scribers / non-clinical physicians). For example, role data 258a can define how caregiver performance data for chest compression team members, ventilation team members, and team supervisors is displayed. For scribes or non-clinical physicians, users can be granted access only to data input features (e.g., patient information entry and treatment marking records) on companion devices 110, 111, 119, and 204. When the companion device user is a non-site (remote) clinician, the user can be granted access only to data viewing features and can disable features associated with triggering events or entering patient data at companion devices 110, 111, 119, and 204.

[0162] In some embodiments, the customization data 260a may include data display format preferences for different companion device users. For example, data display preferences may indicate a user-defined work view layout for viewing one or more data dashboards for caregiver performance data. In some implementations, the customization engine 232 may be configured to manage (e.g., via user-provided credentials and / or biometric input) user authentication at companion devices 110, 111, 119, 204 and access the corresponding customization data 260a for the authenticated user. In some implementations, once a device user configures a work view layout, that layout may be stored as the user's customization data 260a and may be automatically loaded by the corresponding user at companion devices 110, 111, 119, 204 during future use. The individual customization data 260a may be passed to the signal generation engine 230 and / or the GUI rendering engine 238 to request case information from the medical treatment device 202 and / or display the requested data in a user-preferred format based on the customization data 260a. As discussed further below, Custom Data 260a can also define which data or data dashboards to display in the working view associated with a specific type of medical event (see, for example, see...). Figures 8B to 8G The case type working views shown are 814, 820, 824, 834, 840, and 844.

[0163] Go to Figure 4A and Figure 4B Example method 400 is shown for causing medical event case information 242 to be displayed at accessory devices 110, 111, 119, 204. In some examples, method 400 begins by accessory devices 110, 111, 119, 204 transmitting a device view instruction signal to a connected medical treatment device 202 (402), such as a defibrillator. In some implementations, the instruction signal corresponds to a request for case information presented in a device display view at accessory devices 110, 111, 119, 204. In some examples, the device view is one of a plurality of display views that can be presented at accessory devices 110, 111, 119, 204 and corresponds to a display view that presents a visual reproduction of data presented in real time at the display interface of medical treatment device 202. In some embodiments, in response to a request signal for device view case information, medical treatment device 202 transmits the requested data via a wireless communication link, and the requested data is received by accessory devices 110, 111, 119, 204 (404). In some examples, accessory devices 110, 111, 119, 204 cause the received information to be displayed in the device view at a display interface (406).

[0164] Figure 6AA device view user interface (UI) screen 600 is shown for the supporting devices 110, 111, 119, and 204. In some examples, the device view UI screen 600 includes one or more optional inputs at the display interface that enable the display of more, different, or additional information, enable one or more actions at the medical treatment device 202, or provide additional user input interface screens that allow the user to submit information that can be transmitted to the medical treatment device 202. For example, device view 600 may include one or more view selection tabs 602, 604 that allow the user to switch between different display views of the display interface. In one example, a user selection of tab 602 causes device view UI screen 600 to be displayed at the supporting devices 110, 111, 119, and 204. In some implementations, device view UI screen 600 may display a copy or visual reproduction of the case information 242 displayed at the medical treatment device 202. Additionally, case information 242 can be displayed on the device view UI screen 600 in the same or substantially the same format as on the display screen of the medical treatment device 202. For example, the device view UI screen 600 can display multiple waveforms and indicators indicating the patient's condition and / or the medical treatment being administered to the patient. In one example, the device view UI screen 600 may include ECG waveforms 620a, 620b, pulse oximetry (SpO2) waveform 622, and carbon dioxide (CO2) waveform 624. In other examples, the device view UI screen 600 may also display an invasive blood pressure (IBP) waveform. In some implementations, the user can modify which ECG waveforms 620a, 620b are displayed in the device view via ECG settings user input 629. The UI screen 600 may also display the current values ​​of heart rate (HR) 626, SpO2 628, CO2 630, temperature 632, and blood pressure 634a, 634b, 634c. In some implementations, the current values ​​626, 628, and 630 can each be positioned directly adjacent to their respective waveforms 620a, 620b, 622, and 666 within the device view 600. Device view 600, and other supporting device display views (trend view 636) Figure 6B ), Working View 668 ( Figure 6C ), and case type views 814, 820, 824, 834, 840 and 844 ( Figures 8B to 8GIt may also include a status bar and navigation strip with one or more selection buttons and treatment information (discussed further below), including a case event selector 610, a patient type selector 609, an alarm selector 608, a case type selector 606, a patient information input selector 612, a treatment mark input selector 614, a snapshot record selector 616, a 12-lead ECG analysis selector 617, a shock energy value 619, and a number of shocks applied 621.

[0165] In some implementations, the information displayed on the device view UI screen 600 may differ from the information displayed on the display interface of the medical treatment device 202. In some examples, the differences between the interfaces may include differences in the type, layout, or format of the displayed information. For example, the magnification, resolution, size, and screen position of each data section may vary between the device view UI screen 600 and the display interface of the medical treatment device 202. Additionally, relative waveform size and color, font, and text size may vary between the device views 600 on the accompanying devices 110, 111, 119, and 204. In one example, the device view UI screen 600 may display the numerical values ​​of all physiological case information in a maximized large number format without waveforms. In some examples, one or more items of case information displayed on the device view UI screen 600 may differ from the case information displayed on the display of the medical treatment device 202. Figure 6E The display interface 625 at defibrillator 627 is shown. Similar to the device view 600 at accompanying devices 110, 111, 119, and 204, the display interface 625 at the defibrillator may include ECG waveforms 620a and 620b, SpO2 waveform 622, and CO2 waveform 624. The UI screen 600 may also display the current values ​​of heart rate (HR) 626, SpO2 628, CO2 630, temperature 632, and blood pressure 634a, 634b, and 634c. However, the display interface at defibrillator 627 may not include a status bar and navigation strip, but instead features a case event selector 610, a patient type selector 609, an alarm selector 608, a case type selector 606, a patient information input selector 612, a treatment marker input selector 614, a snapshot recording selector 616, a 12-lead ECG analysis selector 617, a shock energy value 619, and a number of shocks administered 621, displayed on the device view UI screen 600. In some implementations, when a shock is administered to a patient, medical treatment device 202 automatically transmits shock information to auxiliary devices 110, 111, 119, and 204, resulting in an update of the shock energy value 619 and the number of shocks administered value 621. Upon updating the values, auxiliary devices 110, 111, 119, and 204 may apply a color or other indicator to the respective display windows to draw the user's attention to the value change.

[0166] In some implementations, the device view UI screen 600 ( Figure 6B and Figure 6B (As shown) View selection tabs 602, 604, 664 and ( Figures 8B to 8G The case type tabs (as shown) allow caregivers to easily switch between display views on companion devices 110, 111, 119, and 204. The ability to switch between display views and view real-time case information and caregiver performance data provides a technical solution to clinical problems such as the inability to easily grasp a complete scenario map when providing care or supervising care provided by other caregivers in the rescue team, as well as technical issues related to limitations in display area and visibility.

[0167] Return to Figure 4A In some implementations, when a selection of a trend view input (e.g., selection of trend view selector 604) is detected at accessory devices 110, 111, 119, and 204 (408), accessory devices 110, 111, 119, and 204 can configure case information to display a trend view display interface at accessory devices 110, 111, 119, and 204 (410). In some implementations, configuring trend data for display at the trend view display interface may include transmitting a signal to the medical treatment device 202 to request the transmission of medical trend data for real-time display.

[0168] For example, Figure 6B A trend view user interface (UI) screen 636 is shown for the accompanying devices 110, 111, 119, and 204. In some implementations, the trend view UI screen 636 may display medical trend data in one or more formats for device users to view. When the trend view selector 604 is selected, in some examples, the accompanying devices 110, 111, 119, and 204 may initially present a default set of case information trends (e.g., measured physiological sensor data from the medical treatment device 202) within the trend view 636 in graphical and / or tabular formats. For example, the default set of case information trends presented in the trend view may include graphs of EtCO2 638, SpO2 640, and NIBP 642 values ​​over time. The trends displayed at the trend view UI screen 636 may also include averages of EtCO2 644, SpO2 648, and NIBP 650 over the course of a medical treatment event. Alternatively, trend data may also be presented in tabular form (such as in data table 652). Figure 8C-2The data table 652 is shown in a complete view (e.g., as shown in the diagram). In some examples, the data table 652 may display one or more physiological information data trends (e.g., HR, SpO2, NIBP) at predetermined time intervals (e.g., every 10 seconds, 20 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes). For example, each row of the data table 652 may correspond to a value of one or more types of physiological information recorded at predetermined time intervals.

[0169] In some implementations, the accessory devices 110, 111, 119, and 204 can use treatment label annotations 656, 658, 660, and 662 to annotate trend graphs 638, 640, and 642, allowing the accessory device user to easily identify the impact of each treatment on the patient's condition over time. This is further discussed below (see...). Figure 7B The medical intervention device 202 can automatically record intervention marker events (e.g., detecting shockable rhythms, administering a shock to a patient, initiating chest compressions, initiating ventilation, etc.), or caregivers can manually enter intervention marker data at the medical intervention device 202 to perform other activities (e.g., administering a specific medication, placing an IV, administering oxygen, etc.). Caregivers who do not actively use the medical intervention device 202 but instead use accessory devices 110, 111, 119, 204 can manually enter intervention marker data corresponding to certain types of medical interventions (e.g., administering oxygen or medication) at accessory devices 110, 111, 119, 204. In trend view 636, intervention marker annotations 656, 660 can correspond to a shock administered to a patient via electrodes connected to a defibrillator (e.g., medical intervention device 202), intervention markers 658, 662 can correspond to administering morphine to a patient, and intervention markers can correspond to initiating an intervention to a patient (e.g., when administering or pausing chest compressions and / or ventilation). In some examples, when trend view selector 604 is selected, the supporting devices 110, 111, 119, and 204 may transmit a data request for treatment marker data 252, either individually or as part of a bulk data transmission request, to overlay the display on trend graphs 638, 640, and 642. When one of treatment marker annotations 656, 658, 660, and 662 is selected, the supporting devices 110, 111, 119, and 204 may enable the display of details related to the selected treatment marker, such as the amount of energy applied during the shock, the amount of medication administered, a display of the defibrillator waveform (e.g., waveforms 620a, 620b, 622, and 624) at the time the treatment marker was input, and / or a snapshot view of ECG or other data from the display interface at the medical treatment device 202 and / or a device view 600 at the time associated with the selected treatment marker, etc.

[0170] In some implementations, the trend view UI screen 636 may also include a trend selection tab 654a, which allows the user of the accessory device to customize the trends displayed within the display interface. For example, when the trend selection tab 654a is selected, the accessory devices 110, 111, 119, and 204 may display one or more trends for the user to select and / or deselect based on trend viewing preferences. In one example, the user may select to display waveforms and / or averages for one or more of the following: HR, pulse rate (PR), SpO2, NIBP, invasive blood pressure (systolic BP, diastolic BP, mean arterial pressure), EtCO2, respiratory rate / respiratory rate (RR / BR), and pulse perfusion variability index (PVI). Additionally, the user may choose whether to display a data table 652. In some embodiments, the user may also select the time interval for recording trend data displayed within the trend view 636 (such as within a data table 652). In some implementations, the input provided at the trend selection tab 654a can also allow the user to select a predetermined time interval (e.g., every 10 seconds, 20 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes) for recording and / or displaying trend data in the trend view UI screen 636.

[0171] Return to Figure 4A When the working view at the detected display interface is activated, input is activated (e.g., Figure 6B When the user selects the work view selection tab (664) (412), the companion devices 110, 111, 119, and 204 can configure case information to display the work view display interface (414) on the companion devices 110, 111, 119, and 204. In some examples, the work view display interface can be activated when the user configures the companion devices 110, 111, 119, and 204 to remove or add any displayed data portions (e.g., waveforms, data values, or dashboards). For example, selecting the waveform deletion input 666 on the device view UI screen 600 to remove the CO2 waveform 624 can cause the work view display interface to be activated on the companion devices 110, 111, 119, and 204. In other examples, a saved work view associated with the user account can be automatically presented when logging in to use the companion devices 110, 111, 119, and 204. In some embodiments, the work view 668 can also be activated when any waveform, indicator value, or dashboard is added for viewing. In some embodiments, the working view display interface can correspond to any type of customization of the case information displayed at the accessory devices 110, 111, 119, 204. In other words, the working view display interface corresponds to the device view 600 ( Figure 6A The display data and format of the accessories 110, 111, 119, and 204 correspond to any set of display data in any format.

[0172] For example, Figure 6C The accompanying devices 110, 111, 119, and 204 are shown with a working view user interface (UI) screen 668, which includes one or more data sections customized to the device user's preferences and / or role. In some implementations, the working view screen 668 may be a scrollable interface, allowing the user to add as many data sections as needed to the working view screen 668 for easier viewing by scrolling up or down. In one example, the working view screen 668 includes ECG waveforms 620a and 620b as in the device view, but displays SpO2 waveform 622 or CO2 waveform 624. The working view UI screen 668 may also include an IBP waveform. Additionally, the working view screen 668 also displays the current values ​​of heart rate (HR) 626, SpO2 628, CO2 630, temperature 632, and blood pressure 634a, 634b, and 634c. In some implementations, device users can manually add / remove data sections or drag / reposition data sections in the working view 668 as needed. For example, the displayed data sections can be used as grab bars that can be moved to another location within the working view 668, which automatically shifts other data sections to support the selected adjustments. In some examples, users can store manually configured working view layouts as custom data 260a, allowing companion devices 110, 111, 119, and 204 to pre-configure customized working views for users in preparation for future medical events. In some examples (such as when a caregiver is supervising other team members administering chest compressions and bag ventilation), the working view may include a chest compression dashboard 670 and a ventilation dashboard 672 that provide the user with feedback on how care is being administered to the patient.

[0173] In some implementations, the chest compression dashboard 670 displays chest compression case information input from at least one chest compression sensor. In one example, the chest compression sensor may be a motion sensor disk positioned under the caregiver's hand while chest compressions are being performed, detecting the depth and rate of chest compressions. Once compressions begin, the chest compression dashboard 670 may include a timer 688 indicating how long chest compressions have been performed during the medical event. While chest compressions are being performed, the chest compression dashboard 670 may include a compression graph 680 that displays the depth of each compression in real time compared to a target range of minimum and maximum compression depths of 671 and 674. For example, in the compression graph 680, each compression is graphically displayed as a bar, where the length of each bar corresponds to the compression depth (e.g., longer bar lengths correspond to deeper compressions, while shorter bar lengths correspond to shallower compressions). As shown in the chest compression dashboard 670, compression 676 is deeper than the maximum threshold depth target 674, while compression 678 is shallower than the minimum threshold depth target 671. The chest compression dashboard 670 can also represent compression rate graphically and / or numerically. For example, in the compression graph 680, each compression can be plotted relative to time, such that compressions occurring at a slower rate are spaced further apart than more closely spaced compressions. Compression depth can also be graphically represented in other ways, such as having a constantly changing diameter corresponding to the relative compression depth, and / or being color-coded to reflect whether each compression is within or outside the target range. For example, the chest compression dashboard 670 can include digital indicators for compression depth 686 and compression rate 687. In some aspects, when the individual depth or compression rate values ​​are outside a predetermined acceptable range, the digital indicators 686, 687 can each be highlighted with a specific color. Additionally, the chest compression dashboard 670 can display real-time feedback related to compression-release rate. For example, the release rate indicator 682 can graphically indicate whether the rescuer has fully released pressure on the patient's sternum upon completion of the compression. For example, a portion of the release rate indicator can illuminate relative to the detected compression release rate to provide real-time feedback related to the quality of the compression release. In some embodiments, the chest compression dashboard 670 may also include an perfusion performance indicator (PPI) 684, which indicates whether the depth and rate of compression are within predetermined chest compression guidelines. In one example, PPI 684 may be the outline of a shape (e.g., a rhombus) that illuminates or becomes filled with color when the compression is within predetermined rates and depths (e.g., when PPI 684 is fully illuminated, the compression is within predetermined guidelines). When PPI 684 is not fully illuminated, this indicates to the caregiver (the supervisor or caregiver administering chest compressions) that the chest compression performance is outside the prescribed guidelines, and the caregiver should adjust the rate and / or depth of compressions to keep PPI 684 fully illuminated.This feedback allows caregivers to immediately adjust their compression depth if they see compressions outside the target range. Therefore, providing real-time caregiver performance feedback via the chest compression dashboard 670 offers a technical solution to the clinical problem of ensuring the maintenance of predetermined standards of chest compression performance through real-time feedback provided at accessory devices 110, 111, 119, and 204.

[0174] In some examples, the chest compression dashboard 670 may also include a summary metric for CPR performance in medical events (see, for example, see...). Figure 6F The dashboards 651 and 653 may include at least one of average compression depth, average compression rate, average release rate, pre-shock pause, post-shock pause, and percentage of compressions within the target compression depth range. In some examples, CPR summary metrics may be displayed in real time within the dashboard 670 while CPR is in progress or after a CPR event has ended. In some implementations, CPR summary metrics may be presented numerically or graphically within the chest compression dashboard 670. The CPR summary can provide CPR rescuers with an unedited CPR report card to help the rescue team report later in the case.

[0175] In some implementations, the ventilation dashboard 672 can provide caregivers and supervisors with real-time feedback related to the performance of bag-mask (BVM) ventilation. In some examples, the ventilation feedback displayed at the ventilation dashboard 672 may include information obtained from airflow sensor inputs connected to the medical treatment device 202. In some examples, the displayed real-time ventilation feedback may include one or more of tidal volume 690, ventilation rate 692, and minute volume. Additionally, the ventilation dashboard 672 may include a ventilation quality indicator (VQI) 691, which provides a graphical countdown timer until the next ventilation and a graphical representation of the delivered ventilation volume. The graphical information provided by VQI 691 provides caregivers with visual feedback regarding how well the ventilation they are administering is. In one example, VQI 691 fills toward a target volume as breaths are delivered to the patient via ventilation. In some implementations, if a predetermined time limit has been exceeded, indicating that too much time has elapsed since the last breath, the VQI 691 may flash and / or change color (e.g., yellow and / or red) to indicate that another breath should be administered. In some embodiments, the VQI 691 may also display a digital countdown of the amount of time until the next ventilator. In other examples, the VQI 691 may include a contour countdown indicator that draws a contour around the VQI 691 at a rate corresponding to the ventilation rate, such that when the contour is complete, it prompts the caregiver to administer the next breath.

[0176] In some examples, the ventilation dashboard may also include one or more ventilation summary metrics, including at least one of mean tidal volume, mean ventilation rate, mean minute volume, and percentage of ventilation within the target volume or rate range. In some examples, the ventilation summary metrics may be displayed in real time within the dashboard 672 while ventilation is in progress or after a ventilation event has ended. In some implementations, the ventilation summary metrics may be presented digitally or graphically within the ventilation dashboard 672. The ventilation summary can provide ventilation rescuers with an unedited ventilation report card to help the rescue team report later in the case. In some examples, the ventilation summary metrics may be displayed in real time within the dashboard 672 while ventilation is in progress or after ventilation has been administered to the patient at the end of the procedure. Similar to the chest compression dashboard 670, the feedback provided at the ventilation dashboard 672 allows caregivers to immediately adjust their ventilation rate and / or technique if they see that the ventilation being administered is outside the target range. Therefore, providing real-time caregiver performance feedback via the ventilation instrument panel 672 provides a technical solution to the clinical problem of ensuring the maintenance of predetermined ventilation performance through real-time feedback provided by the accompanying devices 110, 111, 119, and 204.

[0177] Figure 6D Another implementation showing working views of the accessories 110, 111, 119, 204 is provided, in which the information displayed at each accessory is tailored to the role of a given caregiver. Figure 6D The example shown can be compared with the same Figures 1A to 1C The illustrated treatment events correspond to similar patient treatment events, wherein at least two auxiliary devices 110, 111, 119 are wirelessly connected to defibrillator 102 for use by chest compression caregiver 104 and ventilation caregiver 106, respectively. For example, when the patient is being treated by a rescue team, defibrillator 102 can be used at defibrillator display interface 696 (e.g., Figure 6E The defibrillator display interface 625 (shown) displays physiological information obtained from one or more connected physiological sensors. In some embodiments, the auxiliary devices 110, 111, 119, and 204 can each display a work view UI screen configured for the respective caregiver's treatment role (e.g., Figure 6C(See working view 668). For example, at the accessory device 110 used by chest compression caregiver 104, the chest compression dashboard 670 may be displayed more prominently than other data, waveforms, and dashboards in the working view UI screen 697. In one example, UI screen 697 may be a "compression view" UI screen that only displays the chest compression dashboard. Similarly, at the accessory device 111 used by ventilation caregiver 106, the ventilation dashboard 672 may be displayed more prominently than other data, waveforms, and dashboards in the working view UI screen 699. In one example, UI screen 699 may be a "ventilation view" UI screen that only displays the chest compression dashboard. In another example, the chest compression dashboard 670 and the ventilation dashboard 670 may be displayed separately in the "complete CPR" working view, allowing the supervisor to monitor both CPR and ventilation caregivers simultaneously, or allowing CPR and ventilation caregivers to share the same accessory devices 110, 111, 119, and 204 during a medical event.

[0178] The real-time display of customized work views within companion devices 110, 111, 119, and 204 provides a technical solution to the clinical and technical challenge of providing real-time, user-friendly treatment-related feedback and data to multiple caregivers during acute patient care events. Without the ability to transmit and display customized case information at companion devices based on caregiver roles during medical events, caregivers are forced to huddle around relatively small defibrillator interfaces, which can be limited in their ability to simultaneously display all data portions that any caregiver might wish to show at a given time. Therefore, the ability to transmit medical treatment and caregiver performance data for display at one or more caregiver companion devices allows caregivers to focus on the information displayed in their respective roles and work views, which can aid coordination among caregivers within the rescue team and enhance patient care during medical events.

[0179] Despite Figure 6DThe work view UI screen displayed at accessory devices 110, 111, though not shown, may include additional data sections accessible by scrolling to another location within the work view. In some examples, the work view UI screen displayed at accessory devices 110, 111 can be configured immediately upon user login and association of each user 104, 106 with a customized work view configuration including a highlighted chest compression dashboard 670 or ventilation dashboard 672. In other examples, caregivers 104, 106 can manually configure the work view UI screen at their respective accessory devices 110, 111 by selecting various dashboards, waveforms, trends, or data indicators that they wish to display at accessory devices 110, 111. In some examples, the display interface at accessory devices 110, 111 may include one or more drop-down / select menus that allow caregivers to select data sections for display within the work view. Caregivers 104, 106 can also manually position data sections within the work view by selecting and dragging them to preferred locations within the work view. In other implementations, when logging in at the companion device, caregivers 110 and 111 can select a caregiver role for a medical event (e.g., chest compression caregiver, ventilation caregiver, team leader), and the companion device can automatically configure the corresponding work view for the selected role.

[0180] Figure 6F Another example of device view 649 for companion devices 110, 111, 119, and 204 is shown. In addition to waveforms of ECG 620a, 620b, SpO2 622, and CO2 624, and discrete values ​​of HR 626, SpO2 628, EtCO2 630, and NIBP 634c, UI screen 649 may also include chest compression dashboard 651 and ventilation dashboard 653 providing aggregated metrics of caregiver performance (compression and ventilation caregivers). In one example, device view 649 may be another display interface of the medical treatment device or another device view of companion devices 110, 111, 119, and 204 (e.g., Figure 6A The visual representation of the device view 600 in the UI screen. As described above, in some examples, the display layout, the magnification of each data section, the selection of physiological waveforms, the selection of physiological digital readouts, the resolution, the waveform duration, the waveform size, the text size, the font, and / or the display color may differ from the content displayed at the medical treatment device. Additionally, the navigation and display bars may be displayed on the opposite side of the UI screen 649 as other display views of the supporting devices 110, 111, 119, 204, and / or the medical treatment device 202, while still being another display view (e.g., ...). Figure 6AThe visual representation of the device view 600 or the display screen of the medical treatment device 202. For example, the indicators for the shock energy value 619 and the number of shocks applied 621 can be displayed at the top edge of the UI screen 649 instead of at the bottom edge as in the device view 600. In addition, the alarm user input 667 can display the name of the most recent alarm, or can cycle through all alarm conditions triggered within a predetermined time period.

[0181] In some implementations, CPR summary dashboards 651, 653 may each present numerical summary indicators associated with compressions and / or ventilation (average compression rate 655, average compression depth 657, percentage of compressions within the target range 659, average respiratory rate 661, average tidal volume 663, target percentage of breathing 665), with one or more indicators highlighted in different colors based on their relative importance (e.g., target percentage of compressions 659 and / or target percentage of breathing 655 may be displayed in a larger font size and / or in a color that attracts the viewer's attention (e.g., yellow, orange, or red)). In some embodiments, the summary indicators 651 to 665 displayed within the respective dashboards 651, 653 may be displayed in a different font color than other indicators displayed within the same dashboards 651, 653 to further assist the viewer in distinguishing the displayed case information. In some implementations, summary dashboards 651, 653 can be selected and viewed at any display interface of the accompanying devices 110, 111, 119, 204 (e.g., device view 600). Figure 6A Trend View 636 Figure 6B ), Working View 668 ( Figure 6C ) and case type views 814, 820, 824, 834, 840 and 844 ( Figures 8B to 8G For example, when the corresponding user input is selected at the display interface, summary dashboards 651 and 653 can be displayed at the display interface.

[0182] In another embodiment, device view 649 may be such as working view 668. Figure 6CThe device view 649 provides a visual representation of one or more working views, as it includes caregiver performance dashboards 651, 653, which are similar to caregiver performance dashboards 670, 672 but provide caregiver performance case information in a different format (e.g., color, font, magnification, numerical vs. graphical representation, etc.) and in a manner that highlights different information within the dashboards 651, 653. In some examples, dashboards 651, 653 may be specifically configured for supervisor companion devices 119, 204 such that the case information displayed within dashboards 651, 653 draws the supervisor's eye to one or more corresponding data items, enabling a quick review of caregiver performance during chest compressions and ventilation during a medical event.

[0183] Return to Figure 4A In some implementations, when configuring the working view UI screen at accessory devices 110, 111, 119, 204, if one or more of physiological sensor data, treatment data, and caregiver performance data are required to be displayed within the working view (416), in some examples, accessory devices 110, 111, 119, 204 transmit a data acquisition request to medical treatment device 202 to request one or more of the requested data (418). For example, if the accessory device user selects the chest compression dashboard 670 for display within the working view at accessory devices 110, 111, 119, 204, and it has not been displayed until then, accessory devices 110, 111, 119, 204 may transmit a data acquisition request to medical treatment device 202 to obtain CPR case information (e.g., chest compression depth and rate data) for display within the chest compression dashboard 670. In some examples, upon receiving requested data, the supporting devices 110, 111, 119, and 204 configure the requested data for real-time display in various data sections within the working view interface (420). In some embodiments, depending on the type of requested data, the medical treatment device 202 may transmit the requested data as a streaming data message and / or a REST data message (bulk data transfer).

[0184] Continue to Figure 4B When the selection of case type selector 606 is detected in one of the display views of the supporting devices 110, 111, 119, and 204 (e.g., Figures 6A to 6CWhen the selector 606)(422) is selected, in some implementations, the supporting devices 110, 111, 119, 204 cause the display of the case type selection UI screen (424). When a case type is detected to be selected at the case type selection interface (426), in some implementations, the supporting devices 110, 111, 119, 204 configure data (428) for presentation at the selected case type UI screen. In some examples, each case type view is a working view specifically tailored for a particular type of medical event in the displayed data section, which is particularly relevant to that medical event.

[0185] For example, Figure 8A The accompanying devices 110, 111, 119, and 204 are shown displaying case type selection UI screens 800 in response to selection by case type selector 606. In some implementations, the case type selection UI screen 800 displays a summary of one or more types of medical events, allowing the accompanying device user to view which metrics, trends, waveforms, and dashboards are associated with the various selectable case types 802 to 812, each associated with... Figures 8B to 8G The case type UI screen shown corresponds to one of these. In some implementations, the selectable case types may include basic monitoring 802, advanced monitoring 804, cardiac arrest 806, TBI 808, respiratory distress 810, and critical care monitoring 812. In some examples, indicators, trends, waveforms, and dashboards are associated with each selectable case type 802 to 812, presenting data most relevant to the situation associated with each case type. The pre-configured case type UI screens, including those for display at accessory devices 110, 111, 119, and 204, provide a technical solution to clinical problems due to the improved efficiency achieved by allowing accessory devices 110, 111, 119, and 204 to display relevant case information in a user-friendly format without requiring caregivers to consider which data components (indicators, waveforms, trends, dashboards) are most relevant to a particular patient's case. In some embodiments, once the various case type views are displayed at the accessory devices 110, 111, 119, and 204, the device user can modify the layout of the data sections, add or remove one or more data sections as needed. Additionally, the accessory device user can switch between case type views 802 to 812 as needed.

[0186] Figure 8BA basic monitoring UI screen 814 is shown, configured to be displayed at accessory devices 110, 111, 119, and 204 in response to selecting the basic monitoring selector 802 at the case type selection UI screen 800. In some implementations, the basic monitoring UI screen 814 may be displayed by a caregiver when a patient is being transported from an accident scene to a hospital, in cases where the number of physiological sensors available for medical treatment device 202 is reduced or a patient diagnosis has not yet been made. In one example, the basic monitoring UI screen 814 may include discrete values ​​of ECG waveform 620a, SpO2 waveform 622, HR 626, SpO2 628, and NIBP 650, trend graphs of SpO2 640, NIBP 642, and HR 816, and a data table 652 for displaying physiological trends. Figure 8B (Not shown in the image). Additionally, once the Basic Monitoring Case Type Selector 802 is selected, caregivers can switch between Basic Monitoring UI screen 814 and other accompanying device displays via the Basic Monitoring tab 818. In some examples, the Basic Monitoring tab may include a user input 818 that allows the Basic Monitoring UI screen 814 to be turned off or disabled at accompanying devices 110, 111, 119, and 204. Figures 8B to 8G The case type views 814, 820, 824, 834, 840, and 844 can be deactivated by the user through corresponding user input. In some implementations, however, the device view UI screen 600... Figure 6A Trend View UI Screen 636 Figure 6B ) and working view UI screen 668 ( Figure 6C Once activated, it cannot be deactivated by the device user.

[0187] Figure 8C-1 and Figure 8C-2 An advanced monitoring UI screen 820 is shown, configured to be displayed at companion devices 110, 111, 119, and 204 in response to the selection of the advanced monitoring selector 804 at the case type selection UI screen 800. In some implementations, UI screen 820 is a scrollable interface including user input 817, which allows the device user to scroll up and down to view different portions of UI screen 820 when not all case information is visible in a single viewing pane. For example, Figure 8C-1The first portion of UI screen 820 is shown. In some implementations, caregivers may display advanced monitoring UI screen 820 when a patient is experiencing chest pain or another serious medical condition that does not fall into one of the other case type categories. In some examples, advanced monitoring UI screen 820 may include discrete values ​​of lead II ECG waveforms 620a, SpO2 waveforms 622, CO2 waveforms 624, HR 626, SpO2 628, EtCO2 630, NIBP values, trend graphs of SpO2 640, NIBP 642, EtCO2 826, HR 816, and respiratory rate, as well as ( ) for displaying physiological trends. Figure 8C-2 (See data table 652 shown). In some examples, the Advanced Monitoring UI screen 820 may be a scrollable interface, allowing users to view more content than is visible in a single viewing pane. For example, while scrolling, users can view the entire trend graph of EtCO2 826 and HR816, as well as a tabular description of the trends of HR, NIBP, SpO2, and EtCO2 recorded at predetermined time intervals. Additionally, once the Advanced Monitoring Case Type Selector 802 is selected, caregivers can switch between the Advanced Monitoring UI screen 814 and other accompanying device displays via the Advanced Monitoring tab 822.

[0188] Figure 8DA cardiac arrest UI screen 824 is shown, configured to be displayed at companion devices 110, 111, 119, and 204 in response to the selection of the cardiac arrest selector 806 at the case type selection UI screen 800. In some implementations, when a patient enters cardiac arrest, caregivers can quickly and efficiently switch to the cardiac arrest UI screen 824, which displays multiple waveforms, dashboards, metrics, and trends to enhance the caregiver's ability to care for the patient during cardiac arrest. In some implementations, the layout of the cardiac arrest UI screen 824 and all other case type UI screens can be pre-configured to provide information such that the information most relevant to providing patient care is immediately visible within UI screen 824 without having to scroll to another location. For example, the pad ECG waveform 620a and the filtered ECG waveform 832, along with the current digital HR value 626, can be positioned at the top of the cardiac arrest UI screen 824. In one example, the EtCO2 waveform may also be displayed. Upon switching to the cardiac arrest UI screen 824, the chest compression dashboard 670 and ventilation dashboard 672 are immediately visible, enabling caregivers to monitor chest compression and ventilation performance during a cardiac arrest event. In some implementations, the cardiac arrest UI screen 824 may also include CO2 waveforms, EtCO2 values, trend graphs of SpO2 and EtCO2, and a trend data table 652 displaying the time increments of the various trend graphs. Additionally, once the cardiac arrest case type selector 806 is selected, caregivers can switch between the cardiac arrest UI screen 824 and other accompanying device display views via the cardiac arrest tab 828.

[0189] Figure 8E A TBI UI screen 834 is shown, configured to be displayed at accessory devices 110, 111, 119, and 204 in response to the selection of the TBI selector 808 at the case type selection UI screen 800. In some implementations, the caregiver can display the TBI UI screen 834 when the patient experiences TBI through a traumatic event (such as the effects of a car accident, gunshot wound, etc.). In some implementations, the TBI UI screen 834 can display lead II ECG waveform 830, EtCO2 waveform, digital heart rate value 626, digital NIBP value, and TBI dashboard 838. In some examples, the TBI dashboard 838 may include a subset of dashboards and waveforms related to monitoring the TBI status, including a ventilation dashboard 672, and trend graphs for EtCO2 826, NIBP 642, SpO2 640, and systolic blood pressure (SBP). Additionally, the UI screen 834 may also include a data table 652, which displays the various trend graphs shown (in... Figure 8E(Not shown in the image) The associated time-incrementing value. In some implementations, the TBI dashboard 838 may include a dashboard expansion input 839 that expands the TBI dashboard 838 to encompass additional case information displayed on the TBI dashboard 838, thus magnifying the case information displayed on the TBI dashboard 838. In some cases, magnifying the TBI dashboard 838 makes it easier for the device user to view the case information displayed within the TBI dashboard 838. Additionally, if the expansion input 839 is selected when expanding the TBI dashboard 838, the dashboard 838 shrinks back to its original size. In some examples, the TBI UI screen 834 may be a scrollable interface that also displays graphs of SpO2 and CO2, current values ​​of SpO2 and EtCO2, and trend graphs of HR and RR. Additionally, once the TBI case type selector 808 is selected, the caregiver can switch between the TBI UI screen 834 and other accompanying device display views via the TBI tab 836.

[0190] Figure 8F A respiratory distress UI screen 840 is shown, configured to be displayed at accessory devices 110, 111, 119, and 204 in response to the selection of the respiratory distress selector 810 at the case type selection UI screen 800. In some implementations, the respiratory distress UI screen 840 can be displayed by a caregiver when a patient is ill and exhibits symptoms of a respiratory condition that causes respiratory distress, such as chronic obstructive pulmonary disease (COPD), asthma, congestive heart failure, cystic fibrosis, pneumonia, etc. The respiratory distress UI screen 840 displays waveforms of ECG 630 (e.g., ECG lead II), SpO2 622 and CO2 data, current values ​​of HR 626, SpO2 628 and EtCO2 630, BVM dashboard 672, and trend graphs of SpO2 640 and EtCO2 826. Additionally, the respiratory distress UI screen 840 can be a scrollable interface, allowing users to view the entire EtCO2 trend graph 826, as well as trend graphs for NIBP and HR, and tabular descriptions of the trends of HR, NIBP, SpO2, and EtCO2 recorded in a non-continuous manner at predetermined time intervals. Furthermore, once the respiratory distress case type selector 810 is selected, caregivers can switch between the respiratory distress UI screen 840 and other accompanying device display views via the TBI tab 842.

[0191] Figure 8GA critical care monitoring UI screen 844 is shown, configured to be displayed at accessory devices 110, 111, 119, and 204 in response to the selection of the critical care monitoring selector 812 at the case type selection UI screen 800. In some embodiments, caregivers may display the critical care monitoring UI screen 844 when transporting acutely ill patients between medical facilities or from an incident site to a medical facility (such as when transporting patients by transport helicopter). The critical care monitoring UI screen 844 may display: waveforms of ECG 630 (e.g., ECG lead II), SpO2 622, and CO2 data; current values ​​of HR 626, SpO2 628, EtCO2 630, temperature 632, and blood pressure 634a, 634b, and 634c (e.g., NIBP and IBP1 / 2 / 3); and a graphical trend panel with trend graphs of SpO2 640, NIBP 642, EtCO2 826, HR 816, and respiratory rate. In some implementations, the UI screen 844 may also include a data table 652 for monitoring parameters displayed in the graphical trends. Additionally, the respiratory distress UI screen 840 may be a scrollable interface that allows the user to view the overall SpO2 640 and NIBP 642 trend graphs, and also displays trend graphs for EtCO2 and HR, a table describing the trends of HR, NIBP, SpO2, and EtCO2 recorded at predetermined time intervals, and a ventilation dashboard. The intensive care monitoring UI screen 844 may also display case information for IBP readings. Furthermore, once the intensive care monitoring case type selector 812 is selected, caregivers can switch between the intensive care monitoring UI screen 844 and other accompanying device display views via the intensive care monitoring tab 846.

[0192] Return to Figure 4B In some implementations, when a case-type view UI screen is configured at the accessory devices 110, 111, 119, 204, if one or more of physiological sensor data, treatment data, and caregiver performance data are required to be displayed within the case-type view (430), in some implementations, the accessory devices 110, 111, 119, 204 transmit a data acquisition request 418 to the medical treatment device 202, thereby requesting one or more of the requested data items (432). For example, if the accessory device user selects to view the respiratory distress UI screen 840 ( Figure 8FIf the ventilation dashboard 672 has not been displayed up to this point, the auxiliary devices 110, 111, 119, and 204 may transmit a data acquisition request to the medical treatment device 202 to obtain ventilation case information (e.g., tidal volume and ventilation rate) for display within the respiratory distress UI screen 840. In some examples, upon receiving the requested data, the auxiliary devices 110, 111, 119, and 204 configure the requested data for real-time display in various data sections within the case type interface (434).

[0193] In some embodiments, if the accessory device detects an input selection (436) of a data input, recording, or viewing selector, then in some examples, input management processing associated with each detected input is performed. Figures 5A to 5F (438). In some implementations, a data input, recording, or viewing selector may be included in any display view of the accompanying device (e.g., Figures 6A to 6E , Figures 8B to 8G The selectors displayed at the location include case event selector 610, patient type selector 609, alarm selector 608, case type selector 606, patient information input selector 612, treatment mark input selector 614, and snapshot record selector 616.

[0194] Although described as a specific series of steps, other embodiments may include more or fewer steps. For example, if no working view is selected for display, the steps involving configuring and displaying the working view (410 to 414) may be omitted. On the other hand, if multiple case type views are selected for display, one or more additional steps related to configuring and displaying the selected case type view are performed. In other embodiments, some steps may be performed in a different order, or two or more steps may be performed in parallel. For example, if the case type selector 606 is selected before the working view is activated, the user may be authenticated at the companion device, and then the steps involving configuring and displaying the case type views (422 to 434) may be performed before the steps for configuring and displaying the working view (410 to 414). In some examples, the portion of method 400 performed depends on the selection made by the user of companion devices 110, 111, 119, 204. Other modifications to method 400 are possible while remaining within the scope and purpose of method 400.

[0195] Go to Figures 5A to 5F This illustrates example methods for managing inputs provided at an accessory device and instructing corresponding actions at an associated medical treatment device. In some examples, Figures 5A to 5FThe various methods described herein are associated with various user inputs (such as case event selector 610, alarm selector 608, case type selector 606, patient information input selector 612, treatment mark input selector 614, and snapshot record selector 616, etc.) on one of the display screens of the supporting device. In addition to Figures 5A to 5H In addition to the input selections described herein, other user inputs may be provided at the display views of the supporting devices 110, 111, 119, and 204. For example, at the patient type selector 609, the user can select whether the patient is an adult, a pediatric patient, or a neonatal patient, which can be transmitted to the medical treatment device 202. In some examples, the patient type 609 may affect the alarm setpoint, waveform scale, defibrillation energy, and / or the type of monitoring case information. In one or more examples, input of data affecting the operation of the medical treatment device at the supporting devices may be advantageous during medical events, as well as for alternative user interfaces that allow the user interface provided at the medical treatment device, and / or for preventing interference with the case information displayed at the medical treatment device.

[0196] For example, Figure 5A A method 500 for providing patient input information at an accessory device is illustrated. In some implementations, in response to selection of a patient input selector 612, accessory devices 110, 111, 119, 204 display a patient information input UI screen (512) that allows the accessory device user to input patient background and demographic information in one or more input fields. For example, Figure 7AA patient information input UI screen 700 is shown, in which a user of the companion device can input patient information associated with various medical events. In one example, the input fields may include one or more patient name input fields 708a, 708b, 708c, patient gender input field 706, patient age input field 704, and patient identification code input field 710. Other patient information input fields may include a patient height input field or a patient weight input field. In some embodiments, the patient information input fields may also include a medical record identification input field. In some examples, the user of the companion device can manually type patient information in the various input fields at the patient information UI screen 700. In other examples, the companion device may be configured to scan images of government-issued documents or identification cards via a camera or image capture device installed at the companion device, extract relevant patient information from the scanned documents, and automatically populate the input fields of the patient information UI screen 700 with the extracted information. Additionally, in some implementations, when the supporting devices 110, 111, 119, and 204 display the patient information input UI screen 700, they can transmit a request to the medical treatment device 202 for any patient information 246 already stored in the database. This patient information can then be automatically filled in at the UI screen 700. In some implementations, the device user can edit any information provided in the automatically filled input fields.

[0197] In some examples, when it is detected that one or more input fields of patient information have been submitted at the patient information input UI screen (e.g., the "Save" button 716 is selected) (514), the supporting device transmits an instruction signal with the submitted patient information to the medical treatment device 202, and instructs the medical treatment device 202 to link the submitted patient information 246 with the respective case information 242 and store it in the data storage 208 (516). In some aspects, once the patient information is saved, the medical treatment device 202 sends a confirmation signal to the supporting device indicating that the information has been saved. In response to receiving the confirmation signal (518), in some implementations, the supporting devices 110, 111, 119, 204 cause a confirmation message (520) to be displayed at the display interface, which confirms that the submitted patient information has been linked to the respective case information 242 and updated at the medical treatment device 202. For example, Figure 7A The confirmation message 702 shown is an example of a patient information update confirmation message. In other examples, a separate confirmation message may be displayed if the patient information has been transmitted to the medical treatment device 202 and stored at the medical treatment device 202.

[0198] In another example, the medical treatment device is a ventilator (e.g., Figures 1B to 1C 130 ventilators in the middle and Figure 10In the case of a ventilator (e.g., 1000), in some examples, the patient's height, sex, and / or weight can be used to determine the ventilation volume and ventilation rate administered to the patient. For example, Figure 13B Another example of a patient information input UI screen 1300 is shown, in which an accessory device user can input patient information associated with a medical event that is being addressed by ventilators 130 and 1000. Similar to patient information input UI screen 700, UI screen 1300 may include input fields for patient name 1308a, 1308b, 1308c, gender 1306, age 1304, and identification code 1310. Additionally, UI screen 1300 may also include a patient height input field 1318. In some examples, when one or more input fields of patient information are detected submitted at the patient information input UI screen (e.g., when the "Save" button 1316 is selected), accessory devices 110, 111, 119, and 204 communicating with ventilators 130 and 1000 transmit the submitted patient information, including patient gender and height information. In response to receiving patient gender and height information, ventilators 130 and 1000 automatically adjust the ventilator settings to correspond to the ideal weight of each submitted patient gender and height information, including tidal volume and / or ventilation rate.

[0199] In some examples, supervisors or other caregivers who do not actively provide direct patient care may have greater flexibility in handling administrative tasks such as entering patient information, viewing information from medical intervention devices (e.g., defibrillators, patient monitors, ventilators) that can or cannot be immediately streamed on the device's screen, and / or recording other aspects of medical events. Additionally, entering patient information at the input interface of medical intervention device 202 can be cumbersome and lengthy. Therefore, providing a patient information input interface at an accessory device frees caregivers to better focus on their assigned tasks without being bogged down in lengthy attempts to enter patient information at the medical intervention device's input interface.

[0200] Go to Figure 5B This illustrates a method 502 for inputting disposal marker information at an accessory device. In some implementations, in response to the selection of the disposal marker selector 614, accessory devices 110, 111, 119, and 204 display a disposal marker input UI screen (522) that allows the accessory device user to input disposal marker information at the accessory device. For example, Figure 7BA treatment marker input UI screen 712 is shown, where the companion device user can input treatment marker information associated with various medical events. In some examples, the medical treatment device 202 can automatically record treatment markers that the device 202 can automatically detect, such as detecting shockable ECG rhythms, administering defibrillation shocks to the patient, initiating chest compressions and / or ventilation, etc. However, other treatment actions that the medical treatment device 202 cannot detect may affect the patient response indicated in the waveforms, indicator values, and trends displayed at the medical treatment device 202 and in the display views at companion devices 110, 111, 119, and 204. For example, as shown in trend view UI screen 636 ( Figure 6B As shown, visual indications for treatment markers 656, 658, 660, and 662 are overlaid on trend graphs 638, 640, and 642 to provide additional context related to the patient's response to the treatment associated with each marker. Therefore, providing treatment markers indicating when certain medications or treatments were administered can provide context for caregivers to monitor patient responses during a medical event and can also enhance post-event reporting and analysis. In one example, when a treatment is administered to a patient, a caregiver can open the treatment marker input UI screen 712 to indicate what type of treatment (medication, oxygen, anticoagulant) was administered. In some examples, caregivers can also provide magnified information such as administration time, dosage, type of intravenous (IV) fluid, etc. As shown in the treatment marker input UI screen 712, treatment markers can include multiple preset treatment markers 720 for administering aspirin, oxygen, IV fluid, morphine, diazepam, beta-blockers, lidocaine (LIDO), magnesium sulfate, anticoagulants (thromboembolic), heparin, or restoration of spontaneous circulation (ROSC).

[0201] In some examples, the treatment marker input UI screen 712 may also include one or more customizable treatment markers 722, which enable companion device users to add additional treatment markers to further enhance the caregiver's ability to add meaningful annotations to the case information displayed at the medical treatment device 202 and companion devices 110, 111, 119, 204. Furthermore, enabling caregivers to input treatment marker information at companion devices 110, 111, 119, 204 frees other caregivers providing direct patient care (e.g., CPR, ventilation, or defibrillation) to focus on their respective tasks without having to stop inputting treatment marker information. In some examples, the treatment marker UI screen 712 may also include a selector for enabling audio input of treatment marker selection information detected by an audio sensor (e.g., a microphone), escaped, and converted into one or more selections at the UI screen 712. In some examples, the device user can also add amplified information to annotate the treatment label data by providing audio-visual annotations detected by an audio sensor and converted into text annotations by the companion devices 110, 111, 119, 204. In other examples, the treatment label UI screen 712 may include a selector to enable scanning of an identification code (e.g., a barcode) associated with the treatment label being converted into a treatment label selection. In one example, the device user can scan the barcode of a medication being administered to a patient, and the companion devices 110, 111, 119, 204 can convert the scanned identification code into medication type and / or dosage.

[0202] In some examples, when a treatment mark information is detected submitted at the treatment mark input UI screen (e.g., one or more treatment marks 720, 722 are selected) (524), the supporting devices 110, 111, 119, and 204 transmit an instruction signal containing the submitted treatment mark information to the medical treatment device 202, and instruct the medical treatment device 202 to link the submitted treatment mark data 252 with the respective case information 242 and store it in the data storage 208 (526). In some aspects, once the treatment mark data 252 is saved, the medical treatment device 202 sends a confirmation signal indicating that the data has been saved to the supporting devices 110, 111, 119, and 204. In response to receiving an acknowledgment signal (528), in some implementations, the supporting devices 110, 111, 119, and 204 cause an acknowledgment message (530) to be displayed at the display interface, acknowledging that the submitted treatment marker data 252 has been linked to the respective case information 242 and updated at the medical treatment device 202. In some examples, the medical treatment device may send an acknowledgment signal to the supporting device when the linking and saving of the treatment marker data 252 has begun and ended. In such examples, a separate acknowledgment message may be displayed to confirm that the recording (linking and saving) of the submitted treatment marker is in progress and that the recording / saving of the submitted treatment marker has been completed. For example, Figure 7B The accompanying devices 110, 111, 119, and 204 are shown displaying a treatment tag recording confirmation message 714 in response to receiving a confirmation signal from the medical treatment device 202 indicating that the linking / storage of the submitted morphine treatment tag has begun. This recording confirmation message 714 may help to reassure caregivers (in stressful situations) that treatment tags are indeed being recorded. Similarly, a treatment tag recording completion message 718 may be displayed upon receiving confirmation from the medical treatment device 202 that the linking and storage of the morphine treatment tag has been completed.

[0203] Go to Figure 5CThe diagram illustrates a method 504 for initiating a snapshot at a medical treatment device via an accessory device. In some implementations, when a snapshot recording selector 616 is received at one of the display views of the accessory device, the accessory devices 110, 111, 119, and 204 may generate a snapshot instruction signal and transmit it to the medical treatment device (defibrillator) (532). In some embodiments, in response to receiving the snapshot instruction signal and initiating snapshot capture of the display, the medical treatment device 202 transmits an acknowledgment message to the accessory device that snapshot capture has commenced. In some implementations, the snapshot may include data of one or more waveforms (such as ECG waveforms) of medical data being monitored by the medical treatment device over a predetermined time period. In some implementations, the snapshot data may include medical waveform data over a predetermined time period before and after the snapshot is initiated. In one example, waveform data is captured between 5 seconds and 15 seconds. In one example, snapshot data may be captured for multiple waveforms of physiological data other than ECG data (e.g., SpO2, CO2, NIBP, IBP1 / 2 / 3, etc.). In response to receiving the confirmation message (534), in some implementations, the accompanying device displays a snapshot in progress notification message. Figure 7C-1 The snapshot recording message 724 (536) indicates that the recording (capture and storage) of a snapshot at the medical treatment device has begun. This snapshot recording message 724 may be beneficial for caregivers to know that a snapshot is indeed being recorded. In some implementations, once a snapshot is captured, the medical treatment device may transmit a snapshot completion acknowledgment signal to the accompanying devices 110, 111, 119, 204 indicating that the recording of the snapshot is complete. In response to receiving the snapshot completion acknowledgment signal (538), in some examples, the accompanying device displays a snapshot completion notification message (…). Figure 7C-1 The snapshot completion message 726 in the middle indicates to the device user that the snapshot recording has been completed (540).

[0204] Go to Figure 5D This illustrates a method 506 for initiating a 12-lead ECG analysis at a medical treatment device via an accessory device. In some implementations, when a selection of the 12-lead ECG analysis selector 617 is received at one of the display views of the accessory device, the accessory devices 110, 111, 119, and 204 can generate a 12-lead analysis signal and transmit it to the medical treatment device (defibrillator) (542). In some embodiments, in response to receiving a 12-lead analysis instruction signal and starting a 12-lead ECG analysis, the medical treatment device 202 transmits an acknowledgment message to the accessory device that the 12-lead analysis has started. In response to receiving the acknowledgment message (544), in some implementations, the accessory device displays a 12-lead analysis in progress notification message (…). Figure 7C-2The 12-lead analysis message 728)(546) indicates that a 12-lead ECG analysis has begun at the medical treatment device 202. This 12-lead analysis message 728, along with the recording message 724, may be beneficial for caregivers to know that a 12-lead analysis is in progress. In some implementations, once the 12-lead analysis is complete, the medical treatment device 202 may transmit a 12-lead analysis completion confirmation signal along with the 12-lead data 250 of the completed 12-lead analysis to the supporting devices 110, 111, 119, and 204. In response to receiving the snapshot completion confirmation signal (548), in some examples, the supporting devices 110, 111, 119, and 204 display a 12-lead analysis completion notification message. Figure 7C-2 The 12-lead analysis completion message 730 indicates to the accessory device user that the 12-lead ECG analysis has been completed (550). In some examples, the accessory devices 110, 111, 119, and 204 also display the received 12-lead data for analysis in the display view of the accessory devices 110, 111, 119, and 204 (552).

[0205] For example, Figure 7D The 12-lead analysis UI screen 732 displays the 12-lead analysis data shown at the auxiliary devices 110, 111, 119, and 204. In some implementations, the 12-lead analysis UI screen 732 can only be displayed when the current display device view UI screen 600 is active. In other examples, the 12-lead analysis UI screen 732 can be displayed within any working view UI screen. To close the 12-lead analysis UI screen 732, in some embodiments, the user can select any location on the UI screen 732. In some examples, the auxiliary devices 110, 111, 119, and 204 can request the display of previously performed 12-lead analyses at the 12-lead analysis UI screen 732 because the case information 242 is stored in the data store 208 of the medical treatment device 202, and the auxiliary devices 110, 111, 119, and 204 can request individual 12-lead data 250 from the medical treatment device 202 for the selected previously performed 12-lead analysis. In response, the medical treatment device 202 can transmit the requested 12-lead data 250 as a batch transmission message to the supporting devices 110, 111, 119, and 204 for display.

[0206] Go to Figure 5EThe diagram illustrates a method 508 for generating a medical treatment device alarm summary at an accessory device. In some implementations, when an alarm selector 608 is received at one of the display views of the accessory device, the accessory devices 110, 111, 119, and 204 may generate an alarm summary command signal and transmit it to the medical treatment device (defibrillator) (554). In some examples, upon receiving the command signal, the medical treatment device 202 transmits requested alarm data 256 for a medical event stored in a data store 208. In response to receiving the requested alarm data (556), in some implementations, the accessory device displays the alarm data within an alarm summary UI screen (558).

[0207] For example, Figure 7E Example alarm summary UI screen 734 shows a list of alarms occurring at medical treatment device 202 during a medical event. In some examples, the alarm conditions presented in UI screen 734 may include physiological alarm events and technical alarm events. For example, a physiological alarm event such as HR upper limit alarm 736 may occur when a physiological sensor input detects a value falling outside the sensor's threshold limit. Based on the magnitude of the detected sensor value relative to a predetermined threshold range, alarm events may also be classified as life-threatening or non-life-threatening alarms. Technical alarms may indicate when a sensor may malfunction or cease service, or when other technical problems have occurred at the medical treatment device. For example, an EtCO2 calibration recommendation alarm 738 may be generated when the mainstream CO2 sensor on the airway adapter detects an unstable value or otherwise indicates that the sensor should be calibrated. Additionally, a printer paper out alarm 740 may be generated when no paper is available or the available paper is less than a predetermined amount at medical treatment device 202. In some embodiments, the various alarm events 736, 738, and 740 at the UI screen 734 are optional for presenting details related to each alarm condition (e.g., alarm time, patient condition at the time of the alarm). In some examples, when a new alarm condition is detected at the medical treatment device 202, data associated with that alarm condition may be automatically transmitted to the companion devices 110, 111, 119, and 204, causing the alarm selector 608 to flash or otherwise indicate to the companion device user that a new alarm condition has occurred.

[0208] Figure 13A An exemplary alarm summary UI screen 1320 is shown at accessory devices 110, 111, 119, and 204 during a medical event. In some implementations, the alarm summary UI screen 1320 displays alarm conditions associated with alarm conditions at ventilators 130 and 1000, while Figure 7E The alarm summary UI screen 734 shown is with the defibrillator 108 (see also...). Figures 1A to 1C This is related to the alarm status at ( ). In some examples, the alarm summary UI screen 1320 is generated by the supporting devices 119 and 204 in response to the alarm status at ( ). Figure 11A and Figure 11C The user interface screens 1101 and 1102 of the accompanying device are displayed after selecting alarm user input 1105.

[0209] In some examples, the alarm summary UI 1320 can categorize and / or sort alarm conditions based on time 1350, alarm name 1352, alarm type 1354, and / or alarm priority 1356. For example, alarm type 1354 can indicate whether the detected alarm condition is associated with patient safety, usage environment, or self-test alarms. In some implementations, alarm type 1534 can include patient safety alarms such as high / low airway pressure, high / low tidal volume, high / low respiratory rate / apnea, PEEP leak, insufficient flow, spontaneous breathing - high / low PIP, spontaneous breathing - high / low VT, unmet patient inspiratory needs, automatic PEEP, patient disconnection, expiratory system failure / malfunction, calibration error, suspected triggering, tubing compliance failure, SpO2 sensor off / low / error, high / low heart rate, etc. Usage environment alarms can include alarms for low battery, power failure, climate environment failure, oxygen supply failure, intake failure, etc. Self-test alarms may include internal communication errors, pneumatic system failures, power system failures, pulse oximetry module failures, preventative maintenance alarms, etc. Alarm priorities 1356 can be categorized as "high," "medium," and "low" or other rating schemes (e.g., severity expressed as numbers or letters) based on the severity of associated alarms. In some examples, all patient safety alarms are categorized as high-priority alarms. In one example, each alarm, along with its corresponding alarm information (e.g., type, priority), is stored in the data store 256 of each medical treatment device. When an alarm condition occurs at any of the medical treatment devices 130, 202, 1000, the alarm and corresponding information are transmitted to auxiliary devices 110, 111, 119, 204 for real-time display on the alarm summary UI screen 1320. In some examples, in response to the detection of one of the displayed alarm conditions, auxiliary devices 119, 204 can be configured to display amplified information associated with the alarm, including instructions for resolving the respective alarm condition. In some embodiments, the supporting devices 110, 111, 119, and 204 can also be configured to display alarm conditions as event markers (also referred to as alarm markers) at the display interface (e.g., Figure 11E The event marker 1132 at 1150 in the trend view user interface is used for display.

[0210] In multiple medical treatment devices (e.g., Figure 1CIn some implementations where the defibrillator 108 and ventilator 130 are simultaneously connected to and communicate with the auxiliary devices 110, 111, 119, and 204, features of the alarm summary UI screens 734 and 1320 can be combined into a single user interface screen, enabling the supervisor 118 to simultaneously monitor the alarm status at two or more medical treatment devices 108, 130, and 202. For example, when in Figure 11B and Figure 11D The multi-device working views 1100, 1194 and shown Figure 11E When the alarm user input 1107 is selected at the multi-device trend view 1150, the supporting devices 110, 111, 119, and 204 can enable the display of an alarm summary UI screen that includes alarm status from all connected medical treatment devices 108, 130, and 202.

[0211] Go to Figure 5F The diagram illustrates a method 510 for generating a medical event summary at an accessory device. In some implementations, when a selection is received at one of the display views of the accessory device from the case event selector 610, the accessory devices 110, 111, 119, and 204 may generate an event summary command signal and transmit it to a medical treatment device (defibrillator) (560). In some examples, upon receiving the command signal, the medical treatment device 202 transmits the case information 242 requested for the event summary stored in the data store 208. In response to receiving the medical event data requested for the event summary (562), in some implementations, the accessory device displays the event summary data within the event summary UI screen (564). For example, Figure 7F An example event summary UI screen 742 is shown, which presents one or more timestamped events that occur during patient treatment. In some examples, the displayed events may include automatically generated treatment markers (patient shock 758, 760), CPR initiation 754, manually entered treatment markers (morphine administration 750, 762, diazepam administration 752), alarm status 758, snapshot acquisition 748, 12-lead ECG analysis, or patient / case entry information 746. In some examples, the listed events may be color-coded based on event type. The event summary UI screen 742 may also include an event filter selector 764, which allows the device to filter the events presented in the UI screen 742 to only the types of events that the device user wants to see. For example, an event filtering UI screen 744 may be presented in response to a selection by the event filter selector 764, presenting the types of events that can be presented within the event summary UI screen 742.

[0212] In some implementations, when a selection of one or more filtered event types is detected at the event filtering UI screen 744 (566), the accompanying device can adjust the events presented in the event summary UI screen 742 to include only the events of the filtered types (568). For example, the screening type may include defibrillation 766, pacemaker event 768 (when the patient has a pacemaker implanted), alarm 770, life-threatening alarm (e.g., life-threatening ECG rhythm) 772, treatment flag 774, presenting rhythm 776, checking the patient (e.g., when a shockable rhythm is detected in a continuous background ECG analysis and the caregiver should check the patient immediately) 778, analysis results (e.g., results from the "analysis" input selected by the caregiver to determine whether the rhythm is shockable or not) 780, monitoring (corresponding to a "monitoring" snapshot manually initiated at the operator's request (e.g., in response to an observed event of concern) 782), and 12-lead ECG results (including 12-lead snapshot results of all ECG leads at a high sampling rate, and 12-lead analysis results included in the record) 784. Additionally, the individual events displayed at the event summary UI screen 742 are selectable, such that when selected (570), in some implementations, additional details (572) associated with the event are displayed. In some examples, the additional details shown may include drug dosage, the amount of time associated with chest compressions or ventilation, or other information, and / or an ECT snapshot at the time the event occurred.

[0213] Go to Figure 5G This illustrates a method 574 for adjusting settings of a medical treatment device via an accessory device. In some implementations, method 574 may be performed by accessory devices 110, 111, 119, 204 communicating with ventilators 130, 1000, which include one or more adjustable parameters and / or mode settings for providing positive pressure ventilation to a patient. These parameters and / or mode settings may be modified at accessory devices 110, 111, 119, 204. For example, an accessory device user interface screen (e.g., Figure 11A The user interface screen 1101 in the middle may include a user interface screen 1362 that displays ventilator settings adjustment. Figure 13C The ventilator settings user input is 1129. In other examples, the companion device user interface (e.g., Figure 11B The user interface screen 1100 can activate any displayed ventilator setting (e.g., FIO2, PEEP, V) in response to detecting a selection in any of the ventilator setting sections of the user interface 1100. tThe interface allows for the adjustment of settings such as I:E ratio, ventilator mode, PIP threshold, SpO2, and BPM. For example, selecting the BPM section 1112 on the user interface screen 1100 allows the accompanying devices 110, 111, 119, and 204 to display the BPM adjustment interface 1360. Figure 13D-1 This was done in preparation for changing the BPM applied to patients.

[0214] In some implementations, method 574 begins with the following operation: Supporting devices 110, 111, 119, and 204, in response to detecting a selection by the ventilator settings user input 1129, display a settings input screen (576). In some examples, the settings input screen is the settings adjustment user interface screen 1362. Figure 13C In one example, the settings adjustment user interface screen 1362 may include user input corresponding to various adjustable ventilator settings. For example, adjustable ventilator settings may include fractional oxygen concentration (FIO2) setting 1378, positive end-expiratory pressure (PEEP) setting 1366, and tidal volume (V... t The settings are as follows: 1368, Inspiratory:Expiratory Ratio (I:E) setting 1372, Ventilator Mode setting 1380, Peak Inspiratory Pressure (PIP) Threshold setting 1374, Breathing Rate per Minute (BPM) setting 1370, or SpO2 setting 1376. In some examples, if setting input (578) is selected, the accessories 110, 111, 119, and 204 can display the various setting adjustment interfaces (580). For example, if BPM setting user input 1370 is selected, the accessories 110, 111, 119, and 204 can display the BPM adjustment interface 1322. Figure 13D-1 In some implementations, the BPM setting adjustment user interface 1322 may include an input field 1326 that allows a user to increase or decrease the number of breaths per minute delivered to the patient via ventilators 130 and 1000. In one example, input field 1326 includes increase / decrease inputs 1328a and 1328b that allow the companion device user to raise or lower the BPM setting. In other examples, input field 1326 may be a free text field that allows the user to enter an adjusted BPM value at an interface keyboard. In some implementations, companion devices 110, 111, 119, and 204 may be configured to alert the user if the adjusted setting value is outside one or more predetermined setting ranges. In some embodiments, for PEEP 1366, V tThe setting adjustment interfaces for 1368, I:E 1372, PIP threshold 1374, SpO2 1376, and FIO2 1378 can have essentially the same input fields and format as the BPM setting adjustment interface 1322. In some examples, if ventilator mode setting 1380 is selected, the accompanying devices 110, 111, 119, and 204 cause the ventilator mode adjustment interface 1332 to be displayed. Figure 13D-2 In some embodiments, the ventilator mode adjustment interface 1332 may include individual mode inputs corresponding to various available operating modes of the ventilators 130 and 1000 (e.g., assist / control (AC) mode 1336, synchronized intermittent forced ventilation (SIMV) mode 1340, continuous positive airway pressure (CPAP) mode 1338, or bilevel (BL) mode 1342). To adjust ventilator settings, the device user selects user inputs 1336, 1338, 1340, and 1342 corresponding to the desired ventilator operating mode.

[0215] If you submitted settings adjustments at various settings adjustment user interfaces (for example, you selected...) Figure 13D-1 The user input 1324 or Figure 13D-2 In some embodiments, if user input 1334)(582) is received, the supporting devices 110, 111, 119, 204 transmit the respective setting adjustments to the medical treatment device 202 (584). In some aspects, once the setting adjustment data is received and applied at the ventilators 130, 1000, the ventilators 130, 1000 send an acknowledgment signal to the supporting devices 110, 111, 119, 204 indicating that the respective ventilator settings have been adjusted. In response to receiving the acknowledgment signal (586), in some implementations, the supporting devices 110, 111, 119, 204 cause an acknowledgment message (588) to be displayed at the display interface, which confirms that the submitted ventilator setting adjustments have been received and updated at the ventilators 130, 1000. In some examples, the ventilators 130, 1000 may send the acknowledgment signal to the supporting devices 110, 111, 119, 204 upon receiving and applying both the respective setting adjustments. In such an example, a separate confirmation message can be displayed to acknowledge receipt of the submitted setting adjustment and its application at ventilators 130 and 1000. In some implementations, instead of displaying a confirmation message, or in addition to displaying a confirmation message, the supporting devices 110, 111, 119, and 204 can also be configured to apply event markers to one or more of the displayed user interface screens to indicate that various settings have been changed at ventilators 130 and 1000 (589). For example, as... Figure 11EAs shown, the trend view user interface screen 1150 includes event flags 1130 corresponding to changes in BPM settings. In some examples, event flags 1130 can be automatically applied to the user interface screen 1150 without any user intervention, in addition to submitting setting changes. Furthermore, regardless of whether the setting change is entered at ventilator 130, 1000 or at accessory devices 110, 111, 119, 204, event flags 1130 can be automatically applied to the display interfaces of accessory devices 110, 111, 119, 204. In some implementations, the disposal flags described herein are event flags, and are interchangeably referred to as event flags throughout the invention.

[0216] Although described as a specific series of steps, in other embodiments, more or fewer steps may be included than methods 500, 502, 504, 506, 508, 510, and 574. For example, for method 512 for generating an event summary at the companion device, the steps (566, 568) associated with filtering the content displayed within the event summary UI screen 742 may be omitted. For method 502 for inputting disposal marker information at the companion device ( Figure 5B The accompanying device can display a notification when a treatment tag has been received at the medical treatment device and when the linking and storage of the treatment tag data has been completed. In another embodiment, certain steps may be performed in a different order, or two or more steps may be performed in parallel. Other modifications to methods 500 to 510 are possible while remaining within the scope and purpose of methods 500 to 510.

[0217] In some implementations, the companion devices 110, 111, 119, and 204 may provide additional features to enhance patient care during medical events. In some examples, when the patient has an in-plant pacemaker, the medical treatment device 202 can detect pacing data, which can be transmitted to and displayed on the companion devices 110, 111, 119, and 204. In some examples, the companion devices 110, 111, 119, and 204 may automatically display instruction bubbles at the device interface to instruct caregivers on how best to use the companion devices 110, 111, 119, and 204 to monitor and care for the patient. In some examples, the companion devices 110, 111, 119, and 204 may generate and display instruction bubbles during one or more initial uses of the device 204 by a caregiver. In some embodiments, the supporting devices 110, 111, 119, and 204 may also provide and monitor the completion of medical care lists, monitor QA / agreement compliance, and / or export case information to electronic health records (HERs) or other registries.

[0218] Go to Figure 10 An exemplary ventilator 1000 is shown. In some embodiments, a medical treatment device 202 ( Figure 2 The device can be a ventilator configured to provide positive pressure ventilation to a patient via an oxygen inlet (oxygen) through a suitable mechanism (such as an intubation tube, mask, nasal cannula, etc.). As described above, in some implementations, the aiding devices 110, 111, 119, 204 can be pre-configured to pair with or otherwise connect to the ventilator 1000 to exchange medical data according to the methods described herein. Embodiments of the ventilator of the present invention may have a connection with the Z-type ventilator provided by ZOLL Medical Corporation. The Ventilator has similar functionality but can employ other ventilators. In some examples, Ventilator 1000 is a portable ventilator that can be used in hospital and / or pre-hospital settings (such as airmedic and ground transport), mass casualty situations, and extreme environments. In one example, the portable ventilator 1000 weighs less than 12 pounds, less than 10 pounds, or less than 5 pounds to provide easy transport at the emergency site. Ventilator data generated by Ventilator 1000 that can be transmitted to accessory devices 110, 111, 119, 204 for visual reproduction on accessory devices 110, 111, 119, 204 may include, for example, ventilator settings, ventilation parameters, and / or physiological parameters collected by the ventilator. For example, ventilator settings that can be provided to accessory devices 110, 111, 119, and 204 for visual reproduction may include respiratory rate (breaths per minute (BPM)) 1012, inspiratory:expiratory ratio (I:E, the ratio of inspiratory time to expiratory time) 1013, and tidal volume (the amount of air delivered per breath) (V t1010, Positive end-expiratory pressure (PEEP, the intrapulmonary pressure above atmospheric pressure present at the end of expiration) 1009, Peak inspiratory pressure (PIP) limit 1008, Fractional inspired oxygen (FiO2) 1006, Mode settings (e.g., assist / control (A / C), synchronized intermittent forced ventilation (SIMV), continuous positive airway pressure (CPAP), bilevel (BL) 1014, etc. In some examples, the individual ventilator settings 1002, 1004, 1006, 1008 / 1009, 1010, and 1012 / 1013 may have on the ventilator 1000 for adjusting the individual settings 1002, 1004, 1009, 1010, 1012, 1013. The corresponding user inputs for 006, 1008 / 1009, 1010, and 1012 / 1013 are 1022a to 1022g. Ventilator parameters may include, for example, inspiratory pressure data, expiratory pressure data, inspiratory flow rate data, expiratory flow rate data, leak detection, or other information measured from the ventilator. Examples of physiological parameters that can be provided to the accessory device for visual reproduction may include discontinuous pulse oximetry (SpO2) measurements 1004, end-tidal CO2 (EtCO2) measurements, continuous SpO2 waveform data 1016, airway pressure waveform data 1018, continuous CO2 waveform data, heart rate 1002, blood pressure, etc.

[0219] In some examples, the ventilator 1000 can be configured to generate alarm signals (e.g., visual and / or auditory indications) when one or more parameter setpoints are exceeded. In one example, an alarm can be generated when the airway pressure exceeds the high airway pressure limit of 1020. In some implementations, alarms generated by the ventilator 1000 may include patient safety alarms such as high / low airway pressure, high / low tidal volume, high / low respiratory rate / apnea, PEEP leakage, insufficient flow, spontaneous breathing - high / low PIP, spontaneous breathing - high / low VT, unmet patient inspiratory needs, automatic PEEP, patient disconnection, expiratory system failure / malfunction, calibration error, suspected triggering, tubing compliance failure, SpO2 sensor off / low / error, high / low heart rate, etc. The ventilator 1000 may also generate environmental alarms such as low battery, power failure, climate environment failure, oxygen supply failure, intake failure, etc. Self-test alarms may include internal communication errors, pneumatic system failures, power system failures, pulse oximetry module failures, preventative maintenance alarms, etc. In some examples, a pop-up message can be displayed at the ventilator interface when an alarm is generated. Additionally, one or more alarm setpoints can be adjusted by the user at the ventilator interface. For example, alarm setpoints for high / low airway pressure, high / low tidal volume, respiratory rate, spontaneous breathing, low SpO2%, and high / low heart rate can be manually adjusted by the device user. When an alarm signal is generated and / or when an alarm pop-up message is displayed at the ventilator interface 1022, the user can take one or more actions to mute the alarm signal and / or acknowledge the alarm.

[0220] In some implementations, the display on the ventilator may be insufficient to display all clinically relevant information available in the memory of the ventilator 1000 due to size, resolution, color palette, brightness, or other display performance specifications. For example, the ventilator may be compact in design and ultra-portability, minimizing the display interface. In one example, one or more displays on the ventilator 1000 may be smaller than generally available to enhance device portability, e.g., <2 square inches, <1, 2.5, 4, 5, or 6 square inches. In other examples, there may be no graphic display at all, only indicator lights. In this case, additional relevant information available in the memory of the ventilator 1000 but not visible on the ventilator 1000's display can be transferred to an accessory device for display on the larger display of the accessory device. Additionally, indicator lights may be configured to convey whether physiological sensor data and / or device parameters or settings are within acceptable limits or exceed one or more thresholds. For example, indicator lights may be configured to display different colors (e.g., green, yellow, red) based on whether the parameters and / or sensor data are in-band, tending towards out-of-band, or out-of-band. In other examples, the indicator light may flash at different speeds based on relative parameter / sensor data values ​​(e.g., constant when in-band and flashing when out-of-band). In some implementations, the information on the smaller ventilator display may be one or more user input fields in response to queries from the companion device, and may be limited to one or more user input fields, such as "patient height," "patient weight," and up / down cursors or other numeric selectors via a touchscreen, easing wheel, input dial, buttons, soft keys, etc. For example, a small ventilator interface may provide the ability to input patient characteristics and / or ventilation settings (such as the ventilation settings described herein).

[0221] In some examples, information may be abbreviated or limited to values ​​on a smaller ventilator display, but when the digital display area of ​​the ventilator display is double-clicked or otherwise selected, clinically relevant graphical and numerical information about the values ​​on the digital display area is displayed on the companion device in full graphical and informational detail. For example, only the SpO2 reading may be displayed digitally on the ventilator 1000's display, but when activated via a double-touch operation, as provided in the exemplary embodiments of the invention, the complete SpO2 waveform, oxygen concentration graph, CO2 waveform, and ECG may be displayed on the companion device's display.

[0222] In some implementations, when the accessory devices 110, 111, 119, and 204 are communicatively coupled to the ventilator 1000, the ventilator can transmit case information associated with physiological sensor inputs for display at the accessory devices 110, 111, 119, and 204 in a manner similar to that when the medical treatment device 202 is a defibrillator. For example, in response to receiving user input associated with one of the control operations at the ventilator 1000 at the accessory devices 110, 111, 119, and 204, in some implementations, the accessory devices 110, 111, 119, and 204 transmit command signals to cause various operations to occur at the medical treatment device. In some examples, the command signals sent from the accessory devices 110, 111, 119, and 204 to the medical treatment device may instruct the ventilator 1000 to update patient information, treatment information, or diagnostic information of medical events stored in the ventilator 1000's database. In response to receiving various signals, the ventilator 1000 performs various operations associated with the command signals, which may include: storing the provided information (e.g., transmitting patient information for updating at the ventilator 1000) or recording treatment markers (e.g., transmitting treatment / event markers of the ventilator 1000 for recording in the patient care record) or initiating a snapshot (e.g., transmitting a command signal for the medical treatment device to initiate a snapshot of one or more types of case information displayed on the display screen of the ventilator 1000) or activating analysis features at the ventilator. In one example, in response to receiving patient height, gender, and / or weight information input at the companion devices 110, 111, 119, 204, the ventilator 1000 may automatically adjust the volume and rate of ventilation being administered to the patient by the ventilator 1000.

[0223] Furthermore, the command signals generated by the supporting devices 110, 111, 119, and 204 can also generate control signals for adjusting parameter settings and / or alarm setpoints at the ventilator 1000 based on user input provided at the supporting devices 110, 111, 119, and 204. For example, the ventilator display interface at the supporting devices 110, 111, 119, and 204 may include user inputs corresponding to ventilator setting inputs 1022a to 1022g, allowing the supporting device user to adjust the values ​​of ventilator settings 1002, 1004, 1006, 1008 / 1009, 1010, and 1012 / 1013. Additionally, the ventilator display interface at the supporting devices 110, 111, 119, and 204 may include menu user inputs corresponding to menu input 1024 on the ventilator. In some examples, the ventilator display interface may also include user inputs corresponding to other ventilator inputs, such as a mute / cancel input 1026 that allows the supporting device user to mute or suppress ventilator alarms. In some implementations, the ventilator display interface may also include user input corresponding to a manual breathing button / plateau pressure input 1028 on the ventilator 1000, which enables the accessory device user to have the ventilator 1000 deliver manual breaths to the patient and / or measure plateau pressure. In some examples, the ventilator display interface at accessory devices 110, 111, 119, 204 provides a more user-friendly interface for efficiently using the ventilator to provide enhanced patient care, without having to manipulate cumbersome interface controls such as the selection dial 1030 on the ventilator 1000 (where the user scrolls the dial 1030 back and forth to set ventilator parameters).

[0224] In some implementations, the ventilation display interface at accessory devices 110, 111, 119, and 204 is a selectable user interface that can be switched to be viewed via various selection tabs. In some embodiments, similar to the embodiments discussed above for defibrillator / monitor medical treatment devices, accessory devices 110, 111, 119, and 204 may include one or more device views, working views, trend views, and / or case type views of the ventilator display interface screen, allowing accessory device users to customize the ventilator case information displayed at accessory devices 110, 111, 119, and 204. In some embodiments, accessory devices 110, 111, 119, and 204 may include selectable display interface screens for multiple types of medical treatment devices (e.g., monitors, defibrillators / monitors, ventilators), allowing accessory device users to view case information associated with more than one medical treatment device used to care for a patient during a medical event. In one example, case information for each type of medical treatment device is viewable at a separate display interface of the accessory device. In another example, case information from different medical treatment devices can be combined on the same display interface screen at the supporting devices 110, 111, 119, and 204.

[0225] In some embodiments, in addition to the embodiments described above, when the medical treatment device 202 is a ventilator 130 or 1000, the supporting devices 110, 111, 119, and 204 may be configured to display one or more user interface screens including case information received from the connected ventilator 130 or 1000. In some examples, the ventilator user interface screen configured to be displayed at the supporting devices 110, 111, 119, and 204 may include the device view, operational view, and / or trend view as described above. For example, Figure 11A Shown as a ventilator 1000 ( Figure 10The visual representation of the ventilator device view 1101 is a visual reproduction of the display interface 1022 at the ventilator interface 1022. The visual reproduction of case information at the accessory devices 110, 111, 119, and 204 may include data and format variations that enhance the viewing and understanding of the case information by the accessory device user. In some examples, the display layout, magnification of each data section, physiological waveform selection, physiological digital readout selection, resolution, waveform duration, waveform size, text size, font, and / or display color may differ from the content displayed at the medical treatment device. In some examples where the display interfaces of the accessory devices 110, 111, 119, and 204 are larger than the display interfaces of the ventilator 130 and 1000, additional case information may be provided in device view 1101 compared to the content displayed at the ventilator interface 1022. For example, device view 1101 includes blood pressure measurements 1115, 1117, and 1119 not included at the ventilator interface 1022. In some embodiments, the visual reproduction of case information displayed within device view 1101 of the supporting devices 110, 111, 119, 204 may include rotating the orientation of the displayed case information. For example, the display interface 1022 of the ventilator 1000 has a longitudinal orientation, while the display interface of device view 1101 is rotated 90 degrees and has a lateral orientation. In some examples, device view 1101 is one of a plurality of selectable display views of the supporting devices 110, 111, 119, 204 that can be selected via selection tab 1161.

[0226] In some implementations, the ventilator device view user interface 1101 displayed at the supporting devices 110, 111, 119, 204 may include continuous SpO2 waveform data 1116 and airway pressure waveform 1118. In some examples, the airway pressure waveform 1118 may also include P AW Set point 1121 and high airway pressure limit 1120. Device view 1101 may also include respiratory rate (BPM) 1112, I:E ratio 1113, tidal volume (V) tValues ​​for PEEP 1100, PEEP 1109, PIP limit 1108, FiO2 1106, and mode settings (e.g., AC, SIMV, CPAP, BL) 1114. Examples of physiological parameters that may be displayed at device view 1101 may also include discontinuous SpO2 measurements 1104, EtCO2 measurements 1111, heart rate 1165, temperature 1123, blood pressure 1115, 1117, 1119, and / or smart port data values ​​1197a, 1197b. In some examples, instead of or in addition to physiological sensing on medical treatment device 202, a smart port is a port that enables medical treatment device 202 (e.g., ventilator 130, 1000) to connect to peripheral devices (such as pulse oximeters, carbon dioxide analyzers, spirometers, or ultrasound). In some examples, these peripheral smart port sensors allow closed-loop controlled ventilation algorithms and patient assessment to occur. In some examples, smart ports 1197a and 1197b may also allow configurations of only ventilators 130 and 1000 and accompanying devices 110, 111, 119, and 204 without defibrillator 108. In some examples, the device view user interface screen 1101 may also include an alarm section 1125 displaying any current alarm status. The device status section 1127 may display one or more device status icons indicating battery life and / or connection to an external power source.

[0227] Similar to the other UI screens mentioned above, device view 1101 (and Figures 11B to 11D and Figure 12A and Figure 12B Other display views shown may include a status bar and navigation strip with one or more selection buttons and treatment information, including a case event selector 610, a patient type selector 609, and an interface 1320 for displaying alarm summaries. Figure 13A Alarm selector 1105, case type selector 606, and input interface 1300 for displaying patient information. Figure 13B The patient information input selector 612, treatment / event marker input selector 614, snapshot recording selector 616, and / or enabling the companion device user to verify which medical treatment device 108, 130, 1000, 202 the companion device 110, 111, 119, 204 is connected to, and the pairing device verification input 618. In some examples, the device view user interface 1101 and any other user interface displaying ventilator case information may include, as described above, enabling the display of the ventilator settings adjustment user interface screen 1362. Figure 13C The user enters 1129 to set up the ventilator.

[0228] Go to Figure 11CThe diagram shows a ventilator operational view user interface screen 1102. In some implementations, the operational view user interface screen 1102 can be configured to display one or more ventilator waveforms, settings, and case information data when treatment is administered to a patient. In some implementations, the operational view user interface screen 1102 can be customized based on the preferences and / or roles of the companion device user and which types of medical treatment devices 108, 130, 202 are connected to companion devices 110, 111, 119, 204 via wireless communication links. In some implementations, the operational view screen 1102 can be a scrollable interface, allowing the user to add as much data as needed to the operational view 1102 for easier viewing by scrolling up or down. In some examples, the operational view 1102 is one of several selectable display views of companion devices 110, 111, 119, 204 that can be selected via a selection tab 1163.

[0229] In one example, the working view screen 1102 includes continuous SpO2 waveform data 1116, airway pressure waveform 1118, EtCO2 waveform 1131, and V. t Waveform 1131. Working view 1102 may also include respiratory rate (BPM) 1112, I:E ratio 1113, V t Values ​​for 1110, PEEP 1109, PIP limit 1108, FiO2 1106, and mode settings (e.g., AC, SIMV, CPAP, BL) 1114. Examples of physiological parameters that may be displayed in the device view 1102 may also include discontinuous SpO2 measurements 1104, EtCO2 measurements 1111, heart rate 1165, temperature 1123, and / or blood pressure 1115, 1117, 1119. Other ventilator parameters that may be displayed include, for example, inspiratory pressure data, expiratory pressure data, inspiratory flow rate data, expiratory flow rate data, leak detection, or other information measured from the ventilator. The device status section 1127 may display one or more device status icons indicating battery life and / or connection to an external power source.

[0230] In some implementations, the user can manually add / remove data sections or drag / reposition data sections in the work view 668 as needed. For example, the displayed data sections can be used as grab bars that can be moved to another location within the work view 1102, which automatically shifts other data sections to support the selected adjustments. In some examples, the user can store a manually configured work view layout as custom data 260a, allowing the devices 110, 111, 119, and 204 to pre-configure a customized work view for the user for future medical events. In some examples (such as when a caregiver is supervising other team members administering chest compressions), the work view may include a chest compression dashboard 670 (see [link to dashboard]) that provides the user with feedback on how care is being administered to the patient. Figure 11D (See the chest compression dashboard in the multi-device working view 1194). In some implementations, the chest compression dashboard 670 displays chest compression case information from inputs from at least one chest compression sensor. In one example, the chest compression sensor connected to the ventilator 130, 1000 via a wired or wireless connection may be a motion sensor disc positioned under the caregiver's hand while the caregiver is performing chest compressions and detects the depth and rate of chest compressions.

[0231] Figure 12A and Figure 12B Additional examples of ventilator operating view user interface screens 1200 and 1202, which can be displayed at companion devices 110, 111, 119, and 204, are shown. In some examples, operating view 1200 may include ventilation-based information associated with providing positive pressure ventilation to the patient, and operating view 1202 may include oxygenation-based information. In some examples, the companion device user can switch between the two views 1200 and 1202 via tabs 1206 and 1208. In some examples, the two operating views 1200 and 1202 may include heart rate 1165, BPM 1112, I:E ratio 1113, V... t 1110, PEEP 1109, PIP limit 1108, FiO2 1106, SpO2 1104, and mode settings (e.g., AC, SIMV, CPAP, BL) 1114. In one example, the ventilation working view 1200 may display PIP 1232, P... plat 1234, V t 1236, BPM 1238 and minimum quantity (V) min The waveform of 1240. Additionally, the oxygenation working view 1202 can display PR 1242, SpO2 1244, FiO2 1246, and V. t The waveform of 1236.

[0232] In some implementations, working views 1200, 1202 include examples of navigation bars or strips with one or more user input selections, such as settings user input 1129, alarm summary user input 1105, mode selection user input 1204, patient information user input 612, and snapshot capture user input 616, etc. In some examples, mode selection user input 1204 is integrated with ventilator settings adjustment user interface 1362 (…). Figure 13C This corresponds to the mode selection user input 1380 at the location shown. Additionally, working views 1200 and 1202 may include an event marker section 1250, which displays one or more event markers of different types occurring during the patient treatment process. In some implementations, the event marker section 1250 may display one or more event markers of different types associated with alarm conditions and / or mode changes at the ventilator. In some implementations, individual event markers (e.g., markers 1224, 1226, 1228, 1230) are displayed at locations within one or more event subsections 1210, 1212, 1214, 1216 corresponding to the time of occurrence of each event. For example, the event marker section 1250 may include a patient safety subsection 1210 displaying the event marker (e.g., marker 1224) corresponding to a patient safety alarm. The patient safety alarms displayed in subsection 1210 may include alarms such as: high / low airway pressure, high / low tidal volume, high / low respiratory rate / apnea, PEEP leak, insufficient flow, spontaneous breathing - high / low PIP, spontaneous breathing - high / low VT, unmet patient inspiratory needs, automatic PEEP, patient disconnection, expiratory system failure / malfunction, calibration error, suspected trigger, tubing compliance failure, SpO2 sensor off / low / error, high / low heart rate, etc. In some implementations, the usage environment alarm subsection 1212 may display event markers (e.g., event marker 1226) for detected usage environment alarms (such as low battery, power failure, climate environment failure, oxygen supply failure, intake failure, etc.). The self-test alarm subsection 1214 may display event markers (e.g., event marker 1228) for self-test alarms (such as internal communication errors, pneumatic system failures, power system failures, pulse oximetry module failures, preventative maintenance alarms, etc.). In some embodiments, the event marker portion 1250 may further include a ventilator mode sub-portion 1216, which may display an event marker indicating when the ventilator mode was adjusted. For example, event marker 1230 indicates when the ventilator mode was adjusted from AC(P) to AC(V).

[0233] In some implementations, working views 1200, 1202 display real-time ventilator data over one or more adjustable time periods. Working views 1200, 1202 provide the device user with the ability to adjust the granularity of the real-time time data displayed within the display interfaces of the devices 110, 111, 119, 204. For example, working views 1200, 1202 can display case information for the entire patient case occurring within timeframe 1218. For timeframe 1218, working view interfaces 1200, 1202 can include one or more selectable sub-sections of the time (e.g., sub-sections 1220, 1222), which, when selected, allow the device user to view a magnified version of the case information (e.g., ...). Figure 12A (Waveforms 1232, 1234, 1236, 1238, 1240 in the image). In some examples, the accompanying device user can easily switch back and forth between the full case view 1218 and one or more magnified time frames 1220, 1222 by selecting individual time frames 1218, 1220, 1222.

[0234] In some implementations, a slider control 1248 is provided in the full case view 1218 to examine portions of the timeline including time frames within subsections 1220 and 1222. For example, the slider control 1248 can be positioned to the far left (e.g., time 15:00) to browse the start of the treatment and to the far right (e.g., time 20:59) to view case information in real time. As shown in the figure, the slider control 1248 is positioned at 18:05.

[0235] Return to Figure 2 In some implementations, auxiliary devices 110, 111, 119, and 204 can be configured to simultaneously connect to, monitor, and / or control more than one medical treatment device 202. In some examples, auxiliary devices 110, 111, 119, and 204 can be connected to two or more defibrillators / monitors or two or more ventilators associated with different patients treated at the emergency care scene. In other examples, auxiliary devices 110, 111, 119, and 204 can be simultaneously connected to different types of medical treatment devices 108, 130, and 202 used to treat a single patient. For example, as... Figure 1CAs shown, the accessory device 119 is connected to and communicates with the defibrillator / monitor 108 and ventilator 130, which are used to administer treatment to patient 102. In some implementations, the user interface screen presented on the display screen of the accessory devices 110, 111, 119, 204 can display case information received from one, some, or all of the connected medical treatment devices 108, 130, 202. In one example, the accessory device may include selectable device views for each connected medical treatment device 108, 130, 202 (e.g., ...). Figure 6A View 600 of the defibrillator device in the middle and Figure 11A (Ventilator device view 1101). Instead of device views 600, 1101, or in addition to device views 600, 1101, the auxiliary devices 110, 111, 119, 204 may include an optional combined device working view that displays case information from the multiple connected medical treatment devices 108, 130, 202.

[0236] As further discussed below, in some embodiments, the supporting devices 110, 111, 119, 204 may be configured to present one or more working views and / or trend views that simultaneously display information received from multiple medical treatment devices 108, 130, 202 (e.g., Figure 11B and Figure 11D The working view user interface screens 1100, 1194 and Figure 11E (See trend view user interface screen 1150). In some examples, the ability to monitor and / or control the status of multiple medical treatment devices 108, 130, 202 is provided to the rescue team supervisor 118, offering a technical solution to clinical problems. For example, auxiliary devices 110, 111, 119, 204 can display real-time case information from multiple medical treatment devices 108, 130, 202, improving the quality of care provided to patients. Additionally, auxiliary devices 110, 111, 119, 204 can coordinate the transmission of command signals to one or more medical treatment devices 108, 130, 202 in real time based on received user input to control the operation of medical treatment devices 108, 130, 202, further enhancing patient care. In some implementations, based on the type of received user input, auxiliary devices 110, 111, 119, 204 can be configured to transmit command signals to one or both of the connected medical treatment devices 108, 130, 202.

[0237] For example, go to Figure 5H This illustrates a method 590 for coordinating the control of multiple medical treatment devices by individual accessory devices 110, 111, 119, 204. Although combined with... Figure 1C The example of the emergency scene 100c shown (which includes a defibrillator 108 and a ventilator 130 that are simultaneously connected to and communicate with the accessory device 119) is used for description, but it is understood that method 590 can be applied to any combination of multiple medical treatment devices 108, 130, 202.

[0238] In some embodiments, method 590 begins by receiving user input (591) at companion devices 110, 111, 119, 204. In some examples, the received user input may be associated with one of the medical treatment devices 108, 130, 202 (e.g., 12-lead analysis user input 617 corresponds to defibrillator 108, and setup user input 1129 corresponds to ventilator 130). In other examples, the received user input may be associated with both of these medical treatment devices (e.g., patient information user input 612 and...). Figure 7A and Figure 13B (The user input associated with the patient information user interface screen in the image). Another example of user input affecting the two medical treatment devices 108, 130, 202 is the treatment tag user input 614 and any user input associated with the treatment tag user interface screen 712. For example, submitting treatment tag information at the treatment tag user interface screen can cause the companion devices 110, 111, 119, 204 to transmit command signals to record the treatment tag information at both the defibrillator 108 and the ventilator 130. In other examples, the user can choose to transmit treatment / event tag information to only one of the connected medical treatment devices 108, 130, 202. In some implementations, other user inputs may also correspond to command signals that can be transmitted to one or both of the medical treatment devices 108, 130, 202. For example, snapshot user input 616 can cause a snapshot of the displayed case information to be recorded at the defibrillator 108 and / or the ventilator 130.

[0239] In some examples, if the received user input is consistent with all connected medical treatment devices 108, 130, 202 (e.g., Figure 1CIf the defibrillator 108 and ventilator 130 in the emergency scene 100c correspond to each other (592), then the auxiliary devices 110, 111, 119, and 204 can be configured to transmit command signals to all connected medical treatment devices 108, 130, and 202 (594). If the received user input corresponds to one but not all of the connected medical treatment devices 108, 130, and 202, in some implementations, the auxiliary devices 110, 111, 119, and 204 transmit the corresponding command signal to the respective medical treatment device 108, 130, and 202 associated with the received user input (593). In some embodiments, when a confirmation signal indicating that an action associated with the command signal has been taken is received from one or more of the medical treatment devices 108, 130, and 202 (595), the auxiliary devices 110, 111, 119, and 204 display a confirmation message at a display interface (596). In some examples, when a command signal is sent to the connected medical treatment devices 108, 130, 202, the auxiliary devices 110, 111, 119, 204 can be configured to display an acknowledgment message associated with each of the medical treatment devices 108, 130, 202, indicating that an action has been taken at each of the medical treatment devices 108, 130, 202. In other examples, the auxiliary devices 110, 111, 119, 204 can be configured to display a single acknowledgment message indicating that two of the medical treatment devices 108, 130, 202 have performed the requested action associated with the command signal.

[0240] Additionally, in some implementations, in response to receiving a confirmation signal indicating that a particular action has been taken from one or more of the medical treatment devices 108, 130, 202, the auxiliary devices 110, 111, 119, 204 can be configured to display corresponding treatment / event markers (e.g., markers 658, 662, 1130, 1132) on one or more of the trend view user interface screens. Figure 11E ))(597).

[0241] Although described as a specific series of steps, other embodiments may include more or fewer steps. For example, some user input may not be associated with the displayed event marker (597) (e.g., snapshots and / or 12-lead user input). In other embodiments, some steps may be performed in a different order, or two or more steps may be performed in parallel. For example, an acknowledgment message (596) may be displayed at the accompanying devices 110, 111, 119, 204 before, simultaneously with, or after the display of the corresponding action / event marker (597). Other modifications to method 590 are possible while remaining within the scope and purpose of method 590.

[0242] Figure 11B An example of a working view user interface screen 1100 is shown, which displays multiple medical treatment devices (e.g., defibrillators and ventilators) connected to a single accessory device. Figure 1C The data received by the defibrillator 108 and ventilator 130 connected to the accessory device 119. In some implementations, the multi-device operational view 1100 can display case information dedicated to each of the individual medical treatment devices 108, 130, 202 (e.g., P from ventilator 130). AW Waveform 1118 and ECG II waveform 1169 from defibrillator 108) and / or case information available from medical treatment devices (e.g., SpO2 waveform 1116, EtCO2 waveform 1131, or IBP waveform 1171). In some examples, for values ​​of case information available from more than one of medical treatment devices 108, 130, 202, the companion device user can select whether the displayed value is received from defibrillator 108 or ventilator 130. For example, the displayed HR value 1167 is determined based on ECG data received from defibrillator 108. In some examples, the multi-device working view 1100 may also include BPM 1112, I:E ratio 1113, V tValues ​​for 1110, PEEP 1109, PIP limit 1108, FiO2 1106, and mode settings (AC, SIMV, CPAP, BL) 1114. Examples of physiological parameters that can be displayed in the working view 1100 may also include SpO2 measurements 1104, EtCO2 measurements 1111, temperature 1123, and / or blood pressure 1115, 1117, 1119. In some examples, the multi-device working view 1100 may also include an alarm section 1125 displaying any current alarm status. The device status section 1127 may display one or more device status icons indicating battery life and / or connection to an external power source. In some implementations, the working view user interface screen 1100 is one of several views that can be presented at the display interface of the accompanying devices 110, 111, 119, 204 and can be selected via tab 1181. When an alarm user input 1107 selection is detected at the working view 1100, the supporting devices 110, 111, 119, and 204 can cause the alarm summary UI screen 1320 to be displayed. Figure 13A The alarm summary UI screen 1320 displays a summary of alarm status received from all connected medical treatment devices 108, 130, and 202.

[0243] Figure 11D Another example of a working view user interface screen 1194 is shown, which includes information from devices simultaneously connected to a single companion device (e.g., Figure 1C The data includes the defibrillator 108 and ventilator 130 of the supporting device 119). In one example, the working view 1194 includes ECG waveform 620a received from the defibrillator 108 and V waveform 620a received from the ventilator 130. tWaveform. Additionally, the working view 1194 can display values ​​of temperature 1123, blood pressure 1115, 1117, 1119, EtCO2 1111, and HR 1165 received from any of the medical treatment devices 108, 130, 202. In some implementations, the working view user interface screen 1194 also includes a compression (CPR) dashboard 670 displaying caregiver performance data of the rescuer's compressions on the patient. In some examples, compression sensors that detect the depth and / or rate of compressions can be connected to any of the connected medical treatment devices 108, 130, 202, which in turn transmits the caregiver performance data obtained from the compression sensors to the accompanying devices 110, 111, 119, 204. In some implementations, when the start of compression is detected based on data signals received from the connected compression sensors, the ventilator 130 can automatically adjust ventilation to a CPR-optimized mode. For example, the ventilator 130 can automatically switch to a compression-to-ventilation ratio of 30:2 or switch to providing ventilation in conjunction with the CPR dashboard 670 and / or V. t The waveform at 1133 shows another, more advanced mode of timing synchronization of specific characteristics of the compressions. In some examples, the auxiliary devices 110, 111, 119, and 204 can provide a visual indication of the synchronization between ventilation and compressions at the CPR dashboard 670. For example, the auxiliary devices 110, 111, 119, and 204 can overlay additional bars corresponding to synchronized ventilation on the compression diagram 680. In some examples, the bars corresponding to ventilation on the compression diagram 680 can be displayed in a different color than the bars associated with the same compressions. In some implementations, in response to receiving compression sensor data from one of the connected medical treatment devices 108, 130, and 202, the auxiliary devices 110, 111, 119, and 204 can automatically display the CPR dashboard 670 within at least one working view user interface 1194.

[0244] Go to Figure 11EThe diagram illustrates an example of a trend view user interface screen 1108. In some implementations, the trend view user 1108 can be configured to display graphical, tabular, and / or numerical trends of case information generated by multiple medical treatment devices (e.g., defibrillator 108 and ventilator 130) simultaneously connected to companion devices 110, 111, 119, 204. When the trend view selector 1183 is selected, in some examples, companion devices 110, 111, 119, 204 can initially present a default set of case information trends (e.g., physiological sensor data measured from multiple connected medical treatment devices 108, 130, 202) in graphical and / or tabular format within the trend view 1108. For example, the default set of case information trends presented in the trend view may include graphs of PR 1185, SpO2 1187, and FIO2 1189 values ​​over time. The trends displayed in the trend view UI screen 1108 may also include the average values ​​of EtCO2 1191, SpO2 1193, and NIBP 1195 during the medical treatment event. Alternatively, trend data may be displayed in tabular form (such as in data table 1190). In some examples, data table 652 may display one or more physiological information data trends (e.g., PR, FIO2, SpO2) at predetermined time intervals (e.g., every 10 seconds, 20 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes). For example, each row of data table 1190 may correspond to a value of one or more types of physiological information recorded at predetermined time intervals.

[0245] In some implementations, the auxiliary devices 110, 111, 119, and 204 can annotate trend graphs 1185, 1187, and 1189 with treatment / event marker annotations 656, 658, 660, 662, 1130, and 1132, allowing the auxiliary device user to easily identify the impact of each treatment on the patient's condition over time. In some examples, when the trend view selector 1183 is selected, the auxiliary devices 110, 111, 119, and 204 can transmit data requests individually or as part of a batch data transfer request to overlay treatment / event marker data onto trend graphs 1185, 1187, and 1189. When one of the treatment / event marker annotations 656, 658, 660, 662, 1130, and 1132 is selected, the accompanying devices 110, 111, 119, and 204 can enable the display of details related to the selected treatment / event marker, such as the amount of energy applied during the electric shock, the amount of medication administered, changes in ventilator mode or other settings, a display of the defibrillator and / or ventilator waveforms at the time the treatment / event marker was entered, and / or a snapshot view of ECG and / or ventilator data at the time associated with the selected treatment / event marker.

[0246] In some implementations, the trend view UI 1108 may also include a trend selection tab 654b, which allows the user of the accessory device to customize the trends displayed within the display interface. For example, when the trend selection tab 654b is selected, the accessory devices 110, 111, 119, and 204 can display one or more trends selected and / or deselected by the user based on trend viewing preferences. In one example, the user can select HR, pulse rate (PR), SpO2, NIBP, invasive blood pressure (systolic BP, diastolic BP, mean arterial pressure), EtCO2, respiratory rate / respiratory rate (RR / BR), pulse perfusion variability index (PVI), respiratory rate (BPM), I:E ratio, and V. t The display waveform and / or average value of one or more of PEEP, PIP, and / or FiO2. Additionally, the user can choose whether to display data table 1190. In some embodiments, the user can also select the time interval for recording trend data displayed within the trend view 1108 (such as within data table 1190). In some implementations, the input provided at the trend selection tab 654b can also allow the user to select a predetermined time interval (e.g., every 10 seconds, 20 seconds, 30 seconds, 1 minute, 3 minutes, 5 minutes) for recording and / or displaying trend data in the trend view UI screen 1108.

[0247] refer to Figure 9 Schematic illustration of targeting Figures 1A to 8G and Figures 10 to 13D-2 Examples of components of the various devices discussed. These devices may include medical treatment device 902 (e.g., Figure 2 The medical treatment device 202) and one or more auxiliary devices 904 (e.g., Figure 2 The accompanying devices 904 (110, 111, 119, 204) are mentioned. In implementations, medical treatment device 904 may be a therapeutic medical device configured to deliver medical treatment to a patient, and may not be limited to patient monitoring and / or diagnostic care. In some examples, accompanying device 904 may be a portable computing device such as a tablet, laptop, or smartphone. Accompanying device 904 may be adapted to serve as a display screen for a medical device or (e.g., when monitoring continuous NIBP measurements). In implementations, accompanying device 904 may not be a therapeutic medical device configured to deliver medical treatment to a patient. In such implementations, accompanying device 904 may be limited to patient monitoring and / or diagnostic care, such as monitoring patient condition and / or controlling one or more functional operations at medical treatment device 902 via one or more displays as described in the embodiments herein.

[0248] Medical treatment device 902 and one or more auxiliary devices 904 can be communicationally coupled via communication coupling 906 (which can be a wired and / or wireless communication link). Wired communication links can include wired electrical coupling, optical coupling via fiber optic cables, etc. Wireless communication links can include coupling via radio frequency or other transmission media and / or via networks such as local area networks, ad hoc networks, mesh networks, cellular and / or other communication networks, computer networks, etc. The communication links described herein can utilize, for example, 802.11, The communication link may include near-field communication that can be implemented via a communication RFID tag. The communication link may include one or more networks, such as a local area network, cellular network, satellite network, and / or computer network (e.g., an Internet Protocol (IP) network). In various implementations, the communication coupling described herein can provide a secure and / or authenticated communication channel. In implementations, the apparatus described herein can encrypt and / or decrypt data transmitted and / or received via the communication coupling. In some implementations, the communication coupling 906 is connected to the aforementioned wireless communication link 206 (…). Figure 2 Corresponding to.

[0249] In some embodiments, the memory 910 of the medical treatment device 902 and the similar memory 922 of the auxiliary device 904 may include a data storage unit and corresponding data storage circuitry. The data storage circuitry may include one or more non-transitory or non-volatile computer-readable media, such as flash memory, solid-state memory, magnetic memory, optical memory, cache memory, combinations thereof, and others. The data storage unit may be configured to store executable instructions and data used for the operation of the medical treatment device 902 and / or the auxiliary device 904. In some implementations, the data storage processing circuitry combined with the data storage unit may include executable instructions that, when executed on the processor 908 and / or 920, are configured to cause at least one processor 908 and / or 920 to perform one or more functions, such as targeting... Figure 3 , Figure 4A , Figure 4B and Figures 5A to 5F The methods described, etc.

[0250] exist Figure 9 In this configuration, components 908, 910, 912, 914, 916, and 918 are communicatively coupled to each other (directly and / or indirectly) for bidirectional communication. Similarly, components 920, 922, 924, 926, and 928 are communicatively coupled to each other (directly and / or indirectly) for bidirectional communication.

[0251] In some implementations, components 902, 910, 916, and / or 918 of the medical treatment device 902 may be combined into one or more discrete components, and components 916 and / or 918 may be part of processor 908. Processor 908 and memory 910 may include and / or be coupled to associated circuitry to perform the functions described herein. Additionally, components 920, 922, and 928 of the supporting device 904 may be combined into one or more discrete components, and component 928 may be part of processor 920. Processor 920 and memory 921 may include and / or be coupled to associated circuitry to perform the functions described herein.

[0252] In some implementations, the medical treatment device 902 may include a treatment delivery control module 918. For example, the treatment delivery control module 918 may be an electrotherapy delivery circuit including one or more high-voltage capacitors configured to store electrical energy for pacing or defibrillation pulses. The electrotherapy delivery circuit may also include resistors, additional capacitors, relays and / or switches, bridges such as H-bridges (e.g., including multiple insulated-gate bipolar transistors or IGBTs), voltage measurement components, and / or current measurement components. As another example, the treatment delivery control module 918 may be a press-feed electromechanical controller configured to control a mechanical press-feeding device. As yet another example, the treatment delivery control module 918 may be an electromechanical controller configured to control drug delivery, temperature management, ventilation, and / or other types of treatment delivery.

[0253] Medical treatment device 902 may be incorporated into and / or configured to be coupled to one or more patient interface devices 930. Patient interface device 930 may include one or more treatment delivery components 932a and one or more sensors 932b. Similarly, companion device 904 may be adapted for medical use and may be incorporated into and / or configured to be coupled to one or more patient interface devices 934. Patient interface device 934 may include one or more sensors 936. Sensor 936 may be substantially as described herein with respect to sensor 932b.

[0254] Sensors 932b and 936 (one or more) may include sensing electrodes (e.g., sensing electrode 938), ventilation and / or breathing sensors (e.g., ventilation and / or breathing sensor 940), temperature sensors (e.g., temperature sensor 942), chest compression sensors (e.g., chest compression sensor 944), etc. In some implementations, information obtained from sensors 932b and 936 may be used to generate a display view at the medical treatment device 902 and simultaneously at the accompanying device 904, and (e.g., at...) Figures 6A to 6CDisplay views 600, 636, 668 and Figures 8B to 8G The information described above is shown in case type views 814, 820, 824, 834, 840, and 844. In one example, sensing electrode 938 may include a cardiac sensing electrode. The cardiac sensing electrode may be a conductive and / or capacitive electrode configured to measure changes in the patient's electrophysiology to measure the patient's ECG information. Sensing electrode 938 may also measure the patient's transthoracic impedance and / or heart rate. Ventilation and / or respiration sensor 940 may include a spirometry sensor, a flow sensor, a pressure sensor, an oxygen and / or carbon dioxide sensor (e.g., one or more of a pulse oximetry sensor, an oxygenation sensor (e.g., muscle oxygenation / pH), an O2 gas sensor and a carbon dioxide recording sensor, an impedance sensor, etc.) and combinations thereof. Temperature sensor 942 may include an infrared thermometer, a contact thermometer, a remote thermometer, a liquid crystal thermometer, a thermocouple, a thermistor, etc., and may measure the patient's temperature from the inside and / or from the outside. The chest compression sensor 944 may include one or more motion sensors, such as one or more accelerometers, one or more force sensors, one or more magnetometers, one or more velocity sensors, one or more displacement sensors, etc. The chest compression sensor 944 can provide one or more signals representing chest movement to the medical treatment device 902 via a wired and / or wireless connection. The chest compression sensor 944 may be, for example, but not limited to, a compression disc, a smartphone, a handheld device, a wearable device, etc. The chest compression sensor 944 may be configured to detect chest movement imparted by a rescuer and / or an automated chest compression device (e.g., a belt system, a piston system, etc.). The chest compression sensor 944 can provide signals indicating chest compression data, including displacement data, velocity data, release velocity data, acceleration data, force data, compression rate data, dwell time data, hold time data, blood flow data, blood pressure data, etc. In implementation, defibrillation and / or pacing electrodes may include or be configured to be coupled to chest compression sensor 944.

[0255] In various implementations, sensors 932b and 936 may include one or more sensor devices configured to provide sensor data, such sensor data including, but not limited to, electrocardiogram (ECG), blood pressure, heart rate, respiratory rate, heart sounds, lung sounds, breath sounds, end-tidal CO2, muscle oxygen saturation (SMO2), oxygen saturation (e.g., SpO2 and / or PaO2), cerebral blood flow, point-of-care laboratory measurements (e.g., lactate, glucose, etc.), temperature, electroencephalogram (EEG) signals, cerebral oxygen levels, tissue pH, tissue fluid levels, images and / or videos via ultrasound, laryngoscopy, and / or other medical imaging techniques, near-infrared reflectance spectroscopy, respiratory transpiration, cardiac transpiration, and / or patient movement. Images and / or videos may be two-dimensional or three-dimensional, such as various forms of ultrasound imaging.

[0256] One or more treatment delivery components 932a may include electrotherapy electrodes (e.g., electrotherapy electrode 938a), (one or more) ventilation devices (e.g., ventilation device 938b), (one or more) intravenous devices (e.g., intravenous device 938c), (one or more) compression devices (e.g., compression device 938d), etc. For example, electrotherapy electrode 938a may include defibrillator electrodes, pacing electrodes, and combinations thereof. Ventilation device 938b may include tubes, masks, abdominal and / or chest compression machines (e.g., belts, chest armor, etc.), etc., and combinations thereof. Intravenous device 938c may include drug delivery devices, fluid delivery devices, and combinations thereof. Compression device 938d may include mechanical compression devices such as abdominal compression machines, chest compression machines, belts, pistons, and combinations thereof. In various implementations, (one or more) treatment delivery components 932a may be configured to provide sensor data and / or be coupled to and / or incorporated into sensors. For example, the electrotherapy electrode 938a can provide sensor data such as transthoracic impedance, ECG, heart rate, etc. Furthermore, the electrotherapy electrode 938a may include and / or be coupled to a chest compression sensor. As another example, the ventilation device 938b may be coupled to and / or incorporated with a flow sensor, gas type sensor (e.g., oxygen sensor, carbon dioxide sensor, etc.). As another example, the intravenous device 938c may be coupled to and / or incorporated with a temperature sensor, flow sensor, blood pressure sensor, etc. As yet another example, the compression device 938d may be coupled to and / or incorporated with a chest compression sensor, patient position sensor, etc. The treatment delivery control module 918 may be configured to be coupled to and control (one or more) treatment delivery components 932a respectively.

[0257] One or more sensors 932b and 936 and / or (one or more) treatment delivery components 932a can provide sensor data. Patient data provided at (one or more) operating interfaces and / or (one or more) playback interfaces of the medical treatment device 902 and the accessory device 904 can display the sensor data. For example, the medical treatment device 902 can process signals received from (one or more) sensors 932b and / or (one or more) treatment delivery components 932a to determine sensor data. Similarly, the accessory device 904 can process signals received from (one or more) sensors 936 and / or sensor data received via the medical treatment device 902 from sensor 932b to ...

Claims

1. A medical treatment system for providing resuscitation care to a patient during a medical event, the medical treatment system comprising: A medical treatment device configured to monitor a patient and provide treatment to the patient, the medical treatment device comprising: At least one physiological sensor input is configured to generate a physiological signal corresponding to the patient during the medical event. The screen of a medical treatment device is used to present medical information based on the generated physiological signals, and At least one first processor, operatively coupled to the at least one physiological sensor input and the medical treatment device screen, the at least one first processor being configured to: Receive and process physiological signals corresponding to the patient. Medical data is generated based on processed physiological signals. The medical treatment device displays case information in a first display format, the case information including physiological information visually rendered based on generated medical data, and... The case information and the generated medical data are transmitted to the supporting device; and The supporting device is communicatively coupled to the medical treatment device via a communication link, and the supporting device includes: The device interface includes a display screen configured to allow a user to input one or more commands for the medical treatment device during the medical event. At least one second processor operatively interface-coupled with the device, the at least one second processor being configured to: Processing case information received from the medical treatment device and the generated medical data, This allows a real-time device view of the medical treatment device screen, including the physiological information, to be displayed at the device interface in a second display format, wherein the second display format provides a visual reproduction of the first display format. This enables the display of multiple display views at the device interface, each of which can be selected via a corresponding display view selection unit of the device interface, wherein the multiple display views include: A real-time device view of case information, including physiological information stored in the memory of the medical treatment device; and A working view including one or more custom display sections, and In response to the detection of at least one user input at the device interface, one or more instruction signals are transmitted to the medical treatment device.

2. The system according to claim 1, wherein, The medical treatment device screen includes multiple indicator lights, which are configured to indicate that the case information falls within a range defined by one or more thresholds.

3. The system according to claim 2, wherein, The plurality of indicator lights are configured to display a plurality of colors, wherein each of the plurality of colors is associated with a range of a plurality of ranges of the case information.

4. The system according to claim 1, wherein, The screen of the medical treatment device includes a screen with a display area of ​​no more than 4 square inches.

5. The system according to claim 1, wherein, The medical treatment device screen includes a display area between 3 and 6 square inches.

6. The system according to claim 1, wherein, The medical treatment device screen includes a display area between 2 and 5 square inches.

7. The system according to claim 1, wherein, The medical treatment device is a ventilator.

8. The system according to claim 7, wherein, The ventilator is a portable ventilator used to provide pre-hospital ventilation to patients.

9. The system according to claim 8, wherein, The portable ventilator weighs no more than 10 pounds.

10. The system according to claim 8, wherein, The portable ventilator weighs no more than 5 pounds.

11. The system according to claim 8, wherein, The portable ventilator weighs between 5 and 10 pounds.

12. The system according to claim 8, wherein, The portable ventilator weighs between 7 and 12 pounds.

13. The system according to claim 7, wherein, The surface area of ​​any side of the ventilator shall not exceed 25 square inches.

14. The system according to claim 7, wherein, The surface area of ​​any side of the ventilator shall not exceed 20 square inches.

15. The system according to claim 7, wherein, The surface area of ​​any side of the ventilator is between 15 and 25 square inches.

16. The system according to claim 7, wherein, The ventilator includes: An oxygen inlet, configured to supply oxygen to provide positive pressure ventilation for the patient; and A ventilation outlet is configured to be pneumatically coupled to the oxygen inlet and to deliver positive pressure ventilation with supplied oxygen to the patient.

17. The system according to claim 7, wherein, The one or more instruction signals include one or more control signals used by the ventilator to apply positive pressure ventilation to the patient.

18. The system according to claim 7, wherein, The one or more instruction signals include one or more control signals for adjusting one or more ventilator control settings.

19. The system according to claim 7, wherein, One or more ventilator control settings include at least one of the following: fractional oxygen concentration (FIO2) setting, positive end-expiratory pressure (PEEP) setting, and tidal volume (V) setting. t Settings include the inspiratory:expiratory ratio (I:E) setting, ventilator mode setting, and peak inspiratory pressure (PIP) threshold setting.

20. The system according to claim 1, wherein, The physiological information includes airway pressure waveform, i.e., P. AW The waveform is at least one of the following: peripheral capillary oxygen saturation waveform (SpO2 waveform) and invasive blood pressure waveform (IBP waveform).

21. The system according to claim 1, wherein, The physiological information includes graphs of at least one of end-tidal carbon dioxide (EtCO2), noninvasive blood pressure (NIBP), and pulse rate (PR) over time.

22. The system according to claim 1, wherein, The physiological information includes the current value of at least one of end-tidal carbon dioxide (EtCO2), noninvasive blood pressure (NIBP), invasive blood pressure (IBP), and heart rate (HR).

23. The system according to claim 1, wherein, The at least one user input includes an input for providing an instruction signal from one or more instruction signals to the medical treatment device.

24. The system according to claim 23, wherein, Transmitting one or more command signals to the medical treatment device includes: In response to detecting a selection of one of the at least one user inputs, an instruction signal is transmitted from one or more instruction signals to update at least one of the patient information, treatment information, and diagnostic information of the medical event.

25. The system according to claim 23, wherein, The at least one user input includes patient information input.

26. The system according to claim 25, wherein, The at least one second processor is further configured to display a patient information input interface at the device interface in response to detecting a user input signal associated with the patient information input.

27. The system according to claim 26, wherein, The patient information input interface includes multiple patient information input fields for entering patient background information.

28. The system according to claim 27, wherein, The multiple patient information input fields include a patient gender input field and a patient height input field.

29. The system according to claim 28, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting the corresponding patient gender and the corresponding patient height to the medical treatment device when submitting the corresponding patient gender input field and the corresponding patient height input field.

30. The system according to claim 29, wherein, The at least one first processor is further configured to automatically adjust the tidal volume setting, i.e., V, at the medical treatment device based on the corresponding patient gender and corresponding patient height in response to receiving the corresponding patient gender and corresponding patient height. t set up.

31. The system according to claim 23, wherein, The at least one user input includes medical treatment setting input.

32. The system according to claim 31, wherein, The at least one second processor is further configured to display the medical treatment settings interface at the device interface in response to detecting a user input signal associated with the medical treatment settings input.

33. The system according to claim 32, wherein, The medical treatment settings interface includes multiple medical treatment settings inputs for adjusting multiple medical treatment settings on the medical treatment device.

34. The system according to claim 33, wherein, The plurality of medical treatment settings include at least one of the following at the device interface: positive end-expiratory pressure (PEEP) setting, tidal volume setting (V... t Settings include breath-rate-per-minute (BPM) settings, inspiratory:expiratory ratio (I:E) settings, peak inspiratory pressure (PIP) threshold settings, peripheral capillary oxygen saturation (SpO2) settings, fractional inspiratory oxygen (FIO2) settings, and ventilation mode adjustment settings.

35. The system according to claim 33, wherein, In response to detecting the selection of one of the plurality of medical treatment setting inputs at the medical treatment setting interface, the at least one second processor is configured to display the setting adjustment interface of the corresponding medical treatment setting.

36. The system according to claim 35, wherein, The settings adjustment interface includes an interface for inputting numerical values ​​for the corresponding medical treatment settings.

37. The system according to claim 36, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: when submitting a medical treatment setting adjustment at the corresponding medical treatment setting adjustment interface, transmitting the medical treatment setting adjustment for the corresponding setting to the medical treatment device.

38. The system according to claim 37, wherein, The at least one first processor is further configured to automatically adjust the corresponding settings on the medical treatment device based on the medical treatment setting adjustment in response to receiving a medical treatment setting adjustment for the corresponding settings.

39. The system according to claim 38, wherein, In response to receiving a confirmation signal from the medical treatment device confirming the adjustment of the corresponding settings, the at least one second processor is configured to display an event marker associated with the adjustment of the corresponding settings at the medical treatment device in one or more of a plurality of selectable display views at the accessory device.

40. The system according to claim 39, wherein, The confirmation signal includes the time when the corresponding settings are adjusted at the medical treatment device.

41. The system according to claim 40, wherein, The event marker is displayed in one or more selectable display views at a location related to the time when the corresponding setting adjustment occurred.

42. The system according to claim 33, wherein, In response to detecting the selection of a medical treatment mode adjustment setting at the medical treatment setting interface, the at least one second processor is configured to display a mode selection interface at the device interface.

43. The system according to claim 42, wherein, The mode selection interface includes multiple medical treatment mode inputs, each of which is associated with a corresponding operating mode of the medical treatment device.

44. The system according to claim 43, wherein, The multiple medical treatment mode inputs include at least one of the following: assist / control mode (AC mode), synchronized intermittent forced ventilation mode (SIMV mode), continuous positive airway pressure mode (CPAP mode), and bilevel mode (BL mode).

45. The system according to claim 43, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting the corresponding medical treatment mode input to the medical treatment device when a selection of the corresponding medical treatment mode input is detected at the mode selection interface.

46. ​​The system according to claim 45, wherein, The at least one first processor is further configured to automatically adjust the corresponding operating mode at the medical treatment device in response to receiving a corresponding medical treatment mode input.

47. The system according to claim 46, wherein, In response to receiving a confirmation signal from the medical treatment device confirming the adjustment of the corresponding operating mode, the at least one second processor is configured to display an event marker associated with the adjustment of the corresponding operating mode at the medical treatment device in one or more of a plurality of selectable display views at the accessory device view.

48. The system according to claim 47, wherein, The confirmation signal includes the time when the corresponding operating mode adjustment occurs at the medical treatment device.

49. The system according to claim 48, wherein, The event marker is displayed in one or more selectable display views at a location related to the time when the corresponding operation mode adjustment occurs.

50. The system according to claim 23, wherein, The at least one user input includes an alarm summary input.

51. The system according to claim 50, wherein, The at least one second processor is also configured to display an alarm interface at the device interface in response to the detection of the selection of the alarm summary input.

52. The system according to claim 51, wherein, The alarm interface includes a list of events triggered by one or more alarms at the medical treatment device.

53. The system according to claim 52, wherein, The list of events caused by one or more alarms includes at least one of the following for each alarm-caused event: alarm trigger time, alarm description, alarm type, and alarm priority.

54. The system according to claim 53, wherein, The corresponding alarm types are one of the following: patient safety alarm, self-check alarm, and usage and environmental alarm.

55. The system according to claim 1, wherein, The at least one second processor is configured to display alarm markers associated with each alarm condition detected at the medical treatment device in one or more of a plurality of selectable display views at the accessory device view.

56. The system according to claim 55, wherein, At least one of the colors and shapes of the displayed alarm markers is based on the priority associated with the corresponding detected alarm condition.

57. The system according to claim 56, wherein, The alarm marker is displayed at a location in one or more selectable display views in relation to the time when the corresponding operating mode adjustment occurs.

58. The system according to claim 1, wherein, The medical treatment device screen includes a screen configured to display the case information in a first display format.

59. The system according to claim 58, wherein, The at least one second processor is configured to display a real-time device view of the case information, including the physiological information, displayed on the medical treatment device screen at the device interface in a second display format, wherein the second display format provides a visual reproduction of the first display format.

60. The system according to claim 59, wherein, Providing a visual reproduction of the first display format in the second display format includes: adjusting one or more visual aspects of the case information presented in the second display format based on the case information displayed in the first display format.

61. The system according to claim 60, wherein, The one or more visual aspects include one or more of the layout, color, font, magnification, resolution, size, and image position of the case information.

62. The system according to claim 59, wherein, Providing a visual reproduction of the first display format in the second display format includes rotating the display orientation of the case information presented within the display screen.

63. The system according to claim 1, wherein, The working view and the device view are displayed separately on the interface screen of the supporting device interface.

64. The system according to claim 1, wherein, The one or more customized display portions cannot be used for viewing in one or more device view display portions.

65. The system according to claim 1, wherein, The working view is a scrollable interface that provides more information than is displayed in the device view.

66. The system according to claim 1, wherein, One or more customized display sections can be manually selected by the caregiver.

67. The system according to claim 1, wherein, One of the multiple display views is a case type view that includes one or more case type display sections customized for the type of case associated with the medical event.

68. The system according to claim 67, wherein, The case type view is one of a plurality of case type views, wherein each of the plurality of case type views can be selected for viewing via corresponding user input at the device interface.

69. The system according to claim 68, wherein, The multiple case type views include two or more of the following: basic monitoring case type view, advanced monitoring case type view, cardiac arrest case type view, traumatic brain injury case type view (TBI) case type view, respiratory distress case type view, and critical care monitoring case type view.

70. The system according to claim 1, wherein, The medical treatment device also includes: At least one caregiver performance sensor input is configured to generate caregiver performance signals associated with a corresponding caregiver role among a plurality of caregiver roles during the medical event. The at least one first processor is further configured to: Receive and process the caregiver's performance signals, and Generate caregiver performance data based on processed caregiver performance signals, and The case information also includes caregiver performance information visually drawn based on the generated caregiver performance data.

71. The system according to claim 70, wherein, The at least one caregiver performance sensor input includes at least one CPR sensor input, and wherein the caregiver case information includes CPR case information derived from the at least one CPR sensor input.

72. The system according to claim 71, wherein, The at least one CPR sensor input includes a chest compression sensor input, and wherein the CPR case information includes chest compression information.

73. The system according to claim 72, wherein, The chest compression sensor input is a motion sensor input.

74. The system according to claim 72, wherein, Chest compression case information includes chest compression feedback during the medical event, wherein the chest compression feedback includes at least one of compression depth feedback, compression rate feedback, and release rate feedback.

75. The system according to claim 71, wherein, The at least one first processor is configured to: The compression rate of the compressions delivered to the patient is detected from the processed chest compression sensor input; and The delivery of positive pressure ventilation to the patient is synchronized with the delivered compressions based on the detected compression rate.

76. The system according to claim 75, wherein, The at least one second processor is configured to display a synchronized visual depiction of the delivered positive pressure ventilation and the delivered compressions.

77. The system according to claim 1, wherein, The medical treatment device is one of a plurality of medical treatment devices that are coupled to the supporting device via network communication.

78. The system according to claim 77, wherein, The plurality of medical treatment devices include a defibrillator, the defibrillator comprising: High-voltage capacitors, configured to store and release charge to provide electrotherapy to patients, and An electrode output is configured to be electrically coupled to the high-voltage capacitor and to transfer at least a portion of the charge from the high-voltage capacitor to the patient.

79. The system according to claim 1, wherein, The medical treatment device includes a defibrillator, the defibrillator comprising: High-voltage capacitors, configured to store and release charge to provide electrotherapy to patients, and An electrode output is configured to be electrically coupled to the high-voltage capacitor and to transfer at least a portion of the charge from the high-voltage capacitor to the patient.

80. The system according to claim 79, wherein, The one or more instruction signals include one or more control signals used by the defibrillator to administer the electrical therapy to the patient.

81. The system according to claim 1, wherein, Providing a visual reproduction of the first display format in the second display format includes: providing a copy of the first display format.

82. The system according to claim 1, wherein, Providing a visual reproduction of the first display format in the second display format includes: adjusting one or more visual aspects of the case information presented in the second display format based on the case information displayed in the first display format.

83. The system according to claim 82, wherein, The one or more visual aspects include one or more of the layout, color, font, magnification, resolution, size, and image position of the case information.

84. The system according to claim 1, wherein, Providing a visual representation of the first display format in the second display format includes adding or subtracting one or more items of the case information displayed in the second display format based on the case information displayed in the first display format.

85. The system according to claim 1, wherein, The communication link is a wireless communication link.

86. The system according to claim 85, wherein, The wireless communication link is at least one of a Wi-Fi link and a Bluetooth link.

87. The system according to claim 85, wherein, The wireless communication link is a pre-configured pairing between the medical treatment device and the supporting device.

88. The system according to claim 87, wherein, The at least one first processor is further configured to: The wireless communication signal associated with the pre-configured pairing for the accompanying device is detected via the wireless communication link, and In response to the detection of the wireless communication signal, the device is connected to the accessory device via the wireless communication link.

89. The system according to claim 88, wherein, Transmitting the generated medical data to the supporting device includes: automatically initiating the transmission of the generated medical data when connected to the supporting device.

90. The system according to claim 88, wherein, The at least one first processor is further configured to detect, based on the loss of the wireless communication signal, the disconnection of the auxiliary device from the medical treatment device, and In response to the detection of the disconnection, the transmission of generated medical data to the accompanying device is stopped.

91. The system according to claim 87, wherein, The at least one second processor is configured to: The proximity of the medical treatment device is detected via the wireless communication link, and The device is connected to the medical treatment device via the pre-configured pairing for proximity-based connection.

92. The system according to claim 1, wherein, The at least one second processor is further configured to display a verification input at the device interface, which, when actuated, causes the connected medical treatment device to generate a pairing indication between the companion device and the medical treatment device.

93. The system according to claim 92, wherein, The at least one second processor is also configured to transmit an instruction signal to the medical treatment device in response to the detection of the verification input at the device interface, for generating an indication of pairing between the companion device and the medical treatment device.

94. The system according to claim 92, wherein, The paired indication at the medical treatment device is at least one of a visual indication and an audio indication.

95. The system according to claim 94, wherein, The visual indicator is a flashing light.

96. The system according to claim 94, wherein, The audio indicator is a tone-controlled sound pulse.

97. The system according to claim 1, wherein, The accessory device is one of a plurality of accessories that can be connected to the medical treatment device.

98. The system according to claim 97, wherein, The at least one first processor is also configured to simultaneously transmit at least a portion of the generated medical data to each of the plurality of supporting devices for display at a corresponding device interface of each of the plurality of supporting devices.

99. The system according to claim 1, wherein, The display screen of the device interface is a touchscreen used to receive user input corresponding to the generated input signals.

100. The system according to claim 1, wherein, The physiological information includes ECG waveform, pulse oximetry waveform, invasive blood pressure (IBP) and / or CO2 waveform.

101. The system according to claim 1, wherein, The information includes the current value of at least one of the following: peripheral capillary oxygen saturation (SpO2), carbon monoxide saturation (SpCO), methemoglobin (SpMet), total hemoglobin (SpHB), blood oxygen content (SpOC), pulse perfusion variability index (PVI), perfusion index (PI), end-tidal carbon dioxide (EtCO2), non-invasive blood pressure, invasive blood pressure, heart rate (HR), respiratory rate, fractional oxygen inhalation (FiO2), and body temperature.

102. The system according to claim 1, wherein, The at least one user input includes an input for providing the one or more instruction signals to the medical treatment device.

103. The system according to claim 102, wherein, Transmitting one or more command signals to the medical treatment device includes: In response to detecting a selection of one of the at least one user inputs, an instruction signal is transmitted from one or more instruction signals to update at least one of the patient information, treatment information, and diagnostic information of the medical event.

104. The system according to claim 102, wherein, The at least one user input includes patient information input.

105. The system according to claim 104, wherein, The at least one second processor is further configured to display a patient information input interface at the device interface in response to detecting a user input signal associated with the patient information input.

106. The system according to claim 105, wherein, The patient information input interface includes multiple patient information input fields for entering patient background information.

107. The system according to claim 106, wherein, The multiple patient information input fields include at least one of the following: patient age input field, patient gender input field, patient name input field, patient weight input field, patient height input field, and patient identification input field.

108. The system according to claim 106, wherein, The multiple patient information input fields include a case identification input field.

109. The system according to claim 106, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting the submitted patient information to the medical treatment device when submitting patient information at a portion of the plurality of patient information input fields.

110. The system according to claim 109, wherein, The at least one first processor is further configured to link the submitted patient information with the patient's medical records in response to receiving the submitted portion of the patient information.

111. The system according to claim 110, wherein, The at least one first processor is also configured to transmit a link confirmation signal to the accessory device in response to linking the submitted patient information with the patient's medical record information.

112. The system according to claim 111, wherein, The at least one second processor is further configured to, in response to receiving the link confirmation signal from the medical treatment device, display a patient information transmission confirmation message at the device interface.

113. The system according to claim 109, wherein, The at least one first processor is further configured to, in response to receiving the submitted patient information, store the submitted patient information together with the case information in the data storage area of ​​the medical treatment device.

114. The system according to claim 113, wherein, The at least one first processor is also configured to transmit a storage confirmation signal to the accessory device in response to storing the submitted patient information together with the patient's medical record information.

115. The system according to claim 114, wherein, The at least one second processor is further configured to, in response to receiving the stored confirmation signal from the medical treatment device, display a patient information transmission confirmation message at the device interface.

116. The system according to claim 106, wherein, The device interface includes at least one sensor configured to scan patient information from documents, and The at least one second processor is further configured to automatically populate each input field of the plurality of patient information input fields with the scanned patient information.

117. The system according to claim 116, wherein, The at least one sensor is a camera.

118. The system according to claim 116, wherein, The document in question is a government-issued identification card.

119. The system according to claim 102, wherein, The at least one user input includes an event tag input.

120. The system according to claim 119, wherein, The at least one second processor is further configured to display an event marker input interface at the device interface in response to detecting a user input signal associated with the event marker input.

121. The system according to claim 120, wherein, The event tagging input interface includes multiple event tagging selectors for tagging patient treatment events at the medical treatment device.

122. The system according to claim 121, wherein, The multiple event tag selections include multiple disposal tag selections.

123. The system according to claim 122, wherein, The multiple treatment marker selections include at least one of medication, oxygen, and recovery of spontaneous circulation (ROSC).

124. The system according to claim 122, wherein, The multiple disposal label selections include a customizable disposal label selection for manually entering disposal names.

125. The system according to claim 121, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting an event marker instruction signal for recording the one or more event marker selections to the medical treatment device when submitting one or more of the plurality of event marker selections.

126. The system according to claim 125, wherein, The at least one first processor is further configured to, in response to receiving the event marker instruction signal, select and record one or more event markers in the data storage area of ​​the medical treatment device.

127. The system according to claim 126, wherein, The at least one first processor is also configured to transmit an in-progress event marker recording confirmation signal to the accompanying device in response to the start of recording of one or more event marker selections.

128. The system according to claim 127, wherein, The at least one second processor is further configured to display an in-process event marker record confirmation message at the device interface in response to receiving the in-process event marker record confirmation signal from the medical treatment device.

129. The system according to claim 126, wherein, The at least one first processor is further configured to transmit an event marker recording completion confirmation signal to the accompanying device in response to the recording completion of one or more event marker selections.

130. The system according to claim 129, wherein, The at least one second processor is further configured to display an event tagging completion confirmation message at the device interface in response to receiving the event tagging completion confirmation signal from the medical treatment device.

131. The system according to claim 121, wherein, The device interface includes at least one audio sensor configured to receive audio input from one or more of the plurality of event flag selections. The transmission of one or more instruction signals from the at least one second processor to the medical treatment device includes: transmitting an event marker instruction signal for recording the selection of one or more event markers to the medical treatment device when the audio input is received.

132. The system according to claim 131, wherein, The at least one audio sensor includes a microphone.

133. The system according to claim 102, wherein, The at least one user input includes a 12-lead ECG analysis input.

134. The system according to claim 133, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting the selection of the 12-lead ECG analysis input, transmitting a 12-lead ECG analysis instruction signal for initiating a 12-lead ECG analysis at the medical treatment device.

135. The system according to claim 134, wherein, The at least one first processor is also configured to perform a 12-lead ECG analysis at the medical treatment device in response to receiving the 12-lead ECG analysis command signal.

136. The system according to claim 135, wherein, The at least one first processor is also configured to transmit a confirmation signal of the ongoing 12-lead ECG analysis to the accompanying device in response to the start of the 12-lead ECG analysis.

137. The system according to claim 136, wherein, The at least one second processor is further configured to display a 12-lead ECG analysis confirmation message at the device interface in response to receiving the in-process 12-lead ECG analysis confirmation signal from the medical treatment device.

138. The system according to claim 135, wherein, The at least one first processor is also configured to transmit a 12-lead ECG analysis completion confirmation signal to the accompanying device in response to the completion of the 12-lead ECG analysis.

139. The system according to claim 138, wherein, The at least one second processor is further configured to display a 12-lead ECG analysis completion confirmation message at the device interface in response to receiving the 12-lead ECG analysis completion confirmation signal from the medical treatment device.

140. The system according to claim 133, wherein, The 12-lead ECG analysis input provides user selections for previously performed 12-lead ECG analyses, which can be viewed at the device interface of the accompanying device.

141. The system according to claim 140, wherein, The at least one second processor is also configured to, in response to detecting a selection for viewing of a previously performed 12-lead ECG analysis, issue a command signal to the medical treatment device to obtain 12-lead ECG analysis data associated with the previously performed 12-lead ECG analysis.

142. The system according to claim 141, wherein, The at least one second processor is also configured to, in response to receiving the 12-lead ECG analysis data from the medical treatment device, display the 12-lead ECG analysis data of a previously performed ECG at the device interface of a customized accessory device.

143. The system according to claim 102, wherein, The at least one user input includes a defibrillator snapshot input.

144. The system according to claim 143, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting a selection of a snapshot input for the medical treatment device, transmitting a snapshot instruction signal for initiating the capture of a snapshot of the medical treatment device screen.

145. The system according to claim 144, wherein, The at least one first processor is further configured to capture a snapshot of the medical treatment device image in response to receiving the snapshot instruction signal.

146. The system according to claim 145, wherein, The at least one first processor is also configured to transmit a snapshot confirmation signal to the accompanying device in response to capturing a snapshot of the medical treatment device image.

147. The system according to claim 146, wherein, The at least one second processor is further configured to display a snapshot confirmation message at the device interface in response to receiving the in-process snapshot confirmation signal from the medical treatment device.

148. The system according to claim 145, wherein, The at least one first processor is also configured to transmit a snapshot completion confirmation signal to the accessory device in response to the completion of snapshot capture of the medical treatment device screen.

149. The system according to claim 148, wherein, The at least one second processor is further configured to display a snapshot completion confirmation message at the device interface in response to receiving the snapshot completion confirmation signal from the medical treatment device.

150. The system according to claim 102, wherein, The at least one user input includes a case event summary input.

151. The system according to claim 150, wherein, The at least one second processor is also configured to display an event summary interface at the device interface in response to detecting a selection of the case event summary input.

152. The system according to claim 151, wherein, The event aggregation interface includes a chronological list of events associated with patient care recorded at the medical treatment device.

153. The system according to claim 151, wherein, The at least one second processor is also configured to obtain a chronological list of events from the medical treatment device in response to detecting a selection of the case event summary input.

154. The system according to claim 152, wherein, The at least one second processor is also configured to, in response to selecting an event from the chronological list of events at the event aggregation interface, display details associated with the selected event.

155. The system according to claim 154, wherein, The details displayed for the selected event include a snapshot of the medical treatment device screen at the time associated with the selected event.

156. The system according to claim 102, wherein, The at least one user input includes an alarm summary input.

157. The system according to claim 156, wherein, The at least one second processor is also configured to display an alarm interface at the device interface in response to the detection of the selection of the alarm summary input.

158. The system according to claim 157, wherein, The alarm interface includes a list of events triggered by one or more alarms at the medical treatment device.

159. The system according to claim 158, wherein, The events triggered by the alarms include physiological alarm events and technical alarm events.

160. The system according to claim 159, wherein, The physiological alarm events include threshold limits associated with at least one physiological sensor.

161. The system according to claim 159, wherein, The technical alert events include technical problems associated with the medical treatment device.

162. The system according to claim 102, wherein, The at least one user input includes a non-invasive blood pressure initiation input, i.e., an NIBP initiation input.

163. The system according to claim 162, wherein, Transmitting one or more instruction signals from the at least one second processor to the medical treatment device includes: in response to detecting the selection of the NIBP initiation input, transmitting an NIBP instruction signal for initiating an NIBP measurement at the medical treatment device.

164. The system of claim 1, further comprising one or more additional physiological sensor inputs communicatively coupled to the accompanying device. in, The one or more additional physiological sensor inputs are configured to generate one or more additional physiological signals corresponding to the patient during the medical event.

165. The system according to claim 164, wherein, The at least one second processor is further configured to: Receive and process one or more additional physiological signals corresponding to the patient. Additional medical data is generated based on one or more processed additional physiological signals, and Additional medical information is displayed at the device interface, including additional physiological information visually drawn based on the generated additional medical data.

166. The system according to claim 165, wherein, The at least one second processor is further configured to: The additional case information is transmitted to the medical treatment device for display on the device's screen.

167. The system according to claim 164, wherein, The one or more additional physiological sensor inputs include at least one of a continuous NIBP sensor, an ultrasound imaging sensor, and a laryngoscopy sensor.

168. The system according to claim 1, wherein, The at least one second processor is further configured to: The amount of electrical shock energy to be provided by the medical treatment device is received from the medical treatment device; and This allows the amount of electrical shock energy to be provided by the medical treatment device to be displayed at the device interface.

169. The system according to claim 1, wherein, The at least one second processor is further configured to: Receive from the medical treatment device the number of electric shocks applied to the patient by the medical treatment device; and The number of electric shocks applied to the patient by the medical treatment device is displayed at the device interface.

170. The system according to claim 1, wherein, The device view displayed at the device interface is one of a plurality of views that can be displayed at the device interface of the accompanying device, and The at least one second processor is also configured to display a portion of the plurality of views at the device interface.

171. The system according to claim 170, wherein, Multiple views available for display at the device interface include a trend view that presents trend data based on medical data generated in association with patient care during the medical event.

172. The system according to claim 171, wherein, The trend data includes physiological values ​​over time from the input of the at least one physiological sensor.

173. The system according to claim 172, wherein, The trend data includes at least one of SpO2, EtCO2, systolic blood pressure, diastolic blood pressure, mean arterial pressure, and heart rate values ​​over time.

174. The system according to claim 171, wherein, The trend view includes a graphical display of a portion of the trend data.

175. The system according to claim 171, wherein, The trend view includes a display of a portion of the trend data in tabular format.

176. The system according to claim 1, wherein, The at least one second processor is configured to: This allows multiple data display views to be displayed at the device interface. Each of the multiple display views can be selected via a corresponding display view selection unit of the device interface, and The plurality of display views include: The real-time device view of the case information, including the physiological information, displayed on the medical treatment device screen, and A working view that includes one or more custom display sections.

177. The system according to claim 1, wherein, The medical treatment device also includes: At least one caregiver performance sensor input is configured to generate caregiver performance signals associated with a corresponding caregiver role among a plurality of caregiver roles during the medical event. The at least one first processor is further configured to: Receive and process the caregiver's performance signals, and Generate caregiver performance data based on processed caregiver performance signals, and The case information also includes caregiver performance information visually drawn based on the generated caregiver performance data.

178. The system according to claim 177, wherein, The appropriate caregiver is performing chest compressions on the patient during the medical event.

179. The system according to claim 177, wherein, The at least one caregiver performance sensor input includes a chest compression sensor input, and wherein the caregiver performance information includes chest compression information.

180. The system according to claim 179, wherein, The chest compression sensor input is a motion sensor input.

181. The system according to claim 179, wherein, The chest compression information includes chest compression feedback during the medical event, wherein the chest compression feedback includes at least one of compression depth feedback, compression rate feedback, and release speed feedback.

182. The system according to claim 181, wherein, The compression depth feedback includes a visual indication of the corresponding depth of each chest compression applied to the patient.

183. The system according to claim 182, wherein, The visual indication of the corresponding depth of each chest compression applied to the patient is displayed relative to the target range of chest compression depth.

184. The system according to claim 179, wherein, The chest compression information includes a summary of chest compression performance during the medical event.

185. The system according to claim 184, wherein, The summary of chest compression performance includes at least one of the following: average compression depth, average compression rate, average release rate, pre-shock pause, post-shock pause, and percentage of compressions within the target compression depth range.

186. The system according to claim 184, wherein, The at least one second processor is configured to display a summary of the chest compression performance in real time in the working view during the medical event.

187. The system according to claim 184, wherein, The at least one second processor is configured to display a summary of the chest compression performance in the working view when the medical event is completed.

188. The system according to claim 177, wherein, The at least one caregiver performance sensor input includes at least one ventilation sensor input, and wherein the caregiver performance information includes ventilation case information derived from the at least one ventilation sensor input.

189. The system according to claim 188, wherein, The at least one ventilation sensor input includes an airflow sensor input.

190. The system according to claim 188, wherein, The ventilation case information includes ventilation feedback during the medical event, wherein the ventilation feedback includes at least one of tidal volume, ventilation rate, and minute volume.

191. The system according to claim 188, wherein, The corresponding caregiver is providing ventilation to the patient during the medical event.

192. The system according to claim 188, wherein, One or more customized display sections of the working view include a ventilation performance data section that displays the ventilation case information.

193. The system according to claim 188, wherein, The ventilation case information includes a summary of ventilation performance during the medical event.

194. The system according to claim 193, wherein, The summary of ventilation performance includes a display of at least one of the following: average tidal volume, average ventilation rate, average minute volume, and percentage of ventilation within the target volume range or target rate range.

195. The system according to claim 193, wherein, The at least one second processor is configured to display a summary of the ventilation performance in the working view in real time during the medical event.

196. The system according to claim 193, wherein, The at least one second processor is configured to display a summary of the ventilation performance in the working view when the medical event is completed.

197. The system according to claim 123, wherein, The drug is an anticoagulant.

198. A signal processing method, the method comprising: Using at least one first processor of the medical treatment device, a patient-corresponding physiological signal generated by at least one physiological sensor input communicatively coupled to the medical treatment device is received and processed. Using the at least one first processor, medical data is generated based on the processed physiological signals; Using the at least one first processor, case information is displayed on a medical treatment device screen in a first display format, the case information including physiological information visually drawn based on generated medical data; Using the at least one first processor, the case information and the generated medical data are transmitted to an auxiliary device communicatively coupled to the medical treatment device, the auxiliary device comprising: The device interface includes a display screen configured to allow a user to input one or more commands for the medical treatment device during a medical event. At least one second processor capable of being operatively interface-coupled with the device; The at least one second processor is used to process the case information received from the medical treatment device and the generated medical data; Using the at least one second processor, a real-time device view of the medical treatment device screen, including the physiological information, is displayed at the device interface in a second display format, wherein the second display format provides a visual reproduction of the first display format, and Using the at least one second processor, a plurality of display views are displayed at the device interface, each of the plurality of display views being selectable via a corresponding display view selection unit of the device interface, wherein the plurality of display views includes: A real-time device view of case information, including physiological information stored in the memory of the medical treatment device; and A working view that includes one or more custom display sections.

199. The method according to claim 198, further comprising: Using the at least one first processor, wireless communication signals associated with a pre-configured pairing for the accompanying device are detected via a wireless communication link; as well as Using the at least one first processor, in response to detecting the wireless communication signal, it connects to the accompanying device via the wireless communication link.

200. The method of claim 199, wherein, Transmitting the generated medical data to the supporting device includes: automatically initiating the transmission of the generated medical data when connected to the supporting device.

201. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method according to any one of claims 198-200.

Images