Wearable medical system with programmable device parameters and patient information via a browser interface - Patent Application 20070122997

Abstract

To provide improved devices and methods for interfacing with a wearable monitoring device (WMD) using a companion device.SOLUTION: A wearable monitoring device system includes a WMD, including a support structure 170 and a plurality of electrodes 104, 108. A WMD data store includes parameter data that defines settings of the WMD, an interpreted code that provides access to the parameter data, and a web server configured to serve the interpreted code. The system includes a companion device 199 communicatively coupled to the WMD, including: a display; a companion communication module configured to communicatively couple the companion device and the WMD; and a companion data store. The companion data store includes a browser configured to render the interpreted code. A companion processor is included, configured to execute the browser.SELECTED DRAWING: Figure 1

Description

[Background technology]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of U.S. Provisional Patent Application No. 63 / 347,463, filed May 31, 2022, and U.S. Patent Application No. 18 / 063,457, filed December 8, 2022, the entire disclosures of which are incorporated herein by reference in their entireties for all purposes. Summary of the Invention

[0002] Disclosure Overview and Background When a person suffers from some types of cardiac arrhythmia, the result can be reduced blood flow to various parts of the body. Some arrhythmias can even lead to sudden cardiac arrest (SCA). SCA, unless treated, can be fatal very quickly, for example, within 10 minutes. Some observers mistake SCA for a heart attack, but this is not the case.

[0003] Some people are at increased risk for SCA. These include patients who have had a heart attack or a previous episode of SCA. A frequent recommendation for these people is to receive an implantable cardioverter-defibrillator (ICD). An ICD is surgically implanted in the chest and continuously monitors the patient's electrical activity. If certain cardiac arrhythmias are detected, the ICD delivers an electrical shock directly to the heart in an attempt to correct the arrhythmia.

[0004] As an additional precaution, people identified as being at high risk for SCA are sometimes given a wearable cardioverter-defibrillator (WCD) system to wear until an ICD is implanted or until their cardiac condition no longer poses a high risk for SCA. WCD systems typically include a support structure, such as a harness, vest, belt, or other garment worn by the patient. WCD systems also include electronic components, such as a defibrillator and electrodes, coupled to the support structure. When a patient wears the WCD system, the electrodes make electrical contact with the patient's skin and can thus help sense the patient's electrocardiogram (ECG). If a shockable cardiac arrhythmia (e.g., ventricular fibrillation (VF) or ventricular tachycardia (VT)) is detected from the ECG, the defibrillator delivers an appropriate electrical shock through the patient's body and, therefore, through the patient's heart. The delivered shock can restart the patient's heart and thus save the patient's life. While the term WCD is used throughout this specification, it should be understood that a WCD may also be a wearable monitoring device (WMD), which is a wearable device without the ability to deliver a shock to the patient. Unless otherwise specified, it should be understood that where the term "WCD" is used, this may also be a WMD, and vice versa.

[0005] In some cases, the user interface for changing and viewing parameters and patient information on a WCD is provided by an external companion device, such as a tablet or laptop computer with a dedicated application. This application is a special-purpose application that is compatible with the WCD and its programming when the communication interface changes, such as when new features are added to the WCD. Compatibility issues currently require both a compatible version of the application and a tablet capable of running a compatible version of the application for the WCD to which it is connected. Furthermore, custom applications must be developed for each version of the WCD and multiple potential companion devices. If a user does not have the latest application release, they may not be able to program the WCD until they upgrade the application, which may also include updating the tablet.

[0006] Thus, improved devices and methods for interfacing with a WMD using a companion device (such as a tablet) have not heretofore been known to those skilled in the art.

[0007] The wearable monitoring device system includes a wearable medical monitoring device (WMMD) including a support structure, a plurality of electrodes, a WMMD communication module, and a WMMD data store. The WMMD data store includes parameter data defining a configuration of the WMMD, interpreted code providing access to the parameter data, and a web server configured to provide the interpreted code. The WMMD includes a WMMD processor configured to execute the web server, the web server operative to transmit the interpreted code via the WMMD communication module and modify the parameter data based on input received by the web server via the WMMD communication module. The system includes a companion device communicatively coupled to the WMMD including a display, a companion communication module configured to communicatively couple the companion device and the WMMD, and a companion data store in which components reside. The companion data store includes a browser configured to render the interpreted code, the interpreted code defining a user interface enabling modification of the parameter data, and the user interface operative to receive input from a user of the companion device. A companion processor configured to execute a browser is included, the browser operative to receive the interpreted code via the companion communication module, render a user interface on a display, receive input from a user, and return input to the WMMD communication module via the companion communication module.

[0008] In another aspect, a wearable defibrillator system includes a wearable cardioverter-defibrillator (WCD). The WCD includes a support structure configured to be worn by a patient, a plurality of electrodes coupled to or integrated with the support structure, an energy storage module configured to store an electrical charge, a discharge circuit configured to be coupled to the energy storage module and configured to use the electrical charge stored in the plurality of electrodes and the energy storage module to deliver one or more shocks to the patient while the support structure is worn by the patient, and a WCD communication module. The WCD further includes a data store in which components reside. The components include parameter data defining settings for the WCD, interpreted code providing access to the parameter data, and a web server configured to provide the interpreted code. A user interface is implemented by the interpreted code, the WCD communication module, and a WCD processor. The WCD further includes a WCD processor configured to transmit the interpreted code from the web server via the WCD communication module and to modify the parameter data based on input received via the WCD communication module. The WCD system further includes a companion device communicatively coupled to the WCD. The companion device includes a display and a companion communications module configured to communicatively couple the companion device and the WCD. The companion device further includes a browser component configured to render the interpreted code and receive input from a user of the companion device, and a companion processor. The companion processor is configured to receive the interpreted code via the companion communications module, present the interpreted code to the browser component, receive input from the browser, and return input to the WCD communications module via the companion communications module. When the web server sends the interpreted code to the companion device, the browser component renders the interpreted code on the companion device's display, and user input received by the browser component is returned to the WCD through the WCD communications module and the companion communications module.

[0009] None of the subject matter discussed in this section is necessarily prior art, and need not be assumed to be prior art merely because it is presented in this section. Any reference to any prior art herein is not, and should not be construed as, an admission or any form of suggestion that such prior art forms part of the common general knowledge in any art in any country. Along these lines, recognition of problems in the prior art discussed in this section or related to such subject matter should not be treated as prior art unless expressly stated to be prior art. Rather, the discussion of any subject matter in this section should be treated as part of an approach taken toward solving the particular problem identified. This approach may itself be inventive.

[0010] The Summary provided above is intended to introduce in a simplified form a selection of concepts that are further described below in the Detailed Description. This Summary is not intended to identify key features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [Brief explanation of the drawings]

[0011] [Figure 1] 1 is a conceptual diagram of a patient wearing an exemplary WCD constructed in accordance with an embodiment. [Figure 2] 1 is a conceptual diagram of a sample embodiment of components of a WCD system constructed in accordance with the present disclosure. [Figure 3] FIG. 1 is a functional diagram illustrating components of an exemplary external defibrillator made in accordance with an embodiment. [Figure 4] FIG. 1 is a functional diagram illustrating components of an exemplary ambulatory medical device made in accordance with an embodiment. [Figure 5] FIG. 1 is a conceptual diagram generally illustrating a health monitoring environment, according to an embodiment. [Figure 6]FIG. 1 is a conceptual diagram of a security certificate (also referred to as a digital certificate) that may be used in various embodiments of the present disclosure. [Figure 7] FIG. 1 is a functional flow diagram generally illustrating a process for creating a security certificate in accordance with the present disclosure. [Figure 8] 1 illustrates a process for using security certificates within a WCD system to ensure trusted communication and appropriate access between components of the WCD system according to the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0012] The present disclosure is directed to a system and method for exposing a configuration interface of a WMD to a companion device without a special purpose application on the companion device.

[0013] While exemplary embodiments have been illustrated and described, it will be understood that various changes can be made without departing from the spirit and scope of the disclosure.

[0014] Referring now to the drawings, FIG. 1 illustrates a wearable cardioverter-defibrillator (WCD) system being worn by a patient 182, according to an embodiment of the present disclosure. The WCD described herein is presented as an example of a wearable monitoring device (WMD) that measures and captures cardiac data (e.g., ECG tracing data) of a patient wearing the WCD system. In one example, the WMD is a wearable medical monitoring device (WMMD). A WMMD should be understood to be a medical monitoring device approved by a federal agency, such as the U.S. Food and Drug Administration, for use in medical applications.

