Systems and methods for autonomously and remotely monitoring, analyzing and responding to physiological and diagnostic device data from medical implants - Patents.com

Abstract

The present invention relates to a system for remote patient monitoring. The system comprises at least one medical device, a patient remote device, a remote monitoring server device (RMS), and a healthcare professional (HCP) remote device. The at least one medical device is configured to automatically collect patient physiological data and transmit the collected patient physiological data to the RMS via the patient remote device. The RMS is configured to form an interface connection with the HCP remote device via a healthcare professional interface including a web-based portal and / or an app-based portal to allow the healthcare professional to access the collected patient physiological data on the RMS. In this way, it is possible to provide continuous remote monitoring of physiological data from medical implants without the need for patient interaction. The monitoring data is available to a physician via a web-based and / or app-based user portal on demand. The RMS can provide frequent (e.g. daily) automatic reporting of physiological measurements, e.g. core body temperature indicative of sleep disorders, activity levels, fever (e.g. potential infections).

Description

[Technical field]

[0001] The present disclosure describes systems and methods for remote patient monitoring. [Background technology]

[0002] State-of-the-art implantable pacemakers, cardiac monitors, neurostimulators, and similar Implanted Medical Devices (IMDs) communicate with a Clinician User Interface (CUI) device ("Programmer") during an encounter with a clinician. During the encounter, the Programmer provides a real-time view of diagnostic and technical data.

[0003] Common systems lack data capture capabilities. For example, evaluation of Spinal Cord Stimulation (SCS) patient status for pain management is currently limited to qualitative, subjective feedback from the patient and / or interrogation data collected during follow-up visits within the clinic. These processes generally lack objective assessment tools for integrated patient and device current status review, or review of patient longitudinal data.

[0004] Many modern implantable device systems are also able to periodically transmit diagnostic and technical data to a server (e.g. a "Remote Monitoring Server" or RMS). Clinicians access this data via a secure website or mobile app, allowing them to view the patient's status remotely.

[0005] However, the User Interfaces (UIs) provided for clinicians to interact with this data typically do not provide services beyond displaying interrogation reports of patient IMD collected in the exam room and / or via remote monitoring. The reports available are often too limited for clinicians to provide more complex care to their patients or use this data in other aspects of clinical practice management.

[0006] Additionally, data transmission delays in existing remote monitoring designs are too limiting for clinicians to provide more complex care to patients. For example, neurostimulation systems require bidirectional feedback from the patient to the clinician to effectively adjust stimulation therapy. Providing such interaction remotely is not possible with current systems. In cardiac rhythm management (CRM), it is desirable to be able to view the intracardiac electrogram (IEGM) and device status in real time when the patient contacts the clinic to report the occurrence of an event. Viewing the IEGM and system data in real time allows clinicians to accurately triage the patient and determine the next steps required. Although CRM devices are typically capable of detecting and recording events, it should not be assumed that the device will always be correctly programmed to detect events. Furthermore, because these implantable devices typically transmit only based on internal triggers (e.g., event detection, scheduled update transmissions), the data transmitted from these devices is typically not current at the time of the office check. Thus, devices are typically interrogated at the start of any outpatient visit, resulting in clinical labor costs and time delays. If interrogation is available remotely to the clinic, this function can be performed prior to the patient visit. Summary of the Invention [Means for solving the problem]

[0007] The present disclosure provides a system, a method, a computer program product and a computer readable data carrier for remote patient monitoring according to the independent claims that overcome the drawbacks of the prior art. Further embodiments are incorporated in the dependent claims.

[0008] According to a first aspect of the present disclosure, a system for remote patient monitoring is provided. The system includes at least one medical device, a patient remote device, a remote monitoring server device (RMS), and a healthcare professional (HCP) remote device. The at least one medical device is configured to automatically collect patient physiological data and transmit the collected patient physiological data to the RMS via the patient remote device. The RMS is configured to form an interface connection with the HCP remote device via a healthcare professional interface including a web-based portal and / or an app-based portal to enable the healthcare professional to access the patient physiological data collected on the RMS.

[0009] The proposed system may have the advantage of being able to provide continuous remote monitoring of physiological data from medical implants without the need for patient interaction. The monitoring data is available to the physician via a web-based and / or app-based user portal on demand. The RMS may provide frequent (e.g. daily) automated reporting of physiological measurements, e.g. sleep disturbances, activity levels, core body temperature indicative of fever (e.g. potential infection). The monitoring capabilities may be turned on via a medical professional interface, a manufacturer support interface and / or a patient interface, as described below.

[0010] The proposed system can be used in multiple areas of medical device applications, such as Spinal Cord Stimulation (SCS), Cardiac Rhythm Management (CRM) and many other medical fields utilizing implantable medical devices, such as Deep Brain Stimulation (DBS), Occipital Nerve Stimulation (ONS), Trigeminal Nerve Stimulation (TNS), Vagus Nerve Stimulation (VNS), Phrenic Nerve Stimulation, Gastric Electrical Stimulation and Sacral Nerve Stimulation (SNS).

[0011] According to one embodiment of the present invention, the system is configured to provide real-time remote programming and / or interrogation of at least one medical device using a medical professional interface via a patient remote device.

[0012] In this way, the clinician has control over how and when data is captured since data capture and initiation of data transmission are independent of the patient. The clinic has control over receipt of information transmitted from the implant and can respond to receipt of data as it is received. This can improve workflow for clinical review of data.

