Systems and methods for communicating medical sensor data to a cloud service

Abstract

A device may identify a portion of sensor data associated with a user, the portion of the sensor data having been collected by an analyte sensor device of the first device. The device may identify a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service. The device may determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device. The device may send the portion of the sensor data to the second device.

Description

SYSTEMS AND METHODS FOR COMMUNICATING MEDICAL SENSOR DATA TO A CLOUD SERVICEBACKGROUND

[0001] Current medical sensor devices (medical sensors) collect large amounts of data directly related to a user's health. For data to be accessed from some classes of medical sensors, such as in vivo analyte sensors that are worn by users on a long-term basis (e.g., days to weeks), the data must move from the medical sensor to an associated reader device (e.g., a specialpurpose reader device, or a smartphone configured as a reader device). Even further, if a medical professional or caretaker needs to access the data, the medical professional or caretaker may need to consult the reader device directly or ensure that the data has been uploaded from the reader device to an Internet-accessible service (e.g., cloud service). However, the process of transferring sensor data from a medical sensor to a reader device, and / or from a reader device to a cloud service, can be confusing to users, can be unreliable, and oftentimes requires the user to manually start each upload process (e.g., by launching a smartphone application). If the user forgets or fails to upload data, data may become lost or inaccessible.

[0002] In other scenarios, such as scenarios involving inpatient care within a medical facility, a medical provider may be tasked with applying one or more sensors to a patient, such as a continuous lactate monitor (CLM), a continuous glucose monitor (CGM), or another sensor capable of gathering analyte levels of the patient. The monitors that may be attached to the patient may also include pulsometers, oximeters, and other sensors.

[0003] In some instances, the data gathered from the various monitors are stored in different charts and electronic files associated with the patient within the care facility of the patient. In other instances, the monitors are not persistently gathering data, but are only used to show a real-time graph of the sensor data as it is being monitored.

[0004] Many patients have electronic health records (EHR) that comprise electronic files that store information about a patient, including health metrics and personal information. The EHR for a patient may be stored in a third-party medical clearinghouse and / or be stored by a practitioner system (e.g., a hospital or health network system) to be referenced by practitioners and the patient during ongoing medical treatments.

[0005] To facilitate comprehensive medical considerations, it would be desirable to correlate the different sensor data gathered by the different medical sensors for a patient within a single EHR that can be referenced by medical practitioners. However, in the conventional medical industry, there may be many different types of data gathered for a patient, includingdata in different formats from different devices and in different locations, which can make it difficult to correlate all of the disparate data with a patient, such as within their EHRs, particularly when different vendors utilize different configurations of EHRs.

[0006] Some of the factors affecting the difficulty in correlating the different medical data with a patient is the durations of time during which sensors are used, from when they are initially applied and until they are replaced, and disparate locations in which the sensor data is gathered (e.g., from sensors used within the inpatient facility and from sensor used to monitor the patient at their homes and other outpatient environments).

[0007] In view of the foregoing, there is an ongoing need and desire to provide improved techniques and systems for facilitating the gathering and correlating of sensor data with corresponding patients, such as within user EHRs.

[0008] The subject matter claimed herein is not limited to embodiments that solve any disadvantages or that operate only in environments such as those described supra. Instead, this background is only provided to illustrate one example technology area where some embodiments described herein may be practiced.SUMMARY

[0009] Aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features of one aspect may be applied to other aspects either alone or in combination with other features.

[0010] The aspects are described below and claimed herein as a computer system . However, corresponding methods and apparatus are also described and envisaged herein including network nodes, computer programs, computer program products, computer readable media and logic encoded on tangible media for implementing the computer systems that are described. Apparatus comprising means for implementing the steps described as being implemented by the computer system is also envisaged and encompassed by the present disclosure.

[0011] In some aspects, the techniques described herein relate to a method, implemented at a cloud service computer system, including: receiving a network request from a first remote device, the network request including a uniform resource identifier (URI) that includes a unique identifier of a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensordata having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

[0012] In some aspects, the techniques described herein relate to a cloud service computer system, including: a processor; and a computer-readable media storing computerexecutable instructions that are executable by the processor to perform operations, including: receiving a network request from a first remote device, the network request including a URI that includes a unique identifier of a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

[0013] In some aspects, the techniques described herein relate to a method implemented in a first device including a sensor unit and an analyte sensor device, including: identifying a portion of sensor data associated with a user, the portion of the sensor data having been collected by the analyte sensor device of the first device; identifying a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service; determining, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and sending the portion of the sensor data to the second device.

[0014] In some aspects, the techniques described herein relate to a sensor unit, including: an analyte sensor device; and sensor control electronics that include: a wireless communication hardware; and wireless communication logic that causes the sensor unit to at least: identify a portion of sensor data associated with a user, the portion of the sensor data having been collected by the analyte sensor device; identify a wireless presence of a second device using the wireless communication hardware, the second device configured for relaying the sensor data towards a cloud service; determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and send the portion of the sensor data to the second device via the wireless communication hardware.

[0015] In some aspects, the techniques described herein relate to a method implemented in a hub comprising a processor system and stored executable instructions that are executable by the processor system to implement a method for processing and communicatinganalyte sensor data received from one or more analyte sensors.

[0016] In some instances, systems correlate patient information with sensor data in the EHR of a corresponding patient by at least creating and / or identifying a sensor-to-patient association, a hub-to-patient association and / or a hub and sensor to patient association, the referenced association(s) being transmitted within one or more electronic record(s) transmitted to a practitioner and / or a remote system for identifying the patient EHR and / or for storing the patient's sensor data within their associated EHR.

[0017] Disclosed methods include a hub detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID and / or hub ID; and the hub transmitting the processed patient data packets to a remote system over a long-range communication channel.

[0018] In some aspects, the techniques described herein relate to a hub including: a processor system; and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from one or more analyte sensors, the sensor data being associated with a particular patient via an electronic record that was transmitted to a remote system that correlates a sensor ID of the sensor with an identifier of the particular patient, the method including: the hub detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID; and the hub transmitting the processed patient data packets to a remote system over a long-range communication channel.

[0019] In some aspects, the techniques described herein relate to a method for correlating records including different identifiers received from different sources, the method including: Identifying an electronic record that correlates a sensor identifier and / or a hub identifier with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet including the sensor and / or hub identifier and analyte sensor data from a first source; adding the analyte sensor data to the stored electronic health record in response to determining the sensor and / or hub identifier correlates with the patient identifier of the first user that is associated withthe EHR; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

[0020] In some aspects, the techniques described herein relate to a computing system including: a processor system; and stored executable instructions that are executable by the processor system to implement a method for correlating records including different identifiers received from different sources, the method including: Identifying an electronic record that correlates a sensor and / or hub identifier with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet including a sensor and / or hub identifier and analyte sensor data from a first source; adding the analyte sensor data to the stored electronic health record in response to determining the sensor and / or hub identifier correlates with the patient identifier of the first user that is associated with the EHR; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

[0021] In some aspects, the techniques described herein relate to a method, implemented in a medical sensor reader device, including: starting an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establishing a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publishing connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establishing an ad-hoc network connection with an electronic device via the self-configured network; and communicating the analyte data to the electronic device via the ad-hoc network connection.

[0022] In some aspects, the techniques described herein relate to a medical sensor reader device including one or more processors and a computer-readable storage medium including computer-executable instructions that cause the medical sensor reader device to at least: identify a request to initiate an ad-hoc communications mode; and based on the request:start an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the selfconfigured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

[0023] In some aspects, the techniques described herein relate to a computer-readable storage medium including computer-executable instructions that cause a medical sensor reader device to at least: start an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the self-configured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

[0024] This Summary introduces a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to determine the scope of the claimed subject matter.BRIEF DESCRIPTION OF THE DRAWINGS

[0025] To describe how the advantages of the systems and methods described herein can be obtained, a more particular description of the embodiments briefly described supra is rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. These drawings depict only typical embodiments of the systems and methods described herein and are not, therefore, to be considered to be limiting in their scope. Systems and methods are described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0026] Figure 1 illustrates an example of a computer architecture that facilitates a noapplication experience for connecting a medical sensor to a cloud service.

[0027] Figure 2 illustrates an example of a computer architecture that facilitates opportunistically communicating sensor data from a medical sensor service.

[0028] Figures 3A-3C illustrate an example of opportunistically communicating sensor data from a medical sensor.

[0029] Figure 4 illustrates a flow chart of an example of a method for providing a noapplication experience for connecting a medical sensor to a cloud service.

[0030] Figure 5 illustrates a flow chart of an example of a method for opportunistically communicating sensor data from a medical sensor.

[0031] Figures 6-10 illustrate examples of a medical environment in which patient information is correlated with a sensor ID and / or hub ID by a provider system record and which may be uploaded to a server of the provider or a third-party system and which may be further used to associate the patient with the hub and sensor data transmitted from the hub within a EHR.

[0032] Figure 11 illustrates another example of a medical environment in which patient information is correlated with a hub ID and / or a sensor ID by a provider system record and which may be uploaded to a server of the provider or a third-party system and which may be further used to associate the patient with the corresponding hub and / or sensor and sensor data transmitted from the hub within a EHR and in which the EHR is also used to correlate sensor data obtained from a reader device that is located in a different location than the hub.

[0033] Figure 12 illustrates a flow chart of an example of a method implemented by a hub for processing and transmitting sensor data from one or more medical sensors in a manner that facilitates correlating sensor data from the one more medical sensors with a patient based on at least a hub ID.

[0034] Figure 13 illustrates a flow chart of an example of a method implemented by a computing system for receiving and correlating sensor data with a patient, the sensor data being received from multiple sources, including a hub, such as the hub described in reference to Figure 12, and at least one additional device that is located at a different location than the hub.

[0035] Figure 14 illustrates an example system in which a reader device communicates sensor data to a personal device using an ad-hoc communication mode.

[0036] Figure 15A illustrates an example of a reader device that presents a quick response (QR) code and a personal device that uses the QR code to establish an ad-hoc network connection and to access sensor data from the reader device.

[0037] Figure 15B illustrates an example of a reader device and a personal device using near-field communication to set up a temporary network connection and access sensor data from the reader device.

[0038] Figure 16 illustrates an example of a reader device using a low-power wireless mesh network to communicate sensor data to a cloud service.

[0039] Figure 17 illustrates a flow chart of a method implemented by a medical sensor reader device to facilitate ad-hoc communications with a personal device.DETAILED DESCRIPTION

[0040] Medical sensors are used to collect large amounts of data regarding a patient's health every day. This data is essential for the patient, caretakers, and medical professionals to properly care for the patient. Normally for the data to be accessed, the patient downloads and configures an application provided by a medical sensor vendor onto a personal device, such as a smartphone. That application then enables the personal device to interface with the medical sensor and allows the personal device to receive data from the sensor. Once the sensor data is received, the application sends the sensor data to an Internet-accessible service (e.g., cloud service) that can be accessed by others, such as medical professionals or caretakers.

[0041] There can be significant friction for users when initially attempting to configure a personal device to interface with a medical sensor. For example, the user may be unfamiliar with the personal device's application ecosystem, leading to difficulty in locating and installing the vendor-provided application. Further, in some geographical locations or economic situations, a user may lack sufficient data allotment or bandwidth to download a vendor-provided application. Still further, a user's personal device may be incapable of running a vendor-provided application (e.g., due to processing or storage constraints or compatibility issues).

[0042] Even when a user has successfully installed and configured a vendor-provided application, the user may forget to open the application regularly or forget to synchronize their medical device with the application, leading to a failure of the application to receive sensor data and relay it to the cloud service. This means that the sensor data is not easily accessible to provide proper care to the patient. Even further, when the data cannot easily be transferred from the sensor to the cloud database, it causes frustration for the patient and medical professional and wastes time retrieving the data instead of treating the patient.

[0043] Generally, embodiments of the present disclosure include systems, devices, and methods to improve the user experience and / or reliability of transferring sensor data from a medical sensor to an Internet-accessible service (e.g., cloud service) and for facilitating the correlation of the sensor data with a patient, such as within an EHR associated with the patient.Additional embodiments include systems, devices, and methods to access sensor data from a reader device locally, e.g., without needing an Internet-accessible device.

[0044] Some embodiments improve the user experience and / or reliability of transferring sensor data from a medical sensor to a cloud service by eliminating the need to download, install, and configure a vendor-supplied application to a personal device. These embodiments enable a web-based application experience, in which the vendor-provided application runs on the personal device as a "web application" within web browser software on the personal device. In some embodiments, a user is enabled to launch the web application based on machine reading of a uniform resource identifier (URI) that is included in, or on, the medical sensor, itself. For example, a medical sensor may include a wireless technology, such as NearField Communication (NFC), Radio Frequency Identification (RFID), or ultra-wideband (UWB), that communicates a URI to a personal device when the personal device is brought into proximity of the medical sensor. In another example, a medical sensor may have an optically-readable code, such as a quick-response (QR code) affixed thereto that embeds a URI that is optically readable by a personal device. In some embodiments a URI includes (e.g., as a parameter) a unique value, such as a serial number, which is particular to the medical sensor to which the URI is associated. Thus, when a personal device uses this URI to navigate to the vendor's web application, the identity of the particular medical sensor unit is inherently communicated to the vendor's web application. In embodiments, based on communication of the identity of a particular medical sensor unit via a URI, the medical sensor unit— and any sensor readings obtained therefrom— are associated with a user profile (e.g., based on an email address or other credentials provided by the user via the web application). Thus, scanning and navigating to a URI provided by a medical sensor can enable a user's personal device to quickly reach a vendor-provided web application for the medical sensor, while automatically (from the perspective of the user) registering that medical sensor to that user's profile.

[0045] In other embodiments, the user or patient profile is created by a clinician. In embodiments, creating a user or patient profile involves initially capturing a patient's Medical Record Number (MRN) by scanning the patient's ID wristband and then filling in additional patient ID information, such as name, date of birth, address, and social security number, by querying the patient's Electronic Health Record (EHR) using an Admission Discharge Transfer (ADT) feed. As such, in these embodiments, an MRN is used to locate a patient's EHR, which contains comprehensive ID information about the patient. This seamless process allows clinicians to use an app or shared device to scan a sensor (or hub in some instances) and scan a patient's ID wristband, for example, creating an association between the sensor ID (or optionally a hub ID)and the patient ID. This electronic association can comprise a stored electronic record in the clinician device and can also be transmitted to the practitioner server system or a remote third- party system. In these scenarios, the user information or patient ID may be a patient MRN issued by the practitioner inpatient facility, an insurance entity and / or another third-party entity.

[0046] Notably, by using URIs that are customized per medical sensor unit, each new medical sensor that a given user obtains is automatically associated with the user's profile when the user first navigates to the medical sensor's URI and provides a credential via the vendor's web application.

[0047] In some embodiments, a web application utilizes web browser application programming interfaces (APIs), such as the Web BLUETOOTH API, to communicate directly with a medical sensor (e.g., using a BLUETOOTH low energy (BLE) connection) once that web application is loaded based on a URI obtained from the medical sensor. In embodiments, the URI provided by a medical sensor includes (e.g., as one or more parameters) any details (e.g., device address, authentication information) needed for the web application to connect to the medical sensor. In other embodiments, the cloud service communicates to the personal device the details needed for the web application to connect to the medical sensor. Thus, scanning and navigating to a URI provided by a medical sensor can also enable a personal device to wirelessly connect to that medical sensor to obtain sensor readings from the medical sensor.

[0048] In some embodiments, a medical sensor is capable of initiating direct communication with a cloud service. In these embodiments, the sensor includes wireless communication hardware, such as cellular (e.g., 4G, 5G), wireless fidelity (Wi-Fi), and the like, which enables the sensor unit to be Internet-Protocol (IP)-addressable and, thus, communicate with the cloud service directly. In these embodiments, the medical sensor initiates a connection to the cloud service over the Internet and communicates sensor data to the cloud service via this connection.

[0049] Whether using a native application or a personal application on a personal device, some embodiments further improve the user experience and / or reliability of transferring sensor data off of a medical sensor by configuring the medical sensor to opportunistically communicate sensor data to another device, even if that other device is not the user's device, and even in the absence of user action (e.g., loading or running a vendor-provided native application or web application on a personal device).

[0050] In some embodiments, the opportunistic communication of sensor data is performed in place of a medical sensor communicating sensor data to a personal device, or to a cloud service directly. In other embodiments, the opportunistic communication of sensor data isperformed in addition to a medical sensor communicating sensor data to a personal device, or to a cloud service directly.

