Easier access to specimen data

Abstract

Embodiments described herein include glucose monitoring systems configured to use various methods and additional systems to facilitate communication of glucose data from data receiving devices that do not have wireless network capabilities. Certain embodiments facilitate communication of data to general purpose devices, user devices, and electronic medical record (EMR) systems. Certain embodiments facilitate communication of data to report generation systems that interpret the data and provide reports based on the glucose data. Certain embodiments relate to techniques for facilitating integration of EMR system data management and report generation.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 63 / 328,078, filed April 6, 2022, which is hereby incorporated by reference in its entirety.

[0002] The subject matter described herein relates to systems and devices for receiving data, and methods of controlling systems and devices for receiving data relating to the operation of a handheld device, for example forming part of an in-vivo analyte monitor system. [Background technology]

[0003] Frequent monitoring and management of analyte levels, such as glucose, ketones, lactate, oxygen, or hemoglobin A1C, can improve the overall health of people, especially those with diabetes. As an example, diabetic patients are generally required to monitor their glucose levels to ensure that their glucose levels are maintained within a clinically safe range, and can use that information to determine when they need insulin to manage their glucose levels in the body or when they need glucose to increase their glucose levels in the body. Clinical data reveals a strong correlation between the frequency of glucose monitoring and glycemic control. However, despite such correlation, many individuals diagnosed with diabetic disease do not monitor their glucose levels as frequently as they should due to a combination of factors including convenience, discretion in testing, pain associated with glucose testing, and cost.

[0004] To increase patient adherence to a frequent glucose monitoring regimen, an in-vivo analyte monitoring system can be utilized on the body of an individual requiring analyte monitoring, in which a sensor control device can be worn. To increase comfort and convenience for the individual, the sensor control device can have a small form factor and can be assembled and applied by the individual using a sensor applicator. The application process includes inserting a sensor, such as an in-vivo sensor that senses a user's analyte level in a bodily fluid located at the dermal layer of the human body, using an applicator or insertion feature such that the sensor is in contact with the bodily fluid. The sensor control device can also be configured to transmit analyte data to one or more data receiving devices, from which the individual, her healthcare provider ("HCP"), or others can review the data and make treatment decisions.

[0005] In-vivo analyte monitor systems can be broadly categorized based on the manner in which data is communicated between the reader device and the sensor controlling device. One type of in-vivo system is a "continuous analyte monitor" system in which data can be continuously broadcast from the sensor controlling device to the data receiving device without prompting, for example, in an automated manner according to a broadcast schedule. Another type of in-vivo system is a "flash analyte monitor" system in which data can be communicated from the sensor controlling device, such as using near field communication (NFC) or radio frequency identification (RFID) protocols, in response to a scan or request for data by the data receiving device. The data receiving device can include various hardware components that allow for processing of the analyte data received from the sensor controlling device, and must include electrical communication components that allow for communication with the sensor controlling device. The data receiving device can further include additional testing or transmission hardware to assist individuals or their HCPs in making treatment decisions.

[0006] The data receiving device may be designed with limited features to control cost and complexity. Thus, the data receiving device may lack wide area networking capabilities that would facilitate communicating data from the data receiver to a central application server. The central application server is often used to analyze data at a patient level as well as to analyze larger trends in patient data. Instead of simple wireless connectivity, the data receiving device may connect to a user device, such as a laptop computer, using a wired connection. The user device then relays the relevant data to a remote server. However, providing a wired connection between the data receiving device and the user device may be cumbersome and inconvenient. For example, software updates on either device may require updating drivers to ensure the connection is stable and secure. In addition, patients visiting their HCP who wish to utilize the reports must remember to upload their data prior to their appointment. In addition, users are often required to enter account credentials such as username, user id, password, etc. in order for data from their data receiving device to be uploaded to the application server for processing and made available to their HCP. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] US Patent Application Publication No. 2013 / 0150691 [Patent Document 2] US Patent Application Publication No. 2021 / 0204841 [Patent Document 3] International Publication No. 2018 / 136898 [Patent Document 4] International Publication No. 2019 / 236850 [Patent Document 5] International Publication No. 2019 / 236859 [Patent Document 6] International Publication No. 2019 / 236876 [Patent Document 7] US Patent Application Publication No. 2020 / 0196919 [Patent Document 8] US Patent Application Publication No. 2016 / 0331283 [Patent Document 9] US Patent Application Publication No. 2018 / 0235520 [Patent Document 10] US Patent Application Publication No. 2014 / 0171771 [Patent Document 11] US Patent Application Publication No. 2010 / 00230285 [Patent Document 12] US Patent Application Publication No. 2019 / 0274598 Summary of the Invention [Problem to be solved by the invention]

[0008] It would therefore be beneficial to incorporate alternative methods for retrieving specimen data from a data receiving device so that the specimen data can be used to generate reports or be interpreted by an HCP or other user, and in particular, it would be beneficial to incorporate a method for retrieving specimen data from a data receiving device without requiring a wired connection to the user device, a wireless connection of the data receiving device to an application server, or for any user to have an account with the application server. [Means for solving the problem]

[0009] The objects and advantages of the presently disclosed subject matter will be set forth in and apparent from the description which follows, as well as being learned by practice of the presently disclosed subject matter. Additional advantages of the presently disclosed subject matter will be realized and attained by the methods and systems particularly pointed out in the description and claims hereof, as well as from the drawings.

[0010] Examples described herein include analyte monitoring systems and methods and operations performed thereby. Exemplary analyte monitoring systems can be configured to use various methods and additional systems to facilitate communication of analyte data from data receiving devices that do not have wireless network capabilities. In certain examples, the analyte is glucose. In examples where a particular analyte is to be monitored and the data relates to such a particular analyte, the analyte monitoring system may be referred to as a monitor system for that analyte. For example, where the analyte is glucose, the analyte monitoring system may be referred to as a glucose monitoring system without departing from the scope of the disclosure herein relating to the analyte monitoring system. Optionally, the analyte monitoring system may include an analyte sensor. Optionally, the analyte sensor may form part of a sensor control device of the analyte monitoring system. For example, where the analyte being monitored is glucose, the glucose monitoring system may optionally include a glucose sensor. Optionally, the glucose sensor may form part of a sensor control device of the glucose monitoring system.

[0011] Certain examples facilitate the transmission of data to general purpose devices, user devices, and electronic medical record (EMR) systems. Certain examples facilitate the transmission of data to report generation systems that interpret the data and reports provided based on the specimen data. Certain examples relate to techniques for facilitating the integration of EMR system data management and report generation. In all instances where data is transmitted to systems other than the personal data receiving device (including the specimen data receiving device, the general purpose device, and the user device as described herein), the data may be transmitted to a server computing device (generally referred to as a "server") operated by and embodying the functionality of these systems. For purposes of ease of understanding and clarity, the present disclosure will in each instance describe the transmission of data to and from these systems, rather than explicitly describing the transmission of data to and from servers operated by and embodying the functionality of these systems. Thus, when the present disclosure describes, for example, the transmission of data to or from specimen monitoring systems, EMR systems, report generation systems, and components thereof, the present disclosure contemplates the transmission of data to or from servers operated by and embodying the functionality of these systems, respectively.

[0012] To achieve these and other advantages in accordance with the objectives of the presently disclosed subject matter, as embodied and broadly described, the presently disclosed subject matter includes systems and devices for receiving and processing data in an analyte monitor system, and methods for controlling these systems and devices. Exemplary systems and methods can include a server computing device of a glucose monitor system. The server computing device includes one or more processors and a memory in communication with the one or more processors storing instructions configured, when executed by the one or more processors, to cause the one or more processors to perform operations. The operations can include receiving a request from an electronic medical record (EMR) system to establish a connection between a patient record set stored by the EMR system and associated with the patient and a patient record set stored by the glucose monitor system and associated with the patient. The request can include patient identification information. The operations can include comparing the patient identification information received with the request to patient identification information stored by the glucose monitor system. The operations can include, in response to determining based on the comparison that a patient record set stored by the glucose monitoring system and associated with the patient exists, generating an association between the patient record set stored by the EMR system and associated with the patient and sending a confirmation of the association to the EMR system. In response to determining based on the comparison that a patient record set stored by the glucose monitoring system does not exist, sending a notification to the EMR system that the request to establish a connection cannot be completed. In some examples, the patient identification information includes a patient name, a patient date of birth, a patient address, a patient email address, a patient telephone number, or a patient health care provider information. In some examples, the patient identification information includes a patient identification code that is a unique identifier for the patient within the EMR system.In some examples, the operations can include determining that new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient is available, and sending the new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient to the EMR system. In some examples, the operations can include requesting patient data associated with the patient record set stored by the EMR system and associated with the patient from the EMR system, and receiving a message from the EMR system in lieu of the requested patient data indicating that new patient data associated with the patient record set stored by the EMR system and associated with the patient is not available. In some examples, the operations can include receiving a request from the EMR system for new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient, determining that new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient is not available, and sending a message to the EMR system in lieu of the requested patient data indicating that new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient is not available. In some examples, the operations may optionally include, after confirmation of the association, generating, by an account access code service, an access code associated with the patient record set stored by the glucose monitoring system and associated with the patient, and sending the access code associated with the confirmation of the association to the EMR system. In some examples, the access code acts as or is interpreted as a confirmation of the association. In some examples, the access code is transmitted along with the confirmation of the association. In some examples, the operations may optionally include, after confirmation of the association, sending, to the EMR system, glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient.In some examples, the patient data associated with the patient record set stored by the EMR system and associated with the patient is new patient data received from the EMR system as new patient data becomes available.

[0013] In some examples, the operations can optionally include periodically sending glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient to the EMR system after confirmation of the association. In some examples, the operations can optionally include periodically receiving patient data associated with the patient record set stored by the EMR system and associated with the patient from the EMR system after confirmation of the association. In some examples, the request to establish a connection further includes an access code generated by an account access code service. The operations can further include, prior to sending confirmation of the association, determining with the account access code service that an access code is associated with the patient record set stored by the glucose monitoring system and associated with the patient, and determining validity of the access code with the account access code service. In some examples, the access code is configured to be valid for a predetermined period of time. In some examples, the notification that the request to establish a connection cannot be completed further includes instructions to establish the connection. In some examples, the operations further include, following sending confirmation of association, the server computing device receiving from the EMR system a request to access a report generated based on the glucose data stored by the glucose monitoring system and stored in a patient record set associated with the patient, the server computing device generating the requested report using a report generating system, and the server computing device sending the generated report to the EMR system. In some examples, the request to access the report identifies the glucose data for which the report is requested. In some examples, the operations can include requesting from the EMR system the latest patient data associated with the patient record set stored by the EMR system and associated with the patient, and receiving from the EMR system the latest patient data associated with the patient record set stored by the EMR system and associated with the patient, wherein the requested report is generated based on the latest patient data.In some examples, the operations further include identifying glucose data to be included in the request report based on a date stamp or time stamp associated with the identified glucose data.

[0014] In accordance with another aspect of the subject matter of the present disclosure, a system and method includes a method for establishing a connection or association between a patient record set stored by an EMR system and associated with the patient and a patient record set stored by a glucose monitoring system. The method can include receiving a request from an electronic medical record (EMR) system to establish a connection between a patient record set stored by the EMR system and associated with the patient and a patient record set stored by the glucose monitoring system and associated with the patient. The request can include patient identification information. The method can include comparing the patient identification information received with the request to the patient identification information stored by the glucose monitoring system. The method can include, in response to determining based on the comparison that a patient record set stored by the glucose monitoring system and associated with the patient exists, generating an association between the patient record set stored by the EMR system and associated with the patient and the patient record set stored by the glucose monitoring system and associated with the patient, and sending a confirmation of the association to the EMR system. The method can include, in response to determining based on the comparison that a patient record set stored by the glucose monitoring system does not exist, sending a notification to the EMR system that the request to establish the connection cannot be completed. In some examples, the patient identification information includes a patient name, a patient's date of birth, a patient's address, a patient's email address, a patient's phone number, or the patient's healthcare provider information. In some examples, the patient identification information includes a patient identification code that is a unique identifier for the patient within the EMR system. In some examples, the method may include determining that new glucose data is available that is associated with a patient record set stored by the glucose monitoring system and associated with the patient, and sending the new glucose data to the EMR system that is associated with the patient record set that is stored by the glucose monitoring system and associated with the patient.In some examples, the method may include requesting from the EMR system patient data associated with a patient record set stored by the EMR system and associated with the patient, and receiving a message from the EMR system in lieu of the requested patient data indicating that new patient data associated with the patient record set stored by the EMR system and associated with the patient is not available. In some examples, the method may include receiving from the EMR system a request for new glucose data associated with a patient record set stored by the glucose monitoring system and associated with the patient, determining that new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient is not available, and sending a message to the EMR system in lieu of the requested patient data indicating that new glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient is not available. In some examples, the method may include generating, by an account access code service, an access code associated with the patient record set stored by the glucose monitoring system and associated with the patient, and sending an access code associated with the confirmation of the association to the EMR system. In some examples, the method may include periodically sending glucose data associated with the patient record set stored by the glucose monitoring system and associated with the patient to the EMR system. In some examples, the patient data associated with the patient record set stored by the EMR system and associated with the patient is new patient data received from the EMR system as new patient data becomes available.

[0015] In some examples, the method can include periodically sending glucose data associated with a patient record set stored by the glucose monitoring system and associated with the patient to the EMR system. In some examples, the method can include periodically receiving patient data associated with a patient record set stored by the EMR system and associated with the patient from the EMR system. In some examples, the request to establish a connection further includes an access code generated by an account access code service. The method can further include, prior to sending confirmation of the association, determining with the account access code service that an access code is associated with a patient record set stored by the glucose monitoring system and associated with the patient, and determining validity of the access code with the account access code service. In some examples, the access code is configured to be valid for a predetermined period of time. In some examples, the notification that the request to establish a connection cannot be completed further includes instructions to establish the connection. In some examples, the method may further include, following sending confirmation of association, the server computing device receiving from the EMR system a request to access a report generated based on glucose data stored by the glucose monitoring system and stored in a patient record set associated with the patient, the server computing device generating the requested report using a report generating system, and the server computing device sending the generated report to the EMR system. In some examples, the request to access the report identifies the glucose data for which the report is requested. In some examples, the method may include requesting from the EMR system the latest patient data associated with the patient record set stored by the EMR system and associated with the patient, and receiving from the EMR system the latest patient data associated with the patient record set stored by the EMR system and associated with the patient, wherein the requested report is generated based on the latest patient data.In some examples, the method may further include identifying glucose data to be included in the request report based on a date stamp or time stamp associated with the identified glucose data.

[0016] In accordance with another aspect of the presently disclosed subject matter, a system and method includes a server computing device of a glucose monitor system. The server computing device includes one or more processors and a memory in communication with the one or more processors, the memory storing instructions configured to cause the one or more processors to perform operations when executed by the one or more processors. The operations can include receiving a first web request from a general-purpose device of the glucose monitor system, the first web request including one or more parameters. The one or more parameters include glucose data associated with a user of the glucose monitor system. The operations can include generating a report based on the received glucose data. The operations can include associating an access code with the report. The operations can include receiving a second web request including one or more parameters. The one or more parameters include an access code. The operations can include retrieving the report based on the access code. The operations can include outputting the report on a display. In some examples, the operations can include sending the access code to the general-purpose device in response to receiving the first web request. In some examples, the second web request is received from a computing device associated with an electronic medical record (EMR) system. In some examples, the second web request is received from a general-purpose device. In some examples, the second web request is received from a computing device associated with a user of the glucose monitoring system. In some examples, the first web request is sent by the general-purpose device following scanning of the matrix barcode. In some examples, the one or more parameters further include a device identifier associated with the general-purpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user.

[0017] According to another aspect of the presently disclosed subject matter, systems and methods include a method of providing access to a glucose report. The method can include receiving a first web request from a general-purpose device of a glucose monitoring system, the first web request including one or more parameters. The one or more parameters include glucose data associated with a user of the glucose monitoring system. The method can include generating a report based on the received glucose data. The method can include associating an access code with the report. The method can include receiving a second web request including one or more parameters. The one or more parameters can include an access code. The method can include retrieving the report based on the access code. The method can include outputting the report on a display. In some examples, the method can include sending the access code to the general-purpose device in response to receiving the first web request. In some examples, the second web request is received from a computing device associated with an electronic medical record (EMR) system. In some examples, the second web request is received from a general-purpose device. In some examples, the second web request is received from a computing device associated with a user of the glucose monitoring system. In some examples, the first web request is sent by the general-purpose device following scanning of the matrix barcode. In some examples, the one or more parameters further include a device identifier associated with the general-purpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user.

[0018] According to another aspect of the presently disclosed subject matter, a system and method includes a data receiving device of a glucose monitor system. The data receiving device can include a display, one or more processors, and a memory in communication with the one or more processors, the memory storing instructions for causing the one or more processors to perform operations. The operations can include accepting a request from a user of the glucose monitor system to communicate glucose data associated with the user to another computing device. The operations can include encoding the glucose data. The operations can include generating a matrix barcode including a uniform resource locator (URL) and a glucose data code. The glucose data can be formatted as a parameter passed with the URL by a web browser. The operations can include providing the matrix barcode on a display. In some examples, the operations can include selecting glucose data for encoding based on glucose data corresponding to a predetermined time range. In some examples, the operations can include calculating one or more derived values ​​from the glucose data and encoding the derived values ​​with the glucose data. In some examples, encoding the glucose data can include reducing an accuracy level associated with the glucose data. The accuracy level can be selected based on an actual value of the glucose data. In some examples, the data receiving device is not configured for wireless communication. In some examples, the operations can include generating a report element for the glucose report based on the glucose data. In some examples, the operations can include encoding a report element for the glucose report. The matrix barcode can further include the encoded glucose report element.

[0019] According to another aspect of the presently disclosed subject matter, the system and method include generating a matrix barcode by a data receiving device of a glucose monitor system. The method can include accepting a request from a user of the glucose monitor system to communicate glucose data associated with the user to another computing device. The method can include encoding the glucose data. The method can include generating a matrix barcode including a uniform resource locator (URL) and a glucose data code. The glucose data can be formatted as a parameter passed with the URL by a web browser. The method can include providing the matrix barcode on a display. In some examples, the method can include selecting glucose data for encoding based on glucose data corresponding to a predetermined time range. In some examples, the method can include calculating one or more derived values ​​from the glucose data and encoding the derived values ​​with the glucose data. In some examples, encoding the glucose data can include reducing a level of accuracy associated with the glucose data. The level of accuracy can be selected based on an actual value of the glucose data. In some examples, the data receiving device is not configured for wireless communication. In some examples, the method can include generating a report element for a glucose report based on the glucose data. In some examples, the method can include encoding a reporting element for glucose reporting. The matrix barcode can further include the encoded glucose reporting element.

[0020] According to another aspect of the subject matter of the present disclosure, a system and method includes a multi-purpose device of a glucose monitor system. The multi-purpose device can include a camera, a display, one or more processors, and a memory in communication with the one or more processors, the memory storing instructions for causing the one or more processors to perform operations. The operations can include scanning a matrix barcode through the camera. The operations can include decoding the matrix barcode to obtain a uniform resource locator (URL) and one or more parameters. The one or more parameters can include at least glucose data. The operations can include submitting a web request to a server associated with the URL using the URL and the one or more parameters. The operations can include receiving, by the multi-purpose device, an access code associated with the one or more parameters from a user device associated with the user. The operations can include outputting the access code through the display. In some examples, the server associated with the URL is further associated with the glucose monitor system. In some examples, the access code is a temporary one-time password associated by the server with the one or more parameters. In some examples, the access code is configured to expire after a predetermined period of time. In some examples, the operations can include receiving, by the general-purpose device, a report from a server associated with the URL based on the glucose data contained within the parameters. The report can be generated by the server based on the parameters indicated with the URL. The operations can include outputting the report via a display. In some examples, the matrix barcode is generated and displayed by a data receiving device of the glucose monitoring system, and the one or more parameters include a device identifier associated with the general-purpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user. In some examples, the data receiving device is not configured for wireless communication.

[0021] According to another aspect of the subject matter of the present disclosure, the system and method include a method for generating an access code. The method can include scanning a matrix barcode through a camera. The method can include decoding the matrix barcode to obtain a uniform resource locator (URL) and one or more parameters. The one or more parameters can include at least glucose data. The method can include submitting a web request to a server associated with the URL using the URL and the one or more parameters. The method can include receiving an access code associated with the one or more parameters by the general-purpose device from a user device associated with the user. The method can include outputting the access code through a display. In some examples, the server associated with the URL is further associated with a glucose monitor system. In some examples, the access code is a temporary one-time password associated with the one or more parameters by the server. In some examples, the access code is configured to expire after a predetermined period of time. In some examples, the method can include receiving, by the general-purpose device, a report from a server associated with the URL based on the glucose data included in the parameters. The report can be generated by the server based on the parameters indicated with the URL. The method can include outputting the report through a display. In some examples, the matrix barcode is generated and displayed by a data receiving device of the glucose monitoring system, and the one or more parameters include a device identifier associated with the general purpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user. In some examples, the data receiving device is not configured for wireless communication.

[0022] According to another aspect of the presently disclosed subject matter, a system and method includes a glucose monitor system. The glucose monitor system includes one or more processors and a memory in communication with the one or more processors, the memory storing instructions configured to cause the one or more processors to perform operations when executed by the one or more processors. The operations can include establishing a communication session between the glucose monitor system and an electronic medical record (EMR) system. The operations can include identifying therapy information associated with a user and stored in the EMR system. The operations can include communicating the therapy information associated with the user from the EMR system to an application server. The operations can include converting the therapy information for use by the glucose monitor system. The operations can include storing the converted therapy information in a database accessible to the glucose monitor system. The operations can include displaying the therapy information to a user of the glucose monitor system. In some examples, the therapy information is stored in a first structured format, and converting the therapy information includes mapping the first structured format to a second structured format associated with the glucose monitor system. In some examples, the therapy information is stored in a free text format, and converting the therapy information includes interpreting the therapy information using natural language processing and storing the information in a structured format associated with the glucose monitor system. In some examples, the operations include receiving the additional therapy information through a structured format input, converting the additional therapy information for use by the EMR system, and communicating the converted additional therapy information to the EMR system for storage.

[0023] According to another aspect of the presently disclosed subject matter, a system and method includes a method of receiving and storing therapy information for use by a glucose monitoring system. The method can include establishing a communication session between a glucose monitoring system and an electronic medical record (EMR) system. The method can include identifying therapy information associated with a user and stored in the EMR system. The method can include communicating the therapy information associated with the user from the EMR system to an application server. The method can include converting the therapy information for use by the glucose monitoring system. The method can include storing the converted therapy information in a database accessible to the glucose monitoring system. The method can include displaying the therapy information to a user of the glucose monitoring system. In some examples, the therapy information is stored in a first structured format, and converting the therapy information includes mapping the first structured format to a second structured format associated with the glucose monitoring system. In some examples, the therapy information is stored in a free text format, and converting the therapy information includes interpreting the therapy information using natural language processing and storing the information in a structured format associated with the glucose monitoring system. In some examples, the method includes receiving additional therapy information through a structured format input, converting the additional therapy information for use by the EMR system, and communicating the converted additional therapy information to the EMR system for storage.

[0024] According to another aspect of the presently disclosed subject matter, a system and method includes a glucose monitor system. The glucose monitor system includes one or more processors and a memory in communication with the one or more processors, the memory storing instructions configured to cause the one or more processors to perform operations when executed by the one or more processors. The operations can include establishing a communication session between the glucose monitor system and an electronic medical record (EMR) system. The operations can include receiving a request from a user device for the EMR system to access glucose data stored in a database associated with the patient and accessible to the glucose monitor system. The operations can include causing a multi-purpose device associated with the glucose monitor system and the patient to display an access code associated with the glucose data associated with the patient. The operations can include receiving a second access code from the user device. The access code associated with the glucose data associated with the patient may be referred to herein as a first access code and the access code from the user device may be referred to as a second access code. The operations can include comparing the access code displayed by the multi-purpose device to the second access code. The operations may include granting access to the EMR system to access glucose data associated with the patient in response to determining that the access code displayed by the multi-purpose device and the second access code are equivalent. In some examples, the access code is generated by the multi-purpose device and the glucose monitoring system receives the access code from the multi-purpose device. In some examples, the access code is generated by the glucose monitoring system and the multi-purpose device receives the access code from the glucose monitoring system. In some examples, the operations may include causing the multi-purpose device to display an authorization request and in response to an affirmative response to the authorization request, access is granted to the EMR system. In some examples, one or more of the access code and the second access code include a matrix barcode.

[0025] In accordance with another aspect of the subject matter of the present disclosure, a system and method includes a method for receiving and storing therapy information for use by a glucose monitoring system. The method can include establishing a communication session between the glucose monitoring system and an electronic medical record (EMR) system. The method can include receiving a request from a user device for the EMR system to access glucose data stored in a database associated with the patient and accessible to the glucose monitoring system. The method can include causing the glucose monitoring system and a multi-purpose device associated with the patient to display an access code associated with the glucose data associated with the patient. The method can include receiving a second access code from the user device. The method can include comparing the access code displayed by the multi-purpose device with the second access code. The method can include granting access to the EMR system to access the glucose data associated with the patient in response to determining that the access code displayed by the multi-purpose device and the second access code are equivalent. In some examples, the access code is generated by the multi-purpose device and the glucose monitoring system receives the access code from the multi-purpose device. In some examples, the access code is generated by the glucose monitoring system and the multi-purpose device receives the access code from the glucose monitoring system. In some examples, the operating includes causing the multi-purpose device to display an authorization request, and in response to an affirmative response to the authorization request, access is granted to the EMR system. In some examples, one or more of the access code and the second access code include a matrix barcode.

[0026] Other systems, methods, features, and advantages of the subject matter described herein will be or become apparent to one with skill in the art upon examination of the following figure description and detailed description. All such additional systems, methods, features, and advantages are intended to be included within this specification, be within the scope of the subject matter described herein, and be protected by the accompanying claims. Features of the examples should in no way be construed as limiting the scope of the appended claims unless an explicit recitation of that feature appears in the claim. [Brief description of the drawings]

[0027] Details of the subject matter presented herein, both as to structure and operation, will be apparent from consideration of the accompanying drawings, in which like reference numerals indicate like parts. The components in these figures are not necessarily to scale, with emphasis instead being placed upon illustrating the principles of the inventive subject matter. Moreover, all illustrative examples are intended to convey design concepts, and relative sizes, shapes, and other detailed attributes may be illustrated generally, rather than precisely or precisely.

