Medical monitoring system and method

Abstract

The interactive graphical user interface related information, configured for interactive display and input, includes, for example, patient identification information for each patient in the patient list, a medication schedule for each patient, and a treatment assessment worksheet with displays showing clinical monitoring data for each patient, allowing monitoring results over various time periods to be compared with the progress of the treatment plan.

Description

Cross - reference to related applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 061,704, filed August 5, 2020, which is hereby incorporated by reference in its entirety as part of this application.

Technical Field

[0002] This application relates to electronic interfaces such as graphical user interfaces for the purpose of medical monitoring and treatment management, as well as various related systems, devices, and methods.

Background Art

[0003] There are various body - wearable monitoring devices for interstitial or intravenous monitoring of analytes indicating health status. For example, in the field of diabetes treatment, a sensor control device for monitoring interstitial glucose is available by using a sensor connected to an arithmetic processing unit, a storage device, a power source, and a wireless interface, which are implanted subcutaneously and placed in a reservoir adhered to the patient's skin. The arithmetic processing unit performs periodic sensor readings, stores sensor data in the storage device, and can communicate the sensor data to other devices such as the patient's smartphone, or a medical staff member's notebook computer, personal computer, or similar processing and display devices. In some cases, smartphones and other devices are configured to upload and store monitoring data on a remote server and then distribute it to authorized medical staff. Therefore, by enabling patients and medical staff to obtain a large amount of monitoring data obtained at intervals over continuous periods, it is intended to be used in managing medical treatments for health status, and an example is diabetes but not limited thereto.

Summary of the Invention

Problems to be Solved by the Invention

[0004] However, in some situations, it can be difficult for healthcare professionals to optimally utilize monitoring data from removable body monitoring devices. While various electronic interfaces, such as graphical user interfaces, are known and already used to access monitoring information, healthcare professionals frequently need supplementary information to make the most efficient use of the available data, guidance for interpreting the monitoring data, or guidance for therapeutic recommendations. Currently, the electronic interfaces that healthcare professionals use to access and apply clinical monitoring data from removable body devices lack useful functions, or such functions are not configured in a manner that is optimal for the flow of treatment.

[0005] Therefore, it is desirable to develop new methods and other novel technologies for various electronic interfaces, such as graphical user interfaces for the purpose of medical monitoring and treatment management, that overcome the aforementioned and other limitations of the prior art. [Means for solving the problem]

[0006] The summary of this invention and the detailed description in the following sections are complementary parts of a single, integrated disclosure, and each part should be interpreted as containing redundant subject matter, supplementary subject matter, or both. The omission of either part does not indicate the priority or relative importance of any element described in the integrated application. Differences between the two parts may consist of supplementary disclosures of other optional embodiments, additional details, or alternative descriptions that use different terminology to describe identical embodiments, but these should be obvious from the respective disclosures.

[0007] In one aspect of the present disclosure, a method for an electronic interface of a computer device may include, by at least one processing unit, detecting an identifier of a sensor device worn by a patient within the wireless range of a receiver connected to the at least one processing unit. The method may further include, by at least one processing unit, receiving medical monitoring data collected by the sensor device over a continuous period. The method may also include providing a display device with interactive graphical user interface-related information configured for interactive display and input, such information including patient identification information for each patient in a patient list, a medication schedule for each patient, and a treatment evaluation worksheet containing display content showing medical monitoring data for each patient. Depending on the embodiment, the system may be configured to be suitable for interactive display and input, and may include providing the display device with interactive graphical user interface-related information, including a medical intervention screen. Such a medical intervention screen is configured to show the patterns (problems) that the healthcare provider will address during the current outpatient consultation, the content of editing, adding, deleting, or various combinations of the above for the patient's medication, and self-care actions that the patient can try to replicate. This method may include receiving data input for each patient via an interactive graphical user interface during the outpatient consultation, and saving said data input in a patient-specific history. This method may also include further details and various operations as described in the detailed explanations in the following sections.

[0008] This method may be implemented by any user interface device suitable for receiving clinical monitoring data of identified patients. As used herein, “user interface device” means a computer processing device (e.g., a desktop computer, laptop computer, tablet computer, smartphone, PDA, etc.) that is connected to a storage device and to one or more ports including at least one input port and at least one output port. A computer processing device means, for example, a miniature arithmetic processing unit, a microcontroller, a single-chip integrated system (system-on-a-chip), or any other arithmetic processing circuit. As used herein, “arithmetic processing unit (processor)” means a computer processing unit.

[0009] To achieve the aforementioned and related objectives, one or more embodiments are described in detail below and possess the various features particularly indicated in the claims. The following description and accompanying drawings illustrate each specific embodiment in detail and show only a few of the various ways in which the principle of each specific embodiment is employed. Other advantages and novel features will become apparent from the following detailed description when considered together with the drawings and disclosed embodiments, which cover all such embodiments and their equivalents. [Brief explanation of the drawing]

[0010] The features, nature, and advantages of this disclosure will become more apparent from the detailed description provided below, when interpreted in conjunction with the drawings, in which the same reference numerals throughout the specification and drawings identify the same components in a one-to-one correspondence. [Figure 1] A diagram illustrating the overview of a test substance monitoring system, which consists of a sensor applicator, sensor control device, reader, network, trusted computer system, and local computer system. [Figure 2A] A block diagram illustrating a specific embodiment of the reading device. [Figure 2B] A block diagram illustrating a specific embodiment of the sensor control device. [Figure 2C] A block diagram illustrating a specific embodiment of the sensor control device. [Figure 2D] A block diagram illustrating a specific embodiment of a user interface device. [Figure 3] A flowchart illustrating the operation of a method for providing a graphical user interface for the purpose of monitoring medical care and managing treatment. [Figure 4] A flowchart illustrating various further selective embodiments of the method diagrammed in Figure 3. [Figure 5A] A graphical user interface screen diagram illustrating various aspects of an outpatient consultation using a graphical user interface and its methods. [Figure 5B] A graphical user interface screen diagram illustrating various aspects of an outpatient consultation using a graphical user interface and its methods. [Figure 5C] A graphical user interface screen diagram illustrating various aspects of an outpatient consultation using a graphical user interface and its methods. [Figure 6A] A graphical user interface screen diagram illustrating various aspects of the patient information section of a graphical user interface and its method. [Figure 6B] A graphical user interface screen diagram illustrating various aspects of the patient information section of a graphical user interface and its method. [Figure 6C] A graphical user interface screen diagram illustrating various aspects of the patient information section of a graphical user interface and its method. [Figure 6D] A graphical user interface screen diagram illustrating various aspects of the patient information section of a graphical user interface and its method. [Figure 6E]A graphical user interface screen diagram illustrating each aspect of the patient information part of the graphical user interface and its method. [Figure 7A] A graphical user interface screen diagram illustrating each aspect of the examination information part of the graphical user interface and its method. [Figure 7B] A graphical user interface screen diagram illustrating each aspect of the examination information part of the graphical user interface and its method. [Figure 7C] A graphical user interface screen diagram illustrating each aspect of the examination information part of the graphical user interface and its method. [Figure 7D] A graphical user interface screen diagram illustrating each aspect of the examination information part of the graphical user interface and its method. [Figure 7E] A graphical user interface screen diagram illustrating each aspect of the examination information part of the graphical user interface and its method. [Figure 8] A flowchart illustrating further alternative aspects of the method diagrammed in Figure 3. [Figure 9A] A graphical user interface screen diagram illustrating each aspect of the dosing part of the graphical user interface and its method. [Figure 9B-1] A graphical user interface screen diagram illustrating each aspect of the dosing part of the graphical user interface and its method. [Figure 9B-2] A graphical user interface screen diagram illustrating each aspect of the dosing part of the graphical user interface and its method. [Figure 9B-3] A graphical user interface screen diagram illustrating each aspect of the dosing part of the graphical user interface and its method. [Figure 9C]A graphical user interface screen diagram illustrating each aspect of the dosing portion of the graphical user interface and its method. [Figure 9D] A graphical user interface screen diagram illustrating each aspect of the dosing portion of the graphical user interface and its method. [Figure 9E] A graphical user interface screen diagram illustrating each aspect of the dosing portion of the graphical user interface and its method. [Figure 9F] A graphical user interface screen diagram illustrating each aspect of the dosing portion of the graphical user interface and its method. [Figure 9G] A graphical user interface screen diagram illustrating each aspect of the dosing portion of the graphical user interface and its method. [Figure 10] A flowchart illustrating each aspect of further alternative treatment evaluation of the method diagrammed in Figure 3. [Figure 11A-1-1] A graphical user interface screen diagram illustrating each aspect of the treatment evaluation portion of the graphical user interface and its method. [Figure 11A-1-2] Continuation of Figure 11A-1-1. [Figure 11A-2] A graphical user interface screen diagram illustrating each aspect of the treatment evaluation portion of the graphical user interface and its method. [Figure 11B] A graphical user interface screen diagram illustrating each aspect of the treatment evaluation portion of the graphical user interface and its method. [Figure 11C-1] A graphical user interface screen diagram illustrating each aspect of the treatment evaluation portion of the graphical user interface and its method. [Figure 11C-2] A graphical user interface screen diagram illustrating each aspect of the treatment evaluation portion of the graphical user interface and its method. [Figure 11D]A graphical user interface screen diagram illustrating various aspects of the graphical user interface and the treatment evaluation portion of the method. [Figure 12] A flowchart illustrating one or more additional steps to present human-readable observational records and recommendations for treatment evaluation, which may be included in the method diagrammed in Figure 3. [Figure 13A] A table showing examples of evaluation results that can be managed and displayed using a graphical user interface and its methods. [Figure 13B] A flowchart illustrating various methods for selecting text to represent evaluation results by a processing unit. [Figure 14] A conceptual block diagram illustrating the components of a device or system for providing a graphical user interface for the purpose of monitoring medical care and managing treatment. [Modes for carrying out the invention]