[0051] In some embodiments, opportunistically communicating sensor data to another device results in the secure communication of the sensor data to a cloud service. Thus, in these embodiments, a medical sensor unit communicates sensor data to a cloud service indirectly, via one or more intermediary devices. In these embodiments, the sensor unit includes wireless communication hardware, such as BLUETOOTH, BLE, NFC, RFID, UWB, THREAD, and the like, which enables the sensor unit to relay sensor data to an intermediary device (e.g., a hub). This intermediary device, in turn, relays the sensor data to another intermediary device (e.g., if the intermediary device is not IP-addressable) or to the cloud service (e.g., if the intermediary device is IP-addressable), such as within a BLUETOOTH Gateway ("hub") configuration. In some embodiments, intermediary devices are associated with the same user as a given sensor unit.

[0052] In other embodiments, intermediary devices may be associated with different users from the user of the given sensor unit. For example, an intermediary device may be another sensor unit or a personal device running a vendor-supplied application, each of which may be associated with the user or may not be associated with the user. In one illustrative example, a first sensor unit communicates collected sensor data to a second sensor unit. The second sensor unit, in turn, communicates the sensor data to a personal device, which relays the sensor data to a cloud service. In this way, sensor data generated by the first sensor unit is relayed to the cloud service without the use of a personal device associated with the first sensor unit.

[0053] While the first and second sensor units may be associated with the same user, some embodiments enable the first and second sensor units to be associated with different users. For example, the first sensor unit may encrypt the collected sensor data before communicating it to the second sensor unit, preserving the privacy of that data while it is in possession of the second sensor unit and its associated personal device.

[0054] In other embodiments, opportunistically communicating sensor data to another device (e.g., a medical monitoring device) results in the consumption of that data by the receiving device. The embodiments described herein may include a hub and / or reader that communicates with different sensors, and which are part of the opportunistic communication paths described herein.

[0055] At least some embodiments are advantageous for connecting a medical sensor to a cloud service or medical device without requiring the patient associated with the medical sensor to download, install, or configure a separate application on their personal device, or ensure that the application continues to operate properly. Thus, disclosed systems and methodsallow data to easily be transferred from medical sensors to a cloud service or medical device equipment, and accessed by medical professionals, caretakers, and the patient. Notably, these embodiments also do not preclude a user's use of a personal device to interact with the sensor device, or use of that personal device to communicate sensor data to the cloud service. For example, while a medical sensor may be capable of direct and / or indirect communication of sensor data to a cloud service, the medical sensor may also be capable of more conventional communication of sensor data to a personal device.

[0056] Additionally, disclosed embodiments advantageously can reduce how much data the medical sensors must store due to frequently uploading the data to a cloud service, therefore improving the management of limited memory resources in the sensors themselves. In embodiments, a medical sensor includes decision logic to determine when, and how, to communicate sensor data. In embodiments, this decision logic determines when, and how, to communicate sensor data based on one or more available power supply, a detected wireless network signal level, an amount of stored sensor data, data synchronization history, and the like.

[0057] In some examples, embodiments are operable with medical sensors in the form of in vivo analyte sensors. In vivo analyte sensors are structurally configured so that at least a portion of the sensor is, or can be, positioned in the body of a user to make contact with the bodily fluid of the user and obtain information about at least one analyte, such as glucose, ketones, lactate, oxygen, hemoglobin A1C, or the like. The sensor can be part of a sensor unit that resides on the body of the user, and that contains the electronics and power supply that enable and control the analyte sensing. The sensor unit, and variations thereof, can also be referred to as a "sensor control unit," an "on-body electronics" device or unit, an "on-body" device or unit, or a "sensor data communication" device or unit, to name a few.

[0058] In other examples, embodiments are operable with other forms of medical sensors, such as body temperature sensors, blood flux sensors, blood viscosity sensors, blood pressure sensors, heart rate sensors, oxygen level sensors, and the like.

[0059] Regardless of their form, medical sensors are used to collect large amounts of data regarding people's health. This data can be essential for the patient, caretakers, and medical professionals to properly care for the patient. For many types of medical sensors, the sensor data is accessed using an associated reader device, such as a personal smartphone device or a dedicated reader device. In one example, continuous analyte monitoring systems (e.g., continuous glucose monitoring systems), transmit data from an analyte sensor unit to a personal device continuously (e.g., automatically according to a schedule) using a wireless communication technology such as BLUETOOTH or BLE. In another example, flash analyte monitoring systems(e.g., flash glucose monitoring systems) transfer data from a sensor unit to a personal device or dedicated reader device in response to a direct request by the personal device or dedicated reader device using a wireless communication technology such as NFC, RFID, or UWB.

[0060] Figure 1 illustrates an example of a computer architecture 100 that eliminates the need to download, install, and configure a vendor-supplied application onto a personal device in order to associate a medical sensor with a user profile at a cloud service. In other words, computer architecture 100 facilitates a "no-application" experience for connecting a medical sensor to a cloud service.

[0061] Computer architecture 100 includes a sensor unit 101 comprising a sensor device 102, a power supply 103 (e.g., a battery, a solar cell), and sensor control electronics 104. According to some embodiments, sensor unit 101 can be an on-body unit (also referred to as a sensing unit) that includes an analyte sensor, such as a transcutaneous glucose sensor. In some embodiments, the analyte sensor can have a proximal portion coupled with electronics disposed in the on-body unit. The analyte sensor can also have a distal portion configured to be positioned under a skin layer of the person wearing the on-body unit, where the distal portion is configured to detect or sense an analyte level in the interstitial fluid. In various examples, sensor device 102 is an analyte sensor such as glucose, ketones, lactate, oxygen, or hemoglobin A1C; a temperature sensor; a blood flux sensor, a blood viscosity sensor, a blood pressure sensor, a heart rate sensor, a blood oxygen level sensor, and the like. In embodiments, sensor control electronics 104 comprises a system-on-a-chip (SoC), an application-specific integrated circuit (ASIC), a microcontroller, and the like. In embodiments, sensor control electronics 104 implement one or more of a processor, volatile memory, non-volatile memory, wireless communication hardware, and the like. In many embodiments, the sensor electronics of the on-body unit can include a power supply, processing circuitry, memory, wireless communication circuitry, and a printed circuit board.

[0062] In computer architecture 100, a personal device 108 (e.g., a smartphone) acquires a URI 107 from sensor unit 101. In some embodiments, the personal device 108 acquires URI 107 optically, such as via a QR code printed or affixed to an outer surface of the sensor unit 101. In other embodiments, the personal device 108 acquires URI 107 via radio communication, such as via NFC, RFID or UWB circuitry included in sensor control electronics 104.

[0063] In embodiments, network 115 includes an address for navigating to a web application 114 provided by a cloud service 109 (see data service 112). In embodiments, the cloud service 109 comprises one or more computer systems, each of which comprises computer hardware, such as a processor, memory, storage media, and the like. In embodiments, URI 107includes an identifier unique to the sensor unit 101, such as a serial number corresponding to the sensor unit 101. For example, URI 107 may include an identifier unique in the form of a URI parameter. Based on acquiring URI 107, personal device 108 navigates to web application 114 using a web browser at personal device 108. Due to the presence of the unique identifier of sensor unit 101 in URI 107, the act of navigating to web application 114 communicates the unique identifier to data service 112.

[0064] In embodiments, web application 114 prompts a user of the personal device 108 to provide credential information, such as username, email address, password, and the like. As shown, cloud service 109 includes a database 110 comprising a plurality of user profiles (e.g., user profile Illa to user profile llln). In embodiments, upon receipt of the credential information, data service 112 identifies (which can include creating) a profile (e.g., user profile Illa), that corresponds to the credential information or unique patient identifier. The data service 112 then registers the unique identifier of sensor unit 101, as obtained from URI 107, with that profile. In embodiments, based on cloud service 109 receiving sensor data (e.g., data 106) that is associated with a unique identifier, data service 112 identifies a profile (e.g., user profile Illa) to which that unique identifier is registered and saves that sensor data in that profile.

[0065] In embodiments, data service 112 provides users, doctors, caregivers, etc. access to sensor data stored in a given profile. For example, as shown, data service 112 may provide one or more APIs 113 for interacting with data service 112, web application 114 for browsing sensor data via a web browser, and the like.

[0066] Sensor control electronics 104 is shown as implementing (e.g., via logic gates, software instructions, or a combination of the two) a wireless communication logic 105, and as storing (e.g., in volatile memory and / or non-volatile memory) data 106 comprising sensor readings generated by sensor device 102.

[0067] In computer architecture 100, sensor unit 101 is illustrated as potentially communicating wirelessly directly with personal device 108. Thus, in embodiments, sensor control electronics 104 includes wireless communication hardware, such as BLUETOOTH, BLE, and the like, capable of these direct wireless communications. In these embodiments, wireless communication logic 105 uses this wireless communication hardware to communicate directly with personal device 108 and communicate data 106 to personal device 108. As shown, in embodiments, personal device 108 is also capable of communicating with cloud service 109 via network 115 and thus is capable of relaying data 106 to cloud service 109. In some embodiments, web application 114 utilizes web browser APIs, such as the Web BLUETOOTH API, to communicate directly with the sensor unit 101 (e.g., using BLE). In some embodiments, URI 107includes (e.g., as one or more parameters) any details (e.g., device address, authentication information) needed for web application 114 to connect to the sensor unit 101. In other embodiments, cloud service 109 communicates to the personal device 108, the details needed for web application 114 to connect to sensor unit 101 (e.g., based on sensor information stored in database 110).

[0068] Additionally, or alternatively, in computer architecture 100, sensor unit 101 is illustrated as potentially communicating directly with cloud service 109 via network 115. Thus, in embodiments, sensor control electronics 104 include wireless communication hardware, such as a cellular modem (e.g., 4G, 5G, and so on), Wi-Fi, and the like, capable of obtaining an IP address for communications over network 115 (e.g., which can include a local-area network (LAN) and a wide-area network (WAN) such as the Internet). In these embodiments, wireless communication logic 105 uses this wireless communication hardware to establish a direct connection with cloud service 109 via network 115 and to communicate data 106 to cloud service 109 over that connection.

[0069] Figure 2 illustrates an example of a computer architecture 200 that facilitates opportunistically communicating sensor data from a medical sensor (e.g., to a cloud service, to a medical monitoring device). Computer architecture 200 includes a sensor unit 201 comprising a sensor device 202, a power supply 203 (e.g., a battery, a solar cell), and sensor control electronics 204. Like sensor device 102, in various examples, sensor device 202 is an analyte sensor such as glucose, ketones, lactate, oxygen, or hemoglobin A1C; a temperature sensor; a blood flux sensor, a blood viscosity sensor, a blood pressure sensor, a heart rate sensor, a blood oxygen level sensor, and the like. In embodiments, sensor control electronics 204 comprises a SoC, an ASIC, a microcontroller, and the like. In embodiments, sensor control electronics 204 implements one or more of a processor, volatile memory, non-volatile memory, wireless communication hardware, and the like.

[0070] Sensor control electronics 204 is shown as implementing (e.g., via logic gates, software instructions, or a combination of the two) a wireless communication logic 205, and as storing (e.g., in volatile memory and / or non-volatile memory) data 206 comprising sensor readings generated by sensor device 202. As shown, in some embodiments, computer architecture 200 includes a personal device 208 that is capable of receiving data 206 from the sensor unit 201 (e.g., using BLUETOOTH, BLE, NFC, RFID, UWB, and the like). As shown, in embodiments, personal device 208 is also capable of communicating with cloud service 109 via network 215 and thus is capable of relaying data 206 to cloud service 109.

[0071] In computer architecture 200, sensor unit 201 is also illustrated ascommunicating with device 216 or, as shown, a plurality of devices, to which it can opportunistically communicate sensor data. Thus, in computer architecture 200, sensor control electronics 204 includes wireless communication hardware, such as a BLUETOOTH, BLE, NFC, RFID, UWB, and the like, which enables sensor unit 201 to relay sensor data to at least device 216. Notably, in some embodiments, the wireless communication hardware of sensor control electronics 204 may be incapable of obtaining an IP address for direct communications over network 215. However, in some embodiments, device 216, or another device that device 216 can communicate with is connected to network 115 and can communicate with cloud service 109. In embodiments, wireless communication logic 205 uses this wireless communication hardware to establish a direct connection with device 216 and to communicate data 206 to device 216.