[0015] Patient 182 may also be referred to as a person and / or wearer because the patient is wearing the components of the WCD system. As shown, patient 182 is ambulatory, meaning that under normal circumstances, patient 182 is able to walk around while wearing the wearable portion of the WCD system and is not necessarily bedridden. Patient 182 may also be considered a "user" of the WCD system, although this is not a requirement. For example, a user of a wearable automatic cardioverter-defibrillator (WCD) may be a doctor, nurse, emergency medical technician (EMT), or other similarly tasked individual or group of individuals. In some cases, the user may even be a bystander or manufacturer of the WCD. The specific context of these and other related terms within this description should be interpreted accordingly.

[0016] A WCD system according to embodiments can be configured to defibrillate a patient wearing designated components of the WCD system. Defibrillation can be performed by the WCD system delivering an electrical charge to the patient's body in the form of an electric shock. The electric shock can be delivered in one or more pulses and / or can be delivered again if the WCD continues to detect a shockable rhythm. In alternative embodiments implemented as a WCD, the WCD system can, for example, monitor the patient's cardiac output but does not deliver an electric shock to the patient's body.

[0017] FIG. 1 also illustrates components of a WCD system constructed in accordance with an embodiment. One such component is a support structure 170 that is wearable by an ambulatory patient 182. As such, the support structure 170 is configured to be worn by the ambulatory patient 182 for at least several hours per day and for at least several days, or even several months. It will be understood that the support structure 170 is shown only generally in FIG. 1 and is partially conceptual in nature. FIG. 1 is provided merely to illustrate concepts related to the support structure 170 and should not be construed as limiting how the support structure 170 may be implemented or worn.

[0018] Support structure 170 can be implemented in many different ways. For example, it can be implemented as a single component or a combination of multiple components. In embodiments, support structure 170 can include a vest, a half vest, a garment, or the like. In such embodiments, such an item can be worn similarly to a similar article of clothing. In embodiments, support structure 170 can include a harness, one or more belts or straps, or the like. In such embodiments, such an item can be worn by the patient around the torso, hips, over the shoulders, or the like. In embodiments, support structure 170 can include a container or housing, which may be waterproof. In such embodiments, the support structure can be worn by being attached to the patient's body by an adhesive material, as shown and described in U.S. Patent No. 8,024,037, for example. Support structure 170 can also be implemented as described for support structures in U.S. Patent Application No. US2017 / 0056682, which is incorporated herein by reference. Of course, in such embodiments, one skilled in the art will recognize that additional components of the WCD system may be within the housing of the support structure instead of being mounted externally to the support structure, as described, for example, in U.S. Patent Application Publication No. 2017 / 0056682. Other examples are possible.

[0019] FIG. 1 illustrates a sample external defibrillator 100. As described in more detail later herein, some embodiments of the external defibrillator 100 include a housing and an energy storage module within the housing. Thus, in the context of a WCD system, the defibrillator 100 may also be referred to as a main electronics module. The energy storage module may be configured to store an electrical charge. Other components may discharge at least a portion of the stored electrical charge through the patient via the electrodes to deliver one or more defibrillation shocks through the patient.

[0020] 1 also shows sample defibrillation electrodes 104, 108 coupled to an external defibrillator 100 via electrode leads 105. The defibrillation electrodes 104, 108 can be configured to be worn by a patient 182 in several ways. For example, the defibrillator 100 and the defibrillation electrodes 104, 108 can be directly or indirectly coupled to a support structure 170. In other words, the support structure 170 can be configured to be worn by an ambulatory patient 182 to maintain at least one of the electrodes 104, 108 on the body of the ambulatory patient 182, such as while the patient 182 moves around. Thus, the electrodes can be maintained on the body by being attached to the patient's 182's skin, by simply being pressed against the skin directly or through clothing, or the like. In some embodiments, the electrodes are not necessarily pressed against the skin, but are biased in this manner upon sensing a condition that may merit intervention by the WCD system. Additionally, many of the components of the defibrillator 100 can be considered to be coupled to the support structure 170 directly or indirectly through at least one of the defibrillation electrodes 104, 108.

[0021] Once the defibrillation electrodes 104, 108 make good electrical contact with the body of the patient 182, the defibrillator 100 can deliver a brief, strong electrical pulse 111 through the body via the electrodes 104, 108. The pulse 111 is also known as a shock, defibrillation shock, therapy, electrical therapy, therapeutic shock, etc. The pulse 111 is intended to pass through the heart 185 to restart it in order to save the life of the patient 182. The pulse 111 can also include one or more pacing pulses of a smaller magnitude to simply pace the heart 185 as needed.

[0022] Defibrillators typically determine whether to defibrillate based on the patient's ECG signal, but external defibrillator 100 can initiate defibrillation or hold off defibrillation based on a variety of inputs, of which the ECG signal is simply one.

[0023] A WCD system according to an embodiment can acquire data from a patient 182. To collect such data, the WCD system can optionally include at least external monitoring equipment 180. Device 180 is referred to as an "external" device because it may be provided as a stand-alone device rather than, for example, within the housing of defibrillator 100. Device 180 can be configured to sense or monitor at least one local parameter. The local parameter can be a parameter of the patient 182, a parameter of the WCD system, or a parameter of the environment, as described later herein.

[0024] For some of these parameters, monitoring device 180 may include one or more sensors or transducers. Each such sensor may be configured to sense a parameter of patient 182 and render an input responsive to the sensed parameter. In some embodiments, the input is quantitative, such as the value of the sensed parameter, while in other embodiments, the input is qualitative, such as indicating whether a threshold has been exceeded. Sometimes, these inputs regarding patient 182 are also referred to herein as physiological inputs and patient inputs. In embodiments, sensor may be interpreted more broadly to encompass many individual sensors.

[0025] Optionally, monitoring device 180 is physically coupled to support structure 170. Additionally, monitoring device 180 may be communicatively coupled to other components coupled to support structure 170. Such communication may be effected by communication modules, as deemed applicable by those skilled in the art in view of this description.

[0026] In embodiments, one or more of the components of the illustrated WCD system may be customized for the patient 182. This customization may include several aspects. For example, the support structure 170 may be adapted to the body of the patient 182. In another example, baseline physiological parameters of the patient 182 may be measured, such as the patient's 182 heart rate at rest and while walking, or the motion detector output while walking. Because patients' bodies are different from one another, measurements of such baseline physiological parameters may be used to customize the WCD system and make its diagnosis more accurate. Of course, such parameter values ​​may be stored in the WCD system's memory, etc. Furthermore, according to embodiments, a programming interface may be created that receives such measurements of baseline physiological parameters. Such a programming interface may automatically input these, along with other data, into the WCD system.

[0027] The WCD system may further include a "companion" device 199. In various embodiments, the companion device 199 may be implemented as a mobile medical device that also includes various sensors for capturing patient and / or environmental parameters. For example, the companion device 199 may include motion detection sensors, accelerometers, gyroscope sensors, GPS location sensors, etc. In yet other embodiments, the companion device 199 may also include ECG monitoring components that interface directly with ECG electrodes. The companion device 199 further includes a user interface that allows the patient 182 to provide input to and receive output from the companion device 199.

[0028] In one embodiment, the companion device 199 communicates with either the external defibrillator 100, the external monitoring device 180 (if present), or both. Similarly, the companion device 199 can communicate wirelessly with remote computing systems over a local area network or a wide area network. For example, in various embodiments, the companion device 199 can be implemented as a special purpose mobile communications device or as a downloadable app that can be installed on a cellular smartphone or the like.

[0029] 2 is a conceptual diagram of components of an exemplary WCD system in which embodiments of the present disclosure can be implemented. As shown, support structure 270 includes a vest-like wearable garment. Support structure 270 has a back side 271 and a front side 272 that closes in front of the patient's chest.

[0030] The WCD system of Figure 2 also includes an external defibrillator 200. Figure 2 does not show a support for the external defibrillator 200, which may be carried in a purse, on a belt, by a strap over the shoulder, or the like. Wires 205 connect the external defibrillator 200 to electrodes 204, 208, and 209. Of these, electrodes 204 and 208 are defibrillation electrodes, and electrode 209 is an ECG sensing electrode. The electrodes shown on the front surface 272 of the support structure 270 are shown with dashed lines to indicate that they are within the support structure 270 so that they may contact the patient.