[0011] Here, various embodiments will be described with reference to the drawings. In the following description, an attempt is made to ensure a full understanding of one or more embodiments by explicitly stating numerous specific details for explanatory purposes. However, it is presumed that various embodiments can be carried out even without such specific details. In other examples, various well-known structures and devices are represented in the form of block diagrams to facilitate focusing on the novel embodiments of the present disclosure. While specific embodiments relate to the monitoring of glucose levels in diabetes and the management of treatment therefor, the concepts of the inventions herein may be extended to graphical user interfaces aimed at monitoring and treating various symptoms or diseases other than diabetes.

[0012] Each embodiment disclosed herein relates to various improved graphical user interfaces (GUIs) or GUI functions for analyte monitoring systems that are intuitive, user-friendly, and facilitate healthcare professionals' evaluation of patient physiological information. For example, these embodiments enable healthcare professionals to quickly and thoroughly evaluate patient clinical monitoring data, review patient medication and self-care history synchronized with a graphical display of monitoring data, identify potential shortcomings in treatment, improve medication prescriptions, and advise patients on self-care. Various forms of graphical user interfaces (GUIs) and GUI functions such as guided explanatory reports (GIRs) enable healthcare professionals to gain a better understanding of the actual effects of medication, patient habits, and responses to medication, and to be better prepared to improve the treatment of diseases and conditions. Similarly, each embodiment presented herein provides an improved digital interface, its functions, or both, for the purpose of evaluating the large amount of data collected by an automated analyte monitoring system, enabling rapid and accurate assessment of the effects of past medical interventions, addressing recurring issues in specific time periods, collecting and rapidly integrating relevant data into a compact interface, organizing patient histories, streamlining interviews during hospital visits, and, among other benefits and advantages of the disclosure, conveniently creating accurate records of test results and medical interventions to form a patient's medical history.

[0013] Where used herein and in the appended claims, “a,” “an,” and “the” refer to multiple subjects unless the context otherwise explicitly indicates otherwise.

[0014] Each published document discussed herein merely indicates that it was disclosed prior to the filing date of this application. Nothing in this specification should be interpreted as stating that such published documents are not entitled to precede the disclosure in this application simply because they were disclosed earlier. Furthermore, the published dates presented may differ from the actual published dates and should be verified on a case-by-case basis.

[0015] Broadly speaking, embodiments of the present disclosure include graphical user interfaces (GUIs) and digital interfaces for analyte monitoring systems, as well as related methods and apparatus. Accordingly, many embodiments include various in vivo analyte sensors, which are structurally configured such that at least one part of them can be placed or positioned within the user's body, thereby acquiring information about at least one type of analyte in the body. However, it should be noted that each embodiment disclosed herein can be used in conjunction with various in vivo analyte monitoring systems that incorporate in vitro capabilities, as well as various systems for purely in vitro analyte monitoring, i.e., in vitro analyte monitoring, such as completely non-invasive systems.

[0016] Furthermore, for all embodiments of the methods disclosed herein, various systems and apparatus that can carry out each of them are included within the scope of the disclosure. For example, embodiments of sensor control devices, readers, local computer systems, and trusted computer systems that meet the U.S. National Security Agency computer security assessment standards are disclosed, and these apparatus and systems comprise one or more sensors, an object monitoring circuit (e.g., an analog circuit), a memory device (e.g., for storing instructions), a power supply, a communication circuit, a transmitter, a receiver, a processing unit, a controller (e.g., for executing instructions), or various combinations thereof, and these components can carry out and facilitate the execution of each step of any and all methods.

[0017] However, before describing these aspects of each embodiment in detail, it is preferable to first describe specific examples of the operation of these devices, as well as specific examples of the devices that can be contained within the in vivo analyte monitoring system, although all of these specific examples can be used in conjunction with the embodiments described herein.

[0018] There are various types of in vivo analyte monitoring systems. For example, a "continuous analyte monitoring" system (or "continuous glucose monitoring" system) can continuously transmit data from a sensor control unit to a reader automatically, for example, according to a schedule, without prompting user input. Another example is an "instantaneous analyte monitoring" system (or "instantaneous glucose monitoring" system or simply an "instantaneous" system) that can transfer data from a sensor control unit in response to scanning or data requests by a reader, such as those utilizing Near Field Communication (NFC) or Radio Frequency Identification (RFID) protocols. In vivo analyte monitoring systems can also operate without requiring fingerprick testing.

[0019] In vivo analyte monitoring systems can be distinguished from "in vitro" systems, which handle biological samples outside the body (i.e., "ex vivo") and typically feature measuring devices equipped with ports to receive analyte test pieces containing the user's bodily fluids, which may be analyzed to determine the user's blood glucose levels.

[0020] The in vivo monitoring system may include sensors that, while positioned within the body, come into contact with the user's bodily fluids and sense the levels of analytes contained therein. The sensors may constitute part of a sensor control unit located on the user's body, but have electronic equipment and a power supply that enable and control the sensing of the analytes. The sensors may be invasive, such as glucose sensors or blood glucose sensors configured to be inserted under the skin to sense glucose in interstitial tissue. In alternative embodiments, the sensors may sense different analytes than those described above, or may be non-invasive. The sensor control unit may be equipped to measure a variety of quantities, in addition to glucose and other analytes, such as body temperature, pulse rate, and blood oxygen levels. Sensor control units and their various variations may also be called "sensor control units," "on-body electronic equipment" devices or "on-body electronic equipment" units, "on-body" devices or "on-body" units, or "sensor data communication" devices or "sensor data communication" units.

[0021] In vivo monitoring systems also include a device that receives the detected analyte data from a sensor control unit, processes the detected analyte data, displays the data to the user in any format, or performs various combinations of these operations. This device and its various variations may be referred to as, to name just a few, a "handheld reader," a "reader" (or simply a "reader"), a "handheld electronic device" (or simply a "handheld"), a "portable data processing" device or "portable data processing" unit, a "data receiver," a "receiver" device or "receiver" unit (or simply a "receiver"), a "remote" device or "remote" unit, and so on. Other devices, such as personal computers, are also used in conjunction with or incorporated into in vivo and in vitro monitoring systems.

[0022] Specific Examples of In vivo Analyte Monitoring Systems Figure 1 is a conceptual diagram illustrating a specific embodiment of an analyte monitoring system 100 comprising a sensor applicator 150, a sensor control device 102, and a reader 120. Here, the sensor applicator 150 can be used to deliver a sensor to a monitoring site on the patient's skin, where the sensor 104 is held in place for a period of time by an adhesive patch 105. The sensor control device 102, further described in Figures 2B and 2C, can communicate with the reader 120 via a communication path 140 utilizing wired or wireless technology. Various examples of specific wireless communication protocols include Bluetooth®, Bluetooth Low Energy (BLE or BTLE, i.e., "Bluetooth" Low Energy, i.e., "Bluetooth" Smart, etc.), and Near Field Communication (NFC). The user can use the display screen 122 (which may consist of a touchscreen in most embodiments) and the input unit 121 to visually view and use the application installed in the storage device of the reader 120. The battery of the reader 120 can be recharged using the power port 123. Although only one reader 120 is shown, the sensor control device 102 can communicate with multiple reader devices 120. Each reader device 120 can communicate with each other and share data. Further details about the reader 120 will be shown later with reference to Figure 2A. The reader 120 can communicate with the local computer system 170 via the communication path 141 using a wired communication protocol or a wireless communication protocol.

[0023] The local computer system 170 may be one or more of the following: a laptop, desktop, tablet, phablet, smartphone, set-top box, video game console, or other computer device, or may include one or more of these as components. The wireless communication may include one of many applicable wireless network protocols, such as Bluetooth, Bluetooth Low Energy (BTLE), or Wi-Fi. The local computer system 170 can communicate with the network 190 via the communication path 143, similar to how the reader 120 can communicate with the network 190 via the aforementioned wired or wireless communication protocols via the communication path 142. The network 190 may be one of several networks, such as a private network, a public network, a local area network, or a wide area network. Depending on the embodiment, the local computer system 170 may function as a user interface device that operates an interactive graphical user interface (GUI) in a clinical environment used by a healthcare professional, as described herein. The local computer system 170 may have the same components as, or equivalent to, the components of the reader 120, in the same or different form factors. For example, the reader may be a smartphone, and the local computer may be a laptop or a personal computer.

[0024] The trusted computer system 180 may include a cloud-based platform or server and can provide authentication services, secure data storage, and report generation, and can communicate with the network 190 via wired or wireless technology through the communication path 144. In addition, although Figure 1 shows the trusted computer system 180 and the local computer system 170 communicating with one sensor control device 102 and one reader device 120, a person skilled in the art will recognize that the local computer system 170, the trusted computer system 180, or both can each be in wired or wireless communication with multiple readers and multiple sensor control devices.

[0025] Specific example of a reading device Figure 2A is a block diagram illustrating a specific embodiment of the reading device 120, and in some embodiments, it may be composed of a smartphone. Here, the reading device 120 may include a display screen 122, an input unit 121, and a processing core 206, the processing core 206 having a communication processing unit 222 connected to a storage device 223 and an application processing unit 224 coupled to a storage device 225. A separate storage device 230, a wireless communication device 228 with an antenna 229, and a power supply 226 with a power management module 238 may also be provided. Furthermore, the reading device 120 may include a multifunction transceiver 232, which is equipped with a wireless communication circuit and can be configured to communicate via the antenna 234 using Wi-Fi, NFC, Bluetooth, BTLE, GPS, etc. As those skilled in the art will understand, these components are electrically and communicatively connected in a manner that constitutes a functional device.