[0072] In some embodiments, sensor unit 201 and device 216 are associated with the same user. In other embodiments, sensor unit 201 and device 216 are associated with different users. In either embodiment, sensor unit 201 may encrypt data 206 before communicating it to device 216, preserving the privacy of that data while it is in possession of device 216, or by any other device to which device 216 may send the data. In some embodiments, sensor unit 201 encrypts data 206 using symmetric encryption, based on a key shared with cloud service 109 (e.g., a key stored in a profile associated with the sensor unit's user). In other embodiments, the sensor unit 201 encrypts data 206 using asymmetric encryption, based on a private key whose public key is shared with cloud service 109 (e.g., a public key stored in a profile associated with the sensor unit's user). In either case, embodiments enable cloud service 109 to decrypt the data 206 (e.g., using an appropriate key stored in a profile associated with the sensor unit's user).

[0073] In some embodiments, device 216 relays that sensor data towards cloud service 109 (e.g., directly over network 215 or via another device). In these embodiments, device 216 may be another sensor unit configured to communicate sensor data in a meshed manner among other sensor units or may be a personal device configured (e.g., via a vendor-provided application) to receive sensor data sensor units and communicate that sensor data to cloud service 109 via network 215.

[0074] In other embodiments, device 216 consumes that sensor data. In these embodiments, device 216 may be a medical device, such as a medical monitoring device configured to display or analyze the sensor data. For example, device 216 may be an electrocardiograph, a ventilator, an infusion pump, a hospital bed, surgical equipment, an oxygen concentrator, an anesthetic machine, a bedside multiparameter monitor, and the like. In some embodiments, such a medical device further relays the sensor data to cloud service 109 (e.g., via meshed communications, via network 215).

[0075] Notably, the embodiments described in connection with computer architecture 200 for opportunistic communications are readily combinable with the embodiments described in connection with computer architecture 100. For example, in addition to being configured for facilitating a no-application experience for connecting the sensor unit 101 to cloud service 109, sensor unit 101 may further possess the functionality to send data 106 to device 216, which may consume the data (e.g., as a medical monitoring device ) and / or relay data 106 towards cloud service 109.

[0076] Figures 3A-3C illustrate an example 300 of opportunistically communicating sensor data from a medical sensor. Initially, Figure 3A illustrates an example 300a in which a sensor 301 (e.g., sensor unit 201) is at a location associated with a user and is near device 301 and device 303. Device 302 has a range (shown by a circle around the device), and device 303 has another range (shown by a circle around the device). In one example, device 302 is another sensor unit, and device 303 is a personal device comprising an application (e.g., a vendor app associated with sensor 301) that configures it to engage in the opportunistic communications described herein. In another example, device 302 is medical equipment, and device 303 is another sensor unit or a personal device configured to engage in the opportunistic communications described herein. In some embodiments, the ranges of device 302 and device 303 may be represented by other shapes such as squares, rectangles, octagons, ovals, or irregular shapes. In some embodiments, the ranges of device 302 and device 303 are the same, while in other embodiments the ranges of device 302 and device 303 differ. The ranges of device 302 and device 303 can be static or dynamic. In embodiments where a range is dynamic, the range can change based on the environment, user input, a machine learning model, the presence of other devices, or other factors. In Figure 3A, device 302 and device 303 are out of range of the sensor 301. In this instance, the sensor 301 is not connected to either device 302 or device 303.

[0077] Figure 3B illustrates an example 300b, in which sensor 301 has moved within range of device 302 (e.g., based on the movement of a user wearing sensor 301). In embodiments, sensor 301 detects the presence of device 302 and establishes a connection with device 302 using a wireless protocol such as BLE. Once a connection is established, sensor 301 sends sensor data (potentially in encrypted form) collected by sensor 301 to device 302. For example, device 301 can send analyte data associated with a user of sensor 301 to device 302. In some embodiments, sensor 301 sends all the data that sensor 301 has collected to device 302. In some embodiments, sensor 301 sends only a portion of the data collected to device 302. For example, sensor 301 may send only data from the previous hour or day to device 302.

[0078] In some examples, device 302 consumes the sensor data (e.g., device 302 is amedical monitor that displays the data, monitors changes in an analyte level, etc.). In some embodiments, device 302 consumes the sensor data based on the sensor data being not encrypted when sent by sensor 301 to device 302. In other embodiments, device 302 consumes the sensor data based on decrypting the sensor data, e.g., based on a key obtained from cloud service 109.

[0079] In other examples, device 302 relies on meshed communication to relay the sensor data toward the cloud service 109. For example, Figure 3C illustrates an example 300c in which device 302 and device 303 are now in range of each other. In embodiments, device 302 detects the presence of device 303 and establishes a connection with device 303 using a wireless protocol such as BLE. Once a connection is established, device 303 sends the sensor received from sensor 301 to device 303. In embodiments, such as when device 303 is a personal device configured to engage in opportunistic communications, device 303 sends the data to cloud service 109. In other embodiments, such as when device 303 is another sensor unit, device 303 waits until it is in contact with another device, and sends the sensor data to that device.

[0080] Returning to Figure 2, in embodiments, wireless communication logic 205 includes decision logic for determining when to establish a connection with device 216 and send data 206 to that device. In one embodiment, the decision logic determines whether to establish a connection with device 216 based on how recently sensor data has been communicated to personal device 208, with less recent communications of sensor data to personal device 208 favoring the establishment of the connection with device 216. In another embodiment, the decision logic determines whether to establish a connection with device 216 based on how recently a direct connection was established with cloud service 109, with a less recent connection with cloud service 109 favoring the establishment of the connection with device 216. In another embodiment, the decision logic determines whether to establish a connection with device 216 based on a measured signal strength of device 216, with a stronger measured signal strength favoring the establishment of the connection with device 216. In another embodiment, the decision logic determines whether to establish a connection with device 216 based on a measured availability of power from power supply 203, with a larger availability of power favoring the establishment of the connection with device 216. In another embodiment, the decision logic determines whether to establish a connection with device 216 based on an amount of sensor data in data 206 that has not been sent to either personal device 208 or cloud service 109, with a larger amount of sensor data favoring the establishment of the connection with device 216. Embodiments can use any combination of the foregoing, with various priorities and weightings.

[0081] The following discussion now refers to a number of methods and method acts.Although the method acts are discussed in specific orders or are illustrated in a flow chart as occurring in a particular order, no order is required unless expressly stated or required because an act is dependent on another act being completed prior to the act being performed.

[0082] Embodiments are now described in connection with Figure 4, which illustrates a flow chart of an example method 400 for providing a no-application experience for connecting a medical sensor to a cloud service. In embodiments, instructions for implementing method 400 are encoded as computer-executable instructions (e.g., data service 112, web application 114) stored on a computer storage media that are executable by a processor (e.g., a processor of cloud service 109) to cause a computer system to perform method 400.

[0083] Referring to Figure 4, in embodiments, method 400 comprises act 401 of receiving a network request comprising a unique sensor unit identifier. In some embodiments, act 401 comprises receiving a network request from a first remote device, the network request comprising a URI that includes a unique identifier of a sensor unit. For example, based on receiving URI 107 from sensor unit 101 (e.g., via a QR code, NFC, RFID, or UWB), personal device 108 navigates to URI 107 in a web browser. Because URI 107 includes (e.g., as a parameter) a unique identifier for sensor unit 101, web application 114 receives a network request including that unique identifier.

[0084] Method 400 also comprises act 402 of presenting a web application. In some embodiments, act 402 comprises presenting a web application corresponding to the URI to the first remote device. For example, cloud service 109 serves web application 114 to personal device 108.

[0085] Method 400 also comprises act 403 of receiving a user credential. In some embodiments, act 403 comprises receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device. For example, based on interaction with web application 114 at personal device 108 a user inputs a credential, such as a username, an email address, a password, etc.

[0086] Method 400 also comprises act 404 of associating the unique identifier with a profile of the user credential. In some embodiments, act 404 comprises associating the unique identifier for the sensor unit with a profile associated with the user credential. For example, having received the unique identifier as part of the request received in act 401, data service 112 associates the unique identifier with a profile (e.g., user profile Illa) corresponding to the credential received in act 403.

[0087] Method 400 also comprises act 405 of receiving sensor data associated with the unique identifier. In some embodiments, act 405 comprises receiving sensor data from a secondremote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit. For example, cloud service 109 receives sensor data from sensor unit 101 directly, or via mesh communications as described in connection with Figures 2-3C.

[0088] Method 400 also comprises act 406 of associating the sensor data with the user profile. In some embodiments, act 406 comprises associating the sensor data with the profile based on receiving the unique identifier for the sensor unit. For example, data service 112 stores the sensor data in the profile (e.g., user profile Illa) corresponding to the credential received in act 403.

[0089] Embodiments are now described in connection with Figure 5, which illustrates a flow chart of an example method 500 for opportunistically communicating sensor data from a medical sensor. In embodiments, method 500 is implemented by sensor control electronics (e.g., sensor control electronics 104, sensor control electronics 204) of a sensor unit (e.g., sensor unit 101, sensor unit 201).

[0090] Referring to Figure 5, in embodiments, method 500 comprises act 501 of identifying collected sensor data. In some embodiments, act 501 comprises identifying a portion of sensor data associated with a user, the portion of the sensor data having been collected by an analyte sensor device of the first device. For example, sensor control electronics 204 identifies data 206, which was collected by sensor device 202.

[0091] Method 500 also comprises act 502 of identifying a wireless presence of a relay device. In some embodiments, act 502 comprises identifying a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service. For example, wireless communication logic 205 identifies a wireless presence of device 216.

[0092] Method 500 also comprises act 503 of determining to communicate the collected sensor data to the relay device. In some embodiments, act 503 comprises determining, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device. For example, wireless communication logic 205 determines whether to communicate data 206 to device 216 based on factors such as how recently the sensor unit has communicated with an associated personal device; a type of the second device (e.g., first-party device, partner device, insulin pump, insulin pen); how recently the sensor unit has communicated with the cloud service; a measured signal strength of device 216; a measured availability of power in power supply 203; an amount of the sensor data; whether a relevant patient account is associated with a caregiver (e.g., to send data more frequently so that the caregiver can see the data at a more frequent rate), and the like.

[0093] In some embodiments, method 500 also comprises act 504 of encrypting the collected sensor data. In some embodiments, act 504 comprises encrypting the portion of the sensor data prior to sending the portion of the sensor data to the second device. For example, sensor control electronics 204 encrypt data 206 so that it cannot be read by device 216 but so that it can be read by cloud service 109.

[0094] Method 500 also comprises act 505 of sending the collected sensor data to the relay device. In some embodiments, act 505 comprises sending the portion of the sensor data to the second device. For example, wireless communication logic 205 sends data 206 to device 216, potentially in encrypted form.

[0095] In some embodiments, as described in more detail below with regard to Figures 6-13, methods and systems are also provided for gathering and processing patient sensor data (such as the sensor data described above) and for facilitating the correlation of this sensor data within a patient's EHR.

[0096] The disclosed systems for integrating sensor data with electronic health records (EHR) include hubs that receive and process sensor data from one or more sensors (e.g., analyte sensors). These sensors are configured to capture various types of sensor data (e.g., lactate levels, glucose levels, oxygen levels, body temperature, etc.). All of the referenced sensor data can also be broadly referred to herein as patient data. In some cases, the sensor may be configured to capture the sensor / patient data at a predetermined frequency. This frequency could be set based on the specific requirements of the patient's condition or the type of data being captured. For example, a CGM or CLM may capture data every few seconds, every minute or every few minutes, or at any other suitable frequency.

[0097] In some embodiments, the sensor is activated upon application to a patient and begins broadcasting a BLUETOOTH signal or other short-range wireless signal (e.g., NFC). This activation process is a variation of the operational parameters of the sensors. The activation could be triggered by a physical action, such as pressing a button on the sensor, or it could be triggered automatically when the sensor is applied to the patient's body.

[0098] The sensor may also be preconfigured to transmit a signal with sensor data at a predetermined frequency, e.g., every few milliseconds, every few seconds, etc. A practitioner who applies the sensor may also be able to configure the sensor to transmit data at the desired frequency or interval. Once activated, the sensor begins broadcasting a BLUETOOTH signal that contains the captured patient data. The BLUETOOTH or other signal broadcast by the sensor can be picked up by the hub, allowing the patient data to be transmitted from the sensor to the hub and then on to the cloud server and the EHR system.

[0099] In some instances, the hub is not previously paired with the sensor, but detects the sensor signal and automatically initiates communications with the sensor (e.g., BLUETOOTH pairing communications) to pair the sensor with the hub. The hub may also provide instructions to the sensor when to transmit sensor data and the frequency or interval to transmit the sensor data. In other instances, the hub only maintains selected / filtered subsets of the sensor data that is transmitted from the sensor.

[0100] The hub is configured to receive the patient data from the sensor via a BLUETOOTH connection, an NFC channel, or some other short-range wireless protocol. In some cases, the hub may be configured to process the patient data before transmitting the patient data to the cloud server through a Wi-Fi or other long-range wireless protocol. This processing could include filtering the patient data based on predetermined criteria. For example, the hub could be configured to filter out data points that are outside a predetermined range, or to filter out data points that are likely to be erroneous based on a comparison with previous data points. Before, during or after filtering, the hub may also generate alerts or alarms associated with sensor data that is outside of a predetermined range and / or that is associated with an error, as will be discussed in more details below.

[0101] Notably, the filtering processes can help to ensure that the data transmitted to the cloud server and ultimately to the EHR system is accurate and reliable. The processing may also include normalizing the data to a temporal frequency that corresponds to the temporal frequency of other sensor data and / or that matches a predetermined reporting schema. This may also include associating a patient ID, by way of sensor ID, with the different sensor data. In some instances, the hub may also attach a hub ID to the sensor data. The processing could also include bundling the patient data for transmission at a predetermined frequency. For example, the hub could be configured to bundle data points captured over a 5-minute period into a single data packet for transmission to the cloud server.

[0102] The disclosed methods for integrating sensor data with electronic health records (EHR) include capturing initial patient data (also referred to herein as sensor data) using a sensor, transmitting the patient / sensor data from the sensor to a hub via a BLUETOOTH connection, transmitting the patient data from the hub to a cloud server, and transmitting the patient data from the cloud server to an EHR system. The sensor is preferably pre-associated with a patient record in the EHR system based on a sensor serial number and / or a hub identification number.

[0103] As described herein, the hub is an interface between the sensor and a server (e.g., an on-premises server or a cloud server) where the EHR resides. The hub is configured to receive and to transmit the patient data from the sensors (received via a BLUETOOTH connectionor other short-range wireless protocol) over a long-range protocol to a cloud server or onpremises server system. The hub may also process the sensor data with one or more processes, thereby modifying or reformatting the sensor data, prior to transmitting the data. These processes may include at least the hub correlating the sensor data with the patient ID. Additionally, or alternatively, the hub processing may correlate the sensor data with the hub ID, which is particularly beneficial if the patient ends up taking the hub home with them when they leave the inpatient facility. In some embodiments, the hub functions as a pass-through, receiving raw sensor data (e.g., including sensor serial number) and transferring it to a cloud server or onpremises server. The server, in turn, may modify / format the sensor data, may tie a sensor serial number to a patient identifier (e.g., MRN), etc.

[0104] The processing at the hub can also include bundling the patient data for transmission at a predetermined frequency. In particular, rather than transmitting each data point individually as soon as it is captured, the hub can also be configured to collect a set of data points over a specific period of time and then transmit them all together as a single data packet. This can help to reduce the amount of data traffic and potentially improve the efficiency of the data transmission process.

[0105] The hub is also configured, in some instances, to trigger an alert based on the sensor data. For instance, if the sensor data indicates a sudden change in the patient's condition, such as a rapid increase in glucose levels or lactate levels, the hub could trigger an alert to notify healthcare providers. This alert could be transmitted to the healthcare system along with the patient data, or it could be sent separately to a designated recipient, such as a nurse's station, a healthcare provider's mobile device, or a remote service (e.g., remote monitoring service, virtual care service). This feature can provide an additional layer of patient monitoring and can help to ensure timely intervention when a patient's condition changes.

[0106] The remote cloud server and / or the more localized practitioner system receives the sensor data from the hub and adds it to an appropriate EHR corresponding to the patient based on the patient identifier and / or sensor ID and / or hub ID that is included with the sensor data packets and that was previously associated with the patient. In embodiments, when data goes from sensor to hub to cloud, it becomes available to integrate into an EHR system. In embodiments, once sent from the cloud to the EHR system, the EHR system maps that data into the correct patient's record (e.g., using an MRN or similar).

[0107] In some cases, the sensor data is transmitted directly from the sensor to the cloud, optionally via the hub or by another reader, bypassing any particular patient app. This direct transmission can help to reduce the amount of data traffic and potentially improve theefficiency of the data transmission process. It also eliminates the potential for errors or delays that could occur if the data had to pass through an additional intermediary device, such as a patient app or reader. This direct transmission can help to ensure that the data arrives at the EHR system as quickly as possible, which can be particularly beneficial in situations where timely access to the data is of the essence. It also ensures that, if the patient has moved out of range of their patient app or reader, their data is transferred directly from the sensor into the cloud. It also eliminates the potential for errors or delays that could occur if the data had to pass through an additional intermediary device. The data may also pass through one or more linked devices, still bypassing any patient app, as also described previously.

[0108] In other instances, the hub transmits the sensor data directly to a local practitioner application server, rather than to a remote server in the cloud, wherein the transmission to the local practitioner or application server enables the local practitioner server to add the sensor data to a patient's EHR and / or to transmit the sensor data to another remote server to correlate the patient's sensor data with their EHR.

[0109] These variations on the process of transmitting the sensor data to the cloud server and the EHR system can provide additional flexibility and efficiency in the system, making it more adaptable to a variety of different use cases and scenarios.

[0110] In some cases, the sensor data is associated with the patient record in the EHR system based on the sensor serial number and / or the hub identification number. This association process is a variation on the method of associating the sensor with a patient record in the EHR system. The sensor serial number or the hub identification number serves as a link between the sensor data and the patient record, ensuring that the data is correctly attributed to the right patient. This association process can be carried out manually by a healthcare provider, or it could be automated using software instantiated at the hub and / or another device interfacing with the hub (e.g., a practitioner device having a portal for linking a hub to a particular patient).

[0111] Some specific examples will now be provided with regard to the illustrations shown in Figures 6-13.

[0112] As shown in Figure 6, a patient 100 (or at least the patient ID) is initially associated with a sensor ID (e.g., sensor serial number) at a hub 110 in an inpatient facility with one or more provider system record(s) 125 that are transmitted to and stored by the hub 110 and / or provider system(s) 120. This may occur, for example, during or after the initial processing of a patient to a room within the inpatient facility, for example, and may include the scanning of a bar code, QR code or another identifier on the sensor and an identifier associated with the user (e.g., a code on the patient chart, on an identifier wrist tag or other identifier). Alternatively, thismay also be a manual process when the practitioner enters a practitioner portal to enter the correlating information of the sensor serial number (ID) and the patient identifier (ID). The patient ID may include a name, Medical Record Number, birthdate and / or other identifier of the patient.

[0113] In some instances, the hub ID can also be associated with the patient by a practitioner at the hub, such as by entering or scanning the patient information with a device that links the hub ID to the patient information. This correlation can also be included in the provider system record(s) 125.

[0114] The provider system record(s) 125 may be transmitted to a server 130 that is located within the facility and / or a remote location, and which may also comprise one or more third-party system(s) 140. The server 130 and / or third-party system(s) 140 include reference tables that associate the patient with one or more sensor(s) via the sensor ID and / or a particular hub 110 via the hub ID. They may also correlate this information within a patient EHR 150 stored by and / or accessed by the server and / or third-party systems, as shown in Figure 7.

[0115] Thereafter, when the server and / or third-party systems (130 / 140) receive data (e.g., sensor data) that includes the patient ID (e.g., Medical Record Number), sensor ID and / or a hub ID they can correlate and add the corresponding sensor data to the patient's EHR 150 that is identified based on the patient ID, sensor ID and / or hub ID.

[0116] As shown in Figures 7 and 8, the hub 110 may communicate with the server 130 and / or provider system(s) 120 through a wireless protocol, such as Wi-Fi or another long-range wireless protocol.

[0117] The hub 110 may also communicate with the various sensor(s) connected to the patient 100 (e.g., sensor A, sensor B, sensor C) through BLUETOOTH, NFC or another short-range wireless protocol. In some instances, sensors A, B, C and other sensors connected to the patient may include a CGM, a CLM, a pulsometer, an oximeter, a thermometer, and other analyte and bioinformatic sensors.

[0118] In some instances, the sensors, as soon as being activated by a practitioner, will begin to gather sensor readings from the patient and begin broadcasting those sensor readings and / or a pairing request. In some cases, the broadcasting occurs prior to and / or without the hub 110 initiating pairing with the sensor(s). When the hub (configured with BLUETOOTH, NFC and or other short-range antenna and communication transceiver components) detects the sensor readings (and / or the pairing request) being broadcast over one or more channels that the hub 110 is configured to monitor, the hub 110 will initiate a pairing procedure with the sensor(s). This may include the hub 110 transmitting identifier information to the sensors with a request that the sensors transmit sensor data according to selected communication protocols (e.g., totransmit over certain BLUETOOTH channel(s) that may be different than the initial channel(s) that the sensors were broadcasting over).

[0119] Once paired, the hub 110 will gather the sensor data (also referred to herein as patient data) that is subsequently broadcast by the sensors. This sensor data may optionally include the sensor ID and / or the patient ID that the hub provided to the sensors.

[0120] Once the hub 110 receives the sensor data, the hub 110 may transmit the sensor data (as received) directly to the server 130, provider system 120 and / or third-party system 140 according to specified rules and procedures.

[0121] In some embodiments, a single hub 110 may be associated with and / or utilized with sensor data from multiple different patient(s). This is shown in Figure 7, for example, how a single hub 110 may be linked to two or more patients. Each of these patients may be connected with one more sensors (e.g., sensors A, B, C of Figure 8). In such instances, the hub will link the different sensor data of the different sensors to the appropriate patient or patient ID based on the initial provider system records 125 and reference tables that link the different sensors to the different patients. This may require the hub to process the sensor data in such a way as to distinguish sensor data from one patient from the sensor data from another patient. This processing may include, for instance, batching the different sensor data from different sensors and / or patients into different transmissions that are sent separately to the provider system(s) 120 and / or remote server and third-party system(s).

[0122] Accordingly, it will be appreciated that the hub 110 will process the sensor data in one more ways prior to transmitting the sensor data as modified sensor data 165 (see Figure 9). The sensor data may be formatted, for example, by normalizing the sensor data according to a preferred reporting schema, temporal reporting frequency, adding a patient ID and / or hub ID and / or sensor ID, by filtering out one more data entries that appear erroneous or duplicative or that exceed a desired reporting frequency (e.g., keeping only one entry for every predetermined few seconds or minutes), and / or that are filtered according to different rules.

[0123] The processing of the sensor data may also include classifying the data according to perceived risk level and / or type of sensor. In some instances, the processing of the sensor data includes encrypting the sensor data with a cryptographic key corresponding to a key known by the server 130 and / or third-party system(s) 140 and that can be used to decrypt the encrypted sensor data.

[0124] Once the sensor data is processed, it is transmitted at a predetermined interval and frequency as packets of processed sensor data. Notably, this processed sensor data (which may comprise original sensor data 160 and / or modified sensor data 165) will at least includeand / or be transmitted with the patient ID, sensor ID and / or hub ID which can individually and / or collectively be used by the server 130 to identify the corresponding patient based on the previously received provider system record(s) 125 (Figure 6).

[0125] The packets of processed sensor data may be batched, in some instances, based on sensor type and / or temporal reporting interval. So, all sensor readings that are processed by a single sensor over a predetermined interval may be batched into a single sensor data packet. In other instances, sensor data from multiple sensors gathered over the predetermined interval are batched together, albeit classified separately according to the different sensors they correspond to.

[0126] Once the server 130 receives the packets of processed sensor data, the server 130 will identify the corresponding EHR of a patient corresponding to the sensor data, based on the previously received provider system record(s) 125.

[0127] Then, the server 130 will selectively add relevant sensor data to the EHR according to rules and procedures applied to the server 130 and EHR.

[0128] In some instances, the hub is also configured to identify patterns in the sensor data. The patterns may include, for instance, broadcasting channel used by the sensor to transmit the sensor data, broadcasting frequency or interval, ranges of sensor data, formatting of sensor data, etc. The hub may identify the patterns of sensor data being transmitted by different sensors, wherein each sensor may be associated with a different pattern.

[0129] Then, when the hub identifies any anomalies or interruptions in the sensor data patterns that exceed predetermined thresholds, the hub can generate an alert. By way of example, if the hub misses receiving a predetermined quantity of sensor readings over a predetermined period of time, after establishing a routine interval for receiving the sensor readings from a sensor, the hub may generate an alert or alarm 170 that is transmitted to the server 130 and / or provider system 120 and / or third-party system 150. This alert 170 may be used to notify a practitioner that the sensor needs to be adjusted, reapplied, replaced and / or that there is a more serious problem that needs to be attended to for the patient being monitored (e.g., a lactate or glucose level exceeds a predetermined threshold established by the practitioner and that was communicated to the hub during the initial processes of associating the hub with the practitioner, such as can be communicated through a provider or hub portal connected to the hub).

[0130] The alert 170 may also be generated by the hub 110 in response to receiving an error message generated by the sensor.

[0131] The alert 170 may also be generated by the hub 110 in response to apredetermined interval of time passing, such as to notify the provider that it is time to replace a sensor.

[0132] The alerts 170 may also be based on detecting a correlation of events associated with the different sensor data received from different sensors (e.g., a drop in glucose reported by a CGM, at the same time as a rise in body temperature from a temperature sensor, at the same time as a rise in a pulse from a pulsometer) that may correspond to a predetermined medical condition.

[0133] The alerts 170 are preferably linked with the patient ID, sensor ID and / or hub ID to be used to identify corresponding and correlating EHRs for the relevant patients so that the alert information and corresponding sensor data may be added to the EHRs for subsequent medical evaluation.

[0134] In some instances, as shown in Figure 11, the patient 100 may also utilize one more reader devices 180 to scan sensor data, with or without a patient app, and which can be used to transmit the sensor data to the EHR cloud system to be correlated with the EHR of the patient, along with the sensor data obtained from the hub, as described.

[0135] This is possible, for example, by transmitting an electronic record of a patient ID with the sensor ID and / or reader device ID associated with the sensor to the EHR cloud system (e.g., server 110 and / or provider system 120). This may occur in the inpatient facility during the initial scanning and application of the sensor to the patient and / or (subsequently, within an inpatient or outpatient environment) by using a patient app or provider system portal presented to the patient when applying or replacing the sensor.

[0136] Then, regardless of whether the sensor data is obtained from the reader device (e.g., sensor D data packets 190) and / or from the hub (e.g., processed sensor data 160), the server 110 will be able to correlate the sensor data with the appropriate EHRs. Notably, this is true, regardless of whether the processed sensor data 160 is only directly linked with the patient ID, the sensor ID and / or hub ID as it is received from the hub 110.

[0137] Attention is now directed to Figure 12 which illustrates a flow chart 1200 of acts associated with methods implemented by a hub (such as hub 110) for processing and transmitting processed sensor data from one or more medical sensors in a manner that facilitates correlating sensor data from the one or more medical sensors with a patient based on at least a patient ID, a sensor ID and / or hub ID.

[0138] Preferably, the hub comprises a processor system (e.g., one or more hardware processors) and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from oneor more analyte sensors. The hub associates sensor data that it receives with a particular patient via an electronic record that was previously created and / or transmitted to a remote system (e.g., a provider or server system) that correlates a sensor ID of the sensor (e.g., sensor serial number) and / or a hub ID (e.g., serial number) with an identifier of the particular patient and that can be used to access a EHR of the patient based on the patient ID, for example.

[0139] As shown, the acts implemented by the hub include detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the sensor / patient data packets including sensor data obtained by the analyte sensors (act 1210). The sensors may, for example, be configured to generate sensor data characterizing one or more of glucose, ketones, lactate, or hemoglobin A1C. The sensors may also characterize other bioinformatic information such as blood oxygen level, pulse, temperature.

[0140] The acts also include generating processed patient or sensor data packets that include at least a portion of the sensor data associated with the patient ID (act 1220) via a sensor ID, a hub ID and / or the patient ID and transmitting the processed sensor / patient data packets to a remote system over a long-range communication channel, such as Wi-Fi (act 1240).

[0141] The acts may also include automatically pairing the hub with the one or more analyte sensors in response to detecting the data packets being broadcast (act 1240), as the one or more analyte sensors may not be paired with the hub prior to the hub detecting the data packets. The hub also receives different data packets from a plurality of analyte sensors over the one or a plurality of short-range communication channels (e.g., BLUETOOTH, NFC channels).

[0142] In some instances, the processed patient data packets include a filtered subset of the sensor data, and wherein the method further includes filtering the sensor data prior to or during generation of the processed patient data packets.

[0143] The hub may also encrypt the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a key possessed by the remote system, the key usable by the remote system to decrypt the portion of the sensor data or by encrypting at least a portion of the sensor data with a first key cryptographically bound to a second key possessed by the remote system, the second key usable by the remote system to decrypt the portion of the sensor data. This may be particularly important when the hub is used for multiple patients. In such scenarios, the hub may encrypt different sensor data from different patients with different encryption keys.

[0144] The hub may also batch the sensor data packets into the processed patient data packets and transmit the processed data packets at a transmission interval that is less frequent than a transmission interval in which the hub receives the data packets from the one or moreanalyte sensors. The frequency of transmission may be the same or different when the hub is transmitting data to different server systems.

[0145] The hub may also detect a pattern associated with the sensor data act 1250) and detect an interruption in the pattern that exceeds a predetermined interruption threshold which, when detected, causes the hub to generate an alert (act 1260) that can be transmitted to the server system and / or a medical provider system.

