A system, device, and method for providing a database that integrates test substance monitoring data with an electronic medical record system.

Abstract

This document describes a system and method for integrating data from a test substance monitoring system with data from an electronic medical record system. The method includes identifying a patient's test substance data by associating it with an external patient identifier associated with at least one healthcare institution. The patient's test substance data identified by the external patient identifier can be transferred from a first cloud server to a second cloud server. The test substance data can be stored in a folder within the second cloud server associated with at least one healthcare institution. Furthermore, the test substance data can be combined with the patient's electronic medical record within the second cloud server. The combined data can then be transferred to a database for further detailed analysis.

Description

Technical Field

[0001] The subject matter described herein generally relates to systems, devices, and methods related to the integration of test substance monitoring data and an electronic health record system.

Background Art

[0002] For the health of an individual with diabetes, detecting and / or monitoring test substance values such as glucose, ketone, lactate, oxygen, hemoglobin A1C, etc. may be of extremely important significance. Patients with diabetes mellitus may cause complications such as unconsciousness, cardiovascular disease, retinopathy, neuropathy, nephropathy, etc. Generally, diabetic patients need to monitor their glucose levels to confirm that their glucose levels are maintained within a clinically safe range, and further use this information to determine whether insulin is needed and / or when it is needed to lower the glucose level in the body, or when glucose needs to be added to raise the glucose level in the body.

[0003] And clinical data indicating a strong correlation between the frequency of glucose monitoring and blood glucose control is also being accumulated. However, despite such a correlation, many people diagnosed with diabetes do not monitor their glucose levels at an appropriate frequency due to factors such as annoyance, a cautious attitude towards examinations, pain and costs associated with glucose tests.

[0004] To improve patient compliance with frequent glucose monitoring therapy, an in vivo test substance monitoring system can be used, which is configured to be attached to the body of an individual whose test substance needs to be monitored. To enhance the comfort and convenience of the wearer, the sensor control device is miniaturized in form factor and is configured to be attached by the individual using a sensor applicator. This attachment procedure includes inserting at least a portion of the sensor using the applicator (insertion mechanism) so that the sensor that senses the level of the test substance in bodily fluids comes into contact with bodily fluids present in a certain layer of the user's body. The sensor control device can also be configured to transmit the test substance data to another device, which the individual, or their healthcare provider (HCP), or caregiver can then use to review the test substance data and make treatment decisions.

[0005] In certain environments, such as hospital settings, other relevant information may be collected about the patient. This additional patient information may include other physiological measurements, diagnostic results, and treatment plans, but these are only a few examples. Such information is often stored in a separate electronic medical record (EMR) system, independent of the in vivo test surveillance system that collects the patient's test substance data. Correlating the information and data from these separate systems can potentially yield deeper insights not only at the individual level but also in various populations and epidemiological studies. At the same time, there is a need to appropriately protect patient privacy. [Overview of the Initiative] [Problems that the invention aims to solve]

[0006] Therefore, there is a need for improved methods and related methods and devices that enable the integration of a test substance monitoring system and an electronic medical record system, while offering superior robustness and security. [Means for solving the problem]

[0007] This invention describes exemplary embodiments demonstrating improvements to systems, methods, and devices for integrating a test substance monitoring system with an electronic medical record system. The present invention provides a method as defined in claims 1 and 16 of the appended claims and a system as defined in claim 15. According to many embodiments, a method for integrating data from a test substance monitoring system and data from an electronic medical record system includes the steps of: receiving data indicating a patient's test substance level from the test substance monitoring system using a first trusted computer system; creating a test substance dataset with external patient identifiers by associating the data indicating a patient's test substance level with external patient identifiers associated with at least one healthcare institution using the first trusted computer system; transferring the test substance dataset with external patient identifiers from the first trusted computer system to a second trusted computer system; storing the test substance dataset with external patient identifiers in a folder associated with at least one healthcare institution using the second trusted computer system; transferring the test substance dataset with external patient identifiers from the second trusted computer system to a site server associated with at least one healthcare institution; creating a medical dataset with external patient identifiers by combining the test substance dataset with external patient identifiers and the electronic medical record associated with the patient using the site server; and transferring the medical dataset with external patient identifiers to a database using the site server.

[0008] According to one aspect of several embodiments, the test substance dataset with an external patient identifier does not contain the user's personal identification information.

[0009] According to one aspect of several embodiments, at least a portion of the data relating to the user's test substance levels associated with an external patient identifier includes past glucose measurement results.

[0010] According to one aspect of several embodiments, at least a portion of the data relating to the user's test substance levels associated with an external patient identifier includes glucometrics. According to one aspect of several embodiments, the glucometrics includes at least one of the mean glucose level, the time it was within the target range, and the standard deviation.

[0011] According to one aspect of several embodiments, at least a portion of the data relating to the user's test substance levels associated with an external patient identifier includes an ambulatory glucose profile.

[0012] According to one aspect of several embodiments, an external patient identifier is assigned by at least one medical institution.

[0013] According to one aspect of several embodiments, data indicating the levels of a test substance is associated with multiple healthcare institutions. According to one aspect of several embodiments, a second trusted computer system transfers the test substance dataset with external patient identifiers to site servers associated with each of the multiple healthcare institutions.

[0014] According to one aspect of several embodiments, the method further includes the step of inviting a user to share data with at least one healthcare provider, prior to the step of associating an external patient identifier associated with at least one healthcare provider with data indicating the patient's test substance levels using a first trusted computer system.

[0015] According to one aspect of several embodiments, the method further includes the step of a site server associating a database identifier to be transferred to a database with a medical dataset containing an external patient identifier.

[0016] According to one aspect of several embodiments, the method further includes the step of storing a medical dataset with an external patient identifier in a database according to a database identifier.

[0017] According to one aspect of several embodiments, the method further includes the step of associating a patient identifier with an external patient identifier or a test substance dataset with an external patient identifier using a site server.

[0018] According to one aspect of several embodiments, at least one medical institution is at least one hospital.

[0019] According to one aspect of many embodiments, the data sharing system comprises a sensor control device, a reading device, a first trusted computer system, a second trusted computer system, and a site server. The sensor control device includes a test substance sensor, configured such that at least a portion of the test substance sensor is in fluid contact with the bodily fluids of the monitored user. The reading device is configured to wirelessly receive data indicating the patient's test substance level from the sensor control device and to transmit data indicating the test substance level. The first trusted computer system is configured to perform the steps of: receiving data indicating the test substance level; creating a test substance dataset with external patient identifiers by associating external patient identifiers associated with at least one medical institution with the data indicating the test substance level; and transferring the test substance dataset with external patient identifiers. The second trusted computer system is configured to perform the steps of: receiving the test substance dataset with external patient identifiers; storing the test substance dataset with external patient identifiers in a folder associated with at least one medical institution; and transferring the test substance dataset with external patient identifiers that was stored in the folder associated with at least one medical institution. The site server is configured to perform the following steps: receive a dataset of test substances with external patient identifiers stored in a folder associated with at least one medical institution; create a medical dataset with external patient identifiers by combining the dataset of test substances with external patient identifiers with the electronic medical record associated with the patient; and transfer the medical dataset with external patient identifiers to a database.

[0020] According to one aspect of many embodiments, a data sharing system comprises a reading device, a first trusted computer system, a second trusted computer system, and a site server. The reading device is configured to wirelessly receive data indicating a patient's test substance level from a sensor control device and to transmit data indicating the test substance level. The first trusted computer system is configured to perform the steps of: receiving data indicating the test substance level; creating a test substance dataset with external patient identifiers by associating external patient identifiers associated with at least one medical institution with the data indicating the test substance level; and transferring the test substance dataset with external patient identifiers. The second trusted computer system is configured to perform the steps of: receiving the test substance dataset with external patient identifiers; storing the test substance dataset with external patient identifiers in a folder associated with at least one medical institution; and transferring the test substance dataset with external patient identifiers that was stored in the folder associated with at least one medical institution. The site server is configured to perform the following steps: receive a dataset of test substances with external patient identifiers stored in a folder associated with at least one medical institution; create a medical dataset with external patient identifiers by combining the dataset of test substances with external patient identifiers with the electronic medical record associated with the patient; and transfer the medical dataset with external patient identifiers to a database.

