Multi-disciplinary remote patient assistance system

Abstract

A method for remote patient monitoring comprises the following steps: receiving medical data from at least one medical device of a patient, determining a patient state and / or patient event at least in part based on the medical data, and determining one or more recipients of a report on the patient state and / or patient event at least in part on the patient state and / or patient event.

Description

[0001] MULTI-DISCIPLINARY REMOTE PATIENT ASSISTANCE SYSTEM

[0002] The invention relates to methods, systems, and computer programs for processing of medical data from medical devices such as to manage and / or distribute patient data intelligently for remote patient monitoring.

[0003] Implantable medical devices, wearable medical devices, etc. are increasingly commonly connected to monitoring services so that the implanting physician can utilize its primary diagnostic function in a remote manner or monitor therapeutic aspects of the implant.

[0004] Known diagnostic monitoring solutions are designed to provide diagnostic information to a patient’s implanting or referring physician, in other words the primary physician who prescribed the medical implant. This is the natural process of prescription, implant, and continued diagnosis / therapeutic monitoring and can include reimbursement for this monitoring effort.

[0005] However, as implantable medical monitoring devices able to collect greater amounts of data, and as data processing algorithms become more sophisticated, diagnostic capabilities of the system begin to extend beyond the purview of the prescribing physician.

[0006] Therefore, there is still a need to further improve systems, devices, methods, and computer program for medical data management in remote patient assistance.

[0007] The methods, systems, and computer programs described herein may meet the above need at least in part. According to a first aspect of the invention, a method for remote patient monitoring is provided. The method comprises the following steps: receiving medical data from at least one medical device of a patient, determining a patient state and / or patient event at least in part based on the medical data, and determining one or more recipients of a report on the patient state and / or patient event at least in part on the patient state and / or patient event.

[0008] This may allow for fast and efficient medical data management. In detail, each recipient may only receive those reports that are relevant and understandable for them. Therefore, recipients may spend less time on processing information they receive as they do not have to search for the parts that may be relevant for them. This may increase the overall quality of remote patient monitoring and save time and costs. Vice versa, if the system executing such method is not intelligently designed, potential recipients (e.g., clinicians, technicians, etc.) involved in the remote monitoring may be overwhelmed by the amount of information they receive from said system during remote patient monitoring.

[0009] Remote patient monitoring may, e.g., relate to any recipient receiving reports and / or any other information based at least in part on medical data from at least one medical device of a patient via any kind of typical and known data transmission via any system, e.g., a server system as described herein. This may allow the recipient, typically, e.g., a health professional or a technical expert, to monitor one or more patients and / or medical devices remotely, e.g., requiring no or only few time-consuming face-to-face appointments with the patients. Patient monitoring may thus be performed more regularly and more efficiently in such remote fashion.

[0010] Receiving medical data from at least one medical device of a patient may, e.g., relate to a server receiving medical data from one or more (implantable) medical devices of a patient. The medical data may, e.g., comprise medical device data (e.g., on the battery status, operation mode, warning messages, a medical device identification, etc.), physiological patient data (e.g., at least one parameter relating to a physiological state of the patient measured by the medical device), and / or a patient identifier (e.g., a patient number, patient name, etc.). The at least one medical device may, e.g., be an implantable medical device (such as a neurostimulator, a cardiac rhythm management device, etc.), a wearable medical device, any other type of medical device, and / or any combination thereof. The medical device may be configured to collect medical data, as described herein, automatically and / or may receive user (e.g., patient)-input to collect such medical data.

[0011] Determining a patient state and / or patient event at least in part based on the medical data may comprise, e.g., analyzing at least one parameter comprised in the medical data to determine whether the patient is in a certain patient state and / or whether a certain patient event has occurred. There may be predetermined patient states and / or patient events which may, e.g., be assigned certain criteria that may indicate that the patient is in a certain patient state and / or that a certain patient event has occurred. For example, such criteria may comprise that at least one parameter comprised in the medical data lies within a predetermined range and / or a true-or-false condition is met. The medical data may, e.g., indicate no patient state and / or patient event, or one or more patient states and / or patient events. This processing may even comprise diagnostic steps such as to diagnose a certain patient state based at least in part on the medical data from the at least one medical device. The determining of the recipient may also be based on the patient and / or the medical device. For example, a recipient may in principle be a suitable recipient for a patient state and / or patient event that occurred but when they are not associated with the respective patient, they may not receive the report thereon. Rather, only recipients associated with the respective patient experiencing a certain patient state and / or patient event may receive the report thereon.