[0031] Support structure 270 is configured to be worn by an ambulatory patient to maintain electrodes 204, 208, 209 in contact with the patient's body. Back defibrillation electrode 208 may be maintained within a pocket in support structure 270. Of course, the inside of pocket 278 may be made of a conductive fabric so that electrode 208 can contact the patient's back, particularly with the aid of a conductive fluid that may be deployed. Additionally, sensing electrode 209 is maintained in a position surrounding the patient's torso to sense the patient's ECG signal and / or impedance.

[0032] Figure 3 illustrates certain components of an exemplary external defibrillator 300 constructed in accordance with an embodiment. These components may be included, for example, in external defibrillator 100 of Figure 1 and external defibrillator 200 of Figure 2. External defibrillator 300 is intended for a patient to wear, such as outpatient 182 of Figure 1. The components shown in Figure 3 are exemplary, and additional components not shown may, of course, be included.

[0033] The components shown in Figure 3 may be provided within an enclosure 301, which may also be referred to as a casing. The defibrillator 300 may further include a user interface 380 for a user 382. The user 382 may be a patient 182, also known as a wearer 182. Alternatively, the user 382 may be a local rescuer at the scene, such as a bystander or trained person who may provide assistance. Alternatively, the user 382 may be a trained caregiver at a remote location who communicates with the WCD system.

[0034] The user interface 380 can be created in several ways. The user interface 380 can include an output device, which can be visual, auditory, or tactile, to communicate to the user by outputting an image, sound, or vibration. Images, sounds, vibrations, and anything that can be perceived by the user 382 can also be referred to as a human-perceptible indication (HPI). There are many examples of output devices. For example, the output device can be a light or screen to display what has been sensed, detected, and / or measured, or can provide visual feedback for the rescuer 382 to attempt resuscitation. Another output device can be a speaker, which can be configured to emit audio prompts, beeps, loud alarms, and / or words to warn bystanders, etc.

[0035] The user interface 380 may further include an input device for receiving input from a user. Such input devices may include various controls such as push buttons, a keyboard, a touch screen, one or more microphones, etc. The input device may be a cancel switch, sometimes referred to as an "I'm alive" switch or an "alive person" switch. In some embodiments, activating the cancel switch may prevent the impending delivery of a shock.

[0036] Defibrillator 300 may include an internal monitoring device 381. Device 381 is referred to as an “internal” device because it is incorporated within housing 301. Monitoring device 381 may sense or monitor patient parameters, such as patient physiological parameters, system parameters, and / or environmental parameters, all of which may be referred to as patient data. In other words, internal monitoring device 381 may be complementary to or alternative to external monitoring device 180 of FIG. 1 . Assigning which parameters are monitored by which monitoring device 180, 381 can be made according to design considerations. Device 381 may include one or more sensors, as described elsewhere herein.

[0037] The patient parameters may include physiological parameters of the patient. The patient physiological parameters may include, for example, without limitation, any physiological parameters that may assist the WCD system in detecting whether the patient requires a shock or other intervention or assistance. The patient physiological parameters may also optionally include the patient's medical history, event history, etc. Examples of patient parameters include the patient's ECG, blood oxygen level, blood flow, blood pressure, blood perfusion, pulsatile changes in the optical transmission or reflectance properties of perfused tissue, heart sounds, cardiac wall motion, respiratory sounds, and pulse. Accordingly, the monitoring device 180, 381 may include one or more sensors (described below) configured to acquire physiological signals of the patient.

[0038] Patient status parameters include recorded aspects of the patient 382 (e.g., movement, posture, whether they have spoken recently, and possibly what they have said, etc.), plus optionally a history of these parameters. Alternatively, one of these monitoring devices may include a location sensor, such as a Global Positioning System (GPS) location sensor. Such a sensor can detect location, and velocity can be detected as the rate of change of location over time. Many detectors output motion signals that indicate movement of the detector and, therefore, movement of the patient's body. Patient status parameters can be very useful in narrowing down the determination of whether SCA is actually occurring.

[0039] In some embodiments, trends may be detected in monitored physiological parameters of the patient 382. Trends can be detected by comparing parameter values ​​at different times over short and long periods of time. Parameters for which detected trends may be particularly useful include: (a) cardiac function (e.g., ejection fraction, stroke volume, cardiac output, etc.); (b) heart rate variability at rest or during exercise; (c) heart rate profile and activity measurements during exercise, such as those reported from accelerometer signal profiles and adaptive rate pacemaker technology; (d) heart rate trends; (e) perfusion, e.g., SpO2, CO2, or other parameters, such as those described above; (f) respiratory function, respiration rate, etc.; and (g) exercise, activity level, etc. Once a trend is detected, it can be stored and / or reported via a communications link, possibly with a warning if warranted. From the report, a physician monitoring the patient's 382 progress will be informed of either a condition that is not improving or a condition that is worsening.

[0040] A WCD system constructed in accordance with embodiments may include a motion detector. In embodiments, the motion detector may be implemented within monitoring device 180 or monitoring device 381. Such a motion detector may be constructed in many ways known in the art, such as, for example, using an accelerometer. In this example, motion detector 387 is implemented within monitoring device 381. The motion detector of a WCD system according to embodiments may be configured to detect a motion event. A motion event may be conveniently defined, for example, as a change in motion from baseline motion or rest. In such cases, the sensed patient parameter is motion.

[0041] System parameters of a WCD system may include system identification, battery status, system date and time, self-test reports, records of entered data, records of episodes and interventions, etc. In response to a detected motion event, the motion detector may render or generate a motion detection input from the detected motion event or motion that may be received by a subsequent device or function.

[0042] Environmental parameters can include ambient temperature and pressure. Additionally, a humidity sensor can provide information regarding whether rain is likely. The estimated patient location can also be considered an environmental parameter. If the monitoring device 180 or 381 includes a GPS location sensor as described above, and if the patient is estimated to be wearing a WCD system, the patient's location can be estimated.

[0043] The defibrillator 300 typically includes a defibrillation port 310, which may be a socket within the housing 301. The defibrillation port 310 includes electrical nodes 314, 318. Leads of defibrillation electrodes 304, 308, such as lead 105 of FIG. 1, can be plugged into the defibrillation port 310 so as to be in electrical contact with nodes 314, 318, respectively. Alternatively, the defibrillation electrodes 304, 308 can be serially connected to the defibrillation port 310. In either case, the defibrillation port 310 can be used to transfer at least a portion of the electrical charge stored in an energy storage module 350, described more fully later herein, to the wearer via the electrodes. The electrical charge provides a shock for defibrillation, pacing, etc.

[0044] The defibrillator 300 may also optionally include a sensor port 319 within the housing 301. Typically, but not exclusively, the sensor port 319 may be implemented as an ECG port. The sensor port 319 may be adapted to accept sensing electrodes 309, which may include ECG electrodes and ECG leads. Alternatively, the sensing electrodes 309 may be serially connected to the sensor port 319. When implemented as ECG electrodes, the sensing electrodes 309 may be transducers that can help sense ECG signals, e.g., 12-lead signals, or signals from a different number of leads, particularly if they make good electrical contact with the patient's body, and particularly the patient's skin. Similar to the defibrillation electrodes 304, 308, a support structure can be configured to be worn by the patient 382 to maintain the sensing electrodes 309 on the patient's body. For example, the sensing electrodes 309, similar to the defibrillation electrodes 304, 308, can be attached to the inside of the support structure 170 to make good electrical contact with the patient.

[0045] Many alternative sensing electrodes 309 are also envisioned. For example, the sensing electrodes 309 may further include perfusion sensors, pulse oximeters, devices for detecting blood flow (e.g., Doppler devices), sensors for detecting blood pressure (e.g., cuffs), light sensors, light detectors, and possibly sensors cooperating with light sources to detect color changes in tissue, motion sensors, devices capable of detecting heart wall movement, sound sensors, devices with microphones, SpO2 sensors, etc. In light of the present disclosure, it will be understood that such sensors may serve to detect the patient's pulse and may therefore also be referred to as pulse detection sensors, pulse sensors, and pulse rate sensors.