[0026] Specific Examples of Sensor Control Devices Figures 2B and 2C are block diagrams illustrating specific embodiments of the sensor control device 102, which includes an analyte sensor 104 and sensor electronic equipment 160 (including an analyte monitoring circuit), and can be configured to have most of the processing power necessary to display the final result data to the user. Figure 2B shows a single semiconductor chip 161, which may be a custom-made application-specific integrated circuit (ASIC). The ASIC 161 is shown to contain various advanced functional devices, such as an analog front-end (AFE) 162, a power management (or control) circuit 164, an arithmetic processing unit 166, and a communication circuit 168 (which can be implemented as a transmitter, receiver, transceiver, passive circuit, or other device depending on the communication protocol). In this embodiment, both the AFE 162 and the arithmetic processing unit 166 are used as the analyte monitoring circuit, but in other embodiments, either one of the circuits may perform the analyte monitoring function. The arithmetic processing unit 166 may comprise one or more arithmetic processing units, miniature arithmetic processing units, controllers, microcontrollers, or various combinations thereof, each of which may be a separate chip or distributed among a number of different chips (or even among some of them).

[0027] The memory device 163 is also built into the ASIC 161 and may be shared by various functional devices within the ASIC 161, or it may be distributed among two or more functional devices. The memory device 163 may be a separate chip. The memory device 163 may be a volatile memory device, a non-volatile memory device, or a combination of both. In this embodiment, the ASIC 161 is connected to a power supply 172, which may be a coin cell battery or the like. The AFE 162 intervenes between the ASIC 161 and the in vivo analyte sensor 104 to receive measurement data from it and outputs the data in digital format to the arithmetic processing unit 166. The arithmetic processing unit then processes the data to generate discrete values ​​and trend values ​​of final glucose. This data is provided to the communication circuit 168 and can be transmitted, for example, to a reading device 120 (not shown) via the antenna 171. In this case, a resident software application needs to perform minimal further processing to display the data. In 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 each glucose value in the history can be transmitted from the sensor control device 102 to the reading device 120 every five minutes.

[0028] In some embodiments, to conserve power and computing resources of the sensor control device 102, the digital data received from the analog front end (AFE) 162 can be transmitted to the reader 120 (not shown) with minimal or no processing. Furthermore, in other embodiments, the arithmetic processing unit 166 is configured to generate a predetermined data type (e.g., current glucose value, historical glucose values) for either storage in the storage device 163 or transmission to the reader 120 (not shown), and to check for certain alarm conditions (e.g., various sensor malfunction conditions), although other processing and alarm functions (e.g., high / low glucose threshold alarms) can be performed on the reader 120. Those skilled in the art will understand that the methods, functions, and interfaces described herein can be implemented in whole or in part by the processing circuits of the sensor control device 102, the reading device 120, the local computer system 170, or the trusted computer system 180. As used herein, the term "user interface device" refers to one of the above-mentioned devices that control the interactive graphical user interface that appears on the display device, or means that one of them is included as a component.

[0029] Figure 2C is similar to Figure 2B, but instead features two separate semiconductor chips 162 and 174, which can be packaged together or separately. Here, the analog front-end (AFE) 162 resides on the ASIC 161. The arithmetic processing unit 166 integrates the power management circuit 164 and the communication circuit 168 on chip 174. The AFE 162 may include a memory device 163, and chip 174 includes a memory device 165, each memory device may be isolated or internally distributed. In one specific embodiment, the AFE 162 is combined with the power management circuit 164 and the arithmetic processing unit 166 on a single chip, while the communication circuit 168 resides on a separate chip. In yet another specific embodiment, both the AFE 162 and the communication circuit 168 reside on a single chip, while the arithmetic processing unit 166 and the power management circuit 164 reside on yet another chip. Other chip combinations are also possible; for example, a system may consist of three or more chips, each responsible for a different function as already described, or they may share one or more functions for fail-safe redundancy.

[0030] Specific Examples of Graphical User Interfaces for Analyte Monitoring Systems This specification describes specific embodiments of a graphical user interface (GUI) for a substance monitoring system. As a first point, those skilled in the art will understand that the GUI described herein includes instructions stored in the memory of the reader 120, the memory of the local computer system 170, the memory of the trusted computer system 180, or any other memory of a device or system that is part of or communicates with the substance monitoring system 100, or in the memory of any combination of the above devices or systems. When these instructions are executed by one or more arithmetic units of the reader 120, one or more arithmetic units of the local computer system 170, one or more arithmetic units of the trusted computer system 180, or one or more arithmetic units of any other device or system of the substance monitoring system, the one or more arithmetic units are caused to perform each step of the method described herein, output the GUI described herein, or both. Those skilled in the art will further recognize that the GUIs described herein may be stored as instructions in the memory of a single centralized device, or, instead, may be distributed among numerous discrete devices located in geographically dispersed locations.

[0031] The processing unit of the sensor control device 102 may be configured to receive and process sensor data at periodic intervals or in response to detected events, and to store the measured values ​​of the analyte (e.g., glucose measurements) in a local memory. In addition, the processing unit may transmit the sensor data via its wireless interface to a user interface device, such as a reader 120, a local computer system 170, or a trusted computer system 180, for example, directly or via one or more networks through intermediate nodes. In an alternative embodiment, the sensor control device may transmit data to a local receiver, such as a reader 120, using Bluetooth Low Energy (BLE) or another preferred communication protocol, which can then transfer the data to a remote computer. This is useful when the healthcare professional using the user interface device is located remotely from the patient. In each of the other embodiments, for example, in a certain clinical setting, a physician or other healthcare professional operating the user interface device may receive data directly from the sensor control device 102 via the wireless interface. In each embodiment described herein, the monitoring data includes glucose measurements taken at intervals by a sensor control device over a defined period or period.

[0032] An application running on a user interface device can acquire a patient's actual medication and glucose data during an outpatient visit. This application is intended for use by medical assistants (MAs), physicians, or other qualified healthcare professionals. For brevity, such individuals may be referred to as "users" in this specification. Patients can use any commercially available sensor control device compatible with the user interface application. The user interface application can display glucose data (e.g., ambulatory 24-hour blood glucose fluctuation, or AGP) on the user interface device and allows healthcare professionals to input medication data in relation to the patient's history. The interactive GUI application should be designed to facilitate the evaluation of the impact of past treatment changes and the adjustment of treatment recommendations by making AGP and medication history easily accessible. After the outpatient visit, the user interface application can generate a summary document to add to the patient's existing electronic medical record (EMR).

[0033] Figure 2D shows further details of the user interface device 103, in which at least one arithmetic processing unit (CPU) 204 is connected to a storage device 207, and also to a graphics processing unit (GPU) 210 and a wireless interface (WI) 208 via a bus 212 or other preferred communication path. The arithmetic processing unit 204 can send display outputs and associated instructions to the GPU 210, which generates video signals for a display device 202, such as an LED monitor or a touchscreen. If the display device 202 is configured as a touchscreen, it may also function as a data input device for receiving input from a person using the user interface displayed thereon. In other embodiments, the arithmetic processing unit 204 may be connected via a preferred interface to one or more additional input devices, such as a keyboard, microphone, or pointing device.

[0034] The storage device 207 stores one or more code modules, which, when executed by a programmer, can invoke an interactive graphical user interface as described herein. Any suitable programming language may be used to code each module, including, but not limited to, web application languages ​​such as JavaScript, PHP, or both, or languages ​​converted into executable formats such as C++. Examples of modules include one or more user interface modules (UIs) as described herein, and various other modules, such as communication modules (COMM) and authentication modules (AUTH) known in the art. When one or more modules stored in the storage device 207 are executed by at least one arithmetic processing unit 204, the user interface device 103 can perform the operation of method 300 or any variation thereof as shown in Figure 3.

[0035] Referring to Figure 3, the method 300 performed by the computer on the electronic interface of a computer (e.g., local computer system 170, reader 120, or user interface device 103) includes step 310, in which at least one arithmetic processing unit detects an identifier for a patient or a sensor device worn by the patient, or one or more of them, within the radio range of a receiver to which it is connected. As an alternative, or in addition, at least one arithmetic processing unit may receive data from the sensor device, additional medical information or patient information, or various combinations thereof, via an intermediate node or server. It should be correctly recognized that the operation of step 310 is not required to be included in all embodiments. Instead, for example, a user may manually identify the patient by data entry. When automatic detection is used, the arithmetic processing unit may, after receiving an identifier from the sensor device, selectively associate the identifier of the sensor device with a patient identifier.

[0036] Accordingly, Method 300 may include, in step 320, the reception of clinical monitoring data collected by a sensor control device over a predetermined period of time by at least one processing unit. Method 300 may further include, in step 330, the display of an interactive graphical user interface on a display device. Examples of various states of such a graphical user interface are shown in the attached drawings, which correspond to examples of screenshots or parts thereof. The graphical user interface may be accompanied by information configured to be suitable for interactive displays and one or more fields for user input. The information may include patient identification information for each patient in a patient list, a medication schedule for each patient, a treatment evaluation worksheet consisting of display content showing clinical monitoring data for each patient, further information as described herein, or various combinations thereof. Method 300 may include, in step 340, the reception of data input via an interactive graphical user interface for each patient during an outpatient visit, and in step 350, the storage of the data input in a patient history. The aforementioned operations will be further illustrated and explained in relation to the diagrams described below.

[0037] Method 300 may include one or more additional novel operations, such as those described herein, or other operations well known in the art. For example, Method 300 may include an operation for authenticating a user before allowing access to an interactive graphical user interface. Each of these additional operations is not necessarily performed in all embodiments of Method, and performing any one of these operations is not necessarily a requirement for performing any of the other additional operations.