[0012] For example, when the medical device is a spinal cord stimulator (SCS), a patient state may, e.g., comprise a state of low device usage when the medical device is turned off for 50% or more of the time during a certain time period, a state of medium device usage when the medical device is turned off for 25% to 50% the time during a certain time period, or a state of high device usage when the medical device is turned off for less than 25% of the time during a certain time period. Patient events may, e.g., comprise a patient fall that may be, e.g., indicated by data collected from an accelerometer.

[0013] Determining one or more recipients of a report on the patient state and / or patient event, as described herein, at least in part on the patient state and / or the patient event may be directed at sending the reports only to those recipients that may need and / or understand the information comprised in said report. The system executing the method described herein may send such reports to any plurality of recipients and choose different recipients for different patients, medical devices, patient states, and / or patient events. For example, medical data received from a SCS may indicate a patient state that may be of particular relevance for a SCS technician and / or a pain specialist, which may therefore be determined as recipients of reports thereon. Should the medical data, e.g., merely indicate a technical device issue, the report may in this example only be sent to the technician and not to the paint specialist. Vice versa, should the medical data indicate an alarming patient state that might require medical intervention, the report may in this example only be sent to the pain specialist.

[0014] The method may, for example, further comprise receiving a subscription notification to at least one patient state and / or patient event from a potential recipient, wherein the determining of the one or more recipients may further be based at least in part on the subscription notification.

[0015] This may advantageously ensure that suitable recipients may be determined at all times, that new potential recipients may be added to the list of potential recipients and / or that recipients may be removed from that list, e.g., when they retire and / or are not responsible for a patient anymore. For example, should a clinician become an expert in a new medical field, they may subscribe to reports on that field, analogously clinicians may unsubscribe from reports on at least one patient state and / or patient event. Thereby, the recipients themselves may provide the system distributing the reports with all the relevant information that it needs to determine the recipients, this may increase the efficiency, the reliability, the flexibility, and the user- friendliness of the system. By avoiding incorrect determinations of recipients, user satisfaction may increase and thereby also the acceptance of the method / system and the quality of the remote monitoring may increase.

[0016] The potential recipient may, e.g., send the subscription notification via the same (or a different) user-interface through which they may also receive the reports as described herein, e.g., a user-interface connected to an (online) portal backend as described herein. They may further subscribe to single patient states and / or patient events and / or classes thereof comprising a plurality of patient states and / or patient events, each associated to a patient. A potential recipient may analogously also subscribe to further patients and / or medical devices.

[0017] Determining the one or more recipients may for example be based on the following or a similar process: The system executing the method may for example classify patient states and / or patient events by at least one class. Each class may, e.g., comprise one or more (e.g., similar) patient states and / or patient events, which may simplify subscribing and / or unsubscribing from groups of patient states and / or patient events. Such class may for example relate to the physiological region associated with the patient state and / or the patient event: E.g., the patient state may be classified as a state with relevance for the cardiovascular system, the respiratory system, etc. The system may further have access to a database in which potential recipients may, for example, be classified according to similar classes: A clinician may be listed as a cardiologist, a specialist for the respiratory system, etc. Any user may be listed as such, e.g., by subscribing to an according class of patient states and / or patient events. The same may apply, e.g., for technicians that specialize on certain medical devices, analogously. In a simple direct comparison of the classification of the patient states and / or patient events with the classification of the users: for example, system may determine the cardiologist that is associated with the patient for whom the medical data are received to be the recipient for a report on a patient state with relevance for the cardiovascular system, e.g., a patient state comprising an unusually high blood pressure. The information on the cardiologist may in this example be retrieved from the database. The same may analogously apply to examples wherein potential recipients subscribe to one or more single patient states and / or patient events.

[0018] Like any user may subscribe as described herein they may also unsubscribe from receiving reports on certain patient states and / or patient events, reports from certain patients, and / or medical devices, for example, via a web-based user interface of a portal for accessing the system used for remote patient monitoring as described herein.

[0019] Determining at least one recipient may for example result in determining one recipient because they have subscribed to a patient event that has occurred and a further recipient which has not subscribed to the according patient event but may nevertheless be determined as a suitable recipient as described herein.

[0020] The method may, e.g., further comprise providing the report to the one or more recipients.

[0021] This may yield an intelligent, efficient and automatic distribution of data to the relevant recipients. This may also improve the overall quality of care through remote patient monitoring.

[0022] The method may, in an example, further comprise providing the report to a default recipient if the determining fails. This may improve safety and reliability of the system.

[0023] For example, when the system relies on potential recipients subscribing and / or unsubscribing from receiving reports on patient states and / or patient events as described herein, this safety mechanism may be particularly advantageous: When, e.g., no user has subscribed to a certain patient state and / or patient event or all users that had previously subscribed to that patient state and / or patient event have unsubscribed, the system may not be able to find a suitable recipient when that patient state and / or patient event occurs to provide the report thereon to said recipient, but may provide the report on that patient state and / or patient event to the default recipient.