[0046] In some embodiments, the defibrillator 300 also includes a measurement circuit 320 as one or more of its sensors or transducers in cooperation with the measurement circuit 320. The measurement circuit 320 senses one or more electrophysiological signals of the patient from the sensor port 319 (if provided). Even if the defibrillator 300 lacks the sensor port 319, the measurement circuit 320 can optionally acquire physiological signals instead via the nodes 314, 318 when the defibrillation electrodes 304, 308 are attached to the patient. In these cases, the input reflects an ECG measurement. The patient parameter can be an ECG, which can be sensed as a voltage difference between the electrodes 304, 308. Additionally, the patient parameter can be an impedance, which can be sensed between the electrodes 304, 308 and / or between the connections of the sensor port 319 that are considered to be a pair. Sensing impedance can be useful, among other things, to detect whether the electrodes 304, 308 and / or the sensing electrode 309 are not in good electrical contact with the patient's body. These patient physiological signals may be sensed when available. Measurement circuitry 320 may then render or generate information about them as inputs, data, other signals, etc., and thus measurement circuitry 320 may be configured to render patient inputs in response to patient parameters sensed by sensors. In some embodiments, measurement circuitry 320 may be configured to render patient inputs, such as values ​​of ECG signals, in response to ECG signals sensed by sensing electrodes 309. More specifically, although the information rendered by measurement circuitry 320 is an output therefrom, this information may be referred to as an input because it is received as an input by a subsequent device or function.

[0047] Defibrillator 300 also includes processor 330 (also referred to as WMD processor 330 or WCD processor 330). Processor 330 may be implemented in several ways in various embodiments, including, by way of example and not limitation, as a digital and / or analog processor such as a microprocessor and a digital signal processor (DSP), a controller such as a microcontroller, software running within a machine, a programmable circuit such as a field programmable gate array (FPGA), a field programmable analog array (FPAA), a programmable logic device (PLD), an application specific integrated circuit (ASIC), any combination of one or more of these, etc.

[0048] The processor 330 may include or have access to a non-transitory storage medium, such as memory 338, described more fully later herein. Such memory may have a non-volatile component for storage of machine-readable and machine-executable instructions. Such a collection of instructions may also be referred to as a program. The instructions, which may also be referred to as "software," generally provide functionality by performing acts, operations, and / or methods as disclosed herein or as would be understood by one of ordinary skill in the art in view of the disclosed embodiments. In some embodiments, and as a matter of convention used herein, an instance of software may be referred to by a "module" and other similar terms. Generally, a module includes a set of instructions to provide or implement a particular function. The embodiments of the modules and the functionality provided are not limited by the embodiments described herein.

[0049] The processor 330 can be considered to have several modules. One such module can be a detection module 332. The detection module 332 can include a ventricular fibrillation (VF) detector. A sensed ECG of the patient from the measurement circuit 320, which can be available as an input, data reflecting the value, or the value of another signal, can be used by the VF detector to determine whether the patient is experiencing VF. Detecting VF is useful because VF typically leads to SCA. The detection module 332 can also include a ventricular tachycardia (VT) detector, etc.

[0050] Another such module within processor 330 may be an advice module 334 that generates advice on what to do. The advice may be based on the output of detection module 332. There may be many types of advice according to embodiments. In some embodiments, the advice is a shock / no-shock decision that processor 330 may make, for example, via advice module 334. The shock / no-shock determination may be made by executing a stored shock advisory algorithm. The shock advisory algorithm may make the shock / no-shock determination from one or more captured ECG signals according to embodiments to determine whether shock criteria are met. This determination may be made from rhythm analysis of the captured ECG signals or other methods.

[0051] In some embodiments, if the determination is to shock, an electrical charge is delivered to the patient. Delivery of an electrical charge is also known as discharging and shocking the patient. As mentioned above, this may be for defibrillation, pacing, etc.

[0052] In an ideal situation, a highly reliable shock / non-shock decision can be made from a segment of a patient's detected ECG signal. However, in practice, ECG signals are often corrupted by electrical noise, making them difficult to analyze. Excessive noise can cause false detection of cardiac arrhythmias, resulting in a false alarm to the patient. Noisy ECG signals may be processed as described in U.S. Patent Application No. 16 / 037,990 (filed July 17, 2018, published as U.S. 2019 / 0030351 A1) and U.S. Patent Application No. 16 / 038,007 (filed July 17, 2018, published as U.S. 2019 / 0030352 A1), both of which are commonly assigned and incorporated herein by reference.

[0053] Processor 330 may include additional modules for other functions, such as other module 336. For example, one instance of other module 336 may be a web server as described below in connection with Figure 4. Additionally, if internal monitor 381 is actually provided, processor 330 may receive input therefrom, etc.

[0054] The defibrillator 300 optionally further includes memory 338 for use by the processor 330 in connection with executing several executable modules. The memory 338 may be implemented in several ways. Such ways include, by way of example and not limitation, volatile memory, nonvolatile memory (NVM), read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, smart cards, flash memory devices, any combination thereof, and the like. Thus, the memory 338 is a non-transitory storage medium. The memory 338, if provided, may contain a program for the processor 330, which may read and execute the program. More specifically, the program may include a set of instructions in the form of code that the processor 330 may execute when read. The program may also include other information that may be executed in accordance with the instructions, such as configuration data, profiles, scheduling, etc. Executing is performed by physical manipulation of physical quantities, resulting in functions, operations, processes, acts, actions, and / or methods to be performed and / or the processor causing other devices or components or blocks to perform such functions, operations, processes, acts, actions, and / or methods. The programs can be operable for the specific needs of the processor 330 and can also include protocols and methods by which decisions can be made by the advice module 334. Additionally, the memory 338 can store prompts for the user 382 if this user is a local rescuer. Furthermore, the memory 338 can store data. This data can include patient data, system data, and environmental data, for example, as learned by the internal monitoring device 381 and the external monitoring device 180. The data can be stored in the memory 338 before being transmitted from the defibrillator 300 or can be stored therein after being received by the defibrillator 300.

[0055] The defibrillator 300 may optionally include a communications module 390 for establishing one or more wired or wireless communications links with other devices of other entities, such as mobile companion devices, remote assistance centers, emergency medical services (EMS), etc. The communications links may be used to transfer data and instructions. The data may include patient data, event information, attempted treatments, CPR performance, system data, environmental data, etc. For example, the communications module 390 may wirelessly transmit heart rate, respiratory rate, and other vital sign data, e.g., daily, to a server accessible via the Internet, as described, for example, in U.S. Patent Publication No. 20140043149. This data may be analyzed directly by the patient's physician or automatically by algorithms designed to detect developing illnesses and then notify medical personnel via text, email, phone, etc. The communications module 390 may also include interconnected subcomponents, such as an antenna, portions of a processor, supporting electronics, outlets for telephone or network cables, etc., as may be deemed necessary by those skilled in the art.

[0056] Defibrillator 300 may also include a power source 340. To enable portability of defibrillator 300, power source 340 typically includes a battery. Such a battery is typically implemented as a battery pack, which may or may not be rechargeable. A combination of rechargeable and non-rechargeable battery packs may also be used. Other embodiments of power source 340 may include an AC power override for when AC power is available, an energy storage capacitor, etc. Appropriate components may be included to provide for charging or replacement of power source 340. In some embodiments, power source 340 is controlled and / or monitored by processor 330.

[0057] Defibrillator 300 may further include an energy storage module 350. Energy storage module 350 can be coupled to the support structure of the WCD system, for example, directly or via electrodes and their leads. Module 350 is a location where some electrical energy can be temporarily stored in the form of an electrical charge when preparing to discharge for a shock. In embodiments, module 350 can be charged to a desired amount of energy from power source 340 as controlled by processor 330. In a typical implementation, module 350 includes capacitor 352, which can be a single capacitor, a system of capacitors, or the like. In some embodiments, energy storage module 350 includes a device exhibiting high power density, such as an ultracapacitor. As described above, capacitor 352 can store energy in the form of an electrical charge for delivery to the patient.

[0058] A shock decision can be made in response to the shock criteria being met. If the decision is to deliver a shock, the processor 330 can be configured to discharge at least some or all of the charge stored in the module 350 through the patient 182 while the support structure is worn by the patient 182 to deliver the shock 111 to the patient 182. To cause the discharge, the defibrillator 300 further includes a discharge circuit 355. If the decision is to deliver a shock, the processor 330 can be configured to control the discharge circuit 355 to discharge at least some or all of the charge stored in the energy storage module 350 through the patient. The discharge is to nodes 314, 318 and from there to the defibrillation electrodes 304, 308 to deliver a shock to the patient. The circuit 355 can include one or more switches 357. The switch 357 can be constructed in a number of ways, such as an H-bridge. Accordingly, the circuit 355 can also be controlled via the processor 330 and / or the user interface 380. By controlling the discharge circuit 355 in this way, the time waveform of the discharge can be controlled. The amount of energy of the discharge can be controlled by how much the energy storage module is charged and also by how long the discharge circuit 355 is controlled to remain open.