[0021] According to one aspect of several embodiments, the sensor control device comprises a substance sensor, configured such that at least a portion of the substance sensor is in fluid contact with the bodily fluids of the monitored user.

[0022] According to one aspect of many embodiments, a method of registering a patient in a data sharing program includes, in a test substance monitoring program, the step of accepting a first invitation asking for participation in a medical practice, the step of sending a second invitation asking for consent to data sharing with the medical practice to the patient in the test substance monitoring program, and, in response to the patient accepting the second invitation, the step of registering the patient in the data sharing program to enable sharing of the patient's test substance data with a third-party database, wherein in the test substance monitoring program the patient is associated with an external patient identifier.

[0023] According to one aspect of some embodiments, the patient is registered by entering and verifying an external patient identifier associated with the patient.

[0024] According to one aspect of some embodiments, the second invitation is presented to the patient in a modal display within the test substance monitoring program.

[0025] According to one aspect of some embodiments, the second invitation is presented to the patient in an email sent from the test substance monitoring program.

[0026] Many of the embodiments provided herein are GUI functions for obtaining consent or addressing security issues, and these GUI functions are configured to be very intuitive and user-friendly, enabling sharing and quick access to the user's physiological information. More specifically, with these embodiments, the user can easily move between various user interfaces and within each user interface, and the user and administrator can quickly access medical data such as test substance levels, glucometrics, electronic medical records, etc., and manage invitations.

[0027] By improving the above features and the GUI shown in various aspects described in the detailed description and claims of this specification, at least the technical effect of assisting the user of this device to operate the device more accurately, efficiently, and safely can be obtained. It will be understood that the information provided to the user via the GUI, the presentation order of the information, and the clarity of the information configuration can have a significant impact on how the user interacts with the system and on system operation. Therefore, the report GUI guides the user so that the user can accurately and efficiently obtain the necessary permissions and information through the technical operation of operating the system. Note that other improvements and advantages may also be provided. The various configurations of these devices will be described in more detail using embodiments (however, the embodiments are merely examples).

[0028] Regarding other systems, devices, methods, features, and advantages related to the subject matter described in this specification, they will be obvious to those skilled in the art or will become obvious by examining the following drawings and detailed description. Note that all such additional systems, devices, methods, features, and advantages are also included in this specification, are within the scope of the subject matter described in this specification, and are intended to be the subject of protection of the appended claims. Each aspect of this embodiment is described in an independent claim, and the preferred features are described in the dependent claims. The preferred features described in the dependent claims can be provided in one embodiment in combination, and further, the preferred features of one aspect can be provided in combination with other aspects. The features of the exemplary embodiments should not be construed as limiting the scope of the claims, except as explicitly recited in the appended claims.

Brief Description of the Drawings

[0029] By examining the attached drawings, the details of the subject matter described herein, both in terms of its structure and operation, will become clear. Similar elements in the attached drawings are given the same reference numerals. Furthermore, the components of the drawings are not necessarily shown to scale, and the focus is on illustrating the principles of the subject matter. In addition, all drawings are intended to convey concepts, and detailed attributes such as relative size and shape are shown schematically rather than faithfully and accurately. [Figure 1] System overview diagram of a substance monitoring system comprising a sensor applicator, a sensor control device, a reading device, a network, a trusted computer system, and a local computer system. [Figure 2A] Block diagram showing an exemplary embodiment of the reading device. [Figure 2B] Block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 2C] Block diagram illustrating an exemplary embodiment of a sensor control device. [Figure 3A] This diagram shows an overview of an exemplary system that includes functions for managing surveillance data of tested substances and managing electronic medical records. [Figure 3B] This diagram shows an overview of an exemplary system that includes functions for managing surveillance data of tested substances and managing electronic medical records. [Figure 3C] A diagram illustrating an exemplary method for sharing test substance data and medical records. [Figure 4A] A diagram illustrating an exemplary method for linking accounts between a test substance monitoring program and a database. [Figure 4B] A diagram illustrating an exemplary method for linking accounts between a test substance monitoring program and a database. [Figure 5A] This figure shows exemplary embodiments of various graphical user interfaces (GUIs) and report display GUIs related to the process of linking patient test substance monitoring accounts with a database. [Figure 5B]This figure shows exemplary embodiments of various GUIs and report display GUIs related to the process of linking a patient's test substance monitoring account with a database. [Figure 5C] This figure shows exemplary embodiments of various GUIs and report display GUIs related to the process of linking a patient's test substance monitoring account with a database. [Figure 5D] This figure shows exemplary embodiments of various GUIs and report display GUIs related to the process of linking a patient's test substance monitoring account with a database. [Figure 5E] This figure shows exemplary embodiments of various GUIs and report display GUIs related to the process of linking a patient's test substance monitoring account with a database. [Figure 6A] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 6B] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 6C] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 6D] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 6E] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 6F] This figure illustrates exemplary embodiments of various GUIs in a mobile application related to the process of linking a patient's test substance monitoring account with a database. [Figure 7] A diagram illustrating an exemplary method for applying a two-factor authentication scheme to a substance monitoring system. [Figure 8A]This figure shows exemplary embodiments of various graphical user interfaces related to two-factor authentication schemes used in a substance monitoring system. [Figure 8B] This figure shows exemplary embodiments of various graphical user interfaces related to two-factor authentication schemes used in a substance monitoring system. [Figure 9] This figure shows an exemplary embodiment of an account setting GUI related to a two-factor authentication scheme used in a substance monitoring system. [Modes for carrying out the invention]

[0030] Before describing the subject matter of this disclosure in detail, it should be understood that this disclosure is not limited to the specific embodiments described herein and is naturally subject to various modifications. Furthermore, since the scope of this disclosure is limited only by the appended claims, it should be understood that the terms used herein are merely for describing specific embodiments and are not intended to be limiting.

[0031] In this specification and the appended claims, the singular forms "a," "an," and "the" shall also include references to the corresponding plural forms unless the context clearly indicates that the plural form is not included.

[0032] The publications mentioned herein are listed solely on the basis that their disclosure precedes the filing date of this application. Nothing in this specification should be construed as acknowledging that this disclosure is not entitled to prior rights to such publications on the grounds that such publications have been disclosed prior to this application. Furthermore, the publication dates mentioned herein may differ from the actual publication dates, and such publication dates may need to be verified on a case-by-case basis.

[0033] Embodiments of this disclosure generally include GUIs, software, and digital interfaces for a test substance monitoring system, as well as related methods and devices. Therefore, many embodiments include in vivo test substance sensors. These in vivo test substance sensors are structurally configured to acquire information about at least one test substance in a user's body by placing (or being able to place) at least a portion of the sensor within the user's body. However, it should be noted that embodiments disclosed herein can also be used for in vivo test substance monitoring systems incorporating in vitro functionality, or for fully in vitro or fully ex vivo test substance monitoring systems (e.g., fully non-invasive systems).

[0034] Furthermore, with respect to all embodiments of each method disclosed herein, the systems and devices capable of executing each embodiment are also included within the scope of this disclosure. For example, embodiments of sensor control devices, reading devices, local computer systems, and trusted computer systems are disclosed herein, which may comprise one or more sensors, a substance monitoring circuit (e.g., an analog circuit), memory (e.g., memory for storing instructions), a power supply, a communication circuit, a transmitter, a receiver, a processor and / or controller (e.g., a processor and / or controller for executing instructions), and these components may be configured to execute any and all method steps, or to assist in the execution of any and all method steps.

