CN116847781A - Health event prediction - Google Patents

Abstract

A system includes processing circuitry configured to receive parameter data for a plurality of parameters of a patient. The parameter 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 includes an AF load. The processing circuitry is configured to: deriving one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to the model; and determining a risk level of the health event for the patient based on the application of the one or more features to the model.

Description

Health event prediction

Technical Field

The present disclosure relates generally to systems including medical devices, and more particularly to monitoring patient health using such systems.

Background

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. Physiological signals sensed by such devices include, for example, electrocardiogram (ECG) signals, respiration signals, perfusion signals, activity and/or pose signals, pressure signals, blood oxygen saturation signals, body components, and blood glucose or other blood component signals. Generally, using these signals, such devices facilitate monitoring and assessment of patient health over months or years outside of the clinical setting.

In some cases, such devices are configured to detect health events such as arrhythmia episodes or heart failure exacerbations based on physiological signals. Exemplary cardiac arrhythmia types include asystole, bradycardia, ventricular tachycardia, supraventricular tachycardia, wide-wave group tachycardia, atrial fibrillation, atrial flutter, ventricular fibrillation, atrioventricular block, ventricular premature beat, and atrial premature beat. These devices may store ECG and other physiological signal data collected during a time period that includes a seizure as seizure data. These devices may also store episode data that quantifies episodes, such as the number and/or duration of episodes. The medical device may also store ECG and other physiological data for a period of time as episode data in response to user input, e.g., from a patient or caregiver.

Disclosure of Invention

In general, the present disclosure describes techniques for determining a risk level for a health event based on parameter data for a plurality of parameters of a patient including Atrial Fibrillation (AF) load. In some examples, the techniques include applying AF load pattern features to the pattern to determine a risk level. In some examples, the model is trained with a training set of parametric data classified based on classification data automatically collected in response to detection of a trigger.

In one example, a system includes processing circuitry configured to receive parameter data for a plurality of parameters of a patient. The parameter 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 includes an AF load. The processing circuitry is configured to: deriving one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to the model; and determining a risk level of the health event for the patient based on the application of the one or more features to the model.

In another example, a method includes receiving parameter data for a plurality of parameters of a patient. The parameter 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 includes an AF load. The method comprises the following steps: deriving one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to the model; and determining a risk level of the health event for the patient based on the application of the one or more features to the model.

In another example, a system includes processing circuitry configured to receive parameter data for a plurality of parameters of a patient. The parameter 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: determining a training set of parameter data for training a model based on the parameter data of the patient; classifying the training set of parameter data based on classification data automatically collected in response to detection of the trigger; and training the model with the training set of classified parameter data.

In another example, a method includes receiving parameter data for a plurality of parameters of a patient. The parameter 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 the steps of: determining a training set of parameter data for training a model based on the parameter data of the patient; classifying the training set of parameter data based on classification data automatically collected in response to detection of the trigger; and training the model with the training set of classified parameter data.

In another example, a system includes processing circuitry configured to perform any of the methods described herein.

In another example, a non-transitory computer readable storage medium includes 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 in the following figures and description. Further details of one or more examples are set forth in the accompanying drawings and the description below.

Drawings

Fig. 1 is a block diagram illustrating an exemplary medical device system configured to predict health events and respond to such predictions in accordance with one or more techniques of the present disclosure.

Fig. 2 is a block diagram illustrating an exemplary configuration of the IMD of fig. 1.

Fig. 3 is a conceptual side view illustrating an exemplary configuration of the IMD of fig. 1 and 2.

Fig. 4 is a block diagram illustrating an exemplary configuration of an external device operating in accordance with one or more techniques of this disclosure.

FIG. 5 is a block diagram illustrating an exemplary computing system operating in accordance with one or more techniques of this disclosure.

FIG. 6 is a flow chart illustrating an exemplary technique for training a machine learning model using a training set of parameter data classified based on automatically collected classification data.

FIG. 7 is a flow chart illustrating an exemplary technique for automatically collecting classification data.

FIG. 8 is a flow chart illustrating an exemplary technique for predicting a health event and responding to the prediction of the health event.

Fig. 9 is a graph showing parameter data for a plurality of patient parameters over a period of time surrounding a stroke event.

Fig. 10 is a graph showing time-series values of moving averages of parameter data of patient parameters.

Fig. 11 is a graph showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke.

Fig. 12 is a graph showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke.

Fig. 13A-13D are graphs showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke for different patient populations.

Fig. 14A-14D are graphs showing experimentally determined statistical significance of multiple patient parameters in predicting hospitalization of different patient populations.

FIG. 15 is a chart showing AF load pattern characteristics for predicting stroke and healthcare utilization.

Fig. 16A and 16B are graphs showing AF load patterns for patients experiencing stroke or healthcare utilization events for different patient populations, respectively.

Fig. 17 is a graph showing AT/AF time (load) detected during a monitoring period.

Fig. 18 presents a scatter plot of end nodes for marked HCU rates and patient percentages based on balance training data.

Fig. 19 presents an exemplary graphical illustration of patterns in AF load data for a single HCU patient map.

Figure 20 presents a scatter plot of terminal nodes scored according to the marked HCU rate and patient percentage of the unbalanced validation set.

Fig. 21 presents a venn plot of AF load threshold counts for a validation set.

Like reference numerals refer to like elements throughout the drawings and description.

Detailed Description

Various types of implantable and medical devices detect arrhythmia episodes and other health events based on sensed ECG and, in some cases, other physiological signals. External devices that may be used for non-invasive sensing and monitoring of ECG and other physiological signals include wearable devices such as patches, watches, or necklaces having electrodes configured to contact the skin of a patient. Such medical devices may facilitate relatively long-term monitoring of patient health during normal daily activities.

Implantable Medical Devices (IMDs) also sense and monitor ECG and other physiological signals and detect health events such as arrhythmia episodes and heart failure exacerbations. An exemplary IMD includes: pacemakers and implantable cardioverter-defibrillators, which may be coupled to intravascular or extravascular leads; and a pacemaker having a housing configured for implantation within the heart, the pacemaker may be leadless. Some IMDs do not provide therapy, such as implantable patient monitors. One example of such an IMD is the real LINQ commercially available from Medun force company (Medtronic plc) ^TM An Insertable Cardiac Monitor (ICM) that is percutaneously insertable. Such IMDs may facilitate relatively long-term monitoring of patients during normal daily activities, and may periodically transmit collected data, such as episode data for detected arrhythmia episodes, to a remote patient monitoring system, such as the meiton force Carelink ^TM A network.

Fig. 1 is a block diagram illustrating an exemplary medical device system 2 configured to predict health events of a patient 4 and respond to such predictions in accordance with the techniques of the present disclosure. Exemplary techniquesThe procedure may be used with IMD 10, which may communicate wirelessly with external device 12. In some examples, IMD 10 is implanted outside of the chest of patient 4 (e.g., subcutaneously in the pectoral muscle position shown in fig. 1). IMD 10 may be positioned near a sternum near or just below a heart level of patient 4, e.g., at least partially within a heart outline. IMD 10 includes a plurality of electrodes (not shown in fig. 1) and is configured to sense ECG via the plurality of electrodes. In some examples, IMD 10 employs LINQ ^TM Form of ICM. Although primarily described in the context of an example in which the IMD takes the form of an ICM, the techniques of this disclosure may be implemented in a system 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 episodes and other physiological data collected and stored by IMD 10 from IMD 10. In some examples, the external device takes the form of a personal computing device of the patient or caregiver, such as a smart phone.

In the example shown in fig. 1, the system 2 further includes a sensor device 14 in wireless communication with the external device 12. The sensor device 14 may include electrodes and other sensors to sense physiological signals of the patient 4, and may collect and store physiological data and detect episodes based on such signals. In some examples, the sensor device 14 is an external device that can be worn by the patient 4. The sensor device 14 may be incorporated into the clothing of the patient 14, such as within clothing, shoes, glasses, watches or wristbands, hats, etc. In some examples, the sensor device 14 is a smart watch or other accessory or peripheral to the smart phone external device 12.

The external device 12 retrieves episodes and other physiological data collected and stored by the sensor device 14 from the sensor device 14. The external device 12 may include a display and other user interface elements. In some examples, external device 12 presents physiological data and/or statistical representations thereof retrieved from IMD 10 and/or sensor device 14 to patient 4 or another user. The external device 12 may be in accordance with, for exampleOr->A low power consumption (BLE) protocol communicates with IMD 10 and/or sensor device 14.