[0028] [Figure 1A] 1 is a system schematic diagram of a sensor applicator, a reader device, a monitor system, a network, and a remote system. [Figure 1B] FIG. 1 illustrates an operating environment of an exemplary analyte monitoring system suitable for use with the technology described herein. [Figure 2A] FIG. 2 is a block diagram illustrating an exemplary embodiment of a reader device. [Figure 2B] FIG. 2 is a block diagram illustrating an example data receiving device for communicating with a sensor in accordance with an illustrative embodiment of the presently disclosed subject matter. [Figure 2C] FIG. 2 is a block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 2D] FIG. 2 is a block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 2E] 1 is a block diagram illustrating an exemplary analyte sensor in accordance with an illustrative embodiment of the presently disclosed subject matter. [Figure 3A] FIG. 1 is a close-up perspective view depicting an exemplary embodiment in which a user prepares a tray for assembly. [Figure 3B] 11A-11C are side views depicting an exemplary embodiment of a user preparing the applicator device for assembly. [Figure 3C] FIG. 13 is a close-up perspective view depicting an exemplary embodiment in which a user inserts an applicator device into a tray during assembly. [Figure 3D] 13 is a close-up perspective view depicting an exemplary embodiment in which a user removes the applicator device from a tray during assembly. [Figure 3E] FIG. 1 is a close-up perspective view depicting an exemplary embodiment in which a patient applies a sensor with an applicator device. [Figure 3F] FIG. 1 is a close-up perspective view depicting an exemplary embodiment of a patient with an applied sensor and a used applicator device. [Figure 4A] 1 is a side view depicting an exemplary embodiment of an applicator device coupled to a cap. [Figure 4B] 1 is a side perspective view depicting an exemplary embodiment of an applicator device and cap separated. [Figure 4C] 1 is a perspective view depicting an exemplary embodiment of a distal end of an applicator device and an electronics housing. [Figure 4D] 1 is a top perspective view of an illustrative applicator device in accordance with the presently disclosed subject matter. [Figure 4E] FIG. 4E is a bottom perspective view of the applicator device of FIG. 4D. [Figure 4F] FIG. 4E is an exploded view of the applicator device of FIG. 4D. [Figure 4G] FIG. 4E is a side cutaway view of the applicator device of FIG. 4D. [Diagram 5] FIG. 1 is a close-up perspective view depicting an exemplary embodiment of a tray with a sterilization lid attached thereto. [Figure 6A] FIG. 2 is a close-up perspective cutaway view depicting an exemplary embodiment of a tray having a sensor delivery component. [Figure 6B]FIG. 2 is a close-up perspective view depicting a sensor delivery component. [Figure 7A] FIG. 2 is an isometric exploded top view of an illustrative sensor control device. [Figure 7B] FIG. 2 is an isometric exploded bottom view of an illustrative sensor control device. [Figure 8A] FIG. 13 is an assembly diagram of an on-body device including an integrated connector for the sensor assembly. [Figure 8B] FIG. 13 is a cross-sectional view of an on-body device including an integrated connector for a sensor assembly. [Figure 8C] FIG. 13 is a cross-sectional view of an on-body device including an integrated connector for a sensor assembly. [Figure 9A] 2D is a side view of an exemplary embodiment of the sensor applicator of FIG. 1A coupled with the cap of FIG. 2C. [Figure 9B] 2D is a cross-sectional side view of an exemplary embodiment of the sensor applicator of FIG. 1A coupled with the cap of FIG. 2C. [Figure 10A] FIG. 2 is an isometric view of another exemplary sensor control device. [Figure 10B] FIG. 2 is a side view of another exemplary sensor control device. [Figure 11A] 10A-10B. FIG. 10C is a step-by-step cross-sectional side view illustrating the assembly of a sensor applicator with the sensor control device of FIGS. [Figure 11B] 10A-10B. FIG. 10C is a step-by-step cross-sectional side view illustrating the assembly of a sensor applicator with the sensor control device of FIGS. [Figure 11C] 10A-10B. FIG. 10C is a step-by-step cross-sectional side view illustrating the assembly of a sensor applicator with the sensor control device of FIGS. [Figure 12A] 10A-10B , depicting cross-sectional side views in stages illustrating assembly and disassembly of an exemplary embodiment of a sensor applicator and sensor control device of FIGS. [Figure 12B] 10A-10B , depicting cross-sectional side views in stages illustrating assembly and disassembly of an exemplary embodiment of a sensor applicator and sensor control device of FIGS. [Figure 12C]10A-10B , depicting cross-sectional side views in stages illustrating assembly and disassembly of an exemplary embodiment of a sensor applicator and sensor control device of FIGS. [Figure 13A] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 13B] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 13C] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 13D] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 13E] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 13F] 1A-1C are cross-sectional views depicting an exemplary embodiment of an applicator during a deployment stage. [Figure 14] 1 is a graph illustrating an example of in vitro sensitivity of an analyte sensor. [Figure 15] 1A-1C illustrate exemplary operational states of a sensor in accordance with an illustrative embodiment of the presently disclosed subject matter. [Figure 16] 1 illustrates an exemplary operational and data flow for wireless programming of a sensor in accordance with the subject matter of the present disclosure. [Figure 17] FIG. 2 illustrates an exemplary data flow for secure data exchange between two devices in accordance with the subject matter of the present disclosure. [Figure 18] FIG. 1 illustrates an example environment and data flow for an analyte monitor system. [Figure 19] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Figure 20] FIG. 2 illustrates an exemplary user interface of an application executed in accordance with certain embodiments. [Figure 21] FIG. 2 illustrates an exemplary user interface of another device in accordance with certain embodiments. [Figure 22]FIG. 1 illustrates a procedure for requesting and generating a report based on specimen data provided through a matrix barcode according to certain embodiments. [Diagram 23] FIG. 1 illustrates a procedure for requesting and generating a report based on specimen data provided through a matrix barcode according to certain embodiments. [Figure 24] FIG. 2 illustrates an example interface of an application executed in accordance with certain embodiments. [Diagram 25] FIG. 2 illustrates an example interface of an application executed in accordance with certain embodiments. [Figure 26] FIG. 2 illustrates an exemplary flow of data between components of an analyte monitor system in accordance with certain embodiments. [Figure 27] FIG. 2 illustrates an example interface of an application executed for certain embodiments. [Figure 28] FIG. 2 illustrates an example interface of an application executed in accordance with certain embodiments. [Figure 29] FIG. 2 illustrates an example interface of an application executed for certain embodiments. [Diagram 30] FIG. 2 illustrates an example interface of an application executed for certain embodiments. [Diagram 31] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Diagram 32] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Diagram 33] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Diagram 34] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Diagram 35] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Diagram 36]FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Figure 37] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Figure 38A] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Figure 38B] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Figure 39] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Figure 40A] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Figure 40B] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Diagram 41] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Diagram 42] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. [Diagram 43] FIG. 1 illustrates an exemplary data flow for an analyte monitor system. [Diagram 44] FIG. 2 illustrates a procedure for requesting and generating reports according to certain embodiments. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0029] The present disclosure provides systems, devices, and methods for use in an analyte monitor system. An exemplary analyte monitor system can be configured to use various methods and additional systems to facilitate the transfer of analyte data from a data receiving device that does not have wireless network capabilities. In certain examples, the analyte is glucose. Certain examples facilitate the transfer of data to a general purpose device, a user device, and an electronic medical record (EMR) system. Certain examples facilitate the transfer of data to a report generation system that provides reports based on the analyte data and interprets the data. Certain examples relate to techniques for facilitating integration of EMR system data management and reports.

[0030] The present disclosure provides systems, devices, and methods for the use of an analyte sensor insertion applicator for use in an in vivo analyte monitor system. The applicator can be provided to a user in a sterile package with the electronics housing of the sensor control device included therein. In some examples, a structure such as a container separate from the applicator can also be provided to a user as a sterile package with a sensor module and a sharps module included therein. The user can couple the sensor module to the electronics housing and further couple the sharps to the applicator by an assembly process that includes inserting the applicator into the container in a specified manner. In other examples, the applicator, sensor control device, sensor module, and sharps module can be provided in a single package. The applicator can be used to place the sensor control device on the human body with the sensor in contact with the wearer's bodily fluids. Examples provided herein are improvements that reduce the likelihood of the sensor being improperly inserted or damaged or inducing an adverse physiological response.

[0031] Additionally, many of the examples include in vivo analyte sensors that are structurally configured such that at least a portion of the sensor is or can be placed on the body of a user to obtain information regarding at least one analyte in the body. However, it should be noted that the examples disclosed herein can be used with in vivo analyte monitoring systems that incorporate extracorporeal functionality, as well as purely ex vivo or ex vivo analyte monitoring systems, including completely non-invasive systems.

[0032] Additionally, for each and every example of the methods disclosed herein, systems and devices having the functionality to perform each of these examples are encompassed within the present disclosure. For example, example sensor control devices are disclosed, which may have one or more sensors, analyte monitor circuitry (e.g., analog circuitry), memory (e.g., for storing instructions), power sources, communication circuitry, transmitters, receivers, processors, and / or controllers (e.g., for executing instructions) that may perform or facilitate the execution of any and all procedures. These example sensor control devices may be used and have the functionality to perform the procedures performed by the sensor control device from any of the methods described herein.

[0033] Additionally, the systems and methods presented herein may be used in conjunction with the operation of sensors used in analyte monitor systems, such as, but not limited to, for fitness, dietary, research, informational, or any purpose related to analyte sensing over time. As used herein, a "sensor" may refer to any device capable of accepting sensor information from a user, including, by way of example only, a temperature sensor, a blood pressure sensor, a pulse or heart rate sensor, a glucose level sensor, an analyte sensor, a physical activity sensor, a motion sensor, or any other sensor for collecting physical or biometric information. Analytes measured by an analyte sensor may include, by way of example only, but not limited to, glucose, ketones, lactate, oxygen, hemoglobin A1C, albumin, alcohol, alkaline phosphatase, alanine transaminase, aspartate aminotransferase, bilirubin, blood urea nitrogen, calcium, carbon dioxide, chloride, creatinine, hematocrit, lactate, magnesium, oxygen, pH, phosphorus, potassium, sodium, total protein, uric acid, and the like.

[0034] However, before describing the above-mentioned aspects of the embodiments in detail, it is desirable to first describe examples of devices and their operation that may be present, for example, in an in vivo analyte monitor system, all of which may be used in conjunction with the examples described herein.

[0035] There are various types of in vivo analyte monitor systems. A "continuous analyte monitor" system (or "continuous glucose monitor" system), for example, may transmit data continuously, without prompting, e.g., automatically according to a schedule, from the sensor control device to the reader device. As another example, an "intermittent analyte monitor system" (or "intermittent glucose monitor" system or simply "intermittent" system) may relay data from the sensor control device using near field communication (NFC) or radio frequency identification (RFID) protocols, etc., in response to a scan or data request by the reader device. An in vivo analyte monitor system may operate without the need for fingerstick calibration.

[0036] In vivo analyte monitor systems can be distinguished from "ex vivo" systems, which generally include a measurement device that contacts a biological sample outside the body (or "ex vivo") and has a port for accepting an analyte test strip that can carry a user's bodily fluid and be analyzed to determine the user's blood glucose level.

[0037] An in-vivo monitoring system may include a sensor that contacts a user's bodily fluid while disposed in the living body and senses the analyte level contained therein. The sensor may be part of a sensor control device that resides on the user's body, the sensor control device including the electronics and power source that enable and control the analyte sensing. Sensor control devices and variations thereof may be referred to as "sensor control units," "on-body electronics" devices or units, "on-body" devices or units, or "sensor data communication" devices or units, to name a few.

[0038] An in-vivo monitoring system may include a device that accepts sensed analyte data from a sensor control device and processes and / or displays it to a user in any form. This device and variations thereof may be referred to as a "handheld reader device", "reader device" (or simply "reader"), "handheld electronic device" (or simply "handheld"), "portable data processing" device or unit, "data receiver", "receiver" device or unit (or simply "receiver"), "remote" device or unit, "receiving device", "data receiving device", or "receiver device", to name a few. Unless specifically indicated otherwise, this specification uses these terms interchangeably. Other devices, such as personal computers, have also been used with or incorporated into in-vivo or in-vivo monitoring systems.

[0039] FIG. 1A is a conceptual diagram illustrating an exemplary embodiment of an analyte monitor system 100 including a sensor applicator 150, a sensor control device 102, and a data receiving device 120 (e.g., "receiving device"). In this case, the sensor applicator 150 can be used to deliver the sensor control device 102 to a monitoring location on a user's skin where the sensor 104 is held stationary for a period of time by an adhesive patch 105. The sensor control device 102 will be described in more detail in FIG. 2B and FIG. 2C, and can communicate with the data receiving device 120 through a communication path 140 using wired or wireless technology. Exemplary wireless protocols include Bluetooth, Bluetooth Low Energy (BLE, BTLE, Bluetooth Smart, etc.), Near Field Communication (NFC), and others. A user can monitor applications installed in memory on the data receiving device 120 using a screen 122 and input 121, and can recharge the device's battery using a power port 123. Further details regarding the data receiving device 120 are set forth below in FIG. 2A. The data receiving device 120 can communicate with a local computer system 170 over a communication path 141 using wired or wireless technologies. The 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 the wireless communication can include any of a number of applicable wireless networking protocols, including Bluetooth, Bluetooth Low Energy (BTLE), Wi-Fi, or others. The local computer system 170 can communicate with the network 190 over a communication path 143 using wired or wireless technologies as described above in a manner similar to the manner in which the data receiving device 120 can communicate with the network 190 over communication path 142.Network 190 may be any of a number of networks, such as private and public networks, local area networks or wide area networks, etc. Trusted computer system 180 may include a server, may provide authentication services and secure data storage, and may communicate with network 190 through communications path 144 using wired or wireless technologies.

[0040] FIG. 1B illustrates another example of an operating environment for an analyte monitor system 100 capable of embodying the techniques described herein. As illustrated, the analyte monitor system 100 can include a system of components designed to provide monitoring of a parameter such as an analyte level in a human or animal body, or can enable other operations based on the configuration of various components. As embodied herein, the system can include a low-power sensor control device 102 worn by a user or attached to the body from which information is being collected. As embodied herein, the sensor control device 102 can be a sealed, positionable device having a predetermined useful life (e.g., about 1 day, about 14 days, about 30 days, etc.). The sensor 110 can be applied to the skin of the user's body and can remain adherent for the duration of the sensor life, or can be designed to remain functional when selectively removed and reapplied. The low power analyte monitor system 100 may further include a data reading device 120 or a general-purpose device 130 configured as described herein to facilitate retrieval and transmission of data, including analyte data, from the sensor control device 102.

[0041] As embodied herein, the analyte monitoring system 100 may include software or firmware libraries or applications provided to a third party, for example, through a remote application server 155 or an application storefront server 160, and embedded within a general-purpose hardware device 130, for example, a mobile phone, tablet, personal computing device, or other similar computing device having the capability to communicate with the sensor control device 102 through a communications link. The general-purpose hardware may further include embedded devices, including, but not limited to, an insulin pump or insulin pen having an embedded library configured to communicate with the sensor control device 102. Although the illustrated example of the analyte monitoring system 100 includes only one of each of the illustrated devices, the present disclosure contemplates that the analyte monitoring system 100 may incorporate multiple of each of the components through which it interacts. For example, and without limitation, as embodied herein, the data receiving device 120 and / or the general-purpose device 130 may include multiple of each. As embodied herein, multiple data receiving devices 130 may communicate directly with the sensor control device 102 as described herein. Additionally or alternatively, the data receiving device 130 may communicate with a secondary data receiving device 130 to provide the sample data or a visual representation or analytical results thereof for secondary display to a user or other authorized party.

[0042] 2A is a block diagram illustrating an example of a data receiving device 120 configured as a smartphone. In this case, the data receiving device 120 may include a display 122, an input component 121, a processing core 206 including a communication processor 222 coupled to a memory 223, and an application processor 224 coupled to a memory 225. Similarly, a separate memory 230, an RF transceiver 228 having an antenna 229, and a power source 226 having a power management module 238 may be included. Additionally, a multi-function transceiver 232 capable of communicating through Wi-Fi, NFC, Bluetooth, BTLE, and GPS using an antenna 234 may be included. As will be appreciated by those skilled in the art, these components are electrically and communicatively coupled to create a functional device. In some examples where the data receiving device 120 is configured as a smartphone with other functions, the data receiving device 120 may be referred to as a "multi-purpose device."

[0043] The data receiving device 120 may be, for example, a mobile communication device such as a Wi-Fi or Internet-enabled smartphone, tablet, or personal digital assistant (PDA). Examples of smartphones may include, but are not limited to, phones based on the WINDOWS® operating system, the ANDROID® operating system, the IPHONE® operating system, the PALM, WEBOS, the BLACKBERRY® operating system, or the SYMBIAN operating system with data networking capabilities for data communication over an Internet connection and / or a local area network (LAN).

[0044] The data receiving device 120 can be configured as a mobile smart wearable electronics assembly such as an optical assembly (e.g., a smart monocular or smart glasses such as GOOGLE GLASSES) worn on or adjacent to the user's eye. The optical assembly can have a transparent display that displays information to the user regarding the user's analyte level (as described herein) while allowing the user to see through the display with minimal obstruction to the user's overall vision. The optical assembly can have wireless communication capabilities akin to a smart phone. Other examples of wearable electronics include devices worn on or around the user's wrist (e.g., smart watches, etc.), devices worn on or around the neck (e.g., necklaces, etc.), devices worn on or around the head (e.g., headbands, hats, etc.), devices worn on or around the chest, etc.

[0045] For purposes of illustration and not limitation, reference is made to another example of a data receiving device 120 shown in FIG. 2B for use with the subject matter of the present disclosure. The data receiving device 120 and associated general purpose device 130 include components germane to the discussion of the sensor control device 102 and its operation, and may include additional components. In certain embodiments, the data receiving device 120 and general purpose device 130 may be or include components provided by third parties, and are not necessarily limited to including devices manufactured by the same manufacturer as the manufacturer of the sensor control device 102.

[0046] 2B, the data receiving device 120 includes an ASIC 4000 including a microcontroller 4010 communicatively coupled to a communication module 4040, a memory 4020, and a storage 4030. Power for the components of the data receiving device 120 may be delivered by a power module 4050, which may include a rechargeable battery as specifically shown herein. The data receiving device 120 may further include a display 4070 to facilitate review of analyte data received from the sensor control device 102 or other devices (e.g., a user device 145 or a remote application server 155). The data receiving device 120 may include separate user interface components (e.g., physical keys, a light sensor, a microphone, etc.).

[0047] The communication module 4040 may include a BLE module 4041 and an NFC module 4042. The data receiving device 120 may be configured to wirelessly couple with the sensor control device 102 and transmit commands to and receive data from the sensor control device 102. As embodied herein, the data receiving device 120 may be configured to operate as an NFC scanner and a BLE endpoint through a specific module (e.g., the BLE module 4042 or the NFC module 4043) of the communication module 4040 with respect to the sensor control device 102 described herein. For example, the data receiving device 120 may issue commands (e.g., an activation command for a data broadcast mode of the sensor, a pairing command for identifying the data receiving device 120) to the sensor control device 102 using a first module of the communication module 4040, and may transmit and receive data to and from the sensor control device 102 using a second module of the communication module 4040. The data receiving device 120 may be configured for communication with the user device 145 through a Universal Serial Bus (USB) module 4045 of the communication module 4040 .

[0048] As another example, the communication module 4040 can include, for example, a cellular radio module 4044. The cellular radio module 4044 can include one or more radio transceivers for communicating with wideband zone cellular networks, including but not limited to third generation (3G), fourth generation (4G), and fifth generation (5G) networks. Additionally, the communication module 4040 of the data receiving device 120 can include a Wi-Fi radio module 4043 for communicating with wireless local area networks according to one or more of the "IEEE 802." 11 standards (e.g., 802.11a, 802.11b, 802.11g, 802.11n (aka Wi-Fi4), 802.11ac (aka Wi-Fi5), 802.11ax (aka Wi-Fi6)). Using the cellular wireless module 4044 or the Wi-Fi wireless module 4043, the data receiving device 120 can communicate with a remote application server 155 to receive or update analyte data or provide input received from a user. Although not illustrated, the communication module 5040 of the analyte sensor 120 can also include a cellular wireless module or a Wi-Fi wireless module.

[0049] As embodied herein, the on-board storage 4030 of the data receiving device 120 can store analyte data received from the sensor control device 102. Additionally, the data receiving device 120, the general purpose device 130, or the user device 145 can be configured to communicate over a wide area network with a remote application server 155. As embodied herein, the sensor control device 102 can provide data to the data receiving device 120 or the general purpose device 130. The data receiving device 120 can transmit these data to the user computing device 145. Additionally, the user computing device 145 (or the general purpose device 130) can transmit these data to the remote application server 155 for processing and analysis.

[0050] As embodied herein, the data receiving device 120 may further include sensing hardware 4060 similar to or extended from the sensing hardware 5060 of the sensor control device 102. In some examples, the data receiving device 120 may be configured to associate with and act on analyte data received from the sensor control device 102. As an example, where the sensor control device 102 is a glucose sensor, the data receiving device 120 may be or include an insulin pump or an insulin injection pen. In association, the compatible device 130 may adjust insulin dosage to the user based on the glucose value received from the analyte sensor.

[0051] 2C and 2D are block diagrams illustrating an example of a sensor control device 102 having an analyte sensor 104 and sensor electronics 160 that may have most of the processing functionality for rendering final result data for display to a user. FIG. 2C shows a single semiconductor chip 161 that may be a custom application specific integrated circuit (ASIC). Within the ASIC 161 are shown certain high level functional units including an analog front end (AFE) 162, a power management (or control) circuit 164, a processor 166, and a communication circuit 168 (which may be implemented as a transmitter, receiver, transceiver, passive circuitry, or other communication protocol). In this example, both the AFE 162 and the processor 166 are used as analyte monitor circuitry, although in other examples, either circuitry may perform the analyte monitor function. The processor 166 may include one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be a separate chip or distributed among (and be part of) several different chips.

[0052] Also included within the ASIC 161 is a memory 163, which may be shared by the various functional units present within the ASIC 161 or may be distributed among two or more of these functional units. The memory 163 may be a separate chip. The memory 163 may be a volatile and / or non-volatile memory. In this example, the ASIC 161 is coupled to a power source 172, which may be a coin cell battery or the like. The AFE 162 interconnects with the in-vivo analyte sensor 104, accepts measurement data therefrom, and outputs these data in digital form to a processor 166, which further processes these data to provide final result glucose individual values ​​and glucose trend values, etc. These data may then be provided to a communication circuit 168 for transmission through an antenna 171, for example, to a data receiving device 120 (not shown), where little further processing is required by a resident software application to display the data.

[0053] FIG. 2D is similar to FIG. 2C, but includes two separate semiconductor chips 162 and 174, which may be packaged together or separately. In this case, the AFE 162 resides on the ASIC 161. The processor 166 is integrated with the power management circuit 164 and the communication circuit 168 on the chip 174. The AFE 162 includes memory 163, and the chip 174 includes memory 165, which may be isolated or distributed within it. In one example, the AFE 162 is combined with the power management circuit 164 and the processor 166 on one chip, while the communication circuit 168 is on a separate chip. In another example, both the AFE 162 and the communication circuit 168 are on one chip, while the processor 166 and the power management circuit 164 are on another chip. It should be noted that other chip combinations are possible, including three or more chips, each performing separate functions as described, or sharing one or more functions to achieve fail-safe redundancy.

[0054] For purposes of illustration and not limitation, FIG. 2E illustrates another example of a sensor control device 102 that is compatible with the security architecture and communication schemes described herein.

[0055] As embodied herein, the sensor control device 102 may include an application specific integrated circuit ("ASIC") 5000 communicatively coupled to a communication module 5040. The ASIC 5000 may include a microcontroller core 5010, an on-board memory 5020, and a storage memory 5030. The storage memory 5030 may store data used for authentication and encryption security architecture. The storage memory 5030 may store programming instructions for the sensor control device 102. As embodied herein, a certain communication chipset (e.g., NFC transceiver 5025) may be embedded within the ASIC 5000. The ASIC 5000 may receive power from a power module 5050, such as an on-board battery, or from an NFC pulse. The storage memory 5030 of the ASIC 5000 may be programmed to include information such as an identifier for the sensor control device 102 for identification and tracking purposes. The storage memory 5030 can be programmed with configuration or calibration parameters used by the sensor control device 102 and its various components. The storage memory 5030 can include rewriteable memory or one-time programming (OTP) memory. The storage memory 5030 can be updated using techniques described herein to extend the usefulness of the sensor control device 102.

[0056] As embodied herein, the communication module 5040 of the sensor control device 102 may be or include one or more modules for supporting communication with other devices of the analyte monitoring system 100. By way of example only and not limitation, the exemplary communication module 5040 may include a Bluetooth Low Energy ("BLE") module 5041, which is used throughout this disclosure to refer to a short-range communication protocol optimized for easy Bluetooth device pairing for end users. The communication module 5040 may transmit and receive data and instructions by interacting with a similarly capable communication module of the data receiving device 120 or user device 145. The communication module 5040 may include additional or alternative chipsets suitable for use with similar short-range communication techniques, such as, for example, "IEEE 802".15 protocol, personal area network according to "IEEE 802".11 protocol, infrared communication according to the Infrared Data Association (IrDA) standard.

[0057] To perform its functions, the sensor control device 102 may further include sensing hardware 5060 appropriate for those functions. As embodied herein, the sensing hardware 5060 may include an analyte sensor disposed transcutaneously or subcutaneously in contact with the subject's bodily fluid. The analyte sensor may generate sensor data that includes a value corresponding to one or more analyte levels in the bodily fluid.

[0058] The components of the sensor control device 102 may be acquired by the user in multiple packages that require final assembly by the user prior to delivery to the appropriate user location. Figures 3A-3D depict an example of a user assembly process for the sensor control device 102 including preparation of separate components prior to combining the components to prepare the sensor for delivery. Figures 3E-3F depict an example of delivery of the sensor control device 102 to an appropriate user location by selecting an appropriate delivery location and attaching the device 102 to the location.

[0059] 3A is a close-up perspective view depicting an example of a user preparing a container 810, in this case configured as a tray (although other packaging can be used) for an assembly process. The user can accomplish this preparation by removing the lid 812 from the tray 810 to expose the platform 808, for example, by peeling the non-adhered portion of the lid 812 from the tray 810 such that the adhered portion of the lid 812 is removed. Removal of the lid 812 can be as appropriate in various examples as long as the platform 808 is sufficiently exposed within the tray 810. The lid 812 can then be set aside.

[0060] 3B is a side view illustrating an example of a user preparing applicator device 150 for assembly. Applicator device 150 may be provided in a sterile package sealed by applicator cap 708. Preparing applicator device 150 may include disconnecting housing 702 from applicator cap 708 to expose sheath 704 (FIG. 3C). This disconnection may be accomplished by twisting (or otherwise detaching) applicator cap 708 off of housing 702. Applicator cap 708 may be set aside.

[0061] 3C is a close-up perspective view illustrating an example of a user inserting applicator device 150 into tray 810 during assembly. First, a user can insert sheath 704 into platform 808 inside tray 810 after housing orientation feature 1302 (or slot or recess) and tray orientation feature 924 (abutment or detent) are aligned. Inserting sheath 704 into platform 808 temporarily unlocks sheath 704 from housing 702, and also temporarily unlocks platform 808 from tray 810. At this stage, removal of applicator device 150 from tray 810 will result in the same condition as before the initial insertion of applicator device 150 into tray 810 (i.e., the process can be reversed or interrupted at this point and repeated without further ramifications).

[0062] During distal advancement of the housing 702, the sheath 704 may maintain a position relative to the housing 702 within the platform 808 and mate with the platform 808 to advance the platform 808 distally relative to the tray 810. This unlocks and collapses the platform 808 within the tray 810. The sheath 704 contacts and disengages a locking mechanism (not shown) within the tray 810, thereby unlocking the sheath 704 from the housing 702 and preventing it from moving (relatively) while the housing 702 advances the platform 808 distally. At the end of advancement of the housing 702 and platform 808, the sheath 704 is permanently unlocked from the housing 702. At the end of distal advancement of the housing 702, the sharps and sensor (not shown) within the tray 810 may mate with the electronics housing (not shown) within the housing 702. The operation and interaction of the applicator device 150 with the tray 810 is described in more detail below.

[0063] 3D is a close-up perspective view illustrating an example of a user removing applicator device 150 from tray 810 during assembly. A user can remove applicator 150 from tray 810 by advancing housing 702 proximally relative to tray 810 or other movement that has the same end effect as decoupling applicator 150 and tray 810. Applicator device 150 is removed with sensor control device 102 (sharp, sensor, electronics) (not shown) fully assembled therein and positioned for delivery.