[0035] This specification provides an improved graphical user interface for reporting a test substance monitoring system. For example, this specification discloses various embodiments of the graphical user interface (GUI). The GUIs of this disclosure are highly intuitive and user-friendly, enabling quick access to the user's physiological information. In short, these embodiments provide a robust and user-friendly interface, increasing user engagement with the test substance monitoring system and enabling the user to take timely actions that can be reflected in their own behavior. However, these are only some of the advantages of the embodiments described herein, and other improvements and advantages may be provided. Various configurations of these devices will be described in more detail using embodiments (which are for illustrative purposes only).

[0036] However, before describing each aspect of these embodiments in detail, it is desirable to first describe examples of devices that can be used with the embodiments described herein and examples of their operation, such as those that may be included in an in vivo substance monitoring system.

[0037] Various types of in vivo analyte monitoring systems exist. For example, a "Continuous Analyte Monitoring" system (or "Continuous Glucose Monitoring" system) can transmit data from a sensor control device to a reader device continuously (e.g., automatically according to a schedule) rather than on a prompting basis. Another example is a "Flash Analyte Monitoring" system (or "Flash Glucose Monitoring" system, or simply a "Flash" system). A flash analyte monitoring system can transmit data from a sensor control device in response to data scanning or data requests by a reader device, for example, using a Near Field Communication (NFC) protocol or a Radio Frequency Identification (RFID) protocol. In vivo analyte monitoring systems can also operate without requiring finger prick calibration.

[0038] In vivo substance monitoring systems can be distinguished from in vitro systems, which come into contact with biological samples outside the body (i.e., "ex vivo"). Typically, in vitro systems have a measuring device with a port that receives a substance sample carrying the user's bodily fluids, and are configured to determine the user's blood glucose level by analyzing the sample.

[0039] An in vivo monitoring system can be equipped with a sensor, which, when placed in the body, comes into contact with the user's bodily fluids and detects the levels of a test substance contained in those fluids. The sensor can be part of a sensor control device implanted on the user's body, which contains electronic components and a power supply responsible for performing and controlling the detection of the test substance. Note that the sensor control device and its variations may also be called a "sensor control unit," "on-body electronics" device or unit, "on-body" device or unit, or "sensor data communication" device or unit, and these are just a few examples of alternative names for a sensor control device.

[0040] Furthermore, an in vivo monitoring system may further include a device that receives test substance sensor data from a sensor control device and processes the test substance sensor data and / or displays the data to the user in any number of forms. Such a device and its variations may be called a “handheld reader device,” “reader device” (or simply “reader”), “handheld electronics” (or simply “handheld”), “portable data processing” device or unit, “data receiver,” “receiver” device or unit (or simply “receiver”), or “remote” device or unit, but these are just a few examples of the names that can be used to refer to such a device. In addition, other devices such as personal computers have been used in conjunction with or incorporated into in vivo and in vitro monitoring systems.

[0041] Exemplary Embodiment of an In Vivo Substance Monitoring System Figure 1 is a conceptual diagram showing an exemplary embodiment of a substance monitoring system 100 comprising a sensor applicator 150, a sensor control device 102, and a reading device 120. In this example, the sensor applicator 150 can be used to deliver the sensor control device 102 to a monitoring site on the user's skin. Once the sensor control device 102 is delivered to the monitoring site, the sensor 104 is held in the appropriate position for a certain period of time by an adhesive patch 105. The sensor control device 102 is further described in Figures 2B and 2C. The sensor control device 102 can communicate with the reading device 120 via a communication channel 140 using wired or wireless technology. Examples of wireless protocols include Bluetooth®, Bluetooth Low Energy (BLE, BTLE, Bluetooth SMART, etc.), and Near Field Communication (NFC). The user can view and use applications installed in the memory of the reading device 120 using the screen 122 (in many embodiments, the screen 122 can be a touch panel screen) and the input component 121. The device battery of the reading device 120 can be charged using the power port 123. Although only one reading device 120 is shown in the figure, the sensor control device 102 can communicate with multiple reading devices 120, and these multiple reading devices 120 can communicate with each other and share data. The reading device 120 will be described in detail in the following explanation of Figure 2A. The reading device 120 can also communicate with the local computer system 170 via the communication channel 141 using a wired or wireless communication protocol. The local computer system 170 may consist of one or more computing devices such as a notebook computer, desktop computer, tablet terminal, phablet (a device combining a telephone and a tablet terminal), smartphone, set-top box, or video game console.For wireless communication, numerous wireless network protocols are available, including Bluetooth, Bluetooth Low Energy (BTLE), and Wi-Fi, and any of these protocols can be used. Using the wired or wireless protocols described above, the local computer system 170 can communicate with the network 190 via the communication channel 143, and similarly, the reading device 120 can communicate with the network 190 via the communication channel 142. The network 190 can be any of several networks, including a private network, a public network, a local area network, or a wide area network. The trusted computer system 180 can have a cloud-based platform or server and can provide authentication services, secure data storage, and report generation. Furthermore, the trusted computer system 180 can communicate with the network 190 via the communication channel 144 using wired or wireless technology. Furthermore, Figure 1 illustrates a configuration in which the trusted computer system 180 and the local computer system 170 communicate with one sensor control device 102 and one reading device 120. However, those skilled in the art will understand that the local computer system 170, the trusted computer system 180, or both, can each communicate with multiple reading devices and sensor control devices via wired or wireless means.

[0042] Exemplary Embodiment of a Reading Device Figure 2A is a block diagram showing an exemplary embodiment of the reading device 120. In some embodiments, the reading device 120 can be a smartphone. In this example, the reading device 120 may comprise a display 122, an input component 121, and a processing core 206, the processing core 206 may comprise a communication processor 222 coupled to memory 223 and an application processor 224 coupled to memory 225. The reading device 120 may further comprise a separate memory 230, an RF transceiver 228 with an antenna 229, and a power supply 226 with a power management module 238. Furthermore, the reading device 120 may further comprise a multifunction transceiver 232. The multifunction transceiver 232 may comprise a wireless communication circuit and may be configured to communicate via WiFi, NFC, Bluetooth, BTLE, and GPS via the antenna 234. As those skilled in the art will understand, these components are electrically and communicatively coupled to constitute a functional device.

[0043] Exemplary Embodiments of Sensor Control Devices Figures 2B and 2C are block diagrams illustrating exemplary embodiments of a sensor control device 102 having a substance sensor 104 and a sensor electronic component 160 (equipped with a substance monitoring circuit). The sensor electronic component 160 is responsible for the majority of the processing power required to generate final result data suitable for display to the user. Figure 2B shows a single semiconductor chip 161, which can be a custom-made application-specific integrated circuit (ASIC). In the figure, the ASIC 161 contains several higher-order functional units, including an analog front-end (AFE) 162, a power management (control) circuit 164, a processor 166, and a communication circuit 168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, etc., according to the communication protocol). In this embodiment, both the AFE 162 and the processor 166 are used as substance monitoring circuits, but in other embodiments, it is possible to implement the substance monitoring function with either one of the circuits. The processor 166 may comprise one or more processors, microprocessors, controllers, and / or microcontrollers, each of which may be configured as a separate chip, or may be distributed across multiple different chips (and some thereof).