The external device 12 may be configured to communicate with the computing system 20 via the 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 the onset of an arrhythmia or other health event detected by IMD 10 and sensor device 14, and other physiological signals or data recorded by IMD 10 and sensor device 14. The data retrieved from IMD 10 and sensor device 14 may include values of various patient parameters and/or values that may be used by computing system 20 to determine patient parameters. The values of the patient parameters may be referred to as patient parameter data. Patient parameter data may be retrieved and/or determined on a periodic basis to generate periodic values, such as daily values on a daily basis.

Computing system 20 may include a computing device configured to allow users (e.g., clinicians treating patient 4 and other patients) to interact with data collected from IMD 10 and sensor device 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 (fig. 5) including processing circuitry and storage devices that implement monitoring system 222. The monitoring system 222 may present patient parameter data to the clinician to allow the clinician to remotely track and evaluate their patient. In some examples, the monitoring system 222 may analyze the data and prioritize presentation of data or alarms for certain patients based on the analysis. In some examples, the computing system 20, network 16, and monitoring system 222 may pass the midton force Carelink ^TM A network.

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 protection devices, servers, computer terminals, laptops, printers, databases, wireless mobile devices (such as cellular telephones or personal digital assistants), wireless access points, bridges, cable modems, application accelerators, or other network devices. The network 16 may comprise one or more networks managed by a service provider and may thus form part of a large-scale public network infrastructure (e.g., the internet). The network 16 may provide computing devices (such as the computing system 20 and the medical device 12) with 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 dedicated network that provides a communication framework that allows computing system 20 and external devices 12 to communicate with each other, but separates one or more of these devices or the data flow between these devices from devices external to network 16 for security purposes. In some examples, the communication between the computing system 20 and the external device 12 is encrypted.

The computing system 20 may also retrieve data for the patient 4 from an Electronic Medical Record (EMR) database 22. The EMR database 22 may store electronic medical records (also referred to as electronic health records) of the patient 4, which may be generated by various healthcare providers, laboratories, clinicians, insurance companies, and the like. Although shown as a single database in fig. 1, the EMR database 22 can include various databases managed by various entities.

By way of example, the EMR database 22 may store, for example, a medication history of the patient, a surgical procedure history of the patient, a hospitalization history of the patient, an emergency or emergency care visit history of the patient, a reservation clinic visit history of the patient, one or more laboratory or other clinical test results of the patient 14, a cardiovascular disease history of the patient 14, or a co-morbid condition of the patient 14 (such as atrial fibrillation, heart failure, or diabetes). As a further example, the EMR database 22 may store medical images of the patient 4, such as X-ray images, ultrasound images, echocardiography, anatomical images, medical photographs, radiographic images, and the like. The data stored in the EMR database 22 may include patient-specific records of the patient 4 and many other patients. In some examples, the data stored by the EMR database 22 may include broader demographic information or population type information for a plurality of patients.

Monitoring system 222, implemented by processing circuitry of computing system 20 for example, may implement the techniques of the present disclosure, including developing an algorithm based on a training set of parameter data for a patient or population of subjects retrieved from IMD 10 of the population and external device 14, and applying the algorithm to the parameter data for individual patient 4 to predict the occurrence of a clinically significant health event. In some examples, the monitoring system trains one or more Machine Learning (ML) models to predict the health event. The output of the ML model for a particular patient may be a risk level of the health event, a probability of the health event occurring within a particular time, and/or whether the risk or probability meets a threshold.

Exemplary health events that can be predicted using the techniques of the present disclosure include stroke, clinically significant AF requiring hospitalization or emergency care, and clinically significant episodes of symptomatic events such as syncope or dizziness. Parameter data that may be used to predict such health events may include heart rate data, such as heart rate data and data related to Atrial Fibrillation (AF) or other arrhythmia episodes. The AF data may include a quantization of AF (referred to as AF load) and a pattern of AF load over a plurality of time periods. The parameter data that may be used to predict such clinically significant health events may alternatively 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 a patient or caregiver via external device 12 along with parameter data from IMD 10 or sensor device 14. In some examples, data from the EMR database 22 and/or data entered by the patient or caregiver may be used as input to the ML model or other health event prediction algorithm implemented by the monitoring system 222. In some examples, data from the EMR database 22 and/or data entered by the patient or caregiver via the external device 12 may provide a classification of a training set of parameter data from the IMD 10 and the sensor device 14 for training one or more ML models to predict a health event. For example, data from the EMR database 22 and/or data entered by the patient or caregiver via the external device 12 may indicate whether, when, and the severity of clinically significant health events are experienced by the patient 4. Such data may be associated with the parameter data to create a training set of parameter data. After an initial training phase, such training sets may be used for reinforcement learning, and in some cases, personalization of one or more ML models.

Although the techniques are described herein as being performed by the monitoring system 222, and thus by the processing circuitry of the computing system 20, the techniques may also be performed by the processing circuitry of any one or more devices or systems of a medical device system, such as the computing system 20, the external device 12, or the IMD 10. The ML model may include, for example, a neural network, a deep learning model, a convolutional neural network, or other type of predictive analysis system.

Fig. 2 is a block diagram illustrating an exemplary configuration of IMD 10 of fig. 1. As shown in fig. 2, IMD 10 includes processing circuitry 50, sensing circuitry 52, communication circuitry 54, memory 56, sensors 58, switching circuitry 60, and electrodes 16A, 16B (hereinafter "electrode 16"), one or more of which may be disposed on a housing of IMD 10. In some examples, memory 56 includes computer readable instructions that, when executed by processing circuitry 50, cause IMD 10 and processing circuitry 50 to perform various functions attributed to IMD 10 and processing circuitry 50 herein. Memory 56 may include any volatile, non-volatile, magnetic, optical, or electrical media, such as Random Access Memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), electrically Erasable Programmable ROM (EEPROM), flash memory, or any other digital media.

The processing circuitry 50 may include fixed function circuitry and/or programmable processing circuitry. The processing circuitry 50 may include any one or more of a microprocessor, controller, digital Signal Processor (DSP), application Specific Integrated Circuit (ASIC), field Programmable Gate Array (FPGA), or equivalent discrete or analog logic circuitry. In some examples, processing circuitry 50 may include multiple components (such as one or more microprocessors, one or more controllers, one or more DSPs, one or more ASICs, or any combinations of one or more FPGAs), as well as other discrete or integrated logic circuitry. The functions attributed herein to processing circuitry 50 may be embodied as software, firmware, hardware or any combination thereof.

The sensing circuitry 52 may be selectively coupled to the electrodes 16A, 16B via switching circuitry 60 as controlled by the processing circuitry 50. The sensing circuitry 52 may monitor signals from the electrodes 16A, 16B in order to monitor the electrical activity of the heart of the patient 4 of fig. 1 and generate ECG data of the patient 4. In some examples, processing circuitry 50 may identify sensed characteristics of the ECG, such as heart rate, heart rate variability, intra-beat spacing, and/or ECG morphology characteristics, to detect an arrhythmia episode for patient 4. The processing circuitry 50 may store characteristics of the digitized ECG and the ECG used to detect the arrhythmia episode in the memory 56 as episode data for the detected arrhythmia episode. The processing circuitry 50 may also store parameter data stores (including characteristics of ECG and data quantifying arrhythmia episodes, such as AF loading data) in the memory 56.

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. In some examples, for cardiac depolarization detection, sensing circuitry 52 may include rectifiers, filters, amplifiers, comparators, and/or analog-to-digital converters. In some examples, sensing circuitry 52 may output an indication to processing circuitry 50 in response to sensing of cardiac depolarization. In this manner, processing circuitry 50 may receive a detected cardiac depolarization indicator corresponding to the occurrence of detected R-waves and P-waves. Processing circuitry 50 may use the indication to determine characteristics 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 heart rhythm discrimination, and/or to identify and characterize ECG features, such as QRS amplitude and/or width, or other morphological features.

In some examples, sensing circuitry 52 measures, for example, impedance of tissue in the vicinity of IMD 10 via electrode 16. The measured impedance may vary based on the degree of respiration and perfusion or oedema. Processing circuitry 50 may determine parameter data related 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, the sensing circuitry 52 and/or the processing circuitry 50 may include rectifiers, filters and/or amplifiers, sense amplifiers, comparators, and/or analog-to-digital converters. The processing circuitry 50 may determine parameter data (e.g., physiological parameter values of the patient 4) based on signals from the sensors 58, which may be stored in the memory 56.

In some examples, processing circuitry 50 transmits, via communication circuitry 54, parameters and event data of patient 4 to external device 12 of fig. 1, which may transmit the data to network 16 for processing by monitoring system 222 of computing system 20. Communication circuitry 54 may include any suitable hardware, firmware, software, or any combination thereof for communicating with another device, such as external device 12. Under control of processing circuitry 50, communication circuitry 54 may receive downlink telemetry from and transmit uplink telemetry to external device 12 or another device by way of an internal or external antenna (e.g., antenna 26).

