Remote health monitoring using plug-in devices under event and status health monitoring

Abstract

Technologies for telehealthcare monitoring using a plug-in device include receiving a healthcare plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data regarding the patient from one or more healthcare monitoring devices based on the healthcare plan; and transmitting the healthcare data to the remote source.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims priority to co-pending Indian Patent Application No. 202241037054, titled “Remote Health Monitoring Using Plug-in Devices with Eventful and Stateful Health Monitoring” filed on June 28, 2022. The subject matter of this related application is hereby incorporated herein by reference. background Technical Field

[0004] Embodiments of the present invention generally relate to providing healthcare services, and more particularly, to remote health monitoring using plug-in devices in both episodic and stateful health monitoring.

[0005] Related technical notes

[0006] Remote health monitoring services provided via mobile applications have played an important role in the transformation of the healthcare industry. Using mobile applications, which are often installed on smartphones, healthcare providers ( For example , doctors and nurses) can easily contact their patients after they are discharged from the hospital or leave the clinic, and continue to provide healthcare remotely. Remote health monitoring services may involve video calls between patients and healthcare providers for consultation and diagnosis, as well as video calls via healthcare monitoring devices ( For example , wearable healthcare monitoring devices) monitor patient vital signs ( For example , blood pressure, pulse rate, etc.), the healthcare monitoring device reports the patient information to a mobile application, and the mobile application provides the patient information to a remote healthcare provider via a wireless or wired communication network.

[0007] Smartphone applications are well suited to providing remote health monitoring services because they have built-in communications network connections, video displays, cameras, speakers, microphones, and computing power to collect, organize, and transmit patient data. Typical smartphones also include wireless networking capabilities ( For example , Bluetooth TM), which enables smartphones to wirelessly collect patient data from healthcare monitoring devices. However, one drawback to using smartphones to monitor patients is that some patients have difficulty using smartphones. These difficulties can include the inability to use the small screen of a smartphone as an input device because muscle control issues interfere with the patient's fine motor control. These difficulties can also include the inability to read information on the smartphone's screen due to the patient's impaired vision. For these reasons, many elderly patients resist adopting remote health monitoring applications.

[0008] Healthcare monitoring devices can measure various vital signs, monitor activity levels, and capture stressful events by frequently collecting data about a patient at regular intervals without user intervention. Measuring vital signs so frequently generates a large amount of health data, which can be challenging for healthcare providers and / or data analysis programs to analyze, correlate, and interpret. In addition, since many battery-powered healthcare monitoring devices have limited battery capacity, configuring frequent data collection can cause the battery to drain quickly, which results in frequent recharging or frequent battery replacement. To address this issue, healthcare monitoring devices are often configured to compromise by collecting data less frequently in order to reduce the amount of data generated and increase the battery life of the healthcare monitoring device. However, capturing data less frequently may cause the healthcare monitoring device to miss capturing important data at important moments, such as when the patient is experiencing a stressful condition or is in an important physiological state ( For example , heart attack).

[0009] As previously explained, what is needed in the art is a system that provides remote health monitoring services on a device with a larger screen and the ability to adaptively change data collection from a healthcare monitoring device in both episodic and stateful health monitoring. Summary of the invention

[0010] Various embodiments of the present disclosure describe a computer-implemented method for remote health monitoring, including: receiving a healthcare plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices; and sending the healthcare data to the remote source.

[0011] Additional embodiments provide, among other things, one or more non-transitory computer-readable media and systems configured to implement the methods set forth above.

[0012] At least one technical advantage of the disclosed technology over the prior art is that with the disclosed technology, the possibility of users using remote health monitoring applications is increased, which makes the remote health monitoring applications and associated remote health monitoring platforms more effective and reliable. Another advantage is that patient health data is collected at a time relevant to the patient's health status, while reducing power consumption, reducing memory usage and reducing bandwidth. Another advantage is that the computing resources used to analyze the collected data are reduced. These technical advantages provide one or more technical improvements over prior art methods. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] In order to be able to understand the above-mentioned features of various embodiments in detail, the inventive concept briefly summarized above can be described in more detail by reference to various embodiments, some of which are shown in the accompanying drawings. However, it should be noted that the accompanying drawings only show typical embodiments of the inventive concept and are therefore not to be considered as limiting the scope in any way, and there are other equivalent embodiments.

[0014] Figure 1 is a schematic diagram of a remote patient monitoring (RPM) system configured to implement one or more aspects of the present disclosure;

[0015] Figure 2 shows an example of a graphical user interface (GUI) for configuring a healthcare plan according to various embodiments of the present disclosure;

[0016] Figure 3 shows an example of a GUI for configuring a healthcare plan according to various embodiments of the present disclosure;

[0017] Figure 4 A flowchart showing method steps for remote health monitoring according to various embodiments of the present disclosure;

[0018] Figure 5 A flowchart showing method steps for remote health monitoring according to various embodiments of the present disclosure; and

[0019] Figure 6 A flow chart showing method steps for remote health monitoring according to various embodiments of the present disclosure is shown. DETAILED DESCRIPTION

[0020] In the following description, numerous specific details are set forth to provide a more thorough understanding of various embodiments. However, it will be apparent to one skilled in the art that the inventive concept may be practiced without one or more of these specific details.

[0021] Figure 11 is a schematic diagram of a remote patient monitoring (RPM) system 100 configured to implement one or more aspects of the present disclosure. The RPM system 100 is configured to implement one or more aspects of the present disclosure. For example , physician, nurse practitioner or nurse) to monitor and collect healthcare data about the patient 102 using a healthcare plan selected and / or configured by the patient. The RPM system 100 includes, but is not limited to, a plug-in device 110, one or more healthcare monitoring devices 136, a server 160, a data store 172, a healthcare plan library 174 and a provider device 180. The devices of the RPM system 100 communicate with each other or via a network 150 ( For example , Internet) communications.

[0022] The plug-in device 110 is a computer-based system that interacts with the patient 102 via various devices, including but not limited to a media device 134, a remote control 132, a camera 130, and one or more healthcare monitoring devices 136. The plug-in device 110 includes but is not limited to an input / output (I / O) interface 112, a processing system 114, a network interface 116, and a memory 118. In some embodiments, the plug-in device 110 is an over-the-top (OTT) device, such as a Fire TV. TM Stick, Apple TM TV, Chromecast TM ,Roku TM 、Nvidia Shield TM Etc. The plug-in device 110 may include any technically feasible type of computer system.

[0023] The I / O interface 112 facilitates the connection between the plug-in device 110 and the peripheral devices. The I / O interface may include one or more of the following: a high-definition multimedia interface (HDMI), a universal serial bus (USB) interface, an infrared (IR) interface, a radio frequency (RF) interface, a serial interface, a parallel interface, etc. Examples of devices with which the plug-in device 110 can communicate via the I / O interface 112 include, but are not limited to, a camera 130 (which may include a microphone), a media device 134 (which may include a speaker), and a remote control 132 associated with the plug-in device 110.

[0024] The processing system 114 typically includes a programmable processor that executes program instructions to manipulate input data and generate output data. The processing system 114 can be implemented as a central processing unit (CPU), a digital signal processing unit (DSP), a microprocessor, an application-specific integrated circuit (ASIC), a neural processing unit (NPU), a graphics processing unit (GPU), a field programmable gate array (FPGA) and / or any other type of processing unit, or a combination of different processing units. The processing system 114 of the plug-in device 110 executes the patient-side remote patient monitoring application 120 stored in the memory 118.

[0025] The network interface 116 enables the patient-side RPM application 120 to communicate with the network 150 and, via the network, with the provider-side RPM platform 168 executing on the server 160. The network interface 116 also enables the patient-side RPM application 120 to communicate with one or more healthcare monitoring devices 136 ( For example , FitBit TM ) communication. The network interface 116 may implement any technically feasible wired or wireless communication protocol to facilitate communication with the network 150 and / or the healthcare monitoring device 136. For example, the network interface 116 may include one or more of the following: an optical network interface, a wired network interface, an Ethernet interface, a Wi-Fi transceiver, a Bluetooth TM Transceiver, etc.