[0146] As part of processing the sensor data, the hub may selectively refrain from transmitting at least a portion of the sensor data, such as duplicate data and / or data that is determined to be erroneous by the hub and / or as a result of filtering the sensor data to a subset of the sensor data.

[0147] The hub preferably makes sure the sensor data being transmitted already is associated with a patient ID and / or adds the hub ID to the data packets that are transmitted with the sensor data. The hub may also identify and include a sensor ID corresponding with the sensor that transmitted the sensor data and / or the hub ID. Alternatively, the hub may omit the sensor ID from the processed patient data packets to reduce the size of the data packet and to improve the transmission efficiency of the data packets.

[0148] Methods of the invention also include methods recited from the server, practitioner and / or third-party systems that obtain the sensor data from the hub and that correlate the sensor data with a patient and patient EHR. This may also include modifying the EHR to include the sensor data that is determined to be correlated with a patient, the correlation being based on a hub ID and / or sensor ID.

[0149] Figure 13, for example, illustrates a flow chart 1300 of acts associated with methods implemented by a computing system for receiving and correlating sensor data with a patient, the sensor data being received from multiple sources, including a hub, such as the hub described in reference to Figure 12, and / or at least one additional device that is located at a different location than the hub.

[0150] These acts include identifying an electronic record that correlates a hub identifier with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR) (act 1310), receiving a processed patient data packet including a sensor identifier and / or hub identifier and analyte sensor data from a first source (act 1320), adding the analyte sensor data to the stored electronic health record in response to determining the sensor identifier and / or hub identifier correlates with the patient identifier of the first user that is associated with the EHR (act 1330), receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particularpatient identifier that was not included in the processed patient data packet (act 1340), and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR (act 1350).

[0151] Some embodiments include a dedicated reader device that receives sensor data from a sensor unit, such as sensor unit 101 or sensor unit 201. Depending on the design and configuration, reader devices may have various functions and capabilities. For example, some reader devices may convey the sensor data to a cloud service (e.g., cloud service 109) over a network, such as a cellular, Wi-Fi, or mesh network, allowing the sensor data to be stored and accessed remotely by authorized users and systems. Some reader devices may communicate the sensor data to a personal device (e.g., personal device 108), such as a smartphone, tablet, or laptop, via a wireless connection, such as BLUETOOTH. This may allow users to view and manage the sensor data using their devices. Some reader devices may present the sensor data locally at a display of the reader device. This may allow users to monitor their analyte levels without needing any other device or network connection.

[0152] One challenge of obtaining sensor data from a dedicated reader device is that the reader device may lack access to a reliable network connection in some locations, such as at a doctor's office. This may prevent the reader device from sending the sensor data to a server or a cloud service. Another challenge of obtaining sensor data from a dedicated reader device is establishing communications channels with the dedicated reader device, whether connecting another device (e.g., smartphone) to the dedicated reader device or connecting the dedicated reader device to a network, such as Wi-Fi. For instance, establishing communications channels with the dedicated reader device can confuse users, and technical incompatibilities (e.g., Wi-Fi communications and encryption protocols) can complicate the process.

[0153] Embodiments simplify communicating sensor data from a dedicated reader device to another electronic device, such as a user's or a medical professional's device, via an ad- hoc communication mode. When entering this ad-hoc communications mode, the reader device sets up a local network infrastructure that enables another electronic device to form an ad-hoc network connection with the reader device. The reader device then communicates connection information to the other electronic device, which enables the other electronic device to automatically connect to the reader device via the network infrastructure established by the reader device.

[0154] In some examples, the reader device encodes this connection information in an optical data carrier, such as a quick response (QR) code or a barcode. In other examples, thereader device communicates this connection information via a wireless data carrier, such as NFC. After the other electronic device uses this information to connect to the reader device's ad-hoc network, the reader device utilizes an embedded web server to serve sensor data to the other electronic device. This may be via one or more web pages displayed in a web browser on the other electronic device and / or via an API that is called from an application (e.g., web app, native app) running on the personal device. This ad-hoc communication mode enables users to access the sensor data stored on reader devices without relying on any external network connection or entering any connection information.

[0155] In some embodiments, as described in more detail below with regard to Figures 14—17, methods and systems are also provided for providing an ad-hoc communication mode of a dedicated medical sensor reader device. Figure 14 illustrates an example 1400 of a system in which a reader device communicates sensor data to a personal device using an ad-hoc communication mode. The system of example 1400 includes a sensor unit 1401 capable of gathering sensor data and communicating that data to another electronic device. Sensor unit 1401 is shown as including a sensor device 1402. In various examples, like sensor device 102 and sensor device 202, sensor device 1402 is an analyte sensor such as glucose, ketones, lactate, oxygen, or hemoglobin A1C; a temperature sensor; a blood flux sensor, a blood viscosity sensor, a blood pressure sensor, a heart rate sensor, a blood oxygen level sensor, and the like. Sensor unit 1401 also includes sensor control electronics 1404 that include communication hardware 1405 and that store (e.g., in volatile memory and / or non-volatile memory) data 1406 comprising sensor readings generated by sensor device 1402. Using communication hardware 1405, sensor unit 1401 communicates data 1406 to a reader device 1407. In embodiments, reader device 1407 is a dedicated reader device specialized for reading sensor data from one or more sensor units, including sensor unit 1401. The reader device 1407 includes communication hardware 1413 (e.g., Wi-Fi hardware 1414, NFC hardware 1415, BLUETOOTH hardware 1416, and the like). In embodiments, reader device 1407 uses communication hardware 1413 to receive sensor data (data 1406) from sensor unit 1401. This received sensor data is shown at reader device 1407 as sensor data 1409 (e.g., stored in volatile memory and / or non-volatile memory at reader device 1407).

[0156] Reader device 1407 is configured to use an ad-hoc communication mode to further communicate the sensor data 1409 to a personal device 1421, such as a smartphone, tablet, laptop, etc. To facilitate this ad-hoc communication mode, the reader device 1407 configures its communication hardware 1413 to create a local network infrastructure that enables personal device 1421 to establish an ad-hoc (i.e., direct peer-to-peer) networkconnection with the reader device 1407. In one example, reader device 1407 configures Wi-Fi hardware 1414 to provide a Wi-Fi access point to which personal device 1421 can connect using its communication hardware 1423. In another example, reader device 1407 configures its BLUETOOTH hardware 1416 to operate in a personal area network (PAN) mode. In some examples, reader device 1407 includes a wired serial bus, such as a USB or a THUNDERBOLT bus, and reader device 1407 establishes a serial bus network interface configuration that enables the serial bus to operate in an IP networking mode. In any of these examples, configuring a local network infrastructure can include configuring additional networking components, such as an IP routing table, a Domain Name Service (DNS) server 1419, a Dynamic Host Configuration Protocol (DHCP) server 1420, and the like.

[0157] In embodiments, the reader device 1407 includes one or more network servers 1417, a web application 1410, and a connection information component 1408. Network servers 1417 can include a variety of network servers / services, such as a web server 1418, a DNS server 1419, a DHCP server 1420, and the like. In embodiments, the web server 1418 operates to serve a web application 1410 to personal device 1421, using a set of APIs 1411 (e.g., one or more APIs) and / or a set of web pages 1412 (e.g., one or more web pages). In embodiments, the DNS server 1419 operates to provide domain-name-to-IP-address translations to the personal device 1421, such as to direct a web browser 1422 or other web application at the personal device 1421 to an IP address associated with the web server 1418. In embodiments, the DHCP server 1420 offers an IP address and network routing information to the personal device 1421 when it establishes a network connection to the reader device 1407 using its communication hardware 1423.

[0158] In embodiments, the web application 1410 provides an interface to personal device 1421 for accessing sensor data 1409 after personal device 1421 has established an ad-hoc network connection with reader device 1407. In some embodiments, web application 1410 incorporates sensor data 1409 into web pages 1412 and serves those web pages as static web pages to personal device 1421, which then displays them in web browser 1422. In other embodiments, web pages 1412 dynamically incorporate sensor data 1409 via calls to APIs 1411. In some implementations, calls to APIs 1411 are made locally (e.g., web pages 1412 call APIs 1411 locally within reader device 1407). In other implementations, API calls are made remotely (e.g., web pages 1412 call APIs 1411 remotely from personal device 1421 to the reader device 1407). In some implementations, rather than using a web browser 1422, personal device 1421 includes a dedicated reader software application, and that software application obtains sensor data 1409 via calls to APIs 1411.