[0044] The ASIC 161 also includes a memory 163. The memory 163 may be shared among various functional units present in the ASIC 161, or it may be distributed among two or more of these functional units. The memory 163 can also be configured as a separate chip. The memory 163 can be a volatile memory and / or a non-volatile memory. In this embodiment, the ASIC 161 is coupled to a power supply 172 such as a coin cell battery. The AFE 162 interfaces with the in vivo substance sensor 104 to receive measurement data from the sensor 104 and outputs the data to the processor 166 in digital format. The processor 166 then processes this data to derive final result data such as discrete values ​​and trend values ​​of glucose. This data is supplied to the communication circuit 168 and can be transmitted via the antenna 171 to, for example, a reading device 120 (not shown). The reading device 120 can display this data after performing minimal processing on it by a resident software application. According to some embodiments, for example, the current glucose value can be transmitted from the sensor control device 102 to the reading device 120 every minute, and past glucose values ​​can be transmitted from the sensor control device 102 to the reading device 120 every five minutes.

[0045] In some embodiments, to conserve power and processing resources of the sensor control device 102, digital data received from the AFE 162 may be unprocessed or minimally processed before being transmitted to the reading device 120 (not shown). In yet other embodiments, the processor 166 may be configured to generate predetermined types of data (e.g., current glucose value, past glucose value) and store them in the memory 163 or transmit them to the reading device 120 (not shown), as well as to detect specific alarm conditions (e.g., sensor failure conditions). On the other hand, other processing and alarm functions (e.g., alarms when glucose values ​​exceed upper or lower thresholds) can be performed in the reading device 120. Those skilled in the art will understand that all or part of the methods, functions, and interfaces described herein can be performed by processing circuits in the sensor control device 102, the reading device 120, the local computer system 170, or the trusted computer system 180.

[0046] Figure 2C is the same as Figure 2B, except that it includes two different semiconductor chips 162 and 174. The semiconductor chips 162 and 174 can be packaged in the same package or packaged individually. In this example, the AFE 162 is located in the ASIC 161. The processor 166 is provided on chip 174 together with the power management circuit 164 and the communication circuit 168. The AFE 162 may include a memory 163, and chip 174 may include a memory 165. These memories may be in a separate configuration or may be integrated into the chip as distributed memory. In one exemplary embodiment, the AFE 162 is provided on one chip in combination with the power management circuit 164 and the processor 166, while the communication circuit 168 is provided on a separate chip. In another exemplary embodiment, the AFE 162 and the communication circuit 168 are provided on one chip, while the processor 166 and the power management circuit 164 are provided on separate chips. Furthermore, other chip configurations are possible, such as equipping the chips with three or more functions. Each chip can individually handle the functions described herein, and multiple chips can be configured to share one or more functions for fail-safe redundancy.

[0047] Exemplary Embodiment of a System for Integrating Test Substance Monitoring Data and Electronic Medical Record Data This specification provides exemplary embodiments of a system for integrating and sharing test substance monitoring data and electronic medical record data.

[0048] Figure 3A is a conceptual diagram illustrating an exemplary embodiment of a data flow diagram that combines data related to a patient's test substance levels with the corresponding electronic medical record of that patient. As described elsewhere in this application, the sensor control device 102 is attachable to the patient's skin, thereby holding the sensor 104 in the appropriate position for a period of time by an adhesive patch. The sensor control device 102 can communicate with the reader device 120 via the communication channel 140 using wired or wireless technology. The reader device 120 can communicate with the first trusted computer system 190 via the communication channel 142 using the wired or wireless communication protocol described above. The first trusted computer system 190 may include a cloud-based platform or server that can provide authentication services, secure data storage, and report generation. The first trusted computer system 190 can communicate with the second trusted computer system 200 via the communication channel 145 using wired or wireless technology. In some embodiments, the second trusted computer system 200 may be located on a network separate from the first trusted computer system 190 (for example, a network separated by one or more firewalls), or it may be located in a location physically separate from the first trusted computer system 190. The second trusted computer system 200 can communicate with one or more site servers 206a to 206c via the communication channel 147 using the wired or wireless communication protocols described above. In some embodiments, these one or more site servers 206a to 206c may be located on a network separate from the second trusted computer system 200 (for example, a network separated by one or more firewalls), or they may be located in a location physically separated from the second trusted computer system 200. In some embodiments, the first trusted computer system 190 and the second trusted computer system 200 may be cloud servers.At least one site server 206a to 206c can communicate with the database 210 via communication channels 149a to 149c.

[0049] A patient may have an account associated with a test substance monitoring application on a reading device 120 that receives data on test substance levels from a sensor control device 102. If a patient is under treatment or care by a healthcare center, hospital, or medical institution, the patient may receive an invitation 194 asking them to share their data with the medical institution (one or more). If the patient accepts the invitation 194 and agrees to share their data on test substance levels, a first trusted computer system 190 that receives data from the reading device 120 may transmit at least a portion of the patient's received test substance monitoring data to a second trusted computer system 200. The second trusted computer system 200 may have separate storage locations (e.g., folders) for each medical institution, and may store this at least portion of the patient's test substance monitoring data in the folder corresponding to the medical institution associated with the invitation 194. According to another aspect of the embodiment, the test substance monitoring data associated with a patient may be labeled with an external patient identifier unique to that patient. Subsequently, the second trusted computer system 200 can transmit the data stored in each individual folder to the corresponding site servers 206a-206c of the medical institutions. In some embodiments, the second trusted computer system 200 is configured not to send patient data back to the first trusted computer system 190. The second trusted computer system 200 can also be designed to prevent the mixing of data from different medical institutions. The site servers 206a-206c can combine data on the test substance level with the patient's electronic medical record, or they can share the test substance data with the electronic medical record system of the hospital's medical department. The combined data (test substance data and electronic medical record data) can then be transferred to the database 210.

[0050] As shown in Figure 3B, various patient identifiers can be assigned to the data and used in place of personally identifiable information. The first trusted computer system 190 can associate an anonymized patient ID, an external patient identifier ("EP-ID"), with the patient's test substance data 220 received from the test substance monitoring system. The EP-ID can be assigned to the patient by a medical institution (e.g., a hospital) after the patient has accepted an invitation from the institution to share the patient's test substance data. Alternatively, the patient may already have an EP-ID, in which case it can be entered into the test substance monitoring program. The first trusted computer system 190 can transfer the test substance data 220 associated with the patient's EP-ID to the second trusted computer system 200. In some embodiments, the data 220 transferred to the second trusted computer system 200 is not associated with any personally identifiable information. Furthermore, the first trusted computer system 190 can periodically transfer the data to the second trusted computer system 200 (for example, by uploading it once a day at night).

[0051] According to some embodiments, the second trusted computer system 200 can store the received data in an appropriate folder associated with an EP-ID contained in the test substance dataset 220. The test substance dataset 220 may include one or more .CSV files containing test substance data (e.g., glucose data). In some embodiments, the file name structure of each .CSV file may include an EP-ID. The transmitted data may include at least one of the following: historical glucose measurement results (e.g., glucose levels and timestamps every 15 minutes), glucometrics, and reports. Glucometrics may include at least one of the following: mean glucose value, time in range statistics, standard deviation statistics, and variability statistics. Reports may include ambulatory glucose profile (AGP) reports, circadian rhythm reports, and circadian rhythm reports. In some embodiments, the test substance dataset 220 does not store any personally identifiable information of the patient. According to some embodiments, the files stored in the second trusted computer system may be encrypted. In other embodiments, in addition to or instead of encrypting files stored in the second trusted computer system, the communication link between the first trusted computer system 190 and the second trusted computer system 200 may also be encrypted.

[0052] In some embodiments, the healthcare institution or hospital network 202 may have two servers 204, 206: a first server 204 that is directly connected to the Internet (e.g., located within a DMZ network) and a second server 206 that does not communicate directly with the Internet. Alternatively, in other embodiments, the healthcare institution or hospital 202 may have only a single server. One or more site servers 206 can manage the integration of the test substance monitoring system data 220 with the patient's electronic medical record 224 associated with the EP-ID. Furthermore, the site server 206 can associate or assign patient identifiers ("P-IDs") associated with the site server 206's electronic medical record system to the test substance dataset 220 and / or its corresponding EP-IDs. The site server 206 can link the electronic medical record 224 with the test substance dataset 220. Furthermore, the site server 206 can associate or assign a database identifier ("DB-ID") to the test substance dataset 220 and / or its corresponding EP-ID. In some embodiments, to ensure patient privacy, all or part of the healthcare institution or hospital network 202 may be configured not to be connected online.

