FLOW BASED DYNAMIC CONNECTIVITY SYSTEM

Abstract

A Dynamic Connectivity System (DCS) comprising a patient module configured for communication with an in-vivo device and with at least one additional device; the DCS further comprises a gateway device configured for providing an access point for the patient module for accessing a network; the access point is configured for termination after an idle period of predetermined idle time, and the patient module is configured for uploading data to the network via the mobile device during a non-idle period of the gateway device; the patient module is also configured for sending, during the idle period, a pinging signal to the mobile device different from the data, the pinging signal having a period time shorter than the predetermined idle time, thereby interrupting the idle period and preventing termination of the access point.

Claims

1. A system comprising: an in-vivo device; and a patient module comprising a wearable device, the patient module configured to: receive data from the in-vivo device, operate in a client mode, in which the patient module transfers the data to a gateway module, and upon request from a healthcare professional (HCP) module, dynamically switch from the client mode to an access point (AP) mode, in which the patient module authorizes access to the data by the HCP module, wherein the gateway module comprises a mobile device and is configured to receive the data from the patient module while the patient module operates in the client mode and to upload the data to a cloud server, and wherein the HCP module is configured to connect with the patient module while the patient module operates in the AP mode and to access the data in the patient module.

2-6. (canceled)

7. A system according to claim 1, wherein the wearable device is an adhesive patch.

8. A system according to claim 7, wherein the adhesive patch comprises communication components configured to receive the data from the in-vivo device and to transfer the data to the gateway module.

9. A system according to claim 1, wherein the gateway module is further configured to provide the patient module with access to the Internet.

10. (canceled)

11. (canceled)

12. A system according to claim 1, wherein the gateway module provides an access point while the patient module operates in the client mode.

13. A system according to claim 1, wherein communication between the patient module and the gateway module is performed using one or more communication channels.

14. A system according to claim 13, wherein the one or more communication channels comprise a WiFi channel and a first Bluetooth Low Energy (BLE) channel.

15. (canceled)

16. (canceled)

17. A system according to claim 14, wherein the WiFi channel is used for data transfer and the first BLE channel is used for signaling and control.

18. A system according to claim 12, wherein the access point of the gateway module is configured to terminate after an idle period of a predetermined idle time duration, and wherein the patient module is further configured to send, during the idle period, a pinging signal to the gateway module, the pinging signal sent at a time interval shorter than the predetermined idle time duration and operating to prevent the access point of the gateway module from terminating.

19. A system according to claim 18, wherein the patient module is configured to transfer the data to the gateway module during predetermined Data Upload (DU) time intervals.

20. A system according to claim 19, wherein the predetermined DU time intervals are longer than the predetermined idle time duration.

21. (canceled)

22. A system according to claim 1, wherein the HCP module comprises a display device.

23. A system according to claim 22, wherein the display device is configured to display at least one of: the data or information based one the data.

24. A system according to claim 22, wherein the display device is configured to communicate directly with the patient module while the patient module operates in the AP mode.

25. (canceled)

26. A system according to claim 14, wherein the patient module advertises its presence for discovery by the HCP module via a second BLE channel different from the first BLE channel.

27. A system according to claim 1, wherein the patient module is further configured to switch between the client mode and the AP mode, wherein the patient module is configured to prioritize communications with the HCP module over communications with the gateway module.

28. A system according to claim 1, wherein the patient module is further configured to switch between the client mode and the AP mode, wherein the patient module is configured to prioritize maintaining a connection with the gateway module over communications with the HCP module.

29. A system according to claim 18, wherein in the AP mode, the patient module is further configured to, periodically: switch from the AP mode to the client mode, send the pinging signal to the gateway module, and revert to operating in the AP mode.

30. A system according to claim 1, wherein the HCP module is further configured to communicate with the cloud server and download the data previously uploaded by the gateway module.

31. A system according to claim 30, wherein, while said HCP module is downloading the data from the cloud server: the patient module is configured to transfer the data to the gateway module continuously without buffering, and the gateway module is configured to upload the data to the cloud sever continuously without buffering.

32-35. (canceled)

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to better understand the subject matter that is disclosed herein and to exemplify how it may be carried out in practice, embodiments will now be described, by way of non-limiting example only, with reference to the accompanying drawings, in which:

[0045] FIG. 1 is a schematic illustration of a comprehensive system, comprising the DCS of the present application;

[0046] FIG. 2A is a schematic representation of the DCS of the present application when connecting a medical kit, a gateway module and the cloud; and

[0047] FIG. 2B is a schematic representation of the DCS of the present application when connecting a medical kit, a gateway module and an HCP module.

[0048] It will be appreciated that for simplicity and clarity of illustration, elements shown in the figures have not necessarily been drawn accurately or to scale. For example, the dimensions of some of the elements may be exaggerated relative to other elements for clarity, or several physical components may be included in one functional block or element. Further, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements.

DETAILED DESCRIPTION OF EMBODIMENTS