[0038] For example, Figure 4 shows additional operations 400 to further improve the operation of the interactive graphical user interface. In step 410, method 300 may further include generating information containing a patient list configured for interactive display. Figures 5A and 5B show embodiments of the patient list in the associated screenshot copy screen 500. After authenticating the user, the processing unit can generate display content such as the screenshot copy screen 500, which is labeled "Medical Interview" as indicated by the highlighted tab 504 among the vertical index items 502. The medical interview screen 500 contains a patient list enumerating patients who were in the user interface device's storage because they had been pre-registered. In some embodiments, the processing unit may cause the medical interview screen 500 to display patient data only if the consultation has started but has not yet finished. In another aspect shown in Figure 5B, when the user types a string into the search field 506, the processing unit may use an index or otherwise to display a list of outpatient medical interviews that match the string on the screen. If a patient is not listed, the user can use an interactive graphical user interface to instruct the processing unit to add a new patient history.

[0039] In another embodiment, the processing unit can display the status of the medical interview in a column of the patient list, for example, the three rightmost columns of screen 500. In the illustrated example, the status of the processing tabs "Examination," "Medication," and "Evaluation" are shown on screen 500, which will be explained in more detail below.

[0040] Figure 5C depicts another specific embodiment of the medical interview screen 550. In some embodiments, the interface shown in screen 550 is similar to screen 500 described with respect to Figures 5A and 5B. In some embodiments, screen 550 further includes a column 552, here labeled “Libre Authentication,” to indicate the status of the blood glucose data for each row. For example, some values ​​that may be displayed in column 552 include “Libre Access Not Authenticated” (indicating that the system is not authorized to retrieve, process, display, or perform any combination of these operations on the patient’s blood glucose data), “Data Retrieving / Data Processing” (indicating that the system is retrieving or processing the blood glucose data), “Insufficient Data,” or “Chart Created.” Various other values ​​may be displayed to reflect the status of the blood glucose data, and those skilled in the art will recognize that these are entirely within the scope of the disclosure.

[0041] Figures 6A and 6B show an example of a patient information screen 600 belonging to the information tab 602 of index item 502. At least one arithmetic processing unit can display an interactive field 604, which allows the user to examine, edit, or input data in each of the indicated categories. At least one arithmetic processing unit can display a header section 608 that shows patient identification data once the patient information is saved. At least one arithmetic processing unit can display interactive navigation buttons 606 in single-line or single-array format on the display screen 600 and each display screen belonging to a different tab, for performing navigation functions known in the art (e.g., return to the previous page display screen, proceed to the next page display screen, save data, cancel data changes, etc.). If the user selects "back" or "next," the arithmetic processing unit may be configured to save the data changes, but may also be configured to revert the changes, depending on the user's choice, the application designer's choice, or both. In one embodiment, the processing unit may require the user to complete all patient information fields before allowing them to proceed to a subsequent display screen (for example, a medical examination screen or a later screen).

[0042] Figures 6C to 6E show examples of additional patient information screens. For example, in some embodiments, a patient registration screen 620 may be displayed when a patient is being registered. At least one processing unit displays interactive fields 624, which allow the user to examine, edit, or input data in each displayed category. In some embodiments, the patient registration screen 620 may include a "Create" button 626, which, when clicked, is configured to create a patient input section in the system based on the data entered in the interactive field 624. In another embodiment, once the patient input section has been created (e.g., by the "Create" button 626), at least one processing unit may be configured to display one or more blood glucose data authentication buttons (e.g., buttons 628 and 630) on the patient registration screen 620, which can be used to grant, request, or both access to the patient's blood glucose data from the system. Figure 6D shows two blood glucose data authentication buttons 628 and 630 with the text labels “Authenticate Now” and “Send Authentication Link,” but those skilled in the art will understand that other user interface objects, labels, symbols, or images may be used instead of (or in addition to) the “Authenticate Now” button 628 and the “Send Authentication Link” button 630.

[0043] Depending on the embodiment, in another aspect, once the system has authenticated access to blood glucose data, at least one processing unit may replace the patient registration screen 620 with the patient information screen 640. In some embodiments, the patient information screen 640 in Figure 6E is similar to the patient information screens 600 in Figures 6A and 6B. For example, the interactive field 604 in Figure 6A is similar to the interactive field 642 in Figure 6E. In addition, at least one processing unit may cause screen 640 and each display screen belonging to other tabs to present single-line or single-array interactive navigation buttons 646 for performing navigation functions (e.g., returning to the previous page, going to the next page, saving data, etc.). In some embodiments, the navigation buttons 646 may not include a cancel button.

[0044] Referring again to Figure 4, Method 300 may further include, in Step 420, presenting information configured for an interactive display screen that includes clinical information allowing the input of test result data in addition to clinical monitoring data, using at least one processing unit. In one embodiment of Method 300 illustrated in Step 430, the clinical information allows the input of patient biometric data separately from test result data. In another embodiment of Step 440, the test result data includes one or more of hemoglobin A1c, total cholesterol, low-density lipoprotein, high-density lipoprotein, renal function, and triglycerides. This method may further include, in Step 450, transmitting the aforementioned test result data to a display device using at least one processing unit for display together with test result data entered via an interactive graphical user interface during the most recent session.

[0045] Figures 7A and 7B further illustrate the operations described above in steps 420 to 450 with an example of a consultation screen 700 belonging to the highlighted consultation tab 702. As can be seen in Figure 7A, once all the patient data has been entered, the processing unit displays the patient identifier in the screen header. The processing unit generates a consultation screen 700 which includes section 704 containing fields for inputting and examining the patient's "biometric information" (e.g., height, weight, BMI, blood pressure (e.g., systolic and diastolic blood pressure), heart rate, and habits (e.g., frequency of drinking, physical activity, smoking frequency, etc.)) and section 706 containing fields for inputting and examining clinical test values ​​(e.g., hemoglobin A1c, total cholesterol, low-density lipoprotein, high-density lipoprotein, triglycerides, etc.) along with the associated measurement dates and times. In one embodiment, at least one processing unit may allow the user to complete the input into sections 704 and 706 separately. As can be seen in Figure 7B. In addition, the arithmetic processing unit can display the most recent but previous values ​​of the clinical test data on screen 700, as shown in section 708. For example, in a subsequent consultation, the previously entered values ​​for biological information and clinical test results can be displayed for reference. Furthermore, in some embodiments, as shown in Figures 7C and 7D, a "No recent data" checkbox 710 can be displayed next to the data in each row of section 706. In one aspect of these embodiments, selecting the "No recent data" checkbox indicates that there are no recent clinical test measurements available, and prevents the user from entering values ​​in the adjacent value and date fields. At least one arithmetic processing unit can display the values ​​in each field as they have been entered. If there are no values ​​to enter, the "No recent data" checkbox 710 will be selected.

[0046] Patient data may be manually entered by healthcare providers. Alternatively, or instead, patient data may be automatically retrieved and entered into the interface by any preferred method, for example, by electronic medical record (EMR) data and communication protocols.

[0047] Figure 8 illustrates a further additional operation 800 that may be included as part of method 300. This method may include, in step 810, allowing at least one processing unit to select medications from a list for inclusion in the medication schedule. Figure 9A shows a specific medication screen 900 corresponding to this operation, where the processing unit displays a list of diabetes medications 904 taken by the patient and a list of other medications 906. When the user enters characters into the search field 908, the processing unit can display a selectable list of matching medication names 910. The medication screen is displayed in a location belonging to the highlighted medication tab 902 of index entry 502.

[0048] Method 300 includes, in step 820 of Figure 8, if a drug is added, and in step 815, at least one processing unit determines that a dosing schedule stored in its storage device is available for that drug, the processing unit allows the user of the interactive graphical user interface to select a dosage from one or more available doses for the drug selected from the list. Figure 9B-1 illustrates a medication screen 900 that includes a typical dose or recommended available dose for the drug shown in box 908. The processing unit responds when the user selects one dose from list 914, which indicates the amount of drug the patient will receive. In addition, as can be seen in Figures 9B-2 and 9B-3, screen 900 may include a selectable frequency field 915 (e.g., having an integer value starting from 1), a selectable schedule field 916 (e.g., breakfast, lunch, dinner, bedtime, daily), or both.

[0049] If, in step 825 of Figure 8, the selected medication is a type of insulin, the method may include, in step 830, starting a medication planning module of an interactive graphical user interface that allows the user to input the number of insulin doses for one or more patient events in response to selecting an insulin drug from a list, using at least one processing unit. Figure 9C shows a specific example of a medication screen that includes a medication planning display section 918 for the insulin medication shown in step 919. For long-acting insulin such as Lantus, the medication planning field in section 918 allows the user to input values ​​for insulin doses at mealtimes and before bedtime.

[0050] In step 835 of Figure 8, if the form of insulin is short-acting, method 300 may include, only in response to the user selecting a short-acting insulin drug from the list in step 830, having at least one processing unit allow the user to select an option. The processing unit may display a list 922 of options for administering short-acting insulin, as shown in Figure 9D. These options are not displayed if long-acting insulin is entered. In the illustrated example, three options are displayed: administer a fixed mealtime dose by injection, administer a dose based on meal carbohydrate calculations by injection, and administer a single dose by insulin pump. In step 845, if the short-acting insulin is always administered at a fixed dose, method 300 may include, in response to the user selecting a fixed mealtime injection dose from the mealtime insulin administration options in step 840, having at least one processing unit launch a worksheet that allows the user to enter more detailed administration information for each of one or more patient events. For example, a worksheet launched in step 840 may allow input of the dosage, correction factor, target blood glucose level, and correction threshold for a fixed dosage. In some embodiments, the correction threshold can be automatically added after the correction factor and target blood glucose level have been entered, because the correction threshold is equal to the correction factor plus the target blood glucose level (or some other function thereof). Figure 9E shows a portion of the medication screen 900, including a more detailed worksheet 928 with additional columns for the correction factor, target blood glucose level, and correction threshold, in addition to field 926 for the total daily dose (TDD) value. The option selection for a fixed dosage is shown in 924.