[0053] The site server 206 can transfer the combined data (i.e., data including the test substance dataset 220 and the corresponding electronic medical record 224) to the database 210. In some embodiments, the database 210 may be located on a server on a network separated from the healthcare institution or hospital network 202 (for example, a network separated by one or more firewalls), or it may be located in a location physically separate from the healthcare institution or hospital network 202. The database 210 may include an entry server for receiving data, a multipurpose clinical data repository for storing data, and an analytical database for analyzing the data.

[0054] In the exemplary method 260 shown in Figure 3C, in step 262, a first trusted computer system receives data indicating the patient's test substance levels. In step 264, the first trusted computer system creates a test substance dataset with external patient identifiers by associating the data indicating the patient's test substance levels with external patient identifiers associated with at least one healthcare institution. In step 266, the first trusted computer system transfers this test substance dataset with external patient identifiers to a second trusted computer system. In step 268, the second trusted computer system stores the test substance dataset with external patient identifiers in a folder associated with at least one healthcare institution. In step 270, the second trusted computer system transfers the test substance dataset with external patient identifiers to a site server associated with at least one healthcare institution. In step 272, the site server creates a medical dataset with external patient identifiers by combining the test substance dataset with external patient identifiers with the electronic medical record associated with the patient. In step 274, the site server transfers the medical dataset with external patient identifiers to a database.

[0055] Exemplary Embodiments of the Patient Registration and Consent Process The hospital can create a practice account and invite third parties such as health research teams, care teams, hospital administrators, and healthcare providers (HCPs) to that account. The invited third parties can then invite patients to share their own data with the database. The shared data may include data on the patient's own test substance levels and electronic medical record data. As shown in Figure 4A, in step 282 of Method 280, the hospital creates a professional account in the test substance monitoring program, which receives data indicating test substance levels from a sensor-controlled device. Also, in step 284, the hospital can apply to register a medical practice (practitioner) with a database sharing program that operates separately from the test substance monitoring program. In step 286, the hospital can create a medical practice within the test substance monitoring program. The medical practice can be configured to allow the sharing of data associated with that medical practice. In step 288, the hospital can invite third parties (such as health research teams, care teams, hospital administrators, and healthcare providers) to participate in the medical practice.