[0013] Additionally, clinical experts (e.g., corporate service representatives) can remotely connect and check the status of the implanted device and send new or updated treatment programs to the patient. Workflows can be customized for each physician and patient (e.g., the option to participate in remote patient visits or not).

[0014] According to one embodiment of the present invention, the patient remote device is further configured to interface with the RMS via a patient interface, including a web-based portal and / or an app-based portal, to (i) enable the patient to provide and transmit patient-provided data to the RMS, and / or (ii) enable the patient and / or patient caregivers to access a patient-appropriate subset of the data for the patient.

[0015] In this way, patient-reported symptom data can be generated and early and effective treatment tailored via a patient remote device (e.g., a smartphone).

[0016] Additionally, in the field of spinal cord stimulation, it is known that the likelihood of stimulation success and patient satisfaction increases with the personalized attention given to the patient. The introduction of remote interaction with patient-provided data (even without advanced analytics) allows the clinician / practitioner or company representative to provide more personalized attention more frequently, without the need for the clinician / practitioner or patient to travel.

[0017] According to one embodiment of the present invention, the patient-provided data comprises: - Patient-reported remote pain assessment, Patient-reported remote sleep assessment, and -Patient-reported symptom data Contains one or more of the following:

[0018] According to one embodiment of the present invention, the patient remote device is configured to provide interrogation of diagnostic device data of at least one medical device and transmit the diagnostic device data to the RMS.

[0019] This may enable automated routing of daily device diagnostics that may impact patient compliance (e.g., electrode impedance, lead shift, stimulation usage, charge status (e.g., battery status), therapy on / off).

[0020] According to one embodiment of the present invention, the RMS is configured to form an interface connection with manufacturer support via a manufacturer support interface including a web-based portal and / or an app-based portal to enable manufacturer support to access collected patient physiological data and / or diagnostic device data of the at least one medical device.

[0021] According to one embodiment of the present invention, the RMS is configured to monitor collected patient physiological data and / or patient provided data and generate an alert indicating a likely change in patient health or mental health upon the occurrence of one or more predefined triggers. Alternatively or additionally, the RMS is configured to monitor RMS diagnostic device data and generate an alert indicating a likely affected patient compliance upon the occurrence of one or more predefined triggers.

[0022] In this way, it is possible for monitors to proactively engage with patients / HCPs when remote monitoring identifies an opportunity to optimize treatment. For example, an alert can trigger the need for a specific action (i.e., reprogramming, clinical visit, and / or referral) to be taken by remote management to optimize treatment.

[0023] According to one embodiment of the present invention, the one or more pre-set triggers are configurable via a medical professional interface and / or a manufacturer support interface.

[0024] According to one embodiment of the present invention, the one or more pre-defined triggers are configurable per patient or per patient group. Alternatively or additionally, the one or more pre-defined triggers are configurable for the destination of the generated alert.

[0025] According to one embodiment of the present invention, the RMS is configured to create alerts having levels of priority.

[0026] For example, alerts can be classified as high or normal priority as part of the configuration settings. These alert priorities for individual alert recipients or groups of recipients can control whether and how notifications are received and / or the organization and appearance of the alerts on the front-end interface.

[0027] According to one embodiment of the present invention, the one or more pre-defined triggers are initially configurable via a medical professional interface, and the RMS is configured to autonomously and / or continuously update the one or more pre-defined triggers based on the patient's needs.

[0028] For example, autonomous triggers can be initially set by a clinician, but then an artificial intelligence (AI) process can autonomously monitor and update to further fine-tune the process for individual patient needs.

[0029] According to one embodiment of the present invention, the RMS is configured to create a ticket upon the occurrence of one or more pre-configured triggers and share the ticket among multiple manufacturer support users via the manufacturer support interface.

[0030] The ticket issuing system is described below with particular reference to the embodiment shown in FIG.

[0031] According to a second aspect of the present disclosure, there is provided a method for remote patient monitoring, the method comprising: - automatically collecting physiological data of a patient by at least one medical device; - transmitting, by at least one medical device, physiological data of the patient collected via a patient remote device to a remote monitoring server device (RMS); forming an interface connection with a healthcare professional (HCP) remote device by the RMS via a healthcare professional interface, including a web-based portal and / or an app-based portal, to enable the healthcare professional to access the patient's physiological data collected on the RMS; Includes.

[0032] According to a third aspect of the present disclosure there is provided a computer program product comprising instructions which, when executed by at least one processing unit, cause the at least one processing unit to perform steps of the method according to the second aspect.

[0033] According to another aspect of the invention there is provided a computer readable data carrier storing a computer program product.

[0034] The present invention will now be described in detail with reference to the following drawings. [Brief description of the drawings]

[0035] [Figure 1] FIG. 1 illustrates components of a system for remote patient monitoring. [Diagram 2] FIG. 1 illustrates a system architecture for remote monitoring and programming of the described system. [Diagram 3] FIG. 1 illustrates an example of a system workflow for remote monitoring and programming. [Figure 4A] FIG. 13 illustrates a notification being sent to a patient remote device to complete a new pain map. [Figure 4B] FIG. 1 illustrates a patient's selection of locations in the lower back that correspond to current pain. [Diagram 5] FIG. 1 illustrates a flowchart of a method for remote patient monitoring. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0036] The present invention will be described in detail below with reference to the figures mentioned above. The illustrated exemplary embodiments are used for illustrative purposes, and the subject matter of the present invention is not limited by these exemplary embodiments, but is defined by the subject matter of the claims.