[0026] The memory 118 includes a memory module or a collection of memory modules. The memory 118 may include various computer-readable media selected for their size, relative performance or other capabilities: volatile and / or non-volatile media, removable and / or non-removable media, etc. The memory 118 may include cache, random access memory (RAM), storage, etc. The memory 118 may include one or more discrete memory modules, such as dynamic RAM (DRAM) dual in-line memory modules (DIMMs). In various embodiments, non-volatile memory includes flash memory, optical drive, magnetic drive, flash drive, and / or other non-volatile storage. In some embodiments, a separate data storage place (not shown) may supplement the memory 118.

[0027] The memory 118 typically stores application programs, including the patient-side RPM application 120, and data for processing by the processing system 114. In some embodiments, the memory 118 includes various software programs and modules ( For example, operating system, one or more applications, etc.) and application data associated with the software program. As shown, the memory 118 includes at least a patient-side RPM application 120, which is executed by the processing system 114 to implement the overall functionality of the plug-in device 110 related to remote patient monitoring, as discussed in more detail herein.

[0028] The patient-side RPM application 120 configures the healthcare monitoring device 136 and receives healthcare data captured by the healthcare monitoring device 136. In some examples, the RPM application 120 uses an API provided by the software 146 of the healthcare monitoring device 136 to request healthcare data from the healthcare monitoring device 136 at periodic intervals, in response to various alarms, in response to notifications received from the healthcare monitoring device 136, and / or in response to notifications received from another healthcare monitoring device 136. As shown, the patient-side RPM application 120 uses the network interface 116 to communicate with the healthcare monitoring device 136. For example, the patient-side RPM application 120 can communicate via any feasible wired ( For example , USB) or wireless ( For example , Wi-Fi or Bluetooth TM ) network protocol to communicate with the healthcare monitoring device 136. The patient-side RPM application 120 stores the received healthcare data in the memory 118 or alternatively in a separate storage (not shown).