[0024] Therefore, there may be a default recipient assigned to each patient and / or each medical device. The information on the default recipient may, e.g., be stored in the same in which potential recipients may, for example, be classified according to similar classes, as described herein. The default recipient may, e.g., also have subscribed to one or more patient states and / or patient events or be classified by the system, accordingly, as described herein.

[0025] The method may, e.g., further comprise adapting the report at least partly based on the recipient.

[0026] For example, this may simplify the understanding of the reports provided to the recipient, e.g., by providing exactly that information to the recipient that they may need and / or understand. This might increase the efficiency and speed at which the recipients may review and process the reports to take actions, when needed. This may improve the quality of care through remote monitoring and allow to react fast in, e.g., emergency situations, like, e.g., indicated by a report on an emergency patient event, e.g., a high jerk event indicating that the patient has fallen.

[0027] The adapting may for example comprise simple adaptations, you like the language of the report matching the language preference of the recipient. The adapting may also comprise adjusting the content of the report to the recipient, e.g., selecting the information for the report that may be required by that recipient: providing a report to a technician may comprise (mostly) device-related information while providing a report to a clinician may (mostly) comprise physiological parameters relating to the patient state and / or patient event.

[0028] The method may, e.g., comprise providing reports on a regular basis.

[0029] This may be advantageous for sustaining continuous remote patient monitoring, allowing to identify trends early on which may allow to provide proactive care improving the quality of care and the patient’s health.

[0030] For example, reports may be provided to at least one recipient at least once per day, two days, three days, four days, week, or month, etc. The reports may, e.g., be provided periodically at a certain rate and / or according to a predetermined schedule, e.g., on workdays or any other schedule.

[0031] The method may, e.g., further comprise providing a report, if the medical state and / or the medial event indicate a medical issue.

[0032] This may act as a safety mechanism allowing to react quickly when a medical issue occurs. In this aspect, remote monitoring achieved as described herein, may prove advantageous over in-person monitoring. In-person monitoring may not be able to achieve uninterrupted monitoring of the patient while remote monitoring may allow to identify medical issues at all times and report them to take any action needed. In an example, the report may comprise at least one of the following: device data, physiological patient data, and a patient identifier.

[0033] This may provide the determined recipient with all relevant information on the patient state and / or patient event.

[0034] The device data may comprise data on the medical device, e.g.: a battery charge status, information on the device operation mode (e.g., in the example of an SCS: a stimulation frequency, a stimulation amplitude, a stimulation waveform, a stimulation duty-cycling, a time of active stimulation, etc.), and / or a device-identifier (e.g., a device name, a device number, etc.).

[0035] The physiological patient data may comprise, e.g., objective physiological data measured by one or more medical devices like: a step count, blood pressure, heart rate, breath rate, changes / trends over time thereof, etc. It may further comprise subjective (patient-reported and / or clinician-reported) data like a pain score indicating a current pain level perceived by the patient, a psychological burden score indicating the psychological well-being of the patient, etc.

[0036] The patient identifier may allow to link the report to the patient and may be present in form of a patient name, patient number, patient address, any other code indicating the patient, and / or any combination thereof. It may unambiguously identify the patient associated with the patient report.

[0037] The method may further comprise processing the medical data to provide visualization data for visualization of the medical state and / or medical event.

[0038] Such visualization may increase the speed at which the reports may be processed by the recipients, increase the amount of information that may be comprised in each report and thereby increase the over-all quality of remote patient monitoring as described herein. Visualization may, e.g., comprise creating graphs showing data trends over time, pain maps of the patient’s body, etc.

[0039] An exemplary method may further comprise decrypting the medical data at least partly; and optionally providing the at least partly decrypted data to a database.

[0040] Decrypting may, e.g., be a step allowing to process decrypted medical data which may decrypt privacy-sensitive data according to regulatory standards for the use of medical data. The decrypting may, e.g., result in data free of such privacy-sensitive information, in machine- and / or human readable data, such as to allow a transfer to external devices receiving the reports.

[0041] The at least partly decrypted data ma, e.g., be provided to the database in form of finished report ready to be pulled and / or downloaded by any suitably recipient of that report.

[0042] The at least one medical device comprises an implant, e.g., a spinal cord stimulator, a deep brain stimulator, an electrocardiogram, an integrated care manager, a pacemaker, a defibrillator, an implantable cardioverter-defibrillator, an accelerometer, a blood pressuresensor, and / or a closed-loop stimulator.