[0037] In the following, embodiments of the system of the present invention are described in detail with respect to a medical device in the form of a Spinal Cord Stimulation (SCS) device and a Remote Monitoring Server (RMS) in the form of a Neuro Service Center (NCS), and with respect to remote programming, which may include data interrogation.

[0038] 1 illustrates components of a system 100. The system 100 includes at least one medical device 10, a patient remote device 12, a remote monitoring server device (RMS) 14, and a healthcare professional (HCP) remote device 16.

[0039] The at least one medical device 10 may be referred to as a "therapeutic device" and may be, for example, an implantable medical device (e.g., an implantable monitoring device / loop recorder, a test stimulator, a stimulator or other implantable pulse generator). The at least one medical device 10 is configured to automatically collect patient physiological data and transmit the collected patient physiological data to the RMS via the patient remote device. Examples of collected patient physiological data include, but are not limited to, sleep disorders, activity levels, core body temperature indicative of fever, etc.

[0040] The patient remote device 12 functions as a transceiver for routing communications between at least one medical device 10 and the RMS 14. The patient remote device 12 can provide the patient with some aspects of local control of the treatment process. For example, the patient remote device 12 can give the patient the ability to change the active treatment program of a medical device, such as a medical device for spinal cord stimulation (SCS), control its stimulation amplitude, turn stimulation on / off, and view battery status. The patient remote device 12 can also act as an external programmer for the medical device.

[0041] The RMS 14 may be, for example, a hardware and / or cloud-based service center that facilitates remote programming (RP) and data interrogation of at least one medical device, and may include a central data repository of data collected by at least one medical device. In the example of FIG. 1, the RMS is in the form of a neurological service center (NRS). The hardware may include at least one computing device or a network of multiple computing devices. The RMS further includes computing capabilities as described herein. For example, the RMS is a functional unit that performs substantial calculations including numerous arithmetic and logical operations without human intervention, and may include, for example, a desktop computer, a server computer, a cluster / warehouse-scale computer, or an embedded system.

[0042] The HCP remote device 16 may also be referred to as a clinician programmer.

[0043] The HCP remote device can be used by a medical professional or a field technician to remotely program a medical device. The RMS 14 is configured to interface with the HCP remote device 16 via a medical professional interface, including a web-based portal and / or an app-based portal, to allow the medical professional to access the patient's physiological data collected on the RMS. The HCP remote device 16 can be physical (i.e., a dedicated device) or virtual (e.g., via a web-based interface to the system, a securely connected data reporter).

[0044] FIG. 2 shows a system architecture for remote monitoring and / or programming of the described system 100.

[0045] For SCS embodiments, a medical professional interface (also referred to as an NSC user interface) on the HCP remote device 16 may enable closed-loop real-time communication with at least one medical device 10. For example, a clinician wants to know the status of a patient in preparation for a follow-up visit or remote assistance call with the patient. The clinician triggers a "data update" request from the RMS, which is transmitted to the patient remote device 12 (e.g., a mobile phone or a wearable device such as a smart watch), which relays the request to at least one medical device 10, e.g., an implantable pulse generator (IPG) as shown in FIG. 2. The implant queries the current patient and device status and transmits a report via the patient remote device 12 to the RMS 14. The report may then be received and processed by the RMS (i.e., the message is converted into a form usable by the RMS, scanned for alert conditions using system algorithms, and assigned to the correct clinic and patient). At this point, the clinician can review the new report before meeting in person.

[0046] In some examples, the RMS can be configured to combine subjective data (e.g., patient diaries, patient surveys, clinician notes, etc.) and objective data (physiological and / or technical data such as current patient status, patient trend and outcome analysis, activity-based tracking, medication usage tracking, long-term pain data, statistical and treatment data such as eCap) into one viewable database. The combined data can be retrieved from HCP remote devices, patient remote devices, the RMS, medical devices, and multiple other data reporters.

[0047] In some examples, the RMS can provide a real-time website display of the integrated data accessible by multiple users, for example using a medical professional interface (e.g., a clinician web interface). Data received via periodic routines for collecting data automatically (daily, monthly, etc.) or on request (e.g., preparation for outpatient care, patient adjustments, etc.); A near real-time collected "snapshot" of the current patient condition showing all quantitative and subjective data stored about the patient; online access to the patient remote device and / or at least one medical device to collect real-time data; The status of the patient's system and statistics collected over time (e.g., the integrity of implanted leads, current stimulation settings, and diagnostic trends related to pain and / or system use); The system displays the current program parameters being used by the patient remote device; and Optionally, users may have the ability to configure the display of the combined data so that different data trends are added or removed from the display according to user preferences. can be displayed.

[0048] In some examples, the medical professional interface can be expanded to receive and display other data types, such as patient images, video, and / or audio files, as well as remote assessment of neurostimulation for pain.

[0049] In some examples, the RMS can be configured to enable access control of the patient database. In one example, the RMS can be configured to control device access by providing a means to register clinician programmer users and control their access to remote follow-up. In another example, the RMS can be configured to enable configurable user access rights such that data access to individual Patient Health Records (PHRs) is controlled on a per-user basis.

[0050] In some examples, the RMS can be configured to enable patient database connectivity, for example, an NSC database may be accessible via multiple portals, such as a medical professional interface, a patient interface, a manufacturer support interface, etc.

[0051] For example, internal data consumers 18 and data reporters 20 within the system 100 can read / write to the database through a user interface provided by the system. For example, technical services have the ability to review raw patient data and write to the patient database.