[0029] The patient-side RPM application 120 communicates with the provider-side RPM platform 168 via the network 150 using the network interface 116. The patient-side RPM application 120 receives the healthcare plan from the provider-side RPM platform 168. In some examples, the patient-side RPM application 120 sends a confirmation of receipt of the healthcare plan to the provider-side RPM platform 168 after receiving the healthcare plan from the provider-side RPM platform 168. The patient-side RPM application 120 converts the healthcare data ( For example , healthcare data received from the healthcare monitoring device 136 and stored in the memory 118 is sent to the provider-side RPM platform 168.

[0030] The patient-side RPM application 120 communicates with the media device 134, the camera 130, and the remote control 132 via the I / O interface 112 and / or the network interface 116. The patient-side RPM application 120 communicates with the media device 134 to present information to the patient 102. In some examples, the information includes content related to the healthcare plan ( For example, post-visit summary, educational materials, etc.). The patient-side RPM application 120 presents healthcare reminders and / or healthcare alarms as needed based on the healthcare plan and patient monitoring data. The patient-side RPM application 120 communicates with the camera 130 to receive images of the patient 102, facilitate video calls with healthcare providers, etc. The patient-side RPM application 120 communicates with the remote control 132 to receive input from the patient 102, such as when the patient 102 uses the remote control to navigate and interact with a user interface presented by the patient-side RPM application 120 on the media device 134.

[0031] Server 160 is a computer-based system that supports the provider-side functionality of RPM system 100. Server 160 includes, but is not limited to, a processing system 162, memory 166, network interface 164, and I / O interface 170. Additionally, while server 160 is illustrated as a single server, it should be understood that the functionality provided by server 160 may be provided by two or more servers, one or more virtual machines as part of a server, as part of a cloud-based infrastructure, etc.

[0032] The processing system 162 typically includes a programmable processor that executes program instructions to manipulate input data. The processing system 162 can be implemented as a central processing unit (CPU), a digital signal processing unit (DSP), a microprocessor, an application specific integrated circuit (ASIC), a neural processing unit (NPU), a graphics processing unit (GPU), a field programmable gate array (FPGA) and / or any other type of processing unit, or a combination of different processing units.

[0033] The network interface 164 enables the provider-side RPM platform 168 to communicate with the patient-side RPM application 120 and one or more healthcare providers 198 using the network 150. In some embodiments, the network interface 164 also enables the provider-side RPM platform 168 to communicate with the healthcare monitoring device 136 via the network 150. The network interface 164 may implement any technically feasible wired or wireless communication protocol to facilitate communication with the network 150 and / or the healthcare monitoring device 136. For example, the network interface 164 may include one or more of the following: an optical network interface, a wired network interface, an Ethernet interface, a Wi-Fi transceiver, a Bluetooth® transceiver, a wireless communication protocol ... TM Transceiver, etc.

[0034] The memory 166 includes a memory module or a collection of memory modules. The memory 166 may include various computer-readable media selected for their size, relative performance or other capabilities: volatile and / or non-volatile media, removable and / or non-removable media, etc. The memory 166 may include cache, random access memory (RAM), storage, etc. The memory 166 may include one or more discrete memory modules, such as dynamic RAM (DRAM) dual in-line memory modules (DIMMs). In various embodiments, non-volatile memory includes flash memory, optical drives, magnetic drives, flash drives, and / or other non-volatile storage.

[0035] Memory 166 typically stores applications including provider-side RPM platform 168, as well as data for processing by processing system 162. In some embodiments, memory 166 includes various software programs and modules ( For example , operating system, one or more applications, etc.) and application data associated with the software program. As shown in the figure, the memory 166 includes at least a provider-side RPM platform 168.

[0036] In some embodiments, a separate data store, such as data store 172, supplements memory 166. In some examples, data store 172 includes storage for various libraries and / or other data sources to support the operation of RPM system 100. In some examples, data store 172 is coupled to one or more storage devices ( For example , disk drive, database, etc.). Additionally and / or alternatively, the data store 172 can be coupled to the server 160 via the network 150 and can include network attached storage, cloud-based storage, etc.

[0037] The I / O interface 170 enables the provider-side RPM platform 168 to communicate with various peripheral devices to communicate with the healthcare provider 198. Examples of devices with which the provider-side RPM platform 168 can communicate via the I / O interface 170 include, but are not limited to, a camera (which may include a microphone), a media device (which may include a speaker), a keyboard, and / or a touch screen.

[0038] The provider-side RPM platform 168 provides one or more user interfaces that can be used by the healthcare provider 198 to configure the healthcare plan assigned to the patient 102. For example, the provider-side RPM platform 168 can retrieve a disease-specific or diagnosis-specific healthcare plan from the healthcare plan library 174 and present the retrieved healthcare plan to the healthcare provider 198 for the healthcare provider 198 to use in configuring and / or editing the healthcare plan assigned to the patient 102. The provider-side RPM platform 168 can also retrieve the patient's healthcare data from the data store 172 containing the patient's assigned healthcare plan and patient-specific healthcare data. Under the guidance of the healthcare provider 198, when the healthcare provider 198 has completed creating or updating the healthcare plan, the provider-side RPM platform 168 transmits the healthcare plan to the patient-side RPM application 120 on the plug-in device 110.

[0039] The provider-side RPM platform 168 also receives healthcare data of the patient 102 from the patient-side RPM application 120. The provider-side RPM platform 168 stores the received healthcare data of the patient 102 in the data storage 172. The provider-side RPM platform 168 analyzes the received healthcare data of the patient 102 to determine whether to send an alert to the healthcare provider 198 regarding updates and / or changes in the health status of the patient 102.

[0040] The data store 172 stores the healthcare data and one or more healthcare plans of the patient 102. The data store 172 may include non-volatile storage, such as an optical drive, a magnetic drive, a flash drive, and / or other non-volatile storage.

[0041] The healthcare plan library 174 stores one or more healthcare plans that are intended to be used and can be customized for any patient 102. The healthcare plan library 174 can include non-volatile storage, such as an optical drive, a magnetic drive, a flash drive, or other storage. The healthcare provider 198 can reference the healthcare plans in the healthcare plan library when creating or updating the healthcare plan assigned to the patient 102.

[0042] Each healthcare monitoring device includes, but is not limited to, a processing unit 138, a memory 144, a network interface 142, and one or more sensors 140. The healthcare monitoring devices 136 each receive a configuration from the patient-side RPM application 120 or from the provider-side RPM platform 168, sense the patient 102 based on the configuration to collect healthcare data, store the healthcare data, and send the healthcare data to the patient-side RPM application 120 or the provider-side RPM platform 168.

[0043] Processing unit 138 may include a central processing unit (CPU), a digital signal processing unit (DSP), a microprocessor, an application specific integrated circuit (ASIC), a neural processing unit (NPU), a graphics processing unit (GPU), a field programmable gate array (FPGA), and / or any other type of processor, or a combination of different processors. Processing unit 138 typically includes a programmable processor that executes program instructions to manipulate input data. In some embodiments, processing unit 138 may include any number of processing cores, memories, and other modules for facilitating program execution.

[0044] Memory 144 includes a memory module or a collection of memory modules. Memory 144 may include various computer-readable media selected for their size, relative performance or other capabilities: volatile and / or non-volatile media, removable and / or non-removable media, etc. Memory 144 may include cache, random access memory (RAM), storage, etc. Memory 144 may include one or more discrete memory modules, such as dynamic RAM (DRAM) dual in-line memory modules (DIMMs). In various embodiments, non-volatile memory, such as optical drives, magnetic drives, flash drives, and / or other types of non-volatile storage. In some embodiments, a separate data storage location may supplement memory 144.

[0045] The memory 144 typically stores application programs, as well as data for processing by the processing unit 138. In various embodiments, the memory 144 stores software 146 for performing various functions or techniques described herein. The software 146 provides an application program interface (API) for the healthcare monitoring device 136. The patient-side RPM application 120 and / or the provider-side RPM platform 168 can use the API to configure, access, and use the functionality provided by the healthcare monitoring device 136.

[0046] The processing unit 138 of each healthcare monitoring device 136 controls one or more sensors 140 to collect healthcare data about the patient 102 based on the configuration received from the patient-side RPM application 120 or the provider-side RPM platform 168. The processing unit 138 of each healthcare monitoring device 136 also stores the healthcare data collected by the one or more sensors 140 in the memory 144. The processing unit 138 of each healthcare monitoring device 136 also sends the stored healthcare data to the patient-side RPM application 120 or the provider-side RPM platform 168 via the network interface 142.

[0047] One or more sensors 140 collect healthcare data of the patient 102. The one or more sensors 140 may sense, for example, the patient's 102 pulse rate, blood pressure, body temperature, electroencephalogram (EEG), electrocardiogram (EKG), rapid eye movement (REM), physical activity ( For example , exercise, walking, climbing stairs), oxygenation level, etc. The processing unit 138 reads the healthcare data measured by one or more sensors, and the processing unit stores the sensed healthcare data in the memory 144 and / or takes other actions in response to the sensed healthcare data ( For example , changing the configuration of sensor 140).

[0048] The provider device 180 enables the healthcare provider 198 to interact with the provider-side RPM platform 168 and / or the patient-side RPM application 120. The provider device 180 interacts with the provider-side RPM platform 168 to enable the healthcare provider 198 to create, review, update, or delete a healthcare plan assigned to the patient 102. The provider device 180 also interacts with the provider-side RPM platform 168 to enable the healthcare provider 198 to review the healthcare data of the patient 102 ( For example , recording of vital signs) and / or video call with patient 102. Provider device 180 interacts with patient-side RPM application 120 to review healthcare data of patient 102 ( For example , current vital signs) and / or conduct a video call with the patient 102. The provider device 180 may be a smartphone, tablet computer, laptop computer, or any other type of computing device capable of communicating via the network 150.

[0049] The patient-side RPM application 120 receives the healthcare plan from the provider-side RPM platform 168 via the network 150, stores the healthcare plan in the memory 118 of the plug-in device 110, and parses the healthcare plan. The patient-side RPM application 120 parses the healthcare plan to identify and process content provision, monitoring configuration, event configuration, status configuration, reminder configuration, and / or alarm configuration for the patient 102.

[0050] The patient-side RPM application 120 configures the healthcare monitoring device 136 according to the healthcare plan received by the patient-side remote patient monitoring application 120. Configuring the healthcare monitoring device 136 includes, but is not limited to, sending instructions to the healthcare monitoring device 136 to collect healthcare data about the patient 102 at a specific time, at regular intervals, in response to a detected event, or in response to a detected state. In some examples, the patient-side RPM application 120 configures the healthcare monitoring device 136 using one or more APIs of the healthcare monitoring device 136. Depending on the capabilities of the healthcare monitoring device 136, the patient-side RPM application 120 may configure the healthcare monitoring device 136 to collect data from different sensors 140 that operate together or independently of each other. In some embodiments, the patient-side RPM application 120 configures the healthcare monitoring device 136 to collect a first type of healthcare data with a first sensor 140 at a first set of times, and to collect a second type of healthcare data with a second sensor 140 at a second set of times. The intervals between the first set of times may be different from the intervals between the second set of times, resulting in the first sensor 140 collecting healthcare data multiple times during a certain period of time and the second sensor 140 collecting healthcare data different times during the same period of time.

[0051] The patient-side RPM application 120 receives the healthcare data from the healthcare monitoring device 136. The patient-side RPM application 120 stores the healthcare data in the memory 118 in the plug-in device 110. The patient-side RPM application 120 may additionally or alternatively forward the healthcare data to the provider-side RPM platform 168.

[0052] The healthcare provider 198 may assign a healthcare plan to the patient 102, and the healthcare provider 198 may customize the healthcare plan for the patient 102. The healthcare plan may include, but is not limited to, content provision, monitoring configuration, event configuration, status configuration, reminder configuration, and / or alarm configuration for the patient 102.

[0053] Content provision in a health care plan includes health care providers associated with the health care plan ( example like , healthcare providers 198) want patients to ( For example, patient 102). For example, the content may include one or more of the following: a post-visit summary, a questionnaire, a set of instructions, and / or third-party content, such as a web page, audio, video, etc. The content may be included in the healthcare plan or identified using a link, such as a uniform resource locator (URL). When the healthcare plan includes content to be provided to the patient, the patient-side RPM application 120 provides the content to the patient. For example, the patient-side RPM application 120 may use the media device 134 to display a user interface with a list of available content. The patient may use the input device ( For example , remote control 132, microphone) to select the content to be consumed. Then, the patient-side RPM application 120 outputs the content to the patient via the output device ( For example , media device 134) to present the content to the patient. When the content is identified by a link or URL, the patient-side RPM application 120 uses the link or URL to retrieve the content so as to present the retrieved content to the patient. In some embodiments, if the patient 102 does not access the content ( For example , watch a provided video or listen to an audio file), the patient-side RPM application 120 can configure a reminder so that the patient 102 can access the content at a later time.

[0054] The event configuration includes, but is not limited to, the definition of a set of healthcare data to be collected and / or reported in response to detecting that a healthcare event has occurred. Examples of events that may be defined in the event configuration include, but are not limited to, the patient 102's vital signs being above or below a threshold, the patient 102 falling, the patient 102 starting or stopping an activity (e.g., exercising, climbing stairs, eating, sleeping, walking, running), etc.

[0055] The state configuration includes, but is not limited to, the definition of a set of vital signs to be reported when a patient is detected to be in a particular physiological state and when the patient is in the physiological state. Examples of physiological states that may be defined in a state configuration include, but are not limited to, sleeping, being in a rapid eye movement (REM) state during sleep, exercising, walking, climbing stairs, giving birth, etc.

[0056] The reminder configuration enables the patient-side RPM application 120 to present reminders to the patient 102. The patient-side RPM application 120 enables the reminders to be presented via the media device 134. The patient-side RPM application 120 can enable the reminders to be presented next to other content on the media device 134, or presented as a pop-up window above other content on the media device 134. The patient-side RPM application 120 can interrupt other content on the media device 134 with reminders and / or pause other content when presenting reminders. In some examples, reminders also include audio components, such as tones, unique sounds, verbal components, etc. Reminders include, but are not limited to, messages about taking medications, messages about appointments with healthcare providers 198, messages about activities of the patient 102 ( For example , sleeping, eating or exercising), messages about content provision to the patient 102, etc.

[0057] The alarm configuration enables the patient-side RPM application 120 to send an alarm to the healthcare provider 198. The alarm configuration has one or more criteria for triggering the alarm and the severity of the alarm ( For example , severe, high, or low). Optionally, the alarm configuration may include a message to be included when the alarm is issued. The criteria for the alarm configuration include, but are not limited to, the healthcare data of the patient 102 ( example like , vital signs measured by healthcare monitoring device 136), lack of healthcare data of patient 102 ( For example , the healthcare monitoring device 136 stops reporting measurements to the patient-side RPM application 120), the patient's 102 lack of responsiveness ( example like , failed to acknowledge reminder), etc. When the severity level of the alarm is "critical", the patient-side RPM application 120 sends an immediate notification, such as a text message or automated phone call, to the healthcare provider 198. When the severity level of the alarm is "high", the RPM application 120 presents an audio and / or visual alarm on the provider device 180. When the severity level of the alarm is "low", the RPM application 120 causes the alarm to be recorded in the data store 172 so that the alarm is presented to the healthcare provider 198 the next time the healthcare provider reviews the patient's 102 record.

[0058] The patient-side RPM application 120 analyzes the healthcare data received from one or more healthcare monitoring devices 136 to detect whether an event defined by an event configuration in the healthcare plan has occurred. If an event is detected, the patient-side RPM application 120 may configure one or more healthcare monitoring devices 136 to measure the vital signs of the patient 102 according to the event configuration. If the patient-side RPM application 120 determines that one healthcare monitoring device 136 can detect an event and measure a vital sign to be reported in response to detecting the event, the patient-side RPM application 120 configures the healthcare monitoring device 136 to detect the event and measure the vital sign in response to detecting the event. For example, the event configuration may define an event as a patient's pulse rate being less than a threshold, and in response to the pulse rate falling below the threshold, the patient's blood pressure is to be measured for three minutes. In this case, the patient-side RPM application 120 configures the healthcare monitoring device 136 to monitor the pulse rate of the patient 102, and in response to detecting that the pulse rate is less than the threshold, the blood pressure is measured for three minutes and the measurement result is reported to the patient-side RPM application 120. In another example, the event configuration may define an event as a patient climbing three stairs, and in response to the patient climbing three stairs, the patient's oxygenation level is to be measured for one minute. In this case, the patient-side RPM application 120 configures the healthcare monitoring device 136 to monitor the patient's 102 movement, and in response to detecting that the patient 102 climbs three stairs, the oxygenation level is measured for one minute and the measurement is reported to the patient-side RPM application 120.

[0059] If the patient-side RPM application 120 determines that the healthcare monitoring device 136 capable of detecting the event is unable to measure the vital signs to be reported in response to detecting the event, the patient-side RPM application 120 configures the first healthcare monitoring device 136 to detect the event and collect and report healthcare data indicating the event. If the first healthcare monitoring device 136 reports that the event has occurred or the monitored healthcare data indicates that the event has occurred, in response, the patient-side RPM application 120 configures the first healthcare monitoring device or the second healthcare monitoring device 136 to measure vital signs. For example, the event configuration defines the event as a patient falling, and blood pressure is to be measured for two minutes in response to the patient falling. In this case, the patient-side RPM application 120 configures the first healthcare monitoring device 136 to detect when the patient falls or collect and report healthcare data indicating the fall, and in response to the healthcare monitoring device 136 reporting that the patient has fallen or the reported healthcare data indicates that the patient has fallen, the patient-side RPM application 120 configures the second healthcare device 136 to collect the patient's blood pressure for two minutes.

[0060] If the patient-side RPM application 120 determines that a healthcare monitoring device 136 can detect a state and measure vital signs to be reported when the patient is in the state, the patient-side RPM application 120 configures the healthcare monitoring device 136 to detect the state and measure vital signs when the patient is in the state.

[0061] If the patient-side RPM application 120 determines that one healthcare monitoring device 136 cannot detect a state and simultaneously measure vital signs to be reported when the patient is in the state, the patient-side RPM application 120 configures the first healthcare monitoring device 136 to detect whether the patient has entered the state or collect and report healthcare data indicating the state. When the healthcare monitoring device 136 reports that the patient has entered the state or the monitored healthcare data indicates that the patient has entered the state, then in response, the patient-side RPM application 120 configures the first healthcare monitoring device or the second healthcare monitoring device 136 to measure vital signs when the patient is in the state. After the first healthcare monitoring device 136 reports that the patient has left the state or provides healthcare data indicating that the patient has left the state, the patient-side RPM application 120 reconfigures the first healthcare monitoring device or the second healthcare monitoring device 136 to stop measuring vital signs after a certain period (if any) included in the waiting state configuration. In some embodiments, the patient-side RPM application 120 configures the healthcare monitoring device 136 to monitor the vital signs of the patient 102, and the patient-side RPM application 120 determines that the patient 102 has entered the state based on the monitored vital signs. In some embodiments, configuring the healthcare monitoring device 136 to measure the vital signs while the patient is in the state includes configuring the healthcare monitoring device 136 to collect healthcare data of the patient 102 at a higher rate than the healthcare monitoring device 136 previously collected healthcare data of the patient 102.

[0062] For example, the state configuration may define the state as the patient is sleeping, and define the vital sign to be measured as the oxygenation level of the patient 102. If the patient-side RPM application 120 determines that the patient 102 is in the sleeping state based on the data from the first healthcare monitoring device 136, then in response, the patient-side RPM application 120 configures the first healthcare monitoring device or the second healthcare monitoring device 136 to collect the oxygenation level of the patient 102 while the patient-side RPM application 120 continues to detect that the patient 102 is in the sleeping state based on the data received by the patient-side RPM application 120 from the first healthcare monitoring device 136.

[0063] The patient-side RPM application 120 sends the healthcare data received by the healthcare monitoring device 136 to the provider-side RPM platform 168. The patient-side RPM application 120 sends the healthcare data based on the healthcare plan. In some examples, the healthcare plan indicates that some vital signs of the patient 102 are to be checked and reported only when the vital signs are out of the expected range, and the patient-side RPM application 120 compares the healthcare data with the expected range and determines whether to send the healthcare data to the provider-side RPM platform 168.

[0064] The patient-side RPM application 120 provides reminders to the patient 102 according to the healthcare plan assigned to the patient 102. In some examples, the reminders are presented to the patient 102 via the media device 134 and may be presented simultaneously with the television program or other content being presented by the plug-in device 110 via the media device 134 ( For example , presented next to or superimposed).

[0065] The patient-side RPM application 120 can receive and respond to a video call initiated by the provider-side RPM platform 168. The patient-side RPM application 120 can also initiate a video call to the provider-side RPM platform 168. The patient-side RPM application 120 outputs the video image and sound of the video call via the media device 134. Similarly, the patient-side RPM application 120 receives the video image and sound of the video call via the camera 130. The patient-side RPM application 120 sends the video and audio data to the provider-side RPM platform 168 via the network interface 116 and the network 150. The patient-side RPM application 120 receives the video and audio data via the network interface 116 and the network 150 to present to the patient 102.

[0066] The camera 130 collects images, video streams, and audio streams of the patient and supplies them to the patient-side RPM application 120. In some examples, the camera 130 includes a microphone. When the patient 102 and the healthcare provider 198 are on a video call, the camera 130 can be activated and used to supply the patient's video and audio for the video call. During the video call, the camera 130 can be used to capture images of the patient 102 and / or one or more healthcare monitoring devices 136 for reference by the healthcare provider 198.

[0067] The remote control 132 communicates with the plug-in device 110 via radio signals, infrared signals, or any other technically feasible means. The remote control 132 obtains information from the patient 102 and supplies the information to the plug-in device 110. For example, the patient 102 can use the remote control 132 to scroll through a list of options presented by the plug-in device 110 and select one of the options. The remote control 132 includes, but is not limited to, push buttons and / or other means of obtaining information from the patient 102. In some embodiments, the remote control includes a microphone that can be used to capture audio commands or inputs from the patient.

[0068] The media device may be a television (TV), a smart TV, a display, a laptop computer, a tablet computer, or any other device capable of displaying video images and outputting audio signals. The media device 134 includes, but is not limited to, a video display and at least one speaker. The media device receives video and audio signals from the plug-in device 110 and converts these signals into visual and audible content.

[0069] The provider-side RPM platform 168 executes on the server 160. The provider-side RPM platform 168 enables the healthcare provider 198 to create, review, update, and / or delete the healthcare plan assigned to the patient 102. The provider-side RPM platform 168 presents one or more graphical user interfaces (GUIs), such as one or more create, review, update, and delete (CRUD) GUIs, via which the healthcare provider 198 creates, reviews, updates, and / or deletes the healthcare plan assigned to the patient 102. The healthcare provider 198 can access the GUIs via the network 150 and the healthcare provider device 180. The provider-side RPM platform 168 retrieves the healthcare plan assigned to the patient 102 (if any) from the data store 172. In some examples, the provider-side RPM platform 168 also retrieves the current and historical healthcare data of the patient 102 from the data store 172 for presentation to the healthcare provider 198 so that the healthcare provider can reference the healthcare data of the patient 102 when updating the healthcare plan assigned to the patient 102.

[0070] In some examples, the provider-side RPM platform 168 obtains one or more preconfigured healthcare plans intended for people with a particular disease or condition from the healthcare plan library 174 and presents the one or more preconfigured healthcare plans to the healthcare provider 198. The healthcare provider 198 can then incorporate or customize the one or more preconfigured healthcare plans to create a healthcare plan assigned to the patient 102. The provider-side RPM platform 168 selects the one or more preconfigured healthcare plans from the healthcare plan library 174 based on input from the healthcare provider 198. When the healthcare provider 198 is satisfied with the new or updated healthcare plan to be assigned to the patient 102, the provider-side RPM platform 168 saves the new or updated healthcare plan assigned to the patient 102 to the data store 172 and sends the healthcare plan to the patient-side RPM application 120.

[0071] Figure 2An example GUI 200 for configuring a healthcare plan according to various embodiments of the present disclosure is shown. The provider-side RPM platform 168 presents the GUI 200 to allow a healthcare provider 198 to specify one or more healthcare data monitoring configurations for a healthcare plan. Each row 210, 220, or 230 in the GUI 200 shows the vital signs of the patient 102 to be monitored according to the healthcare plan. The entry at 212 shows that blood pressure is selected for monitoring in the displayed healthcare plan. The entry at 214 indicates the frequency with which blood pressure is to be monitored. As shown by the entry at 214, blood pressure is to be monitored daily. Although not shown, other monitoring intervals are possible, such as hourly, weekly, etc. In addition, the frequency field may indicate that the vital signs of the row are part of the criteria for an event configuration or a state configuration. When the healthcare provider 198 selects a vital sign as part of the criteria for an event configuration, the GUI 200 presents additional fields to enable the healthcare provider 198 to configure the vital signs to be monitored or the actions to be taken in response to detecting the occurrence of an event or detecting healthcare data indicating the event. When the healthcare provider 198 selects vital signs as part of the criteria for the state configuration, the GUI 200 presents additional fields to enable the healthcare provider 198 to configure the vital signs to be monitored or the actions to be taken in response to detecting a physiological state or detecting healthcare data indicating that the patient has entered the physiological state. The entry at 216 shows that blood pressure is to be monitored between 6 a.m. and 10 p.m. The entry at 222 shows that blood glucose (R) is selected in the healthcare plan for monitoring. The entry at 224 indicates that blood glucose (R) is to be monitored every day, and the entry at 226 shows that blood glucose (R) is to be monitored between 6 a.m. and 10 a.m. and between 2 p.m. and 6 p.m. The healthcare provider 198 uses a drop-down list 232 to select the additional vital signs to be monitored in the displayed healthcare plan. Once the healthcare provider 198 selects additional vital signs, the healthcare provider 198 will select the frequency and specific time for collecting the additional vital signs.

[0072] Figure 3 An example of a GUI 300 for configuring a healthcare plan according to various embodiments of the present disclosure is shown. The provider-side RPM platform 168 presents the GUI 300 via the provider device 180 to allow a healthcare provider 198 to specify one or more alarm configurations for a healthcare plan. Each row 310, 330, 350 in the GUI 300 shows an alarm configuration included in the displayed healthcare plan.

[0073] The entry at 312 shows that systolic blood pressure is selected as the basis for the first alarm of the displayed health care plan. The entry at 314 shows which reading or reading function the first alarm is based on. As shown by the entry at 314, the current reading of systolic blood pressure is the basis for the first alarm. Although not shown, other readings or reading functions are possible, such as the maximum reading in the past hour, the average reading in the past two hours, or the difference from the previous reading. The entry at 316 shows the relationship of the vital signs to the criteria of the vital signs that trigger the first alarm (shown at 318 and 320). As shown by the entry at 316, the first alarm is triggered when the current systolic blood pressure is greater than or equal to the criteria shown at 318 and 320. The entry at 318 shows the numerical value of the vital sign criteria on which the first alarm is based, and the entry at 320 shows the measurement unit of the criteria. As shown by the entries at 318 and 320, the criteria for the first alarm is that the current systolic blood pressure is 120 mmHg. The entry at 322 shows the relative severity of the first alarm ( For example , severe, high, or low). The severity level of an alarm determines how an RPM application (such as RPM application 120) responds to the alarm. For example, an alarm with a severity level of "severe" indicates that the RPM application should provide an alert to the patient and contact emergency medical services; an alarm with a severity level of "high" indicates that the RPM application should provide an alert to the patient and call or dial a healthcare provider; and an alarm with a severity level of "low" indicates that the RPM application should alert the patient and send a notification to the healthcare provider ( For example , email, or text message). Each entry at 312, 314, 316, 318, 320, and 322 may be selected from a corresponding drop-down list.

[0074] The entry at 332 shows that systolic blood pressure is selected as the basis for the second alarm of the displayed health care plan. The entry at 334 shows which reading or reading function the second alarm is based on. As shown via the entry at 334, the current reading of systolic blood pressure is the basis for the second alarm. The entry at 336 shows the relationship of the vital signs to the criteria (shown at 338 and 340) for the vital signs that trigger the second alarm. As shown via the entry at 336, the second alarm is triggered when the current systolic blood pressure is less than or equal to the criteria shown at 338 and 340. The entry at 338 shows the numerical value of the vital sign criteria on which the second alarm is based, and the entry at 340 shows the measurement unit of the criteria. As shown via the entries at 338 and 340, the criteria for the second alarm is that the current systolic blood pressure is 80 mmHg. The entry at 342 shows the relative severity of the second alarm ( For example, severe, high or low). As shown via the entry at 322, the relative severity of the second alert of the displayed healthcare plan is high. Each entry at 332, 334, 336, 338, 340 and 342 can be selected from a corresponding drop-down list.

[0075] The entry at 352 shows that systolic blood pressure is selected as the basis for the third alarm of the displayed health care plan. The entry at 354 shows which reading or reading function the third alarm is based on. As shown via the entry at 354, the current reading of systolic blood pressure is the basis for the third alarm. The entry at 356 shows the relationship of the vital signs to the criteria (shown at 358 and 360) for the vital signs that trigger the third alarm. As shown via the entry at 356, the third alarm is triggered when the current systolic blood pressure is greater than or equal to the criteria shown at 358 and 360. The entry at 358 shows the numerical value of the vital sign criteria on which the third alarm is based, and the entry at 360 shows the measurement unit of the criteria. As shown via the entries at 358 and 360, the criteria for the third alarm is that the current systolic blood pressure is 80 mmHg. The entry at 362 shows the relative severity of the third alarm ( For example , severe, high or low). As shown via the entry at 322, the relative severity of the third alert of the displayed healthcare plan is high. Each entry at 352, 354, 356, 358, 360 and 362 can be selected from a corresponding drop-down list.

[0076] 300. The button 370 enables the healthcare provider 198 to add a new alarm to the displayed healthcare plan. When the healthcare provider 198 selects the button 494, the provider-side RPM platform 168 adds a row to the GUI 300. The added row includes a set of drop-down lists for the healthcare provider 198 to use to select the vital sign, reading or reading function, relationship to standard, standard, unit of measurement, and severity of the new alarm. The cancel button 380 enables the healthcare provider 198 to exit the GUI without saving any changes to the alarms of the displayed healthcare plan. The save button 382 enables the healthcare provider 198 to save changes to the displayed healthcare plan.

[0077] Reference again Figure 1, the provider-side RPM platform 168 sends the new or updated healthcare plan assigned to the patient to the patient-side RPM application 120 via the network 150 and the network interface 164. The provider-side RPM platform 168 receives a confirmation from the patient-side RPM application 120 that the new or updated healthcare plan was received from the patient-side RPM application 120. If the provider-side RPM platform 168 does not receive a confirmation from the patient-side RPM application 120, the provider-side RPM platform 168 may notify the healthcare provider 198 that the patient-side RPM application 120 did not receive the new or updated healthcare plan. Optionally, the provider-side RPM platform 168 may send the healthcare plan assigned to the patient 102 to the patient-side RPM application 120 at regular intervals as a precaution against unauthorized changes at the plug-in device 110.

[0078] The provider-side RPM platform 168 receives healthcare data about the patient 102 from the patient-side RPM application 120. The provider-side RPM platform 168 receives the healthcare data via the network 150 and the network interface 164. The provider-side RPM platform 168 saves the received healthcare data to the data storage 172.

[0079] The provider-side RPM platform 168 analyzes the healthcare data about the patient 102 and detects whether any alerts should be triggered regarding the healthcare data about the patient 102. If the provider-side RPM platform 168 detects that an alert should be triggered regarding the healthcare data about the patient 102, the provider-side RPM platform 168 sends the triggered alert to the healthcare provider 198 via a text message, email, automated phone call, or any technically feasible means.

[0080] The provider-side RPM platform 168 can initiate a video call to the patient 102 based on input from the healthcare provider 198. The provider-side RPM platform 168 can also receive the video call from the patient-side RPM application 120. The provider-side RPM platform 168 transmits a request to start the video call to the patient-side RPM application 120 via the network interface 164 and the network 150. The provider-side RPM platform 168 accepts video and audio data from the provider device 180.

[0081] Figure 4 A flowchart showing method steps for remote health monitoring according to various embodiments of the present disclosure is shown. Figure 1 The method steps are described with reference to a system of FIG. 400 , but any system configured to perform the method steps in any order falls within the scope of the various embodiments. In some embodiments, the method 400 is performed by the patient-side RPM application 120 .

[0082] Method 400 begins at step 402, where a healthcare plan for a patient is received from a remote source. The healthcare plan includes one or more content provisioning, monitoring configurations, event configurations, status configurations, reminder configurations, and / or alarm configurations, such as those described above with respect to Figure 1 In some examples, the healthcare plan is received by an RPM application executing on a plug-in device, such as a patient-side RPM application 120 executing on the plug-in device 110. In some examples, the RPM application confirms receipt of the healthcare plan. The RPM application parses the healthcare plan to determine whether the healthcare plan includes content provision; configuration of the healthcare monitoring device based on the monitoring configuration, event configuration, and state configuration; reminder configuration and / or alarm configuration.

[0083] In step 404, one or more reminders are configured based on the healthcare plan. The one or more reminders are configured by the RPM application. In some examples, each of the one or more reminders is a reminder to take medication or perform some other activity at a specific time.

[0084] In step 406, one or more healthcare monitoring devices are configured to collect healthcare data about the patient. The one or more healthcare monitoring devices are configured by an RPM application (such as the patient-side RPM application 120). In some examples, the RPM application uses one or more APIs provided by the healthcare monitoring device to configure each of the one or more healthcare monitoring devices. In some examples, the one or more healthcare monitoring devices are configured according to the monitoring configuration in the healthcare plan (such as collecting healthcare data of one or more vital signs at a specific frequency, collection time, etc.). Examples of healthcare data that can be collected include pulse rate, blood pressure, blood oxygen, EKG, EEG, body temperature, REM, physical activity ( For example , exercise, walking, climbing stairs), etc. In some examples, the healthcare monitoring device is configured to detect events or collect and report healthcare data indicating events according to the event configuration in the healthcare plan. Examples of events include a patient's vital signs being above or below a threshold, a patient falling, a patient starting or stopping an activity (e.g., exercising, climbing stairs, eating, sleeping, walking, running), etc. In some examples, the healthcare monitoring device is configured to detect states and / or collect and report healthcare data indicating physiological states according to the state configuration in the healthcare plan. Examples of physiological states include sleeping, being in a rapid eye movement (REM) state during sleep, exercising, walking, climbing stairs, giving birth, etc. In some examples, the RPM application executed on the plug-in device configures the healthcare monitoring device via a network interface.

[0085] In step 408, the content is provided to the patient. The RPM application provides the content via a separate media device, such as media device 134. In some examples, providing the content includes displaying a user interface with a list of available content that the patient can select. In some examples, the content is identified by a link or URL, and the link or URL is used by the RPM application to retrieve the content so as to present the retrieved content to the patient.

[0086] In step 410, one or more reminders are displayed to the patient. The RPM application displays the one or more reminders via a separate media device, such as media device 134. In some examples, each of the one or more reminders is displayed as a pop-up window or with other content on a separate media device when the current time matches the time for the reminder or when other criteria for displaying the reminder are met. In some examples, each of the one or more reminders also includes an audio component, such as a tone, a unique sound, a verbal component, etc.

[0087] In step 412, healthcare data about a patient is received. The RPM application receives healthcare data about a patient, such as patient 102, from a healthcare monitoring device, such as healthcare monitoring device 136. In some examples, the healthcare data is received when the healthcare monitoring device detects an event or state and begins collecting healthcare data in response. In some examples, the healthcare data is received when the healthcare monitoring device is configured by the RPM application to begin collecting healthcare data in response to the RPM application detecting an event or state. In some examples, the RPM application analyzes the healthcare data from the first healthcare monitoring device to see if the healthcare data indicates a particular event in an event configuration or an event in an event configuration for which the first healthcare monitoring device is not configured to automatically collect additional healthcare data associated with the event configuration or the state configuration. When the first healthcare monitoring device is not configured to automatically collect additional healthcare data, the RPM application configures the first healthcare monitoring device or the second healthcare monitoring device to collect the additional healthcare data. In some examples, the RPM application uses an API provided by the healthcare monitoring device to request healthcare data from the healthcare monitoring device at periodic intervals, in response to various alerts, in response to notifications received from the healthcare monitoring device, and / or in response to notifications received from another healthcare monitoring device.

[0088] In step 414, one or more alarms are processed. In some examples, the RPM application (such as the patient-side RPM application 120) analyzes the healthcare data received during step 412 to determine whether to trigger one or more alarms. The RPM application compares the healthcare data to the conditions identified in each alarm configuration included in the healthcare plan. When the healthcare data is consistent with the conditions specified in the particular alarm configuration, the RPM application generates an alarm consistent with the severity level specified in the particular alarm configuration. Depending on the severity level, the alarm includes one or more of the following: providing a notification to the patient, sending a notification to the RPM platform or healthcare provider, calling 911, etc.

[0089] In step 416, the video call is processed. The RPM application receives a video call request from the provider-side RPM platform and / or from the patient via input (such as by the patient selecting a video call option from the GUI using a remote control). The RPM application communicates with the provider-side RPM platform 168 to establish the video call and activates the camera 130 to capture video and / or audio data from the patient 102. The RPM application sends video and audio data from the camera 130 to the provider-side RPM platform 168, receives video and audio data from the provider-side RPM platform 168, and causes the media device 134 to output the video and audio data received from the provider-side RPM platform 168.

[0090] Steps 408-416 are then repeated as needed to provide content to the patient, display one or more additional reminders, receive additional healthcare data, process one or more additional alarms, and / or support additional video calls. In some embodiments, when a new or updated healthcare plan is received, method 400 instead returns to step 402.

[0091] Figure 5 A flowchart showing method steps for remote health monitoring according to various embodiments of the present disclosure is shown. Figure 1 The method steps are described with reference to a system, but any system configured to perform the method steps in any order falls within the scope of the various embodiments. In some embodiments, the method 500 is performed by the provider-side platform 168.

[0092] The method 500 begins at step 502, where a patient is selected. The patient is selected using an RPM platform, such as the provider-side RPM platform 168 executing on the server 160. In some examples, a healthcare provider, such as the healthcare provider 198, selects the patient by providing input to the RPM platform. For example, the healthcare provider may select the patient from a list of patients displayed by the RPM platform.

[0093] In step 504, a healthcare plan assigned to the patient is created or updated. The healthcare plan includes one or more content provisioning, monitoring configurations, event configurations, status configurations, reminder configurations, and / or alarm configurations, such as those described above with respect to Figure 1 In some examples, a healthcare provider uses the RPM platform to create or update a healthcare plan assigned to a patient, such as patient 102. In some embodiments, creating or updating a healthcare plan includes adding or updating one or more content provisioning, monitoring configurations, event configurations, status configurations, reminder configurations, and / or alarm configurations to a predefined healthcare plan and / or a previously created healthcare plan for the patient. In some examples, a predefined healthcare plan or a previously created healthcare plan is retrieved from a data store ( For example , data storage location 172) and / or health care plan repository ( For example , healthcare plan library 174). In some examples, healthcare providers use one or more GUIs (such as Figure 2 and Figure 3 GUI) to create and update the health care plan. In some examples, the health care plan is stored in a data store (such as data store 172).

[0094] In step 506, the health care plan is sent to the RPM application. The RPM platform sends the health care plan to the RPM application, such as the patient-side RPM application 120. In some examples, the health care plan is sent to the RPM application in response to instructions from the health care provider (such as the health care provider 198) when the health care provider has completed creating or updating the health care plan. In some examples, the health care plan is sent to the RPM application via a network interface (such as the network interface 164) and a network (such as the network 150). In some examples, the RPM receives a confirmation from the RPM application that the health care plan has been received.

[0095] In step 508, healthcare data about the patient is received. The RPM platform receives the healthcare data from the RPM application and / or directly from one or more healthcare monitoring devices. In some examples, the healthcare data is received in response to the RPM platform requesting the healthcare data and / or at periodic intervals.

[0096] In step 510 , the healthcare data is saved. The healthcare data is saved by the RPM platform to a data store, such as the data store 172 .

[0097] In step 512, the healthcare data is analyzed. The RPM platform analyzes the healthcare data during step 512 to determine whether to trigger one or more alarms. The RPM platform compares the healthcare data to the conditions identified in each alarm configuration included in the healthcare plan. When the healthcare data is consistent with the conditions specified in the particular alarm configuration, the RPM platform generates an alarm consistent with the severity level specified in the particular alarm configuration. Depending on the severity level, the alarm includes sending a notification to a healthcare provider, calling 911, etc. In some embodiments, the alarm is sent to the healthcare provider using one or more of a text message, an email, a pager, a phone call, etc.

[0098] In step 514, the video call is processed. The RPM platform receives a video call request from the patient-side RPM application, and / or via input from the healthcare provider (such as by the healthcare provider selecting a video call option from the GUI using a provider device). The RPM platform communicates with the patient-side RPM application to establish the video call and activates the provider device to capture video and / or audio data from the healthcare provider. The RPM platform sends video and audio data from the provider device to the patient-side RPM application, receives video and audio data from the patient-side RPM application, and sends video and audio data received from the patient-side RPM application to the provider device.

[0099] Steps 508-514 are then repeated as needed to receive additional healthcare data, save additional healthcare data, analyze healthcare data, and / or support additional video calls. In some embodiments, when a new patient is selected, method 500 instead returns to step 502.

[0100] Figure 6 A flowchart showing method steps for remote health monitoring according to various embodiments of the present disclosure is shown. Figure 1 The method steps are described with reference to a system, but any system configured to perform the method steps in any order falls within the scope of the various embodiments. In some embodiments, the method 600 is consistent with the operations performed by each healthcare monitoring device.

[0101] The method 600 begins at step 602, where a configuration is received from a remote source. The configuration is received by a healthcare monitoring device, such as any of the healthcare monitoring devices 136. In some examples, the configuration is received from an RPM application, such as the patient-side RPM application 120, and / or from an RPM platform, such as the provider-side RPM platform 168. In some examples, the configuration is received using one or more APIs provided by the healthcare monitoring device. In some examples, the configuration is a monitoring configuration in a healthcare plan, such as collecting healthcare data of one or more vital signs at a specific frequency, collection time, etc. Examples of healthcare data that may be configured to be monitored include pulse rate, blood pressure, blood oxygen, EKG, EEG, body temperature, REM, physical activity ( For example , exercise, walking, climbing stairs), etc. In some examples, the configuration configures the healthcare monitoring device to detect events or collect and report healthcare data indicating events according to the event configuration in the healthcare plan. Examples of events include a patient's vital signs being above or below a threshold, a patient falling, a patient starting or stopping an activity (e.g., exercising, climbing stairs, eating, sleeping, walking, running), etc. In some examples, the configuration configures the healthcare monitoring device to detect states and / or collect and report healthcare data indicating physiological states according to the state configuration in the healthcare plan. Examples of physiological states include sleeping, being in a rapid eye movement (REM) state during sleep, exercising, walking, climbing stairs, giving birth, etc. In some examples, the configuration is received via a network interface.

[0102] In step 604, healthcare data is collected from one or more sensors. Healthcare data is collected by a processing unit of the healthcare monitoring device according to the configuration received during step 602. In some embodiments, healthcare data is collected at specific times indicated in the configuration. In some embodiments, healthcare data is collected in response to detecting an event according to an event configuration in the configuration. In some embodiments, healthcare data is collected in response to a patient being in a certain state according to a state configuration in the configuration and while the patient is in the state.

[0103] In step 606, the healthcare data is stored. The healthcare monitoring device stores the healthcare data in a memory and / or other storage device.

[0104] In step 608, the healthcare data is sent to a remote source. The healthcare monitoring device is connected to the remote source via a network, such as an optical network, Ethernet LAN, Wi-Fi LAN, Bluetooth TMThe healthcare data is sent to the remote source by connecting to the remote source, etc. When the healthcare data is collected, the healthcare monitoring device sends the healthcare data to the remote source at periodic intervals, when an event or state is detected, and / or in response to a request from the remote source.

[0105] Steps 604-608 are then repeated as needed to collect additional healthcare data, store additional healthcare data, and / or send additional healthcare data to a remote source. In some embodiments, when a new configuration is received, method 600 instead returns to step 602.

[0106] In summary, a remote patient monitoring (RPM) application on a plug-in device receives a healthcare plan assigned to a patient from a remote source. The patient-side RPM application enables a separate media device ( For example , television) presents the patient's healthcare information. The patient-side RPM application receives healthcare data about the patient from one or more healthcare monitoring devices and sends the healthcare data to a remote source. The healthcare plan includes information such as content to be provided to the patient, one or more reminders, one or more alarms, configuration of one or more healthcare monitoring devices for collecting healthcare data, events to be monitored, conditions to be detected, and healthcare data to be collected in response to one or more events and / or one or more conditions.

[0107] At least one technical advantage of the disclosed technology over the prior art is that with the disclosed technology, the possibility of users using remote health monitoring applications is increased, which makes the remote health monitoring applications and associated remote health monitoring platforms more effective and reliable. Another advantage is that patient health data is collected at a time relevant to the patient's health status, while reducing power consumption, reducing memory usage and reducing bandwidth. Another advantage is that the computing resources used to analyze the collected data are reduced. These technical advantages provide one or more technical improvements over prior art methods.

[0108] 1. In various embodiments, a computer-implemented method for remote patient monitoring using a plug-in device includes: receiving a healthcare plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; and sending the healthcare data to the remote source.

[0109] 2. The method of clause 1, further comprising configuring the one or more healthcare monitoring devices based on the healthcare plan.

[0110] 3. The method of clause 2, wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to capture a first vital sign at a first time.

[0111] 4. A method as described in any of clauses 1 to 3, wherein configuring the one or more healthcare monitoring devices includes configuring a first healthcare monitoring device to detect a physiological state of the patient and measure one or more vital signs of the patient in response to detecting the physiological state.

[0112] 5. A method as described in any of clauses 1 to 4, further comprising: analyzing the healthcare data to determine that the patient is in a physiological state; and configuring a first healthcare monitoring device to capture one or more vital signs of the patient in response to determining that the patient is in the physiological state.

[0113] 6. A method as described in any of clauses 1 to 5, wherein configuring the first healthcare monitoring device to capture the one or more vital signs includes configuring the first healthcare monitoring device to capture the one or more vital signs at a first rate, the first rate being higher than a second rate used to capture the one or more vital signs before determining that the patient is in the physiological state.

[0114] 7. A method as described in any of clauses 1 to 6, further comprising: receiving additional healthcare data about the patient from the one or more healthcare monitoring devices; determining that the patient is no longer in the physiological state based on the additional healthcare data; and reconfiguring the first healthcare monitoring device to stop capturing the one or more vital signs of the patient in response to determining that the patient is no longer in the physiological state.

[0115] 8. A method as described in any of clauses 1 to 7, wherein configuring the one or more healthcare monitoring devices includes configuring a first healthcare monitoring device to detect an event associated with the patient and measure one or more vital signs of the patient in response to detecting the event.

[0116] 9. A method as described in any of clauses 1 to 8, further comprising: detecting the occurrence of an event associated with the patient based on the healthcare data; and configuring a first healthcare monitoring device to capture one or more vital signs of the patient in response to detecting the event.

[0117] 10. The method of any one of clauses 1 to 9, further comprising: determining, based on the healthcare data, that one or more criteria for an alert are satisfied; and generating the alert in response to determining that the one or more criteria for the alert are satisfied.

[0118] 11. The method of any one of clauses 1 to 10, further comprising using the media device to provide reminders to the patient based on the healthcare plan.

[0119] 12. In various embodiments, one or more non-transitory computer-readable media store instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: receiving a healthcare plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; and sending the healthcare data to the remote source.

[0120] 13. One or more non-transitory computer-readable media as described in claim 12, wherein the step further includes configuring the one or more healthcare monitoring devices based on the healthcare plan, wherein configuring the one or more healthcare monitoring devices includes one or more of the following: configuring a first healthcare monitoring device to capture a first vital sign at a first time; configuring the first healthcare monitoring device to measure one or more vital signs of the patient in response to detecting a physiological state of the patient; or configuring the first healthcare monitoring device to measure one or more vital signs of the patient in response to detecting an event associated with the patient.

[0121] 14. The one or more non-transitory computer-readable media of clause 12 or clause 13, wherein the steps further comprise using the media device to provide reminders to the patient based on the healthcare plan.

[0122] 15. The one or more non-transitory computer-readable media of any one of clauses 12 to 14, wherein the reminder is a reminder to take medication or perform an action.

[0123] 16. The one or more non-transitory computer-readable media of any of clauses 12 to 15, wherein providing the reminder comprises pausing media content being presented by the media device.

[0124] 17. One or more non-transitory computer-readable media as described in any of clauses 12 to 16, wherein the steps further include: receiving a confirmation of the reminder from a remote control associated with the plug-in device; and resuming presentation of the content in response to receiving the confirmation.

[0125] 18. The one or more non-transitory computer-readable media of any one of clauses 12 to 17, wherein the steps further comprise facilitating a video call with a healthcare provider.

[0126] 19. The one or more non-transitory computer-readable media of any one of clauses 12 to 18, wherein the remote source is a remote patient monitoring platform.

[0127] 20. In various embodiments, a plug-in device includes: a memory storing instructions; and a processing system coupled to the memory, the processing system executing the instructions to perform steps, the steps including: receiving a healthcare plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; and sending the healthcare data to the remote source.

[0128] Any and all combinations of any of the claim elements of any of the claims and / or any of the elements described in this application, in any form, are within the intended scope of the invention and protection.

[0129] The description of the various embodiments has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments.

[0130] Aspects of the embodiments of the present invention may be embodied as systems, methods, or computer program products. Therefore, aspects of the present disclosure may take the form of a complete hardware implementation, a complete software implementation (including firmware, resident software, microcode, etc.), or an implementation that combines software and hardware aspects that are generally referred to as "modules", "systems" or "computers" in this article. In addition, any hardware and / or software technology, process, function, component, engine, module, or system described in the present disclosure may be implemented as a circuit or circuit group. In addition, aspects of the present disclosure may take the form of a computer program product, which is embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0131] Any combination of one or more computer-readable media may be utilized. A computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, device, or apparatus, or any suitable combination of the foregoing. More specific examples (non-exhaustive list) of computer-readable storage media will include the following: an electrical connection with one or more wires, a portable computer floppy disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer-readable storage medium may be any tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, device, or apparatus.