[0064] 3E is a close-up perspective view illustrating an example of a patient using applicator device 150 to apply sensor control device 102 to a target area of ​​skin, for example on the abdomen or other suitable location. Advancing housing 702 causes sheath 704 therein to collapse distally, applying the sensor to the target location such that an adhesive layer on the bottom surface of sensor control device 102 adheres to the skin. The sharps automatically retract when housing 702 is fully advanced, while the sensor (not shown) is left in place to measure the analyte level.

[0065] 3F is a close-up perspective view illustrating an example of a patient with the sensor control device 102 in an application position. The user can then remove the applicator 150 from the application site.

[0066] 3A-3F and elsewhere herein, may result in a reduction or elimination of the possibility of accidental damage, permanent deformation, or incorrect assembly of applicator components compared to prior art systems. Because the applicator housing 702 directly engages the platform 808 while the sheath 704 is unlocked, rather than indirect engagement through the sheath 704, the relative angle between the sheath 704 and the housing 702 will not result in damage or permanent deformation of the arms or other components. The potential for relatively high forces during assembly (such as in conventional devices) is reduced, thereby reducing the possibility of user assembly failure.

[0067] FIG 4A is a side view illustrating an example of applicator device 150 coupled to a screw applicator cap 708. This view is an example of how applicator 150 may be shipped and received by a user prior to assembly with a sensor by the user. FIG 4B is a side perspective view illustrating applicator 150 and applicator cap 708 after they have been separated. FIG 4C is a perspective view illustrating an example of the distal end of applicator device 150 with electronics housing 706 and adhesive patch 105 removed from the positions they would have been maintained within sensor carrier 710 of sheath 704 when applicator cap 708 was in place.

[0068] 4D-4G, for purposes of illustration and not limitation, another example applicator device 20150 can be provided to a user as a single integrated assembly. Figures 4D and 4E provide perspective top and bottom views, respectively, of the applicator device 20150, Figure 4F provides an exploded view of the applicator device 20150, and Figure 4G provides a side cutaway view. These perspective views show how the applicator 20150 is shipped and received by a user. The exploded and cutaway views show the components of the applicator device 20150. The applicator device 20150 may include a housing 20702, a gasket 20701, a sheath 20704, a sharps carrier 201102, a spring 205612, a sensor carrier 20710 (also referred to as a "puck carrier"), a sharps hub 205014, a sensor control device (also referred to as a "puck") 20102, an adhesive patch 20105, a desiccant 20502, an applicator cap 20708, a serial label 20709, and an unopened evidence feature 20712. In some examples, only the housing 20702, the applicator cap 20708, the unopened evidence feature 20712, and the label 20709 are visible when a user receives the shipment. Only the unopened evidence feature 20712 and the label 20709 are visible. The tamper evident feature 20712 may be, for example, a sticker coupled to each of the housing 20702 and the applicator cap 20708, and may be, for example, irreparably damaged by separating the housing 20702 and the applicator cap 20708, thereby indicating to a user that the housing 20702 and the applicator cap 20708 have previously been separated. These features are described in more detail below.

[0069] FIG. 5 shows an example of a tray 810 with a sterilization lid 812 removably coupled thereto, in a close up perspective view that may represent how the package is shipped to a user and received by the user prior to assembly.

[0070] 6A is a close-up perspective cutaway view depicting the sensor delivery components within a tray 810. A platform 808 is slidably coupled within the tray 810. A desiccant 502 is fixed relative to the tray 810. A sensor module 504 is mounted within the tray 810.

[0071] 6B is a close-up perspective view depicting the sensor module 504 in greater detail, where the retention arm extensions 1834 of the platform 808 releasably secure the sensor module 504 in place. The module 2200 is coupled with the connector 2300, the sharps module 2500, and the sensor (not shown) so that they can be detached from one another as the sensor module 504 during assembly.

[0072] Briefly referring back to FIGS. 1A and 3A-3G, in a two-piece architecture system, the sensor tray 810 and the sensor applicator 150 are provided to the user as separate packages, thus requiring the user to unpack each package and ultimately assemble the system. In some applications, these separate sealed packages allow the sensor tray 810 and the sensor applicator 150 to be sterilized in separate sterilization processes that are unique to the contents of each package and incompatible with the contents of the other. More specifically, the sensor tray 810 including the plug assembly 207 including the sensor 104 and the sharps 220 can be sterilized using radiation sterilization, such as electron beam (or "e-beam") illumination. Suitable radiation sterilization processes include, but are not limited to, electron beam (e-beam) illumination, gamma ray illumination, x-ray illumination, or any combination thereof. However, radiation sterilization may damage electrical components located within the electronics housing of the sensor control device 102. As a result, if the sensor applicator 150, including the electronics housing of the sensor control device 102, needs to be sterilized, it can be sterilized by another method, such as gas chemical sterilization using, for example, ethylene oxide. However, gas chemical sterilization may damage enzymes or other chemical and biological agents contained on the sensor 104. Due to this sterilization incompatibility, the sensor tray 810 and the sensor applicator 150 are typically sterilized in separate sterilization processes and then packaged separately, thereby requiring the user to ultimately assemble the components for use.

[0073] 7A and 7B are exploded top and bottom views, respectively, of a sensor control device 3702 according to one or more examples. The shell 3706 and the mount 3708 act as opposing clamshell halves that enclose or otherwise substantially encapsulate various electronic components of the sensor control device 3702. As shown, the sensor control device 3702 can include a printed circuit board assembly (PCBA) 3802 including a printed circuit board (PCB) 3804 to which a number of electronic modules 3806 are coupled. Exemplary electronic modules 3806 include, but are not limited to, resistors, transistors, capacitors, inductors, diodes, and switches. Conventional sensor control devices typically stack PCB components on only one side of the PCB. In contrast, the PCB components 3806 in the sensor control device 3702 can be distributed around the surface area of ​​both sides (i.e., top and bottom) of the PCB 3804.

[0074] In addition to the electronic module 3806, the PCBA 3802 may further include a data processing unit 3808 mounted on the PCB 3804. The data processing unit 3808 may include, for example, an application specific integrated circuit (ASIC) configured to perform one or more functions or routines related to the operation of the sensor control device 3702. More specifically, the data processing unit 3808 may be configured to perform data processing functions, where such functions may include, but are not limited to, filtering and encoding a plurality of data signals each corresponding to a sampled analyte level of a user. The data processing unit 3808 may further include or otherwise communicate with an antenna for communicating with the reader device 106.

[0075] A battery opening 3810 can be defined within the PCB 3804 and sized to receive and seat a battery 3812 configured to power the sensor control device 3702. The PCB 3804 can have axial and radial battery contacts 3814a and 3814b coupled thereto that can extend into the battery opening 3810 to facilitate transfer of power from the battery 3812 to the PCB 3804. As the names suggest, the axial battery contact 3814a can be configured to provide axial contact to the battery 3812, while the radial battery contact 3814b can provide radial contact to the battery 3812. Positioning the battery 3812 within the battery opening 3810 with the battery contacts 3814a, 3814b helps reduce the height H of the sensor control device 3702, thereby allowing the PCB 3804 to be centrally positioned and its components to be distributed on both sides (i.e., top and bottom). This also helps facilitate providing the chamfer 3718 on the electronics housing 3704 .

[0076] The sensor 3716 may be centrally positioned with respect to the PCB 3804 and may include a tail 3816, a flag 3818, and a neck 3820 interconnecting the tail 3816 and the flag 3818. The tail 3816 may extend through a central opening 3720 in the mount 3708 and be configured to be transcutaneously received beneath the skin of a user. Additionally, the tail 3816 may have an enzyme or other chemical agent included thereon to assist in facilitating analyte monitoring.

[0077] The flag 3818 may include a generally flat surface having one or more sensor contacts 3822 (three shown in FIG. 7B ) disposed thereon. The sensor contacts 3822 may be configured to align with and engage with corresponding one or more circuit contacts 3824 (three shown in FIG. 7A ) provided on the PCB 3804. In some examples, the sensor contacts 3822 may include a carbon-impregnated polymer printed or otherwise digitally applied to the flag 3818. Conventional sensor control devices typically include a connector made of silicone rubber that encapsulates one or more flexible carbon-impregnated polymer modules that serve as conductive contacts between the sensor and the PCB. In contrast, the sensor contacts 3822 of the present disclosure provide a direct connection between the sensor 3716 and the PCB 3804, thereby eliminating the need for a prior art connector and advantageously reducing the height H. Furthermore, by eliminating the flexible carbon-impregnated polymer modules, significant circuit resistance is eliminated, thus improving circuit conductivity.

[0078] The sensor control device 3702 may further include a compliant member 3826 that may be positioned to be sandwiched between the flag 3818 and an inner surface of the shell 3706. More specifically, when the shell 3706 and the mount 3708 are assembled together, the compliant member 3826 may be configured to provide a passive biasing load against the flag 3818 that forces the sensor contacts 3822 into continuous engagement with the corresponding circuit contacts 3824. In the illustrated example, the compliant member 3826 is a resilient O-ring, but it is contemplated that the compliant member 3826 may alternatively include any other type of biasing device or mechanism, such as a compression spring or the like, without departing from the scope of the present disclosure.

[0079] The sensor control device 3702 may further include one or more electromagnetic shields, shown as a first shield 3828a and a second shield. The shell 3706 may be provided or otherwise defined with a first orientation determining receptacle 3830a (FIG. 7B) and a second orientation determining receptacle 3830b (FIG. 7B), and the mount 3708 may be provided or otherwise defined with a first orientation determining post 3832a (FIG. 7A) and a second orientation determining post 3832b (FIG. 7A). The shell 3706 is properly aligned with the mount 3708 by mating the first and second orientation determining receptacles 3830a, 3830b with the first orientation determining posts 3832a, 3832b, respectively.

[0080] 7A , the inner surface of the mount 3708 can include or otherwise define a number of pockets or recesses configured to receive various component parts of the sensor control device 3702 when the shell 3706 is mated to the mount 3708. For example, the inner surface of the mount 3708 can define a battery locator 3834 configured to receive a portion of the battery 3812 when the sensor control device 3702 is assembled. An adjacent contact pocket 3836 can be configured to receive a portion of the axial contact 3814a.

[0081] Additionally, a plurality of module pockets 3838 may be defined within the inner surface of the mount 3708 for receiving various electronic modules 3806 disposed on the bottom of the PCB 3804. Additionally, a shield locator 3840 may be defined within the inner surface of the mount 3708 for receiving at least a portion of the second shield 3828b when the sensor control device 3702 is assembled. The battery locator 3834, the contact pocket 3836, the module pocket 3838, and the shield locator 3840 all extend a short distance into the inner surface of the mount 3708, such that the overall height H of the sensor control device 3702 may be reduced as compared to conventional sensor control devices. The module pockets 3838 may assist in minimizing the diameter of the PCB 3804 by allowing PCB components to be disposed on both sides (i.e., the top and bottom).

[0082] Continuing to refer to FIG. 7A, the mount 3708 can further include a plurality of carrier gripping features 3842 (two shown) defined to be interspersed about its circumference. The carrier gripping features 3842 are axially offset from a bottom 3844 of the mount 3708, where a transfer adhesive (not shown) can be applied during assembly. In contrast to conventional sensor control devices that typically include a conical carrier gripping feature that intersects with the bottom of the mount, the carrier gripping features 3842 of the present disclosure are offset from this plane (i.e., bottom 3844), where a transfer adhesive is applied. This can prove advantageous as it helps ensure that the delivery system is not inadvertently attached to the transfer adhesive during assembly. Additionally, the carrier gripping features 3842 of the present disclosure eliminate the need for a scalloped transfer adhesive, thereby facilitating the manufacture of the transfer adhesive and eliminating the need to precisely orient the transfer adhesive relative to the mount 3708. Similarly, this increases the bonding area and therefore the bond strength.

[0083] 7B, the bottom 3844 of the mount 3708 may be provided with or otherwise defined with a plurality of grooves 3846 that may be defined at or near the periphery of the mount 3708 and spaced apart equidistantly from one another. A transfer adhesive (not shown) may be bonded to the bottom 3844, and the grooves 3846 may be configured to assist in transporting moisture from the sensor control device 3702 around the mount 3708 during use. In some examples, the spacing of the grooves 3846 may be sandwiched between a module pocket 3838 (FIG. 7A) defined on the opposite (inner) side of the mount 3708. As will be appreciated, alternating the location of the grooves 3846 and the module pockets 3838 ensures that opposing features do not extend into one another on either side of the mount 3708. This may help maximize utilization of material for the mount 3708, thereby assisting in maintaining a minimum height H of the sensor control device 3702. The module pocket 3838 can significantly reduce mold collapse and improve the flatness of the bottom 3844 where the transfer adhesive adheres.

[0084] 7B , the inner surface of the shell 3706 can also be provided with or otherwise define a number of pockets or recesses configured to receive various component parts of the sensor control device 3702 when the shell 3706 is mated to the mount 3708. For example, the inner surface of the shell 3706 can define an opposing battery locator 3848 positionable opposite the battery locator 3834 ( FIG. 7A ) of the mount 3708 and configured to receive a portion of the battery 3812 when the sensor control device 3702 is assembled. The opposing battery locator 3848 extends a short distance into the inner surface of the shell 3706, which helps reduce the overall height H of the sensor control device 3702.

[0085] A sharp and sensor locator 3852 may be provided by or otherwise defined on an inner surface of the shell 3706. The sharp and sensor locator 3852 may be configured to receive both a sharp (not shown) and a portion of the sensor 3716. Further, the sharp and sensor locator 3852 may be configured to align and / or mate with a corresponding sharp and sensor locator 2054 ( FIG. 7A ) provided on an inner surface of the mount 3708.

[0086] 8A-8C illustrate alternative sensor assembly / electronics assembly approaches in accordance with examples of the present disclosure. As shown, the sensor assembly 14702 includes a sensor 14704, a connector support 14706, and a shroud 14708. Among other things, a recess or receptacle 14710 can be defined in the bottom of the mount of the electronics assembly 14712, which can provide a location to receive the sensor assembly 14702 and couple it to the electronics assembly 14712, thereby fully assembling the sensor control device. The contours of the sensor assembly 14702 can be shaped in a manner that matches or is complementary to the receptacle 14710, which includes a resilient sealing member 14714 (including a conductive material that couples to a circuit board and aligns with the electrical contacts of the sensor 14704). Thus, when the sensor assembly 14702 is snapped or otherwise attached to the electronics assembly 14712 by pressing it into a recess 14710 integrally formed in the electronics assembly 14712, the on-body device 14714 shown in FIG. 8C is formed. This example provides an integrated connector for the sensor assembly 14702 within the electronics assembly 14712.

[0087] Additional information regarding sensor assemblies is provided in U.S. Patent Application Publication No. 2013 / 0150691 and U.S. Patent Application Publication No. 2021 / 0204841, the entire contents of each of which are incorporated by reference into this specification.

[0088] In accordance with examples of the present disclosure, the sensor control device 102 can be modified to provide a one-piece architecture that can be subjected to sterilization techniques specifically designed for the one-piece architecture sensor control device. The one-piece architecture allows the sensor applicator 150 and the sensor control device 102 to be shipped to the user in a single sealed package that does not require any end user assembly considerations. In other words, the user only needs to unpack one package and then deliver the sensor control device 102 to the target monitoring location. The one-piece system architecture described herein can prove advantageous by eliminating component parts, various processing steps, and user assembly. This results in less packaging and waste, and less user error or contamination of the system.

[0089] Figures 9A and 9B are a side view and a cross-sectional side view, respectively, of an example sensor applicator 150 with an applicator cap 708 coupled thereto. More specifically, Figure 9A illustrates how the sensor applicator 150 may be shipped to and received by a user, and Figure 9B depicts the sensor control device 4402 disposed within the sensor applicator 150. These figures show that the fully assembled sensor control device 4402 is installed within the already assembled sensor applicator 150 prior to delivery to the user, thus eliminating any additional assembly that the user may otherwise have to perform.

[0090] The fully assembled sensor control device 4402 can be loaded into the sensor applicator 150, and then the applicator cap 708 can be coupled to the sensor applicator 150. In some examples, the applicator cap 708 can be threaded onto the housing 702 and can include an unsealing ring 4702. When the applicator cap 708 is rotated (e.g., twisted off) relative to the housing 702, the unsealing ring 4702 is threaded off, thereby allowing the applicator cap 708 to be released from the sensor applicator 150.

[0091] In accordance with the present disclosure, the sensor control device 4402 may be subjected to a gas chemical sterilization 4704 configured to sterilize its electronics housing 4404 and any other exposed portions while loaded into the sensor applicator 150. To effect this sterilization, a chemical may be injected into a sterilization chamber 4706 cooperatively defined by the sensor applicator 150 and the interconnected cap 210. In some applications, the chemical may be injected into the sterilization chamber 4706 through one or more vents 4708 defined in the applicator cap 708 at its proximal end 610. Exemplary chemicals that may be used for the gas chemical sterilization 4704 include, but are not limited to, ethylene oxide, hydrogen peroxide vapor, nitrogen oxides (e.g., nitrous oxide, nitrogen dioxide, etc.), and steam.

[0092] The distal portion of the sensor 4410 and the sharps 4412 are sealed within the sensor cap 4416 so that the chemicals used during the gas chemical sterilization process do not interact with the enzymes, chemical agents, or biological agents provided on the tail 4524 and other sensor components, e.g., on the membrane coating that conditions the analyte inflow.

[0093] Once a desired level of sterility has been reached within the sterilization chamber 4706, the gas solution can be removed and the sterilization chamber 4706 can be aerated. Aeration can be accomplished by a series of vacuums followed by circulating a gas (e.g., nitrogen) or sterile air through the gas sterilization chamber 4706. Once the sterilization chamber 4706 is properly aerated, the vent 4708 can be blocked with a seal 4712 (shown in dashed lines).

[0094] In some examples, the seal 4712 may include two or more layers of different materials. The first layer may be made of a synthetic material (e.g., flash-spun high density polyethylene fiber) such as Tyvek® available from DuPont®. Tyvek® is highly durable, puncture resistant, and allows vapor transmission. The Tyvek® layer may be applied prior to the gas-chemical sterilization process, and following the gas-chemical sterilization process, a foil or other steam- and moisture-resistant material layer may be sealed (e.g., heat-fused) over the Tyvek® layer to prevent ingress of contaminants and moisture into the sterilization chamber 4706. In other examples, the seal 4712 may include only a single protective layer added to the applicator cap 708. In such examples, this single layer may be gas-permeable with respect to the sterilization process, but may also function as a protection against moisture and other harmful elements after the sterilization process is completed.

[0095] With the seal 4712 in place, the applicator cap 708 provides a barrier to external contamination, thereby maintaining a sterile environment for the assembled sensor control device 4402 until the user removes (unscrews) the applicator cap 708. The applicator cap 708 can create a dust-free environment that prevents the adhesive patch 4714 from becoming soiled during shipping and storage.

[0096] 10A and 10B are isometric and side views, respectively, of another exemplary sensor control device 5002 according to one or more examples of the present disclosure. The sensor control device 5002 may be similar in some respects to the sensor control device 102 of FIG. 1A and therefore may be best understood with reference thereto. Moreover, the sensor control device 5002 may replace the sensor control device 102 of FIG. 1A and therefore may be used in conjunction with the sensor applicator 150 of FIG. 1A, which may deliver the sensor control device 5002 to a target monitor location on the user's skin.

[0097] However, unlike the sensor control device 102 of FIG. 1A, the sensor control device 5002 may include a one-piece system architecture that does not require a user to unpack multiple packages and final assemble the sensor control device 5002 prior to application. In other words, upon receipt by the user, the sensor control device 5002 is already fully assembled and properly positioned within the sensor applicator 150 (FIG. 1A). To use the sensor control device 5002, the user only needs to open one barrier for use (e.g., applicator cap 708 of FIG. 3B) and then immediately deliver the sensor control device 5002 to the target monitoring location.

[0098] As shown, the sensor control device 5002 includes an electronics housing 5004 that is generally disc-shaped and may have a circular cross-section. However, in other examples, the electronics housing 5004 may exhibit other cross-sectional shapes, such as oval or polygonal, without departing from the scope of the present disclosure. The electronics housing 5004 may be configured to house or otherwise contain various electrical components used to operate the sensor control device 5002. In at least one example, an adhesive patch (not shown) may be disposed on the bottom of the electronics housing 5004. The adhesive patch may be similar to the adhesive patch 105 of FIG. 1A and may thus assist in adhering the sensor control device 5002 to the skin of a user for use.

[0099] As shown, the sensor control device 5002 includes an electronics housing 5004 that includes a shell 5006 and a mateable mount 5008. The shell 5006 may be secured to the mount 5008 by a variety of techniques, such as a snap fit, an interference fit, sonic welding, one or more mechanical fasteners (e.g., screws), a gasket, an adhesive, or any combination thereof. In some cases, the shell 5006 may be secured to the mount 5008 such that a sealed interface is generated between the shell 5006 and the mount 5008.

[0100] The sensor control device 5002 may further include a sensor 5010 (partially visible) and a sharp 5012 (partially visible) that is used to assist in transdermal delivery of the sensor 5010 beneath the skin of a user during application of the sensor control device 5002. As shown, corresponding portions of the sensor 5010 and sharp 5012 extend distally from a bottom of the electronics housing 5004 (e.g., mount 5008). The sharp 5012 may include a sharp hub 5014 configured to securely support it. As seen most clearly in FIG. 10B, the sharp hub 5014 may include or otherwise define a mating member 5016. To couple the sharp 5012 to the sensor control device 5002, the sharp 5012 may be advanced axially through the electronics housing 5004 until the sharp hub 5014 engages an upper surface of the shell 5006 and the mating member 5016 extends distally from the bottom of the mount 5008. When the sharp 5012 penetrates the electronics housing 5004, the exposed portion of the sensor 5010 can be received within the hollow or recessed (arcuate) portion of the sharp 5012. The remainder of the sensor 5010 is disposed within the electronics housing 5004.

[0101] The sensor control device 5002 may further include a sensor cap 5018, which is shown in FIGS. 10A-10B disassembled or detached from the electronics housing 5004. The sensor cap 5018 may be removably coupled to the sensor control device 5002 (e.g., the electronics housing 5004) at or near the bottom of the mount 5008. The sensor cap 5018 may assist in providing a sealing barrier surrounding exposed portions of the sensor 5010 and the sharps 5012 to protect against gas chemical sterilization. As shown, the sensor cap 5018 may include a generally cylindrical body having a first end 5020a and an opposing second end 5020b. The first end 5020a may be open to provide access into an interior chamber 5022 defined within the body. In contrast, the second end 5020b may be closed and may be provided with or otherwise defined by an engagement feature 5024. As described herein, the engagement feature 5024 can assist in mating the sensor cap 5018 with a cap (e.g., applicator cap 708 of FIG. 3B) of a sensor applicator (e.g., sensor applicator 150 of FIGS. 1 and 3A-3G) and can assist in removing the sensor cap 5018 from the sensor control device 5002 when the cap is removed from the sensor applicator 150.

[0102] The sensor cap 5018 can be removably coupled to the electronics housing 5004 at or near the bottom of the mount 5008. More specifically, the sensor cap 5018 can be removably coupled to a mating member 5016 that extends distally from the bottom of the mount 5008. In at least one example, for example, the mating member 5016 can define a set of male threads 5026a (FIG. 10B) that can mate with a set of female threads 5026b (FIG. 10A) defined by the sensor cap 5018. In some examples, the male and female threads 5026a, 5026b can include a square thread design (e.g., lacking a helical curvature), which can prove advantageous for molding these parts. Alternatively, the male and female threads 5026a, 5026b can include a helical threaded engagement. Thus, the sensor cap 5018 can be threadably coupled to the sensor control device 5002 at the mating member 5016 of the Sharp hub 5014. In other examples, the sensor cap 5018 can be removably coupled to the mating member 5016 by other types of engagement including, but not limited to, an interference or friction fit, or a frangible member or material that can be broken with a small separation force (e.g., axial or rotational force).

[0103] In some examples, the sensor cap 5018 may include a monolithic (single) structure extending between the first end 5020a and the second end 5020b. However, in other examples, the sensor cap 5018 may include two or more component parts. In the illustrated example, for example, the sensor cap 5018 may include a seal ring 5028 disposed at the first end 5020a and a desiccant cap 5030 disposed at the second end 5020b. The seal ring 5028 may assist in sealing the inner chamber 5022 as described in more detail below. In at least one example, the seal ring 5028 may include an elastomeric O-ring. The desiccant cap 5030 may store or include a desiccant that assists in maintaining a preferred humidity level within the inner chamber 5022. Additionally, the desiccant cap 5030 may define or otherwise provide an engagement feature 5024 for the sensor cap 5018.

[0104] 11A-11C are step-by-step cross-sectional side views illustrating the assembly of a sensor applicator 150 and a sensor control device 5002 according to one or more examples. Once the sensor control device 5002 is fully assembled, it can be loaded into the sensor applicator 150. With reference to FIG. 11A, the sharps hub 5014 can include or otherwise define hub snap tabs 5302 configured to assist in coupling the sensor control device 5002 to the sensor applicator 150. More specifically, the sensor control device 5002 can be advanced into the sensor applicator 150 and the hub snap tabs 5302 can be received by corresponding arms 5304 of a sharps carrier 5306 disposed within the sensor applicator 150.

[0105] 11B shows the sensor control device 5002 received by the sharps carrier 5306 and thus secured within the sensor applicator 150. Once the sensor control device 5002 is loaded into the sensor applicator 150, the applicator cap 708 can be coupled to the sensor applicator 150. In some examples, the applicator cap 708 and housing 702 can have a set of opposing matable threads 5308 that allow the applicator cap 708 to be twisted onto the housing 702 in a clockwise (or counterclockwise) direction, thereby securing the applicator cap 708 to the sensor applicator 150.

[0106] As shown, a sheath 704 is further disposed within the sensor applicator 150, which may include a sheath locking mechanism 5310 configured to ensure that the sheath 704 does not prematurely collapse during an impact event. In the illustrated example, the sheath locking mechanism 5310 may provide a threaded engagement between the applicator cap 708 and the sheath 704. More specifically, one or more internal threads 5312a may be defined or otherwise provided on an inner surface of the applicator cap 708, and one or more external threads 5312b may be defined or otherwise provided on the sheath 704. The internal threads 5312a and external threads 5312b may be configured to threadably mate when the applicator cap 708 is threaded onto the sensor applicator 150 via the threads 5308. The female and male threads 5312 a , 5312 b can have the same thread pitch as the threads 5308 that allow the applicator cap 708 to be screwed onto the housing 702 .

[0107] 11C shows the applicator cap 708 fully threadedly coupled to the housing 702. As shown, the applicator cap 708 may further include or otherwise define a cap post 5314 centrally located therein and extending proximally from a bottom of the applicator cap 708. The cap post 5314 may be configured to receive at least a portion of the sensor cap 5018 when the applicator cap 708 is twisted onto the housing 702.

[0108] With the sensor control device 5002 loaded into the sensor applicator 150 and the applicator cap 708 properly secured, the sensor control device 5002 can then be subjected to a gas chemical sterilization configured to sterilize its electronics housing 5004 and any other exposed portions. Because the sensor 5010 and distal portion of the sharps 5012 are sealed within the sensor cap 5018, the chemicals used during the gas chemical sterilization process cannot interact with the enzymes, chemical and biological agents provided on the tail 5104, as well as other sensor components, such as the membrane coating that regulates analyte inflow.

