Systems, devices, and methods for analyte monitoring systems

Abstract

Systems, devices, and methods for user account verification and telesurveillance feature activation in an analyte monitoring system are described. In some embodiments, a first verification process of a new user account is performed in response to a determination of a first region for the new user account, and a second verification process of the new user account is performed in response to a determination of a second region for the new user account.

Description

SYSTEMS, DEVICES, AND METHODS FOR ANALYTE MONITORING SYSTEMSCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to, and the benefit of, U.S. Provisional Application No. 63 / 727,415, filed December 3, 2024, and U.S. Provisional Application No. 63 / 617,007, filed January 2, 2024, both of which are hereby expressly incorporated by reference in their entireties for all purposes.FIELD

[0002] The subject matter described herein relates generally to systems, methods, and devices for user account verification and telesurveillance activation in analyte monitoring systems.BACKGROUND

[0003] The detection and / or monitoring of analyte levels, such as glucose, ketones, lactate, oxygen, hemoglobin A1C, or the like, can be vitally important to the health of an individual having diabetes. Patients suffering from diabetes mellitus can experience complications including loss of consciousness, cardiovascular disease, retinopathy, neuropathy, and nephropathy. Diabetics are generally required to monitor their glucose levels to ensure that they are being maintained within a clinically safe range, and may also use this information to determine if and / or when insulin is needed to reduce glucose levels in their bodies, or when additional glucose is needed to raise the level of glucose in their bodies.

[0004] Growing clinical data demonstrates a strong correlation between the frequency of glucose monitoring and glycemic control. Despite such correlation, however, many individuals diagnosed with a diabetic condition do not monitor their glucose levels as frequently as they should due to a combination of factors including convenience, testing discretion, pain associated with glucose testing, and cost.

[0005] To increase patient adherence to a plan of frequent glucose monitoring, in vivo analyte monitoring systems can be utilized, in which a sensor control device may be worn on the body of an individual who requires analyte monitoring. To increase comfort and convenience for the individual, the sensor control device may have a small form-factor and can be applied by the individual with a sensor applicator. The application process includes inserting at least a portion of a sensor that senses a user’s analyte level in a bodily fluid located in a layer of the human body, using an applicator or insertion mechanism, such that the sensor comes into contact with a bodilyfluid. The sensor control device may also be configured to transmit analyte data to another device, from which the individual, her health care provider (“HCP”), or a caregiver can review the data and make therapy decisions.

[0006] Analyte monitoring systems can also be used to improve monitoring by an HCP’s patients. For example, analyte monitoring systems can be utilized for telesurveillance (also known as telemedicine or telemonitoring), in which an HCP can directly monitor and communicate, in real time or near real-time, with patients wearing sensor control devices. However, certain regulations and requirements associated with the use of analyte monitoring systems for telesurveillance can vary from region to region.

[0007] In view of the sensitive nature of the data, security is a concern with respect to analyte monitoring systems. For example, verification of a patient’s or HCP’s identity can help to prevent unauthorized individuals from accessing an analyte monitoring system, or data relating thereto, in an unauthorized manner. Furthermore, certain regulations and requirements associated with security and verification of patient and / or HCP accounts in an analyte monitoring system can vary from region to region.

[0008] Thus, needs exist for improved methods for user account verification and telesurveillance activation in analyte monitoring systems, as well as methods and devices relating thereto, that are robust and secure.SUMMARY

[0009] Aspects of the invention are set out in the independent claims and preferred features are set out in the dependent claims. Features associated with one aspect may be applied to other aspects alone or in combination. Provided herein are example embodiments of systems, methods, and devices for telesurveillance and account validation features in analyte monitoring systems. According to some embodiments, a system for managing analyte data of one or more patients is provided, wherein the system comprises one or more servers, the one or more servers comprising communication circuitry configured to receive, over a network, the analyte data of the one or more patients, a database for storing the received data of the one or more patients, and one or more processors coupled with a memory. According to an aspect of some embodiments, the memory is configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to initiate a user account creation process for a new user account, determine a region for the new user account, perform a first verification process in response to adetermination of a first region for the new user account, perform a second verification process in response to a determination of a second region for the new user account, and display a home page for the new user account in response to a successful completion of either the first verification process or the second verification process. The region may for example be a geographical region or an administrative region.

[0010] In some embodiments, either of the first verification process or the second verification process comprises: sending a verification e-mail message to an e-mail address associated with the new user’s account; and receiving an indication that a verification button in the verification e-mail message was actuated. In some embodiments, either of the first verification process or the second verification process comprises: sending a verification text message to a mobile phone number associated with the new user’s account; and receiving an indication that a verification link in the verification text message was actuated. In some embodiments, either of the first verification process or the second verification process comprises linking the new user account with a social media account.

[0011] In some embodiments, either of the first verification process or the second verification process comprises: requesting a change to a social media account or a website associated with the new user account; and monitoring the social media account or the website to detect the requested change. In some embodiments, either of the first verification process or the second verification process comprises: requesting an entry of a unique identifier; and requesting a verification of the unique identifier by a trusted third party. In some embodiments, either of the first verification process or the second verification process comprises: identifying a family member associated with the new user account; and displaying one or more questions relating to the identified family member.

[0012] According to some embodiments, a system for managing analyte data of one or more patients is provided, wherein the system comprises one or more servers, the one or more servers comprising communication circuitry configured to receive, over a network, the analyte data of the one or more patients, a database for storing the received data of the one or more patients, and one or more processors coupled with a memory. According to an aspect of some embodiments, the memory is configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to initiate a healthcare provider (HCP) account creation or login process, determine if the HCP account is in a region indicated for telesurveillance, and if so, display an option to activate telesurveillance features, receive inputted patient profile information, request confirmation of review of one or more exclusion criteria, and prompt a selection of a patient category and a patient level of care.

[0013] In many of the embodiments, the systems described herein further comprise one or more sensor control units, each of which is configured to be worn on a body of a patient, wherein each sensor control unit comprises a glucose sensor comprising a proximal portion configured to be positioned above a skin surface and electrically coupled with sensor electronics, and a distal portion configured to be positioned under the skin surface and to sense an analyte level in a bodily fluid of the patient. In many of the embodiments, each sensor control unit further comprises the sensor electronics comprising wireless communication circuitry configured to transmit data to a reader device.

[0014] In many of the embodiments, the region of the user account can be determined based on a user selection from a list of predetermined regions. In some embodiments, the region of the user can be determined without user intervention. In some embodiments, the region of the user can be based on a location of the user. In some embodiments, the region of the user can be determined using GPS data or geotargeting.

[0015] Many of the embodiments provided herein are GUI features for verifying user accounts and / or activating telesurveillance features for an analyte monitoring system that are highly intuitive, user-friendly, and provide for the sharing and rapid access to physiological information of a user. More specifically, these embodiments allow a user to easily navigate through and between different user interfaces that can quickly allow patients and HCPs to manage medical data, including analyte levels and analyte data reports.

[0016] The improvements to the aforementioned features and GUIs in the various aspects described and claimed herein produce a technical effect at least in that they assist the user of an analyte monitoring system operate it more accurately, more efficiently, and more safely. It will be appreciated that the information that is provided to the user via the GUI, the order in which that information is provided, and the clarity with which that information is structured can have a significant effect on the way the user interacts with the system and the way the system operates. The various GUIs disclosed herein therefore guide the user in the technical task of operating the system to obtain the necessary permissions and / or obtain information accurately and efficiently. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.

[0017] Other systems, devices, methods, features and advantages of the subject matter described herein will be or will become apparent to one with skill in the art upon examination ofthe following figures and detailed description. It is intended that all such additional systems, devices, methods, features, and advantages be included within this description, be within the scope of the subject matter described herein, and be protected by the accompanying claims. Aspects of the embodiments are set out in the independent claims and preferred features are set out in the dependent claims. The preferred features of the dependent claims may be provided in combination in a single embodiment and preferred features of one aspect may be provided in conjunction with other aspects. In no way should the features of the example embodiments be construed as limiting the appended claims, absent express recitation of those features in the claims. Systems, devices, and methods for user account verification and telesurveillance feature activation in an analyte monitoring system are described. In some embodiments, a first verification process of a new user account is performed in response to a determination of a first region for the new user account, and a second verification process of the new user account is performed in response to a determination of a second region for the new user account.BRIEF DESCRIPTION OF THE FIGURES