[0159] In embodiments, the connection information component 1408 operates toprovide information to personal device 1421 that enables the personal device to initiate an ad- hoc connection with the reader device 1407. The information may include Wi-Fi network details (e.g., SSI D, password), an IP address for the personal device 1421 to adopt once connected, a URI for the personal device 1421 to navigate to reach web application 1410, etc. The connection information component 1408 may communicate the information to the personal device 1421 using optical or wireless mechanisms. For example, the connection information component 1408 may display a QR code or a barcode on a screen of the reader device 1407, which the personal device 1421 can scan using a camera. Alternatively, the connection information component 1408 may use NFC to transmit the information to the personal device 1421 when the devices are nearby (e.g., using NFC tag emulation).

[0160] In embodiments, when consumed by personal device 1421, the information provided by the connection information component 1408 causes the personal device 1421 to automatically form an ad-hoc network connection with the reader device 1407. In embodiments, once the ad-hoc network connection is established, the personal device 1421 also automatically interfaces with the web application 1410. For example, a QR code or an NFC tag could include an SSID, a password, and a URI. When the personal device 1421 scans the QR code or the NFC tag, the personal device 1421 uses the SSID and password to automatically connect to a wireless AP provided by the Wi-Fi hardware 1414 and to navigate to the URI in the web browser 1422 to interface with the web application 1410.

[0161] Figure 15A illustrates an example 1500a of a reader device 1501a that presents a QR code and a personal device 1502a that uses the QR code to establish an ad-hoc network connection and to access sensor data from reader device 1501a. The reader device 1501a includes a connection information component 1408 that generates and displays a QR code on the screen of the reader device 1501a. The QR code contains information such as Wi-Fi network details, an IP address, a URI for a web application 1410 hosted by the reader device 1501a, etc. The personal device 1502a scans the QR code using a camera and then uses the information to automatically connect to the Wi-Fi network provided by the reader device 1501a and to navigate to the URI in a web browser 1422. The web browser 1422 then displays web pages 1412 that incorporate sensor data 1409 received by the reader device 1501a from a sensor unit 1401.

[0162] Figure 15B shows an example 1500b of how a reader device 1501b and a personal device 1502b can use NFC to set up a temporary network connection and to access sensor data from the reader device 1501b. The reader device 1501b has a connection information component 1408 that acts like an NFC tag (e.g., using NFC tag emulation) to send information to the personal device 1502b when it comes close to the reader device 1501b. This information includes, e.g.,Wi-Fi network details, an IP address, a URI for the web application run by the reader device 1501b, and the like. The personal device 1502b reads the NFC tag using NFC hardware (e.g., its communication hardware 1423) and then uses the information to automatically join a Wi-Fi network provided by the reader device 1501b and to go to the URI in a web browser. The web browser then shows web pages that use sensor data from the reader device 1501b.

[0163] As mentioned, in some examples, a reader device may convey the sensor data to a cloud service (e.g., cloud service 109) over a network, such as a cellular, Wi-Fi, or mesh network. In some embodiments, a reader device utilizes a low-power wireless mesh network, such as one that utilizes the THREAD protocol defined by the THREAD GROUP. Figure 16 shows an example 1600 with a local network 1608 (e.g., in a home or business), including a LAN-to-WAN router 1605 (e.g., a Wi-Fi router and access point). The router 1605 connects to one or more THREAD border routers 1602 (e.g., border router 1602a and border router 1602b, shown as rectangles), which in turn communicate with a mesh network of THREAD routers 1603 (e.g., router 1603a, router 1603b, and router 1603c, shown as pentagons). The routers 1603, in turn, connect to THREAD hosts 1604 (e.g., host 1604a, host 1604b, host 1604c, and host 1604d, shown as circles). In example 1600, the reader device 1407 is one of the THREAD hosts (e.g., host 1604c, shown in bold), and it uses the THREAD mesh network to obtain a publicly routable IP address (e.g., an IPv6 address) that enables it to communicate with cloud service 1607. For example, host 1604c communicates via the THREAD network (e.g., routers 1603 and border routers 1602) to router 1605 and the internet 1606 to reach the cloud service 1607 and communicate sensor data 1409. The arrangement of example 1600 is for illustrative purposes only, and a THREAD mesh network can have various members and topologies. Additionally, while the reader device 1407 is shown in example 1600 as being a THREAD host (i.e., host 1604c), reader device 1407 could embody any of the elements of a THREAD network (e.g., border routers 1602, routers 1603, or hosts 1604). In embodiments, the reader device 1407 encrypts data before transmitting it over a THREAD network, ensuring data privacy, integrity, and security. In embodiments, as a device that participates in a THREAD network, one reader device may receive encrypted sensor data from another and route that encrypted sensor data towards the cloud service 1607.

[0164] In addition to, or as an alternative to, connecting to a low-power wireless mesh network, such as THREAD, in some embodiments, the reader device 1407 includes a cellular modem (e.g., 2G, 3G, 4G, LTE, 5G), and the reader device 1407 uses that cellular modem to communicate with a personal device (e.g., personal device 1421) and / or with a cloud service (e.g., cloud service 109 or cloud service 1607). In some embodiments, the reader device 1407 functions as a thread router (e.g., router 1605) to facilitate the communication of data between cloudservice 1607 and other thread devices, including other reader devices.

[0165] Attention is now directed to Figure 17, which illustrates a flow chart of method 1700 implemented by a medical sensor reader device (such as reader device 1407) to facilitate ad-hoc communications with a personal device.

[0166] Referring to Figure 17, in some embodiments, method 1700 comprises act 1701 of detecting a request to enable ad-hoc communications. In embodiments, act 1701 comprises receiving a user request at the reader device to enable an ad-hoc communications mode. For example, in some implementations, the reader device 1407 only enables ad-hoc communications based on a user request, such as by pressing a physical button on the reader device 1407 or interacting with a graphical user interface on the reader device 1407. Only enabling ad-hoc communications when the user requests it improves battery life by reducing power usage by reader device 1407. For example, when the reader device 1407 is not in the ad-hoc communications mode, it may be able to reduce power consumption by Wi-Fi hardware 1414 (e.g., because it is not hosting a Wi-Fi access point) and by shutting down one or more of web application 1410, web server 1418, DNS server 1419, and DHCP server 1420. Additionally, only enabling ad-hoc communications when the user requests it improves security by only enabling personal devices to connect to reader device 1407 when its user requests it.

[0167] Method 1700 also comprises act 1702 of enabling an ad-hoc sensor data communication mode. In embodiments, act 1702 comprises configuring various components to support ad-hoc communications and data transfer, such as starting an embedded web server, establishing a local self-configured network, and publishing the connection information.

[0168] In some embodiments, act 1702 includes act 1703 of starting an embedded web server. In embodiments, act 1703 comprises starting an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device. For example, reader device 1407 initiates web server 1418, which is configured to serve web application 1410 to provide access to sensor data 1409. In embodiments, reader device 1407 obtains the sensor data from sensor unit 1401. Examples of sensor data include analyte sensor data (e.g., measurements of one or more of glucose, ketone, lactate, oxygen, or hemoglobin A1C), temperature sensor data, blood flux sensor data, blood viscosity sensor data, blood pressure sensor data, heart rate sensor data, oxygen level sensor data, etc. In embodiments, analyte sensor data is a continuous measurement of analyte date, e.g., a plurality of data points obtained over a period of time.

[0169] In some embodiments, act 1702 also includes act 1704 of establishing a local network infrastructure. In embodiments, act 1704 comprises establishing a local self-configurednetwork that enables establishing one or more ad-hoc network connections with the medical sensor reader device. For example, reader device 1407 configures communication hardware 1413 and one or more network servers 1417 to enable reader device 1407 to form an ad-hoc network connection with another electronic device. In some embodiments, establishing the local selfconfigured network comprises establishing an ad-hoc Wi-Fi access point (e.g., Wi-Fi hardware 1414). In some embodiments, establishing the local self-configured network comprises establishing an embedded DHCP service (e.g., 1420). In some embodiments, establishing the local self-configured network comprises establishing an embedded DNS (e.g., 1419). In some embodiments, establishing the local self-configured network comprises establishing a BLUETOOTH PAN configuration (e.g., IP networking over BLUETOOTH). In some embodiments, establishing the local self-configured network comprises establishing a serial bus network interface configuration (e.g., IP networking over USB or THUNDERBOLT).

[0170] As shown, in some embodiments, act 1702 also includes act 1704 of publishing connection information. In embodiments, act 1705 comprises publishing connection information to one or more electronic devices, the connection information including one or more parameters enabling one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network. For example, reader device 1407 displays an optical code at a display device, emulates an NFC tag using NFC hardware 1415, etc., to enable personal device 1421 to receive connection information over optical or wireless means. In one example, the parameters comprise a Wi-Fi SSID and a Wi-Fi password, and establishing the ad-hoc network connection with an electronic device via the self-configured network includes receiving a Wi-Fi association request from the electronic device that uses one or more of the WiFi SSID or the Wi-Fi password.

[0171] In some implementations, publishing the connection information to the electronic device comprises displaying an optical data carrier that encodes the connection information. In one example, the optical data carrier comprises a QR code that encodes the connection information. In other implementations, publishing the connection information to the electronic device comprises provisioning an NFC tag (e.g., via NFC tag emulation) to communicate the connection information when scanned.

[0172] No express ordering is required between acts 1703, 1704, and 1705. Thus, in various implementations, they may be performed serially (in any order) or at least partially in parallel.

[0173] Method 1700 also comprises act 1706 of establishing an ad-hoc network connection. In embodiments, act 1706 comprises establishing an ad-hoc network connectionwith an electronic device via the self-configured network based on publishing the connection information. For example, as shown in Figures 15A-15B, personal device 1421 obtains the connection information published in act 1705, and it uses that information to initiate an ad-hoc network connection with reader device 1407.

[0174] Method 1700 also comprises act 1707 of communicating medical sensor data via the ad-hoc network. In embodiments, act 1707 communicates the analyte data to the electronic device via the ad-hoc network connection. For example, personal device 1421 interacts with web application 1410, e.g., using web browser 1422 or a dedicated application to consume sensor data 1409. In some embodiments, communicating the analyte data to the electronic device via the ad-hoc network connection comprises serving one or more web pages (e.g., web pages 1412) to the electronic device using the embedded web server. In additional or alternative embodiments, communicating the analyte data to the electronic device via the ad-hoc network connection comprises processing an API request (e.g., APIs 1411) received by the embedded web server from the electronic device.

[0175] In some embodiments, the reader device 1407 uses the ad-hoc network connection for additional, or even alternative, purposes than communicating analyte data to the personal device 1421. In some examples, the reader device 1407 uses the ad-hoc network connection to facilitate establishing a connection to a network, such as a Wi-Fi network or a cellular network. For example, after establishing the ad-hoc network connection between the reader device 1407 and the personal device 1421, the personal device 1421 can communicate Wi-Fi connection parameters (e.g., SSID, Wi-Fi password) to the reader device 1407. For instance, the personal device 1421 communicates Wi-Fi connection parameters that the personal device 1421 uses to connect to a home or office Wi-Fi network, enabling the reader device 1407 to form a network connection with that home or office Wi-Fi network directly. In another example, after establishing the ad-hoc network connection between the reader device 1407 and the personal device 1421, the personal device 1421 can provision the reader device 1407 on a cellular network, such as by configuring an electronic Subscriber Identity Module (eSIM) on the reader device 1407. In other examples, the reader device 1407 uses the ad-hoc network connection to register with, associate with, and / or communicate with a cloud service, such as a cloud service 109. In one example, the reader device 1407 uses the ad-hoc network connection to communicate an identifier of the reader device 1407 to the cloud service 109, enabling the cloud service 109 to associate the reader device 1407 with a user account. In another example, the reader device 1407 uses the ad-hoc network connection to communicate analyte data directly to the cloud service 109. In yet another example, the reader device 1407 uses the ad-hoc network connection toreceive an encryption key from the cloud service 109, which the reader device 1407 uses to encrypt analyte data prior to sending the analyte data to another device (e.g., personal device 1421, a device on a THREAD network, or cloud service 109).

[0176] As mentioned in connection with act 1701, in some instances, the reader device 1407 only enables ad-hoc communications based on a user request, such as by pressing a physical button on the reader device 1407 or interacting with a graphical user interface on the reader device 1407. In embodiments, a user expressly disables this ad-hoc communications mode when they are done interacting with the reader device 1407 using the personal device 1421. In other embodiments, the reader device 1407 automatically disables the ad-hoc communications mode after a certain amount of time has elapsed. This may be an amount of time since the ad-hoc communications mode was enabled, an amount of time since the last data request (e.g., API call) from the personal device 1421, an amount of time since the personal device 1421 disconnected from the reader device 1407, or some combination thereof. Thus, in some embodiments, method 1700 also comprises act 1708 of detecting a timeout condition and act 1709 of disabling the ad- hoc sensor data communication mode. In some examples, method 1700 further comprises, based on a threshold amount of time having elapsed, performing one or more of stopping the embedded web server, tearing down the local self-configured network, or ceasing publishing the connection information.

[0177] As discussed in connection with Figure 16, in some embodiments, reader device 1407 communicates sensor data to a cloud service 1607 using a low-power mesh network, such as a THREAD network. In these embodiments, method 1700 further comprises establishing a THREAD network configuration and communicating the analyte data to a cloud service using a THREAD mesh network. In some embodiments, method 1700 further comprises receiving encrypted data from another electric device via a THREAD mesh network and communicating the encrypted data towards a cloud service using the THREAD mesh network.

[0178] In view of the foregoing description, it will be appreciated that the present invention can also be described in accordance with the following numbered clauses:

[0179] Clause 1. A method implemented in a first device comprising a sensor unit and an analyte sensor device, comprising: identifying a portion of sensor data associated with a user, the portion of the sensor data having been collected by the analyte sensor device of the first device; identifying a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service; determining, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and sending the portion of the sensor data to the seconddevice.

[0180] Clause 2. The method of clause 1, wherein the portion of the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

[0181] Clause 3. The method of clause 1, wherein the portion of the sensor data characterizes one of glucose, ketones, lactate, creatinine, alcohol, or oxygen.

[0182] Clause 4. The method of clause 1, wherein the method further comprises encrypting the portion of the sensor data prior to sending the portion of the sensor data to the second device.

[0183] Clause 5. The method of clause 4, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a key possessed by the cloud service, the key usable by the cloud service to decrypt the portion of the sensor data.

[0184] Clause 6. The method of clause 4, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a first key cryptographically bound to a second key possessed by the cloud service, the second key usable by the cloud service to decrypt the portion of the sensor data.

[0185] Clause 7. The method of clause 1, wherein sending the portion of the sensor data to the second device comprises establishing a wireless connection with the second device.

[0186] Clause 8. The method of clause 1, wherein sending the portion of the sensor data to the second device utilizes a short-range wireless technology.

[0187] Clause 9. The method of clause 8, wherein the short-range wireless technology comprises BLUETOOTH, BLUETOOTH low energy, Near Field Communication, Radio Frequency Identification, or ultra-wideband.

[0188] Clause 10. The method of clause 1, wherein the portion of the sensor data is a first portion of sensor data, and wherein the method further comprises sending a second portion of sensor data to a personal device.

[0189] Clause 11. The method of clause 1, wherein the one or more additional factors include one or more of how recently the sensor unit has communicated with an associated personal device; a type of the second device; how recently the sensor unit has communicated with the cloud service; a measured signal strength of the second device; a measured availability of power; an amount of the sensor data; or whether a patient account is associated with a caregiver.

[0190] Clause 12. The method of clause 1, wherein the sensor unit and the second device are each associated with the user.

[0191] Clause 13. The method of clause 12, wherein the sensor unit is a first sensor unit,and the second device is a second sensor unit.

[0192] Clause 14. The method of clause 12, wherein the second device is a personal device.

[0193] Clause 15. The method of clause 1, wherein the second device is an insulin pump or an insulin pen.

[0194] Clause 16. The method of clause 1, wherein the sensor unit is associated with the user, and the second device is associated with a different user.

[0195] Clause 17. The method of clause 15, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

[0196] Clause 18. The method of clause 15, wherein the second device is a personal device.

[0197] Clause 19. The method of clause 1, wherein the sensor unit characterizes a hemoglobin A1C level.