[0109] 12A-12C are step-by-step cross-sectional side views illustrating assembly and disassembly of alternative embodiments of a sensor applicator 150 and a sensor control device 5002 according to one or more additional examples. As generally described above, the fully assembled sensor control device 5002 can be loaded into the sensor applicator 150 by coupling the hub snap prongs 5302 into the arms 5304 of a sharps carrier 5306 disposed within the sensor applicator 150.

[0110] In the illustrated example, the sheath arm 5604 of the sheath 704 can be configured to interact with a first detent 5702a and a second detent 5702b defined within the housing 702. The first detent 5702a may alternatively be referred to as a "locking" detent and the second detent 5702b may alternatively be referred to as a "firing" detent. When the sensor control device 5002 is initially installed within the sensor applicator 150, the sheath arm 5604 may be received within the first detent 5702a. As described below, the sheath 704 may be actuated to move the sheath arm 5604 to the second detent 5702b, thereby placing the sensor applicator 150 in a firing position.

[0111] 12B, the applicator cap 708 is aligned with and advanced relative to the housing 702 such that the sheath 704 is received within the applicator cap 708. Instead of rotating the applicator cap 708 relative to the housing 702 to couple the applicator cap 708 to the housing 702, the threads of the applicator cap 708 can be snapped onto corresponding threads of the housing 702. Axial cuts or slots 5703 (one shown) defined in the applicator cap 708 can allow a portion of the applicator cap 708 proximate its threads to bend outwardly and snap into engagement with the threads of the housing 702. When the applicator cap 708 is snapped onto the housing 702, the sensor cap 5018 can be snapped into the cap post 5314 accordingly.

[0112] 11A-11C, the sensor applicator 150 can include a sheath locking mechanism configured to ensure that the sheath 704 does not prematurely collapse during an impact event. In the illustrated example, the sheath locking mechanism includes one or more ribs 5704 (one shown) defined near a base of the sheath 704 that are configured to interact with one or more ribs 5706 (two shown) defined near a base of the applicator cap 708 and a shoulder 5708. The ribs 5704 can be configured to engage between the ribs 5706 and the shoulder 5708 while attaching the applicator cap 708 to the housing 702. More specifically, once the applicator cap 708 is snapped onto the housing 702, the applicator cap 708 can be rotated (e.g., clockwise) such that the rib 5704 of the sheath 704 is positioned between the rib 5706 and shoulder 5708 of the applicator cap 708, which "locks" the applicator cap 708 in place until a user counter-rotates the applicator cap 708 to remove it for use. The engagement of the rib 5704 between the rib 5706 and shoulder 5708 of the applicator cap 708 can also prevent the sheath 704 from prematurely collapsing.

[0113] In Figure 12C, the applicator cap 708 has been removed from the housing 702. As with the example of Figures 12A-12C, the applicator cap 708 can be removed by counter-rotating it, which correspondingly rotates the cap post 5314 in the same direction, unscrewing the sensor cap 5018 from the mating member 5016 as generally described above. Additionally, disconnecting the sensor cap 5018 from the sensor control device 5002 exposes a distal portion of the sensor 5010 and the sharps 5012.

[0114] When the applicator cap 708 is twisted off of the housing 702, the rib 5704 defined on the sheath 704 can slidingly engage an upper portion of a rib 5706 defined on the applicator cap 708. The upper portion of the rib 5706 can provide a corresponding raised surface that causes an upward displacement of the sheath 704 when the applicator cap 708 is rotated, and as a result of moving the sheath 704 upward, the sheath arm 5604 bends out of engagement with the first detent 5702a and is received into the second detent 5702b. As the sheath 704 moves to the second detent 5702b, the radial shoulder 5614 disengages from radial engagement with the carrier arm 5608, thereby allowing the passive spring force of the spring 5612 to urge the sharp carrier 5306 upward, forcing the carrier arm 5608 out of engagement with the groove 5610. As the sharps carrier 5306 moves upward within the housing 702, the engaging member 5016 can be retracted accordingly until it is flush, substantially flush, or near-flush with the bottom of the sensor control device 5002. At this point, the sensor applicator 150 is in the fired position. Thus, in this example, removing the applicator cap 708 will cause the engaging member 5016 to retract accordingly.

[0115] 13A-13F illustrate exemplary details of an example of the internal device configuration for "firing" the applicator 150, including safely retracting the sharpener 1030 back into the used applicator 150, for the purpose of attaching the sensor control device 102 to a user. All together, these figures represent an exemplary sequence of driving the sharpener 1030 (carrying a sensor coupled to the sensor control device 102) into the user's skin, withdrawing the sharpener while leaving the sensor in operable contact with the user's interstitial fluid, and adhesively adhering the sensor control device to the user's skin. By reference to these figures, one skilled in the art can recognize modifications of such activities for use with alternative applicator assembly examples and components. Additionally, the applicator 150 can be a sensor applicator having a one-piece or two-piece architecture as disclosed herein.

[0116] 13A, the sensor 1102 is supported within the sharp 1030 slightly above the user's skin 1104. Rails 1106 (optionally three rails 1106) on the upper guide section 1108 can be provided to control movement of the applicator 150 relative to the sheath 704. The sheath 704 is secured within the applicator 150 by a detent feature 1110 such that an appropriate downward force along the longitudinal axis of the applicator 150 will overcome the resistance provided by the detent feature 1110 such that the sharp 1030 and sensor control device 102 can be translated along the longitudinal axis into (and onto) the user's skin 1104. Additionally, a catch arm 1112 on the sensor carrier 1022 engages the sharp retraction assembly 1024 to maintain the sharp 1030 in position relative to the sensor control device 102.

[0117] 13B, a user force is applied to overcome and disable the detent feature 1110, causing the sheath 704 to collapse into the housing 702 and drive the sensor control device 102 (with associated portions) to translate downward along the longitudinal axis as shown by arrow L. The inner diameter of the upper guide section 1108 of the sheath 704 constrains the position of the carrier arm 1112 throughout the entire stroke of the sensor / sharps insertion process. The retention of the stop surface 1114 of the carrier arm 1112 against the complementary surface 1116 of the sharps retraction assembly 1024 maintains the position of these members with the return spring 1118 fully biased. By way of example, instead of using a user force to drive the sensor control device 102 to translate downward along the longitudinal axis as shown by arrow L, the housing 702 can include a button (by way of example and not limitation, a push button) that activates a drive spring (by way of example and not limitation, a coil spring) to drive the sensor control device 102.

[0118] In Figure 13C, the sensor 1102 and sharp 1030 reach maximum insertion depth. In doing so, the carrier arm 1112 passes through the inner diameter of the upper guide section 1108. The compression force of the coil return spring 1118 then drives the bent stop surface 1114 radially outward, releasing a force that drives the sharp carrier 1102 of the sharp retraction assembly 1024 to pull the (slotted or otherwise configured) sharp 1030 out of the user and away from the sensor 1102, as shown by arrow R in Figure 13D.

[0119] With the sharp 1030 fully retracted as shown in Figure 13E, the final locking mechanism 1120 is engaged into the upper guiding section 1108 of the sheath 704. As shown in Figure 13F, the used applicator assembly 150 is removed from the insertion site leaving the sensor control device 102 behind with the sharp 1030 safely secured inside the applicator assembly 150. At this point, the used applicator assembly 150 is ready to be discarded.

[0120] The actuation of the applicator 150 when applying the sensor control device 102 is designed to give the user the sensation that both the insertion and retraction of the sharpener 1030 are performed automatically by the internal features of the applicator 150. In other words, the subject matter of the present disclosure avoids the user from experiencing the sensation of forcing the sharpener 1030 into his / her skin. Thus, after the user applies sufficient force to overcome the resistance from the detent features of the applicator 150, the resulting movement of the applicator 150 is perceived as an automatic response to the applicator being "triggered". Even though all the driving force to insert the sharpener 1030 is provided by the user and no additional biasing / driver is used, the user does not perceive that he / she is providing additional force to drive the sharpener 1030 to penetrate the skin. As detailed above in FIG. 13C, the retraction of the sharpener 1030 is automated by the coil return spring 1118 of the applicator 150.

[0121] With respect to any of the example applicators and components of the example applicators described herein, including but not limited to the example sharps, the example sharps modules, and the example sensor modules, one skilled in the art will appreciate that these examples can be dimensioned and configured to be suitable for use in a sensor configured to sense an analyte level in a bodily fluid within the epidermis, dermis, or subcutaneous tissue of a subject. In some examples, for example, the sharps and distal portions of the analyte sensors disclosed herein can be dimensioned and configured to be positioned at a particular distal depth (i.e., the deepest point of penetration into a tissue or layer of the subject's body, e.g., the epidermis, dermis, or subcutaneous tissue). With respect to some example applicators, one skilled in the art will appreciate that certain examples of the sharps can be dimensioned and configured to be positioned at a different distal depth within the subject's body as compared to the final distal depth of the analyte sensor. In some examples, for example, the sharps can be positioned at a first distal depth within the epidermis of the subject prior to retraction, whereas the distal portion of the analyte sensor can be positioned at a second distal depth within the dermis of the subject. In other examples, the sharp can be positioned at a first distal depth within the dermis of the subject prior to retraction, while a distal portion of the analyte sensor can be positioned at a second distal depth within subcutaneous tissue of the subject. In yet other examples, the sharp can be positioned at a first distal depth and the analyte sensor can be positioned at a second distal depth prior to retraction, both of which are within the same layer or tissue of the subject's body.

[0122] Additionally, for any of the example applicators described herein, one of ordinary skill in the art will appreciate that the analyte sensor and one or more structured components coupled to the analyte sensor, including but not limited to the one or more spring mechanisms, can be positioned within the applicator in an eccentric location relative to one or more axes thereof. In some example applicators, for example, the analyte sensor and spring mechanism can be positioned in an eccentric location on a first side of the applicator relative to the applicator axis, and the sensor electronics can be positioned in an eccentric location on a second side of the applicator relative to the applicator axis. In other example applicators, the analyte sensor, spring mechanism, and sensor electronics can be positioned in eccentric locations on the same side of the applicator axis. One of ordinary skill in the art will appreciate that other permutations and configurations in which any or all of the analyte sensor, spring mechanism, sensor electronics, and other components of the applicator are positioned in central or eccentric locations relative to one or more axes of the applicator are possible and fully within the present disclosure.

[0123] Additional details of suitable devices, systems, methods, components, and their operation, along with associated features, are described in WO 2018 / 136898 to Rao et al., WO 2019 / 236850 to Thomas et al., WO 2019 / 236859 to Thomas et al., WO 2019 / 236876 to Thomas et al., and U.S. Patent Publication No. 2020 / 0196919, filed June 6, 2019, the entire contents of each of which are incorporated herein by reference. Further details regarding examples of applicators, their components, and variations thereof are described in U.S. Patent Publication Nos. 2013 / 0150691, 2016 / 0331283, and 2018 / 0235520, the entire contents of all of which are incorporated herein by reference for all purposes. Further details regarding examples of the SHARP module, SHARP, its components, and variations thereof are described in U.S. Patent Publication No. 2014 / 0171771, the entire contents of which are incorporated by reference herein for all purposes.

[0124] A biochemical sensor can be described by one or more sensing properties. A common sensing property is called the sensitivity of a biochemical sensor, which is a measure of the sensor's responsiveness to the concentration or composition of the chemical that the biochemical sensor is designed to detect. In electrochemical sensors, this response can be in the form of current (amperometric) or charge (coulometric). In other types of sensors, the response can be in a different form, such as photon intensity (e.g., light). The sensitivity of a biochemical analyte sensor can vary depending on several factors, including whether the sensor is in an in vitro or in vivo condition.

[0125] FIG. 14 is a graph depicting the in vitro sensitivity of an amperometric analyte sensor. The in vitro sensitivity can be obtained by testing the sensor in vitro at various analyte concentrations and then performing a regression (e.g., linear or non-linear) or other curve fitting on the resulting data. In this example, the sensitivity of the analyte sensor is linear or substantially linear and can be modeled according to the equation y=mx+b, where y is the output current of the sensor, x is the analyte level (or concentration), m is the slope of the sensitivity, and b is the intercept of the sensitivity that corresponds approximately to the background signal (e.g., noise). For sensors with a linear or substantially linear response, the analyte level corresponding to a given current can be determined from the slope and intercept of the sensitivity. Sensors with non-linear sensitivity require additional information to determine the analyte level resulting from the sensor's output current, and one of ordinary skill in the art would be familiar with schemes for modeling non-linear sensitivity. In some examples of in vivo sensors, the in vitro sensitivity may be the same as the in vivo sensitivity, while in other examples, a transfer (or transformation) function is used to convert the in vitro sensitivity to an in vivo sensitivity applicable to the sensor's intended in vivo use.

[0126] Calibration is a technique for improving or maintaining accuracy by adjusting the measured output of a sensor to reduce the difference from the expected output of the sensor. One or more parameters describing the sensing characteristics of the sensor, such as sensitivity, are determined for use in making the calibration adjustments.

[0127] Certain in vivo analyte monitor systems require calibration to be performed either by user intervention after implantation of the sensor in a user or patient, or automatically by the system itself. For example, when user intervention is required, the user performs an in vitro measurement (e.g., a blood glucose (BG) measurement using a finger prick and an in vitro test strip) while the analyte sensor is implanted and enters the measurement into the system. The system compares the in vitro measurement to the in vivo signal and uses the difference to determine an estimate of the in vivo sensitivity of the sensor. The in vivo sensitivity can then be used in an algorithmic process to convert data collected with the sensor into a value indicative of the user's analyte level. This and other processes that require user action to perform a calibration are referred to as "user calibration." Systems may require user calibration due to instability in the sensitivity of the sensor, such that sensitivity drifts or changes over time. Thus, multiple user calibrations (e.g., on a regular (e.g., daily) schedule, according to a variable schedule, or on demand) may be required to maintain accuracy. The examples described herein may incorporate some degree of user calibration as appropriate for a particular implementation, but generally user calibration is not preferred as it requires the user to perform painful or otherwise difficult BG measurements and can introduce user error.

[0128] Some in vivo analyte monitor systems can periodically adjust calibration parameters through the use of automated measurements of sensor characteristics performed by the system itself (e.g., processing circuitry running the software). Repeated adjustment of the sensor's sensitivity based on variables measured by the system (rather than the user) is generally referred to as "system" (or automatic) calibration, and can be performed with or without user calibration, such as an early BG measurement. As with repeated user calibration, repeated system calibration is generally necessitated by drift in the sensor's sensitivity over time. Thus, although the examples described herein can be used with some degree of automated system calibration, preferably the sensor's sensitivity is relatively stable over time such that post-implementation calibration is not required.

[0129] Some in vivo analyte monitor systems operate with factory calibrated sensors. Factory calibration refers to the determination or estimation of one or more calibration parameters prior to sale to a user or healthcare professional (HCP). The calibration parameters may be determined by the sensor manufacturer (or by the manufacturer of other components of the sensor control device, if the latter manufacturer is different from the sensor manufacturer). Many in vivo sensor manufacturing processes process sensors in groups or batches called production lots, production-stage lots, or simply lots. A single lot may contain thousands of sensors.

[0130] The sensor may include a calibration code or calibration parameters that are derived or determined during one or more sensor manufacturing processes, encoded or programmed into a data processing device of the analyte monitoring system as part of the manufacturing process, or may be provided on the sensor itself, for example as a bar code, laser tag, RFID tag, or other machine-readable information displayed on the sensor. When the code is provided to a receiver (or other data processing device), user calibration during in vivo use of the sensor may be avoided or the frequency of in vivo calibration while wearing the sensor may be reduced. In instances where the calibration code or calibration parameters are displayed on the sensor itself, the calibration code or calibration parameters may be automatically transmitted or provided to a data processing device in the analyte monitoring system prior to or at the start of sensor use.

[0131] Some in-vivo analyte monitor systems operate with sensors that can be one or more of factory calibrated, system calibrated, and / or user calibrated. For example, a sensor can be provided with a calibration code or calibration parameters that can enable factory calibration. If this information is provided to the receiver (e.g., entered by a user), the sensor can operate as a factory calibrated sensor. If this information is not provided to the receiver, the sensor can operate as a user calibrated sensor and / or a system calibrated sensor.

[0132] In yet another aspect, programming or executable instructions may be provided or stored within the data processing device and / or receiver / controller unit of the analyte monitoring system for providing a time-varying adjustment algorithm to the in-vivo sensor during use. For example, based on retrospective statistical analysis of the analyte sensor used in vivo and corresponding glucose level feedback, a time series of predetermined or analyzed curves or databases may be generated that are configured to make additional adjustments to one or more in-vivo sensor parameters to compensate for potential sensor drift or other factors in the stability profile.

[0133] In accordance with the presently disclosed subject matter, the analyte monitor system can be configured to compensate or adjust the sensor sensitivity based on the sensor drift profile. A time-varying parameter β(t) can be defined or determined based on an analysis of the sensor behavior during in vivo use, and a time-varying drift profile can be determined. In some aspects, the compensation or adjustment of the sensor sensitivity can be programmed into a receiver unit, controller, or data processor of the analyte monitor system such that the compensation or adjustment, or both, can be performed automatically and / or iteratively as sensor data is received from the analyte sensor. In accordance with the presently disclosed subject matter, the adjustment or compensation algorithm can be user initiated or executed (rather than self-initiated or self-executing) such that the adjustment or compensation of the analyte sensor sensitivity profile is performed or executed upon user initiation or initiation of a corresponding function or routine or when a user enters a sensor calibration code.

[0134] According to the subject matter of the present disclosure, each sensor in a sensor lot (not including the sample sensor used for in vivo testing in some implementations) can be non-destructively inspected to determine or measure a sensor characteristic, such as film thickness at one or more points on the sensor, and other characteristics, including physical characteristics such as the area / volume of the active area, can be measured or determined. Such measurements or determinations can be performed using an automated method, for example, using an optical scanner or other suitable measurement device or system, and the sensor characteristic determined for each sensor in the sensor lot is compared to a corresponding average value based on the sample sensors with possible corrections to the calibration parameters or calibration codes assigned to each sensor. For example, with a calibration parameter defined as the sensor sensitivity, the sensitivity is approximately inversely proportional to the film thickness, so that for a sensor from a sensor lot that has a measured film thickness that is about 4% greater than the average film thickness of multiple sensors sampled from the same sensor lot, the sensitivity assigned to the sensor in one example is the average sensitivity determined from the sample sensors divided by 1.04. Similarly, sensitivity is approximately proportional to the active area of ​​the sensor, so that for a sensor with a measured active area that is about 3% smaller than the average active area for sensors sampled from the same sensor lot, the assigned sensitivity for that sensor is the average sensitivity multiplied by 0.97. The assigned sensitivity can be determined by multiple successive adjustments for each test or measurement of that sensor from the average sensitivity from the sample sensors. In some examples, the testing or measurement of each sensor can additionally include measurements of the film thickness and / or area or volume of the active sensing area as well as film stiffness or texture.

[0135] Additional information regarding sensor calibration is provided in U.S. Patent Application Publication No. 2010 / 00230285 and U.S. Patent Application Publication No. 2019 / 0274598, the entire contents of each of which are incorporated herein by reference.

[0136] The storage memory 5030 of the sensor control device 102 may include software blocks related to the communication protocol of the communication module. For example, the storage memory 5030 may include a BLE service software block having functions to provide an interface to make the BLE module 5041 available to the computer hardware of the sensor control device 102. These software functions may include a BLE logical interface and an interface parser. The BLE services provided by the communication module 5040 may include a generic access profile service, a generic attribute service, a generic access service, a device information service, a data transmission service, and a security service. The data transmission service may be a primary service used to transmit data such as sensor control data, sensor status data, analyte measurement data (past and present), and event log data. The sensor status data may include error data, current active time, and software status. The analyte measurement data may include information such as current and past raw measurements, current and past values ​​after processing with appropriate algorithms or models, predictions and trends of measurement levels, comparison of other values ​​to patient-specific averages, invocation of actions determined by algorithms or models, and other similar types of data.

[0137] According to aspects of the presently disclosed subject matter, as embodied herein, the sensor control device 102 can be configured to communicate with multiple devices simultaneously by adapting the capabilities of the communication protocol or communication medium supported by its hardware and radio. As an example, the BLE module 5041 of the communication module 5040 can be provided with software or firmware to enable multiple simultaneous connections between the sensor control device 102 as a central device or as a peripheral device if another device is the central device, and multiple other devices as peripheral devices.

[0138] A connection between two devices using a communication protocol such as BLE, and the resulting communication session, can be characterized by a similar physical channel operating between these two devices (e.g., the sensor control device 102 and the data receiving device 120). The physical channel can include a single channel or a set of channels, including using an agreed set of channels determined by, for example and without limitation, a common clock and a channel hopping or frequency hopping sequence. The communication sessions can use a similar amount of the available communication spectrum, and multiple such communication sessions can exist in close proximity. In some examples, each set of devices in a communication session uses a different physical channel or set of channels to manage interference with devices in the same proximity.

[0139] For purposes of illustration and not limitation, reference is made to an example procedure for sensor-receiver connection for use with the subject matter of the present disclosure. First, the sensor control device 102 repeatedly advertises its connection information to its environment in search of a data receiving device 120. The sensor control device 102 can repeat the advertisement periodically until a connection is established. The data receiving device 120 detects the advertisement packet and scans and filters through the data provided in the advertisement packet in search of a sensor control device 102 to connect to. The data receiving device 120 then sends a scan request command, and the sensor control device 102 responds with a scan response packet providing additional details. The data receiving device 120 then sends a connection request using the associated Bluetooth device address. The data receiving device 120 can continually request to establish a connection to the sensor control device 102 using a specific Bluetooth device address. The data receiving device then establishes an initial connection that allows it and the sensor to begin exchanging data. These devices begin the process to initialize the data exchange service and perform a mutual authentication procedure.

[0140] During the first connection between the sensor control device 102 and the data receiving device 120, the data receiving device 120 can initialize a discovery procedure of services, characteristics, and attributes. The data receiving device 120 can evaluate these capabilities of the sensor control device 102 and store them for use during subsequent connections. The data receiving device then enables notification of the respective corresponding security services to be used for mutual authentication between the sensor control device 102 and the data receiving device 120. The mutual authentication procedure may be automated and does not require user involvement. Following successful completion of the mutual authentication procedure, the sensor control device 102 sends a connection parameter update to request the data receiving device 120 to use the connection parameter settings selected by it as the dominant and configured to maximize the lifetime.

[0141] The data receiving device 120 then executes a sensor control procedure to backfill the historical data, current data, event log, and factory data. As an example, the data receiving device 120 sends a request to start the backfill process for each type of data. The request can specify a defined recording range based on, for example, measurements, timestamps, etc., as needed. The sensor control device 102 responds with the request data until all previously unsent data in its memory is sent to the data receiving device 120. The sensor control device 102 can respond to the backfill request from the data receiving device 120 that it has already sent all data. Once backfilling is complete, the data receiving device 120 can notify the sensor control device 102 that it is ready to receive periodic measurement readings. The sensor control device 102 can send the readings repeatedly over multiple notification results. As embodied herein, the multiple notifications can be redundant notifications to ensure that the data is sent correctly. Alternatively, the multiple notifications can include a single payload.

[0142] For purposes of illustration and not limitation, reference is made to an example procedure for sending a shutdown command to the sensor control device 102. The shutdown operation is performed when the sensor control device 102 is, for example, in an error state, an insertion failure state, or an expired sensor state. The sensor control device 102 can log the command if it is not in these states and perform the shutdown when it transitions to an error state or an expired sensor state. The data receiving device 120 sends a properly formatted shutdown command to the sensor control device 102. If the sensor control device 102 is actively processing another command, it will respond with a standard error response indicating that it is busy. Otherwise, the sensor control device 102 will send a response when it receives the command. In addition, the sensor control device 102 will send a success notification via its own sensor control to acknowledge that it has received the command. The sensor control device 102 will register the shutdown command. At the next appropriate opportunity (e.g., depending on the current sensor state as described herein), the sensor control device 102 will shut down.

[0143] For purposes of illustration and not limitation, reference is made to an example of a high-level depiction of a state machine representation 6000 of actions that the sensor control device 102 may take, as shown in FIG. 15. After initialization, the sensor enters a state 6005 associated with manufacturing the sensor control device 102. In the manufacturing state 6005, the sensor control device 102 may be configured for operation, e.g., writing to the storage memory 5030. At various times while in state 6005, the sensor control device 102 moves to a save state 6015, where it checks for received commands. Upon entering the save state 6015, the sensor performs a software integrity check. While in the save state 6015, the sensor may receive a wake-up request command, after which it proceeds to an insertion detection state 6025.

[0144] Upon entering state 6025, the sensor control device 102 may store information about authenticated devices to communicate with the sensor as configured during startup or initialize algorithms related to communicating and interpreting measurements from the sensing hardware 5060. The sensor control device 102 may initialize a life cycle timer responsible for maintaining its active operation time count and begin communication with the authenticated device to transmit recorded data. While in the insertion detection state 6025, the sensor may enter state 6030, where the sensor control device 102 checks whether the operation time is equal to a predefined threshold. This operation time threshold may correspond to a timeout function to determine whether the insertion is successful. If the operation time reaches the threshold, the sensor control device 102 proceeds to state 6035, where it checks whether the average data read amount is greater than a threshold amount corresponding to the expected data read amount to trigger the detection of a successful insertion. If the data read amount is lower than the threshold while in state 6035, the sensor proceeds to state 6040, corresponding to an insertion failure. If the data read amount meets the threshold, the sensor proceeds to an active pairing state 6055 .

[0145] The active pairing state 6055 of the sensor control device 102 reflects a state in which the sensor control device 102 is operating normally by recording measurements, processing measurements, and reporting these measurements as necessary. While in the active pairing state 6055, the sensor control device 102 attempts to send measurements or establish a connection with the receiving device 120. The sensor control device 102 further increments the operating time. The sensor control device 102 transitions to the active lapsed state 6065 when a predetermined threshold operating time is reached (e.g., the operating time reaches a predetermined threshold). The active lapsed state 6065 of the sensor control device 102 reflects a state in which the sensor control device 102 has operated for its maximum predetermined amount of time.

[0146] While in the active revocation state 6065, the sensor control device 102 may generally perform operations related to gradually terminating operation and ensuring that collected measurements are securely transmitted to the receiving device, if necessary. For example, while in the active revocation state 6065, the sensor control device 102 may transmit collected data and may intensify attempts to find and establish a connection with a nearby authenticated device if a connection is unavailable. While in the active revocation state 6065, the sensor control device 102 may receive a shutdown command in state 6070. If a shutdown command is not received, the sensor control device 102 may check whether the operation time has exceeded a final operation threshold in state 6075. The final operation threshold may be based on the battery life of the sensor control device 102. The normal transmission state 6080 corresponds to a final operation of the sensor control device 102, ultimately shutting down the sensor control device 102.

[0147] Before the sensor is powered up, the ASIC 5000 is in a low power storage mode. The power-up process can begin, for example, when an incident RF field (e.g., an NFC field) drives the voltage of the power supply to the ASIC 5000 above a reset threshold, causing the sensor control device 102 to enter a wake-up state. While in the wake-up state, the ASIC 5000 enters a power-up sequence state. The ASIC 5000 then wakes up the communication module 5040. The communication module 5040 is initialized and a power-on self-test is triggered. The power-on self-test can include the ASIC 5000 communicating with the communication module 5040 using a specified sequence of reading and writing data to verify that the memory and one-time programmable memory are not corrupted.

[0148] When the ASIC 5000 enters the measurement mode for the first time, an insertion detection sequence is performed to verify that the sensor control device 102 is properly attached on the patient's body before a proper measurement can be made. First, the sensor control device 102 interprets a command to initiate a measurement configuration process to place the ASIC 5000 in a measurement command mode. The sensor control device 102 then temporarily enters a measurement lifecycle state in which it performs several consecutive measurements to test whether the insertion was successful. The communication module 5040 or the ASIC 5000 evaluates the measurement results to determine whether the insertion was successful. The sensor control device 102 enters a measurement state when the insertion is deemed successful, where it begins to take periodic measurements using the sensing hardware 5060. If the sensor control device 102 determines that the insertion was not successful, it is triggered to enter an insertion failure mode, where the ASIC 5000 is commanded to return to a storage mode, while the communication module 5040 disables itself.

[0149] 1B further illustrates an exemplary operating environment for applying over-the-air ("OTA") updates suitable for use with the techniques described herein. An operator of the analyte monitoring system 100 can bundle updates to the data receiving device 120 or the sensor controlling device 102 into updates to applications running on the general-purpose device 130. Using the communication channels available between the data receiving device 120, the general-purpose device 130, and the sensor controlling device 102, the general-purpose device 130 can receive periodic updates to the data receiving device 120 or the sensor controlling device 102, and initiate the installation of these updates on the data receiving device 120 or the sensor controlling device 102. Applications that enable the multi-purpose device 130 to communicate with the sensor control device 102, the data receiving device 120, and / or the remote application server 155 can update software or firmware on the data receiving device 120 or the sensor control device 102 without using wide area networking capabilities, so that the multi-purpose device 130 acts as an installation or update platform for the data receiving device 120 or the sensor control device 102.

[0150] As embodied herein, a remote application server 155 operated by the manufacturer of the sensor control device 102 and / or the operator of the analyte monitoring system 100 can provide software and firmware updates to the devices of the analyte monitoring system 100. In some examples, the remote application server 155 can provide updated software and firmware to the user device 140 or directly to the general-purpose device. As embodied herein, the remote application server 155 can provide application software updates to the application storefront server 160 using an interface provided by the application storefront. The general-purpose device 130 can periodically communicate with the application sales site server 160 to download and install updates.

[0151] After the multipurpose device 130 downloads an application update including a firmware or software update for the data receiving device 120 or the sensor controlling device 102, the data receiving device 120 or the sensor controlling device 102 and the multipurpose device 130 establish a connection. The multipurpose device 130 determines that a firmware or software update is available for the data receiving device 120 or the sensor controlling device 102. The multipurpose device 130 can prepare the software or firmware update for sending to the data receiving device 120 or the sensor controlling device 102. As an example, the multipurpose device 130 can compress or split data related to the software or firmware update, or can encrypt or decrypt the firmware or software update, or can perform an integrity check on the firmware or software update. The multipurpose device 130 sends the data related to the firmware or software update to the data receiving device 120 or the sensor controlling device 102. Additionally, the multipurpose device 130 can send a command to initiate the update to the data receiving device 120 or the sensor control device 102. Additionally or alternatively, the multipurpose device 130 can include commands to facilitate the update, such as commands to present a notification to its user and keep the data receiving device 120 and the multipurpose device 130 connected to and close to a power source until the update is complete.

[0152] The data receiving device 120 or the sensor control device 102 receives data for the update and a command to start the update from the multi-purpose device 130. The data receiving device 120 can then install the firmware or software update. To install the update, the data receiving device 120 or the sensor control device 102 can place itself in or resume in a so-called "safe" mode, which has only limited operating capabilities. Once the update is complete, the data receiving device 120 or the sensor control device 102 re-enters or resets in a standard operating mode. The data receiving device 120 or the sensor control device 102 can perform one or more self-diagnostic tests to determine that the firmware or software update was successfully installed. The multi-purpose device 130 can receive notification of a successful update. The multi-purpose device 130 can then report confirmation of the successful update to the remote application server 155.

[0153] In some examples, the storage memory 5030 of the sensor control device 102 includes a one-time programmable (OTP) memory. The term OTP memory can refer to a memory that includes access restrictions and security to facilitate writing to a specific address or segment in the memory a predetermined number of times. The memory 5030 can be pre-determined up to a number of pre-allocated memory blocks or memory bins. The bins are pre-allocated to a fixed size. When the storage memory 5030 is a one-time programmable memory, the bins can be considered to be in a non-programmable state. Additional bins that have not yet been written can be made programmable or writable. Containerizing the storage memory 5030 in this manner can improve the portability of the code and data to be written to the storage memory 5030. Updating the software of a device (e.g., a sensor device described herein) stored in an OTP memory can be performed by replacing only the code in one or more specific bins that were previously written with the latest code written to one or more new bins, rather than replacing the entire code in the memory. In a second example, the memory is not pre-determined. Instead, the space allocated to the data is dynamically allocated or determined as needed. Containers of various sizes may be defined in which updates are expected, so that incremental updates can be sent.

[0154] 16 illustrates an exemplary operational and data flow diagram associated with over-the-air (OTA) programming of the storage memory 5030 in the sensor control device 102 in accordance with the subject matter of this disclosure, as well as the use of the memory during execution of a process by the sensor device 110 after OTA programming. In the exemplary OTA programming 500 illustrated in FIG. 5, a request to initiate OTA programming (or reprogramming) is sent from an external device (e.g., data receiving device 130). At 511, the communication module 5040 of the sensor device 110 receives an OTA programming command. The communication module 5040 sends the OTA programming command to the microcontroller 5010 of the sensor device 110.

[0155] At 531, after receiving the OTA programming command, the microcontroller 5010 validates the OTA programming command. For example, the microcontroller 5010 may determine whether the OTA programming command is signed with a proper digital signature token. Upon determining that the OTA programming command is valid, the microcontroller 5010 may set the sensor device to an OTA programming mode. At 532, the microcontroller 5010 may validate the OTA programming data. At 533, the microcontroller 5010 may reset the sensor device 110 to reinitialize the sensor device 110 in the programming state. Once the sensor device 110 transitions to the OTA programming state, the microcontroller 5010 may begin writing data to the rewritable memory 540 (e.g., memory 5020) of the sensor device at 534 and may further write data to the OTP memory 550 (e.g., storage memory 5030) of the sensor device at 535. The data written by the microcontroller 5010 may be based on the validated OTA programming data. The microcontroller 5010 may write data that causes one or more programming blocks or programming areas of the OTP memory 550 to be marked as incorrect or inaccessible. The data written to free or unused portions of the OTP memory 550 may be used to replace programming blocks of the OTP memory 550 that are deemed incorrect or inaccessible. After the microcontroller 5010 has written the data to the respective memories at 534 and 535, it may perform one or more software integrity checks to ensure that no errors were introduced into the programming blocks during the writing process. After it can be determined that the data was written without error, the microcontroller 5010 may resume normal operation of the sensor device.

[0156] In the execution mode, the microcontroller 5010 can retrieve a programming manifest or programming profile from the rewritable memory 540 at 536. The programming manifest or programming profile can include a list of legitimate software programming blocks and can further include program execution guides for the sensor control device 102. By following the programming manifest or programming profile, the microcontroller 5010 can determine which memory blocks of the OTP memory 550 are appropriate to execute and can avoid executing or referencing expired data of programming blocks that are deemed expired or fraudulent. At 537, the microcontroller 5010 can selectively retrieve memory blocks from the OTP memory 550. At 538, the microcontroller 5010 can use the retrieved memory blocks by executing programming code stored in the memory or using stored variables.

[0157] As embodied herein, a first layer of security for communications between the sensor control device 102 and other devices may be established based on security protocols dictated by and embedded in the communications protocol used for communication. Another layer of security may be based on communications protocols that require proximity of the communicating devices. Additionally, certain packets and / or certain data contained within packets may be encrypted, while other packets and / or other data within packets may or may not be otherwise encrypted. Additionally or alternatively, application layer encryption may be used in conjunction with one or more block or stream ciphers to establish mutual authentication and communications encryption with other devices in the analyte monitoring system 100.

[0158] The ASIC 5000 of the sensor control device 102 can be configured to dynamically generate authentication and encryption keys using data held in the storage memory 5030. The storage memory 5030 can be pre-programmed with a set of valid authentication and encryption keys for use with a particular class of device. The ASIC 5000 can be further configured to implement an authentication procedure with other devices using the received data and provide the generated key to the sensitive data before transmitting the sensitive data. The generated key can be unique to the sensor control device 102, unique to a pair of devices, unique to a communication session between the sensor control device 102 and another device, unique to a message sent during the communication session, or unique to a data block contained in the message.

[0159] Both the sensor control device 102 and the data receiving device 120 can guarantee the authority of the other party in the communication session, for example, to send commands or receive data. In some examples, identity authentication can be performed by two functions. First, the party asserting identity provides a valid proof signed by the device manufacturer or the operator of the analyte monitoring system 100. Second, authentication can be performed using public and private keys determined by the device of the analyte monitoring system 100 or by the operator of the analyte monitoring system 100, and a shared secret derived therefrom. To verify the identity of the other party, the party can provide proof that it controls the private key itself.

[0160] The manufacturer of the sensor control device 102, the data receiving device 120, or the provider of the application for the general purpose device 130 may provide the information and programs necessary for these devices to communicate securely through secure programming and updates. For example, the manufacturer may provide information that can be used to generate encryption keys for each device, including a secure root key for the sensor control device 102 and optionally the data receiving device 120, which can be used in combination with device specific information and operational data (e.g., an entropy-based random value) to generate a unique encryption value for the device, session, or data transmission as needed.

[0161] Analyte data associated with a user is sensitive data due at least in part to the fact that it can be used for a variety of purposes, including health monitoring and drug dosage determination. In addition to user data, the analyte monitor system 100 can implement enhanced security against attempts by external parties to reverse engineer. The communication connection can be encrypted using device-specific or session-specific encryption keys. Encrypted or unencrypted communications between any two devices can be verified using transmission integrity checks built into the communication. The operation of the sensor control device 102 can be protected from tampering by restricting access to the ability to read and write to the memory 5020 through the communication interface. The sensor can be configured to only allow access to known or "trusted" devices that are listed in a "white list" or devices that can provide a predetermined code associated with the manufacturer or other authorized user. The white list may represent a limited scope, meaning that no connection identifiers other than those included therein should be used, or a preferred scope where the white list is searched first, but other devices may still be used. Additionally, the sensor control device 102 can reject a connection request and shut down if the requestor fails to complete the login procedure over the communication interface within a predefined time period (e.g., within 4 seconds). These properties provide protection against certain denial of service attacks, particularly against BLE interfaces.

[0162] As embodied herein, the analyte monitoring system 100 may employ periodic key rotation to further reduce key disabling and tampering. The key rotation strategy employed by the analyte monitoring system 100 may be designed to accommodate backward compatibility for devices deployed or distributed across a site. As an example, the analyte monitoring system 100 may use keys designed to be compatible with multiple generations of keys used by upstream devices for downstream devices (e.g., devices at a site or devices that cannot be provided with updates in a feasible manner).

[0163] For purposes of illustration and not limitation, reference is made to an example message sequence diagram 600 for use with the subject matter of the present disclosure shown in FIG. 17 and illustrating an example data exchange between a pair of devices, specifically the sensor control device 102 and the data receiving device 120. The data receiving device 120 may be a data receiving device 120 or a general-purpose device 130 as embodied herein. In 605, the data receiving device 120 may send a sensor wake-up command 605 to the sensor control device 102, for example, by a short-range communication protocol. The sensor control device 102 may be primarily dormant prior to 605, conserving battery until a full wake-up is required. After waking up in 610, the sensor control device 102 may collect data or perform other operations appropriate to the sensing hardware 5060 of the sensor control device 102. In 615, the data receiving device 120 may initiate an authentication request command 615. In response to the authentication request command 615, both the sensor control device 102 and the data receiving device 120 can engage in a mutual authentication process 620. The mutual authentication process 620 can include the transfer of data including challenge parameters that enable the sensor control device 102 and the data receiving device 120 to ensure that the other device is fully capable of adhering to the agreed upon security framework described herein. Mutual authentication can be based on the ability of two or more entities to authenticate each other, verifying the establishment of a secret key by a challenge response with or without the involvement of an online trusted third party. Mutual authentication can be implemented using two-pass, three-pass, four-pass, or five-pass authentication or similar versions thereof.

[0164] Following a successful mutual authentication process 620, in 625 the sensor control device 102 can provide the data receiving device 120 with a sensor secret 625. The sensor secret includes a sensor-specific value and can be derived from a random value generated during manufacturing. The sensor secret can be encrypted before or during transmission to prevent third parties from accessing it. The sensor secret 625 can be encrypted by one or more of the keys generated by the mutual authentication process 620 or accordingly. In 630, the data receiving device 120 can derive a sensor-specific encryption key from the sensor secret. The sensor-specific encryption key can further be session-specific. Thus, the sensor-specific encryption key can be determined by each device without being transmitted between the sensor control device 102 and the data receiving device 120. In 635, the sensor control device 102 can encrypt the data to be included in the payload. At 640, the sensor control device 102 can transmit the encrypted payload 640 to the data receiving device 120 using the communication link established between its appropriate communication model and the appropriate communication model of the data receiving device 120. At 645, the data receiving device 120 can decrypt the payload using the sensor-specific encryption key derived at 630. Following 645, the sensor control device 102 can send out additional (including newly collected) data, and the data receiving device 120 can process the received data appropriately.

[0165] As discussed herein, the sensor control device 102 may be a device that has only limited processing power, battery supply, and storage. The encryption techniques (e.g., selection of cryptographic algorithms or implementations thereof) used by the sensor control device 102 may be selected based at least in part on these limitations. The data receiving device 120 may be a more powerful device that has fewer limitations of this nature. Thus, the data receiving device 120 may use more sophisticated and computationally intensive encryption techniques, such as cryptographic algorithms and implementations.

[0166] The sensor control device 102 can be configured to modify discoverability behavior to attempt to increase the probability that a receiving device will receive a proper data packet and / or provide an acknowledgment signal or to reduce limitations that may otherwise result in a lack of ability to receive an acknowledgment signal. Modifying the discoverability behavior of the sensor control device 102 may include, by way of example and not limitation, modifying how often connection data is included in a data packet, modifying how often data packets are transmitted in general, lengthening or shortening a broadcast window for data packets, modifying the amount of time the sensor control device 102 waits to receive an acknowledgment signal or a scanning signal after a broadcast, including a directional transmission (e.g., via one or more attempted transmissions) to one or more devices that were previously in communication with the sensor control device 102 and / or one or more devices on a whitelist, modifying the transmit power associated with the communication module when broadcasting a data packet (e.g., to increase the distance of the broadcast or to consume less energy to extend the battery life of the analyte sensor), modifying the rate at which data packets are prepared and broadcast, or a combination of one or more other modifications. Additionally or alternatively, the receiving device may also adjust parameters related to the device's listen behavior to increase the likelihood of receiving data packets containing connection data.

[0167] As embodied herein, the sensor control device 102 can be configured to broadcast data packets using two types of windows. The first window relates to the rate at which the sensor control device 102 is configured to activate its communication hardware. The second window relates to the rate at which the sensor control device 102 is configured to be in an active transmission (e.g., broadcast) state of data packets. As an example, the first window can indicate that the sensor control device 102 activates its communication hardware to transmit and / or receive data packets (including connection data) during the first two seconds of each 60 second period. The second window can indicate that the sensor control device 102 transmits a data packet every 60 milliseconds during each two second window. The remaining time during the two second window, the sensor control device 102 is scanning. The sensor control device 102 can extend or shorten either window to modify its discoverability behavior.

[0168] In some examples, the discoverability behavior of the analyte sensor may be stored in a discoverability profile and modifications may be made based on one or more factors such as the status of the sensor control device 102 and / or by applying rules based on the status of the sensor control device 102. For example, these rules may reduce the power consumed by the broadcasting process to the sensor control device 102 when the battery level of the sensor control device 102 falls below a predetermined amount. As another example, configuration settings related to broadcasting or otherwise transmitting packets may be adjusted based on the ambient temperature, the temperature of the sensor control device 102, or the temperature of certain components of the communication hardware of the sensor control device 102. In addition to modifying the transmission power, other parameters related to the transmission function or transmission process of the communication hardware of the sensor control device 102 may be modified, including but not limited to the rate, frequency, and timing of transmission. As another example, when the analyte data indicates that the subject is experiencing or about to experience an adverse health event, the above-mentioned rules may increase the discoverability of the sensor control device 102 to alert receiving devices of the adverse health event.

[0169] As embodied herein, certain calibration functions for the sensing hardware 5060 of the sensor control device 102 may be adjusted based on external or internal environmental functions and also to compensate for natural degradation of the sensing hardware 5060 during extended periods of non-use (e.g., a "shelf life" prior to use). The calibration functions of the sensing hardware 5060 may be adjusted autonomously by the sensor control device 102 (e.g., by operation of the ASIC 5000 which modifies functions in the memory 5020 or storage 5030) or by other devices in the analyte monitoring system 100.

[0170] As an example, the sensor sensitivity of the sensing hardware 5060 can be adjusted based on external temperature data or time since manufacture. When the external temperature is monitored during storage of the sensor, the subject matter of the present disclosure can adaptively change the compensation of the sensor sensitivity over time as the device experiences changes in storage conditions. By way of example and not limitation, adaptive sensitivity adjustment can be implemented using an "active" storage mode in which the sensor control device 102 is periodically woken up to measure temperature. These features can conserve the battery of the analyte device and extend the life of the analyte sensor. At each temperature measurement, the sensor control device 102 can calculate a sensitivity adjustment amount over that period based on the measured temperature. The temperature weighted adjustment amount can then be accumulated over the active storage mode period to calculate a total sensor sensitivity adjustment value at the end of the active storage mode (e.g., upon insertion). Similarly, upon insertion, the sensor control device 102 can determine the time difference between its or the sensing hardware 5060's manufacture (which can be written to the ASIC 5000's storage 5030) and modify the sensor sensitivity or other calibration functions according to one or more known natural degradation rates or natural degradation formulas.