[0043] Implants may e.g., be particularly suitable for applications in remote patient monitoring as they may provide medical data at all times allowing for continuous patient monitoring, identifying long- and short-term trends early on.

[0044] Another aspect of the invention provides a method for remote patient monitoring comprising the following steps: sending a subscription notification to at least one patient state and / or patient event of a patient and receiving a report on the patient state and / or patient event, when medical data from at least one medical device of the patient indicate the at least one patient state and / or patient event.

[0045] This aspect provides the counterpart of the method providing the reports as described herein by relating to the method performed, e.g., by the subscribing recipient via a device allowing them to access the system involved in remote patient monitoring, e.g., via a portal backend comprising, e.g., a web-based user-interface as described herein. This aspect may therefore yield the same advantages as stated above. The recipient may, e.g., subscribe, unsubscribe and / or receive reports via the same and / or different user-interfaces.

[0046] The receiving may, e.g., comprise regularly pulling a report from a database, based at least partly on the patient state and / or patient event the recipient subscribed to.

[0047] This may, e.g., occur according to a schedule as described herein and help to sustain continuous remote patient monitoring to keep the quality of remote care high.

[0048] Another aspect of the invention proved a system for remote patient monitoring comprising means for receiving medical data from at least one medical device of a patient, means for determining a patient state and / or patient event at least in part based on the medical data, and means for determining one or more recipients of a report on the patient state and / or patient event at least in part on the patient state and / or patient event.

[0049] Such systems allow for full integration of the medical device’s capabilities into the medical care specialist field in an efficient, direct, sustainable manner which maximizes the device value to the patient by optimizing remote patient monitoring. The system poses a medical implantable device-coupled diagnostic system, comprising a framework for diagnostics, visualization and providing reports, as described herein. The diagnostic framework may consist of a data aggregation means (e.g., a database), a diagnostic network processing means, a user interface which allows for subscribing, unsubscribing, receiving reports, etc., and determining recipients for said reports. It may further comprise other tools providing billing services, e.g., for accessing reimbursable diagnostic data. The system may allow for multiple recipients of the reports and may inform each recipient of their role in order to prevent duplicate medical practice and / or billing.

[0050] According to a further aspect, a computer program comprises instructions for: receiving medical data from at least one medical device of a patient, determining a patient state and / or patient event at least in part based on the medical data, and determining one or more recipients of a report on the patient state and / or patient event at least in part on the patient state and / or patient event.

[0051] The methods herein may be computer-implemented methods, and a computer program may be provided with instructions according to the steps of the methods. Further, any functionality described herein in reference to the system may be implemented as steps of a method and / or as instructions of a respective computer program, and vice versa.

[0052] Computer programs may be stored in any storage device, and the various method steps may be implemented in software or hardware or a combination thereof.

[0053] Embodiments of the present disclosure may be realized in any of various forms. For example, in some embodiments, the present invention may be realized as a computer-implemented method, a computer-readable memory medium, or a computer system.

[0054] In some embodiments, a non-transitory computer-readable memory medium may be configured so that it stores program instructions and / or data, where the program instructions, if executed by a computer system, cause the computer system to perform a method, e.g., any of the method embodiments described herein, or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets.

[0055] In some embodiments, a computing device may be configured to include a processor (or a set of processors) and a memory medium, where the memory medium stores program instructions, where the processor is configured to read and execute the program instructions from the memory medium, where the program instructions are executable to implement any of the various method embodiments described herein (or, any combination of the method embodiments described herein, or, any subset of any of the method embodiments described herein, or, any combination of such subsets). The device may be realized in any of various forms. Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.

[0056] The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.

[0057] Fig. 1 shows an exemplary system for the distribution of information provided by a medical device to one determined recipient.

[0058] Fig. 2 shows an exemplary scenario of information distribution between multiple patients and multiple recipients of information.

[0059] Fig. 3 shows an abstracted schematic representation of the communication infrastructure for medical device data allocation to a user interface highlighting an exemplary grouping of involved components into two blocks.

[0060] Fig. 4 shows an exemplary trial summary report.

[0061] Fig. 5 shows an exemplary therapeutic monitoring report.

[0062] Fig. 6 shows an exemplary programming session report.

[0063] Fig. 7 shows an exemplary device data transmission log. Fig. 8 shows a user interface for data input for the identification of primary pain areas.

[0064] Fig. 9 shows a long-term follow-up display of a medical device battery charge and a recent recharge.

