Patent Application
20240047072
This disclosure generally relates to systems including medical devices and, more particularly, to monitoring of patient health using such systems.
A variety of devices are configured to monitor physiological signals of a patient. Such devices include implantable or wearable medical devices, as well as a variety of wearable health or fitness tracking devices. The physiological signals sensed by such devices include as examples, electrocardiogram (ECG) signals, respiration signals, perfusion signals, activity and/or posture signals, pressure signals, blood oxygen saturation signals, body composition, and blood glucose or other blood constituent signals. In general, using these signals, such devices facilitate monitoring and evaluating patient health over a number of months or years, outside of a clinic setting.
In some cases, such devices are configured to detect health events, such as episodes of cardiac arrhythmia or worsening of heart failure, based on the physiological signals. Example arrhythmia types include asystole, bradycardia, ventricular tachycardia, supraventricular tachycardia, wide complex tachycardia, atrial fibrillation, atrial flutter, ventricular fibrillation, atrioventricular block, premature ventricular contractions, and premature atrial contractions. The devices may store ECG and other physiological signal data collected during a time period including an episode as episode data. The devices may also store episode data quantifying the episodes, e.g., number and/or duration of episodes. The medical device may also store ECG and other physiological data for a time period as episode data in response to user input, e.g., from the patient or a caregiver.
In general, the disclosure describes techniques for determining a risk level of a health event based on parametric data of a plurality of parameters of a patient including atrial fibrillation (AF) burden. In some examples, the techniques include applying an AF burden pattern feature to a model to determine the risk level. In some examples, the model is trained with training sets of parametric data that are classified based on classification data collected automatically in response to detection of a trigger.
In one example, a system comprises processing circuitry configured to receive parametric data for a plurality of parameters of a patient. The parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices. The plurality of parameters comprises AF burden. The processing circuitry is configured to derive one or more features based on the parametric data for the plurality of parameters, wherein the one or more features comprise at least one AF burden pattern feature, apply the one or more features to a model, and determine a risk level of a health event for the patient based on the application of the one or more features to the model.
In another example, a method comprises receiving parametric data for a plurality of parameters of a patient. The parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices. The plurality of parameters comprises AF burden. The method further comprises deriving one or more features based on the parametric data for the plurality of parameters, wherein the one or more features comprise at least one AF burden pattern feature, applying the one or more features to a model, and determining a risk level of a health event for the patient based on the application of the one or more features to the model.
In another example, a system comprises processing circuitry configured to receive parametric data for a plurality of parameters of a patient. The parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices. The processing circuitry is further configured to determine a training set of parametric data for training a model based on the parametric data of the patient, classify the training set of parametric data based on classification data collected automatically in response to detection of a trigger, and train the model with the classified training set of parametric data.
In another example, a method comprises receiving parametric data for a plurality of parameters of a patient. The parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices. The method further comprises determining a training set of parametric data for training a model based on the parametric data of the patient, classifying the training set of parametric data based on classification data collected automatically in response to detection of a trigger, and training the model with the classified training set of parametric data.
In another example, a system comprises processing circuitry configured to perform any of the methods described herein.
In another example, a non-transitory computer readable storage medium comprises program instructions configured to cause processing circuitry to perform any of the methods described herein.
This summary is intended to provide an overview of the subject matter described in this disclosure. It is not intended to provide an exclusive or exhaustive explanation of the apparatus and methods described in detail within the accompanying drawings and description below. Further details of one or more examples are set forth in the accompanying drawings and the description below.
Like reference characters refer to like elements throughout the figures and description.
A variety of types of implantable and medical devices detect arrhythmia episodes and other health events based on sensed ECGs and, in some cases, other physiological signals. External devices that may be used to non-invasively sense and monitor ECGs and other physiological signals include wearable devices with electrodes configured to contact the skin of the patient, such as patches, watches, or necklaces. Such external devices may facilitate relatively longer-term monitoring of patient health during normal daily activities.
Implantable medical devices (IMDs) also sense and monitor ECGs and other physiological signals, and detect health events such as arrhythmia episodes and worsening heart failure. Example IMDs include pacemakers and implantable cardioverter-defibrillators, which may be coupled to intravascular or extravascular leads, as well as pacemakers with housings configured for implantation within the heart, which may be leadless. Some IMDs do not provide therapy, such as implantable patient monitors. One example of such an IMD is the Reveal LINQ™ Insertable Cardiac Monitor (ICM), available from Medtronic plc, which may be inserted subcutaneously. Such IMDs may facilitate relatively longer-term monitoring of patients during normal daily activities, and may periodically transmit collected data, e.g., episode data for detected arrhythmia episodes, to a remote patient monitoring system, such as the Medtronic Carelink™ Network.
IMD 10 takes the form of the LINQ™ ICM. Although described primarily in the context of examples in which the IMD takes the form of an ICM, the techniques of this disclosure may be implemented in systems including any one or more implantable or external medical devices, including monitors, pacemakers, or defibrillators.
External device 12 is a computing device configured for wireless communication with IMD 10. External device 12 retrieves episode and other physiological data from IMD 10 that was collected and stored by IMD 10. In some examples, external device takes the form of a personal computing device of the patient or caregiver, such as a smartphone.
In the example illustrated by
External device 12 retrieves episode and other physiological data from sensor device 14 that was collected and stored by sensor device 14. External device 12 may include a display and other user interface elements. In some examples, external device 12 presents physiological data retrieved from IMD 10 and/or sensor device 14, and/or statistical representations thereof, to patient 4 or another user. External device 12 may communicate with IMD 10 and/or sensor device 14 according to the Bluetooth® or Bluetooth® Low Energy (BLE) protocols, as examples.
External device 12 may be configured to communicate with a computing system 20 via a network 16. External device 12 may be used to retrieve data from IMD 10 and sensor device 14, and may transmit the data to computing system 20 via network 16. The retrieved data may include values of physiological parameters measured by IMD 10 and sensor device 14, data regarding episodes of arrhythmia or other health events detected by IMD 10 and sensor device 14, and other physiological signals or data recorded by IMD 10 sensor device 14. The data retrieved from IMD 10 and sensor device 14 may include values of various patient parameters, and/or may be used by computing system 20 to determine values of patient parameters. The values of patient parameters may be referred to as patient parametric data. Patient parametric data may be retrieved and or determined on a periodic basis to produce periodic values, e.g., on a daily basis to produce daily values.
Computing system 20 may comprise computing devices configured to allow users, e.g., clinicians treating patient 4 and other patients, to interact with data collected from IMDs 10 and sensor devices 14 of their patients. In some examples, computing system 20 includes one or more handheld computing devices, computer workstations, servers or other networked computing devices. In some examples, computing system 20 may include one or more devices, including processing circuitry and storage devices, that implement a monitoring system 222 (
Network 16 may include one or more computing devices (not shown), such as one or more non-edge switches, routers, hubs, gateways, security devices such as firewalls, intrusion detection, and/or intrusion prevention devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices such as cellular phones or personal digital assistants, wireless access points, bridges, cable modems, application accelerators, or other network devices. Network 16 may include one or more networks administered by service providers, and may thus form part of a large-scale public network infrastructure, e.g., the Internet. Network 16 may provide computing devices, such as computing system 20 and external device 12, access to the Internet, and may provide a communication framework that allows the computing devices to communicate with one another. In some examples, network 16 may be a private network that provides a communication framework that allows computing system 20 and external device 12 to communicate with one another but isolates one or more of these devices or data flows between these device from devices external to network 16 for security purposes. In some examples, the communications between computing system 20 and external device 12 are encrypted.
Computing system 20 may also retrieve data for patient 4 from electronic medical records (EMR) database 22. EMR database 22 may store electronic medical records, also referred to as electronic health records, for patient 4, which may be generated by various health care providers, laboratories, clinicians, insurance companies, etc. Although illustrated as a single database in
As examples, EMR database 22 may store a medication history of the patient, a surgical procedure history of the patient, a hospitalization history of the patient, emergency or urgent care visit history of the patient, scheduled clinic visit history of the patient, one or more lab or other clinical test results for patient 14, a cardiovascular history of patient 14, or co-morbidities of patient 14 such as atrial fibrillation, heart failure, or diabetes, as examples. As further examples, EMR database 22 may store medical images for patient 4, such as x-ray images, ultrasound images, echocardiograms, anatomical imagery, medical photographs, radiographic images, etc. The data stored in EMR database 22 may include the patient specific records for patient 4 and numerous other patients. In some examples, the data stored by EMR database 22 may include broader demographic information or population-type information for a plurality of patients.
Monitoring system 222, e.g., implemented by processing circuitry of computing system 20, may implement the techniques of this disclosure including developing an algorithm based on training sets of parametric data of a population of patients or subjects retrieved from IMDs 10 and external devices 14 of the population, and applying the algorithm to parametric data of an individual patient 4 to predict the occurrence of a clinically significant health event. In some examples, monitoring system trains one or more machine learning (ML) models for prediction of the health event. The output of the ML models for a particular patient may be a level of risk of the health event, a probability of the health event occurring within a certain time, and/or whether the risk or probability satisfies a threshold.
Example health events that may be predicted using the techniques of this disclosure include stroke, clinically significant AF requiring hospitalization or urgent care, and clinically significant episodes of symptomatic events, such as syncope or dizziness. Parametric data that may be useful for predicting such health events may include cardiac rhythm data, such as heart rate data and data related to atrial fibrillation (AF) or other arrhythmia episodes. AF data may include quantifications of AF, referred to as AF burden, as well as patterns of AF burden over a plurality of periods of time. Parametric data that may be useful for predicting such clinically significant health events may additionally or alternatively include patient activity data or any other patient data or signals described herein.
Monitoring system 222 may also utilize data from EMR database 22 and/or data entered by the patient or a caregiver via external device 12 in conjunction with the parametric data from IMD 10 or sensor device 14. In some examples, data from EMR database 22 and/or data entered by the patient or caregiver may be used as inputs to the ML model(s) or other health event prediction algorithms implemented by monitoring system 222. In some examples, data from EMR database 22 and/or data entered by the patient or caregiver via external device 12 may provide classifications for training sets of parametric data from IMD 10 and sensor device 14 used to train one or more ML models to predict a health event. For example, data from EMR database 22 and/or data entered by the patient or caregiver via external device 12 may indicate whether, when, and to what degree of severity patient 4 experienced the clinically significant health event. Such data may be correlated with the parametric data to create a training set of parametric data. After an initial training phase, such training sets may be used for reinforcement learning and, in some cases, personalization of the one or more ML models.
Although the techniques are described herein as being performed by monitoring system 222, and thus by processing circuitry of computing system 20, the techniques may be performed by processing circuitry of any one or more devices or systems of a medical device system, such as computing system 20, external device 12, or IMD 10. The ML models may include, as examples, neural networks, deep learning models, convolutional neural networks, or other types of predictive analytics systems.
Processing circuitry 50 may include fixed function circuitry and/or programmable processing circuitry. Processing circuitry 50 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or analog logic circuitry. In some examples, processing circuitry 50 may include multiple components, such as any combination of one or more microprocessors, one or more controllers, one or more DSPs, one or more ASICs, or one or more FPGAs, as well as other discrete or integrated logic circuitry. The functions attributed to processing circuitry herein may be embodied as software, firmware, hardware or any combination thereof
Sensing circuitry 52 may be selectively coupled to electrodes 16A, 16B via switching circuitry 60 as controlled by processing circuitry 50. Sensing circuitry 52 may monitor signals from electrodes 16A, 16B in order to monitor electrical activity of a heart of patient 4 of
Sensing circuitry 52 and/or processing circuitry 50 may be configured to detect cardiac depolarizations (e.g., P-waves of atrial depolarizations or R-waves of ventricular depolarizations) when the ECG amplitude crosses a sensing threshold. For cardiac depolarization detection, sensing circuitry 52 may include a rectifier, filter, amplifier, comparator, and/or analog-to-digital converter, in some examples. In some examples, sensing circuitry 52 may output an indication to processing circuitry 50 in response to sensing of a cardiac depolarization. In this manner, processing circuitry 50 may receive detected cardiac depolarization indicators corresponding to the occurrence of detected R-waves and/or P-waves. Processing circuitry 50 may use the indications for determining features of the ECG including inter-depolarization intervals, heart rate, and heart rate variability. Sensing circuitry 52 may also provide one or more digitized ECG signals to processing circuitry 50 for analysis, e.g., for use in cardiac rhythm discrimination and/or to identify and delineate features of the ECG, such as QRS amplitudes and/or width, or other morphological features.
In some examples, sensing circuitry 52 measures impedance, e.g., of tissue proximate to IMD 10, via electrodes 16. The measured impedance may vary based on respiration and a degree of perfusion or edema. Processing circuitry 50 may determine parametric data relating to respiration, perfusion, and/or edema based on the measured impedance.
In some examples, IMD 10 includes one or more sensors 58, such as one or more accelerometers, microphones, optical sensors, temperature sensors, and/or pressure sensors. In some examples, sensing circuitry 52 may include one or more filters and amplifiers for filtering and amplifying signals received from one or more of electrodes 16A, 16B and/or other sensors 58. In some examples, sensing circuitry 52 and/or processing circuitry 50 may include a rectifier, filter and/or amplifier, a sense amplifier, comparator, and/or analog-to-digital converter. Processing circuitry 50 may determine parametric data, e.g., values of physiological parameters of patient 4, based on signals from sensors 58, which may be stored in memory 56.
In some examples, processing circuitry 50 transmits, via communication circuitry 54, the parametric and episode data for patient 4 to external device 12 of
Although described herein in the context of example IMD 10, the techniques for cardiac arrhythmia detection disclosed herein may be used with other types of devices. For example, the techniques may be implemented with an extra-cardiac defibrillator coupled to electrodes outside of the cardiovascular system, a transcatheter pacemaker configured for implantation within the heart, such as the Micra™ transcatheter pacing system commercially available from Medtronic PLC of Dublin Ireland, an insertable cardiac monitor, such as the Reveal LINQ™ ICM, also commercially available from Medtronic PLC, a neurostimulator, or a drug delivery device.
As discussed with respect to
One or more of antenna 26, sensors 58, or circuitries 50-56 may be formed on insulative cover 74, such as by using flip-chip technology. Insulative cover 74 may be flipped onto a housing 18. When flipped and placed onto housing 18, the components of IMD 10 formed on the inner side of insulative cover 74 may be positioned in a gap 76 defined by housing 18. Electrodes 16 may be electrically connected to switching circuitry 60 through one or more vias (not shown) formed through insulative cover 74. Insulative cover 74 may be formed of sapphire (i.e., corundum), glass, parylene, and/or any other suitable insulating material. Housing 14 may be formed from titanium or any other suitable material (e.g., a biocompatible material). Electrodes 16 may be formed from any of stainless steel, titanium, platinum, iridium, or alloys thereof. In addition, electrodes 16 may be coated with a material such as titanium nitride or fractal titanium nitride, although other suitable materials and coatings for such electrodes may be used.
Processing circuitry 80, in one example, is configured to implement functionality and/or process instructions for execution within external device 12. For example, processing circuitry 80 may be capable of processing instructions, including applications 90, stored in storage device 82. Examples of processing circuitry 80 may include, any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.
Storage device 82 may be configured to store information within external device 12, including applications 90 and data 100. Storage device 82, in some examples, is described as a computer-readable storage medium. In some examples, storage device 82 includes a temporary memory or a volatile memory. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. Storage device 82, in one example, is used by applications 90 running on external device 12 to temporarily store information during program execution. Storage device 82, in some examples, also includes one or more memories configured for long-term storage of information, e.g. including non-volatile storage elements. Examples of such non- volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable (EEPROM) memories.
External device 12 utilizes communication circuitry 84 to communicate with other devices, such as IMD 10, sensor device 14, and computing system 20 of
External device 12 also includes a user interface 86. User interface 86 may be configured to provide output to a user using tactile, audio, or video stimuli and receive input from a user through tactile, audio, or video feedback. User interface 86 may include, as examples, a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone, or any other type of device for detecting a command from a user, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user. In some examples, a presence-sensitive display includes a touch-sensitive screen.
Example applications 90 executable by processing circuitry 80 of external device 12 include an IMD interface application 92, a sensor device interface application 94, a health monitor application 96, and a location service 98. Execution of IMD interface 92 by processing circuitry 80 configures external device 12 to interface with IMD 10. For example, IMD interface 92 configures external device 12 to communicate with IMD 10 via communication circuitry 84. Processing circuitry 80 may retrieve IMD data 102 from IMD 10, and store IMD data 102 in memory 82. IMD interface 92 also configures user interface 86 for a user to interact with IMD 10 and/or IMD data 102. For example, IMD interface 92 configures external device 12 to communicate with IMD 10 via communication circuitry 84. Processing circuitry 80 may retrieve IMD data 102 from IMD 10, and store IMD data 102 in memory 82. IMD interface 92 also configures user interface 86 for a user to interact with IMD 10 and/or IMD data 102. Similarly, sensor device interface 94 configures external device 12 to communicate with sensor device 14 via communication circuitry 84, retrieve sensor device data 104 from sensor device 14, and store sensor device data 104 in memory 82. Sensor device interface 42 also configures user interface 86 for a user to interact with sensor device 14 and/or sensor device data 104.
Health monitor 96 may be configured facilitate monitoring the health of patient 4 by a user, such as the patient or a caregiver. Health monitor 96 may present health information, such as at least portions of IMD data 102 and/or sensor device data 104, via user interface 86. Health monitor 96 may also collect information regarding the patient's health from the user via user interface 86, and store the information as user recorded health data 106. In some examples, health monitor 96 present the user with a questionnaire or survey seeking health data 106 from the user. Health monitor 96 may present the surveys according to a schedule, in response to IMD data 102 and/or sensor device data 104 indicating that patient 4 experienced a health event, and/or based on a location of patient 4, e.g., in response to location service 98 indicating that patient 4 entered a geofence area defined by geofence data 108. Presenting surveys in response to health events may facilitate timely capture of user recorded health data 106 regarding the health event. In some examples, geofence areas are defined around clinics, hospitals, or the like, and entry into a such geofence area may similarly indicate that patient 4 experienced a health event meriting timely collection of user recorded health data 106. Processing circuitry 80 may also store the times and durations of patient entering a geofence area as geofence data 108.
IMD data 102 and sensor device data 104 may include patient parametric data derived from sensed physiological signals as described herein. As examples, IMD data 102 may include periodic (e.g., daily) values of one or more of: heart rate, heart rate variability, one or more ECG morphological features or intrabeat intervals, AF and/or other arrhythmia burden (e.g., number, time, or percent time per period), respiratory rate, perfusion, and activity levels.
As examples, sensor device data 104 may include one or more of: activity levels, walking/running distance, resting energy, active energy, exercise minutes, quantifications of standing, body mass, body mass index, heart rate, low, high, and/or irregular heart rate events, heart rate variability, walking heart rate, heart beat series, digitized ECG, blood oxygen saturation, blood pressure (systolic and/or diastolic), respiratory rate, maximum volume of oxygen, blood glucose, peripheral perfusion, and sleep patterns.
As examples, user recorded health data 106 may include one or more of: exercise and activity data, sleep data, symptom data, medical history data, quality of life data, nutrition data, medication taking or compliance data, allergy data, demographic data, weight, and height. Symptom data may include times a patient experienced a symptom and their characterizations of the symptoms, such as palpitations, atrial flutter, AF, atrial tachycardia, syncope, or dizziness. Medical history data may relate to history of AF, stroke, chronic obstructive pulmonary disease (COPD), renal dysfunction, or hypertension, history of procedures, such as ablation or cardioversion, and healthcare utilization. Sensor device data 104 and/or user recorded health data 106 may include one or more of the types of data listed in Table 1 below.
In the example of
Processing circuitry 202, in one example, is configured to implement functionality and/or process instructions for execution within computing system 20. For example, processing circuitry 202 may be capable of processing instructions stored in storage device 208. Examples of processing circuitry 202 may include any one or more of a microprocessor, a controller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry.
One or more storage devices 208 may be configured to store information within computing device 20 during operation. Storage device 208, in some examples, is described as a computer-readable storage medium. In some examples, storage device 208 is a temporary memory, meaning that a primary purpose of storage device 208 is not long-term storage. Storage device 408, in some examples, is described as a volatile memory, meaning that storage device 408 does not maintain stored contents when the computer is turned off. Examples of volatile memories include random access memories (RAM), dynamic random access memories (DRAM), static random access memories (SRAM), and other forms of volatile memories known in the art. In some examples, storage device 208 is used by software or applications 220 running on computing system 20 to temporarily store information during program execution.
Storage devices 208 may further be configured for long-term storage of information, such as applications 220 and data 230. In some examples, storage devices 208 include non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard discs, optical discs, floppy discs, flash memories, or forms of electrically programmable memories (EPROM) or electrically erasable and programmable memories (EEPROM).
Computing system 20, in some examples, also includes communication circuitry 206 to communicate with other devices and systems, such as IMD 10 and external device 12 of
Computing system 20, in one example, also includes one or more user interface devices 204. User interface devices 204, in some examples, may be configured to provide output to a user using tactile, audio, or video stimuli and receive input from a user through tactile, audio, or video feedback. User interface devices 204 may include, as examples, a presence-sensitive display, a mouse, a keyboard, a voice responsive system, video camera, microphone, or any other type of device for detecting a command from a user, a sound card, a video graphics adapter card, or any other type of device for converting a signal into an appropriate form understandable to humans or machines, a speaker, a cathode ray tube (CRT) monitor, a liquid crystal display (LCD), or any other type of device that can generate intelligible output to a user.
Applications 220 may also include program instructions and/or data that are executable by processing circuitry 202 of computing system 20 to cause computing system to provide the functionality ascribed to it herein. Example application(s) 220 may include monitoring system 22. Other additional applications not shown may alternatively or additionally be included to provide other functionality described herein and are not depicted for the sake of simplicity.
In accordance with the techniques of the disclosure, computing system 20 receives IMD data 102, sensor device data 104, user recorded health data 106, and geofence data 108 from external device 12 via communication circuitry 206. Processing circuitry 202 stores these as data 230 in storage devices 208.
Computing system 20 may also receive EMR data 230 from EMR database 22 (
Monitoring system 222, e.g., implemented by processing circuitry of computing system 20, may implement the techniques of this disclosure including developing an algorithm based on training sets of parametric data, e.g., from IMD data 102 and sensor device data 104, and in some cases user recorded health data 106 and EMR data 230, of a population of patients or subjects, and applying the algorithm to parametric data of an individual patient 4 to predict the occurrence of a clinically significant health event. In some examples, monitoring system 222 trains one or more machine learning (ML) models 224 for prediction of the health event. The output of the ML models for a particular patient may be a level of risk of the health event, e.g., a probability of the health event, a level of risk or probability of the health event occurring within a certain predetermined time period, and/or whether the risk or probability satisfies a threshold.
The plurality of patient parameters may include AF burden, one or more activity parameters, and/or any of the physiological parameters described herein. In some examples, monitoring system 222 may derive features from the parametric data, and apply the features as inputs to the algorithm, e.g., ML model 224, to determine the risk level. One or more of the features may be AF burden features.
One or more of the features may be AF burden pattern features. An AF burden pattern feature may quantify a pattern of AF burden over a plurality of periods including the current period for which monitoring system 222 is determining the risk level. AF burden patterns including a change, e.g., spike or increase, in AF relative to an overall AF burden trend may be associated with an increased risk of a health event, such as a stroke of other clinically significant episode related to cardiovascular health. In some examples, monitoring system 222 determines the AF burden pattern feature by comparing, e.g., determining a difference or ratio between, a current AF burden value and an average, e.g., mean or median, of previous AF burden values. The current value may be a single value for the current period of a shorter-term average of values including the current period and a number of preceding periods. The average value may be a longer-term average of previous values, e.g., including more values and/or values from further in the past, which may not include the current period value. In some examples, the features include a patient activity feature, such as a daily activity level, a daytime or nighttime activity level, or a change in such an activity level relative to a baseline or trend in activity levels.
In general, the health event may be any clinically significant health event. In some examples, the health event may be a cardiovascular event. The health event may be a stroke. In some examples, the health event is a health care utilization event, such as a hospitalization. In some examples, the health event comprises a symptomatic event, such as clinically significant syncope or dizziness.
Monitoring system 222 may initially train ML model 224 with parametric data collected from one or more populations of patients, e.g., during a clinical study. In conventional clinical studies, one or more human experts review the parametric data and collect other information to classify each of the training sets by endpoint, e.g., as either including the health event or not. In contrast, monitoring system 222 may classify the training sets of parametric data based on classification data 232 collected automatically in response to detection of a trigger, which may reduce the cost or manpower overhead associated with the clinical study.
In some examples, processing circuitry 202 executing monitoring system 222 collects the classification data 232. In some examples, classification data is additionally or alternatively collected by other processing circuitry of system 2 (
Any one or more of IMD 10, sensor device 14, external device 12, or computing system 20 may detect the trigger for collection of classification data 232. In some examples, the trigger is a geofence event, e.g., detected by external device 12 indicating that the patient went to a hospital or clinic for a threshold amount of time. In such examples, external device 12 or computing system 20 may present a survey to the patient to collect information regarding the visit, e.g., confirming the visit and regarding the health issue(s) addressed, as user recorded health data 106 and classification data 230.
In some examples, the trigger comprises a feature of the parametric data for the patient satisfying a criterion, e.g., indicating that the patient may have experienced the health event. For example, a trigger may be AF burden meeting or exceeding a threshold. Other example triggers may include a feature of any physiological parameter described herein meeting a threshold value. In some examples, the trigger feature may be included within a training set of features used to train ML model 224, e.g., a set of features from which monitoring system 222 may choose to be input features based on their predictive value for the health event. In response to the detection of the trigger feature, monitoring system 222 or other processing circuitry of system 2 may collect classification data 230. The collection of classification data 232 may be via a survey as discussed above, or by checking geofence data 108 and/or EMR data 230 to identify a time proximate hospital or clinic visit indicative of the occurrence of the health event.
Subsequent to training ML model 224, monitoring system 222 may apply the ML model to parametric data, e.g., IMD data 102 and sensor device data 104, of a particular patient, such as patient 4, to determine a risk level that the patient with experience the health event. In some examples, monitoring system 222 may determine whether risk level of the health event satisfies a criterion, e.g., meets or exceeds a threshold risk level. Monitoring system 222 may take one or more actions based on determining that the risk level satisfied the criterion, e.g., as described with respect to
Although the techniques are described herein as being performed by monitoring system 222, and thus by processing circuitry 202 of computing system 20, the techniques may be performed by processing circuitry of any one or more devices or systems of system 2. In some examples, external device 12 may additionally or alternatively implement monitoring system 222, e.g., using ML model 224 trained based on population parametric data and, in some examples, personalized based on parametric data of patient 4. ML model 224 may include, as examples, neural networks, deep learning models, convolutional neural networks, or other types of predictive analytics systems. Furthermore, although the techniques of this disclosure are described primarily with respect to examples including ML model 224, in some examples the techniques may be implemented with different models or algorithms that do not necessarily require machine learning, such as linear regression, trend analysis, decision trees, or thresholds, as examples.
If the trigger occurs (YES of 402), monitoring system 222 collects classification data 232 (404). As discussed above with respect to
According to the example illustrated by
Monitoring system 222 may change a sensing behavior of system 2 (506). For example, monitoring system 222 may direct IMD 10 and/or sensing device 104 to employ more sensitive setting for sensing circuitry 52 or sensors 58, sample physiological signals at a higher rate, and or make periodic measurements at a greater frequency.
As another example, monitoring system 222 may provide an instruction to patient 4 to take a medication or modify the taking of a medication (508). The medication may be an anticoagulant. The instruction may be to take a pro re nata dose of the medication or change a dosage of the medication.
As another example, monitoring system 222 may prioritize patient 4, or the portions of parametric data associated with the risk level of the health event, in a notification for a clinician treating patient 4 (810). Monitoring system 222 implementing the techniques of this disclosure may advantageously reduce the burden of treating patients by prioritizing patients and/or patient data in their notification from system 2 based on the risk level satisfying a criterion indicating a clinically significant risk of the health event. In some examples, monitoring system 222 reduces burden by determining which rhythms should be transmitted or alerted to the patient and/or clinician, e.g., presents a clinically relevant patient report that adjudicates symptoms.
As another example, monitoring system 222 may determine a classification for the parametric data associated with the risk level of the health event, and create a training set of parametric data for reinforcement training of ML model 224 and/or personalization of ML model 224 for patient 4, e.g., to create a patient-specific version of ML model 224 (512). Monitoring system 222 may utilize any of the techniques described herein, e.g., with respect to
Health monitor 96 executed by processing circuitry 80 of external device may implement portions of the techniques described with respect to
In some examples, in order to enable real-time patient management, health monitor 96 can follow a pre-determined protocol to automatically push patient actions based on specific, detected patterns of parametric data. For example, health monitor 96 may see a predetermined clinically significant degree of AF burden and recommend modifications to a patient's anticoagulation medication. As discussed above, the actions may additionally or alternatively be pushed based on the risk level of the health event satisfying a criterion. In some examples, computing system 20 may provide an interface for a clinician via a web interface or user interface devices 204 to specify the parametric data features or risk level criterion that would trigger clinical action, e.g., AF duration lasting longer than 1 hour or probability of stroke exceeding a threshold probability, and the clinical action that the patient would need to take, such as an up titration of anticoagulation medications. In some examples, health monitor 96 may provide a pro re nata (PRN) medication request. In some examples, health monitor 96 may have a communication tab and also a priority status that would require the action to be acknowledged before allowing patient 4 to move on to other features of health monitor 96, such as viewing parametric data of patient 4.
The experimental analysis suggested that a change in AF burden occurs within a long-term trend (21+ days) prior to a stroke event. AF burden may be considered the leading predictor in the long-term. More particularly, a growing short-term trend in AF burden within a longer term trend may be predictive of stroke. The predictive ability of AF burden may be 4× greater when acute, shorter-term changes are compared to a longer-term trend.
A retrospective cohort study of patients with ICMs, including the Reveal LINQ™ ICM, was performed to determine whether rules-based algorithms that examine change from baseline ICM-based parameters can be used to stratify risk of near-term HCU. The occurrence of HCU as a study end point was obtained from deidentified claims data. A patient was labeled as having an occurrence of HCU if their claims history included at least one encounter from an in- or outpatient hospital, emergency room, or ambulatory surgical center with a cardiovascular DRG or diagnosis code. The first occurrence of HCU was recorded if a patient had multiple utilizations.
ICM-based diagnostic parameters evaluated in the study included daily total AT/AF burden (milliseconds/day), total patient activity, e.g., time with supra-threshold patient motion (minutes/day), average ventricular rate (night and day), and HRV. Patients with less than 21 days of daily follow-up after implant, or with a gap in follow-up greater than or equal to 30 days, were excluded from the cohort. Missing data resulting from a gap in daily follow-up was interpolated by forward-filling the last known value for each diagnostic parameter. Follow-up history was limited to two years unless there was an HCU, in which case follow-up ended the day prior to the event. Patients without any device-detected time in AT/AF within the two-year follow-up period were excluded from the cohort.
To define diagnostic temporal patterns for the study, each parameter, at each patient follow-up date, was evaluated as a cumulative moving average (CMA) from the day after implant and as an SMA of different historical periods (1, 2, 3, 5, 8, 13, and 21 days) starting 21 days after implant. For the study, offset SMAa_b denoted the difference between SMAa and SMAb where the longer period SMA is subtracted from the shorter period SMA (i.e., a<b). An offset of period p with its respective CMA was denoted as SMAp_c.
For the study, the occurrence of HCU was treated as an unbalanced, binary, classification problem. A recursive partitioning & regression tree algorithm (RPART) was used to predict which follow-up days had an occurrence of HCU using diagnostic parameters and moving average offsets as predictors. Random sampling methods for imbalanced learning were used within a bootstrapping routine to promote algorithm convergence and to improve classifier accuracy. HCU events were oversampled by labeling the five days prior to an occurrence as an event. For patients who experienced an HCU, follow-up ended on the day prior to the occurrence to prevent the use of device measurements taken on the same day the event happened, a situation that would introduce look ahead bias into the modeling. For each bootstrap iteration:
Each split for a terminal node was recorded as a 3-tuple, [predictor name, comparison, index], along with its respective HCU rate and patient count for both training and validation sets. Each split was saved as a separate entry if a node had multiple splits. In such a case, the utilization rates and patient counts would be the same for all splits in each node.
A scatterplot of decision tree terminal nodes showing the relationship between labeled HCU rate and the percent of patients was used to identify patterns in the AF burden classification tree structure that would stratify healthcare event risk. The algorithm for defining these patterns was:
Descriptive analyses and tests of equal proportions were performed to compare the odds ratio for AF burden patterns with clinically relevant thresholds for duration and quantity.
The bootstrapping routine was run 3,000 times to create an equal number of classification trees.
A
timeinafat
—
c
<
930
193
3,000
100.00%
B
timeinafat
—
c
>=
900
214
454
15.13%
timeinafat
—
offset
—
21
—
c
<
−675
564
399
13.30%
timeinafat
—
offset
—
1
—
21
>=
−75,656
182,026
371
12.37%
C
timeinafat
—
c
>=
959
342
950
31.67%
timeinafat
—
offset
—
21
—
c
>=
−721
566
938
31.27%
D
timeinafat
—
c
>=
170,559
552,040
256
8.53%
timeinafat
—
offset
—
21
—
c
>=
−4,771
61,172
231
7.70%
activitiesofdlyliving
—
c
<
76
8
200
6.97%
Table 2 (above) presents a summary of the top five splits by area. Splits with a selection rate above their respective elbow point are in bold. Together, these highlighted splits define the AF burden pattern for a given area. Pattern A is defined by an AF burden CMA less than approximately 1 second. The pattern is present in all 3,000 decision trees and describes the follow-up period prior to the first detection of AT/AF (77% of occurrences) and the period of relative sinus rhythm recovery after device detected AT/AF (23% of occurrences). Pattern C is defined by an AF burden CMA greater than approximately 1 second and an AF burden 21-day SMA that is approximately greater than its historical average. The pattern is present in 25% of all decision trees and describes a relative spike or increasing trend in daily AF burden. Pattern B is defined by an AF burden CMA greater than approximately 1 second, but unlike pattern C, it has a decreasing AF burden 21-day SMA that is less than its historical average. The increasing 1-day SMA (daily burden) relative to the 21-day SMA suggests that pattern C signals a period of sporadic, below average burden, relative to the patient, that can occur after a period of elevated burden.
Labeled HCU rate and patient percent were calculated on the training data for AF burden quantity and duration thresholds. The quantity threshold was defined as daily AF burden greater than 5% (72 minutes); the duration threshold was defined as continuous AF greater than one hour. The log odds event rate was 0.369 and 0.386 and the patient percent was 12.9% and 7.6% for the respective thresholds. Table 2, Area D presents a summary of the top five splits in the terminal node scatterplot where the log odds event rate was greater than 0.369 and the percent of patients was greater than 12.9%. The top three splits define a partial substructure of pattern C where the CMA of daily activity drops below 76 minutes. When applied to a balanced training set, pattern D is selected 10.4% of the time and has a log odds ratio of 0.368, a value that is not statistically different from the other log odds ratios (Poisson regression, p>0.5 for all threshold coefficients).
In Table 3, Count indicates the number of times the threshold was met; Events, the number of labeled HCUs; Odds, the ratio of event count to threshold count divided by the group mean event rate for the validation set; Patients, the number of patients with at least one day meeting the threshold as a percent of total patients in the validation set; Follow-ups, the number of days meeting the threshold as a percent of total follow-up days for patients with at least one occurrence of the threshold. Note: counts are mutually exclusive per follow-up days, not by patient. A patient may experience different thresholds across follow-up days. Therefore, patient and follow-up percents will not sum to 100%.
The analysis of AF burden patterns in the study confirm the correlation between increased burden and risk and, more particularly, that a growing trend in AF burden (e.g., daily) over time is associated with a greater risk for HCU, especially when accompanied with a decline in daily activity. Patterns for AF burden amounts less than approximately 1-hour predict healthcare events on par with quantity and duration thresholds greater than 1-hour. AF burden patterns proved additional event capture that complements quantity and duration thresholds. AF burden as a risk factor for HCU is relative to a patient's historical burden.
The study illustrates the value of AF burden and patient activity as parametric data from which features may be derived and then applied to an algorithm or model to determine a likelihood of an event, such as an HCU event, as described herein. The features derived from AF burden may include AF burden pattern features, such as a change, e.g., spike or increase, in AF burden relative to an overall AF burden trend. For example, AF burden pattern features may include one or more offsets between SMAs for different look-back periods and/or between an SMA for a look-back period and a CMA. As described herein, the model to which such features are applied may be machine learned or rules-based, e.g., involving decision trees and/or thresholds.
It should be understood that various aspects disclosed herein may be combined in different combinations than the combinations specifically presented in the description and accompanying drawings. It should also be understood that, depending on the example, certain acts or events of any of the processes or methods described herein may be performed in a different sequence, may be added, merged, or left out altogether (e.g., all described acts or events may not be necessary to carry out the techniques). In addition, while certain aspects of this disclosure are described as being performed by a single module, unit, or circuit for purposes of clarity, it should be understood that the techniques of this disclosure may be performed by a combination of units, modules, or circuitry associated with, for example, a medical device.
Example 1. A system comprising processing circuitry configured to: receive parametric data for a plurality of parameters of a patient, wherein the parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices, and wherein the plurality of parameters comprises AF burden; derive one or more features based on the parametric data for the plurality of parameters, wherein the one or more features comprise at least one AF burden pattern feature; apply the one or more features to a model; and determine a risk level of a health event for the patient based on the application of the one or more features to the model.
Example 2. The system of Example 1, wherein the AF burden pattern feature comprises a comparison between a current AF burden value and an average of AF burden values.
Example 3. The Example of claim 2, wherein the current AF burden value comprises a shorter-term average of AF burden values and the average of AF burden values comprises a longer-term average of AF burden values.
Example 4. The system of any of Examples 1 to 3, wherein the one or more features comprise a patient activity feature.
Example 5. The system of any of Examples 1 to 4, wherein the health event comprises stroke.
Example 6. The system of any of Examples 1 to 4, wherein the health event comprises a health care utilization event.
Example 7. The system of any of Examples 1 to 4, wherein the health event comprises a symptomatic event.
Example 8. The system of any of Examples 1 to 7, wherein, to determine the risk level of the health event, the processing circuitry is configured to determine a probability of occurrence of the health event.
Example 9. The system of any of Examples 1 to 8, wherein the risk level comprises a risk that the health event will occur within a predetermined time period.
Example 10. The system of any of Examples 1 to 9, wherein the processing circuitry is configured to determine whether the risk level of the health event satisfies a criterion.
Example 11. The system of Example 10, wherein the processing circuitry is configured to change a sensing configuration of at least one of the one or more sensing devices based on the risk of the health event satisfying the criterion.
Example 12. The system of Examples 10 or 11, wherein the processing circuitry is configured to deliver an instruction for a medication to the patient based on the risk of the health event satisfying the criterion.
Example 13. The system of Example 12, wherein the instruction comprises an instruction for a pro re nata dose of the medication.
Example 14. The system of Examples 12 or 13, wherein the medication comprises an anticoagulant.
Example 15. The system of any of Examples 10 to 14, wherein the processing circuitry is configured to deliver a notification to a clinician based on the risk of the health event satisfying the criterion.
Example 16. The system of any of Examples 10 to 15, wherein the processing circuitry is configured to: determine whether the health event occurred subsequent to determining that the risk of the health event satisfied the criterion; determine a training set of parametric data for training the model based on the parametric data of the patient; classify the training set of parametric data based on whether the health event occurred.; and train the model with the classified training set of parametric data.
Example 17. The system of Example 16, wherein, to determine whether the health event occurred, the processing circuitry is configured to prompt the patient to complete a survey based on determining that the risk of the health event satisfied the criterion.
Example 18. The system of Examples 16 or 17, wherein, to determine whether the health event occurred, the processing circuitry is configured to determine whether a geofence event occurred in time proximity to the risk of the health event satisfying the criterion.
Example 19. The system of any of Examples 16 to 18, wherein, to determine whether the health event occurred, the processing circuitry is configured to retrieve data from an electronic medical records database based on determining that the risk of the health event satisfied the criterion.
Example 20. The system of any of Examples 1 to 19, wherein the processing circuitry comprises processing circuitry of at least one of: a patient computing device configured for wireless communication with the one or more sensing devices; and a computing system configured for network communication with the patient computing device.
Example 21. The system of any of Examples 1 to 20, wherein the system comprises the one or more sensing devices comprising an implantable medical device and an external sensing device that is a peripheral device for the patient computing device.
Example 22. A method comprising: receiving parametric data for a plurality of parameters of a patient, wherein the parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more sensing devices, and wherein the plurality of parameters comprises AF burden; deriving one or more features based on the parametric data for the plurality of parameters, wherein the one or more features comprise at least one AF burden pattern feature; applying the one or more features to a model; and determining a risk level of a health event for the patient based on the application of the one or more features to the model.
Example 23. The method of Example 22, wherein the AF burden pattern feature comprises a comparison between a current AF burden value and an average of AF burden values.
Example 24. The method of Example 23, wherein the current AF burden value comprises a shorter-term average of AF burden values and the average of AF burden values comprises a longer-term average of AF burden values.
Example 25. The method of any of Examples 22 to 24, wherein the one or more features comprise a patient activity feature.
Example 26. The method of any of Examples 22 to 25, wherein the health event comprises stroke.
Example 27. The method of any of Examples 22 to 25, wherein the health event comprises a health care utilization event.
Example 28. The method of any of Examples 22 to 25, wherein the health event comprises a symptomatic event.
Example 29. The method of any of Examples 22 to 28, wherein determining the risk level of the health event comprises determining a probability of occurrence of the health event.
Example 30. The method of any of Examples 22 to 29, wherein the risk level comprises a risk that the health event will occur within a predetermined time period.
Example 31. The method of any of Examples 22 to 30, further comprising determining whether the risk level of the health event satisfies a criterion.
Example 32. The method of Example 31, further comprising changing a sensing configuration of at least one of the one or more sensing devices based on the risk of the health event satisfying the criterion.
Example 33. The method of Examples 31 or 32, further comprising delivering an instruction for a medication to the patient based on the risk of the health event satisfying the criterion.
Example 34. The method of Example 33, wherein the instruction comprises an instruction for a pro re nata dose of the medication.
Example 35. The method of Examples 33 or 34, wherein the medication comprises an anticoagulant.
Example 36. The method of any of Examples 31 to 35, further comprising delivering a notification to a clinician based on the risk of the health event satisfying the criterion.
Example 37. The method of any of Examples 31 to 36, further comprising: determining whether the health event occurred subsequent to determining that the risk of the health event satisfied the criterion; determining a training set of parametric data for training the model based on the parametric data of the patient; classifying the training set of parametric data based on whether the health event occurred; and training the model with the classified training set of parametric data.
Example 38. The method of Example 37, wherein determining whether the health event occurred comprises prompting the patient to complete a survey based on determining that the risk of the health event satisfied the criterion.
Example 39. The method of Examples 37 or 38, wherein determining whether the health event occurred comprises determining whether a geofence event occurred in time proximity to the risk of the health event satisfying the criterion.
Example 40. The method of any of Examples 37 to 39, wherein determining whether the health event occurred comprises retrieving data from an electronic medical records database based on determining that the risk of the health event satisfied the criterion.
Example 41. The method of any of Examples 22 to 40, wherein the one or more sensing devices comprise an implantable medical device and an external sensing device that is a peripheral device for a patient computing device.
Example 42. A system comprising processing circuitry configured to: receive parametric data for a plurality of parameters of a patient, wherein the parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices; determine a training set of parametric data for training a model based on the parametric data of the patient; classify the training set of parametric data based on classification data collected automatically in response to detection of a trigger; and train the model with the classified training set of parametric data.
Example 43. The system of Example 42, wherein the plurality of patient parameters comprises AF burden.
Example 44. The system of Examples 42 or 43, wherein the plurality of patient parameters comprises a patient activity parameter.
Example 45. The system of any of Examples 42 to 44, wherein the processing circuitry is configured to: classify the training set of parametric data into a first category if a health event occurred for the patient or a second category if the health event did not occur for the patient; and train the machine learning algorithm to determine a risk of the health event.
Example 46. The system of Example 45, wherein the health event comprises stroke.
Example 47. The system of Example 45, wherein the health event comprises a health care utilization event.
Example 48. The system of Example 45, wherein the health event comprises a symptomatic event.
Example 49. The system of any of Examples 42 to 48, wherein the processing circuitry is configured to collect the classification data in response to detection of the trigger.
Example 50. The system of Example 49, wherein the trigger comprises a geofence event.
Example 51. The system of Example 49, wherein the trigger comprises a feature of the parametric data satisfying a criterion.
Example 52. The system of Example 51, wherein the feature is included within a training set of features used to train the model.
Example 53. The system of Examples 51 or 52, wherein the feature comprises an AF burden feature.
Example 54. The system of any of Examples 49 and 51 to 53, wherein, to collect the classification data, the processing circuitry is configured to determine whether a geofence event occurred in time proximity to the detection of the trigger.
Example 55. The system of any of Examples 49 to 54, wherein, to collect the classification data, the processing circuitry is configured to retrieve data from an electronic medical records database.
Example 56. The system of any of Examples 49 to 55, wherein, to collect the classification data, the processing circuitry is configured to prompt the patient to complete a survey.
Example 57. The system of any of Examples 42 to 56, wherein the processing circuitry comprises processing circuitry of at least one of: a patient computing device configured for wireless communication with the one or more sensing devices; and a computing system configured for network communication with the patient computing device.
Example 58. The system of any of Examples 42 to 57, wherein the system comprises the one or more sensing devices comprising an implantable medical device and an external sensing device that is a peripheral device for the patient computing device.
Example 59. A method comprising: receiving parametric data for a plurality of parameters of a patient, wherein the parametric data is generated by one or more sensing devices of the patient based on physiological signals of the patient sensed by the one or more devices; determining a training set of parametric data for training a model based on the parametric data of the patient; classifying the training set of parametric data based on classification data collected automatically in response to detection of a trigger; and training the model with the classified training set of parametric data.
Example 60. The method of Example 59, wherein the plurality of patient parameters comprises AF burden.
Example 61. The method of Example 59 or 60, wherein the plurality of patient parameters comprises a patient activity parameter.
Example 62. The method of any of Examples 59 to 61, wherein the processing circuitry is configured to: classify the training set of parametric data into a first category if a health event occurred for the patient or a second category if the health event did not occur for the patient; and train the machine learning algorithm to determine a risk of the health event.
Example 63. The method of Example 62, wherein the health event comprises stroke.
Example 64. The method of Example 62, wherein the health event comprises a health care utilization event.
Example 65. The method of Example 62, wherein the health event comprises a symptomatic event.
Example 66. The method of any of Examples 59 to 65, wherein the processing circuitry is configured to collect the classification data in response to detection of the trigger.
Example 67. The method of Example 66, wherein the trigger comprises a geofence event.
Example 68. The method of Example 66, wherein the trigger comprises a feature of the parametric data satisfying a criterion.
Example 69. The method of Example 68, wherein the feature is included within a training set of features used to train the model.
Example 70. The method of Examples 68 or 69, wherein the feature comprises an AF burden feature.
Example 71. The method of any of Examples 66 or 68 to 70, wherein collecting the classification data comprises determining whether a geofence event occurred in time proximity to the detection of the trigger.
Example 72. The method of any of Examples 66 to 71, wherein collecting the classification data comprises retrieving data from an electronic medical records database.
Example 73. The method of any of Examples 66 to 72, wherein collecting the classification data comprises prompting the patient to complete a survey.
Example 74. The method of any of Examples 66 to 73, wherein the one or more sensing devices comprise an implantable medical device and an external sensing device that is a peripheral device for a patient computing device.
Example 75. A method comprising any combination of the Example methods described herein.
Example 76. A system comprising processing circuitry configured to perform the method of any one or more of Examples 22 to 41 and 59 to 75.
Example 77. A non-transitory computer readable storage medium comprising program instructions configured to cause processing circuitry to perform the method of any one or more of Examples 22 to 41 and 59 to 75.
Example 78. A system comprising processing circuitry configured to: derive one or more features based on parametric data of a patient generated by one or more sensing devices of the patient based on one or more signals of the patient sensed by the one or more sensing devices, wherein the parametric data comprises AF burden data, wherein the one or more features comprise one or more offsets between moving averages of the AF burden data for different time periods; apply the one or more features to a rules-based model; and determine a risk level of a health care utilization event for the patient based on the application of the one or more features to the rules-based model.
Example 79. The system of Example 78, wherein the parametric data comprises activity data of the patient.
Example 80. The system of Examples 78 or 79, wherein the parametric data comprises heart rate data.
Example 81. An apparatus comprising means for any of the Examples described herein.
In one or more examples, the described techniques may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include non-transitory computer-readable media, which corresponds to a tangible medium such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer).
Instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Accordingly, the term “processor” or “processing circuitry” as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. Also, the techniques could be fully implemented in one or more circuits or logic elements.
Various examples have been described. These and other examples are within the scope of the following claims.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2022/015398 | 2/7/2022 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63147594 | Feb 2021 | US | |
| 63288902 | Dec 2021 | US |