[0171] Additionally, for purposes of illustration and not limitation, as embodied herein, the sensor sensitivity adjustment can take into account other sensor conditions, such as sensor drift. For example, in the event of sensor drift, the sensor sensitivity adjustment amount can be hard coded into the sensor control device 102 during manufacturing based on an estimate of how much an average sensor is expected to drift. The sensor control device 102 can use a calibration function having a time-varying function related to the offset and gain of the sensor that can take into account the drift over the period of wearing the sensor. Thus, the sensor control device 102 can use a function that accounts for the drift of the sensor control device 102 over time, represents the sensor sensitivity, and is used to convert the interstitial current to an interstitial glucose value using device-dependent functions that can be device-specific in combination with the baseline of the glucose profile. Such a function that takes into account the sensor sensitivity and drift can improve the accuracy of the sensor control device 102 over the period of wearing without the need for user calibration.

[0172] The sensor control device 102 detects raw measurements from the sensing hardware 5060. Sensor-related processing may be performed, such as by one or more models trained to interpret the raw measurements. The models may be machine learning models trained off-device to detect, predict or interpret the raw measurements to detect, predict or interpret one or more analyte levels. Yet another training model may be acted upon based on the output of the machine learning model trained to interact with the raw measurements. As an example, the models may be used to detect, predict or recommend an event based on the raw measurements and the type of analyte detected by the sensing hardware 5060. The events may include the initiation or completion of a physical activity, a meal, the application of a medical procedure or drug, an emergency health event, and other events of a similar nature.

[0173] The model may be provided to the sensor control device 102, the data receiving device 120, or the general-purpose device 130 during manufacturing or during firmware or software updates. The model may be periodically refined by the manufacturer of the sensor control device 102 or the operator of the analyte monitor system 100, etc., based on data received from the sensor control device 102 and data receiving devices of individual users or collectively multiple users. In some examples, the sensor control device 102 includes sufficient computer components to support additional training or improvement of the machine learning model based on unique characteristics of the user to which it is attached, etc. The machine learning model may include, by way of example and not limitation, models trained using or including decision tree analysis, gradient boosting, adaptive boosting, artificial neural networks or variations thereof, linear discriminant analysis, nearest neighbor analysis, support vector machines, supervised or unsupervised classification, and others. The model may include algorithmic models or rule-based models in addition to machine learning models. Model-based processing may be performed by other devices, including the data receiving device 120 or the general-purpose device 130, upon receiving data from the sensor control device 102 (or other downstream devices).

[0174] Data transmitted between the sensor control device 102 and the data receiving device 120 may include generated or processed measurements. Data transmitted between the sensor control device 102 and the data receiving device 120 may further include alarms or notifications for display to a user. The data receiving device 120 may display or otherwise communicate notifications to a user based on generated or processed measurements, or may display an alarm upon receiving it from the sensor control device 102. Alarms that may be triggered for display to a user include alarms based on direct analyte values ​​(e.g., a momentary reading that exceeds or fails to meet a threshold), trends in analyte values ​​(e.g., average readings that exceed or fail to meet a threshold over a set period of time, slope), predictions of analyte values ​​(e.g., when an algorithmic calculation based on the analyte values ​​exceeds or fails to meet a threshold), sensor alerts (e.g., detection of a suspected malfunction), communication alerts (e.g., when an unknown device attempts or fails to initiate a communication session with the sensor controlling device 102 when there has been no communication between the sensor controlling device 102 and the data receiving device 120 for a threshold period of time), reminders (e.g., reminders to charge the data receiving device 120, reminders to take medication or perform other activities), and other alerts of a similar nature. By way of example and not limitation, as embodied herein, the alarm parameters described herein may be configurable by the user, or may be fixed during manufacture, or may be a combination of user-settable and non-user-settable parameters.

[0175] As discussed herein, the data receiving device 120 (e.g., "receiving device") is often purposefully designed to limit cost and interoperability. The data receiving device 120 is often limited in processor capabilities and the type of wireless communication hardware included in the device. In particular, the data receiving device 120 is often not configured to communicate over a wide area network and thus lacks Wi-Fi enabled hardware. Instead, the data receiving device 120 is configured to simply wirelessly communicate with the sensor control device 102 to maintain security. Although multi-purpose devices 130 (e.g., smartphones, tablets, smart watches, etc.) are gaining popularity as a secondary option, the data receiving device 120 is utilized by a significant percentage of patients who wear analyte sensors.

[0176] A physical wired (e.g., USB) connection is established between the data receiving device 120 and the user device 140 to communicate the data to another user device 140 or to an application server 155. The user device 140 can then optionally relay relevant information to the application server 155. Software running on the user device 140 or application server 155 can interpret the received data and generate actionable reports based, for example, on the analyte data contained within the data.

[0177] The specimen report may be generated by the patient or HCP from software running on the HCP's user device 140 (e.g., a computer terminal at a doctor's office) or may be generated remotely on behalf of the patient or HCP by a web-based application. For the report to be generated based on the latest information from the data receiving device 120, the patient must periodically connect the data receiving device 120 to an internet-connected device through a wired connection. However, as described herein, providing a wired connection between the data receiving device 120 and the user device 140 may be cumbersome and inconvenient. The user device 140 should have a data interface software driver that can retrieve data from the data receiving device 120 and communicate it to the report generation software. When the driver associated with the data receiving device 120 or the user device 140 is updated, the driver must be obtained before a secure connection can be established, which further delays report generation. Due to lack of interest or knowledge, many patients do not take the time to create an account for the web-based report generation software or upload their latest data through an internet-connected device. Similarly, many HCPs do not create HCP accounts in the report generation software, and therefore, for many patients who utilize analyte sensors, the HCP cannot make effective and optimal treatment decisions based on up-to-date information from the user's sensor control device 102.

[0178] This problem may be particularly acute for users who rarely connect the data receiving device 120 to their user device 140. This may cause the drivers that facilitate a secure connection between the data receiving device 120 and the user device 140 to become out of date. For example, a non-specialized HCP may want to review the overall trends of analyte levels for their patients, but may not see patients using the data receiving device 120 very often. The non-specialized HCP may review data from the data receiving device 120 using the user device 140 only when certain patients visit the clinic. As another example, certain patients may be largely satisfied with reviewing daily information from the sensor controlling device 102 using the data receiving device 120, and therefore only connect their data receiving device 120 to the user device 140 when requested by the HCP.

[0179] HCPs, especially non-specialized HCPs, face a variety of challenges in accessing a patient's analyte data, especially reports generated based on the analyte data. These challenges are a major obstacle to the utility of continuous analyte monitors, such as continuous glucose monitors, to inform patient treatment decisions. Many analyte report generation tools require both the patient and the HCP to register respective accounts, each of which requires a username and password, with the application server 155 with which it is associated. The patient must then enter the account credentials in order to upload data from his or her data receiving device 120 to the application server 155 for processing. Similarly, the patient must grant the HCP permission to link his or her patient record with the HCP account. This permission requires both parties to remember their account credentials.

[0180] To address these obstacles, techniques are disclosed herein that are intended to enable the transfer of information useful for report generation without requiring a physical data connection to the data receiving device 120 or an account (either for the HCP or the patient) for the report generation software from the application server 155. The techniques for alternative methods and procedures for retrieving specimen data from the data receiving device 120 further simplify the procedures for primary care providers (PCPs) and other HCPs to view and perform analyses based on the specimen data by not requiring PCPs to generate separate accounts, be able to remember usernames and passwords, or engage in additional communication channels to request patients to provide data. Various systems and techniques are described herein for enabling HCPs to easily access their patient's specimen reports. Of particular advantage, the systems and techniques described herein do not require the extra overhead of having to manage new or unique accounts and data storage requirements. This allows the techniques of the present invention to be used with and tailored to specific clinical applications or electronic medical record (EMR) systems. These techniques can be extended to applications where EMR systems are configured to access specimen data where similar challenges exist, such as requiring patients to remember and provide access credentials in order for the EMR to allow one-time or repeat access to the patient's data.

[0181] 18 illustrates an example environment and data flow for an analyte monitor system 1800 configured to provide accessible analyte data reporting and system-to-system integration. A sensor control device 102 configured as described herein measures the level of one or more analytes of interest in a patient and provides the analyte level (or a signal from which the analyte level can be derived). In some examples, the sensor control device 102 can additionally or alternatively provide the analyte level to a multi-purpose device 130.

[0182] The data receiving device 120 is a low-cost proprietary computing device configured to communicate with the sensor control device 102 to provide basic report generation functionality regarding a patient's health. The data receiving device 120 generally does not have the capability for wireless communication with other general-purpose devices. The data receiving device 120 can be connected to the general-purpose device 130 or the user device 140 through a wired connection or through certain limited-function communication capabilities.

[0183] The multi-purpose device 130 and the user device 140 include general-purpose computing devices running software applications or other bundles of executable programming code configured to allow them to communicate with devices in the analyte monitor system 1800. The multi-purpose device 130 and the user device 140 are typically capable of performing some analyte data processing to generate some form of report or recommendation. The multi-purpose device 130 and the user device 140 may also relay data (processed or unprocessed) from the sensor control device 102 to various remote systems.

[0184] The remote systems include, by way of example and not limitation, a remote application server 155 associated with the analyte monitor system 1800, a report generation system 1860 associated with the analyte monitor system 1860, and an EMR system 1865 that may optionally be integrated with the analyte monitor system 1860. The remote application server 155 may enable advanced data processing based on individual patient data or patient data from large populations. The report generation system 1860 may generate reports based on the provided analyte data. The reports may be patient-identified, semi-anonymous, or fully anonymous based on the preferences of the user requesting their generation and the quality of the data. Generally, the EMR system 1865 is a medical record system operated and managed by or on behalf of the HCP. The EMR system 1865 may be integrated with the analyte monitor system 1800 under the examples described herein, thus automatically receiving patient analyte data and reports to facilitate treatment and therapy decisions by the HCP.

[0185] As described herein, the multi-purpose device 130 may include a user's smartphone or other device having wide area networking capabilities. The multi-purpose device 130 may have installed thereon an application associated with the analyte monitor system 100 that allows the multi-purpose device 130 to communicate with other devices in the analyte monitor system 100, including the sensor control device 102 and the remote application server 155. The application may provide a variety of additional functions.