Although described herein in the context of exemplary IMD 10It is the techniques for arrhythmia detection disclosed herein that can be used with other types of devices. For example, the technique may be implemented with: external cardiac defibrillator coupled to electrodes external to the cardiovascular system, transcatheter pacemaker configured for implantation within the heart (such as Micra commercially available from midwifery corporation of dublin, irish ^TM Transcatheter pacing system), an insertable cardiac monitor (such as a real LINQ, which is also commercially available from meiton force corporation) ^TM ICM), neurostimulator or drug delivery device.

As discussed with respect to fig. 1, the sensor device 14 may be an external device, such as a smart watch, fitness tracker, patch, or other wearable device. Sensor device 14 may be configured similarly to IMD 10 in the sense that it may include electrodes, sensors, sensing circuitry, processing circuitry, memory and communication circuitry, and may be similarly used to collect parameter data and communicate with external device 12. The sensors and parameter data collected by IMD 10 and sensor device 14 may be different, as described herein.

Fig. 3 is a conceptual side view illustrating an exemplary configuration of IMD 10. In the example shown in fig. 3, IMD 10 may include a leadless subcutaneous implantable monitoring device having a housing 18 and an insulating cover 74. Electrodes 16A and 16B may be formed or placed on the outer surface of cover 74. Circuitry 50 through 56 and 60 described above with respect to fig. 2 may be formed or placed on an inner surface of cover 74 or within housing 18. In the example shown, the antenna 26 is formed or placed on the inner surface of the cover 74, but in some examples may be formed or placed on the outer surface. In some examples, the sensor 58 may also be formed or placed on an inner or outer surface of the cover 74. In some examples, insulating cover 74 may be positioned over open housing 18 such that housing 18 and cover 74 enclose antenna 26, sensor 58, and circuitry 50-56 and 60, and protect the antenna and circuitry from fluids such as body fluids.

One or more of the antenna 26, the sensor 58, or the circuitry 50-56 may be formed on the insulating cover 74, such as by using flip-chip technology. The insulating cover 74 may be flipped over onto the housing 18. When flipped over and placed onto housing 18, components of IMD 10 formed on the inside of insulative cap 74 may be positioned in gap 76 defined by housing 18. The electrode 16 may be electrically connected to the switching circuitry 60 through one or more vias (not shown) formed through the insulating cover 74. The insulating cover 74 may be formed of sapphire (i.e., corundum), glass, parylene, and/or any other suitable insulating material. The housing 14 may be formed of titanium or any other suitable material (e.g., biocompatible material). The electrode 16 may be formed of any of stainless steel, titanium, platinum, iridium, or alloys thereof. In addition, the electrode 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.

Fig. 4 is a block diagram showing an exemplary configuration of the external device 12. In some examples, the external device 12 takes the form of a mobile device, such as a mobile phone, "smart" phone, laptop computer, tablet computer, or Personal Digital Assistant (PDA). In some examples, sensor device 12 is a computing device of patient 4. As shown in the example of fig. 4, the external device 12 includes processing circuitry 80, a storage device 82, communication circuitry 84, and a user interface 86. Although shown as a stand-alone device in fig. 4 for purposes of example, external device 12 may be any component or system that includes processing circuitry or other suitable computing environment for executing software instructions, and for example does not necessarily include one or more of the elements shown in fig. 4 (e.g., in some examples, components such as storage 82 may not be co-located with other components or in the same rack).

In one example, the processing circuitry 80 is configured to implement functionality and/or process instructions for execution within the external device 12. For example, the processing circuitry 80 may be capable of processing instructions (including the application 90) stored in the storage 82. Examples of processing circuitry 80 may include any one or more of the following: 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.

The storage 82 may be configured to store information (including the application 90 and the data 100) within the external device 12. In some examples, storage 82 is described as a computer-readable storage medium. In some examples, the storage 82 includes temporary memory or volatile memory. Examples of volatile memory include Random Access Memory (RAM), dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), and other forms of volatile memory known in the art. In one example, the storage 82 is used by an application 90 running on the external device 12 to temporarily store information during program execution. In some examples, the storage 82 further includes one or more memories configured for long-term storage of information, including for example, non-volatile storage elements. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or Electrically Erasable and Programmable (EEPROM) memory.

External device 12 communicates with other devices, such as IMD 10, sensor device 14, and computing system 20 of fig. 1, using communication circuitry 84. Communication circuitry 84 may include a network interface card such as an ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that may send and receive information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radios.

The external device 12 also includes a user interface 86. The user interface 86 may be configured to provide output to the user using tactile, audio, or video stimuli and to receive input from the user through tactile, audio, or video feedback. User interface 86 may include, for example, a presence-sensitive display, a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting commands from a user, a sound card, a video graphics adapter card, or any other type of device for converting signals into a suitable form that is 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 an understandable output to a user. In some examples, the presence-sensitive display includes a touch-sensitive screen.

Exemplary applications 90 that may be executed by the processing circuitry 80 of the 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 interact 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 user interaction 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 user interaction with IMD 10 and/or IMD data 102. Similarly, the sensor device interface 94 configures the external device 12 to: communicate with the sensor device 14 via the communication circuitry 84, retrieve the sensor device data 104 from the sensor device 14, and store the sensor device data 104 in the memory 82. Sensor device interface 42 also configures user interface 86 for user interaction with sensor device 14 and/or sensor device data 104.

The health monitor 96 may be configured to facilitate a user (such as a patient or caregiver) monitoring the health of the patient 4. 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. The health monitor 96 may also collect information about the patient's health from the user via the user interface 86 and store the information as user-recorded health data 106. In some examples, the health monitor 96 presents a questionnaire or survey to the user seeking health data 106 from the user. The health monitor 96 may present the survey according to a schedule, in response to IMD data 102 and/or sensor device data 104 indicating that the patient 4 experienced a health event, and/or based on the location of the patient 4 (e.g., in response to the location service 98 indicating that the patient 4 entered the geofenced area defined by the geofence data 108). Presenting a survey in response to a health event may facilitate timely capturing of user-recorded health data 106 regarding the health event. In some examples, a geofence area is defined around a clinic, hospital, or the like, and entering such a geofence area may similarly indicate that the patient 4 experienced a health event worth collecting the user's recorded health data 106 in a timely manner. The processing circuitry 80 may also store the time and duration of patient entry into the geofenced area as geofence data 108.

IMD data 102 and sensor device data 104 may include patient parameter data derived from sensed physiological signals, as described herein. As an example, IMD 102 may include periodic (e.g., daily) values of one or more of the following: heart rate, heart rate variability, one or more ECG morphology features or intra-beat intervals, AF and/or other arrhythmia burden (e.g., number of times per cycle, time or percent time), respiration rate, perfusion, and activity level.

As an example, the sensor device data 104 may include one or more of the following: activity level, walking/running distance, resting energy, active energy, exercise minutes, quantification of standing, body weight, body mass index, heart rate, low heart rate events, high heart rate events 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), respiration rate, maximum oxygen volume, blood glucose, peripheral perfusion, and sleep mode.

As an example, the user-recorded health data 106 may include one or more of the following: exercise and activity data, sleep data, symptom data, medical history data, quality of life data, nutritional data, medication or compliance data, allergy data, demographic data, weight, and height. Symptom data may include the time the patient experienced the symptom and its symptom characteristics, such as palpitations, atrial flutter, AF, atrial tachycardia, syncope, or dizziness. Medical history data may relate to a history of AF, stroke, chronic Obstructive Pulmonary Disease (COPD), renal dysfunction or hypertension, a history of a procedure such as ablation or cardioversion, and healthcare utilization. The sensor device data 104 and/or the user-recorded health data 106 may include one or more of the data types listed in table 1 below.

/>

TABLE 1

Fig. 5 is a block diagram illustrating an exemplary configuration of computing system 20. In the illustrated example, computing system 24 includes processing circuitry 202 for executing applications 220, including a monitoring system 222 or any other application described herein. Computing system 20 may be any component or system that includes processing circuitry or other suitable computing environment for executing software instructions and, for example, need not include one or more of the elements shown in fig. 5 (e.g., user interface device 204, communication circuitry 206; and in some examples, components such as storage device 208 may not be co-located with other components or in the same rack). In some examples, computing system 20 may be a cloud computing system distributed across multiple devices.

