Patent Application
20220183607
The present disclosure relates to monitoring cardiac and biometric signals of a patient and preparing cardiac health reports based on the monitored cardiac and biometric signals.
There are a wide variety of electronic and mechanical devices for monitoring and treating patients' medical conditions. In some examples, depending on the underlying medical condition being monitored or treated, medical devices such as cardiac monitors or defibrillators may be surgically implanted or externally connected to the patient. In some cases, physicians may use medical devices alone or in combination with drug therapies to treat conditions such as cardiac arrhythmias.
A patient with a known or suspected cardiac arrhythmia may be provided with a device that monitors the patient's cardiac activity. The device may transmit data on the patient's cardiac activity to a remote server, where the data is analyzed by a technician. The technician prepares a report on the patient's cardiac activity from the received data and transmits the report to the patient's physician for review. Based on the report of the patient's cardiac activity, the physician may make one or more recommendations for the patient's cardiac health.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The system includes a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient, and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac sensor is further configured to transmit the ECG signals and motion signals to a remote server. The system also includes the remote server in communication with the cardiac sensor and further in communication with a user interface. The remote server includes a database implemented in a non-transitory memory and a processor in communication with the database. The processor is configured to store the ECG signals and the motion signals in the database and identify an arrhythmia event based on the received ECG signals. The processor is also configured to determine, based on the motion signals, contextual biometric information of the patient for the arrhythmia event and display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient.
Implementations of the cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the following features. In some implementations, the processor is configured to determine the arrhythmia event based on the received ECG signals by determining an onset of the arrhythmia event based on the received ECG signals. In some implementations, the processor is further configured to determine an arrhythmia contextual time period around the onset of the arrhythmia event. In some implementations, the processor is configured to determine, based on the motion signals, the contextual biometric information of the patient for the arrhythmia event during the arrhythmia contextual time period. In some implementations, the processor is configured to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient by displaying on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation. In some implementations, the processor is further configured to determine an offset of the arrhythmia event based on the received ECG signals. The processor is also configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by further displaying on the user interface an arrhythmia offset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator is overlaid on the contextual biometric information. In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30 minute time period during which the offset of the arrhythmia event occurred, a 15 minute time period during which the offset of the arrhythmia event occurred, or a 10 minute time period during which the offset of the arrhythmia event occurred.
In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's posture. In some implementations, the changes in the patient's posture include changes in a degree of the patient's posture. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's activity level. In implementations, the changes in the patient's activity level include changes in a type of the patient's activity level. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's respiration. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by further displaying when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's sleep status. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the arrhythmia event, and further display, on the user interface, the biometric summary for the arrhythmia event. In some implementations, the processor is configured to determine the biometric summary for the arrhythmia event by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration of the patient, a sleep status of the patient, or heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the arrhythmia event, and display the biometric summary for the arrhythmia event by displaying the one or more human-readable phrases that describe the biometric summary.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient, and further display, on the user interface, at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the arrhythmia event overlaid on the contextual biometric information of the patient, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia event. In some implementations, the processor is configured to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia event on a second screen.
In some implementations, the arrhythmia contextual time period is a default time period. In some implementations, the processor is further configured to determine an arrhythmia type for the arrhythmia event, and determine the arrhythmia contextual time period based on the arrhythmia type for the arrhythmia event. In some implementations, the processor is further configured to determine a biometric status of the patient at the onset of the arrhythmia event, and determine the arrhythmia contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30 minute time period during which the onset of the arrhythmia event occurred, a 15 minute time period during which the onset of the arrhythmia event occurred, or a 10 minute time period during which the onset of the arrhythmia event occurred. In some implementations, the arrhythmia contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer. In some implementations, the cardiac monitoring device further includes a portable gateway configured to transmit the sensed ECG signals and acquired motion signals to the remote server. In some implementations, the portable gateway includes the motion sensor.
In some implementations, the arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The system includes a cardiac monitoring device. The cardiac monitoring device includes a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient, and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac sensor is further configured to identify an arrhythmia event based on the ECG signals, determine biometric information for the patient based on the motion signals, and transmit, to a remote server, the identified arrhythmia event, ECG signals corresponding to the arrhythmia event, and the biometric information for the patient. The system also includes the remote server in communication with the cardiac sensor and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the identified arrhythmia event, the ECG signals corresponding to the arrhythmia event, and the biometric information for the patient in the database. The processor is also configured to determine, from the biometric information for the patient, contextual biometric information of the patient for the arrhythmia event, and display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient.
Implementations of the cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the following features. In some implementations, the processor is configured to determine the arrhythmia event based on the received ECG signals by determining an onset of the arrhythmia event based on the received ECG signals. In some implementations, the processor is further configured to determine an arrhythmia contextual time period around the onset of the arrhythmia event. In some implementations, the processor is configured to determine, based on the motion signals, the contextual biometric information of the patient for the arrhythmia event during the arrhythmia contextual time period. In some implementations, the processor is configured to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient by displaying on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation. In some implementations, the processor is further configured to determine an offset of the arrhythmia event based on the received ECG signals. The processor is also configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by further displaying on the user interface an arrhythmia offset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator is overlaid on the contextual biometric information. In some implementations, the arrhythmia contextual time period includes at least two of: a two hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30 minute time period during which the offset of the arrhythmia event occurred, a 15 minute time period during which the offset of the arrhythmia event occurred, or a 10 minute time period during which the offset of the arrhythmia event occurred.
In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's posture. In some implementations, the changes in the patient's posture include changes in a degree of the patient's posture. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's activity level. In implementations, the changes in the patient's activity level include changes in a type of the patient's activity level. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's respiration. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by further displaying when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the processor is configured to display the arrhythmia event overlaid on the contextual biometric information of the patient by displaying changes in the patient's sleep status. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the arrhythmia event, and further display, on the user interface, the biometric summary for the arrhythmia event. In some implementations, the processor is configured to determine the biometric summary for the arrhythmia event by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration of the patient, a sleep status of the patient, or heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the arrhythmia event, and display the biometric summary for the arrhythmia event by displaying the one or more human-readable phrases that describe the biometric summary.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient, and further display, on the user interface, at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the arrhythmia event overlaid on the contextual biometric information of the patient, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia event. In some implementations, the processor is configured to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia event on a second screen.
In some implementations, the arrhythmia contextual time period is a default time period. In some implementations, the processor is further configured to determine an arrhythmia type for the arrhythmia event, and determine the arrhythmia contextual time period based on the arrhythmia type for the arrhythmia event. In some implementations, the processor is further configured to determine a biometric status of the patient at the onset of the arrhythmia event, and determine the arrhythmia contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30 minute time period during which the onset of the arrhythmia event occurred, a 15 minute time period during which the onset of the arrhythmia event occurred, or a 10 minute time period during which the onset of the arrhythmia event occurred. In some implementations, the arrhythmia contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer. In some implementations, the cardiac monitoring device further includes a portable gateway configured to transmit the sensed ECG signals and acquired motion signals to the remote server. In some implementations, the portable gateway includes the motion sensor.
In some implementations, the arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The system includes a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac sensor is further configured to transmit the ECG signals and motion signals to a remote server. The system also includes the remote server in communication with the cardiac sensor and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the ECG signals and the motion signals in the database, determine an onset of an arrhythmia event based on the received ECG signals, determine an arrhythmia contextual time period around the onset of the arrhythmia event, and determine, based on the motion signals, contextual biometric information of the patient during the arrhythmia contextual time period. The processor is also configured to display on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation.
Implementations of the cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the following features. In some implementations, the processor is further configured to determine an offset of the arrhythmia event based on the received ECG signals, and further display on the user interface an arrhythmia onset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator is overlaid on the biometric graphical representation. In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30 minute time period during which the offset of the arrhythmia event occurred, a 15 minute time period during which the offset of the arrhythmia event occurred, or a 10 minute time period during which the offset of the arrhythmia event occurred.
In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the biometric graphical representation includes changes in the patient's posture over the arrhythmia contextual time period. In some implementations, the changes in the patient's posture include changes in a degree of the patient's posture over the arrhythmia contextual time period. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture over the arrhythmia contextual time period. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the biometric graphical representation includes changes in the patient's activity level over the arrhythmia contextual time period. In some implementations, the changes in the patient's activity level include changes in a type of the patient's activity level over the arrhythmia contextual time period. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the biometric graphical representation includes changes in the patient's respiration over the arrhythmia contextual time period. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration over the arrhythmia contextual time period. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the changes in the patient's respiration include when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the biometric graphical representation includes changes in the patient's sleep status over the arrhythmia contextual time period. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is also further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the arrhythmia event and further display on the user interface the biometric summary for the arrhythmia event. In some implementations, the processor is configured to determine the biometric summary for the arrhythmia event by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration of the patient, a sleep status of the patient, or a heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the arrhythmia event and display the biometric summary for the arrhythmia event by displaying the one or more human-readable phrases that describe the biometric summary.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the arrhythmia onset graphical indicator overlaid on the biometric graphical representation, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia event. In some implementations, the processor is configured to display, on the user interface, the arrhythmia onset graphical indicator overlaid on the biometric graphical representation on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia event on a second screen.
In some implementations, the arrhythmia contextual time period is a default time period. In some implementations, the processor is further configured to determine an arrhythmia type for the arrhythmia event and determine the arrhythmia contextual time period based on the arrhythmia type for the arrhythmia event. In some implementations, the processor is further configured to determine a biometric status of the patient at the onset of the arrhythmia event and determine the arrhythmia contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30 minute time period during which the onset of the arrhythmia event occurred, a 15 minute time period during which the onset of the arrhythmia event occurred, or a 10 minute time period during which the onset of the arrhythmia event occurred. In some implementations, the arrhythmia contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer. In some implementations, the cardiac monitoring system further includes a portable gateway configured to transmit the sensed ECG signals and acquired motion signals to the remote server. In some implementations, the portable gateway further includes the motion sensor.
In some implementations, the arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The system includes a cardiac monitoring device. The cardiac monitoring device includes a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac sensor is further configured to determine an onset of an arrhythmia event based on the ECG signals, determine biometric information for the patient based on the motion signals, and transmit the onset of the arrhythmia event, ECG signals corresponding to the arrhythmia event, and the biometric information for the patient to a remote server. The system also includes the remote server in communication with the cardiac sensor and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the onset of the arrhythmia event, the ECG signals corresponding to the arrhythmia event, and the biometric information for the patient in the database, determine an arrhythmia contextual time period around the onset of the arrhythmia event, and determine, from the biometric information for the patient, contextual biometric information of the patient during the arrhythmia contextual time period. The processor is also configured to display on the user interface a graphical timeline including the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation.
Implementations of the cardiac monitoring system for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the following features. In some implementations, the processor is further configured to determine an offset of the arrhythmia event based on the received ECG signals, and further display on the user interface an arrhythmia onset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator is overlaid on the biometric graphical representation. In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30 minute time period during which the offset of the arrhythmia event occurred, a 15 minute time period during which the offset of the arrhythmia event occurred, or a 10 minute time period during which the offset of the arrhythmia event occurred.
In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the biometric graphical representation includes changes in the patient's posture over the arrhythmia contextual time period. In some implementations, the changes in the patient's posture include changes in a degree of the patient's posture over the arrhythmia contextual time period. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture over the arrhythmia contextual time period. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the biometric graphical representation includes changes in the patient's activity level over the arrhythmia contextual time period. In some implementations, the changes in the patient's activity level include changes in a type of the patient's activity level over the arrhythmia contextual time period. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the biometric graphical representation includes changes in the patient's respiration over the arrhythmia contextual time period. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration over the arrhythmia contextual time period. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the changes in the patient's respiration include when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the biometric graphical representation includes changes in the patient's sleep status over the arrhythmia contextual time period. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is also further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the arrhythmia event and further display on the user interface the biometric summary for the arrhythmia event. In some implementations, the processor is configured to determine the biometric summary for the arrhythmia event by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration of the patient, a sleep status of the patient, or a heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the arrhythmia event and display the biometric summary for the arrhythmia event by displaying the one or more human-readable phrases that describe the biometric summary.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the arrhythmia onset graphical indicator overlaid on the biometric graphical representation, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia event. In some implementations, the processor is configured to display, on the user interface, the arrhythmia onset graphical indicator overlaid on the biometric graphical representation on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia event on a second screen.
In some implementations, the arrhythmia contextual time period is a default time period. In some implementations, the processor is further configured to determine an arrhythmia type for the arrhythmia event and determine the arrhythmia contextual time period based on the arrhythmia type for the arrhythmia event. In some implementations, the processor is further configured to determine a biometric status of the patient at the onset of the arrhythmia event and determine the arrhythmia contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30 minute time period during which the onset of the arrhythmia event occurred, a 15 minute time period during which the onset of the arrhythmia event occurred, or a 10 minute time period during which the onset of the arrhythmia event occurred. In some implementations, the arrhythmia contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer. In some implementations, the cardiac monitoring device further includes a portable gateway configured to transmit the sensed ECG signals and acquired motion signals to the remote server. In some implementations, the portable gateway includes the motion sensor.
In some implementations, the arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for patient-provided symptom inputs includes a cardiac monitoring device including a cardiac sensor configured to be coupled to a patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac monitoring device is configured to receive a patient-provided symptom input indicating that the patient is experiencing a suspected cardiac-related symptom and transmit the sensed ECG signals, the acquired motion signals, and the patient-provided symptom input to a remote server. The system also includes the remote server in communication with the cardiac monitoring device and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the ECG signals, the motion signals, and the patient-provided symptom input in the database, determine a symptom contextual time period around a time of the patient-provided symptom input, and determine, based on the motion signals, contextual biometric information of the patient during the symptom contextual time period. The processor is also configured to display on the user interface a graphical timeline including the symptom contextual time period around the time of the patient-provided symptom input, a symptom graphical indicator corresponding to the patient-provided symptom input, and a biometric graphical representation of the contextual biometric information of the patient during the symptom contextual time period. The symptom graphical indicator is overlaid on the biometric graphical representation.
Implementations of the cardiac monitoring system for displaying contextual biometric information for patient-provided symptom inputs can include one or more of the following features. In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the biometric graphical representation includes changes in the patient's posture over the symptom contextual time period. In some implementations, the changes in the patient's posture include changes in a decree of the patient's posture over the symptom contextual time period. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture over the symptom contextual time period. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the biometric graphical representation includes changes in the patient's activity level over the symptom contextual time period. In some implementations, the changes in the patient's activity level include changes in a type of the patient's activity level over the symptom contextual time period. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the biometric graphical representation includes changes in the patient's respiration over the symptom contextual time period. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration over the symptom contextual time period. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the changes in the patient's respiration include when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the biometric graphical representation includes changes in the patient's sleep status over the symptom contextual time period. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the patient-provided symptom input and further display on the user interface the biometric summary for the patient-provided symptom input. In some implementations, the processor is configured to determine the biometric summary for the patient-provided symptom input by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration over the patient, a sleep status of the patient, or heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the patient-provided symptom input and display the biometric summary for the patient-provided symptom input by displaying the one or more human-readable phrases.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the symptom graphical indicator overlaid on the biometric graphical representation, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the patient-provided symptom input. In some implementations, the processor is configured to display, on the user interface, the symptom graphical indicator overlaid on the biometric graphical representation on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the patient-provided symptom input on a second screen.
In some implementations, the symptom contextual time period is a default time period. In some implementations, the processor is further configured to determine a symptom type for the patient-provided symptom input and determine the symptom contextual time period based on the symptom type for the patient-provided symptom input. In some implementations, the processor is further configured to determine a biometric status of the patient at the time of the patient-provided symptom input and determine the symptom contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the cardiac monitoring device further includes a portable gateway configured to receive the patient-provided symptom input. In some implementations, the portable gateway includes a visual display and a gateway processor in communication with the visual display. The gateway processor is configured to display, on the visual display, a symptom screen including a list of potential cardiac-related symptoms to the patient, and receive the patient-provided symptom input as a selection, via the symptom screen, of one or more of the potential cardiac-related symptoms. In some implementations, the portable gateway is configured to transmit the sensed ECG signals, acquired motion signals, and patient-provided symptom input to the remote server. In some implementations, the portable gateway includes the motion sensor. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom input. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom input via a tapping of the cardiac sensor by the patient.
In some implementations, the symptom contextual time period includes at least one of: a two hour time period including the time of the patient-provided symptom input, an hour time period including the time of the patient-provided symptom input, a 30 minute time period including the time of the patient-provided symptom input, a 15 minute time period including the time of the patient-provided symptom input, or a 10 minute time period including the time of the patient-provided symptom input. In some implementations, the symptom contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer.
In some implementations, the suspected cardiac-related symptom comprises at least one of: light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, or shortness of breath. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying contextual biometric information for patient-provided symptom inputs is provided. The system includes a cardiac monitoring device including a cardiac sensor configured to be coupled to a patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac monitoring device is configured to determine biometric information for the patient based on the motion signals, receive a patient-provided symptom input indicating that the patient is experiencing a suspected cardiac-related symptom, and transmit the biometric information, the patient-provided symptom input, and ECG signals corresponding to the patient-provided symptom input to a remote server. The system also includes the remote server in communication with the cardiac monitoring device and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the biometric information, the patient-provided symptom input, and the ECG signals corresponding to the patient-provided symptom input in the database, determine a symptom contextual time period around a time of the patient-provided symptom input, and determine, from the biometric information for the patient, contextual biometric information of the patient during the symptom contextual time period. The processor is also configured to display on the user interface a graphical timeline including the symptom contextual time period around the time of the patient-provided symptom input, a symptom graphical indicator corresponding to the patient-provided symptom input, and a biometric graphical representation of the contextual biometric information of the patient during the symptom contextual time period. The symptom graphical indicator is overlaid on the biometric graphical representation.
Implementations of the cardiac monitoring system for displaying contextual biometric information for patient-provided symptom inputs can include one or more of the following features. In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, the biometric graphical representation includes changes in the patient's posture over the symptom contextual time period. In some implementations, the changes in the patient's posture include changes in a decree of the patient's posture over the symptom contextual time period. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture over the symptom contextual time period. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, the biometric graphical representation includes changes in the patient's activity level over the symptom contextual time period. In some implementations, the changes in the patient's activity level include changes in a type of the patient's activity level over the symptom contextual time period. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, the biometric graphical representation includes changes in the patient's respiration over the symptom contextual time period. In some implementations, the changes in the patient's respiration include changes in a type of the patient's respiration over the symptom contextual time period. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, the changes in the patient's respiration include when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, the biometric graphical representation includes changes in the patient's sleep status over the symptom contextual time period. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to determine a biometric summary for the patient-provided symptom input and further display on the user interface the biometric summary for the patient-provided symptom input. In some implementations, the processor is configured to determine the biometric summary for the patient-provided symptom input by determining at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration over the patient, a sleep status of the patient, or heart rate recovery of the patient. In some implementations, the processor is further configured to determine one or more human-readable phrases that describe the biometric summary for the patient-provided symptom input and display the biometric summary for the patient-provided symptom input by displaying the one or more human-readable phrases.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the symptom graphical indicator overlaid on the biometric graphical representation, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the patient-provided symptom input. In some implementations, the processor is configured to display, on the user interface, the symptom graphical indicator overlaid on the biometric graphical representation on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the patient-provided symptom input on a second screen.
In some implementations, the symptom contextual time period is a default time period. In some implementations, the processor is further configured to determine a symptom type for the patient-provided symptom input and determine the symptom contextual time period based on the symptom type for the patient-provided symptom input. In some implementations, the processor is further configured to determine a biometric status of the patient at the time of the patient-provided symptom input and determine the symptom contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the cardiac monitoring device further includes a portable gateway configured to receive the patient-provided symptom input. In some implementations, the portable gateway includes a visual display and a gateway processor in communication with the visual display. The gateway processor is configured to display, on the visual display, a symptom screen including a list of potential cardiac-related symptoms to the patient, and receive the patient-provided symptom input as a selection, via the symptom screen, of one or more of the potential cardiac-related symptoms. In some implementations, the portable gateway is configured to transmit the sensed ECG signals, acquired motion signals, and patient-provided symptom input to the remote server. In some implementations, the portable gateway includes the motion sensor. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom input. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom input via a tapping of the cardiac sensor by the patient.
In some implementations, the symptom contextual time period includes at least one of: a two hour time period including the time of the patient-provided symptom input, an hour time period including the time of the patient-provided symptom input, a 30 minute time period including the time of the patient-provided symptom input, a 15 minute time period including the time of the patient-provided symptom input, or a 10 minute time period including the time of the patient-provided symptom input. In some implementations, the symptom contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patch. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to the skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes. Additionally, the sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer.
In some implementations, the suspected cardiac-related symptom comprises at least one of: light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, or shortness of breath. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs, over predetermined use periods, is provided. The system includes a cardiac monitoring device including a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac monitoring device is configured to transmit the sensed ECG signals and the acquired motion signals to a remote server. The system also includes the remote server in communication with the cardiac sensor and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the ECG signals, the motion signals, and patient-provided symptom inputs in the database, determine, based on the received ECG signals, arrhythmia events that occurred in the patient over a predetermined use period, and determine, based on the motion signals, a biometric context summary for the predetermined use period. The processor is also configured to provide, via the user interface, a summary view of the arrhythmia events and/or the patient-provided symptom inputs over the predetermined use period by presenting information about each of the arrhythmia events and/or each of the patient-provided symptom inputs over the predetermined use period by presenting information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and information about the biometric context summary. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary is presented within a predetermined relationship in the summary view.
Implementations of the cardiac monitoring system for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs, over predetermined use periods, can include one or more of the following features. In some implementations, the biometric context summary includes a summary of posture of the patient over the predetermined use period. In some implementations, the information about the biometric context summary includes changes in the patient's posture over the predetermined use period. In some implementations, the information about the biometric context summary includes types of posture. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of posture or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of posture. In some implementations, the types of posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the biometric context summary includes a summary of an activity level of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's activity level over the predetermined use period. In some implementations, the information about the biometric context summary includes types of activity levels. In some implementations, the types of activity levels include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of activity level or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of activity level. In some implementations, the biometric context summary further includes a summary of heart rate recovery of the patient.
In some implementations, the biometric context summary includes a summary of respiration of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's respiration over the predetermined use period. In some implementations, the information about the biometric context summary includes types of respiration. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of respiration or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of activity level. In some implementations, the types of respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration.
In some implementations, the biometric context summary includes a summary of a sleep status of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's sleep status over the predetermined use period. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was asleep or a proportion of the patient-provided symptom inputs occurring while the patient was asleep. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the summary view of the arrhythmia events and/or patient-provided symptom inputs, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia events and/or the patient provided symptom inputs. In some implementations, the processor is configured to display, on the user interface, the summary view of the arrhythmia events and/or the patient-provided symptom inputs on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia events and/or the patient-provided symptom inputs on a second screen.
In some implementations, the predetermined relationship includes presenting, on a first axis, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and, on a second axis, the information about the biometric context summary. In some implementations, the predetermined relationship includes presenting one or more human-readable phrases including information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary. In some implementations, the processor is further configured to, for each of the arrhythmia events, determine a type of arrhythmia event to which the arrhythmia event belongs. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a plurality of types of arrhythmia events. The plurality of types of arrhythmia events includes each type of arrhythmia event that occurred in the patient over the predetermined use period. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a proportion of each type of arrhythmia event that occurred in the patient over the predetermined use period. In some implementations, the processor is further configured to provide the summary view of the arrhythmia events by presenting a graphical timeline including the predetermined use period. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a timing of each patient-provided symptom input on the graphical timeline including the predetermined use period. In some implementations, the predetermined use period includes at least one of: 24 hours, 48 hours, 72 hours, a week, two weeks, or a month. In some implementations, the predetermined use period is user-specified via the user interface.
In some implementations, the cardiac monitoring device is configured to receive, over the predetermined use period, patient-provided symptom inputs indicating that the patient is experiencing a suspected cardiac-related symptom. In some implementations, the cardiac monitoring device further includes a portable gateway. The cardiac monitoring device is configured to transmit to the remote server via the portable gateway. In some implementations, the portable gateway is configured to receive the patient-provided symptom inputs. In some implementations, the portable gateway includes a visual display and a gateway processor in communication with the visual display. The gateway processor is configured to display, on the visual display, a symptom screen including a list of potential cardiac-related symptoms to the patient, and receive the patient-provided symptom inputs as selections, via the symptom screen, of one or more of the potential cardiac-related symptoms. In some implementations, the portable gateway includes the motion sensor. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom inputs. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom inputs via tapping of the cardiac sensor by the patient.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patient. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. The sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in communication via a plurality of cables to the plurality of ECG electrodes. The sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer.
In some implementations, each arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, each patient-provided symptom input is associated with a suspected cardiac-related symptom. Each suspected cardiac-related symptom includes at least one of: light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, or a shortness of breath. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a cardiac monitoring system for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs, over predetermined use periods, is provided. The system includes a cardiac monitoring device including a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The cardiac monitoring device is configured to determine, based on the ECG signals, arrhythmia events that occurred in the patient over a predetermined use period, determine biometric information for the patient based on the motion signals, and transmit the determined arrhythmia events, ECG signals corresponding to the arrhythmia events, ECG signals corresponding to the patient-provided symptom inputs, and the biometric information for the patient to a remote server. The system also includes a remote server in communication with the cardiac monitoring device and further in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The processor is configured to store the determined arrhythmia events, the ECG signals corresponding to the arrhythmia events, the patient-provided symptom inputs, the ECG signals corresponding to the patient-provided symptom inputs, and the biometric information for the patient in the database, and determine, from the biometric information for the patient, a biometric context summary for the predetermined use period. The processor is also configured to provide, via the user interface, a summary view of the arrhythmia events and/or the patient-provided symptom inputs over the predetermined use period by presenting information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and information about the biometric context summary. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary is presented within a predetermined relationship in the summary view.
Implementations of the cardiac monitoring system for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs, over predetermined use periods, can include one or more of the following features. In some implementations, the biometric context summary includes a summary of posture of the patient over the predetermined use period. In some implementations, the information about the biometric context summary includes changes in the patient's posture over the predetermined use period. In some implementations, the information about the biometric context summary includes types of posture. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of posture or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of posture. In some implementations, the types of posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the biometric context summary includes a summary of an activity level of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's activity level over the predetermined use period. In some implementations, the information about the biometric context summary includes types of activity levels. In some implementations, the types of activity levels include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of activity level or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of activity level. In some implementations, the biometric context summary further includes a summary of heart rate recovery of the patient.
In some implementations, the biometric context summary includes a summary of respiration of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's respiration over the predetermined use period. In some implementations, the information about the biometric context summary includes types of respiration. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was experiencing each type of respiration or a proportion of the patient-provided symptom inputs occurring while the patient was experiencing each type of activity level. In some implementations, the types of respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration.
In some implementations, the biometric context summary includes a summary of a sleep status of the patient. In some implementations, the information about the biometric context summary includes changes in the patient's sleep status over the predetermined use period. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes at least one of a proportion of the arrhythmia events occurring while the patient was asleep or a proportion of the patient-provided symptom inputs occurring while the patient was asleep. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The processor is further configured to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the processor is further configured to receive patient-reported information relating to a health status of the patient and further display on the user interface at least a subset of the patient-reported information. In some implementations, the processor is further configured to receive, via the user interface, a user interaction with the summary view of the arrhythmia events and/or patient-provided symptom inputs, and in response to the user interaction, display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia events and/or the patient provided symptom inputs. In some implementations, the processor is configured to display, on the user interface, the summary view of the arrhythmia events and/or the patient-provided symptom inputs on a first screen, and display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia events and/or the patient-provided symptom inputs on a second screen.
In some implementations, the predetermined relationship includes presenting, on a first axis, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and, on a second axis, the information about the biometric context summary. In some implementations, the predetermined relationship includes presenting one or more human-readable phrases including information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary. In some implementations, the processor is further configured to, for each of the arrhythmia events, determine a type of arrhythmia event to which the arrhythmia event belongs. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a plurality of types of arrhythmia events. The plurality of types of arrhythmia events includes each type of arrhythmia event that occurred in the patient over the predetermined use period. In some implementations, the information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a proportion of each type of arrhythmia event that occurred in the patient over the predetermined use period. In some implementations, the processor is further configured to provide the summary view of the arrhythmia events by presenting a graphical timeline including the predetermined use period. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs includes a timing of each patient-provided symptom input on the graphical timeline including the predetermined use period. In some implementations, the predetermined use period includes at least one of: 24 hours, 48 hours, 72 hours, a week, two weeks, or a month. In some implementations, the predetermined use period is user-specified via the user interface.
In some implementations, the cardiac monitoring device is configured to receive, over the predetermined use period, patient-provided symptom inputs indicating that the patient is experiencing a suspected cardiac-related symptom. In some implementations, the cardiac monitoring device further includes a portable gateway. The cardiac monitoring device is configured to transmit to the remote server via the portable gateway. In some implementations, the portable gateway is configured to receive the patient-provided symptom inputs. In some implementations, the portable gateway includes a visual display and a gateway processor in communication with the visual display. The gateway processor is configured to display, on the visual display, a symptom screen including a list of potential cardiac-related symptoms to the patient, and receive the patient-provided symptom inputs as selections, via the symptom screen, of one or more of the potential cardiac-related symptoms. In some implementations, the portable gateway includes the motion sensor. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom inputs. In some implementations, the cardiac sensor is configured to receive the patient-provided symptom inputs via tapping of the cardiac sensor by the patient.
In some implementations, the cardiac sensor includes a patch. The plurality of ECG electrodes are disposed on the patient. The cardiac sensor also includes a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes. The sensor unit includes the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in communication via a plurality of cables to the plurality of ECG electrodes. The sensor unit includes the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor includes a 3D accelerometer.
In some implementations, each arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, each patient-provided symptom input is associated with a suspected cardiac-related symptom. Each suspected cardiac-related symptom includes at least one of: light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, or a shortness of breath. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a method for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The method includes providing a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes transmitting the ECG signals and motion signals from the cardiac sensor to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the ECG signals and motion signals in the database, causing the processor to identify an arrhythmia event based on the received ECG signals, causing the processor to determine, based on the motion signals, contextual biometric information of the patient for the arrhythmia event, and causing the processor to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient.
Implementations of the method for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the following features. In some implementations, causing the processor to determine the arrhythmia event based on the received ECG signals comprises causing the processor to determine, an onset of the arrhythmia event based on the received ECG signals. In some implementations, the method further includes causing the processor to determine an arrhythmia contextual time period around the onset of the arrhythmia event. In some implementations, causing the processor to determine the contextual biometric information of the patient includes causing the processor to determine, based on the motion signals, the contextual biometric information of the patient for the arrhythmia event during the arrhythmia contextual time period. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation.
In some implementations, the method further includes causing the processor to determine an offset of the arrhythmia event based on the received ECG signals. The method also includes causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient by further displaying on the user interface an arrhythmia offset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator is overlaid on the contextual biometric information. In some implementations, the arrhythmia contextual time period includes at least one of: a two hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30 minute time period during which the offset of the arrhythmia event occurred, a 15 minute time period during which the offset of the arrhythmia event occurred, or a 10 minute time period during which the offset of the arrhythmia event occurred.
In some implementations, the contextual biometric information includes a posture of the patient. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric of the patient includes causing the processor to display changes in the patient's posture. In some implementations, the changes in the patient's posture include changes in a degree of the patient's posture. In some implementations, the changes in the patient's posture include changes in a type of the patient's posture. In some implementations, the types of the patient's posture include at least two of: supine, reclined, upright, standing, sitting, resting, lying on a right side, or lying on a left side.
In some implementations, the contextual biometric information includes an activity level of the patient. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display changes in the patient's activity level. In some implementations, changes in the patient's activity level include changes in a type of the patient's activity level. In some implementations, the types of the patient's activity level include at least two of: active, non-active, walking, low activity, intermediate activity, or high activity. In some implementations, the contextual biometric information further includes heart rate recovery of the patient.
In some implementations, the contextual biometric information includes respiration of the patient. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display changes in the patient's respiration. In some implementations, changes in the patient's respiration include changes in a type of the patient's respiration. In some implementations, the types of the patient's respiration include at least two of: regular breathing, rapid breathing, shallow breathing, rapid shallow breathing, deep breathing, wheezing, sleep disordered breathing, or Cheyne-Stokes respiration. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display when the patient's respiration rate crosses a respiration rate threshold.
In some implementations, the contextual biometric information includes a sleep status of the patient. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display changes in the patient's sleep status. In some implementations, the contextual biometric information further includes a posture of the patient, an activity level of the patient, and respiration of the patient. The method further includes causing the processor to determine the patient's sleep status based on a combination of at least two of: the posture of the patient, the activity level of the patient, or the respiration of the patient.
In some implementations, the method further includes causing the processor to determine a biometric summary for the arrhythmia event and causing the processor to further display, on the user interface, the biometric summary for the arrhythmia event. In some implementations, causing the processor to determine the biometric summary for the arrhythmia event includes causing the processor to determine at least one of: an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a predetermined time period. In some implementations, the biometric parameter includes at least one of: a posture of the patient, an activity level of the patient, respiration of the patient, a sleep status of the patient, or heart rate recovery of the patient. In some implementations, the method further includes causing the processor to determine one or more human-readable phrases that describe the biometric summary for the arrhythmia event. Causing the processor to display the biometric summary for the arrhythmia event also includes causing the processor to display, on the user interface, the one or more human-readable phrases that describe the biometric summary.
In some implementations, the method further includes receiving, at the remote server, patient-reported information relating to a health status of the patient and causing the processor to further display, on the user interface, at least a subset of the patient-reported information. In some implementations, the method further includes receiving, via the user interface and at the remote server, a user interaction with the arrhythmia event overlaid on the contextual biometric information of the patient, and in response to the user interaction, causing the processor to display, on the user interface, a portion of the ECG signals corresponding to the arrhythmia event. In some implementations, causing the processor to display the arrhythmia event overlaid on the contextual biometric information of the patient includes causing the processor to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient on a first screen. Causing the processor to display the portion of the ECG signals corresponding to the arrhythmia event also includes causing the processor to display, on the user interface, the portion of the ECG signals corresponding to the arrhythmia event on a second screen.
In some implementations, the arrhythmia contextual time period is a default time period. In some implementations, the method further includes causing the processor to determine an arrhythmia type for the arrhythmia event and causing the processor to determine the arrhythmia contextual time period based on the arrhythmia type for the arrhythmia event. In some implementations, the method further includes causing the processor to determine a biometric status of the patient at the onset of the arrhythmia event and causing the processor to determine the arrhythmia contextual time period based on the biometric status of the patient at the onset of the arrhythmia event.
In some implementations, the arrhythmia contextual time period comprises at least one of: a two hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30 minute time period during which the onset of the arrhythmia event occurred, a 15 minute time period during which the onset of the arrhythmia event occurred, or a 10 minute time period during which the onset of the arrhythmia event occurred. In some implementations, the arrhythmia contextual time period is user-specified via the user interface.
In some implementations, the cardiac sensor further includes a patch, the plurality of ECG electrodes disposed on the patch and a sensor unit configured to be removably attached to the patch and in electrical communication with the plurality of ECG electrodes, the sensor unit comprising the motion sensor. In some implementations, the patch is an adhesive patch configured to be adhesively coupled to skin of the patient. In some implementations, the adhesive patch is disposable. In some implementations, the adhesive patch is configured to be continuously adhesively coupled to the skin of the patient for at least one of: 3-5 days, 5-7 days, 7-10 days, 10-14 days, or 14-30 days.
In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The cardiac sensor further includes a sensor unit in electrical communication via a plurality of cables to the plurality of ECG electrodes, the sensor unit comprising the motion sensor. In some implementations, the plurality of ECG electrodes are configured to be disposed at predetermined anatomical locations on the patient's body. The motion sensor includes one or more accelerometers coupled to one or more of the plurality of ECG electrodes. In some implementations, the motion sensor comprises a 3D accelerometer. In some implementations, the method further includes providing a portable gateway configured to transmit the sensed ECG signals and acquired motion signals to the remote server. In some implementations, the portable gateway includes the motion sensor.
In some implementations, the arrhythmia event includes at least one of: ventricular tachycardia, bigeminy, a supraventricular ectopic beat, supraventricular tachycardia, atrial fibrillation, ventricular fibrillation, a pause, a 2nd AV block, a 3rd AV block, bradycardia, or non-ventricular tachycardia. In some implementations, the user interface includes a desktop computer, a laptop computer, or a portable personal digital assistant.
In one or more examples, a method for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes identifying, at the cardiac monitoring device, an arrhythmia event based on the ECG signals, determining, at the cardiac monitoring device, biometric information for the patient based on the motion signals, and transmitting the identified arrhythmia event, ECG signals corresponding to the arrhythmia event, and the biometric information for the patient from the cardiac monitoring device to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the identified arrhythmia event, the ECG signals corresponding to the arrhythmia event, and the biometric information for the patient in the database, causing the processor to determine, from the biometric information for the patient, contextual biometric information of the patient for the arrhythmia event, and causing the processor to display, on the user interface, the arrhythmia event overlaid on the contextual biometric information of the patient. Implementations of the method for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the above-described features.
In one or more examples, a method for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The method includes providing a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes transmitting the ECG signals and motion signals from the cardiac sensor to a remote server in communication with a user interface. The remote server includes a database implemented in non-transitory media and a processor in communication with the database. The method additionally includes storing the ECG signals and the motion signals in the database, causing the processor to determine an onset of an arrhythmia event based on the received ECG signals, causing the processor to determine an arrhythmia contextual time period around the onset of the arrhythmia event, and causing the processor to determine, based on the motion signals, contextual biometric information of the patient during the arrhythmia contextual time period. In addition, the method includes causing the processor to display on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation. Implementations of the method for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the above-described features.
In one or more examples, a method for displaying contextual biometric information for arrhythmia events occurring in a patient is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes determining, at the cardiac monitoring device, an onset of an arrhythmia event based on the ECG signals, determining, at the cardiac monitoring device, biometric information for the patient based on the motion signals, and transmitting the onset of the arrhythmia event, ECG signals corresponding to the arrhythmia event, and the biometric information for the patient from the cardiac monitoring device to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the onset of the arrhythmia event, the ECG signals corresponding to the arrhythmia event, and the biometric information for the patient in the database, causing the processor to determine an arrhythmia contextual time period around the onset of the arrhythmia event, and causing the processor to determine, from the biometric information for the patient, contextual biometric information of the patient during the arrhythmia contextual time period. In addition, the method includes causing the processor to display on the user interface a graphical timeline comprising the arrhythmia contextual time period around the onset of the arrhythmia event, an arrhythmia onset graphical indicator corresponding to the onset of the arrhythmia event, and a biometric graphical representation of the contextual biometric information of the patient during the arrhythmia contextual time period. The arrhythmia onset graphical indicator is overlaid on the biometric graphical representation. Implementations of the method for displaying contextual biometric information for arrhythmia events occurring in a patient can include one or more of the above-described features.
In one or more examples, a method for displaying contextual biometric information for patient-provided symptom inputs is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to a patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient, wherein the motion signals comprise motion information and/or posture information of the patient. The method also includes receiving, at the cardiac monitoring device, a patient-provided symptom input indicating that the patient is experiencing a suspected cardiac-related symptom, and transmitting the sensed ECG signals, the acquired motion signals, and the patient-provided symptom input to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the ECG signals, the motion signals, and the patient-provided symptom input in the database, causing the processor to determine a symptom contextual time period around a time of the patient-provided symptom input, and causing the processor to determine, based on the motion signals, contextual biometric information of the patient during the symptom contextual time period. In addition, the method includes causing the processor to display on the user interface a graphical timeline comprising the symptom contextual time period around the time of the patient-provided symptom input, a symptom graphical indicator corresponding to the patient-provided symptom input, and a biometric graphical representation of the contextual biometric information of the patient during the symptom contextual time period. The symptom graphical indicator is overlaid on the biometric graphical representation. Implementations of the method for displaying contextual biometric information for patient-provided symptom input can include one or more of the above-described features.
In one or more examples, a method for displaying contextual biometric information for patient-provided symptom inputs is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to a patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes determining, at the cardiac monitoring device, biometric information for the patient based on the motion signals, receiving, at the cardiac monitoring device, a patient-provided symptom input indicating that the patient is experiencing a suspected cardiac-related symptom, and transmitting the biometric information, the patient-provided symptom input, and ECG signals corresponding to the patient-provided symptom input from the cardiac monitoring device to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the biometric information, the patient-provided symptom input, and the ECG signals corresponding to the patient-provided symptom input in the database, causing the processor to determine a symptom contextual time period around a time of the patient-provided symptom input, and causing the processor to determine, from the biometric information for the patient, contextual biometric information of the patient during the symptom contextual time period. In addition, the method includes causing the processor to display on the user interface a graphical timeline comprising the symptom contextual time period around the time of the patient-provided symptom input, a symptom graphical indicator corresponding to the patient-provided symptom input, and a biometric graphical representation of the contextual biometric information of the patient during the symptom contextual time period. The symptom graphical indicator is overlaid on the biometric graphical representation. Implementations of the method for displaying contextual biometric information for patient-provided symptom input can include one or more of the above-described features.
In one or more examples, a method for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs over predetermined use periods is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient. The motion signals include motion information and/or posture information of the patient. The method also includes transmitting the sensed ECG signals and the acquired motion signals from the cardiac monitoring device to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the ECG signals, the motion signals, and patient-provided symptom inputs in the database, causing the processor to determine, based on the received ECG signals, arrhythmia events that occurred in the patient over a predetermined use period, and causing the processor to determine, based on the motion signals, a biometric context summary for the predetermined use period. In addition, the method includes causing the processor to provide, via the user interface, a summary view of the arrhythmia events and/or the patient-provided symptom inputs over the predetermined use period by presenting information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and information about the biometric context summary. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary is presented within a predetermined relationship in the summary view. Implementations of for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs over predetermined use periods can include one or more of the above-described features.
In one or more examples, a method for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs over predetermined use periods is provided. The method includes providing a cardiac monitoring device comprising a cardiac sensor configured to be coupled to the patient. The cardiac sensor includes a plurality of ECG electrodes configured to sense ECG signals of the patient and a motion sensor configured to acquire motion signals associated with the patient, wherein the motion signals comprise motion information and/or posture information of the patient. The method also includes determining, at the cardiac monitoring device, based on the ECG signals, arrhythmia events that occurred in the patient over a predetermined use period, determining, at the cardiac monitoring device, biometric information for the patient based on the motion signals, and transmitting the determined arrhythmia events, ECG signals corresponding to the arrhythmia events, ECG signals corresponding to patient-provided symptom inputs, and the biometric information for the patient from the cardiac monitoring device to a remote server in communication with a user interface. The remote server includes a database implemented in a non-transitory media and a processor in communication with the database. The method additionally includes storing the determined arrhythmia events, the ECG signals corresponding to the arrhythmia events, the patient-provided symptom inputs, the ECG signals corresponding to the patient-provided symptom inputs, and the biometric information for the patient in the database, and causing the processor to determine, from the biometric information for the patient, a biometric context summary for the predetermined use period. In addition, the method includes causing the processor to provide, via the user interface, a summary view of the arrhythmia events and/or the patient-provided symptom inputs over the predetermined use period by presenting information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and information about the biometric context summary. The information about each of the arrhythmia events and/or each of the patient-provided symptom inputs and the information about the biometric context summary is presented within a predetermined relationship in the summary view. Implementations of for displaying graphical summary views of arrhythmia events occurring in a patient and/or patient-provided symptom inputs over predetermined use periods can include one or more of the above-described features.
Various aspects of at least one example are discussed below with reference to the accompanying figures, which are not intended to be drawn to scale. The figures are included to provide an illustration and a further understanding of the various aspects and examples, and are incorporated in and constitute a part of this specification, but are not intended to limit the scope of the disclosure. The drawings, together with the remainder of the specification, serve to explain principles and operations of the described and claimed aspects and examples. In the figures, each identical or nearly identical component that is illustrated in various figures is represented by a like numeral. For purposes of clarity, not every component may be labeled in every figure.
In today's busy cardiology practice, the assessment and management of patients involves an integrated approach of reviewing several parameters such as clinical observations/assessment, ECG changes, thoracic fluid changes, weight loss/gain, urine output, radiographic signs, among others. Medical professionals assess their patients' clinical status by monitoring multiple vital signs such as ECG-based heart rate, respiration rate, temperature, blood pressure, and oxygen saturation. This approach is superior to one where only individual vital signs (such as only heart rate changes) are obtained and assessed. For example, normal respiration rate ranges from 10 to 20 breaths per minute and, in accordance with current standards of care, changes are part of the patient clinical assessment. Consequently, the disclosed improved cardiac monitoring systems, devices and techniques for health care professionals to remotely monitor a plurality of these parameters will play an important role.
This disclosure relates to an improved cardiac monitoring system for remotely monitoring the cardiac health of patients with known or suspected heart conditions, such as arrhythmias. Such patients may be prescribed a cardiac sensor configured to be worn continuously for an extended period of time and transmit (e.g., via internal communications circuitry or a separate portable gateway), information about the patient's suspected cardiac symptoms, cardiac and physical activity to a remote server. For example, such information can be ECG signals and motion signals (including both motion and posture information) associated with the patient. At the remote server, this information can be processed to determine arrhythmias and biometric information. The biometric information provides context for the determined arrhythmia, and can include activity and posture information such as whether the patient is standing, sitting, walking, climbing stairs, running, or lying down; respiration information; pulse oximetry information; blood pressure information; body temperature information; and sleep data. In some examples, the cardiac sensor and/or portable gateway may itself process such ECG and motion signals and determine the arrhythmias and the biometric information, and then transmit such determined arrhythmias and biometric information to the remote server.
In some implementations, the biometric information may also include environmental conditions of the patient, cardiac sensor, and/or portable gateway. For example, the biometric information may include the temperature outside the cardiac sensor and/or portable gateway, the humidity level, pressure, elevation, windchill, air quality, auditory noise level, and so on. These environmental conditions may be measured by the cardiac sensor and/or portable gateway and transmitted to the remote server, and/or these environmental conditions may be determined by the remote server. For example, the remote server may receive location data from the cardiac sensor and/or portable gateway determined by a global positioning system (GPS) sensor of the cardiac sensor and/or portable gateway. Using the location data of the cardiac sensor, the remoter server may look up the environmental conditions for the patient.
In this disclosure, techniques and systems are described for presenting, to caregivers and technicians, information about the arrhythmias and biometric information such that the arrhythmias are presented within the context of the biometric information. The improved cardiac monitoring system as described herein provides several advantages over prior art systems. For example, the additional contextual biometric information enhances the diagnostic yield or diagnostic quality of the reporting infrastructure within the cardiac care continuum. In this regard, the improved cardiac monitoring system enhances reporting of data from prescribed cardiac sensors to provide medically relevant information needed to establish a diagnosis for the patient without a need for additional diagnostic tests, clinical visits, or extending a time period of cardiac monitoring. Example use scenarios are provided below that further demonstrate the value afforded by the improved cardiac monitoring systems described herein. Accordingly, in implementations herein, the cardiac monitoring system comprises a cardiac sensor that includes ECG and biometric data monitoring. The improved system overcomes limitations in existing technologies where heart rate and rhythm data have limited clinical utility by an inability to place cardiac events into the context of what the patient may be doing during such events. Traditionally, patients are asked to maintain a diary of their activities to allow for later analysis of these events. The improved systems and techniques herein provide missing information so the interpreting physician will know if the patient is sleeping, exercising, hyperventilating, etc. at the time of an arrhythmic event or patient reported symptom. By placing the circumstances in the correct context, the appropriate clinical action can be taken. With situations where there is not a significant arrhythmia, the improved system can still provide valuable wellness information with biometric information, such as activity, respiration rate, and body position.
For example, in one implementation, the remote server may prepare reports, or graphically present via a user interface, including detailed information based on an arrhythmia event along with an associated biometric context for the arrhythmia event. The arrhythmia information and the contextual biometric information is graphically presented in a predetermined relationship illustrating visually the context for the detected arrhythmias. For example, the report illustrates the arrhythmia event overlaid on the contextual biometric information that corresponds to the arrhythmia event.
For example, overlaying the arrhythmia event on the contextual biometric information includes displaying the arrhythmia event information on a foreground of a display area, while the contextual biometric information is graphically presented on a background of the display area.
In an example, overlaying the arrhythmia event on the contextual biometric information includes graphical animation to first present the contextual biometric information in a display area and then, upon user prompt or after a short configurable delay, displaying the arrhythmia event information on top of the presented biometric information on the display area. In an example, overlaying the arrhythmia event on the contextual biometric information includes graphical animation to first present the arrhythmia event information on the display area and then presenting contextual biometric information in a display area and then, upon user prompt or after a short configurable delay, displaying contextual biometric information in the display area. In an example, overlaying the arrhythmia event on the contextual biometric information includes visually presenting graphical animation to first present the arrhythmia event information on the display area and then presenting contextual biometric information in a display area and then, upon user prompt or after a short configurable delay, displaying contextual biometric information in the display area.
The remote server may be in communication with a user interface, such as a computer monitor, laptop, tablet, or a portable handheld device associated with a technician or a physician. As such, the remote server may cause the report to be displayed on the user interface such that it is viewable by the technician or caregiver in a way that increases diagnostic yield or diagnostic quality.
In another implementation, the cardiac sensor and/or portable gateway may be further configured to receive an input from a patient indicating that the patient is experiencing a symptom suspected of being related to a cardiac issue in the patient. For example, a suspected cardiac-related symptom may include light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, and/or shortness of breath. The cardiac sensor may transmit this patient-provided input to the remote server, which may prepare reports based on the patient-provided symptom input and a biometric context for the symptom. The patient-provided symptom input and the contextual biometric information is graphically presented in a predetermined relationship illustrating visually the context for the symptom. For example, the report illustrates the patient-provided symptom input overlaid on the contextual biometric information that corresponds to the symptom input. The overlying of the symptom input on the contextual biometric information includes similar systems and techniques described for the arrhythmia event report above. Similar to the arrhythmia event report discussed above, the remote server may cause the report to be displayed on the user interface such that it is viewable by a technician or caregiver.
In another implementation, the remote server may prepare reports for a predetermined use period of the cardiac sensor. The predetermined use period may be, for example, 24 hours, 48 hours, 72 hours, a week, two weeks, a month, 2 months, 3 months, 5 months, or 6 months. Alternatively, the use period may be specified by a user under authorization from a licensed prescriber. The remote server may identify arrhythmias that occurred in the patient over the predetermined use period. The remote server may also determine a biometric context summary for the predetermined use period, where the biometric context summary includes a summary of one or more biometric parameters of the patient over the predetermined use period. For instance, the biometric context summary may include how many hours per day of the use period that the patient was asleep, how many hours per day of the use period that the patient was active, what percentage of arrhythmias occurred while the patient was asleep over the use period, and so on. Additionally or alternatively, the identification of the arrhythmias over the use period and the biometric context summary for the use period may be determined by the cardiac sensor and/or portable gateway device and transmitted to the remote server. Once the determination of the arrhythmia events and biometric context summary for the predetermined use period is made, the remote server may prepare a report for the use period. If the report is an interim report, a user under authorization from a licensed prescriber may specify the length of the report period as the predetermined use period described above. For instance, the user may seek interim reports once a day, once every two days, once every three days, once a week, once every two weeks, once every month, or any other configurable interim duration. In some examples, the use-period report can cover a custom period of time. For example, the user under authorization from a licensed prescriber can input a custom period range as the predetermined use period. The use-period report may include a graphical summary of the arrhythmia events over the predetermined use period. The arrhythmia information and the biometric context summary information may be graphically presented in a predetermined relationship illustrating visually the context for the detected arrhythmias over the predetermined use period. As an illustration, the predetermined relationship includes presenting via a first axis of the graphical summary, information about each of the arrhythmia events and, via a second axis of the graphical summary, information about the biometric context summary. As with the arrhythmia and symptom reports discussed above, the remote server may be in communication with a user interface and cause the use-period report to be displayed on the user interface of a computer monitor, laptop, tablet, or a portable handheld device such that it is viewable, for example, by a technician or caregiver.
Described below is a cardiac monitoring system for monitoring the status of patients with known or suspected heart conditions, such as known or suspected cardiac arrhythmias. The cardiac monitoring system includes a cardiac monitoring device, where the cardiac monitoring device includes a cardiac sensor that is continuously worn by the patient for an extended period of time (e.g., depending on how much data a caregiver needs to make a diagnosis). The cardiac sensor includes ECG electrodes that senses ECG signals from the patient, as well as one or more motion sensors that acquire motion signals (including posture information) associated with the patient. As an illustration, in some cases, the cardiac sensor may be a patch-based device configured to be adhesively coupled to the patient for the extended period of time. In some cases, the cardiac sensor may include a sensor unit connected via cables to multiple ECG electrodes, where each of the ECG electrodes is individually adhered to the patient. The cardiac sensor may be in communication with a portable gateway device configured for data transmission. Thus, through the portable gateway device, the cardiac sensor may transmit data for the patient to a remote server. Alternatively, in some cases, the cardiac monitoring device may not include a portable gateway device, and the cardiac sensor may include communications circuitry be configured to transmit data from the patient to the remote server. For example, the communications circuitry may 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 technologies for high-speed wireless communication. In some implementations, the communications circuitry in the cardiac sensor and/or the portable gateway may communicate with the remote server over a Wi-Fi™ communications link based on the IEEE 802.11 standard. In some implementations, the cardiac sensor and/or portable gateway device may be part of an Internet of Things (IoT) and communicate with each other and/or the remote server 102 via IoT protocols (e.g., Constrained Application Protocol (CoAP), Message Queuing Telemetry Transport (MQTT), Wi-Fi, Zigbee, Bluetooth®, Extensible Messaging and Presence Protocol (XMPP), Data-Distribution Service (DDS), Advanced Messaging Queuing Protocol (AMQP), and/or Lightweight M2M (LwM2M)).
In some embodiments, the cardiac sensor transmits the sensed ECG signals and motion signals to a remote server via the portable gateway device. The remote server stores the ECG signals and the motion signals in a database (e.g., implemented in a non-transitory memory and in communication with a processor of the remote server). The remote server then uses the stored ECG signals to identify an arrhythmia event that occurred, or in some cases is occurring, in the patient. In some implementations, the cardiac sensor may locally store at least some of the data that is transmitted to the remote server, such as several days of data at a time. Locally storing the data may, for example, help prevent data losses when there is a connectivity issue between the cardiac monitoring device and the remote server. Additionally, the remote server uses the motion and/or other biometric signals to identify a biometric context for the arrhythmia event. For example, the biometric context may include the posture of the patient, the patient's respiratory rate, whether the patient was active, and/or whether the patient was asleep when the arrhythmia event occurred. Alternatively, in some embodiments, the identification of the arrhythmia event and/or the biometric context for the arrhythmia event may occur at the cardiac sensor and/or the portable gateway. In such embodiments, the portable gateway device may transmit information on the arrhythmia event and/or information on the biometric context for the arrhythmia event to the remote server instead of, or in addition to, the ECG and motion signals.
The remote server may prepare one or more reports based on the arrhythmia event and the biometric context for the arrhythmia event. In various embodiments, the report illustrates the arrhythmia event overlaid on the contextual biometric information that corresponds to the arrhythmia event. The remote server may be in communication with a user interface, such as an interface associated with a technician or a physician. As such, the remote server may cause the report to be displayed on the user interface such that it is viewable by the technician or physician. Additionally, in some implementations, the remote server may prepare the one or more reports based on interactive feedback with a technician. For example, a technician may provide time intervals to the remote server to include in a report or desired biometric information to include in the report, and the remote server may prepare or modify the report based on the technician's input. In some implementations, the remote server may prepare the one or more reports in concert with other report generation tools, such as programs used to take existing data sets and output the data into a particular format.
Alternatively, instead of or in addition to identifying that a patient has experienced an arrhythmia event, the cardiac monitoring system may receive an input from a patient indicating that the patient has experienced a symptom suspected to be related to a cardiac condition. For example, a suspected cardiac-related symptom may include light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, and/or shortness of breath. Accordingly, in such cases, a cardiac monitoring device (e.g., including a cardiac sensor and portable gateway) is configured such that the patient can provide the input to the cardiac monitoring system (e.g., via a cardiac sensor and/or a portable gateway of the cardiac monitoring device). The portable gateway (or, in some implementations, the cardiac sensor) transmits the patient-provided symptom input to the remote server, along with ECG signals and motion signals for the patient. The remote server then identifies a biometric context for the symptom input. Alternatively, in some embodiments, the cardiac sensor and/or the portable gateway may identify the biometric context for the symptom input and transmit the biometric context to the remote server.
The remote server may then prepare one or more reports based on the patient-provided symptom input and the biometric context for the input. In various embodiments, similar to the reports on arrhythmia events discussed above, the report illustrates the patient-provided symptom input overlaid on the contextual biometric information corresponding to the patient-provided symptom input. The remote server may also be in communication with a user interface and cause the report to be displayed on the user interface such that it is viewable, for example, by a technician or physician.
In some embodiments, the cardiac monitoring system may additionally or alternatively prepare use-period reports for a patient wearing a cardiac sensor. A use period is predetermined for a patient wearing a cardiac sensor. This predetermined use period may be as described above. Alternatively, the use period may be a custom period specified by a user under authorization from a licensed prescriber. In some cases, the use period may span the entire period that the patient wears the cardiac sensor. In other cases, the use period may be a subset of the entire period that the patient wears the cardiac sensor. Similar to the embodiments discussed above, the cardiac sensor transmits ECG signals and motion signals for the patient to the remote server via the portable gateway device. The remote server stores the ECG signals and motion signals and then determines, based on the ECG signals, arrhythmia events that occurred in the patient over the predetermined use period for the cardiac sensor.
The remote server also determines, based on the motion signals, a biometric context summary for the predetermined use period. This biometric context summary may include a summary of one or more biometric parameters of the patient over the use period. For instance, the biometric context summary may include how many hours per day of the use period that the patient was asleep, how many hours per day of the use period that the patient was active, what percentage of arrhythmias occurred while the patient was asleep over the use period, what percentage of arrhythmias occurred while the patient was active over the use period, and so on. Alternatively, in some cases, the determination of the arrhythmia events over the predetermined use period and/or the determination of the biometric context summary for the predetermined use period may be performed by the cardiac sensor and/or the portable gateway device. In such embodiments, the portable gateway device may instead transmit information on the arrhythmia event and/or information on the biometric context for the arrhythmia event to the remote server.
Once the determination of the arrhythmia events and biometric context summary for the predetermined use period is made, the remote server may prepare a report for the use period. The use-period report may include a graphical summary of the arrhythmia events over the predetermined used period, where the use-period report includes information about each of the arrhythmia events, presented via a first axis of the graphical summary, and information about the biometric context summary, presented via a second axis of the graphical summary. As an illustration, the use-period report may include a graph that shows types of arrhythmias on one axis and a timeline of the predetermined use period on another axis. The graph may chart each day that an arrhythmia occurred in the patient and which type(s) of arrhythmias occurred on that day. The graph may also show biometric information for each day of the predetermined use period along the timeline, such as the number of hours the patient slept per day of the use period or the number of hours the patient was active per day of the use period. As with the arrhythmia and symptom reports discussed above, the remote server may be in communication with a user interface and cause the use-period report to be displayed on the user interface such that it is viewable, for example, by a technician or physician.
Example use case scenarios are presented below to demonstrate advantages/benefits of the improved cardiac monitoring system and techniques described herein.
In one example use case, a 76-year-old male patient wearing a cardiac monitoring device may experience a four-second pause due to sinus arrest at 4 pm, which the cardiac monitoring system detects. Yet, there is no corresponding entry in the patient's diary, meaning that the patient's caregiver does not have patient-reported biometric context information to rely on in interpreting the four-second pause. Appropriate clinical action could depend on whether the patient was awake or asleep at the time of these events. However, using the motion signals from the cardiac monitoring device, the cardiac monitoring system is able to determine the patient's activity level and body posture at the time of the pause event. Evaluation of the patient's activity level and body posture reveals that this episode, as well as previous pause episodes, occurred while the patient was asleep. This information may help the patient's caregiver determine the best treatment plan for the patient's pause episodes.
In another example use case, a 56-year-old female patient may complain to her caregiver that she is suffering from a shortness of breath with daily activities. Her caregiver may prescribe that she wear a cardiac monitoring device. Using motion signals from the cardiac monitoring device, the cardiac monitoring system may determine that the patient has a normal respiratory rate during the day and at night. However, the cardiac monitoring system may further determine that while the patient was engaged in significant activity, her sinus rate never increased above 85 beats per minute (“bpm”), suggesting a diagnosis of chronotropic incompetence.
In another example use case, a 62-year-old male patient may complain to her caregiver of heart palpitations and syncope. His caregiver may prescribe that he wear a cardiac monitoring device for 30 days. After the 30 days, the cardiac monitoring system may analyze the ECG signals and motion signals acquired by the cardiac monitoring device and determine that no significant arrhythmias occurred over the 30-day use period. The patient was able to exercise with no arrhythmias and able to sleep flat with a nighttime resting heart rate of 72 bpm. As such, the patient's caregiver may determine that the patient does not need a treatment plan at this time.
In another example use case, a patient may experience a syncopal episode or a fainting spell. The patient may report the fainting spell as a symptom input to the cardiac monitoring device. The remote server may prepare a contextual biometric report for the fainting spell, which the patient's caregiver reviews. This contextual biometric report may include, for example, the activity level and the posture of the patient when the fainting spell occurred. Based on the contextual biometric report, the patient's caregiver may correctly identify that the fainting spell was a syncope.
In another example use case, a recently adult patient (e.g., around 18-21 years of age) may report to their caregiver that they have been feeling heart palpitations. The caregiver may prescribe that the patient wear a cardiac monitoring device for 30 days to assure the patient that the palpitations are not part of an underlying cardiac condition. The remote server may prepare a use-period report for the 30 days, which includes biometric information as described herein, and the caregiver may use the report to verify to the patient that the patient does not have an underlying cardiac condition.
In another example use case, a technician may receive a preliminary report or data set from the remote server that includes a biometric context for a certain period of time around an arrhythmia. The technician may modify the period of time and submit the modified period of time to the remote server. For instance, the technician may expand the period of time to show a broader context for the arrhythmia, or may decrease the period of time to cut out less informative context. The remote server may then prepare an updated report that includes a biometric context for the modified period of time. The technician may also draft a summary for the arrhythmia, which the remote server further includes in the report.
In traditional cardiac monitoring regimes, cardiac monitors are used to monitor the heart conditions of various patients. A cardiac monitor being worn by a given patient may provide ECG signals to a remote server, which analyzes the ECG signals to identify that an arrhythmia has occurred or is occurring in the patient. The remote server may also prepare a report on the arrhythmia for a physician of the patient to review. This report may include information on the ECG of the patient and other heart information, such as an average heart rate of the patient, over the period of the arrhythmia. A cardiac monitor being worn by a given patient may also be able to provide an indication to the remote server that the patient has experienced a suspected cardiac-related symptom. Thus, the remote server may also prepare a report on the suspected cardiac-related symptom that similarly includes, for example, information on the ECG of the patient and other heart information from the time of the symptom. The remote server may further prepare a similarly configured use-period report at the end of a period of use for the device.
A physician may use these reports as part of treating the patient. For example, the physician may use these reports to diagnose a cardiac condition in the patient and determine a treatment plan for the cardiac condition. However, the physician's decisions regarding diagnosing or treating the patient may be affected by a biometric context in which the patient's arrhythmias and/or patient-reported symptom occurred, as well as by a context in which arrhythmias did not occur. As an illustration, a physician's treatment plan may be affected by whether the arrhythmias occurred while the patient was asleep as opposed to while the patient was awake or whether the arrhythmias occurred while the patient was active versus while the patient was inactive. A physician's treatment plan may also be affected by whether the patient experienced any arrhythmias while exercising. The biometric context for an arrhythmia and/or patient-reported symptom is generally not included in reports prepared from cardiac monitors. In some cases, a patient may keep a physical or virtual (e.g., stored on a remote server via an online portal or locally on non-transitory storage media) diary of their symptoms, including how and when their symptoms occurred. However, the patient may forget to record symptoms or may incompletely record symptoms, making the diary's reliability variable based on the patient. Physical diaries may also be lost, while both physical or virtual diaries may be of insufficient accuracy to be useful. For example, without a highly accurate patient diary, it may not be possible to know if a person's episodes of atrial fibrillation only occur during exercise, or whether a person's episodes of atrial fibrillation only occur during sleep, which could include daytime sleep. The ability to provide objective physiologic data could reduce or eliminate the reliance on diary information for rhythm and symptom interpretation.
As such, it would be beneficial for reports prepared by a cardiac monitoring system to include biometric context information for arrhythmias and patient-reported symptoms. Advantageously, a report including biometric context information for arrhythmias and patient-reported symptoms would help the patient's physician understand the context of the patient's arrhythmias and symptoms and therefore make a better diagnosis or treatment plan. Additionally, this information would be objectively recorded and analyzed by the cardiac monitoring system, and therefore would not rely on the reliability of the patient like the patient diary does. Such biometric context information provides clinicians with a global evaluation of arrhythmic or other cardiovascular risks in individual patients and insights into the patient's overall wellness and health status.
Additionally, depending on the reason for ambulatory arrhythmia monitoring and the duration of monitoring, in some scenarios, around 12-50% of patients may experience no arrhythmias or symptoms while undergoing arrhythmia monitoring. In such cases, longitudinal tracking of biometric parameters (e.g., tracking biometric parameters over time) is useful to clinicians. Such tracking may reveal information including discovery of a disordered sleep pattern in a patient complaining of fatigue or significant decreases in activity during periods of paroxysmal atrial fibrillation.
In some embodiments, such as the embodiment shown in
Alternatively or additionally, in some embodiments, the portable gateway 106 includes at least one sensor configured to sense motion signals of the patient, such as a 3D accelerometer. Further, another embodiment of the cardiac sensor 104 may include a sensor unit 110 connected via cables to electrodes 112 that are individually adhered to the patient, as shown in
Alternatively, or additionally, the sensor unit 110 may include another type of motion sensor, such as a gyroscope configured to detect patient posture and movement. Further, in some embodiments, the cardiac sensor 104 may include additional physiological sensors or functionalities. As an example, the cardiac sensor 104 includes a radiofrequency (RF) sensor comprising an RF antenna and RF transmitter and receiver such that the cardiac sensor 104 can take bio-impedance measurements of the patient's thorax. RF technology as described herein is available from ZOLL Medical Corporation (Chelmsford, Mass.), and makes use of a non-ionizing techniques by illuminating the body with low-power electromagnetic pulses at microwave range frequencies (approximately 0.5-30 GHz, more particularly approximately 0.5-5 GHz, more particularly approximately 0.5-2.5 GHz) and measuring the returned RF signals. The reflected and refracted RF signals enable the system to discern between different tissues based on their electromagnetic properties. Such RF technologies are biologically safe, having electromagnetic power much lower than those from a cellular phone. The RF sensor can be used to determine physiological information such as heart wall motion, respiration, thoracic fluid context (e.g., lung water), certain arrhythmias, heart valve abnormalities, arterial pulse information (e.g. pulse transit time (PTT), pulse arrival times (PAT)), blood pressure readings based on the arterial pulse information. Additionally or alternatively, the cardiac sensor 104 includes a temperature sensing device configured to sense a body temperature of the patient. For example, the temperature sensing device can include an infrared device for determining the body temperature. Additionally or alternatively, the cardiac sensor 104 includes a pulse oximeter configured to sense oxygen saturation information for the patient. Additionally or alternatively, the cardiac sensor 104 includes a respiration accelerometer that is separate from a motion sensor used to measure, for instance, the patient's posture and activity level. To illustrate, the respiratory sensor may be based on the operation of a tri-axis microelectromechanical system (MEMS) accelerometer within the cardiac sensor 104 when mounted on the patient's torso.
Further, the cardiac sensor 104 is configured for long-term and/or extended use or wear by, or attachment or connection to, a patient. For example, devices as described herein may be capable of being continuously used or continuously worn by, or attached or connected to a patient, without substantial interruption (e.g., up to 24 hours or beyond, such as for weeks, months, or even years). In some implementations, such devices may be removed for a period of time before use, wear, attachment, or connection to the patient is resumed. As an illustration, devices may be removed to change batteries, carry out technical service, update the device software or firmware, and/or to take a shower or engage in other activities, without departing from the scope of the examples described herein. Such substantially or nearly continuous use or wear as described herein may nonetheless be considered continuous use or wear.
In some embodiments, the cardiac sensor 104 is configured to monitor, record, and transmit the signals to the portable gateway 106 continuously. In particular, the cardiac sensor 104 may not interrupt monitoring and/or recording additional data while transmitting already acquired data to the portable gateway 106. Put another way, in some embodiments, both the monitoring/recording and the transmission processes occur at the same time or at least nearly at the same time.
As another example, if the cardiac sensor 104 does suspend monitoring and/or recording additional data while it is transmitting already acquired data to the portable gateway 106, the cardiac sensor 104 may then resume monitoring and/or recording additional data prior to all the already acquired data being transmitted to the portable gateway 106. As an illustration, the interruption period for monitoring and/or recording may be less in comparison to the time it takes to transmit the already acquired data (e.g., between about 0% to about 80%, about 0% to about 60%, about 0% to about 40%, about 0% to about 20%, about 0% to about 10%, about 0% to about 5%, including values and subranges therebetween). This moderate interruption period facilitates the near-continuous monitoring and/or recording of additional data during transmission of already acquired physiological data. For example, in one scenario, when a measurement time is around two minutes, any period of suspension or interruption in the monitoring and/or recording of subsequent measurement data may range from a few milliseconds to about a minute. Example reasons for such suspension or interruption of data may include allowing for the completion of certain data integrity and/or other online test of previously acquired data. If the previous measurement data has problems, the cardiac sensor 104 can notify the patient and/or remote technician of the problems so that appropriate adjustments can be made.
In some embodiments, the cardiac sensor 104 may be configured to monitor, record, and transmit some data in a continuous or near-continuous manner as discussed above, while monitoring, recording, and transmitting some other data in a non-continuous manner (e.g., periodically, non-periodically, etc.). For example, the cardiac sensor 104 may be configured to record and transmit ECG data continuously or nearly continuously while biometric-based measurements and/or transmissions may be periodic. As an illustration, ECG data may be transmitted to the portable gateway 106 (and subsequently the remote server 102) continuously or near-continuously as additional ECG data is being recorded, while biometric measurements may be transmitted once the measuring process is completed. Monitoring and/or recording of signals by the cardiac sensor 104 may be periodic and, in some embodiments, may be accomplished as scheduled (e.g., periodically) without delay or latency during the transmission of already acquired data to the portable gateway 106. For example, the cardiac sensor 104 may sense signals or acquire signals from the patient in a periodic manner and transmit the data to the portable gateway 106 in a continuous manner as described above.
As discussed above, the portable gateway 106 is configured to receive the signals sensed or acquired by the cardiac sensor 104 and transmit the signals to the remote server 102. Accordingly, the portable gateway 106 may be in wired and/or wireless communication with the cardiac sensor 104 and the remote server 102. As an illustration, the portable gateway 106 may communicate with the cardiac sensor 104 via Bluetooth®, via Ethernet, via Wi-Fi, via RF, via near-field communication (NFC), and the like. The portable gateway 106 may further communicate with the remote server 102 via cellular networks, via Bluetooth®-to-TCP/IP access point communication, via Ethernet, via Wi-Fi, and the like.
In some embodiments, the portable gateway 106 may transmit the signals sensed or acquired by the cardiac sensor 104 continuously to the remote server 102. Thus, for example, the portable gateway 106 may transmit the signals from the cardiac sensor 104 to the remote server 102 with little or no delay or latency. To this end, in the context of data transmission between the cardiac monitoring device 100, including the cardiac sensor 104 and the portable gateway 106, and the remote server 102, continuously includes continuous (e.g., without interruption) or near continuous (e.g., within one minute after completion of a measurement and/or an occurrence of an event on the cardiac sensor 104). Continuity may also be achieved by repetitive successive bursts of transmission (e.g., high-speed transmission). Similarly, immediate includes occurring or done immediately or nearly immediately (e.g., within one minute after the completion of a measurement and/or an occurrence of an event on the cardiac sensor 104).
Further in the context of signal acquisition and transmission by the cardiac monitoring device 100, continuously also includes uninterrupted collection of sensor data, such as ECG data and/or motion data, with clinical continuity. In this case, short interruptions in data acquisition of up to one second several times an hour or longer interruptions of a few minutes several times a day may be tolerated and still seen as continuous. As to latency as a result of such a continuous scheme as described herein, this relates to the overall budget of response time that can amount to between about five to about fifteen minutes overall response time (e.g., time from when an event onset is detected to when a notification regarding the event is issued). As such, transmission/acquisition latency would therefore be in the order of minutes.
In some embodiments, the bandwidth of the link between the cardiac sensor 104 and the portable gateway 106 may be larger, and in some instances, significantly larger, than the bandwidth of the acquired data to be transmitted via the link (e.g., burst transmissions). Such embodiments may ameliorate issues that may arise during link interruptions, periods of reduce/absent reception, etc. In some embodiments, when transmission is resumed after interruption, the resumption may be in the form of last-in-first-out (LIFO). Additionally, in some embodiments, the portable gateway 106 may be configured to operate in a store and forward mode where the data received from the cardiac sensor 104 is first stored in an onboard memory of the portable gateway 106 and then forwarded to the remote server 102. In some embodiments, the portable gateway 106 may function as a pipeline and pass through data from the cardiac sensor 104 immediately to the remote server 102. Further, in some embodiments, the data from the cardiac sensor 104 may be compressed using data compression techniques to reduce memory requirements as well as transmission times and power consumption.
Alternatively, in some embodiments, the cardiac sensor 104 may be configured to transmit the sensed or acquired signals to the remote server 102 instead of, or in addition to, transmitting the signals to the portable gateway 106. Accordingly, the cardiac sensor 104 may be in wired or wireless communication with the remote server 102. As an illustration, the cardiac sensor 104 may communicate with the remote server 102 via cellular networks, via Ethernet, via Wi-Fi channels, and the like. Further, in some embodiments, the cardiac monitoring device 100 may not include the portable gateway 106. In such embodiments, the cardiac sensor 104 may perform the functions of the portable gateway 106 described above.
The charger 107 includes charging cradles configured to hold and recharge the sensor unit 110 and the portable gateway 106. Alternatively, in some embodiments, the cardiac monitoring device 100 may not include the portable gateway, and accordingly, the charger 107 may be configured to hold the sensor unit 110 alone. Embodiments of the cardiac monitoring device 100 are described in further detail below with reference to
The remote server 102 is configured to receive and process the signals transmitted by the cardiac monitoring device 100. Accordingly, the remote server 102 may include a computing device, or a network of computing devices, including at least one database (e.g., implemented in a non-transitory memory) and at least one processor configured to execute instructions (e.g., stored in the database, with the at least one processor being in communication with the database) to receive and process the signals transmitted by the cardiac monitoring device 100. In various embodiments, the remote server 102 identifies an arrhythmia that has occurred in the patient from the ECG signals transmitted by the cardiac monitoring device 100, as described in further detail below (e.g., with reference to
Alternatively, in some embodiments, the identification of arrhythmias from the ECG signal and other ECG analysis may be performed by the cardiac monitoring device 100. As an example, the cardiac sensor 104 may transmit ECG signals to the portable gateway 106, which detects an arrhythmia from the ECG signals. The portable gateway 106 may then transmit an indication that an arrhythmia has occurred to the remote server 102, along with the relevant ECG signals. In another example, the portable gateway 106 may detect an arrhythmia from the ECG signals and transmit the indication that an arrhythmia has occurred and the complete ECG signals to the remote server 102. In another example, the cardiac sensor 104 may be configured to detect an arrhythmia from the ECG signals sensed by the cardiac sensor 104. The cardiac sensor 104 may transmit the indication that the arrhythmia has occurred, along with the relevant ECG signals and/or the complete ECG signals, to the portable gateway 106. The portable gateway 106 then passes the indication that the arrhythmia has occurred and the relevant and/or complete ECG signals to the remote server 102. As noted herein, arrhythmia detection and/or determination processes can be implemented on one or more of the cardiac sensor, portable gateway, and/or the remote server.
In various embodiments, the remote server 102 also processes the motion signals received from the cardiac monitoring device 100 to determine biometric parameters for the patient. For instance, an accelerometer of the cardiac sensor 104 may measure patient posture (e.g., 45°±20°) and detect movement indicative of respiration rate and activity level. Accordingly, the remote server 102 may process the accelerometer signals to identify patient posture, respiration rate, and activity level over periods of time. Other biometric information that may be determined for the patient may include, for example, sleep status, heart rate recovery, blood pressure, body temperature, and so on. In some implementations, biometric information may additionally or alternatively include environmental conditions for the patient and/or cardiac monitoring device 100, such as the temperature, humidity level, pressure, elevation, windchill, air quality, auditory noise level, and so on outside the cardiac monitoring device 100. As such, in some implementations, the cardiac monitoring device 100 may additionally or alternatively include other biometric sensors (e.g., non-motion biometric sensors) that transmit biometric signals to the remote server 102 for processing. The process of determining the biometric information for a patient is described in further detail below (e.g., with reference to
In some embodiments, the remote server 102 may also process other biometric signals transmitted by the cardiac monitoring device 100, such as RF signals used to determine the patient's thoracic impedance levels. These thoracic impedance levels may be further used to identify an amount of fluid in the patient's thorax. Additionally, the remote server 102 may perform secondary processing of the patient's biometrics determined from the accelerometer or other signals transmitted by the cardiac monitoring device 100 to determine further biometrics for the patient. As an example, in some embodiments, the remote server 102 may determine the patient's sleep status (e.g., whether the patient is awake or asleep) based on a combination of the patient's posture, activity level, and respiration rate. For instance, the remote server 102 may determine that the patient is asleep at any given minute where activity (e.g., as determined by accelerometer counts) is detected for less than 12 seconds and the patient's average posture is less than or equal to 35 degrees for that minute.
Alternatively, in some embodiments, the processing of the signals measuring biometric parameters of the patient that are acquired by the cardiac monitoring device 100 may occur at the cardiac monitoring device 100. As an example, the cardiac sensor 104 may transmit accelerometer signals to the portable gateway 106, which determines patient posture, activity level, respiration rate, and/or sleep status over time from the accelerometer signals. The portable gateway 106 may then transmit the patient posture, activity level, respiration rate, and/or sleep status over time to the remote server 102. In another example, the cardiac sensor 104 may be configured to determine the patient posture, activity level, respiration rate, and/or sleep status over time from the accelerometer signals acquired by the cardiac sensor 104. The cardiac sensor 104 may then transmit the patient posture, activity level, respiration rate, and/or sleep status over time to the portable gateway 106, which then passes these biometrics to the remote server 102.
As shown in
The technician interfaces 114 are configured to electronically communicate with the remote server 102 for the purpose of preparing reports on patients wearing cardiac monitoring devices 100. Accordingly, a technician interface 114 may include a computing device having a processor communicably connected to a memory and a visual display. The technician interface 114 may display to a user of the technician interface 114 (e.g., a technician) one or more parameters relating to the patient and/or to preparation of a report. The user of the technician interface 114 can interact with the parameters via the technician interface 114 to guide the remote server 102 in preparing a report on a patient. As an example, a technician may select a time period to use for a report, and the remote server 102 prepare a report corresponding to the selected time period. As another example, a technician may view a report prepared by the remote server 102 and draft a summary of the report that is included in a summary section of the report. Alternatively, in some embodiments, the remote server 102 may prepare a patient report with minimal or no input or interaction with a technician via a technician interface 114. In this way, the remote server 102 may prepare a patient report through a completely or mostly automated process.
The caregiver interfaces 116 are configured to electronically communicate with the remote server 102 for the purpose of viewing reports on patients wearing cardiac monitoring devices 100. As such, a caregiver interface 116 may include a computing device having a processor communicably connected to a memory and a visual display. The caregiver interface 116 may display to a user of the caregiver interface 116 (e.g., a physician, a nurse, or other caregiver) a patient report prepared by the remote server 102. In some implementations, the user of the caregiver interface 116 may be able to interact with the patient report. For example, the user of the caregiver interface 116 may be able to select a portion of the patient report and, in response, be able to view additional information relating to the selected portion of the report. In implementations, the user of the caregiver interface 116 may view the patient report without interacting with the patient report.
In some implementations, a technician interface 114 and/or a caregiver interface 116 may be a specialized user interface configured to communicate with the remote server 102. As an example, the technician interface 114 may be a specialized user interface configured to receive preliminary patient reports from the remote server 102, receive input from a technician to adjust the preliminary patient report (e.g., adjust a timeline of the preliminary patient report), and transmit the input to the remote server 102. The remote server 102 then uses the input from the technician to prepare a finalized patient report, which the remote server 102 transmits to the technician interface 114. As another example, the caregiver interface 116 may be a user interface specialized to receive and display patient reports from the remote server 102. In such implementations, the specialized technician interface 114 and/or caregiver interface 116 may be limited to performing functions related to the cardiac monitoring system.
In implementations, a technician interface 114 and/or a caregiver interface 116 may be a generalized user interface that has been adapted to communicate with the remote server 102. To illustrate, the technician interface 114 may be user interface executing a technician application that configures the portable personal digital assistant to communicate with the remote server 102. For example, the technician application may be downloaded from an application store or otherwise installed on the user interface. Accordingly, when the user interface executes the technician application, the user interface is configured to receive preliminary patient reports from the remote server 102, receive input from a technician, transmit the input to the remote server 102, and receive finalized patient reports from the remote server 102. Similarly, the caregiver interface 116 may be a user interface executing a caregiver application that configures the user interface to communicate with the remote server 102. The caregiver application may be similarly downloaded from an application store or otherwise installed on the user interface and, when executed, may configure the user interface to receive and display patient reports from the remote server 102. The application store is typically included within an operating system of the device implementing the user interface. For example, in a device implementing an operating system provided by Apple Inc. (Cupertino, Calif.), the application store can be the App Store, a digital distribution platform, developed and maintained by Apple Inc., for mobile apps on its iOS and iPadOS operating systems. The application store allows users to browse and download a technician and/or caregiver interface app developed with in accordance with Apple's iOS Software Development Kit. For example, such technician and/or caregiver interface apps can be downloaded on the iPhone smartphone, the iPod Touch handheld computer, or the iPad tablet computer, and some can be transferred to the Apple Watch smartwatch.
In some cases, the technician application and the caregiver application may be the same application, and the application may provide different functionalities to the device executing the application based on, for example, credentials provided by the user. For instance, the application may provide technician functionalities to a first user interface in response to authenticating technician credentials entered on the first user interface, and may provide caregiver functionalities to a second user interface in response to authenticating caregiver credentials entered on the second user interface. In other cases, the technician application and the caregiver application may be separate applications, each providing separate functionalities to a user device executing them.
In some implementations, the system shown in
As shown in
The cardiac monitoring device 100 also acquires motion signals at step 204. In various embodiments, the cardiac monitoring device 100 acquires the motion signals via one or more motion sensors incorporated into the cardiac monitoring device 100. The motion sensor(s) may include, for example, one or more accelerometers, gyroscopes, magnetometers, ballistocardiographs, and the like. For instance, the cardiac monitoring device 100 may include a sensor unit 110 that includes a 3D accelerometer with three axes. As such, the motion signals include motion and/or posture information. As another example, the cardiac monitoring device 100 includes an adhesive patch 108 with an integrated motion sensor, such as an integrated accelerometer. As another example, the cardiac monitoring device 100 includes individual electrodes 112 configured to be disposed at predetermined anatomical locations on the patient's body (e.g., adhered to specific locations on the patient's body). For example, the locations can be the patient's lateral left chest wall at the mid-axillary line at the nipple level or the patient's front lest chest location. As such, the motion signals may be acquired via one or more accelerometers coupled to the electrodes 112 and/or coupled to connections between the electrodes 112 and a sensor unit 110 (e.g., coupled to wires connecting the electrodes 112 to the sensor unit 110).
After sensing the ECG signals and acquiring motion signals, the cardiac monitoring device 100 transmits the sensed ECG signals and acquired motion signals to the remote server 102 at step 206. In some embodiments, the portable gateway 106 transmits the ECG signals and motion signals to the remote server 102. For example, the sensor unit 110 may receive ECG signals from the electrodes 112, and the sensor unit 110 may acquire motion signals via one or more motion sensors incorporated into the adhesive patch 108, incorporated into the sensor unit 110, and/or coupled to the electrodes 112. The sensor unit 110 may then transmit the ECG signals and motion signals to the portable gateway 106 (e.g., via Bluetooth®). The portable gateway 106 further transmits the ECG signals and motion signals to the remote server 102 (e.g., via cellular networks, via Wi-Fi). In other embodiments, the cardiac monitoring device 100 may not include a portable gateway 106, and the cardiac sensor 104 may instead transmit the ECG signals and motion signals to the remote server 102 (e.g., via cellular networks or via Wi-Fi as noted above).
The remote server 102 stores the ECG signals and motion signals at step 208. For example, the remote server 102 may include one or more databases and store the ECG signals and motion signals in a database of the remote server 102. The remote server 102 also determines the onset of an arrhythmia event based on the received ECG signals at step 210. The remote server 102 (or, in some embodiments, the sensor unit 110 itself) may execute ECG classification processes to detect and classify the beats and rhythms of the patient's heartbeat from the received data. For example, the ECG classification processes may detect ventricular ectopic beats, ventricular couplets, short (e.g., non-sustained) runs (e.g., ventricular runs of less than about 30-second duration), long (e.g., sustained) runs (e.g., ventricular runs of greater than about 30-second duration), supraventricular ectopic beats (SVEBs), ventricular couplets, and/or the like. In some embodiments, the ECG classification unit may detect bradycardia, tachycardia, atrial fibrillation episodes, pauses (e.g., in the heartbeat of the patient), ventricular tachycardia, bigeminy, trigeminy, multigeminy, supraventricular tachycardia, ventricular fibrillation, and heart block (e.g., atrioventricular (AV) blocks including first degree, second degree, and/or third degree heart blocks). In some instances, the AV second-degree blocks may include type I and/or type II blocks.
Further, in some embodiments, the ECG classification processes may include a feature extraction process that is configured to determine various features of the beats classified by the ECG classification processes. For example, the feature extraction process may calculate beat features including, but not limited to, QRS width, polarity, maximum-to-minimum ratio, P-wave, existence, and/or the like. The ECG classification processes can include rhythm change classifiers. Such example, such rhythm change classifies may be implemented in a non-transitory computer-readable medium (e.g., a memory, a programmable circuit board, a field programmable gate array, an integrated circuit, any combination thereof, and/or the like). The rhythm change classifier may include at least one neural network trained based on a historical collection of a plurality of ECG signal portions with known rhythm change information. Additionally, at least one processor may be operatively connected to the ECG channel(s) and the non-transitory computer-readable medium. The processor(s) may receive the ECG signal(s) via the ECG channel(s). The processor(s) may also use the rhythm change classifier to detect time data corresponding to a rhythm change (e.g., predetermined rhythm change and/or the like) in the ECG signal(s). For example, the time data may include a start time, a time interval, any combination thereof, and/or the like. The processor(s) may also determine, based on the detected time data, at least one ECG signal portion associated with the detected time data corresponding to the predetermined rhythm change in the ECG signal(s). The processor(s) may also transmit the determined ECG signal portion(s) to a remote computer system (e.g., a remote server, a cardiac monitoring facility, and/or the like). For example, in such embodiments, the rhythm change classifier (e.g., neural network(s) and/or the like thereof) may detect (e.g., identify and/or the like) the rhythm change without having to classify the specific rhythm type. For the purpose of illustration, the rhythm change classifier may detect a rhythm when heart rhythm changes from normal sinus rhythm (NSR) to Atrial Fibrillation (AFIB), from AFIB to NSR, from AFIB to Atrial Flutter (AFL), from one morphology to another, and/or the like. Additionally, every time a rhythm change is detected (e.g., identified and/or the like), an ECG signal portions (e.g., ECG strip and/or the like) containing the detected rhythm change may be transmitted to the remote computer system (e.g., with an indication, message, marking, and/or the like indicating a detected rhythm change). Additionally or alternatively, the rhythm change classifier may determine a confidence score associated with the detected rhythm change (e.g., output the confidence score associated with the probability that the detected rhythm change actually is a rhythm change). An example process flow for step 210 of determining the onset of the arrhythmia event is shown in
In the example process flow shown in
For example, in some implementations, the remote server 102 may receive raw ECG data sampled at 250 Hz. The remote server 102 may then remove baseline wander, high frequency noise, and 50/60 Hz interference. This filtering may be represented mathematically by denoting the raw ECG data as x and representing the process as:
y
1
=bpf*x
In this equation, bpf represents band pass filtering, * stands for convolution, and y1 represents the filtered signal. Subsequently, the remote server 102 may use a Pan-Tompkins-based QRS complex detector to identify the QRS complexes in the filtered signal. First, the remote server 102 finds the derivative of the filtered y1 signal and square the result, which may be represented as:
Next, the remote server 102 applies a moving average to the y2 result, which may be further represented mathematically by:
y
3=MovingAverageFilter*y2
The remote server 102 then applies an adaptive power threshold to locate the QRS complexes in the y3 signal and find the locations of R peaks within the QRS complexes, where the R peaks location sequence may be represented as {Ri}.
The remote server 102 may then use Ri as the input in the heart rate estimation stage. More particularly, the remote server 102 calculates heart rate for moving, overlapping, one-minute windows. Each window is tested for validity. If a window is not valid, no heart rate result is provided for that time window. Validity may be determined, for instance, based on determining no signal saturation and RRi distribution meeting validity conditions, where RRi represents a sequence of R-R intervals. For valid windows, the sequence of R-R intervals is computed as follows:
RR
i
=R
i+1
−R
i
If there are outlying R-R values, the remote server removes the two most extreme Rri outliers are removed, and the heart rate is computed by:
In implementations, the remote server 102 compares the ECG signals to one or more stored thresholds at step 234. As an illustration, as shown in the example embodiment of
In some implementations, the bradycardia onset threshold and/or the bradycardia offset threshold may be determined on a patient-by-patient basis. For instance, the bradycardia onset and offset thresholds may be determined based on physiological information about the patient (e.g., using the patient's height, weight, gender, age, health, etc.) to determine statistically probable bradycardia onset and offset thresholds based on one or more categories the patient falls into. To illustrate, the remote server 102 may determine that the bradycardia onset and offset thresholds for a 25-year-old man are higher than for a 64-year-old woman based on statistics for men between the ages of 20-30 and women between the ages of 60-70. As another example, the bradycardia onset and offset thresholds may be determined based on a baseline ECG taken, for instance, by the patient's physician. The remote server 102 may analyze the baseline ECG to identify features from the ECG, such as the patient's baseline heart rate, and set the bradycardia onset and offset thresholds based on the identified features.
In some embodiments, looking to the tachycardia thresholds at step 234b, the remote server 102 may compare the heart rate determined from the ECG signals to a tachycardia onset threshold for heart rate. If the determined heart rate rose above the tachycardia onset threshold (e.g., for a certain period of time, for a certain number of heartbeats), the remote server 102 determines that the patient entered tachycardia at that time. Further, the remote server 102 may determine when the patient left tachycardia by comparing the heart rate determined from the ECG signals to a tachycardia offset threshold for heart rate, which may or may not be the same as the tachycardia onset threshold. Once the determined heart rate drops below the tachycardia offset threshold (e.g., for a certain period of time, for a certain number of heartbeats), the remote server 102 determines that the patient left tachycardia at that time. As an illustration, the remote server 102 may determine that the patient entered tachycardia if the patient's determined heart rate rose above 140 beats per minute for at least 45 seconds. The remote server 102 may then determine that the patient left tachycardia once the patient's determined rate fell below 120 beats per minute for at least 15 seconds.
Additionally, similar to the bradycardia onset and offset thresholds, in some implementations, the tachycardia onset threshold and/or the tachycardia onset threshold may be determined on a patient-by-patient basis. For instance, the tachycardia onset and offset thresholds may be determined based on physiological information about the patient (e.g., using the patient's height, weight, gender, age, health, etc.) to determine statistically probable tachycardia onset and offset thresholds based on one or more categories the patient falls into. To illustrate, the remote server 102 may determine that the tachycardia onset and offset thresholds for a 55-year-old man are lower than for an 18-year-old man based on statistics for men between the ages of 15-22 and 50-58. As another illustration, similar to the bradycardia example discussed above, the tachycardia onset and offset thresholds may be determined based on a baseline ECG taken, for instance, by the patient's physician and features identified from the baseline.
In some embodiments, looking to the atrial fibrillation thresholds at step 234c, the remote server 102 may determine R-R intervals between successive R-waves of the ECG signals. The remote server 102 may also determine the difference between successive R-R intervals as A R-R. In some implementations, the remote server 102 may detect atrial fibrillation based on an analysis of sequences of R-R intervals and ΔR-R values considered as random variables, such as per a sliding window of length N centered on each beat. An application of the Kolmogorov-Smirnov test can return the probability of the hypothesis that a set of ΔR-R values over a window belongs to a standard distribution depending on a mean value of R-R intervals over the same window. In such cases, if the probability provided by the Kolmogorov-Smirnov test exceeds a threshold, then the remote server 102 may recognize the central beat (or subset of beats around the central beat) as atrial fibrillation. Further, in some implementations, the remote server 102 may require that the patient be in atrial fibrillation for a certain amount of time (e.g., one minute) before the remote server 102 determines that an atrial fibrillation event occurred.
In some embodiments, looking to the pause thresholds at step 236d, the remote server 102 may determine whether a distance between successive QRS complexes is above a pause threshold. For example, the remote server 102 may determine that a pause occurred if the distance between successive R-waves is greater than 3500 milliseconds. Further, in some implementations, the remote server 102 may impose a pause maximum, after which the remote server 102 will not identify the event as a pause. As an illustration, the remote server 102 may determine that ECG signals showing no activity for more than 20 seconds is likely due to the cardiac monitoring device 100 incorrectly receiving signals from the patient, rather than due to a cardiac event.
In some implementations, the remote server 102 may set the pause thresholds and/or the pause maximum on a patient-by-patient basis, similar to the bradycardia and tachycardia thresholds. For instance, the pause threshold may be determined based on physiological information about the patient (e.g., using the patient's height, weight, gender, age, health, etc.) to determine a statistically probable pause threshold based on one or more categories the patient falls into. To illustrate, the remote server 102 may determine that the pause threshold is higher for an 80-year-old than for a 20-year-old based on the fact that the average heart rate for an 80-year-old is lower than for a 20-year-old. As another example, similar to the bradycardia and tachycardia examples discussed above, the pause threshold may be determined based on a baseline ECG taken, for instance, by the patient's physician and features identified from the baseline.
In some embodiments, in addition to or in the alternative of, the bradycardia, tachycardia, atrial fibrillation, and pause thresholds discussed above, the remote server 102 may compare the ECG signals to other thresholds associated with other types of cardiac events at step 234. For example, the remote server 102 may use other thresholds to identify ventricular ectopic beats, ventricular couplets, short runs, long runs, SVEBs, ventricular couplets, ventricular tachycardia, bigeminy, trigeminy, multigeminy, supraventricular tachycardia, ventricular fibrillation, and/or heart blocks. Further, in some embodiments, the methods used to identify bradycardia, tachycardia, atrial fibrillation, and pause events may vary. Additional methods and details on identifying cardiac events from ECG signals are discussed in U.S. patent application Ser. No. 16/041,402, filed Jul. 20, 2018, entitled “SYSTEMS, DEVICES, AND METHODS FOR PHYSIOLOGICAL MONITORING OF PATIENTS,” now U.S. Pat. No. 11,020,002, the disclosure of which is hereby incorporated in its entirety by reference. Yet additional methods and systems for identifying cardiac events from ECG signals based on machine learning and/or neural networks techniques are discussed in U.S. patent application Ser. No. 17/083,472, filed Oct. 29, 2020, entitled “SYSTEMS, DEVICES, AND METHODS FOR CARDIAC DIAGNOSIS AND/OR MONITORING,” the disclosure of which is hereby incorporated in its entirety by reference.
The remote server 102 identifies an arrhythmia event from a threshold at step 236. For example, the remote server 102 may identify a bradycardia event, tachycardia event, atrial fibrillation event, pause event, etc. as discussed above. The remote server 102 also identifies the onset of the arrhythmia event at step 238. As an illustration, if the remote server 102 has determined that the ECG signals reflect a bradycardia event based on bradycardia onset and/or offset thresholds, the remote server 102 may determine that the bradycardia event onset occurred at the time the patient's heart rate fell below the bradycardia onset threshold. As another illustration, if the remote server 102 has determined that the ECG signals reflect a pause event based on the patient's ECG signals showing no activity for 5000 milliseconds, the remote server 102 may determine that the pause event onset occurred at the time the patient's ECG signals stopped showing activity. Alternatively, the remote server 102 may determine that the pause event onset occurred a certain amount of time into the pause event, such as 10 milliseconds after the patient's ECG signals stopped showing activity.
Additionally, in some embodiments, the remote server 102 may identify the offset of the arrhythmia event. To illustrate, if the remote server 102 has determined that the ECG signals reflect a tachycardia event based on tachycardia onset and/or offset thresholds, the remote server 102 may determine that the tachycardia event offset occurred at the time the patient's heart rate fell below the tachycardia event offset threshold. As another example, if the remote server 102 has determined that the ECG signals reflect an atrial fibrillation event based on the patient's R-R intervals and ΔR-R values, the remote server 102 may determine that the atrial fibrillation event offset occurred at the time the patient's R-R intervals and A R-R values reflected values.
Returning to the sample process 200 shown in
In the example process flow shown in
Additionally, in some implementations, the period of time for the arrhythmia contextual time period may be a fixed period of time, while in other implementations, the period of time may be a variable period of time. For instance, the period of time may be a fixed amount of time around a portion of the arrhythmia event, such as a fixed amount of time around the onset or the offset of the arrhythmia event. Alternatively, the period of time may be a variable amount of time that depends, for example, on the length of the arrhythmia event. As an illustration, the period of time may consist of a certain amount of time before the onset of the arrhythmia event, the duration of the arrhythmia event, and a certain amount of time after the arrhythmia event.
The remote server 102 uses the period of time from step 242 to identify the arrhythmia contextual time period at step 244. In some implementations, the remote server 102 may determine that the arrhythmia contextual time period includes a time period that includes the onset of the arrhythmia event. For example, the remote server 102 may determine that the arrhythmia contextual time period includes a two-hour time period during which the onset of the arrhythmia event occurred, an hour time period during which the onset of the arrhythmia event occurred, a 30-minute time period during which the onset of the arrhythmia event occurred, a 15-minute time period during which the onset of the arrhythmia event occurred, and/or a 10-minute time period during which the onset of the arrhythmia event occurred.
As an illustration, the remote server 102 may determine that the arrhythmia event onset occurred at 9:15 am on December 2. The period of time for the arrhythmia contextual time period may be a 2-hour block. As such, the remote server 102 may determine that the arrhythmia contextual time period is 8:00-10:00 am on December 2. Alternatively, the period of time for the arrhythmia contextual time period may be 2 hours centered around the arrhythmia event onset. Thus, the remote server 102 may determine that the arrhythmia contextual time period is 8:15-10:15 am on December 2. As another alternative, the period of time for the arrhythmia contextual time period may be a first amount of time before the arrhythmia event onset and a second amount of time after the arrhythmia event onset, such as an hour before the arrhythmia event onset and 30 minutes after the arrhythmia event onset, or 90 minutes before the arrhythmia event onset and 30 minutes after the arrhythmia event onset. The remote server 102 may accordingly determine that the arrhythmia contextual time period is 8:15-9:45 am on December 2. As another alternative, the period of time for the arrhythmia contextual time period may be an amount of time that ends at the arrhythmia event onset, such that the arrhythmia contextual time period is 15 minutes before the arrhythmia event onset. Therefore, the remote server 102 may determine that the arrhythmia contextual time period is 9:00-9:15 am on December 2. As another alternative, the period of time for the arrhythmia contextual time period may be an amount of time that begins at the arrhythmia event onset, such that the arrhythmia contextual time period is 30 minutes after the arrhythmia event onset. In such cases, the remote server 102 may determine that the arrhythmia contextual time period is 9:15-9:45 am on December 2.
In some implementations, the remote server 102 may determine that the arrhythmia contextual time period includes the offset of the arrhythmia event. For example, the remote server 102 may determine that the arrhythmia contextual time period includes a two-hour time period during which the offset of the arrhythmia event occurred, an hour time period during which the offset of the arrhythmia event occurred, a 30-minute time period during which the offset of the arrhythmia event occurred, a 15-minute time period during which the offset of the arrhythmia event occurred, and/or a 10-minute time period during which the offset of the arrhythmia event occurred.
As an illustration, the remote server 102 may determine that the arrhythmia event offset occurred at 5:24 pm (or alternatively, 17:24) on November 15. The period of time for the arrhythmia contextual time period may be a 1-hour block. As such, the remote server 102 may determine that the arrhythmia contextual time period is 5:00-6:00 pm (or alternatively, 17:00-18:00) on November 15. Alternatively, the period of time for the arrhythmia contextual time period may be 1 hour centered around the arrhythmia event offset. Thus, the remote server 102 may determine that the arrhythmia contextual time period is 4:54-5:54 pm (or alternatively, 16:54-17:54) on November 15. As another alternative, the period of time for the arrhythmia contextual time period may be a first amount of time before the arrhythmia event offset and a second amount of time after the arrhythmia event onset, such as an hour before the arrhythmia event offset and an hour and a half after the arrhythmia event offset. The remote server 102 may accordingly determine that the arrhythmia contextual time period is 4:24-6:54 pm (or alternatively, 16:24-18:54) on November 15. As another alternative, the period of time for the arrhythmia contextual time period may be an amount of time that ends at the arrhythmia event offset, such as 10 minutes before the arrhythmia event offset. Therefore, the remote server 102 may determine that the arrhythmia contextual time period is 5:14-5:24 pm (or alternatively, 17:14-17:24) on November 15. As another alternative, the period of time for the arrhythmia contextual time period may be an amount of time that begins at the arrhythmia event offset, such as an hour after the arrhythmia event offset. In such cases, the remote server 102 may determine that the arrhythmia contextual time period is 5:24-6:24 pm (or alternatively, 17:24-18:24) on November 15.
In some implementations, the remote server 102 may determine that the arrhythmia contextual time period includes a time period that includes both the onset and the offset of the arrhythmia event. In such implementations, the arrhythmia contextual time period may include, for example, various combinations of the periods of time surrounding the arrhythmia event onset and the arrhythmia event offset discussed above.
As an illustration, the remote server 102 may determine that the arrhythmia event offset occurred at 6:48 am on April 27 and that the arrhythmia event offset occurred at 8:33 am on April 27. The period of time for the arrhythmia contextual time period may be a 1-hour block that includes the arrhythmia event onset up to a 1-hour block that includes the arrhythmia event offset. As such, the remote server 102 may determine that the arrhythmia contextual time period is 6:00-9:00 am on April 27. Alternatively, the period of time for the arrhythmia contextual time period may be 30 minutes before the arrhythmia event onset up to 30 minutes after the arrhythmia event offset. Thus, the remote server 102 may determine that the arrhythmia contextual time period is 6:18-9:03 am on April 27. As another alternative, the arrhythmia contextual time period may be a first amount of time before the arrhythmia event onset and a second amount of time after the arrhythmia event offset, such as three hours before the arrhythmia event onset and an hour after the arrhythmia event offset. Accordingly, the remote server 102 may determine that the arrhythmia contextual time period is 3:48-9:33 am on April 27.
In some implementations, the remote server 102 may determine that the arrhythmia contextual time period includes a time period within the duration of the arrhythmia event. For example, the remote server 102 may determine that the arrhythmia contextual time period includes a time period a certain amount of time after the arrhythmia event onset, a certain amount of time before the arrhythmia event offset, a randomly sampled amount of time during the duration of the arrhythmia event, an amount of time during the midpoint of the arrhythmia event, and so on. The above arrhythmia contextual time periods and methods thereto are illustrative. Other arrhythmia contextual time period durations as well as other ways of calculating the arrhythmia contextual time period, are within the scope this disclosure.
In some implementations, as discussed above, the remote server 102 may set a default arrhythmia contextual time period. The default arrhythmia contextual time period may be modified by a user, such as a technician via a technician interface 114 or a caregiver via a caregiver interface 116. For example, a user may be able to select from a list of time periods for an arrhythmia contextual time period or may be able to input a custom arrhythmia contextual time period (e.g., up to 24 hours around the arrhythmia event onset).
In some implementations, the default arrhythmia contextual time period may depend on the type of arrhythmia (or symptom event, as described in further detail below). A benefit of this feature is that it provides a more relevant context for certain types of arrhythmias to enhance diagnostic yield and/or quality. As an illustration, the default arrhythmia contextual time period for a pause event may be shorter than the default arrhythmia contextual time period for a tachycardia event. In some implementations, the arrhythmia contextual time period may depend on the biometric status of the patient at the onset and/or offset of the arrhythmia event. For example, the remote server 102 may determine that the arrhythmia event onset occurred while the patient was asleep. As another example, the remote server 102 may determine whether the arrhythmia event onset occurred while the patient was active and use this information in determining the default values for the arrhythmia or symptom contextual time period.
Referring to
Subroutine 2010 is initiated if a user input for the arrhythmia or symptom contextual time period is received. In step 2012, a custom value for the arrhythmia or symptom contextual time period is received. For example, a technician user via a technician interface 114 or a caregiver user via a caregiver interface 116 may be presented with a default value for the arrhythmia or symptom contextual time period (determined as shown in subroutine 2020) and provided with a user interactive feature on the interface 114, 116 to modify the value. In some implementations, the technician or caregiver user can specify via the interface 114, 116 a custom value for the arrhythmia or symptom contextual time period. As noted above, the user may be able to select from a list of time periods for an arrhythmia or symptom contextual time period or may be able to input a custom arrhythmia or symptom contextual time period (e.g., up to 24 hours around the arrhythmia event onset or the patient-provided symptom input). In implementations, the user can select a first custom value for a preceding time period for the arrhythmia onset or symptom event, and a second custom value for a following time period for the arrhythmia onset or symptom event.
As an illustration, the user may note that the arrhythmia event onset or symptom event occurred at 6:48 am on April 27. The user may select or input a period of time for the arrhythmia or symptom contextual time period as a 1-hour block that includes the arrhythmia event onset or symptom event. In this example, the arrhythmia event onset or symptom event may be automatically centered within the 1-hour block. Accordingly, the period of time for the arrhythmia or symptom contextual time period may be 30 minutes before the arrhythmia event onset or the patient-provided symptom input indicating the symptom event and up to 30 minutes after the arrhythmia onset event or symptom input. Alternatively, the arrhythmia or symptom contextual time period may be a first custom amount of time (e.g., 20 minutes) before the arrhythmia event onset or symptom input and a second custom amount of time (e.g., 40 minutes) after the arrhythmia onset event or symptom input.
In step 2014, the contextual biometric information during the default or custom arrhythmia or symptom contextual time period is determined based on motion signals. An example of such a subroutine is described in connection with
Subroutine 2020 is initiated if a default value for the arrhythmia or symptom contextual time period is to be calculated. In step 2022, the arrhythmia event or symptom event is assessed to determine the underlying event type. Alternatively or additionally, in step 2024, the biometric status of the patient is assessed. In step 2026, the value of the arrhythmia or symptom contextual time period is determined based on the event type and/or biometric status of the patient.
For example, in steps 2022-2026, if the arrhythmia event type is a pause, then a default value for the arrhythmia contextual time period may be 15 minutes before and 15 minutes after the onset of the pause event. For example, the default arrhythmia contextual time period for a tachycardia event may be 60 minutes before and 30 minutes after the onset of the tachycardia event. For example, the default arrhythmia contextual time period for a bradycardia event may be 90 minutes before and 60 minutes after the onset of the bradycardia event. For example, the default arrhythmia contextual time period for an atrial fibrillation onset event may be 2 hours before and 1 hour after the onset of the atrial fibrillation event. In examples, a user may specify in advance these default values.
Additionally or alternatively, in steps 2024-2026, the default value for the arrhythmia contextual time period may depend on the biometric status of the patient at or around the arrhythmia event onset and/or or symptom input. To illustrate, the remote server 102 may determine that the arrhythmia event onset occurred while the patient was asleep. The remote server 102 may determine whether the patient was still asleep 60 minutes before the arrhythmia event onset. If the patient was awake 60 minutes before the arrhythmia event onset, the remote server 102 may set the arrhythmia contextual time period as 60 minutes before and 30 minutes after the onset of the arrhythmia event. If the patient was asleep 60 minutes before the arrhythmia event onset, the remote server 102 may determine whether the patient was awake 120 minutes before the arrhythmia event onset. If the patient was awake 120 minutes before the onset of the arrhythmia event, the remote server 102 may set the arrhythmia contextual time period as 120 minutes before and 30 minutes after the onset of the arrhythmia event. If the patient was asleep 120 minutes before the arrhythmia event onset, the remote server 102 may set they arrhythmia contextual time period as 180 minutes before and 30 minutes after the onset of the arrhythmia event. The remote server 102 may also determine the last time the patient was awake before the arrhythmia event onset and provide amount of time the patient was asleep before the arrhythmia event onset as part of the arrhythmia report, discussed in further detail below.
As another example, the remote server 102 may determine whether the arrhythmia event onset occurred while the patient was active. If the patient was inactive when the arrhythmia event onset occurred, the remote server 102 may set the arrhythmia contextual time period as 60 minutes before and 30 minutes after the onset of the arrhythmia event. If the patient was active when the arrhythmia event onset occurred, the remote server 102 may determine the time when the patient transitioned from an inactive status to an active status and set the arrhythmia contextual time period as that time until 30 minutes after the arrhythmia event onset.
Alternatively or additionally, in step 2028, depending on the event type, the subroutine 2020 may prompt a user to specify custom value(s) for the arrhythmia or symptom contextual time period in accordance with subroutine 2010. This mandatory custom value feature provides a benefit that ensures care is taken for certain arrhythmias and/or symptom events. For example, a caregiver may prescribe the cardiac monitor to assess a patient suffering from frequent syncopal episodes. As such, it is desirable that, rather than using the default values, the process 2005 prompt the technician user or caregiver user to specify custom value(s) for the syncopal contextual time period to ensure that special attention is given to the preparation of reports relating to syncopes.
Returning to the sample process 200 shown in
In the example process flow shown in
The remote server 102 then determines various biometric information for the patient based on the filtered signals at step 254. As an illustration, as shown in the example embodiment of
For example, in some implementations, the cardiac monitoring device 100 may include a tri-axial accelerometer sensitive to the gravitational field, where the accelerometer reading samples during the measurement time window may be represented as xi, yi, and zi. For each axis, the remote server 102 may normalize the accelerometer samples by the g (gravity) value. The remote server 102 may then average the accelerometer measurements over the measurement time window, which may be represented as:
x
a=mean(xi)
y
a=mean(yi)
z
a=mean(zi)
If the accelerometer is being worn on the patient's front (e.g., on the patient's chest), the remote server 102 may apply an angle transformation to the averaged accelerometer measurements. This transformation rotates the axis reference from the front location to a side location to bring the data to a common frame of reference (e.g., a common frame of reference with accelerometer data from accelerometers worn on the patient's side). To do this transformation, the remote server 102 defines rotation matrices ROT1 and ROT2 as follows:
where α=24° and θ=45°. The remote server 102 then rotates the acceleration vector as follows:
For accelerometer data normalized to a common frame of reference, the remote server 102 may then calculate pitch and roll using the formulas:
pitch=a tan 2(−yr,√{square root over (xr2+zr2)})
roll=a tan 2(zr,√{square root over (yr2+μ*xr2)})
where a tan 2 is the four quadrant inverse tangent, μ=0.1, and μ*xr2 is used to remove calculation instabilities. Additionally, in the formula above, the pitch angle is the tilt angle from a vertical orientation. This angle is used to determine if the patient is supine, reclined, or upright.
In some embodiments, the remote server 102 determines the posture information by classifying the patient's posture over time into various posture types. The posture types may include, for example, “supine,” “reclined,” “upright,” “standing,” “sitting,” “resting,” “lying on the right side,” “lying on the left side,” and/or the like. To illustrate, the remote server 102 may either determine or receive from the motion sensor a signal indicating the device tilt of the motion sensor in degrees over time. The remote server 102 may compare the degree of the motion sensor's tilt to various degree thresholds to classify whether a patient's posture at any given time fits under various categories, such as “supine,” “reclined,” and “upright.” For instance, the remote server 102 may determine that the patient was supine where the motion sensor's tilt (e.g., the patient's pitch angle) was less than 30 degrees, determine that the patient was reclined when the motion sensor's tilt was between 30 degrees and 60 degrees, and determine that the patient was upright when the motion sensor's tilt was greater than 60 degrees.
The posture for the patient may also be calibrated, for example, the first time that the patient wears the cardiac monitoring device 100 to determine an upright posture for the patient. As an example, the patient may wear the cardiac monitoring device 100 in a caregiver's office. The caregiver may indicate to the cardiac monitoring device 100, or directly to the remote server 102 via a caregiver interface 116, when the patient is upright versus reclined. The remote server 102 may then set degree thresholds for classifying posture based on this calibration.
As another example, with respect to the activity information determined at step 254b, the motion sensor may include an accelerometer, and the motion signals may capture activity information for the patient. In particular, activity may be measured in accelerometer counts, which are correlated with energy expenditure due to physical activity (e.g., a commonly accepted measure of activity level). Counts may be calculated by taking patient acceleration, removing the component exerted by the Earth's gravity, taking the absolute value, and integrating over time. In some implementations, the determining the activity information for the patient may include determining accelerometer counts for a certain amount of time. For instance, the number of accelerometer counts per second may be determined. As another example, the number of accelerometer counts per second may be determined and multiplied by 60 to find the number of accelerometer counts per minute at any given time for the patient. As another example, these number of accelerometer counts per minute may be averaged over the course of a certain period, such as five minutes, of time to determine an average number of accelerometer counts over the five-minute period. In some cases, the count determination may be made at the remote server 102, which may receive raw or filtered accelerometer signals from the motion sensor. In other cases, this determination may be made by the motion sensor of the cardiac monitoring device 100, which transmits motion signals that include accelerometer counts corresponding to activity information for the patient over time to the remote server 102.
In some embodiments, the remote server 102 to determines the activity information by classifying the patient's activity level over time into various activity level types. The activity level types may include, for example, “active,” “non-active,” “walking,” “low activity,” “intermediate activity,” “sleeping,” “high activity,” “patient fall,” and/or the like. As an illustration, the remote server 102 may either determine or receive from the motion sensor a signal indicating the accelerometer counts of the motion sensor over time. The remote server 102 may compare the accelerometer counts to various count thresholds to classify whether a patient's activity level at any given time fits under various categories, such as “active” and “non-active.” For instance, the remote server 102 may determine that the patient was active when the accelerometer counts per minute were 1000 or more and that the patient was non-active when the accelerometer counts per minute were less than 1000. To illustrate another example, the remote server 102 may determine that the patient was active when the accelerometer counts per second were greater than 15 for at least 30 seconds of a minute time interval and that the patient was non-active the rest of the time.
As another example, the remote server 102 may determine that the patient was in an “active” state for a given minute when the patient showed activity (e.g., accelerometer counts above a predetermined threshold) for at least 30 seconds and had an average posture greater than 35 degrees. Additionally, the remote server 102 may determine that the patient was in an “asleep” state for a given minute when the patient showed activity for less than 12 seconds and had an average posture less than or equal to 35 degrees for that minute. The remote server 102 may finally determine that the patient was in an “inactive” state if the patient had a combination of activity and posture values for a given minute that did not satisfy the active or sleep state thresholds.
Systems and techniques are described for classifying activity and posture information based on “Classification of basic daily movements using a triaxial accelerometer,” M. J. Mathie, B. G. Cellar, N. H. Lovell, and A. C. F. Coster, Med. Biol. Eng. Comput., 2004, 42, 679-687. Mathie et al. describes systems and methods for automated classification of human movements using an accelerometry monitoring system. Actual subjects were recruited for the study: “26 normal, healthy subjects (seven female, 19 male; mean age 30.5 years, 4-6.3 years standard deviation).” The results from the study: “sensitivity of every classification exceeded 87%, and the specificity exceeded 94%. The overall accuracy of the system, measured as the number of correct classifications across all levels of the hierarchy, was a sensitivity of 97.7% and a specificity of 98.7% over a data set of 1309 movements.” A binary decision tree divides the movements into classes and subclasses at different hierarchical levels. General distinctions between movements are applied in the top levels, and successively more detailed subclassifications were made at the lower levels of the tree. A classifier is used to identify basic movements from the signals obtained from a single, triaxial accelerometer mounted on the patient's body. Initially, the movements are divided into “activity” and “rest.” The activities are further classified as “falls,” “walking,” “transition between postural orientations,” and/or other movement. The “postural orientations” during rest were classified as “sitting,” “standing” or “lying.” The movements were performed in “a set sequence: stand; lie supine; lie left side; lie face down; lie fight side; stand; sit; stand; walk along a level corridor; stand; sit; stand; walk up a flight of stairs; walk down a flight of stairs; stand; sit; stand; walk along a level corridor; and stand.” Each of the resting postures was held for 30 s, with the exception of periods of quiet standing between activities, which were held for 10 s.
As noted, “activity and rest were discriminated by integration of the area under the acceleration curves every second, to produce a measure of metabolic energy expenditure, and then comparison of the measured value with a predetermined threshold, if the measured value exceeded the preset threshold, then the subject was classified as engaged in activity. Otherwise, a classification of resting was made.” Further, an “upright posture and lying were discriminated using the measured tilt angle of the subject. Lying substates were discriminated using the measured angle of rotation of the subject when lying.” Additionally, “[s]tanding and sitting were discriminated using a probability rule-based system that used a range of parameters, including tilt angle, duration over which the subject maintained the posture, measured metabolic energy expenditure and previous and next activities, and determined the probabilities that the subject was sitting and standing. The state with the higher probability was then selected as the actual state of the subject.” For determining falls, sit-to-stand, and stand-to-sit transitions the measured signals were compared with signal templates for these movements.
If the patient is not upright at step 272, the process determines whether the patient is experiencing a lying posture at step 276. If the patient is not experiencing a lying posture, the patient's motion/posture is classified as “inverted” at step 278. Otherwise, if the patient is in a lying posture, the process determines whether the patient is lying face down at step 280. If the patient is lying face down, the patient's motion/posture is classified as “lying face down” at step 282. If the patient was not lying face down, the process determines whether the patient is lying on their back at step 284. If the patient is lying on their back, the patient's motion/posture is classified as “lying on back” at step 286. If the patient is not lying on their back, the process determines whether the patient is lying on their left side at step 288. If the patient is lying on their left side, the patient's motion/posture is classified as “lying on left side” at step 290. Otherwise, if the patient is not lying on their left side, the patient's motion/posture is classified as “lying on right side” at step 292.
In some implementations, the remote server 102 may determine when the patient is walking, for example, based on regular peaks in the motion signals that indicate a regular gait. In some cases, the remote server 102 may determine that the patient is walking by matching the motion signals to a walking baseline recorded for the patient, such as recorded for the patient in a caregiver's office when the patient first wears the cardiac monitoring device 100. The determination of when the patient is walking may be used as part of the biometric context, as described in further detail below.
In implementations, the motion sensor can be disposed in either or both of the cardiac sensor 110 attached to the patch affixed to the patient's upper torso and the portable gateway 106 carried by the patient, e.g., in their pants pocket or clipped to a belt worn about the patient's waist (
An activity classification is determined based on the motion and/or posture information as described above. Further classification of the activity can be established as follows. For example, the activity can be classified as “walking,” “running,” “climbing stairs,” or “walking down stairs.” For this illustration, the motion and/or posture data includes acceleration in three axes. Further, the motion sensor is assumed to be located within a patch-based cardiac sensor 104 and affixed to the upper front portion of the patient's torso (See
The periodic patterns for walking, running, climbing stairs, and walking down stairs includes a plurality of peaks (e.g., peaks 1750 for the walking plot 1704), and durations between the peaks. Further, the plots comprise relative magnitudes of the acceleration values for each of the activities. As an example, the plot for walking 1704 comprises a series of high peaks 1750 for the y-axis, spaced out at approximately 0.5 second intervals. The peaks for the z-axis data have similarly timed peaks but with a lower amplitude. The duration between the peaks of the z-axis data and y-axis data comprises a time taken by the patient to complete a single stride length. The x-axis data comprises an even lower amplitude but also includes peaks that are synchronized with the other axes data. For the running plot 1708, the z-axis and y-axis data have synchronized peaks, but the duration between peaks is less than the duration for walking, around 0.25 seconds. Further, a range of y-axis acceleration values for running is larger than for walking. For climbing down stairs, a series of small peaks in the y-axis data occur every 0.5 seconds. Each small peak comprises a movement down a single step. The z-axis data comprises a negative acceleration, indicating regular movement down each step. The x-axis data comprises a series of small peaks, with acceleration ranging between positive and negative values. For climbing up stairs, a series of regular peaks for the z-axis data and y-axis data can be seen. These peaks are spaced approximately 0.75 second seconds apart. The longer duration implies longer time to take to climb up stairs.
Returning to
Systems and techniques for determining respiration from triaxial accelerometer data are described, based on “Respiratory rate and flow waveform estimation from tri-axial accelerometer data,” A. Bates, M. J. Ling, J. Mann, and D. K. Arvind, Sensors, 2016, 16, 750-756. The accelerometer is assumed worn on the chest of the patient. In this case, if the patient is still, then the measured and normalized acceleration vector, a, will be close to the acceleration due to gravity, g, because the linear accelerations due to breathing would be relatively small. As noted in Bates et al., “as the accelerometer rotates, the gravity vector will rotate in the co-ordinate frame of the device. The axis of this rotation may be arbitrarily oriented in the device frame, and may change due to differences in the way the patient breathes at different times. It can also change with the orientation of the patient.” More specifically, the angle θt and the axis of rotation rt between consecutive measurements of the acceleration vector at times t−1 and t were determined by dot and cross products as follows:
θt=cos−1(at·at-1)
r
t
=a
t
×a
t-1
Because oscillatory rotation rt inverts when the direction of rotation reverses, Bates et al. normalized the axis direction by comparison to a reference axis rref as follows:
The predominant axis of rotation was then identified from measurements over a window of length W. Additionally, to reduce the noise, the estimate was weighted by the angle θt associated with each measurement, and to weight measurements closer in time to t, a Hamming window function H(n) was used. This process may be represented as follows:
The central point of the present rotations was estimated similarly:
Using these values, the current rotation angle ϕt, measured from the mean direction of gravity, was determined as follows:
ϕt=sin−1((āt×
The angular velocity on the axis cot was then determined as the derivative of ϕt:
The angular rate in radians per second is used to determine the respiration rate. For example, thresholds in the angular rate signals, scaled based on the RMS level of the signal, and dividing the amplitude range of the signal into low, middle and high bands can be determined. Accordingly, identification of a complete breath can be established using a state machine. where the signal transitions through a middle, a high, the middle, a low and then middle bands, in order to register a breath. The instantaneous respiratory rate is then given by the number of such qualifying breaths within a predetermined period of time.
In some embodiments, the remote server 102 determines the respiration information by classifying the patient's respiration over time into various respiration types. The respiration types may include, for example, “regular breathing,” “rapid breathing,” “shallow breathing,” “rapid shallow breathing,” “deep breathing,” “wheezing,” “sleep disordered breathing,” “Cheyne-Stokes respiration,” and/or the like. As an illustration, the remote server 102 may either determine or receive from the motion sensor a signal indicating the respiration rate of the patient over time. The remote server 102 may compare the respiration rates to various respiration thresholds to classify whether a patient's respiration rate at any time fits under various categories, such as “regular breathing,” “shallow breathing,” and “deep breathing.” For instance, the remote server 102 may determine that the patient was experiencing regular breathing when the patient was breathing between 12 and 20 breaths per minute, that the patient was experiencing shallow breathing when the patient when the patient was breathing over 20 breaths per minute, and that the patient was experiencing deep breathing when the patient was breathing less than 12 breaths per minute. In some cases, the respiration thresholds used to determine which category the patient's respiration rate fits into are determined on a patient-by-patient basis, such as based on a respiration rate baseline for the patient taken by a clinician.
As another example, with respect to the sleep information determined at step 254d, the sleep status for the patient may be determined from a combination of other biometric information of the patient, such as a combination of posture, activity level, and/or respiration of the patient. For instance, the patient may be determined to be asleep when the patient is identified as supine (e.g., at a tilt of less than 35 degrees) and non-active (e.g., showed a non-active accelerometer count for at least 12 seconds of a minute time interval). To illustrate another example, the patient may be determined to be asleep when the patient is identified as supine, non-active, and experiencing deep breathing (e.g., less than 12 breaths per minute) for at least five consecutive minutes.
Other types of biometric information may be determined at step 254, and other processes for determining biometric information may be used at step 254, such as processes for determining biometric information from gyroscopes, magnetometers, ballistocardiographs, ECG, and the like. Further, other types of biometric information may be determined from a combination of other biometric information of the patient. Additional types of biometric information may include, for example, blood pressure, steps taken per day, body temperature, heart rate variability, oxygen saturation, environmental conditions, and/or the like. As such, in some implementations, the remote server 102 may receive other biometric signals from the cardiac monitoring device 100 that the remote server 102 may use to determine the biometric information for the patient.
As an illustration, the remote server 102 may determine heart rate recovery information for the patient by identifying a period of activity (e.g., a certain amount of time, such as five or ten minutes, during which the patient's accelerometer counts showed that the patient was active) and determining the patient's heart rate (e.g., determined from the ECG signals at step 232 of
As another illustration, the remote server 102 may determine, using data from one or more sensors of the cardiac monitoring device 100, environmental conditions for the patient and/or cardiac monitoring device 100 at the time of an arrhythmia. For example, the remote server 102 may determine that an arrhythmia occurred at 8:45 pm, and the remote server 102 may use location data for the patient (e.g., as determined by a GPS sensor on the cardiac monitoring device 100) to further identify environmental data from a separate weather server as the biometric contextual information. Such environmental data can include, for example, outside temperature (e.g., 70° F.), relative humidity (e.g., 60%), air quality (e.g., an Air Quality Index value of 25), and/or elevation (e.g., 145 feet) around the time of the arrhythmia. As another example, the remote server 102 may determine that an arrhythmia occurred at 8:45 pm, and the remote server 102 may receive a temperature read from a temperature sensor of the cardiac monitoring device 100 to use as the biometric contextual information around the time of the arrhythmia.
Additionally, in some implementations, the remote server 102 may determine the biometric information for the patient based at least partially on patient inputs regarding the patient's biometric status at various times over the period the motion signals were recorded. For example, a patient may input to the cardiac monitoring device 100 that the patient anticipates a change in the patient's biometric status, such as the patient is going to sleep or that the patient is about to exercise. To illustrate, a patient may interact with a touchscreen of the portable gateway 106, interact with a digital assistant of the portable gateway 106, tap the sensor unit 110, and so on to indicate an upcoming change in the patient's biometric status.
Once biometric information for the patient is determined, the remote server 102 may then determine the biometric information for the arrhythmia contextual time period at step 256. Accordingly, the remote server 102 may identify the arrhythmia contextual time period determined at step 212 of
In some implementations, the type and/or depth of biometric information isolated may depend on an aspect of the arrhythmia event, such as the type of the arrhythmia event. For instance, for an atrial fibrillation event, the remote server 102 may determine whether the patient was inactive or active from the motion signals and determine the inactive/active status of the patient over the arrythmia contextual time period. In some cases, the remote server 102 may determine a statistical measure, e.g., an average or median value, for the patient over the arrhythmia contextual time period, such as whether the patient was active or inactive for a majority of the arrhythmia contextual time period, and/or the inactive/active status of the patient at the onset of the atrial fibrillation event. However, for a tachycardia event, the remote server 102 may determine a type of activity the patient was engaged in over the arrhythmia contextual time period. As an illustration, the remote server 102 may determine whether the patient was lying down, sitting, standing, walking, or moving briskly from the motion signals and determine the type of activity of the patient over the arrhythmia contextual time period for the tachycardia event. The remote server 102 may, in some cases, determine an average or median type of activity of the patient over the arrhythmia contextual time period and/or a type of activity the patient was engaged in at the tachycardia event onset.
In some implementations, the remote server 102 may identify the contextual biometric information after further analysis of an arrhythmia. For instance, in some cases, the remote server 102 may identify a series of arrhythmia event onsets and arrhythmia event offsets for the same type of arrhythmia in a relatively short time period (e.g., over 12 hours, over 24 hours, over 48 hours). As such, the remote server 102 may determine that the series of arrhythmia event onsets and arrhythmia event offsets belong to one continuous arrhythmia event spanning from the first arrhythmia event onset to the last arrhythmia event offset. In such cases, the remote server 102 may determine the arrhythmia contextual time period and, subsequently, the contextual biometric information based on the determination of the one continuous arrhythmia, rather than determining arrhythmia contextual time periods and contextual biometric information for each arrhythmia event onset and/or arrhythmia event offset.
Returning to the sample process 200 shown in
An example process flow for preparing the display of the arrhythmia report as part of step 216 is shown in
For example, if the contextual biometric information for the arrhythmia contextual time period includes posture information for the patient, the biometric graphical representation may include changes in the patient's posture over the arrhythmia contextual time period. In some cases, these posture changes may be displayed in degrees (e.g., as degrees of the device tilt over the arrhythmia contextual time period. In other cases, these posture changes may be displayed as changes in the type of posture over the arrhythmia contextual time period. As such, viewers may be able to discern either or both absolute or relative posture information. For example, absolute posture information includes absolute values of the patient's posture state in degrees, radians, and the like relative to the horizontal lying position or to the vertical upright position. For example, relative posture information includes changes in the patient's posture from an initial reference such as the horizontal lying position or the vertical upright position. To illustrate, the remote server 102 may classify the patient's posture at any given time or over averaged time intervals of the arrhythmia contextual time period into posture type categories, as discussed above with reference to
As another example, if the contextual biometric information for the arrhythmia contextual time period includes activity level information for the patient, the biometric graphical representation may include changes in the patient's activity level over the arrhythmia contextual time period. In some cases, these activity level changes may be displayed in accelerometer counts (e.g., accelerometer counts per second, accelerometer counts per minute, average accelerometer counts per minute calculated from the accelerometer counts per second over the minute). In other cases, these activity level changes may be displayed as changes in the types of activity level over the arrhythmia contextual time period. To illustrate, the remote server 102 may classify the patient's activity level at any given time or over averaged time intervals of the arrhythmia contextual time period into activity level type categories, as discussed above with reference to
In some implementations, the biometric graphical representation may display when the patient is walking versus when the patient is at rest or active at a level above walking. Additionally, in some cases, the walking information may be further contextualized with respect to arrhythmia (or, as described below, symptom) information and/or other physiological information of the patient. For example, a biometric graphical representation, or a human-readable sentence summary at the end of a biometric graphical representation, may indicate that the patient input that the patient was dizzy while walking or had low heart rates while walking.
As another example, if the contextual biometric information for the arrhythmia contextual time period includes respiration information for the patient, the biometric graphical representation may include changes in the patient's respiration over the arrhythmia contextual time period. In some cases, these respiration changes may be displayed as respiration rates over time (e.g., average respiration rate for a minute time interval). In other cases, these respiration changes may be displayed as changes in the types of respiration over the arrhythmia contextual time period. To illustrate, the remote server 102 may classify the patient's respiration rate at any given time or over averaged time intervals of the arrhythmia contextual time period into respiration type categories, as discussed above with reference to
As another example, if the contextual biometric information for the arrhythmia contextual time period includes sleep status information for the patient, the biometric graphical representation may include changes in the patient's sleep status over the arrhythmia contextual time period. In some cases, these sleep status changes may be displayed as whether the patient was asleep or awake over time.
In some implementations, if the contextual biometric information includes more than one biometric, the biometrics may be charted against separately, though still on the same graphical timeline (e.g., the x-axes of the biometric charts may be aligned). For instance, if the contextual biometric information includes respiration rate, body posture, and activity level, the respiration rate over the arrhythmia contextual time period may be plotted on a first graph encompassing the graphical timeline, the body posture over the arrhythmia contextual time period may be plotted on a second graph encompassing the graphical timeline, and the activity level over the arrhythmia contextual time period may be plotted on a third timeline. In implementations, more than one biometric may be charted on the same graph encompassing the graphical timeline.
In some embodiments, additional or alternative types of biometric information may be used, such as blood pressure, steps taken per day, body temperature, heart rate, heart rate variability, oxygen saturation, environmental conditions, and/or the like. In some embodiments, the biometric graphical representation may also include patient-reported information, such as sleep times reported by the patient, activity times reported by the patient, meals eaten by the patient, symptoms experienced by the patient, and/or the like. Additionally, in some cases, the biometric graphical representation may configured differently from the contextual biometric information plotted or graphed over time, as discussed above. For example, rather than displaying a graphical timeline and a biometric graphical representation, the remote server 102 may determine a summary for each desired biometric over the arrhythmia contextual
The remote server 102 also displays an arrhythmia onset graphical indicator, which may be displayed as overlaid on the biometric graphical representation at step 299. The arrhythmia onset graphical indicator corresponds to the onset of the arrhythmia event. In this regard, an onset or other fiducial aspect of the arrhythmia event is graphically presented within a same display area as the contextual biometric information. For example, overlaying the arrhythmia event on the contextual biometric information includes aligning the arrhythmia event information within the contextual biometric information to convey to a viewer one or more of arrhythmia occurrence time, patient state information, and/or whether the patient was undergoing a transition from or to such state (e.g., active, sleeping, etc.). As an illustration, the remote server 102 may display the arrhythmia onset graphical indicator as a line over the graphical representation at the time of the arrhythmia event onset. The line may extend over all of the contextual biometric information shown in the biometric graphical representation such that a user can easily see how the contextual biometric information corresponds to the arrhythmia event onset. The arrhythmia onset graphical indicator may alternatively be formatted differently from a line. As an illustration, points plotting the contextual biometric information may change color or shape after the arrhythmia event onset, the graphical timeline may become a different color after the arrhythmia event onset, and so on.
Additionally, in some cases, the remote server 102 may display one or more additional graphical indicators on the biometric graphical representation, such as an arrhythmia offset graphical indicator corresponding to the offset of the arrhythmia event. The arrhythmia offset graphical indicator may be formatted similarly to the arrhythmia onset graphical indicator, such as by being shown as a second line labelled as the “arrhythmia event offset.” Alternatively, the arrhythmia offset graphical indicator may be formatted differently from the arrhythmia onset graphical indicator, such as by changing the color of the graphical timeline at the time of the arrhythmia event offset where the arrhythmia onset graphical indicator was shown as a line marking the arrhythmia event onset on the graphical timeline.
In some implementations, the biometric graphical representation may also or alternatively include other types of formatting to present the contextual biometric information for the arrhythmia event. For instance, the biometric graphical representation may include a color change that indicates portions of the biometric information recorded during the daytime (e.g., between 6 am and 6 pm) versus portions of the biometric information recorded during the nighttime (e.g., between 6 pm and 6 am the next day).
In an example, the remote server 102 executes computer-readable instructions or code (e.g., stored in a database of the remote server 102) that accepts an input of “patientID” corresponding to an ID number for the patient for whom the remote server 102 is preparing an arrhythmia event report and an input of “eventID” for an arrhythmia event detected for the patient. The output is a plot of heart rate, respiration rate, posture pitch, and activity in seconds for the period of 90 minutes prior to the onset of the arrhythmia event and 30 minutes after the onset of the arrhythmia event. Additionally, the code outputs the heart rate, respiration rate, pitch, and activity at the onset of the arrhythmia event. As such, example pseudocode for preparing an arrhythmia event report for a patient may be as follows:
As shown in
The cardiac monitoring device 100 then determines the onset of the arrhythmia event at step 306. For example, the cardiac sensor 104 and/or the portable gateway 106 may determine the onset of the arrhythmia event from the ECG signals similarly to the processes described above with reference to step 210 and
The cardiac monitoring device 100 then transmits the arrhythmia event onset, at least the ECG signals corresponding to the arrhythmia event, and the biometric information to the remote server 102 at step 310. The ECG signals corresponding to the arrhythmia event may be, for example, ECG signals including the entire arrhythmia event; ECG signals including the arrhythmia event onset and a certain period of time before the arrhythmia event onset; ECG signals including the arrhythmia event onset, the duration of the arrhythmia event, the arrhythmia event offset, and a certain period of time before and after the arrhythmia event; and so on. In cases where the cardiac monitoring device 100 determines the cardiac event offset, the cardiac monitoring device 100 also transmits the cardiac event offset to the remote server 102.
In some embodiments, the portable gateway 106 transmits the arrhythmia event onset, the ECG signals, and the biometric information to the remote server 102, as described above with reference to step 206 of
The remote server 102 stores the arrhythmia event onset, ECG signals corresponding to the arrhythmia event, and biometric information (as well as any other information and/or signals received from the cardiac monitoring device 100) at step 312. For example, the remote server 102 may include one or more databases and store the arrhythmia event onset, ECG signals corresponding to the arrhythmia event, and biometric information in a database of the remote server 102.
The remote server 102 determines the arrhythmia contextual time period at step 314. In various embodiments, the remote server 102 determines the arrhythmia contextual time period according to the processes discussed above with respect to step 212 and with reference to
In some embodiments, the cardiac monitoring device 100 and the remote server 102 may implement a process flow that is a combination of the sample processes 200 and 300. For example, the cardiac monitoring device 100 may identify the onset of an arrhythmia event and determine a first portion of biometric information for the patient. The cardiac monitoring device 100 may then transmit the arrhythmia event onset, the ECG signals corresponding to the arrhythmia event, the first portion of biometric information, and motion signals corresponding to a second portion of biometric information to the remote server 102. Subsequently, the remote server 102 may determine the second portion of the biometric information from the received motion signals. Alternatively, the remote server 102 may process the first portion of biometric information to identify the second portion of biometric information. As an illustration, the cardiac monitoring device 100 may transmit patient heart rate information, patient posture information, patient activity level information, and patient respiration information to the remote server 102. The remote server 102 may then use the patient heart rate information and the patient activity level information to determine heart rate recovery information for the patient, and/or one or more arrhythmias such as bradycardia, tachycardia, atrial fibrillation, pauses, atrial flutter, ventricular paced beats (VPB), ectopic beats, and so on. The remote server 102 may further user the patient posture information, patient activity level information, and patient respiration information to determine sleep status information for the patient.
The arrhythmia event report 400 further includes a biometric graphical representation 408 for an arrhythmia event determined (e.g., by the cardiac monitoring device 100 worn by the patient or the remote server 102) to have occurred in the patient. In the example shown in
Additionally, as shown in
In addition to the biometric graphical representation 408, the arrhythmia event report 400 includes an arrhythmia onset graphical indicator 414 that corresponds to the onset of the arrhythmia event. The arrhythmia onset graphical indicator 414 is overlaid on the biometric graphical representation 408. As an illustration, in the example of
Alternatively, in some implementations, a biometric graphical representation 408 may display multiple arrhythmia onset graphical indicators corresponding to multiple arrhythmia events. Each arrhythmia onset graphical indicator may be displayed in a different color, with a different shape, or so on to illustrate that they correspond to different arrhythmia events. In some implementations, a biometric graphical representation 408 may include an arrhythmia offset graphical indicator corresponding to the offset of an arrhythmia event. In some implementations, a biometric graphical representation 408 may include an arrhythmia event duration graphical indicator showing the duration of the arrhythmia event. For example, an arrhythmia duration graphical indicator may be displayed as a line across the biometric graphical representation 408, starting at the time of the arrhythmia event onset and ending at the time of the arrhythmia event offset. In some implementations, a biometric graphical representation 408 may be color-coded to show when the arrhythmia event was occurring versus when no arrhythmia event was occurring. Additional methods for displaying an arrhythmia in the context of biometric information are contemplated herein.
In some implementations, the arrhythmia event report 400 may be shown to a user as illustrated in
In implementations, the graphical display may present such information in an interactive manner. For example, the user of a technician interface 114 or caregiver interface 116 may be able to interact with the arrhythmia event report 400 and, in some cases, modify the arrhythmia event report 400 based on those interactions. As an illustration, a technician may be able to adjust the arrhythmia contextual time period for the arrhythmia event report 400 and thus the graphical timeline 410 shown on the report. In this way, the technician may be able to increase or decrease the amount of biometric information included in the arrhythmia event report 400.
As another illustration, a user may be able to interact with the arrhythmia event report 400 and, for example, see additional information relating to the arrhythmia event. For instance, a user may be able to interact with the arrhythmia onset graphical indicator 414, such as by clicking on the arrhythmia onset graphical indicator 414. The user's interface (e.g., a technician interface 114 or a caregiver interface 116) transmits the user's action to the remote server 102. For example, such exchange between the remote server and the user's interface may be facilitated via XML, and/or JSON data exchange formats. For example, to implement interactivity as described here, the user's actions can on the frontend user interface can be implemented as a form which the user's action (e.g., specific location on display area) as an input and converts it into JSON object using javascript and send it to the server. After clicking the arrhythmia onset graphical indicator 414, a send.JSON( ) is called which is defined below.
When sending data to a web server, the data can be converted into a string using, for example, JSON.stringify( ) function to convert data to string and send it via XHR request to the server. In implementations, on the remote server, a scripting language such as PHP can be used to respond to the user's request. For example, a file named Object.php, can be implemented to decode the received user click location to JSON and return textual or other human readable information formed using the received data. The server thus to the interface 114 or 116 a portion of the ECG signals corresponding to the arrhythmia event. For example, the portion of the ECG signals corresponding to the arrhythmia event is displayed within a pop-out area that is displayed in response to the user's action. In some cases, the display of the portion of ECG signals corresponding to the arrhythmia event may replace the display of the arrhythmia event report 400 shown in
In some embodiments, the arrhythmia event report 400 may include additional or alternative information, layouts, formats, and/or graphical representations. For example, in some implementations, the remote server 102 may additionally determine a biometric summary for an arrhythmia event. The biometric summary may include various summary metrics for biometric information that corresponds to the arrhythmia event, such as an average, a median, a minimum, or a maximum of a biometric parameter of the patient over the duration of the arrhythmia event. As an illustration, and with reference to the example arrhythmia event report 400 shown in
In some implementations, the remote server 102 may be configured to prepare the arrhythmia event report 400 to display the biometric status (e.g., as part of a biometric summary for the arrhythmia event or separate from a biometric summary for the arrhythmia event) of the patient at the time the arrhythmia event occurred. For example, the remote server 102 may determine, for a given arrhythmia event, whether a patient was active at the time of the arrhythmia event onset, whether the patient was active a certain amount of time before the arrhythmia event onset (e.g., 30 minutes before the arrhythmia event onset), a level to which the patient was active (e.g., whether the patient was standing, walking, moving briskly, etc.), and so on. As another example, the remote server 102 may determine, for a given arrhythmia event, whether a patient was asleep at the time of the arrhythmia event onset, whether the patient was asleep a certain amount of time before or after the arrhythmia event onset, whether the patient appeared to be having trouble sleeping after the arrhythmia event onset, and so on. In some cases, these determinations may be made at least partially based on feedback or input from a technician via a technician interface 114. For instance, a technician may provide biometric parameters (e.g., activity level, sleep status, posture, etc.) to the remote server 102 that the technician wants included in the arrhythmia event report 400. The remote server 102 may accordingly prepare the arrhythmia event report 400 to display the arrhythmia event, along with the biometric status of the patient, such as in a graphical representation described above and/or in a natural language or human-readable phrase/sentence that summarizes or describes the biometric status of the patient for the arrhythmia event.
The remote server 102 may prepare human-readable phrases or sentences for the patient report from a bank of words and/or phrases related to biometric information and arrhythmia events (and, in some cases, symptom events, as discussed in further detail below). The remote server 102 may analyze the contextual biometric information for an arrhythmia event (or symptom event) to determine features to present to a user. For example, the remote server 102 may determine if the patient was active at the arrhythmia event onset, asleep at the arrhythmia event onset, had a normal respiration rate over the arrhythmia event onset, experienced any concurrent symptoms during the arrhythmia event (e.g., as reported by the patient via a patient-provided symptom input, as discussed in further detail below), and so on. The remote server 102 may then use machine-learning processes to determine which words and/or phrases from the bank best describe the features to present to the user and construct natural language phrases or sentences from those words and/or phrases. These machine-learning processes may employ recurrent neural networks, recursive neural networks, bidirectional recurrent neural networks, and the like. Example processes for constructing the natural language descriptions may be similar to those described in “Connecting images and natural language,” A. Karpathy, Doctoral Dissertation, Stanford University, 2016. For instance, the remote server 102 may encode the features to present to the user as vectors. The remote server 102 then matches the vectors to the words and/or phrases in the bank based on scores for similarities between the feature vectors and sentence vectors for the words and/or phrases.
As another illustration of a patient report,
As shown in
The cardiac monitoring device 100 also receives a patient-provided symptom input at step 506. The symptom input is provided by the patient and indicates that the patient is experiencing a symptom that is suspected to be cardiac-related. For example, the cardiac-related symptom may include light-headedness, a racing heart, fatigue, fainting, a fall, chest discomfort, a skipped heartbeat, a shortness of breath, and/or the like.
In some embodiments, the patient may provide the symptom input via the portable gateway 106 of the cardiac monitoring device 100. For example, the portable gateway 106 may include a visual display and a processor for the gateway in communication with the visual display. As such, the portable gateway 106 may be configured to display, on the visual display, a screen that includes a list of potential cardiac-related symptoms to the patient, such as the aforementioned list of example cardiac-related symptoms. The portable gateway 106 may be further configured to receive a selection by the patient of one or more of the displayed potential cardiac-related symptoms. For instance, the visual display may include a touchscreen, where the patient interacts with the touchscreen to select the cardiac-related symptom(s) that the patient is experiencing. As another example, the patient may use an input device of the portable gateway, such as arrow buttons or a tracking pad, to select the cardiac-related symptom(s) that the patient is experiencing. The portable gateway 106 thus records the selected cardiac-related symptom(s) and the time the patient submitted the cardiac-related symptom(s).
To illustrate,
In response to the patient selecting the “Record Event” button 604, the portable gateway 106 may display a symptom screen 606, an example of which is shown in
In response to the patient selecting the “Next” button 612, the portable gateway 106 may display an activity screen 614, an example of which is shown in
In implementations, the example screens described above may be displayed on a user interface disposed on the cardiac sensor, e.g., on a housing of the sensor unit 110. The patient may provide the symptom input via the sensor unit 110 of the cardiac monitoring device. For example, the front of the sensor unit 110 (e.g., the face of the sensor unit 110 facing away from the patient when the sensor unit 110 is being worn by the patient) may be configured to receive a patient input. As an illustration, the front of the sensor unit 110 may include a button the patient can tap, or the sensor unit 110 may sense changes in electrical charge on the front surface by the patient tapping on the front surface. The patient can then provide a symptom input to the sensor unit 110 via the front face of the sensor unit 110. An example process for providing a symptom input to the sensor unit 110 may include (1) the patient remaining still, (2) double tapping the front face of the sensor unit 110 with the palm of the patient's hand, and (3) waiting for a beeping sound from the sensor unit 110, which indicates that the symptom input has been recorded. If the beeping sound does not occur, the patient may need to re-tap the sensor unit 110 to record the symptom input.
In some embodiments, the cardiac monitoring device 100 may include a portable gateway 106 configured to receive the symptom input, as well as a sensor unit 110 configured to receive the symptom input. In such embodiments, the patient may be able to provide the symptom input to the cardiac monitoring device 100 via either the portable gateway 106 or the sensor unit 110. For example, in one cardiac monitoring device 100, both the portable gateway 106 and the sensor unit 110 may be configured to receive the symptom input. However, the patient may be encouraged to use the portable gateway 106 to record the symptom input (e.g., because the patient can input more information about the suspected cardiac-related symptom, such as the type of symptom it is and the activity level of the patient when the symptom occurred).
Additionally, in some implementations, the cardiac monitoring device 100 may be configured to receive additional inputs from the patient. For instance, the cardiac monitoring device 100 may be configured to receive a second input from the patient once the patient has stopped experiencing the suspected cardiac-related symptom.
Returning to the sample process 500 shown in
The remote server 102 stores the ECG signals, motion signals, and symptom input at step 510. For example, the remote server 102 may include one or more databases and store the ECG signals, motion signals, and symptom input in a database of the remote server 102.
The remote server 102 determines the symptom contextual time period at step 512. In various embodiments, the remote server 102 determines the arrhythmia contextual time period similarly to the processes discussed above with respect to step 212 and with reference to
The remote server 102 also determines contextual biometric information for the symptom contextual time period at step 514. Finally, the remote server 102 displays a symptom report for the symptom event at step 516. In various embodiments, the remote server 102 determines the contextual biometric information for the symptom input similarly to the processes discussed above with respect to step 212 and with reference to
As shown in
The cardiac monitoring device 100 determines biometric information for the patient at step 708. As such, the cardiac sensor 104 and/or the portable gateway 106 may determine the biometric information for the patient similarly to the processes described above with reference to step 214 of
The cardiac monitoring device 100 then transmits the biometric information, the symptom input, and at least the ECG signals corresponding to the symptom input to the remote server 102 at step 710. The ECG signals corresponding to the symptom input may be, for example, ECG signals including a certain period of time before and/or after the symptom input. In some embodiments, the portable gateway 106 transmits the biometric information, the ECG signals, and the biometric information to the remote server 102, as described above with reference to step 206 of
The remote server 102 stores the biometric information, symptom input, and ECG signals corresponding to the symptom input (as well as any other information and/or signals received from the cardiac monitoring device 100) at step 712. For example, the remote server 102 may include one or more databases and store the biometric information, symptom input, and ECG signals corresponding to the symptom input in a database of the remote server 102.
The remote server 102 determines the symptom contextual time period in step 714. In various embodiments, the remote server 102 determines the symptom contextual time period according to the processes discussed above with respect to step 512 and with reference to
In some embodiments, the cardiac monitoring device 100 and the remote server 102 may implement a process flow that is a combination of the sample processes 500 and 700. For example, the cardiac monitoring device 100 may determine a first portion of biometric information for the patient. The cardiac monitoring device 100 may then transmit the symptom input, the ECG signals corresponding to the symptom input, the first portion of biometric information, and motion signals corresponding to a second portion of biometric information to the remote server 102. Subsequently, the remote server 102 may determine the second portion of the biometric information from the received motion signals. Alternatively, the remote server 102 may process the first portion of biometric information to identify the second portion of the biometric information. As an illustration, the cardiac monitoring device 100 may transmit patient heart rate information, patient posture information, patient activity level information, and patient respiration information to the remote server 102. The remote server 102 may then use the patient heart rate information and the patient activity level information to determine heart rate recovery information for the patient. The remote server 102 may further user the patient posture information, patient activity level information, and patient respiration information to determine sleep status information for the patient.
The symptom report 800 further includes a biometric graphical representation 808 for a patient-provided symptom input. In the example shown in
Additionally, as shown in
In addition to the biometric graphical representation 808, the symptom report 800 includes a symptom graphical indicator 812 that corresponds to the patient-provided symptom input. Similar to the arrhythmia onset graphical indicator 414 of the example arrhythmia event report 400, the symptom graphical indicator 812 is overlaid on the biometric graphical representation 808. As an illustration, in the example of
Similar to the arrhythmia event report 400 shown in
In some embodiments, the symptom report 800 may include additional or alternative information, layouts, formats, and/or graphical representations. For example, in some representations, the remote server 102 may additionally determine a biometric summary for the symptom input. The biometric summary may include various summary metric for biometric information that corresponds to the symptom input, such as an average, a median, a minimum, or a maximum of a biometric parameter of the patient over a time interval corresponding to the symptom input. This time interval may be a default time interval (e.g., two hours following the symptom input, four hours centered around the symptom input), or the time interval may be a user-specified time interval (e.g., set by a technician reviewing the symptom report 800). In some cases, the time interval may also depend on the types of symptoms reported by the patient. For instance, the time interval may be longer for patient-reported fatigue than for patient-reported shortness of breath. Similar to the biometric summary discussed with reference to the arrhythmia event report 400 of
In some implementations, the remote server 102 may be configured to prepare the symptom report 800 to display the biometric status of the patient at the time of the patient-provided symptom input. For example, the remote server 102 may determine, for a given symptom input, what the patient's respiration rate was at the time of the symptom input, what the patient's respiration rate was a certain amount of time before the symptom input (e.g., an hour before the symptom input), what the patient's respiration rate was a certain amount of time after the symptom input, and so on. In some cases, these determinations may be made at least partially based on feedback or input from a technician via a technician interface 114. The remote server 102 may accordingly prepare the symptom report 800 to display the symptom input, along with the biometric status of the patient, such as in a graphical representation described above and/or in a human-readable sentence that summarizes the biometric status of the patient for the arrhythmia event. As noted above, for example, such sentences may state: “Patient-triggered event: Normal Sinus Rhythm with PAC occurred during activity. Min HR 77 bpm, Max HR 134 bpm, Avg HR 92 bpm, Average respiration rate was >20 breaths/min, Body position was upright.”
As shown in
The remote server 102 stores the ECG signals, the motion signals, and patient-provided symptom inputs at step 908. For example, the remote server 102 may include one or more databases and store the ECG signals, motion signals, and symptom inputs in a database of the remote server 102. In some implementations, the symptom inputs are patient-provided, such as patient-provided to the cardiac monitoring device 100 as described above with reference to step 506 of
The remote server 102 determines arrhythmia events for a predetermined use period from the ECG signals at step 910. In various embodiments, the remote server 102 may determine arrhythmia events using processes similar to the processes described above with reference to step 210 of
In some implementations, the predetermined use period may be a default use period for the cardiac monitoring device 100. For example, the predetermined use period may be 24 hours, 48 hours, 72 hours, a week, two weeks, 30 days, a month, the entire duration that the patient is wearing the cardiac monitoring device 100, and/or the like. In some implementations, the predetermined use period may be user-specified, such as by a technician via a technician interface 114 or a caregiver via a caregiver interface 116. For instance, a technician may specify the predetermined use period by selecting a default use period (e.g., from a list displayed to the technician). Alternatively, the technician may enter in a custom use period, such as a custom use period not included in the list of default use periods.
The remote server 102 also determines a biometric context summary for the predetermined use period at step 912. An example process flow for step 912 of determining the biometric context summary for the predetermined use period is shown in
Once biometric information for the patient is determined, the remote server 102 may determine a biometric context summary from the biometric information at step 926. Accordingly, the remote server 102 may isolate the biometric information that corresponds to the predetermined use period. In some cases, the remote server 102 may isolate biometric information corresponding to the predetermined use period for all biometric parameters determined for the patient. In other cases, the remote server 102 may isolate biometric information corresponding to the predetermined use period for a subset of biometric parameters determined for the patient, such as for biometric parameters specified by a technician via a technician interface 114 or a caregiver via a caregiver interface 116.
The remote server 102 uses the isolated biometric information to determine a biometric context summary for the predetermined use period. In some implementations, the remote server 102 may determine various summary metrics for the isolated biometric information, such as an average, a median, a minimum, or a maximum of a biometric parameter of the patient over the predetermined use period. For example, the remote server 102 may determine an average, minimum, and maximum hours per day that the patient was active over the predetermined use period. As another example, the remote server 102 may determine an average, minimum, and maximum hours of sleep the patient received per day of the predetermined use period. As another example, the remote server 102 may determine a maximum and a minimum respiration rate of the patient over the predetermined use period. In some cases, the remote server 102 may determine summary metrics for biometric parameters that overlapped. For instance, the remote server 102 may determine a median respiration rate for time periods when the patient was awake and a median respiration rate for time periods when the patient was asleep.
In some implementations, the remote server 102 may determine a value for a biometric parameter for the patient for a certain time period within the predetermined use period. The certain time period may be an hour, a day, a week, and so on. For example, the remote server 102 may determine how many hours per day and/or hours per week the patient was active over the predetermined use period. As another example, the remote server 102 may determine how many hours per day and/or hours per week the patient slept over the predetermined use period.
In some implementations, the remote server 102 may determine trends for the isolated biometric information over the predetermined use period. For instance, the remote server 102 may determine whether the amount of time the patient was active per day increased, decreased, or stayed the same over the predetermined use period. As another example, the remote server 102 may determine whether the amount of time the patient slept per day increased, decreased, or stayed the same over the predetermined use period.
In some implementations, the remote server 102 may determine whether arrhythmia events and/or symptom events (e.g., times when a patient provided an input indicating they were experiencing a potential cardiac-related symptom) occurred while the patient had a certain biometric status. As an illustration, the remote server 102 may determine whether a given arrhythmia event or symptom event occurred while the patient was active, while the patient was asleep, and so on. Additionally, in some implementations, the remote server 102 may determine a burden of arrhythmia events and/or symptom events while the patient had a certain biometric status. For example, the remote server 102 may determine a proportion of arrhythmia events that occurred while the patient was asleep and a percentage of symptom events that occurred while the patient was asleep. As another example, the remote server 102 may determine a percentage of arrhythmia events that occurred while the patient was active and a percentage of symptom events that occurred while the patient was active.
In some implementations, the remote server 102 may identify each type of arrhythmia event that occurred in the patient (e.g., from the determination of the arrhythmia events made at step 910 of
In some implementations, the remote server 102 may determine a biometric summary for each arrhythmia event and/or symptom input that occurred in the patient. The remote server 102 may determine these biometric summaries as discussed above with reference to the arrhythmia event report 400 shown in
Returning to the sample process 900 shown in
Additionally, the remote server 102 presents information about the biometric context summary at step 932. For example, the information about the biometric context summary may include summary metrics for the predetermined use period (e.g., an average hours per day the patient slept, an average hours per day the patient was active, etc.). As another example, the information about the biometric context summary may include biometric information for the patient shown over the predetermined use period (e.g., a plot of the number of hours per day the patient slept). As another example, the information about the biometric context summary may include trends in the biometric information over the predetermined use period (e.g., an indicating showing that the patient's activity decreased over the predetermined use period).
Further, the remote server 102 is configured to present the information about each of the arrhythmia events and/or symptom inputs in a predetermined relationship to the information about the biometric context summary. In some implementations, the predetermined relationship may include presenting the information about each of the arrhythmia events and/or symptom inputs on a first axis and the information about the biometric context summary on a second axis. As an example, the remote server 102 may plot the hours that the patient was active against a graphical timeline of the predetermined use period. On the same chart, the remote server 102 may plot a timing of each arrhythmia event and/or symptom event against the graphical timeline. For instance, the remote server 102 may plot an indication for each day that a type of arrhythmia event occurred. The remote server 102 may also plot an indication for each day that a symptom event occurred, or an indication for each day that a type of symptom event occurred. As another example, the remote server 102 may plot a proportion of arrhythmia events and/or symptom events that occurred while the patient had a certain biometric status, such as a percentage of arrhythmia events and/or symptom events that occurred while the patient was asleep versus while the patient was awake. As another example, the remote server 102 may plot a proportion of types of arrhythmia events and/or symptom events that occurred while the patient had a certain biometric status.
In some implementations, the predetermined relationship may be a human-readable sentence or a human-readable phrase that includes the information about each of the arrhythmia events and/or symptom input and the information about the biometric context summary. As an illustration, the remote server 102 may present a written summary indicating the average number of hours the patient was active per day, the minimum number of hours the patient was active per day, the number of arrhythmia events detected while the patient was active, and the number of symptom events reported while the patient was active. The written summary may further include the type of arrhythmia events that occurred while the patient was active, the type of symptom events (e.g., which symptoms the patient reported) while the patient was active, the percentage of the arrhythmia events that occurred while the patient was active to the total number of arrhythmia events that occurred over the predetermined use period, and so on.
In an example, the remote server 102 executes computer-readable instructions or code that accepts an input of “patientID” corresponding to an ID number for the patient for whom the remote server 102 is preparing a use-period report for a predetermined use period. The output is various statistics and figures for heart rate, respiration rate, activity, and posture, as well as their relationship with events over the use period. As such, example pseudocode for preparing a use-period report for a patient may be as follows:
As shown in
The cardiac monitoring device 100 determines arrhythmia events occurring over a predetermined use period at step 1006. For example, the cardiac sensor 104 and/or the portable gateway 106 may determine the arrhythmia events from the ECG signals similarly to the processes described above with reference to step 910 of
The cardiac monitoring device 100 then transmits the arrhythmia events, at least the ECG signals corresponding to the arrhythmia events, and the biometric information to the remote server 102 at step 1010. In some embodiments, the portable gateway 106 transmits the arrhythmia events, at least the ECG signals corresponding to the arrhythmia events, and the biometric information to the remote server 102, as described above with reference to step 206 of
The remote server 102 stores the arrhythmia events, the ECG signals corresponding to the arrhythmia events, the biometric information, and symptom inputs (as well as any other information and/or signals received from the cardiac monitoring device 100) at step 1012. For example, the remote server 102 may include one or more databases and store the arrhythmia events, the ECG signals corresponding to the arrhythmia events, the biometric information, and symptom inputs in a database of the remote server 102. In various embodiments, the symptom inputs may be patient-provided or provided, for example, by a caregiver of the patient as described above with reference to step 908 of
The remote server 102 determines the biometric context summary for the predetermined use period at step 1014. The remote server 102 further presents summary views of the arrhythmia events and/or symptom inputs at step 1016. In various embodiments, the remote server 102 determines the biometric context summary and presents the summary views according to the processes described above with respect to steps 912 and 914 of
In some embodiments, the cardiac monitoring device 100 and the remote server 102 may implement a process flow that is a combination of the sample processes 900 and 1000. For example, the cardiac monitoring device may determine arrhythmia events that occurred over the predetermined use period and a first portion of biometric information for the patient. The cardiac monitoring device 100 may then transmit the arrhythmia events, the ECG signals corresponding to the arrhythmia events, the first portion of biometric information, and motion signals corresponding to a second portion of biometric information to the remote server 102. Subsequently, the remote server 102 may determine the second portion of the biometric information from the received motion signals. Alternatively, the remote server 102 may process the first portion of biometric information to identify the second portion of the biometric information. As an illustration, the cardiac monitoring device 100 may transmit patient heart rate information, patient posture information, patient activity level information, and patient respiration information to the remote server 102. The remote server 102 may then use the patient heart rate information and the patient activity level information to determine heart rate recovery information for the patient. The remote server 102 may further user the patient posture information, patient activity level information, and patient respiration information to determine sleep status information for the patient.
The use-period report 1100 further includes a first summary section 1106. The first summary section 1106 presents human-readable phrases that present information about the arrhythmia events and/or symptom inputs, as well as biometric context summary information, occurring over the predetermined use period. As an illustration, in the example of
Underneath the first summary section 1106, the use-period report 1100 includes a second summary section 1108. The second summary section 1108 presents charts that present information about the arrhythmia events and/or symptom inputs, as well as biometric context summary information, occurring over the predetermined use period. In the example of
Looking next to
Looking next to
The use-period report 1100 in some examples may include additional or different information. For example, the use-period report 1100 may include activity and sleep durations for each day of cardiac monitoring device 100 wear along with arrhythmic events and patient-reported symptoms, daytime and nocturnal median heart rate and respiration trends, and respiration rates at the onsets of arrhythmias and patient-reported symptoms. As another example, the use-period report 1100 may include summary statistics for upright activity duration, sleep duration, heart rate, and respiration for the use period; the summary of the arrhythmia and symptom onsets experienced by the patient during the use period; the median heart rate trend data during the day (e.g., shown as “daytime”) and during the night (e.g., shown as “nocturnal”); duration of upright activity and sleep for each of the monitored days along with any arrhythmia or symptom onsets experienced by the patient during each day of the use period; median respiration rate trends during the day and during the night; graphical representations of the median respiration rates during the onset of the subject-reported symptoms and during arrhythmia onsets; and a “Technician Summary” section that provides a concise review of the percent of the time arrhythmias or symptoms occurred during upright activity and sleep. These data may provide insights to clinicians regarding health status of the patient during the monitoring over a period of time.
Similar to the arrhythmia event report 400 and symptom report 800, in some implementations, the use-period report 1100 may be shown to a user as illustrated in
In some cases, each arrhythmia and/or symptom event in the event summary 1120 may be selectable. For instance, upon selecting an arrhythmia event or symptom event, the user may be redirected to a screen showing ECG information for the event and/or biometric information for the event (e.g., an activity level summary, posture level summary, respiration rate summary, sleep status, etc.). Alternatively, the user may be shown a pop-up screen overlaid on the event summary 1120 displaying the ECG information and/or biometric information for the event.
As an example, the cardiac monitoring device 100 was used in a study where the cardiac monitoring device 100 and the remote server 102 recorded heart rhythm, heart rate, subject-reported symptoms, and multiple parameters that include respiration rate, activity, and body posture (e.g., biometric data). The study was carried out to determine whether systems, devices, and methods as described herein provide clinicians with better insights into the context of detected arrhythmias, subject-reported symptoms, and/or wellness status. Subjects were prescribed to wear a cardiac monitoring device 100 as described herein for a maximum of thirty days. If there was an arrhythmic event or a subject-reported symptom event, investigators (e.g., the prescribing clinicians) received an event report describing the event along with the biometric information around the timeframe of these events. Investigators reviewed the ECG data first and answered a questionnaire on whether they found the ECG rhythm or symptom information useful. Then they reviewed the biometrics trend data to answer a questionnaire to document whether the biometric data were useful in assisting or changing their ECG- or symptom-based diagnosis and recommending modification(s) to the subject's treatment plan, including changes to medication, a follow-up plan, and/or lifestyle. At the end of the device 100 use, investigations received an end-of-use report (e.g., a use period report) that contained an assessment of the subject's wellness in addition to the heart rhythm and biometric information summary. Investigators answered addition questionnaires to understand how they used wellness information provided in the end-of-use report.
The patient/subject selection consisted of adult patients 21 years or older with an indication for mobile cardiac telemetry (MCT) monitoring for the detection of non-lethal cardiac arrhythmias. Patients were excluded if they had an implantable cardiac device, wearable cardioverter defibrillator, Holter monitor, wearable event recorder, and/or another MCT device at the same time. Other exclusion criteria were a skin condition preventing the patient from wearing the device 100, being hospitalized at the time of screening, being non-ambulatory, being pregnant, or participating in another study. All subjects provided informed consent, and the protocol was approved by a central or local Institutional Review Board.
The primary endpoint for the study was the demonstrated clinical utility provided by adding biometric information to the ECG-only and/or symptom-only assessment. Clinical utility of biometric data was determined by analyzing the clinicians' responses to the questionnaire based on the event reports. These questionnaires captured how useful the clinicians found the biometric data in assisting or changing their ECG-alone or patient-reported symptom-alone based action plan, and in recommending modifications to the subject's treatment plan, including changes to medication, a follow-up plan, and/or lifestyle.
The secondary endpoint for the study was the overall usefulness of longitudinal wellness reporting, e.g., wellness reporting over a period of time, for better patient management decisions. The usefulness of the longitudinal biometrics data was determined by analyzing the physicians' responses to the questionnaire based on the end-of-use report, which contained the wellness information (e.g., biometric information for the use period). The answers to these questionnaires determined whether physicians utilized the longitudinal biometrics data to better understand the circumstances associated with the reported arrhythmia(s), symptom(s), or when neither arrhythmia(s) or symptom(s) were reported. In addition, these answers were utilized to determine the recommendations or changes to the subject's care plan based on the longitudinal biometrics data.
With respect to data analysis, event-, subject-, and physician-level analyses were performed. Demographic, clinical, follow-up, and biometric data were presented as means±standard deviation (SD) for skewed distributions as median and interquartile range (IQR). Arrhythmias of interest that were analyzed during this study included ectopic beats consisting of premature atrial and premature ventricular contractions, atrial fibrillation, supra-ventricular tachycardia, intra-ventricular conduction disorders, ventricular tachycardia, pause, and 2nd/3rd degree atrioventricular blocks. Odds ratios were used to quantify the strength of the associations between the various arrhythmias of interest and the activity biometrics. Pairwise t-test with Holm-Bonferroni correction was used to compare heart rate and respiration rate between the various arrhythmias of interest. Identical analyses were performed for determining the associations between subject-reported symptoms and biometrics data. Physician responses to the event report and end-of-use report questionnaires were reported at an event-, subject-, and physician level. Changes to the subject's treatment plan (medication, follow-up plan, and/or subject's lifestyle), when an arrhythmic event or subject-reported symptom was reported, based on the biometrics data were analyzed for each of the biometrics (activity, body position, sleep, and respiration rate). All analyses were conducted using RStudio version 1.2.1335 (RStudio Inc, Boston, Mass.). P<0.05 was considered significant.
Five hundred eighty-three patients were enrolled by twenty-seven physicians from eighteen U.S. cardiology practices. Information for these patients is shown below in Table 1. The mean age of these subjects was 63±16 years, and 43% were male. The most common reason for device 100 prescription was palpitations (40%) followed by atrial fibrillation (21%). Based on the prescriptions, the median length of need was 30 days (IQR=14-30 days). Five hundred thirty-seven (92%) of the subjects wore the device 100 for longer than one day. For these 537 subjects, the median number of days they used the device 100 was 21 days (IQR=12-30 days), and the median average wear time per day was 21.5 hours (IQR=19-23 hours). Of the 537 subjects who wore the device for longer than one day, end-of-use reports were published for 535 subjects. Insufficient trend information prevented the creation of end-of-use reports for the remaining two subjects.
A total of 5,831 event reports were generated for the 535 subjects who wore the device 100 for more than one day. Arrhythmias of interest were detected in 365 (68%) subjects. Ectopic beats were detected in 53% of the subjects; atrial fibrillation, supra-ventricular tachycardia (SVT), and intra-ventricular conduction disorders (IVCD) were detected in 15%, 13%, and 11% of the subjects, respectively; and ventricular tachycardia (VT), pause, and 2nd/3rd degree atrioventricular blocks (AVB) were detected in 3%, 2.6%, and 1.9% of the subjects, respectively. Overall, 313 (59%) subjects reported at least one symptom. The commonly reported symptoms were heart racing (25%), light headedness (22%), shortness of breath (21%), fatigue (19%), skipped beat (18%), and chest discomfort (14%). Two percent of the patients reported to have fainted or fallen during the study.
Twenty-six physicians completed 2,685 event report questionnaires from 508 subjects. When presented with just the initial ECG and associated symptoms, physicians labelled 17% of the events as occurring while subjects were active, 5% of the events as occurring while the subjects were sleeping, and 3% of the events as occurring while the subjects were tachypneic. In contrast, when physicians reviewed the ECG along with the biometrics data, they were able to assess that 70% (P<0.001) of the events occurred while the subjects were active, 55% (P<0.001) of the events occurred while sleeping, and for 39% (P<0.001) of the events, the subjects were tachypneic.
An example event report is shown in
Overall, with the assistance of the biometric data in addition to ECG data, 96% of the physicians changed an individual subject's treatment plan, including changes to medication, a follow-up plan, and/or subject's lifestyle. In combination, treatment plans were changed for a total of 64% of the subjects. Specifically, the biometric data assisted physicians in making changes to medication and follow-up plan in 17% of the subjects. When determining which biometric data physicians found useful in recommended lifestyle changes, activity was the most useful in 62% of subjects, respectively. From physician reporting, the change recommendations included activity/exercise, explanation of relationship of events to activity levels and body position, changing sleep position, changing sleep pattern, stress reduction, reduction of caffeine intake, and subject reassurance.
The analysis, at the event level, on how physicians utilized the biometrics data to change treatment plans is shown in Table 2 below. For example for VT events, the treatment plan (medication, follow-up plan, and/or lifestyle) was changed compared to ECG alone in 90% of the events, with activity and body position as the most useful for making changes to the treatment plan. Similarly, when the subject reported fainting or falls, physicians used biometrics data to change the treatment in 88% of the events compared to ECG alone. In these patients, the activity biometrics were deemed to be most helpful (86%).
Longitudinal wellness information for the use period of the device 100 was provided for each of the 535 subjects in the form of an end-of-use summary, as described above. The information contained in the wellness report includes activity and sleep durations for each day along with arrhythmic events and patient-reported symptoms, as well as median heart rate and respiration trends (daytime and nocturnal) and respiration rates at the onsets of arrhythmia or symptoms. For instance, the end-of-use wellness report included a graph showing the median daytime heart rate for each day of the use period and the median nighttime heart rate for each day of the use period, and a graph showing the median daytime respiration rate for each day of the use period and the median nighttime respiration rate for each day of the use period.
Twenty-seven physicians completed end-of-use report questionnaires for 527 subjects. Ninety-six percent of the physicians found the end-of-use wellness information useful to better understand the circumstances associated with the arrhythmia diagnosis or subject-reported symptoms (in 52% of the subjects). With the addition of wellness information, 63% of the physicians changed the treatment plan (e.g., changes to medication, a follow-up plans, and/or subject's lifestyle) for at least one subject. These changes were made for 24% of the total subjects. Specifically, changes in medications and/or a follow-up plan were made in 11% of the subjects, and in 22% of the subjects the wellness summary was used to recommend changes to subject's lifestyle. For the 91 subjects who had no reported arrhythmias or symptoms, physicians reported the wellness report helpful to better understand the patient status in 38 subjects (42%).
An example use-period wellness report is shown in
Overall, this example study found that, when using biometrics data (both from event and end of use reports) compared to ECG alone, 96% of the physicians made changes to the subject's treatment plan. The biometrics-based treatment plan changes involved 63% of all patients (n=535) and included modifications to medications, follow-up plans, and lifestyle in 18%, 19%, and 62% of the subjects, respectively. Furthermore, for the subgroup of subjects with a reported arrhythmia or symptom (n=444), physicians reported that the biometrics data helped better understand the circumstances associated with the event in 69% of these subjects.
The study also found that among the various arrhythmias and symptoms, atrial fibrillation, shortness of breath, and light-headedness showed a significant likelihood of occurring during activity. In contrast, 2nd/3rd AVB, pauses, skipped beats, and heart racing events were more likely to occur when subjects were at rest (inactive and/or asleep). Providing objective physiologic data to clinicians reduces or eliminates the reliance on the subjective patient diaries and provides more in-depth contextual information around provocative factors and patient responses, enhancing the interpretation of both arrhythmic events and symptoms.
Additionally, elevated resting heart rate has been shown to be an independent risk factor for mortality and cardiovascular risk. Furthermore, studies have shown that heart rate reduction is associated with improved outcomes. As such, systems and methods herein facilitate the achievement of rate control that is helpful in not only improving cardiovascular outcomes but also improving quality of life. In examples, new or worsening symptoms during rate control therapy titration can prompt investigation with ambulatory cardiac monitoring. In such cases, providing clinicians with heart rate and biometrics trend data, as described above, before and after the onset of an arrhythmic or symptomatic event could aid the physician in better rate control therapy titration. One finding from the current study related to the onset of atrial fibrillation. The median heart rate of 96 bpm at atrial fibrillation onset was significantly higher than the heart rate at the onset of other arrhythmias. Based on this, physicians used the activity assessment at a higher frequency (91% of the events; Table 2) than other biometrics parameters, when modifying the treatment plan for patients with atrial fibrillation.
While most cardiac monitors are prescribed solely for diagnostic purposes, the ability to review daily biometrics and the availability of trending data allows for a broader range of usefulness. As described above, the wellness trend report, available at the end of the prescription use period, contains daytime and nighttime heart rate trending data. This was useful in assessing the response to medication titration and as a tool to review medication compliance.
Ambulatory daily respiration rates trends and elevated sleeping respiration rates have also been identified as important risk markers for heart failure and sleep apnea. However, no previous study has reported the relationships between arrhythmic or symptomatic events and respiration rate. In this example study, the respiration rates at the onset of SVT and shortness of breath events were significantly higher than the respiration rates of other arrhythmias and other reported symptoms. In contrast, the respiration rates at the onset of pause events were significantly lower than the respiration rates seen at the onset of other arrhythmias. Interestingly, physicians modified the treatment for 76% (Table 2) of pause events when they had respiration rate data available. These results exemplify the fidelity of the biometric data to capture the interactions of the cardiopulmonary system, which then allow physicians to modify their treatment plan accordingly.
Further, in the example study, 91 (17%) out the 535 subjects did not experience an arrhythmia of interest or report any symptoms. Typically, in these subjects the cardiac monitoring would be considered as inconclusive. In this study, however, physicians were able to use the longitudinal wellness information provided in the end of use reports to better understand the patient status. Physicians reported the longitudinal trend data was useful in 38 (42%) of these 91 subjects. Additionally, even in subjects with arrhythmic or symptomatic events, these longitudinal wellness data provided insights into patient's overall wellness and health status by reporting total daily activity time and sleep durations. In many cases these longitudinal biometric data were harbingers of other cardiovascular risk and comorbidities. For example, as seen in
In some implementations, a biometric context report may be formatted or formulated differently from the examples and embodiments provided above. As an example, arrhythmia information may be disassociated from biometric context information (e.g., with the ECG showing an arrhythmia provided on one page and biometric context information, such as 24-hour trends or nighttime biometric information, provided on a second page). As another example, a report may allow for further interactivity with a caregiver. For instance, a caregiver may be able to zoom into a portion of a report (e.g., ECG information and/or biometric context information) to see shorter trends, such as daily trends for the patient, and zoom out of the portion of the report to see longer trends, such as weekly or monthly trends. As a further illustration, a caregiver may be able to configure a report to view the same time period from multiple days. As a further illustration, a caregiver may be able to enter a specific time period (e.g., over a certain number of days, over a certain number of weeks, etc.) and a time of day and thereby view ECG information and/or biometric context information for each day of the specific time period and the specified time of day.
As another example, a report may illustrate where a medication change for the patient occurred along with ECG biometric context information for the patient to show whether medication changes are correlated with changes in arrhythmias and/or biometric information. As another example, a report may include trends of ECG information and/or arrhythmia information along with trends of other biometric context information, such as trends of posture, activity level, respiration rate, and/or sleep status over the same period of time (e.g., whether an arrhythmia occurred in a given week trended with average activity level per day for the given week). As another example, a report may illustrate sleep trends over time (e.g., how many hours of sleep per day the patient has gotten). As another example, a report may include three-dimensional (3D) biometric context information for ECG information and/or arrhythmia information, such as by mapping the ECG information and/or arrhythmia information against time and a type of biometric context information. To illustrate, arrhythmia information over time may be mapped in the same 3D graph against patient activity over time. As another example, a report may display trends from previous weeks (e.g., compressed trends) along with more granular ECG information and/or arrhythmia information and biometric context information for the present day, week, 10-day period, etc. As another example, a report may display ECG information and/or arrhythmia information and biometric context information in a heat map. As another example, a report may group types of biometric context information with ECG information and/or arrhythmia information. For instance, a report may show ECG information or atrial fibrillation episodes when the patient was at a body posture of greater than 90 degrees.
As another example, a report may include longer strips of ECG information (e.g., hour-long ECG strips, two-hour long ECG strips, three-hour long ECG strips, four-hour long ECG strips, five-hour long ECG strips, six-hour long ECG strips, twelve-hour long ECG strips, eighteen-hour long ECG strips, twenty-four-hour long ECG strips, etc.) with a running trend (e.g., from the past 3 days, past 5 days, past week, past two weeks, past month, etc.) above or underneath the strips of ECG information. As another example, a report may include longer strips of ECG information with markers that indicate changes in trends of the patient's biometric context information. To illustrate, a report may show when a patient's activity level rises above or falls below a predetermined level or changes by a predetermined percentage, rises above or falls below a predetermined level of average sleep per night or changes by a predetermined percentage, when a patient's wear time rises above or falls below a predetermined level or changes by a predetermined percentage, etc. As another illustration, a report may note changes in an ECG strip that correspond with a change in one or more biometric context information trends.
As another example, a report may include a wellness “score” that summarizes the arrhythmia information and biometric context information in the report. For instance, a wellness score may be based on a combination of sinus rhythm over the report period, average level of patient activity over the report period, and whether the patient was at or above a predetermined average sleep level over the report period. As another example, a report may include an arrhythmia risk score for the patient, for example, based on the trends of the biometric context information (e.g., decreasing heart rate variability). For instance, machine learning may be used to determine whether, based on various inputs such as the types of biometric context information, a predicted risk (e.g., from 0 to 100) of the patient developing an arrhythmia. As another example, a report may include a heart failure prediction (e.g., based on R-R intervals, based on heart rate, etc.) using, for instance, machine learning similar to how an arrhythmia risk score may be generated. As another example, a report may include suggested next steps to improve the patient's health (e.g., a pacemaker, increased physical activity, increased sleep, a medication change, etc.).
As another example, a report may include wear time for the cardiac monitoring device 104 over the biometric context time period and/or over a use period (e.g., determined from whether the cardiac monitoring device 104 is on, from whether the electrodes are sensing an ECG from the patient, from impedance sensors configured to transmit a fall-off signal into the patient, etc.). For instance, a report may include wear time overlaid with sleep status and activity level graphs. As another example, a report may include heart rate variability alone, overlaid with other biometric context information, overlaid with arrhythmic data, linked to an autonomic nervous system disorder, recurrence plots for heart rate variability to visualize patterns, etc.
As another example, a report may be configured to be presented to a patient. For instance, a report may include more streamlined information such that it is easier for a patient to parse through the information, such as by including more trends and less day-to-day information and/or including a shortened summary of the information in the report at the beginning of the report with less detailed patient information. As another illustration, a patient report may include a patient's recommendations for improving the patient's health. As another illustration, the patient may be provided with a patient report along with notifications, such as a notification to increase an activity level or increase the amount of time the patient sleeps if the patient trends below a predetermined level. Notifications may be sent, for example, to the patient via email, as a text or SMS message, as a phone call, etc. As another illustration, the patient report may include a wellness score, as described above.
Returning to the cardiac monitoring device 100, in some implementations, the cardiac monitoring device 100 may include a cardiac sensor 104 that further includes an adhesive patch 108 and a sensor unit 110.
In some embodiments, the patch 108 may include additional components that facilitate or aid with the monitoring and/or recording or acquiring of physiological data by the sensor unit 110. For example, as discussed above, the patch 108 may include conductive elements such as one or more ECG electrodes 112 (e.g., a single lead, two leads, etc.) that can be used when recording ECG signals from the surface (e.g., skin contacted directly or through a covering) of a patient's body. The electrodes 112 may be coupled to the sensor unit 110 by dedicated wiring within the patch. In some embodiments, the ECG may have a sampling rate in then range from about 250 Hz to about 500 Hz, from about 300 Hz to about 450 Hz, from about 350 Hz to about 400 Hz, including values and subranges therebetween. In some embodiments, the ECG signal may be sampled after band-pass filtering by a 12 bit ADC. During normal operation, data may be transferred to the server “as-is” and can then be used by the remote server 102 for analysis. In some embodiments, an internal process allows for real-time evaluation of the ECG signal quality upon each attachment of the device to the patient (“attachment test”). Alternatively, as discussed above, in some embodiments, an internal process allows for processing of the ECG signals, such as by determining arrhythmia events that have occurred or are occurring in the patient based on the ECG signals.
Examples of locations on surface of a patient body at which a patch may be placed are shown in
With reference to
In some embodiments,
In some embodiments, the sensor unit 110 may also include input interfaces such as buttons for interfacing with a user. For example, the sensor may include a button 1330 that allows a patient or a health care professional to activate or deactivate the sensor unit 110. Such input interfaces may be configured to avoid or at least minimize unintended interactions with a user. For example, a button may be sized and shaped to avoid accidental activation (e.g., the button may be configured to require activation by being pushed in with an external object). This button may be used to reset the sensor as well as pair the sensor to the gateway device and initiate communication. As another example, an input interface of the sensor unit 110 may include a touchscreen configured to receive input from a user and/or provide information back to the user. In some embodiments, the input may allow the user to set the sensor in an “airplane mode,” for example by deactivating any wireless communication (e.g., Wi-Fi, Bluetooth®, etc.) with external devices and/or servers. For example, the button can be implemented as a magnetic switch, e.g., an embedded magnetic switch, instead of a physical button. Such an implementation can be useful for designing the housing of the device and avoid exposing button components to the environment.
In some embodiments, as described above, the disclosed cardiac sensor 104 is configured to monitor and/or acquire data on physiological parameters including but not limited to ECG, heart rate, respiration rate, physical activity, posture, thoracic impedance, and/or the like. To that effect, the sensor unit 110 and/or the patch 108 housing the sensor unit 110 may include components that facilitate or undertake the monitoring and/or recording of at least some of these parameters. For example, as noted above, the patch 108 housing the sensor unit 110 may include ECG electrodes 112 coupled to the sensor unit 110 to facilitate the monitoring and/or acquiring of ECG data. As shown in
With reference to
Internally, in some embodiments, the sensor unit 110 may include a microprocessor 1408 (which may be alternatively referred to as a micro-controller) that includes instructions thereon specifying how measurements (RF, ECG, accelerometer, etc.) are taken and the obtained data are transmitted, how to relay the status of the sensor unit 110, how/when the sensor unit 110 can enter a plurality of sleep levels, and/or the like. In some embodiments, the instructions may also specify the conditions for performing certain types of measurements. For example, the instructions may specify that an accelerometer of the sensor unit 110 may not commence measurements (e.g., for physical activity, patient posture, respiration rate, etc.) unless the user of the sensor unit 110 is at rest or maintaining a certain posture. As another example, the instructions may identify the conditions that may have to be fulfilled before ECG measurements can commence, such conditions including at least sufficient attachment level between the sensor and the surface on the body to which the sensor unit 110 is attached. In some embodiments, the microprocessor 1408 may have internal and external non-volatile memory banks that can be used for keeping measurement directory and data, scheduler information, and/or a log of actions and errors. This non-volatile memory allows saving power via a total power-down while retaining data and status information.
As discussed above, in various embodiments, the sensor unit 110 includes one or more motion sensors. In some implementations, the sensor unit 110 may include an accelerometer, and the accelerometer may be used to determine one or more of the physical activity, posture, respiration rate, etc. of a patient wearing the sensor unit 110, as discussed above. For example, a three-axis (3D) accelerometer 1422 may be used to acquire data on patient movements and posture as well as the respiration rate, and a processor (e.g., of the sensor unit 110, the portable gateway 106, and/or the remote server 102) receiving the acquired data may use the data (e.g., in conjunction with data obtained by the sensor such as ECG data) to determine biometric information of the patient. In some embodiments, the accelerometer 1422 may also contain an internal tap detector, which may be used for recording a patient-provided symptom input (e.g., using “double tap” feature). In some implementations, the sensor unit 110 may include more than one accelerometer, such as an accelerometer that measures patient posture and an accelerometer that measures patient respiration and activity. In some implementations, in addition to or in the alternative of the accelerometer 1422, the sensor unit 110 may include gyroscope(s), magnetometer(s), ballistocardiograph(s), and/or the like.
For example, in some implementations, the sensor unit 110 may include an RF module 1432 configured to transmit and receive RF signals via the RF antennas 1404a, 1404b. The RF module 1432 may communicate with a field-programmable gate array (“FPGA”), which may be configured to control a transceiver module, control analog-to-digital signal conversion, output samples, and the like. The RF signals may be processed to determine, for instance, lung fluid levels for the patient.
As discussed,
In some embodiments, the sensor unit 110 may also include other types of sensors, such as a temperature sensor, conductance sensor, a pressure sensor, a respiration sensor, SPO2 sensor, a light sensor, a humidity sensor, an altimeter, an anemometer, an air quality sensor, and/or a GPS sensor. For example, a respiration sensor can include an accelerometer configured to monitor the patient's chest movements, e.g., during certain portions of the day and/or night. For instance, a 3D multi-axis, multi-channel accelerometer can be configured to, on a first channel, monitor for a patient movement and/or posture, and on a second, different channel, monitor the chest movements of the patient to determine respiration rate and other related data. Alternatively, a respiration accelerometer can be provided in the device that is separate from a posture sensing accelerometer. In some examples, the respiration rate measurement can be based on the operation of a tri-axis micro-electromechanical system (MEMS) accelerometer within the device mounted on the patient's torso. The accelerometer can measure projections of the gravity vector on its intrinsic axes. From these measurements, a respiration rate can be derived based on measured quasi-periodic changes of the projections that occur due to respiration movements of the patient's rib cage.
An alternative implementation of the cardiac monitoring device 100 is illustrated in
The individual electrodes 112 may be positioned on the patient in a configuration suited for acquiring ECG signals from the patient. For example, as illustrated in
As illustrated, the charger 107 includes a sensor unit cradle 1600 configured to receive a sensor unit 110 (e.g., the sensor unit 110 shown in
As shown in
Although the subject matter contained herein has been described in detail for the purpose of illustration, such detail is solely for that purpose and that the present disclosure is not limited to the disclosed embodiments, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the present 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.
Other examples are within the scope and spirit of the description and claims. Additionally, certain functions described above can be implemented using software, hardware, firmware, hardwiring, or combinations of any of these. Features implementing functions can also be physically located at various positions, including being distributed such that portions of functions are implemented at different physical locations.
While various inventive embodiments have been described and illustrated herein, those of ordinary skill in the art will readily envision a variety of other means and/or structures for performing the function and/or obtaining the results and/or one or more of the advantages described herein, and each of such variations and/or modifications is deemed to be within the scope of the inventive embodiments described herein. Those skilled in the art will readily appreciate that all parameters, dimensions, materials, and configurations described herein are meant to be an example and that the actual parameters, dimensions, materials, and/or configurations will depend upon the specific application or applications for which the inventive teachings is/are used.
Also, various inventive concepts may be embodied as one or more methods, of which an example has been provided. The acts performed as part of the method may be ordered in any suitable way. Accordingly, embodiments may be constructed in which acts are performed in an order different than illustrated, which may include performing some acts simultaneously, even though shown as sequential acts in illustrative embodiments.
This provisional application claims priority to U.S. Provisional Patent Application Ser. No. 63/199,208, filed on Dec. 14, 2020, titled “CONTEXTUAL BIOMETRIC INFORMATION FOR USE IN CARDIAC HEALTH MONITORING,” and to U.S. Provisional Patent Application Ser. No. 63/262,657, filed on Oct. 18, 2021, titled “CONTEXTUAL BIOMETRIC INFORMATION FOR USE IN CARDIAC HEALTH MONITORING,” the entirety of each of which is hereby incorporated by reference.
| Number | Date | Country | |
|---|---|---|---|
| 63262657 | Oct 2021 | US | |
| 63199208 | Dec 2020 | US |