[0186] In some examples, the application may provide functionality to facilitate shared access to specimen data uploaded by the multi-purpose device 130 to the remote application server 155 and reports generated therefrom. In the application's user interface, this functionality may be labeled as a "report sharing" functionality. When a user activates this functionality, a unique access code is displayed along with an access URL.

[0187] In some examples, the unique access code can be generated randomly on demand in response to a user request. In some examples, the application generates the access code, while in other examples, the access code is generated and provided to the application, for example, by the remote application server 155 or the report generation system 1860. Once the application generates the access code, the multi-purpose device 130 sends a message encrypted with the access code to the report generation system 1860. In some examples, the encrypted message can include additional information, such as the specimen data stored by the multi-purpose device 130 and received from the sensor control device 102. Alternatively, the multi-purpose device 130 can include information to identify the associated patient. The report generation system 1860 can use the identification information to retrieve recent specimen data from the application server 155. The report generation system 1860 stores the access code associated with the specimen data or any previously generated reports.

[0188] 19 illustrates an example data flow between components of an analyte monitor system 1900 configured to generate and provide accessible reports. At 1910, the sensor control device 102 provides analyte data to the general purpose device 130. As described herein, the sensor control device 102 can provide data continuously, in real time, or near real time when a connection between it and the general purpose device 130 is available. Additionally or alternatively, the sensor control device 102 can provide data on demand from the general purpose device 130.

[0189] At 1920, the multi-purpose device 130 transmits a request to share a report based on the analyte data with the report generation system 1860. The request may include the most recent analyte data from the sensor control device 102, including a predetermined immediately preceding period (e.g., 14 days). The amount of data included may be user-configurable, such as by the patient or the patient's HCP. In some examples, the request may additionally or alternatively include a reference to analyte data stored in another system, such as the remote application server 155 of the analyte monitoring system 1800.

[0190] Based on the analyte data received from the multi-purpose device 130 or retrieved from the remote application server 155 at the request of the multi-purpose device 130, the report generation system 1860 can generate a report associated with the user. The report can include information such as trends based on the analyte data, trends seen in similar patients or the general population, suggested therapy modifications, and a wide range of other information. At 1930, the report generation system 1860 can send the report to the multi-purpose device 130 for viewing by the user of the multi-purpose device 130. Additionally or alternatively, the report generation system can provide a unique access code and access URL that can be used by another user of another user device 140 to view the report. In some examples, the multi-purpose device 130 can generate an access code and provide it to the report generation system 1860 during 1920 or during an additional transmission.

[0191] At 1940, the user device 140 sends a request to view a report on the analyte data from the sensor control device 102. The user device 140 may navigate with a web browser or other suitable application to the access URL. The user of the user device 140 may enter the access code into a website that may be provided by the report generation system 1860, its subsystems, or an associated website server. The report generation system 1860 may use the access code to identify the analyte data from the sensor control device 102 or a pre-generated report based on the analyte data, if available. The report generation system 1860 may search a database that stores analyte data associated with a valid access code. Upon finding a valid record, at 1950, the report generation system 1860 provides a report to the user device 140 for review.

[0192] FIG. 20 illustrates an exemplary user interface of an application executed according to certain embodiments. In particular, FIG. 20 illustrates a user interface of an application executed on a multi-purpose device 130. The interface 2000 includes several options for accessing data collected by the multi-purpose device 130 from the sensor control device 102 and local reports. Among these options is an interaction element 2005 (e.g., an interface button) labeled "Share Report." When a user selects the interaction element 2005, the multi-purpose device executes the routine described above for collecting specimen data associated with the immediately preceding time period and sending the latest specimen data to the report generation system 1860. The multi-purpose device 130 also generates or receives an access code associated with the report. The interface 2010 includes a display element 2015 for the access code, in this case "12YZ." Similarly, the interface 2010 includes a display element 2017 that instructs the viewer to visit a particular website to view an associated report.

[0193] As described herein, in some examples, the multipurpose device 130 may have a constant connection to the remote application server 155 or the report generation system 1860. When the user interacts with the interactive element 2005, the multipurpose device 130 may request that data over a corresponding period of time be made available. The period of time may be selected by the user, for example, based on information included in the request to share the report, or may be automatically determined, for example, based on the time span of data available to the user. In addition, in some examples, the remote application server 155 or the report generation system 1860 may generate an access code and send the access code to the multipurpose device 130 to ensure that the report is available.

[0194] At a later point in time, the report generation system 1860 receives a request from a user device 140 for a report based on the patient data. The request includes the access code. The report generation system 1860 searches the patient data records and / or reports and identifies corresponding information based on the access code. The report generation system 1860 can then provide the corresponding report to the user device 140 that requested the report.

[0195] FIG. 21 illustrates an exemplary user interface of another device according to certain embodiments. In particular, FIG. 21 illustrates a user interface of an application or web browser that can be executed on the user device 140 and used by another user, such as an HCP. The interface 2100 includes a web browser that executes on the user device 140. As indicated by the address bar 2105, a user (e.g., an HCP) of the user device 140 navigates to a website provided in the interface 2010. The website includes a user input prompt 2107 that requests the user to enter a code to review a corresponding report. After entering the code, for example the code shown in the interface 2010, the report generation system 1860 receives the code and searches an associated database for corresponding specimen data or pre-generated reports. In the event that no pre-generated report exists for the corresponding specimen data, a report can be generated on demand based on the corresponding specimen data. The interface 2110 illustrates an exemplary presentation of a report 2117 to a user of the multi-purpose device 130. As described herein, the report can include a variety of information and can be provided in a variety of forms based on user preferences and the capabilities and features of the user device 140. If no report exists that corresponds to the code entered by the user or the code is no longer valid, the interface 2117 can instead indicate an error indicating that the data is not available or that the code has expired.

[0196] As described herein, the access code can be limited in terms of number of uses, duration of use, or other contextual information. As an example, the access code can be set to be usable only for 15 minutes, after which the access code expires. As another example, the access code can be set to be usable only by devices within a particular geographic area or within a specified distance of the multi-purpose device 130 at the time the user requests to share his / her report. When another user device 140 submits a request that includes the access code, the general location of the user device can be determined and included in the request. Appropriate restrictions on when and how frequently reports can be retrieved improve the security of patient data using the techniques described herein.

[0197] In some examples, the application running on the multi-purpose device 130 has a continuous connection with the remote application server 155 or report generation system 1860. Through this connection, the multi-purpose device 130 continuously uploads data received from the sensor control device 102 worn by the user. The data is stored in one or more databases associated with the user. In some examples, the database may store or associate the analyte data with an account registered by the patient. For example, the patient may register a username or user identifier and a password that may be required to access the data. As another example, the user may store the analyte data in an unidentifiable manner using an anonymous account. In such examples, the remote application server 155 or report generation system 1860 may recognize an identifier for the multi-purpose device 130 (e.g., serial number, IMEI, MAC address, etc.) or an identifier for an application instance of an application running on the multi-purpose device 130. The remote application server 155 may associate the analyte data from an identifier in the same database as the recognized identifier. In this example, when a patient requests to share a report, an access code is generated and shared and displayed between the multi-purpose device 130 and the report generation system 1860. Specimen data is not sent on demand from the multi-purpose device to the report generation system 1860.

[0198] As described herein, in the analyte monitor system 100, a user may be provided with a proprietary data receiving device 120 (e.g., a "receiving device"). The data receiving device 120 may include hardware and programming for communicating with the sensor control device 120, but may generally have only limited functionality, including lacking the ability to communicate using a wide area network. Alternatively, the data receiving device 120 may be connected to a user device 140 by a wired connection for uploading the analyte data to an application server 155 for further storage and processing. The user device 140 may store data related to the data receiving device 120 and may upload the analyte data to a remote application server 155. While the low cost of the data receiving device 120 may be advantageous to provide to a user, the lack of the ability to easily communicate data stored on the data receiving device 120 to another user, such as an HCP, on demand limits the usefulness of the analyte data for the HCP to view when making treatment decisions. It would therefore be beneficial to provide a simplified process for communicating specimen data and other information from a data receiving device 120 to a user device 140 (such as a user device of an HCP in a clinical environment) without a direct wired or wireless connection. In particular, it would be beneficial to enable HCPs to view authentic reports based on specimen data similar to those available via the above-described "report sharing" feature provided through the multi-purpose device 130.

[0199] In accordance with the techniques described herein, the software executing on the data receiving device 120 can be modified to provide a "Data Share" feature accessible, for example, from a settings menu. Instead of uploading the data to a remote server (as the data receiving device 120 cannot connect to a remote server), when selected by the patient, the data share feature causes the data receiving device 120 to generate and display a specially configured matrix barcode (e.g., a quick response (QR) code). This matrix barcode can be generated to include a URL that defines the internet location of a web server associated with the report generation system 1860 to transmit a request to generate a report based on the specimen data provided with the request. The matrix barcode can further include a sequence of specimen data value codes that can be provided as parameters passed with the URL.

[0200] The specialized encoding described herein allows a large amount of data to be included within the matrix barcode, balancing the ability for a user to interact with and use the matrix barcode against still providing enough data to provide useful information when converted into a report. For example, analyte value readings can represent values ​​every 15 minutes over a 14 day period.

[0201] Once the data receiving device 120 generates the matrix barcode, another user can scan the matrix barcode with the multi-purpose device 130. Many modern smartphones, for example, include cameras that can automatically recognize and decode simple matrix barcodes. A patient or HCP user can scan the matrix barcode using a built-in camera function within the smartphone or user device 140. The smartphone or user device 140 can direct a web browser to a website server 1860 identified by the URL code. The website server 1860 includes a report generation function that decodes the specimen data codes and generates a specimen report based on these data. The website server 1860 will send the report back to the web browser for display on the multi-purpose device 130 or user device 140. In some instances, no identifying information is encoded in the matrix barcode, i.e., the security of the specimen level report is protected by being unidentifiable and requiring physical access to the matrix barcode to be available.

[0202] If the HCP wishes to view the report on another device, such as the user device 140, the report generation system 1855 can generate an access code, associate it with the specimen data in the database, and display the access code on the general-purpose device 130 along with a URL that allows the HCP to access the corresponding report. As in the previous example, the HCP visits the report viewing website with the user device 140, provides the access code displayed by the general-purpose data receiving device 130, and receives the report from the report generation system 1860.

[0203] In some examples, for added security, the web server 1860 may generate an access code and include this access code in the glucose report displayed on the multi-purpose device 130 along with another URL identifying another website. The access code may be, for example, a random alphanumeric code. The HCP may access the second website from a web browser on their own internet-connected user device 140 or any other internet-connected device by entering the URL into the URL field of the browser. The second website may be provided by the same provider as the first website. The second website may request the HCP to enter the access code by causing a code entry field to appear on the web browser of the user device 140. Upon entering the code and indicating submission, the second website will receive the access code and generate a sample report with the patient data for display on the web browser of the HCP's user device 140.

[0204] In some examples, the report generating system 1860 can generate access codes for the first and second websites. In some examples, the access codes can be generated by the data receiving device 120 as part of a process for generating, for example, a matrix barcode. The access codes can be associated with the report (if generated when the sample data is received) or can be associated with the sample data used to generate the report on demand. The access codes can be used permanently or semi-permanently by a user of the data receiving device 120 to facilitate secure data sharing, or the like. Alternatively, the access codes can be associated temporarily with the report or the sample data. This association can be removed after expiration of a predetermined or user-specified amount of time, after the report has been accessed a specified number of times (e.g., to facilitate sharing the same report with multiple other users), or upon request by the user of the data receiving device 120 or the user who accessed the report. The codes can take any form, such as an alphanumeric sequence such as "AB12" or can include other symbols or pictograms (e.g., emojis).

[0205] 22 and 23 show a first procedure 2200 and a second procedure 2300 for requesting and generating a report based on analyte data provided through a matrix barcode. The process begins at 2201, where a data receiving device 120, also referred to at this point as a receiving device, collects analyte data from a sensor control device 102. The data receiving device 120 may be part of an analyte monitoring system 100, such as a glucose monitoring system. The data receiving device 120 may include a display, one or more processors, and a memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the first procedure 2200, such as operations 2201 through 2206.

[0206] In 2202, the data receiving device 120 receives a request to share or offload analyte data, for example, by a user of the data receiving device 120 selecting an interactive element provided on a user interface of the data receiving device 120.

[0207] At 2203, the data receiving device 120 retrieves analyte data associated with a particular time period of interest. The data receiving device 120 can be configured to automatically identify data relating to a predefined time period (e.g., the last 14 days, 7 days, 24 hours, etc.). In some examples, the request received at 2202 can specify the time period of interest.

[0208] At 2204, the data receiving device 120 encodes the retrieved data. The specimen data may be encoded prior to generating a matrix barcode associated with the specimen data. The specimen data code may be achieved by formatting the data to conform to parameters provided to the report generation system 1860 such that the report generation system 1860 may generate a report. As an example, the data code may include a date stamp and / or time stamp for each specimen data value associated with the specimen data. The data code may include a single date stamp and / or time stamp followed by a sequence of specimen data values ​​that are interpreted as being provided at regular intervals (e.g., every 5 minutes, every 15 minutes, every 30 minutes, etc.). This encoding reduces the need to include explicit timing information for each specimen data value when it is not necessary.

[0209] In some examples, other data may be encoded and included within the matrix barcode. As an example, elements to be included in a sample report may be generated and encoded. Elements to be included in a sample report may include, for example, percentile line data or other sample data metrics calculated from the sample data. In some examples, the elements to be included may be based on the type of sample being tracked. For example, if the sample is glucose, the data code may include time in hypoglycemia range, time in hyperglycemia range, and time in euglycemia range. The data code may include derived values ​​calculated from the sample data. In some examples, other data encoded and included within the matrix barcode may include an identifier for the data receiving device 120, an identifier for the patient, an identifier for software running on the data receiving device 120, or other methods for uniquely identifying the data encoded within the matrix barcode.

[0210] When generating a matrix barcode, the complexity of the barcode scales with the density of data that can be included in the matrix barcode. The more information, especially the number of bytes, that one tries to include in the matrix barcode, the more complex the barcode becomes. While the size of the matrix barcode can be expanded to allow for more information, there is a limit at a certain point based on the display resolution of the device that displays the matrix barcode (e.g., data receiving device 120) and the fidelity of the camera used to scan the matrix barcode. Therefore, additional encoding can be used to improve the balance of information density in the barcode.

[0211] One technique for reducing information density is to shorten the time period covered by the specimen data included in the matrix barcode. Another technique for reducing information density is to reduce the frequency of specimen data in the data columns (e.g., specimen data values ​​corresponding to every 30 minutes instead of every 15 minutes). These solutions are simple and do not require additional computer power or time to use. However, they also reduce the amount of useful data that is presented to a user (e.g., HCP) viewing the resulting report.

[0212] Various forms of data compression can be used to reduce information density but maintain parameters such as duration and frequency of included data. As an example, the dynamic range (e.g., precision) of analyte data values ​​can be reduced in a context-aware manner. One such data compression technique can be rounding of analyte data values. For example, analyte data values ​​can be stored by a data receiving device with a precision to 0.1 mg / dL. Prior to encoding the data values ​​into a matrix barcode, the data can be rounded or truncated to a precision to 1 mg / dL. As another example, analyte data values ​​can be rounded to increments of 5 mg / dL (or 10 mg / dL or other suitable value).

[0213] In some examples, rounding can be performed to round to different levels of precision based on the original value of the analyte data value itself. Specifically, analyte data values ​​greater than a threshold value can be rounded to a more precise value if analytes with values ​​higher than the threshold are considered more important to monitor than analytes with values ​​lower than the threshold. The inverse can be applied if analyte data values ​​with lower values ​​are considered more important to monitor. Multiple thresholds and multiple rounding precision levels can be used to scale the rounding precision accordingly. Furthermore, the thresholds can be pre-programmed or set by a user of the data receiving device 120 or a user (e.g., HCP) reviewing the report based on the individual user's requirements or preferences.

[0214] As an example, where the analyte is or correlates to a glucose value, it may be preferable to have a higher resolution glucose value for low glucose values ​​than for high glucose values. When decoding a glucose sequence, approximate resolution to 1 mg / dL can be partially restored by using a spline technique on the sequence and rounding the resulting glucose values ​​to the nearest 1 mg / dL.

[0215] An example of a multi-threshold rounding scheme is provided below: For glucose values ​​between 40 and 100, round to the nearest 2 mg / dL. For glucose values ​​between 101 and 180, round to the nearest 3 mg / dL. For glucose values ​​between 181 and 280, round to the nearest 4 mg / dL. For glucose values ​​between 281 and 400, round to the nearest 5 mg / dL.

[0216] When rounded, the analyte data used for the matrix barcode metrics calculated by the report generation system 1860 for inclusion in the report are calculated using the rounded data. The metric values ​​calculated and included in the report using analyte values ​​with higher precision may differ from the metric values ​​calculated using analyte values ​​with rounded precision. Thus, the metric values ​​shown in the report may differ slightly from the values ​​shown on the data receiving device 120. As a result, the user or HCP may question the accuracy of the data, become distracted by the inconsistencies, or even change therapy recommendations based on less accurate data. To address this issue, the input data to the matrix barcode may further include metrics that are calculated based on the original analyte data (e.g., with full resolution) and will be used in the report that is subsequently generated. The report generation system 1860 may use these metrics based on the original analyte data instead of recalculating the metrics from the rounded glucose data. This has the added benefit of allowing the report generation system 1860 to run more efficiently due to the metrics not having to be calculated before the report can be generated.

[0217] The report generating system 1860 receiving the web request based on the data code will interpret the data as necessary. In some examples, the web request (and thus the matrix barcode) may include an identifier for the encoding. The identifier may be, for example, a version number based on which the report generating system 1860 may select an appropriate decoding procedure. The inclusion of the identifier may provide additional flexibility in programming the data receiving device 120, allowing multiple types of encoding to be used simultaneously, and allowing a user of the data receiving device 120 to use the procedure without having to update the software or firmware running on the device. The type of encoding may further be selected based on the type of specimen data, the density of data included in the request, or user preferences.

[0218] Returning to step 2200 of Figure 22, step 2200 continues to 2205 at which point the data receiving device 120 generates a matrix barcode. The matrix barcode may be generated using an available algorithm or technology (e.g., QR Code®) or may be generated by a proprietary algorithm used by the analyte monitoring system 1800. While a proprietary algorithm may be used to improve the security of the process and allow for additional functionality using the matrix barcode (e.g., including more data), this may also limit the interoperability and advantages provided by using a more general technology.

[0219] At 2206, the data receiving device 120 displays the matrix barcode. Additionally, the data receiving device 120 may display instructions regarding using the matrix barcode to request and retrieve the report.

[0220] At 2211, the matrix barcode is scanned. As an example, the multi-purpose device 130 can scan the matrix barcode. The multi-purpose device 130 can be part of the analyte monitor system 100, such as a glucose monitor system. The multi-purpose device 130 can include a display, one or more processors, a camera (or other hardware for scanning the matrix barcode), and a memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the first procedure 2200, including operations 2211, 2212, 2213, and 2214.

[0221] Another user device 140 can be used that has the appropriate hardware (e.g., camera) and software to decode the matrix barcode. Many camera applications on modern smartphones include the ability to easily recognize and scan matrix barcodes.

[0222] At 2212, the matrix barcode is decoded to obtain the URL and parameters to be used therewith. As with scanning a matrix barcode, many modern smart phones include the ability to decode and interpret commonly available matrix barcodes. In cases where a proprietary algorithm is used to generate the matrix barcode, instructions may be provided to the general purpose device 130 to download or execute programming code to decode the matrix barcode. For example, an application associated with the analyte monitor system 1800 may be downloaded and executed on the general purpose device. Generally, decoding the matrix barcode includes identifying the data encoded in the matrix barcode. For example, where the matrix barcode includes an access URL and analyte data, decoding the matrix barcode includes converting the information in the matrix barcode into plain text or another format suitable for interpretation by the general purpose device 130, at which point the general purpose device 130 determines how the data is to be processed.

[0223] At 2213, the URL and parameters are used to generate and send a web request. For example, a web browser running on the data receiving device 120 can be used. Once the matrix barcode has been decoded, the access URL and the specimen data provided as parameters for the web request to generate the report are available to the multi-purpose device 130. The multi-purpose device 130 can construct the web request using standard functions. The multi-purpose device 130 sends the request to the report generation system 1860.

[0224] At 2221, the report generation system 1860 receives a web request based on the URL and the parameters. The report generation system 1860 can be part of the analyte monitor system 100, e.g., a glucose monitor system. The report generation system can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the first procedure 2200, e.g., including operations 2221 and 2222. At 2222, the report generation system 1860 generates a report. As discussed herein, the report generation system 1860 can interpret parameters passed by the multi-purpose device 130 to determine the analyte values ​​to be used for the report. The report may take a variety of forms, including displaying individual analyte data values, displaying trend information (e.g., short and long term extremes, time in range, rate of change trends, etc.), displaying treatment summaries, displaying therapy recommendations, and displaying other suitable information. The content of the report is based on the data available to the report generation system 1860. When the data is of mostly low quality or anonymous, the report will necessarily be more limited than when the data is of high quality and patient-specific. Following generation, the report generation system 1860 may transmit the report back to the general purpose device 130. By way of example, the report may be provided as a formatted web page or portable document (e.g., PDF).

[0225] At 2214 , the report is displayed by the general purpose device 130 .

[0226] Figure 23 illustrates an associated procedure 2300 for requesting and generating a report based on specimen data provided via a matrix barcode. In particular, operation 2321 is an alternative version of operation 2221 shown in Figure 22. Operations 2201-2206 and 2211-2213 shown in Figure 22 may also be performed prior to Figure 23, and these operations are excluded for the sole purpose of providing a concise description of procedure 2300.

[0227] At 2321, the report generation system 1860 receives a web request (e.g., a "first web request") based on the URL and parameters. The report generation system 1860 can be part of the analyte monitor system 100, e.g., a glucose monitor system. The report generation system can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 2300, e.g., including operations 2321-2325. The first web request includes a request to enable limited access to additional user devices 140. At 2322, the report generation system 1860 generates a report based on the received parameters. The report generation system 1860 generates a report based on available analyte data using processes described herein.

[0228] At 2223, the report generation system 1860 generates an access code for the report. As described herein, the access code can be associated with the specimen data or report once generated to limit access to the report to only those individuals who have it. Additionally, the report can be used to share the report and specimen data with multiple users and systems without requiring a direct connection between the multi-purpose device 130 and the other systems. On behalf of the multi-purpose device 130, the report generation system 1860 uses the access code to validate access to the report and provides the report on behalf of the patient to the other system.

[0229] At 2224, the report generation system 1860 associates the access code with the report. For example, the report generation system 1860 can store the access code with the report in a database. In instances where the report is generated on-demand for display, the database can instead store the specimen data passed as a parameter to the report generation system 1860 in relation to the access code. As mentioned above, the access code can be a temporary access code that is deleted after certain conditions occur, such as, for example, a number of uses, the passage of a specified amount of time, etc.

[0230] After generating the access code, the report generation system 1860 can send it to the general-purpose device 130 that sent the web request in 2213. For example, the access code can be provided in response to the web request.

[0231] At 2315, the access code may be displayed by the multi-purpose device 130. The multi-purpose device 130 may be part of the analyte monitor system 1800, e.g., a glucose monitor system. The multi-purpose device 130 may include a display, one or more processors, a camera (or other hardware for scanning matrix barcodes), and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 2300, e.g., including operation 2315. In addition to the access code, the multi-purpose device 130 may display an access URL that allows the report to be accessed. Note that in some examples, the multi-purpose device 130 itself may generate the access code and include it in the report generation request issued to the report generation system 1860.

[0232] At 2331, another user device 140 may visit the access URL using a web browser. The user device 140 may be part of the analyte monitor system 100, e.g., a glucose monitor system. The user device 140 may include a display, one or more processors, and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of procedure 2300, e.g., including operations 2331-2333. A web page may be displayed that requests the user of the user device 140 to enter an access code. The access URL may be a publicly available URL and any web browser may be used to visit the access URL, since a visitor to the access URL cannot retrieve patient data without the access code. Additionally, in examples where data included in reports shared by the functionality described herein includes anonymous or non-identifiable data, individual patient information is not at risk. The report may be further protected by a password or other contextual information that limits access to the report if the patient allows personal information to be included. This can reduce the effectiveness of brute force techniques to guess access codes to retrieve patient information.

[0233] In 2232, the user device 140 can receive the access code as input to the web page. The user device 140 can send a second web request to the report generation system 1860 (or another associated server) using the access code.

[0234] In 2225, the report generation system 1860 can retrieve the report based on the access code and the second web request. After receiving the access code, the report generation system 1860 can use the access code to search an associated database and identify the report according to the access code. If the access code cannot be located or has expired, the report generation system 1860 can send a message to the user device 140 indicating that an error has occurred and identify the source of the error. If the access code is located and valid in response to the second web request, the report generation system 1860 can send the report to the user device 140.

[0235] At 2333, the user device displays the report. The report may be displayed within a web browser or using an application configured to display reports. In some examples, the report may be best viewed using a proprietary application that may be associated with the analyte monitor system 1800 and installed on the user device 140.

[0236] Although the above examples are described in the context of a data receiving device 120, similar techniques can be used for a general purpose device 130 configured to receive and process data from a second controlling device 102. Although the general purpose device 130 may include hardware for connecting to a wide area network (including the Internet), the user may lack the time or motivation to ensure that the remote application server 155 has up-to-date information before visiting the HCP. Similarly, the user may not have an account set up with the remote application server 155 or valid to share specimen data with the HCP. Furthermore, the general purpose device 130 may not have access to a wide area network (e.g., no cellular service) to upload up-to-date information when visiting the HCP. The examples described herein eliminate the need for the patient and / or HCP to open and maintain an account with the report generation software or to maintain a persistent connection to the remote application server 155 or the report generation system 1860.

[0237] FIG. 24 illustrates an exemplary user interface of an application executed according to certain examples. In particular, FIG. 24 illustrates a user interface of an application executed on a data receiving device 120 that does not have wide area networking capabilities. The interface 2400 includes several options for accessing data collected by the data receiving device 120 from the sensor control device 102 and local reports. Among these options is an interactive element 2405 labeled "Share Report." When a user selects the interactive element 2405, the data receiving device 120 executes routines, including those described herein, aimed at collecting and encoding analyte data associated with the immediately preceding time period. Additionally, the data receiving device 120 generates a matrix barcode that includes the specimen data code and a URL to cause the general purpose device 130 to upload the specimen data code to the report generating system 1860. The data receiving device 120 then displays the matrix barcode in an interface, such as interface 2410, that provides instructions on how to initiate the upload.

[0238] FIG. 25 illustrates an exemplary interface of an application executed according to certain examples. In particular, FIG. 25 illustrates a user interface of an application executed on the multi-purpose device 130. The interface 2500 corresponds to a camera application of the multi-purpose device 130. The user positions the multi-purpose device 130 so that the data receiving device 120 is within the field of view of the camera of the multi-purpose device 130 while showing the interface 2410. The user of the multi-purpose device 130 scans the matrix barcode shown in the viewfinder using the interaction element 2507. After scanning the matrix barcode, the multi-purpose device 130 decodes the matrix barcode and interprets the URL and the specimen data encoded therein. The multi-purpose device 130 then sends a web request based on the URL to upload the specimen data to the report generation system 1860. The report generation system 1860 stores the specimen data in a database and generates an access code associated with the specimen data. The report generation system 1860 provides the access code and the access URL to the multi-purpose device 130. Interface 2510 illustrates an interface that is shown after a user has successfully uploaded specimen data. Interface 2510 includes a display element with an access code 2515 provided by the report generation system 1860 and a display element with an access URL. Once the user visits the access URL and provides the access code, the user device 140 used to visit the access URL may provide an interface such as that shown in FIG.