In the example of fig. 5, computing system 24 includes processing circuitry 202, one or more User Interface (UI) devices 204, communication circuitry 206, and one or more storage devices 208. In some examples, computing system 20 also includes one or more applications 220 (such as monitoring system 222) executable by computing system 20.

In one example, processing circuitry 202 is configured to implement functionality and/or process instructions for execution within computing system 20. For example, the processing circuitry 202 may be capable of processing instructions stored in the storage 208. Examples of processing circuitry 202 may include any one or more of the following: 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.

The one or more storage devices 208 may be configured to store information within the computing device 20 during operation. In some examples, storage 208 is described as a computer-readable storage medium. In some examples, the storage 208 is temporary storage, meaning that the primary purpose of the storage 208 is not long-term storage. In some examples, storage 408 is described as volatile memory, meaning that when the computer is turned off, storage 408 does not hold stored content. Examples of volatile memory include Random Access Memory (RAM), dynamic Random Access Memory (DRAM), static Random Access Memory (SRAM), and other forms of volatile memory known in the art. In some examples, storage 208 is used by software or application 220 running on computing system 20 to temporarily store information during program execution.

The storage 208 may be further configured for long-term storage of information, such as applications 220 and data 230. In some examples, the storage 208 includes a non-volatile storage element. Examples of such non-volatile storage elements include magnetic hard disks, optical disks, floppy disks, flash memory, or various forms of electrically programmable memory (EPROM) or electrically erasable and programmable memory (EEPROM).

In some examples, computing system 20 also includes communication circuitry 206 to communicate with other devices and systems, such as IMD 10 and external device 12 of fig. 1. Communication circuitry 206 may include a network interface card such as an ethernet card, an optical transceiver, a radio frequency transceiver, or any other type of device that may send and receive information. Other examples of such network interfaces may include 3G, 4G, 5G, and WiFi radios.

In one example, computing system 20 also includes one or more user interface devices 204. In some examples, the user interface device 204 may be configured to provide output to a user using tactile, audio, or video stimuli and to receive input from the user through tactile, audio, or video feedback. User interface device 204 may include, for example, a presence-sensitive display, a mouse, a keyboard, a voice response system, a video camera, a microphone, or any other type of device for detecting commands from a user, a sound card, a video graphics adapter card, or any other type of device for converting signals into a suitable form that is human or machine-understandable, a speaker, a Cathode Ray Tube (CRT) monitor, a Liquid Crystal Display (LCD), or any other type of device that can generate an understandable output to a user.

The application 220 may also include program instructions and/or data executable by the processing circuitry 202 of the computing system 20 to cause the computing system 20 to provide the functionality attributed thereto herein. Exemplary application 220 may include monitoring system 22. Other additional applications not shown may be included alternatively or additionally to provide other functions described herein, and are not depicted for simplicity.

In accordance with the techniques of this 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. The processing circuitry 202 stores these data as data 230 in the storage 208.

The computing system 20 may also receive EMR data 230 from the EMR database 22 (fig. 1) via the communication circuitry 206 and store the EMR data 230 in the storage 208. For each of a plurality of patients or subjects, the EMR data 230 can include, for example, a medication history, a surgical procedure history, a hospital history, an emergency or emergency care visit history, a reservation clinic visit history, one or more laboratory or other clinical test results, a procedure history, a cardiovascular history, or a comorbidity such as atrial fibrillation, heart failure, syncope, or diabetes. As a further example, the EMR data 230 can include medical images, such as x-ray images, ultrasound images, echocardiography, anatomic images, medical photographs, radiographic images, and the like.

The monitoring system 222, e.g., implemented by the processing circuitry of the computing system 20, may implement the techniques of the present disclosure, including developing an algorithm based on a training set of parameter data, e.g., IMD data 102 and sensor device data 104 (and in some cases, user-recorded health data 106 and EMR data 230) from a patient or population of subjects, and applying the algorithm to the parameter data of an individual patient 4 to predict the occurrence of clinically significant health events. In some examples, the monitoring system 222 trains one or more Machine Learning (ML) models 224 to predict the health event. The output of the ML model for a particular patient may be a risk level of the health event, such as a probability of the health event, a risk level or probability of the health event occurring within a particular predetermined period of time, and/or whether the risk or probability meets a threshold.

The plurality of patient parameters may include an AF load, one or more activity parameters, and/or any of the physiological parameters described herein. In some examples, the monitoring system 222 may derive features from the parameter data and apply these features as inputs to an algorithm (e.g., the ML model 224) to determine the risk level. One or more of these features may be an AF load feature.

One or more of these features may be an AF load mode feature. The AF load pattern feature may quantify AF load patterns over a plurality of periods including a current period in which the monitoring system 222 is determining a risk level. AF load patterns that include changes in AF relative to overall AF load trend (e.g., spikes or increases) may be associated with increased risk of health events such as other clinically significant episodes of stroke associated with cardiovascular health. In some examples, the monitoring system 222 determines the AF load pattern characteristics by comparing the current AF load value to an average (e.g., mean or median) of the previous AF load values (e.g., determining a difference or ratio therebetween). The current value may be a single value of the current period that includes a shorter term average of values of the current period and a plurality of previous periods. The average may be a longer term average of previous values (e.g., including more values and/or values from more past), which may not include the current period value. In some examples, these characteristics include patient activity characteristics, such as daily activity levels, daytime or nighttime activity levels, or changes in such activity levels relative to a baseline or trend of activity levels.

Generally, the health event can 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 healthcare utilization event, such as hospitalization. In some examples, the health event includes a symptomatic event, such as a clinically significant syncope or dizziness.

The monitoring system 222 may initially train the ML model 224 using, for example, parameter data collected from one or more patient populations during a clinical study. In conventional clinical studies, one or more human experts review the parameter data and gather other information to classify each training set by endpoint as including or not including, for example, a health event. In contrast, the monitoring system 222 may classify the training set of parameter data based on classification data 232 that is automatically collected in response to detection of a trigger, which may reduce costs or human overhead associated with clinical studies.

In some examples, the processing circuitry 202 executing the monitoring system 222 collects classification data 232. In some examples, the classification data is additionally or alternatively collected by other processing circuitry of system 2 (fig. 1), such as processing circuitry 80 of external device 12 (fig. 4), and received by computing system 20 from the other processing circuitry. The classification data 232 includes data indicating an endpoint of a training set of parameter data, such as data indicating whether the patient experienced a health event. The classification data 232 may include data from the user recorded health data 106, the geo-fence data 108, and/or EMR data 230 indicating the endpoint of the patient.

Any one or more of IMD 10, sensor device 14, external device 12, or computing system 20 may detect a trigger for collecting classification data 232. In some examples, the trigger is a geofence event, e.g., detected by the external device 12, that indicates that the patient is going to a hospital or clinic for a threshold amount of time. In such examples, the external device 12 or computing system 20 may present a survey to the patient to gather information about the visit (e.g., confirm the visit and about the health issue being addressed) as user-recorded health data 106 and classification data 230.

In some examples, the trigger includes a feature of the parameter data of the patient meeting a criterion, e.g., indicating that the patient may have undergone a health event. For example, the trigger may be that the AF load meets or exceeds a threshold. Other exemplary triggers may include the feature of any of the physiological parameters described herein reaching a threshold. In some examples, the trigger features may be included within a training set used to train features of the ML model 224, e.g., the monitoring system 222 may select a feature set of input features from among them based on their predicted values for the health event. In response to detection of the trigger feature, the monitoring system 222 or other processing circuitry of the system 2 may collect classification data 230. The collection of the classification data 232 may identify a time of a near-hospital or clinic visit indicating the occurrence of a health event via investigation as discussed above, or by examining the geofence data 108 and/or the EMR data 230.

After training the ML model 224, the monitoring system 222 may apply the ML model to parameter data (e.g., IMD data 102 and sensor device data 104) of a particular patient (such as patient 4) to determine a risk level for the patient to experience a health event. In some examples, the monitoring system 222 may determine whether the risk level of the health event meets a criterion, such as meeting or exceeding a threshold risk level. The monitoring system 222 may take one or more actions based on determining that the risk level meets the criteria, e.g., as described with respect to fig. 8.

Although these techniques are described herein as being performed by the monitoring system 222, and thus by the processing circuitry 202 of the computing system 20, these techniques may be performed by the processing circuitry of any one or more devices or systems of the system 2. In some examples, the external device 12 may additionally or alternatively implement the monitoring system 222, for example, using an ML model 224 trained based on population parameter data and, in some examples, personalized based on parameter data of the patient 4. The Ml model 224 may include, for example, a neural network, a deep learning model, a convolutional neural network, or other type of predictive analysis system. Furthermore, although the techniques of this disclosure are described primarily with respect to examples including the ML model 224, in some examples, the techniques may be implemented with different models or algorithms (such as linear regression, trend analysis, decision trees, or thresholds) that do not necessarily require machine learning, for example.