[0018] The details of the subject matter set forth herein, both as to its structure and operation, may be apparent by study of the accompanying figures, in which like reference numerals refer to like parts. The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the subject matter. Moreover, all illustrations are intended to convey concepts, where relative sizes, shapes and other detailed attributes may be illustrated schematically rather than literally or precisely.

[0019] FIG. 1 is a system overview of an analyte monitoring system including a sensor applicator, a sensor control device, a reader device, a network, a trusted computer system, and a local computer system.

[0020] FIG. 2A is a block diagram depicting an example embodiment of a reader device.

[0021] FIGS. 2B and 2C are block diagrams depicting example embodiments of sensor control devices.

[0022] FIGS. 3A and 3B are flow diagrams depicting example embodiments of methods for user account verification in an analyte monitoring system.

[0023] FIGS. 4A to 41 are example embodiments of various GUIs related to user account creation and verification for an analyte monitoring system.

[0024] FIG. 5A is a flow diagram depicting an example embodiment of a method for activating telesurveillance features in an analyte monitoring system.

[0025] FIG. 5B is an example embodiment of a GUI related to direct messages in an analyte monitoring system.

[0026] FIGS. 6A to 6H are example embodiments of various GUIs related to telesurveillance features in an analyte monitoring system.

[0027] FIG. 7 is an example embodiment of a GUI related to event logging in an analyte monitoring system.DETAILED DESCRIPTION

[0028] Before the present subject matter is described in detail, it is to be understood that this disclosure is not limited to the particular embodiments described, as such may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting, since the scope of the present disclosure will be limited only by the appended claims.

[0029] As used herein and in the appended claims, the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise.

[0030] The publications discussed herein are provided solely for their disclosure prior to the filing date of the present application. Nothing herein is to be construed as an admission that the present disclosure is not entitled to antedate such publication by virtue of prior disclosure. Further, the dates of publication provided may be different from the actual publication dates which may need to be independently confirmed.

[0031] Generally, embodiments of the present disclosure include GUIs, software, and digital interfaces for analyte monitoring systems, and methods and devices relating thereto. Accordingly, many embodiments include in vivo analyte sensors structurally configured so that at least a portion of the sensor is, or can be, positioned in the body of a user to obtain information about at least one analyte of the body. It should be noted, however, that the embodiments disclosed herein can be used with in vivo analyte monitoring systems that incorporate in vitro capability, as well as purely in vitro or ex vivo analyte monitoring systems, including systems that are entirely non-invasive.

[0032] Furthermore, for each and every embodiment of a method disclosed herein, systems and devices capable of performing each of those embodiments are covered within the scope of thepresent disclosure. For example, embodiments of sensor control devices, reader devices, local computer systems, and trusted computer systems are disclosed, and these devices and systems can have one or more sensors, analyte monitoring circuits (e.g., an analog circuit), memories (e.g., for storing instructions), power sources, communication circuits, transmitters, receivers, processors and / or controllers (e.g., for executing instructions) that can perform any and all method steps or facilitate the execution of any and all method steps.

[0033] Improved graphical user interfaces (“GUIs”) for analyte monitoring systems are provided. For example, disclosed herein are various embodiments of GUIs that are highly intuitive, user-friendly, and provide for rapid access to physiological information of a user. In sum, these embodiments provide for a robust, user-friendly interfaces that can increase user engagement with the analyte monitoring system and provide for timely and actionable responses by the user, to name a few advantages. Other improvements and advantages are provided as well. The various configurations of these devices are described in detail by way of the embodiments which are only examples.

[0034] Before describing these aspects of the embodiments in detail, however, it is first desirable to describe examples of devices that can be present within, for example, an in vivo analyte monitoring system, as well as examples of their operation, all of which can be used with the embodiments described herein.

[0035] There are various types of in vivo analyte monitoring systems. “Continuous Analyte Monitoring” systems (or “Continuous Glucose Monitoring” systems), for example, can transmit data from a sensor control device to a reader device continuously without prompting, e.g., automatically according to a schedule. “Flash Analyte Monitoring” systems (or “Flash Glucose Monitoring” systems or simply “Flash” systems), as another example, can transfer data from a sensor control device in response to a scan or request for data by a reader device, such as with a Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocol. In vivo analyte monitoring systems can also operate without the need for finger stick calibration.

[0036] In vivo analyte monitoring systems can be differentiated from “in vitro” systems that contact a biological sample outside of the body (or “ex vivo”) and that typically include a meter device that has a port for receiving an analyte test strip carrying bodily fluid of the user, which can be analyzed to determine the user’s blood sugar level.

[0037] In vivo monitoring systems can include a sensor that, while positioned in vivo, makes contact with the bodily fluid of the user and senses the analyte levels contained therein. The sensor can be part of the sensor control device that resides on the body of the user and contains the electronics and power supply that enable and control the analyte sensing. The sensor control device, 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.

[0038] In vivo monitoring systems can also include a device that receives sensed analyte data from the sensor control device and processes and / or displays that sensed analyte data, in any number of forms, to the user. This device, and variations thereof, can be referred to as a “handheld reader device,” “reader device” (or simply a “reader”), “handheld electronics” (or simply a “handheld”), a “portable data processing” device or unit, a “data receiver,” a “receiver” device or unit (or simply a “receiver”), or a “remote” device or unit, to name a few. Other devices such as personal computers have also been utilized with or incorporated into in vivo and in vitro monitoring systems.Example Embodiment of In V ivo Analyte Monitoring System

[0039] FIG. 1 is a conceptual diagram depicting an example embodiment of an analyte monitoring system 100 that includes a sensor applicator 150, a sensor control device 102, and a reader device 120. Here, sensor applicator 150 can be used to deliver sensor control device 102 to a monitoring location on a user’s skin where a sensor 104 is maintained in position for a period of time by an adhesive patch 105. Sensor control device 102 is further described in FIGS. 2B and 2C, and can communicate with reader device 120 via a communication path 140 using a wired or wireless technique. Example wireless protocols include Bluetooth, Bluetooth Low Energy (BLE, BTLE, Bluetooth SMART, etc.), Near Field Communication (NFC) and others. Users can view and use applications installed in memory on reader device 120 using screen 122 (which, in many embodiments, can include a touchscreen), and input 121. A device battery of reader device 120 can be recharged using power port 123. While only one reader device 120 is shown, sensor control device 102 can communicate with multiple reader devices 120. Each of the reader devices 120 can communicate and share data with one another. More details about reader device 120 is set forth with respect to FIG. 2A below. Reader device 120 can communicate with local computer system 170 via a communication path 141 using a wired or wireless communication protocol.Local computer system 170 can include one or more of a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computing device and wireless communication can include any of a number of applicable wireless networking protocols including Bluetooth, Bluetooth Low Energy (BTLE), Wi-Fi or others. Local computer system 170 can communicate via communications path 143 with a network 190 similar to how reader device 120 can communicate via a communications path 142 with network 190, by a wired or wireless communication protocol as described previously. Network 190 can be any of a number of networks, such as private networks and public networks, local area or wide area networks, and so forth. A trusted computer system 180 can include a cloud-based platform or server, and can provide for authentication services, secured data storage, report generation, and can communicate via communications path 144 with network 190 by wired or wireless technique. In addition, although FIG. 1 depicts trusted computer system 180 and local computer system 170 communicating with a single sensor control device 102 and a single reader device 120, it will be appreciated by those of skill in the art that local computer system 170 and / or trusted computer system 180 are each capable of being in wired or wireless communication with a plurality of reader devices and sensor control devices.Example Embodiment of Reader Device

[0040] FIG. 2A is a block diagram depicting an example embodiment of a reader device 120, which, in some embodiments, can include a smart phone. Here, reader device 120 can include a display 122, input component 121, and a processing core 206 including a communications processor 222 coupled with memory 223 and an applications processor 224 coupled with memory 225. Also included can be separate memory 230, RF transceiver 228 with antenna 229, and power supply 226 with power management module 238. Further, reader device 120 can also include a multi-functional transceiver 232, which can include wireless communication circuitry, and which can be configured to communicate over Wi-Fi, NFC, Bluetooth, BTLE, and GPS with an antenna 234. As understood by one of skill in the art, these components are electrically and communicatively coupled in a manner to make a functional device.Example Embodiments of Sensor Control Devices