[0132] Aspects of the present disclosure are described above with reference to the flowchart illustration and / or block diagram of the method, device (system) and computer program product according to the embodiments of the present disclosure. It should be understood that each frame in the flowchart illustration and / or block diagram and the frame combination of the flowchart illustration and / or block diagram can be realized by computer program instructions. These computer program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine. Instructions enable the function / action specified in one or more frames of the flowchart and / or block diagram to be realized when executed via the processor of a computer or other programmable data processing device. Such processors can be, but are not limited to, general-purpose processors, special-purpose processors, special-purpose processors or field programmable gate arrays.

[0133] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality and operation of possible implementations of the systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram may represent a module, code segment or part of a code, which includes one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions mentioned in the box may not appear in the order mentioned in the accompanying drawings. For example, in practice, depending on the functionality involved, the two boxes shown in succession may be executed substantially simultaneously, or the boxes may sometimes be executed in the opposite order. It should also be noted that each box illustrated in the block diagram and / or flowchart and the box combination in the block diagram and / or flowchart may be implemented by a special-purpose hardware-based system that performs a specified function or action, or by a combination of special-purpose hardware and computer instructions.

[0134] While the foregoing is directed to embodiments of the present disclosure, other and further embodiments of the present disclosure may be devised without departing from the basic scope of the present disclosure, and the scope of the present disclosure is determined by the claims.