[0051] If, in step 855, short-acting insulin is based on carbohydrate calculation, method 300 may further include starting a worksheet with at least one arithmetic processing unit that allows the user to input more detailed administration information for each of one or more patient events, total daily dose (TDD), and options to select empirical dosing, in response to the user selecting the option of injecting insulin by carbohydrate calculation from each of the mealtime insulin administration options in step 850. For example, the carbohydrate calculation worksheet may allow input of the insulin / carb ratio (I:C ratio), correction factor, target blood glucose level, and correction threshold. In some embodiments, the correction threshold may be automatically added after the correction factor and target blood glucose level have been entered, because the correction threshold is equal to the correction factor plus the target blood glucose level (or some other function thereof). Figure 9F shows a portion of the medication screen 900, which includes additional columns for correction coefficients, target blood glucose levels, and correction thresholds, as well as a more detailed worksheet 928 with fields 926 for the total daily dose (TDD) value and options for empirical medication. Options for carbohydrate-calculated dosages are shown in 930.

[0052] If short-acting insulin is administered by pump in step 865, method 300 may further include one or more arithmetic processing units starting a worksheet that allows the user to input time, basal metabolic rate, insulin / carb ratio (I:C ratio), correction threshold and correction factor, total daily dose (TDD), and options for selecting empirical dosing, in response to the user selecting the option of insulin pump administration from the options for mealtime insulin administration in step 860. Figure 9G shows a portion of the dosing screen 900, which includes a worksheet 934 for inputting time and correction factor, a field 926 for the total daily dose (TDD) value, and an option for empirical dosing. The selection of the pump administration option is shown in 932.

[0053] In each of the aforementioned screens, healthcare providers can manually enter medication data. In addition to this, or as an alternative, drug data may be automatically retrieved and entered into the interface by any preferred method, such as electronic medical record (EMR) data or communication protocols.

[0054] Referring to Figure 10, Method 300 may include one or more of the additional operations 1000 for treatment evaluation. The treatment evaluation section of the interactive graphical user interface allows the user to compare the current ambulatory 24-hour blood glucose fluctuation (AGP) with the AGP before the last treatment change, review the issues addressed during the last outpatient visit, review any relative changes in treatment effectiveness, and reconsider changes in medication. In step 1010, Method 300 may include at least one processing unit preparing a treatment evaluation worksheet that allows the patient's most recent ambulatory 24-hour blood glucose fluctuation (AGP) to be compared with the AGP from a period prior to the most recent treatment change for the patient. The comparison is illustrated in Figure 11A-1, where the leftmost section 1104 displays monitoring and medication data from before the last medical intervention, and the rightmost section 1106 shows the most recent data. The treatment evaluation screen 1100 is displayed belonging to the evaluation tab 1102 and secondary tab 1124 for treatment evaluation. Other available sub-tabs may include sub-tab 1122 for each event and observation results, sub-tab 1126 for medical interventions, and sub-tab 1128 for an overview of medical interventions.

[0055] In embodiments other than those described above, the evaluation 1160 and medical intervention 1162 may consist of completely separate tabs (i.e., instead of sub-tabs), as shown in Figure 11A-2. In some embodiments, the evaluation tab 1160 may have a sub-tab for treatment evaluation (not shown) and a sub-tab for events and observation records (not shown). In another embodiment, the medical intervention tab 1162 may have a sub-tab for medical intervention 1164 and a sub-tab for medical intervention summary 1166, in which case the sub-tab for medical intervention summary 1166 is displayed only after the outpatient visit has been requested to be completed (for example, by clicking the sign button 1168).

[0056] Referring again to Figure 11A-1, treatment evaluation data 1104, 1106 may include comparisons of indicators such as GMI, mean blood glucose level, standard deviation, and coefficient of variation; comparisons of blood glucose patterns in graph format 1108, 1110; a list of blood glucose patterns addressed during the most recent outpatient visit 1112; a list of current blood glucose pattern issues 1116; and medication lists 1120, 1118. Section 1120 shows recommended medication changes resulting from the treatment evaluation at the patient's most recent outpatient visit. Similarly, section 1121 may indicate any recommended self-care changes identified by previous treatment evaluations. In addition, the most recent data section 1106 may include either or both observational records and / or recommendations regarding treatment effectiveness 1114. Such observational records and recommendations1114 can be determined using algorithms and logic based, for example, on the central trend (e.g., median) and variability of blood glucose levels, the TIR value (e.g., time below 70 mg / dL, time above 180 mg / dL), or both, but most of the above are described in more detail in International Publication Nos. 2012 / 108939, 2014 / 106263, and 2014 / 145335, all of which are clearly incorporated herein by reference. The algorithms may be run on a cloud-based platform. The highlighted blood glucose pattern issues1112,1114 may include hyperglycemia or hypoglycemia periods that are determined to be the most problematic based on such algorithms. Further discussion of algorithms for displaying observational records and recommendations is presented below in relation to Figure 12.

[0057] Referring to Figure 10, step 1020 of method 300 may further include at least one processing unit initiating an Events and Observations worksheet that allows the user to select each treatment-related event, each observation record, and comorbidity in response to their selection. Figure 11B shows an example of an evaluation screen 1100 belonging to the Events and Observations sub-tab 1122. Screen 1100 includes a list of diabetes-related events and observation records in the left column 1130 and a list of the patient's comorbidities in the right column 1132. Depending on the embodiment, the list of comorbidities, their respective selections, or both may be carried over from a previous outpatient visit. The processing unit sets up an interactive graphical user interface that allows the user to select each item in both lists 1130 and 1132.

[0058] In step 1030, method 300 may further include at least one processing unit initiating a medical intervention worksheet that allows the user to select a blood glucose pattern to be addressed in conjunction with a change in treatment, in response to the user's selection. In one aspect, in section 1140, the medical intervention worksheet further allows the selection of the patient's self-care options for the purpose of influencing the blood glucose pattern to be addressed. Figure 11C shows an example of a medical intervention screen 1170, which in the illustrated embodiment belongs to the sub-tab 1126 of the medical interventions of the evaluation tab 1102. The medical intervention worksheet 1140 includes a list of user-selectable options 1142 for identifying the blood glucose pattern to be addressed, medication changes 1144, and self-care actions 1146. To the right of it, the processing unit may display results for the most recent data 1132 for easy reference. After the user has completed all input on the medical intervention screen, the processing unit may process the consultation as complete and remove the patient from the consultation list.

[0059] Depending on the embodiment, in another aspect, certain user interface functions may be displayed depending on the situation. For example, in some embodiments, as described above with respect to Figures 9A to 9D, if insulin drugs are already listed, a "Medication Plan" button 1145 may be provided in the medication change section 1144 (instead of the "Next Page" button), as shown in Figure 11C-2. The "Medication Plan" button 1145 can be set to display a medication plan (e.g., an insulin medication plan) when clicked, allowing the user to edit each input item in the medication plan. Under other circumstances, the medication change section 1144 may have an "Edit" button that allows editing of the medication list (e.g., adding, deleting, or both medications). Under other circumstances, as shown in Figure 11C-1, the button may display "Next Page" and guide the user to the self-care activity section 1146.

[0060] The processing unit may determine blood glucose patterns as described in U.S. Patent No. 9,351,670, its related applications, International Publication Nos. 2012 / 108939, 2014 / 106263, and 2014 / 145335, or both sets of documents. Each pattern is listed in section 1142 and can be set as a user-selectable association link. The medical intervention screen may be configured to help the user (e.g., a healthcare professional) identify and prioritize patterns that need to be modified in connection with changes in medication, self-care, or both. For example, screen 1170 may have user-selectable or user-inputtable fields for medication changes and self-care changes, as can be seen in sections 1144 and 1146, respectively. The processing unit stores all of these user inputs in association with the current outpatient appointment date and time. When the same user accesses the system during their next outpatient visit, the processing unit should assist the user by displaying previously addressed patterns, medication changes, and self-care changes on the evaluation screen, as shown in the aforementioned functional categories 1112, 1120, and 1121 in Figure 11A. This allows the user to evaluate how previous medical interventions affected the patient's blood glucose patterns by comparing the current outpatient data with the data from the previous outpatient visit when the medical intervention was performed. The evaluation screen 1100 assists the user in evaluating the effectiveness of previous medical interventions by reminding the user of which patterns they intended to address from the previous outpatient visit, and can similarly provide information on changes to patterns that have not yet been addressed, or can do both.

[0061] In step 1050, method 300 may further include one or more computing devices generating a medical intervention summary page that concisely summarizes the data entered into the interactive graphical user interface, the treatment evaluation, and any changes to the treatment plan, in response to user selections. Figure 11D shows an example of a medical intervention summary 1180, which in the illustrated embodiment belongs to the summary sub-tab 1128 of the evaluation tab 1102. The computing device displays the summary 1150 in a standard format suitable for input into the electronic medical record (EMR). In response to user selections, the computing device can generate the summary in electronic format and save it to the patient's file as an electronic medical record (EMR).

[0062] Figure 12 illustrates one or more additional operations 1200 for presenting human-readable observation records and recommendations in treatment evaluation, sometimes referred to as guided commentary reports (GIRs), which are included in Method 300 or a similar method for controlling an interactive user interface such as a GUI. Observation records may include time-of-day patterns, and recommendations may include medication considerations and self-care considerations, which may be prioritized by algorithms based on relationships identified between multiple blood glucose patterns at a single time of day or between blood glucose patterns at multiple time of day. More detailed examples of operations 1200 and related operations may be found in International Publication Nos. 2012 / 108939, 2014 / 106263, 2014 / 145335, or various combinations of these publications.