[0041] FIGS. 2B and 2C are block diagrams depicting example embodiments of sensor control devices 102 having analyte sensors 104 and sensor electronics 160 (including analyte monitoringcircuitry) that can have the majority of the processing capability for rendering end-result data suitable for display to the user. In FIG. 2B, a single semiconductor chip 161 is depicted that can be a custom application specific integrated circuit (ASIC). Shown within ASIC 161 are certain high-level functional units, including an analog front end (AFE) 162, power management (or control) circuitry 164, processor 166, and communication circuitry 168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or otherwise according to the communication protocol). In this embodiment, both AFE 162 and processor 166 are used as analyte monitoring circuitry, but in other embodiments either circuit can perform the analyte monitoring function. Processor 166 can include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which can be a discrete chip or distributed amongst (and a portion of) a number of different chips.

[0042] A memory 163 is also included within ASIC 161 and can be shared by the various functional units present within ASIC 161, or can be distributed amongst two or more of them. Memory 163 can also be a separate chip. Memory 163 can be volatile and / or non-volatile memory. In this embodiment, ASIC 161 is coupled with power source 172, which can be a coin cell battery, or the like. AFE 162 interfaces with in vivo analyte sensor 104 and receives measurement data therefrom and outputs the data to processor 166 in digital form, which in turn processes the data to arrive at the end-result glucose discrete and trend values, etc. This data can then be provided to communication circuitry 168 for sending, by way of antenna 171, to reader device 120 (not shown), for example, where minimal further processing is needed by the resident software application to display the data. According to some embodiments, for example, a current glucose value can be transmitted from sensor control device 102 to reader device 120 every minute, and historical glucose values can be transmitted from sensor control device 102 to reader device 120 every five minutes.

[0043] In some embodiments, to conserve power and processing resources on sensor control device 102, digital data received from AFE 162 can be sent to reader device 120 (not shown) with minimal or no processing. In still other embodiments, processor 166 can be configured to generate certain predetermined data types (e.g., current glucose value, historical glucose values) either for storage in memory 163 or transmission to reader device 120 (not shown), and to ascertain certain alarm conditions (e.g., sensor fault conditions), while other processing and alarm functions (e.g., high / low glucose threshold alarms) can be performed on reader device 120. Those of skill in theart will understand that the methods, functions, and interfaces described herein can be performed - in whole or in part — by processing circuitry on sensor control device 102, reader device 120, local computer system 170, or trusted computer system 180.

[0044] FIG. 2C is similar to FIG. 2B but instead includes two discrete semiconductor chips 162 and 174, which can be packaged together or separately. Here, AFE 162 is resident on ASIC 161. Processor 166 is integrated with power management circuitry 164 and communication circuitry 168 on chip 174. AFE 162 may include memory 163 and chip 174 includes memory 165, which can be isolated or distributed within. In one example embodiment, AFE 162 is combined with power management circuitry 164 and processor 166 on one chip, while communication circuitry 168 is on a separate chip. In another example embodiment, both AFE 162 and communication circuitry 168 are on one chip, and processor 166 and power management circuitry 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each bearing responsibility for the separate functions described, or sharing one or more functions for fail-safe redundancy.Example Embodiments of Account Creation and Verification Features

[0045] Example embodiments of features for analyte monitoring systems will now be described, including features for user account creation and verification. As an initial matter, those of skill in the art will recognize that any method steps described herein can include software instructions stored in a memory of a computing device of system 100 (e g., a reader 120, a local computer system 170, a trusted computer system 180), such that the instructions, when executed by one or more processors of the computing device, cause the one or more processors to perform any or all of the method steps described herein.

[0046] Likewise, in many embodiments, the subject matter described herein is implemented by a software application program that is stored in a memory of and executed by a processor-based device, such as any one of the reader devices (e.g., a smart phone), drug delivery devices, trusted computer system, local computer system, or any of the other computing devices described herein. In certain embodiments, the software is implemented as one or more downloadable software applications on a reader device such as a mobile communication device or a smartphone. In certain embodiments, the software, and its associated features and functionalities, can be implemented on a single centralized device or, in the alternative, can be distributed across multiple discrete devices in geographically dispersed locations. Likewise, those of skill in the art will recognize that therepresentations of various computer systems in the embodiments disclosed herein, as shown in FIG. 1, are intended to cover both physical computing devices and virtual computing devices (e.g., virtual servers or virtual machines).

[0047] Referring first to FIG. 3 A, a flow diagram depicts an example embodiment of a method 300 for creating and verifying a user account for an analyte monitoring system. In some embodiments, the user account can be configured for a subject being monitored for one or more physiological parameters (e.g., a patient wearing a sensor control device such as those described with respect to FIGS. 2B and 2C). In some embodiments, the user account can be configured for a health care provider (“HCP”), such as a physician, a medical practitioner, or any individual or caretaker responsible for monitoring one or more physiological parameters of their patients.

[0048] At Step 302, an account creation process is initiated. In some embodiments, the account creation process can be initiated through a login GUI by a user, such as the GUI described with respect to FIG. 4A. In some embodiments, the account creation process can be initiated on the reader device. In other embodiments, the account creation process can be initiated on a computing device with access to a trusted computer system, such as those described with respect to FIG. 1. At Step 304, an account type is selected. An account type can indicate, for example, whether the user account is for a patient or an HCP. At Step 306, a region of the user is determined. In some embodiments, the region can be determined by manual input from the user. For example, according to some embodiments, the user can be prompted to select or enter a “Country” or “Region of Residence” through a GUI, such as the GUI described with respect to FIG. 4C. In other embodiments, the region can be determined without user intervention, such as, by determining the user’s location via GPS data from the user’s reader device, geotargeting, IP address databases, or other similar technologies.

[0049] Referring still to FIG. 3A, at Step 308, account information is received. According to some embodiments, account information can include the user’s first name, the user’s last name, the user’s date of birth, the user’s e-mail address, the user’s password, the healthcare organization that the user is associated with (if the user is an HCP), and / or the user’s work address. In some embodiments, where the user is a minor, a parent, or a guardian, the account information can include the parent’s or guardian’s first name, the parent’s or guardian’s last name, an e-mail address, and a password.

[0050] At Step 310, a verification process is performed. According to one aspect of some embodiments, the verification process can include, first, sending a verification e-mail message to an e-mail address associated with the user’s account (e.g., as inputted by the user in Step 308), and second, receiving an indication that the user opened the e-mail message and clicked on a “verification” button or link in the e-mail message. Alternatively, in some embodiments, the verification e-mail message can contain a verification code (e.g., a plurality of numeric of alphanumeric characters) which the user can enter into a verification code field in a GUI.

[0051] According to some embodiments, the verification process can utilize a mobile phone number instead of an e-mail address. For example, the verification process can include, first, sending a verification text message (e.g., via Short Messaging Service, or SMS) to a mobile phone number associated with the user’ s account (e.g., as inputted by the user in Step 308). Subsequently, the verification process is completed when an indication is received that the user has opened the verification text message and / or clicked on a “verification” hyperlink contained therein. Alternatively, in some embodiments, the verification text message can contain a verification code (e.g., a plurality of numeric of alphanumeric characters) which the user can enter into a verification code field in a GUI.

[0052] In some embodiments, the verification process can include verifying the identity of the user via a social media account. In some embodiments, for example, the user can be prompted to “link” a social media account to the new user account. Subsequently, a message can be sent to the user’s social media account prompting the user to click on a “verification” button or link in the message. In other embodiments, the verification process can include automatically identifying a social media account that is likely to be associated with the user by using the user’s account information (e.g., user’s full name, user’s e-mail address, user’s work address). In response to identifying a social media account, the user can be prompted to successfully link the social media account to the new user account.

[0053] Similarly, in some embodiments, the verification process can include prompting the user to provide information from the user’s social media account. According to an aspect of some embodiments, the verification process can automatically identify the user’s social media account and retrieve certain identifying information such as, for example, the user’s current occupation and employer, the user’s hometown, the user’s high school, the user’s educational background and degrees obtained, the user’s job history, and / or the user’s contacts, to name only a few examples.Subsequently, the user can be prompted to answer one or more questions based on the retrieved identifying information. If the user answers a minimum number of question(s) correctly, the user account is then verified.

[0054] According to some embodiments, the verification process can include prompting the user to make a change to the user’s social media account. According to an aspect of some embodiments, the verification process can automatically identify the user’s social media account. Subsequently, the user can be prompted to make a small change to the social media account (e.g., temporarily change a hometown location or post a status update with a specific phrase). Then, the verification process can monitor the social media account to confirm that the requested change has been made before verifying the user’s new account.