Claims

1. A computer-implemented method for remote patient monitoring using a plug-in device, comprising: receiving a health care plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; as well as The healthcare data is transmitted to the remote source. 2 . The method of claim 1 , further comprising configuring the one or more healthcare monitoring devices based on the healthcare plan. 3 . The method of claim 2 , wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to capture a first vital sign at a first time.

4. The method of claim 1 , wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to: detecting a physiological state of the patient; and One or more vital signs of the patient are measured in response to detecting the physiological state.

5. The method of claim 1, further comprising: analyzing the health care data to determine that the patient is in a physiological state; as well as A first healthcare monitoring device is configured to capture one or more vital signs of the patient in response to determining that the patient is in the physiological state.

6. The method of claim 5, wherein configuring the first healthcare monitoring device to capture the one or more vital signs comprises configuring the first healthcare monitoring device to capture the one or more vital signs at a first rate that is higher than a second rate used to capture the one or more vital signs prior to determining that the patient is in the physiological state.

7. The method of claim 5, further comprising: receiving additional healthcare data about the patient from the one or more healthcare monitoring devices; determining, based on the additional healthcare data, that the patient is no longer in the physiological state; as well as Responsive to determining that the patient is no longer in the physiological state, the first healthcare monitoring device is reconfigured to cease capturing the one or more vital signs of the patient.