[0052] Optionally, the RMS may allow system users to both pull data from the RMS 14 and push data from patient remote devices to the RMS 14. For example, an external data consumer 22, such as an Electronic Health Record (EHR) system, can securely query and pull patient data from the RMS based on its own internal schedule or on demand during a real-time session. For example, the RMS 14 can export preselected data to the external data consumer 22 based on a schedule previously configured by the user. Optionally, the external data consumer 22 and data reporter 24 (e.g., an EHR system) can connect to the RMS via a system-supplied Application Programming Interface (API).

[0053] In some examples, the RMS 14 may be configured to allow queries to a searchable database of all patients and devices under the control of the clinic.

[0054] In some examples, the RMS 14 is configurable to allow for configurable reporting formats, allowing customization to the needs of a clinic or individual user.

[0055] In some examples, the RMS 14 can be configured to enable “electronic signature” or “digital signature” functionality to allow physicians and / or patients to electronically provide consent for future participation in remote follow-ups.

[0056] In some examples, the RMS 14 can be configurable to enable the ability to view population-wide data for a clinic or device registry, such as looking at relationships between overall outcomes or patient characteristics.

[0057] FIG. 3 shows an example workflow for remote monitoring and programming of the described system.

[0058] Typically, when a patient's information is created, the patient may be assigned to one or more patient groups (such as clinic groups or field support areas). These groups can be changed later, if desired, via the system administration user interface.

[0059] For each patient, consent must be documented before monitoring capabilities are turned on. Optionally, the patient programmer or patient app may include the consent.

[0060] The monitoring capabilities can be turned on via a manufacturer support interface, a medical professional interface, and / or a patient interface. Users of the monitoring data must have individual accounts created for which patient groups they are allowed access to, and, optionally, alert notification preferences, including contact information if applicable.

[0061] Alerts In some examples, the RMS 14 is configured to monitor collected patient physiological data and / or patient-provided data and generate an alert indicating a likely change in patient health or mental health upon the occurrence of one or more pre-defined triggers. Alternatively or additionally, the RMS 14 is configured to monitor RMS diagnostic device data and generate an alert indicating a likely affected patient compliance upon the occurrence of one or more pre-defined triggers.

[0062] For example, an alert indicating a likely change in a patient's health or mental health may include one or more of the following: Daily active minutes (rolling average over Y days) falls below X or rises above X. Daily hours of rest (averaged over Y days) fell below X or rose above X. Your heart rate per minute (averaged over Y days) falls below X or rises above X. Your sleep restlessness score (a Y-day rolling average from your accelerometer movement algorithm) falls below X or rises above X. - Temperature rises above X, indicating fever or possible infection. Patient-reported pain scores increased above X for Y days. Patient-reported sleep score drops below X for Y days. Additionally, any combination of conditions that indicate a possible deterioration of the patient's condition, such as both patient-reported pain and accelerometer-measured activity reaching a threshold. · Patient data has not been reviewed for X days. Regularly scheduled remote follow-ups are conducted on a fixed date or interval schedule.

[0063] For example, an alert indicating affected patient compliance may include one or more of the following: -Lead impedance on the therapy electrodes is out of range. · Suspected lead shift occurred for more than X contacts. Stimulant usage was less than X% for the last Y days. The battery is depleted and stimulation is automatically shut off. · MRI mode remains on for X days. · The active treatment program has been changed from the preferred treatment program. The amplitude of an active treatment program has fallen below X for more than Y days.

[0064] In another embodiment, the system provides "active" patient alerts. For example, the system provides "push" alerts that are formed autonomously within the system, compared to forming only a passive / "pull" display of data within the user interface of the patient remote device or HCR remote device. In one embodiment, the patient remote device communicates data to the RMS that the stimulator battery charge is low, in accordance with the requirements for safely administering the therapy (the trigger settings for determining that the alert condition has been met can reside either in the RMS or in the patient remote device itself). The system then sends a message to the patient's personal mobile phone (e.g., via a patient app) to inform the patient of the low charge condition.

[0065] Additionally, according to another embodiment, if the system detects a specific additional issue during charging of the medical device, the system automatically sends educational information to the patient app that can guide the patient through the best charging process (e.g., "Charging Education"), which can be determined from observed behavior such as frequent charging being stopped before charging is complete, excessive time between recharging sessions, or other usage patterns that suggest the patient is not charging the battery in a manner consistent with best practices.

[0066] In another embodiment, the system provides estimated battery usage for programs associated with the medical device. For therapy programs available on the medical device, the system calculates an estimate for the runtime before recharging is required. The information may be available as "pull" data that the user can view as needed, or as "push" alerts when current program usage may lead to rapid battery drain. Such information may be available to both the HCP and patient remote devices, or to the patient personal device (e.g., a mobile phone). In this embodiment, the RMS will calculate the estimated battery usage instead of performing the calculation on the HCP remote device, which may only be intermittently connected. According to one embodiment, the estimated battery usage is calculated for the actively running therapy programs of the medical device.

[0067] In another embodiment, the system provides automatic treatment recommendations for the patient. For example, data acquired by or associated with the medical device and monitored via the RMS is used as a trigger for automatic recommendations to be sent to the patient remote device. The recommendation system is, for example, programmed according to a decision tree. As an example, if the medical device is a neurostimulator for treating pain and includes monitoring the patient's pain score, the system can autonomously suggest to the patient to try a new default program if the patient's pain score is still elevated 5 days after the reprogramming session. The decision tree used can use patient-specific characteristics or can make a purely general recommendation based on the configured decision tree.