[0063] In step 1202, the method may further include the device's computing unit defining pre-medical intervention monitoring datasets and post-medical intervention monitoring datasets for analytical purposes. “Medical intervention” may refer to a previous outpatient visit by the patient to a healthcare professional, to which medication and monitoring data as described herein are available and updated by the healthcare professional via an interactive graphical user interface. The post-medical intervention monitoring dataset may or may include monitoring data collected after the most recent completed medical intervention. The pre-medical intervention monitoring data may be monitoring data collected before the most recent completed medical intervention, or it may include monitoring data collected since the medical intervention before the previous one. In some embodiments, the pre-medical intervention dataset may include the most recent pre-medical intervention monitoring data and data obtained over one or more older periods. In one embodiment, defining the pre-medical intervention and post-medical intervention datasets may be implicitly performed based on the state of the storage device after accessing the most recent monitoring data. Alternatively, or in addition, the device's processing unit may define a dataset based on user input.

[0064] In step 1204, the arithmetic processing unit can set one or more earliest time zone values ​​of the day based on a predetermined time or based on events detectable in the monitoring data. For example, the "after breakfast" time zone may be defined as the period from 8 a.m. to noon, or it may be defined as the time between signals or data indicating the period between breakfast and the next meal. In step 1206, the arithmetic processing unit can characterize the blood glucose pattern (GP) by analyzing the data for the selected time zone of the day. The blood glucose pattern may be one or more numerical values, a string of characters such as "high," "low," "moderately high," "moderately low," "within range," or symbolic indicators thereof. Once determined, in step 1208 the arithmetic processing unit may store the blood glucose pattern in a memory device for later use in operation 1200.

[0065] In step 1210, the processing unit checks whether there are any other time periods within the day that have not yet been analyzed. In step 1212, if there are other time periods within the day that should be analyzed, the processing unit defines the next time period and returns to step 1206. The processing unit repeats the blood glucose pattern characteristic evaluation loop (steps 1206, 1210, and 1212) for the pre-medical intervention dataset and the post-medical intervention dataset until there are no more time periods remaining to be analyzed. Then, in step 1214, the processing unit resets the time periods within the day, thereby initiating the evaluation loop for each relevant time period in the data.

[0066] In step 1216, the processing unit retrieves the pre-medical intervention blood glucose pattern (GP), and in step 1218, for example, retrieves the post-medical intervention blood glucose pattern from a storage device, where the blood glucose patterns are stored in step 1208 associated with time periods that are correlated with them. Optionally, the processing unit may determine or retrieve secondary factors that represent the influence of the blood glucose pattern on consecutive time periods. For example, for the post-lunch blood glucose pattern, the processing unit may retrieve the post-breakfast blood glucose pattern as a secondary factor. In step 1220, for the current time period of the day, the processing unit can find textual values ​​of comments, observation records, or recommendations from a quick reference table or other data structure based on the blood glucose pattern for each period, or it may selectively find textual values ​​for one or more secondary factors. For example, if the pre-medical intervention period's blood glucose pattern points to a row and the post-medical intervention period's blood glucose pattern points to a column, the processing unit may find the textual value stored in the history indicated by the intersection of the row and column. When using secondary factors, each factor may be used to define another dimension of the data table. Therefore, in step 1220, the processing unit selects textual values ​​that are optimal for a unique combination of at least one 24-hour period, one pre-medical intervention blood glucose pattern, and one post-medical intervention blood glucose pattern. In step 1222, the unique combinations described above, along with the associated textual values ​​defined in step 1220, may be stored in a memory device in step 1224 for later use in the graphical user interface.

[0067] In step 1226, the processing unit determines whether the evaluation loop (steps 1216 to 1228) has finished. If it has not finished, the processing unit selects the next time period in step 1228 and returns to step 1216. If it has finished, in step 1230, the processing unit ranks the documents or subsets of documents stored in the memory in step 1224 according to a priority scheme. Any priority scheme may be used if desired, for example, a scheme based on a predefined risk or priority score for each document sequence, or a scheme based on a unique combination of each associated factor. In step 1232, the processing unit selectively assigns the associated factors to the document sequences or their high-priority subsets and outputs them via an interactive graphical user interface for use in the current medical intervention. For example, screen 1100, which uses the screenshot function in Figure 11A-1, shows the selected and prioritized text sequences in section 1114, and the associated blood glucose level patterns and time periods of the day in section 1112.

[0068] Figure 13A illustrates various patterns and evaluations for diabetes treatment, including evaluation details. Table 1300 illustrates some specific results using the evaluation logic used to determine the recommendations displayed to the user. Reading from left to right, the first two columns show examples of input conditions for arriving at a classification evaluation, such as that shown in the third column. More specifically, the first column shows the time of day for prominent blood glucose patterns detected over a multi-day monitoring period, and the second column shows the patterns observed at the indicated time. The third column shows a status evaluation based on comparing the blood glucose pattern detected in the most recent monitoring period with the blood glucose pattern from one or more previous periods, e.g., the period immediately preceding the most recent. The fourth column, with the heading "Details," shows a predetermined example of text that, when displayed, can be retrieved from memory based on the selection algorithm described above, such as section 1114 in Figure 11A.

[0069] At least one arithmetic processing unit of the device may perform additional operations 1310, as shown in Figure 13B, to execute evaluation logic that generates text such as that shown in Figure 13A. Such logic can be represented by a data table or an equivalent data structure, the data table relating blood glucose patterns for each time period of the day (TOD) to the displayed text based on a set of intervening input conditions. The data table may be used once for each time period of the day (after breakfast, after lunch, after dinner, and at night). By utilizing each input column of the data table, each row in the table that corresponds to a uniquely determined set of inputs can be identified. For example, the first column can identify a period of time within a day to which a specific row is related; the second column can identify the blood glucose pattern from previous outpatient visits, also known as the pre-medical intervention pattern; the third column can identify the blood glucose pattern from the current outpatient visit (also known as the post-medical intervention pattern); the fourth column can compare the TIR value (times when blood glucose levels are below 70 mg / dL, such as TB70, or time when TA180, or time when TA is above 180 mg / dL) after medical intervention with that before medical intervention; and the fifth column can identify a specific sentence.

[0070] An additional operation (algorithm) 1310 may include step 1312, which identifies a period of time within a day (TOD) for evaluation purposes. In step 1314, the processing unit may receive various input parameters for this time period, which include at least a pre-medical intervention pattern and a post-medical intervention pattern. In step 1316, the processing unit may select one or more history entries that match the above input parameters, for example, it may select one or more rows that match the input combination of time within a day, a pre-medical intervention pattern, and a post-medical intervention pattern. In step 1316, the processing unit may determine whether the number of selected history entries (e.g., rows) is greater than one (i.e., whether the history is uniquely determined). If the history is uniquely determined, in step 1320, the processing unit may select text for display in the selected rows or selected history entries.

[0071] For some of the multiple time periods (TOD) within a single day, the combination of the second and third columns may not be unique; that is, the same combination may occur in two or more rows of the data table. In such cases, an additional column, a "fourth" column, can be used as input to select rows that are ultimately uniquely determined. The fourth column can represent the relationship between pre-medical intervention patterns and post-medical intervention patterns, for example, whether the pre-medical intervention index is smaller, larger, or equal to the post-medical intervention index. The index calculation should preferably be based on blood glucose data used to determine the blood glucose pattern. Therefore, in step 1322, the processing unit may compare this index for pre-medical intervention and post-medical intervention periods, and then in step 1324, select rows or history that satisfy the comparison index.

[0072] For example, the indicator may be the percentage of time when blood glucose levels are below a threshold (e.g., 70 mg / dL), or it may include part of that. Similarly, during periods of hyperglycemia, the indicator may be the percentage of time when blood glucose levels are above a threshold (e.g., 180 mg / dL), or it may include part of that. The processing unit may detect "no change" or "equal" if both indicators are within a specified range, for example, if the difference does not exceed 5%. Similarly, in determining whether a value is "above" or "below," the processing unit may apply a threshold if the correlation requirement is that the difference exceeds a threshold.

[0073] In step 1320, the arithmetic processor can use a unique combination of various input parameters to select a corresponding unique row containing the output text that will be displayed in step 1326. Some examples of this text may be accompanied by further modifiable text determined by metric calculations. For example, if {metric text} is shown, the arithmetic processor may calculate the difference between each metric used in the fourth column, or it may calculate the absolute value of the metric change between the current outpatient visit and the previous outpatient visit. The device may display values ​​in step 1326 in units of percentages % (or time), along with the remainder of the text, as shown in each example. In step 1328, the arithmetic processor may determine whether there is an additional 1-day time period (TOD) remaining to be evaluated. If operation 1310 is not completed, in step 1330, the arithmetic processor selects the next TOD period and returns to step 1314 for the newly selected period. If this process is completed, the arithmetic processor returns to the routine that called evaluation logic operation 1310.

[0074] In each of the alternative embodiments, the data table may include one or more further outputs that further subdivide the evaluations, for example, to highlight the “improvement” evaluation by coloring the displayed text green.

[0075] In another embodiment, the processing unit may determine the order in which evaluation sentences are displayed. For example, the data table may prepare evaluation sentences for display, one for each time period of the day (TOD), for example, up to four. The processing unit can define the display order in the order shown in each column. For example, the processing unit may display sentences associated with the "low" pattern before sentences associated with other patterns. As a further example, within a single pattern, the processing unit may display sentences associated with TODs that begin with the nighttime period, and then arrange each subsequent period in the order of the normal time period sequence.

[0076] The example texts and evaluation logic illustrated and explained in relation to Figures 13A and 13B are not limited to those. Any text can be created and stored in memory, as long as it is suitable for selection and display on a graphical user interface, and the evaluation logic can be adapted to the text and intended use cases.