[0055] Similarly, in some embodiments, the verification process can include prompting the user to make a change to a website that is owned, managed, or otherwise controlled by the user. This verification process typically applies to HCPs, as they may have their own website or belong to a group practice with a website. According to an aspect of some embodiments, the website associated with the user can be automatically determined based on the user’s account information (e g., e-mail address, e-mail address domain, workplace address), or, in the alternative, can be selected by the user from a predetermined list. Subsequently, the verification process can prompt the user to modify a characteristic of the website such as, for example, a field of the user’s web page. If the change is successfully detected by the verification process, then the user account is verified.

[0056] According to some embodiments, the verification process can include prompting the user to enter a unique identifier that can be verified by a third party. In some embodiments, for example, the user can be prompted to enter a driver’s license number, which can be subsequently verified by a third party by cross-referencing a trusted database. In other embodiments, the verification process can utilize a social security number or a passport number as the unique identifier, which can be cross-referenced against a trusted national database. In still other embodiments, the verification process can utilize an enterprise master patient index to verify the user. In some embodiments, for example, the verification process can utilize the date of birth of the user and / or the e-mail address of the user to cross-reference the enterprise master patient index in order to verify the user. In still other embodiments, a public health care provider index can be utilized by the verification process to verify an HCP’s user account. According to someembodiments, the public health care provider index can include doctors, nurses, dentists, dental assistants, and students.

[0057] In some embodiments, the verification process can include automatically identifying at least one likely relative or family member of the user based on account information provided by the user. In some embodiments, for example, the likely relative or family member can be identified by cross-referencing the user’s personal information against a trusted database (e.g., a national registry). In other embodiments, the likely relative or family member can be determined based on corroborating information from multiple sources including, but not limited to, public and private directories, social media platforms, national or statewide registries and / or databases, to name only a few. Subsequently, in some embodiments, the verification process can prompt the user to answer one or more questions about the likely relative or family member. For example, the user can be asked about the names and / or number of siblings that she has, the age of a particular sibling, the full names of the user’s parents or grandparents, or the city of residence of the user’s aunt or uncle, to name only a few examples. If the user answers a minimum number of question(s) correctly, the user account is then verified.

[0058] According to some embodiments, the verification process can include an interview session between the user and a third party. In some embodiments, for example, the user can be required to submit to an interview with a third party in person or through a web conferencing platform. According to some embodiments, the user can be prompted to display physical proof of identity during the interview session (e.g., by the user displaying a passport or a driver’s license). For example, the user can be prompted to display an identification card with a headshot photograph during the interview session.

[0059] In some embodiments, the verification process can require the user to obtain a verification from a trusted third party, such as another user that has already been verified. For example, in the case of an HCP, the verification process can be performed when the requesting HCP initiates a verification request to another HCP who has already been verified (e.g., which can be an HCP in the same group practice). In some embodiments, if the requesting HCP does not have an already -verified contact, the requesting HCP can purchase a license that includes a verified account. In this regard, the requesting HCP becomes a trusted account to verify other HCPs in the future. Furthermore, in some embodiments, the request can be communicated via an e-mailmessage, a text message, or a message received through a web portal hosted on a trusted computer system, to name only a few examples.

[0060] In some embodiments, the verification process can require the user to go to a physical location to obtain a verification. For example, in the case of an HCP seeking verification, the verification process can require that the HCP visit any one of a plurality of predetermined events (e.g., conferences) and to show a form of identification to obtain a verification. In other embodiments, a verification can be obtained at a specific location (e.g., a trusted third party’s offices) at any time. At the specific location or event, for example, an indication that the user has been verified can be transmitted to the analyte monitoring system. In some embodiments, the user can be provided with a verification code to be entered later to confirm verification.

[0061] In some embodiments, the verification process can include using information about the user from an electronic medical record or the analyte monitoring system to validate the user’s identity. In some embodiments, for example, the verification process can include retrieving the user’s historical analyte data and other related information, which can be stored on a computing device of the analyte monitoring system, such as the sensor control device, the reader device, or the trusted computer system. In some embodiments, the user can be prompted to answer one or more questions based on information from the electronic medical record or the analyte monitoring system in order to complete the verification process. According to one aspect of the embodiments, the information on which the questions are based can include, but are not limited to, the user’s last logged medication, last new sensor initiation, the user’s last logged meal, the user’s last logged physical activity, the user’s last visit to the HCP, the HCP’s full name, and / or the HCP’s office address, to name only a few examples. In some embodiments, a machine learning model can be utilized on the retrieved historical analyte data and related information to ascertain characteristics about the user. For example, according to some embodiments, the machine learning model can be configured to ascertain gender, age, and / or ethnicity of the user based on the retrieved historical analyte data and related information. Those of skill in the art will appreciate that other characteristics can be ascertained based on historical analyte data and related information. Subsequently, the user can be prompted to answer one or more questions based on characteristics ascertained by the machine learning model.

[0062] In some embodiments, the verification process can include the user of biometrics for verifying the identity of the user. For example, according to some embodiments, the verificationprocess can be configured to utilize a facial recognition routine, a fingerprint identification routine, and / or voiceprint identification routine, to name only a few. According to some embodiments, the verification process would then cross-reference a trusted database to confirm the identity of the user.

[0063] It will be understood by those of skill in the art that any one or more of the verification processes described herein can be utilized alone or in combination with each other. Indeed, any combination of verification processes described herein are fully within the scope of the present disclosure.

[0064] Referring back to FIG. 3A, at Step 312, an optional two-factor authentication setup process can be performed by the user. According to some embodiments, to provide additional account security and protection, two-factor authentication can be provided for HCPs and patients via SMS or e-mail verification. In some embodiments, two-factor authentication can be provided to HCPs only or patients only. In still further embodiments, the presence of the two-factor authentication setup process can depend on the determined region.

[0065] At Step 314, after the user account has been created and verified, a home page can be displayed to the user. From the home page, the user can view one or more reports that are based at least in part on the user’s analyte data. Further descriptions of such reports can be found in U.S. Publ. Nos. 20220409102A1, 20220338803A1, 20220092019A1, and 20220248988A1, all of which are incorporated by reference in their entireties for all purposes.

[0066] Referring next to FIG. 3B, a flow diagram depicts another example embodiment of a method 320 for creating and verifying a user account for an analyte monitoring system. In many regards, method 320 shares several of the same steps as method 300, as described with respect to FIG. 3A. For example, according to many embodiments, method 320 includes: initiating an account creation process at Step 322; selecting an account type at Step 324; determining a region of the user at Step 326; and receiving account information at Step 328.

[0067] According to one aspect of some embodiments, at Step 330, a verification process is performed based on the region of the user that was determined at Step 326. Privacy and other related regulations can differ between various countries, municipalities, and / or regions. In this regard, method 320 is capable of utilizing different account verification methods in accordance with a user’s particular region. For example, according to some embodiments, if the user’s region is determined to be a first region, then a first verification process can be performed and completedat Step 332. If the user’s region is determined to be a second region that is different from the first region, then a second verification process can be performed and completed at Step 334. In some embodiments, the first verification process and the second verification process can be different verification processes. In other embodiments, the first verification process and the second verification process can be the same verification process. Moreover, those of skill in the art will appreciate that any of the verification processes described with respect to FIG. 3A can be implemented with either or both of the first verification process or the second verification process of method 320. In addition, according to some embodiments, depending on the requirements of the region, either of the first verification process or the second verification process can entail no verification process, such that Step 328 proceeds directly to Step 336.

[0068] Referring still to FIG. 3B, at Step 336, after the user account has been created and verified, a home page can be displayed to the user. From the home page, the user can view one or more reports that are based at least in part on the user’s analyte data.

[0069] FIGS. 4A to 41 are example embodiments of graphical user interfaces (“GUIs”) that can be used with methods for creating and verifying a user account in an analyte monitoring system, such as methods 300, 320 as described with respect to FIGS. 3A and 3B. As an initial matter, it will be understood by those of skill in the art that any of the GUIs described herein can be for use with either a patient account or an HCP user account. It will also be understood that any of the GUIs described herein can include software instructions stored in a memory of a computing device of an analyte monitoring system 100 (e g., a reader 120, a local computer system 170, a trusted computer system 180), such that the instructions, when executed by one or more processors of the computing device, cause the one or more processors to display any one or more of the GUIs described herein. It will further be understood by those of skill in the art that the software instructions can be stored in memory on a different computing device than the computing device on which the GUI is displayed.