[0068] In some examples, the alerts are configurable through a front-end user interface: for example, a physician / clinic team may define a list of alerts and trigger conditions.

[0069] In some examples, separate alerts may be configurable for the manufacturer support team and the doctor / clinic team. Optionally, individual users may be defined within the doctor / clinic team to have their own customized alerts. For example, doctors may only be notified of temperature changes, while nurses are notified of all alerts. Optionally, the manufacturer team may be able to access and modify the alerts of these users as a means to assist the doctor / clinic users. Optionally, individual users may be defined within the manufacturer team to get their own customized alerts. For example, local field personnel may only be notified of certain alerts, while the internal customer support team receives all alerts.

[0070] In some examples, the alerts may be customized on a per-patient basis, in other words, individual users may be defined to get individually customized alerts.

[0071] In some examples, alerts can be customized for patient groups. For example, a clinical user can have the option to set consistent alerts across all patients associated with a clinic. For example, a manufacturer user has the option to set consistent alerts across all patients in a clinic group.

[0072] In some examples, where to send notifications of alerts may also be configurable. For example, each clinical user may choose from input contact information such as SMS or email to send notifications, or may choose to have notifications displayed only on the web interface. Optionally, notifications may be integrated into the clinic's electronic health record system.

[0073] Optionally, alerts can be classified as high or normal priority as part of the configuration settings, which can control, for example, whether and how notifications are received for individual alert recipients or groups of recipients.

[0074] Optionally, autonomous triggers can be initially set by the clinician, but then the AI ​​process can autonomously monitor and update to further fine-tune the process for individual patient needs.

[0075] A portal for the manufacturer support team, i.e. the Manufacturer Support Interface Central to the functionality of the Manufacturer Support Team Interface may be an alert-based ticketing system that may be shared among Manufacturer Support users.

[0076] In some examples, new "tickets" created by alert conditions can be assigned to individual manufacturer support users, who can have their own queue of tickets to view and act on, ordered by alert priority and / or time since the alert was detected and / or clinical account priority.

[0077] In some examples, each ticket can be linked to an individual patient master record that includes patient monitoring data (e.g., collected physiological data, patient-reported data, and / or diagnostic device data), notes related to past tickets and ticket resolution, and / or any related clinic communications.

[0078] In some instances, the ticketing system also allows for tickets to be added manually, for example when a patient or clinician calls a support center directly.

[0079] In some examples, the ticketing system may allow for a status to be assigned to the ticket including, for example, evaluation, contacting patient, reporting to physician, follow-up, etc. The ticketing system may allow support users to consistently handle tickets of the same type by providing specific prompts with selectable drop-down menu selections to complete. For example, a ticket in a "Needs Assessment" status may include a drop-down for responding with "Evaluation Results" with options of "Refer to physician," "Contact patient for more information," or "No intervention required."

[0080] The ticketing system may track a historical record of time, users involved, and / or data / notes added for each change to a ticket.

[0081] In some examples, the manufacturer support team portal may also include the ability to view monitoring data, whether or not it is associated with an alert. The format of the monitoring data may include one or more of the following: ·Ability to view history listings and associated notes for significant patient events such as in-office follow-ups, remote follow-ups and other interactions; ·The ability to view a snapshot of the most recent measurements and the dates these measurements were taken; Ability to view trend plots of data with flexible trend period views. Optionally, trend plots may be customizable to include two or more variables on the same trend. For example, a user may choose to have activity and sleep quality appear on the same graph. In addition to supporting various period views, trend plots may support providing details on individual data points of interest (e.g., dates and specific values). Trend plots may also be modified to visually include important events such as in-office follow-ups, remote follow-ups and other interactions with the patient; · Ability to compare in tabular form two or more specific time points, e.g., the average over the last X days against the pre-implant average for a day or specific X days; Ability to create customized reports for sending to physicians / clinics via a medical professional interface (e.g., clinic web portal). Customized report options may be selectable for what monitoring data is included, what time periods of monitoring data are included, specific notes from the ticketing system to be included, as well as customizable additional notes to the physician's office.

[0082] Portal for doctors / clinics, i.e. medical professional interface A web-based or app-based portal for a physician / clinic may include all of the functionality described in the manufacturer's portal, or a subset of that functionality. In general, a clinic portal may also include one or more of the following in addition to the possibilities listed above: ·Ability to define a default view for the clinic, including what data is displayed, the order in which the data is displayed, and the time period for each type of data. Ability to define a list of predefined reports for individual patients, which the clinic user can quickly select and export (e.g. for use in the EHR for remote monitoring billing). Ability to view a summary of key outcome data for all patients in the practice as defined by the practice preferences (e.g., a list of all patients by implant date within the last 3, 6, 12 and 24 months, as well as most recent pain scores and activity values) with the ability to select individual patients in the summary to drill down to more detailed patient information. · The ability to track the amount of time users spend within the system seeing individual patients, for example, for remote monitoring billing purposes.

[0083] Portal for patients and / or caregivers A subset of the data can be selected and displayed in a patient-friendly format on a patient and / or caregiver web portal or app on the patient remote device 12. The subset of data can be defined according to selections made by the clinic, a member of the manufacturer support team, or the patient or caregiver user themselves.