8. The method of claim 1 , wherein configuring the one or more healthcare monitoring devices comprises configuring a first healthcare monitoring device to: detecting an event associated with the patient; and One or more vital signs of the patient are measured in response to detecting the event.

9. The method of claim 1, further comprising: detecting an occurrence of an event associated with the patient based on the healthcare data; as well as A first healthcare monitoring device is configured to capture one or more vital signs of the patient in response to detecting the event.

10. The method of claim 1, further comprising: determining, based on the healthcare data, that one or more criteria for an alert are satisfied; as well as The alert is generated in response to determining that the one or more criteria for the alert are met.

11. The method of claim 1, further comprising using the media device to provide reminders to the patient based on the healthcare plan.

12. One or more non-transitory computer-readable media storing instructions that, when executed by one or more processors, cause the one or more processors to perform the following steps: receiving a health care plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; as well as The healthcare data is transmitted to the remote source.

13. The one or more non-transitory computer-readable media of claim 12, wherein the steps further comprise configuring the one or more healthcare monitoring devices based on the healthcare plan, wherein configuring the one or more healthcare monitoring devices comprises one or more of: configuring a first healthcare monitoring device to capture a first vital sign at a first time; configuring the first healthcare monitoring device to measure one or more vital signs of the patient in response to detecting a physiological state of the patient; or The first healthcare monitoring device is configured to measure one or more vital signs of the patient in response to detecting an event associated with the patient.

14. The one or more non-transitory computer-readable media of claim 12, wherein the steps further comprise using the media device to provide reminders to the patient based on the healthcare plan.

15. The one or more non-transitory computer-readable media of claim 14, wherein the reminder is a reminder to take medication or perform an action.

16. The one or more non-transitory computer-readable media of claim 14, wherein providing the reminder comprises pausing media content being presented by the media device.

17. The one or more non-transitory computer readable media of claim 14, wherein the steps further comprise: receiving a confirmation of the reminder from a remote control associated with the plug-in device; as well as Resume presenting the content in response to receiving the confirmation.

18. The one or more non-transitory computer-readable media of claim 12, wherein the steps further comprise facilitating a video call with a healthcare provider.

19. The one or more non-transitory computer-readable media of claim 12, wherein the remote source is a remote patient monitoring platform.

20. A plug-in device, comprising: a memory storing instructions; as well as a processing system coupled to the memory, the processing system executing the instructions to perform steps comprising: receiving a health care plan assigned to a patient from a remote source; causing a separate media device to present healthcare information of the patient based on the healthcare plan; receiving healthcare data about the patient from one or more healthcare monitoring devices based on the healthcare plan; and The healthcare data is transmitted to the remote source.

Images