[0239] Electronic medical record (EMR) systems are used by many HCPs. EMR systems (e.g., EMR system 1865) store data about patients and about interactions between patients and HCPs. In some instances, it may be beneficial to incorporate systems and techniques, including those described herein, aimed at generating reports about patient specimen data. In particular, it may be beneficial to streamline the process used by HCPs and by the EMR system 1865 itself to access patient specimen data. For example, a specimen report generation application as described herein may be included as part of the EMR system. The specimen report generation application may be any software program provided on a computer of the HCP or accessible by the HCP, and in some instances provided on a server, not necessarily an EMR.

[0240] In many systems, patient data is only accessible for storage and processing by the EMR system 1865 with explicit permission from the patient. The patient must log into their account on the remote application server 155, identify the correct HCP who needs to review their specimen data, and ensure the data provided is up to date. In some cases, before the patient can authorize data sharing, the HCP must also log into their account on the remote application, identify the correct patient, and submit a request. The HCP may also need to remind the patient to approve the sharing request. This process is time consuming and prone to errors where a user may forget their account credentials, identify the wrong patient or HCP, or make other errors, resulting in a largely inefficient use of time by the HCP as they review the patient's medical records and treatment options. Attempts have been made to automate some parts of this process. For example, the EMR system 1865 and the remote application server 155 may attempt to match information such as the patient's name, unique identifier, or contact information to generate a request to authorize data sharing. In this case, however, the patient is required to ensure that the information provided to their HCP and the information provided to the remote application server 155 is the same; any spelling errors or, for example, different contact information may take the patient back into a fully manual process. Even if the match is successful, the patient must still log into their account on the remote application server 155 to authorize the sharing request. Furthermore, previous attempts to automate data sharing do not take into account patients who do not have an account on the remote application server 155.

[0241] 26 illustrates an example data flow 2600 between components of a analyte monitor system configured to facilitate a persistent connection or association between a remote application server 155 and an EMR system 1865. The illustrated data flow begins at 2601, where an HCP uses a user device 140 to request a report from the EMR system 1865 based on or using the patient's analyte data from the remote application server 155. The HCP can send a request to review the patient's most recent analyte data or otherwise generate a request that requests an interface between the EMR system 1865 and the remote application server 155.

[0242] Upon receiving the request, the EMR system 1865 determines that it does not have access to the patient's specimen data stored in the remote application server 155. The request may include a unique identifier for the patient (e.g., a patient identification number or other unique identifier). In some examples, the EMR system 1865 may query its data from the remote application server 155 for stored data about the patient integrated with the EMR system 1865 in a database associated with the EMR system 1865 using the unique identifier for the patient. In some examples, the EMR system 1865 may query the remote application server 155 for a request for data and reports related to the patient identifier. If integration between the remote application server 155 and the EMR system 1865 for a particular patient is not complete, the EMR system 1865 will receive a denial to the request to access the data and reports.

[0243] If the EMR system 1865 determines that the EMR system 1865 is not integrated with the remote application server's data for a particular patient, then in 2602 the EMR system 1865 responds that the HCP does not have access to the requested information for the patient. The user device 140 may display an error message to the HCP and / or the EMR system 1865 indicating that access is not permitted. In some examples, the EMR system 1865 may display instructions on the user device 140 to the HCP regarding how to request access and / or how to integrate the EMR system 1865 with the remote application server 155. As an example, the user device 140 may display a prompt through the EMR system application prompting the HCP to enter an access code associated with the patient data.

[0244] 27 illustrates an example interface for a user device 140 running an application associated with the EMR system 1865 and showing how to request specific specimen data access. The interface includes a user input field 2705 that allows the HCP to enter an access code provided by the patient.

[0245] Returning to the data flow of Figure 26, at 2603, the EMR system 1865 sends a request to receive patient data associated with the patient identified by the HCP. The request may include a unique patient identifier and other information that allows the remote application server 155 to identify which patient the HCP is interested in. The remote application server 155 may perform validation and integrity checking on the request to reduce the opportunity for a malicious user to spam authorizations from the patient.

[0246] At 2604, upon receiving the request from the EMR system 1865, the remote application server 155 can request the report generation system 1860 to initiate an integration process on behalf of the EMR system 1865. As described herein, the integration process includes generating an access code, providing the access code through the patient's multi-purpose device 130, and enabling the user device 140 to provide the access code to the report generation system 1860. Thus, the report generation system 1860 can generate a request to the multi-purpose device 130. The request can include an indication that an HCP has requested patient specimen data access on the multi-purpose device 130. The request can identify the HCP if available, e.g., if provided by the EMR system 1865. The request can include the access code generated by the report generation system 1860. At 2605, the EMR system 1865 provides the request to the multi-purpose device 130.

[0247] Upon receiving the request from the report generation system 1860, the multi-purpose device 130 may display an access code. An application associated with the remote application server 155 may be launched for foreground execution by the multi-purpose device 130 and notify a user (e.g., patient) of the multi-purpose device 130 that an HCP has requested access to the user's specimen data. The application may display the access code and provide instructions for the patient to show the access code to the HCP. In some examples, the multi-purpose device 130 may first verify that the patient wishes to share their specimen data and reports with the HCP before displaying the access code. In some examples, the multi-purpose device 130 may itself generate the access code, in which case the multi-purpose device 130 may further provide the access code to the report generation system 1860 (not illustrated).

[0248] In some examples, the process of generating an access code is initiated by the patient rather than by the report generation system 1860 on behalf of the HCP. As discussed herein, the patient can use a "report sharing" feature to generate an access code that is shared between the multi-purpose device 130 and the report generation system 1860. The report generation system 1860 can use the access code to identify the patient's record as discussed below.

[0249] The patient provides the access code to the HCP, who enters the access code into a user input presented on an application running on the user device 140 and associated with the user EMR system 1865. In 2606, the user device 140 provides the entered access code to the EMR system 1865.

[0250] At 2607, the EMR system 1865 provides the access code to the report generation system 1860. For purposes of simplicity, this provision is shown as a direct transmission between the EMR system 1865 and the report generation system 1860, but it should be understood that the access code can be provided by the EMR system 1865 to the report generation system 1860 through the remote application server 155. Similarly, in some examples, the user device 140 can have or establish a connection to the report generation system 1860 and can provide the access code to the report generation system 1860 through this connection. As an example, the general purpose device 130 can display an access URL for the report generation system 1860 in addition to displaying the access code. The HCP can navigate to a website accessible by the access URL using the user device 140 and provide the access code to the report generation system 1860 through this website.

[0251] Upon receiving the access code, the report generation system 1860 validates and verifies the access code from the user device 140 with the access code it generated (or generated and provided to the report generation system 1860 by the multi-purpose device 130). Validating the access code may include determining that the access code has not expired and does not have other constraints that limit the use of the access code to enable integration of specimen data. If the access code is invalid, the report generation system 1860 may optionally notify the user device 140 (e.g., via the remote application server 155 or the EMR system 1865 as an intermediary system) that the access code provided is not valid or that some other error has occurred. The report generation system 1860 may notify the multi-purpose device 130 of the error.

[0252] If the access code is valid, the report generation system 1860 may perform an additional access validation check with the multi-purpose device 130. In some examples, the process shown in data flow 2600 may be used to generate a continuous or permanent integration of the patient's specimen data with the EMR system 1865. Because this integration may involve highly sensitive information, the specimen monitoring system 1800 may require the patient to validate the request even after the HCP provides the access code. This request acts as a second factor to authenticate access to the patient data. At 2608, the report generation system 1860 sends a validation request to the multi-purpose device 130.

[0253] The multi-purpose device 130 receives the validation request and displays it to the patient. As an example, the validation request can be displayed as a pop-up or push notification on the multi-purpose device 130. The notification can include a user interface with a prompt that prompts the user to validate the access request made by the HCP. The notification can include information about the HCP and the EMR system 1865 that was provided when the EMR system 1865 provided the access code to the report generation system 1860. At 2609, the multi-purpose device 130 provides the patient's response to the prompt to the report generation system 1860.

[0254] If the patient denies access through a prompt, the report generation system 1860 can deny access to the EMR system 1865. The report generation system 1860 can notify the EMR system 1865 that the patient's specimen data access was not granted. In some examples, the report generation system 1860 can measure the number of access requests for a particular patient or made by a particular EMR system 1865 or HCP over a period of time and determine to block additional access requests if abuse of the system is suspected.

[0255] If the patient responds affirmatively to the validation request, then in 2610, the report generation system 1860 notifies the remote application server 155 that access has been granted. The report generation system 1860 can notify the remote application server 155 associated with the analyte monitoring system 1800 that a valid access code was received and that the multi-purpose device 130 verified the request.

[0256] At 2611, the remote application server 155 authorizes the requested patient specimen data access and provides the requested data and reports to the EMR system 1865. As described, data integration can enable the HCP to retrieve the latest available specimen data for the patient using the EMR system 1865. For example, the sensor control device 102 worn by the patient provides data to the multi-purpose device 130, which is uploaded to the remote application server 155 so that the data can be shared with or accessed by the HCP through the EMR system 1865. The patient can control which data is shared, for example, allowing only one-time data sharing or sharing data over a specific time range or period. Of particular advantage is that the system can proceed without either user (e.g., patient or HCP) being required to remember access credentials for any of the systems being used. In addition, the patient's identity and the HCP's identity are verified with each other multiple times throughout the process, which helps ensure that the right data for the right patient is shared with the right HCP.

[0257] FIG. 28 illustrates user interfaces that may be displayed on a multipurpose device in accordance with examples disclosed herein. In particular, FIG. 28 illustrates a detailed view of user interfaces 2800-2820 that may be used to facilitate integration of shared specimen data from a remote application server 155 with an EMR system 1865. User interface 2800 includes a notification 2805 that is generated from an application executing on the multipurpose device 130 associated with the specimen monitoring system 1800 and indicates that an HCP has requested access to a patient's specimen data. Notification 2805 includes an access code to be used by the HCP as described above. Interface 2810 illustrates a notification 2813 that is generated from an application executing on the multipurpose device 130 associated with the specimen monitoring system 1800 and indicates that a particular HCP has entered an access code. Notification 2813 includes a dialogue element 2815 for approving or authorizing access and a dialogue element 2817 for denying access. Interface 2820 illustrates a notification confirming that access has been granted.

[0258] Once a connection or association between the EMR system 1865 and the remote application server 155 is established, the HCP may share information entered, for example, based on reports from the report generating system 1860, back with the remote application server 155 as needed. For example, requests for therapy modifications or additional monitoring capabilities may be made by the HCP through the EMR system 1865. This may be particularly advantageous when the HCP feels uncomfortable using the native applications provided by the analyte monitoring system 1800 or the HCP's own EMR system 1865 is preferred for other advantage reasons. Additional information from the HCP may be shared with the patient through the HCP's own access to the remote application server 155 or other applications associated with the analyte monitoring system 1800. In addition, analyte data associated with the patient may be centralized by the remote application server 155, but may be obtained from the sensor control device 102 through various paths (e.g., through the data receiving device 120, the general purpose device 130, or the user device 140), so that the data may be shared with the EMR system 1865 regardless of its origin. Patients do not have to remember to go through additional processes to ensure that up-to-date data is provided to the HCP to help monitor their health.

[0259] In some examples, integration between the remote application server 155 and the EMR system 1865 may be limited based on system environment or user preferences. For example, when authorizing access, the patient may specify that only certain types of specimen data or specimen data over a specified period of time will be shared with the EMR system 1865. Requests to access data stored by the remote application server 155 that is greater than the authorized permissions may be denied by the remote application server 155 on behalf of the patient or may be converted into additional access requests on behalf of the HCP.

[0260] Some examples can facilitate data sharing between a patient and the EMR system 1865 even if the patient does not have an account on the remote application server 155. For example, when a patient requests a "report share," the remote application server 155 can generate a limited-use account associated with an application instance of an application associated with the remote application server 155. Once the authorization process is complete, the remote application server 155 can share data related to the limited-use account. The patient can be given the option to generate a full account to maintain the connection or association with the EMR system 1865. The patient can delete the account, in which case the data sharing is a one-time action.

[0261] It should be noted that while the remote application server 155 and the report generation system 1860 have been described as separate entities, this description is merely intended to provide a clearer description of the functionality of the various components. In some instances, the remote application server 155 and the report generation system 1860 may be functions of the same overall system.

[0262] In some examples, the connection or association between the remote application server 155 and the EMR system 1865 may be facilitated using a matrix barcode instead of requiring entry of an access code at the user device 140. In this example, the user device 140 displays the matrix barcode upon receiving confirmation from the EMR system 1865 that the HCP does not already have access to the requested patient data. The matrix barcode may be configured to transmit a web request that allows a particular user or system (e.g., the HCP and the EMR system 1865) access to the patient specimen data stored by the remote application server.

[0263] The patient can scan the matrix barcode displayed on the user device 140 using the camera of his / her multi-purpose device 130. The matrix barcode can include instructions for enabling authorization for the EMR system 1865 to accept the patient's analyte data access through the remote application server 155. Once the matrix barcode is scanned, the multi-purpose device 130 can extract details regarding the authorization request encoded in the matrix barcode and use this information to begin the authorization process as described herein. In some examples, the matrix barcode scanning functionality can be bundled into an application associated with the analyte monitor system 1800 and running on the multi-purpose device 130 (e.g., enabling the multi-purpose device 130 to communicate with the sensor control device 102). Scanning the matrix barcode can cause a prompt to be displayed in the application with information regarding the type of access to be granted, who and which system is requesting access, and the ability to control the access. Upon the patient's affirmative response, access is granted to the EMR system 1865, and this authorization can be communicated by the remote application server 155.

[0264] As discussed herein, once the patient has confirmed their request to generate an access code, for example by initiating a "report sharing" function of an application running on the multi-purpose device 130, the interface 2800 may simply confirm that recent sample data has been provided to the report generation system 1860 and provide the access code.

[0265] As discussed herein, the data receiving device 120 is a low-cost mechanism for a patient to interact with the analyte monitor system 1800. The data receiving device 120 can communicate with the sensor control device 120, but cannot communicate directly with the remote application server 150. Instead, the data receiving device 120 is connected to the user device 140 by a wired connection, and the analyte data is uploaded by the user device 140 to the remote application server. For many patients, the data receiving device is the primary way they monitor their analyte levels on a day-to-day basis.

[0266] In some examples, the data receiving device 120 may also be used to grant access to allow the EMR system 1865 to access specimen data stored by the data receiving device 120 or continuously uploaded to the remote application server 150. For example, at least the procedure described above with respect to FIG. 26 may be modified to use the data receiving device.

[0267] As an example, when an HCP uses the user device 140 to access a patient's specimen data (e.g., at 2600), the EMR system 1865 may display an application interface on the user device 140 that provides instructions for enabling access. The application interface may include a user input field for entering an access code (e.g., in interface 2700 of FIG. 27). The instructions may instruct the HCP to ask the patient to activate a "report share" function with his or her data receiving device 120. This report share function may be similar to the report share function with the data receiving device 120 discussed above (e.g., with respect to FIGS. 22-23). ​​This report share function generates a matrix barcode on the data receiving device 120 that is encoded with a URL and the specimen data code as a parameter thereto. The instructions may further instruct the HCP or patient to scan the matrix barcode with an appropriate application (e.g., a camera application running on a smartphone or other general purpose device 130). The matrix barcode may further encode access credentials and other user identification information to facilitate a persistent connection or association between the EMR system 1855 and the remote application server 155 .

[0268] Upon scanning the matrix barcode, the specimen data code is provided to the report generation system 1860, which generates an access code and an access URL. The report generation system 1860 provides the access code and access URL to the device that scanned the matrix barcode (e.g., as shown in FIG. 25). The HCP can enter the access code into a user input field shown in an application associated with the EMR system 1865. The EMR system 1865 then relays the access code to the report generation system 1860 (e.g., as in 2607). Upon validating the access code, the remote application server 155 can allow access to some or all of the specimen data provided by the multi-purpose device 130 to the report generation system 1860. This access can be limited to one-time access or continuous access depending on the system settings or the patient's user preferences. As the patient uploads additional specimen data, the data can also be shared with the EMR system 1865 as described herein without the need to validate access at each run.

[0269] FIG. 29 illustrates an exemplary user interface for granting access in accordance with embodiments herein. In particular, FIG. 29 illustrates an exemplary user interface 2900 that may be used by an application executing on a user device of an HCP associated with the EMR system 1865 to request patient specimen data access. The interface 2900 includes a user input field 2905 for the HCP to enter an access code provided by the patient. The interface 2900 further includes instructions for the HCP to follow to generate an access code when the patient uses the data receiving device 120. The instructions, as outlined above, require the HCP to scan a matrix barcode generated by the data receiving device 120 with another device, such as a smartphone, and enter the access code that will be displayed in the user input field 2905.

[0270] This procedure can be further modified to minimize the amount of manual user input required to grant authorization. In this example, after the HCP or patient scans the matrix barcode, the URL triggers access to a web application that will be displayed on the device that scanned the matrix barcode. The web application includes camera functionality and provides instructions for the user to scan the authorization matrix barcode. The authorization matrix barcode is shown in the instructions that are associated with the EMR system 1865 and that are presented to the application running on the user device after the HCP requests access. The authorization matrix barcode contains information needed for the web application running on the other device to send specimen data, reports, or data access credentials to the report generation system 1860 or remote application server 155 to facilitate access.

[0271] FIG. 30 illustrates an exemplary user interface for granting access in accordance with embodiments herein. In particular, FIG. 30 illustrates an exemplary user interface 3000 that may be used with an application running on a user device of an HCP associated with an EMR system 1865 to request patient specimen data access. The user interface 3000 includes instructions for the HCP to follow to request generating an access code. For example, the instructions may enable the EMR system 1865 to receive data when the patient uses the data receiving device 120. The instructions may require the HCP to scan a matrix barcode generated by the data receiving device 120 with another device, such as a smartphone, and scan a second matrix barcode 3005 shown in the user interface 3000, as outlined above. In some examples, the instructions may be modified to require the HCP to first scan the matrix barcode 3005 shown in the user interface 3000 to begin the process. In a non-illustrated example, the instructions in the user interface 3000 may additionally or alternatively require the patient to scan a matrix barcode displayed in the user interface 3000 using a camera or scanning feature of an application running on their multi-purpose device 130. In some examples, the application is associated with the analyte monitor system 100. In some examples, the application is a camera application or a scanning application. The matrix barcode may include, for example, a URL, deep link, or other instructions to cause the multi-purpose device 130 to send a request to establish or authorize a connection or association between the patient's analyte data stored by the analyte monitor system 100 and the patient data stored by the EMR system 1865.

[0272] The HCP can access data retrieved from and based on the sensor controlling device 102 in a web-based or server-based application. For example, the patient can communicate data from the sensor controlling device 102 to the data receiving device 120 or the general purpose device 130. The data can then be relayed to the remote application server 155 for processing. In addition to providing standard types of reports based on the analyte data, the applications running on or made available by the remote application server 155 can provide guided interpretation of the data. For example, if the analyte of interest includes or is derived from a glucose level, the application running on the remote application server 155 can provide an interpretation of a metric such as an ambulatory glucose profile (AGP) by identifying glucose patterns or areas requiring attention. The guided interpretation can include details such as therapy and lifestyle advice.

[0273] Therapy and lifestyle guidance may include an evaluation of the effect of current therapy on patient health goals, such as glycemic control. However, this guidance requires knowledge of the patient's current therapy, which may not always be immediately available to the remote application server 155. For example, the remote application server 155 may be operated by a provider of the analyte monitor system 100, whereas information regarding the patient's current therapy may be stored by a third party (e.g., an HCP system). In order to provide more effective therapy and lifestyle guidance to HCPs and patients, as well as to provide a comprehensive view of the patient's health and healthcare, it may be advantageous to enable integration of information such as the patient's current therapy within tools provided by the remote application server 155.

[0274] The HCP can enter therapy information directly into an application running on the remote application server 155. For example, the HCP can be asked to enter information such as drug name, dose, frequency, and schedule. Taking glucose management again as an example, if the therapy includes insulin, the HCP can be asked to enter context-specific information regarding the insulin regimen, which can include dose, schedule, insulin-to-carb ratio, correction factor, and target glucose. If the patient is on insulin pump therapy, the HCP can enter the basal rate and schedule.

[0275] In another example, the HCP can enter therapy information into an electronic medical record (EMR) system 1865. The therapy information can be retrieved from the EMR system 1865 and imported into the remote application server 155, or can otherwise be accessed on-demand by the remote application server 155. In particular, aspects of the remote application server 155 can be integrated with the EMR system 1865.

[0276] In some examples, the therapy information stored by the EMR system 1865 may be stored in a well-structured format ("first structured format"). As an example, the therapy information may be stored in a database or table with labeled headers and consistent use and input enforcement rules. The remote application server 155 database may also store the data in another well-structured format (e.g., "second structured format"). In such examples, the therapy information may be extracted by the EMR system 1865 after a mapping between fields of the EMR system 1865 database and fields of the remote application server 155 database, e.g., a mapping between the first structured format and the second structured format.

[0277] In some examples, the therapy information stored by the EMR system 1865 may be included in the form of unstructured data or free text notes. Because no direct mapping is available, additional processing of the therapy information may be required to identify the relevant information and determine how to use the therapy information in the context of the remote application server 155. As an example, the free text may be interpreted using keyword association, natural language processing, or pattern matching for addition to the remote application server 155. The extracted information may be mapped to a structured format used by the database of the remote application server 155.

[0278] To encourage the use of a well-structured format, the remote application server 155 can provide a structured data entry interface. As an example, the remote application server 155 can provide an insulin regimen table with doses, schedules, insulin to carbohydrate ratios, correction factors, and target glucose or a table for entering insulin pump therapy parameters. Similar interface options can be provided for other analytes of interest. Once data is entered into the remote application server 155, the remote application server 155 can use its integration with the EMR system 1865 to convert the data into a structured format usable by the EMR system 1865. For example, a reverse mapping to the EMR system 1865 can be determined. Alternatively, the structured data from the remote application server 155 can be converted into a format that can be added to a free text field shown in the EMR system 1865. This would encourage storing the data in a structured format even within the free text field of the EMR system 1865, so that the data can be easily extracted during subsequent imports.

[0279] The connection or association and report generation techniques described herein contemplate traditional request-based systems for electronic medical reports. However, it is contemplated that these techniques are also applicable to application-based EMR systems, which may be developed, for example, using the Smart on FHIR framework. Additionally or alternatively, these procedures may work with relays that bridge the EMR system to external data providers.

[0280] FIG. 31 illustrates an exemplary data flow for a specimen monitor system according to certain embodiments. In the illustrated data flow 3100, the remote application server 155 includes two additional components: an account access code service (AACS) 3110 and an account management service (AMS) 3120. The EMR system 1865 has multiple patient accounts corresponding to multiple users. The remote application server 155 also has accounts corresponding to each of the existing patient accounts stored by the EMR system 1865. The remote application server 155 manages patient specimen data and generates reports using these data. In the example illustrated in FIGS. 31 and 32, the remote application server 155 and the EMR system 1865 store a common unique identifier for each patient. One exemplary common unique identifier is a patient identification code (PIC) stored by both the remote application server 155 and the EMR system 1865 for a given patient. It should be noted that a unique identifier such as a PIC may be generated by either system in nature and may take a variety of forms. For example, the PIC may be the patient's medical record number in the EMR system 1865. As another example, the PIC may be a Globally Unique Identification Code (GUID) generated by either system during the process of establishing a connection or association.

[0281] When a request for a specimen report is placed into the EMR system (e.g., by a healthcare professional), a request 3101 is sent electronically to the remote application server 155. The request 3101 includes this unique identifier for the patient. Upon receiving the request, the remote application server 155 uses the account management service 3120 to determine the patient account for the received unique identifier. In 3104, the remote application server 155 returns one or more reports based on the specimen data it stores associated with the patient's account through the account management service 3120 to the EMR system 1865. The EMR system 1865 also associates the one or more reports with the patient account within the EMR system 1865.

[0282] FIG. 32 illustrates a procedure for requesting and generating a report according to certain embodiments. Procedure 3200 illustrated in FIG. 32 corresponds to data flow 3100 illustrated in FIG. 31. In 3201, EMR system 1865 submits a request for a analyte report. EMR system 1865 may be in communication with or be part of analyte monitoring system 100, e.g., a glucose monitoring system. EMR system 1865 may be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of procedure 3200, e.g., including operations 3201, 3205, and 3207.

[0283] At 3202, the AMS 3120 attempts to match the patient identification code (PIC) with an existing patient account stored by the EMR system 1865. The AMS 3120 can be part of the analyte monitor system 100, e.g., a glucose monitor system. The AMS 3120 can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3200, e.g., including operations 3202, 3203, 3204, and 3206. At 3203, the AMS 3120 determines whether a match can be identified. In this case, a match between the PIC indicates a connection or association between a patient account in the EMR system 1865 and a patient account in the remote application server 155. In 3203, if the AMS 3120 finds a match, the procedure proceeds to 3204.

[0284] In 3204, the AMS 3120 (or other components of the remote application server 155) generates a report based on the specimen data associated with the patient identified using the PIC. Further, in 3204, the AMS 3120 sends the generated report to the EMR system 1865. In 3205, the EMR system 1865 displays and / or stores the generated report. In some examples, the AMS 3120 sends and / or the EMR system 1865 displays a confirmation of the association or connection of the specimen data for the patient with the data for the patient stored by the EMR system 1865. In 3203, if the AMS 3120 is unable to find a match, the process proceeds to 3206. In 3206, the AMS 3120 responds to the EMR system 1865 with a message indicating that the AMS system 3120 was unable to connect the received PIC to an existing patient account. In 3207, the EMR system 1865 displays a connection or association failure message and instructions for establishing the connection or association.

[0285] FIG. 33 illustrates an example data flow for a specimen monitor system according to certain embodiments. In particular, the example data flow 3300 is for a procedure for establishing a connection or association using patient identification information and other information fields commonly stored by the remote application server 155 and the EMR system 1865. In particular, ideal patient identification information is information obtained from both systems. Such patient identification information may include, but is not limited to, last name, first name, date of birth, email address, phone number, and insurance card, etc., as examples. The EMR system 1865 issues a request 3301 as a request to establish a connection or association. The request 3301 includes patient identification information. The remote application server 155 receives the request including the patient identification information. The AMS 3120 (or other components of the remote application server 155) attempts to identify the received patient identification information in the request and match them with corresponding fields in the server's database. If the AMS 3120 finds a match, it returns a response 3304. The response 3304 may include a patient identification code (PIC). The EMR system 1865 stores this PIC to establish the connection or association. In some examples, the EMR system 1865 may generate the PIC for its own patient record. The EMR system 1865 may provide the PIC in its request 3301. Upon finding a match with the patient information contained in the request 3301, the remote application server 1865 may store the PIC and establish the connection or association. Subsequent report requests issued by the EMR system 1865 may include this PIC as described herein (whether generated by the EMR system 1865 or the remote application server 155). In some examples, confirmation of the association or connection between the specimen data related to the patient and the data related to the patient stored by the EMR system 1865 is sent by the AMS 3120 and / or displayed by the EMR system 1865.