[0059] Optionally, the WCD system according to the embodiment also includes a fluid that can be automatically deployed between the defibrillation electrodes and the patient's skin. The fluid can be conductive, such as by including an electrolyte, to establish better electrical contact between the electrodes and the skin. Electrically, as the fluid is deployed, the electrical impedance between each electrode and the skin decreases. Mechanically, the fluid can be in the form of a low-viscosity gel, so that after deployment, the fluid does not flow out from the location where it was released near the electrodes. The fluid can be used with the defibrillation electrodes 304, 308 and / or the sensing electrodes 309.

[0060] The fluid may be initially stored in a fluid reservoir, not shown in FIG. 3 . Such a fluid reservoir may be coupled to a support structure. Additionally, WCD systems according to embodiments further include a fluid deployment mechanism 374. The fluid deployment mechanism 374 may be configured to expel at least a portion of the fluid from the reservoir and deploy it near one or both of the patient locations where the electrodes 304, 308 are configured to be attached to the patient. In some embodiments, the fluid deployment mechanism 374 is activated prior to discharge in response to receiving an activation signal AS from the processor 330, which will be described more fully later herein.

[0061] FIG. 4 is a functional block diagram generally illustrating a wearable monitoring device (WMD) 401 used in implementations of the present disclosure. In some embodiments, WMD 401 may be implemented within or as part of an external defibrillator (e.g., external defibrillator 100, 200, or 300) of a WCD system. Alternatively, WMD 401 may be implemented within or as part of a standalone WMD (e.g., external to monitoring device 180). In another alternative, WMD 401 may be implemented within or as part of a mobile companion device (e.g., companion device 199). While shown as a single design in FIG. 4, it will be appreciated that one or more of the functional blocks illustrated in FIG. 4 may, in various embodiments, be implemented within one or more other devices that are incorporated together in a WCD system.

[0062] 4 is functionally depicted using a basic computing architecture including a processor 405 (also referred to as a WMD processor 405 or a WDC processor 405), a memory 410, and a bus 412 connecting the processor 405 to the memory 410. In various embodiments, the processor 405 may be implemented as any form of instruction processing unit, such as a central processing unit (CPU), a graphics processing unit (GPU), a data processing unit (DPU), an accelerated processing unit (APU), a tensor processing unit (TPU), or the like.

[0063] A user interface 480 is also included and is a logical component that includes features that allow a user (e.g., patient 482) to provide input to and receive output from WMD 401. In various embodiments, user interface 480 receives manual input (e.g., keystrokes or taps) from the patient. For example, user interface 480 may include a microphone 481 for receiving sounds and converting those sounds into computer-usable signals. User interface 480 may also include a speaker 482 for converting computer-usable signals into audible sounds. User interface 480 may also include a visual display 483 for converting computer-usable signals into visual data that can be visually perceived. In some embodiments, visual display 483 is a touchscreen display that can also receive tactile input in the form of touches on visual display 483.

[0064] One or more sensors 420 may also be included in the WMD 401 to sense patient physiological signals. Similar to the external defibrillator 300 shown in FIG. 3 and described above, the sensors 420 may include any one or more components used to detect various parameters (e.g., patient parameters, system parameters, environmental parameters, etc.). For example, in some embodiments in which the WMD 401 is implemented as part of an external defibrillator (e.g., the external defibrillator 300) or an external monitoring device (e.g., the external monitoring device 180), the sensors may include any or all of the sensors described above. In some embodiments in which the WMD 401 is implemented in or as part of a companion device 199, the sensors may omit those used to capture patient parameters (e.g., ECG electrodes) and instead include only sensors used to detect environmental parameters (e.g., a motion detector, an accelerometer, a compass, a proximity sensor, a barometer, etc.). It will be appreciated that in some embodiments, when WMD 401 is implemented within companion device 199, it may rely on sensor data collected by either or both an external defibrillator or an external monitoring device. In such embodiments, most or all of sensors 409 may be omitted from or not used by WMD 401 itself. Additionally, overlapping sensors (e.g., between an external defibrillator and WMD 401) are also possible.

[0065] A communications module 490 is also included in the WMD 401 to enable communication between the WMD 401 and other devices (such as the companion device 199). In various embodiments, the communications module 490 may implement wired and / or wireless communications between the WMD 401 and an external defibrillator. For example, if the WMD 401 is implemented within a companion device (e.g., the companion device 199), the communications module may enable bidirectional communications between the companion device 199 and the external defibrillator 100. In this manner, the WMD 401 can receive signals from the external defibrillator 100, such as ECG waveforms and other patient parameters detected by the external defibrillator 100. Similarly, the WMD 401 may transmit commands and / or data to the external defibrillator 100, such as requests for the external defibrillator 100 to transmit information to the WMD 401. Furthermore, the communications module 490 may implement cellular communications capabilities to enable long-range cellular data communications with remote computing devices. These and other embodiments of the communications module 490 will be apparent to those skilled in the art.

[0066] Memory 410 is a data store implemented within WMD 401 for storing data and software components, such as various executable modules. Memory 410 may be implemented as volatile memory, nonvolatile memory, or a combination of volatile and nonvolatile memory. Nonvolatile memory may be used to persistently store information, while volatile memory may be used by processor 405 while executing various instructions. Thus, the term "memory," as used herein, should be given its broadest interpretation as any repository where computer-readable information may be held temporarily and / or persistently.

[0067] Within memory 410 are several executable modules according to various embodiments. For example, a direct input module 411 may be included to receive and process direct user data provided by an external source. In one example, the direct input module 411 is configured to prompt the patient 482 for and accept data through the user interface 480, either through a microphone, a display, a speaker, or any combination thereof. The direct input module 411 may be configured to receive user-provided data and combine it with other data, such as parameter data 413 and / or patient data 414. For example, the patient 482 may be prompted to provide specific information by speaking into the microphone 481. Similarly, the patient 482 may be presented with options that can be selected on the display 483. These are just a few examples of direct patient input.

[0068] According to some embodiments, a web server 412 is included in the memory. In some embodiments, the web server 412 is software that responds to client requests made over a wide area network by returning interpreted page content using HTTP (Hypertext Transfer Protocol) and / or other protocols. In addition to HTTP, the web server 412 may also support IP (Internet Protocol), HTTPS (Secure Hypertext Transfer Protocol), FTP (File Transfer Protocol) protocol, and other communication protocols.

[0069] In operation, web server 412 communicates with clients (e.g., web browsers) using the Secure Hypertext Transfer Protocol (HTTPS). Web server 412 provides interpreted code 430, which in some embodiments is Hypertext Markup Language (HTML). The content (or code) can be static (e.g., text and images) or dynamic (e.g., assembled "on the fly"). To deliver dynamic content, in some embodiments, web server 412 supports server-side scripting languages ​​for encoding business logic into communications. In some embodiments, these languages ​​may include any one or more of Active Server Pages (ASP), Java, JavaScript, PHP, Python, Ruby, etc.

[0070] In some embodiments, the interpreted code 430 provides the requesting client with access to parameter data of the WMD as described herein. In some embodiments, the interpreted code 430 provides access to patient data. In some embodiments, the patient data includes a patient identifier, number of delivered shocks, performance reporting records, WMD status, cardiac rhythm, etc. In some embodiments, the interpreted code 430 is implemented as HTML. In some embodiments, the interpreted code 430 may also include cascading style sheets (CSS). In operation, the processor 405 transmits the interpreted code 430 from the web server 412 to the requesting client via the communications module 490. In such embodiments, browser software executing on the client can then modify the parameter data via the display 480, or perhaps through one or more inputs received from a companion device (such as the companion device 199). The one or more inputs can then be transmitted back to the web server via the communications module 490.

[0071] In some embodiments, the interpreted code 430 provides a requesting client with access to the parameter data 413 and / or patient data 414 of the WMD as described herein. Examples of parameter data 413 include notification volume levels, display settings, localization settings (e.g., language, text orientation, etc.), battery power profile, patient configuration information, device configuration information, etc. Examples of patient data 414 include any information about the patient 482, such as a patient identifier, number of delivered shocks, performance reporting records, WMD status, cardiac rhythm, etc. In some embodiments, the interpreted code 430 implements a web interface that provides access to the parameter data 413 and / or patient data 414. In some embodiments, the interpreted code 430 is implemented as HTML. In some embodiments, the interpreted code 430 may also include CSS.