[0198] Clause 20. A computing system for opportunistically communicating sensor data from a medical sensor to a cloud system, the system comprising: (1) a first device comprising an on-body unit configured to be worn on a user's body, the on-body unit comprising: a glucose sensor, comprising: a proximal portion coupled with sensor electronics, wherein the proximal portion is configured to be positioned above a skin surface of the user; and a distal portion configured to be positioned under the skin surface of the user and to detect a glucose level in an interstitial fluid of the user; sensor electronics, comprising: a power supply; processing circuitry coupled with memory; wireless communication circuitry configured to transmit sensor data according to a wireless communication protocol; and a hardware storage system comprising stored instructions that are executable by the processing circuitry to cause the sensor electronics to: identify a portion of sensor data associated with a user, the portion of the sensor data having been collected by the glucose sensor; identify a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service; determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and send the portion of the sensor data to the second device; and (2) the second device, comprising: a processor system; and a hardware storage system comprising stored instructions that are executable by the processor system to cause the second device to relay the sensor data towards the cloud service.

[0199] Clause 21. A sensor unit, comprising: an analyte sensor device; and sensor control electronics that include: a wireless communication hardware; and wireless communication logic that causes the sensor unit to at least: identify a portion of sensor dataassociated with a user, the portion of the sensor data having been collected by the analyte sensor device; identify a wireless presence of a second device using the wireless communication hardware, the second device configured for relaying the sensor data towards a cloud service; determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and send the portion of the sensor data to the second device via the wireless communication hardware.

[0200] Clause 22. The sensor unit of clause 21, wherein the portion of the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

[0201] Clause 23. The sensor unit of clause 21, wherein the portion of the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

[0202] Clause 24. The sensor unit of clause 21, wherein the wireless communication logic also causes the sensor unit to encrypt the portion of the sensor data prior to sending the portion of the sensor data to the second device.

[0203] Clause 25. The sensor unit of clause 24, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a key possessed by the cloud service, the key usable by the cloud service to decrypt the portion of the sensor data.

[0204] Clause 26. The sensor unit of clause 24, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a first key cryptographically bound to a second key possessed by the cloud service, the second key usable by the cloud service to decrypt the portion of the sensor data.

[0205] Clause 27. The sensor unit of clause 21, wherein sending the portion of the sensor data to the second device comprises establishing a wireless connection with the second device.

[0206] Clause 28. The sensor unit of clause 21, wherein sending the portion of the sensor data to the second device utilizes a short-range wireless technology.

[0207] Clause 29. The sensor unit of clause 28, wherein the short-range wireless technology comprises BLUETOOTH, BLUETOOTH low energy, Near Field Communication, Radio Frequency Identification, or ultra-wideband.

[0208] Clause 30. The sensor unit of clause 21, wherein the portion of the sensor data is a first portion of sensor data, and wherein the wireless communication logic also causes the sensor unit to send a second portion of sensor data to a personal device.

[0209] Clause 31. The sensor unit of clause 21, wherein the one or more additional factors include one or more of how recently the sensor unit has communicated with an associated personal device; a type of the second device; how recently the sensor unit has communicated with the cloud service; a measured signal strength of the second device; a measured availabilityof power; an amount of the sensor data; or whether a patient account is associated with a caregiver.

[0210] Clause 32. The sensor unit of clause 21, wherein the sensor unit and the second device are each associated with the user.

[0211] Clause 33. The sensor unit of clause 32, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

[0212] Clause 34. The sensor unit of clause 32, wherein the second device is a personal device.

[0213] Clause 35. The sensor unit of clause 21, wherein the second device is an insulin pump or an insulin pen.

[0214] Clause 36. The sensor unit of clause 21, wherein the sensor unit is associated with the user, and the second device is associated with a different user.

[0215] Clause 37. The sensor unit of clause 36, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

[0216] Clause 38. The sensor unit of clause 36, wherein the second device is a personal device.

[0217] Clause 39. The sensor unit of clause 21, wherein the sensor unit characterizes a hemoglobin A1C level.

[0218] Clause 40. A method, implemented at a cloud service computer system, comprising: receiving a network request from a first remote device, the network request comprising a uniform resource identifier (URI) that includes a unique identifier of a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

[0219] Clause 41. The method of clause 40, wherein the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

[0220] Clause 42. The method of clause 40, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

[0221] Clause 43. The method of clause 40, wherein the method further comprises creating the profile based on the user credential.

[0222] Clause 44. The method of clause 40, wherein the user credential includes an email address.

[0223] Clause 45. The method of clause 40, wherein the unique identifier of the sensor unit is a parameter within the URL

[0224] Clause 46. The method of clause 40, wherein the unique identifier of the sensor unit is a serial number of the sensor unit.

[0225] Clause 47. The method of clause 40, wherein the URI also includes information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

[0226] Clause 48. The method of clause 40, wherein the method further comprises sending, to the first remote device, information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

[0227] Clause 49. The method of clause 48, wherein the method further comprises obtaining the information enabling the web application to initiate the wireless connection to the sensor unit at the first remote device from a database based on the unique identifier of the sensor unit.

[0228] Clause 50. The method of clause 40, wherein the second remote device is the first remote device.

[0229] Clause 51. The method of clause 40, wherein the second remote device is different from the first remote device.

[0230] Clause 52. The method of clause 51, wherein the second remote device is the sensor unit.

[0231] Clause 53. A cloud service computer system, comprising: a processor; and a non- transitory computer-readable media storing computer-executable instructions that are executable by the processor to perform operations, comprising: receiving a network request from a first remote device, the network request comprising a uniform resource identifier (URI) that includes a unique identifier of a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

[0232] Clause 54. The cloud service computer system of clause 53, wherein the sensordata is collected based on contact of the analyte sensor device with a bodily fluid of the user.

[0233] Clause 55. The cloud service computer system of clause 53, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

[0234] Clause 56. The cloud service computer system of clause 53, wherein the operations further comprise creating the profile based on the user credential.

[0235] Clause 57. The cloud service computer system of clause 53, wherein the user credential includes an email address.

[0236] Clause 58. The cloud service computer system of clause 53, wherein the unique identifier of the sensor unit is a parameter within the URL

[0237] Clause 59. The cloud service computer system of clause 53, wherein the unique identifier of the sensor unit is a serial number of the sensor unit.

[0238] Clause 60. The cloud service computer system of clause 53, wherein the URI also includes information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

[0239] Clause 61. The cloud service computer system of clause 53, wherein the operations further comprise sending, to the first remote device, information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

[0240] Clause 62. The cloud service computer system of clause 61, wherein the operations further comprise obtaining the information enabling the web application to initiate the wireless connection to the sensor unit at the first remote device from a database based on the unique identifier of the sensor unit.

[0241] Clause 63. The cloud service computer system of clause 53, wherein the second remote device is the first remote device.

[0242] Clause 64. The cloud service computer system of clause 53 wherein the second remote device is different from the first remote device.

[0243] Clause 65. The cloud service computer system of clause 64, wherein the second remote device is the sensor unit.

[0244] Clause 66. A method implemented in a hub comprising a processor system and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from one or more analyte sensors, the sensor and / or hub being associated with a particular patient via an electronic record that was transmitted to a remote system that correlates a sensor ID of the sensor and / or a hub ID of the hub with an identifier of the particular patient, the method comprising: the hub detecting data packets being broadcast over one or more short-range communication channelsfrom one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID and / or hub ID; and the hub transmitting the processed patient data packets to a remote system over a long-range communication channel.

[0245] Clause 67. The method of clause 66, wherein the method further includes automatically pairing the hub with the one or more analyte sensors in response to detecting the data packets being broadcast.

[0246] Clause 68. The method of clause 66, wherein the method further includes receiving different data packets from a plurality of analyte sensors over the one or more short- range communication channels.

[0247] Clause 69. The method of clause 66, wherein the method further includes receiving different data packets from a plurality of analyte sensors over a plurality of different short-range communication channels.

[0248] Clause 70. The method of clause 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

[0249] Clause 71. The method of clause 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over one or more BLUETOOTH channels and one or more NFC channels.

[0250] Clause 72. The method of clause 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

[0251] Clause 73. The method of clause 66, wherein the one or more analyte sensors are not paired with the hub prior to the hub detecting the data packets.

[0252] Clause 74. The method of clause 66, wherein the long-range communication channel comprises a Wi-Fi connection.

[0253] Clause 75. The method of clause 66, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

[0254] Clause 76. The method of clause 66, wherein the processed patient data packets include a filtered subset of the sensor data, and wherein the method further includes filtering the sensor data prior to or during generation of the processed patient data packets.

[0255] Clause 77. The method of clause 66, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patientdata packets by at least encrypting at least a portion of the sensor data with a key possessed by the remote system, the key usable by the remote system to decrypt the portion of the sensor data.

[0256] Clause 78. The method of clause 66, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a first key cryptographically bound to a second key possessed by the remote system, the second key usable by the remote system to decrypt the portion of the sensor data.

[0257] Clause 79. The method of clause 66, wherein the method further includes batching the sensor data packets into the processed patient data packets and transmitting the processed data packets and at a transmission interval that is less frequent than a transmission interval in which the hub receives the data packets from the one or more analyte sensors.

[0258] Clause 80. The method of clause 66, wherein the method further includes detecting a pattern associated with the sensor data.

[0259] Clause 81. The method of clause 80, wherein the method further includes detecting an interruption in the pattern that exceeds a predetermined interruption threshold.

[0260] Clause 82. The method of clause 81, wherein the method further includes generating an alert in response to detecting the interruption.

[0261] Clause 83. The method of clause 82, wherein the method further includes transmitting the alert to a medical provider system.

[0262] Clause 84. The method of clause 66, wherein the method includes refraining from transmitting at least a portion of the sensor data when transmitting the processed patient data packets.

[0263] Clause 85. The method of clause 84, wherein the method further includes identifying a sensor ID with the sensor data and omitting the sensor ID from the processed patient data packets.

[0264] Clause 86. The method of clause 66, wherein the method further includes identifying a sensor ID with the sensor data and including the sensor ID in the processed patient data packets.

[0265] Clause 87. A hub comprising: a processor system; and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from one or more analyte sensors, the sensor and / or hub being associated with a particular patient via an electronic record that was transmitted to a remote system that correlates a sensor ID of the sensor and / or a hub ID of thehub with an identifier of the particular patient, the method comprising: the hub detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID and / or hub ID; and the hub transmitting the processed patient data packets to a remote system over a long-range communication channel.

[0266] Clause 88. The hub of clause 87, wherein the method further includes automatically pairing the hub with the one or more analyte sensors in response to detecting the data packets being broadcast.

[0267] Clause 89. The hub of clause 87, wherein the method further includes receiving different data packets from a plurality of analyte sensors over the one or more short-range communication channels.

[0268] Clause 90. The hub of clause 87, wherein the method further includes receiving different data packets from a plurality of analyte sensors over a plurality of different short-range communication channels.

[0269] Clause 91. The hub of clause 90, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

[0270] Clause 92. The hub of clause 91, wherein the method further includes receiving different data packets from a plurality of analyte sensors over one or more BLUETOOTH channels and one or more NFC channels.

[0271] Clause 93. The hub of clause 90, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

[0272] Clause 94. The hub of clause 92, wherein the one or more analyte sensors are not paired with the hub prior to the hub detecting the data packets.

[0273] Clause 95. The hub of clause 87, wherein the long-range communication channel comprises a Wi-Fi connection.

[0274] Clause 96. The hub of clause 87, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

[0275] Clause 97. The hub of clause 87, wherein the processed patient data packets include a filtered subset of the sensor data, and wherein the method further includes filtering the sensor data prior to or during generation of the processed patient data packets.

[0276] Clause 98. The hub of clause 87, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient datapackets by at least encrypting at least a portion of the sensor data with a key possessed by the remote system, the key usable by the remote system to decrypt the portion of the sensor data.

[0277] Clause 99. The hub of clause 87, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a first key cryptographically bound to a second key possessed by the remote system, the second key usable by the remote system to decrypt the portion of the sensor data.

[0278] Clause 100. The hub of clause 87, wherein the method further includes batching the sensor data packets into the processed patient data packets and transmitting the processed data packets and at a transmission interval that is less frequent than a transmission frequency in which the hub receives the data packets from the one or more analyte sensors.

[0279] Clause 101. The hub of clause 87, wherein the method further includes detecting a pattern associated with the sensor data.

[0280] Clause 102. The hub of clause 101, wherein the method further includes detecting an interruption in the pattern that exceeds a predetermined interruption threshold.

[0281] Clause 103. The hub of clause 102, wherein the method further includes generating an alert in response to detecting the interruption.

[0282] Clause 104. The hub of clause 103, wherein the method further includes transmitting the alert to a medical provider system.

[0283] Clause 105. The hub of clause 87, wherein the method includes refraining from transmitting at least a portion of the sensor data when transmitting the processed patient data packets.

[0284] Clause 106. The hub of clause 105, wherein the method further includes identifying a sensor ID with the sensor data and omitting the sensor ID from the processed patient data packets.

[0285] Clause 107. The hub of clause 87, wherein the method further includes identifying a sensor ID with the sensor data and including the sensor ID in the processed patient data packets.

[0286] Clause 108. A method for correlating records comprising different identifiers received from different sources, the method comprising: identifying an electronic record that correlates a sensor identifier and / or hub ID with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet comprising at least one of the patient identifier, the sensor identifier or the hub identifier, as well as analyte sensor data from a first source; adding theanalyte sensor data to the stored electronic health record in response to determining the patient identifier of the first user that is associated with the EHR correlates with said patient identifier, sensor identifier or hub identifier; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

[0287] Clause 109. A computing system comprising: a processor system; and stored executable instructions that are executable by the processor system to implement a method for correlating records comprising different identifiers received from different sources, the method comprising: identifying an electronic record that correlates a sensor identifier and / or hub ID with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet comprising at least one of the patient identifier, the sensor identifier or the hub identifier, as well as analyte sensor data from a first source; adding the analyte sensor data to the stored electronic health record in response to determining the patient identifier of the first user that is associated with the EHR correlates with said patient identifier, sensor identifier or hub identifier; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

[0288] Clause 110. A method, implemented in a medical sensor reader device, comprising: starting an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establishing a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publishing connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establishing an ad-hoc network connection with an electronic device via the self-configured network; and communicating the analyte data to the electronic device via the ad-hoc network connection.

[0289] Clause 111. The method of clause 110, wherein the method further comprisesobtaining the analyte data from the medical sensor device.

[0290] Clause 112. The method of clause 111, wherein publishing the connection information to the electronic device comprises displaying an optical data carrier that encodes the connection information.

[0291] Clause 113. The method of clause 112, wherein the optical data carrier encodes one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSI D), or a Wi-Fi password.

[0292] Clause 114. The method of clause 112, wherein the optical data carrier comprises quick response code that encodes the connection information.

[0293] Clause 115. The method of clause 110, wherein publishing the connection information to the electronic device comprises provisioning a near field communication tag to communicate the connection information, when scanned.

[0294] Clause 116. The method of clause 115, wherein the near field communication tag communicates one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password, when scanned.

[0295] Clause 117. The method of clause 110, wherein establishing the local selfconfigured network comprises establishing an ad-hoc wireless fidelity (Wi-Fi) access point.

[0296] Clause 118. The method of clause 117, wherein the one or more parameters comprise one or more of a Wi-Fi service set identifier (SSID) or a Wi-Fi password.

[0297] Clause 119. The method of clause 118, wherein establishing the ad-hoc network connection with an electronic device via the self-configured network includes receiving a Wi-Fi association request from the electronic device that uses one or more of the Wi-Fi SSID or the WiFi password.

[0298] Clause 120. The method of clause 110, wherein establishing the local selfconfigured network comprises establishing an embedded dynamic host configuration protocol (DHCP) service.

[0299] Clause 121. The method of clause 110, wherein establishing the local selfconfigured network comprises establishing an embedded domain name service (DNS).

[0300] Clause 122. The method of clause 110, wherein establishing the local selfconfigured network comprises establishing a serial bus network interface configuration.

[0301] Clause 123. The method of clause 110, wherein establishing the local selfconfigured network comprises establishing a BLUETOOTH personal area network (PAN) configuration.

[0302] Clause 124. The method of clause 110, wherein communicating the analyte datato the electronic device via the ad-hoc network connection comprises serving one or more web pages to the electronic device using the embedded web server.

[0303] Clause 125. The method of clause 110, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises processing an application programming interface (API) request received from the electronic device using the embedded web server.

[0304] Clause 126. The method of clause 110, wherein the method further comprises establishing a THREAD network configuration.

[0305] Clause 127. The method of clause 126, wherein the method further comprises communicating the analyte data towards a cloud service using a THREAD mesh network.

[0306] Clause 128. The method of clause 126, wherein the method further comprises: receiving encrypted data from another electric device via a THREAD mesh network; and communicating the encrypted data towards a cloud service using the THREAD mesh network.