[0065] Fig. 1 shows an exemplary system 10 wherein a patient 11 carries an implanted medical device 12. The medical device 12 collects medical data 13 and provides them to a central server system 14 where they are collected and processed: Said processing comprises determining the patient state of the patient 11 and / or determining whether a patient event has occurred. Based on that processing the server system 14 may comprise one or more servers and generates a report 15 on the patient state and / or the patient event associated with the patient 11. It further determines recipient 16 as the recipient for the report 15 and forwards said report 15 to the determined recipient 16. Potential recipients 16a, 16b are not determined as suitable recipients in this exemplary scenario and therefore do not receive the report 15. They may, however, receive reports on other patient states and / or events (as indicated by the dashed arrows), other patients and / or other medical devices.

[0066] The example of Fig. 2 relates to a spinal cord stimulator system containing, within the implanted device, a lead impedance monitor, an internal temperature sensor, a multi-axis motion sensor, and a plethysmography device which detects blood oxygenation and cardiac rhythms. From these sensors, the implanted device collects and transmits medical data, namely, e.g., an average daily temperature of the implanted device, a correlate of core temperature, a daily step count derived from the motion sensor, body position estimates derived from the motion sensor, any detected high-jerk or impact events detected from the motion sensor, a sleep score derived from the motion sensor, epochs of differing levels of activity derived from the motion sensor, a daily heart rate histogram derived from the plethysmography sensor, blood oxygenation trends derived from the plethysmography sensor, and potential arrythmia snapshots derived from the plethysmography sensor. This medical data is transmitted to a data aggregation component of an external network- connected diagnostic system, as described herein. The data aggregation component stores the collected data and makes it available to the diagnostic processor component of the diagnostic system.

[0067] In the example of Fig. 2, a server processes the data from patients in an exemplary method 20, and detects the following:

[0068] Patient 21a experienced a high-jerk impact event. Patient 21b exhibited a trend of decreasing activity, increased heart rate, and increased temperature over tend over the course of 3 days. Patient 21c experienced episodes of high heart rate variability which became more frequent. Patient 21d experienced a trend of decreasing sleep restfulness and periods decreasing blood oxygenation levels during sleep hours over the course of a year. Patient 21e experienced out of range impedance on a contact that was used to deliver spinal cord stimulation therapy, and the patient reported higher pain scores in their patient partner application, along with a trend of decreasing levels of high activity. There may be further patients and / or potential recipients connected to the system of Fig. 2 which are not shown here.

[0069] The diagnostic distribution component of the diagnostic system then receives the medical data of each patient and processes this against the caregiver specifications unique to each patient, such that:

[0070] The example of Fig. 2 illustrates different patient states and / or events and / or different kinds of reports 25a, 25b, 25c, 25d, 25e, 25f thereon provided to the recipients 26a, 26b, 26c, 26e, 26f: The local caregiver 26a of patient 21a is alerted by text message 25a that a certain patient event (the potential fall of the patient) has occurred, and that they can log into the diagnostic system to view the patient event. The primary care physician 26b for patient 21b receives an email 25b, 25d from the diagnostic system that a new patient event has occurred for patients 21b and 21d, both of which they provide care for. The practitioner of this physician 26b logs into the diagnostic web portal to view information 25b, 25d on both patients 21b, 2 Id. The cardiologist 26c office of patient 21c receives a low-priority entry 25c to evaluate the patient 21c for atrial fibrillation at their next office visit. The pain physician 26e for patient 21e receives a notification 25e in their monthly list of patient events, they subscribed to, that patient 21e may have experienced a lead failure and to follow up with the patient regarding reprogramming performed. In addition, the medical company 26f responsible for patient 21e’s implant receives a notification 25f that a patient event has occurred for patient 21e which may be lead failure. The representative 26f responsible for this patient automatically receives a notification 26f what a follow-up with this patient is desired, based on the multiple concurrent events.

[0071] A record of data containing these events may also be provided to each of the caregivers, physicians, and medical company representatives covering care (not shown).

[0072] Fig. 3 shows an abstracted schematic representation of the communication infrastructure 30 for medical device data allocation to a portal backend 39, e.g., in the form of reports to determined recipients as described herein. In this representation, intermediate and / or internal elements of the system 30 are shown to provide a better overview and indeed in some embodiments only one or more selected such elements are present. These elements may form, e.g., at least a part of the server system of Fig. 1 and / or may constitute separate elements. The infrastructure 30 is one example for a system determining recipients and distributing reports to recipients as described in reference to Fig. 2.