[0072] During operation, processor 405 transmits interpreted code 430 from web server 412 to the requesting client via communications module 490. In such an embodiment, browser software running on the requesting client interprets the interpreted code 430 and renders the code on a display. In that manner, by using the browser software on the requesting client (e.g., companion device 199), a user can remotely modify parameter data 413 through one or more inputs received from the browser software. In various embodiments, the browser software can render interpreted code 430 locally, such as on display 480. In other embodiments, the browser software may render interpreted code 430 on a remote device, such as companion device 199. The one or more inputs can then be transmitted back to web server 412 via communications module 490.

[0073] In some embodiments, the WCD further comprises patient data 414, the interpreted code of the web server further configured to provide access to the patient data, and the companion browser further configured to display the patient data. In some embodiments, the patient information includes at least a patient identifier, the number of delivered shocks, an execution report record, a WCD status, or a presented cardiac rhythm. In some embodiments, the patient data may be patient parameters as described herein. For example, the patient parameters may include patient physiological parameters. The patient physiological parameters may include, for example, but are not limited to, any physiological parameters that may assist the WCD system in detecting whether the patient requires a shock or other intervention or assistance. The patient physiological parameters may also optionally include the patient's medical history, event history, etc. Examples of patient parameters include the patient's ECG, blood oxygen level, blood flow, blood pressure, blood perfusion, pulsatile changes in the optical transmission or reflectance properties of perfused tissue, heart sounds, cardiac wall motion, respiratory sounds, and pulse. In some embodiments, the WCD may include one or more sensors described herein configured to acquire the patient's physiological signals.

[0074] Patient status parameters include recorded aspects of the patient 382 (e.g., movement, posture, whether they have spoken recently, and possibly what they have said, etc.), plus optionally a history of these parameters. Alternatively, one of these monitoring devices may include a location sensor, such as a Global Positioning System (GPS) location sensor. Such a sensor can detect location, plus velocity, which can be detected as the rate of change of location over time. Many motion detectors output a motion signal that indicates movement of the detector and, therefore, movement of the patient's body. Patient status parameters can be very useful in narrowing down the determination of whether SCA is actually occurring.

[0075] In some embodiments, the web server transmits the interpreted code to the companion device, the browser component renders the interpreted code on the companion device's display, and user input received by the browser component is returned to the WCD through the WCD communication module and the companion communication module. In some embodiments, such as when the interpreted code includes patient data, a user of the WCD can modify the patient data displayed by the browser component via a series of inputs (e.g., taps, keystrokes, button presses, etc.) on the communication device. The communication device can then return the input to the WCD via the companion communication module. The WCD processor can then modify the patient data in the interpreted code provided by the web server.

[0076] As described, various components shown for convenience in WMD 480 may alternatively be implemented in or distributed across other devices. For example, in other embodiments, user interface 480 may be implemented in a companion mobile device (not shown) rather than in WMD 480. In such embodiments, WMD 480 may employ a communications module 490 to communicate patient parameters and / or sensory data to the companion mobile device. Many other permutations will be apparent to those skilled in the art.

[0077] FIG. 5 is a conceptual diagram generally illustrating a health monitoring environment 500, according to an embodiment. As shown in FIG. 5, the health monitoring environment 500 includes a wearable cardiac monitoring device (WCD 501), a mobile device (e.g., a companion device) 521, and a remote patient data platform (care station server 510). Each of these components variously communicates with one or more other components, either locally via a local communication link or remotely via a remote communication link over a wide area network 550, such as the Internet. While the companion device 521 is illustrated as a mobile device, it should be understood that the companion device 521 may take any number of forms, including a tablet, a laptop, a desktop computer, a smartphone, etc.

[0078] The wearable cardiac monitoring device 501 may be any medical device configured to detect and report a patient's physiological parameters, as described in detail above. The wearable cardiac monitoring device 501 is described herein as a WCD for ease of discussion only. One example of such a WCD is the Assure WCD, developed and offered by Kestra Medical Technologies, Inc. of Kirkland, Washington. Many other types of wearable cardiac monitoring devices can be used in various alternative embodiments without departing from the spirit of the present disclosure. Accordingly, reference to the use of a WCD as the cardiac monitoring device 501 is exemplary only and is not intended to limit the present disclosure.

[0079] The WCD 501 may also communicate via a local communication link 503 with a mobile device 521 running an app configured to facilitate communication between the patient 582, the WCD 501, and other remote devices. In various embodiments, the mobile device 521 may be referred to as a companion device. In one example, the mobile device 521 and the WCD 501 may communicate using a relatively short-range local communication link 503, such as Ethernet™, Bluetooth™ Low Energy (BLE), or Wi-Fi. In some embodiments, the mobile device 521 and the WCD 501 may communicate using a wired connection, a personal area network (PAN), or a local area network (LAN) connection. The mobile device 521 may also communicate with other remote devices using a remote communication link 551 to a wide area network 550, such as the Internet. In one particular embodiment, the application running on the mobile device 521 may be the Assure patient app, developed and offered by Kestra Medical Technologies, Inc. of Kirkland, Washington. In various embodiments, a patient application running on the mobile device 521 can provide a graphical user interface (GUI) that allows review of patient physiological parameters captured by the WCD 501 .

[0080] In some embodiments, the remote patient data platform (care station server 510) is implemented as a remote server for use by medical professionals and / or clinicians to provide an efficient tool for managing cardiac patient care. In various embodiments, the remote patient data platform delivers relevant data and valuable insights into patient cardiac rhythm and usage compliance by providing clear patient reports including VT, VF, bradycardia, asystole, and non-sustained ventricular arrhythmia episodes, WCD usage, and physical activity trends, and may include a population dashboard with configurable notifications. One example of such a remote patient data platform is the CareStation platform developed and offered by Kestra Medical Technologies, Inc. of Kirkland, Washington. The remote patient data platform is described herein as a care station server for ease of discussion only. Many other types of remote patient data platforms may be used in various alternative embodiments without departing from the spirit of the present disclosure. Accordingly, reference to using a care station server as the remote patient data platform is exemplary only and is not intended to limit the present disclosure.

[0081] In some embodiments, the care station server 510 acts as a certificate authority. In such embodiments, a certificate authority acts as a trusted organization to issue signed digital certificates and to certify the authenticity of those signed digital certificates. Certificate authorities are known in the art.

[0082] Generally speaking, patient data is collected by WCD 501 and uploaded to care station server 510 either directly by WCD 501 or by using an associated mobile device (e.g., companion device 521). In addition, mobile device 521 may also collect some forms of patient data.

[0083] The care station server 510 stores patient data and can perform several analyses on the patient data to identify patient health problems such as the occurrence of arrhythmias, shockable and non-shockable events, and other medical events. Additionally, post-mortem evaluations can be performed on the patient data to help improve the quality of future shock therapy.

[0084] In some embodiments, the WCD 501 may include a web server (e.g., web server 412), as described in connection with FIG. 4 . In some embodiments, the WCD 501 may be communicatively coupled to a companion device 521. The WCD 501 may include a processor configured to transmit interpreted code from the web server via a communications module and to modify parameter data based on input received via the communications module. The interpreted code may be transmitted to a companion device communications module. In some embodiments, the companion device includes a display and a browser module. In some embodiments, the companion device is configured to receive the interpreted code via the companion communications module, present the interpreted code to a browser component, receive input from the browser, and return input to the WCD communications module via the companion communications module.

[0085] In some embodiments, the WMD further includes patient data, the web server user interface is further configured to provide access to the patient data, and the companion browser is further configured to display the patient data. In some embodiments, the patient information can take any number of many different forms, such as a patient identifier, number of delivered shocks, performance reporting records, WCD status, cardiac rhythm, etc.

[0086] Authentication Method In one embodiment, the web server includes one or more security measures configured to restrict access to the web server to unauthorized users. In some embodiments, the one or more security measures restrict access to one or more functions of the web server, or even complete access to the web server, depending on the user's authentication credentials. For example, various authorized users may have different needs for access to different features made available by the web server. For example, a patient may need access to different information than a medical professional, caregiver, or manufacturer of the WCD, and vice versa.