[0070] Referring first to FIG. 4A, GUI 400 depicts a home page including an account field 402, a password field 404, a login button 406, a forgotten password link 408, and a sign-up button 410. According to some embodiments, if a user does not have a user account, the sign-up button 410 can be used to initiate an account creation process, as described with Steps 302 and 322 of FIGS. 3A and 3B, respectively. On the other hand, if a user already has a user account, then theuser can input their login information into account field 402 and password field 404, and subsequently, login button 406 can be actuated.

[0071] FIG. 4B depicts GUI 415 for receiving an account type selection, which can be utilized with Steps 304 and 324 of FIGS. 3A and 3B, respectively. According to some embodiments, GUI 415 can include a plurality of account types which can be selected, including a checkbox 417 for a patient account and a checkbox 419 for an HCP account. Although only two options are depicted in GUI 415, those of skill in the art will appreciate that other options for account types can be implemented, such as, for example: a user account for a child, a caregiver’s user account, a trial user account, a user account for non-diabetics, and / or a user account for intermittent CGM system users, to name only a few. It will also be understood by those of skill in the art that GUI 415 can utilize other features besides check boxes for receiving the user’s selection of an account type, such as, for example: radio buttons, pull down menu, sliders, and / or switches.

[0072] Turning to FIG. 4C, GUI 420 depicts an interface for receiving a user’s selection of a region in accordance with some embodiments, such as those described with respect to Step 306 and Step 326 of FIGS. 3 A and 3B, respectively. In some embodiments, GUI 420 can include a pulldown menu 422 configured to display a list of predetermined regions (e.g., countries) from which the user can make a selection. Those of skill in the art will appreciate that other features besides a pulldown menu 422 can be implemented such as, for example, radio buttons, slides, switches, check boxes, and / or free text fields, to name only a few.

[0073] Referring next to FIG. 4D, GUI 425 depicts an interface for receiving account information in accordance with some embodiments, such as those described with respect to Step 308 and 328 of FIGS. 3 A and 3B, respectively. In many embodiments, account information can include a user’s first name 427, a user’s last name 429, a user’s e-mail address 431, a user’s password 433, a confirmation of the user’s password 435, and / or (in the case of an HCP’s user account) information relating to the user’s healthcare organization (e.g., name of the healthcare organization, address, etc.). According to an aspect of some embodiments, certain account information can be used by the user to login to their account. For example, as shown in FIG. 4D, the user’s e-mail address 431 and password 433 are shown under the section entitled, “Login Information.” In other embodiments, the user’s mobile phone number (not shown) can also be a part of the account information received from the user and, moreover, can be utilized as part of the login information in lieu of the user’s e-mail address.

[0074] FIGS. 4E and 4F depict GUIs for user account verification in accordance with some embodiments, such as those described with respect to Step 310, Step 332, and Step 334 of FIGS. 3 A and 3B. According to some embodiments, GUI 440 of FIG. 4E can include a set of instructions 442 for account verification. In some embodiments, for example, instructions 442 can prompt the user to check their e-mail account for a verification e-mail. In other embodiments, instructions 442 can prompt the user to check their mobile phone device for a verification SMS text message. Those of skill in the art will appreciate that the instructions can be configured to provide information to the user on how to complete any of the verification processes described herein. Subsequently, in some embodiments, GUI 445 of FIG. 4F can include an example verification e- mail message with a verification button 447 embedded within. In other embodiments (not depicted), instead of verification button 447, the verification e-mail message can include a passcode for the user to enter to complete the verification process.

[0075] FIGS. 4G and 4H depict GUIs for an optional two-factor authentication setup process in accordance with some embodiments, such as those described with respect to Step 312 of FIG. 3A. According to some embodiments, GUI 450 of FIG. 4G includes a pulldown menu 452 configured to allow the user to select the method by which to receive a security code, where the methods can include via an SMS text message or an e-mail message. In addition, GUI 450 further includes a text entry field 454 to receive the particular mobile phone number or e-mail address associated with the selected method to receive the security code. Subsequently, GUI 455 of FIG. 4H includes another text entry field 457 for the user to enter the received security code. In addition, GUI 455 further includes a button or link 458 to re-send the security code in case the user did not receive it, and a “Remember Me” checkbox 459 so that the user can enable or disable the two factor authentication feature in the future without having to receiving a new security code.

[0076] FIG. 41 depicts a new home page GUI 460 in accordance with some embodiments, such as those described with respect to Step 314 and Step 336 of FIGS. 3A and 3B, respectively. According to some embodiments, home page GUI 460 can include a “Getting Started” section 462, an “Upload Devices” section 464, and a “Reports” section 466. In some embodiments, the “Getting Started” section 462 can be configured to provide further instructions and tutorials to the user. In addition, in some embodiments, the “Upload Devices” section 464 allows the user to view and manage the current and historical computing devices used with the analyte monitoring system.Furthermore, in some embodiments, the “Reports” section 466 allows the user to select, view, and manage various predetermined analyte reports.Example Embodiments of Telesurveillance Activation Features

[0077] Example embodiments of telesurveillance activation features for analyte monitoring systems will now be described. As an initial matter, those of skill in the art will recognize that any method steps described herein can include software instructions stored in a memory of a computing device of system 100 (e.g., a reader 120, a local computer system 170, a trusted computer system 180), such that the instructions, when executed by one or more processors of the computing device, cause the one or more processors to perform any or all of the method steps described herein.

[0078] Likewise, in many embodiments, the subject matter described herein is implemented by a software application program that is stored in a memory of and executed by a processor-based device, such as any one of the reader devices (e.g., a smart phone), drug delivery devices, trusted computer system, local computer system, or any of the other computing devices described herein. In certain embodiments, the software is implemented as one or more downloadable software applications on a reader device such as a mobile communication device or a smartphone. In certain embodiments, the software, and its associated features and functionalities, can be implemented on a single centralized device or, in the alternative, can be distributed across multiple discrete devices in geographically dispersed locations. Likewise, those of skill in the art will recognize that the representations of various computer systems in the embodiments disclosed herein, as shown in FIG. 1, are intended to cover both physical computing devices and virtual computing devices (e.g., virtual servers or virtual machines).

[0079] Referring first to FIG. 5A, a flow diagram depicts an example embodiment of a method 500 for activating and configuring telesurveillance features in an analyte monitoring system. According to one aspect of some embodiments, telesurveillance (sometimes also referred to as “telemonitoring” or “telemedicine”) can enable a direct one-to-one connection between an HCP and their patient by allowing direct messaging and the sharing of data and reports. As such, it can be advantageous to activate telesurveillance features in an analyte monitoring system to allow an HCP to communicate directly with their patient and remotely interpret analyte data reports and other related information. It can also be advantageous for the analyte monitoring system to keep a record of the HCP’s telesurveillance actions for various reasons such as, for example, to ensurecompliance with regulatory issues and reimbursement requirements. Moreover, telesurveillance may not be supported in all regions for regulatory or other technical reasons.

[0080] As seen in FIG. 5B, GUI 530 is an exemplary interface that allows for direct one-to- one connection between an HCP and their patient. A message 556 may be displayed in the software application, e.g., a website interface. GUI 530 can include a profde link 532, messages link 534, notifications link 536, and a link 538 to upload data from a reader device. GUI 530 can also include a field 540 to search patients, and a link 542 to add patients. A list of messages 544 can be displayed along with a link 558 to draft a new message. Upon selection of link 558, window 556 will appear with fields for the patient name 546, a field to enter at least one email address 548a-c, and a subject field 550. As mentioned above, the message may be sent from an HCP to the patient, but may also be sent to other HCPs regarding a patient, without sending the message to the patient.

[0081] At Step 502, an HCP account creation or login process is initiated. According to some embodiments, an HCP account creation process can utilize methods 300, 320, as described with respect to FIGS. 3A and 3B, respectively. Once the HCP has completed the account creation or login process, at Step 504, a determination can be made whether the HCP is in a region where telesurveillance features are supported. According to some embodiments, the determination can be based on the HCP’s selection of the region, as described with respect to Step 306 and Step 326 of FIGS. 3A and 3B, respectively. In other embodiments, the determination of the region can be made without user intervention, such as, by determining the user’s location via GPS data from the user’s reader device, geotargeting, IP address databases, or other similar technologies.

[0082] If it is determined that telesurveillance is supported in the HCP’s region, then at Step506, one or more telesurveillance settings of the analyte monitoring system can be activated. In some embodiments, for example, a telesurveillance activation button can be displayed for the HCP to enable for each patient, as described with respect to FIG. 6A. In other embodiments, the telesurveillance features may be automatically activated for each patient upon a determination that telesurveillance is supported in the HCP’s region.