[0307] Clause 129. The method of clause 110, wherein one or more of i) starting the embedded web server, ii) establishing the local self-configured network, or iii) publishing the connection information is triggered by a user request received at the medical sensor reader device.

[0308] Clause 130. The method of clause 129, wherein the method further comprises, based on a threshold amount of time having elapsed, performing one or more of: stopping the embedded web server, tearing down the local self-configured network, or ceasing publishing the connection information.

[0309] Clause 131. The method of clause 110, wherein the analyte data comprises a plurality of data points over a period of time.

[0310] Clause 132. The method of clause 110, wherein the method further comprises: receiving a network connection parameter via the ad-hoc network connection; and using the network connection parameter to form a network connection.

[0311] Clause 133. The method of clause 110, wherein the method further comprises communicating with a cloud service via the ad-hoc network connection.

[0312] Clause 134. The method of clause 110, wherein the method further comprises establishing a cellular network connection via a cellular modem.

[0313] Clause 135. A medical sensor reader device comprising one or more processors and a computer-readable storage medium comprising computer-executable instructions that cause the medical sensor reader device to at least: identify a request to initiate an ad-hoc communications mode; and based on the request: start an embedded web server at the medicalsensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the selfconfigured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the self-configured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

[0314] Clause 136. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to obtain the analyte data from the medical sensor device.

[0315] Clause 137. The medical sensor reader device of clause 135, wherein publishing the connection information to the electronic device comprises displaying an optical data carrier that encodes the connection information.

[0316] Clause 138. The medical sensor reader device of clause 137, wherein the optical data carrier encodes one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password.

[0317] Clause 139. The medical sensor reader device of clause 137, wherein the optical data carrier comprises quick response code that encodes the connection information.

[0318] Clause 140. The medical sensor reader device of clause 135, wherein publishing the connection information to the electronic device comprises provisioning a near field communication tag to communicate the connection information, when scanned.

[0319] Clause 141. The medical sensor reader device of clause 140, wherein the near field communication tag communicates one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password, when scanned.

[0320] Clause 142. The medical sensor reader device of clause 135, wherein establishing the local self-configured network comprises establishing an ad-hoc wireless fidelity (Wi-Fi) access point.

[0321] Clause 143. The medical sensor reader device of clause 142, wherein the one or more parameters comprise one or more of a Wi-Fi service set identifier (SSID) or a Wi-Fi password.

[0322] Clause 144. The medical sensor reader device of clause 143, wherein establishing the ad-hoc network connection with the electronic device via the self-configured networkincludes receiving a Wi-Fi association request from the electronic device that uses one or more of the Wi-Fi SSID or the Wi-Fi password.

[0323] Clause 145. The medical sensor reader device of clause 135, wherein establishing the local self-configured network comprises establishing an embedded dynamic host configuration protocol (DHCP) service.

[0324] Clause 146. The medical sensor reader device of clause 135, wherein establishing the local self-configured network comprises establishing an embedded domain name service (DNS).

[0325] Clause 147. The medical sensor reader device of clause 135, wherein establishing the local self-configured network comprises establishing a serial bus network interface configuration.

[0326] Clause 148. The medical sensor reader device of clause 135, wherein establishing the local self-configured network comprises establishing a BLUETOOTH personal area network (PAN) configuration.

[0327] Clause 149. The medical sensor reader device of clause 135, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises serving one or more web pages to the electronic device using the embedded web server.

[0328] Clause 150. The medical sensor reader device of clause 135, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises processing an application programming interface (API) request received from the electronic device using the embedded web server.

[0329] Clause 151. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to establish a THREAD network configuration.

[0330] Clause 152. The medical sensor reader device of clause 151, wherein the computer-executable instructions also cause the medical sensor reader device to communicate the analyte data towards a cloud service using a THREAD mesh network.

[0331] Clause 153. The medical sensor reader device of clause 152, wherein the computer-executable instructions also cause the medical sensor reader device to: receive encrypted data from another electric device via a THREAD mesh network; and communicate the encrypted data towards a cloud service using the THREAD mesh network.

[0332] Clause 154. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to, based on athreshold amount of time having elapsed, perform one or more of: stopping the embedded web server, tearing down the local self-configured network, or ceasing publishing the connection information.

[0333] Clause 155. The medical sensor reader device of clause 135, wherein the analyte data comprises a plurality of data points over a period of time.

[0334] Clause 156. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to: receive a network connection parameter via the ad-hoc network connection; and use the network connection parameter to form a network connection.

[0335] Clause 157. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to communicate with a cloud service via the ad-hoc network connection.

[0336] Clause 158. The medical sensor reader device of clause 135, wherein the computer-executable instructions also cause the medical sensor reader device to establish a cellular network connection via a cellular modem.

[0337] Clause 159. A computer-readable storage medium comprising computerexecutable instructions that cause a medical sensor reader device to at least: start an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the self-configured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

[0338] Embodiments of the disclosure comprise or utilize a special-purpose or general- purpose computer system that includes computer hardware, such as, for example, a processor system and system memory, as discussed in greater detail below. Embodiments within the scope of the present disclosure also include physical and other computer-readable media for carrying or storing computer-executable instructions and / or data structures. Such computer-readable media can be any available media accessible by a general-purpose or special-purpose computer system. Computer-readable media that store computer-executable instructions and / or data structures are computer storage media. Computer-readable media that carry computer-executable instructions and / or data structures are transmission media. Thus, embodiments of the disclosure can comprise at least two distinctly different kinds of computer-readable media: computer storage media and transmission media.

[0339] Computer storage media are physical storage media that store computerexecutable instructions and / or data structures. Physical storage media include computer hardware, such as random access memory (RAM), read-only memory (ROM), electrically erasable programmable ROM (EEPROM), solid state drives (SSDs), flash memory, phase-change memory (PCM), optical disk storage, magnetic disk storage or other magnetic storage devices, or any other hardware storage device(s) which store program code in the form of computer-executable instructions or data structures, which can be accessed and executed by a general-purpose or special-purpose computer system to implement the disclosed functionality.

[0340] Transmission media include a network and / or data links that carry program code in the form of computer-executable instructions or data structures that are accessible by a general-purpose or special-purpose computer system. A "network" is defined as a data link that enables the transport of electronic data between computer systems and other electronic devices. When information is transferred or provided over a network or another communications connection (either hardwired, wireless, or a combination thereof) to a computer system, the computer system may view the connection as transmission media. The scope of computer- readable media includes combinations thereof.

[0341] Upon reaching various computer system components, program code in the form of computer-executable instructions or data structures can be transferred automatically from transmission media to computer storage media (or vice versa). For example, computerexecutable instructions or data structures received over a network or data link can be buffered in RAM within a network interface module and eventually transferred to computer system RAM and / or less volatile computer storage media at a computer system. Thus, computer storage media can be included in computer system components that also utilize transmission media.

[0342] Computer-executable instructions comprise, for example, instructions and data which when executed at a processor system, cause a general-purpose computer system, a special-purpose computer system, or a special-purpose processing device to perform a function or group of functions. In embodiments, computer-executable instructions comprise binaries, intermediate format instructions (e.g., assembly language), or source code. In embodiments, a processor system comprises one or more central processing units (CPUs), one or more graphics processing units (GPUs), one or more neural processing units (NPUs), and the like.

[0343] In some embodiments, the disclosed systems and methods are practiced innetwork computing environments with many types of computer system configurations, including personal computers, desktop computers, laptop computers, message processors, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, mobile telephones, PDAs, tablets, pagers, routers, switches, and the like. In some embodiments, the disclosed systems and methods are practiced in distributed system environments where different computer systems, which are linked through a network (e.g., by hardwired data links, wireless data links, or by a combination of hardwired and wireless data links), both perform tasks. As such, in a distributed system environment, a computer system may include a plurality of constituent computer systems. Program modules may be located in local and remote memory storage devices in a distributed system environment.

[0344] In some embodiments, the disclosed systems and methods are practiced in a cloud computing environment. In some embodiments, cloud computing environments are distributed, although this is not required. When distributed, cloud computing environments may be distributed internally within an organization and / or have components possessed across multiple organizations. In this description and the following claims, "cloud computing" is a model for enabling on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services). A cloud computing model can be composed of various characteristics, such as on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud computing model may also come in the form of various service models such as Software as a Service (SaaS), Platform as a Service (PaaS), Infrastructure as a Service (laaS), etc. The cloud computing model may also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, etc.

[0345] Although the subject matter has been described in language specific to structural features and / or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the described features or acts described supra or the order of the acts described supra. Rather, the described features and acts are disclosed as example forms of implementing the claims.

[0346] The present disclosure may be embodied in other specific forms without departing from its essential characteristics. The described embodiments are only illustrative and not restrictive. All changes which come within the meaning and range of equivalency of the claims are to be embraced within their scope.

[0347] When introducing elements in the appended claims, the articles "a," "an," "the,"and "said" are intended to mean there are one or more of the elements. The terms "comprising / ' "including / ' and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements. Unless otherwise specified, the terms "set," "superset," and "subset" are intended to exclude an empty set, and thus "set" is defined as a non-empty set, "superset" is defined as a non-empty superset, and "subset" is defined as a non-empty subset.Unless otherwise specified, the term "subset" excludes the entirety of its superset (i.e., the superset contains at least one item not included in the subset). Unless otherwise specified, a "superset" can include at least one additional element, and a "subset" can exclude at least one element.

Claims

CLAIMSWhat is claimed:

1. A method implemented in a first device comprising a sensor unit and an analyte sensor device, comprising: identifying a portion of sensor data associated with a user, the portion of the sensor data having been collected by the analyte sensor device of the first device; identifying a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service; determining, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and sending the portion of the sensor data to the second device.

2. The method of claim 1, wherein the portion of the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

3. The method of claim 1, wherein the portion of the sensor data characterizes one of glucose, ketones, lactate, creatinine, alcohol, or oxygen.

4. The method of claim 1, wherein the method further comprises encrypting the portion of the sensor data prior to sending the portion of the sensor data to the second device.

5. The method of claim 4, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a key possessed by the cloud service, the key usable by the cloud service to decrypt the portion of the sensor data.

6. The method of claim 4, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a first key cryptographically bound to a second key possessed by the cloud service, the second key usable by the cloud service to decrypt the portion of the sensor data.

7. The method of claim 1, wherein sending the portion of the sensor data to the second device comprises establishing a wireless connection with the second device.

8. The method of claim 1, wherein sending the portion of the sensor data to the second device utilizes a short-range wireless technology.

9. The method of claim 8, wherein the short-range wireless technology comprises BLUETOOTH, BLUETOOTH low energy, Near Field Communication, Radio Frequency Identification, or ultra-wideband.

10. The method of claim 1, wherein the portion of the sensor data is a first portion of sensor data, and wherein the method further comprises sending a second portion of sensordata to a personal device.

11. The method of claim 1, wherein the one or more additional factors include one or more of how recently the sensor unit has communicated with an associated personal device; a type of the second device; how recently the sensor unit has communicated with the cloud service; a measured signal strength of the second device; a measured availability of power; an amount of the sensor data; or whether a patient account is associated with a caregiver.

12. The method of claim 1, wherein the sensor unit and the second device are each associated with the user.

13. The method of claim 12, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

14. The method of claim 12, wherein the second device is a personal device.

15. The method of claim 1, wherein the second device is an insulin pump or an insulin pen.

16. The method of claim 1, wherein the sensor unit is associated with the user, and the second device is associated with a different user.

17. The method of claim 15, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

18. The method of claim 15, wherein the second device is a personal device.

19. The method of claim 1, wherein the sensor unit characterizes a hemoglobin A1C level.

20. A computing system for opportunistically communicating sensor data from a medical sensor to a cloud system, the system comprising:(1) a first device comprising an on-body unit configured to be worn on a user's body, the on-body unit comprising: a glucose sensor, comprising: a proximal portion coupled with sensor electronics, wherein the proximal portion is configured to be positioned above a skin surface of the user; and a distal portion configured to be positioned under the skin surface of the user and to detect a glucose level in an interstitial fluid of the user; sensor electronics, comprising: a power supply; processing circuitry coupled with memory; wireless communication circuitry configured to transmit sensor dataaccording to a wireless communication protocol; and a hardware storage system comprising stored instructions that are executable by the processing circuitry to cause the sensor electronics to: identify a portion of sensor data associated with a user, the portion of the sensor data having been collected by the glucose sensor; identify a wireless presence of a second device, the second device configured for relaying the sensor data towards a cloud service; determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and send the portion of the sensor data to the second device; and(2) the second device, comprising: a processor system; and a hardware storage system comprising stored instructions that are executable by the processor system to cause the second device to relay the sensor data towards the cloud service.

21. A sensor unit, comprising: an analyte sensor device; and sensor control electronics that include: a wireless communication hardware; and wireless communication logic that causes the sensor unit to at least: identify a portion of sensor data associated with a user, the portion of the sensor data having been collected by the analyte sensor device; identify a wireless presence of a second device using the wireless communication hardware, the second device configured for relaying the sensor data towards a cloud service; determine, based on the wireless presence of the second device, and based on one or more additional factors, to communicate the portion of the sensor data to the second device; and send the portion of the sensor data to the second device via the wireless communication hardware.

22. The sensor unit of claim 21, wherein the portion of the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

23. The sensor unit of claim 21, wherein the portion of the sensor data characterizesone of glucose, ketones, lactate, or oxygen.

24. The sensor unit of claim 21, wherein the wireless communication logic also causes the sensor unit to encrypt the portion of the sensor data prior to sending the portion of the sensor data to the second device.

25. The sensor unit of claim 24, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a key possessed by the cloud service, the key usable by the cloud service to decrypt the portion of the sensor data.

26. The sensor unit of claim 24, wherein encrypting the portion of the sensor data comprises encrypting the portion of the sensor data with a first key cryptographically bound to a second key possessed by the cloud service, the second key usable by the cloud service to decrypt the portion of the sensor data.

27. The sensor unit of claim 21, wherein sending the portion of the sensor data to the second device comprises establishing a wireless connection with the second device.

28. The sensor unit of claim 21, wherein sending the portion of the sensor data to the second device utilizes a short-range wireless technology.

29. The sensor unit of claim 28, wherein the short-range wireless technology comprises BLUETOOTH, BLUETOOTH low energy, Near Field Communication, Radio Frequency Identification, or ultra-wideband.

30. The sensor unit of claim 21, wherein the portion of the sensor data is a first portion of sensor data, and wherein the wireless communication logic also causes the sensor unit to send a second portion of sensor data to a personal device.

31. The sensor unit of claim 21, wherein the one or more additional factors include one or more of how recently the sensor unit has communicated with an associated personal device; a type of the second device; how recently the sensor unit has communicated with the cloud service; a measured signal strength of the second device; a measured availability of power; an amount of the sensor data; or whether a patient account is associated with a caregiver.

32. The sensor unit of claim 21, wherein the sensor unit and the second device are each associated with the user.

33. The sensor unit of claim 32, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

34. The sensor unit of claim 32, wherein the second device is a personal device.

35. The sensor unit of claim 21, wherein the second device is an insulin pump or an insulin pen.

36. The sensor unit of claim 21, wherein the sensor unit is associated with the user,and the second device is associated with a different user.

37. The sensor unit of claim 36, wherein the sensor unit is a first sensor unit, and the second device is a second sensor unit.

38. The sensor unit of claim 36, wherein the second device is a personal device.

39. The sensor unit of claim 21, wherein the sensor unit characterizes a hemoglobin A1C level.

40. A method, implemented at a cloud service computer system, comprising: receiving a network request from a first remote device, the network request comprising a uniform resource identifier (URI) that includes a unique identifier of a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

41. The method of claim 40, wherein the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

42. The method of claim 40, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

43. The method of claim 40, wherein the method further comprises creating the profile based on the user credential.

44. The method of claim 40, wherein the user credential includes an email address.

45. The method of claim 40, wherein the unique identifier of the sensor unit is a parameter within the URI.

46. The method of claim 40, wherein the unique identifier of the sensor unit is a serial number of the sensor unit.

47. The method of claim 40, wherein the URI also includes information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

48. The method of claim 40, wherein the method further comprises sending, to the first remote device, information enabling the web application to initiate a wireless connection tothe sensor unit at the first remote device.

49. The method of claim 48, wherein the method further comprises obtaining the information enabling the web application to initiate the wireless connection to the sensor unit at the first remote device from a database based on the unique identifier of the sensor unit.

50. The method of claim 40, wherein the second remote device is the first remote device.

51. The method of claim 40, wherein the second remote device is different from the first remote device.

52. The method of claim 51, wherein the second remote device is the sensor unit.