[0286] One advantage of this procedure for establishing a connection or association is that it does not require an affirmative action from the patient. However, in some instances, these fields for the patient are not recorded identically in both the EMR system 1865 and the remote application server 155. For example, one system may have a different spelling for the patient's name, additional or different names (e.g., including a middle name or middle initial, the patient's maiden name), and old or invalid emails or phone numbers. In such scenarios, the connection or association will fail. If the AMS 3120 is unable to match the information received with the request 3301 with information stored in its own database, the response 3304 from the AMS 3120 will include a connection or association failure message. The connection or association failure message may include instructions regarding alternative methods for establishing the connection or association as described herein.

[0287] FIG. 34 illustrates a procedure 3400 for requesting and generating a report according to certain embodiments. The procedure 3400 illustrated in FIG. 34 corresponds to the data flow 3300 illustrated in FIG. 33. In 3401, the EMR system 1865 submits a analyte report request to the remote application server 155. The EMR system 1865 may be in communication with or be part of the analyte monitoring system 100, e.g., a glucose monitoring system. The EMR system 1865 may be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3400, e.g., including operations 3401, 3405, and 3407. As described herein, the request includes patient information from one or more patient information fields of the EMR system 1865 instead of the PIC.

[0288] In 3402, the AMS 3120 attempts to match the received patient information with information stored by the remote application server 155. The AMS 3120 can be part of the analyte monitor system 100, such as a glucose monitor system. The AMS 3120 can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3400, including operations 3402, 3403, 3404, and 3406.

[0289] In 3403, the AMS 3120 determines whether it can identify a match to the information provided by the EMR system 1865. In this case, a match indicates that a patient account in the specimen monitoring system has already been established and is therefore appropriate to link the above-mentioned information to the patient account represented by the EMR system 1865. If the AMS 3120 finds a match in 3403, the process proceeds to 3404. In 3404, the AMS 3120 (or other components of the remote application server 155) generates a PIC and generates a report based on the specimen data associated with the patient identified based on the provided information. In 3404, the AMS 3120 sends the PIC and the generated report to the EMR system 1865. In 3405, the EMR system 1865 stores the PIC associated with the patient account in the EMR system 1865 and displays and / or stores the generated report. If the AMS 3120 is unable to find a match at 3403, the procedure proceeds to 3406. At 3406, the AMS 3120 responds to the EMR system 1865 with a message indicating that the AMS system 3120 was unable to identify an existing patient account using the provided information. At 3407, the EMR system 1865 displays a connection failure message and instructions for establishing a connection.

[0290] Once a connection or association is established between patient data associated with a particular patient stored by the EMR system 1865 and the patient data stored by the AMS 3120 (or other components of the remote application server 155 of the analyte monitoring system 100), data can be exchanged between the EMR system 1865 and the AMS 3120 to keep the patient data stored by each system up to date. For example, when the AMS 3120 or other components of the remote application server 155 of the analyte monitoring system 100 determine that new or updated analyte data, or data derived therefrom, is available for a patient record associated with the patient, the AMS 3120 can send the new or updated data to the EMR system 1865 for display and / or storage in relation to the patient record. Similarly, when the EMR system 1865 determines that new or updated patient record data, including diagnosis, prognosis, treatment, drug regimens, and other therapy plans, is available for a patient record associated with the patient, the EMR system 1865 can send the new or updated data to the AMS 3120 for storage in relation to the patient record and / or analysis. The latest data may be provided, for example, upon a determination that new data is available or upon analysis during a regularly scheduled batch update. Similarly, patient data records between the AMS 3120 and the EMR system 1865 may be synchronized (i.e., latest data may be exchanged between the AMS 3120 and the EMR system 1865) on a regular or recurring basis. In some examples, the AMS 3120 may be configured to request the latest data from the EMR system 1865, or the EMR system 1865 may be configured to request the latest data from the AMS 3120. For example, as described herein, the remote application server 155 may include or communicate with a report generation server such that the analyte monitor system 100 has the capability to generate reports based on the patient's data. When the AMS 3120 receives a request for such a report, it may first request the latest patient data from the EMR system 1865.The EMR system 1865 may store, for example, therapy data about a patient or a patient's prescribed drug regimen that may be material for report generation. The EMR system 1865 may respond to the request with the latest drug regimen (or other relevant data). In response to a request for new or updated patient data, if the responding system (e.g., if the AMS 3120 sends the request, the EMR system 1865 is considered to be the responding system, and vice versa) determines that no new patient data is available, the responding system may respond with a message indicating that no new data is available for the particular patient.

[0291] FIG. 35 illustrates an example data flow for an analyte monitor system. The data flow 3500 corresponds to a procedure for establishing a connection or association between patient data stored in the remote application server 155 and patient data stored in the EMR system 1865, according to some examples, and optionally requesting a analyte report based on these data. The particular procedure illustrated in FIG. 35 includes an affirmative action by the patient confirming authorization for the EMR system 1865 to access data associated with the patient in the remote application server 155. As illustrated, this procedure involves a multi-purpose device 130 owned or used by the patient. As described herein, the multi-purpose device 130 may be embodied as a smartphone running an application associated with the patient's account in the remote application server 155. In some examples, the application may further interact with the patient's analyte sensor and send analyte data detected by the analyte sensor to the patient's account in the remote application server 155. That is, the multi-purpose device 130 may be an intermediary through which the patient sends analyte data to the remote application server 155. In other examples, this application may be separate from the application that interacts with the patient's analyte sensors, in other words, it is a dedicated application for authenticating access requests and connection or association requests between the EMR system 1865 and the remote application server 155.

[0292] As shown, the remote application server 155 includes an account access code server (AACS) 3110. The AACS 3110, along with the AMS 3120, is one of many services running within or accessible by the remote application server 155. The actual software architecture of the remote application server 155 may include many additional services or many instances of the same service running in parallel with the AACS 3110 and AMS 3120 shown. The AACS 3110 is configured to generate unique access codes upon request from a user (through the general purpose device 130), from the EMR system 1865, or from other services and components of the remote application server 155. When the AACS 3110 receives an access code from these, it may be configured to verify its validity as described herein.

[0293] In some examples, the access code can be a globally unique identifier (GUID) or a code that is unique at least within the context of the remote application server 155. In some examples, the access code can include a relatively long string of characters to facilitate its uniqueness. In some examples, the access code has validity only for a limited amount of time, such as, for example, 60 minutes, 30 minutes, 20 minutes, 10 minutes, 5 minutes. Because the access code is only valid for a limited period of time, the length and complexity of the code can be reduced (e.g., during a specified period of time) while still maintaining the uniqueness of the code. As an example, by having only a short validity period, the access code can be shortened to a code that is easily stored and typed by the patient. In some examples, the access code can be shortened to a six-digit numeric code or a four-digit alphanumeric code, among other possible lengths and structures. Short access codes are permissible because only a small number of patient accounts are expected to seek connection during the allotted period, and the code can be reused after the validity period has expired.

[0294] The data flow 3500 begins with the multi-purpose device 130 configured to display a user interface element (e.g., a button or menu item) that facilitates the connection or association process. Upon accepting the selection of the user interface element, the multi-purpose device 130 sends a request 3502 for an access code to the AACS 3110. The AACS 3110 receives the request 3502 and generates an access code and associates it with the patient account associated with the multi-purpose device 130. As an example, the remote application server 155 can uniquely associate the multi-purpose device 130 with a particular patient account or set of patient records. Additionally or alternatively, the remote application server 155 can associate a login account to an application running on the multi-purpose device 130 with a patient account or database record, or associate a particular unique identifier with both the multi-purpose device 130 and a certain patient record in the remote application server 155. In other examples, other associations are possible.

[0295] The AACS sends a response 3504 including the access code to the multi-purpose device 130. The multi-purpose device 130 displays the access code. The access code is then entered into a request field on the EMR system 1865, such as a comment field of the request or a dedicated field in the user interface of the EMR system 1865. The EMR system 1865 can receive the access code as a result of the patient showing or sending the displayed access code to the HCP. The EMR system 1865 sends a request 3507 including the access code to the remote application server 155. As an example, the request 3507 can be a request for a specimen report (in which case the initial request request will also be used to establish the computer operating system). As another example, the request 3507 can be a request for connection or association only (e.g., does not include a request for a specimen report that can be requested separately later). The AMS 3120 receives the request 3507 on behalf of the remote application server 155 and sends the access code received in the request 3507 as a validation request 3508 to the AACS 3110 .

[0296] The AACS 3110 determines whether the access code is valid. For example, the AACS 3110 can determine whether the access code matches one previously generated, whether the access code is still within the validity period, and whether the access code is associated with the patient account record to which access is requested in the request 3507. If the access code is valid, the AACS 3110 sends a response 3509 to the AMS 3120 with authorization to access the patient account record and the account identification information. The AMS 3120 sends a response 3511 with the PIC to the EMR system 1865. As described herein, the PIC will be maintained as a shared identifier for a given patient's record in both the remote application server 155 and the EMR system 1865. The EMR system 1865 stores this PIC and associates it with the patient's EMR account. In some examples, the EMR system 1865 generates the PIC and includes it in the request 3507. The remote application server 155 can store the PIC with the patient's account in the AMS 3120. If the request 3507 includes a specimen report request, the AMS 3120 can respond with one or more reports generated from the specimen data associated with the patient, as described herein. If the AACS 3110 determines that the access code included in the request 3507 (and associated by the AMS 3120 to the AACS 3110) is invalid, the AACS 3110 response 3509 to the AMS 3120 is denied for access. The AMS 3120 response 3511 to the EMR system 1865 includes a connection or association failure message, as described herein.

[0297] FIG. 36 illustrates a procedure for requesting and generating a report according to certain embodiments. Procedure 3600 illustrated in FIG. 36 corresponds to data flow 3500 illustrated in FIG. 35. In 3601, the multi-purpose device 130 receives a request to establish a connection or association between a patient record in the EMR system 1865 and a patient record in the remote application server 155. The multi-purpose device 130 can be part of an analyte monitor system 1800, such as a glucose monitor system. The multi-purpose device 130 can include a display, one or more processors, a camera (or other hardware for scanning a matrix barcode), and a memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of procedure 3600, including operations 3601, 3602, and 3605. In 3602, the multi-purpose device 130 generates and sends a request for an access code for an associated account. As another example, the general-purpose device 130 generates a request for an access code to an account associated with a particular application instance running on it or associated with a login account to that application instance. The request is sent to the AACS 3110.

[0298] At 3603, the AACS 3110 generates an access code associated with the appropriate account. The AACS 3110 can be part of the analyte monitor system 100, e.g., a glucose monitor system. The AACS 3110 can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3600, e.g., including operations 3603, 3604, and 3609. At 3604, the AACS 3110 transmits the access code back to the general-purpose device 130. Examples of displaying the access code and URL are shown and described in FIG. 20 and FIG. 25 in conjunction with an example where the user scans a matrix barcode displayed by the data receiving device 120. At 3605, the general-purpose device 130 displays the received access code. The patient can then show the access code to the HCP who activates the EMR system 1865 .

[0299] At 3606, the EMR system 1865 accepts the access code. The EMR system 1865 can be in communication with or be part of the analyte monitor system 100, e.g., a glucose monitor system. The EMR system 1865 can be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory can include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3600, e.g., including operations 3606, 3607, 3612, and 3614. For example, the HCP can enter the access code into the EMR system 1865. At 3607, the EMR system 1865 generates a request for a specimen report corresponding to the patient's specimen data stored by the remote application server 155. At 3608 and 3609 , the AMS 3120 and 3110 (respectively) cooperate to verify the access code received from the EMR system 1865 with the access code generated by the AACS 3110 .

[0300] At 3610, the AMS 3120 evaluates the validity of the results of 3608. The AMS 3120 may be part of the analyte monitor system 100, e.g., a glucose monitor system. The AMS 3120 may be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of the procedure 3600, e.g., including operations 3608, 3610, 3611, and 3613. At 3610, if the AMS 3120 finds a valid result, the procedure proceeds to 3611. At 3611, the AMS 3120 (or other components of the remote application server 155) generates a report based on the analyte data associated with the patient identified using the PIC. In 3611, the AMS 3120 sends the generated report to the EMR system 1865. In some examples, the AMS 3120 sends and / or the EMR system 1865 displays a confirmation of the association or connection between the specimen data for the patient and the data for the patient stored by the EMR system 1865. In 3612, the EMR system 1865 displays and / or stores the generated report. In 3610, if the AMS 3120 finds an invalid result, the procedure proceeds to 3613. In 3613, the AMS 3120 responds to the EMR system 1865 with a message indicating that the AMS system 3120 was unable to connect the receiving PIC to an existing patient account. In 3614, the EMR system 1865 displays a connection or association failure message and instructions to establish the connection or association.

[0301] FIG. 37 illustrates an example data flow for a specimen monitor system. The data flow 3700 corresponds to a procedure for establishing a connection or association between patient data stored in the remote application server 155 and patient data stored in the EMR system 1865, and optionally requesting a specimen report based on these data, according to some examples. In the illustrated data flow 3700, a connection or association request is sent from a request request 3701 sent by the EMR system 1865. In some examples, the request request 3701 can include patient identification information such as the patient name, date of birth, and contact information such as an email address. The AMS 3120 attempts to find a match based on the patient information in its account database. If the AMS 3120 fails to find a match, it sends a message to the contact information (e.g., email address) provided by the EMR system 1865. In some examples, the AMS 3120 does not perform a match if a connection or association is not established and sends a message to the contact information provided by the EMR system 1865. For a patient using the multipurpose device 130, the patient may receive a message on their multipurpose device 130. The message includes instructions for the patient to click on a link in the message that will open a particular portion of a web page or application associated with the remote application server 155 and running on the multipurpose device 130. The web page is configured to display an access code entry field along with instructions for the patient.

[0302] The patient can then send a request to the AACS 3110 using the multipurpose device 130 to generate an access code. The AACS 3110 generates the access code as described herein and sends the access code back to the multipurpose device 130 for display in a response 3703. Once the patient enters the access code into the web page, the web page sends the access code to the AMS 3120, which will include the access code in an access request 3705 to the AACS 3110 on behalf of the EMR system 1865. If the AACS determines that the access code is valid, it will respond 3706 to the AMS with access approval and account information for the patient. The AMS establishes a connection or association as described herein and optionally responds 3707 to the EMR system 1865 with a PIC, a specimen report, or a connection or association failure message in accordance with the techniques described herein.

[0303] In this example, the EMR system 1865 does not necessarily require near real-time contact between the patient and the HCP to achieve access, but still maintains the security benefits of access code-based technology. As an example, in data flow 3500, the patient grants access to the EMR system 1865 during or immediately prior to a medical visit. Because the process would require the HCP and patient to be in near real-time communication, the HCP can ensure that the patient complies with the required actions. In contrast, in data flow 3700, the patient makes an access code request to the AACS 3110 and enters the access code into a web page relatively asynchronously to the interaction with the HCP. As an example, the HCP can request access prior to the medical visit and the patient can complete the process at home, maximizing the amount of time for the HCP to interact with the patient during the visit. In some examples, the various components can interact automatically. For example, the web page for accepting the access code can automatically open an application associated with the patient account on the remote application server 155, bringing the patient account to the foreground on the screen of the application, thereby transmitting a request 3706 to generate an access code. As another example, when the access code is returned to the application, the application can provide a simple user interface for copying the access code into an input field on a web page.

[0304] 38A-B illustrate a procedure for requesting and generating a report according to certain embodiments. Procedure 3800 illustrated in FIGS. 38A-B corresponds to data flow 3100 illustrated in FIG. 37. At 3801, EMR system 1865 receives a request for a analyte report based on a patient record therein. EMR system 1865 may be in communication with or be part of analyte monitoring system 100, e.g., a glucose monitoring system. EMR system 1865 may be or include a server or server computing device including networking hardware, one or more processors, and memory communicatively coupled to the one or more processors. The memory may include instructions configured, when executed by the one or more processors, to cause the one or more processors to perform one or more operations of procedure 3800, e.g., including operations 3801, 3805, 3816, and 3818. As described herein, in some examples, the request may not be a request for a specimen report, but rather a request only to establish a connection o...

Claims

1. A server computer device for a glucose monitoring system, One or more processors, A memory communicatively coupled to the one or more processors, Includes, The memory, when executed by the one or two or more processors, The steps include receiving a request from an electronic medical record (EMR) system, which includes patient identification information, to establish a connection between a set of patient records stored by the EMR system and associated with a patient and a set of patient records stored by the glucose monitoring system and associated with the patient, The steps include comparing the patient identification information received along with the request with the patient identification information stored by the glucose monitoring system, In response to the step of determining, based on the comparison, that a set of patient records exists that is stored by the glucose monitoring system and associated with the patient, A step of establishing an association between the set of patient records stored by the EMR system and associated with the patient and the set of patient records stored by the glucose monitor system and associated with the patient, The step of sending the confirmation of the association to the EMR system, In response to the step of determining, based on the comparison, that there is no set of patient records stored by the glucose monitoring system, A step of sending a notification to the EMR system that it is not possible to complete the request to establish the connection, Instructions configured to cause one or more processors to perform operations including the above, Server computer device.

2. The server computer device according to claim 1, wherein the patient identification information includes the patient's name, date of birth, address, email address, telephone number, or patient healthcare provider information.

3. The server computer device according to claim 1, wherein the patient identification information includes a patient identification code that includes an identifier unique to the patient within the EMR system.

4. The aforementioned instruction is, The step of determining that new glucose data is available that is stored by the glucose monitoring system and associated with the set of patient records associated with the patient, The steps include sending the new glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient to the EMR system, The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 1.

5. The aforementioned instruction is, The steps include requesting patient data from the EMR system that is associated with the set of patient records stored by the EMR system and associated with the patient, The steps include receiving a message from the EMR system in place of the requested patient data indicating that new patient data associated with the set of patient records stored by the EMR system and associated with the patient is unavailable, The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 1.

6. The aforementioned instruction is, The step of receiving a request from the EMR system for new glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient, The step of determining that new glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient is unavailable, The steps include sending a message to the EMR system in place of the requested patient data indicating that new glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient is not available, The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 1.

7. The aforementioned instruction is, The steps include: generating an access code using an account access code service, associated with the set of patient records stored by the glucose monitoring system and associated with the patient; The steps include sending the access code associated with the confirmation of the association to the EMR system, The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 1.

8. The server computer device according to claim 1, wherein the instruction is further configured to cause the one or more processors to perform further operations, including sending glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient to the EMR system.

9. The server computer device according to claim 8, wherein the patient data associated with the set of patient records stored by the EMR system and associated with the patient is new patient data received from the EMR system when new patient data becomes available.

10. The server computer device according to claim 8, wherein the instruction is further configured to cause the one or more processors to perform further operations, including the step of periodically sending glucose data associated with the set of patient records stored by the glucose monitoring system and associated with the patient to the EMR system.

11. The server computer device according to claim 1, wherein the instruction is further configured to cause the one or more processors to perform further operations, including the step of periodically receiving from the EMR system patient data associated with the set of patient records stored by the EMR system and associated with the patient.

12. The request for establishing a connection further includes an access code generated by the account access code service, and the instruction precedes the step of sending the confirmation of the association. Using the account access code service, determine that the access code is associated with the set of patient records stored by the glucose monitoring system and associated with the patient; The steps include determining the validity of the access code using the aforementioned account access code service, The server computer device according to claim 1, further configured to cause the one or more processors to perform further operations, including the operation described above.

13. The server computer device according to claim 12, wherein the access code is configured to be valid for a predetermined period of time.

14. The server computer device according to claim 1, wherein the notification that it is unable to complete the request to establish the connection further includes an instruction to establish the connection.

15. The instruction follows the step of sending the confirmation of the association, The steps include: receiving a request by a server computer device and from the EMR system to access a report generated based on glucose data stored by the glucose monitoring system and associated with the patient in the set of patient records; The steps include generating the requested report using a server computer device and a report generation system, The step of sending the generated report to the EMR system via a server computer device, The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 1.

16. The server computer device according to claim 15, wherein the request for accessing the report identifies the glucose data for which the report was requested.

17. The aforementioned instruction is, A step of requesting updated patient data from the EMR system, associated with the set of patient records stored by the EMR system and associated with the patient; A step of receiving updated patient data from the EMR system, which is associated with a set of patient records stored by the EMR system and associated with the patient, wherein the requested report is generated based on the updated patient data. The system is further configured to cause the one or more processors to perform yet another operation, including The server computer device according to claim 15.

18. The server computer device according to claim 15, wherein the instruction is further configured to cause the one or more processors to perform further operations, including the step of identifying glucose data to be included in the requested report based on a datastamp or timestamp associated with the identified glucose data.

19. A data receiving device for a glucose monitoring system, The display and One or more microprocessors, Communicatively coupled to the one or more processors, and executed by the one or more processors, The steps include receiving a request from a user of the glucose monitoring system to transmit glucose data associated with the user to another computer device, The step of encoding the glucose data, A step of generating a matrix barcode including a uniform resource locator (URL) and the encoded glucose data, wherein the glucose data is formatted as a parameter to be included with the URL by a web browser, The step of displaying the matrix barcode on the display, A memory including instructions configured to cause one or more processors to perform an operation including, A data receiving device that includes this.

20. The data receiving device according to claim 19, further configured such that the instruction causes the one or more processors to perform another operation, which includes the step of selecting the glucose data to encode based on the glucose data corresponding to a predetermined time range.

21. The instruction for encoding the glucose data is: A step of calculating one or more derived values ​​from the glucose data, The steps include encoding the derived value together with the glucose data, The system is further configured to cause the one or more processors to perform yet another operation, including The data receiving device according to claim 19.

22. The step of encoding the glucose data includes a step of reducing the level of precision associated with the glucose data, The level of accuracy is selected based on the actual values ​​of the glucose data. The data receiving device according to claim 19.

23. The aforementioned instruction is, A step of generating report elements for a glucose report based on the glucose data, A step of encoding the report elements for the glucose report, wherein the matrix barcode further comprises the encoded glucose report elements, The system is further configured to cause the one or more processors to perform yet another operation, including The data receiving device according to claim 19.

24. A data receiving device according to claim 19, which is not configured for wireless communication.

25. A multipurpose device for glucose monitoring systems, Camera and, The display and One or more processors, Communicatively coupled to the one or more processors, and executed by the one or more processors, The step of scanning a matrix barcode through the aforementioned camera, The step of decoding the matrix barcode in order to obtain a uniform resource locator (URL) and one or more parameters including at least glucose data, The step of presenting a web request to the server associated with the URL using the URL and the one or more parameters, The step of receiving an access code associated with the one or more parameters mentioned above from the user via a multipurpose device, and The step of outputting the access code through the aforementioned display, A memory including instructions configured to cause one or more processors to perform an operation including, A multipurpose device including [mention specific device details].

26. The server associated with the URL is further associated with the glucose monitoring system. The access code is a temporary one-time password associated with one or more parameters by the server. The multipurpose device according to claim 25.

27. The multipurpose device according to claim 26, wherein the access code is configured to expire after a predetermined period of time.

28. The aforementioned instruction is, A step of receiving a report based on the glucose data included in the parameters from the server associated with the URL using a multipurpose device, wherein the report is generated by the server based on the parameters presented together with the URL, The step of outputting the aforementioned report through the display, The system is further configured to cause the one or more processors to perform yet another operation, including The multipurpose device according to claim 25.

29. The matrix barcode is generated and displayed by the data receiving device of the glucose monitoring system. The one or more parameters mentioned above further include a device identifier associated with the multipurpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user. The multipurpose device according to claim 28.

30. The multipurpose device according to claim 29, wherein the data receiving device is not configured for wireless communication.

31. A server computer device for a glucose monitoring system, One or more processors, Communicatively coupled to the one or more processors, and executed by the one or more processors, The step of receiving a first web request from the multipurpose device of the glucose monitoring system, which includes one or more parameters including glucose data associated with a user of the glucose monitoring system, The step of generating a report based on the received glucose data, The step of associating the access code with the aforementioned report, The step of receiving a second web request that includes one or more parameters, including the aforementioned access code, The step of retrieving the report based on the aforementioned access code, and At the stage of outputting the aforementioned report on the display, A memory including instructions configured to cause one or more processors to perform an operation including, Server computer devices including...

32. The server computer device according to claim 31, wherein the instruction is further configured to cause the one or more processors to perform further operations, including the step of sending the access code to the multipurpose device in response to the step of receiving the first web request.

33. The server computer device according to claim 31, wherein the second web request is received from a computer device associated with an electronic medical record (EMR) system.

34. The server computer device according to claim 31 receives the second web request from the multipurpose device.

35. The server computer device according to claim 31, wherein the second web request is received from a computer device associated with a user of the glucose monitoring system.

36. The server computer device according to claim 31, wherein the first web request is sent by the multipurpose device following the step of scanning a matrix barcode.

37. The server computer device according to claim 31, wherein the one or more parameters further include a device identifier associated with the multipurpose device, a device identifier associated with the data receiving device, or a patient identifier associated with the user.

38. A glucose monitoring system, One or more processors, Communicatively coupled to the one or more processors, and executed by the one or more processors, The stage of establishing a communication session between the glucose monitoring system and the electronic medical record (EMR) system. A step of identifying therapeutic information associated with the user and stored in the EMR system, A step of transmitting the therapy information associated with the user from the EMR system to the application server, The steps include: converting the aforementioned therapeutic information for use with a glucose monitoring system, The steps include storing the converted therapeutic information in a database accessible to the glucose monitoring system, and The step of displaying the aforementioned therapeutic information to the user of the glucose monitoring system, A memory including instructions configured to cause one or more processors to perform an operation including, A glucose monitoring system including a glucose monitor system.

39. The aforementioned therapeutic information is stored in a first structured format. The step of converting the therapeutic information includes the step of mapping the first structured format to a second structured format associated with the glucose monitoring system. The glucose monitoring system according to claim 38.

40. The aforementioned therapeutic information is stored in free text format. The step of converting the aforementioned therapeutic information is: The step of interpreting the aforementioned therapeutic information using natural language processing, The steps include storing the aforementioned information in a structured format associated with the glucose monitoring system, including, The glucose monitoring system according to claim 38.

41. The aforementioned instruction is, The stage of receiving additional therapeutic information through structured format input, The step of converting the additional therapeutic information for use with the EMR system, The steps include: transmitting the converted additional therapeutic information to the EMR system for storage; The system is further configured to cause the one or more processors to perform yet another operation, including The glucose monitoring system according to claim 38.

42. A glucose monitoring system, One or more processors, Communicatively coupled to the one or more processors, and executed by the one or more processors, The stage of establishing a communication session between the glucose monitoring system and the electronic medical record (EMR) system. The step of receiving a request from a user device for the EMR system to access glucose data stored in a database associated with the patient and accessible by the glucose monitoring system, A step of displaying the access code associated with the glucose data associated with the patient on a glucose monitoring system and a multipurpose device associated with the patient. The step of receiving a second access code from the user device, A step of comparing the access code displayed by the multipurpose device with the second access code, and In response to determining that the access code displayed by the multipurpose device and the second access code are equivalent, the step of granting access to the EMR system for accessing the glucose data associated with the patient, A memory including instructions configured to cause one or more processors to perform an operation including, A glucose monitoring system including a glucose monitor system.

43. The glucose monitoring system according to claim 42, wherein the access code is generated by the multipurpose device, and the glucose monitoring system receives the access code from the multipurpose device.

44. The glucose monitoring system according to claim 42, wherein the access code is generated by the glucose monitoring system, and the multipurpose device receives the access code from the glucose monitoring system.

45. The aforementioned instruction is, The step of displaying an authorization request on the multipurpose device, wherein access to the EMR system is permitted in response to an affirmative response to the authorization request. The system is further configured to cause the one or more processors to perform yet another operation, including The glucose monitoring system according to claim 42.

46. The glucose monitoring system according to claim 42, wherein one or more of the access code and the second access code include a matrix barcode.

Images