[0077] Figure 14 is a conceptual block diagram illustrating the components of an apparatus or system 1400 for providing an interactive graphical user interface as described herein, according to one embodiment. As shown in the figure, the apparatus or system 1400 may consist of functional blocks representing functions implemented by a processing unit, software, or a combination thereof (e.g., firmware).

[0078] The device or system 1400 may further include an electrical component 1402 for receiving sensor control data collected by a sensor control device over a continuous period of time. Component 1402 may be a means for receiving data as described above, or may include such means as part of the device. The means may include a storage device 1416 and an arithmetic processing unit 1410 connected to a wireless interface 1414, which executes an algorithm based on program instructions stored in the storage device. Such an algorithm may include a series of more detailed operations, such as establishing a wireless session with a sensor control device worn by the patient, requesting data from a monitoring device, and receiving monitoring data from the device, or, instead of the above example, sending a patient identifier to a server (not a monitoring device) in conjunction with a data request, and receiving monitoring data from the server.

[0079] The device or system 1400 may further include an electrical component 1404 to provide an interactive graphical user interface accompanied by information configured for interactive display and input, such information including patient identification information for each patient in a patient list, a medication schedule for each patient, and a treatment evaluation worksheet that includes a display showing patient-specific medical monitoring data. Component 1404 may be a means of providing the interface as described above, or may include such means as part of the interface. Such means may include an arithmetic processing unit 1410 connected to a storage device 1416 and an input device 1414, the arithmetic processing unit executing an algorithm based on program instructions stored in the storage device. Such an algorithm may include a series of more detailed operations, such as authenticating the user, determining the session state, generating an interactive data object based on the session state, and sending the data object to a graphics processing unit for rendering and output. In some embodiments, the electrical component 1404 may be a standalone component or such device. In other embodiments, the electrical component 1404 may be an embedded screen of the Mass Data Processing Framework (EMR), but for example, hybrid optical fiber coaxial cable (HFC) wiring is provided so that the electrical component 1404 and one or more of its corresponding functions can be accessed from inside the EMR.

[0080] The device or system 1400 may further include an electrical component 1406 for receiving data inputs from each patient during an outpatient consultation via an interactive graphical user interface and storing them in a history. Component 1406 may be a means for receiving and storing data inputs as described above, or may include such means in part. Such means may include a storage device 1416 and an arithmetic processing unit 1410 connected to a wireless interface 1414, the arithmetic processing unit executing an algorithm based on program instructions stored in the storage device. Such an algorithm may include a series of more detailed operations, such as defining interface objects in relation to variables, invoking interface object emphasis functions in response to user input, associating inputs from the emphasized objects with variables assigned to those objects, creating a history of each received variable, and transmitting this history to a computer storage device for storage.

[0081] In the case of a device 1400 configured as a data processing device, the device 1400 may optionally include an arithmetic processing module 1410 equipped with at least one arithmetic processing unit. In such a case, the arithmetic processing unit 1410 can effectively communicate with modules 1402 to 1406 via bus 1412 or other communication channels, such as a network. The arithmetic processing unit 1410 can act on the initiation and scheduling of various processes or functions performed by electrical components 1402 to 1406.

[0082] In a relevant embodiment, the device 1400 may also include a wireless interface module 1414 that can operate to communicate with a sensor control device worn on the patient's body. In a further relevant embodiment, the device 1400 may selectively include modules for storing information, such as a storage device 1416 or a module thereof. A computer-readable medium or storage device module 1416 can be operably connected to other components of the device 1400 via a bus 1412, etc. The storage device module 1416 may be configured to store computer-readable instructions and data for enabling various processes and behaviors of modules 1402 to 1406 and their subcomponents, or of the arithmetic processing unit 1410, or for enabling one or more of the additional operations 400, 800, 1000, 1200, 1310 already described in connection with method 300 and that method. The storage device module 1416 may hold instructions for performing functions associated with modules 1402 to 1406. Although they are shown as being outside the storage device 1416, it should be understood that modules 1402 and 1406 may be built into the storage device 1416.

[0083] The logic processes, modules, circuits, and algorithmic stages of the various specific examples described in relation to each aspect of this disclosure can be implemented as electronic hardware, computer software, or various combinations of both. To clearly demonstrate this interchangeability between hardware and software, the components, process blocks, modules, circuits, and process stages of the various specific examples have been broadly described in relation to their respective functions. Whether such functions are implemented as hardware or software depends on the application and design constraints imposed on the overall system. A person skilled in the art will presume that the functions described will be implemented in various ways depending on the application, but such implementation decisions should not be interpreted as deviating from the scope of this disclosure.

[0084] As used in this application, terms such as “component,” “module,” and “system” are intended to refer to computer-related entities, whether hardware, a combination of hardware and software, software, or running software. For example, a component may be, but is not limited to, a process running on an arithmetic processing unit, an arithmetic processing unit, an object, an executable file, an execution thread, a program, a computer, or a system consisting of multiple collaborating computers, or any combination thereof. For example, both an application running on a server and the server may be components. One or more components may reside within a process, within an execution thread, or both, and a component may be localized on one computer, distributed across two or more computers, or both localized and distributed.

[0085] Program instructions can be written in any suitable high-level language, such as C, C++, C#, JavaScript, or Java (trademark), and should be compilable to generate executable machine code for the arithmetic unit. Program instructions can be divided into multiple functional modules to improve coding efficiency and ease of understanding. Such modules, even if they are recognized as separate parts or categorized in the source code, should be understood as not necessarily distinguishable as distinct code blocks at the machine level. A code bundle for a particular function may be considered to constitute a single module, regardless of whether the machine code on the bundle can be executed independently of other machine code. In other words, each module may be a higher-level module only.

[0086] This document presents various embodiments of systems that can be composed of numerous components and modules. It should be understood and correctly recognized that diverse systems may include additional components and modules, that they may not possess all of the components and modules described in relation to the drawings, and that both may be true. These various approaches may be used in combination. The various embodiments disclosed herein can be implemented in various electrical devices, including devices utilizing touchscreen display technology, mouse and keyboard interfaces, or both. Examples of such devices include computers (desktop and mobile), smartphones, personal digital assistants (PDAs), and various other electronic devices, both wireless and wired.

[0087] In addition, the logic processes, modules, circuits, etc., of the various specific examples described in relation to each aspect disclosed herein are implemented or performed using the following: general-purpose arithmetic processors, digital signal arithmetic processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic circuits, discrete hardware components, or any combination of the above designed to perform the functions described herein. The general-purpose arithmetic processor may be a miniature arithmetic processor, but instead, the arithmetic processor may be any conventional arithmetic processor, controller, microcontroller, or state machine. The arithmetic processor may be implemented as some kind of combination of various computer devices, for example, a combination of a DSP and a miniature arithmetic processor, multiple microprocessors, one or more miniature arithmetic processors working with a DSP core, or any other configuration as described above. As used herein, “arithmetic processor” encompasses any one or functional combination of the above examples.

[0088] The modes of operation of the disclosed herein may be implemented directly in hardware, in a software module executed by an arithmetic processing unit, or in a combination of both. The software module may reside on a storage medium known in the art, such as a RAM, flash memory, ROM, EPROM, EEPROM, various registers, a hard disk, a removable disk, a CD-ROM, or any other storage medium. In the specific example, the storage medium is connected to the arithmetic processing unit so that the arithmetic processing unit can read information from and write information to the storage medium. Alternatively, the storage medium may be integrated with the arithmetic processing unit. The arithmetic processing unit and the storage medium may reside in an ASIC. The ASIC may reside in a user terminal. Alternatively, the arithmetic processing unit and the storage medium may reside as discrete components within a user terminal.

[0089] Furthermore, one or more versions may be implemented as a method, apparatus, or product that utilizes standard programming techniques, engineering techniques, or both to generate software, firmware, hardware, or any combination thereof, to control a computer to realize each aspect of the disclosure. Persistent, computer-readable media include magnetic storage devices (e.g., hard disks, floppy disks, magnetic strips, etc.), optical discs (e.g., compact discs, i.e., CDs, digital multipurpose discs, i.e., DVDs, Blu-rays, etc.) TM Examples include, but are not limited to, smart cards, solid-state devices (i.e., SSDs), and flash memory devices (e.g., card-type, stick-type, etc.). Of course, those skilled in the art will recognize that many modifications can be made to this configuration without departing from the scope of each disclosed embodiment.

[0090] Considering each of the specific systems described above, numerous ways in which the disclosed subject matter can be implemented have been explained with reference to several flowcharts. For the sake of simplicity, these methods have been illustrated and explained as a series of blocks, but the claimed subject matter is not limited to the order of these blocks, for some blocks may occur in a different order than that depicted and explained herein, may occur simultaneously with other blocks, or both may occur. Furthermore, not all of the illustrated blocks are requirements for implementing each of the methods described herein. In addition, it should be understood that each of the methods disclosed herein can be stored in a product that allows them to be easily transferred and transmitted to a computer.

[0091] Non-limiting embodiments are illustrated in more detail in the following numbered sections.

[0092] Example 1 A method for providing human-readable observation records and recommendations for therapeutic evaluation of an interactive user interface of a computer device, wherein the method is: To receive medical monitoring data collected by a sensor control device over a predetermined period of time. To define separate datasets of clinical monitoring data for pre- and post-medical intervention for evaluation purposes. The blood glucose level pattern is determined for each time period of the day in the corresponding separate datasets before and after medical intervention. To determine text to be displayed in the interactive user interface based at least partially on blood glucose patterns for each time period of the day corresponding to the blood glucose pattern, and, This includes providing text for output via the aforementioned interactive user interface.

[0093] Example 2 The method of Embodiment 1, wherein the at least one processing unit, in determining the text, utilizes a data structure for the purpose of finding a predetermined value labeled by at least two separate indicators of the blood glucose level pattern for each period of time within a day corresponding to the blood glucose level pattern.