[0087] In some embodiments, the web server comprises one or more security measures configured to restrict access to the web server from unauthorized users. In some embodiments, the one or more security measures restrict one or more functions of the web server depending on the identity of an authorized user. In some embodiments, the identity of an authorized user is selected from a patient, a medical professional, a caregiver, or a manufacturer of the WCD.

[0088] In some embodiments, the one or more security measures are a set of authentication credentials, such as a username and password. In some embodiments, the set of authentication credentials may be further protected with two-factor authentication. In such embodiments, an authorized user may receive a set of authentication credentials specific to the authorized user's identity. For example, a patient may receive a patient set of authentication credentials that may allow the patient to view the status of the WCD and WCD and patient information, but may restrict the patient from adjusting parameters of the WCD or WMD. In some embodiments, a medical professional may receive a set of medical professional credentials that allow the medical professional to adjust parameters of the WCD or WMD, review patient information, and view the status of the WMD or WCD. Additionally, for example, a manufacturer may receive a set of manufacturer credentials that allow the medical professional to adjust parameters of the WCD or WMD, but not access patient information.

[0089] In an alternative embodiment, the one or more security measures include a security certificate. Figure 6 is a conceptual diagram of a security certificate 600 (also referred to as a digital certificate) that may be used in various embodiments of the present disclosure. In a particular embodiment, security certificate 600 is a digital file that includes various data fields. These fields may include one or more of a subject, an issuer, an expiration date, an algorithm, and a unique identifier. Not all of these fields need be included in all embodiments, and other fields not described herein may also be included. These fields are provided by way of example only.

[0090] The subject field may identify the certificate holder, or entity with which security certificate 600 is associated. The certificate holder may be an individual, an organization, a particular computing device, or any entity whose identity has been verified and whose trust has been certified by a certification authority (as described in connection with FIGS. 7-8).

[0091] The issuer field may identify a trusted certificate authority that may be trusted to verify the authenticity of an entity. In one example, an Assure Certificate Authority may be established and trusted to verify the identities of various components authorized to communicate with the WCD or other components of the WCD system, for example.

[0092] The expiration date field may identify the date on which the security certificate becomes invalid or can no longer be used to trust a subject. In some embodiments, a "not before" field may also be included to identify the date on which the security certificate is no longer valid.

[0093] The public key portion of the security certificate 501 is included to provide a subject's public key and associated public key information. Public / private key pairs are used in public key infrastructure (PKI) systems to facilitate asymmetric cryptography. The public key information may include additional information describing the public key, such as the algorithm (e.g., elliptic curve public key), key size (e.g., 256 bits), and key usage (e.g., can be encrypted, verified, derived). The public key portion of the security certificate 501 enables the recipient of the security certificate 501 to communicate securely with the subject through an encrypted communication session.

[0094] An algorithm field may be included in security certificate 501 to specify the particular algorithm used to sign the certificate, as described below. Examples of algorithms that may be used include SHA-1, SHA-2, SHA-256, etc.

[0095] A unique identifier or serial number is also included to uniquely identify the security certificate. Note that the unique identifier should be distinguished from the subject in that the subject identifies the trusted entity or entity with which the security certificate is associated, whereas the unique identifier identifies the actual security certificate itself.

[0096] Optionally, one or more permission fields may be included in security certificate 600. In some embodiments, certain elements of a WCD system (e.g., a WCD) need to govern the actions that other connected components are permitted to perform during communication. For example, in some embodiments, a WCD may be configured to allow a limited set of element types to change critical configuration parameters of the WCD, but prevent other element types from doing so. An example of this may be that a WCD may be configured to allow a tablet to configure such parameters, but not allow a companion device to do so. In such embodiments, one or more fields of security certificate 600 (collectively referred to as "permission" fields for ease of discussion) may be "permission" fields.

[0097] Other data fields may also be included and used for a variety of reasons: arbitrary or structured data may be included to provide or convey any manner of information that is deemed trustworthy or has a need to ensure its integrity.

[0098] A signature is also included in security certificate 600. A signature is a data structure that represents a testimony to the authenticity of security certificate 600. A signature is created by an issuer (e.g., a certificate authority) and is verifiable using the issuer's security certificate (or digital certificate). A signature may be created in different ways, but one example may be that the body of the security certificate is input into an algorithm (e.g., a hash algorithm) identified in the security certificate along with the issuer's private key. The algorithm creates a unique value based on the body of the security certificate and the issuer's private key. The issuer's public key can then be used by the identified algorithm to verify that the body of the security certificate has not been altered since the signature was created by the issuer. In this way, the integrity of the data in the body of the security certificate can be trusted as long as the issuer is trusted.

[0099] 7 and 8, the operation of an embodiment of the present disclosure will be described with reference to the components shown in Figures 1-6 and described above. The following operations are provided for the completeness of the disclosure, but it will be understood that departures from these operations are contemplated and this description should not be considered as limiting the scope of the disclosure.

[0100] 7 is a functional flow diagram generally illustrating a process 700 for creating a security credential in accordance with the present disclosure. The credential creation process 700 may be implemented by the components of the WCD system 301 shown in FIG. 3 and described above. Alternatively, other components may be modified or adapted to implement some of the steps discussed herein. References to components with the same name are for ease of explanation only, and steps may be performed by various components.

[0101] Process 700 begins when a companion device (companion device 720) creates 701 a certificate signing request (CSR) for a "requesting entity" (not shown) that wishes to communicate with the WCD. As part of that operation, the companion device 720 may create a public / private key pair on behalf of the requesting entity, or the public / private key pair may be provided to the companion device 720 by the requesting entity. The CSR contains information identifying the requesting entity and includes the requesting entity's public key.

[0102] Once the CSR is created, the companion device 720 sends 702 the CSR to a component responsible for facilitating the creation of a security certificate for use in the WCD system. In this example, the web server 740 is the responsible component. Thus, the companion device 720 sends the CSR to the web server 740. It will be appreciated that to ensure the CSR is securely delivered to the web server 740, the companion device 740 may first establish a secure connection to the web server 740 using the companion device's own security certificate.

[0103] Web server 740 forwards 703 the CSR to certificate authority 760. In certain embodiments, web server 740 may forward additional information along with the CSR. For example, web server 740 may maintain a record of which components are authorized to perform which functions on or in conjunction with the WCD. In such embodiments, web server 740 may forward authorization information along with the CSR to certificate authority 760.

[0104] The certificate authority 760 is configured to perform the operation of verifying (704) the accuracy of the information contained in the CSR. For example, the certificate authority 760 may have access to records or data that can establish that the CSR actually originated from the request element and properly named the request element. Additionally, the certificate authority 760 may have access to records or data that confirm that the request element is authorized to access other components in the WCD system, such as the WCD itself. Additionally, the certificate authority 760 may verify authorization information provided by the web server 740 (if such information is provided) or have information describing the appropriate authorization for the request element in the first instance. In one embodiment, the certificate authority may be on the care station server (as shown in FIG. 5).

[0105] If the CSR survives validation, the certificate authority 760 creates a security certificate that contains information from the CSR and signs the security certificate using the private key of the certificate authority 760. By signing the certificate, the certificate authority protects the information in the certificate from tampering and also certifies the validity of the information.

[0106] Once the security certificate is signed, the certificate authority and web server 740 returns the signed certificate to the companion device 720, which then installs the security certificate on the requesting element. In this way, the requesting element (i.e., the companion device) can, for example, authenticate itself to the WCD and have secure communications with the WCD.

[0107] It should be noted that although both are referred to as a "web server," the web server 740 shown in Figure 7 need not be the same as the web server (e.g., web server 412) implemented within the subject WMD. Any suitable web server can be used in the process 700 shown in Figure 7 to create security credentials, and the web server used in process 700 need not provide access to any features or settings stored in the WMD.

[0108] FIG. 8 illustrates a process 800 for using security certificates within a WCD system to ensure trusted communication and appropriate access between components of the WCD system. Again, while described in the context of a WCD, the present teachings apply equally to any WMD. Certificate usage process 800 may be performed by components of a WCD system as described above. Alternatively, other components may be modified or adapted to implement some of the steps discussed herein. References to identically named components are for ease of description only, and steps may be performed by various components.

[0109] Process 800 begins when companion device 820 wishes to initiate communication with another component in the WCD system (801). The other component is a web server for WCD 840 in this example, but may be any other component in the WCD system. In accordance with this disclosure, companion device 820 initiates a handshake with WCD 840 to exchange security credentials. During this process, companion device 820 sends its security credentials to WCD 840, and WCD 840 returns its own security credentials (not shown).