[0073] The first block 31 in the simplified schematic representation of Fig. 3 comprises the medical device 32 and the secure medical device server 33, wherein the medical device 32 provides (encrypted) medical data to the secure medical device server 33. The medical data may comprise, e.g., a home monitoring frame containing different data, many of which are highly sensitive from a privacy / regulatory perspective. For example, these data comprise patient information (sensitive), a device status, battery and charging information, therapy information, ISW forensic data, and / or physiologic monitoring data. Typically, these data are compressed and encrypted to minimize the required medical device memory. Especially implantable medical devices have only limited storage due to limitations in terms of available space and energy consumption that large data storage may bring along. The secure medical device server 33 processes, decompresses, and / or decrypts the compressed and / or encrypted medical data at least partly.

[0074] The second block 34 comprises a connectivity system 35 and an intelligence layer 36. At least a part of the medical data at least partly decrypted by the secure medical device server 33 may be transmitted to the second block 34 (in detail, its connectivity system 35).

[0075] Additionally or alternatively, a follow-up report, as described herein, may be provided by the secure medical device server 33 to the second block 34 (in detail, its intelligence layer 36).

[0076] The data provided to the connectivity system 35 may, e.g., have the following content (or other, e.g., non-human-readable content / format):

[0077] 54 68 65 20 71 75 69 63

[0078] 6b 20 62 72 6f 77 6e 20

[0079] 66 6f 78 20 6a 75 6d 70

[0080] 73 20 6f 76 65 72 20 31

[0081] 33 20 6c 61 7a 79 20 64

[0082] 6f 67 73 2e

[0083] In general, a proprietary format may be used.

[0084] The intelligence layer 36 may additionally receive data from the connectivity system 35, and (optionally) further data from a patient remote 37 and / or further devices 38, e.g., wearables, web-user-interfaces, etc. The further data may comprise patient-reported data, health professional-reported data, and / or device-reported data, e.g., recorded by the at least one external device 37, 38. The further data from the further devices 37, 38 may comprise, e.g., automatically acquired data from external devices, physiological monitoring data, e.g., from wearables like activity monitors, step counters, pulse frequency, etc., patient-reported data from, e.g., surveys via the patient app, and / or clinician-reported data. The further data may generally comprise objective and / or subjective data. The intelligence layer 36 may process and / or merge all incoming data at least partly and provides processed data to portal backend 39, e.g., as required to be outputted by the portal backend 39.

[0085] The processed data preferably have a human- and / or machine-readable format and content, e.g., in form of a JSON file. The processed data may, e.g., have the following content (or other, e.g., human- and / or machine-readable content / format):

[0086] { therapyDate=23 -03-01 patientID=“P-0123” therapyUsage=“ 100%”

[0087] B attery StateOfCharge=75 painScore=3 }

[0088] In general, thus the data may be decrypted from a proprietary format to a generally readable (data) format, such as JSON or similar formats, for example.

[0089] The portal backend 39 of the example shown in Fig. 3 does not perform any further data transformation but just configures the visualization of the received pre-processed data. For example, the portal backend 39 may output sales data, patient data, stimulator data, follow up data, patient management data (including, e.g., educational information for education sessions and / or proactive care triggers), and / or further clinically understandable data. Generally, all data received and / or outputted by the portal backend 39 via a user interface maybe clinically understandable to any expert on the respective medical field and / or on the respective medical device(s) 32, 38. The portal backend 39 performs functions to visualize the clinically understandable data in a one stop shop for different recipients. For example, this may facilitate sales, patient journey management, and remote monitoring with proactive care by health professionals. In some examples, the intelligence layer 36 may decrypt encrypted data received from the secure medical device server and / or a secure medical device database located therein.

[0090] In the following, some exemplary reports (of Figs. 5 - 6) are described that may be provided to determined recipients on different patient states and / or patient events:

[0091] Fig. 4 shows an exemplary trial summary report 40. Such report 40 may be issued by the system automatically or upon request by, e.g., the attending clinician. At the end of an SCS trial period (i.e., to determine if a patient is a suitable candidate for an implanted SCS device), patient reported metrics may be summarized in a trial summary report 40 which may be reviewed by a clinician user as supplementary information to assess the patient’s response to the SCS therapy.

[0092] The following is an exemplary workflow to generate the trial summary report 40: (i) The trial summary report 40 is generated in the portal by the care team after the patient has completed their SCS trial, (ii) During the lead pull appointment, the attending clinician / technical expert / manufacturer representative may add pain relief and notes (including qualitative description of medication changes) to the report 40 based on the patient’s final assessment of their therapy response, (iii) The manufacturer representatives may make the report available to the clinic in the portal, (iv) The clinician may use the portal to access the report 40.