[0056] A healthcare provider who has received an invitation to join a medical practice can invite their patients to register with that medical practice. This registration allows the patient to share their data with the medical practice, and the authorized medical practice can then share the patient data with the database 210. As shown in Figure 4B, in step 292 of method 290, the healthcare provider can receive an invitation to join a medical practice from the substance monitoring program. In one embodiment, if the healthcare provider does not yet have an account with the substance monitoring program, in step 294, the healthcare provider can create an account (e.g., a professional account). If the healthcare provider already has an account, step 294 can be omitted. In step 296, the healthcare provider can invite (one or more) patients to join the medical practice of the substance monitoring program. If the patient accepts, the substance monitoring program shares the patient data with the medical practice, and thereafter, the medical practice can share the patient data with the database. If the patient accepts the invitation (step 296), the healthcare provider can register the patient with the medical practice (step 300). In one embodiment, a healthcare provider can enroll a patient in a medical practice by entering the patient's EP-ID. In another embodiment, the healthcare provider may have previously entered the patient's EP-ID (or the patient's EP-ID may already be associated with the patient's account in the test substance monitoring program), in which case the healthcare provider only needs to confirm enrolling the patient (for example, by clicking the "enroll" button or by re-entering the patient's EP-ID). On the other hand, if the patient declines the invitation in step 298, the healthcare provider can send the invitation to the patient again after some time (step 296).

[0057] The test substance monitoring program can display a modal window (popup window) to healthcare providers, allowing them to enter patient information required by the program for invitation purposes. As shown in Figure 5A, the modal display 310 may include fields 312 for entering the patient's name, 314 for entering the patient's date of birth, 316 for entering a medical practice, and 318 for entering the patient's email address associated with the test substance monitoring program account. The medical practice field 316 can be configured to include a dropdown menu displaying a list of medical practices, or, alternatively or in addition, to automatically complete and display suggestions in the field as the healthcare provider begins typing a medical practice name. The patient invitation / creation modal display 310 can be accessed via a "Create New Patient" link, which can be accessed from the patient information upload linkage screen or from the "Invite Patient" button on the test substance monitoring program's global navigation bar.

[0058] When invitation 194 is sent, the login screen can display that there is a pending invitation. As shown in Figure 5B, the login screen of the test substance monitoring program can include a notification 322 informing the user that there is a "Pending Invitation". Furthermore, the notification 322 can also prompt the patient to accept the invitation from the healthcare provider and display the name of the requester.

[0059] As shown in Figure 5C, when a patient logs into the test substance monitoring program, a sharing request modal 330 can be displayed. The sharing request modal 330 displays text 332 indicating that a third party ([Name of requester]) is requesting access to the patient's glucose history for the care team listed below, and further displays the medical practice 334 from which the data will be shared. If the patient accepts this request, a confirmation modal 340 (see Figure 5D) can be displayed. The confirmation modal 340 displays text 342 indicating that the patient will share their glucose history with the medical practice 334 listed below. Once the invitation is accepted, the healthcare provider or requester may receive a message or notification (e.g., a modal display or email) indicating that the patient's consent has been obtained and they are ready to register the patient in the database program that will share the glucose data and EP-ID with the database. The requester can complete the registration. Registration can be completed by clicking "enroll," or it can be configured to require the patient to enter or re-enter their EP-ID to complete the registration. Once patient registration is complete, the requester may receive a message or notification (e.g., a modal display or email) informing them that the patient has been registered in the program and is ready to share data with the database.

[0060] Patients can view the medical practices to which their account is linked from the "My Practices" tab in the account settings menu. The "My Practices" GUI 350 (see Figure 5E) includes section 352, which allows patients to link their account to a medical practice without an invitation. Patients can enter the medical practice ID associated with the medical practice to which they wish to share their data. Patients can obtain the medical practice ID from their healthcare provider. When a patient enters the medical practice ID and clicks "Add," their account is linked to that medical practice. The "My Practices" GUI 350 also includes a second section 358 that lists linked medical practices. Each medical practice entry in the "Linked Medical Practices" section 358 can include the medical practice's name, address, phone number, and medical practice ID. Each medical practice entry has a selectable button that users can use to remove a linked medical practice from their account. When a medical practice is removed from an account, patient data sharing with that medical practice and database is terminated.

[0061] Patients can also connect with medical practices via a mobile application version of the substance monitoring application. As shown in Figure 6A, the "Connected Apps" GUI360 can include a "Pending Invitations" section362 and a "Connected Medical Practices" section366. The "Pending Invitations" section362 can list medical practices to which the patient has received an invitation but has not yet responded. The "Connected Medical Practices" section366 lists all medical practices currently connected to the patient's account. When a patient selects a medical practice displayed in either the "Pending Invitations" section362 or the "Connected Medical Practices" section366, a GUI is displayed showing additional information about that medical practice. If a patient selects a medical practice 364 displayed in the "Pending Invitations" section362, a GUI370 as shown in Figure 6B may be displayed. This GUI370 displays the name of the medical practice 372, and optionally also displays the medical practice ID 374, address 376, and telephone number 378. Patients can accept or decline the invitation by selecting the appropriate button. On the other hand, if there are no pending invitations or linked medical practices, the test substance monitoring application can display the "Linked Apps" GUI380, as shown in Figure 6C. This GUI380 displays "No linked medical practices" and can also display a "Link to Medical Practice" link382. When the user selects this link382, the "Linked Apps" GUI390 (see Figure 6D) is displayed. GUI390 displays a field 392, in which the user can enter the medical practice ID number of the medical practice from which they wish to share their data. Once the medical practice ID is entered, the test substance monitoring application can display a confirmation GUI400 (see Figure 6E).This GUI400 displays the name of the medical practice 372, and optionally also displays the medical practice ID 374, address 376, and telephone number 378. If a patient wants to stop sharing data with a medical practice currently linked to their account, they can select the relevant medical practice in the "Linked Medical Practices" section 366 of the "Linked Apps" GUI360, and display the GUI410 shown in Figure 6F. This "Linked Medical Practices" GUI410 displays the name of the selected medical practice 372, and optionally also displays the medical practice ID 374, address 376, and telephone number 378. The user can unlink the medical practice from their account by selecting the "Stop Sharing" option. In some embodiments, a confirmation modal may be displayed before unlinking the medical practice to ask the user if they really want to stop sharing data with the selected medical practice, and the link may only be unlinked after the patient confirms that they wish to stop sharing data with that medical practice.

[0062] Exemplary Embodiments of Methods and Systems for Implementing Two-Factor Authentication To improve the security and integrity of the aforementioned substance monitoring systems, it is desirable to implement a more sophisticated authentication scheme for user access to substance monitoring data, beyond simply requiring a username and password. One example of such a scheme is two-factor authentication (2FA). Two-factor authentication requires individuals attempting to access a user's substance monitoring data to provide a second "factor" in addition to their username and password. This second "factor" is typically an authentication code obtained from a device associated with that individual (e.g., an email sent to the individual's associated email account, an SMS text message sent to the individual's phone number, or a code displayed on an electronic key fob device). However, for users who frequently use substance monitoring systems, logging in with two-factor authentication every time they need to access their substance monitoring data can be cumbersome and inconvenient. For example, some healthcare providers may need to access substance monitoring data for multiple patients and therefore log in to the same trusted computing system multiple times a day. Therefore, the substance monitoring system requires a robust yet user-friendly two-factor authentication scheme.

[0063] Figure 7 is a flowchart illustrating an exemplary method for applying a two-factor authentication scheme to a substance monitoring system. It should be noted from the outset that those skilled in the art will understand that each method step described herein can be implemented as instructions stored in the memory of a reading device, trusted computer system, local computer system, or any other computing device used in the substance monitoring system described herein. In some embodiments, these instructions may constitute, for example, a substance monitoring software program. In some embodiments, these instructions may also be configured as a graphical user interface (GUI) generated on a trusted computer system and displayed (output) to the user's reading device or local computing system.

[0064] Referring again to Figure 7, in step 702, the username and password are received and authenticated. Next, in response to this authentication, in step 704, a code is sent to the user by a predetermined two-factor authentication means. In some embodiments, this code can be sent to the user's email address. In some embodiments, this code can also be sent to the user's phone number as an SMS text message. In yet another embodiment, this code can be sent to an electronic key fob device associated with the user. Then, in step 706, the user enters this code, and the substance monitoring system receives it.

[0065] In step 708, it is determined whether the user has selected the option to remember the currently logged-in device. If the user has not selected the "Remember device" option, the user is logged in in step 712 and method 700 ends. On the other hand, if the user has selected the "Remember device" option, in step 710, it is determined whether the number of devices the user has already remembered has reached the maximum number. If the number of devices the user has remembered has not yet reached the maximum number, in step 714, the current device is stored in memory and the user is logged in. If the number of devices the user has already remembered has reached the maximum number, in step 716, the oldest device is removed from memory, the current device is stored in memory, and the user is logged in.

[0066] Figures 8A and 8B are exemplary embodiments of a graphical user interface 810 used in a two-factor authentication scheme, such as the scheme described in the description of Figure 7. First, referring to Figure 8A, the GUI 810 displays information 812 about the two-factor authentication means from which the user is expected to receive a code. According to some embodiments, the GUI 810 further includes an input field 814 for the user to enter the code received. In some embodiments, the GUI 810 may also include a link 816 (or other selectable object such as a button) for instructing the substance monitoring system to resend the code.

[0067] Continuing to refer to Figures 8A and 8B, the GUI 810 may include a checkbox 818 (or other selectable object such as a button) to indicate the user's intention to store the device for 30 days. Those skilled in the art will understand that other storage periods (e.g., 7 days, 14 days, 21 days, 3 months, etc.) can also be used. In some embodiments, this storage period can be a fixed length of time. In other embodiments, this storage period can be a rolling window of time. For example, in some embodiments, the substance monitoring system can be configured to store the device in memory for 14 days on a rolling basis, in which case the 14-day storage period is reset each time the user logs in. Also, in some embodiments, the storage period can be set to indefinite, and the device can be stored in memory until deleted (released) by the user or the system. A "Cancel" button 822 and a "Login" button 820 are provided at the bottom of the GUI 810.

[0068] As described in the explanation of Figure 7 above, in some embodiments, if the user selects checkbox 818 (shown in Figure 8B) and the number of devices already remembered by the user has reached the maximum number, a message 824 is displayed informing the user that the current device will be remembered and the oldest device will be automatically deleted.

[0069] Figure 9 shows an exemplary embodiment of an account configuration GUI 910 configured to correspond to a two-factor authentication scheme for a substance monitoring system. Specifically, the account configuration GUI 910 provides an interface that allows the user to configure the two-factor authentication settings among the various items of the account configuration. For example, according to some embodiments, the GUI 910 may include a search bar 902 and a navigation panel 904. Furthermore, in some embodiments, the GUI 910 may also include a profile section 906. In this profile section 906, the user can change their password, change the email address associated with the account, change other account information associated with the user, or delete the account.

[0070] In another embodiment, the GUI 910 may further include a two-factor authentication section 908. In this two-factor authentication section 908, the user can configure various settings related to the two-factor authentication scheme. Specifically, the two-factor authentication section 908 is provided with a two-factor authentication means management unit 910, in which the user can select one or more authentication means for receiving a two-factor authentication code. Examples of such authentication means include means using a telephone number or means using an email address. In some embodiments, the two-factor authentication means management unit 910 may be configured to allow editing of information associated with the two-factor authentication means, or to allow specifying which two-factor authentication means to use as the primary or auxiliary means.

[0071] Continuing to refer to Figure 9, the two-factor authentication section 908 also includes a trusted device management unit 912, in which the user can check the number of trusted devices stored in memory. In some embodiments, the trusted device management unit 912 can be configured to allow the user to delete individual trusted devices. In some embodiments, the trusted device management unit 912 can also include a link 914 (or other selectable object such as a button) for deleting all trusted devices at once. Furthermore, according to some embodiments, if the user selects this link 914, a confirmation modal display can be shown to ask the user whether they want to delete all trusted devices.

[0072] Those skilled in the art will understand that the GUIs, report interfaces, or parts thereof described herein are for illustrative purposes only, and that any individual element or any combination of elements illustrated and described in relation to a particular embodiment or figure can be freely combined with any element or any combination of elements illustrated and described in relation to any other embodiment.

[0073] Furthermore, those skilled in the art will understand that any of the GUIs, reporting interfaces, or parts thereof described herein can be implemented in a test substance monitoring system that monitors one or more test substances. Such test substances may include one or more arbitrary test substances detectable in the user's bodily fluids, such as glucose, ketones, lactic acid, and alcohol. Also, those skilled in the art will understand that any of the GUIs, reporting interfaces, or parts thereof described herein can take in data received from multiple test substance monitoring systems and their associated devices, for example, from devices that perform ex vivo test substance measurements or physiological measurements.

[0074] It should be noted that all features, elements, components, functions, and steps described in the description of any embodiment described herein are intended to be freely combined and interchangeable with features, elements, components, functions, and steps of any other embodiment. Furthermore, even if a particular feature, element, component, function, or step is described in only one embodiment, it should be understood that, unless otherwise explicitly stated, that feature, element, component, function, or step is applicable to all other embodiments described herein. Therefore, even if the following description does not explicitly mention, as a specific example, that features, elements, components, functions, and steps can be combined or interchangeable between different embodiments, this paragraph serves as prior art and supporting documentation, allowing claims including such combinations or substitutions to be added at any time. Explicitly describing every possible combination and substitution would be an undue burden, especially considering that the permissibility of all such combinations and substitutions would be readily apparent to those skilled in the art.

[0075] While various modifications and changes in form are possible for the embodiments, specific examples are shown in the drawings and described in detail herein. However, it should be understood that these embodiments are not limited to the specific forms disclosed, but rather encompass all variations, equivalents, and substitutions within the spirit of the invention. Furthermore, any feature, function, step, or element of an embodiment may be included in the claims, and the scope of the invention in the claims may be defined by negative limitations indicating features, functions, steps, or elements not included in the claims.

[0076] The above describes a system and method for integrating data from a test substance monitoring system and data from an electronic medical record system. This method includes the step of identifying a patient's test substance data by associating the patient's test substance data with an external patient identifier associated with at least one medical institution. The patient's test substance data identified by the external patient identifier can be transferred from a first cloud server to a second cloud server. The test substance data can be stored in a folder associated with at least one medical institution within the second cloud server. The test substance data can also be combined with the patient's electronic medical record within the second cloud server. The combined data can then be transferred to a database for further detailed analysis.

[0077] Sectionalized description The following exemplary embodiments are described in separate numbered sections.

[0078] Section 1 A method for providing a medical dataset database for data sharing, which integrates data from a substance monitoring system and data from an electronic medical record system, The first trusted computer system receives data from the test substance monitoring system indicating the patient's test substance levels, The steps of creating a test substance dataset with external patient identifiers by identifying an external patient identifier associated with at least one medical institution and associating the data indicating the patient's test substance level with the external patient identifier associated with the at least one medical institution using the first trusted computer system, The steps include transferring the test substance dataset with external patient identifier from the first trusted computer system to the second trusted computer system, The steps include: using the second trusted computer system to identify a folder associated with the at least one medical institution, and using the second trusted computer system to store the external patient identifier-attached test substance dataset in the folder associated with the at least one medical institution; The steps include transferring the external patient identifier-attached test substance dataset from the second trusted computer system to a site server associated with the at least one medical institution, The steps include: using the site server to identify the electronic medical record associated with the patient, and using the site server to combine the external patient identifier-attached test substance dataset with the electronic medical record associated with the patient to create an external patient identifier-attached medical dataset; The site server transfers the medical dataset with external patient identifiers to the database. A method that includes this.

[0079] Section 2 The method according to paragraph 1, wherein the test substance dataset with external patient identifiers does not contain the user's personal identification information.

[0080] Section 3 The method according to paragraph 1 or 2, wherein at least a portion of the data relating to the test substance levels of the user associated with the external patient identifier includes past glucose measurement results.

[0081] Section 4 The method according to paragraph 1, paragraph 2, or paragraph 3, wherein at least a portion of the data relating to the test substance levels of the user associated with the external patient identifier includes glucometers.

[0082] Section 5 The method according to paragraph 4, wherein the glucometer includes at least one of the mean glucose level, the time it was within the target range, and the standard deviation.

[0083] Section 6 The method according to any one of paragraphs 1 to 5, wherein at least a portion of the data relating to the test substance levels of the user associated with the external patient identifier includes an ambulatory glucose profile.

[0084] Section 7 The method according to any one of paragraphs 1 to 6, wherein the external patient identifier is assigned by the at least one medical institution.

[0085] Section 8 The method according to any one of paragraphs 1 to 7, wherein the data indicating the level of the substance being tested is associated with multiple medical institutions.

[0086] Section 9 The method according to paragraph 8, wherein the second trusted computer system transfers the external patient identifier-attached test substance dataset to a site server associated with each of the multiple medical institutions.

[0087] Section 10 The method according to any one of paragraphs 1 to 9, further comprising the step of inviting a user to share data with the at least one healthcare provider, prior to the step of associating the external patient identifier associated with the at least one healthcare provider with the data indicating the patient's test substance levels using the first trusted computer system.

[0088] Section 11 The method according to any one of paragraphs 1 to 10, further comprising the step of the site server associating a database identifier to be transferred to the database with the medical dataset with the external patient identifier.

[0089] Section 12 The method of paragraph 11, further comprising the step of storing the medical dataset with external patient identifiers in the database according to the database identifier.

[0090] Section 13 The method according to any one of paragraphs 1 to 12, further comprising the step of associating a patient identifier with the external patient identifier or the test substance dataset with the external patient identifier using the site server.

[0091] Section 14 The method according to any one of paragraphs 1 to 13, wherein the at least one medical institution is at least one hospital.

[0092] Section 15 A system that provides a database of medical datasets for data sharing, A sensor control device equipped with a substance sensor, wherein at least a portion of the substance sensor is configured to come into fluid contact with the bodily fluids of the monitored user, A reading device configured to wirelessly receive data indicating the patient's test substance level from the sensor control device and to transmit the data indicating the test substance level, The steps include receiving the data indicating the level of the substance to be tested, The steps include creating a test substance dataset with external patient identifiers by identifying external patient identifiers associated with at least one medical institution and associating the external patient identifiers associated with the at least one medical institution with the data indicating the test substance levels, The steps include transferring the aforementioned dataset of test substances with external patient identifiers, A first trusted computer system configured to perform, The steps include receiving the aforementioned external patient identifier-attached test substance dataset, The steps include: identifying a folder associated with at least one medical institution, and storing the external patient identifier-attached test substance dataset in the folder associated with the at least one medical institution; The steps include transferring the external patient identifier-attached test substance dataset that was stored in the folder associated with the at least one medical institution, A second trusted computer system configured to perform the following: A site server associated with at least one of the aforementioned medical institutions, The steps include receiving the external patient identifier-attached test substance dataset stored in the folder associated with at least one medical institution, The steps include identifying the electronic medical record associated with the patient, and creating a medical dataset with an external patient identifier by combining the external patient identifier-attached test substance dataset with the electronic medical record associated with the patient, The steps include transferring the aforementioned medical dataset with external patient identifiers to a database, A site server configured to run, A system equipped with these features.

[0093] Section 16 A method of providing a database by registering patients in a data sharing program, In the substance surveillance program, the first step is to accept the invitation to participate in medical practice, The steps include identifying a patient in the aforementioned substance monitoring program and sending a second invitation to the patient in the aforementioned substance monitoring program to request consent to data sharing with the medical practice, If the patient accepts the second invitation, in response, The step of registering the patient in the data sharing program so that the patient's test substance data can be shared with a third-party database, The steps include identifying an external patient identifier associated with the patient in the aforementioned test substance monitoring program, A method that includes this.

[0094] Section 17 The method of paragraph 16, wherein the patient is registered by entering the external patient identifier associated with the patient and confirming the registration.

[0095] Section 18 The method according to paragraph 16 or 17, wherein the second invitation is displayed to the patient in a modal display within the substance monitoring program.

[0096] Section 19 The method according to paragraph 16, 17, or 18, wherein the second invitation is displayed to the patient in an email sent from the substance monitoring program. [Explanation of symbols]

[0097] 100 Test Substance Monitoring System 102 Sensor control devices 104 Sensor for the substance being tested 105 Adhesive Patches 120 reading devices 121 Input components of reading devices 122 Display of reading device 123 Power port for reading device 140, 141, 142, 143, 144, 145, 147, 149a~149c communication path 150 Sensor Applicators 160 Sensor electronic components for sensor control devices 161 Semiconductor Chips (ASICs) 162 Semiconductor Chips (AFE) 163, 165 Memory of sensor control devices 164 Power management (control) circuit for sensor control devices 166 Processors for Sensor Control Devices 168 Communication Circuit for Sensor Control Devices 170 Local Computer System 171 Antennas for sensor control devices 172 Power supply for sensor control devices 174 Semiconductor Chips 180 Trusted Computer Systems 194 Invitation 200 Second Trusted Computer System 202 Network of medical institutions or hospitals 210 Databases 220 Test substance data, test substance monitoring system data, test substance dataset 222 Communication processor for reading devices 223, 225, 230 Memory of the reading device 226 Power supply for reading devices 228 RF transceivers for reading devices 229, 234 Antennas of reading devices 232 Multifunctional transceiver for reading devices 238 Power management module for reading devices 310 Modal display for patient invitation / creation 312 Input field for patient name 314 Input field for patient's date of birth 316 Input fields for medical practice 318 Input field for patient's email address 322 Notification informing you that you have pending invitations 330 Share Request Modal Display 332 Text indicating that a third party is requesting access to your glucose history. 334 Display of medical practices requesting data sharing 340 Confirmation modal display 342 Text indicating that the following medical practices and glucose history will be shared. 350 "My Medical Practice" GUI 352 Section for collaborating with medical practices without invitation Sections 358 and 366, "Collaborated Medical Practices" 360, 370, 380, 390 "Linked Apps" GUI 362 "Pending Invitations" section Display of 364 medical practices with pending invitations. 372 Names of medical practices 374 Medical Practice ID 376 Medical practice addresses 378 Medical practice phone number 382 Link to "Collaborating with Medical Practice" 392 Medical Practice ID Input Field 400 "Linked App" GUI (GUI for confirming medical practices) 410 "Linked App" GUI ("Linked Medical Practices" GUI) 810 GUI used in two-factor authentication schemes 812 Information regarding two-factor authentication methods 814 Verification code input field Link to instruct you to resend the 816 code. 818 Device storage options checkbox 820 "Login" button 822 "Cancel" button 824 Message notifying you of the current device memory and automatic deletion of the oldest device. 902 Search bar 904 Navigation Panel 906 Profile Section 908 Two-Factor Authentication Section 912 Trusted Devices Management Department 914 Link to remove trusted devices in bulk

Claims

1. A method for providing a medical dataset database for data sharing, which integrates data from a substance monitoring system and data from an electronic medical record system, The first trusted computer system receives data from the test substance monitoring system indicating the patient's test substance levels, The steps include: identifying an external patient identifier associated with at least one medical institution, and creating a test substance dataset with an external patient identifier by associating the data indicating the patient's test substance level with the external patient identifier associated with the at least one medical institution using the first trusted computer system; The steps include transferring the test substance dataset with external patient identifier from the first trusted computer system to the second trusted computer system, The steps include: using the second trusted computer system to identify a folder associated with the at least one medical institution, and using the second trusted computer system to store the external patient identifier-attached test substance dataset in the folder associated with the at least one medical institution; The steps include transferring the external patient identifier-attached test substance dataset from the second trusted computer system to a site server associated with at least one medical institution, The steps include: using the site server to identify the electronic medical record associated with the patient, and using the site server to combine the external patient identifier-attached test substance dataset with the electronic medical record associated with the patient to create an external patient identifier-attached medical dataset; The site server transfers the medical dataset with external patient identifiers to the database. A method that includes this.

2. The method according to claim 1, wherein the dataset of test substances with external patient identifiers does not contain the user's personal identification information.

3. The method according to claim 1, wherein at least a portion of the data relating to the test substance levels of the user associated with the external patient identifier includes past glucose measurement results.

4. The method according to claim 1, wherein at least a portion of the data relating to the test substance levels of a user associated with the external patient identifier includes glucometry.

5. The method according to claim 4, wherein the glucometer includes at least one of the mean glucose level, the time it was within the target range, and the standard deviation.

6. The method according to claim 1, wherein at least a portion of the data relating to the test substance levels of the user associated with the external patient identifier includes an ambulatory glucose profile.

7. The method according to claim 1, wherein the external patient identifier is assigned by the at least one medical institution.

8. The method according to claim 1, wherein the data indicating the level of the substance being tested is associated with multiple medical institutions.

9. The method according to claim 8, wherein the second trusted computer system transfers the external patient identifier-attached test substance dataset to a site server associated with each of the plurality of medical institutions.

10. The method according to claim 1, further comprising the step of inviting a user to share data with the at least one healthcare provider, prior to the step of associating the external patient identifier associated with the at least one healthcare provider with the data indicating the patient's test substance levels using the first trusted computer system.

11. The method according to claim 1, further comprising the step of associating a database identifier to be transferred to the database with the medical dataset with external patient identifiers using the site server.

12. The method according to claim 11, further comprising the step of storing the medical dataset with external patient identifiers in the database according to the database identifier.

13. The method according to claim 1, further comprising the step of associating a patient identifier with the external patient identifier or the test substance dataset with the external patient identifier using the site server.

14. The method according to claim 1, wherein the at least one medical institution is at least one hospital.

15. A system that provides a database of medical datasets for data sharing, A sensor control device equipped with a substance sensor, wherein at least a portion of the substance sensor is configured to come into fluid contact with the bodily fluids of the monitored user, A reading device configured to wirelessly receive data indicating the patient's test substance level from the sensor control device and to transmit the data indicating the test substance level, The steps include receiving the data indicating the level of the substance to be tested, The steps include: identifying an external patient identifier associated with at least one medical institution, and creating a test substance dataset with an external patient identifier by associating the data indicating the level of the test substance with the external patient identifier associated with the at least one medical institution; The steps include transferring the aforementioned dataset of test substances with external patient identifiers, A first trusted computer system configured to perform the following: The steps include receiving the aforementioned external patient identifier-attached test substance dataset, The steps include: identifying a folder associated with at least one medical institution, and storing the external patient identifier-attached test substance dataset in the folder associated with the at least one medical institution; The steps include transferring the external patient identifier-attached test substance dataset that was stored in the folder associated with at least one medical institution, A second trusted computer system configured to perform the following: A site server associated with at least one of the aforementioned medical institutions, The steps include receiving the external patient identifier-attached test substance dataset stored in the folder associated with at least one medical institution, The steps include identifying the electronic medical record associated with the patient, and creating a medical dataset with an external patient identifier by combining the external patient identifier-attached test substance dataset with the electronic medical record associated with the patient, The steps include transferring the aforementioned medical dataset with external patient identifiers to a database, A site server configured to run, A system equipped with these features.

16. A method of providing a database by registering patients in a data sharing program, In the substance surveillance program, the first step is to accept the invitation to participate in medical practice, The steps include identifying a patient in the aforementioned substance monitoring program and sending a second invitation to the patient in the aforementioned substance monitoring program to request consent to data sharing with the medical practice, If the patient accepts the second invitation, in response, The step of registering the patient in the data sharing program so that the patient's test substance data can be shared with a third-party database, The steps include identifying an external patient identifier associated with the patient in the aforementioned test substance monitoring program, A method that includes this.

17. The method according to claim 16, wherein the patient is registered by entering the external patient identifier associated with the patient and confirming the registration.

18. The method according to claim 16, wherein the second invitation is displayed to the patient in a modal display within the substance monitoring program.

19. The method according to claim 16, wherein the second invitation is displayed to the patient in an email sent from the substance monitoring program.

Images