FIG. 6 is a flow chart illustrating an exemplary technique for training a machine learning model using a training set of parameter data classified based on automatically collected classification data. According to the example shown in fig. 6, monitoring system 222 receives parameter data (such as IMD data 102 and sensor device data 104) for a plurality of patients (300). The monitoring system 222 determines a training set of parameter data (302). The monitoring system 222 classifies the training set of parameter data based on the automatically collected classification data, as discussed above with reference to fig. 5 (304). The monitoring system 222 trains the ML model 224 using a training set of the classified parameter data (306).

FIG. 7 is a flow chart illustrating an exemplary technique for automatically collecting classification data. According to the example of fig. 7, the monitoring system 222 collects parameter data for a patient in a plurality of patients, e.g., during a clinical study and ML model training phase (400). As discussed above with respect to fig. 5, the monitoring system determines if a trigger has occurred (402). As discussed above with respect to fig. 5, exemplary triggers include features in the parameter data meeting a criterion or a geofence event. A geofence event may be an event in which a patient stays within a geofence area (e.g., an area near or around a hospital, emergency care clinic, and/or healthcare provider) for more than a threshold time. The patient staying within the geofenced area beyond the threshold retention time may be evidence of an unplanned or planned healthcare utilization. Examples of features in the parameter data that meet the criteria include AF load or other features derived from the ECG, such as heart rate or heart rate variability that exceeds a threshold, and/or patient activity features that fall below a threshold. If the trigger does not occur ("NO" of 402), the monitoring system 222 may continue to receive patient parameter data and monitor for the trigger (400, 402).

If a trigger occurs ("yes" of 402), the monitoring system 222 collects classification data 232 (404). As discussed above with respect to fig. 5, exemplary classification data 232 may include health data 106 from user records of surveys delivered to patients in response to triggers, or geo-fence data 108 (where parameter data features trigger) or EMR data 230 indicating that the patient is going to a hospital or clinic and in some cases indicating that a health event occurred in close-in time. The monitoring system 222 associates the classification data 232 with the parameter data for final classification of the training set of parameter data (406).

FIG. 8 is a flow chart illustrating an exemplary technique for predicting a health event and responding to the prediction of the health event. As discussed above, exemplary health events include stroke, hospitalization, or other healthcare utilization, or symptomatic events such as symptomatic AF or other cardiovascular events.

According to the example shown in fig. 8, monitoring system 222 receives parameter data for patient 4, such as IMD data 102 and sensor device data 104 (500). The monitoring system 222 applies features derived from the parameter data to the ML model 224 (502). As discussed above, these features may include AF features, such as AF load pattern features, and in some cases, patient activity features or other features derived from another physiological signal. The monitoring system 222 determines a risk level for the health event based on the application of these features to the ML model 224, e.g., the ML model 224 outputs a probability of the health event occurring within a predetermined period of time (e.g., days). The monitoring system 222 determines whether the risk level of the health event meets a criterion, such as whether a threshold is met or exceeded (504). If the risk level does not meet the criteria ("NO" of 504), the monitoring system 222 continues to receive the parameter data and apply features to the ML model 224, e.g., on a cycle-by-cycle basis (500, 502). Based on the risk level meeting the criteria ("yes" of 504), the monitoring system 222 may perform one or more of the optional actions shown in fig. 8 (506-512).

The monitoring system 222 may change the sensing behavior of the system 2 (506). For example, monitoring system 222 may direct IMD 10 and/or sensing device 104 to employ a more sensitive setting for sensing circuitry 52 or sensor 58, sample physiological signals at a higher rate, and/or make periodic measurements at a higher frequency.

As another example, the monitoring system 222 may provide instructions to the patient 4 to take a medication or modify the medication administration (508). The drug may be an anticoagulant. The instruction may be to take an on-demand dose of the drug or to change the dose of the drug.

As another example, the monitoring system 222 may prioritize the patient 4 or a portion of the parameter data associated with the risk level of the health event in a notification to a clinician treating the patient 4 (810). The monitoring system 222 implementing the techniques of this disclosure may advantageously relieve the burden of treating a patient by prioritizing the patient and/or patient data in the notification from the system 2 based on the risk level meeting criteria indicative of clinically significant risk of a health event. In some examples, the monitoring system 222 relieves the load by determining which rhythms (e.g., clinically relevant patient reports that present the determined symptoms) should be transmitted or alerted to the patient and/or clinician.

As another example, the monitoring system 222 may determine a classification of parameter data associated with a risk level of a health event and create a training set of parameter data for intensive training of the ML model 224 and/or personalization of the ML model 224 for the patient 4, e.g., to create a patient-specific version of the ML model 224 (512). The monitoring system 222 may collect classification data 232 for classifying the training set of parameter data using any of the techniques described herein, for example, with reference to fig. 7.

The health monitor 96, executed by the processing circuitry 80 of the external device, may implement portions of the techniques described with respect to fig. 6-8. For example, the health monitor 96 may present surveys and collect answers from the patient 4, present instructions to the patient 4 to take medications, and provide enabling messaging between the patient 4 and the clinician.

In some examples, to enable real-time patient management, the health monitor 96 may follow a predetermined protocol to automatically push patient actions based on a particular, detected parameter data pattern. For example, the health monitor 96 may see a predetermined clinically significant degree of AF burden and recommend modification of the patient's anticoagulant medication. As discussed above, actions may additionally or alternatively be motivated based on the risk level of the health event meeting a criterion. In some examples, computing system 20 may provide an interface to a clinician via network interface or user interface device 204 to specify parameter data characteristics or risk level criteria that will trigger a clinical action (e.g., AF duration for more than 1 hour or a probability of stroke exceeding a threshold probability), as well as a clinical action that the patient will need to take (e.g., increase the dose of anticoagulant drug). In some examples, the health monitor 96 may provide on-demand (PRN) medication requests. In some examples, the health monitor 96 may have a communication tab and a priority status that would require confirmation of the action before allowing the patient 4 to continue moving to other features of the health monitor 96, such as viewing parameter data of the patient 4.

Fig. 9 is a graph showing parameter data for a plurality of patient parameters over a period of time around a stroke event (time 0). In the example of fig. 9, the patient parameters include patient activity parameters (daily life activity, related to the amount of patient motion exceeding a threshold during the time of day), heart Rate Variability (HRV), night heart rate, day heart rate, and AF time (or AF load). As can be seen in the example shown, both AF time and heart rate related parameters increase and patient activity decreases during the days prior to stroke.

Fig. 10 is a graph showing time-series values of moving averages of parameter data of patient parameters. In the example shown in fig. 10, the patient parameter is daily life activity, although similar techniques may be applied to any of the other patient parameters described herein. Fig. 10 illustrates a technique for quantifying features associated with patient parameters deviating from their baseline or trend, which may indicate an increased risk of a health event. In some examples, the monitoring system 222 summarizes the trend with at least two Simple Moving Averages (SMAs) and uses a comparison or offset of the two SMAs to capture clinically significant changes in patient parameters. One SMA may be a shorter-term SMA and the other a longer-term SMA, e.g., comprising less recent values of patient parameters than a shorter-term SMA. Patient parameter values occurring within a predetermined number of days of a health event (e.g., stroke) may be identified. Under sample control, cases may be 1:1, and all offsets and covariates can be evaluated in one model. The monitoring system 22 may compare the goodness of fit of each variable (patient parameter) to determine the relative importance of the variables.

Fig. 11 is a graph showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke. Patient parameters in the example of fig. 11 are AF load (AFB), daytime Heart Rate (DHR), daily life Activity (ADL), nocturnal Heart Rate (NHR), and Heart Rate Variability (HRV). The statistical significance shown in fig. 11 is determined based on parameter data collected from a plurality of patients including patients suffering from stroke. As shown in fig. 11, AF loading was found to be a significantly better stroke predictor than other patient parameters.

Experimental analysis showed that changes in AF load occurred within a long-term trend (21+ days) prior to stroke event. In the long term, the AF load can be considered as the main predictor. More specifically, the short-term trend of AF load continues to grow over the long-term trend, possibly predictive of stroke. The predictive power of AF load may be 4 times higher when acute, short-term changes are compared to long-term trends.

Fig. 12 is another chart showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke. Fig. 12 is similar to fig. 11 but includes additional patient parameters. Specifically, FIG. 12 includes a history of AF, CHADS-VASc scores, past oral anticoagulants (prior_aac), and a history of chronic kidney disease. Although FIG. 12 shows that past stroke is 13 times more important as a predictor of stroke than AF load, AF load is the primary predictor after CHADS-VASc.