[0083] At Step 508, after the telesurveillance features are activated, the HCP is prompted to input information for a patient profile as a step in the telesurveillance activation process. One example embodiment of a GUI for receiving input from the HCP for a patient profile is depicted in FIG. 6B. According to an aspect of some embodiments, the patient profile can includeinformation such as the patient’s first name, the patient’s last name, the patient’s date of birth, the patient’s identification number (e.g., national identification number or social security number), the patient’s e-mail address, and / or the patient’s phone number, to name only a few.

[0084] At Step 510, the HCP is prompted to review one or more exclusion criteria, and to confirm that none of the one or more exclusion criteria apply to the patient. One example embodiment of a GUI for displaying exclusion criteria to the HCP is depicted in FIG. 6C. According to one aspect of the embodiments, the exclusion criteria displayed to the HCP can depend on the determined region of the HCP. For example, if it is determined that the HCP is in a first region, then a first set of exclusion criteria associated with the first region is retrieved from a database and displayed to the HCP. If it is determined that the HCP is in a second region, then a second set of exclusion criteria associated with the second region is retrieved from the database and displayed to the HCP, and wherein the second set of exclusion criteria is different from the first set of exclusion criteria.

[0085] According to one aspect of many embodiments, the one or more exclusion criteria can include one or more of the following: a patient’s physical or mental inability to use telesurveillance features; chronic dialysis; severe liver failure; a life expectancy of less than twelve (12) months; a patient’s refusal to receive treatment; and an absence of a fixed place of residence. Those of skill in the art will recognize that the aforementioned list is illustrative and non-exhaustive, and that other exclusion criteria can be utilized and are fully within the scope of the present disclosure.

[0086] At Step 512, the HCP can be prompted to select a patient category and a level of care for the patient as another step in the telesurveillance activation process. One example embodiment of a GUI for selecting a patient category and a level of care is depicted in FIG. 6D.

[0087] Referring still to FIG. 5, at Step 514, the HCP can be prompted to enter prescription information for their patient as another step in the telesurveillance activation process. One example embodiment of a GUI for entering prescription information is depicted in FIG. 6E. According to some embodiments, the prescription information can include the patient’s home address and / or the patient’s diabetes diagnosis date. Furthermore, in some embodiments, the prescription information can also include an uploaded file including a prescription document.

[0088] At Step 516, the HCP can be prompted to configure one or more threshold and notification settings relating to the telesurveillance features as another step in the telesurveillance activation process. One example embodiment of a GUI for configuring threshold and notificationsettings relating to telesurveillance features is depicted in FIG. 6F. According to some embodiments, the threshold and notification settings can include target, low, and high glucose threshold settings, sensor usage notification settings, hypoglycemia event threshold notification settings, hyperglycemia event threshold notification settings, and / or target range notification settings, to name only a few.

[0089] At Step 518, the HCP can be prompted to enter one or more e-mail preferences relating to telesurveillance features as another step in the telesurveillance activation process. One example embodiment of a GUI for configuring e-mail preferences relating to telesurveillance features is depicted in FIG. 6G. According to some embodiments, the e-mail preferences can include receiving a summary e-mail with all pending notification for all patients or receiving an e-mail every time a notification is triggered for a particular patient.

[0090] Upon completion of the aforementioned steps for the telesurveillance activation process by the HCP, the patient will be notified to complete a patient enrollment process. At Step 520, the HCP can view the status of the patient enrollment process until an indication is received that the patient enrollment is completed. One example embodiment of a GUI for displaying the status of the patient enrollment process is depicted in FIG. 6H.

[0091] It will be understood by those of skill in the art that, unless expressly stated so, the aforementioned steps can be performed in any order. As one non-limiting example, it will be understood by those of skill in the art that Step 510 (displaying the exclusion criteria) can be performed before Step 508 (inputting information for the patient profde). It will also be understood by those of skill in the art that, unless expressly stated so, each of the aforementioned methods can omit one or more steps, and by doing so, each method is still within the scope of the present disclosure.

[0092] FIGS. 6A to 6H are example embodiments of GUIs that can be used with methods for activating telesurveillance features in an analyte monitoring system, such as method 500 as described with respect to FIG 5. As an initial matter, it will be understood by those of skill in the art that any of the GUIs described herein can include software instructions stored in a memory of a computing device of an analyte monitoring system 100 (e.g., a reader 120, a local computer system 170, a trusted computer system 180), such that the instructions, when executed by one or more processors of the computing device, cause the one or more processors to display any one or more of the GUIs described herein. It will further be understood by those of skill in the art thatthe software instructions can be stored in memory on a different computing device than the computing device on which the GUI is displayed.

[0093] Referring first to FIG. 6A, GUI 600 depicts an interface from which an HCP can initiate an activation process for telesurveillance features in an analyte monitoring system in accordance with Step 506 of FIG. 5. According to some embodiments, GUI 600 can include a navigation bar 608 that includes a telesurveillance option. In some embodiments, when the telesurveillance option is selected, GUI 600 can further include a telesurveillance activation section including an activation button 602 and a “Learn More” button 604. In some embodiments, selecting the “Learn More” button 604 can provide more information to the HCP about the telesurveillance features. In addition, according to some embodiments, GUI 600 can include an informational section 606 that can include a plurality of links to documents containing related information. It will be understood by those of skill in the art that information provided through the “Learn More” button 604 and the informational section 606 can depend on the region determined at Step 504 of FIG. 5.

[0094] FIG. 6B depicts GUI 610 for receiving input from the HCP for a patient profile, which can be utilized with Step 508 of FIG. 5. In many embodiments, the patient profile can include one or more of the patient’s first name 612, the patient’s last name 614, the patient’s date of birth 616, the patient’s identification number (e.g., national identification number or social security number) 618, the patient’s e-mail address 620, and / or the patient’s mobile telephone number 622. In some embodiments, GUI 610 can further include a back button 626 and a next button 628 to allow the HCP to navigate between the various interfaces during the telesurveillance activation process. Similarly, GUI 610 can include a step indicator 624 to indicate to the HCP where they are in the telesurveillance activation process.

[0095] FIG. 6C depicts GUI 630 for displaying exclusion criteria, which can be utilized with Step 510 of FIG. 5. In many embodiments, GUI 630 can include a list of exclusion criteria 632 for the HCP to review. In this regard, the HCP can confirm that none of the exclusion criteria apply before continuing with the telesurveillance activation process. Furthermore, as described earlier, the list of exclusion criteria displayed can depend on the determined region of the HCP.

[0096] FIG. 6D depicts GUI 635 for receiving input from the HCP regarding the patient’s category and the patient’s level of care, which can be utilized with Step 512 of FIG. 5. In many embodiments, GUI 635 can include: a first option 637 to indicate that the patient is a Type 1 diabetic using insulin for over six months; a second option 639 to indicate that the patient is arecently diagnosed Type 1 diabetic; a third option 641 to indicate that the patient is a Type 2 diabetic. Those of skill in the art will recognize that other patient categories and levels of care can be presented as selectable options and are within the scope of the present disclosure.

[0097] FIG. 6E depicts GUI 645 for receiving prescription information of the patient, which can be utilized with Step 514 of FIG. 5. In many embodiments, the patient’s prescription information can include one or more of the patient’s home addresses 647, 649; the patient’s city 651; the patient’s state and ZIP code 653; and / or the patient’s diabetes diagnosis date 655. According to some embodiments, GUI 645 can also include an upload section 657 to allow the HCP to upload a prescription document (e.g., in a PDF, JPEG, PNG file format).

[0098] FIG. 6F depicts GUI 660 for including HCP-configurable threshold and notification settings for telesurveillance features, which can be utilized with Step 516 of FIG. 5. In many embodiments, the threshold settings can include one or more of a target glucose range 662; a low glucose threshold 664; and / or a high glucose threshold 666. In some embodiments, the target range 662 can include a first analyte concentration to represent the low end of the target range and a second analyte concentration to represent the high end of the target range. In some embodiments, the analyte concentration is a glucose concentration. Similarly, according to many embodiments, the notification settings can include one or more of a require all notifications option 668; an insufficient data notification option 670; and / or an insufficient sensor usage notification option 672. In some embodiments, the insufficient data notification option 670 can further include a settable percentage of data over a settable period of time. In some embodiments, the insufficient sensor usage notification option 672 can further include a settable minimum number of views / scans over a settable period of time. Those of skill in the art will recognize that other threshold and notification settings can be implemented and are within the scope of the present disclosure.