[0093] The exemplary report 40 of Fig. 4 comprises a report identification section 41, e.g., a title relating to the topic of the report 40, a patient identification section 42, e.g., comprising patient name, date of birth, manufacturer identification, implantation date, medical device (e.g., SCS) serial number, and / or medical device (e.g., SCS) model. The exemplary trial summary report 40 comprises, in this specific example, six further sections 43, 44, 45, 46, 47, 48. Section 43 comprises a pain score trend in which the pain score is shown as a function of time, for example as data points on multiple consecutive days to visualize trends during the trial phase. Section 44 comprises a body map highlighting primary pain areas. As shown in Fig. 4, primary areas where the patient experienced pain may be highlighted in a colour in a front and back view of a body map of the patient. Further sections 45, 46, 47, 48 show medical data as a function of time for example as single data points on different dates, namely function scores (section 45), sleep scores (section 46), patient activity (section 47), and patient mood scores (section 48).

[0094] Fig. 5 shows an exemplary therapeutic monitoring report 50. Such report 50 may be issued by the system automatically or upon request by, e.g., the attending clinician. Issuing such therapeutic monitoring reports 50, similar, or other reports for remote monitoring of patients may be seen as a central functionality of the system itself as it allows for closed loop monitoring of the patient which may significantly improve remote care quality, especially considering the triggers implemented in the system as described herein. The portal may allow clinician users to access a therapeutic monitoring report 50 on-demand to review the patient’s condition with the patient during in-office or remote visit. The therapeutic monitoring report 50 may contain device data information captured in the portal and can be downloaded by the clinician for documentation purposes. Furthermore, the therapeutic monitoring report 50 may serve as evidence of remote patient monitoring when submitting reimbursement claims for remote therapeutic monitoring reimbursement codes. Clinician users may be able to adjust the report data time window to capture a minimum of 16 days of device data within a 30-day period to meet criteria for reimbursement for remote therapeutic monitoring and for physiologic monitoring, respectively. The portal may also be capable of logging the number of report generations per month for internal tracking. Further, the system may be capable of alerting the clinic if the minimum of 16 days of device data within a 30- day period is at risk of not being met.

[0095] The exemplary report 50 of Fig. 5 comprises a report identification section 51, e.g., a title relating to the topic of the report 50, a patient identification section 52, e.g., comprising patient name, date of birth, manufacturer identification, implantation date, medical device (e.g., SCS) serial number, and / or medical device (e.g., SCS) model. The exemplary therapeutic monitoring report 50 comprises a first section 53 showing daily therapy usage detail trends in a given time window, where in the therapy usage of the patient by using the medical device is shown overtime for example by showing which program was used or not used on each day. Each color of the respective bar for one time window, e.g., a day, indicates a program / stimulation mode. The therapeutic monitoring report 50 further comprises a section 54 comprising a patient interaction log listing which triggers were activated on which date which technical staff member was involved and how the associated issue was resolved. Section 55 of the (remote) therapeutic monitoring report 50 comprises information on the programs in the patient programmer on a given date, for example the date of issuing the therapeutic monitoring report 50. Section 55 may, e.g., further comprise for each program identified by a program name, the contacts involved in delivering the therapy and the respective stimulation mode. Section 56 of the exemplary report 50 comprises information on therapy usage mix, for example in a 30-day time window. In the example of Fig. 5, two pie charts show the relative therapy usage by program name and by stimulation mode.

[0096] Fig. 6 shows an exemplary programming session report 60. Such report 60 may be issued by the system automatically or upon request by, e.g., the attending clinician. For each therapy device programming session interaction, the care team and clinicians may view the programming session report 60 in the portal.

[0097] The exemplary report 60 of Fig. 6 comprises a report identification section 61, e.g., a title relating to the topic of the report 60, a patient identification section 62, e.g., comprising patient name, date of birth, manufacturer identification, implantation date, medical device (e.g., SCS) serial number, and / or medical device (e.g., SCS) model. The report 60 of Fig. 6 further comprises a programming section 63, e.g., comprising a follow-up date, a programming duration, information on who performed the programming, reason for the follow up, and / or a location of the programming session. Such programming section 63 may relate to a (re-)programming of the medical device of the patient either via conventional in person programming or via remote programming. Further, it may comprise a general settings section 64, listing, e.g., information on the stimulation mode, a magnetic resonance imaging (MRI) mode wherein the medical device is switched into a mode allowing for MRI, and / or lead impedance tests. The system may issue a programming session report 60 independently of how exactly the programming has been performed. The exemplary programming session report 60 further comprises two sections 65, 66 on the two leads (A and B) of the SCS, e.g., relating for each contact to an impedance and an electrode status. The report 60 further comprises a program summary comprising a first chart 67 on the initial settings of the SCS and a second chart 68 on the final settings of the SCS. In the shown example, for each program of the SCS, indicated by a program name, the respective chart 67, 68 indicates whether the program has been edited (changed / newly created / deleted / ...), its mode, which contacts are involved in the respective stimulation, the stimulation strength / amplitude (e.g., in mA), the pulse width (e.g., in microseconds) and / or the stimulation frequency (e.g., in Hz).