Fig. 13A-13D are graphs showing experimentally determined statistical significance of a plurality of patient parameters in predicting stroke for different patient populations. Fig. 13A shows statistical significance of a plurality of patient parameters in predicting stroke for a patient with past AF ablation. Fig. 13B shows statistical significance of multiple patient parameters in predicting stroke in patients with past AF management. Fig. 13C shows statistical significance of a plurality of patient parameters in predicting stroke for a patient with a past stroke. Fig. 13D shows the statistical significance of multiple patient parameters in predicting stroke for a patient in which AF is suspected to be unacknowledged.

Fig. 14A-14D are graphs showing experimentally determined statistical significance of multiple patient parameters in predicting hospitalization (a subset of healthcare utilization) for different patient populations. Fig. 14A shows statistical significance of a plurality of patient parameters in predicting stroke for a patient with past AF ablation. Fig. 14B shows the statistical significance of multiple patient parameters in predicting stroke in patients with past AF management. Fig. 14C shows statistical significance of a plurality of patient parameters in predicting stroke for a patient with a past stroke. Fig. 14D shows the statistical significance of multiple patient parameters in predicting stroke for a patient in which AF is suspected to be unacknowledged.

Fig. 15 is a graph showing analysis of AF load pattern characteristics for predicting stroke and Health Care Utilization (HCU). This analysis shows that for both stroke and HCU, a surge in AF load (accompanied by a lower patient activity level in some cases) predicts events that occur over a certain time frame.

Fig. 16A and 16B are graphs showing AF load patterns for patients experiencing stroke or healthcare utilization events for different patient populations, respectively. AF load patterns (such as those shown in fig. 16A and 16B) signal subclinical changes indicative of stroke and HCU risk elevation cycles.

A retrospective cohort study was performed on ICM patients (including real LINQ ^TM ICM) to determine if rule-based algorithms are available to stratify the risk of short-term HCU, these algorithms check for changes in baseline ICM parameters. The occurrence of HCU was obtained as a study endpoint from unidentified claim data. A patient is marked as developing an HCU if the patient's claim history includes at least one encounter with a cardiovascular DRG or diagnostic code in an in-patient or out-patient hospital, emergency room, or out-patient surgery center. If the patient uses HCU multiple times, the first occurrence of HCU is recorded.

ICM-based diagnostic parameters evaluated in the study included total daily AT/AF load (milliseconds/day), total patient activity (e.g., time of patient supra-threshold movement (minutes/day)), average ventricular rate (night and day), and HRV. Patients with daily follow-up times less than 21 days post-implantation or with follow-up intervals greater than or equal to 30 days were excluded from the cohort. Missing data due to daily follow-up intervals is interpolated by forward filling the last known value of each diagnostic parameter. The follow-up history is only two years, unless there is an HCU, in which case the follow-up ends the day before the event. Patients without any device detecting AT/AF time during the two year follow-up period were excluded from the cohort.

To define the diagnostic time pattern of the study, each parameter was evaluated as a Cumulative Moving Average (CMA) from the second day after implantation, and SMA for different historical periods (1, 2, 3, 5, 8, 13, and 21 days) from 21 days after implantation on each patient follow-up date. For this study, the SMA was biased _{a_b} Representing SMA _a And SMA (shape memory alloy) _b The difference between, wherein the longer period SMA is subtracted from the shorter period SMA (i.e., a<b) A. The invention relates to a method for producing a fibre-reinforced plastic composite The shift of period p from its corresponding CMA is denoted SMA _{p_c} 。

Fig. 17 is a graph showing AT/AF time (load) detected during a monitoring period. The vertical bars show the AF burden (AT/AF time) of the patient undergoing a sub-period (in this case, a day) of AT/AF. The graph of fig. 17 further includes three trend lines showing CMA for AF load 600, 21-day SMA for AF load 602, and the difference between 21-day SMA and CMA for AF load 604, respectively.

For this study, the occurrence of HCU was considered an unbalanced, binary classification problem. A recursive partitioning and regression tree algorithm (RPART) is used to predict which follow-up days HCU occurs using diagnostic parameters and moving average offsets as predictors. Random sampling methods for imbalance learning are used within the boot routine to facilitate algorithm convergence and improve classifier accuracy. HCU events were oversampled by marking the first five days of occurrence as events. For patients who have experienced HCU, the follow-up is ended the day before the event occurs to prevent using device measurements made on the day of the event occurrence, which would introduce a look-ahead bias in the modeling. For each boot iteration:

1. patients were randomly divided into training (70%) and validation (30%).

2. For the training set, the unlabeled days are undersampled, equal to the labeled days.

3. The classification tree using 10-fold cross-validation is suitable for a balanced training set.

4. The model fit in step 3 is trimmed to its minimum cross-validation error.

5. The split information of the model fitting in step 4 has been saved.

6. The unbalanced validation set is classified using the model fit in step 4.

7. And (5) saving the classification statistics of each terminal node in the step (6).

Each split of the end nodes is recorded as a 3-tuple [ predictor name, comparison, index ] and its corresponding HCU rate and patient count for both the training set and the validation set. If a node has multiple splits, each split is saved as a separate entry. In this case, the utilization and patient count would be the same for all splits in each node.

The scatter plot of the decision tree terminal nodes shows the relationship between the tagged HCU rate and the patient percentage for identifying patterns in the AF load classification tree structure that will stratify healthcare event risk. The algorithms that define these modes are:

1. areas of the scatter plot where the patient percentage is locally maximum are visually identified.

2. If the region is unique to the AT/AF time, rectangular coordinates of event risk and patient percentage surrounding the region are defined.

3. If the area is not unique to the AT/AF time, then

i. The upper and lower limits of the patient percentages are set equal to the local maximum.

Subtracting 0.01 from the lower limit of the patient percentage.

Setting the lower and upper limits of the event rate as the corresponding locations at which the scatter plot intersects the lower limit of the patient percentage defined in the previous step.

4. Nodes within the rectangular region are selected.

5. Grouping by pair [ predictor name, comparison ].

6. The number of times each pair is selected is calculated, the number of times each pair is selected as a percentage of all guide classification trees, and the average of the [ exponential ] values.

7. If the region is not unique to the AT/AF time, then steps 3. Ii-6 are repeated until the modality predictors are selected in AT least 10% of all classification trees.

8. The 3-tuple [ predictors, comparisons, mean index values ] are ordered in descending order according to the selectivity.

9. An elbow in the selectivity (i.e., where the selectivity drops by about 50%) is identified.

10. AF load pattern is defined as 3-tuple with selectivity higher than the elbow point identified in the previous step.

An equal scale descriptive analysis and test was performed to compare the odds ratio of the AF load pattern to clinically relevant thresholds of duration and number.

The boot routine runs 3,000 times to create an equal number of classification trees. Fig. 18 presents a scatter plot of 50751 terminal nodes from marked HCU rate and patient percentage of balance training data. The points on the graph represent unique end nodes. When the definition of a single node includes multiple splits and each split has a different parameter (e.g., AT/AF time >1 hour and daily activity <100 minutes and nocturnal heart rate >80 times/minute), a single node may be represented across diagnostic parameters. Three local maxima are identified and represented as shaded areas A, B and C. The absence (a and C) or infrequent (B) nodes of daily activity and heart rate parameters indicate that these areas are primarily defined by AT/AF time. Region D is derived from analysis of regions A, B and C and is defined later in the result.

Table 2: top split for per terminal node distribution of training data

Table 2 (above) presents a summary of the first five splits performed per region. Resolution with selectivity higher than its corresponding elbow point is shown in bold. These highlighted splits together define the AF-load mode for a given area. Mode a is defined by an AF load CMA of less than about 1 second. This pattern exists in all 3,000 decision trees and describes a follow-up period (77% incidence) before the first detection of AT/AF and a relative sinus rhythm recovery period (23% incidence) after the device detected AT/AF. Mode C is defined by an AF load CMA of greater than about 1 second and an AF load of about 21 days SMA greater than its historical average. This pattern exists in 25% of the decision tree and describes the relative spike or trend of increase in daily AF load. Mode B is defined by an AF load CMA of greater than about 1 second, but unlike mode C, it has a reduced AF load of 21 days SMA that is less than its historical average. An increase in 1 day SMA (daily load) relative to 21 days SMA indicates that pattern C signals a lower than average load shed period relative to the patient, which may occur after a load boost period. Fig. 19 presents an example graphical illustration of these patterns in AF load data for a single HCU patient map.