[0110] With the security certificate in hand, the WCD 840 performs step (802) to validate the security certificate. For example, the WCD 840 can identify a certificate authority from information in the security certificate to determine whether the security certificate is certified by a trusted certificate authority. Once identified, the WCD 840 checks a certificate store to determine whether the identified certificate authority is trusted by the WCD 840. If so, the WCD 840 uses the stored security certificate (CA certificate) to verify the integrity of the received security certificate. In essence, the WCD 840 uses the CA certificate to verify the authenticity of the security certificate and that its contents have not been tampered with. The WCD 840 also ensures that the security certificate is within the appropriate time frame for its use (e.g., it is currently valid and has not yet expired).

[0111] In an optional step (803), WCD 840 (or other receiving component) may perform a check to ensure that the security certificate has not been revoked since it was issued. In one embodiment, WCD 840 transmits the security certificate (or a portion thereof, such as a serial number) to another component, such as certificate authority 860, for verification.

[0112] In such an embodiment, the certificate authority 860 compares (804) the received security certificate with a certificate revocation list (CRL) to determine whether the security certificate has been revoked, and then returns (805) a pass / fail or yes / no response indicating whether the security certificate has been revoked.

[0113] In an alternative embodiment, rather than sending a security certificate, WCD 840 can request (803) a CRL from certificate authority 860, which then returns (805) the CRL to WCD 840 so that WCD 840 can determine for itself whether a security certificate has been revoked. In such an embodiment, WCD 840 can cache the CRL for future use to reduce the number of network communications it performs for certificate validation purposes.

[0114] If the security credentials are properly verified and validated, the WCD 840 can authorize a communication session with the companion device 820 (806). Furthermore, through the exchange of security credentials, and therefore public keys, the communication session can be encrypted between the two components to ensure that the exchanged data is not compromised. However, if the security credentials fail any test, the WCD 840 prohibits communication with the trusted component 820 (which is now untrusted). In various embodiments, when the WCD 840 initiates a secure connection, it can use the security credentials, and in particular the permission field, to determine which operations the companion device 820 is authorized to perform. Although generally referred to as the permission field, it will be understood that the WCD 840 can use any data in the security credentials (such as the “element type” field) to control the scope of permissions granted to the companion device 820. In other words, the security credentials may, but need not, have dedicated fields that explicitly describe the permissions. Operational permissions can be implied based on other data in the security credentials. For example, a security certificate may include a device type field that describes the type of connected element, such as a tablet, a companion device, a manufacturing system, etc., and various permissions may be assigned to different device types. Another example is a region field that describes the geographic region of the trusted component, such as the United States, the European Union, Canada, Japan, etc. In such an embodiment, the security certificate may be used to select an appropriate localization component (e.g., language, left-to-right text orientation, etc.).

[0115] Other embodiments include combinations and subcombinations of features described or shown in the drawings herein, including embodiments that are equivalent to both providing or applying features in a different order than the embodiments described herein, extracting individual features from one embodiment and inserting such features into another embodiment, removing one or more features from an embodiment, or removing one or more features from an embodiment and adding one or more features extracted from one or more other embodiments, while providing the advantages of the features incorporated in such combinations and subcombinations. As used in this paragraph, one or more features may refer to the structure and / or function of a device, product, or system, and / or a method step, act, or modality.

Claims

1. A wearable medical monitoring device (WMMD), comprising: a support structure configured to be worn by a patient; a plurality of electrodes coupled to the support structure; a WMMD communication module; a WMMD data store in which components reside, the WMMD data store including parameter data defining a configuration of the WMMD, interpreted code providing access to the parameter data, and a web server configured to provide the interpreted code; a WMMD processor configured to execute the web server operative to transmit the interpreted code via the WMMD communications module and to modify the parameter data based on input received by the web server via the WMMD communications module. The WMMD; a companion device communicatively coupled to the WMMD, The display and a companion communication module configured to communicatively couple the companion device and the WMMD; a companion data store in which components reside, including a browser configured to render the interpreted code, the interpreted code defining a user interface that allows modification of the parameter data, the user interface operable to receive input from the patient; and a companion processor configured to execute the browser, receive input from the patient, and return the input to the WMMD communication module via the companion communication module, operable to receive the interpreted code via the companion communication module and render the user interface on the display; the companion device; the web server transmits the interpreted code to the companion device, the browser component renders the interpreted code on the display of the companion device, and input received from the patient is returned to the WMMD via a communication link between the WMMD communication module and the companion communication module; the web server includes one or more security measures configured to restrict access to functionality of the web server depending on authentication credentials based on whether a user is the patient, a medical professional, or a manufacturer of the WMMD; the WMMD data store includes patient data defining parameters of the patient including one or more of a patient identifier, a number of delivered shocks, a performance report record, a WMMD state, or a cardiac rhythm; the authentication credentials based on the user being the patient may allow the user to view the status of the WMMD as well as patient information but may limit the patient's ability to adjust parameters of the WMMD; the authentication credentials based on the user being a medical professional allow the user to adjust parameters of the WMMD, review patient information, and view the status of the WMMD; and the authentication credentials based on the user being a manufacturer allow the user to adjust parameters of the WMMD but do not allow access to patient information; the interpreted code further provides access to the patient data. Wearable monitoring device system.

2. The wearable monitoring system of claim 1 , wherein the interpreted code is HTML.

3. The wearable monitoring device system of claim 1 , wherein the communication link is a Wi-Fi, Bluetooth Low Energy (BLE), wired connection, personal area network (PAN), or local area network (LAN) connection.

4. The wearable monitoring device system of claim 1 , wherein the companion device is a tablet, laptop, desktop computer, or smartphone.

5. The wearable monitoring system of claim 1 , wherein the interpreted code includes one or more available functions.

6. A wearable automatic cardioverter defibrillator (WCD), comprising: a support structure configured to be worn by a patient; a plurality of electrodes coupled to the support structure; an energy storage module configured to store an electrical charge; a discharge circuit configured to be coupled to the energy storage module and configured to use the plurality of electrodes and a charge stored in the energy storage module to deliver one or more shocks to the patient while the support structure is worn by the patient; A WCD communication module, a WCD data store in which components reside, the WCD data store including parameter data defining a configuration of the WCD, interpreted code providing access to the parameter data, and a web server configured to provide the interpreted code; a WCD processor configured to execute the web server operative to transmit the interpreted code via the WCD communications module and to modify the parameter data based on input received by the web server via the WCD communications module. The WCD; a companion device communicatively coupled to the WCD, The display and a companion communication module configured to communicatively couple the companion device and the WCD; a companion data store in which components reside, including a browser configured to render the interpreted code, the interpreted code defining a user interface that allows modification of the parameter data, the user interface operable to receive input from the patient; and a companion processor configured to execute the browser, receive input from the patient, and return the input to the WCD communication module via the companion communication module, operable to receive the interpreted code via the companion communication module and render the user interface on the display; the companion device; the web server transmits the interpreted code to the companion device, the browser component renders the interpreted code on the display of the companion device, and input received from the patient is returned to the WCD via a communication link between the WCD communication module and the companion communication module; the web server includes one or more security measures configured to restrict access to functionality of the web server depending on authentication credentials based on whether a user is the patient, a medical professional, or a manufacturer of the WCD; the WCD data store includes patient data defining parameters of the patient including one or more of a patient identifier, a number of delivered shocks, a performance report record, a WCD status, or a cardiac rhythm; The authentication credentials based on the user being the patient may allow the user to view the status of the WCD as well as patient information but may limit the patient's ability to adjust parameters of the WCD; the authentication credentials based on the user being a medical professional may allow the user to adjust parameters of the WCD, review patient information, and view the status of the WCD; and the authentication credentials based on the user being a manufacturer may allow the user to adjust parameters of the WCD but not allow access to patient information; the interpreted code further provides access to the patient data. Wearable automated defibrillator system.

7. 7. The wearable automatic defibrillator system of claim 6, wherein the interpreted code is HTML.

8. 7. The wearable automatic defibrillator system of claim 6, wherein the WCD and the companion device are communicatively coupled via a Wi-Fi, Bluetooth Low Energy (BLE), wired connection, personal area network (PAN), or local area network (LAN) connection.

9. 7. The wearable automatic defibrillator system of claim 6, wherein the companion device is a tablet, laptop, desktop computer, or smartphone.

10. 7. The wearable automatic defibrillator system of claim 6, wherein the interpreted code includes one or more available functions.

Images