[0099] FIG. 6G depicts GUI 675 for receiving the HCP’s e-mail preferences relating to telesurveillance features, which can be utilized with Step 518 of FIG. 5. In many embodiments, GUI 675 can include a first option 677 for receiving a summary e-mail with all pending notifications for all patients according to a configurable schedule. In some embodiments, for example, the schedule can be on a daily basis, on a weekly basis, and / or on a monthly basis. In addition, in many embodiments, GUI 675 can include a second option 679 for receiving an e-mail every time a notification is triggered for a particular patient.

[0100] FIG. 6H depicts GUI 680 for displaying to the HCP a patient enrollment status relating to telesurveillance, which can be utilized with Step 520 of FIG. 5. In many embodiments, GUI 680 can include a patient enrollment status section 682 that provides a current status of the patient enrollment (e.g., pending, completed). In some embodiments, the patient enrollment status section 682 can also include instructions to provide to the patient. Furthermore, in many embodiments, GUI 680 can also include an informational section 684 including a plurality of downloadable documents relating to telesurveillance. In some embodiments, the plurality of downloadable documents can also include forms, such as a patient enrollment form, a patient prescription form, and / or a telesurveillance program checklist. Those of skill in the art will appreciate that other downloadable documents (e.g., instructions, tutorials, forms) can also be made available through informational section 684.

[0101] The software application may also have the capability of allowing users to view and download a log of events relating to a patient 702. As seen in FIG. 7, event log 704 in GUI 700 includes a list of events 706 related to the patient, an identifier of the person who performed or who is associated with the actions listed in the event 708, and the date that the events were performed 710. The events in the log can include, but are not limited to, viewing a patient profile, viewing a patient’s glucose history, telesurveillance, viewing and / or sending messages, viewing and / or downloading an event log, an in-person appointment, and a prescription. The identifier of the person 708 can include the person’s name or username. The log may be downloadable. The HCP could utilize the downloaded log of events to gain reimbursement.

[0102] It will be understood by those of skill in the art that any of the GUIs, reports interfaces, or portions thereof, as described herein, are meant to be illustrative only, and that the individual elements, or any combination of elements, depicted and / or described for a particular embodiment or figure are freely combinable with any elements, or any combination of elements, depicted and / or described with respect to any of the other embodiments.

[0103] It will also be understood by those of skill in the art that any of the GUIs, reports interfaces, or portions thereof, as described herein, can be implemented in an analyte monitoring system for monitoring one or more types of analytes. These analytes can include one or more of glucose, ketones, lactate, alcohol, or any other analytes that are detectable in a bodily fluid of the user. It will also be understood by those of skill in the art that the GUIs, reports interfaces, or portions thereof, as described herein, can incorporate data received from multiple analytemonitoring systems and devices relating thereto, including the incorporation of data from devices for taking ex vivo analyte measurements and / or physiological measurements.

[0104] It should be noted that all features, elements, components, functions, and steps described with respect to any embodiment provided herein are intended to be freely combinable and substitutable with those from any other embodiment. If a certain feature, element, component, function, or step is described with respect to only one embodiment, then it should be understood that that feature, element, component, function, or step can be used with every other embodiment described herein unless explicitly stated otherwise. This paragraph therefore serves as antecedent basis and written support for the introduction of claims, at any time, that combine features, elements, components, functions, and steps from different embodiments, or that substitute features, elements, components, functions, and steps from one embodiment with those of another, even if the following description does not explicitly state, in a particular instance, that such combinations or substitutions are possible. It is explicitly acknowledged that express recitation of every possible combination and substitution is overly burdensome, especially given that the permissibility of each and every such combination and substitution will be readily recognized by those of ordinary skill in the art.

[0105] While the embodiments are susceptible to various modifications and alternative forms, specific examples thereof have been shown in the drawings and are herein described in detail. It should be understood, however, that these embodiments are not to be limited to the particular form disclosed, but to the contrary, these embodiments are to cover all modifications, equivalents, and alternatives falling within the spirit of the disclosure. Furthermore, any features, functions, steps, or elements of the embodiments may be recited in or added to the claims, as well as negative limitations that define the inventive scope of the claims by features, functions, steps, or elements that are not within that scope.

[0106] Exemplary embodiments are set forth in the following numbered clauses:Clause 1. A system for managing analyte data of one or more patients, the system comprising: one or more servers, comprising: communications circuitry configured to receive, over a network, the analyte data of the one or more patients; a database for storing the received analyte data of the one or more patients;one or more processors; a memory coupled with the one or more processors, the memory configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to: initiate a user account creation process for a new user account; determine a region for the new user account; perform a first verification process in response to a determination of a first region for the new user account; perform a second verification process in response to a determination of a second region for the new user account; and display a home page for the new user account in response to a successful completion of either the first verification process or the second verification process.Clause 2. The system of clause 1, further comprising: one or more sensor control units configured to be worn on a body of a patient of the one or more patients, wherein each sensor control unit of the one or more sensor control units comprises: a glucose sensor, comprising: a proximal portion configured to be positioned above a skin surface and electrically coupled with sensor electronics; and a distal portion configured to be positioned under the skin surface and to sense an analyte level in a bodily fluid of a patient of the one or more patients; and the sensor electronics comprising wireless communications circuitry configured to transmit data to a reader device.Clause 3. The system of clause 2, further comprising the reader device, wherein the reader device is a smart phone.Clause 4. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises: sending a verification e-mail message to an e-mail address associated with the new user’s account; and receiving an indication that a verification button in the verification e-mail message was actuated.Clause 5. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises: sending a verification text message to a mobile phone number associated with the new user’s account; and receiving an indication that a verification link in the verification text message was actuated.Clause 6. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises linking the new user account with a social media account.Clause 7. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises: requesting a change to a social media account or a website associated with the new user account; and monitoring the social media account or the website to detect the requested change.Clause 8. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises: requesting an entry of a unique identifier; and requesting a verification of the unique identifier by a trusted third party.Clause 9. The system of any preceding clause, wherein either of the first verification process or the second verification process comprises: identifying a family member associated with the new user account; and displaying one or more questions relating to the identified family member.Clause 10. The system of any preceding clause, wherein the software instructions, when executed by the one or more processors, further cause the one or more processors to: receive a selection of a user account type for the new user account.Clause 11. The system of clause 10, wherein the user account type comprises one of a patient or a healthcare provider (HCP) account.Clause 12. The system of any preceding clause, wherein the software instructions, when executed by the one or more processors, further cause the one or more processors to:receive inputted account information for the new user account.Clause 13. The system of clause 12, wherein the inputted account information for the new account comprises one or more of: a user’s first name; a user’s last name; a user’s e-mail address; a user’s password; and a user’s healthcare organization.Clause 14. The system of any preceding clause, wherein the region is determined based on a user selection from a list of predetermined regions.Clause 15. The system of any preceding clause, wherein the region is determined without user intervention.Clause 16. The system of any preceding clause, wherein the region is further determined based on a location of the user.Clause 17. The system of any preceding clause, wherein the region is further determined using GPS data.Clause 18. The system of any preceding clause, wherein the region is further determined using geotargeting.Clause 19. The system of any preceding clause, wherein the new user account is for a patient of the one or more patients.Clause 20. The system of any preceding clause, wherein the new user account is for a healthcare provider (HCP) of the one or more patients.Clause 21. A system for managing analyte data of one or more patients, the system comprising: one or more servers, comprising: communications circuitry configured to receive, over a network, the analyte data of the one or more patients;a database for storing the received analyte data of the one or more patients; one or more processors; a memory coupled with the one or more processors, the memory configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to: initiate a healthcare provider (HCP) account creation or login process; determine if the HCP account is in a region indicated for telesurveillance; perform the following steps in response to a determination that the HCP account is in the region indicated for telesurveillance: display an option to activate telesurveillance features; receive inputted patient profile information; request confirmation of review of one or more exclusion criteria; and prompt a selection of a patient category and a patient level of care.Clause 22. The system of clause 21, further comprising: one or more sensor control units configured to be worn on a body of a patient of the one or more patients, wherein each sensor control unit of the one or more sensor control units comprises: a glucose sensor, comprising: a proximal portion configured to be positioned above a skin surface and electrically coupled with sensor electronics; and a distal portion configured to be positioned under the skin surface and to sense an analyte level in a bodily fluid of a patient of the one or more patients; and the sensor electronics comprising wireless communications circuitry configured to transmit data to a reader device.Clause 23. The system of clause 21 or 22, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, receive inputted prescription information.Clause 24. The system of clause 23, wherein the received inputted prescription information comprises a home address of a patient and a diabetes diagnosis date of the patient.Clause 25. The system of clause 24, wherein the received inputted prescription information further comprises an uploaded prescription document.Clause 26. The system of any of clauses 21 to 25, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, display threshold and notification settings.Clause 27. The system of clause 26, wherein the threshold and notification settings comprise one or more of: a target glucose range; a low glucose threshold; a high glucose threshold; an insufficient data notification option; and an insufficient sensor usage notification option.Clause 28. The system of any of clauses 21 to 27, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, prompt selection of an e-mail preference.Clause 29. The system of clause 28, wherein the selection of the e-mail preference comprises a selection of either: a summary e-mail of pending notification for all patient according to a configurable schedule; or an e-mail for each triggered notification of a patient.Clause 30. The system of any of clauses 21 to 29, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, display a patient enrollment status interface.Clause 31 . The system of any of clauses 21 to 30, wherein the inputted patient profile information comprises one or more of: a first name of a patient; a last name of the patient; an identification number of the patient; an e-mail address of the patient; and a phone number of the patient.Clause 32. The system of clause 31, wherein the identification number of the patient is a social security number.Clause 33. The system of clause 31, wherein the identification number of the patient is a national identification number.Clause 34. The system of any of clauses 21 to 33, wherein the one or more exclusion criteria comprises one or more of: a patient’s physical or mental inability to use telesurveillance features; chronic dialysis; severe liver failure; a life expectancy of less than twelve (12) months; a patient’s refusal to receive treatment; and an absence of a fixed place of residence.Clause 35. The system of any of clauses 21 to 34, wherein the selection of the patient category and the patient level of care comprises selection of either: a first option to indicating a Type 1 diabetic using insulin for over six months; a second option indicating a recently diagnosed Type 1 diabetic; or a third option indicating a Type 2 diabetic.