The HCU rate and patient percentage of the marker are calculated from training data for the AF load and duration thresholds. The number threshold is defined as a daily AF load of greater than 5% (72 minutes); the duration threshold is defined as continuous AF for more than one hour. For the corresponding thresholds, the log dominant event rates were 0.369 and 0.386, respectively, and the patient percentages were 12.9% and 7.6%, respectively. Table 2, region D presents a summary of the first five splits in the terminal node scatter plot with a log dominant event rate greater than 0.369 and a patient percentage greater than 12.9%. The first three splits define part of the substructure of pattern C, where the CMA for daily activity falls below 76 minutes. When applied to a balanced training set, pattern D was selected 10.4% of the time with a log odds ratio of 0.368, which was not statistically different from the other log odds ratios (poisson regression, p >0.5 for all threshold coefficients).

Figure 20 presents a scatter plot of terminal nodes scored according to the marked HCU rate and patient percentage of the unbalanced validation set. The overall distribution is similar in shape to the training data (fig. 18). Different color shading shows different threshold patterns, with the lightest shaded points representing nodes not covered by the pattern. The AF load mode (A-C) provides a broad coverage of the end node distribution, clearly dividing the risk of an event (B versus A, odds Ratio (OR) 3.82, 95% CI 3.59-4.07; C versus A, OR 8.25, 95% CI 7.84-8.69). The inclusion of a daily activity threshold (D) provides more specific coverage, with the greatest risk of HCU in AF load mode (D versus a, OR 11.66, 95% ci 10.63-12.79).

Fig. 21 presents a venn plot of AF load threshold counts for a validation set. Table 3 (below) gives the statistics for each threshold and its mutually exclusive subset. About 32% of the mode D threshold (6,594/20,858) is mutually exclusive with the number and duration thresholds and represents a 33% increase in event capture rate (212/644). Tests using poisson regression versus odds differences showed that the intersection coefficients of all three thresholds were statistically significant (p < 0.10); the remaining coefficients have no statistical difference (p >0.10 for all coefficients). About 23% of patients experience only the mode D threshold, with an expected follow-up rate of 18.2%, or 66 days per year.

Table 3: AF load threshold statistics for validation data

In table 3, the count indicates the number of times the threshold is met; event, number of labeled HCUs; advantageously, the ratio of event counts to threshold counts is divided by the group mean event rate of the validation set; patients, the number of patients reaching the threshold for at least one day being a percentage of the total number of patients in the validated set; follow-up, for patients who have a threshold at least once, the number of days to reach the threshold is a percentage of the total follow-up number of days. Note that: each count over the time is mutually exclusive, rather than counting by patient. The patient may experience different thresholds during the follow-up. Thus, the sum of the patient and the percentage follow-up does not reach 100%.

Analysis of the AF load pattern in the study demonstrated a correlation between load increase and risk, and more specifically, the trend of increasing AF load (e.g., daily) over time correlated with greater risk of HCU, particularly when accompanied by a decline in daily activity. The pattern predicted healthcare event for AF loads less than about 1 hour is comparable to the number and duration thresholds of greater than 1 hour. The AF load mode demonstrates additional event captures that supplement the number and duration thresholds. AF load as a risk factor for HCU is related to the patient's historical load.

The study shows the values of AF load and patient activity as parametric data from which features can be derived and then applied to algorithms or models to determine the likelihood of an event, such as an HCU event, as described herein. Features derived from AF load may include AF load pattern features such as changes (e.g., spikes or increases) in AF load relative to total AF load trend. For example, the AF load pattern characteristics may include one or more offsets between SMA for different backtracking periods and/or between SMA and CMA for backtracking periods. As described herein, the model to which such features are applied may be machine-learned or rule-based, e.g., involving decision trees and/or thresholds.

It should be understood that the various aspects disclosed herein may be combined in different combinations than specifically presented in the specification and drawings. It should also be appreciated that, depending on the example, certain acts or events of any of the processes or methods described herein can be performed in a different order, may be added, combined, or omitted entirely (e.g., not all of the described acts or events may be required to perform the techniques). Additionally, although certain aspects of the present disclosure are described as being performed by a single module, unit, or circuit for clarity, it should be understood that the techniques of the present disclosure may be performed by a combination of units, modules, or circuitry associated with, for example, a medical device.

Embodiment 1. A system comprising processing circuitry configured to: receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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 includes AF load; deriving one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to the model; and determining a risk level of the health event for the patient based on the application of the one or more features to the model.

Embodiment 2. The system of embodiment 1 wherein the AF load mode feature includes a comparison between the current AF load value and an average of AF load values.

Embodiment 3. The system of embodiment 2 wherein the current AF load value comprises a shorter term average of AF load values and the average of AF load values comprises a longer term average of AF load values.

Embodiment 4. The system of any of embodiments 1-3, wherein the one or more characteristics include patient activity characteristics.

Embodiment 5. The system of any of embodiments 1-4, wherein the health event comprises a stroke.

Embodiment 6. The system of any of embodiments 1-4, wherein the health event comprises a healthcare utilization event.

Embodiment 7. The system of any of embodiments 1-4, wherein the health event comprises a symptomatic event.

Embodiment 8. The system of any of embodiments 1-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.

Embodiment 9. The system of any of embodiments 1-8, wherein the risk level comprises a risk that the health event will occur within a predetermined period of time.

Embodiment 10. The system of any of embodiments 1-9, wherein the processing circuitry is configured to determine whether the risk level of the health event meets a criterion.

Embodiment 11. The system of embodiment 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 meeting the criterion.

Embodiment 12. The system of embodiment 10 or 11, wherein the processing circuitry is configured to deliver medication guidance to the patient based on the risk of the health event meeting the criteria.

Embodiment 13. The system of embodiment 12, wherein the instructions comprise on-demand dosing instructions for the drug.

Embodiment 14. The system of embodiment 12 or 13, wherein the drug comprises an anticoagulant.

Embodiment 15 the system of any one of embodiments 10-14, wherein the processing circuitry is configured to deliver a notification to a clinician based on the risk of the health event meeting the criteria.

Embodiment 16. The system of any of embodiments 10-15, wherein the processing circuitry is configured to: determining whether the health event occurred after determining that the risk of the health event meets the criteria; determining a training set of parameter data for training the model based on the parameter data of the patient; classifying a training set of the parameter data based on whether the health event occurred; and training the model with the training set of classified parameter data.

Embodiment 17. The system of embodiment 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 meets the criteria.

Embodiment 18. The system of embodiment 16 or 17 wherein to determine whether the health event occurred, the processing circuitry is configured to determine whether a geo-fence event occurred at a time proximate to the risk of the health event meeting the criteria.

Embodiment 19. The system of any of embodiments 16-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 meets the criteria.

Embodiment 20. The system of any of embodiments 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.

Embodiment 21 the system of any one of embodiments 1-20, wherein the system comprises one or more sensing devices including an implantable medical device and an external sensing device as a peripheral device for the patient computing device.

Example 22. A method, the method comprising: receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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 includes AF load; deriving one or more features based on the parameter data for the plurality of parameters, wherein the one or more features include at least one AF load pattern feature; applying the one or more features to the model; and determining a risk level of the health event for the patient based on the application of the one or more features to the model.

Embodiment 23. The method of embodiment 22 wherein the AF load mode feature includes a comparison between the current AF load value and an average of AF load values.

Embodiment 24. The method of embodiment 23 wherein the current AF load value comprises a shorter term average of AF load values and the average of AF load values comprises a longer term average of AF load values.

Embodiment 25. The method of any of embodiments 22 to 24, wherein the one or more characteristics comprise patient activity characteristics.

Embodiment 26. The method of any of embodiments 22 to 25, wherein the health event comprises a stroke.

Embodiment 27. The method of any of embodiments 22 to 25 wherein the health event comprises a healthcare utilization event.

Embodiment 28. The method of any of embodiments 22 to 25, wherein the health event comprises a symptomatic event.

Embodiment 29. The method of any of embodiments 22-28 wherein determining the risk level of the health event comprises determining a probability of occurrence of the health event.

Embodiment 30. The method of any of embodiments 22-29, wherein the risk level comprises a risk that the health event will occur within a predetermined period of time.

Embodiment 31. The method of any of embodiments 22-30, further comprising determining whether the risk level of the health event meets a criterion.

Embodiment 32. The method of embodiment 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 meeting the criteria.

Embodiment 33. The method of embodiment 31 or 32, further comprising delivering drug guidelines to the patient based on the risk of the health event meeting the criteria.

Embodiment 34. The method of embodiment 33, wherein the instructions comprise on-demand dosing instructions for the drug.

Embodiment 35. The method of embodiment 33 or 34, wherein the drug comprises an anticoagulant.