[0094] Example 3 The method of Embodiment 1 or Embodiment 2, wherein the at least one arithmetic processing unit further determines the text based on the index for each period of time within a day that corresponds to an index for time within a day.

[0095] Example 4 The method of Example 2 or Example 3, wherein the at least one processing unit further determines the text based on the index for at least one contiguous period before and after each period of time in the day that corresponds to at least one additional blood glucose pattern index.

[0096] Example 5 The method of any two embodiments 2 to 4 further includes providing a signal to the at least one arithmetic processing unit for displaying the text on a display device using the interactive user interface.

[0097] Example 6 Defining the dataset before and after the medical intervention is performed implicitly based on the state of the storage device after accessing the latest monitoring data, as in any of the methods of Examples 1 to 5.

[0098] Example 7 The method of any of Examples 1 to 6, wherein defining the dataset before and after the medical intervention is based on user input via the interactive user interface.

[0099] Example 8 A method according to any one of Examples 1 to 7, further comprising analyzing medical monitoring data using at least one processing unit, with each period of the day defined based on data characteristics indicating one or more meal events.

[0100] Example 9 The aforementioned blood glucose pattern index consists of an index with a higher value and an index with a lower value, according to any of the methods in Examples 1 to 8.

[0101] Example 10 A method according to any one of Examples 1 to 9, further comprising ranking multiple sentences for various time periods of a day in order toward the output by the at least one processing unit.

[0102] Example 11 Any method of Examples 1 to 10 further includes displaying a series of texts on a user interface device along with the associated blood glucose patterns and time periods of the day.

[0103] Example 12 A method according to any one of Examples 1 to 11, further comprising determining a first blood glucose pattern by processing a dataset before the medical intervention, and separately determining a second blood glucose pattern by processing a dataset after the medical intervention.

[0104] Example 13 A method according to any one of Examples 1 to 12, further comprising processing the data set before the medical intervention according to a first processing method and processing the data set after the medical intervention according to a second processing method.

[0105] Example 14 A method according to any one of Examples 1 to 13, further comprising automatically defining a pre-medical intervention dataset and a post-medical intervention dataset based on identifying a predetermined pattern in the medical monitoring data.

[0106] Example 15 A method according to any one of Examples 1 to 14, further comprising: analyzing a dataset before the medical intervention for the purpose of identifying a first blood glucose pattern or a first blood glucose event based on a first set of predetermined patterns; and analyzing a dataset after the medical intervention for the purpose of identifying a second blood glucose pattern or a second blood glucose event based on a second set of predetermined patterns.

[0107] Example 16 A device for providing human-readable observation records and recommendations for therapeutic evaluation of an interactive user interface comprises at least one arithmetic processing unit connected to a computer storage device and a wireless interface for receiving data from a sensor control device worn by a patient, wherein the storage device holds program instructions that, when executed by the at least one arithmetic processing unit, cause the device to perform each of the operations described in Examples 1 to 15.

[0108] Example 17 The persistent storage medium, which is readable by a computer, holds program instructions that, when executed by the arithmetic processing unit, cause the device to perform any of the operations described in Examples 1 to 15.

[0109] Example 18 The apparatus is equipped with means for performing each of the operations described in any of Examples 1 to 15.

[0110] In summary, the interactive graphical user interface includes information configured for interactive display and input, including a treatment evaluation worksheet that partially displays patient identification information, medication schedules, and medical monitoring data for each patient in a patient list. This worksheet allows for the comparison of monitoring results over various time periods and enables the development of treatment plans.

[0111] It should be noted that all features, elements, components, functions, and processes described in relation to any embodiment presented herein are intended to be freely combined with or substituted for any other embodiment. Even if a feature, element, component, function, or process is described in relation to only one embodiment, it should be understood that that feature, element, component, function, or process can be used in all other embodiments described herein unless explicitly stated otherwise. Thus, this paragraph serves as a prerequisite and written support for introducing the claims, but the claims can always be combined with features, elements, components, functions, and processes from various embodiments, or substitute features, elements, components, functions, and processes from one embodiment with those from another embodiment, even if the subsequent description does not explicitly state that such combinations or substitutions are possible in special cases. Accordingly, the foregoing descriptions of specific embodiments of the disclosed subject matter are presented for illustrative and explanatory purposes only. In particular, given that it is readily apparent to those skilled in the art that all possible combinations and substitutions are permitted, it is clear that there is agreement that explicitly listing all possible combinations and substitutions would be excessively cumbersome.

[0112] Each embodiment is subject to various modifications and alternative forms, specific examples of which are shown in the drawings and described in detail herein. It will be apparent to those skilled in the art that various modifications and changes can be made to the methods and systems of the disclosed subject matter without departing from the essence or scope of the disclosed subject matter. Accordingly, the disclosed subject matter is intended to include modifications and variations that fall within the scope of the appended claims and their equivalents. Furthermore, any features, functions, processes, or elements of each embodiment, as well as any negative limitations that define the scope of the claimed invention by features, functions, processes, or elements not included in the claims, are enumerated or appended to the claims. [Explanation of Symbols]

[0113] 100 Analyzed Substance Monitoring System 102 Sensor control device 104 Sensor for analyzing the material 120 Reader 160 Sensors and Electronic Equipment 170 Local Computer Systems 180 Trusted Computer Systems 207 Storage Devices and Various Modules 1100 Graphical User Interface Display Screen

Claims

1. A method for providing human-readable observation records and recommendations to the therapeutic evaluation of an interactive user interface of a computer device, wherein at least one computing device provides these observation records and recommendations. A step of receiving medical monitoring data collected by a sensor control device over a predetermined period of time using at least one processing unit, A step of defining separate datasets of medical monitoring data, one before and one after medical intervention, using the aforementioned processing unit, for the purpose of evaluation. A step of determining a blood glucose pattern for each time period of day in separate datasets before and after medical intervention, using at least one processing unit, wherein the blood glucose pattern is generated using statistical aggregate values ​​performed by the processing unit on stored measurements assigned to the same time period of day among multiple monitoring days, and includes at least one of a high pattern and a low pattern. A step of determining, using at least one processing unit, text to be displayed in an interactive user interface based at least partially on blood glucose patterns for each time period of the day corresponding to the blood glucose pattern, and The process of providing output text via the interactive user interface on a display screen associated with a computer device that the patient is facing. A method that includes this.

2. The method according to claim 1, wherein the at least one processing unit, in determining the text, utilizes a data structure for the purpose of searching for a predetermined value labeled by at least two distinct indicators of the blood glucose level pattern for each period of time within a day corresponding to the blood glucose level pattern.

3. The method according to claim 1, wherein the at least one arithmetic processing unit further determines the text based on the index for each period of time in a day that corresponds to an index of time in a day.

4. The method according to claim 2, wherein the at least one processing unit further determines the text based on the at least one additional blood glucose pattern index for at least one contiguous period before and after each period of time in the daytime that corresponds to at least one additional blood glucose pattern index.

5. The method according to claim 2, further comprising the step of providing a signal to the at least one arithmetic processing unit for displaying the text on a display device using the interactive user interface.

6. The method according to claim 1, wherein the step of defining the pre-medical intervention dataset and the post-medical intervention dataset is implicitly performed based on the state of the storage device after accessing the latest monitoring data, and / or based on user input through the interactive user interface.

7. The method according to claim 1, further comprising the step of analyzing the medical monitoring data using at least one processing unit, with each period of time within the day defined based on data characteristics indicating one or more meal events.

8. The method according to claim 1, wherein the indicator of the blood glucose level pattern consists of an indicator with a higher value and an indicator with a lower value.

9. The method according to claim 1, further comprising the step of ranking multiple sentences for various time periods of a day in order toward the output using the at least one arithmetic processing unit.

10. The method according to claim 1, further comprising the step of displaying a series of sentences on a user interface device together with the associated blood glucose patterns and time periods of the day.

11. The method according to claim 1, further comprising the steps of determining a first blood glucose pattern by processing a dataset before the medical intervention, and separately determining a second blood glucose pattern by processing a dataset after the medical intervention.

12. The method according to claim 1, further comprising the steps of processing a dataset before medical intervention according to a first processing method, and processing a dataset after medical intervention according to a second processing method.

13. The method according to claim 1, further comprising the step of automatically defining a pre-medical intervention dataset and a post-medical intervention dataset based on identifying a predetermined pattern in the medical monitoring data.

14. The method according to claim 1, further comprising: analyzing a dataset before medical intervention for the purpose of identifying a first blood glucose pattern or a first blood glucose event based on a first set of predetermined patterns; and analyzing a dataset after medical intervention for the purpose of identifying a second blood glucose pattern or a second blood glucose event based on a second set of predetermined patterns.

15. A device for providing human-readable observation records and recommendations for therapeutic evaluation of an interactive user interface, comprising at least one arithmetic processing unit connected to a computer storage device and a wireless interface for receiving data from a sensor control device worn by a patient, wherein the storage device holds program instructions that, when executed by the at least one arithmetic processing unit, cause the device to perform each of the steps described in claim 1, and selectively cause one or more of the steps described in claims 2 to 14.

16. A persistent storage medium readable by a computer, which holds program instructions that, when executed by an arithmetic processing unit, cause the device to perform one or more of the steps described in claims 1 to 14, and selectively cause one or more of the steps described in claims 2 to 14.

17. An apparatus comprising means for performing one or more steps according to claims 1 to 14, and selectively performing one or more steps according to claims 2 to 14.

18. A step of displaying an interactive field in which the user can examine, edit, or input data for each of the indicated categories, and The method according to claim 1, further comprising the step of requiring the user to complete all patient information fields before allowing them to proceed to a subsequent display screen.

Images