[0084] A particular aspect of the present disclosure is a set of assessments that can be used in combination with remote management to ensure effective daily pain relief and high QoL over the life of the implanted device. These assessments can be triggered autonomously based on pre-set criteria or manually by the clinician or patient.

[0085] Generally, these assessments can trigger actions from remote management, either individually or based on a combination of responses from different assessments. Data scientific approaches can be used to determine which assessment responses or groups of responses are most predictive of the need for a particular action to be taken by remote management (e.g., reprogramming, clinical visit, referral). Such approaches can include, for example, artificial neural networks, linear and logistic regression, clustering, and dimensionality reduction, among others.

[0086] For example, the technical process of evaluation that triggers an actionable output can be summarized as follows: 1. Patient completes the assessment and uploads the results to the NSC (cloud database). 2. Custom software reads the data and converts the assessment results into input variables (which can be alphanumeric or graphical data). 3. The software compares the input variables (or quantities calculated from the input variables) with predetermined thresholds. 4. If the input exceeds a threshold, custom software creates and transmits an alert.

[0087] Patient-reported remote pain assessment In some examples, a remote management system or component such as the RMS 14 can send a notification to the patient via the patient remote device 12 to complete a chronic pain assessment. This can be done on a predetermined schedule as part of a clinical study, at the patient's request, or at the physician's request, possibly prior to a clinical follow-up visit.

[0088] An example of remote pain assessment is described below.

[0089] Step 1: A notification is sent to a patient remote device. Examples of notifications include, for example: "On a scale from 0 (no pain) to 10 (worst possible), how bad is your back pain?" "On a scale from 0 (no pain) to 10 (worst possible), how bad is the pain in your legs?" "On a scale from 0 (no pain) to 10 (worst possible), how bad is your overall body pain?" It may be.

[0090] Step 2: The patient completes the assessment. In response to each question, the patient can enter a number or move a slider to indicate their current pain score.

[0091] Step 3: The patient submits the survey via secure, cloud-based remote administration, which can trigger one or more of the following potential actions: A consistently increasing pain score can trigger a follow-up remote or in-person visit. For example, a threshold can be defined (e.g., Numeric Rating Scale (NRS) 3 points above the daily NRS averaged over 3 consecutive days in the previous month). An alert (e.g., text message or email) about the increasing pain may be sent to the clinician. The message can include a link to schedule a follow-up with the patient (so the NSC knows action has been taken), but alternatively, the AI ​​can automatically perform the analysis and suggest appropriate adjustments to the patient and / or physician in light of the increasing pain score. A consistent decrease could trigger an adjustment of parameters (lower energy could result in longer recharge intervals). A similar trigger could prompt an alert to the clinician. Alternatively, the AI ​​could automatically perform the analysis and suggest appropriate adjustments to the patient and / or physician, taking into account the decrease in pain scores. During the study, high pain scores can trigger a remote programming session to send a new study treatment. Similar types of triggers, such as lower thresholds triggered by small increases in NRS scores due to study time constraints, can alert clinicians.

[0092] Patient-reported remote sleep assessment In some examples, remote management can send a reminder to the patient via the patient remote device 12 to complete a sleep quality assessment. This can be done on a predetermined schedule as part of a clinical study, at the patient's request, or at the physician's request, possibly prior to a clinical follow-up visit. The assessment interval can be, for example, last night, last week, or one month after optimizing treatment.

[0093] An example of remote sleep assessment is described below.

[0094] Step 1: A notification is sent to a patient remote device. Examples of notifications include, for example: "On a scale from 0 (worst possible) to 10 (best possible), how well did you sleep last night?" It may be.

[0095] Step 2: The patient completes the assessment. The patient can enter a number or move a slider to indicate the previous night's sleep score.

[0096] Step 3: The patient submits the survey via secure, cloud-based remote administration, which can trigger one or more of the following potential actions: · If the sleep score is consistently decreasing (sleep deprivation), a follow-up tele- or in-person visit or another evaluation can be triggered to determine if it is pain-related. For example, a threshold can be defined (e.g., a weekly averaged sleep score is less than 3 points below the same averaged sleep score for the previous month). An alert (e.g., text message or email) can then be sent to the clinician regarding the change in sleep score. The message can include a link to send the patient an additional survey to evaluate if the sleep deprivation is a result of increased pain. Alternatively, AI can automatically analyze and suggest adjustments to the patient and / or physician to account for the decrease in sleep score. The results of this or other assessments may trigger a remote or in-person follow-up visit. During the trial, remote programming sessions can be conducted to send new study treatments or alert clinicians to assist with interpreting subsequent pain scores because sleep quality correlates with pain.

[0097] Patient-reported remote pain map In some examples, remote management can send notifications to the patient via a patient remote device to complete a chronic pain map. This can be done on a predetermined schedule as part of a clinical study, at the patient's request, or at the physician's request, possibly prior to a clinical follow-up visit. Ideally, the patient will have completed an initial pain map at the start of the test implant, continuous implant, or both.

[0098] An example of a patient-reported remote pain map is provided below.

[0099] Step 1: The patient completes a baseline chronic pain map, e.g., prior to test or continuous implant. For example, the patient can select areas on the pain map where they feel chronic pain. This can be accomplished using standard graphical software and a touch screen, such as those available on remote devices for medical professionals.

[0100] 4A, for example, shows that a notification is sent to a patient remote device to complete a new pain map, which includes shading to indicate previously reported baseline pain.

[0101] Step 2: The patient completes the pain map assessment by selecting the area that corresponds to the current pain.

