Lightweight network communication for wearable cardiac devices

Abstract

A cardiac monitoring system is provided that preferentially handles certain clinical and operational communications. The cardiac monitoring system includes an externally wearable cardiac device configured to sense one or more electrocardiogram (ECG) signals from a patient wearing the cardiac device. A cardiac device includes a network interface, a memory configured to store ECG data derived from one or more ECG signals, and a processor coupled to the memory. The processor is configured to determine an occurrence of a priority event associated with the cardiac device or a patient wearing the cardiac device from a subset of the ECG data, publish a message specifying the priority event to a first topic via the network interface using a first communication protocol, and transmitting the ECG data to a remote storage service via the network interface using a second communication protocol different from the first communication protocol.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Patent Application No. 63 / 387,785 (filed December 16, 2022), the entire disclosure of which is incorporated herein by reference. Background Art

[0003] The present disclosure relates to medical devices configured for patient cardiac telemetry utilizing one or more lightweight communication protocols.

[0004] If heart failure is not treated, it may lead to certain life-threatening arrhythmias. Both atrial and ventricular arrhythmias are common in patients with heart failure. One of the most lethal heart arrhythmias is ventricular fibrillation, which occurs when normal, regular electrical impulses are replaced by irregular and rapid impulses, causing the heart muscle to stop contracting normally. Because the victim has no perceptible warning of the impending fibrillation, death often occurs before necessary medical help arrives. Other heart arrhythmias may include a very slow heart rate called bradycardia or a very fast heart rate called tachycardia. Cardiac arrest may occur when a patient experiences various heart arrhythmias such as ventricular fibrillation (VF), ventricular tachycardia (VT), pulseless electrical activity (PEA) and asystole (the heart stops all electrical activity), resulting in the heart supplying insufficient blood flow to the brain and other vital organs to sustain life. It is often useful to monitor patients with heart failure to assess heart failure symptoms early and provide interventional treatment as soon as possible.

[0005] Patients who are at risk, have been hospitalized for an adverse cardiac condition, or otherwise have an adverse cardiac condition may be prescribed a wearable cardiac monitoring and / or treatment device. In addition to the wearable device, the patient may also be given a battery charger and a set of rechargeable batteries. Since the wearable device is typically prescribed for continuous use (e.g., removed only for showering), the patient wears the device during all daily activities such as walking, sitting, climbing stairs, resting or sleeping, and other similar daily activities. Maintaining continuous use of the device as prescribed can be beneficial in monitoring the patient's progress and providing treatment to the patient when needed. Summary of the Invention

[0006] In an example, a cardiac system for efficiently publishing ECG data for subscription-based access is provided. The cardiac system includes an external wearable cardiac device configured to sense one or more ECG signals from a patient's skin. The external wearable cardiac device includes a memory and at least one processor coupled to the memory. The memory is configured to store a device identifier for uniquely identifying the external wearable cardiac device among a plurality of external wearable cardiac devices. The at least one processor is configured to: subscribe to a device-specific topic related to one or more device parameters for controlling operation of the external wearable cardiac device; and publish to a first topic related to information derived from the one or more ECG signals sensed by the external wearable cardiac device, the first topic being different from the device-specific topic, wherein the device-specific topic incorporates the device identifier.

[0007] Examples of the described cardiac system may incorporate one or more of the following features.

[0008] In the cardiac system, the at least one processor may be further configured to: receive a message specifying one or more device settings associated with the external wearable cardiac device via the device-specific topic; and apply the one or more device settings to the one or more device parameters of the external wearable cardiac device. The one or more device settings may include a positioning setting. The cardiac system may also include a device control service configured to: receive input specifying the one or more device settings; generate a message specifying the one or more device settings based on the input; and publish the message to the device-specific topic.

[0009] In the cardiac system, the at least one processor may be further configured to: subscribe to a patient-specific topic related to device parameters for controlling operation of the external wearable cardiac device, the patient-specific topic being distinct from the device-specific topic and the first topic; receive a message specifying one or more patient settings associated with the patient via the patient-specific topic; and apply the one or more patient settings to one or more device parameters of the external wearable cardiac device. The external wearable cardiac device may include: one or more monitoring electrodes configured to sense the one or more ECG signals; and one or more therapy electrodes configured to deliver electrical therapy to the patient's skin; and the one or more patient settings may include one or more shock settings assigned to the electrical therapy. The cardiac system may also include a device control service configured to: receive input specifying the one or more patient settings; generate a message specifying the one or more patient settings based on the input; and publish the message to the patient-specific topic. In the cardiac system, the at least one processor may be further configured to: generate an authentication code; and verify that a message specifying the one or more patient settings may include the authentication code.

[0010] In the cardiac system, the external wearable cardiac device may also be configured to sense one or more heart sound signals from the patient; and the first topic may also be related to information derived from the one or more heart sound signals sensed by the external wearable cardiac device.

[0011] In the cardiac system, the externally wearable cardiac device may be further configured to collect device event data indicating the ability of the externally wearable cardiac device to monitor and treat the patient; and the first topic further relates to information derived from the device event data collected by the externally wearable cardiac device. The device event data may include one or more of a hold response button condition, a disconnected therapy electrode condition, and a unable to treat condition.

[0012] In the cardiac system, the at least one processor may be further configured to: derive ECG data from the one or more ECG signals; identify a cardiac arrhythmia condition of the patient indicated in the ECG data; and transmit the ECG data to a remote storage service using a first communication protocol; and publishing to the first topic may include publishing a message specifying the cardiac arrhythmia condition of the patient using a second communication protocol different from the first communication protocol. The device-specific topic may be a first device-specific topic; transmitting the ECG data to the remote storage service may include: publishing a message specifying a request for an upload link to a second topic different from the first topic and the first device-specific topic, and receiving the message specifying the upload link via a subscription to the second device-specific topic, the second device-specific topic being different from the first topic, the second topic, and the first device-specific topic; and transmitting the ECG data to the remote storage service via the upload link.

[0013] The cardiac system may further include the remote storage service, wherein the remote storage service may be configured to: receive the ECG data using the first communication protocol; and publish a message identifying the ECG data to a second topic using the first communication protocol, the second topic being distinct from the first topic and the device-specific topic. The message specifying the cardiac arrhythmia condition may further specify an identifier for the ECG data. The cardiac system may further include a message handling service configured to: receive a message specifying the cardiac arrhythmia condition of the patient; receive a message identifying the ECG data; and in response to receiving the message specifying the cardiac arrhythmia condition of the patient, communicate a notification message to a reporting service.

[0014] The cardiac system may further include the reporting service, wherein the reporting service may be configured to receive the notification message and process a communication alert message to a recipient, the alert message specifying a connection between the patient's cardiac arrhythmia condition and the ECG data. In the cardiac system, the external wearable cardiac device may include security credentials created during manufacture of the external wearable cardiac device; and the message handling service may be further configured to register the security credentials and authenticate communications from the external wearable cardiac device using the security credentials. The security credentials may include the device identifier, the device identifier being used to uniquely identify the external wearable cardiac device among a plurality of external wearable cardiac devices; and the message handling service may be further configured to identify the external wearable cardiac device using the device identifier. In the cardiac system, the first communication protocol may be Hypertext Transfer Protocol (HTTP), and the second communication protocol may be Message Queuing Telemetry Transport (MQTT).

[0015] In another example, a cardiac monitoring system with prioritized handling of certain clinical and operational communications is provided. The cardiac monitoring system includes an external wearable cardiac device configured to sense one or more electrocardiogram signals, i.e., one or more ECG signals, from a patient wearing the external wearable cardiac device. The external wearable cardiac device includes a network interface; a memory configured to store ECG data derived from the one or more ECG signals; and at least one processor coupled to the memory. The at least one processor is configured to: determine, based on a subset of the ECG data, an occurrence of a priority event associated with the external wearable cardiac device or a patient wearing the external wearable cardiac device; publish a message specifying the priority event to a first topic via the network interface using a first communication protocol; and transmit the ECG data to a remote storage service via the network interface using a second communication protocol different from the first communication protocol.

[0016] Examples of the cardiac monitoring system may incorporate one or more of the following features.

[0017] In the cardiac monitoring system, the priority event may include one or more of a cardiac arrhythmia condition of the patient and a noise condition of the external wearable cardiac device. The ECG data may include one or more of an ECG segment, heart rate, QRS duration, and QTC interval. The external wearable cardiac device may also be configured to: collect device event data indicating the ability of the external wearable cardiac device to deliver electrotherapy to the patient; receive input via a user interface indicating that the patient's cardiac arrhythmia condition is false; and deliver the electrotherapy in response to detecting the cardiac arrhythmia condition and not receiving input indicating that the patient's cardiac arrhythmia condition is false. The priority event may be a first priority event; the memory may also be configured to store operational data derived from the device event data; and the at least one processor may be further configured to: determine, based on a subset of the operational data, an occurrence of a second priority event associated with the external wearable cardiac device or a patient wearing the external wearable cardiac device, and publish a message specifying the second priority event to the first topic via the network interface using the first communication protocol. The second priority event may include: an inability condition in which the external wearable cardiac device is unable to receive input indicating that the patient's cardiac arrhythmia condition is false; or an inability condition in which the external wearable cardiac device is unable to release the electrical therapy in response to detecting the cardiac arrhythmia condition.

[0018] In the cardiac monitoring system, the external wearable cardiac device may be further configured to sense one or more heart sound signals from the patient; the memory may be configured to store heart sound data derived from the one or more heart sound signals; determining the occurrence of the priority event may include determining the occurrence of the priority event based on a subset of the ECG data and a subset of the heart sound data; and the at least one processor may be further configured to transmit the heart sound data to the remote storage service via the network interface using the second communication protocol. The heart sound data may include one or more of S1, S2, S3, and S4.

[0019] The at least one processor may also be configured to: receive a message specifying one or more device settings associated with the external wearable cardiac device via a subscription to a device-specific topic implemented using the first communication protocol, the device-specific topic being different from the first topic; and apply the one or more device settings to one or more operating parameters of the external wearable cardiac device. The memory may be configured to store a device identifier that uniquely identifies the external wearable cardiac device among a plurality of external wearable cardiac devices; and the at least one processor may also be configured to subscribe to the device-specific topic using the device identifier. The device identifier may be stored in the memory during manufacture of the external wearable cardiac device; and the device-specific topic may include a copy of the device identifier stored in the memory. The at least one processor may also be configured to: generate an authentication code; and verify that the message specifying the one or more device settings includes the authentication code. The one or more device settings may include a positioning setting.

[0020] In the cardiac monitoring system, the at least one processor may be further configured to: receive a message specifying one or more patient settings associated with a patient wearing the external wearable cardiac device via a subscription to a patient-specific topic implemented using the first communication protocol, the patient-specific topic being different from the first topic; and apply the one or more patient settings to one or more operating parameters of the external wearable cardiac device. The external wearable cardiac device may include: one or more monitoring electrodes configured to sense the one or more ECG signals; and one or more therapy electrodes configured to deliver electrical therapy to the patient's skin; and the one or more patient settings may include one or more shock settings assigned to the electrical therapy.

[0021] In the cardiac monitoring system, the message for specifying the priority event may also specify an identifier of the ECG data. The cardiac monitoring system may further include the remote storage service, wherein the remote storage service may be configured to: receive the ECG data using the second communication protocol; and publish a message identifying the ECG data to a second topic using the first communication protocol, the second topic being different from the first topic. The cardiac monitoring system may further include a message handling service, wherein the message handling service is configured to: receive a message for specifying the priority event; receive a message identifying the ECG data; and in response to receiving the message for specifying the priority event, communicate a notification message to a reporting service. The cardiac monitoring system may further include the reporting service, wherein the reporting service may be configured to communicate a warning message specifying the connection between the priority event and the ECG data in response to receiving the notification message.

[0022] In the cardiac monitoring system, the externally wearable cardiac device may include security credentials created during manufacture of the externally wearable cardiac device; and the message handling service may be further configured to register the security credentials and authenticate communications from the externally wearable cardiac device using the security credentials. In the cardiac monitoring system, the security credentials may include a device identifier uniquely identifying the externally wearable cardiac device among a plurality of externally wearable cardiac devices; and the message handling service may be further configured to identify the externally wearable cardiac device using the device identifier.

[0023] In the cardiac monitoring system, transmitting the ECG data to the remote storage service may include: publishing a message for specifying a request for an upload link to a second topic different from the first topic, and receiving a message for specifying the upload link via a subscription to a device-specific topic implemented using the first communication protocol, the device-specific topic being different from the first topic and the second topic; and transmitting the ECG data to the remote storage service via the upload link.

[0024] In the cardiac monitoring system, the first communication protocol may be Message Queuing Telemetry Transport (MQTT), and the second communication protocol may be Hypertext Transfer Protocol (HTTP).

[0025] In another example, a cardiac treatment system for use in bandwidth-challenged environments may be provided. The cardiac treatment system includes an external wearable cardiac device configured to sense one or more ECG signals from a patient wearing the external wearable cardiac device and deliver electrical therapy in response to detecting an arrhythmia condition occurring in the patient. The external wearable cardiac device includes at least one processor configured to: receive a first message specifying one or more patient settings associated with the patient via a subscription to a patient-specific topic implemented in a bandwidth-efficient communication protocol; receive a second message specifying one or more device settings associated with the external wearable cardiac device via a subscription to a device-specific topic implemented in the bandwidth-efficient communication protocol; apply the one or more patient settings and the one or more device settings to a plurality of operating parameters of the external wearable cardiac device; and control operation of the external wearable cardiac device based on the plurality of operating parameters.

[0026] Examples of the cardiac treatment system may incorporate one or more of the following features.

[0027] In the cardiac treatment system, the one or more patient settings may specify one or more of a value for a patient baseline parameter, a value for a lead preference parameter, a value for a ventricular fibrillation rate parameter, a value for a ventricular tachycardia rate parameter, and a value for an electrotherapy energy parameter.

[0028] In the cardiac treatment system, the one or more device settings may specify one or more of a value of a location parameter, a value of a message handling service URL, and a value of an account lock parameter.

[0029] The cardiac treatment system may further include a device control service configured to: receive input specifying the one or more patient settings and the one or more device settings; generate the first message and the second message based on the input; publish the first message to the patient-specific topic; and publish the second message to the device-specific topic. In the cardiac treatment system, the at least one processor may further be configured to: generate a first authentication code and a second authentication code; and verify that the first message includes the first authentication code and that the second message includes the second authentication code.

[0030] In the cardiac treatment system, the bandwidth efficient communication protocol may be MQTT, Constrained Application Protocol (CoAP), Advanced Message Queuing Protocol (AMQP), Lightweight Machine-to-Machine Protocol (LWM2M), or Data Distribution Service (DDS).

[0031] In the cardiac treatment system, controlling the operation of the externally wearable cardiac device may include: deriving ECG data from the one or more ECG signals; detecting the arrhythmia condition via the ECG data; controlling the delivery of the electrical therapy in response to detecting the arrhythmia condition; controlling the publication of a third message specifying the patient's arrhythmia condition to a first topic using the bandwidth-efficient communication protocol, the first topic being distinct from the patient-specific topic and the device-specific topic; and controlling the transmission of the ECG data to a remote storage service using a transfer protocol distinct from the bandwidth-efficient communication protocol. The transfer protocol may be Hypertext Transfer Protocol (HTTP) or File Transfer Protocol (FTP). The ECG data may include one or more of an ECG segment, heart rate, QRS duration, and QTC interval. Controlling the operation of the externally wearable cardiac device may also include: controlling the acquisition of one or more heart sound signals from the patient; deriving heart sound data from the heart sound signals; and controlling the transmission of the heart sound data to the remote storage service using the transfer protocol. The heart sound data may include one or more of S1, S2, S3 and S4.

[0032] The cardiac treatment system may further include the remote storage service, wherein the remote storage service may be configured to: receive the ECG data using the transfer protocol; and publish a fourth message identifying the ECG data to a second topic using the bandwidth-efficient communication protocol, the second topic being distinct from the first topic, the device-specific topic, and the patient-specific topic. The third message specifying the cardiac arrhythmia condition may further specify an identifier for the ECG data. The cardiac treatment system may further include a message handling service, wherein the message handling service is configured to: receive the third message specifying the cardiac arrhythmia condition of the patient; receive the fourth message identifying the ECG data; and, in response to receiving the third message specifying the cardiac arrhythmia condition of the patient, communicate a warning message to a reporting service. The cardiac treatment system may further include the reporting service, wherein the reporting service may be configured to communicate a warning message specifying a connection between the cardiac arrhythmia condition of the patient and the ECG data in response to receiving the notification message. In the cardiac treatment system, the externally wearable cardiac device may include security credentials created during manufacture of the externally wearable cardiac device; and the message handling service may be further configured to: register the security credentials, and use the security credentials to authenticate communications from the externally wearable cardiac device.

[0033] In the cardiac treatment system, the security credentials may include a device identifier for uniquely identifying the external wearable cardiac device among a plurality of external wearable cardiac devices; and the message handling service may be further configured to use the device identifier to identify the external wearable cardiac device. In the cardiac treatment system, the device-specific topic is a first device-specific topic; transmitting the ECG data to the remote storage service includes: publishing a fourth message specifying a request for an upload link to a second topic that is different from the first topic, the first device-specific topic, and the patient-specific topic; receiving a fifth message specifying the upload link via a subscription to the second device-specific topic, the second device-specific topic being different from the first topic, the second topic, the first device-specific topic, and the patient-specific topic; and transmitting the ECG data to the remote storage service via the upload link. In the cardiac treatment system, controlling the operation of the external wearable cardiac device may further include: collecting device event data indicating the ability of the external wearable cardiac device to sense the one or more ECG signals and to release the electrical therapy; and publishing a fourth message specifying the device event data collected by the external wearable cardiac device to the first topic. In the cardiac treatment system, the device event data may include one or more of a hold response button condition, a disconnected therapy electrode condition, and a cannot treat condition. BRIEF DESCRIPTION OF THE DRAWINGS

[0034] Various aspects of at least one example are discussed below with reference to the accompanying drawings, which are not intended to be drawn to scale. The accompanying drawings are included to provide illustration and further understanding of the various aspects and examples and are incorporated into and constitute a part of this specification, but are not intended to limit the scope of the present disclosure. The accompanying drawings, together with the rest of the specification, serve to explain the principles and operation of the described and claimed aspects and examples. In the drawings, each identical or nearly identical component illustrated in various figures is represented by the same reference numeral. For clarity, not every component may be labeled in every figure.

[0035] Figure 1 is a schematic diagram of a cardiac monitoring system according to examples disclosed herein.

[0036] Figure 2 According to the examples disclosed in this article Figure 1 Schematic diagram of some features of a cardiac monitoring system.

[0037] Figure 3 According to the examples disclosed in this article Figure 1 Schematic diagram of some features of a cardiac monitoring system.

[0038] Figure 4is a schematic diagram of a controller of a wearable medical device according to examples disclosed herein.

[0039] Figure 5A and Figure 5B is a sequence diagram illustrating a provisioning and configuration process performed by a cardiac monitoring system according to examples disclosed herein.

[0040] Figure 5C is a flow chart illustrating a message handling process performed by a cardiac monitoring system according to examples disclosed herein.

[0041] Figure 5D and Figure 5E is a sequence diagram illustrating another configuration process performed by a cardiac monitoring system according to examples disclosed herein.

[0042] Figure 5F is a flow chart illustrating a message handling process performed by a cardiac monitoring system according to examples disclosed herein.

[0043] Figure 6A and Figure 6C is a sequence diagram illustrating a process performed by a cardiac monitoring system to issue a priority event according to examples disclosed herein.

[0044] Figure 6B is a flow chart illustrating another message handling process performed by a cardiac monitoring system according to examples disclosed herein.

[0045] Figure 7A and Figure 7B is a sequence diagram illustrating processing of communication batch data performed by a cardiac monitoring system according to examples disclosed herein.

[0046] Figure 7C is a flow chart illustrating a batch data file handling process performed by a cardiac monitoring system according to examples disclosed herein.

[0047] Figure 7D is a flow chart illustrating another message handling process performed by a cardiac monitoring system according to examples disclosed herein.

[0048] Figure 8 is a sequence diagram illustrating a process performed by a cardiac monitoring system to control a remote device according to examples disclosed herein.

[0049] Figure 9 is a schematic diagram of a computing device according to examples disclosed herein.

[0050] 10A to 10D Example ambulatory cardiac devices according to examples disclosed herein are illustrated.

[0051] Figure 11Illustrated are example user interface screens for classifying events detectable by an ambulatory cardiac device as priority events according to examples disclosed herein. DETAILED DESCRIPTION

[0052] Mobile medical devices, due to their mobility, need to operate in a variety of regularly changing environments. For example, consider a mobile cardiac device, such as a mobile cardiac telemetry (MCT) device or a wearable cardioverter-defibrillator (WCD). Such devices are often prescribed to patients dealing with serious (if not life-threatening) conditions and require continuous use to record accurate electrocardiogram (ECG) information for patient diagnosis and treatment. In the case of a WCD, continuous use protects the patient while the ECG information is being recorded. For these devices, the need for continuous use contributes to a diverse operating environment because mobile patients wear the device while performing daily activities. Such activities can include sleeping, going to work, exercising, etc. Each of these activities can bring the patient, and therefore the medical device, to a new environment with different operating conditions.