[0049] Attention is first drawn to FIG. 1, in which a comprehensive system is shown, generally designated 1 and comprising a medical kit module 10, a gateway module 20, an HCP module 30 and the cloud 40. The Dynamic Connectivity System (DCS) of the present application is established between the medical kit 10 and the gateway module 20, and between the medical kit 10 and the HCP module 30.

[0050] In the following example, the comprehensive system is shown as part of a capsule endoscopy procedure, wherein the medical kit 10 comprises a swallowable endoscopy capsule 50 constituting the in-vivo device and an adhesive patch 60 constituting a patient module, configured for communication therebetween using an uplink channel 62 and a downlink channel 64.

[0051] Attention is now drawn to FIG. 2A, in which the DCS is shown providing communication between the medical kit 10 and the gateway module 20. The patch 60 is configured for receiving data from the capsule 50 and for uploading data to the cloud 40. It should be noted that the data uploaded to the cloud may be any of the following: [0052] raw data obtained from the in-vivo device; [0053] processed data obtained from the in-vivo device; [0054] data processed by the patient module based on raw/processed data obtained from the device; and [0055] data based on any of the above.

[0056] The patch 60 is configured for uploading data to the cloud 40 either by direct communication 84 with the router 80, or via a hotspot established by a mobile device 70. The patch 60 is configured for communicating with the mobile device 70 via secure Wi-Fi 72 and via a first Bluetooth Low Energy (BLE) channel 74. Under this configuration, the mobile device 70 serves as an Access Point (AP) while the patch 60 functions as the client. The WiFi channel 72 is used in order to transfer acquired/processed data to the mobile device 70 while the BLE channel 74 is used for providing the mobile device 70 with notification and instructions related to the CE procedure, as well as a control signal checking that the mobile device 70 is active, in range etc.

[0057] It is noted that when the mobile device 70 establishes a hotspot, it connects the patch 60 to the cloud 40 via a cell antenna 100 (indicated by connections 102 and 94), or to the router 80 via connection 82.

[0058] When the patch 60 is connected to the cloud 40 via the mobile device 70 and cell antenna 100, the mobile device 70 is configured for terminating the hotspot within ninety seconds if no data is provided thereto by the patch 60. On the other hand, the patch 60 is configured for uploading data to the cloud 40 in chunks of predetermined size, and until such a data chunk is accumulated, the patch 60 will not transmit it to the mobile device 70.

[0059] This can create a situation in which the mobile device's hotspot remains idle for over ninety seconds, causing termination of the hotspot. Thereafter, if the patch 60 is required to upload data there will be a need to reestablish the hotspot, causing a delay in communication. In order to overcome this deficiency, the DCS is provided, according to which the patch 60 is configured for periodically sending a pinging signal to the mobile device 70, with a time period shorter than ninety seconds (in this example—sixty seconds). Thus, even if data is not being uploaded to the cloud 40 via the hotspot during the entire idle period, the hotspot will remain active and the hotspot will not be terminated.

[0060] In accordance with a particular example, the patch 60 is also configured for sending a secondary pinging signal via the first BLE channel 74 every five to fifteen seconds, configured for verifying that the mobile device 70 is active (hadn't shut down, is in range etc.).

[0061] Turning now to FIG. 2B, the DCS is shown providing communication between the HCP module 30, the gateway module 20 and the medical kit 10. In particular, during a capsule endoscopy procedure, an HCP may desire to review the data uploaded from the capsule 50 to the patch 60. In this case, a display device such as a tablet 110 may be used by the HCP to view the data.

[0062] Under this configuration, the patch 60 continuously advertises its presence, via a second BLE channel 112, in order to be discoverable by the HCP device 110. When the HCP desires to view the data, the tablet 110 requests access from the patch 60 via BLE connection 112. The patch 60 then verifies that the tablet 110 is authorized to access (in order to prevent unauthorized parties from viewing a patient's data), and grants access.

[0063] When the patch 60 receives such a request, it prioritizes the establishment of such a connection with the tablet 110 and switches to functioning as an AP while the tablet 110 functions as a client. In this case, once the connection 112 is established, the patch 60 halts its connection 72 with the mobile device's hotspot, and the HCP can have a Real Time View (RTV) of the data.

[0064] However, the patch 60 still prioritizes maintaining the hotspot active over the RTV, wherein after sixty seconds of RTV, the patch 60 will temporarily terminate the connection 112, switch back to functioning as a client for the mobile device 70 and send the pinging signal to maintain the channel 72 open. Thereafter, the patch 60 can switch back to the connection 112 and continue RTV with the HCP tablet 110.

[0065] With further reference to FIG. 2B, the HCP may also operate under a Near Real Time View (NRTV), in which case the router 120 of the HCP module 30 establishes a connection 126 with the cloud, downloading therefrom the data. Under this configuration, the patch 60 will no longer buffer the data in chunks, but rather will continuously upload data to the cloud via hotspot. Also in this case, there is not need for sending the pinging signal since the channel 72 with the mobile device 70 is constantly in use (i.e. no idle time).

[0066] Those skilled in the art to which this invention pertains will readily appreciate that numerous changes, variations, and modifications can be made without departing from the scope of the invention, mutatis mutandis.