53. A cloud service computer system, comprising: a processor; and a non-transitory computer-readable media storing computer-executable instructions that are executable by the processor to perform operations, comprising: receiving a network request from a first remote device, the network request comprising a uniform resource identifier (URI) that includes a unique identifierof a sensor unit; presenting a web application corresponding to the URI to the first remote device; receiving a user credential for a user of the sensor unit based on presenting the web application to the first remote device; associating the unique identifier for the sensor unit with a profile associated with the user credential; receiving sensor data from a second remote device, including receiving the unique identifier for the sensor unit, the sensor data having been collected by an analyte sensor device of the sensor unit; and associating the sensor data with the profile based on receiving the unique identifier for the sensor unit.

54. The cloud service computer system of claim 53, wherein the sensor data is collected based on contact of the analyte sensor device with a bodily fluid of the user.

55. The cloud service computer system of claim 53, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

56. The cloud service computer system of claim 53, wherein the operations further comprise creating the profile based on the user credential.

57. The cloud service computer system of claim 53, wherein the user credential includes an email address.

58. The cloud service computer system of claim 53, wherein the unique identifier of the sensor unit is a parameter within the URL59. The cloud service computer system of claim 53, wherein the unique identifier of the sensor unit is a serial number of the sensor unit.

60. The cloud service computer system of claim 53, wherein the URI also includes information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

61. The cloud service computer system of claim 53, wherein the operations further comprise sending, to the first remote device, information enabling the web application to initiate a wireless connection to the sensor unit at the first remote device.

62. The cloud service computer system of claim 61, wherein the operations further comprise obtaining the information enabling the web application to initiate the wireless connection to the sensor unit at the first remote device from a database based on the unique identifier of the sensor unit.

63. The cloud service computer system of claim 53, wherein the second remote device is the first remote device.

64. The cloud service computer system of claim 53 wherein the second remote device is different from the first remote device.

65. The cloud service computer system of claim 64, wherein the second remote device is the sensor unit.

66. A method implemented in a hub comprising a processor system and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from one or more analyte sensors, the sensor and / or hub being associated with a particular patient via an electronic record that was transmitted to a remote system that correlates a sensor ID of the sensor and / or a hub ID of the hub with an identifier of the particular patient, the method comprising: the hub detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID and / or hub ID; and the hub transmitting the processed patient data packets to a remote system over a long- range communication channel.

67. The method of claim 66, wherein the method further includes automatically pairing the hub with the one or more analyte sensors in response to detecting the data packets being broadcast.

68. The method of claim 66, wherein the method further includes receiving different data packets from a plurality of analyte sensors over the one or more short-range communication channels.

69. The method of claim 66, wherein the method further includes receiving different data packets from a plurality of analyte sensors over a plurality of different short-range communication channels.

70. The method of claim 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

71. The method of claim 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over one or more BLUETOOTH channels and one or more NFC channels.

72. The method of claim 69, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

73. The method of claim 66, wherein the one or more analyte sensors are not paired with the hub prior to the hub detecting the data packets.

74. The method of claim 66, wherein the long-range communication channel comprises a Wi-Fi connection.

75. The method of claim 66, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

76. The method of claim 66, wherein the processed patient data packets include a filtered subset of the sensor data, and wherein the method further includes filtering the sensor data prior to or during generation of the processed patient data packets.

77. The method of claim 66, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a key possessed by the remote system, the key usable by the remote system to decrypt the portion of the sensor data.

78. The method of claim 66, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a first key cryptographically bound to a second key possessed by the remote system, the second key usable by the remote system to decrypt the portion of the sensor data.

79. The method of claim 66, wherein the method further includes batching the sensor data packets into the processed patient data packets and transmitting the processed data packets and at a transmission interval that is less frequent than a transmission interval in which the hub receives the data packets from the one or more analyte sensors.

80. The method of claim 66, wherein the method further includes detecting a pattern associated with the sensor data.

81. The method of claim 80, wherein the method further includes detecting an interruption in the pattern that exceeds a predetermined interruption threshold.

82. The method of claim 81, wherein the method further includes generating an alert in response to detecting the interruption.

83. The method of claim 82, wherein the method further includes transmitting the alert to a medical provider system.

84. The method of claim 66, wherein the method includes refraining from transmitting at least a portion of the sensor data when transmitting the processed patient data packets.

85. The method of claim 84, wherein the method further includes identifying a sensor ID with the sensor data and omitting the sensor ID from the processed patient data packets.

86. The method of claim 66, wherein the method further includes identifying a sensor ID with the sensor data and including the sensor ID in the processed patient data packets.

87. A hub comprising: a processor system; and stored executable instructions that are executable by the processor system to implement a method for processing and communicating analyte sensor data received from one or more analyte sensors, the sensor and / or hub being associated with a particular patient via an electronic record that was transmitted to a remote system that correlates a sensor ID of the sensor and / or a hub ID of the hub with an identifier of the particular patient, the method comprising: the hub detecting data packets being broadcast over one or more short-range communication channels from one or more analyte sensors, the data packets including sensor data obtained by the analyte sensors; the hub generating processed patient data packets that include at least a portion of the sensor data received by the hub and associated with a particular patient through the sensor ID and / or hub ID; and the hub transmitting the processed patient data packets to a remote system overa long-range communication channel.

88. The hub of claim 87, wherein the method further includes automatically pairing the hub with the one or more analyte sensors in response to detecting the data packets being broadcast.

89. The hub of claim 87, wherein the method further includes receiving different data packets from a plurality of analyte sensors over the one or more short-range communication channels.

90. The hub of claim 87, wherein the method further includes receiving different data packets from a plurality of analyte sensors over a plurality of different short-range communication channels.

91. The hub of claim 90, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

92. The hub of claim 91, wherein the method further includes receiving different data packets from a plurality of analyte sensors over one or more BLUETOOTH channels and one or more NFC channels.

93. The hub of claim 90, wherein the method further includes receiving different data packets from a plurality of analyte sensors over different BLUETOOTH channels.

94. The hub of claim 92, wherein the one or more analyte sensors are not paired with the hub prior to the hub detecting the data packets.

95. The hub of claim 87, wherein the long-range communication channel comprises a Wi-Fi connection.

96. The hub of claim 87, wherein the sensor data characterizes one of glucose, ketones, lactate, or oxygen.

97. The hub of claim 87, wherein the processed patient data packets include a filtered subset of the sensor data, and wherein the method further includes filtering the sensor data prior to or during generation of the processed patient data packets.

98. The hub of claim 87, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a key possessed by the remote system, the key usable by the remote system to decrypt the portion of the sensor data.

99. The hub of claim 87, wherein the method further includes the hub encrypting the processed patient data packets prior to transmitting the processed patient data packets by at least encrypting at least a portion of the sensor data with a first key cryptographically bound to a second key possessed by the remote system, the second key usable by the remote system todecrypt the portion of the sensor data.

100. The hub of claim 87, wherein the method further includes batching the sensor data packets into the processed patient data packets and transmitting the processed data packets and at a transmission interval that is less frequent than a transmission frequency in which the hub receives the data packets from the one or more analyte sensors.

101. The hub of claim 87, wherein the method further includes detecting a pattern associated with the sensor data.

102. The hub of claim 101, wherein the method further includes detecting an interruption in the pattern that exceeds a predetermined interruption threshold.

103. The hub of claim 102, wherein the method further includes generating an alert in response to detecting the interruption.

104. The hub of claim 103, wherein the method further includes transmitting the alert to a medical provider system.

105. The hub of claim 87, wherein the method includes refraining from transmitting at least a portion of the sensor data when transmitting the processed patient data packets.

106. The hub of claim 105, wherein the method further includes identifying a sensor ID with the sensor data and omitting the sensor ID from the processed patient data packets.

107. The hub of claim 87, wherein the method further includes identifying a sensor ID with the sensor data and including the sensor ID in the processed patient data packets.

108. A method for correlating records comprising different identifiers received from different sources, the method comprising: identifying an electronic record that correlates a sensor identifier and / or hub ID with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet comprising at least one of the patient identifier, the sensor identifier or the hub identifier, as well as analyte sensor data from a first source; adding the analyte sensor data to the stored electronic health record in response to determining the patient identifier of the first user that is associated with the EHR correlates with said patient identifier, sensor identifier or hub identifier; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that wasnot included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

109. A computing system comprising: a processor system; and stored executable instructions that are executable by the processor system to implement a method for correlating records comprising different identifiers received from different sources, the method comprising: identifying an electronic record that correlates a sensor identifier and / or hub ID with a patient identifier corresponding to a first user, the first user being further associated with a stored electronic health record (EHR); receiving a processed patient data packet comprising at least one of the patient identifier, the sensor identifier or the hub identifier, as well as analyte sensor data from a first source; adding the analyte sensor data to the stored electronic health record in response to determining the patient identifier of the first user that is associated with the EHR correlates with said patient identifier, sensor identifier or hub identifier; receiving a new data packet from a second source, the new data packet including new sensor data and a sensor identifier or a particular patient identifier that was not included in the processed patient data packet; and upon determining that the sensor identifier or the particular patient identifier that was not included in the processed patient data packet is also correlated with the first user, adding the new sensor to the EHR.

110. A method, implemented in a medical sensor reader device, comprising: starting an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establishing a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publishing connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the selfconfigured network; based on publishing the connection information, establishing an ad-hoc network connection with an electronic device via the self-configured network; and communicating the analyte data to the electronic device via the ad-hoc networkconnection.

111. The method of claim 110, wherein the method further comprises obtaining the analyte data from the medical sensor device.

112. The method of claim 111, wherein publishing the connection information to the electronic device comprises displaying an optical data carrier that encodes the connection information.

113. The method of claim 112, wherein the optical data carrier encodes one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password.

114. The method of claim 112, wherein the optical data carrier comprises quick response code that encodes the connection information.

115. The method of claim 110, wherein publishing the connection information to the electronic device comprises provisioning a near field communication tag to communicate the connection information, when scanned.

116. The method of claim 115, wherein the near field communication tag communicates one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password, when scanned.

117. The method of claim 110, wherein establishing the local self-configured network comprises establishing an ad-hoc wireless fidelity (Wi-Fi) access point.

118. The method of claim 117, wherein the one or more parameters comprise one or more of a Wi-Fi service set identifier (SSID) or a Wi-Fi password.

119. The method of claim 118, wherein establishing the ad-hoc network connection with an electronic device via the self-configured network includes receiving a Wi-Fi association request from the electronic device that uses one or more of the Wi-Fi SSID or the Wi-Fi password.

120. The method of claim 110, wherein establishing the local self-configured network comprises establishing an embedded dynamic host configuration protocol (DHCP) service.

121. The method of claim 110, wherein establishing the local self-configured network comprises establishing an embedded domain name service (DNS).

122. The method of claim 110, wherein establishing the local self-configured network comprises establishing a serial bus network interface configuration.

123. The method of claim 110, wherein establishing the local self-configured network comprises establishing a BLUETOOTH personal area network (PAN) configuration.

124. The method of claim 110, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises serving one or more web pagesto the electronic device using the embedded web server.

125. The method of claim 110, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises processing an application programming interface (API) request received from the electronic device using the embedded web server.

126. The method of claim 110, wherein the method further comprises establishing a THREAD network configuration.

127. The method of claim 126, wherein the method further comprises communicating the analyte data towards a cloud service using a THREAD mesh network.

128. The method of claim 126, wherein the method further comprises: receiving encrypted data from another electric device via a THREAD mesh network; and communicating the encrypted data towards a cloud service using the THREAD mesh network.

129. The method of claim 110, wherein one or more of i) starting the embedded web server, ii) establishing the local self-configured network, or iii) publishing the connection information is triggered by a user request received at the medical sensor reader device.

130. The method of claim 129, wherein the method further comprises, based on a threshold amount of time having elapsed, performing one or more of: stopping the embedded web server, tearing down the local self-configured network, or ceasing publishing the connection information.

131. The method of claim 110, wherein the analyte data comprises a plurality of data points over a period of time.

132. The method of claim 110, wherein the method further comprises: receiving a network connection parameter via the ad-hoc network connection; and using the network connection parameter to form a network connection.

133. The method of claim 110, wherein the method further comprises communicating with a cloud service via the ad-hoc network connection.

134. The method of claim 110, wherein the method further comprises establishing a cellular network connection via a cellular modem.

135. A medical sensor reader device comprising one or more processors and a computer-readable storage medium comprising computer-executable instructions that cause the medical sensor reader device to at least: identify a request to initiate an ad-hoc communications mode; andbased on the request: start an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad-hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the self-configured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the self-configured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

136. The medical sensor reader device of claim 135, wherein the computerexecutable instructions also cause the medical sensor reader device to obtain the analyte data from the medical sensor device.

137. The medical sensor reader device of claim 135, wherein publishing the connection information to the electronic device comprises displaying an optical data carrier that encodes the connection information.

138. The medical sensor reader device of claim 137, wherein the optical data carrier encodes one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password.

139. The medical sensor reader device of claim 137, wherein the optical data carrier comprises quick response code that encodes the connection information.

140. The medical sensor reader device of claim 135, wherein publishing the connection information to the electronic device comprises provisioning a near field communication tag to communicate the connection information, when scanned.

141. The medical sensor reader device of claim 140, wherein the near field communication tag communicates one or more of a uniform resource identifier (URI), a wireless fidelity (Wi-Fi) service set identifier (SSID), or a Wi-Fi password, when scanned.

142. The medical sensor reader device of claim 135, wherein establishing the local self-configured network comprises establishing an ad-hoc wireless fidelity (Wi-Fi) access point.

143. The medical sensor reader device of claim 142, wherein the one or moreparameters comprise one or more of a Wi-Fi service set identifier (SSID) or a Wi-Fi password.

144. The medical sensor reader device of claim 143, wherein establishing the ad-hoc network connection with the electronic device via the self-configured network includes receiving a Wi-Fi association request from the electronic device that uses one or more of the Wi-Fi SSID or the Wi-Fi password.

145. The medical sensor reader device of claim 135, wherein establishing the local self-configured network comprises establishing an embedded dynamic host configuration protocol (DHCP) service.

146. The medical sensor reader device of claim 135, wherein establishing the local self-configured network comprises establishing an embedded domain name service (DNS).

147. The medical sensor reader device of claim 135, wherein establishing the local self-configured network comprises establishing a serial bus network interface configuration.

148. The medical sensor reader device of claim 135, wherein establishing the local self-configured network comprises establishing a BLUETOOTH personal area network (PAN) configuration.

149. The medical sensor reader device of claim 135, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises serving one or more web pages to the electronic device using the embedded web server.

150. The medical sensor reader device of claim 135, wherein communicating the analyte data to the electronic device via the ad-hoc network connection comprises processing an application programming interface (API) request received from the electronic device using the embedded web server.

151. The medical sensor reader device of claim 135, wherein the computerexecutable instructions also cause the medical sensor reader device to establish a THREAD network configuration.

152. The medical sensor reader device of claim 151, wherein the computerexecutable instructions also cause the medical sensor reader device to communicate the analyte data towards a cloud service using a THREAD mesh network.

153. The medical sensor reader device of claim 152, wherein the computerexecutable instructions also cause the medical sensor reader device to: receive encrypted data from another electric device via a THREAD mesh network; and communicate the encrypted data towards a cloud service using the THREAD mesh network.

154. The medical sensor reader device of claim 135, wherein the computer-executable instructions also cause the medical sensor reader device to, based on a threshold amount of time having elapsed, perform one or more of: stopping the embedded web server, tearing down the local self-configured network, or ceasing publishing the connection information.

155. The medical sensor reader device of claim 135, wherein the analyte data comprises a plurality of data points over a period of time.

156. The medical sensor reader device of claim 135, wherein the computerexecutable instructions also cause the medical sensor reader device to: receive a network connection parameter via the ad-hoc network connection; and use the network connection parameter to form a network connection.

157. The medical sensor reader device of claim 135, wherein the computerexecutable instructions also cause the medical sensor reader device to communicate with a cloud service via the ad-hoc network connection.

158. The medical sensor reader device of claim 135, wherein the computerexecutable instructions also cause the medical sensor reader device to establish a cellular network connection via a cellular modem.

159. A computer-readable storage medium comprising computer-executable instructions that cause a medical sensor reader device to at least: start an embedded web server at the medical sensor reader device, the embedded web server configured to provide access to analyte data obtained from a medical sensor device; establish a local self-configured network that enables establishment of one or more ad- hoc network connections with the medical sensor reader device; publish connection information to one or more electronic devices, the connection information including one or more parameters enabling the one or more electronic devices to initiate ad-hoc network communication with the medical sensor reader device via the selfconfigured network; based on publishing the connection information, establish an ad-hoc network connection with an electronic device via the self-configured network; and communicate the analyte data to the electronic device via the ad-hoc network connection.

Images