[0053] The varying operating conditions experienced by mobile cardiac devices present challenges to successful operation. For example, temperature and humidity may impact the ability of a mobile cardiac device to acquire, store, and transmit ECG information related to a patient, for example, because these conditions may affect the quality of the connection between the device's electrodes and the patient's skin. Similarly, network conditions may impact the quality of the connection between the mobile medical device and the network over which data is reported. Example implementations, including the systems, devices, methods, and computer program products described herein, address these challenges. The mobile cardiac devices described herein include features configured to enable the device to efficiently wirelessly transmit ECG information while being worn by a patient in various bandwidth-challenged environments. In this regard, the systems and methods described herein include messaging services for monitoring and / or managing various aspects of the connection between the mobile cardiac device and a network access point. The features described herein provide for monitoring and / or managing these aspects, enabling the mobile cardiac device to successfully transmit recorded ECG information while navigating bandwidth-challenged environments. The example systems, devices, methods, and computer program products described herein provide a messaging service capable of robust operation even when connection strength degrades to the point where the connection becomes bandwidth-challenged (e.g., available bandwidth <.25 Mbps, <.5 Mbps, <1 Mbps, <2 Mbps, depending on the amount of data being transmitted). In these environments, the messaging service enables the ambulatory cardiac device to transmit recorded ECG information in a timely manner. Thus, the example systems, devices, methods, and computer program products described herein help reduce potential harmful effects on a patient, where the ECG information indicates the occurrence of a priority event (such as a patient's cardiac arrhythmia condition or other device-critical event, including events that may adversely affect the safety-critical function of the device). In examples, an ambulatory cardiac device as disclosed herein can minimize the use of battery power in certain situations (e.g., where the device may need to increase the power supplied to its radio subsystem to enhance connection strength), consuming power on communications, thereby limiting the power available for other medical device functions. Thus, implementations as described herein minimize the use of battery power on communications and reduce deleterious effects, particularly where the medical device is a WCD and is therefore configured to use battery power to deliver therapeutic pulses (e.g., cardioversion or defibrillation pulses) to a patient in the event that a treatable, life-threatening arrhythmia condition (e.g., VT or VF) is detected in the patient. One or more advantages of the improved messaging service as described herein include the following. The messaging service as described herein ensures message delivery in a variety of bandwidth-challenged environments. For example, a mobile cardiac device is a mobile object that is also a battery-powered device. This can cause the connection of the mobile cardiac device to a network access point to become unstable in certain environments and for certain purposes. In cardiac care settings where devices often handle life-threatening and safety-critical features, it is desirable to improve the reliability of communications.The example message service features described herein minimize data loss and / or duplication. Another benefit of the message service disclosed herein is that the service is lightweight. For example, the message service is configured to support a growing number of mobile cardiac devices, each of which can be configured for low onboard memory and processing power usage. In this context, the message service described herein is lightweight because it is well suited for such mobile cardiac devices—more so than services based on conventional protocols (e.g., HTTP). This is because, for example, an HTTP header can typically include approximately 8,000 bytes, while the improved message service described herein can include less than approximately 2 bytes to approximately 10 bytes. Another advantage of the present message service is that it conserves battery power. For example, it is expected that the battery power consumption of the present message service can be approximately 170 times less energy on a 3G network and approximately 50 times less energy on a Wi-Fi network when compared to standard HTTP. As another advantage, the present message service is universal and can operate on a variety of communication networks (including communication networks based on the Internet Protocol TCP / IP, or any ordered, lossless, and bidirectional network). The messaging service may also operate over non-TCP / IP networks (eg, ZigBee), UDP, or wireless ad hoc networks or wireless sensor networks (WSNs).

[0054] At least some of the examples described herein demonstrate an understanding of the challenges faced by mobile cardiac devices as described above. In these examples, a cardiac monitoring system balances the need to immediately report priority events (e.g., a patient's cardiac arrhythmia condition or other device-critical events, including events that may adversely affect the safety-critical functions of the device) with the need to conserve power. The systems, devices, methods, and computer program products described herein provide an improved messaging service for facilitating communication between a mobile cardiac device and a remote server. For example, in some examples, the messaging service as described herein facilitates reporting of priority events detected by the mobile cardiac device via a first pipeline that prioritizes reporting speed over power efficiency, and reporting of routine events detected by the mobile cardiac device via a second pipeline that prioritizes power efficiency over reporting speed.

[0055] To enhance reporting speed and robustness, the first pipeline involves fewer operations and utilizes bandwidth-efficient protocols, including a publish / subscribe messaging service such as an MQTT protocol implementation (e.g., based on specifications such as MQTT-SN v1.2, MQTT 3.1, MQTT 3.1.1, or MQTT 5 from the OASIS Message Queuing Telemetry Transport Technology Association) for communication. The use of bandwidth-efficient protocols increases the robustness of communication functionality relative to bandwidth-challenged environments. The first pipeline includes, for example, a priority pipeline for responding to priority events such as a patient's cardiac arrhythmia condition or a device-critical event, including events that may adversely affect the safety-critical function of the device. Priority events processed via the priority pipeline may include, for example, the occurrence of a patient condition (e.g., the occurrence of a treatable or non-treatable arrhythmia condition, a syncope, etc.) and / or the occurrence of a device-critical condition (e.g., a disconnection of electrodes from a patient, a device-critical error that prevents treatment of the patient, etc.). Other examples of treatable arrhythmia conditions include bradycardia, tachycardia, and asystole, which can be treated by delivering pacing pulses transcutaneously to the patient. In implementation, the WCD can treat VF and VT events and monitor and record ECG information related to bradycardia, tachycardia, and / or asystole. For example, a WCD monitoring bradycardia, tachycardia, and / or asystole can provide warnings and notifications related to these bradycardia, tachycardia, and / or asystole events directly to the patient (e.g., via a user interface module integrated into the WCD monitor, a smartphone, or other electronic device carried by the patient).

[0056] In an example, non-treatable arrhythmia conditions may also be monitored, including conditions that the device may not treat but instead monitor and record ECG information for use in issuing warnings and notifications and / or for transmission to a remote location for additional analysis. Examples of these non-treatable arrhythmia conditions include pulseless electrical activity (PEA), cardiac arrest, atrial fibrillation, ectopic beats, premature ventricular contractions (PVC) counts, bigeminy, trigeminy, etc. Examples of device-critical errors that may adversely affect the safety-critical functions of the device and prevent patient treatment include lack of properly deployed (or deployable) conductive gel and insufficient remaining battery power, etc.

[0057] In some examples, the priority pipeline originates from a medical device. In these examples, the medical device transmits a message to a message service for specifying a priority event, for example, the message includes information indicating the nature of the priority event and other details. For example, the nature of the priority event can be whether the event is a patient priority event or a device priority or critical event. For example, patient priority events include events such as life-threatening cardiac arrhythmias occurring in a patient, including VT and / or VF. For example, the systems, devices, methods and / or computer program products provided herein include one or more configurable parameters to permit a health care provider (HCP) such as an authorized technician, caregiver or physician (e.g., via a user interface) to indicate a priority event. For example, a caregiver can use one or more configurable parameters to indicate that patient priority events include events such as cardiac arrhythmias of the patient, including bradycardia episodes, tachycardia episodes and / or asystole events. For example, device priority or critical events include device critical errors as described above, which may affect the safety function of the device and / or the ability of the device to provide life-saving treatment to the patient. Examples of such device critical errors include detection of a fault in the gel deployment system, an electrode detachment or poor body contact issue, insufficient battery power to issue appropriate action, and the like. These critical errors and further examples of diagnostic self-tests that can be used to detect them are described in U.S. Patent No. 10,272,010, entitled "SYSTEMS AND METHODS FOR TESTING A MEDICAL DEVICE," issued April 30, 2019, and included herein as Appendix A. For example, the systems, devices, methods, and / or computer program products provided herein include one or more configurable parameters to permit an authorized technician, caregiver, or physician (e.g., via a user interface) to indicate device priority or critical events. For example, a caregiver can use one or more configurable parameters to indicate device priority or critical events including events such as a gel deployment system failure event or an electrode detachment event.

[0058] If the messaging service supports a publish-subscribe protocol, such as an MQTT implementation, the medical device publishes messages to a data upload topic to which a record processor and a reporting service subscribe. The record processor, in turn, processes the messages to extract priority data and stores the priority data in a data store accessible to the reporting service. For example, the priority data may include ECG data, patient annotations, timestamps, and other such medically relevant information associated with the patient's cardiac arrhythmia condition. For example, the priority data may include timestamps, device diagnostics, or technical log information related to device critical events (including events that could adversely impact the safety-critical function of the device). The reporting service receives the messages, retrieves the priority data, and interoperates with a healthcare provider (HCP) interface program (e.g., a browser-based application, a local application, etc.) to alert the HCP of the priority events. In an example, the reporting service includes functionality for determining the nature of the priority data (e.g., whether it is patient priority data or device priority data). In an example, the reporting service includes functionality for determining to alert the HCP if the priority event includes a patient priority event. In an example, the reporting service includes functionality for determining to alert a technician or other designated service representative if the priority event includes a device priority or critical event. Additional details regarding the apparatus and process for implementing prioritized pipelining are further described below.

[0059] To improve power efficiency, the second pipeline utilizes power-efficient operations to limit the use of other power-inefficient operations. For example, routine data processed by the second pipeline is batched (e.g., delayed and collected into dense groups in memory) and compressed into batch data files before being transmitted via the radio. By batching the routine data, the medical device needs to transmit the routine data via the radio at a lower frequency than would be required without batching. This feature saves a significant amount of battery power. Additionally, by compressing the batch data files before transmission, the radio consumes less power during the transmission of the compressed batch data files than during the transmission of the uncompressed batch data files. This second pipeline includes, for example, a routine pipeline for communicating routine events. Examples of routine events include the occurrence of normal patient physiological conditions and satisfactory device operating conditions. More specifically, in some examples, the routine data included in the batch data files includes data describing device wear time, patient body position, and patient heart rate trends.

[0060] In some examples, a routine pipeline originates from a medical device. The medical device interacts with a storage service to upload a batch data file to a file store. The storage service includes a publisher that monitors the file store for new batch data files. The publisher extracts individual data records from the batch data file and transmits a message for each data record to a messaging service. If the messaging service supports a publish-subscribe protocol such as MQTT, the publisher publishes the message to a batch data topic to which a record processor subscribes. The record processor, in turn, processes the message to extract the routine data and stores the routine data in a data store accessible by a reporting service.

[0061] Other features of the cardiac monitoring systems and methods described herein promote power efficiency and / or robust communication, among other benefits, in the face of changing operating environments. For example, in some examples, the messaging service is configured to insert an identifier of the medical device transmitting the message within certain types of messages received from a medical device. This feature enables the medical device to transmit less data within these types of messages, thereby saving power.

[0062] In some examples, a cardiac monitoring system provides subscription-based access to processing hosted on a medical device and processing hosted in a data center environment that is part of the cardiac monitoring system. This subscription-based access enables one message published to a particular topic to reach many subscribers to that topic, which enables efficient distribution of information.

[0063] In order to achieve precise communication while using a subscription-based protocol, some examples disclosed herein implement device-specific and patient-specific topics. These topics enable messages to be sent to a specific mobile cardiac device using, for example, the bandwidth-efficient MQTT protocol. This level of precision is required for some types of messages (e.g., messages related to medical device configuration). In some examples, configuration messages are generated and transmitted by a cloud-based control service. The control service enables the HCP to remotely modify the operating parameters of the mobile cardiac device via the transmitted messages. In some examples, the HCP can access the cloud-based service via an HCP interface program that interoperates with the control service to generate configuration messages.

[0064] Now, let's discuss an example of mobile cardiac device configuration. Configuration parameters (including operational parameters) for the mobile cardiac device that can be remotely modified using the control service include patient operational parameters and device operational parameters. Examples of patient operational parameters include patient name, patient ECG baseline, patient prescription parameters, cardiac rehabilitation prescription parameters, whether the patient needs to complete a health survey and how often, preferred ECG sensor leads, patient identifier, patient language, therapy pulse energy level, sleep mode hours, sleep mode treatment delay, speaker volume, time zone, threshold number of days between uploads that, if exceeded, will result in an alert, ventricular fibrillation threshold rate, ventricular tachycardia threshold rate, threat delay time, and whether the patient needs to complete a walk test and how often. Examples of device operational parameters include location parameters (e.g., a list of available languages, a list of supported time zones), a URL for connecting to a messaging service, number of days between diagnostic recordings, physiological signals to be recorded (e.g., ECG, heart sounds, etc.), and a threshold number of login attempts, which, if exceeded, will cause the mobile cardiac device to lock the account of a failed login attempt.

[0065] In some examples, the mobile cardiac device is configured to interoperate with the storage service to upload a detailed data file for a specified ECG segment as a supplement to the priority data for a specified patient arrhythmia. In these examples, the priority data includes a reference to the detailed data file so that the reporting service can locate the detailed data file if requested by the HCP.

[0066] Now refer to Figures 1 to 11 Example systems and methods that achieve and provide the aforementioned aspects and advantages are described in detail.

[0067] Figure 1 is a schematic diagram of a cardiac monitoring system 100 configured to monitor and treat a patient according to some examples. Figure 1 As shown, the system 100 includes one or more ambulatory cardiac devices 108A-108N. MD (collectively referred to as ambulatory cardiac devices 108), one or more HCP devices 104A-104N HD (collectively referred to as HCP device 104), data center environment 102, and communication network 106. HCP device 104 is configured to host one or more HCP interface applications 122A-122N HI (collectively referred to as HCP interface applications 122) and communicate with one or more HCPs 110A-110N HP (collectively referred to as HCP 110). The ambulatory cardiac device 108 is associated with one or more ambulatory patients 112A-112N PTThe HCP device 104, the mobile cardiac device 108, and the data center environment 102 are associated with the patient 112 (collectively, the patient 112) and are configured to monitor physiological data generated by the patient 112 as the patient 112 performs their daily activities. Thus, in some examples, the mobile cardiac device 108 can be worn by the patient 112. The HCP device 104, the mobile cardiac device 108, and the data center environment 102 are coupled to the network 106 and communicate with each other via the network 106. The mobile cardiac device 108, the HCP device 104, the data center environment 102, and the network 106 each include (e.g., as described below with reference to Figure 9 The association between users (eg, HCP 110 and patient 112 ) and their devices (eg, HCP device 104 and ambulatory cardiac device 108 ) is established during user authentication to system 100 .

[0068] like Figure 1 As shown, the data center environment 102 may include physical space, communications, cooling, and power infrastructure to support the networking operations of computing devices. For example, the infrastructure may include rack space in which computing devices are installed, uninterruptible power supplies, cooling and ventilation systems and equipment, and networking devices. The data center environment 102 may be dedicated to the cardiac monitoring system 100, may be a non-dedicated, commercially available cloud computing service (e.g., MICROSOFT AZURE, AMAZON WEBSERVICES (AWS), or GOOGLE CLOUD, etc.), or may include a hybrid configuration consisting of dedicated and non-dedicated resources. Regardless of its physical or logical configuration, such as Figure 1 As shown, the data center environment 102 is configured to host a patient reporting service 114 , an ambulatory cardiac device control service 116 , a message handling service 118 , and a storage service 120 .

[0069] continue Figure 1 In the example of , the messaging service 118 is configured to connect with and route messages between the ambulatory cardiac device 108 , the reporting service 114 , the control service 116 , and the storage service 120 . In operation, the messaging service 118 implements a secure, scalable, and reliable communication backbone within the system 100 .

[0070] For example, in some examples, the messaging service 118 connects to the mobile cardiac device 108, authenticates the mobile cardiac device 108, and exchanges messages with the mobile cardiac device 108. The messages exchanged with the mobile cardiac device 108 may specify a wide range of information. For example, some messages exchanged with the mobile cardiac device 108 include data specifying settings for operating parameters of the mobile cardiac device 108. Other messages include data specifying the operational readiness of the mobile cardiac device 108. Other messages include operational data collected by the mobile cardiac device 108 relating to the mobile cardiac device 108. Other messages may include data specifying a request generated by the control service 116 for the mobile cardiac device 108 to perform a programmed operation and a response to the request generated by the mobile cardiac device 108. Other messages include data specifying clinical data collected by the mobile cardiac device 108 relating to the patient 112. Other messages may include data requesting one or more links to which the mobile cardiac device 108 may upload one or more files generated by the mobile cardiac device 108. The following references Figures 5A to 8 Examples of these and other types of messages are described in further detail.

[0071] In some examples, the messaging service 118 exchanges messages with the reporting service 114. These messages may include, for example, data specifying priority events detected by the ambulatory cardiac device 108. Figure 6A and Figure 6C These and other examples of messages exchanged between messaging service 118 and reporting service 114 are described in further detail.

[0072] In some examples, the messaging service 118 exchanges messages with the control service 116. These messages may include, for example, data specifying settings for operating parameters of the mobile cardiac device 108. Other messages may include data specifying requests generated by the control service 116 for the mobile cardiac device 108 to perform programmed operations and responses to the requests generated by the mobile cardiac device 108. Figure 5D 、 Figure 5E and Figure 8 Examples of these and other types of messages are described in further detail.

[0073] In some examples, the messaging service 118 exchanges messages with the storage service 120. These messages may include, for example, data specifying requests for links to storage locations configured to receive and store files generated by the mobile cardiac device 108 and responses to these requests. Other messages may include data specifying settings for operating parameters of the mobile cardiac device 108. Other messages include data specifying operational readiness of the mobile cardiac device 108. Other messages include operational data collected by the mobile cardiac device 108 relating to the mobile cardiac device 108. Other messages include data specifying clinical data collected by the mobile cardiac device 108 relating to the patient 112. 5A to 7D Examples of these and other types of messages are described in further detail. It should be noted that in some examples, the messages or data records mentioned herein may be written in JavaScript Object Notation (JSON), although other suitable encoding standards will be apparent in view of this disclosure. Since there can be different types of configuration values (e.g., strings, integers, floating points), JSON can be used to store configuration settings because it is supported by nearly every major programming language and has great support and adoption. In an example, an ambulatory cardiac device may include a configuration file that stores its current settings in a JSON file. An example JSON record is as follows, which presents a periodic heart rate data record.

[0074]

[0075] In some examples, the messaging service 118 exposes and implements application programming interfaces (APIs) that support communication via one or more specialized protocols. For example, in some examples, the messaging service 118 supports bandwidth-efficient protocols that require less traffic and provide greater throughput than the Hypertext Transfer Protocol (HTTP). In some examples, the messaging service 118 supports a bidirectional protocol that, unlike HTTP, enables duplex communication of packets between devices within a single communication session. In some examples, the messaging service 118 supports a high-reliability protocol that can guarantee packet delivery subject to time-to-live constraints. In some examples, the messaging service 118 supports a publish-subscribe protocol that maintains a list of topics to which authenticated processes can publish messages and from which authenticated subscribing processes can receive messages. In some examples, the messaging service 118 exposes and implements Internet of Things (IoT) protocols that embody one or more of the specialized protocols listed above. Examples of some IoT protocols include MQTT, Constrained Application Protocol (CoAP), Advanced Message Queuing Protocol (AMQP), Lightweight Machine-to-Machine Protocol (LWM2M), and Data Distribution Service (DDS). Support for one or more of the above protocols enables the ambulatory cardiac device 108 to communicate effectively with the messaging service 118 even in bandwidth-challenged environments. Figures 5A to 8 Some examples of processing performed by message service 118 are further described.

[0076] Now go to Figure 2 , provides a diagram illustrating additional details about an example of a messaging service 118. The messaging service 118 is Figure 2 Zhongzai Figure 1 104, the HCP device 104, the reporting service 114, the storage service 120, and the ambulatory cardiac device 108. The messaging service 118 includes a broker 202, a message data store 204, an identity provider 208, and an identifier injector 210. In this example, the messaging service 118 communicates with other processes using a protocol that supports subscriptions and publications to topics, such as MQTT. Thus, the messaging service 118 is configured to receive messages for one or more topics from one or more publishers (e.g., processes within the messaging service 118 that are authorized to send messages). The messaging service 118 is also configured to deliver received messages to subscribers (e.g., processes within the messaging service 118 that are authorized to subscribe to one or more topics).

[0077] like Figure 2 As shown, the message data store 204 stores one or more topic records 206A-206N representing topics supported by the message service 118. TR(collectively referred to as topic records 206). Each topic record 206 includes a topic ID field and a publication field. A publication comprises a message that is communicated for delivery via a publish-subscribe protocol. The topic ID field stores individual values (e.g., as strings) of topic IDs that uniquely identify each topic. The publication field stores individual copies of, or references to, messages published to the topic identified by the topic ID. The publication field and a particular topic ID are associated with each other by being stored within the same topic record 206. It should be noted that in some examples, the publication field stores a reference (e.g., a pointer or some other form of address) to a persistent queue, stack, or other data structure (not shown) that holds publications for the topic identified by the topic ID. In these examples, the message service 118 is configured to allocate and control these queues, stacks, or other data structures. Figure 2 In the illustrated example, topic record 206A stores information for Figure 1 The data of the medical device 108A is uploaded to the publication of the topic, and the topic record 206N TR Storage for specific Figure 1 These and other topics are further described below.

[0078] In some examples, at least some of the subject records 206 within the data store 204 store a subject ID that is specific to each mobile cardiac device 108. In these examples, each device-specific subject ID uniquely identifies the mobile cardiac device among all the mobile cardiac devices 108. Examples of values that may be used as a device-specific subject ID include a string containing a serial number of the mobile cardiac device and / or a string containing a globally unique identifier (GUID) assigned to the mobile cardiac device, among other values. Alternatively or in addition, in some examples, at least some of the subject records 206 within the data store 204 store a subject ID that is specific to each patient 112. In these examples, each patient-specific subject ID uniquely identifies the mobile cardiac device. Figure 1 The patient from all patients 112 is represented by a list of patients. One example of a value that can be used as a patient-specific subject ID is a string comprising the patient's government-issued identification number. Another example of such a value is a string comprising a GUID or some randomly generated number assigned to the patient that uniquely identifies the patient. Other examples will be apparent in light of this disclosure. It should be noted that, depending on the implementation of system 100, a randomly generated patient identifier can provide privacy benefits over a government-issued identification number.

[0079] continue Figure 2In some examples, the identity provider 208 is configured to authenticate the mobile cardiac device 108 via security credentials communicated by the mobile cardiac device 108 to the messaging service 118 in a connection request. For example, in some examples, the identity provider 208 compares the security credentials with security information stored in the data store 204 and authenticates the mobile cardiac device if the security credentials match the security information.

[0080] continue Figure 2 In some examples, the identifier injector 210 identifies the mobile cardiac device 108 connected to the messaging service 118 via an association between the mobile cardiac device's 108 security credentials and a device ID stored in the data store 204. In these examples, the identifier injector 210 can manipulate data records stored in messages from the mobile cardiac device 108. This manipulation can include, for example, extending the data stored within the data record and / or supplementing the data stored within the data record with additional data (e.g., adding a quick copy of metadata, such as the device ID stored in the message data store 204). For example, in some examples, the identifier injector 210 adds a device identifier and / or a patient identifier to a data record generated by the mobile cardiac device 108. This post-receive manipulation of the data record by the identifier injector 210 is beneficial to the mobile cardiac device 108 because it enables the mobile cardiac device 108 to transmit less data (and therefore consume less power) for each message than would be required if metadata were transmitted in the data record. This power conservation can be particularly important if the mobile cardiac device 108 is battery-powered.

[0081] continue Figure 2 In some examples, the proxy 202 is configured to connect and exchange messages with the control service 116, the HCP device 104, the reporting service 114, the storage service 120, and the mobile cardiac device 108. In these examples, the connection with the proxy 202 can be established via one or more API calls defined by a protocol implemented by the messaging service 118. These API calls can be executed by a process requesting a connection with the proxy 202 during a handshake process performed by the requesting process and the proxy 202 to establish the connection. In some examples, the proxy 202 is configured to interoperate with the identity provider 208 to authenticate a process hosted by one of the mobile cardiac devices 108 that requested a connection during the handshake process (e.g., via security credentials passed as part of the connection request). After the connection is established, the proxy 202 can exchange messages with the requesting process using the protocol. Figure 2In some examples illustrated, messages exchanged between the agent and other processes can be publications to topics specified by the topic record 206. Thus, messages can be targeted to device-specific topics and / or patient-specific topics that can include device-specific identifiers and / or patient-specific identifiers. In this manner, the message service 118 provides a facility by which individual ambulatory cardiac devices 108 and / or individual patients 112 can be targeted as discrete recipients of individual messages, even when the protocol implements a topic-centric publish-subscribe paradigm.

[0082] In some examples, the agent 202 is configured to receive, process, and respond to authorization requests from the control service 116, the HCP device 104, the reporting service 114, the storage service 120, and the ambulatory cardiac device 108. These requests can specify one or more topic IDs, one or more types of communication operations for which authorization is requested specific to the topic ID, and one or more publishing quality of service (QoS) levels for which authorization is requested specific to the topic ID. The types of communication operations for which a process can request authorization include publishing a message to a topic, subscribing to messages from a topic, or both. The QoS levels for which a process can request authorization include delivering a message to each subscriber at most once, delivering a message to each subscriber at least once, and delivering a message to each subscriber exactly once.

[0083] In some examples, the proxy 202 is configured to parse a received authorization request to extract the subject ID, communication operation type, and QoS level sought by the requesting process. In these examples, the proxy 202 is also configured to evaluate preconfigured policies (e.g., one or more predetermined rules) to determine whether the requesting process is authorized to perform the requested communication operation type at the requested QoS level for the subject ID. If the proxy 202 determines that the requesting process is so authorized, the proxy 202 stores a record of the authorization within the data store 204, responds to the authorization request with a positive acknowledgement, and permits the requesting process to engage in the authorized communication operation type at the authorized QoS level for the authorized subject ID via subsequently received API calls. If the proxy 202 determines that the requesting process is not so authorized, the proxy 202 responds to the authorization request with an error message indicating a lack of authorization. In this manner, each mobile cardiac device 108 can be attributed only to a specific subject (e.g., a subject specific to each mobile cardiac device and / or a subject specific to the patient associated with the mobile cardiac device). This feature enhances data integrity and security by preventing a first mobile cardiac device from receiving information related to a second mobile cardiac device and / or preventing a first mobile cardiac device from publishing information under the guise of a second mobile cardiac device. It should be noted that authorization records may have a limited lifespan, and therefore, request processing may need to be reauthorized from time to time.

[0084] Return to Figure 1 In some examples, the storage service 120 is configured to interoperate with the reporting service 114, the control service 116, the messaging service 118, and the mobile cardiac device 108 to receive, process, store, and provide access to data records and files generated by the system 100. These data records may include, for example, settings for operating parameters of the mobile cardiac device 108, operational data generated by the mobile cardiac device 108, and clinical data generated by the mobile cardiac device 108. The files that the storage service 120 is configured to store may include detailed operational logs generated by the mobile cardiac device and batch data files that store multiple individual data records derived from the operational and clinical data generated by the mobile cardiac device 108. In some examples, the storage service 120 is configured to interoperate with the messaging service 118 to receive messages generated by the mobile cardiac device 108, the reporting service 114, and the control service 116. In some examples, the storage service 120 is also configured to publish messages, receive and respond to queries, and otherwise provide access to messages and files stored within the storage service 120. The following references 5A to 7D Some examples of the processing performed by storage service 120 are further described.

[0085] Now go to Figure 3 , illustrates an example of the storage service 120 in more detail. Figure 3 As shown, the storage service 120 includes a file store 308 , a publisher 306 , a link generator 304 , a record processor 302 , an active data store 310 , and an archived data store 312 . Figure 3 The storage service 120 is instantiated within the context of the reporting service 114 , the control service 116 , the messaging service 118 , and the ambulatory cardiac device 108 .

[0086] In at least some examples, the record processor 302 is configured to process messages generated by the mobile cardiac device 108 and received via the proxy 202 that specify settings for operating parameters, operational data, and clinical data. If the proxy 202 supports a publish-subscribe protocol, these messages can be published to one or more topics to which the record processor 302 subscribes. These one or more topics can be dedicated to the communication of data generated by and / or stored on the mobile cardiac device 108. In certain examples, the record processor 302 is configured to receive the messages, parse the messages to extract one or more data records therefrom, and store a copy of the original data record in an archived data store 312 and / or store data derived from the data record in an active data store 310 for subsequent querying. The derived data stored in the active data store 310 can include operational and clinical data accessible to the reporting service 114 and settings for operating parameters accessible to the control service 116. In some examples, the record processor 302 generates the derived data by manipulating the data stored in the received data records to prepare the data for access by the reporting service 114 and the control service 116. The following references Figures 5A to 6B 、 Figure 7A 、 Figure 7B and Figure 7D Examples of processing that record processor 302 is configured to perform are further described.

[0087] continue Figure 3 In some examples, the link generator 304 is configured to process messages specifying upload link requests generated by the mobile cardiac device 108 and received via the agent 202. If the agent 202 supports a publish-subscribe protocol, the messages may be published to one or more topics to which the link generator 304 subscribes. These one or more topics may be specific to link requests. In some examples, the link generator 304 is configured to receive a message from a link requester (e.g., any one of the mobile cardiac devices 108), parse the message to extract the link request therefrom, generate an upload link, and respond to the link requester with a response message. The response message may specify an upload link (e.g., a uniform resource locator (URL) or other link). The upload link may identify a data storage unit (e.g., a file storage unit 308) configured to receive and store the file 307 generated by the link requester. If the agent 202 supports a publish-subscribe protocol, the link generator 304 may respond to the link requester by publishing a response message to a topic related to a link response specific to the link requester. The topic may be specified within the link request. The following reference Figure 6C and Figure 7A An example of the processing that the link generator 304 is configured to perform is further described.

[0088] continue Figure 3 In some examples, the storage service 120 exposes and implements an API configured to receive requests to upload files generated by the mobile cardiac device 108. These files may store, for example, operational and / or clinical data collected by the mobile cardiac device 108. In some examples, to receive files, the storage service 120 implements an HTTP API that utilizes a representational state transfer (REST) architectural style. In these examples, the storage service 120 exposes and monitors one or more HTTP API endpoints as URLs to which the mobile cardiac device 108 can submit files for transfer and storage within the storage service 120 (e.g., within the file storage 308). In some examples, the URL that makes the storage service 120 available is a URL generated by the link generator 304 during link request processing. It should be noted that the protocol underlying the above-described file receiving API is not limited to HTTP. Other example file receiving APIs may utilize other protocols, such as file transfer protocol (FTP) and MQTT. It should also be noted that in at least one example, the file storage 308 is implemented as an AMAZON S3 object storage. The following references Figure 6C and Figure 7A An example of processing involving file store 308 that storage service 120 is configured to perform is further described.

[0089] continue Figure 3In some examples, publisher 306 is configured to process newly received batch data files stored in file storage 308. In some examples, these batch data files specify multiple individual operational and / or clinical data records generated by the mobile cardiac device 108. The batch data files can be compressed to reduce the resources (e.g., power, bandwidth, etc.) of the mobile cardiac device 108 required to communicate the batch data files to the file storage 308. In some examples, the batch data file processing performed by publisher 306 includes monitoring file storage 308 for newly received files that match one or more predetermined attributes (e.g., a particular type of file name, etc.) common to the batch data files, decompressing any newly received files that match the predetermined attributes, and parsing the files to extract the individual operational and / or clinical data records stored therein. In some examples, the processing performed by publisher 306 also includes generating a separate message for each of the individual data records extracted from the files and sending the separate message to agent 202 for downstream processing (e.g., by record processor 302). If the proxy 202 supports a publish-subscribe protocol, these individual messages may be published to one or more topics to which the record processor 302 subscribes. These one or more topics may be dedicated to the communication of data generated by and / or stored on the mobile cardiac device 108. 7A to 7C Examples of the processing that publisher 306 is configured to perform are further described.

[0090] Return to Figure 1 For example, the reporting service 114 is configured to process operational and clinical data received from the ambulatory cardiac device 108 and report the operational and clinical data, or data derived therefrom, to the HCP 110 via the HCP interface application 122. The operational and clinical data accessed by the reporting service 114 may be stored in, for example, Figure 3 In some examples, the reporting service 114 receives messages from the messaging service 118 specifying information related to events detected by the system 100. In these examples, the reporting service 114 interoperates with the storage service 120 to generate information related to the detected events and communicates the information to the HCP 110 via the HCP interface application 122. Figure 6A and Figure 6C Examples of the processing that reporting service 114 is configured to perform are further described.

[0091] continue Figure 1In some examples, the control service 116 is configured to retrieve settings of configurable operating parameters of the mobile cardiac device 108 and adjust the parameters to adapt the behavior of the mobile cardiac device 108 to the needs of the patient 112 determined by the HCP 110. For example, in some examples, the control service 116 retrieves the settings from the storage service 120 and publishes a message to the messaging service 118 specifying the adjusted settings. The settings accessed by the control service 116 may be stored in Figure 3 In addition, in some examples, the control service 116 receives a message published by the ambulatory cardiac device 108 from the messaging service 118, wherein the message specifies an error in the requested parameter adjustment. Figure 5D 、 Figure 5E and Figure 8 Examples of processing that the control service 116 is configured to perform are further described.

[0092] continue Figure 1 For example, the network 106 may include one or more public and / or private networks that support, for example, the Internet Protocol (IP). The network 106 may include, for example, one or more local area networks (LANs), one or more personal area networks (PANs), and / or one or more wide area networks (WANs). The LAN may include a wired or wireless network that supports various LAN standards, such as IEEE 802.11 versions. The PAN may include a wired or wireless network that supports various PAN standards, such as Bluetooth or ZIGBEE. The WAN may include a wired or wireless network that supports various WAN standards, such as the Code Division Multiple Access (CDMA) radio standard or the Global System for Mobile (GSM) radio standard. The network 106 connects the data center environment 102, the HCP device 104, and the mobile cardiac device 108, and enables data communication between the data center environment 102, the HCP device 104, and the mobile cardiac device 108. In at least some examples, data center environment 102 includes network devices (e.g., routers, switches, etc.) configured to communicate with network 106 and computing devices collocated with or near the network devices. It should be noted that in some examples, network 106 and any existing networks within data center environment 102 support other communication protocols, such as MQTT or other IoT protocols.

[0093] continue Figure 1In some examples, the HCP interface application 122 is configured to control the HCP device 104 during certain interactions between the HCP device 104 and the HCP 110. For example, in some examples, the HCP interface application 122 is configured to interoperate with the reporting service 114 and / or the control service 116 and interact with the HCP 110 to allow the HCP 110 to access reporting and / or control functionality provided by the reporting service 114 and / or the control service 116. The HCP interface application 122 can be implemented as a local application and / or a browser-based application. Figure 5D 、 Figure 5E 、 Figure 6A 、 Figure 6C and Figure 8 Examples of the processing that the HCP interface application 122 is configured to perform are further described.

[0094] It should be noted that in at least some examples, the services hosted by data center environment 102 are implemented using AWS IoT services and AMAZON S3 in conjunction with custom AWS LAMBDA code.

[0095] continue Figure 1 In some examples, the mobile cardiac devices 108 are configured to interoperate with other portions of the system 100 to monitor and / or treat the patient 112. In some examples, at least some of the mobile cardiac devices 108 are incorporated into a controller such as Figure 4 A cardiac monitoring and / or treatment device of the medical device controller 400, etc., schematically depicted in FIG.

[0096] like Figure 4 As shown, medical device controller 400 may include a housing 401, which may be physically integrated with or distinct from other portions of the medical device controlled by controller 400. Housing 401 may house therapy delivery circuitry 402 configured to deliver one or more therapy shocks to a patient via at least two therapy electrodes 420, a data storage unit 404, a network interface 406, a user interface 408, and at least one rechargeable battery 410. Housing 401 may also be configured to house a physiological sensor interface 412, a cardiac event detector 416, a data manager 440, at least one accelerometer 432, an accelerometer interface 430, and at least one processor 418. Physiological sensor interface 412 may be configured to interface with both ECG sensing electrodes 422 and non-ECG physiological sensors 423, such as vibration sensors, lung fluid sensors, infrared and near-infrared-based pulse oximetry sensors, blood pressure sensors, and other types of sensors.

[0097] In some examples, one or more of the ambulatory cardiac devices 108 includes a medical device controller that includes the same components as described above, but does not include the therapy delivery circuitry 402 and therapy electrodes 420 (shown in dashed lines). That is, in some implementations, the medical device may include only ECG monitoring components and not be configured to provide therapy to a patient. In such implementations, such as a heart failure management system (HFMS), a cardiac event monitor (CEM), or a mobile cardiac telemetry (MCT) device, the controller of the medical device is constructed similarly in many respects to the medical device controller 400, but need not include the therapy delivery circuitry 402 and associated therapy electrodes 420.

[0098] like Figure 4 As further shown in FIG, therapy delivery circuitry 402 may include or be operably connected to circuitry configured to generate and deliver an electrical therapy shock. The circuitry may include, for example, resistors, capacitors, relays and / or switches, a bridge such as an H-bridge (e.g., including a plurality of insulated gate bipolar transistors or IGBTs), voltage and / or current measurement components, and other similar circuitry components arranged and connected such that the circuitry components operate in coordination with the therapy delivery circuitry and under the control of one or more processors (e.g., processor 418) to, for example, deliver at least one therapy shock including one or more pacing, cardioversion, or defibrillation therapy pulses to a patient.

[0099] Pacing pulses may be used to treat cardiac arrhythmia conditions such as bradycardia (e.g., less than 30 beats per minute) and tachycardia (e.g., greater than 150 beats per minute) using, for example, fixed-rate pacing, demand pacing, and anti-tachycardia pacing. Defibrillation pulses may be used to treat ventricular tachycardia and / or ventricular fibrillation.

[0100] The capacitor may comprise a parallel-connected capacitor bank consisting of a plurality of capacitors (e.g., two, three, four, or more capacitors). In some examples, the capacitor may comprise a single film or electrolytic capacitor as a series-connected device comprising a group of identical capacitors. These capacitors may be switched into series connection during the discharge of the defibrillation pulse. For example, a single capacitor of approximately 140 μF or greater or four capacitors of approximately 650 μF may be used. The capacitor may have a rating of 1600 VDC or greater for a single capacitor or a surge rating of between approximately 350 and 500 VDC for parallel capacitors and may be charged from the battery pack in approximately 15 to 30 seconds.

[0101] For example, each defibrillation pulse can deliver between 60 and 180 joules of energy. In some implementations, the defibrillation pulse can be a biphasic truncated exponential waveform, whereby the signal can switch between a positive portion and a negative portion (e.g., charge direction). This type of waveform can effectively defibrillate the patient at a lower energy level when compared to other types of defibrillation pulses (e.g., such as monophasic pulses). For example, the amplitude and width of the two phases of the energy waveform can be automatically adjusted to deliver a precise amount of energy (e.g., 150 joules) regardless of the patient's body impedance. The therapy delivery circuit system 402 can be configured to perform switching and pulse delivery operations, for example, under the control of the processor 418. As energy is delivered to the patient, the amount of energy being delivered can be tracked. For example, even if the pulse waveform is dynamically controlled based on factors such as the patient's body impedance while the pulse is being delivered, the amount of energy can be maintained at a predetermined constant value.

[0102] In some examples, therapy delivery circuitry 402 can be configured to deliver a set of cardioversion pulses to correct, for example, a heart that is beating incorrectly. When compared to defibrillation as described above, cardioversion typically includes less powerful electrical shocks delivered at a frequency to simulate the heart's normal rhythm.

[0103] In some examples, the data manager 440 is configured to store data received, collected, and / or generated by the medical device during operation and to communicate at least some of the stored data to the messaging service 118 and the storage service 120. Examples of data that the data manager 440 is configured to manipulate include settings for operating parameters, operational data, and clinical data. If the received data includes settings for operating parameters, in some examples, the data manager 440 is configured to validate the received settings and, if the settings are valid, apply the settings. When applying the settings, the data manager 440 may store the values specified by the settings in a memory location referenced by the processor 418 during operation of the medical device to control the behavior of the medical device.

[0104] In some examples, the data manager 440 is configured to communicate at least some of the data via the network interface 406 via one or more compressed files storing a plurality of data records specifying operational data and clinical data. Alternatively or in addition, in some examples, the data manager 440 is configured to communicate at least some of the data specifying settings, operational data, and clinical data via the network interface 406 via one or more messages storing separate data records. These messages can specify a wide range of information. For example, some messages include data specifying settings for operating parameters of a medical device. Other messages include data specifying operational readiness of a medical device. Other messages include operational data collected by the medical device relating to the medical device. Other messages include messages specifying settings for a medical device. Figure 1Other messages may include data specifying a request generated by the control service 116 for a medical device to perform a programmatic operation and a response generated by the medical device to the request. Other messages may include data specifying clinical data collected by the medical device related to the patient. Other messages may include data requesting one or more links to which the medical device may upload one or more files generated by the medical device.

[0105] In some examples, operational data and / or clinical data communicated by data manager 440 is segmented into priority data (e.g., data specifying priority events) or routine data (e.g., data specifying routine events). Priority events can include any event from a set of enumerated events that are processed by system 100 using a priority pipeline that prioritizes processing speed over power efficiency. Examples of priority events include an arrhythmia condition, a hold response button, a disconnected electrode condition, and / or any critical error condition identified by a diagnostic self-test that renders the medical device unable to safely treat the patient. An example of a medical device controller configured to perform a diagnostic self-test that identifies and reports a critical error as a priority event is further described in U.S. Patent No. 10,272,010. Priority events can be contrasted with routine events, which are processed by system 100 using a routine pipeline that prioritizes processing power efficiency over speed. Examples of routine events include normal patient physiological conditions and satisfactory device operating conditions detected with respect to patient 112 and ambulatory cardiac device 108.

[0106] In some examples, the data manager 440 is configured to communicate priority data via a priority pipeline and to communicate routine data via a routine pipeline. In these examples, to communicate priority data via the priority pipeline, the data manager 440 packages the priority data into a data record, stores the data record as a payload of a message, and communicates the message to Figure 2 Agent 202. The priority data in these messages is determined by Figure 3 The record processor 302 processes and stores the Figure 3 The activity data store 310 is stored in the activity data store 310 and is presented to the HCP interface application 122 by the reporting service 114 via the HCP interface application 122. Figure 1 Furthermore, in these examples, to communicate routine data via the routine pipeline, the data manager 440 packages the routine data into batch data files and communicates with the Figure 3 The storage service 120 interoperates to transfer the compressed version of the bulk data file to Figure 3 The routine data in the batch data file is stored in the file storage unit 308. Figure 3The publisher 306 processes the messages to generate separate messages, each of which stores a separate data record as a payload. As described above with reference to the prioritized pipeline, the publisher 306 sends the separate messages to the broker 202 for subsequent processing by the record processor 302, the reporting service 114, and the HCP interface application 122.

[0107] exist Figure 2 In examples where the agent 202 supports a publish-subscribe protocol, the data manager 440 can be configured to communicate messages by publishing messages to one or more topics to which the record processor 302 subscribes. These one or more topics can be specifically for data communications performed by the data manager 440. Additionally or alternatively, in these examples, the data manager 440 can be configured to subscribe to one or more device-specific and / or patient-specific topics to ensure that messages published to these topics by the control service 116 and the storage service 120 are received by the data manager 440. The topic ID of the device-specific topic can incorporate an identifier (e.g., a serial number) of a medical device stored in the data store 404. The topic ID of the patient-specific topic can incorporate an identifier (e.g., a randomly generated string) of a patient stored in the data store 404. The following references Figures 5A to 8 Examples of the processing that data manager 440 is configured to perform are further described.

[0108] The data manager 440 may be configured to operate under the control of the processor 418 to perform one or more operations as described herein. The data manager 440 may be implemented using hardware or a combination of hardware and software. For example, in some examples, the data manager 440 may be implemented as code stored within the data storage 404 and executed by the processor 418. In this example, the instructions included in the data manager 440 may cause the processor 418 to perform one or more of the operations attributed to the data manager 440 herein. In other examples, the data manager 440 may be an application specific integrated circuit (ASIC) coupled to the processor 418 and configured to perform one or more of the operations attributed to the data manager 440 herein. Thus, examples of the data manager 440 are not limited to a particular hardware or software implementation.

[0109] The data storage unit 404 may include one or more non-transitory computer-readable media, such as flash memory, solid-state memory, magnetic memory, optical memory, cache memory, combinations thereof, and the like. The data storage unit 404 may be configured to store code (e.g., executable instructions) and data for the operation of the medical device controller 400. In some examples, the data storage unit may include executable instructions that are configured to cause the processor 418 to perform one or more operations through their execution. In some examples, the data storage unit 404 may be configured to store information such as ECG data received from, for example, the physiological sensor interface 412. Alternatively or in addition, in some examples, the data storage unit 404 may be configured to store an IoT certificate (e.g., an X.509 certificate) for specifying a device ID (e.g., a serial number of a medical device). In these examples, Figure 1 The messaging service 118 may utilize the IoT certificate to authenticate the medical device and utilize a device identifier embedded in the IoT certificate to uniquely identify the medical device.

[0110] In some examples, the network interface 406 can facilitate information communication between the medical device controller 400 and one or more other devices or entities via a communication network. For example, in the case where the medical device controller 400 is included in a mobile medical device, the network interface 406 can be configured to communicate with a remote computing device (such as a remote server or other similar computing device). The network interface 406 can, for example, include a communication circuit system for transmitting data according to the Bluetooth wireless standard to exchange such data to an intermediate device over a short distance. For example, such an intermediate device can be configured as a base station, a "hotspot" device, a smartphone, a tablet computer, a portable computing device, and / or other devices near the wearable medical device including the medical device controller 400. The (one or more) intermediate devices can then communicate the data to the remote server via a broadband cellular network communication link. The communication link can implement broadband cellular technology (e.g., 2.5G, 2.75G, 3G, 4G, 5G cellular standards) and / or Long Term Evolution (LTE) technology or GSM / EDGE and UMTS / HSPA technology for high-speed wireless communication. In some implementations, the intermediary device(s) may communicate with the remote server via a WI-FI communication link based on the IEEE 802.11 standard.

[0111] In some examples, the user interface 408 may include one or more physical interface devices (such as input devices, output devices, and combined input / output devices) and a software stack configured to drive the operation of the device. These user interface elements may present visual, audio, and / or tactile content. Thus, the user interface 408 may receive input or provide output, thereby enabling a user to interact with the medical device controller 400.

[0112] The medical device controller 400 may also include at least one rechargeable battery 410 configured to provide power to one or more components of the medical device controller 400. The rechargeable battery 410 may include a rechargeable multi-cell battery pack. In one example implementation, the rechargeable battery 410 may include three or more 2200 mAh lithium-ion batteries that provide power to other components of the medical device controller 400. For example, the rechargeable battery 410 may provide a power output in the range of 20 mA to 1000 mA (e.g., 40 mA) output and may support a runtime of 24 hours, 48 hours, 72 hours, or more between charges. In some implementations, the battery capacity, runtime, and type (e.g., lithium-ion, nickel-cadmium, or nickel-metal hydride) may be varied to best suit the specific application of the medical device controller 400.

[0113] Physiological sensor interface 412 may include a physiological signal circuit system that is coupled to one or more sensors configured to monitor one or more physiological parameters of a patient. As shown, the sensor can be coupled to the medical device controller 400 via a wired or wireless connection. The sensor may include one or more ECG sensing electrodes 422 and non-ECG physiological sensors 423, such as a vibration sensor 424, (e.g., based on an ultra-wideband RF device) tissue fluid monitor 426, and a motion sensor (e.g., an accelerometer, a gyroscope, and / or a magnetometer). In some implementations, in addition to digital sensing electrodes, the sensor may also include a plurality of conventional ECG sensing electrodes.

[0114] Sensing electrodes 422 can be configured to monitor ECG information of a patient. For example, by design, digital sensing electrodes 422 can include skin-contacting electrode surfaces that can be considered polarizable or non-polarizable, depending on various factors, including the metal and / or coating used to construct the electrode surface. All such electrodes can be used with the principles, techniques, devices, and systems described herein. For example, the electrode surface can be based on stainless steel, a precious metal such as platinum, or Ag-AgCl.

[0115] In some examples, electrode 422 can be used with an electrolytic gel dispersed between the electrode surface and the patient's skin. In some implementations, electrode 422 can be a dry electrode that does not require an electrolytic material. As an example, such a dry electrode can be based on metallic tantalum and have a tantalum pentoxide coating as described above. Such a dry electrode may be more comfortable for long-term monitoring applications.

[0116] Return Reference Figure 4 The vibration sensor 424 can be configured to detect heart or lung vibration information. For example, the vibration sensor 424 can detect heart valve vibration information of the patient. For example, the vibration sensor 424 can be configured to detect heart vibration signal values including any one or all of S1, S2, S3, and S4. Based on these heart vibration signal values or heart vibration values, certain heart vibration metrics can be calculated, including any one or more of electromechanical activation time (EMAT), average EMAT, percentage EMAT (%EMAT), systolic dysfunction index (SDI), and left ventricular contraction time (LVST). The vibration sensor 424 can also be configured to detect heart wall motion, for example, by placing the sensor in the apex beat region. The vibration sensor 424 can include a vibration sensor configured to detect vibrations from the patient's cardiopulmonary system and provide an output signal in response to the detected vibrations of the target organ, for example, capable of detecting vibrations generated in the trachea or lungs due to air flow during breathing. In some implementations, additional physiological information can be determined from the lung vibration signal, such as, for example, lung vibration characteristics based on sounds generated within the lungs (e.g., wheezes, crackles, etc.). The vibration sensor 424 can also include a multi-channel accelerometer, for example, a three-channel accelerometer configured to sense movement in each of three orthogonal axes, so that patient movement / body position can be detected and correlated with detected cardiac vibration information. The vibration sensor 424 can transmit information describing the cardiac vibration information to the sensor interface 412 for subsequent analysis.

[0117] Interstitial fluid monitor 426 can use RF-based technology to assess the fluid level and accumulation in the patient's body tissue. For example, interstitial fluid monitor 426 can be configured to measure the fluid content in the lungs, which is commonly used for the diagnosis and follow-up of pulmonary edema or pulmonary congestion in heart failure patients. Interstitial fluid monitor 426 may include one or more antennas that are configured to guide RF waves through the patient's tissue and measure output RF signals in response to the waves that have passed through the tissue. In some implementations, the output RF signal includes parameters indicating the fluid level in the patient's tissue. Interstitial fluid monitor 426 can transmit information describing the interstitial fluid level to sensor interface 412 for subsequent analysis.

[0118] like Figure 4As further shown in FIG, the controller 400 may also include an accelerometer interface 430 and an accelerometer set 432. The accelerometer interface 430 may be operably coupled to each of the accelerometers 432 and configured to receive one or more outputs from the accelerometers. The accelerometer interface 430 may also be configured to condition the output signals by, for example, converting analog accelerometer signals to digital signals (if analog accelerometers are used), filtering the output signals, and combining the output signals into a combined directional signal (e.g., combining each x-axis signal into a composite x-axis signal, combining each y-axis signal into a composite y-axis signal, and combining each z-axis signal into a composite z-axis signal). In some examples, the accelerometer interface 430 may be configured to filter the signals using a high-pass or band-pass filter to isolate the acceleration of the patient due to movement from the component of acceleration due to gravity.

[0119] In addition, the accelerometer interface 430 can configure the output for further processing. For example, the accelerometer interface 430 can be configured to arrange the output of each accelerometer 432 into a vector representing the acceleration components of the x-axis, y-axis, and z-axis received from each accelerometer. The accelerometer interface 430 can be operably coupled to the processor 418 and configured to transmit the output signals from the accelerometers 432 to the processor 418 for further processing and analysis.

[0120] As described above, one or more of the accelerometers 432 may be integrated into one or more components of the medical device. Figure 4 As shown, accelerometer 432 can be integrated into controller 400. In some examples, accelerometer 432 can be integrated into one or more of therapy electrode 420, sensing electrode 422, physiological sensor 423, and other components of the medical device. When controller 400 is included in a hospital wearable defibrillator (HWD), the accelerometer can be integrated into adhesive ECG sensing and / or therapy electrode patches.

[0121] In certain implementations, cardiac event detector 416 can be configured to monitor a patient's ECG signal for the occurrence of cardiac events, such as arrhythmias or other similar cardiac events. The cardiac event detector can be configured to operate under the control of processor 418 to perform one or more methods that process received ECG signals, for example, from sensing electrodes 422, and determine the likelihood that the patient is experiencing a cardiac event. Cardiac event detector 416 can be implemented using hardware or a combination of hardware and software. For example, in some examples, cardiac event detector 416 can be implemented as code stored within data storage 404 and executed by processor 418. In this example, the instructions included in cardiac event detector 416 can cause processor 418 to perform one or more methods for analyzing received ECG signals to determine whether an adverse cardiac event is occurring. In other examples, cardiac event detector 416 can be an application-specific integrated circuit (ASIC) coupled to processor 418 and configured to monitor ECG signals for the occurrence of an adverse cardiac event. Thus, examples of cardiac event detector 416 are not limited to specific hardware or software implementations.

[0122] In some implementations, the processor 418 includes one or more processors (or one or more processor cores) each configured to execute a series of instructions that result in manipulated data and / or control the operation of other components of the medical device controller 400. In some implementations, when performing a particular process (e.g., cardiac monitoring), the processor 418 can be configured to make specific logic-based determinations based on received input data and further configured to provide one or more outputs that can be used to control or otherwise inform subsequent processing to be performed by the processor 418 and / or other processors or circuitry to which the processor 418 is communicatively coupled. Thus, the processor 418 reacts to a particular input stimulus in a particular manner and generates a corresponding output based on the input stimulus. In some example cases, the processor 418 can proceed through a sequence of logic transitions in which various internal register states and / or other bit cell states within or external to the processor 418 can be set to logic high or logic low. As described herein, the processor 418 can be configured to perform a function, wherein software is stored in a data storage portion coupled to the processor 418, the software being configured to cause the processor 418 to proceed through a sequence of various logical decisions that result in the execution of the function. The various components described herein as executable by the processor 418 can be implemented in various forms of dedicated hardware, software, or a combination thereof. For example, the processor 418 can be a digital signal processor (DSP), such as a 24-bit DSP. The processor 418 can be, for example, a multi-core processor having two or more processing cores. The processor 418 can be an Advanced RISC Machine (ARM) processor, such as a 32-bit ARM processor or a 64-bit ARM processor. The processor 418 can execute an embedded operating system and include services provided by the operating system that can be used for file system manipulation, display and audio generation, basic networking, firewalls, data encryption, and communications.

[0123] In some examples, the ambulatory cardiac device 108 includes a front-end configuration that uses circuitry to accommodate signals from high source impedance (e.g., having an internal impedance ranging from approximately 100 kilo-ohms to one mega-ohm or more) of the sensing electrodes. As described above, the high source impedance signal is processed and transmitted to a monitoring device, such as the processor 418 of the controller 400, for further processing. In some implementations, the ambulatory cardiac device 108 includes a microprocessor or other dedicated processor operably coupled to the sensing electrodes, the microprocessor or other dedicated processor configured to receive a common-mode noise signal from each of the sensing electrodes, sum the common-mode noise signals, invert the summed common-mode noise signal, and feed the inverted signal back to the patient as a drive ground using, for example, a drive right leg circuit to cancel the common-mode signal.

[0124] Now go to Figure 5A , providing process 500 is illustrated as a sequence diagram. In some examples, process 500 can be performed by a medical device (e.g., Figure 1 medical device 108A) and messaging services (e.g., Figure 1 Message service 118) is executed. Figure 5A As shown, process 500 begins with a medical device transmitting a device certificate 502 to a messaging service. Certificate 502 can be created by the medical device (e.g., via the openssl utility) and can specify an identifier for the medical device. For example, in some examples, certificate 502 is an X.509 certificate that embeds the serial number of the medical device as a subject. In some examples, to transmit certificate 502 to the messaging service, the medical device submits certificate 502 as part of an HTTP request to an API endpoint monitored by the messaging service, although other forms of communication will be apparent in view of this disclosure.

[0125] Continuing with process 500, the messaging service generates and registers 504 an IoT certificate using certificate 502. For example, in some examples, the messaging service generates a certificate signing request (CSR) specifying certificate 502 as a parameter, transmits the CSR to a certificate authority (not shown), and receives an IoT certificate 506 based on certificate 502 in response to the CSR from the certificate authority. In some examples, the messaging service registers the IoT certificate 506 for subsequent use in authenticating and identifying the medical device and transmits the IoT certificate 506 to the medical device. The medical device stores the IoT certificate in local storage for subsequent use in authenticating and identifying the medical device, and process 500 ends. It should be noted that in some examples, process 500 is performed during the manufacture of the medical device.

[0126] continue Figure 5A and Figure 5B , configuration process 508 is illustrated as a sequence diagram. In some examples, process 508 can be performed by a medical device (e.g., Figure 1 Medical device 108A), message service (e.g., Figure 1 Message service 118), record processor (e.g., Figure 3 Record processor 302), active data storage unit (e.g., Figure 3 active data storage section 310) and archived data storage section (e.g., Figure 3 The archive data storage unit 312) is executed. Figure 5A As shown, the process 508 begins with the medical device receiving and storing 510 initial settings for the operating parameters of the medical device. These initial settings may be prescribed to the patient (e.g., Figure 1Patient 112A) and by the HCP (e.g., Figure 1 10A) as part of initially fitting the medical device to the patient. The initial setup may specify patient operating parameters and / or one or more values for one or more device operating parameters. Examples of patient operating parameters include patient name, patient ECG baseline, whether the patient needs to complete a health survey and how often, preferred ECG sensor leads, patient identifier, patient language, therapy pulse energy level, sleep mode hours, sleep mode treatment delay, speaker volume, time zone, threshold number of days between uploads that if exceeded will cause an alert, ventricular fibrillation threshold rate, ventricular tachycardia threshold rate, threat delay time, and whether the patient needs to complete a walk test and how often. Examples of device operating parameters include a list of available languages, a list of supported time zones, a language for connecting to a data center environment (e.g., Figure 1 The medical device may be configured to receive a medical device login request, such as a URL to a data center environment 102 (e.g., a medical device data center environment 102), the number of days between diagnostic recordings, the physiological signals to be recorded (e.g., ECG signals, cardiac oscillation signals, etc.), and a threshold number of login attempts, where exceeding the threshold number will cause the medical device to be locked. An example JSON data record of patient and device operating parameters is as follows.

[0127] Continuing with processing 508, the medical device transmits a message 512 to the messaging service specifying a connection request that conforms to an IoT protocol supported by the messaging service. For example, in some examples, the message 512 (or another message transmitted as part of a handshake process between the medical device and the messaging service to establish a connection) includes a copy of the medical device's IoT certificate. In response to receiving the message 512, the messaging service attempts to authenticate the medical device 514. For example, in one example, the messaging service authenticates the medical device by providing a certificate to the messaging service (e.g., via a message data store, such as Figure 2 The medical device is authenticated 514 by verifying the IoT certificate and its contents (e.g., device identifier) using a previously registered IoT certificate accessible to the data storage unit 204 (e.g., the messaging service). If the messaging service successfully authenticates 514 the medical device, the messaging service transmits a positive confirmation in a message 516 specifying a connection response to the medical device. If the messaging service does not successfully authenticate 514 the medical device, the messaging service transmits an authentication error message in the message 516, and the process 508 ends.

[0128] Continuing with process 508, the medical device transmits a message 518 specifying an authorization request to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device transmits the message 518 to the broker (e.g., Figure 2202 of the agent 202). Message 518 may specify one or more topic IDs, one or more types of communication operations for which authorization is requested that is specific to the topic ID, and one or more publication QoS levels for which authorization is requested that is specific to the topic ID. In response, the agent evaluates the preconfigured policy to determine whether the medical device is authorized to perform the requested type of communication operation at the requested QoS level for the topic ID, and transmits a message 520 specifying an authorization response to the medical device. If the agent determines that the policy evaluates to true for the medical device, the agent stores a record indicating authorization for the medical device in a data store (e.g., Figure 2 The message 520 includes a positive confirmation. If the agent determines that the policy evaluation is false, the message 520 includes an error message indicating lack of authorization.

[0129] Continuing with process 508, the medical device transmits a message 522 to the messaging service specifying initial settings for the operating parameters of the medical device. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes message 522 to the messaging service under an initial settings topic to which the record processor subscribes. The payload of message 522 may include a data record specifying the initial settings.

[0130] Continuing with process 508, the messaging service inserts 524 the device ID of the medical device into the message 522. In some examples, the messaging service (e.g., via Figure 2 The identifier injector 210) from the message data storage unit (eg, Figure 2 The message service retrieves the device ID of the medical device from the message data store 204 (e.g., the message service). For example, in some examples, the message service queries the message data store with a query requesting the device ID of the publisher of message 522 and receives the device ID in response. The message service then writes the retrieved device ID to a predefined location within the header of the data record stored in message 522, thereby generating a new message 526. This predefined location can be specified by the data type of the data record, which in turn can be identified by the topic ID to which message 522 was published. The data type of a data record specifies the name, size, type, and location of each field within any data record of that data type.

[0131] Continue to refer Figure 5B At process 508, the message service transmits the message 526 to the record processor. In an example where the message service supports an IoT protocol such as MQTT, the message service publishes the message 526 to subscribers of the initially set topic (which includes the record processor).

[0132] Continuing with processing 508 , the record processor processes 528 message 526 . Figure 5CAn example of message handling processing performed by the record processor in operation 528 is illustrated. Figure 5B As shown, processing 528 begins with the record processor receiving 534 a message 526. For example, in some examples, the record processor may receive the message 526 from a messaging service as a publication to an initially set topic.

[0133] Continuing with processing 528, the record processor parses the message 526 to extract 536 the data records from the message 526. For example, in some examples, the record processor identifies a data type associated with the initial setup topic and accesses the payload via the data type to extract the data records.

[0134] Continuing with processing 528, the record processor extracts 538 the initial settings from the data record. For example, in some examples, the record processor reads the values of the initial settings from the fields of the extracted data record.

[0135] Continuing with processing 528, the record processor stores 540 the extracted initial settings in the active data store. For example, in some examples, the record processor executes a query that inserts a new record in the active data store that stores the values of the initial settings read from the fields of the extracted data record.

[0136] Continuing with processing 528, the record processor extracts 542 the header of the data record from the topic ID of the topic. For example, in some examples, the record processor parses the topic ID of the initial settings topic and reads the string "initial_settings" from a predefined location within the topic ID.

[0137] Continuing with processing 528, the record processor stores 544 the extracted header in the header of the data record. For example, in some examples, the record processor writes the string "initial_settings" to a predefined location within the header of the data record. The predefined location can be specified by the data type of the data record.

[0138] Continuing with process 528, the record processor stores 546 the data record in the archival data store. For example, in some examples, the record processor executes a query that inserts a new record into the archival data store that stores data records that include supplemental data items (e.g., title and device ID). After operation 546, process 528 ends.

[0139] Return to Reference Figure 5BDuring operation 528 of process 508 , the record processor stores 530 the initial settings of the operating parameters of the medical device in the active data store and stores 532 a copy of the data record specifying the initial settings of the operating parameters of the medical device in the archived data store. After operation 528 , process 508 ends.

[0140] In some cases, HCP (e.g., Figure 1 The HCP 110A may wish to change one or more values of a patient operating parameter (i.e., patient settings) of a medical device and / or the value of a device operating parameter (i.e., device settings). When this occurs, the HCP may call the patient (e.g., Figure 1 Patient 112A) to be processed via a configuration such as Figure 5D and Figure 5E In some examples, the process 550 can be performed by a medical device (e.g., Figure 1 Medical device 108A), message service (e.g., Figure 1 Message service 118), record processor (e.g., Figure 3 Record processor 302), active data storage unit (e.g., Figure 3 active data storage unit 310), archived data storage unit (e.g., Figure 3 Archive data storage unit 312), control services (e.g., Figure 1 control service 116) and HCP interface (e.g., Figure 1 HCP interface 122A) is executed. Figure 5C As shown, process 550 begins with the HCP interface transmitting a message 552 specifying a settings request to the control service. For example, in some examples, in response to receiving input from the HCP indicating that the HCP wishes to reconfigure settings of the medical device, the HCP interface transmits message 552. Message 552 can be, for example, an API call and can include, for example, an identifier of the medical device (e.g., a serial number) as a parameter.

[0141] Continuing with process 550, the control service 116 processes the settings request. For example, in some examples, the control service parses the settings request to extract the device ID specified therein, generates a query 554 requesting settings for the medical device identified by the device ID, and transmits the query 554 to the active data store.

[0142] Continuing with process 550 , the active data store processes the query. For example, in some examples, the active data store receives the query, identifies a row storing the current settings of the medical device identified in the query, generates query results 556 including the identified settings, and transmits query results 556 to the control service 116 .

[0143] Continuing with process 550, the control service 116 generates a message 558 specifying a settings response to the settings request specified in message 552 and transmits the message 558 to the HCP interface. For example, in some examples, the control service 116 transmits the message 558 as a reply to an API call executed by the HCP interface. The message 558 may include the current settings specified in the query result 556.

[0144] Continuing with process 550, the medical device generates 560 and outputs an authentication code. For example, in some examples, the HCP instructs the patient to input an input to the medical device that signals the medical device to enter support mode. In these examples, upon entering support mode, the medical device generates 560 an authentication code and outputs the authentication code via a user interface (e.g., Figure 4 The user interface 408 of the HCP outputs the authentication code, and the HCP asks the patient to read the authentication code aloud.

[0145] Alternatively or in addition, in some examples, the medical device transmits a message 562 specifying an authentication code to a messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes the message 562 to the messaging service as a code publication under a supported schema topic to which the control service subscribes. The payload of the message 562 may include a data record specifying the authentication code. Furthermore, in these examples, the messaging service inserts 564 the device ID of the medical device into the header of the message 562 to generate a modified message 566, and publishes the message 566 to subscribers of the supported schema topic (which includes the control service). The control service, in turn, extracts the authentication code and device ID from the message 566, generates an authentication message 568, and transmits the authentication message 568 to the HCP interface via an API call to the control service.

[0146] Continuing with process 550, the HCP interface receives 570 the authentication code. For example, in some examples, the HCP interface receives input from the HCP specifying the authentication code. Alternatively or additionally, in some examples, the HCP interface receives an authentication message 568 from the control service and parses the message 568 to retrieve the authentication code therefrom.

[0147] Continuing with process 550, the HCP interface receives input from the HCP specifying new settings, generates a message 572 specifying the new settings, and transmits the message 572 to the control service. The new settings may include new patient settings and / or new device settings. In some examples, the HCP interface transmits the message 572 to the control service by executing an API call exposed and implemented by the control service. The API call may include, for example, an identifier of the medical device (e.g., a serial number), an authentication code, and the new settings as parameters.

[0148] It should be noted that in some examples, the authentication code may be a serial number of the medical device rather than a different authentication code. Additionally, some examples omit all operations and messages between and including operations 560 and 570. In such examples, the API call executed by the HCP interface to transmit message 572 omits the authentication code altogether.

[0149] Continuing with process 550, the control service processes message 572 and transmits a message 574 based on message 572 to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the control service generates a modified message 574 and publishes the modified message 574 to the messaging service under a device-specific remote action topic to which the medical device has subscribed. The payload of message 574 may include a data record specifying an authentication code, the new settings, and a response topic to which the control service has subscribed. The topic ID of the response topic may be specific to the medical device.

[0150] Continuing with process 550 , the messaging service receives the message 574 and transmits the message 574 to the medical device. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 574 to a device-specific remote action topic to which the medical device subscribes.

[0151] Continue to refer Figure 5E Following processing 550 , the medical device processes 578 message 574 . For example, in some examples, the medical device receives message 574 , parses the message to extract the topic ID and settings of the corresponding topic from the data record stored in the payload of message 574 , verifies the settings, and applies the settings if the settings are valid. When applying the settings, the medical device stores the values specified by the settings in memory locations referenced during operation of the medical device to control the behavior of the medical device.

[0152] Continuing with process 550, the medical device generates a message 580 specifying a response and transmits the message 580 to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes the message 580 to the messaging service under the response topic. The message 580 may specify the result of operation 578, such as a positive confirmation or an error message. Any error message specified by the message 580 may indicate one or more of the settings that caused the application of the settings to fail.

[0153] Continuing with process 550, the message service receives the message 580 and transmits the message 580 to the control service. In examples where the message service supports an IoT protocol such as MQTT, the message service publishes the message 580 to a response topic to which the control service subscribes.

[0154] Continuing with process 550, the control service interacts with the HCP interface to present the results of the new setup request specified in message 572 to the HCP. For example, in some examples, the control service generates a message 584 specifying the setup results and transmits the message 584 to the HCP interface via an API call to the control service. Furthermore, in some examples, the HCP interface receives the message 584, parses the message 584 to extract the setup results, and presents a human-readable version of the setup results to the HCP.

[0155] Continuing with process 550, the medical device transmits a message 586 to the message service specifying all settings for the operating parameters of the medical device. In examples where the message service supports an IoT protocol such as MQTT, the medical device publishes message 586 to the message service under a settings topic (e.g., a patient settings topic and / or a device settings topic) to which the message service subscribes. The payload of message 586 may include a data record specifying all settings.

[0156] Continuing with process 550, the messaging service inserts 588 the device ID of the medical device into message 586 to generate a new message 590. In some examples, the messaging service (e.g., via Figure 2 The identifier injector 210) from the message data storage unit (eg, Figure 2 The message service retrieves the device ID of the medical device from the message data store 204 (e.g., the message service). For example, in some examples, the message service queries the message data store with a query requesting the device ID of the publisher of message 586 and receives the device ID in response. The message service then writes the retrieved device ID to a predefined location within the header of the data record stored in message 586. The predefined location can be specified by the data type of the data record, which in turn can be identified by the topic ID to which message 586 was published.

[0157] Continuing with process 550, the messaging service transmits the message 590 to the record processor. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 590 to subscribers of the set topic (which includes the record processor).

[0158] Continuing with processing 550 , the record processor processes 592 message 590 . Figure 5F An example of message handling processing performed by the record processor in operation 592 is illustrated. Figure 5F As shown, processing 592 begins with the record processor receiving 593 a message 590. For example, in some examples, the record processor may receive the message 590 from a messaging service as a publication to a settings topic.

[0159] Continuing with processing 592, the record processor parses the message 590 to extract 594 data records from the message 590. For example, in some examples, the record processor identifies a data type associated with the settings topic and accesses the payload via the data type to extract the data records.

[0160] Continuing with processing 592, the record processor extracts 595 the setting from the data record. For example, in some examples, the record processor reads the value of the setting from a field of the extracted data record.

[0161] Continuing with process 592, the record processor stores 596 the extracted settings in the active data store. For example, in some examples, the record processor executes a query that inserts a new record in the active data store that holds the values of the settings read from the fields of the extracted data records.

[0162] Continuing with processing 592, the record processor extracts 597 the header of the data record from the topic ID of the topic. For example, in some examples, the record processor parses the topic ID of the initial settings topic and reads the string "patient_settings" and / or "device_settings" from a predefined location within the topic ID.

[0163] Continuing with processing 592, the record processor stores 598 the extracted header in the header of the data record. For example, in some examples, the record processor writes the string "patient_settings" and / or "device_settings" to a predefined location within the header of the data record.

[0164] Continuing with process 592, the record processor stores 599 the data record in the archival data store. For example, in some examples, the record processor executes a query that inserts a new record into the archival data store that stores data records that include supplemental data items (e.g., title and device ID). After operation 599, process 592 ends.

[0165] Return to Reference Figure 5E In process 550, during execution of operation 592, the record processor stores 596 the settings of the operating parameters of the medical device in the active data store and stores 599 a copy of the data record specifying the settings of the operating parameters of the medical device in the archived data store. After operation 599, process 550 ends.

[0166] Now go to Figure 6A and Figure 6C , a process 600 for reporting a priority event is illustrated as a sequence diagram. In some examples, the process 600 can be performed by a medical device (e.g., Figure 1 Medical device 108A), message service (e.g., Figure 1 Message service 118), record processor (e.g., Figure 3 ), the reporting service 114, and the HCP interface (e.g., Figure 1 HCP interface 122A) is executed. Figure 6A As shown, the process 600 begins with the medical device detecting 602 a priority event. Examples of priority events that the medical device may detect include a patient (e.g., Figure 1 The detected arrhythmia condition may be a treatable (e.g., VT, VF) or non-treatable (asystole). The disconnected electrode condition may be specific to one or more sensing or therapy electrodes.

[0167] Continuing with process 600, the medical device and the message service are referred to above. Figure 5A If the medical device is not currently authorized to interoperate with the messaging service, the medical device and messaging service further perform the operations described above with reference to Figure 5A The operations described with respect to messages 518 and 520 ( Figure 6A (not shown) to authorize the medical device to interoperate with the messaging service.

[0168] Continuing with process 600, the medical device transmits a message 604 to the messaging service specifying the occurrence of a priority event. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes message 604 to the messaging service under a topic specific to the type of priority event detected (e.g., "treatable_arrhythmia," "nontreatable_arrhythmia," etc.) to which the record processor subscribes. The payload of message 604 may include a data record specifying the priority event.

[0169] Continuing with process 600, the messaging service inserts 606 the device ID of the medical device into the message 604. In some examples, the messaging service (e.g., via Figure 2 The identifier injector 210) from the message data storage unit (eg, Figure 2 The message service retrieves the device ID of the medical device from the message data store 204 (e.g., the message service). For example, in some examples, the message service queries the message data store with a query requesting the device ID of the publisher of message 604 and receives the device ID in response. The message service then writes the retrieved device ID to a predefined location within the header of the data record stored in message 604, thereby generating a new message 608. The predefined location can be specified by the data type of the data record, which in turn can be identified by the topic ID to which message 604 was published.

[0170] Continuing with process 600, the messaging service transmits the message 608 to the record processor. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 608 to subscribers of the priority event topic, which includes the record processor and the reporting service.

[0171] Continuing with process 600 , the record processor processes 610 message 608 . Figure 6B An example of message handling processing performed by the record processor in operation 610 is illustrated. Figure 6B As shown, process 610 begins with a record processor receiving 620 a message 608. For example, in some examples, the record processor may receive message 608 from a messaging service as a publication to a priority event topic.

[0172] Continuing with process 610, the record processor parses the message 608 to extract 622 data records from the message 608. For example, in some examples, the record processor identifies a data type associated with the priority event topic and accesses the payload via the data type to extract the data records.

[0173] Continuing with processing 610, the record processor extracts 624 the title of the data record from the topic ID of the topic. For example, in some examples, the record processor parses the topic ID of the priority event topic and reads the string "treatable_arrhythmia" from a predefined location within the topic ID.

[0174] Continuing with process 610, the record processor stores 626 the extracted header in the header of the data record. For example, in some examples, the record processor writes the string "treatable_arrhythmia" to a predefined location within the header of the data record. The predefined location can be specified by the data type of the data record.

[0175] Continuing with process 610 , the record processor adds 628 a copy of the data record to a queue associated with the extracted title and adds 636 a copy of the data record to a general queue associated with all data records generated by the medical device.

[0176] Continuing with processing 610, the record processor extracts 630 priority data from the data record. For example, in some examples, the record processor reads the value of the priority data from a field of the extracted data record. In some examples, the priority data includes summary information related to the priority event and links to detailed data related to the priority event. For example, in some examples, the summary information may include a type of arrhythmia detected or a description of a device condition that prevented the medical device from treating the patient. The detailed data may include, for example, one or more ECG segments or device diagnostic data that are temporally adjacent to, around, or otherwise related to the priority event. The links may include links to data that may be fully resolved (e.g., by a reporting service) to an active data store (e.g., Figure 3 In one example, the relative link includes the patient ID, the device ID, and the name of the file storing the detailed data.

[0177] Continuing with process 610, the record processor transforms 632 the priority data into a form desired by one or more consumers of the priority data (e.g., a reporting service). The transformation may include changing the type, precision, and relative position of data items stored within the priority data. Completing the transformation prepares the priority data for efficient access by the one or more consumers.

[0178] Continuing with process 610, the record processor stores the transformed priority data in the active data store 634 and removes a copy of the data record from the priority event queue. For example, in some examples, the record processor executes a query that inserts a new record in the active data store that stores the value (and structure, in some examples) of the transformed priority data.

[0179] Continuing with process 610, the record processor stores 638 the extracted data records in an archive data store (e.g., Figure 3 The data record is then stored in the archive data store 312 and the duplicate of the data record is removed from the general queue. For example, in some examples, the record processor executes a query that inserts a new record into the archive data store that stores data records including supplemental data items (e.g., title and device ID). After operation 638, process 610 ends.

[0180] Return to Reference Figure 6A In the process 600, the reporting service generates a message 612 for specifying the priority event and transmits the message 612 to the HCP interface. For example, in some examples, the reporting service transmits the message 612 using a call to an API exposed and implemented by the HCP interface. The message 612 may include a human-readable presentation of summary information related to the priority event and a clickable link to detailed information. The clickable link may be inactive until the storage service processes the message 666 for identifying the detailed data file. Figure 6C The processing of message 666 and the detailed data file is further described.

[0181] Continue to refer Figure 6C 6. In the example where the priority event is an arrhythmia condition, the detailed data file includes an ECG segment or strip that includes ECG data collected within a time window proximate to and / or including the occurrence of the arrhythmia condition. The time window can have a duration of 30 seconds, 45 seconds, 1 minute, 1.5 minutes, 2 minutes, or longer and can be centered around the time at which the arrhythmia condition was declared. In some examples, the time at which the arrhythmia condition was declared can be offset within the time window (e.g., within the first third of a 45-second time window). Other examples will be apparent in light of this disclosure.

[0182] Continuing with process 600, the medical device generates a message 652 specifying a request for a file upload link and transmits it to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes message 652 to the messaging service under a topic specific to the upload link request to which the storage service subscribes. The payload of message 652 may include a response topic to which the medical device subscribes. The topic ID of the response topic may be specific to the medical device.

[0183] Continuing with process 600, the messaging service transmits a message 652 to the storage service. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 652 to subscribers of the upload link event topic (which includes the storage service).

[0184] Continuing with process 600, the storage service parses the message 652 to extract the link request specified therein and (e.g., via Figure 3 ) generates 654 an upload link. For example, in some examples, the storage service generates 654 an upload link in the file storage unit (e.g., Figure 3 The file storage unit 308 of the storage unit allocates storage space to receive file uploads, generates a URL specific to the allocated space to serve as an upload link, and monitors any messages received that are addressed to the URL. In some examples, the storage service also extracts a response topic from the link request.

[0185] Continuing with process 600, the storage service generates a message 656 and transmits it to the messaging service. Message 656 may specify an upload link. In an example where the messaging service supports an IoT protocol such as MQTT, the storage service publishes message 656 to subscribers of the corresponding topic (which may include the medical device) via the messaging service to transmit the message.

[0186] Continuing with process 600, the messaging service receives and transmits the message 656 to the medical device. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 656 to subscribers of the response topic (which includes the medical device).

[0187] Continuing with process 600, the medical device processes message 656 to transfer the detailed data file 658 to the storage service. For example, in some examples, the medical device parses message 656 to extract the upload link specified therein and performs an HTTP post to the upload link, the HTTP post including the detailed data file 658 as a parameter.

[0188] Continuing with process 600, the HCP interface receives data from the HCP (e.g., Figure 1 The HCP 110A) receives input specifying a request for detailed data related to a priority event. For example, in at least one example, as described above with respect to reference Figure 6A As shown in message 612, the HCP interface receives a click on the clickable link. In response, the HCP interface generates and transmits message 660 specifying a request for detailed data related to the priority event. For example, in some examples, the HCP interface transmits an API call to the reporting service, the API call including the patient ID, the device ID, and the name of the detailed data file as parameters.

[0189] Continuing with process 600, the reporting service processes message 660. For example, in some examples, the reporting service parses message 660 to extract the patient ID, device ID, and name of the detailed data file specified therein, generates a query 662 requesting the detailed data file based on the extracted parameters, and transmits query 662 to the storage service.

[0190] Continuing with process 600, the storage service processes the query. For example, in some examples, the storage service receives and parses the query, interacts with the file store to identify the detailed data file using the query parameters, generates query results 664 including the detailed data file, and transmits the query results 664 to the reporting service.

[0191] Continuing with process 600, the reporting service processes query results 664 to generate a message 666 specifying a response to message 660 and transmits message 666 to the HCP interface. For example, in some examples, the reporting service transmits message 666 in response to an API call executed by the HCP interface. Response 666 can include the detailed data file specified in query results 664 or data derived from the detailed data file. Furthermore, in some examples, the HCP interface receives response 666, parses response 666 to extract the detailed data file or data derived from the detailed data file, and presents a human-readable version of the extracted data file or derived data to the HCP, and process 600 ends.

[0192] Now go to Figure 7A and 7B , a process 700 for batch data publishing is illustrated as a sequence diagram. In some examples, the process 700 can be performed by a medical device (e.g., Figure 1 Medical device 108A), message service (e.g., Figure 1 Message service 118), link generator (e.g., Figure 3 Link generator 304), record processor (e.g., Figure 3 Record processor 302), file storage unit (for example, Figure 3 file storage unit 308) and publishers (e.g., Figure 3 Publisher 306) executes. Figure 7A As shown, the process 700 begins with the medical device detecting 702 a batch release trigger. Examples of batch release triggers that the medical device may detect include a batch release trigger from a user (e.g., Figure 1 Patient 112A or Figure 1The HCP 110A receives input that specifies a request to perform a data upload and / or the occurrence of an event generated autonomously by the medical device, such as the expiration of a timer or the size of a bulk data file exceeding a configurable threshold. The timer can be periodic (e.g., daily) or non-periodic. In some implementations, the medical device can add a random amount of time to the timer to prevent a large number of medical devices (e.g., Figure 1 The mobile heart device 108) attempts to publish batch data simultaneously via the messaging service.

[0193] Continuing with process 700, the medical device and the message service are referred to above. Figure 5A If the medical device is not currently authorized to interoperate with the messaging service, the medical device and messaging service further perform the operations described above with reference to Figure 5A The operations described with respect to messages 518 and 520 ( Figure 7A (not shown) to authorize the medical device to interoperate with the messaging service.

[0194] Continuing with process 700, the medical device, the messaging service, and the link generator (as part of the storage service) are referenced above. Figure 6C The operations described in connection with messages 652-656 are performed to create the upload link.

[0195] Continuing with process 700, the medical device processes the message 656 to transfer the bulk data file 704 to the file storage via the API implemented by the storage service. For example, in some examples, the medical device parses the message 656 to extract the upload link specified therein and performs an HTTP post to the upload link, the HTTP post including the bulk data file 704 as a parameter. As described above with reference to Figure 4 As described above, the batch data file 704 can specify routine data collected by a medical device. In some examples, the batch data file is structured to include a header and a payload. In these examples, the payload includes multiple partial data records, and the header includes supplemental data common to all partial data records that can be used to generate a complete data record from the partial data records (e.g., device ID, patient ID, etc.).

[0196] Continuing with process 700, the file store receives and stores the batch data file 704 and transmits a message 706 indicating that new data is available within the file store for processing by the publisher. For example, in some examples, the file store implements a trigger for generating and transmitting message 706. Message 706 can specify an identifier for the new batch data file, which can be used to access a copy of the new batch data file via an API exposed and implemented by the file store.

[0197] Continuing with processing 700 , the publisher monitors and processes 708 new batch data files. Figure 7C An example of batch data file handling processing 708 performed by the publisher in operation 708 is illustrated. Figure 7C As shown, process 708 begins with the publisher determining 720 whether a new data notification has been received from the file store. For example, in some examples, the publisher determines whether message 706 has been received. In these examples, if the publisher determines that message 706 has been received, the publisher proceeds to operation 722. If the publisher determines that message 706 has not been received, the publisher again performs operation 720.

[0198] Continuing with process 708, the publisher parses the message 706 to extract the identifier of the new batch data file and retrieves the new batch data file from the file store 722. For example, in some examples, the publisher generates and transmits a query to the file store using the identifier of the new batch data file as a parameter. In these examples, the file store processes the query and responds with a copy of the new batch data file. The publisher receives the copy and proceeds to process 724.

[0199] Continuing with processing 708, the publisher extracts 724 the header from the bulk data file and extracts the supplemental data from the header. For example, in some examples, the record processor identifies a data type associated with the bulk data file and accesses the header by the data type to extract the header and the supplemental data.

[0200] Continuing with process 708, the publisher extracts 726 the payload from the bulk data file. For example, in some examples, the record processor identifies a data type associated with the bulk data file and accesses the payload by the data type to extract the payload.

[0201] Continuing with process 708, the publisher determines 728 whether any partial data records remain to be extracted from the payload. For example, in some examples, the publisher attempts (e.g., using a bulk data file data type) to access the next partial data record from the payload. In these examples, if the publisher successfully accesses the next partial data record from the payload, the publisher proceeds to operation 730. If the publisher fails to access the next partial data record (e.g., due to a now empty payload), the publisher returns to operation 720.

[0202] Continuing with process 708, the publisher extracts 730 the next portion of data records from the payload. For example, in some examples, the publisher uses the data type of the batch data file to identify and extract the next portion of data records from the payload.

[0203] Continuing with processing 708, the publisher stores 732 the supplemental data in the next portion of the data record to generate a complete data record. For example, in some examples, the publisher uses the data type of the batch data file to identify the supplemental data and inserts it into the next portion of the data record.

[0204] Continuing with process 708, the publisher sends a Figure 7B The message service 118 of the message server 118 transmits 734 a message specifying the complete data record. In examples where the message service supports an IoT protocol such as MQTT, the publisher sends 734 a message to the record processor (e.g., Figure 7B After operation 734, processing 708 returns to operation 728.

[0205] Returning to process 700, as a result of operation 708, the publisher transmits a plurality of messages 710 to the message service. The message service, in turn, transmits the messages 710 to the record processor. In examples where the message service supports an IoT protocol such as MQTT, the message service publishes the messages 710 to subscribers of the bulk data topic (which includes the record processor).

[0206] Continuing with process 700 , the record processor processes 712 message 710 . Figure 7D An example of message handling processing performed by the record processor in operation 712 is illustrated. Figure 7D As shown, process 712 begins with the record processor receiving 740 one of the messages 710. For example, in some examples, the record processor may receive the message 710 from a messaging service as a publication to a bulk data topic.

[0207] Continuing with process 712, the record processor parses the message 710 to extract 742 data records from the message 710. For example, in some examples, the record processor identifies a data type associated with the bulk data topic and accesses the payload by the data type to extract the data records.

[0208] Continuing with process 712, the record processor extracts 744 a header of the data record from the data record. For example, in some examples, the record processor parses the data record and reads the header from a predefined location within the data record defined by the data type associated with the batch of data records.

[0209] Continuing with processing 712 , the record processor adds 746 a copy of the data record to a queue associated with the title and adds 754 a copy of the data record to a general queue associated with all data records generated by the medical device.

[0210] Continuing with processing 712, the record processor extracts 748 the routine data from the data record. For example, in some examples, the record processor reads the value of the routine data from a field of the extracted data record. In some examples, the routine data extracted from the data record specifies the patient (e.g., Figure 1 One or more of the patient's body positioning information (112A), the patient's heart rate trend information, and the patient's wearing time information.

[0211] Continuing with process 712, the record processor transforms 750 the routine data into a form desired by one or more consumers (i.e., computer-implemented processes) of the routine data (e.g., a reporting service). The transformation may include changing the type, precision, and relative position of data items stored within the priority data. Completing the transformation prepares the routine data for efficient access by the one or more consumers.

[0212] Continuing with processing 712, the record processor stores the transformed routine data in the active data store 752 and removes a copy of the data record from the priority event queue. For example, in some examples, the record processor executes a query that inserts a new record in the active data store that stores the value (and structure, in some examples) of the transformed routine data.

[0213] Continuing with processing 712, the record processor stores 756 the extracted data records in an archive data store (e.g., Figure 3 The data record is stored in the archive data store 312 and the copy of the data record is removed from the general queue. For example, in some examples, the record processor executes a query that inserts a new record into the archive data store where the data record is stored. After operation 756, the process 712 ends.

[0214] Return to Reference Figure 7B After operation 712, the process 700 ends.

[0215] In some cases, HCP (e.g., Figure 1 The HCP 110A) may wish to use a Figure 1 For example, the HCP may wish to upgrade the software installed on the medical device, clone the medical device, or initiate other remote operations. Figure 8 , a remote execution process 800 that can be initiated by the HCP to accomplish this goal is illustrated as a sequence diagram. In some examples, the process 800 can be initiated by the HCP interface, the medical device, the messaging service (e.g., Figure 1 messaging services 118) and control services (e.g., Figure 1 The control service 116) is executed. Figure 8As shown, the process 800 receives 802 an input from an HCP specifying a remote operation request at an HCP interface. For example, in some examples, the input specifies a request to perform a software upgrade on a medical device.

[0216] Continuing with process 800, the HCP interface transmits a message specifying a remote operation request to the control service 804. For example, in some examples, the HCP interface transmits an API call to the control service that includes an identifier (eg, serial number) of the medical device and a command string as parameters.

[0217] Continuing with process 800, the control service processes 806 the remote operation request. For example, in some examples, the control service parses the remote operation request to extract the device ID and command string specified therein. In these examples, the control service generates message 808 based on message 804 and transmits message 808 to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the control service generates message 808 and publishes it to the messaging service under a device-specific remote action topic to which the medical device is subscribed. The payload of message 808 can specify the command string and a response topic to which the control service is subscribed. The topic ID of the response topic can be specific to the medical device.

[0218] Continuing with process 800, the medical device and message service are referred to above. Figure 5A If the medical device is not currently authorized to interoperate with the messaging service, the medical device and messaging service further perform the operations described above with reference to Figure 5A The operations described with respect to messages 518 and 520 ( Figure 8 (not shown) to authorize the medical device to interoperate with the messaging service.

[0219] Continuing with process 800, the messaging service transmits a message 808 to the medical device. In examples where the messaging service supports an IoT protocol such as MQTT, the messaging service publishes the message 808 to subscribers of the device-specific remote action topic, which includes the medical device.

[0220] Continuing with process 800, the medical device processes 810 message 808. For example, in some examples, the medical device receives message 808, parses the message to extract a command string stored in a payload of message 808, validates the command string, and executes the command string if the command string is valid.

[0221] Continuing with process 800, the medical device generates a message 812 specifying a response and transmits the message 812 to the messaging service. In examples where the messaging service supports an IoT protocol such as MQTT, the medical device publishes the message 812 to the messaging service under the response topic. The message 812 can specify the result of the operation 810, such as a positive confirmation or an error message.

[0222] Continuing with process 800, the message service receives the message 812 and transmits the message 812 to the control service. In examples where the message service supports an IoT protocol such as MQTT, the message service publishes the message 812 to a response topic to which the control service subscribes.

[0223] Continuing with process 800, the control service interacts with the HCP interface to present the results of the remote operation request received in operation 802 to the HCP. For example, in some examples, the control service generates a message 814 specifying the results and transmits the message 814 to the HCP interface via an API call to the control service. Furthermore, in some examples, the HCP interface receives the message 814, parses the message 814 to extract the results, and presents a human-readable version of the results to the HCP.

[0224] Now go to Figure 11 , illustrates a priority event screen 1100. Figure 11 As shown, screen 1100 includes a sequence number control 1102, a patient priority event control 1104, a device priority event control 1106, a save control 1108, and a cancel control 1110. In some examples, the priority event screen 1100 is accessed from a control service (e.g., Figure 1 The control service 116) is provided to the HCP interface application (e.g., Figure 1 In these examples, the HCP interface application (e.g., a browser) presents screen 1100. Additionally, in these examples, the HCP interface application accesses the HCP (e.g., Figure 1 Input is received through interaction between the HCP 110A) and the screen 1100.

[0225] like Figure 11 As shown, the control 1102 is configured to present one or more ambulatory cardiac devices (e.g., Figure 1 In these examples, in response to the control 1102 receiving input specifying the serial number of the mobile cardiac device for which the HCP wishes to check the currently configured priority events, the HCP interface application requests configuration information specifying the priority events configured for the mobile cardiac device having the serial number selected in the control 1102. For example, in some examples, the HCP interface application transmits a setup request (e.g., Figure 5D The control service, in turn, queries the activity data store (e.g., activity data store 310) to receive configuration data specifying the priority events for the current configuration and responds via a setup response (e.g., Figure 5D The setup response 558) communicates the configured priority events to the HCP interface application.

[0226] continue Figure 11 In the example of FIG. 1 , the HCP interface application is configured to present the currently configured priority events via controls 1104 and 1106. Figure 11 As shown, control 1104 indicates that VF and VT are currently configured patient priority events, and control 1106 indicates that electrode off and belt disconnection are currently configured device priority events. In these examples, the HCP interface application is configured to select or deselect each priority event based on input received from the HCP specifying the selection or deselection of each priority event.

[0227] continue Figure 11 In some examples, the HCP interface application is configured to save and deploy the currently selected priority events in controls 1104 and 1106. For example, in some examples, the HCP interface application generates and transmits a new setup request (e.g., Figure 5D 572), which triggers a new setup request Figures 5D to 5F The remainder of process 550 is illustrated in FIG. It should be noted that in some examples, the medical device does not require an authorization code to change the priority events for the current configuration of the ambulatory cardiac device.

[0228] continue Figure 11 In an example, the HCP interface application is configured to close screen 1100 in response to receiving input from the HCP selecting control 1100.

[0229] Now go to Figure 9 , schematically illustrates a computing device 900. Figure 9 As shown, the computing device includes at least one processor 902, volatile memory 904, one or more interfaces 906, non-volatile memory 908, and an interconnect mechanism 914. The non-volatile memory 908 includes code 910 and at least one data store 912.

[0230] In some examples, non-volatile (non-transitory) memory 908 includes: one or more read-only memory (ROM) chips; one or more hard drives or other magnetic or optical storage media; one or more solid-state drives (SSDs), such as flash drives or other solid-state storage media; and / or one or more hybrid magnetic storage media and SSDs. In some examples, code 910 stored in non-volatile memory may include an operating system and one or more applications or programs configured to execute under the operating system. Alternatively or in addition, code 910 may include specialized firmware and embedded software that can execute without relying on a commercially available operating system. Regardless, execution of code 910 may result in manipulated data that can be stored as one or more data structures in data storage 912. Data structures may have fields that are associated through colocation within the data structures. Such associations may also be achieved by allocating storage for the fields in locations within the memory that convey the association between the fields. However, other mechanisms may be used to establish associations between information in the fields of a data structure, including through the use of pointers, tags, or other mechanisms.

[0231] continue Figure 9 In some examples, the processor 902 may be one or more programmable processors for executing one or more executable instructions (such as a computer program specified by code 910) to control the operation of the computing device 900. As used herein, the term "processor" describes a circuit system that performs a function, an operation, or a sequence of operations. The function, operation, or sequence of operations may be hard-coded into the circuit system, or soft-coded by means of instructions stored in a memory device (e.g., volatile memory 904) and executed by the circuit system. In some examples, the processor 902 is a digital processor, but the processor 902 may be analog, digital, or mixed. Therefore, the processor 902 may use digital values and / or use analog signals to perform functions, operations, or sequences of operations. In some examples, the processor 902 may be embodied in one or more application-specific integrated circuits (ASICs), microprocessors, digital signal processors (DSPs), graphics processing units (GPUs), neural processing units (NPUs), microcontrollers, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), or multi-core processors. The multi-core processor 902 example may provide functionality for executing instructions in parallel, simultaneously, or for executing one instruction on more than one piece of data in parallel, simultaneously.

[0232] continue Figure 9For example, before executing code 910, processor 902 may copy code 910 from non-volatile memory 908 to volatile memory 904. In some examples, volatile memory 904 includes one or more static or dynamic random access memory (RAM) chips and / or cache memory (e.g., memory provided on the silicon die of processor 902). Volatile memory 904 can provide faster response times than main memory (such as non-volatile memory 908).

[0233] By executing code 910, processor 902 can control the operation of interface 906. Interface 906 may include a network interface. These network interfaces may include one or more physical interfaces (e.g., radio, Ethernet port, USB port, etc.) and a software stack including drivers and / or other code 910 configured to communicate with the one or more physical interfaces to support one or more LAN, PAN, and / or WAN standard communication protocols. Communication protocols may include, for example, TCP and UDP. Thus, the network interface enables computing device 900 to access and communicate with other computing devices via a computer network.

[0234] The interface 906 may include a user interface. For example, in some examples, the user interface includes a user input and / or output device (e.g., a keyboard, a mouse, a touch screen, a display, a speaker, a camera, an accelerometer, a biometric scanner, an environmental sensor, etc.) and a software stack that includes a driver and / or other code 910 configured to communicate with the user input and / or output device. Thus, the user interface enables the computing device 900 to interact with the user to receive input and / or present output. The presented output may include, for example, one or more GUIs that include one or more controls configured to display output and / or receive input. The input may specify a value to be stored in the data storage 912. The output may indicate a value stored in the data storage 912.

[0235] continue Figure 9 In some examples, the various features of the computing device 900 described above can communicate with each other via an interconnect mechanism 914. In some examples, the interconnect mechanism 914 includes a communication bus.

[0236] The teachings of the present disclosure can generally be applied to external medical monitoring and / or treatment devices that include one or more sensors as described herein. Such external medical devices can, for example, include mobile medical devices as described herein that are capable of and designed to move with a patient as the patient goes about his or her daily life. Example mobile medical devices can be wearable medical devices such as WCDs, wearable cardiac monitoring devices, in-hospital devices such as HWDs, short-term wearable cardiac monitoring and / or treatment devices, mobile cardiac event monitoring devices, and other similar wearable medical devices.

[0237] The wearable medical device is capable of continuous use by the patient. In some implementations, continuous use can be substantially or nearly continuous in nature. That is, the wearable medical device can be used continuously except for sporadic periods of temporary cessation of use (e.g., when the patient showers, when the patient changes into new and / or different clothing, when the battery is charged / changed, when clothing is washed, etc.). However, such substantially or nearly continuous use as described herein can be considered continuous use. For example, the wearable medical device can be configured to be worn by the patient for up to 24 hours a day. In some implementations, the patient can remove the wearable medical device for a short period of time a day (e.g., within half an hour of showering). In such an example, nearly continuous can include 23.5 hours of wear a day with a half-hour removal period.

[0238] In addition, the wearable medical device can be configured as a long-term or extended-use medical device. Such a device can be configured for use by a patient for an extended period of days, weeks, months, or even years. In some examples, the wearable medical device can be used by a patient for an extended period of at least one week. In some examples, the wearable medical device can be used by a patient for an extended period of at least 30 days. In some examples, the wearable medical device can be used by a patient for an extended period of at least one month. In some examples, the wearable medical device can be used by a patient for an extended period of at least two months. In some examples, the wearable medical device can be used by a patient for an extended period of at least three months. In some examples, the wearable medical device can be used by a patient for an extended period of at least six months. In some examples, the wearable medical device can be used by a patient for an extended period of at least one year. In some implementations, extended use can be uninterrupted until a physician or other healthcare provider (HCP) provides the patient with specific instructions to stop using the wearable medical device.

[0239] Regardless of the extended period of wear, use of the wearable medical device may include continuous wear by the patient as described above. For example, continuous use may include periods of monitoring as well as periods during which the device may not be monitoring the patient but is otherwise worn by the patient or otherwise attached to the patient, such as by continuously wearing or attaching the wearable medical device to the patient via one or more electrodes as described herein. The wearable medical device may be configured to continuously monitor cardiac-related information (e.g., ECG information, including arrhythmia information, cardiac oscillations, etc.) and / or non-cardiac information (e.g., blood oxygenation, the patient's body temperature, glucose levels, tissue fluid levels, and / or lung oscillations) of the patient. The wearable medical device may perform its monitoring at periodic or non-periodic time intervals or times. For example, monitoring during an interval or time period may be triggered by a user action or other event.

[0240] As described above, the wearable medical device can be configured to monitor other non-ECG physiological parameters of the patient in addition to monitoring heart-related parameters. For example, the wearable medical device can be configured to monitor lung vibrations (e.g., using a microphone and / or accelerometer), respiratory vibrations, sleep-related parameters (e.g., snoring, sleep apnea), tissue fluid (e.g., using a radio frequency transmitter and sensor), etc.

[0241] Other example wearable medical devices include automatic heart monitors and / or defibrillators for use in certain specialized conditions and / or environments (such as for use in war zones or in emergency vehicles, etc.). Such devices can be configured so that they can be used immediately (or substantially immediately) in life-saving emergency situations. In some examples, the mobile medical devices described herein can be pacing-enabled, for example, capable of providing therapeutic pacing pulses to the patient. In some examples, the mobile medical device can be configured to monitor and / or measure ECG metrics, including, for example, heart rate (such as the mean, median, mode or other statistical metric of heart rate, and / or maximum, minimum, resting, pre- and post-exercise heart rate values and / or ranges, etc.), heart rate variability metrics, premature ventricular contractions (PVC) load or count, atrial fibrillation load metrics, pauses, heart rate oscillations, QRS height, QRS width, changes in the size or shape of the morphology of ECG information, cosine RT, artificial pacing, QT interval, QT variability, T wave width, T wave alternans, T wave variability, and ST segment changes.

[0242] Figure 10AAn example medical device 1000 is illustrated that is external, mobile, and wearable by a patient 1002 and is configured to implement one or more of the configurations described herein. For example, the medical device 1000 can be a non-invasive medical device configured to be substantially external to the patient. Such a medical device 1000 can, for example, be a mobile medical device that is capable of and designed to move with the patient as the patient goes about his or her daily life. For example, a medical device 1000 as described herein can be attached to the patient's body, such as to be wearable from a patient's body. MedicalCorporation acquired Wearable cardioverter defibrillators, etc. Such wearable defibrillators are typically worn almost continuously for two to three months at a time. During the period that the patient wears the wearable defibrillator, the wearable defibrillator can be configured to continuously monitor the patient's vital signs and, when it is determined that treatment is needed, can be configured to deliver one or more therapeutic electrical pulses to the patient. For example, such therapeutic shocks can be pacing, defibrillation, or transcutaneous electrical nerve stimulation (TENS) pulses.

[0243] Medical device 1000 may include one or more of the following: garment 1010, one or more ECG sensing electrodes 1012, one or more non-ECG physiological sensors 1013, one or more therapy electrodes 1014a and 1014b (collectively referred to herein as therapy electrodes 1014), a medical device controller 1020 (e.g., as described above in Figure 4 10), a connection pod 1030, a patient interface pod 1040, a strap 1050, or any combination thereof. In some examples, at least some of the components of medical device 1000 can be configured to be attached to (or, in some examples, permanently integrated into) a garment 1010 that can be worn about the patient's torso.

[0244] The medical device controller 1020 can be operably coupled to a sensing electrode 1012, which can be attached to the garment 1010, for example, assembled into the garment 1010 or removably attached to the garment using, for example, hook-and-loop fasteners. In some implementations, the sensing electrode 1012 can be permanently integrated into the garment 1010. The medical device controller 1020 can be operably coupled to a therapy electrode 1014. For example, the therapy electrode 1014 can also be assembled into the garment 1010, or in some implementations, the therapy electrode 1014 can be permanently integrated into the garment 1010. In an example, the medical device controller 1020 includes a patient user interface 1060 to allow the patient to interface with an external wearable device. For example, the patient can use the patient user interface 1060 to respond to activity-related questions, prompts, and surveys as described herein.

[0245] Apart from Figure 10A Component configurations other than those shown in are also possible. For example, sensing electrodes 1012 can be configured to be attached at various locations around the body of patient 1002. Sensing electrodes 1012 can be operably coupled to medical device controller 1020 via connection pod 1030. In some implementations, sensing electrodes 1012 can be adhesively attached to patient 1002. In some implementations, at least one of therapy electrodes 1014 and sensing electrode 1012 can be included on a single integrated patch and adhesively applied to the patient's body.

[0246] The sensing electrodes 1012 can be configured to detect one or more cardiac signals. Examples of such signals include ECG signals and / or other sensed cardiac physiological signals from the patient. In some examples, as described herein, the non-ECG physiological sensors 1013 are components such as accelerometers, vibration sensors, RF-based sensors, and other measurement devices for recording additional non-ECG physiological parameters. For example, as described above, such non-ECG physiological sensors are configured to detect other types of patient physiological parameters and acoustic signals, such as tissue fluid levels, heart vibrations, lung vibrations, respiratory vibrations, patient movement, and the like.

[0247] In some examples, the therapy electrodes 1014 may also be configured to include sensors configured to detect ECG signals and other physiological signals of the patient. In some examples, the connection pod 1030 may include a signal processor configured to amplify, filter, and digitize the cardiac signals before transmitting them to the medical device controller 1020. One or more of the therapy electrodes 1014 may be configured to deliver one or more therapeutic defibrillation shocks to the body of the patient 1002 if the medical device 1000 determines that such treatment is warranted based on signals detected by the sensing electrodes 1012 and processed by the medical device controller 1020. Example therapy electrodes 1014 may include metal electrodes, such as stainless steel electrodes, that include one or more conductive gel deployment devices configured to deliver conductive gel to the metal electrodes prior to delivering the therapeutic shock.

[0248] In some implementations, a medical device as described herein can be configured to switch between a therapeutic medical device and a monitoring medical device configured to monitor a patient only (e.g., not provide or perform any therapeutic functions). For example, therapeutic components such as therapy electrodes 1014 and associated circuitry can be optionally decoupled from (or coupled to) the medical device or switched out of (or into) the medical device. For example, a medical device can have optional therapeutic elements (e.g., defibrillation and / or pacing electrodes, components, and associated circuitry) configured to operate in a therapeutic mode. The optional therapeutic elements can be physically decoupled from the medical device to convert the therapeutic medical device into a monitoring medical device for a specific use (e.g., for operation in a monitoring-only mode) or patient. Alternatively, the optional therapeutic elements can be deactivated (e.g., via a physical or software switch), thereby essentially converting the therapeutic medical device into a monitoring medical device for a specific physiological purpose or a specific patient. As an example of a software switch, an authorized person can access a protected user interface of the medical device and select a preconfigured option via the user interface or perform some other user action to deactivate the therapeutic elements of the medical device.

[0249] Figure 10B A wearable defibrillator 1000A for use in a hospital setting is illustrated as being external, ambulatory, and wearable by a patient 1002. In some implementations, the wearable defibrillator 1000A for use in a hospital setting can be configured to provide pacing therapy, such as to treat bradycardia, tachycardia, and asystole conditions. The wearable defibrillator 1000A for use in a hospital setting can include one or more ECG sensing electrodes 1012a, one or more therapy electrodes 1014a and 1014b, a medical device controller 1020, and a connection compartment 1030. For example, each of these components can be constructed and used as the same number of components of the medical device 1000. For example, the electrodes 1012a, 1014a, 1014b can include disposable adhesive electrodes. For example, the electrodes can include sensing components and therapy components disposed on separate sensing electrode and therapy electrode adhesive patches. In some implementations, both the sensing component and the therapeutic component can be integrated and provided on the same electrode adhesive patch, which is then attached to the patient. For example, a front adhesively-attachable therapy electrode 1014a is attached to the front of the patient's torso to deliver pacing or defibrillation therapy. Similarly, a back adhesively-attachable therapy electrode 1014b is attached to the back of the patient's torso. In an example scenario, at least three ECG adhesively-attachable sensing electrodes 1012a can be attached to at least one portion of the patient's chest near the right arm, one portion of the patient's chest near the left arm, and toward the bottom of the patient's chest in a manner prescribed by a trained professional.

[0250] Patients being monitored by hospital wearable defibrillators and / or pacing devices may be confined to a hospital bed or room for a significant amount of time (e.g., 75% or more of the patient's hospital stay). As a result, user interface 1060a may be configured to interact with users other than the patient (e.g., a nurse) to perform device-related functions such as initial device baseline, setting and adjusting patient parameters, and changing device batteries. Such interactions may also be performed using an HCP interface application (e.g., Figure 1 This is accomplished using the HCP interface application 122A).

[0251] In some examples, the hospital wearable defibrillator 1000A may further include one or more motion sensors, such as accelerometers, etc. For example, the accelerometer may be integrated into one or more of the sensing electrode 1012a (e.g., integrated into the same patch as the sensing electrode), the therapy electrode 1014a (e.g., integrated into the same patch as the therapy electrode), the medical device controller 1020, the connection pod 1030, and various other components of the hospital wearable defibrillator 1000A.

[0252] In some implementations, examples of therapeutic medical devices that include a digital front end according to the systems and methods described herein may include a short-term defibrillator and / or a pacing device. For example, a physician may prescribe such a short-term device for a patient presenting with syncope. The wearable defibrillator may be configured to monitor a patient presenting with syncope by, for example, analyzing the patient's physiological and cardiac activity for abnormal patterns that may indicate abnormal physiological function. For example, such abnormal patterns may occur before, during, or after a syncopal episode. In this example implementation of a short-term wearable defibrillator, the electrode assembly may be adhesively attached to the patient's skin and have a Figure 10A A similar configuration to the wearable defibrillator described for hospital use.

[0253] Figure 10C and Figure 10D An example wearable patient monitoring device without treatment or therapeutic functionality is illustrated. For example, such a device is configured to monitor one or more physiological parameters of a patient, such as for remote monitoring and / or diagnosis of a patient's condition. For example, such physiological parameters may include the patient's ECG information, tissue (e.g., lung) fluid levels, cardiac oscillations (e.g., using an accelerometer or microphone), and other relevant cardiac information. The cardiac monitoring device is a portable device that a patient can carry with them in their daily lives.

[0254] refer to Figure 10C, an example wearable patient monitoring device 1000C may include a tissue fluid monitor 1065 that uses RF-based technology to assess fluid levels and accumulation in a patient's body tissues. Such a tissue fluid monitor 1065 can be configured to measure fluid content in the lungs, typically for diagnosis and follow-up of pulmonary edema or pulmonary congestion in heart failure patients. The tissue fluid monitor 1065 may include one or more antennas configured to direct RF waves through the patient's tissue and measure an output RF signal in response to the waves that have passed through the tissue. In certain implementations, the output RF signal includes a parameter indicating the fluid level in the patient's tissue. In an example, the device 1000C may be a cardiac monitoring device that also includes digital sensing electrodes 1070 for sensing the patient's ECG activity. The device 1000C may pre-process the ECG signal under the control of a microprocessor via one or more ECG processing and / or conditioning circuits (such as an ADC, an operational amplifier, a digital filter, and / or a signal amplifier, etc.). Device 1000C may transmit information describing ECG activity and / or interstitial fluid levels to a remote server via a network interface for analysis. Additionally, in certain implementations, device 1000C may include one or more accelerometers as described herein for measuring motion signals.

[0255] refer to Figure 10D Another example wearable cardiac monitoring device 1000D can be attached to a patient via at least three adhesive digital cardiac sensing electrodes 1075 disposed around the patient's torso. Additionally, in certain implementations, the device 1000D can include one or more accelerometers for measuring motion signals as described herein, integrated into, for example, one or more digital sensing electrodes.

[0256] Cardiac devices 1000C and 1000D are used in cardiac monitoring and telemetry and / or continuous cardiac event monitoring applications, for example, in a patient population reporting irregular cardiac symptoms and / or conditions. These devices can transmit information describing ECG activity and / or tissue fluid levels to a remote server via a network interface for analysis. Example cardiac conditions that can be monitored include atrial fibrillation (AF), bradycardia, tachycardia, atrioventricular block, Lown-Ganong-Levine syndrome, atrial flutter, sinus node dysfunction, cerebral ischemia, (one or more) cardiac arrest and / or palpitations. For example, such a patient can be prescribed a cardiac monitoring device for an extended period of time (e.g., 10 to 30 days or longer). In some ambulatory cardiac monitoring and / or telemetry applications, the portable cardiac monitoring device can be configured to continuously monitor the patient's cardiac abnormalities, and upon detecting such an abnormality, the monitor can automatically send data related to the abnormality to the remote server. The remote server can be located in a 24-hour manned monitoring center, where the data is interpreted by qualified, cardiac-trained examiners and / or HCPs, and feedback is provided to the patient and / or designated HCP via detailed periodic or event-triggered reports. In some cardiac event monitoring applications, the cardiac monitoring device is configured to allow the patient to manually press a button on the cardiac monitoring device to report symptoms. For example, the patient can report symptoms such as missed beats, shortness of breath, dizziness, increased heart rate, fatigue, fainting, chest discomfort, weakness, dizziness and / or vertigo. The cardiac monitoring device can record the patient's predetermined physiological parameters (e.g., ECG information) for a predetermined amount of time (e.g., 1-30 minutes before and 1-30 minutes after the reported symptoms). As described above, the cardiac monitoring device can be configured to monitor the patient's physiological parameters other than cardiac-related parameters. For example, the cardiac monitoring device can be configured to monitor, for example, cardiac vibration signals (e.g., using an accelerometer or microphone), lung vibration signals, respiratory vibrations, sleep-related parameters (e.g., snoring, sleep apnea), tissue fluid, etc.

[0257] In some examples, the devices described herein (e.g., 10A to 10D ) can be achieved through Figure 10D The intermediary or gateway device 1080 shown in FIG. 1080 communicates with the remote server. For example, 10A to 10D The apparatus shown in the foregoing may be configured to include the apparatus as described herein with reference to e.g. Figure 4 Describes the communication capabilities of the network interface.

[0258] Although the subject matter contained herein has been described in some detail for purposes of illustration, it should be understood that such detail is intended for that purpose only and that the disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements within the scope of the appended claims. For example, it should be understood that the disclosure contemplates that, to the extent possible, one or more features of any embodiment can be combined with one or more features of any other embodiment.

[0259] Other examples are within the scope of the description and claims. In addition, some of the functions described above may be implemented using software, hardware, firmware, hardwiring, or any combination of these. Features that implement the functions may also be physically located at various locations, including being distributed so that parts of the functions are implemented at different physical locations.

[0260]

[0261]

[0262]

[0263]

[0264]

[0265]

[0266]

[0267]

[0268]

[0269]

[0270]

[0271]

[0272]

[0273]

[0274] Systems and methods for testing medical devices

[0275] CROSS-REFERENCE TO RELATED APPLICATIONS

[0276] This application claims priority to U.S. Provisional Patent Application No. 62 / 135,910, filed March 20, 2015, the disclosure of which is incorporated herein by reference in its entirety. Technical Field

[0277] The present disclosure relates to a wearable medical device and, in some aspects, to self-testing of the medical device. Background Art

[0278] The technology of correcting a too slow heart rate (bradycardia) using an implantable device commonly referred to as a pacemaker is available, which delivers microjoule electrical pulses to the slow-beating heart in order to speed up the heart rate to an acceptable level. In addition, it is well known to deliver high-energy electric shocks (e.g., 180 to 360 joules) by external paddles applied to the chest wall in order to correct the too fast heart rate and prevent the possible fatal consequences of ventricular fibrillation or certain ventricular tachycardias. Bradycardia, ventricular fibrillation, and ventricular tachycardia are all electrical dysfunctions (arrhythmias) of the heart. Each of these can lead to death within minutes unless corrected by appropriate electrical stimulation.

[0279] One of the most deadly forms of cardiac arrhythmia is ventricular fibrillation, which occurs when normal, regular electrical impulses are replaced by irregular and rapid pulses, causing the heart muscle to cease contracting normally and begin to tremble. Normal blood flow ceases, and if normal heart contractions are not restored, organ damage or death can result within minutes. Although victims often go unnoticed during ventricular fibrillation, it is often preceded by ventricular tachycardia, a regular but rapid rhythm of the heart. Because victims have no discernible warning of impending fibrillation, death often occurs before necessary medical assistance arrives. Because delays in applying corrective electrical therapy can result in death, implantable pacemakers and defibrillators have significantly improved the ability to treat these life-threatening conditions. When implanted in a patient, the device continuously monitors the patient's heart for treatable arrhythmias and, when such an arrhythmia is detected, delivers corrective electrical pulses directly to the heart.

[0280] People with ventricular fibrillation or ventricular tachycardia can often restore normal heart function through a procedure called cardioversion, which involves the synchronized application of electrical therapy to the heart muscle. Pacemakers and defibrillators, which apply corrective electrical pulses externally to the patient's chest wall, are also used to correct these life-threatening arrhythmias. However, their disadvantage is that they cannot be applied in time to save the patient's life during an acute arrhythmia emergency. This treatment needs to be administered within minutes to be effective.

[0281] Therefore, when patients are considered at high risk of dying from such arrhythmias, electronic devices are often implanted so that treatment is readily available when needed. However, patients who have recently suffered a heart attack or are awaiting such an implantable device may be kept in the hospital, where corrective electrical therapy is often within easy reach. However, prolonged hospitalization is often impractical due to its high cost or because the patient needs to engage in normal daily activities.

[0282] Wearable defibrillators have been developed for patients who have recently experienced a heart attack, are susceptible to cardiac arrhythmias and are at risk of temporary sudden death, and are awaiting implantation of a device. While these wearable defibrillators have been widely accepted and have a good reputation in the market, there is still a desire to develop improvements to such devices. Summary of the Invention

[0283] Non-limiting examples of embodiments will now be described in the following numbered clauses.

[0284] Clause 1: In an example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and monitoring and self-test circuitry configured to detect a triggering event and to initiate one or more self-tests based on the detection of the triggering event, wherein the ambulatory medical device senses the physiological signal of the patient substantially continuously over an extended period of time.

[0285] Clause 2: The mobile medical device of clause 1, wherein the triggering event comprises at least one of a shock and a vibration event experienced by the mobile medical device.

[0286] Clause 3: The mobile medical device of clause 1 or 2, wherein at least one of the shock and vibration events experienced by the mobile medical device corresponds to one of a shock level exceeding a predetermined shock level and a vibration level exceeding a predetermined vibration level.

[0287] Clause 4: The mobile medical device of any of clauses 1-3, wherein at least one of the shock and vibration events experienced by the mobile medical device corresponds to a shock duration exceeding a predetermined shock duration and a vibration duration exceeding a predetermined vibration duration.

[0288] Clause 5: The mobile medical device of any of clauses 1-4, further comprising an electromechanical switch for detecting at least one of a shock and a vibration event experienced by the mobile medical device.

[0289] Clause 6: The mobile medical device of any of clauses 1-5, further comprising at least one of a single-axis accelerometer, a multi-axis accelerometer, and a piezoelectric transducer for detecting at least one of shock and vibration events experienced by the mobile medical device.

[0290] Clause 7: The mobile medical device of any one of clauses 1-6, wherein the one or more self-tests comprise testing at least one of a device, a component, and a subsystem of the mobile medical device to ensure that at least one of the shock and the vibration event does not adversely affect at least one of the device, the component, and the subsystem.

[0291] Clause 8: The ambulatory medical device of any of clauses 1-7, wherein the triggering event comprises at least one of a software update, a device configuration update, and a patient parameter change.

[0292] Clause 9: The ambulatory medical device of clause 8, wherein at least one of a software update, a device configuration update, and a patient parameter change is remotely initiated.

[0293] Clause 10: The ambulatory medical device of clause 8 or 9, wherein the device configuration update comprises an update to one or more device parameters set in the ambulatory medical device.

[0294] Clause 11: The ambulatory medical device of any of clauses 1-10, wherein the triggering event is based on a user action or activity.

[0295] Clause 12: The ambulatory medical device of any one of clauses 1-11, wherein the triggering event is a wireless test signal.

[0296] Clause 13: The mobile medical device of clause 12, wherein the wireless test signal is initiated at a remote support center. Clause 14: The mobile medical device of any one of clauses 1-13, wherein the triggering event is based on detecting at least one of battery replacement, battery removal, and battery ejection.

[0297] Clause 15: The ambulatory medical device of any of clauses 1-14, wherein the triggering event is based on a battery level exceeding a predetermined battery charge threshold.

[0298] Clause 16: The ambulatory medical device of any of clauses 1-15, wherein the triggering event is based on a signal indicating that one or more electrodes are making insufficient contact with the patient's skin.

[0299] Clause 17: The ambulatory medical device of any of clauses 1-16, wherein the triggering event is responsive to detecting humidity exceeding a predetermined humidity level.

[0300] Clause 18: The ambulatory medical device of any of clauses 1-17, wherein the triggering event is responsive to detecting strain on a device component exceeding a predetermined strain level.

[0301] Clause 19: The ambulatory medical device of any one of clauses 1-18, wherein the triggering event is responsive to detecting a temperature of the device or at least one of its components being greater than a predetermined maximum temperature or less than a predetermined minimum temperature. Clause 20: The ambulatory medical device of any one of clauses 1-19, wherein the triggering event is responsive to detecting an operable connection between one or more electrodes and the medical device.

[0302] Clause 21: The ambulatory medical device of any one of clauses 1-20, wherein the triggering event comprises at least one of: replacing a garment comprising the ambulatory medical device worn about a patient's torso, replacing a patient signal sensor, and prompting replacement of at least one of the garment and the patient signal sensor in response to at least one of the garment and the patient signal sensor being worn over time due to use.

[0303] Clause 22: The ambulatory medical device of any of clauses 1-21, wherein the one or more self-tests comprise one or more tests related to a type of the triggering event.

[0304] Clause 23: An ambulatory medical device according to any one of clauses 1-22, wherein the triggering event is initiated by or within a device, component or subsystem of the ambulatory medical device, and the one or more self-tests include one or more tests of the device, component or subsystem of the ambulatory medical device that initiated or caused the triggering event.

[0305] Clause 24: The ambulatory medical device of any of clauses 1-23, wherein the monitoring and self-test circuitry is configured to classify the triggering event and, based on the classification, determine whether to initiate a self-test of the continuous-use medical device.

[0306] Clause 25: The ambulatory medical device of any of clauses 1-24, wherein the monitoring and self-test circuit is configured to store a flag indicative of a status of the triggering event in a memory of the ambulatory medical device.

[0307] Clause 26: The ambulatory medical device of any of clauses 1-25, wherein the monitoring and self-test circuit is always operable to monitor whether a main power source in the ambulatory medical device is available.

[0308] Clause 27: The mobile medical device of clause 26, wherein the primary power source is a primary battery used with the mobile medical device.

[0309] Clause 28: The mobile medical device of clause 26 or 27, wherein the secondary power source provides power to the monitoring and self-test circuitry when the primary power source is unable or unavailable to supply power.

[0310] Clause 29: The mobile medical device of clause 28, wherein the secondary power source comprises at least one of a backup battery, a capacitor, an inductor, and a supercapacitor.

[0311] Clause 30: An ambulatory medical device according to clause 28 or 29, wherein, when the secondary power source is providing power to the monitoring and self-test circuitry, in response to the triggering event, at least one of: executing a subset of the one or more self-test procedures using power from the secondary power source, and delaying execution of the subset of the one or more self-test procedures until the primary power source is supplying power to the monitoring and self-test circuitry.

[0312] Clause 31: An ambulatory medical device according to any of clauses 28-30, wherein the monitoring and self-test circuit, which operates solely using power from the auxiliary power source, is operable to monitor during at least one of: replacement of the primary power source; removal and donning of at least one of the sensing components by the patient for showering or bathing; replacement of clothing comprising the mobile medical device worn about the patient's torso; and replacement of a patient signal sensor.

[0313] Clause 32: In another example, a mobile medical device includes: a sensing component, which is disposed on a patient to detect physiological signals of the patient; one or more components, subsystems or systems, which are disposed within the mobile medical device and are operably coupled to the sensing component; a memory, which is configured to store one or more programs corresponding to one or more predetermined self-tests to be performed on the one or more components, subsystems or systems; and at least one processor that executes a self-test component, which is configured to cause execution of the one or more programs stored in the memory to perform the one or more predetermined self-tests on the one or more components, subsystems or systems according to a predetermined schedule; wherein the mobile medical device operates continuously during a monitoring period.

[0314] Clause 33: The ambulatory medical device of clause 32, wherein the monitoring period begins when the sensing component is caused to begin detecting a physiological signal of the patient and ends when the sensing component is caused to no longer detect a physiological signal of the patient.

[0315] Clause 34: The ambulatory medical device of clause 32 or 33, further comprising at least one treatment element for providing therapeutic shock to the patient.

[0316] Clause 35: The ambulatory medical device of any of clauses 32-34, wherein the one or more predetermined self-tests include at least one of the following battery tests: a battery capacity test, a battery internal resistance test, a battery status test, and a battery charger test.

[0317] Clause 36: The ambulatory medical device of any of clauses 32-35, wherein the one or more predetermined self-tests include a power converter test configured to test at least one of an output voltage and current of a converter, a capacitor charge retention test, and a capacitor charge / discharge test.

[0318] Clause 37: The mobile medical device of any of clauses 32-36, wherein the one or more predetermined self-tests include a test of a response button of the mobile medical device.

[0319] Clause 38: The mobile medical device of any of clauses 32-37, wherein the one or more predetermined self-tests comprise a test of one or more processors of the mobile medical device.

[0320] Clause 39: The mobile medical device of any of clauses 32-38, wherein the one or more predetermined self-tests include a test of at least one of the sensing component and a therapeutic element of the mobile medical device.

[0321] Clause 40: The ambulatory medical device of any of clauses 32-39, wherein the one or more predetermined self-tests include a test of at least one of a user interface of the ambulatory medical device and a communication module of the ambulatory medical device.

[0322] Clause 41: The mobile medical device of any of clauses 32-40, wherein the self-test component is always operable for the one or more predetermined self-tests regardless of whether mains power is available in the mobile medical device.

[0323] Clause 42: The mobile medical device of clause 41, wherein the primary power source is a primary battery for use with the mobile medical device.

[0324] Clause 43: The mobile medical device of clause 41 or 42, wherein an auxiliary power source provides power to the at least one processor when the primary power source is unable or unavailable to supply power.

[0325] Clause 44: The mobile medical device of clause 43, wherein the secondary power source comprises at least one of a backup battery, a capacitor, an inductor, and a supercapacitor.

[0326] Clause 45: An ambulatory medical device according to clause 43 or 44, wherein, while the auxiliary power source is providing power to the at least one processor, a subset of the one or more predetermined self-tests is performed using power from the auxiliary power source, and performing the subset of the one or more predetermined self-tests is delayed until the main power source is supplying power to the at least one processor.

[0327] Clause 46: In an example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and a circuit including a monitoring component for detecting a triggering event and a self-test component for executing one or more self-test procedures on the ambulatory medical device, wherein the ambulatory medical device is always operable during a monitoring period.

[0328] Clause 47: The ambulatory medical device of clause 46, wherein the monitoring period begins when the sensing component is caused to begin detecting a physiological signal of the patient and ends when the sensing component is caused to no longer detect a physiological signal of the patient.

[0329] Clause 48: The ambulatory medical device of clause 46 or 47, further comprising a therapeutic element for delivering electrotherapy to the patient.

[0330] Clause 49: The mobile medical device of any of clauses 46-48, wherein the mobile medical device comprises a garment worn about the patient's torso.

[0331] Clause 50: In another example, a continuous-use medical device includes: a sensing component for detecting a physiological signal of a patient; a memory; and a processor operably connected to the sensing component and the memory, the processor being configured to detect at least one of shock and vibration events experienced by the continuous-use medical device; and in response to detecting at least one of the shock and vibration events experienced by the continuous-use medical device, storing a flag in the memory of the continuous-use medical device.

[0332] Clause 51: The continuous-use medical device of clause 50, wherein the flag is configured to be retrieved from the memory when continuous use of the continuous-use medical device ends.

[0333] Clause 52: The continuous-use medical device of clause 50 or 51, wherein the indicia, when retrieved from the memory, provides an indication that at least one of a shock and a vibration event has occurred.

[0334] Clause 53: The continuous-use medical device of clause 52, wherein the indication is displayed on at least one display device along with information associated with the indication to allow a service person to view the indication and the information.

[0335] Clause 54: The continuous-use medical device of any of clauses 50-53, wherein at least one of the shock and vibration events experienced by the continuous-use medical device corresponds to one of a shock level exceeding a predetermined shock level and a vibration level exceeding a predetermined vibration level.

[0336] Clause 55: The continuous-use medical device of any of clauses 50-54, wherein at least one of the shock and vibration events experienced by the continuous-use medical device corresponds to a shock duration exceeding a predetermined shock duration and a vibration duration exceeding a predetermined vibration duration.

[0337] Clause 56: The continuous-use medical device of any of clauses 50-55, further comprising an electromechanical switch for detecting at least one of a shock and a vibration event experienced by the continuous-use medical device.

[0338] Clause 57: The continuous use medical device of any of clauses 50-56, further comprising at least one of a single-axis accelerometer, a multi-axis accelerometer, and a piezoelectric transducer for detecting at least one of shock and vibration events experienced by the continuous use medical device.

[0339] Clause 58: The continuous-use medical device of any one of Clauses 50-57, wherein the processor is further configured to initiate one or more continuous-use medical device self-tests in response to detecting at least one of a shock and a vibration event experienced by the continuous-use medical device.

[0340] Clause 59: A continuous use medical device as described in clause 58, wherein the one or more self-tests include testing of one or more devices, components, and subsystems of the continuous use medical device to ensure that at least one of the shock and the vibration events has not adversely affected any of the one or more devices, components, and subsystems.

[0341] Item 60: In an example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and a circuit comprising a monitoring component for monitoring a triggering event and a self-test component for executing one or more self-test procedures on the ambulatory medical device, wherein the monitoring component is always operable to monitor during a time period starting when the sensing component first senses a physiological signal of the patient and ending when the patient no longer requires the monitoring.

[0342] Clause 61: The mobile medical device of clause 60, wherein the physiological signal may include a cardiac signal.

[0343] Clause 62: The ambulatory medical device of clause 60 or 61, wherein the device further comprises a therapeutic element for delivering therapy to a patient.

[0344] Clause 63: An ambulatory medical device according to any one of clauses 60-62, wherein the treatment may include electrotherapy

[0345] Clause 64: The ambulatory medical device of any of clauses 60-63, wherein the continuous use medical device may comprise a garment worn by the patient.

[0346] Clause 65: An ambulatory medical device according to any one of clauses 60-64, wherein the physiological signal of the patient can be first sensed when the physiological signal is any of the following: collected by the sensing component; received from the sensing component by a processing component configured to process the physiological signal; processed by the processing component for the purpose of processing analysis; or stored in a memory.

[0347] Clause 66: An ambulatory medical device as described in any of clauses 60-65, wherein the patient no longer requires monitoring upon one or more of the following events: the patient is implanted with sensing and monitoring components; the patient's physical condition changes, thereby medically requiring the patient to use a different medical device; the patient is switched to a different device with more or fewer capabilities; the patient is switched to a different device used by a different caregiver; and the patient moves from one environment to another.

[0348] Clause 67: A mobile medical device according to any of clauses 60-66, wherein the monitoring component is operable to monitor during at least one of: changing the power source of the mobile medical device; removing and wearing the sensing component by the patient for the patient to shower or bathe; changing the clothing including the mobile medical device worn around the patient's torso; and replacement of the patient signal sensor.

[0349] Clause 68: The ambulatory medical device of any of clauses 60-67, wherein the patient signal sensor can be replaced in response to wear of the patient signal sensor due to use over a period of time.

[0350] Clause 69: In another example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and a circuit configured to detect a change in a software or firmware configuration of the ambulatory medical device, and a self-test component for executing one or more self-test procedures on the ambulatory medical device in response to the change in the software configuration.

[0351] Clause 70: The ambulatory medical device of clause 69, wherein the change in the software configuration may comprise a software or firmware update to the software of the ambulatory medical device.

[0352] Clause 71: The ambulatory medical device of clause 69 or 70, wherein the change to the software or firmware configuration may include an update to one or more device parameters set in the ambulatory medical device.

[0353] Clause 72: In another example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and a circuit including a monitoring component for monitoring a triggering event and a self-test component for performing one or more self-test procedures on the ambulatory medical device, wherein the monitoring component is always operable to monitor whether a main power source is available in the ambulatory medical device.

[0354] Clause 73: The mobile medical device of clause 72, wherein the primary power source can be a primary battery used with the mobile medical device.

[0355] Clause 74: The mobile medical device of clause 72 or 73, wherein the secondary power source can provide power to the monitoring component when the primary power source is unable or unavailable to supply power.

[0356] Clause 75: The ambulatory medical device of any of clauses 72-74, wherein the secondary power source may comprise a battery, a capacitor, a supercapacitor, an inductor, or other energy storage device.

[0357] Clause 76: An ambulatory medical device according to any one of clauses 72-75, wherein, in response to the triggering event when the secondary power supply is supplying power to the monitoring component, the self-test component can: (a) perform a first subset of the one or more self-test procedures using only power from the secondary power supply; or can (b) delay execution of a second subset of the one or more self-test procedures until the primary power supply is supplying power to the monitoring component.

[0358] Clause 77: The ambulatory medical device of any of clauses 72-76, wherein the first subset and the second subset of self-test procedures may be the same or different.

[0359] Clause 78: An ambulatory medical device according to any one of clauses 72-77, wherein step (a) or step (b) (of clause 76) can be performed during a period of time when the main power source is unable or unavailable to supply power to the first component, the period of time being at least one week or at least one month.

[0360] Clause 79: The ambulatory medical device of any of clauses 72-78, wherein the monitoring component is operable to directly or indirectly monitor the triggering event.

[0361] Clause 80: The ambulatory medical device of any of clauses 72-79, wherein the monitoring component can monitor the occurrence of the event indirectly via a component, subsystem, or system configured to convert the event into a form for processing by the monitoring component.

[0362] Clause 81: The ambulatory medical device of any of clauses 72-80, wherein the monitoring component may include one or more microprocessors, microcontrollers, or other integrated devices.

[0363] Clause 82: An ambulatory medical device according to any of clauses 72-81, wherein the monitoring component, which operates solely using power from the secondary power source, is operable to monitor during at least one of the following events: replacement of the primary power source; removal and wearing of the sensing component by the patient for the patient to shower or bathe; replacement of clothing comprising the mobile medical device worn about the patient's torso; and replacement of the patient signal sensor (e.g., due to wear over a period of time).

[0364] Item 83: In another example, an ambulatory medical device includes: a sensing component disposed on a patient for detecting a physiological signal of the patient; and a circuit comprising a monitoring component for monitoring a triggering event and a self-test component for performing one or more self-test procedures on the ambulatory medical device, wherein the monitoring component is always operable for the monitoring during a time period starting when the sensing component is first configured to begin detecting the patient's physiological signal and ending when the sensing component no longer detects the patient's physiological signal.

[0365] Clause 84: The ambulatory medical device of clause 83, wherein the device further comprises a therapeutic element for delivering electrotherapy to the patient.

[0366] Clause 85: The ambulatory medical device of clause 83 or 84, wherein the continuous use medical device may comprise a garment worn about the patient's torso.

[0367] Clause 86: In another example, a mobile medical device includes: a monitoring component for monitoring one or more triggering events that are different from the intended medical use or intended medical purpose of the medical device, and the triggering events may potentially prevent the medical device from functioning for its intended purpose; and a self-test component responsive to the one or more triggering events, for performing one or more self-test procedures on the mobile medical device.

[0368] Clause 87: An ambulatory medical device according to clause 86, wherein the one or more triggering events may include: excessive mechanical shock; exposure to a temperature greater than a predetermined maximum temperature or less than a predetermined minimum temperature; exposure to excessive moisture; excessive strain on a component, subsystem, or system of the medical device; exposure to temperature changes outside predetermined limits; exposure to a rate of temperature change that exceeds predetermined limits; prolonged vibration that exceeds a time limit or amplitude limit; a passage of time that exceeds a predetermined limit; or a change in ambient pressure that exceeds a predetermined limit.

[0369] Clause 88: In another example, a continuous-use medical device includes: one or more components, subsystems, and / or systems; a user interface; a memory storing one or more programs for testing the one or more components, subsystems, and / or systems; and a processing element operably coupled to the user interface, the one or more components, subsystems, and / or systems, and the memory, the processing element responsive to a triggering event for executing a subset of the one or more programs selected via the user interface.

[0370] Clause 89: The continuous-use medical device of clause 88, wherein a subset of the one or more programs can be selected prior to a triggering event.

[0371] Clause 90: In another example, a continuous-use medical device includes: one or more components, subsystems, and / or systems; a shock detector; a memory storing one or more programs for testing the one or more components, subsystems, and / or systems; and a processing element operably coupled to the memory, the shock detector, and the one or more components, subsystems, and / or systems, the processing element operable to execute the one or more programs in response to detecting an impact greater than a predetermined impact stored in the memory via the shock detector. Clause 91: The continuous-use medical device of clause 90, wherein the shock detector may include a piezoelectric transducer, a single-axis accelerometer, or a multi-axis accelerometer. BRIEF DESCRIPTION OF THE DRAWINGS

[0372] These and other features and characteristics of the present disclosure, as well as the methods of operation and function of the related elements of structure, and the combination of parts and economy of manufacture, will become more apparent upon consideration of the following description and appended claims with reference to the accompanying drawings, all of which form a part of this specification and in which like reference numerals designate corresponding parts in the various figures. It is to be expressly understood, however, that the drawings are for purposes of illustration and description only and are not intended as a definition of the limits of the invention.

[0373] Further features and other examples and advantages will become apparent from the following detailed description made with reference to the accompanying drawings, in which:

[0374] Figure 1 An exemplary wearable medical device is shown;

[0375] Figure 2 shows a front perspective view of an example monitor for a wearable medical device;

[0376] Figure 3 is an example block diagram illustrating how functional components of a wearable medical device may interact;

[0377] Figure 4 AB shows an example block diagram of a wearable medical device;

[0378] FIG5 is an example block diagram of a supervisory, e.g., watchdog timer (WDT) scheme for a wearable medical device;

[0379] FIG6 is a flowchart illustrating an example method of operating a wearable medical device;

[0380] FIG7 is an example flow chart of a self-test process;

[0381] Figure 8 is a non-exhaustive list of example triggering events for self-testing;

[0382] Figure 9 is a non-exhaustive list of exemplary self-tests; and

[0383] 10 is a flow chart of an exemplary self-test process for battery replacement.

[0384] DETAILED DESCRIPTION As used herein, the singular forms "a," "an," and "the" include plural referents unless the context clearly dictates otherwise.

[0385] As used herein, the terms "end," "upper," "lower," "right," "left," "vertical," "horizontal," "top," "bottom," "lateral," "longitudinal," and their derivatives shall relate to the invention as it is oriented in the accompanying drawings. However, it will be understood that the invention can assume various alternative orientations and, therefore, these terms should not be considered limiting. Furthermore, it will be understood that the invention can assume various alternative variations and sequences of stages, unless expressly specified to the contrary. It will also be understood that the specific devices and processes illustrated in the accompanying drawings and described in the following specification are examples. Accordingly, specific dimensions and other physical characteristics associated with the embodiments disclosed herein should not be considered limiting.

[0386] For the purpose of this specification, unless otherwise stated, all numerals expressing the amount of component, reaction conditions, size, physical property etc. used in the specification and claims should be understood to be modified by the term "about" in all cases. Therefore, unless otherwise indicated, the numerical parameters set forth in the following specification and the appended claims are approximate values, which can be varied according to the desired properties sought to be obtained by the present disclosure. At least, and without attempting to limit the application of the doctrine of equivalents to the scope of the claims, each numerical parameter should at least be interpreted according to the number of reported significant figures and by applying common rounding techniques. Although the numerical range and parameters setting forth the wide range of the present invention are approximate values, the numerical value set forth in the specific embodiments is reported as accurately as possible. However, any numerical value inherently contains certain errors, which are necessarily caused by the standard deviation found in their respective test measurements.

[0387] Furthermore, it should be understood that any numerical range recited herein is intended to include all subranges contained therein. For example, a range of "1 to 10" is intended to include any and all subranges between and including the recited minimum value of 1 and the recited maximum value of 10, i.e., all subranges starting with a minimum value equal to or greater than 1 and ending with a maximum value equal to or less than 10, as well as all subranges between, for example, 1 to 6.3, or 5.5 to 10, or 2.7 to 6.1.

[0388] As used herein, the terms "communication" and "communication" refer to the reception or transmission of one or more signals, messages, commands or other types of data. One unit or component communicating with another unit or component means that one unit or component is able to directly or indirectly receive data from the other unit or component and / or send data to the other unit or component. This can refer to a direct or indirect connection that can be wired and / or wireless in nature. In addition, two units or components can communicate with each other even if the transmitted data can be modified, processed, routed, etc. between the first and second units or components. For example, a first unit can communicate with a second unit even if the first unit passively receives data and does not actively send data to the second unit. As another example, a first unit can communicate with a second unit if an intermediate unit processes data from one unit and transmits the processed data to the second unit. It should be understood that many other arrangements are possible.

[0389] The present disclosure relates to tests performed in and / or on medical devices. For example, tests as disclosed herein can be performed in and / or on medical devices that are configured to be substantially always on or for continuous use (after initial power-on) for a predetermined medical purpose. For example, such medical devices can include monitoring devices that are configured to continuously monitor certain medical conditions of a patient for an extended period of time, such as more than 4 hours (e.g., treatment and monitoring devices, such as sleep apnea devices), more than 12 hours (e.g., treatment and / or monitoring devices, such as mobile cardiac monitoring devices, wearable defibrillator devices, etc.), and including substantially continuous monitoring over a period of time greater than 24 hours or even several days. Such devices can monitor the patient substantially continuously, except for periods during which the patient can periodically remove the device, such as for showering, refitting, replacing parts of the device, etc. In some embodiments, in addition to monitoring medical conditions, such devices can provide treatment to the patient based on detection of a predetermined medical condition. For example, a medical device as disclosed herein may include an automated always-on or continuously-on (or continuously-in-use) defibrillator, such as an in-facility defibrillator (e.g., for use in a confined space within a facility (such as, in a hospital setting, to a patient's room) or an outpatient wearable defibrillator. Such a device may be configured to monitor a patient for an arrhythmia condition, such as ventricular tachycardia (VT) or ventricular fibrillation (VF). If an arrhythmia condition is detected, the device may automatically deliver a defibrillation pulse or shock to treat the condition.

[0390] Other example devices capable of performing or running the tests and techniques discussed herein include automated always-on or continuously-on portable defibrillators for use in certain specialized conditions and / or environments, such as in combat zones or within emergency vehicles. Such devices may need to remain powered on so that they can be used immediately (or substantially immediately) in life-saving emergencies. In some examples, the automated extended-use defibrillators described herein may be capable of pacing, e.g., providing therapeutic pacing pulses to a patient.

[0391] For example, a continuous-use medical device as described herein may include at least one component, subsystem, or system (e.g., powered or unpowered circuitry or one or more processors) that is substantially always enabled during a predefined period or in a state that is immediately (or substantially immediately) usable for at least one of the primary uses of the device, as discussed in further detail below. For example, in the case of certain treatment and monitoring devices, such as sleep apnea devices, the predetermined period of time during which the device can substantially continuously monitor certain sleep apnea-related conditions may exceed four hours. In the case of certain other treatment and / or monitoring devices, such as mobile cardiac monitoring devices, ambulatory and / or wearable defibrillator devices, such predetermined period of time may exceed 12 hours. These devices may be configured for substantially continuous monitoring over periods of time exceeding 24 hours or even several days. As described above, such devices may monitor the patient substantially continuously, except for periods during which the patient may periodically remove the device (such as for showering, refitting, replacing parts of the device, etc.).

[0392] For example, a medical device that can implement one or more features described herein can be invasive (e.g., an implantable defibrillator and / or pacing device) or non-invasive (e.g., a wearable defibrillator). For example, a medical device can be mobile, e.g., the device can be and is designed to move with the patient.

[0393] Example medical devices are in the examples and reference Figure 1 The medical device may be configured as a wearable defibrillator, generally designated 1, such as available from Pittsburgh, Pennsylvania. Medical companies receive Wearable Defibrillator. and Chelmsford, Massachusetts. Wearable defibrillator 1 can be worn by a patient and can include a garment, generally designated by reference numeral 2, an electrode assembly, generally designated by reference numeral 3, and a monitor, generally designated by reference numeral 5, operatively connected to electrode assembly 3. Garment 2 can be configured as a harness, shirt, or other garment and is configured to allow the patient to wear defibrillator 1. Electrode assembly 3 can be configured to be assembled within garment 2.

[0394] Such a wearable defibrillator can typically be worn almost continuously for two to three months at a time. During the period that the patient wears the wearable defibrillator 1, the wearable defibrillator 1 can be configured to continuously monitor the patient's vital signs, be user-friendly and accessible, be as lightweight, comfortable and portable as possible, and be capable of delivering one or more life-saving therapeutic shocks when needed. Non-limiting examples of suitable wearable defibrillators are disclosed in U.S. Patent Nos. 4,928,690, 5,078,134, 5,741,306, 5,944,669, 6,065,154, 6,253,099, 6,280,461, 6,681,003, 8,271,082; and 8,369,944, the entire contents of which are incorporated herein by reference.

[0395] Continue to refer Figure 1 , the electrode assembly 3 includes a plurality of electrodes, such as electrodes 7a, 7b, 7c, and 7d, which contact the patient 9 when the wearable defibrillator 1 is worn by the patient 9. According to one example, the electrodes 7a, 7b, 7c, and 7d are configured to receive ECG signals from the patient 9. For example, the electrodes 7a, 7b, 7c, and 7d can be positioned on the patient 9 to receive ECG signals from the front-to-back channel and from the side-to-side channel. For example, the front-to-back (FB) channel can include one of the electrodes 7a, 7b, 7c, and 7d positioned on the chest of the patient 9 and another of the electrodes 7a, 7b, 7c, and 7d positioned on the back of the patient 9. For example, the side-to-side (SS) channel includes one of the electrodes 7a, 7b, 7c, and 7d located on the left side of the chest of the patient 9 and another of the electrodes 7a, 7b, 7c, and 7d located on the right side of the chest. In some examples, the electrodes 7a, 7b, 7c, and 7d can be operably connected to the distribution node 11 of the electrode assembly 3.

[0396] In some embodiments, the electrode assembly 3 may further include therapeutic pads 13a, 13b, and 13c operably connected to the distribution node 11. The therapeutic pads 13a, 13b, and 13c may be configured to deliver one or more lifesaving therapeutic shocks when needed. In some examples, the electrode assembly 3 may further include other sensing electrodes and devices (not shown), such as, but not limited to, a heartbeat sensor, an accelerometer, and sensors capable of measuring blood pressure, heart rate, thoracic impedance, respiratory rate, heart sounds, acoustic sensors, audio transducers, and the activity level of the subject. The electrode assembly 3 may further include a tactile stimulator 12, such as a vibrator, positioned within the distribution node 11 to provide tactile stimulation to the patient 9, as described in more detail below.

[0397] Monitor 5 can be operably connected to treatment pads 13a, 13b, and 13c and one or more of electrodes 7a, 7b, 7c, and 7d via, for example, trunk cable 15 or any other suitable cable or connection means. Wiring or other connection means can be used to connect at least a portion of distribution node 11 to electrodes 7a, 7b, 7c, and 7d and treatment pads 13a, 13b, and 13c. Alternatively, monitor 5 can be operably connected to one or more of electrodes 7a, 7b, 7c, and 7d, treatment pads 13a, 13b, and 13c, and distribution node 11 via a wireless connection or a combination of wireless and wired connections.

[0398] The distribution node 11 is configured to obtain ECG data from the electrodes 7a, 7b, 7c, and 7d, digitize the data, and transmit the data to the monitor 5. Thus, the distribution node 11 includes a processor, such as a band node processor (BNP) 17 (see Figure 3 、 4 A and 4B), which are operatively connected to the electrodes 7a, 7b, 7c and 7d and are configured to receive signals representing the ECG of the patient 9 from the electrodes 7a, 7b, 7c and 7d. The BNP 17 is connected to the patient via a controller area network (CAN) bus 19 (see Figure 3 and Figure 4 ) or any other suitable bus including the trunk cable 15 to communicate with the monitor 5. The BNP 17 is also configured to sense whether one or more of the electrodes 7a, 7b, 7c and 7d have become detached from the patient's body to control the tactile stimulator 12, and when a request is received from the monitor 5, trigger the electrode gel interface to provide electrolytic gel to the therapy pads 13a, 13b and 13c. Figure 2 And continue to refer to Figure 1 , the monitor 5 may include an external housing 31 having a port that allows the ECG electrodes 7a, 7b, 7c, and 7d of the electrode assembly 3 and the treatment pads 13a, 13b, and 13c to be operably connected to the monitor 5 via a trunk cable 15. The monitor may include one or more batteries, such as a rechargeable and removable battery (not shown) positioned within the battery housing. The battery has sufficient capacity to allow the wearable defibrillator 1 to administer one or more therapeutic shocks and to provide power to all internal components of the defibrillator 1. The external housing 31 also includes at least one and, for example, a pair of patient response buttons 41, which are positioned, for example, in the upper left corner of the housing 31. The housing 31 of the defibrillator may also include a display screen 43 for providing information to the patient 9 and for providing a user input device to the patient 9. Further details of the monitor 5 can be found in U.S. patent application No. 14 / 448,997, which is incorporated herein by reference in its entirety.

[0399] System Architecture of an Exemplary Medical Device

[0400] refer to Figure 3 And continue to refer to Figure 1 and Figure 2 , the functional components of the monitor 5 can be disposed within the outer housing 31 of the monitor 5. In one example, the functional components can be disposed on a distributed printed circuit board, as disclosed in U.S. patent application serial number 14 / 448,857, the entire contents of which are incorporated herein by reference. In one example, the functional components can include a discharge module 42, an energy storage module 44, a controller module 47, and a communication module 49. The discharge module 42 is used to selectively deliver energy pulses to the patient 9 via the therapy pads 13a, 13b, and 13c. The energy storage module 44 is operably connected to the discharge module 42. The controller module 47 can be operably connected to the energy storage module 44 and can be configured to control the delivery of the energy pulses to the patient 9. The communication module 49 is operably connected to the controller module 47.

[0401] In one example, the energy storage module 44 may include a high voltage power converter 64 (in Figure 4 ) and capacitive means, such as capacitor bank 67 (shown in Figure 4 ). Discharge module 42 may include at least one high voltage switch (not shown) and may be configured to selectively deliver energy pulses stored in energy storage module 44 to patient 9 based on signals from controller module 47. Energy pulses are transmitted from discharge module 42 to patient 9 via therapy pads 13a, 13b, and 13c through port 38.

[0402] By switching at least one high-voltage switch of discharge module 42, a biphasic waveform is delivered to patient 9. The operation of the pulse delivery system can be dynamic and dependent on the patient's body impedance when the pulse is delivered. For example, the amount of energy delivered can remain constant while varying the duration of the first and second phases. In another example, a monophasic waveform can be delivered to the patient depending on the patient's condition.

[0403] refer to Figure 4 A-4B, and continue to refer to Figure 1-3 , the controller module 47 may include one or more processors 69, 71 ( Figure 4 A), each processor operates under the control of a control program that, when executed, performs certain functions of the wearable defibrillator 1. In one example, the controller module 47 may include at least a first processor 69 and a second processor 71. In one example, the first processor 69 and the second processor 71 may be configured to function as disclosed in U.S. Patent No. 8,904,214, which is incorporated herein by reference in its entirety.

[0404] In some embodiments, one of the first processor 69 and the second processor 71 can be a multi-core processor. The interface between the processors 69 and 71 can be implemented as a serial interface. For example, the first processor 69 can be configured to include an operating system (e.g., accessible via a housing) and include one or more programs for controlling the entire continuous use device (including its various components, subsystems, and systems). For example, in a continuous use defibrillator, the second processor 71 can be configured to manage and operate a high voltage circuit for delivering, monitoring, and modifying one or more defibrillation pulses to a patient. In this regard, for example, the second processor 71 can be configured to operate as a slave device of the first processor 69. Thus, the monitoring components and self-test components as described herein can be executed within the first processor 69 and utilize housing features to interact with various other device components, subsystems, and systems.

[0405] In addition, or as an alternative to the processors 69, 71, the controller module 47 ( Figure 4 B) may include discrete and / or integrated electrical and / or electronic circuitry 75 configured to perform the functions described herein (alone or in combination with one or more of the processors 69, 71), but not under the control of the control program. In an example, the electrical and / or electronic circuitry 75 of the controller module 47 may include one or more discrete components, such as, but not limited to, one or more of the following: a transistor, a resistor, a capacitor, an inductor, a memristor, a diode, a speaker, a buzzer, a linear variable differential transformer (LVDT), a rotary encoder, a shaft encoder, an inclinometer, a motion sensor, a vibration sensor, a flow meter, a strain gauge, an accelerometer, a thermocouple, a thermopile, a thermistor, a resistance temperature detector (RTD), a bolometer, a magnetometer, a gauss meter, a hygrometer, a photoresistor, an LED or other light emitting device, and / or an antenna.

[0406] In an example, the electrical and / or electronic circuitry 75 of the controller module 47 may also or alternatively include one or more integrated circuits, such as, but not limited to, analog integrated circuits, digital integrated circuits, mixed-signal (analog and digital) integrated circuits, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), gate arrays, field-programmable gate arrays (FPGAs), and / or micro-electromechanical systems (MEMS). In an example, these one or more integrated circuits may include one or more analog-to-digital converters (ADCs), multiplexers, power regulators, or some combination thereof.

[0407] In another example, the controller module 47 is operably connected to the user interface 70 (including one or more response buttons 41 and / or display screen 43), the high-voltage power converter 64, and the discharge module 42. This configuration allows at least one of the first processor 69 and the second processor 71 to provide output to the patient 9, for example, via the display screen 43, and to accept input from the patient 9, such as from the response button 41, and to provide instructions to the high-voltage power converter 64 and / or the discharge module 42 to deliver a therapeutic shock to the patient 9. For example, Figure 4 A shows the first processor 69 and the second processor 71 or Figure 4 Circuitry 75, shown in FIG. 1 , may be used to provide certain functions within the wearable defibrillator 1 , such as, but not limited to: high voltage converter control; discharge module control; system real-time clock (date / time); execution of timing-critical software or functions, such as therapy pulse synchronization (e.g., synchronizing pulse delivery to avoid delivering pulses on the T wave); ECG acquisition from the CAN bus 19 ; ECG monitoring and arrhythmia detection; user interface control; therapy sequencing; audio message generation; and data communication and storage. An example of a method for detecting abnormal heart rhythms can be found in U.S. Patent No. 5,944,669 , which is assigned to the assignee of the present application and is incorporated herein by reference in its entirety. These functions may be performed by circuitry 75 distributed between the two processors 69 and 71 or by some combination of circuitry 75 and one or more of the processors 69 and 71 . For example, the first processor 69 may perform some of these functions, while other functions may be performed by the second processor 71 .

[0408] In some embodiments, the BNP 17 can be operably connected to the controller module 47. As described above, the BNP 17 can act as an ECG data acquisition engine for the controller module 47 via the CAN bus 19.

[0409] In one example, the communication module 49 can be controlled by at least one of the processors 69, 71, or circuitry 75 of the controller module 47 and can provide various devices for transmitting information to and from the monitor 5. For example, the communication module 49 can include a GPS transceiver, a Bluetooth transceiver, a Wi-Fi modem, and a cellular modem. The communication module 49 is configured to communicate with a remote server provided via a cellular modem. Alternatively, if cellular communication capabilities are unavailable, the communication module 49 can communicate with the remote server via a Wi-Fi modem.

[0410] For simplicity, the following will refer to Figure 4The invention is described with reference to a monitor 5 shown at A, which comprises a controller module 47 having processors 69, 71. However, this should not be construed as limiting the invention, as it is envisaged that the controller module 47 may also or instead of the processors 69, 71 comprise circuitry 75.

[0411] Refer to Figure 5 and continue to refer to Figure 4 A and 4B, in one example, the controller module 47 may include circuitry or circuitry 76, such as implemented on a programmable logic device (PLD), to provide, among other things, supervisory circuit functionality. The circuitry 76 may be configured to provide interface support and input / output conversion between the first processor 69, the second processor 71, and various system peripherals 77. The circuitry 76 may be configured to implement processor supervisory functionality. For example, such supervisory functionality may be a watchdog timer (WDT) function 75a, 75b. Typically, the supervisory functionality may monitor one or all three of the first processor 69, the second processor 71, and the BNP 17. In one example, the first processor 69 and the second processor 71 may be required to periodically service the WDT 75a, 75b functions to prevent timeouts.

[0412] Operation of an Exemplary Medical Device

[0413] Referring to FIG6 , the operation of monitor 5 will be described when an abnormal event is detected by the detection algorithm of one or both processors 69 and 71. Initially, at least one of processors 69 and 71 executes the detection algorithm at 100 and detects normal sinus rhythm. In one example, one of processors 69 and 71 can execute the detection algorithm while the other processor 69 and 71 is in a low-power sleep state. When the detection algorithm detects a VT or VF rhythm type, it dispatches the event to a state machine executing on at least one of processors 69 and 71. Upon receiving the event, the state machine exits the normal sinus rhythm monitoring state 100 and transitions to the notification state 102, which initiates a patient notification sequence to provide stimulation to the patient to make them aware that an event has been detected and initiates a capacitor charging cycle. After the capacitor is fully charged, a charge cycle complete event 104 can be sent to at least one of processors 69 and 71. As shown in FIG6 , a timer can be used to determine when to release the gel (see 106) and allow for the timing of the gel wet-out period (see 105) to reduce transthoracic impedance.

[0414] At any point after the notification state 102, the patient can cancel the treatment sequence by pressing the response button 41, and the system confirms the patient's response and stops charging the capacitor 110. This is shown by arrows 112, 115, and 116. If the patient does not respond to the alarm and the timer for gel wetting expires, the state machine issues a command 120 to at least one of the processors 69, 71 to activate the defibrillator and treat the patient. Since at least one of the processors 69, 71 continuously monitors the patient's heart rhythm, if defibrillation is successful, at least one processor 69, 71 can detect sinus rhythm and send an event notification to the state machine.

[0415] An automated continuous-use medical device, such as the wearable defibrillator 1, as described herein, can be used to monitor and optionally treat a patient. For example, the automated continuous-use medical device can be designed to be always on and configured to perform one or more self-tests, including but not limited to one or more event-driven self-tests, one or more periodic self-tests, one or more non-periodic self-tests, or some combination thereof. A non-limiting example of such a self-test will now be described with reference to a continuous-use defibrillator that is used to monitor an ambulatory patient and deliver an electric shock when necessary. However, the disclosure of the wearable defibrillator 1 herein should not be construed as limiting the present disclosure in any way, as it is contemplated that the present invention may also be used with any medical device that is designed to be always on to monitor and optionally treat a patient.

[0416] Typically, in a continuous-use medical device for monitoring an ambulatory patient and delivering an electric shock when necessary, one or more circuits or processors of the medical device (e.g., under the control of a program stored in a memory accessible to the one or more processors) can perform one or more self-tests described herein based on a triggering event (such as, but not limited to, one or more triggering events).

[0417] In one example, a continuous-use medical device can include one or more monitoring elements or components, such as circuits or processors, that are operable throughout the expected period of time that the patient is using the device and monitor for triggering events, as described in further detail below. For example, in some embodiments, one or more monitoring components can be operable throughout the life of the continuous-use device.

[0418] In some embodiments, one or more monitoring elements can include non-powered elements, e.g., elements that do not require external power to operate. For example, such an element can include a mechanical switch that can detect an impact or other device abuse to the device and change its state from on to off (or vice versa). This state change can cause the medical device to perform a self-test during continuous use. Alternatively, as described in detail below, the low-power microprocessor can be configured to always operate in a monitoring state, regardless of the main power state of the medical device.

[0419] In embodiments, a continuous use medical device may include one or more self-test components that may perform one or more self-tests based on a triggering event. For example, such a self-test component may include circuitry and / or a processor that may operate throughout the intended use cycle of the device, as described below. In some examples, one or more of the monitoring and self-test components may be included in a monitor 5 of a wearable defibrillator (see, e.g., Figure 1 Furthermore, it should be apparent to those skilled in the art that aspects of the monitoring element and the self-test assembly may be included together in a single circuit or microprocessor, or distributed across multiple circuits or microprocessors.

[0420] One or more examples described below in connection with triggering events for self-tests and self-tests performed by medical devices specifically refer to a microprocessor as an example of circuitry that can perform in the manner discussed in the examples. However, this should not be construed as limiting the present invention, as it is contemplated that the microprocessor referenced in any such examples can be replaced with any suitable and / or desired circuitry or circuitry that can perform the operations disclosed in the examples.

[0421] Certain example triggering events are described below in the context of an example continuous-use defibrillator. It should be understood that these examples are equally applicable to other continuous-use medical devices, including continuous-use cardiac monitoring devices or therapeutic devices, such as those configured for therapeutic current delivery (such as pacing) and / or TENS (transcutaneous electrical nerve stimulation).

[0422] In an example, the circuitry 75 of the controller module 47 of the continuous use medical device is configured to detect a triggering event, as described in further detail below. As described above, the triggering event can be any number of events detected by any number of sensors associated with the continuous use medical device. For example, the triggering event can be the detection of an impact on the continuous use medical device above a predetermined threshold by an impact detector (such as a piezoelectric transducer, a mechanical switch, a single-axis accelerometer, or a multi-axis accelerometer). For example, such an impact can be due to the continuous use medical device being dropped by the patient. In another example, the triggering event can be the detection of the removal of a sensing electrode from contact with the patient or the detection of a temperature exceeding exposure to a temperature greater than a predetermined maximum temperature or less than a predetermined minimum temperature by a temperature sensor associated with the continuous use medical device. In yet another example, the triggering event can be Figure 8 Any one or more of the triggering events listed in .

[0423] In one example, a continuous-use medical device can be configured to detect one or more of the triggering events and set a flag in the memory of the continuous-use medical device that one or more triggering events occurred. Depending on predefined rules in a program stored in the memory of the continuous-use device, the device may or may not initiate a self-test in response to the triggering event. The flag can be configured to be retrieved by a service person, for example, when the continuous use of the medical device is deemed to have ended. These flags are configured to provide the service person with an indication of a particular event that occurred during the patient's use of the continuous-use medical device and allow the service person to properly diagnose any problems with the continuous-use medical device. The indication provided by the flag can be displayed on a display of the continuous-use medical device or on an external display device operably connected to the continuous-use medical device when the device is being serviced.

[0424] Circuitry 75 can be configured to store a flag in a memory (e.g., memory available to processors 1 and 2 ( FIG. 5 ) of the continuous-use medical device). The flag can be in the form of a yes / no (or on / off) data element that is configured to indicate whether a potential triggering event has occurred, for example, based on one or more data conditions or thresholds corresponding to a monitored parameter. For example, if a flag is set to “yes” or “on,” an indication that a particular triggering event has occurred can be provided. On the other hand, if the flag is set to “no” or “off,” the element indicates that the conditions for the given triggering event have not been met. Using the detection of a shock example provided above, a shock detector signals to circuitry 75 of controller module 47 that the continuous-use medical device has experienced a shock or vibration event. As described below, circuitry 75 of controller module 47 analyzes signals from one or more shock or vibration detectors disposed within the device and determines whether the detected shock is above a predetermined threshold. If the shock or vibration exceeds the predetermined threshold or has a duration exceeding a predetermined duration level, circuitry 75 is configured to store the flag in the memory of the continuous-use medical device. In one embodiment, different flags can be used to record the violation of thresholds corresponding to shock or vibration. For example, a first flag may be used to record an event involving a violation of a predetermined shock or vibration threshold level, and a second flag may be used to record an event involving a violation of a predetermined shock or vibration duration level. Similarly, separate flags corresponding to each of shock detection and vibration detection events may be maintained.

[0425] The flag can be configured to be retrieved and / or read from the memory of the continuous-use device when such continuous use has ended. In one example, the use of the medical device can be considered to have ended when the medical device is returned to the manufacturer for repair. In this context, when the flag is retrieved from the memory, an indication of the occurrence of at least one triggering event (such as, but not limited to, detection of an impact, temperature change, or electrode detachment) can be provided. The indication can be displayed on a display device configured to allow service personnel to view such indications. This allows service personnel the opportunity to review various events that occur with the device while it is in continuous use so that they can accurately and effectively diagnose any problems with the device before returning the device to the patient or a new patient. The display device can be the display 43 of the continuous-use medical device, or it can be a display external to the continuous-use medical device and operably connected to the continuous-use medical device. The display can provide a code (e.g., a number, alphanumeric, color, shading, pattern, or other code) associated with the flag to indicate the priority, criticality, or other classification of the underlying flag. For example, such classification can be predefined by one or more rules associated with a program stored in the memory of the continuous-use medical device or a display device used by service personnel to view the flag information. For example, a shock event flag may be coded red to indicate a higher criticality than, for example, an electrode-off event.

[0426] In another example, the circuit 75 of the controller module 47 can be configured to classify the triggering event before storing the flag in the memory in response to at least one triggering event, and determine whether to store the flag in the memory or initiate a self-test of the continuous use medical device based on the classification. More specifically, some triggering events can be considered minor events that are unlikely to require a complete self-test of the continuous use medical device. In this case, the circuit 75 will only set a flag in the memory that the triggering event occurred for service personnel to review later, rather than running a self-test on the device. Such triggering events include, but are not limited to, detecting an impact to at least one medical device, detecting an electrode being removed from contact with the patient, and detecting a temperature exceeding a predetermined maximum temperature or less than a predetermined minimum temperature.

[0427] However, certain triggering events may adversely affect the manner in which the continuous-use medical device operates. Accordingly, the circuitry 75 of the controller module 47 may be configured to initiate a self-test if such a triggering event is detected. Such triggering events include, but are not limited to, detecting a replacement of the battery of the continuous-use medical device, completing a reset of the continuous-use medical device, and detecting the delivery of at least one electric shock to a patient.

[0428] Self-test trigger event

[0429] Initialization and Baseline In one example, circuitry (e.g., including a microprocessor) in a continuous-use defibrillator may run one or more self-tests as part of an initialization process for the continuous-use defibrillator, which may occur, for example, following a software- or user-initiated reset of the continuous-use defibrillator.

[0430] The tests described herein can be performed in a manner and at a time that does not interfere with the substantial use of the device. For example, if the device is actively performing an important task, such as charging a device capacitor, the device can suspend the scheduled test or even reset (depending on the reset conditions) until the task is completed (or cancel the test or reset entirely).

[0431] For example, the tests may be run before or after performing a baseline process (e.g., a process that records a baseline template of a patient's monitored parameters). An exemplary baseline process is described in U.S. Patent No. 5,944,669, the disclosure of which is incorporated herein in its entirety. For example, the baseline process may be initiated periodically or aperiodically in response to a predetermined event, and thus, the tests associated with the baseline process may follow a similar schedule.

[0432] In some examples, one or more self-tests can be based on the type of triggering event, as described in further detail below. For example, a triggering event initiated by or within a device, component, or subsystem of a medical device can be the basis for initiating a self-test of the device, component, or subsystem. In some cases, one or more of such self-tests can also include diagnostic tests of other devices, components, or subsystems associated with the device, component, or subsystem associated with the triggering event. For example, the triggering event can be a battery event, such as a battery replacement, removal, or ejection, as described below. A battery-related triggering event can also be based on a battery charge level exceeding a predetermined battery level threshold. Such a battery-related triggering event can result in the initiation of one or more battery-related self-tests. For example, such tests can include testing of the battery voltage, a high-voltage converter coupled to the battery, a battery power consumption test, a battery gas meter exhaustion test, and a battery internal resistance test. These battery-related tests can also include testing of components, devices, and / or subsystems that are directly or indirectly coupled to the battery.

[0433] In some embodiments, the triggering event may be an indication that an electrode has become dislodged or is causing a noisy ECG signal. Thus, one or more self-tests associated with an ECG event may include a test of the ECG sensor circuitry, a sensor impedance check, and / or an electrode integrity verification test.

[0434] Download patient information

[0435] Examples of initialization processes that can trigger a self-test include, but are not limited to, completing the downloading of all or part of a patient profile or an updated patient profile into a memory of the continuous-use defibrillator accessible by the microprocessor of the continuous-use defibrillator. The patient profile or updated patient profile may include data unique to the patient wearing the defibrillator during use. The patient profile (or portion thereof) may include, for example, but is not limited to, a baseline ECG signal or other criteria, such as a threshold heart rate value used by the defibrillator's microprocessor to determine whether the patient is experiencing an arrhythmia event and, if so, to deliver a shock.

[0436] Button actuation

[0437] In another example, the microprocessor of a continuous use defibrillator runs a self-test in response to actuation of one or more buttons of the defibrillator (eg, response button 41 of monitor 5) or as part of an initialization process (as described above) during use.

[0438] Periodically, aperiodically, or in response to a triggering event, the continuous use device can perform a test on the response button as follows. For example, the test can involve determining whether the response button circuit detects actuation of the response button. For example, the test on the response button can include determining whether one or more processors of the device are receiving an actuation signal associated with actuation of the response button.

[0439] Detection of mechanical shock or vibration

[0440] In another example, in response to the continuous-use defibrillator's microprocessor determining via the continuous-use defibrillator's accelerometer or other shock or vibration detection device (such as, but not limited to, a piezoelectric device) that the continuous-use defibrillator has experienced one or more shocks or vibrations exceeding a predetermined shock (amplitude) or vibration level or a predetermined time limit stored in a memory accessible to the microprocessor, the microprocessor can set a flag and / or initiate a self-test of the continuous-use defibrillator. In another example, the other shock detection device can be an electromechanical or mechanical switch that is configured to change state, for example, from an open state to a closed state, or vice versa, in response to experiencing a g-force that exceeds the g-force that the electromechanical or mechanical switch is designed to experience without changing state. In this manner, the device can be configured to determine whether any device, component, or subsystem of the medical device has been adversely affected by shock or vibration. For example, the microprocessor can be programmed to initiate a self-test of the continuous-use defibrillator in response to the electromechanical or mechanical switch changing state. Examples of continuous-use defibrillators capable of detecting shock are disclosed in U.S. patent application serial numbers 14 / 180,775 and 14 / 175,433 and U.S. Patent No. 8,676,313, each of which is incorporated herein by reference in its entirety. The continuous-use defibrillator may also include a GPS that can be used by the microprocessor to record the GPS location of the continuous-use defibrillator when it experiences a shock exceeding a predetermined shock level. Examples of precision microsensors used as electromechanical or mechanical switches for the applications described herein are the SQ-SEN, ASx, and MIN product lines from SignalQuest, Inc. of Lebanon, New Hampshire.

[0441] Remotely initiated self-test

[0442] In another example, if the continuous-use defibrillator includes wireless communication capabilities (such as, but not limited to, cellular telephone circuitry, Wi-Fi circuitry, and / or other suitable and / or desired wireless communication circuitry as described above), one or more self-tests can be triggered via the wireless communication capabilities. For example, via the continuous-use defibrillator's wireless communication capabilities, the continuous-use defibrillator can receive a wireless test signal that causes the microprocessor to initiate a self-test of the continuous-use defibrillator. In another example, if the continuous-use defibrillator's software or firmware, including patient profile information, is updated using the wireless capability, the microprocessor can initiate a self-test in response to the completion of such a software or firmware update. In another example, if a patient can utilize the wireless capability to wirelessly contact a remote support center to inquire about or notify a problem, the microprocessor can initiate a self-test of the continuous-use defibrillator in response to such a patient-initiated inquiry or notification, or in response to receiving a wireless communication (in some embodiments, not necessarily a test signal) from the remote support center. In another example, the microprocessor of the continuous-use defibrillator can be programmed to periodically or occasionally wirelessly transmit the results of the self-test to a remote service center for analysis or storage. If the remote service center determines that one or more self-tests (alone or compared to other self-tests that have been reported) indicate the possibility of a problem with a component, subsystem, or system of the continuous-use defibrillator, the customer service center can wirelessly contact the microprocessor via the wireless capability of the continuous-use defibrillator to cause the microprocessor to initiate the one or more self-tests and wirelessly report the results of the one or more self-tests back to the service center via the wireless capability of the defibrillator. In another example, when notifying a patient of a potential operational problem in the continuous-use defibrillator, and / or when updating a patient profile stored in the memory of the defibrillator, the service center can wirelessly request the microprocessor to perform one or more self-tests for any reason, for example, as part of a periodic or occasional assessment of the operational capabilities of the defibrillator, via the wireless capability of the defibrillator. It will be understood by those skilled in the art that other reasons may be considered and should not be limited to the reasons listed herein.

[0443] In another example, one or more self-tests can be downloaded to the continuous-use defibrillator at or about the time it is desired to perform the one or more self-tests. In this example, it is contemplated that the one or more self-tests can be wirelessly downloaded from an external device to a memory of the continuous-use defibrillator under the control of the continuous-use defibrillator's microprocessor, without requiring patient interaction to cause the downloading. Additionally or alternatively, a user of the continuous-use defibrillator can initiate a request to wirelessly download the one or more self-tests to the continuous-use defibrillator, for example, by pressing one or more buttons (real or virtual) on the monitor 5.

[0444] Download self-test during execution

[0445] In one example, one or all self-tests to be run by the external defibrillator can be wirelessly downloaded to a memory of the continuous-use defibrillator accessible to a microprocessor of the continuous-use defibrillator at or around the time the one or more self-tests are expected to be performed. Additionally or alternatively, the memory of the continuous-use defibrillator can store a first subset of one or more self-tests, and a second subset of one or more self-tests can be wirelessly downloaded to the continuous-use defibrillator at or around the time the second subset of one or more self-tests are expected to be performed. An advantage of storing zero or less than a complete self-test to be run on the continuous-use defibrillator is that the requirement for memory storage to permanently store the self-tests in the memory of the continuous-use defibrillator is reduced. Another advantage is that the downloaded self-tests can be customized to account for natural or age-related changes in components, subsystems, or systems of the continuous-use defibrillator.

[0446] In an example, the results of one or more self-tests can be wirelessly transmitted from the continuous-use defibrillator to a remote server or other remote storage device for storage in association with the continuous-use defibrillator. The remote server or storage device can also store or access other tests performed on the continuous-use defibrillator or other self-tests run by the continuous-use defibrillator. By examining the tests run on the continuous-use defibrillator or the self-tests run by the continuous-use defibrillator, trends in the operating status or tolerances of the components, subsystems, or systems of the continuous-use defibrillator can be analyzed for actual or impending failures, whereby appropriate remedial action can be taken to address the failure or impending failure, such as, but not limited to, dispatching a replacement component, subsystem, or system of the continuous-use defibrillator for replacement by the user, shipping a replacement continuous-use defibrillator, or issuing a recall alert for the continuous-use defibrillator.

[0447] It is contemplated that, in addition to or in lieu of the continuous-use defibrillator's wireless communication capabilities, the continuous-use defibrillator may also include wired communication capabilities, such as, but not limited to, plain old telephone service (POTS), a hard-wired Internet connection, a serial or parallel port, etc., for communicating with a remote device. In this example, the continuous-use defibrillator includes any suitable and / or desired communication circuitry and interfaces, such as a plug and / or receptacle, to facilitate such wired communication.

[0448] Assembly / disassembly sensing

[0449] In another example, a continuous-use defibrillator may include a harness or garment, such as a vest or shirt, that supports components, subsystems, or systems of the continuous-use defibrillator on the patient during use. Certain assembly may be required before equipping the patient with the defibrillator. For example, in a continuous-use defibrillator, an electrode belt may need to be assembled within the harness or garment. For example, the electrode belt may include components such as a distribution node, a therapy electrode, and / or a sensing electrode that can be inserted into a pocket in the garment. In such an example, the harness or garment may include a sensor coupled to a portion of the harness or garment that is proximate to or in contact with the harness and / or its components, and when the harness and / or its components come into contact with the harness or garment for assembly, the sensor notifies the microprocessor of the continuous-use defibrillator. In response to sensing an assembly (or disassembly) event via such a sensor, such as insertion or removal of a therapy electrode from a pocket in the garment, the microprocessor may initiate one or more self-tests of the continuous-use defibrillator. In another example, the device may sense the establishment of an operative connection between an electrode assembly (e.g., assembly 3) and a monitor (e.g., monitor 5) of the device. This connection may trigger one or more self-tests as described herein. In one example, a safety belt or garment can include one or more snaps, buckles, or fasteners that facilitate securing the safety belt or garment to the patient (or securing components, systems, and / or subsystems of the device within the garment) and removing the continuous-use defibrillator from the patient during use. Each snap, buckle, or fastener can include a sensor whose state can be detected by the microprocessor, and the sensor notifies the microprocessor when the snap, buckle, or fastener is in a closed state or an open state. In response to sensing that the snap, buckle, or fastener is in a closed state or an open state (or has transitioned to a closed state or an open state), the microprocessor can initiate one or more self-tests of the continuous-use defibrillator.

[0450] In one example, the snap, buckle, or fastener is a two-piece snap, buckle, or fastener, wherein a first piece of the snap, buckle, or fastener has a mating arrangement that positively mates with a corresponding mating arrangement of a second piece of the snap, buckle, or fastener. The first piece and the second piece can include a first conductive segment and a second conductive segment (including a snap, buckle, or fastener sensor), the first conductive segment and the second conductive segment being in contact when the two pieces are coupled together in a closed state (e.g., when a patient is wearing a continuous-use defibrillator), and the conductive segments being separated when the snap, buckle, or fastener is in an open state (e.g., when the patient is taking off or not wearing a continuous-use defibrillator). In an example, the first conductive segment can be coupled to a low voltage (e.g., 3 volts) source, while the second conductive segment can be coupled in parallel to an input of a microprocessor and coupled to ground potential via a current limiting resistor. In use, when the snap, buckle, or fastener is in an open state where the two segments are uncoupled, the input of the microprocessor coupled to the second conductive segment is biased to ground potential (similar to a logical zero) via the current limiting resistor. Instead, when the two segments are coupled together, the microprocessor input will detect the voltage of the low voltage source (similar to a logic source). Based on whether the microprocessor input senses a logic 0 or a logic 1, the microprocessor can determine whether the snap, buckle, or fastener is in an open or closed state, or when it transitions between an open and closed state, or vice versa, and can initiate a self-test upon any one or a combination of these events. Other detection mechanisms may include capacitive elements, inductive elements, and / or elements capable of detecting changes in resistance and / or impedance values.

[0451] Cycle test

[0452] In another example, the microprocessor of a continuous-use defibrillator may be programmed to perform different subsets of the total number of self-tests of the components, subsystems, or systems of the continuous-use defibrillator that can be run each time a self-test cycle is initiated in some manner. For example, assume that the microprocessor is programmed to run the following self-tests: (1) one or more I / O tests; (2) a battery voltage test; (3) a capacitor voltage test; (4) a high-voltage converter output test; (5) a battery drain test; (6) a battery gas meter test; e.g., draining faster / slower than it indicates; and (7) a component test, such as the internal resistance of the battery.

[0453] In a first test cycle, the microprocessor may run one or more of self-tests 1-3; in a second test cycle, the microprocessor may run one or more self-tests, such as 4-5; and in a third test cycle, the microprocessor may run one or more self-tests, such as 6-7. Alternatively, in the second test cycle, the microprocessor may run one or more self-tests, such as 3-5, and in the third test cycle, the microprocessor may run one or more self-tests, such as 5-7 (i.e., any combination of one or more tests in any test cycle may be the same as or different from any combination of one or more tests run in another test cycle).

[0454] Serialization mismatch

[0455] In another example, various components, subsystems, or systems of a continuous-use defibrillator can be serialized in a manner that can be read by a microprocessor to compare with serial numbers stored in a memory accessible to the continuous-use defibrillator's microprocessor. For example, unique serial numbers can be assigned to batteries, wireless devices, and the like of the continuous-use defibrillator, and these serial numbers can be stored in a memory, for example, in the form of a database, accessible to the continuous-use defibrillator's microprocessor, for example, during the setup of the continuous-use defibrillator. For example, unique serial numbers can be implemented by using radio frequency identification (RFID) tags on components. An example of using identification devices in continuous-use defibrillators is disclosed in U.S. patent application No. 14 / 448,761, which is incorporated herein by reference in its entirety. Thereafter, at one or more appropriate times, the microprocessor can read the serial number of each component and compare it with the serial number of the component stored in the memory. In the event that the read serial number does not match the serial number of the corresponding component, subsystem, or system stored in the memory, for example, when the component, subsystem, or system has been replaced by a similar component with a different serial number, the microprocessor can initiate a self-test. The self-test may include testing all components, subsystems, or systems of the continuous-use defibrillator that are testable by the microprocessor, or a subset of these components, subsystems, or systems, including components or subsystems detected by the microprocessor as having new serial numbers that are not stored in a memory of the continuous-use defibrillator accessible to the microprocessor.

[0456] For example, upon detecting that a component or subsystem has a new serial number that is not stored in a memory accessible to the microprocessor, the microprocessor may initiate a self-test of the new component or subsystem, and upon successfully passing the self-test, the microprocessor may store the new serial number in memory to replace the serial number of the replaced component or subsystem. However, if the new component or subsystem fails the self-test, the microprocessor may output a suitable indication of the fault, such as via an LED or visual display of the continuous-use defibrillator, or by signaling the occurrence of the fault via the wireless communication capability of the continuous-use defibrillator.

[0457] Current sensing

[0458] In another example, a continuous-use defibrillator may include a current sensor having an output that can be read and processed by a microprocessor directly, via an internal analog-to-digital converter (A-to-D) of the microprocessor, or indirectly (e.g., via a discrete A-to-D converter disposed in a signal path between the output of the current sensor and one or more inputs of the microprocessor and operating under the control of the microprocessor). More specifically, the microprocessor may sample the output of the current sensor and compare the sampled output to a preprogrammed value indicating an acceptable maximum (or minimum) current stored in a memory accessible to the microprocessor. If the sampled output of the current sensor exceeds the stored preprogrammed value, indicating that the current is too high (or too low), the microprocessor may initiate a self-test of one or more components, subsystems, or systems of the continuous-use defibrillator. In an example, the microprocessor may utilize a current sensor (e.g., an in-line resistor or a Hall effect sensor) to monitor the current output by the battery of the continuous-use defibrillator. If the microprocessor determines, via the current sensor, that the current supplied by the battery exceeds (or is less than) the current value stored in the memory accessible to the microprocessor, the microprocessor may initiate a self-test of one or more components, subsystems, or systems of the continuous-use defibrillator.

[0459] Temperature sensor

[0460] In another example, a continuous-use defibrillator may include a temperature sensor coupled to the microprocessor, either directly or via suitable A-to-D interface circuitry. The microprocessor may sample the output of the temperature sensor to detect the ambient temperature in which the continuous-use defibrillator is operating and may compare the ambient temperature to an upper temperature limit value stored in a memory accessible to the microprocessor, the upper temperature limit value indicating the maximum expected temperature to which the continuous-use defibrillator is designed to be exposed. In response to detecting an ambient temperature greater than a preprogrammed maximum value, the microprocessor may initiate a self-test of a component, subsystem, or system of the continuous-use defibrillator. In some embodiments, the memory may be programmed with a temperature value indicating the lowest expected temperature to which the continuous-use defibrillator will be exposed, and if the microprocessor determines, via the temperature sensor, that the ambient temperature is below the lower temperature value stored in the memory, the microprocessor may initiate a self-test of a component, subsystem, or system of the continuous-use defibrillator. In some examples, the microprocessor may also be programmed to sense temperature changes outside predetermined limits or exposure to a rate of temperature change outside predetermined limits.

[0461] Humidity sensor

[0462] In another example, a continuous use defibrillator can include a humidity sensor coupled to the microprocessor directly or via a suitable interface circuit. For example, a continuous use defibrillator can be rated according to an industry standard code, such as an International Protection Rating (IP rating). The humidity sensor can detect conditions and / or events, such as those implied by the IP rating of the device. For example, the humidity sensor can be configured to detect vertical dripping water and provide an alarm or take corrective action (e.g., events involving an IP22 rating). In some cases, the sensor can be configured to detect and respond to water falling as a spray at an angle (e.g., up to 60°) to vertical, splashing against the housing of the device from any direction, protrusion from a nozzle against the housing, water ingress and / or immersion.

[0463] In one example, a humidity sensor may include a pair of conductors held in a spaced relationship by or on a substrate. In the absence of moisture or water bridging the gap between the spaced conductors, no current will flow between the conductors in response to a voltage applied between the pair of spaced conductors. Conversely, in response to moisture bridging the gap between the spaced conductors, current will flow between the spaced conductors. The microprocessor may be programmed to initiate a self-test in response to detecting current flowing through the spaced conductors.

[0464] In some embodiments, the microprocessor can be programmed to not initiate a self-test based on the absence of current flowing across the spaced apart conductors, the current indicating the absence of water or moisture bridging the spaced apart conductors. To detect the current flowing through the spaced apart conductors, a moisture sensor can be coupled between an input of the microprocessor and a suitable low voltage source. The input can be an input that the microprocessor samples periodically or aperiodically, or can be an interrupt input of the microprocessor that, in response to detecting the current flowing through the spaced apart conductors, triggers an interrupt handling routine of the microprocessor that initiates a self-test of a component, subsystem, or system of the continuous use defibrillator to determine whether exposure to moisture has had any effect on the operation of one or more of the components, subsystems, or systems of the defibrillator.

[0465] Remaining battery power

[0466] In another example, the microprocessor can be programmed to initiate a self-test based on the remaining power stored in the battery of the continuous-use defibrillator. For example, upon detecting via A-to-D that the available power is at, for example, but not limited to, 90% of the maximum available power in the battery, the microprocessor can initiate a self-test of a component, subsystem, or system of the continuous-use defibrillator. It is contemplated that one or more other percentages of available power in the battery can be used as a basis for initiating such a self-test.

[0467] Critical error handling

[0468] In another example, in response to the microprocessor receiving notification of a potentially critical fault in a component, subsystem, or system of the continuous-use defibrillator, the microprocessor can be programmed to disable and / or initiate a self-test of the component, subsystem, or system experiencing the potentially critical fault. In some embodiments, the microprocessor can cause an appropriate alert to generate an alarm to alert the patient and / or a service center of the potential critical fault. The patient alert can be a tone output by a speaker, the flashing of one or more lights or LEDs on the continuous-use defibrillator, and / or a warning message displayed on a display of the continuous-use defibrillator. The alert to the service center can be provided via the aforementioned wired or wireless connection. For example, in response to the microprocessor determining that a self-test of a component, subsystem, or system of the continuous-use defibrillator has failed, the microprocessor can be programmed to take appropriate remedial action. In another example, in response to detecting a capacitor voltage input fault (e.g., of a capacitor of capacitor bank 67), the microprocessor can be programmed to learn the capacitor's charge time and then charge the capacitor via time measurement rather than directly reading the capacitor voltage. Once a service center is notified of a failure of a component, subsystem, or system of a continuous-use defibrillator, or of the entire continuous-use defibrillator, either via a microprocessor that automatically notifies the service center via a wired or wireless connection, or via notification by the user to the service center, the service center can record the occurrence of the failure and automatically initiate the process of sending a replacement component, subsystem, system, or continuous-use defibrillator to the patient, as appropriate. For example, if a self-test determines that a battery is out of tolerance, the service center is notified of this fact and can automatically initiate the process of sending a replacement battery to the patient.

[0469] Battery Replacement

[0470] When a battery is removed, replaced, or otherwise ejected, some of the self-tests described herein can be initiated (manually or automatically). For example, the battery compartment can include a sensor that detects when a battery is removed or inserted into the device and causes the device to initiate a selected series of self-tests. In some examples, the sensor can indicate when a battery may have fallen out of the battery compartment or otherwise been ejected. For example, in a continuous-use defibrillator, the patient or caregiver may change the defibrillator's battery daily. In this case, certain key self-tests can be performed immediately after the battery is replaced. For example, battery-related tests that check the battery's output voltage and current thresholds can be performed immediately when the battery is inserted into the battery compartment. In some examples, certain self-tests described herein can be initiated when the battery is replaced, but can be configured to be performed at different intervals, for example, every second or third time a battery removal / insertion event is detected. In some examples, if a key self-test fails, additional self-tests described herein can be initiated. In some examples, the patient can manually cause the device to perform one or more additional self-tests after inserting the battery.

[0471] As described above, some of the tests described herein may be performed daily, weekly, or monthly after the continuous-use defibrillator is initialized, e.g., after new patient parameters are installed in a memory accessible to the microprocessor, in response to detecting an event (such as a buckle sensor transitioning from an open state to a closed state or vice versa), a humidity sensor detecting humidity, the microprocessor detecting a new serial number of a component, subsystem, or system of the continuous-use defibrillator, the microprocessor detecting a shock exceeding a predetermined shock level via an accelerometer, receiving a wired or wireless test signal from an external source, detecting a current exceeding (or less than) a preprogrammed current via a current sensor, a temperature greater than or less than a preprogrammed maximum or minimum temperature, a gas meter value, etc.).

[0472] In the case of a continuous-use medical device (e.g., a continuous-use defibrillator) that includes multiple microprocessors, the detection of one or more events and the initiation of one or more self-tests can be under the control of one or more microprocessors. In another example, the continuous-use medical device can be configured such that a first microprocessor is primarily responsible for detecting the one or more events and initiating the one or more self-tests, while the second microprocessor can be configured to detect the one or more events and initiate the one or more self-tests in the event that the first microprocessor does not initiate the one or more self-tests in a timely manner in response to the occurrence of the one or more events, for example, the first microprocessor does not detect the one or more events or does not respond to the one or more events. In another example, the first microprocessor and the second microprocessor of the continuous-use medical device can be configured to respectively perform a first subset and a second different subset of available self-tests that can be performed.

[0473] Countdown Timer

[0474] In an example, a continuous-use defibrillator may include a countdown timer (CDT) (not necessarily the WDT mentioned above) having an output that can be sensed by a microprocessor and optionally reset via the microprocessor. The duration of the countdown period of the CDT may be selected by a person skilled in the art in any suitable and / or desired manner. The countdown period may be on the order of seconds, minutes, days, weeks, months, or years. The microprocessor may be configured to initiate one or more self-tests in response to the expiration of the countdown period. Optionally, the microprocessor may be operable to reset the countdown period to a starting value after the expiration of the previous countdown period. In another example, in addition to or in lieu of the CDT, the continuous-use defibrillator may include a time / date clock that the microprocessor may sample at different times, compare the difference between the two times / dates with a predetermined value stored in a memory, and initiate one or more self-tests when the difference exceeds the predetermined value.

[0475] Multitasking

[0476] In an example, the microprocessor can be multitasking, wherein a portion of the microprocessor's processing time is dedicated to patient monitoring and / or treatment, and another portion of the microprocessor's processing time is dedicated to performing one or more self-tests. In this example, it is contemplated that the processing time dedicated to patient monitoring does not compromise the microprocessor's ability to monitor and / or treat the patient.

[0477] User activity

[0478] In an example, the microprocessor can determine patient activity, for example, via an activity sensor such as an accelerometer, and can decide whether to perform one or more self-tests based on the determined activity. In one example, in response to the microprocessor determining that the patient is active and moving around, indicating the absence of a life-threatening cardiac event, the microprocessor can perform one or more self-tests. In another example, in response to the microprocessor determining that the patient is stationary and the patient's ECG signal is normal, the microprocessor can perform one or more self-tests. Furthermore, one or more user actions can be the basis for a self-test initiated by the device. For example, a patient can manually select one or more self-tests as described herein to cause the device to initiate the selected self-tests. For example, if a patient wishes to test the charge holding capacity, charging circuitry, and / or converter circuitry in conjunction with a readiness test, the patient can initiate corresponding self-tests of the relevant portions and / or components of the medical device. For example, a patient can use a user interface to navigate to a screen displaying a list of diagnostic device tests that the patient can select, for example, by touching a touch-sensitive display, a soft or physical button, providing a voice command, or other input. For example, a patient can be authorized to perform only a subset of the available self-tests on the device. In some embodiments, patient access to one or more self-tests can be remotely authorized via a remote wireless signal from a remote server. In this case, a remote technician can access one or more self-tests via a remote server. The patient can then interact with the medical device to have the test performed and view the results. The results of such tests can also be transmitted to the remote server and displayed to the remote technician via a workstation operatively coupled to the remote server.

[0479] Delivery after shock

[0480] In an example, the microprocessor may initiate one or more self-tests after administering one or more shocks to the patient.

[0481] Uploading or downloading data

[0482] In one example, the microprocessor can initiate one or more self-tests in response to uploading data to or downloading data from a memory or RFID tag of a continuously opened medical device (discussed below) (for example, but not limited to, via the communication module 49 or directly into or out of the RFID tag). The data can include software and / or firmware. The data can also or alternatively include parameters, constants and / or variables used in conjunction with the software and / or firmware. In an example, the microprocessor can set a flag in the memory when uploading or downloading data. At the appropriate time, in response to the flag being set, the microprocessor can start one or more self-tests.

[0483] Excessive Strain...

Claims

1. A cardiac system for efficiently publishing ECG data for subscription-based access, comprising: An externally wearable cardiac device configured to sense one or more ECG signals from the skin of a patient, the externally wearable cardiac device comprising: a memory configured to store a device identifier for uniquely identifying the externally wearable cardiac device among a plurality of externally wearable cardiac devices, and at least one processor coupled to the memory, the at least one processor configured to: subscribing to device-specific topics related to one or more device parameters used to control operation of the external wearable cardiac device, and publishing to a first topic related to information derived from the one or more ECG signals sensed by the external wearable cardiac device, the first topic being distinct from the device-specific topic, The device-specific subject incorporates the device identifier.

2. The cardiac system according to claim 1, wherein: The at least one processor is further configured to: receiving, via the device-specific topic, a message specifying one or more device settings associated with the external wearable cardiac device; and The one or more device settings are applied to the one or more device parameters of the external wearable cardiac device.

3. The cardiac system of claim 2, wherein: The one or more device settings include a positioning setting.

4. The cardiac system of claim 3, further comprising a device control service configured to: receiving input specifying the one or more device settings; generating a message specifying the one or more device settings based on the input; and The message is published to the device-specific topic.

5. The cardiac system of claim 1 , wherein: The at least one processor is further configured to: subscribing to a patient-specific topic related to device parameters for controlling operation of the external wearable cardiac device, the patient-specific topic being distinct from the device-specific topic and the first topic; receiving, via the patient-specific topic, a message specifying one or more patient settings associated with the patient; as well as The one or more patient settings are applied to the one or more device parameters for controlling operation of the externally wearable cardiac device.

6. The cardiac system of claim 5, wherein: The external wearable cardiac device comprises: one or more monitoring electrodes configured to sense the one or more ECG signals, and one or more therapy electrodes configured to deliver electrical therapy to the patient's skin; and The one or more patient settings include one or more shock settings assigned to the electrotherapy.

7. The cardiac system of claim 6, further comprising a device control service configured to: receiving input specifying the one or more patient settings; generating a message specifying the one or more patient settings based on the input; and The message is published to the patient-specific topic.

8. The cardiac system of claim 7, wherein: The at least one processor is further configured to: Generate an authentication code; and Verifying that the message specifying the one or more patient settings includes the authentication code.

9. The cardiac system of claim 1, wherein: The external wearable cardiac device is further configured to sense one or more heart sound signals from the patient; and The first topic is also related to information derived from the one or more heart sound signals sensed by the external wearable cardiac device.

10. The cardiac system of claim 1, wherein: The externally wearable cardiac device is further configured to collect device event data indicative of an ability of the externally wearable cardiac device to monitor and treat the patient; and The first topic also relates to information derived from device event data collected by the external wearable cardiac device.

11. The cardiac system of claim 10, wherein: The device event data includes one or more of a held response button condition, a disconnected therapy electrode condition, and a unable to treat condition.

12. The cardiac system of claim 1, wherein: The at least one processor is further configured to: deriving ECG data from the one or more ECG signals, identifying a cardiac arrhythmia condition of the patient indicated within the ECG data, and The ECG data is transmitted to a remote storage service using a first communication protocol; and publishing to the first topic includes publishing a message specifying a cardiac arrhythmia condition of the patient using a second communication protocol different from the first communication protocol.

13. The cardiac system of claim 12, wherein: The device-specific subject is a first device-specific subject; as well as Transmitting the ECG data to the remote storage service comprises: publishing a message specifying a request for an upload link to a second topic different from the first topic and the first device-specific topic, receiving a message specifying the upload link via a subscription to a second device-specific topic, the second device-specific topic being distinct from the first topic, the second topic, and the first device-specific topic, and The ECG data is transmitted to the remote storage service via the upload link.

14. The cardiac system of claim 12, further comprising the remote storage service, wherein: The remote storage service is configured as follows: receiving the ECG data using the first communication protocol; as well as A message identifying the ECG data is published using the first communication protocol to a second topic that is distinct from the first topic and the device-specific topic.

15. The cardiac system of claim 14, wherein: The message specifying the cardiac arrhythmia condition also specifies an identifier for the ECG data.

16. The cardiac system of claim 15, further comprising a message handling service configured to: receiving a message specifying a cardiac arrhythmia condition of the patient; receiving a message identifying the ECG data; as well as In response to receiving the message specifying a cardiac arrhythmia condition of the patient, a notification message is communicated to a reporting service.

17. The cardiac system of claim 16, further comprising the reporting service, wherein: The reporting service is configured to: receiving the notification message; as well as A process communicates an alert message to a recipient, the alert message specifying a connection between the patient's cardiac arrhythmia condition and the ECG data.

18. The cardiac system of claim 17, wherein: The externally-wearable cardiac device includes security credentials created during manufacture of the externally-wearable cardiac device; and The message handling service is further configured to: registering the security credentials, and Communications from the external wearable cardiac device are authenticated using the security credentials.

19. The cardiac system of claim 18, wherein: The security credential includes the device identifier, the device identifier being used to uniquely identify the externally wearable cardiac device among the plurality of externally wearable cardiac devices; as well as The message handling service is further configured to identify the external wearable cardiac device using the device identifier.

20. The cardiac system of claim 12, wherein: The first communication protocol is Hypertext Transfer Protocol (HTTP), and the second communication protocol is Message Queuing Telemetry Transport (MQTT).

21. A cardiac monitoring system having prioritized handling of certain clinical and operational communications, the cardiac monitoring system comprising: An externally wearable cardiac device configured to sense one or more electrocardiogram signals, i.e., one or more ECG signals, from a patient wearing the externally wearable cardiac device, the externally wearable cardiac device comprising: Network interface, a memory configured to store ECG data derived from the one or more ECG signals, and at least one processor coupled to the memory, the at least one processor being configured to: determining, based on the subset of the ECG data, an occurrence of a priority event associated with the external wearable cardiac device or a patient wearing the external wearable cardiac device, publishing a message specifying the priority event to a first topic via the network interface using a first communication protocol, and The ECG data is transmitted to a remote storage service via the network interface using a second communication protocol different from the first communication protocol.

22. The cardiac monitoring system of claim 21, wherein: The priority events include one or more of a cardiac arrhythmia condition of the patient and a noise condition of the external wearable cardiac device.

23. The cardiac monitoring system of claim 22, wherein: The ECG data includes one or more of an ECG segment, a heart rate, a QRS duration, and a QTC interval.

24. The cardiac monitoring system of claim 22, wherein: The external wearable cardiac device is further configured to: collecting device event data indicative of an ability of the external wearable cardiac device to deliver electrical therapy to the patient; receiving input via a user interface indicating that the patient's cardiac arrhythmia condition is false; as well as The electrical therapy is released in response to detecting the cardiac arrhythmia condition and not receiving an input indicating that the patient's cardiac arrhythmia condition is false.

25. The cardiac monitoring system of claim 24, wherein: The priority event is a first priority event; The memory is further configured to store operational data derived from the device event data; and The at least one processor is further configured to: determining, based on the subset of the operational data, an occurrence of a second priority event associated with the externally wearable cardiac device or a patient wearing the externally wearable cardiac device, and A message specifying the second priority event is published to the first topic via the network interface using the first communication protocol.

26. The cardiac monitoring system of claim 25, wherein: The second priority events include: an incapacity condition in which the external wearable cardiac device is unable to receive input indicating that the patient's cardiac arrhythmia condition is false; or An incapacity condition in which the externally wearable cardiac device is unable to release the electrical therapy in response to detecting the cardiac arrhythmia condition.

27. The cardiac monitoring system of claim 21, wherein: The external wearable cardiac device is further configured to sense one or more heart sound signals from the patient; The memory is configured to store heart sound data derived from the one or more heart sound signals; Determining the occurrence of the priority event includes determining the occurrence of the priority event based on the subset of the ECG data and the subset of the heart sound data; as well as The at least one processor is further configured to transmit the heart sound data to the remote storage service via the network interface using the second communication protocol.

28. The cardiac monitoring system of claim 27, wherein: The heart sound data includes one or more of S1, S2, S3 and S4.

29. The cardiac monitoring system of claim 21, wherein: The at least one processor is further configured to: receiving a message specifying one or more device settings associated with the external wearable cardiac device via a subscription to a device-specific topic implemented using the first communication protocol, the device-specific topic being different from the first topic; and The one or more device settings are applied to one or more operating parameters of the externally wearable cardiac device.

30. The cardiac monitoring system of claim 29, wherein: The memory is configured to store a device identifier for uniquely identifying the external wearable cardiac device among a plurality of external wearable cardiac devices; as well as The at least one processor is further configured to subscribe to the device-specific topic using the device identifier.

31. The cardiac monitoring system of claim 30, wherein: storing the device identifier in the memory during manufacture of the externally wearable cardiac device; and The device-specific topic includes a copy of a device identifier stored in the memory.

32. The cardiac monitoring system of claim 30, wherein: The at least one processor is further configured to: Generate an authentication code; and The message for specifying the one or more device settings is verified to include the authentication code.

33. The cardiac monitoring system of claim 29, wherein: The one or more device settings include a positioning setting.

34. The cardiac monitoring system of claim 21, wherein: The at least one processor is further configured to: receiving a message specifying one or more patient settings associated with a patient wearing the external wearable cardiac device via a subscription to a patient-specific topic implemented using the first communication protocol, the patient-specific topic being different from the first topic; as well as The one or more patient settings are applied to one or more operating parameters of the externally wearable cardiac device.

35. The cardiac monitoring system of claim 34, wherein: The external wearable cardiac device comprises: one or more monitoring electrodes configured to sense the one or more ECG signals, and one or more therapy electrodes configured to deliver electrical therapy to the patient's skin; and The one or more patient settings include one or more shock settings assigned to the electrotherapy.

36. The cardiac monitoring system of claim 21, wherein: The message specifying the priority event also specifies an identifier of the ECG data.

37. The cardiac monitoring system of claim 36, further comprising the remote storage service, wherein: The remote storage service is configured as follows: receiving the ECG data using the second communication protocol; as well as A message identifying the ECG data is published to a second topic using the first communication protocol, the second topic being different from the first topic.

38. The cardiac monitoring system of claim 37, further comprising a message handling service configured to: receiving a message specifying the priority event; receiving a message identifying the ECG data; and In response to receiving the message specifying the priority event, a notification message is communicated to a reporting service.

39. The cardiac monitoring system of claim 38, further comprising the reporting service, wherein: The reporting service is configured to communicate an alert message specifying a connection between the priority event and the ECG data in response to receiving the notification message.

40. The cardiac monitoring system of claim 38, wherein: The externally-wearable cardiac device includes security credentials created during manufacture of the externally-wearable cardiac device; and The message handling service is further configured to: registering the security credentials, and Communications from the external wearable cardiac device are authenticated using the security credentials.

41. The cardiac monitoring system of claim 40, wherein: The security credential includes a device identifier for uniquely identifying the externally wearable cardiac device among a plurality of externally wearable cardiac devices; as well as The message handling service is further configured to identify the external wearable cardiac device using the device identifier.

42. The cardiac monitoring system of claim 21, wherein: Transmitting the ECG data to the remote storage service comprises: publishing a message specifying a request for an upload link to a second topic different from the first topic; receiving a message specifying the upload link via a subscription to a device-specific topic implemented using the first communication protocol, the device-specific topic being different from the first topic and the second topic; and The ECG data is transmitted to the remote storage service via the upload link.

43. The cardiac monitoring system of claim 21, wherein: The first communication protocol is Message Queuing Telemetry Transport, or MQTT, and the second communication protocol is Hypertext Transfer Protocol, or HTTP.

44. A cardiac treatment system for use in bandwidth-challenged environments, the cardiac treatment system comprising: An externally wearable cardiac device configured to sense one or more ECG signals from a patient wearing the externally wearable cardiac device and to deliver electrical therapy in response to detecting a cardiac arrhythmia condition occurring in the patient, the externally wearable cardiac device comprising: At least one processor configured to: receiving, via a subscription to a patient-specific topic implemented in a bandwidth-efficient communication protocol, a first message specifying one or more patient settings associated with the patient, receiving, via a subscription to a device-specific topic implemented in the bandwidth-efficient communication protocol, a second message specifying one or more device settings associated with the external wearable cardiac device, applying the one or more patient settings and the one or more device settings to a plurality of operating parameters of the externally wearable cardiac device, and Operation of the externally wearable cardiac device is controlled based on the plurality of operating parameters.

45. The cardiac treatment system of claim 44, wherein The one or more patient settings specify one or more of a value for a patient baseline parameter, a value for a lead preference parameter, a value for a ventricular fibrillation rate parameter, a value for a ventricular tachycardia rate parameter, and a value for an electrotherapy energy parameter.

46. The cardiac treatment system of claim 44, wherein The one or more device settings specify one or more of a value of a location parameter, a value of a message handling service URL, and a value of an account lock parameter.

47. The cardiac treatment system of claim 44, further comprising a device control service configured to: receiving input specifying the one or more patient settings and the one or more device settings; generating the first message and the second message based on the input; publishing the first message to the patient-specific topic; as well as The second message is published to the device-specific topic.

48. The cardiac treatment system of claim 44, wherein The at least one processor is further configured to: generating a first authentication code and a second authentication code; and Verifying that the first message includes the first authentication code and verifying that the second message includes the second authentication code.

49. The cardiac treatment system of claim 44, wherein: The bandwidth-efficient communication protocol is Message Queuing Telemetry Transport (MQTT), Constrained Application Protocol (CoAP), Advanced Message Queuing Protocol (AMQP), Lightweight Machine-to-Machine Protocol (LWM2M), or Data Distribution Service (DDS).

50. The cardiac treatment system of claim 44, wherein Controlling the operation of the external wearable cardiac device includes: deriving ECG data from the one or more ECG signals; detecting the cardiac arrhythmia condition via the ECG data; controlling delivery of said electrical therapy in response to detecting said cardiac arrhythmia condition; controlling publishing of a third message specifying a cardiac arrhythmia condition of the patient to a first topic distinct from the patient-specific topic and the device-specific topic using the bandwidth-efficient communication protocol; and Transmission of the ECG data to a remote storage service using a transport protocol different from the bandwidth efficient communication protocol is controlled.

51. The cardiac treatment system of claim 50, wherein The transfer protocol is the Hypertext Transfer Protocol (HTTP) or the File Transfer Protocol (FTP).

52. The cardiac treatment system of claim 50, wherein The ECG data includes one or more of an ECG segment, a heart rate, a QRS duration, and a QTC interval.

53. The cardiac treatment system of claim 50, wherein: Controlling the operation of the external wearable cardiac device further includes: controlling acquisition of one or more heart sound signals from the patient; deriving heart sound data from the one or more heart sound signals; and The transmission of the heart sound data to the remote storage service using the transmission protocol is controlled.

54. The cardiac treatment system of claim 53, wherein The heart sound data includes one or more of S1, S2, S3 and S4.

55. The cardiac treatment system of claim 50, further comprising the remote storage service, wherein The remote storage service is configured as follows: receiving the ECG data using the transmission protocol; as well as A fourth message identifying the ECG data is published using the bandwidth-efficient communication protocol to a second topic that is distinct from the first topic, the device-specific topic, and the patient-specific topic.

56. The cardiac treatment system of claim 55, wherein The third message specifying the cardiac arrhythmia condition also specifies an identifier for the ECG data.

57. The cardiac treatment system of claim 56, further comprising a message handling service configured to: receiving the third message specifying a cardiac arrhythmia condition of the patient; receiving the fourth message identifying the ECG data; and In response to receiving the third message specifying a cardiac arrhythmia condition of the patient, a notification message is communicated to a reporting service.

58. The cardiac treatment system of claim 57, further comprising the reporting service, wherein The reporting service is configured to communicate, in response to receiving the notification message, an alert message specifying a link between the patient's cardiac arrhythmia condition and the ECG data.

59. The cardiac treatment system of claim 57, wherein The externally-wearable cardiac device includes security credentials created during manufacture of the externally-wearable cardiac device; and The message handling service is further configured to: registering the security credentials, and Communications from the external wearable cardiac device are authenticated using the security credentials.

60. The cardiac treatment system of claim 59, wherein The security credential includes a device identifier for uniquely identifying the externally wearable cardiac device among a plurality of externally wearable cardiac devices; as well as The message handling service is further configured to identify the external wearable cardiac device using the device identifier.

61. The cardiac treatment system of claim 50, wherein The device-specific subject is a first device-specific subject; as well as Transmitting the ECG data to the remote storage service comprises: publishing a fourth message specifying a request for an upload link to a second topic that is different from the first topic, the first device-specific topic, and the patient-specific topic, receiving a fifth message specifying the upload link via a subscription to a second device-specific topic, the second device-specific topic being distinct from the first topic, the second topic, the first device-specific topic, and the patient-specific topic, and The ECG data is transmitted to the remote storage service via the upload link.

62. The cardiac treatment system of claim 50, wherein Controlling the operation of the external wearable cardiac device further includes: collecting device event data indicative of an ability of the external wearable cardiac device to sense the one or more ECG signals and deliver the electrical therapy; and A fourth message specifying device event data collected by the external wearable cardiac device is published to the first topic.

63. The cardiac treatment system of claim 62, wherein: The device event data includes one or more of a held response button condition, a disconnected therapy electrode condition, and a unable to treat condition.

Images