Embodiment 36 the method of any one of embodiments 31-35, further comprising delivering a notification to a clinician based on the risk of the health event meeting the criteria.

Embodiment 37 the method of any one of embodiments 31 to 36, further comprising: determining whether the health event occurred after determining that the risk of the health event meets the criteria; determining a training set of parameter data for training the model based on the parameter data of the patient; classifying a training set of the parameter data based on whether the health event occurred; and training the model with the training set of classified parameter data.

Embodiment 38. The method of embodiment 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 meets the criteria.

Embodiment 39. The method of embodiment 37 or 38 wherein determining whether the health event occurred comprises determining whether a geo-fence event occurred at a time proximate to the risk of the health event meeting the criteria.

Embodiment 40. The method of any of embodiments 37-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 meets the criteria.

Embodiment 41. The method of any of embodiments 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 the patient computing device.

Embodiment 42. A system comprising processing circuitry configured to: receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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; determining a training set of parameter data for training a model based on the parameter data of the patient; classifying the training set of parameter data based on classification data automatically collected in response to detection of the trigger; and training the model with the training set of classified parameter data.

Embodiment 43. The system of embodiment 42, wherein the plurality of patient parameters includes AF load.

Embodiment 44 the system of embodiment 42 or 43, wherein the plurality of patient parameters includes patient activity parameters.

Embodiment 45 the system of any one of embodiments 42 to 44, wherein the processing circuitry is configured to: classifying the training set of parameter data into a first category if the patient has a health event, or classifying the training set of parameter data into a second category if the patient has no health event; and training the machine learning algorithm to determine a risk of the health event.

Embodiment 46. The system of embodiment 45 wherein the health event comprises a stroke.

Embodiment 47. The system of embodiment 45 wherein the health event comprises a healthcare utilization event.

Embodiment 48. The system of embodiment 45 wherein the health event comprises a symptomatic event.

Embodiment 49 the system of any of embodiments 42-48 wherein the processing circuitry is configured to collect the classification data in response to detection of the trigger.

Embodiment 50. The system of embodiment 49 wherein the trigger comprises a geofence event.

Embodiment 51. The system of embodiment 49 wherein the trigger includes a feature of the parameter data meeting a criterion.

Embodiment 52. The system of embodiment 51 wherein the feature is included in a training set for training the features of the model.

Embodiment 53. The system of embodiment 51 or 52, wherein the feature comprises an AF load feature.

Embodiment 54 the system of any of embodiments 49 and 51-53 wherein to collect the classification data, the processing circuitry is configured to determine whether a geofence event occurred at a time proximate to the detection of the trigger.

Embodiment 55 the system of any of embodiments 49-54, wherein to collect the classification data, the processing circuitry is configured to retrieve data from an electronic medical records database.

Embodiment 56 the system of any of embodiments 49-55, wherein to collect the classification data, the processing circuitry is configured to prompt the patient to complete a survey.

Embodiment 57 the system of any one of embodiments 42-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.

Embodiment 58 the system of any of embodiments 42 to 57, wherein the system comprises one or more sensing devices including an implantable medical device and an external sensing device as a peripheral device for the patient computing device.

Example 59. A method, the method comprising: receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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; determining a training set of parameter data for training a model based on the parameter data of the patient; classifying the training set of parameter data based on classification data automatically collected in response to detection of the trigger; and training the model with the training set of classified parameter data.

Embodiment 60. The method of embodiment 59, wherein the plurality of patient parameters includes AF load.

Embodiment 61. The method of embodiment 59 or 60, wherein the plurality of patient parameters includes patient activity parameters.

Embodiment 62 the method of any one of embodiments 59 to 61, wherein the processing circuitry is configured to: classifying the training set of parameter data into a first category if the patient has a health event, or classifying the training set of parameter data into a second category if the patient has no health event; and training the machine learning algorithm to determine a risk of the health event.

Embodiment 63. The method of embodiment 62 wherein the health event comprises a stroke.

Embodiment 64. The method of embodiment 62, wherein the health event comprises a healthcare utilization event.

Embodiment 65. The method of embodiment 62 wherein the health event comprises a symptomatic event.

Embodiment 66. The method of any of embodiments 59-65 wherein the processing circuitry is configured to collect the classification data in response to detection of the trigger.

Embodiment 67. The method of embodiment 66 wherein the trigger comprises a geofence event.

Embodiment 68. The method of embodiment 66 wherein the triggering includes the feature of the parameter data meeting a criterion.

Embodiment 69. The method of embodiment 68 wherein the feature is included in a training set of features used to train the model.

Embodiment 70. The method of embodiment 68 or 69 wherein the characteristic comprises an AF load characteristic.

Embodiment 71 the method of any of embodiments 66 or 68-70, wherein collecting the classification data comprises determining whether a geo-fence event occurred proximate to the time of the detection of the trigger.

Embodiment 72. The method of any of embodiments 66-71, wherein collecting the classification data comprises retrieving data from an electronic medical records database.

Embodiment 73. The method of any of embodiments 66-72, wherein collecting the classification data comprises prompting the patient to complete a survey.

Embodiment 74 the method of any one of embodiments 66-73, wherein the one or more sensing devices include an implantable medical device and an external sensing device that is a peripheral device for the patient computing device.

Embodiment 75. A method comprising any combination of the exemplary methods described herein.

Embodiment 76. A system comprising processing circuitry configured to perform the method of any one or more of embodiments 22-41 and 59-75.

Embodiment 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 embodiments 22-41 and 59-75.

Embodiment 78. A system comprising processing circuitry configured to: deriving one or more characteristics based on parameter data of the 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 parameter data comprises AF load data, wherein the one or more characteristics comprise one or more offsets between moving averages of the AF load data for different periods of time; applying the one or more features to the rule-based model; and determining a risk level of the healthcare utilization event for the patient based on the application of the one or more features to the rule-based model.

Embodiment 79. The system of embodiment 78 wherein the parameter data comprises activity data of the patient.

Embodiment 80. The system of embodiments 78 or 79, wherein the parameter data comprises heart rate data.

Embodiment 81 an apparatus comprising means for any of the embodiments described herein.

In one or more examples, the techniques described 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 corresponding to tangible media, 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).

The 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. Thus, 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. In addition, the present techniques may 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.

Claims (15)

1. A system, the system comprising processing circuitry configured to:

receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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 includes AF load;

deriving one or more features based on the parameter data of the plurality of parameters, wherein the one or more features include at least one AF load mode feature;

applying the one or more features to the model; and

a risk level of a health event for the patient is determined based on the application of the one or more features to the model.

2. The system of claim 1, wherein the AF load pattern characteristics comprise a comparison between a current AF load value and an average of AF load values.

3. The system of claim 2, wherein the current AF load value comprises a shorter term average of AF load values, and the average of AF load values comprises a longer term average of AF load values.

4. The system of claim 1, wherein the one or more characteristics include patient activity characteristics.

5. The system of claim 1, wherein the health event comprises a stroke.

6. The system of claim 1, wherein the health event comprises a healthcare utilization event.

7. The system of claim 1, wherein the health event comprises a symptomatic event.

8. The system of claim 1, 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.

9. The system of claim 1, wherein the risk level comprises a risk that the health event will occur within a predetermined period of time.

10. The system of claim 1, wherein the processing circuitry is configured to determine whether the risk level of the health event meets a criterion.

11. The system of claim 1, 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 meeting the criteria.

12. A method, the method comprising:

receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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 includes AF load;

deriving one or more features based on the parameter data of the plurality of parameters, wherein the one or more features include at least one AF load mode feature;

applying the one or more features to the model; and

a risk level of a health event for the patient is determined based on the application of the one or more features to the model.

13. A system, the system comprising processing circuitry configured to:

receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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;

determining a training set of parameter data for training a model based on the parameter data of the patient;

classifying a training set of the parameter data based on classification data automatically collected in response to detection of a trigger; and

The model is trained with a training set of the classified parameter data.

14. A method, the method comprising:

receiving parameter data for a plurality of parameters of a patient, wherein the parameter 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;

determining a training set of parameter data for training a model based on the parameter data of the patient;

classifying a training set of the parameter data based on classification data automatically collected in response to detection of a trigger; and

the model is trained with a training set of the classified parameter data.

15. A system, the system comprising processing circuitry configured to:

deriving one or more features based on parameter 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 parameter data comprises AF load data, wherein the one or more features comprise one or more offsets between moving averages of the AF load data for different periods of time;

Applying the one or more features to a rule-based model; and

a risk level of a healthcare utilization event for the patient is determined based on the application of the one or more features to the rule-based model.