Claims

What is claimed is:

1. A system for managing analyte data of one or more patients, the system comprising: one or more servers, comprising: communications circuitry configured to receive, over a network, the analyte data of the one or more patients; a database for storing the received analyte data of the one or more patients; one or more processors; a memory coupled with the one or more processors, the memory configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to: initiate a user account creation process for a new user account; determine a region for the new user account; perform a first verification process in response to a determination of a first region for the new user account; perform a second verification process in response to a determination of a second region for the new user account; and display a home page for the new user account in response to a successful completion of either the first verification process or the second verification process.

2. The system of claim 1, further comprising: one or more sensor control units configured to be worn on a body of a patient of the one or more patients, wherein each sensor control unit of the one or more sensor control units comprises: a glucose sensor, comprising: a proximal portion configured to be positioned above a skin surface and electrically coupled with sensor electronics; anda distal portion configured to be positioned under the skin surface and to sense an analyte level in a bodily fluid of a patient of the one or more patients; and the sensor electronics comprising wireless communications circuitry configured to transmit data to a reader device.

3. The system of claim 2, further comprising the reader device, wherein the reader device is a smart phone.

4. The system of claim 1, wherein either of the first verification process or the second verification process comprises: sending a verification e-mail message to an e-mail address associated with the new user’s account; and receiving an indication that a verification button in the verification e-mail message was actuated.

5. The system of claim 1, wherein either of the first verification process or the second verification process comprises: sending a verification text message to a mobile phone number associated with the new user’s account; and receiving an indication that a verification link in the verification text message was actuated.

6. The system of claim 1, wherein either of the first verification process or the second verification process comprises linking the new user account with a social media account.

7. The system of claim 1, wherein either of the first verification process or the second verification process comprises: requesting a change to a social media account or a website associated with the new user account; and monitoring the social media account or the website to detect the requested change.

8. The system of claim 1, wherein either of the first verification process or the second verification process comprises: requesting an entry of a unique identifier; and requesting a verification of the unique identifier by a trusted third party.

9. The system of claim 1 , wherein either of the first verification process or the second verification process comprises: identifying a family member associated with the new user account; and displaying one or more questions relating to the identified family member.

10. The system of claim 1, wherein the software instructions, when executed by the one or more processors, further cause the one or more processors to: receive a selection of a user account type for the new user account.

11. The system of claim 10, wherein the user account type comprises one of a patient or a healthcare provider (HCP) account.

12. The system of claim 1, wherein the software instructions, when executed by the one or more processors, further cause the one or more processors to: receive inputted account information for the new user account.

13. The system of claim 12, wherein the inputted account information for the new account comprises one or more of: a user’s first name; a user’s last name; a user’s e-mail address; a user’s password; and a user’s healthcare organization.

14. The system of claim 1, wherein the region is determined based on a user selection from a list of predetermined regions.

15. The system of claim 14, wherein the region is determined without user intervention.

16. The system of claim 15, wherein the region is further determined based on a location of the user.

17. The system of claim 16, wherein the region is further determined using GPS data.

18. The system of claim 16, wherein the region is further determined using geotargeting.

19. The system of claim 1, wherein the new user account is for a patient of the one or more patients.

20. The system of claim 1, wherein the new user account is for a healthcare provider (HCP) of the one or more patients.

21. A system for managing analyte data of one or more patients, the system comprising: one or more servers, comprising: communications circuitry configured to receive, over a network, the analyte data of the one or more patients; a database for storing the received analyte data of the one or more patients; one or more processors; a memory coupled with the one or more processors, the memory configured to store software instructions that, when executed by the one or more processors, cause the one or more processors to: initiate a healthcare provider (HCP) account creation or login process; determine if the HCP account is in a region indicated for telesurveillance; perform the following steps in response to a determination that the HCP account is in the region indicated for telesurveillance: display an option to activate telesurveillance features; receive inputted patient profile information; request confirmation of review of one or more exclusion criteria; and prompt a selection of a patient category and a patient level of care.

22. The system of claim 21, further comprising:one or more sensor control units configured to be worn on a body of a patient of the one or more patients, wherein each sensor control unit of the one or more sensor control units comprises: a glucose sensor, comprising: a proximal portion configured to be positioned above a skin surface and electrically coupled with sensor electronics; and a distal portion configured to be positioned under the skin surface and to sense an analyte level in a bodily fluid of a patient of the one or more patients; and the sensor electronics comprising wireless communications circuitry configured to transmit data to a reader device.

23. The system of claim 21, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, receive inputted prescription information.

24. The system of claim 23, wherein the received inputted prescription information comprises a home address of a patient and a diabetes diagnosis date of the patient.

25. The system of claim 24, wherein the received inputted prescription information further comprises an uploaded prescription document.

26. The system of claim 21, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, display threshold and notification settings.

27. The system of claim 26, wherein the threshold and notification settings comprise one or more of: a target glucose range; a low glucose threshold; a high glucose threshold; an insufficient data notification option; and an insufficient sensor usage notification option.

28. The system of claim 21, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, prompt selection of an e-mail preference.

29. The system of claim 28, wherein the selection of the e-mail preference comprises a selection of either: a summary e-mail of pending notification for all patient according to a configurable schedule; or an e-mail for each triggered notification of a patient.

30. The system of claim 21, wherein the software instructions, when executed by the one or more processors, cause the one or more processors to, in response to the determination that the HCP account is in the region indicated for telesurveillance, display a patient enrollment status interface.

31. The system of claim 21, wherein the inputted patient profile information comprises one or more of: a first name of a patient; a last name of the patient; an identification number of the patient; an e-mail address of the patient; and a phone number of the patient.

32. The system of claim 31, wherein the identification number of the patient is a social security number.

33. The system of claim 31, wherein the identification number of the patient is a national identification number.

34. The system of claim 21, wherein the one or more exclusion criteria comprises one or more of: a patient’s physical or mental inability to use telesurveillance features; chronic dialysis; severe liver failure; a life expectancy of less than twelve (12) months; a patient’s refusal to receive treatment; and an absence of a fixed place of residence.

35. The system of claim 21, wherein the selection of the patient category and the patient level of care comprises selection of either: a first option to indicating a Type 1 diabeticusing insulin for over six months; a second option indicating a recently diagnosed Type 1 diabetic; or a third option indicating a Type 2 diabetic.

Images