[0102] FIG. 4B, for example, shows the patient's selected sites in the lower and forelimbs corresponding to current pain.

[0103] Step 3: The patient submits their current pain via secure cloud-based remote management, which can trigger one or more of the following potential actions: If the pain area is increasing, a follow-up tele- or in-person visit can be triggered. For example, new back pain can cause reprogramming by shifting the active contacts upwards. Reprogramming can be done with AI or with AI support. If the pain area is decreasing, an adjustment of parameters can be triggered (lower energy can result in longer recharge intervals). An alert (e.g. text or email) can be sent to the clinician to inform them of the reduction in the pain area. The alert can include a link to schedule a follow-up with the patient, or alternatively, the AI ​​can automatically analyze and suggest adjustments to the patient and / or physician given the reduction in the pain area. During a study, a remote programming session can be triggered to send new study treatments.

[0104] Ability to remotely monitor physiological and diagnostic device data from implants (without requiring patient interaction).

[0105] Daily activity level monitoring Daily activity level may be calculated from a motion / acceleration sensing circuit incorporated in an implantable device for pain management. For example, the motion detection circuit may integrate counts (e.g., accelerometer counts sampled at 8 Hz) representative of activity over a short epoch (E1), e.g., 1 second period. At the end of E1, the accumulated count value (Cv) may be compared to a number of threshold levels, e.g., L0-L3. A set of counters C0-C3 representing levels L0-L3 may be implemented, with each counter incremented in response to falling within a corresponding threshold range Cv.

[0106] In some examples, a longer epoch E2 can be defined, say 10 minutes, and the current values ​​of C0-C3 can be stored in a retention record Rx, which are then reset to zero for periods that are multiples of E2, resulting in activity records R0...Rx. For example, if E2 is 10 minutes, there will be 144 records per day.

[0107] Activity records are stored within the implanted device and can then be transmitted to a central database in the RMS.

[0108] In some examples, activity records stored in a database may be processed for a display representative of the patient's activity at various intensity levels I0-I3 corresponding to threshold levels L0-L3.

[0109] In some examples, the activity records stored in the database may be used as objective performance criteria in the assessment of a patient's mental health during medical treatment.

[0110] In some examples, activity records stored in the database can be used to evaluate activity goals set by the patient as a measure of improvement in the patient's QoL during medical treatment.

[0111] In some examples, activity records stored in a database can be used to identify "high activity" and "low activity" periods, such that the presence or absence of a desired count in each period can trigger an alert to a caregiver or device management assistant to monitor the patient.

[0112] In some examples, the activity records stored in the database can be segmented into 24-hour periods representing at least one "wake" period and at least one "sleep" period, which are used to assess the presence of activity or improvement in intensity or duration of activity during the "wake" periods, assess the absence of activity during the "sleep" periods, and report a composite measure of sleep quality and efficiency derived from the absence of activity during the "sleep" periods.

[0113] In some examples, the above criteria and trends can be utilized to identify changes in a patient's activity behavior compared to a baseline or compared to historical trends, such that substantial deviations from a calculated baseline (e.g., historical average) or trend (linear or cyclical predictive model) trigger an alert (email, text, other notification system) to a caregiver. An alert can represent a reliable behavior-derived indicator of a change in a patient's health or mental health. For example, an alert can represent a possible change in pain status or a pain patient's ability to cope with pain. An alert may be used to trigger a patient care action or initiate an appointment.

[0114] Temperature Monitoring At least one medical device can be configured to house a temperature sensor that collects and relays temperature data to a central server, as previously described.

[0115] In some examples, at least one medical device may have the additional capability of identifying periods during which its internal temperature readings are not representative of the patient's body temperature, for example, while the implantable device is charging. In response to identifying such periods, the system may prevent temperature readings corresponding to such periods from affecting the representative patient body temperature norm that is recorded and displayed to the end user (e.g., physician, etc.). Temperature measurements recorded in such a manner may be used to track baseline trends (averages) and identify deviations from such baseline trends. Such deviations may then alert a caregiver that the patient's body temperature surrounding the implantable device has deviated from the standard trend, potentially as a result of infection or other causes resulting in an altered metabolic state.

[0116] Referring to FIG. 5, a flow chart of a method 200 for remote patient monitoring is shown.

[0117] In step 210, at least one medical device automatically collects physiological data of the patient (eg, core body temperature indicative of sleep disorders, activity level and / or fever).

[0118] In step 220, the at least one medical device transmits the collected patient physiological data to a remote monitoring server device (RMS) via the patient remote device.

[0119] In step 230, the RMS forms an interface connection with a healthcare professional (HCP) remote device via a healthcare professional interface, including a web-based portal and / or an app-based portal, to enable the healthcare professional to access the patient's physiological data collected on the RMS.

[0120] In this way, it is possible to provide continuous remote monitoring of physiological data from medical implants without the need for patient interaction. The monitoring data is available to the physician on demand via a web- and / or app-based user portal.

[0121] In another exemplary embodiment of the invention, a computer program or a computer program element is provided, characterized in that it is adapted to perform, on a suitable system, the method steps of the method according to one of the previous embodiments.

[0122] The computer program element may therefore be stored in a computing unit which may also be part of an embodiment of the present invention. This computing unit may be adapted to execute or direct the execution of the steps of the method described above. It may further be adapted to operate the components of the apparatus described above. The computing unit may be adapted to operate automatically and / or to execute user instructions. The computer program may be loaded into a working memory of a data processor. A data processor may thus be equipped for executing the method of the present invention.