[0098] The following Figs. 7 - 9 show elements that may either be part of user interfaces for inputting medical data which may indicate a patient state and / or a patient event and / or which may be comprised in a report as described herein:

[0099] Fig. 7 shows an exemplary device data transmission log 70. This data log may be provided, e.g., to the portal backend as described herein to be accessed by a clinician to track the data received through the system and / or to assign the data to potentially multiple patients and / or devices. The log 70 may comprise a list of data transmission events, e.g., providing for each event The serial number of the involved medical device, a message creation date, a message creation time including the relevant time zone, and / or the time at which the data were received by the portal backend.

[0100] Fig. 8 shows a user interface 80 for data input for the identification of primary pain areas 84. The patient and / or the clinician may provide corresponding data on the type of pain 83 (e.g., aching, burning, cramping, shooting, tingling, numbness, stabbing, spasm, etc.) and / or a pain intensity 82 (e.g., on a scale from 0 - 10) for different areas 84 of the patient’s body according to a body map 81. This interface 80 may be e.g., shown like this or in a similar way by the patient app and / or the (online) portal backend described herein, e.g., in form of a report.

[0101] Fig. 9 shows a long-term follow-up display 90 of a medical device battery charge 91 and a recent recharge 94, which may be e.g., shown like this or in a similar way by the patient app and / or the (online) portal backend described herein, e.g., comprised in a report. The exemplary graph shows three data series, the medical device battery charge 91, the default charge level of 15% 92, and the low battery level of 10% 93 (both of which may be triggers for alters provided to e.g., the patient via the portal backend and / or the patient app instructing the patient to recharge the medical device) over time as reports. Upon the recent recharge 94, as possibly suggested by the respective alert triggered by the battery charge falling below 15% and / or 10%, the battery charge increases from < 5% to 100%.

Claims

Claims1. A method for remote patient monitoring, comprising the following steps: receiving medical data (13) from at least one medical device (12) of a patient (11); determining a patient state and / or patient event at least in part based on the medical data (13); and determining one or more recipients (16) of a report (15) on the patient state and / or patient event at least in part on the patient state and / or patient event.

2. The method of claim 1, further comprising: receiving a subscription notification to at least one patient state and / or patient event from a potential recipient (16); wherein the determining of the one or more recipients (16) is further based at least in part on the subscription notification.

3. The method of any of claims 1 or 2, further comprising providing the report (15) to the one or more recipients (16).

4. The method of any of claims 1 - 3, further comprising providing the report (15) to a default recipient (16) if the determining fails.

5. The method of any of claims 1 - 4, further comprising adapting the report (15) at least partly based on the recipient (16).

6. The method of any of claims 1 - 5, wherein the method comprises providing reports (15) on a regular basis.

7. The method of any of claims 1 - 6, further comprising providing a report (15), if the medical state and / or the medial event indicate a medical issue.

8. The method of any of claims 1 - 7, wherein the report (15) comprises at least one of the following: device data, physiological patient data, and a patient identifier.

9. The method of any of claims 1 - 8, further comprising processing the medical data (13) to provide visualization data for visualization of the medical state and / or medical event.

10. The method of any of claims 1 - 9, further comprising decrypting the medical data (13) at least partly; and optionally providing the at least partly decrypted data to a database.

11. The method of any of claims 1 - 10, wherein the at least one medical device (12) comprises an implant.

12. A method for remote patient monitoring comprising the following steps: sending a subscription notification to at least one patient state and / or patient event of a patient (11); and receiving a report (15) on the patient state and / or patient event, when medical data (13) from at least one medical device (12) of the patient (11) indicate the at least one patient state and / or patient event.

13. The method of claim 11, wherein the receiving comprises regularly pulling a report (15) from a database, based at least partly on the patient state and / or patient event the recipient (16) subscribed to.

14. System (10) for remote patient monitoring comprising: means for receiving medical data (13) from at least one medical device (12) of a patient (i i); means for determining a patient state and / or patient event at least in part based on the medical data (13); and means for determining one or more recipients (16) of a report (15) on the patient state and / or patient event at least in part on the patient state and / or patient event.

15. A computer program comprising instructions for: receiving medical data (13) from at least one medical device (12) of a patient (11); determining a patient state and / or patient event at least in part based on the medical data (13); and determining one or more recipients (16) of a report (15) on the patient state and / or patient event at least in part on the patient state and / or patient event.

Images