[0123] Such exemplary embodiments of the present invention encompass both computer programs that initially use the present invention, and computer programs that, through updates, convert existing programs into programs that use the present invention.

[0124] Moreover, the computer program element may provide all the steps required to carry out the procedures of the exemplary embodiments of the methods described above.

[0125] According to a further exemplary embodiment of the present invention, a computer readable medium, such as a CDROM, is provided, which stores the computer program elements described in the above sections.

[0126] The computer program may be stored and / or distributed on a suitable medium, such as an optical storage medium or a solid-state medium, supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless communication systems.

[0127] It should be noted that the computer program may be provided via a network such as the World Wide Web and may be downloaded from such a network into the working memory of a data processor. According to a further exemplary embodiment of the invention, a medium for making available for downloading a computer program element is provided, the computer program element being configured to perform a method according to one of the aforementioned embodiments of the invention.

[0128] It should be noted that the embodiments of the present invention are described with reference to different subject matters. In particular, some embodiments are described with reference to method type claims, and other embodiments are described with reference to apparatus type claims. However, a person skilled in the art will infer from the above and following description that, unless otherwise noted, any combination of features belonging to one type of subject matter, as well as any combination between features relating to different subject matters, is considered to be disclosed by the present application. It should be noted that all features can be combined to provide synergistic effects that exceed the simple sum of the features.

[0129] While the invention has been illustrated and described in detail in the drawings and the foregoing description, such illustration and description are illustrative or illustrative and are not to be considered as limiting. The invention is not limited to the disclosed embodiments. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the claimed invention, from a study of the drawings, the disclosure and the dependent claims.

[0130] In the claims, the word "comprising" does not exclude other elements or steps, and the indefinite articles "a" or "an" do not exclude a plurality. A single processor or other unit may fulfill the functions of several items recited in the claims. The mere fact that certain measures are recited in mutually different dependent claims does not indicate that a combination of these measures cannot be used to advantage. Any reference signs in the claims should not be interpreted as limiting the scope.

Claims

1. A system (100) for remote patient monitoring, said system (100) comprising: at least one medical device (10); - a patient remote device (12); a remote monitoring server device (RMS) (14); a Health Care Professional (HCP) remote device (16); Equipped with the at least one medical device is configured to automatically collect patient physiological data and transmit the collected patient physiological data to the RMS via the patient remote device; The RMS is configured to interface with the HCP remote device via a medical professional interface, including a web-based portal and / or an app-based portal, to allow a medical professional to access the patient's physiological data collected on the RMS. system.

2. the system is configured to provide real-time remote programming and / or interrogation of the at least one medical device using the medical professional interface via the patient remote device. The system of claim 1 .

3. The patient remote device interfaces with the RMS via a patient interface including a web-based portal and / or an app-based portal; (i) enabling the patient to provide patient-provided data and transmit the patient-provided data to the RMS; and / or (ii) enabling the patient and / or patient caregiver to access a patient-specific subset of data for the patient; [0023] The system of claim 1 .

4. The patient-provided data includes: - Patient-reported remote pain assessment; - Patient-reported remote sleep assessment; - Patient-reported symptom data; and including one or more of: The system of claim 3.

5. the patient remote device is configured to provide interrogation of diagnostic device data of the at least one medical device and to transmit the diagnostic device data to the RMS; The system of claim 1 .

6. the RMS is configured to interface with manufacturer support via a manufacturer support interface, including a web-based portal and / or an app-based portal, to allow the manufacturer support to access collected physiological data of the patient and / or diagnostic device data of the at least one medical device. The system of claim 1 .

7. The RMS is - monitoring collected physiological data and / or patient-provided data of the patient and generating an alert in response to the occurrence of one or more pre-defined triggers indicating that the patient's health or mental health is likely to have changed; and / or - monitoring said diagnostic device data and generating alerts indicative of patient compliance likely to be affected upon the occurrence of one or more pre-defined triggers; It is configured as follows: The system of claim 6.

8. the one or more pre-defined triggers are configurable via the medical professional interface and / or the manufacturer support interface. The system of claim 7.

9. the one or more pre-defined triggers are configurable per patient or per patient group; and / or The one or more pre-defined triggers are configurable with respect to the destination of the generated alert. The system of claim 8.

10. The RMS is configured to generate the alerts having a level of priority. The system of claim 7.

11. the one or more pre-defined triggers are initially configurable via the medical professional interface; the RMS is configured to continuously update the one or more pre-defined triggers based on the patient's needs. The system of claim 7.

12. the RMS is configured to generate a ticket upon occurrence of one or more predefined triggers and share the ticket among a plurality of manufacturer support users via the manufacturer support interface; The system of claim 7.

13. 1. A method (200) for remote patient monitoring, the method (200) comprising: - automatically collecting (210) physiological data of a patient by at least one medical device; - transmitting (220) the physiological data of the patient collected by the at least one medical device to a remote monitoring server device (RMS) via a patient remote device; - forming an interface connection with a healthcare professional (HCP) remote device by the RMS via a healthcare professional interface, including a web-based portal and / or an app-based portal, to allow the healthcare professional to access the patient's physiological data collected on the RMS (230); The method includes:

14. comprising instructions which, when executed by at least one processing unit, cause the at least one processing unit to perform the steps of the method of claim 13; Computer program products.

15. 15. A computer program product according to claim 14, A computer readable data carrier.

Images