EA040777B1 - SYSTEM AND METHOD FOR REMOTE ADMINISTRATION OF MEDICINAL DOSING SCHEMES - Google Patents

Description

Field of invention

The present invention relates to medical devices and medical information systems and, in particular, to systems and methods for remotely administering drug dosing regimens.

State of the art

There are many diseases and medical indications for which patients receive medical treatment. Quite often, such treatment includes one or more dosing regimens for one or more drugs.

Short description

Disclosed herein are systems and methods for remote administration of drug dosage regimens. The present systems and methods are applicable to numerous types of drugs for many types of diseases and other medical indications. Patients who are treated for such medical indications are treated by professionals referred to in the present invention as healthcare professionals (HCPs). For the purposes of this document, NRS includes both people and organizations that directly provide medical care to patients (for example, physicians, nurses, PAs, physician assistants, paramedics, and similar professionals), as well as people and/or organizations that provide medical care to patients. who do not directly provide medical care to patients, but who indirectly assist in the provision of medical care to patients (for example, administrative personnel, database administration personnel, personnel involved in other information technology, insurance-related personnel, and / or personnel, related to other payments, as well as similar personnel). In the situations described in this document, when the HCP prescribes a dosing regimen and/or other treatment for which the prescription is required, it is assumed that the HCP has the appropriate education, training, certification, license and/or the like, which is required for to make such appointments. Examples of drugs covered by these drug regimens include one or more therapeutic agents, which include, but are not limited to, insulins, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agents that can be administered via a drug delivery device or that a patient can take without the help of a drug delivery device (eg, orally or by application to the patient's skin). One or more excipients may be present in the finished mixture of medicinal products.

One example of the scope of the present systems and methods is diabetes (which is sometimes also referred to as diabetes mellitus), which is a general term for a group of metabolic disorders, usually characterized by elevated levels of glucose (for example, blood glucose, or blood sugar) in the human body in over extended periods of time. As is known in the art and in the medical community, another term for elevated glucose levels is hyperglycemia, which is usually defined as a glucose level of more than 180 milligrams per deciliter (mg/dL), the threshold value of which is also expressed as an amount of 10 millimoles per liter (mmol/dL). l). The reverse indication (ie, insufficient glucose) is known as hypoglycemia, which is usually defined as a glucose level equal to or less than 70 mg/dL (3.9 mmol/L).

There are two main types of diabetes, known as type 1 and type 2 diabetes, each associated differently with insulin, a hormone that plays a central role in the body's metabolic conversion of glucose into energy that is either immediately used or stored for later use. Type 1 diabetes is generally considered an autoimmune disease in which the patient's immune system mistakenly aggressively attacks the insulin-producing β-cells in the pancreas. Type 2 diabetes is usually characterized by the inability of the pancreas to produce enough insulin for the body's needs, or by the patient's body becoming unable to respond to insulin.

Among the treatments for type 1 and/or type 2 diabetes is the subcutaneous injection of synthetic insulin. In general, synthetic insulins are classified according to a number of parameters, which include onset of action (i.e. how quickly they usually begin to work), peak value (i.e. how long it usually takes before maximum effectiveness is reached), duration (i.e. . amount of time the effect usually lasts) and concentration. A typical way of expressing concentration is in terms of units per milliliter (mL); for example, a concentration of 100 units per ml is usually expressed as U100.

In the case of type 1 and/or type 2 diabetes, there are two main categories of synthetic insulin that HCP is commonly prescribed, usually by subcutaneous injection: basal insulin and bolus insulin. Basal insulin is also known by a number of other terms, such as background insulin and long-acting insulin, and is usually taken once or twice by diabetic patients.

- 1 040777 per day at regular intervals and in agreed dosages in order to maintain a certain initial level of insulin in the patient during such periods of time as fasting, sleep, time between meals, etc. Bolus insulin also has a number of names by which it is known, which include prandial insulin, dietary insulin, and rapid-acting insulin, and is typically taken by diabetic patients as needed, most often with meals, to cope with spikes in levels. glucose, which are typical during meals but can occur at other times. While the present methods and systems are certainly applicable to numerous types of drugs for many types of diseases, indications, and the like, they are intended, at least in part, to assist HCPs and patients with type 1 or type 2 diabetes in establishing and managing regimens. treatment (sometimes intensive) with basal insulin and/or bolus insulin. Indeed, while some of the examples of the present invention generally relate to the administration and use of bolus insulin dosing regimens for diabetic patients, it should be understood that this is by way of illustration and not limitation, and in no way excludes that the present systems and methods are in accordance with dosing regimens. other types of insulin (eg basal insulin) and/or for other types of diseases. In general, as noted above, it should be understood that the present systems and methods are applicable to a wide range of drug dosing regimens for a wide range of diseases, indications, and the like. The inventors of the present systems and methods recognize that managing and managing insulin therapy with multiple components can be challenging, both on the part of the HCP, but especially on the part of the patient. The present systems and methods solve a number of technical problems associated with the prior art, which include the technical problem that prior implementations of medical devices and medical technology in general do not provide a mechanism by which the HCP can select and even adapt to at least one dosing regimen (for example, a bolus insulin dosing regimen) from a number of predetermined and preprogrammed dosing regimens for a particular patient, and then additionally assign this at least one treatment regimen to that patient over the network data transmission by remote interaction using an application program running on a mobile device associated with the patient. In accordance with some embodiments of the present systems and methods, the logic portion for a number of predefined and programmed drug dosing patterns may be provided by an application running on a patient's mobile device, but may be initially disabled to be inaccessible to the patient. In addition, in accordance with some embodiments of the invention, the HCP may remotely unlock at least one specific treatment regimen selected by the HCP from a number of pre-programmed drug dosing regimens for that patient on that mobile device, which may then provide the patient with instructions to implement at least at least one treatment regimen, and in some cases, control one or more additional medical devices (which is or which are also associated with the patient) to perform some or all of at least one drug dosage regimen selected by the HCP. The present systems and methods provide a technical solution to at least this technical problem. And it should be tactfully noted that this paragraph in no way implies that the present invention does not provide other technical solutions to other technical problems.

One embodiment of the invention is a method that includes presenting, using the HCP portal application running on the HCP system, a number of drug dosage regimens that are appropriate for the patient. Each presented drug dosing regimen is associated with a corresponding, different drug dosing algorithm. The method also includes obtaining, by means of the HCP Portal user application, the selection of the HCP at least one of the presented drug dosing regimens. The method also includes transmitting to a medical mobile application (MMA) on a mobile device associated with the patient, data on the selected HCP treatment regimen, indicating at least one selected HCP drug dosing regimen.

Another embodiment of the invention is a Connected-care health information server system that includes one or more servers, each of which includes one or more information exchange interfaces, one or more processors, and a storage device. In at least some embodiments, the Connected-care Server-Based Health Information Exchange is a Connected-care-cloud (C3) Server-Based Health Information Exchange (C3), and each of the one or more servers is a cloud server. The storage device of one or more servers collectively contains instructions that, when executed by one or more processors of one or more servers, cause the Connected-care health information exchange server system to perform a set of server system functions that

- 2 040777 include the features listed in the previous paragraph. Another embodiment of the invention is one or more non-volatile computer-readable media (CRM) that store instructions that, when executed by one or more processors, are capable of causing one or more processors to perform a set of functions that includes includes the functions listed in the previous paragraph. In conjunction with any embodiment of the invention, the CRM may be any non-volatile storage media referred to herein and/or any other non-volatile storage media that those skilled in the art deem appropriate for the implementation. Examples include any suitable form of storage device (which includes both volatile and non-volatile storage device), magnetic disk storage device, optical information storage device, and/or the like.

Another embodiment of the invention is a method that includes obtaining in the MMA, which is executed on a mobile device associated with the patient, data about the selected HCP treatment regimen, which is an indication that the HCP has made a choice of drug dosing regimen from some the number of drug dosing regimens, each of which is associated with a corresponding, different drug dosing algorithm. The selection of the HRS for the patient was made by the HRS using the HRS Portal application that runs on the HRS system. The method also includes unlocking said HCP-selected dosing regimen for MMA responsive at least in part to receiving data on the HCP-selected treatment regimen.

Another embodiment of the invention is a mobile device associated with a patient. The mobile device includes a mobile device communication interface, a mobile device processor, and a mobile device storage device. The storage device of the mobile device contains instructions that, when executed by the processor of the mobile device, cause the mobile device to execute MMA in order to perform a set of MMA functions that includes the functions listed in the previous paragraph. Another embodiment of the invention is one or more non-volatile CRMs that store instructions that, when executed by one or more processors, are capable of causing one or more processors to execute a set of functions that includes the functions listed in the previous paragraphs. Yet another embodiment of the invention is a system that includes the Connected-care health information server system described above and the mobile device described above. At least one embodiment of the invention further includes the HCP system described above.

Another embodiment of the invention is a method that includes simultaneously presenting, by means of a processor of a mobile device associated with a patient, a number of panels on a visual display of the mobile device, wherein the number of panels includes a first panel that displays the number of units of insulin. administered to the patient and a second panel showing the amount of carbohydrate expected to be provided by the number of units of insulin displayed on the first panel; receiving on the mobile device a user input representing the requested adjustment to the number of units of insulin displayed in the first panel; and updating, by the processor, each panel of the number of panels according to the requested adjustment to the number of insulin units displayed on the first panel, the update including displaying the adjusted number of units of insulin on the first panel and the adjusted amount of carbohydrates that are expected to be provided with an adjusted number of units of insulin, in the second panel.

In some embodiments of the invention, a number of panels may further comprise a panel that displays an indication of the size of a single meal corresponding to the amount of carbohydrates displayed by the second panel, and wherein the update includes displaying an indication of an adjusted single meal corresponding to the adjusted amount of carbohydrates. Alternatively, or in addition to this, a number of panels may further comprise a panel that shows a spectrum representing the size range of a meal from a small meal to a large meal, and an indicator that indicates where the amount of carbohydrates displayed by the second bar , falls into the spectrum. Alternatively, or in addition to this, a number of panels may further comprise a panel that indicates whether the carbohydrate amount displayed by the second panel corresponds to a small meal, a medium meal, or a large meal. Alternatively, or in addition, a number of panels may further comprise a panel that displays the patient's glucose drop that is expected as a result of administering the number of units of insulin shown in the first panel, wherein the update includes displaying the corrected drop. level

- 3 040777 glucose in the patient, which is expected as a result of the administration of the adjusted number of units of insulin.

In some embodiments, the method may further include obtaining, on the mobile device, a maximum carbohydrate threshold for an average single meal and a minimum carbohydrate threshold for an average single meal, wherein one of a number of panels indicates whether the amount of carbohydrates displayed matches the second panel, a small meal, a medium meal, or a large meal, based on the maximum carbohydrate threshold and minimum carbohydrate threshold obtained. The method may also further include obtaining on the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, wherein the carbohydrate amount displayed by the second panel is calculated by the processor based on the number of units displayed by the first panel and the received ICR. The method may also further include obtaining on the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the patient's glucose drop displayed on one of a number of panels is calculated based on the amount displayed by the first panel. units of insulin and received ISF. This document describes a number of variations and permutations of the above embodiments of the invention. Moreover, it is expressly noted that any change or permutation that is described in this document can be implemented in relation to any type of embodiment of the invention. For example, a change or permutation that is primarily described in connection with a method embodiment may also be implemented in connection with a system and/or CRM embodiment. In addition, this flexibility and cross-applicability of embodiments of the invention is present despite any slightly different language (for example, process, method, steps, functions, set of functions, etc.) that are used to describe and/or characterize such embodiments. inventions.

Brief description of graphic materials

A more detailed view may be obtained from the following description, which is given by way of example in conjunction with the following drawings, in which the same reference numerals are used throughout the drawings in connection with the same elements.

In accordance with at least one embodiment of the invention in FIG. 1 depicts a typical information exchange environment that includes a typical HCP system, a typical healthcare information technology (IT, information technology) system, a typical mobile device that is associated with a typical patient and is in an information exchange mode with a number of personal medical devices that also associated with a typical patient, a typical server system that includes one or more typical servers (for example, Connected-care cloud servers) that are interconnected with each other with the help of a typical network with the ability to exchange information, and a typical system admin portal.

In accordance with at least one embodiment of the invention in FIG. 2 depicts an exemplary physical architecture of the exemplary HCP system shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 3 depicts an exemplary physical architecture of the exemplary mobile device shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 4A depicts an exemplary physical architecture of one of the exemplary servers in the exemplary server system shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 4B depicts an exemplary physical architecture of the exemplary Admin Portal system shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 5 depicts an exemplary functional architecture of the exemplary server system shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 6 depicts various entities in a typical information exchange and information processing system.

In accordance with at least one embodiment of the invention in FIG. 7 shows a first exemplary method that may be performed by the server system shown in FIG. 1.

In accordance with at least one embodiment of the invention in FIG. 8 depicts a second exemplary method that may be performed by the mobile device shown in FIG. 1 that performs a typical MMA.

In accordance with at least one embodiment of the invention in FIG. 9-18 depict various exemplary screen shots for displaying information using the exemplary HCP system shown in FIG. 1.

In FIG. 19 is a flowchart illustrating a typical process for computing, representing

- 4 040777 and editing the recommended dose of insulin, implemented using MMA in accordance with at least one embodiment of the invention.

In FIG. 20 depicts an exemplary screenshot resulting from MMA, in which the MMA automatically syncs with a patient's glucose sensor, in accordance with at least one embodiment of the invention.

In FIG. 21A, 21B, and 21C are exemplary screenshots resulting from MMA, in which the MMA obtains a patient's glucose level, in accordance with at least one embodiment of the invention.

In FIG. 22A, 22B, 22C and 22D depict exemplary MMA screenshots that MMA uses for a daily titration dosing schedule in accordance with at least one embodiment of the invention.

In FIG. 23A, 23B, 23C and 23D depict exemplary MMA screenshots that MMA uses for a fixed dose dosing regimen in accordance with at least one embodiment of the invention.

In FIG. 24A, 24B, 24C, and 24D depict exemplary MMA screenshots that MMA uses to derive a carbohydrate value for a carbohydrate bolus calculator dosing schedule, in accordance with at least one embodiment of the invention.

In FIG. 25A, 25B, 25C, and 25D depict exemplary MMA screenshots that MMA uses to derive a food insulin unit value for a carbohydrate bolus calculator dosing schedule, in accordance with at least one embodiment of the invention.

In FIG. 26A, 26B, 26C, and 26D depict exemplary MMA screenshots that MMA uses for a carbohydrate per meal calculator dosing scheme, in accordance with at least one embodiment of the invention.

In FIG. 27A, 27B, and 27C depict exemplary MMA screenshots that MMA uses to present and/or edit recommended insulin dose in accordance with at least one embodiment of the invention.

In FIG. 28 depicts an exemplary user interface screen in which there are four panels of information relating to a presented insulin dose, in accordance with at least one embodiment of the invention.

In FIG. 29 depicts an exemplary user interface screen sequence that shows how the four panels of information are updated as the presented insulin dose is adjusted, in accordance with at least one embodiment of the invention.

In FIG. 30 depicts an exemplary embodiment of the invention in which the user interface shown in FIG. 28 and 29 is displayed on a connected drug delivery device in accordance with at least one embodiment of the invention.

In FIG. 31 is a flowchart illustrating an exemplary process performed by a mobile device for displaying and updating the user interface shown in FIG. 28, 29 and 30 in accordance with at least one embodiment of the invention.

In order to provide a more complete understanding of the principles of the present disclosure, reference is made below to the embodiments of the invention, which are described below, illustrated using drawings. The embodiments of the invention disclosed herein are not intended to be exhaustive or limit the present invention to the specific form disclosed in the following detailed description. Rather, the embodiments of the invention are selected and described so that others skilled in the art can use their principles. Thus, no limitation on the scope of the present invention is intended.

In some cases, throughout the description of the present invention and in the claims, numerical modifiers such as first, second, third and fourth are used in relation to various data components, such as various identifiers and/or other elements. Such usage is not intended to indicate or prescribe a particular or required order of elements. Rather, such numerical terminology is used to help the reader identify the referenced element and distinguish that element from other elements, and should not be narrowly construed as indicating any particular order.

In addition, before proceeding to this detailed description, it should be noted that the objects, devices, and the like, which are depicted in various drawings and described in combination with various drawings, are presented by way of example and not as a limitation. Thus, any and all statements or other indications taken together as to what a particular graphic material depicts, what it is or what a particular element or object on a particular graphic material has, as well as any and

- 5 040777 taken together, such statements, which may individually be considered absolute, and therefore limiting, and may also be considered absolute, and therefore limiting, out of context - can only be correctly read in a constructive sense (except in the immediate cases) as if it were preceded by such a phrase, as, for example, in at least one embodiment of the invention, .... And it is precisely for reasons implying brevity and clarity of presentation that this implied preceding phrase is not repeated constantly in this detailed description .

Detailed description of graphic materials

I. Typical architecture.

A. Typical information exchange environment.

In accordance with at least one embodiment of the invention in FIG. 1 depicts a typical communication environment 100 that includes a typical HCP system 102, a typical healthcare IT system 118, a typical mobile device 104 that is associated with a typical patient 124 and is in communication mode with a number of typical personal medical devices (on in this image, a typical glucose meter 126 and a typical connected injection device 134), which are also associated with a typical patient 124, a typical server system 106, which includes one or more typical servers 140-146, which are interconnected using a typical private network 138 with a friend with the ability to exchange information, and a typical system 148 administrator portal. In FIG. 1 also shows the data network 108, communication channels 110, 112, 114, 116, 128, 136, 150, 152 and 154; a display 120 of the HCP system 102; and a display 122 of the mobile device 104. In addition, an associativity arrow 125, a conceptual traffic arrow 130, and a conceptual traffic arrow 132 are displayed, both of which are described below. It should be understood that the objects, their arrangement and cross-links depicted in FIG. 1 are provided by way of illustration and by way of example, and not limitation, and that other objects, devices, and cross-links may be implemented or found suitable by those skilled in the art for a given environment.

HCP system 102 (which includes display 120) is described in terms of physical architecture in more detail below in conjunction with FIG. 2, but in general, the system may take the form of any computing device that is equipped, configured, and programmed to perform the HCP portal functions described herein. Some optional equipment of the HRS system 102 includes a desktop computer, a laptop computer, a tablet computer, a mobile device such as a smartphone, or a device that interacts with the HRS using voice, augmented reality (AR) technology, or virtual reality technologies (VR, virtual reality). In some embodiments, the HCP system 102 is any electronic device capable of supporting and running an Internet browser (i.e., a web browser, which may be a separate application, may be a capability of another application, just to name a few examples). ). As shown in FIG. 1, the HCP system 102 is a system capable of exchanging information with the healthcare IT system 118 via the communication channel 116, and connected to the data communication network 108 via the communication channel 110. Although the communication channel 116 is shown separately from the communication network 108, it should be understood that in some cases all or part of the information communication channel 116 may pass through at least portions of the communication network 108. In some instances, HCP system 102 may communicate with HIT system 118 indirectly via data network 108 rather than using direct channel 116 as depicted in FIG. 1. Among other examples, typical users of the NRS system 102 are prescribing NRSs (e.g. physicians, physician assistants (PAs), nurse practitioners, etc.) as well as non-prescribing NRSs that are included in medical team, as well as users associated with integrated delivery networks (IDN, integrated delivery networks).

In various different embodiments of the invention, the HCP system 102 provides and supports functions such as prescribing drug dosing regimens (e.g., insulin dosing regimens such as a basal insulin dosing regimen, a bolus insulin dosing regimen, and/or the like), modifying existing prescribing dosing regimens, setting and/or changing parameters of dosing regimens, and viewing individual patient data, among other examples that may be listed herein. Prescribing and setting parameters based on drug dosing schedules performed by the HCP using the 102 HCP system helps patients to determine the doses of drugs. Among other functions, the HCP system 102 provides the HCP with the ability to download patient EHR data from the healthcare IT system 118 using the communication channel 116 and view the EHR data on the HCP portal, view a selection of available drug dosing regimens, select a drug dosing regimen to prescribe to the patient, and assign values to the required parameters for the selected drug dosing regimen (such as starting dose, insulin-to-carbohydrate ratio, etc., as long as

- 6 040777 in the new case of the insulin dosing regimen). Additionally, the HRS system 102 provides data visualization features that allow users of the HRS to view data regarding a patient in chronological order. In various embodiments, these patient data are chronologically viewable in chart form, graphical form, tabular form, and/or one or more other forms that those skilled in the art deem appropriate for a given implementation.

Mobile device 104 (which includes display 122) is described in terms of physical architecture in more detail below in conjunction with FIG. 3, but in general, a mobile device may take the form of any computing device that is equipped, configured, and programmed to perform the mobile device functions described herein. Some optional equipment of mobile device 104 includes a cellular phone, smartphone, personal digital assistant (PDA), tablet computer, laptop computer, wearable device, mobile device that interacts with its user through voice or based on virtual reality technology. and so on. As shown in FIG. 1, the mobile device 104 is communicatively connected to the glucometer 126 via the communications channel 128, to the connected injection device 134 via the communications channel 136, and to the data network 108 via the communications channel 112. As shown by the double-sided dashed associativity arrow 125, mobile device 104 is associated, for example, via a subscription service account, individual ownership information, ownership information, and/or one or more other means, with patient 124.

With respect to the C3 server system 106, an illustrative example of one of the C3 servers 140-146 is described more fully in terms of physical architecture below in conjunction with FIG. 4A. In addition, the C3 server system 106 as a whole is described in terms of functional architecture (eg, software architecture) more fully below in conjunction with FIG. 5. In general, however, C3 server system 106 may take the form of any set of one or more servers that are collectively equipped, configured, and programmed to collectively perform the C3 server system functions described herein. As shown in FIG. 1, C3 server system 106 is communicatively connected to data network 108 via communication channel 114 .

It should be noted that, as shown in FIG. 1, each respective C3 server 140-146 in the C3 server system 106 may have its own respective communication channel 114 with the data network 108; also or instead, the single communications channel 114 may communicatively connect the C3 server system 106 to the data network 108, possibly via a firewall firewall, a network access server (NAS), and/ or the like. For clarity, in the remainder of this disclosure, one or more communication channels 114 are referred to as communication channel 114 . Moreover, as also shown in FIG. 1, the respective C3 servers 140-146 are interconnected with each other with the possibility of exchanging information using a private network 138, which may take the form of or include a local area network (LAN, local area network), virtual private network (VPN, virtual private network ) and/or one or more optional equipment options that those skilled in the art deem appropriate for a given implementation. In some embodiments, the depicted network 138 will not exist as a separate network as currently shown, in such embodiments the respective C3 servers 140-146 communicate with each other via their channels to the data network 108. The possibility of establishing a communication connection between the C3 server system 106 and the admin portal system 148 will be discussed below.

In general, C3 server system 106 functions like a cloud, as the term is used in the art to refer to entities such as HCP system 102, healthcare IT system 118, and mobile device 104 (and in particular to one or multiple applications, such as one or more MMAs, running on the mobile device 104). In some embodiments, a subset of C3 servers may be allocated to serve at least one of the HCP system 102 (e.g., to provide the HCP portal application 572 as detailed below), the healthcare IT system 118, and the mobile device 104. 140-146. However, in some embodiments of the invention, each of the C3 servers 140-146 can serve any of these three objects. Regardless of the specific architectural implementation, the C3 server system 106 functions as at least one cloud with specific goals for these entities. Thus, in at least one embodiment of the invention, all communication—to and from the C3 server system 106—with any one or more other entities is a secure communication, for example, such communication may be encrypted and/or signed, as known in the field

- 7 040777 technology. Such communication may take place within a tunnel, such as a VPN, among other communication security and data security options, which may be implemented in a manner that those skilled in the art deem appropriate in various contexts.

In various different embodiments of the invention and as further described below, the C3 server system 106 provides and supports functions such as the secure and reliable transmission of information and data (associated, for example, with appointments) between the HCP system 102 and the MMA running on patient-related mobile devices, data storage, patient-to-HCP relationship management, IDN, and the like, and in some embodiments, instead or in addition, provides and supports one or more other functions that those skilled in the art deem appropriate for a given implementation. Moreover, in some embodiments, the C3 server system 106 facilitates data sharing that involves payers (eg, insurance companies); in some such embodiments of the invention, such sharing of data with payer entities is dependent on whether the respective patients agree to allow such sharing of information. Other examples of features provided and supported may also be listed in this document. The admin portal system 148 is described in terms of physical architecture in more detail below in conjunction with FIG. 4B, but in general, the system may take the form of any computing device that is equipped, configured, and programmed to perform the functions of the Admin Portal System described herein. Some options for optional equipment for the admin portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. As shown in FIG. 1, the admin portal system 148, in at least one embodiment of the invention, can communicate with the C3 server system 106 (and in the illustrated example, private network 138 in particular) via communication channel 150. In other embodiments of the invention, as also shown in FIG. 1, the admin portal system 148 functions to communicate with the HCP system 102, the mobile device 104, and/or the C3 server system 106 via the communication network 108. In some embodiments, the admin portal system 148 can perform both.

Typically, in various other embodiments of the invention, the admin portal system 148 provides various services in relation to the HCP portal 102, the MMA running on the mobile device 104, and/or the C3 server system 106. One of the typical categories of such services are those related to user management, login, access level, and so on. In at least one embodiment of the invention, a user with a sufficient level of authority can use the admin portal system 148 to change and/or manage various settings of the HCP portal 102, perform MMA on the mobile device 104, and/or the C3 server system 106. In some cases, changes made using the admin portal system 148 affect only a single MMA, a single user, a single HCP, and/or the like; in other cases, such changes affect multiple MMAs, multiple user accounts, multiple NSRs, and/or the like. For example, an integrated delivery network (IDN) (eg, a healthcare organization network) may be provided by an admin portal system 148 that manages patient accounts registered with the IDN. In some embodiments, the admin portal system 148 is configured to perform updates, upgrades, and the like. In some embodiments, the admin portal system 148 is configured to manage individual HCP accounts, individual patient accounts, and/or the like. And, of course, this document can list a number of other typical administrative functions for which the admin portal system 148 can be used.

In the typical situation depicted in Fig. 1, the data communication network 108 is connected, with the possibility of exchanging information, with the HCP system 102 using the information exchange channel 110, with the mobile device 104 using the information exchange channel 112, with the C3 server system 106 using the information exchange channel 114 and with the system 148 portal of the administrator using the channel 152 exchange of information. In at least one exemplary scenario, communication network 108 includes one or more Internet Protocol (IP) networks, such as the World Wide Web, commonly referred to as the Internet, one or more public IP networks, one or more private (eg, corporate) IP networks and/or one or more IP networks of any other type, as those skilled in the art deem appropriate for a given implementation. Entities that communicate via communication network 108 may be identified by address, such as an IP address (eg, IPv4 address or IPv6 address). However, the data network 108 is not required to be or include an IP network, as this is just an example. As used in this document, the term communication channel includes

- 8 040777 one or more wired communication channels (for example, Ethernet, Universal Serial Bus (USB, Universal Serial Bus) and/or the like) and/or one or more wireless communication channels (for example, cellular, Wi-Fi, Bluetooth, and/or the like) and may include any suitable number of relay devices such as routers, switches, bridges, and/or the like. Communication channel 112 may specifically include at least one wireless communication channel to facilitate two-way communication with mobile device 104. Moreover, one or both of communication channels 128 and 136 may take the form or at least , include at least one of the following: near-field communication (NFC) channel, Bluetooth channel, radio-frequency identification channel (RFID, radio-frequency identification), direct radio frequency (RF, direct radio frequency) a channel and/or one or more other types of wireless communication channels. In addition, communication channels 128 and 136 may be, but need not be, point-to-point communication channels between (i) mobile device 104 and (ii) glucometer 126 and connected injection device 134, respectively, in some embodiments of the invention one or both communication channels 128 and 136 are indirect channels that operate, for example, with a Wi-Fi router or a ZigBee router, or with a cellular network or tower (not shown). Of course, other examples of implementation could be listed in this document.

In the typical scenario depicted in Fig. 1, healthcare IT system 118 is communicatively connected to HCP system 102 via communication channel 116, and typically can take the form of one or more servers. Health IT system 118 may or may not have its own local user interface, such as its own monitor, keyboard, mouse, touch screen, or other user interface. In various various embodiments of the invention, the healthcare IT system 118 further provides and maintains secure maintenance, secure storage, and secure access to patient electronic health records (EHR, Electronic Health Record, also referred to in the industry as electronic outpatient records or EMR, Electronic Medical Record), perhaps, among other functions that those skilled in the art would deem appropriate for a healthcare IT system. In addition, the health care IT system 118 is communicatively connected to the data communication network 108 via an information exchange channel 154 . The healthcare IT system 118 may also communicate with the C3 server system 106 via the data network 108 . In some embodiments, the healthcare IT system 118 interacts with the C3 server system 106 and/or the HCP system 102 using a standardized protocol, such as the Fast Healthcare Interoperability Resources (FHIR) protocol or the Substitutable Medical Applications and Reusable Technologies (SMART) protocol, which are given as examples.

In the exemplary scenarios described herein, patient 124 has been diagnosed with diabetes and is being treated for HCP associated with the HCP system 102, although this case is provided by way of example only and not limitation. In the described embodiments, both the mobile device 104 (and the at least one MMA running thereon), the glucometer 126, and the connected injection device 134 are associated with the patient 124, and at least thus, with each other. The aforementioned associativity arrow 125 is intended to represent general associativity and interaction at the user interface level of the patient 124 with the mobile device 104.

Further, it should be noted that although in FIG. 1 shows a mobile device 104 connected to both the glucometer 126 and the connected injection device 134, in some cases in various scenarios, only one of the listed devices can be present: the meter 126 and the connected injection device 134, and the presence of both is not required. Indeed, in some scenarios, there are no additional medical devices connected to the mobile device 104 at all, as is the case with systems that require patients to separately and manually measure glucose levels and/or record dosage information, or as in the case of drugs, which are taken orally and in this case, devices are not required to monitor or otherwise test one or more levels, readings or other parameters of the patient 124. In some cases, the patient may connect more than one glucometer and / or more than one connected injection device to the MMA for example, a patient may have one glucometer and/or injection device at home and may have one glucometer and/or injection device at work. MMA can be configured to support multiple connections of each. Moreover, in some cases, there is one or more connected medical devices other than a glucometer and/or an attached injection device. Some examples include a blood pressure monitor, a pulse/oxygen monitor, and/or the like. And, of course, a number of other examples could be listed in this document. The glucometer 126 is associated with the patient 124 for medical, diabetes-related purposes, and is also associated with the possibility of exchanging information.

- 9 040777 formation with the mobile device 104 using the above-described communication channel 128. The meter 126 may include a blood-glucose meter (BGM), a continuous glucose meter (CGM), a flash glucose monitor (FGM), or other devices that measuring the patient's blood glucose level 124 or other sources of glucose level information (eg, contact lens devices or devices that use near infrared radiation to measure glucose levels). The BGM performs discrete spot measurements of the patient's blood glucose (eg, by pricking the patient's finger to take capillary spot measurements of the patient's total blood glucose). Both CGM and FGM use sensors to measure glucose levels in the interstitial fluid. The CGM system may include a sensor, a transmitter, and a receiver/application. The CGM may take more frequent (ie, more continuous) measurements of the patient's interstitial fluid glucose levels, and possibly the patient may wear it continuously for relatively long periods of time (eg, several hours or days at a time). One illustrative example of such a CGM is the G6 sensor manufactured by Dexcom, Inc. The FGM system may include a sensor worn on or inserted into the patient's body part and a reader (eg, handheld reader) that, when activated or placed in close proximity to the sensor, obtains glucose readings from the sensor. One illustrative example of such an FGM is the FreeStyle Libre device manufactured by Abbott Diabetes Care Inc. In some embodiments, the FGM does not require clarification due to a finger prick. And, of course, one or more other types of glucometers can also be used.

The CGM and FGM systems can measure interstitial fluid glucose levels, and the BGM systems can measure blood glucose levels. For simplicity and readability, the remainder of this disclosure simply refers to glucose or GL. It is understood that such references may refer to either blood glucose or interstitial fluid glucose, depending on the situation. The connected injection device 134 is also associated with the patient 124 for medical, diabetes-related purposes, and also communicates with the mobile device 104 via the communication channel 136 described above. The device 134 may further contain a drug or drug. In some embodiments of the invention, the system may contain one or more devices, which include a device 134 and a drug or drug. The term drug or drug product refers to one or more therapeutic agents, which include, but are not limited to, insulins, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic funds that can be delivered using the above device. The drug or drug used in the device 134 may be manufactured using one or more excipients. To administer a drug to a human, the device is used by the patient, caregiver, or healthcare professional in the manner generally described herein. In at least one embodiment, the connected injection device 134 is or at least includes what is sometimes referred to in the art as a connected insulin delivery device (e.g., a connected insulin pen, such as pen with built-in and / or plug-in electronics for automatic detection and transfer to another electronic device of the amount of insulin injected). In various various embodiments of the invention, the connected injection device 134 is or includes one or more of the insulin delivery devices described in any of the following patent applications, each of which is hereby incorporated by reference in its entirety. :

PCT Application No. PCT/US 17/65251 filed December 8, 2017 entitled Medication Delivery Device with Sensing System (Patent Attorney Case No. X21353);

PCT Application No. PCT/US 18/19156, filed February 22, 2018, entitled Dose Detection and Drug Identification for a Medication Delivery Device (Patent Attorney Case No. X21457); and U.S. Provisional Application No. 62/552659, filed August 31, 2017, titled Dose Detection with Piezoelectric Sensing for a Medication Delivery Device (Attorney Case No. P21462).

Moreover, in some cases, one or more of the capabilities of one of the two devices in this disclosure is also, or instead, provided by the other of the two devices and/or one or more additional devices. In one illustrative example, one device can both monitor glucose (and report results) and administer insulin (and report back administered amounts). And, of course, other combinations of features could be listed in this document. In addition, as also described below, in some embodiments of the invention, the MMA running on the mobile device 104 communicates for different purposes (for example, from

- 10 040777 editing commands for drug dosing, receiving dosed quantity confirmation reports, requesting readings (e.g. glucose, obtaining one or more measured values, and/or the like) with one or more medical devices connected, such as a glucometer 126 and an attached injection device 134. This exchange of information with this device can be one-way or two-way. Additional examples of information that can be transmitted from a connected medical device to the MMA include error codes, device metrics, drug dosing records, and/or drug dosing confirmations. And, of course, other examples could be listed in this document. Moreover, in some cases, direct communication channels exist between various connected medical devices, such as between the glucometer 126 and the connected injection device 134.

The conceptual information flow arrow 130 is intended to be a graphical and conceptual depiction of what, among other information, and as described in more detail below, the HCP system 102 transmits either directly via the data network 108, via the C3 server system 106, or via some other an intermediate component or network, a drug dosing schedule selected by the HCP (e.g., a bolus dosing schedule) in an MMA running on the mobile device 104. Similarly, the conceptual information flow arrow 132 is intended to be a graphical and conceptual depiction of what, among other information, and as described in more detail below, MMA executing on mobile device 104 transmits, either directly or via C3 server system 106, patient-tracked and patient-shared health indication data regarding the patient's diabetes and/or one or more other indicators, pr signs related to health, etc. In general, it should be understood that any of the entities described herein, which include, but are not limited to, HCP system 102, healthcare IT system 118, mobile device 104 (which includes MMA running on a mobile device), the C3 server system 106 and the admin portal system 148, in at least one embodiment of the invention can communicate with any other of these entities without requiring that communications be routed by one or more of the other entities. For example, in at least one embodiment of the invention, the HCP system 102 and the mobile device 104 can exchange information without the information passing through the C3 server system 106 . However, in some embodiments of the invention, one or more objects communicate with each other using at least one additional object; by way of example, in at least one embodiment of the invention, data (eg, data regarding a selected HCP treatment regimen) is transmitted from the HCP system 102 to the MMA running on the mobile device 104 using the C3 server system 106 .

B. Generic System NSR (Regular Physical Architecture).

In accordance with at least one embodiment of the invention in FIG. 2 depicts a typical physical architecture of an HCP system. This architecture is provided by way of illustration and not limitation, as other architectures may be implemented as deemed appropriate by those skilled in the art. As shown in FIG. 2, HCP system 102 includes a communications interface 202, a processor 204, a data storage device 206, and a user interface 208 that includes the aforementioned display 120.

Communications interface 202 may include one or more components such as Ethernet cards and/or the like for wired communications and/or one or more components such as Wi-Fi chips and/or the like. , for wireless communication. Processor 204 may be a general purpose microprocessor, such as a central processing unit (CPU). Storage device 206 may be or include any suitable non-volatile computer readable medium (CRM) such as a storage device (e.g., read-only memory (ROM), random access memory (RAM, m)) flash memory, solid state drive, optical storage device, and/or the like) and may contain instructions executable by the processor 204 to perform at least the HCP portal system functions described herein. The user interface 208, in addition to the display 120, may include one or more output devices, such as speakers, LEDs, and/or the like, and may further include one or more input devices, such as a keyboard, mouse, trackpad. , microphone and/or the like, as are known in the art. The various components of the HRS system 102 are depicted as interconnected, with the ability to exchange information, using the system bus 210. In addition, it should be understood that in at least one embodiment of the present systems and methods, the HRS system 102 launches or implements the HRS portal 572 (depicted in Fig. 5, also referred to in this document as the application program 572 of the HCP portal). Portal 572 HCP may be a software or embedded application program that runs on

- 11 040777 hardware system 102 HCP. For example, the HCP portal 572 may be a widget running on the HCP's electronic health record (EHR) system. Such a widget can be integrated with the HCP EHR system using a protocol such as SMART (Substitutable Medical Apps, Reusable Technology) on FHIR (Fast Healthcare Interoperability Resources). In some embodiments of the invention, the HCP portal 572 may take the form of a web application running in a web browser. In an illustrative example, the HCP registers with the HCP portal 572 by pointing to a hyperlink in a web browser in the HCP system 102, after which the HCP portal 572 is opened in the browser. In at least one such embodiment of the invention, the HCP portal content in the HCP portal 572 is hosted by the C3 server system 106 . Thus, in some examples, the HCP system 102 stores little or no patient data (e.g., patient medical records, drug dosing schedule data, and/or the like) and instead acts as a simple transmission channel. such patient data between its HCP user and the C3 server system 106 . In some such embodiments of the invention, there is locally stored data in the form of code for the web browser itself (for example, Microsoft Edge, Google Chrome, Apple Safari, and / or the like), and possibly code for a web application add-on ( e.g. Java). And, of course, other options regarding the centralized and/or distributed nature of the operating code and/or other essential data may be listed herein as those skilled in the art may deem appropriate for a given implementation.

C. Typical mobile device (typical physical architecture).

In accordance with at least one embodiment of the invention in FIG. 3 depicts a typical physical architecture of a mobile device. As can be seen from the study, Fig. 3 is similar in many respects to FIG. 2, and therefore is not described in this document in such detail. However, due to the fact that the mobile device 104 is a mobile device, those skilled in the art will appreciate that appropriate differences may be present in each of the components, such as the communication interface 302, possibly equipped, programmed, and configured for wireless wide area communication. networks (WWAN, wireless-wide-area-network) (according, for example, with LTE), and for the exchange of information over a wireless local area network (WLAN, wireless-local-area-network) (according, for example, with Wi -Fi), as well as additional wireless communication capabilities such as NFC, Bluetooth, RFID, RF, and/or the like. Moreover, in at least one embodiment of the invention, the processor 304 is selected to be suitable for implementation in mobile devices, as is the storage device 306, which contains instructions executable by the processor 304 to perform at least the functions of a mobile device. described in this document, which includes, but is not limited to performing the MMA described in this document. Finally, in addition to the display 122, the user interface 308 includes one or more user input and/or user output components suitable for mobile device hardware (e.g., touchscreen, stylus, pointing and clicking devices, softkeys, keyboard). , microphone, speaker, camera, data ports, and/or the like). The various components of the mobile device 104 are depicted as interconnected, with the ability to exchange information using the system bus 310.

D. Typical C3 server (typical physical architecture).

Fig. 4A depicts an exemplary physical architecture of a C3 server 140, exemplarily selected as one of the C3 servers 140-146 of a C3 server system 106, in accordance with at least one embodiment of the invention. As noted above, the C3 server system 106 may take the form of any number of servers, including only one, and also including more than one. In FIG. 1, four servers 140-146 C3 with an ellipsis between the third and fourth are intended to illustrate this numerical variability. As can also be seen, FIG. 4A is similar in many respects to FIG. 2 as well as FIG. 3 and is therefore not described in detail in this document.

In most scenarios, the architecture of the C3 server 140 will typically be more similar to that of the HCP system 102 than to the mobile device 104, just because of the level of performance and data processing that these different architectures provide. However, in at least one embodiment of the invention, there are differences in the architecture of the C3 server 140 even compared to the HCP system 102. For data security reasons, communications interface 402 may include wired communications-only hardware (eg, Ethernet cards) and may include more communications interfaces than HCP system 102.

Similarly, processor 404 and storage device 406 are typically selected to handle more communication data, storage data, data processing, and the like than is normally required from HCP system 102. The data storage device 406 contains instructions executable by the processor 404 to perform at least the C3 server functions described herein. Finally, the user interface 408 is shown in dotted lines to indicate that

- 12 040777 it is not present in all embodiments of the invention. For example, in some cases, the C3 server 140 is only accessible in a user interface-like manner through data connections such as remote desktop connections, shell connections, and/or the like. The various components of C3 server 140 are depicted as interconnected, with the ability to exchange information via system bus 410. As described herein, in at least one embodiment of the invention, C3 server system 106 collectively comprises commands that are executed by one or more of one or multiple processors of one or more C3 servers 140-146 to cause the C3 server system to perform various combinations of the functions of the C3 server system described herein. The method 700 described below, shown in FIG. 7 is one such exemplary combination. Indeed, in at least one embodiment of the invention, the logic for implementing the C3 server system 106 is distributed across a number of physical servers. In at least one embodiment of the invention, the hardware (eg, storage device, processor capacity, web servers, switches, routers, communication links, etc.) that are used to facilitate specific access requests and/or the like. , are provided dynamically so that different access requests can be performed by different sets of hardware. Such hardware may be dynamically provisioned for a particular access request based on various factors such as geographic location of the request, load balancing, required quality of service (QoS, quality of service), service agreement parameters, and/or the like. Thus, a C3 server system can be thought of as a cloud, as the term is used in the art, wherein such a cloud includes a distributed network of servers that collectively and dynamically run virtual services. In at least one embodiment of the invention, each such virtual service is its own autonomous software process. Moreover, the particular hardware server (or servers) that actually runs a given running copy of a given virtual service is dynamically allocated as it runs depending on one or more factors such as those mentioned in this paragraph.

E. Generic Admin Portal System (Physical Architecture Types).

In accordance with at least one embodiment of the invention in FIG. 4B depicts a typical physical architecture of an admin portal system 148. As can be seen from the study, Fig. 4B is similar in many respects to each of FIGS. 2, 3 and 4A, and therefore is not described in this document in such detail. As noted above, some of the optional equipment options for the admin portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. The admin portal system 148 may take the form of any one or more computing devices that are appropriately equipped, programmed, and configured to perform at least the functions of the admin portal system described herein. As shown in FIG. 4B, the admin portal system 148 includes an communications interface 452, a processor 454, a storage device 456 containing instructions executable by the processor 454 to perform at least the functions of the admin portal system described herein, and a user interface 458, they are all connected to each other with the ability to exchange information using the system bus 460.

In addition, it should be understood that, in at least some embodiments of the invention, like the HCP system 102, the admin portal system 148 launches or implements an admin portal application (not shown). The admin portal application may be a software or embedded application that runs on the admin portal system 148 hardware. For example, the admin portal application may take the form of a web application running in a web browser. An administrator or user can log in to the Admin Portal Application by pointing a web browser on the Admin Portal system to a hyperlink, which will open the Admin Portal Application in the browser. In such embodiments, the content in the admin portal application may be hosted by the C3 server system 106, and little or no patient data may be stored locally in the admin portal system 148 (e.g., patient medical records, drug dosing regimens and/or the like). Alternatively, the administrator portal system 148 instead acts as a simple communication channel for patient data between its administrator/user and the C3 server system 106 .

F. Typical C3 server system (typical functional architecture).

In accordance with at least one embodiment of the invention in FIG. 5 depicts a typical functional architecture of a C3 server system 106. It should be understood that this functional architecture is provided by way of illustration and not limitation, and that other functional architectures may be implemented in as many different contexts as deemed necessary.

- 13 040777 appropriate specialists in the art. The functional architecture of the C3 server system 106, which includes each of the following: various storage devices, services, gateways, channels and interfaces, can be implemented using any combination of hardware, firmware and / or software (with the firmware software and/or software runs on hardware) as deemed appropriate by those skilled in the art. It should also be noted that entities in addition to the C3 server system 106 are depicted in architecture 500 as shown in FIG. 5. This is illustrated by the left curly brace labeled 106 for the C3 server system 106—components outside of said left curly brace are associated with objects in addition to the C3 server system 106.

As seen in FIG. 5, architecture 500 includes four of what are known in computing and programming as layers separated by interfaces; these are logical constructs that, among other things, contribute to the formation of data packets and improve the quality of management of complex systems. The architecture 500 includes a data layer 502, an internal web services (IWS) layer 504, an externally-facingservices (EFS) layer 506, and an application program layer 508. Data layer 502 is separated by IWS data interface 503 from IWS layer 504, which is separated by IWS-EFS interface 505 from EFS layer 506, which is separated by EFS application program interface 507 from application program layer 508. In addition, it should be noted that interface 509 is a logical part of the architecture 500 in which users will interact with the entire system and, in particular, interact directly with the application program layer 508, in other words, interface 509 is what is often referred to in field of technology human-machine interface.

In the illustrated embodiment, data layer 502 includes a number of data storage devices 510a-e. Each storage device 510a-e corresponds to one of the microservices 514, 516, 518, 520, and/or 522 described in this document. Data storage devices 510a-e collectively contain patient data and/or medical data that includes personally identifiable information (PII) such as names, addresses, telephone numbers, email addresses, social security numbers, and the like. The data storage 510a-e may also collect information other than PII, such as information regarding medical procedures, disease detection, drug dosing regimens (i.e., templates), and the like. In at least one embodiment, the data layer 502 is implemented using on-demand cloud computing platforms and services operated and offered by Amazon Web Services, a subsidiary of Amazon.com, Inc. from Seattle, Washington. In at least one other embodiment of the invention, the data layer 502 is implemented using the PostgreSQL product developed by Heroku of San Francisco, California. And, of course, other options may be listed in this document. In at least one embodiment of the invention, the data layer 502 is organized in accordance with the FHIR standards, which are proposed by Health Level Seven International (HL7) of Ann Arbor, Michigan.

IWS layer 504 includes a number of microservices 514, 516, 518, 520, and 522. The ellipsis between service 520 and service 522 is intended to indicate that there can be any number of services in IWS layer 504 that those skilled in the art deem appropriate. for this implementation. Each microservice is a data gateway, implemented as a software service responsible for processing data, or some type of functionality. Typical microservices include a human microservice for processing RP related to registered or potential patients; order microservice for processing data related to appointment orders; observation microservice for processing data related to patient observations entered using HCP or observed using MMA running on a mobile device; microservice user access for processing data regarding access rights and permissions of users; a client compatibility microservice for checking the compatibility of the user's mobile device with the functions provided by the C3 system 106, and a substance microservice for processing data regarding the types of medicines used or administered to patients/are administered by patients. Each microservice 514-522 has access to one data storage device 510a-e via a corresponding communication channel 51la-e.

Each internal service 514-522 is, in at least one embodiment of the invention, a service designed such that access, which includes read and write access, to data stored in the data storage device 510a-e is available. only for the various EFS layer 506 gateway interfaces 524-530 in a manner defined and permitted by the respective internal services 514-522. In at least one embodiment of the invention, the IWS layer 504 is implemented using Amazon Web Services. In yet another embodiment of the invention, the IWS layer 504 is implemented using Heroku

- 14 040777

Platform, also developed by Heroku. And, of course, other options may be listed in this document.

Further, it should be noted that the channels which are described in conjunction with FIG. 5 represent logical access channels, not necessarily physical communication channels; the logical access channel shown in FIG. 5 indicates that, at least in the described embodiment, appropriate configurations, authorizations, authentications, permissions, and/or the like have been established to facilitate the exchange of information between respective entities. The EFS layer 506 includes an HCP portal gateway 524, an MMA gateway 526, an MMA gateway 528, and an administrator gateway 530. In addition, the ellipsis between MMA gateways 526 and 528 means that any suitable number of MMA gateways may be implemented; the ellipsis between mobile devices 104 and 532 at application level 508 indicates the same. Each MMA gateway corresponds to a particular MMA type or version. Implementing a dedicated running copy of the MMA gateway for each type or version of MMA is a design decision and others can be made. Using the IWS-EFS interface 505, it can be seen - from the image of the IWS-EFS interface 505, similar to the system bus - that any of the gateway interfaces of the EFS level 506 in this depicted embodiment of the invention can, as necessary, call any of the internal services 514-522 . Each gateway 524-530 at the EFS layer 506 is designed in at least one embodiment of the invention such that access to internal services 514-522 at the IWS layer 502 is only available to objects at the application program layer 508 in a manner defined and permitted by the respective gateways. 524-530. For example, in one embodiment of the invention, the HRS portal 572 running on the HRS system 102 can access internal services 514-522 using the HRS portal gateway 524; similarly, MMA 568 running on mobile device 104 can access internal services 514-522 using MMA gateway 526. In at least one embodiment of the invention, the EFS layer 506 is implemented using Amazon Web Services. In at least another embodiment of the invention, the EFS layer is implemented using the Heroku Platform. And, of course, other options may be listed in this document. The application layer 508 includes the HCP system 102 running the Health Information Technology User Interface (HIT UI) 574, which in turn runs the HCP portal 572. The application layer 508 further includes the aforementioned mobile device 104 (executing MMA 568 in accordance with the present disclosure), a second mobile device 532 (executing a different type or version of MMA, referred to as MMA 570 in accordance with the present disclosure), an administrator portal 534 and portal 536 administrator. As with the previously mentioned ellipsis examples, the ellipsis between mobile device 104 and mobile device 532 is intended to indicate that any suitable number of mobile devices may be present at application level 508. In addition, one MMA gateway (eg, MMA gateway 526) may be connected to a number of mobile devices, each running the same type or version of MMA (eg, MMA 568). Similarly, the ellipsis between admin portal 534 and admin portal 536 is intended to indicate that any suitable number of system administrator level portals may be implemented as those skilled in the art deem appropriate in the given context. In one embodiment, the admin portal 534 is a clinical C3 admin server configured to administer a C3 server system 106 in conjunction with clinical aspects. In one embodiment, the admin portal 536 is a product support C3 admin server configured to administer a C3 server system 106 in conjunction with product support aspects. And, of course, other examples could be listed in this document. In at least one embodiment of the invention, one or both of the admin portal 534 and admin portal 536 are processes running on the admin portal system 148. In addition, although in FIG. 5 does not depict any examples of ellipsis associated with the NDS portal or additional NDS portals, it is also possible that any suitable number of NDS portals could be implemented in this context. The HCP system 102 may provide the HCP with a 574 Health Information Technology User Interface (HIT UI). In some embodiments, the HIT UI 574 may be a web application, shell, or other suitable user interface that allows the HCP to view, edit, create, or otherwise interact with patient or non-patient data and records that are stored in the HIT 118. The HIT UI 574, in turn, can launch the HCP portal 572 as a separate user interface on the HIT UI 574 upon command of the HCP - exemplary screenshots of the HCP portal 572 are provided as part of FIG. 9-18. As described earlier in this document, the HCP portal 572 may take the form of a web application running in a web browser that allows the HCP to receive

- 15 040777 access or provide data regarding the patient from/to the system 106 S3 servers. In at least some embodiments, the HCP portal 572 may also interact with the HIT 118, access or provide patient data from/to the HIT 118. Thus, the HCP may launch the HCP portal 572 with a single click of a button or key while viewing a record. specific patient in HIT UI 574 to assign a dosing regimen, view patient observations or recorded dosing history, or access other HCP portal features described in this document.

In some embodiments, HIT UI 574 and HCP portal 572 may be provided by the same vendor. In other embodiments, the HIT UI 574 may be provided by a first provider and the HCP portal 572 may be provided by a second provider. The HCP portal 572 may be integrated into HIT UI 574 using industry standards such as SMART on FHIR described above. Thus, the integration of the HCP portal 572 allows the HCP to access patient data from the HIT 118 through the portal 572 without having to manually enter the data, and also allows the HCP to select an appropriate drug dosing regimen without having to return to the HIT UI 574 to view important patient data. such as medications, medical history, lab results, blood sugar records in chronological order, insulin dosage information, etc. In some cases, the HCP portal 572 may also be configured to retrieve a minimum set of patient-specific demographic data (eg, patient name, date of birth, patient unique identifier, or unique identifier for the patient's EHR) from the HIT 118 and display that demographic data. in a header or other prominently displayed area. This can help ensure that the HCP is working with the correct patient record.

Although the HCP portal 572 is depicted as being encapsulated in HIT UI 574, the HCP portal 572 may also be implemented as a standalone application outside of any healthcare IT system. In such cases, the HCP system 102 will execute or implement the HCP portal 572 without any HIT UI 574. In such embodiments, the HCP portal 572 may additionally obtain patient data from the healthcare IT system, but may not be launched as a separate window or graphical user interface from the user interface of the healthcare IT system. Of course, the HCP portal 572 may also be configured to not communicate with any healthcare IT system at all—in such embodiments, it may be necessary to manually enter and store medical and biographical data regarding the patient in the HCP portal 572.

Through the EFS application interface 507, only the HCP system 102 has access, via channel 558, to the HCP portal gateway 524; only MMA 568 (on mobile device 104 or on a number of mobile devices) has access via link 560 to MMA gateway 526; only MMA 570 (on mobile device 532 or on a number of mobile devices), via channel 562, has access to MMA gateway 528; and the C3 manager gateway 530 is available to both the C3 manager portal 534 (via channel 564) and the C3 manager portal 536 (via channel 566). Such limited access in the depicted embodiment of the invention is two-way, since the C3 server system 106 can only access the HCP system 102 using the HCP portal gateway 524 and channel 558; C3 server system 106 can only access MMA 568 using MMA gateway 526 and channel 560, and similarly with MMA 570 using MMA gateway 528 and channel 562, as well as C3 manager gateway 530 and channels 564 and 566 - to the respective portals 534 and 536 of the administrator C3.

G. Typical interconnected system.

In accordance with at least one embodiment of the invention in FIG. 6 depicts various entities in an exemplary interconnected communication and information processing system 600. Of course, the term interconnected system is not used in this document in the biological sense of the word, but rather in the context of information exchange and information processing using a computer. Wherever possible, the elements discussed above in conjunction with FIG. 1-5 are also indicated in Figs. 6 to help the reader understand by placing such elements in an interrelated system environment 600 that includes an NRS activity area 602, a patient activity area 604, a population management activity area 606, and a care management activity area 608, which all interact with the possibility of exchanging information, and are interconnected with each other using the C3 server system 106, which is shown in FIG. 6, as the inclusion of a data analysis engine in this image. As mentioned above, it is also contemplated that in some embodiments of the invention, the C3 server system 106 connects with the ability to exchange information (for example, share data with (possibly only subject to the consent of the patient) and receive data from) paying organizations, such as insurance companies, Medicare, etc.

- 16 040777

The data analysis engine may be configured to analyze data collected or accessed by patient mobile devices and/or medical record data to gain insight into a patient's behavior or symptoms associated with a disease or condition. The analyzed data may be unique to an individual patient and used to obtain information specific to that patient. For example, by analyzing the glucose log of a patient with diabetes, the data analysis engine can determine that the patient has a tendency to hyperglycemia or hypoglycemia under certain conditions, for example, at certain times of the day, after eating certain types of food, on certain days of the week when the patient is in or on the way to certain geographic locations, before/during/after certain types of physical activity and other types of conditions. Based on these findings, the data analysis engine can take various actions, such as notifying the patient's HCP, offering the patient educational content related to observed episodes of hyper- or hypoglycemia, or prompting the patient to change his/her behavior at a specific time or location when or where they are likely to have the greatest effect (for example, by asking the patient to take the medication just before bedtime, right after exercise, or while en route to/from a specific geographic location).

The HRS activity area 602 of the interconnected system 600 includes the HRS system 102 and the healthcare IT system 118, and as indicated in FIG. 6 allows clinicians to order products from a company or other organization that operates the C3 server system 106, access information about such products, and integrate existing systems and methods into their existing clinical workflow.

The patient activity area 604 of interconnected system 600 includes a mobile device 104 performing MMA 568, a patient 124, a glucometer 126, an attached injection device 134, and a variety of other patient-related medical devices such as a blood pressure monitor or other meter and etc. In the patient area 604 of the interconnected system 600, the purposes of the present systems and methods include, as indicated in FIG. 6, providing relevant and valuable decision support to reduce patient burden and improve outcomes.

The community management activities area 606 of interconnected system 600 includes computing hardware (possibly similar in physical architecture to HCP system 102) as well as an EMR/HIE (Health Information Exchange) system for proper storage and maintenance of personal medical data regarding patients. . In the stakeholder management activities area 606 of the interconnected system 600, the objectives of the present systems and methods include, as indicated in FIG. 6, enabling clinical and financial stakeholders (payers, healthcare systems, etc.) to assess the populations involved and better serve high-risk patients.

The care management activity area 608 of the interconnected system 600 also includes computer hardware similar to that used in the HCP system 102, as well as its own EMR/HIE system, and is typically designed for remote monitoring and clinical decision support (CDS, clinical decision support) which includes what is often referred to as the medical team for a given patient. Such a medical team may include a number of distinct HCPs (different types of physicians, different types of nurses, therapists, caregivers, etc.) performing various functional responsibilities that are all related to health. and well-being of the patient. In the care management activities area 608 of the interconnected system 600, the purposes of the present systems and methods include, as indicated in FIG. 6, enabling the medical team to identify patients and prioritize patients in need of care, as well as provide direct interaction between the patient and the medical team.

In at least one embodiment of the invention, additional MMA is provided that allows caregivers, loved ones, and/or the like. persons to access some or all of the data received, recorded, monitored or entered by the patient 124 using the MMA 568. In at least one such embodiment of the invention, the person using the additional MMA can view the patient log (which includes, for example, glucose measurements, dosing information, food-related information, and/or the like), as well as the prescribed dosing schedule(s) and/or any other type of data that those skilled in the art deem appropriate for the given implementation. The amount and/or types of data that can be viewed with the optional MMA can be set to default values, and can also be adjusted by the HCP, patient 124, and/or one or more other people, depending on the design parameters of a given implementation.

In accordance with the present systems and methods, the C3 server system 106 provides and

- 17 040777 supports a number of design features that contribute to the achievement of the above and other goals in the interconnected system 600. One of these design features is data storage, since the C3 server system 106 in at least one embodiment of the invention securely stores data, which allows the system 102 NSR and MMA 568 communicate securely with each other. The C3 server system 106 further allows MMA users to securely back up their medical data and achieve data consistency across a number of devices (e.g., in embodiments where the MMA application 568 creates an instance on mobile device 104, and possibly also on another mobile device associated with the patient 124, which may have both a smartphone and a tablet, which is quite common, and/or in embodiments of the invention in which the patient 124 has access to similar functions and information using, for example, a web portal, which is also commonly implemented in the art).

In various embodiments of the invention as described herein, the HCP, using the HCP system 102 and the C3 server system 106, establishes drug dosing schedules and sends them to the MMA 568 using the secure data communication capabilities of the C3 server system 106. In addition, in various embodiments of the invention, the C3 server, using the HCP system 102 and/or MMA 568, makes available data regarding the patient in chronological order, the status of the drug dosing regimen, and the like. In addition, in at least one embodiment of the invention, secure communication (i.e., messaging functionality or mailbox functionality) is provided by the C3 server system 106 between the HCP using the HCP system 102 and the patient 124 using the MMA 568 and mobile device 104. In addition, in various embodiments of the invention, the C3 server system 106 facilitates software updates, revocation notifications, and/or other functions that those skilled in the art deem appropriate for a given implementation or in a given context.

I. Typical operation.

A. NSR Portal.

Fig. 7 depicts an exemplary method 700 that may be performed by a C3 server system 106 in accordance with at least one embodiment of the invention. It should be understood that the description of C3 server system 106 implementing method 700 provided herein is provided for illustration and not limitation, and that method 700 may be implemented by any device or set of devices that is suitably equipped, programmed, and executed with relevant possibilities.

At step 702, the C3 server system 106 presents, via the HCP portal 572, using the user interface 208 of the HCP system 102, a number of drug dosing schedules related to the patient 124. In at least one embodiment of the invention, each of the presented drug dosing schedules associated with the corresponding, different from the others, dosing algorithm for drugs. Typical treatment regimens and drug dosing algorithms will be discussed in more detail below.

Any one or more of the presented drug dosing regimens may be what is known in the art as an open-loop regimen or a feedback regimen. In general, a feedback treatment regimen can be said to iteratively adjust doses (e.g., amount, timing, and/or the like) of one or more drugs in an automated fashion, at least in part, based on an automatically sensed feedback flow, such as the results of a measurement (eg, glucose level) taken on a patient, while an open-loop treatment regimen does not allow automatic iterative dose adjustments of drugs. However, it is often the case that an open-loop dosing schedule takes into account similar data in chronological order in a more manual manner, when the patient manually enters the feedback flow parameters. An open-loop dosing regimen may also require the patient to manually control drug dosing. More generally, the present systems and methods are not limited to any particular type of drug dosing regimen, any particular drug or drug type, or any particular mode of delivery (e.g., parenteral, intravenous, oral, etc.) of the drug. drug to the patient.

At step 704, the C3 server system 106, using the HCP portal 572, obtains, using the user interface 208 of the HCP system 102, the selection of the HCP (for the patient 124) of at least one of the presented drug dosing regimens. In the terminology of this disclosure, the selected at least one treatment regimen is referred to as at least one selected HCP dosage regimen, at least one selected HCP treatment regimen, and/or the like. In at least one embodiment, the dosing regimens presented at 702 include one or more insulin dosing regimens, and at least one dosing regimen selected by the HCP includes

- 18 040777 at least one insulin dosing regimen selected by the HCP. Any number of regimens shown may be basal insulin dosing regimens, and any number may be bolus insulin dosing regimens. In some HCP cases, either a basal insulin dosing schedule or a bolus insulin dosing schedule is selected for patient 124. In some instances, the HCP will simultaneously administer to patient 124 both one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens.

In at least one embodiment of the invention, at least one selected HCP bolus insulin dosing regimen includes a type, which is referred to herein as a daily titration bolus insulin dosing regimen, which is associated with a type of dosing algorithm, which is referred to herein as algorithm bolus insulin dosing with daily dose selection. Other types of HCP bolus insulin dosing schedules that have been selected include the type that is referred to herein as the Fixed Dose Bolus Insulin Dosing Schedule, which is related to the type of dosing algorithm that is referred to herein as the Fixed Dose Bolus Insulin Dosing Algorithm; a type referred to herein as a bolus insulin dosing schedule using a carbohydrate bolus calculator, which is related to a type of dosing algorithm referred to herein as a bolus insulin dosing scheme using a carbohydrate bolus calculator; and the type, herein referred to as the bolus insulin dosing schedule using the carbohydrate per meal calculator, which is related to the type of dosing algorithm, referred to herein as the bolus insulin dosing algorithm using the carbohydrate per meal calculator. food. Examples of each of the above four types of non-feedback bolus insulin dosing schedules/algorithms are described in the appropriate subsection below.

In step 706, the C3 server system 106 transmits to the MMA 568 on the mobile device 104 associated with the patient 124, data about the treatment regimen selected by the HCP, which indicates at least one treatment regimen selected by the HCP at block 704. Although the exemplary method 700 has been described above as being implemented by C3 server system 106, method 700 may also be implemented directly by HCP system 102. In such embodiments, the HCP portal 572 may not be a web application hosted by the C3 server system 106 over a network connection, instead, the HCP portal 572 may comprise a user interface hosted locally and executed by the HCP system 102. In these cases, the HCP system 102 presents a number of HCP dosing regimens (step 702), accepts a selection of HCP from the presented dosing regimens (step 704), and transmits the data regarding the selected HCP treatment regimen to the MMA 568, all without any - either support from the system 106 C3 servers or exchange of information with this system. In such embodiments, the HCP system 102 can communicate directly with the mobile device 104 via the data network 108 without requiring that the data be transmitted or processed by the C3 server system 106 .

Regardless of whether method 700 is implemented by C3 server system or HCP portal 102, in at least some embodiments of the invention, MMA 568 is configured to provide, via user interface 308, drug dosage recommendations based on at least one schedule. treatment chosen by the HCP. In some embodiments, the MMA 568 presents a dialog box through the user interface 308, providing the patient 124 with options to accept or decline the recommended (ie, prescribed) drug dosage regimen. In at least one embodiment of the invention, the C3 server system 106 is configured to turn off the MMA 568 in response to receiving a regimen rejection indication indicating that the MMA 568, via the user interface 308, has received a patient rejection indication associated with at least at least one selected HCP treatment regimen. Disabling MMA 568 may include restricting a user's access to some or all of the functionality of MMA 568, or restricting a user's access to some or all of the data stored in MMA 568. For example, disabling MMA 568 may include restricting a user's ability to access or use drug dosing regimens prescribed or recommended by the HCP. In other cases, the C3 server system 106 instead receives a treatment regimen confirmation indication indicating that the MMA 568, via the user interface 308, has received a patient confirmation indication associated with at least one selected HCP treatment regimen.

In at least one embodiment of the invention, it is the MMA 568 receiving data on the selected HCP treatment at step 706 that unlocks at least one selected HCP treatment on the MMA 568. In some cases, this unlock includes the MMA 568, which is allowed access to the data. in relation to the implementation, already stored on the mobile device 104 (potentially as part of the MMA 568), for at least one selected HCP treatment regimen, only after receiving data in relation to the selected HCP treatment regimen. In other implementations, this unlocking includes the transition of the MMA 568 from non-functional to functional.

- 19 040777 state for downloading implementation data for at least one selected HCP treatment regimen only after receiving data for the selected HCP treatment regimen. In these implementations, implementation data for at least one selected HCP treatment regimen may be downloaded from the C3 server system 106 and/or the HCP system 102.

In some instances, this release occurs only in response to the MMA 568 receiving, via the user interface 308, a patient confirmation indication of at least one selected HCP treatment regimen. Allowing MMA 568 to unlock or download a particular HCP-selected regimen only after receiving data on the HCP-selected regimen may be useful in enforcing FDA (Food and Drug Administration) regulations. Administration) USA. Such FDA regulations may require that certain drug dosing regimens be available to a patient only on the prescription of a qualified and licensed physician. By limiting access to the drug dosing regimen until data is available regarding the selected HCP treatment regimen, MMA 568 in such embodiments ensures that patients cannot access the drug dosing regimen without the required prescription.

Embodiments of the invention that store implementation data for all treatment regimens submitted by the HCP and selected by the HCP at steps 702 and 704 on the mobile device 104 (e.g., as part of the MMA 568) and unlock one or more treatment regimens on the mobile device only after obtaining data regarding the selected HCP treatment regimen transmitted at step 706 provides several technical advantages that increase the efficiency and/or functionality of the present systems and methods. For example, storing implementation data for all treatment regimens on mobile device 104 provides the HCP with the ability to activate a particular assigned treatment regimen on a patient's mobile device 104 without requiring mobile device 104 to download potentially significant additional implementation data for the assigned treatment regimen. This allows the patient to more easily access and implement the prescribed treatment regimen if the patient's mobile device 104 has only a short-lived or low-speed communication channel 112 with the data network 108 (for example, in the event of a network failure or if the mobile device is put into flight mode).

Embodiments of the invention that include aggregation of implementation data for all treatment regimens as part of MMA 568 also allow MMA 568 to be hosted, for ease of patient access, in some popular online mobile application repositories. Such online mobile application repositories may include repositories operated by third parties other than the organization(s) that owns, maintains, and/or is associated with the HCP system 102, administrator portal 148, or patient 124; such online mobile application repositories may include the App Store operated by Apple, Inc. or Google Play operated by Google LLC. Such online repositories typically require that published applications include all implementation logic at the time of publication. In other words, to ensure the security and stability of applications running on mobile devices, administrators of such online repositories may prevent application developers from updating or changing the code of published applications unless each update is submitted, reviewed, and/or approved by a third party. (like Apple or Google) that supports online repositories. As such, embodiments of the invention that include downloading implementation data to mobile device 104 each time a new treatment regimen or dosing algorithm is prescribed may require a time-consuming third party submission, review, and/or approval process. This is a problem that is unique and specific to the field of medical mobile applications that provide access to drug dosing regimens that, according to FDA regulations, should only be available to patients who have been prescribed. By aggregating implementation data for all regimens as part of MMA 568 at the time of publication, and by selectively releasing the assigned treatment regimen only after data on the selected HCP regimen is received, MMA 568 avoids such time consuming submission, review and/or approval every time the patient is prescribed a new dosing regimen for drugs. This association also increases the safety and stability of MMA.

As described above, in at least one embodiment of the invention, the MMA 568 is communicatively connected, via its central mobile device 104, to one or more insulin delivery devices and/or insulin monitors associated with the patient 124 An example of such an insulin monitoring device is a glucose meter 126. In at least some embodiments of the invention, in which the MMA 568 is communicatively connected to an insulin delivery device associated with a patient 124, the MMA 568 communicates with the device. for administering insulin to perform at least one selected HCP treatment regimen. An example

- 20 040777 such device for administering insulin is the connected device 134 for injection. In some embodiments, the C3 server system 106 and/or the HCP system 102 receive patient data, examples of which (such as insulin injection record data and glucose measurement data) are described herein, transmitted by the MMA 568 from the administration device. insulin and/or an insulin monitor.

V. MMA on your mobile device.

In FIG. 8 depicts an exemplary method 800 that may be implemented by a mobile device 104 performing MMA 568 in accordance with at least one embodiment of the invention. It should be understood that the description herein of method 800 as implemented by MMA 568 running on mobile device 104 is provided by way of illustration and not limitation, and that method 800 may be implemented by any device or set of devices that is suitable. properly equipped, programmed and executed with the appropriate capabilities.

In step 802, the MMA 568 obtains HCP-selected treatment regimen data that indicates that the HCP has selected at least one drug dosing regimen from a number of drug dosing regimens, each associated with a respective, distinct dosing algorithm. medicines. In at least one embodiment of the invention, HCP selection for patient 124 has been made using HCP system 102 (e.g., using a web interface (HCP portal 572) provided by C3 server system 106 and accessible by HCP using HCP system 102). As described above, MMA 568 can receive data regarding the selected HCP treatment regimen directly from the HCP system 102 or, as described in this example, from the C3 server system 106 . The at least one selected HCP dosing regimen may include any of the possible regimens or combinations of regimens described herein. At step 804, MMA 568 unlocks the indicated HCP-selected dosing regimen to MMA 568, responsive at least in part to the receipt of data regarding the selected HCP regimen at 802. As previously discussed, in at least one embodiment step 804 includes accessing previously unavailable implementation data for the selected HCP treatment regimen that has been previously stored on mobile device 104. Such embodiments of the invention may be useful, at least for the technical reasons discussed above. In some embodiments of the invention, step 804 includes downloading previously unavailable implementation data for the selected HCP treatment regimen.

In at least one embodiment of the invention, after performing step 802 and before performing step 804, MMA 568 presents, using the user interface 308 of the mobile device 104, a dialog box for patient confirmation or patient rejection of at least one selected HCP dosing regimen, and then receives user input using the user interface 308 corresponding to the presented dialog box; in at least one such embodiment, MMA 568 executes step 804 because the user input received is indicative of patient confirmation of at least one HCP selected dosing regimen. In addition, in at least one embodiment of the invention, the MMA 568 transmits the received user input to the C3 server system 106 and/or the HCP system 102.

In at least one embodiment of the invention, in which the prescribed regimen is or includes a bolus insulin dosing regimen, upon receipt of a patient confirmation indication indicating that the user has accepted the prescription of the dosage regimen, the MMA 568 provides the user with an opportunity to enter the workflow. during which, in at least one embodiment of the invention, the MMA 568 prompts the user to select a meal time, prompts the user to enter and/or confirm their glucose measurement result, and accordingly provides the user with bolus recommendations. The user may indicate to the MMA 568 that he has taken the recommended dose, in which case the MMA 568 will record in the memory that the recommended dose has been taken. Alternatively, the user may indicate to the MMA 568 that they have taken a dose of insulin that is different from the recommended dose, and the MMA 568 will record the amount of insulin actually taken. The record may include a value for the time the dose was taken, which may be automatically set to the time the confirmation is received from the user, or a time value specified by the user.

In at least one embodiment, the MMA 568 is communicatively connected via mobile device 104 to an insulin delivery (and/or glucose monitoring) device associated with the patient; in at least one such embodiment, the MMA 568 communicates with the insulin delivery device to perform a selected HCP treatment regimen or to obtain dose information administered

- 21 040777 by the patient manually using an insulin delivery device. In at least one embodiment, the MMA 568 receives patient data from the insulin delivery device and relays the received patient data to the C3 server system 106 and/or the HCP system 102. Patient data may include insulin injection record data (for example, which includes time and amount of insulin administered in previous doses) and/or glucose measurement data, among a number of other examples that may be listed. in this document. In at least one embodiment, the MMA 568, using the user interface 308 of the mobile device 104, provides drug dosage recommendations based on the selected HCP treatment regimen.

In at least one embodiment, the MMA 568 may include a safety feature that notifies the patient if it detects that the patient may be taking an unsafe or incorrect dose. For example, MMA 568 can calculate the expected base amount of drugs expected for each dose. This base dosage can be determined in several ways. For example, the basal dose may be a predetermined amount of drugs programmed by the HCP and/or the patient, or it may be algorithmically and automatically generated based on medical or biographical information regarding the patient (e.g., gender, age, weight, type, and severity of illness). and so on.). The basal dosage may also be derived from a moving average, most likely value, or median of a specified number of previous doses (e.g., the last three, five, ten, or more doses) or doses taken in a previous rolling time period (e.g., the last three, five, ten or more days). In some embodiments of the invention, the base dosage may vary depending on the time of day or upward or downward trends found in previous doses. Before recommending a dose based on the chosen HCP treatment regimen, MMA 568 can compare the recommended dose with that base dose. If the MMA 568 finds that it is recommending a dose that differs significantly from that base dose, for example, if the recommended dose differs from the base dose by a certain absolute number of drugs or by a certain percentage, the MMA 568 may alert the patient and prompt him/her to confirm the dose. For example, it is possible that the recommended dose is based on incorrectly entered patient input data, such as incorrectly entered active insulin parameters, single meal values, or current glucose levels. Alternatively, or in addition to this, if the user indicates to the MMA that he/she plans to take a different amount of medication than the recommended amount, the MMA 568 can similarly determine if the user-specified amount differs significantly from the base dosage. If the user-specified amount is significantly different, the MMA 568 can alert the patient that the dose indicated is significantly higher or lower than the base dose. This additional dialog box and warning can help alert the user that they are about to take an unsafe or incorrect amount of medication. If necessary, the user can ignore the warning.

In at least one embodiment of the invention, the MMA 568 provides at least the following two levels of access: public access, available to anyone to download, self-registration and use; and prescribing access, which provides additional functionality that is unlocked by electronic prescribing of the drug dosing schedule. In one embodiment, sharing offers features that include (i) logging of data related to diabetes, which may include glucose (GL), basal insulin, bolus insulin, carbohydrate input, and exercise/stress factors /diseases, as examples, and (ii) access to visualizations (e.g., graphs) of user data, while in one embodiment, prescription access unlocks bolus insulin dose recommendations by implementing a drug dosing schedule. In some embodiments of the invention, the appearance of the MMA 568 user interface changes depending on whether the MMA 568 is in shared mode or in destination access mode (and/or possibly other modes). Such changes may include, but are not limited to, additional and/or fewer menu items, color scheme changes, symbology changes, layout changes, and/or the like.

In at least some embodiments of the invention, the shared (non-assigned) mode of the MMA 568 provides one or more of the following design features.

Data input.

The user can enter data related to diabetes to make it easier to track and view HSR data.

The user can enter bolus insulin doses, basal insulin doses, glucose readings (manually or wirelessly with the meter), and consumption.

- 22 040777 carbohydrates.

The user can also register the following modifiers, if applicable, and yes/no character tokens for: activity, stress, illness, steroids, and menstruation.

The patient can enter values into their MMA such as glucose values (automatic from a sensor or manually), current activity level, current food eaten, food carbohydrate content, physiological characteristics such as body weight, etc.

Digital registration log.

The user can track diabetes related data so that all their data is easily accessible and viewable in one place.

The user can view any data entered in digital log format.

Pairing a glucometer.

Simplifies the process of entering glucose readings for users who want to keep all their data in one place or want to use glucose data to get dosage recommendations.

The user can select a device pairing option such as pairing a glucometer, continuous glucometer, fast glucose monitor, or other glucose monitor. Once the user has connected their glucose monitor, the MMA will display their most current glucose reading while the user navigates to the bolus recommendation workflow (only available in prescription mode) or the flow data entry operations (available in shared mode).

Users can pair with connected meters that comply with the Continua Standard (also known as the Continua Design Guidelines) published by the Personal Connected Health Alliance (PCHAlliance) of Arlington, Virginia.

In some embodiments of the invention, users can conduct experiments by performing actions and measuring the effect on their glucose levels. Users can view the results of the experiments they have done. Such experiments may be based on activity, food and/or other factors. In some embodiments of the invention, third-party data sources (eg, HealthKit, FitBit, and/or the like) create experiments for users. Indeed, in some embodiments, the MMA may connect and communicate with wearable devices such as FitBit, Apple Watch, and/or the like) to facilitate tracking and/or integration of information regarding one or more physiological parameters.

Data visualization.

The user can view the collected data for various periods of time to make the data more understandable.

The user can go to the MMA section, which contains the results of data visualization. Users can then select the type of data and time period they wish to view.

MMA will also show a pie chart of recorded glucose values to show numbers over range, in range, under range, and those that fall within hypoglycemic levels (<70 mg/dl).

Reminders.

Helps the user remember to check their glucose levels or enter the bolus recommendation workflow when their schedule is busy.

The user can set reminders for times when they would like to check their glucose levels and/or administer insulin. The user will receive a message on their mobile device with a reminder.

Familiarization.

User can register MMA and learn about useful features.

A user can register to use MMA by creating login credentials, entering basic information about themselves, and agreeing to the terms of use.

MMA will offer additional features (such as tutorials) to help users learn about useful features, which include pairing a glucometer or setting personalized reminders.

Diabetes education.

Helps the user to learn about their diabetes from authoritative sources.

The user can access a link to diabetes education from MMA. Among other possibilities, such a link can run within the MMA or launch a browser application.

C. Sample screenshots of the NSR Portal.

As described below, in FIG. 9-21 depict various screen shots of various different embodiments of the HCP system 102. Fig. 9 represents instant

- 23 040777 screenshot 900 of a HCP user working on the Method Selection [Drug] tab and in which four bolus insulin dosing schedules are listed as options for selecting HCP - these four bolus insulin dosing schedules are described in more detail below. In one embodiment of the invention, clicking on any of the diagrams presented presents a pop-up window that provides additional information. In at least one embodiment of the invention, when the HCP selects one of these four drug regimens, the HCP system 102 sends data regarding the selected HCP treatment regimen to the mobile device 104, which allows the patient to access the selected drug regimen on the mobile device.

Fig. 10 is a screen snapshot 1000 showing electronic health record (EHR) data pertaining to one exemplary patient, displaying various patient data in graphical form. In this screenshot 1000, the exemplary patient has not yet been assigned a drug dosing regimen.

Fig. 11 is a screenshot 1100 showing a warning message 1102 indicating that a proposed change in drug dosage recommendation, or prescription, is still pending patient confirmation. In this screen shot 1100, the patient is not assigned current drug dosing regimens and has no historical records of glucose values or dosing information. The patient has been assigned a fixed meal bolus dosage method, but has not yet taken the prescribed drug method.

Fig. 12 is a screenshot 1200 showing a warning message 1202 indicating that a proposed change in drug dosage recommendation, or prescription, is still pending patient confirmation. In this screenshot 1200, the patient was previously assigned a bolus insulin dosing schedule using a carbohydrate bolus calculator, but is now assigned a fixed bolus insulin dosing schedule. The patient has not yet accepted the newly prescribed drug regimen.

Fig. 13 is a snapshot 1300 of a screen showing the Configure Settings tab, where the selected drug dosing schedule is a bolus insulin dosing schedule with daily titration, also simply referred to as a daily titration regimen. As shown in FIG. As shown in Figure 13, the regimen options tab with daily dose selection allows the clinician to prescribe bolus dose options for three meals: breakfast, lunch, and dinner. For each meal, the HCP can choose between dosing, stable, and no. The dosing option causes the dosage recommended for this meal to be selected according to the algorithm described in this document below. The option stably allows the HCP to specify a fixed bolus for that meal. The no option means that no bolus is given at this time.

Fig. 14 is a screen snapshot 1400 showing the Review and Confirm tab, where again the selected drug dosing schedule is a Daily Dose Adjustment schedule. In this situation, the HCP can review and confirm the intended dosing regimen of the daily dose adjustment before prescribing it to the patient.

Fig. 15A and 15B are a snapshot 1500 of a screen showing the Configure Settings tab, where the selected drug dosing schedule is a Fixed Dose Bolus Insulin Dosing Schedule, also simply referred to as a Fixed Meal Dosing regimen. The HCP user is given the opportunity to confirm the proposed customizable details of the treatment regimen for a particular patient. For example, the HCP can customize bolus dosage settings for three time periods: (i) morning, (ii) afternoon, and (iii) evening and night. The value of the start time of each time period can be adjusted by the NDS. For each time period, the HCP user can select a target glucose level, an insulin sensitivity factor (described in more detail below), a bolus dose, options for considering various health factors (for example, activity, illness, stress, steroids and menstruation, described in more detail below), settings permission (which, if enabled, allows the patient to change their own prescription settings) and active insulin (described in more detail below).

Fig. 16 is a screen snapshot 1600 showing the Review and Confirm tab, where again the selected drug dosing regimen is a fixed meal dosing regimen. In this situation, the HCP can review and validate the proposed fixed dose meal regimen before prescribing it to the patient.

Fig. 17 is a screenshot 1700 of a screen showing the Configure Settings tab, where the selected drug dosing schedule is a bolus insulin dosing schedule using a carb based calculator.

- 24 040777 a single meal, which is also simply called a treatment regimen The amount of carbohydrates in a single meal. As shown in FIG. 17, the Meal Carbohydrate Regimen Options tab allows clinicians to prescribe bolus dose options for three time intervals: (i) morning, (ii) afternoon, and (iii) evening and night. The value of the start time of each time period can be adjusted by the NDS. For each time interval, the HCP user can select a target glucose level, an insulin sensitivity factor (described in more detail below), and an insulin to carbohydrate ratio (described in more detail below). Regardless of time periods, the HCP user can also select the expected number of grams of carbohydrates for each of Low, Medium, and High for a meal. Finally, the HCP user can choose the duration of action of the insulin.

Fig. 18 is a snapshot 1800 of a screen showing the Configure Settings tab, where the selected drug dosing regimen is a bolus insulin algorithm using a carbohydrate bolus calculator, also referred to simply as the Carbohydrate Counting treatment regimen. As shown in FIG. As shown in Figure 18, the Carbohydrate Recipe Options tab is similar to the Single Meal Carb Recipe Options tab, except it does not allow the HCP user to select the expected amount of carbohydrate grams for each of Low, Medium, and High for food intake.

II. Examples of open-loop bolus insulin algorithms and associated treatment regimens.

Some or all of the generic open-loop insulin bolus algorithms and associated regimens described in this document can calculate a recommended bolus based on Insulin on Board (IOB) active insulin. The IOB is a calculated value that describes the amount of insulin that is expected to still be active in the patient's body after previously administered bolus doses of insulin. This value can reduce the amount of insulin the algorithm recommends for the patient. IOB can be calculated using at least two different approaches.

The first approach can calculate the IOB by taking into account only that portion of the previous doses that was necessary to correct the glucose reading above the desired value. The single dose of insulin taken at a given point in time may be determined based on several parameters, which include any or all of the following: (i) the amount of insulin needed to correct a glucose reading that is above the desired value, (ii) the additional amount insulin needed to provide or account for the amount of carbohydrate consumed by the patient at meals shortly after, shortly before or at the time of the dose, and (iii) any adjustments (positive or negative) necessary to account for lifestyle or health factors that may affect the amount of insulin needed (eg, whether the patient is ill, whether the patient is exercising or planning to exercise, whether the patient is menstruating, whether the patient is taking steroids, and/or whether the patient is under stress). This first approach can calculate the IOB considering only the parameter (i), i.e. the amount of insulin needed to correct a glucose reading that is higher than the desired value. When calculating IOB, the first approach may ignore either parameters (ii) or parameters (iii). The second approach allows you to calculate the IOB taking into account all the insulin that was taken as part of the previous doses. In other words, the second approach calculates IOB taking into account not only parameter (i), but also parameter (ii) (i.e. the amount of insulin needed to provide the amount of carbohydrates in the meal), as well as parameter (iii) (any adjustments for health factors). This second approach usually results in a higher calculated IOB, unless the negative adjustments from parameter (iii) override the positive contribution of parameter (ii).

Of course, other approaches to calculating IOB are also possible. For example, other approaches may calculate IOB with parameters (i) and (iii) but without parameter (ii). It is understood that references to residual active insulin or IOB in the following discussion may be calculated using any of the above approaches. In some embodiments, the HCP, the patient, or both may instruct the insulin dosing algorithm to use a certain approach to calculate the IOB. For example, the screen snapshot 1500 in FIG. 15B shows that the HCP can choose either the Conservative option for calculating active insulin (eg, IOB) or the Standard option. The Standard option corresponds to the first approach discussed above, while the Conservative option corresponds to the second approach. The MMA may include logic to allow IOB to be calculated using both the first and second approaches, and the patient, HCP, and/or both may be given a choice between the two approaches when calculating the recommended bolus.

A. Daily dose selection.

A typical daily dose titration algorithm and associated dosing regimen are described below.

- 25 040777 drugs.

The recommended doses start from the initial value established by the HCP when prescribing the dosing regimen. Default starting doses are 10% of total daily basal insulin for breakfast or lunch doses and 5% for dinner doses. The recommended doses for each subsequent day are calculated based on the glucose values recorded for the previous day. In other words, the recommended doses for the second day are calculated based on the glucose readings of the first day; the recommended doses on the third day are calculated based on the glucose readings of the second day, and so on. Some typical rules for calculating the recommended doses for each following day are given in the table below.______________________________

Dose for breakfast Dose for lunch Dose for dinner Initial dose: Dose 10% TBI Initial dose: Dose 10% TBI Initial dose: Dose 5% TBI GL before dinner Performance* Adjustments and doses Score and GL before dinner* Adjustments and doses Score and GL before going to bed* Dose adjustment >115 +1 and >115 +1 and >115 +1U 85-114 without changes 85-114 without changes 85-114 without changes 56-84 -1 and 56-84 -1 and 56-84 -1 and <56 -2U <56 -2U <56 -2U

Abbreviations: GL = glucose level, TBI = total basal insulin, U = units. ^Prior day's GL readings (mg/dL).

The generic daily titration regimen is suitable for users with T2DM (type 2 diabetes) aged 18 to 85 who meet the following criteria.

Glycemic targets cannot be achieved despite optimization of basal insulin, with or without metformin, intensification of dietary insulin treatment is required.

Those for whom the stated target glucose range of 85-114 mg/dL is appropriate.

In order to use a typical daily titration regimen, the HCP sets the following parameters:

total daily basal insulin (TBI), in units of insulin, initial starting dose and meal for dose adjustment, in units of insulin.

Additionally, the NSR can set the following parameters:

stable dose(s) per meal(s), in units of insulin. To calculate the recommended dose, MMA will use the following additional inputs:

current GL, in mg/dl: current GL is used by MMA to prevent insulin dose recommendation when the patient is hypoglycemic (glucose <70 mg/dl).

Pre-meal GL (GL), in mg/dl: Pre-meal GL is GL taken after dose adjustment on the previous day.

In at least one embodiment of the invention, the typical daily titration regimen does not take adjustment doses, IOB (residual active insulin), or adjustment factors as input to the calculation of the recommended dose.

The MMA 568, in at least one embodiment of the invention, provides recommendations for initiating and titrating basal insulin dosage for one meal at a time using patient-entered glucose values, and is intended to be used in this way multiple times a day under the guidance of an HCP to enter glucose values. and receive dosage recommendations.

B. Fixed dose.

An exemplary fixed dose algorithm and associated treatment regimen is described below. This fixed dose algorithm may allow the HCP to set a "fixed" amount of bolus per meal, allowing for any adjustments necessary to correct the patient's glucose level beyond the required range. Meal choices may include no food (eg, corrective dose only), breakfast, lunch, or dinner. The HCP may assign a fixed dose value for a single meal, the same fixed dose value for multiple meals, or different fixed dose values for multiple meals. The drug dosing regimen may include dose adjustment for residual active insulin (IOB), adjustment of glucose (GL) levels above or below the target GL level, and factors

- 26 040777 life or health events (such as exercise, stress, disease, steroids, or menstruation).

A generic fixed dose regimen may be suitable for users with type 1 diabetes mellitus (T1DM) or type 2 diabetes mellitus (T2DM) who are just starting bolus therapy or need bolus dose optimization. In some cases, the user may require a number of daily injections of food insulin with a rapid-acting insulin analogue.

In order to use a typical fixed dose regimen, HCPs can set the following parameters:

fixed dose (FD) in units of insulin per type of diet selected by the patient, target GL (GLT), in mg/dl, insulin sensitivity factor (ISF), in mg/dl/unit of insulin, duration of action of insulin (ID, Insulin Duration ), in hours.

In some embodiments of the invention, the HCP can control whether users can change their specific treatment regimen settings. For example, the user may not be able to change the insulin to carbohydrate ratio unless such change has been authorized by the HCP. And, of course, other examples could be listed in this document. In addition, in some embodiments of the invention, the HCP may activate any, all, or none of the following lifestyle modifiers and set the appropriate adjustment amount. When enabled, lifestyle modifiers allow an MMA patient user to indicate, for example, through the user interface of their mobile device, whether they are exposed to certain conditions that may affect the amount of insulin their body needs - such conditions include, for example: if he/she is exercising or engaging in physical activity, if he/she is stressed, if he/she is ill, if he/she is taking steroids, or if she is menstruating. For each of these lifestyle modifiers, the NDS sets a percentage adjustment value. The percentage value is converted to a decimal value for use in the equation. If the HCP does not enable the use of the modifier, the drug dosing schedule will use the value 0.

Activity factor (AF, Activity factor), in percent.

Stress factor (SF, Stress factor), in percent.

Illness factor (IF), in percent.

Steroid factor (StF, Steroid factor), in percent.

Menstruation factor (MF, Menstruation factor), as a percentage.

To calculate the recommended dose, MMA will use the following additional inputs:

meal selection (without food, breakfast, lunch, dinner) to determine the FD value, in insulin units, current GL (GL), in mg/dl, current time (t), in hours.

Note: The current time may include hours, minutes, and seconds, but may be used in calculations as fractions of hours.

Residual active insulin (IOB), i.e. all insulin doses that are still active in the current time period will be included in the calculation. The previous dose is considered active if it was taken less than ID (duration of action of insulin) hours ago. In some embodiments of the invention, previous doses can be calculated using the following parameters:

delivered bolus (DB, Delivered Bolus), in units of insulin, time of bolus administration (t _DB ), in hours, multiplication factor (X),

X = 0 when the previous individually delivered bolus was delivered less than 0.5 hour before,

X = 1 when the previous individually delivered bolus was delivered more than 0.5 h and less than ID h.

As previously discussed, the DB parameter in the IOB calculation can be determined in one of two ways for a particular previously administered dose of insulin. According to these two methods, the DB parameter can be set to (i) only a fraction of the previous glucose correction dose, or (ii) the total amount of insulin delivered in the previous dose. Option (i) corresponds to the first approach discussed above and is also referred to herein as the Standard Option in FIG. 15V. With this option, the fraction of the previous dose for glucose correction can be calculated gl _db -gl _t as w' where GL _DB is the GL administered at the time the previous dose was calculated, GLT is the target GL, and ISF is the sensitivity factor to insulin (discussed below). Option (ii) corresponds to the second approach discussed above and is also referred to herein as the Conservative Option in FIG. 15V. The NCP can choose which of these two methods to use to calculate

- 27 040777 parameter DB, as shown in FIG. 15V. Alternatively, the patient, or both the HCP and the patient, may be able to specify which method should be used to calculate the DB parameter.

In a typical fixed dose regimen, the recommended dose (RD) of bolus insulin can be calculated using the following formula:

/ GL - GL _T \

RD = \ FD + --- C * (1 + AF + SF + IF + StF + MF) \ ISF / v/Λ _v (t - t _DB ) - 0.5 \ - Σ P ¹ - ^x * ID - 0.5)* ^DB )

GL-GL _T

The term FD is the fixed dose portion of the formula. The term isf is a portion of a dose-correcting formula, eg, a portion of a formula that adjusts a recommended dose based on the amount by which a patient's glucose (GL) level exceeds a target glucose level (GLT). ISF is an insulin sensitivity factor that measures how much one unit of insulin (eg rapid-acting insulin) is expected to lower a person's glucose levels. Typically, to correct high glucose levels, one unit of insulin is required to lower glucose levels by 50 mg/dL. However, this decrease in glucose levels can also be from 15 to 100 mg/dl or more, depending on individual insulin sensitivity and other circumstances.

The term (1 + AF + SF + IF + StF + MF) takes into account the previously discussed lifestyle factors.

Σ ((1 - Ύ * * db\

The term V ^ID ~°· ⁵ ' J takes into account the IOB from all previous doses.

The following considerations apply to the formula.

The fixed dose value will be 0 if the patient does not choose to eat; however, the patient will still receive a corrective dose if applicable.

(GL-GL _T \

The corrective dose V isf J can be positive, negative or have a value of 0.

Any ^{v ID 0.5} ' IOB calculation can be positive or have a value of 0. If IOB is negative during calculation, MMA will use a value of 0 units of active insulin.

If the calculated recommended dose is negative, then MMA will recommend 0 units of insulin. Alternatively, the MMA may advise the patient to eat a certain amount of carbohydrate if the MMA detects that the patient is or is about to enter a hypoglycemic state and/or if the MMA determines that the patient has too much IOB (residual active insulin, i.e. the amount of insulin within the patient system). In some embodiments, the MMA may direct the patient to administer glucagon or some other drug that raises the patient's glucose levels if the MMA determines that the patient is in or about to enter a hypoglycemic state.

This generic fixed dose regimen can reduce the complexity of bolus insulin dosing by allowing the user to receive dosage recommendations based on the fixed dose regimen as configured by the HCP. If the user has accepted the drug dosing plan assignment, they will enter the application and select the bolus recommendation workflow. They will select a meal, enter and/or confirm their glucose readings, select any additional modifiers such as a change in activity or stress, and receive a bolus recommendation. The fixed dose regimen takes into account the amount of insulin prescribed by the HCP to provide a meal, a correction dose based on current and target blood sugar levels, and residual active insulin based on the insulin's internal PKPD data.

C. Carbohydrate bolus calculator.

A typical carbohydrate bolus calculator algorithm and associated treatment regimen is described below.

The typical treatment regimen using the carbohydrate bolus calculator is based on the rules for ensuring the carbohydrate content of the meal, and this method is recommended in clinical guidelines as an individual way to match prandial insulin with food intake. Accordingly, it can be used at any time of the day and cannot be associated with a specific meal. It calculates your recommended insulin bolus based on insulin sensitivity, carbohydrate intake, GL target, and current GL. It will also take into account corrective doses, IOB, and additional adjustment factors.

The bolus can be calculated based on two factors: (i) the insulin needed to feed or provide carbohydrates, and (ii) the insulin needed to correct high blood sugar.

- 28 040777

The bolus for food or carbohydrate provision is based on the insulin to carbohydrate ratio (ICR). The ratio of insulin and carbohydrates shows how many grams of carbohydrates 1 unit of insulin provides or utilizes. Typically, one unit of rapid-acting insulin utilizes 12-15 g of carbohydrates; however, this parameter can vary from 4 to 30 or more grams of carbohydrates depending on individual insulin sensitivity. Insulin sensitivity can vary by time of day, from person to person, and is affected by physical activity and stress.

The Carbohydrate Bolus Calculator Generic Treatment Regimen is suitable for users with T1DM or T2DM who can accurately count carbohydrates or, in the opinion of the HCP, can learn to accurately count carbohydrates. In some cases, users may require a number of daily injections of food-grade insulin with a rapid-acting insulin analog.

In order to use a typical treatment regimen using a carbohydrate bolus calculator, the HCP can set the following parameters:

Target GL (GLT) in mg/dL, Insulin Sensitivity Factor (ISF) in mg/dL/unit of insulin, Insulin Carbohydrate Ratio (ICR) in grams of carbohydrate/unit of insulin, Insulin Duration of Action (ID), in hours .

In addition, the NSR may activate any, all, or none of the following lifestyle modifiers and set the appropriate adjustment amount. HCPs adjust for lifestyle factors using percentages appropriate for their patient. The percentage value is converted to a decimal value for use in the equation. If the HCP does not enable the use of the modifier, the drug dosing schedule will use the value 0.

Activity factor (AF), in percent.

Stress factor (SF), in percent.

Disease index (IF), in percent.

Steroid factor (StF), in percent.

Menstruation factor (MF), in percent.

To calculate the recommended dose, MMA will use the following additional inputs:

current GL (GL), in mg/dl, current time (t), in hours, carbohydrate intake (CHO, Carb intake) in grams of carbohydrates or food insulin (MI, meal insulin) in units of insulin.

Residual active insulin (IOB), i.e. all insulin doses that are still active in the current time period will be included in the calculation. The previous dose is considered active if it was taken less than ID (duration of action of insulin) hours ago. In some embodiments of the invention, previous doses can be calculated using the following parameters:

bolus delivered (DB), in units of insulin, bolus delivery time (t _DB ), in hours, multiplier (X)

X = 0 when the previous individually delivered bolus was administered less than 0.5 hour before,

X = 1 when the previous individually delivered bolus was delivered more than 0.5 hour and less than ID hours.

As discussed earlier, the DB parameter in the IOB calculation can be specified in several ways. For example, the DB parameter may be set to either (i) the total amount of insulin from the previous dose, or (ii) only a fraction of the previous dose for glucose adjustment.

The MMA user can choose to enter either carbohydrate intake (CHO) (eg, expected amount of carbohydrates in a meal) or dietary insulin (MI) (eg, expressed in units of insulin). If the MMA user chooses to administer dietary insulin, the MMA user may enter the number of units of insulin that the user expects the particular meal to provide. For example, if the MMA user does not know exactly how many grams of carbohydrates are in a particular meal, but knows from experience that a certain number of units of insulin should be sufficient to provide that type of meal, the MMA user may choose to enter the number of units of dietary insulin instead of the expected intake. carbohydrates. Depending on whether the MMA user is entering carbohydrate intake or dietary insulin, the formula below will be used to calculate the recommended dose. When the user enters a carbohydrate intake value, the recommended dose (RD) of the bolus insulin will be calculated using the following formula:

- 29 040777

(CHO\ where x icr / represents the carbohydrate intake portion of the formula.

When the user enters a food insulin value, the recommended dose (RD) of the bolus insulin will be calculated using the following formula:

/ GL - GL _T \

RD = (MI +——— ] * (1 + AF + SF + IF + StF + MF)

XISF /

V/^Λ v — / 111 — X *--———— I * DB I

- 0.5 JJ ,

where MI is insulin providing food intake.

The following considerations apply to the formula.

(GL-GLrX

The corrective dose x ^ISF / can be positive, negative, or have a value of 0.

„ , --- , „

Any calculation of x ^{to ID 0.5} '' IOB can be positive or have the value 0.

If IOB is negative during calculation, MMA will use the value of 0 units of active insulin.

If the calculated recommended dose is negative, then MMA will recommend 0 units of insulin. Alternatively, the MMA may advise the patient to eat a certain amount of carbohydrate if the MMA detects that the patient is or is about to enter a hypoglycemic state and/or if the MMA determines that the patient has too much IOB (residual active insulin, i.e. the amount of insulin within the patient system). In some embodiments, the MMA may direct the patient to administer glucagon or some other drug that raises the patient's glucose levels if the MMA determines that the patient is in or about to enter a hypoglycemic state.

The Carbohydrate Bolus Calculator Generic Treatment Plan helps reduce the complexity of bolus insulin dosing by allowing the user to receive dosage recommendations based on the bolus calculator treatment plan as configured by the HCP. If the user has accepted the drug dosing plan assignment, they will enter the application and select the bolus recommendation workflow. They will enter and/or confirm their glucose measurements, enter the amount of carbohydrate they intend to consume, select any additional modifiers such as a change in activity or stress, and receive a bolus recommendation. The user can choose to enter the number of units of insulin needed to provide a meal instead of the number of carbohydrates, using the treatment regimen to adjust doses and account for residual active insulin. The dosing schedule of the carbohydrate bolus calculator takes into account the amount of insulin to provide the estimated carbohydrate intake, the correct dose based on the current and target blood sugar level, the remaining active insulin, based on the internal insulin PKPD data.

D. Calculator based on the amount of carbohydrates per meal.

Below is a typical algorithm using a calculator based on the amount of carbohydrates per meal and the associated treatment regimen. The Meal Carb Meal Calculator Generic Dosing Schedule uses the functionality of the Carbohydrate Bolus Calculator Generic Treatment Schedule described above, with additional adjustments made by the HCP for small, medium, and large qualitative estimates of food carbohydrate content. For example, instead of prompting the MMA user to enter the expected amount of carbohydrates in the meal or the amount of dietary insulin, the MMA user can simply indicate whether his/her meal will be Low, Medium, or High. The MMA user's selection is then translated into an approximate amount of carbohydrates based on preset values (potentially configurable by the HCP and/or the MMA user) for a Low, Medium, or High meal.

The Meal Carbohydrate Calculator Generic Meal Regimen is suitable for users with T1DM and T2DM who can estimate the size of a meal and in particular the carbohydrate content of a meal. In some cases, the user may require a number of daily injections of food insulin with a rapid-acting insulin analog. In order to use a typical treatment regimen using the Meal Carbohydrate Calculator, HCPs may set the following:

- 30 040777 parameters:

Target GL (GLT) in mg/dL, Insulin Sensitivity Factor (ISF) in mg/dL/unit of insulin, Insulin Carbohydrate Ratio (ICR) in grams of carbohydrate/unit of insulin, Insulin Duration of Action (ID), in hours , estimated carbs in the Small Meal Size, in grams of carbs, estimated carbs in the Medium Meal Size, in grams of carbs, estimated carbs in the Large Meal Size, in grams of carbs.

In addition, the NSR may activate any, all, or none of the following lifestyle modifiers and set the appropriate adjustment amount. HCPs adjust for lifestyle factors using percentages appropriate for their patient. For use in an equation, the percentage value is converted to a decimal value. If the HCP does not enable the use of the modifier, the drug dosing schedule will use the value 0.

Activity factor (AF), in percent.

Stress factor (SF), in percent.

Disease index (IF), in percent.

Steroid factor (StF), in percent.

Menstruation factor (MF), in percent.

To calculate the recommended dose, MMA will use the following additional inputs:

current GL (GL), in mg/dl, current time (t), in hours, carbohydrate intake for meal size (MS, meal size), as a choice of small, medium, large, or no meals.

Depending on the HSR preset for the selected meal, MMA will replace the size of the single meal with the appropriate number of grams of carbohydrates. If the patient chooses the no-meal option, then MMA will replace the single meal size with a value of 0.

Residual active insulin (IOB), i.e. all insulin doses that are still active in the current time period will be included in the calculation. The previous dose is considered active if it was taken less than ID (duration of action of insulin) hours ago. In some embodiments of the invention, previous doses can be calculated using the following parameters:

bolus delivered (DB), in units of insulin, bolus delivery time (t _DB ), in hours, multiplier (X)

X = 0 when the previous individually delivered bolus was administered less than 0.5 hour before,

X = 1 when the previous individually delivered bolus was delivered more than 0.5 hour and less than ID hours.

As discussed earlier, the DB parameter in the IOB calculation can be specified in several ways. For example, the DB parameter may be set to either (i) the total amount of insulin from the previous dose, or (ii) only a fraction of the previous dose for glucose adjustment.

The recommended dose (RD) of bolus insulin will be calculated using the following formula:

ΓΏ ...... . . .

where \icrJ represents carbohydrate intake.

The following considerations apply to the formula.

/GL-GL _T \

Corrective dose \ ^ISF ' can be positive, negative or have a value of 0.

-x * * _db \

Any Ά ^{ID 0.5} '' IOB calculation can be positive or have a value of 0. If IOB is negative at the time of calculation, MMA will use a value of 0 units of active insulin.

If the calculated recommended dose is negative, then MMA will recommend 0 units of insulin. Alternatively, the MMA may advise the patient to eat a certain amount of carbohydrates if the MMA detects that the patient is or is about to enter hypothyroidism.

- 31 040777 lycemic condition, and/or if the MMA determines that the patient has too much IOB (residual active insulin, ie the amount of insulin within the patient's system). In some embodiments, the MMA may direct the patient to administer glucagon or some other drug that raises the patient's glucose levels if the MMA determines that the patient is in or about to enter a hypoglycemic state.

The Single Meal Carbohydrate Calculator Generic Meal Regimen can help reduce the complexity of bolus insulin dosing by allowing the user to receive dosage recommendations based on the Meal Meal Calculator Meal Recipe as configured by the HCP. If the user has accepted the drug dosing plan assignment, they will enter the application and select the bolus recommendation workflow. They will enter and/or validate their glucose measurements, select a meal size, select any additional modifiers such as activity or stress changes, and receive a bolus recommendation. The Meal Carb Calculator Dosing Scheme takes into account the amount of insulin to provide estimated carbohydrate intake, a correction dose based on current and target blood sugar levels, and residual active insulin based on internal insulin PKPD data.

Fig. 19 is a flowchart illustrating an exemplary process 1900 implemented using MMA running on a mobile device (eg, MMA 568 running on mobile device 104 or MMA 570 running on mobile device 532). The MMA uses process 1900 to collect information regarding the patient's condition and recommend an insulin dose according to which insulin dosing regimen has been administered and activated in the MMA.

In step 1902, the MMA receives glucose readings from the patient. This can be done in many ways. For example, in FIG. 20 shows a typical screenshot from an MMA, in which the MMA automatically syncs with an attached patient glucose sensor, such as a continuous glucose meter (CGM). As shown in FIG. 20, MMA can display the time the meter readings were taken from the connected meter (in this example 9:31am), the blood glucose level (in this case 355mg/dl), and also allow the patient to edit the blood sugar readings by pressing the button labeled Or edit your blood sugar. If the patient agrees with the glucose level received from the connected meter, or if the patient has finished editing the glucose level, the patient can touch the button labeled Confirm Blood Sugar Level, after which the MMA will record the submitted glucose level in the patient log.

Alternatively, the MMA may allow the patient to manually enter his or her glucose value, or initiate synchronization of the MMA with a connected meter. These methods for obtaining a patient's glucose value are shown in FIG. 21A, 21B and 21C. in fig. 21A, MMA prompts the patient to enter a value for his or her glucose level. If the patient touches the button labeled Enter Blood Sugar Level, the MMA will advance to the screen shown in FIG. 21B, where the patient can manually enter a value for his or her glucose level. After the patient enters a glucose value, they can press the Next button to instruct the MMA to write the entered glucose value to the patient's logbook. If the patient touches the button labeled Or sync with meter, then MMA proceeds to the screen shown in FIG. 21C, where the MMA is synced to the patient's connected glucometer (eg, BGM, CGM, or FGM). In this case, as shown in FIG. 21C, MMA receives a glucose level of 355 mg/dl from the patient's connected meter. Alternatively, if the patient touches the Or button, synchronize with the meter in FIG. 21B, MMA will also go to the screen shown in FIG. 21C. Once the MMA has received a glucose value from the connected meter, the patient can instruct the MMA to write the glucose value to the patient's log by pressing the Next button.

Returning to the consideration of FIG. 19, once the MMA receives the glucose readings, the MMA proceeds to step 1904. At this point, the MMA determines which drug dosing schedule has been administered and activated in the MMA. If a daily titration regimen has been administered/activated, process 1900 proceeds to 1906. If a fixed dose regimen has been administered/activated, process 1900 proceeds to 1908. If a carbohydrate bolus calculator dosing regimen has been administered/activated, process 1900 proceeds to block 1910. If the calculator's dosing scheme based on carbohydrate per meal has been assigned/activated, process 1900 proceeds to block 1912.

In step 1906 (used for a daily titration regimen), MMA receives from the patient a choice of meal type or time of day. For example, the illustrative screenshots shown in FIG. 22A-22C allow the patient to indicate whether he or she is going to take the dose at breakfast time (FIG. 22A), at lunch time (FIG. 22B), at dinner time (FIG. 22C), or at bedtime (FIG. 22D). ). MMA uses this information to calculate the recommended insulin dose according to the exemplary algorithms described above for the Daily Adjustment dosing regimen. In step 1908 (used for a fixed dose regimen), MMA receives from the patient a choice of food type, as well as any health factors that apply. For example, the illustrative screenshots shown in FIG. 23A-23D allow the patient to indicate whether he or she is going to take a non-meal dose (FIG. 23A), at breakfast time (FIG. 23B), at lunch time (FIG. 23C), or during dinner (Fig. 23D). Regardless of which diet the patient chooses, the patient can also choose any health factors they are currently exposed to, such as stress, activity, illness, steroids, and/or menstruation. MMA uses this information to calculate the recommended insulin dose in accordance with the generic algorithms described above for the Fixed Dose dosing regimen.

In step 1910 (used for a carbohydrate bolus calculator dosing schedule), the MMA receives the expected number of grams of carbohydrates the patient intends to consume and/or the expected number of food insulin units that the patient believes will be sufficient to provide the carbohydrates he or she intends to consume. The MMA also receives information from the patient about any health related factors. For example, FIG. 24A prompts the patient to enter the expected amount of carbohydrate intake in grams. The patient can enter the estimated amount of carbohydrates using the numeric keypad. As shown in FIG. 24B, the patient has indicated that he or she intends to consume 96 grams of carbohydrates. When the patient presses the Next button, MMA proceeds to the screen shown in FIG. 24C, where the patient can select any health factors he or she is currently exposed to, such as stress, activity, illness, steroids, and/or menstruation. After the patient has finished selecting health factors, they can press the Next button (not shown), which appears when at least one health factor has been selected. Alternatively, the patient can click the Skip button if the patient is not exposed to any of these health factors. If at least one health factor is selected, or if the patient presses the Skip button, the MMA proceeds to the screen shown in FIG. 24D. In FIG. The 24D MMA displays the selected amount of carbohydrate grams as well as any selected health factors for patient confirmation. The patient can confirm by pressing the Next button.

Alternatively, the patient may decide to administer the number of units of food insulin that the patient expects (based on experience, for example) to provide the meal he or she intends to consume. The patient can indicate to the MMA that he or she will administer food insulin by selecting the Food Insulin radio button in FIG. 24A. In the event that the Nutritional Insulin radio button is selected, MMA proceeds to the series of screens shown in FIG. 25A-25D. In FIG. 25A, MMA prompts the patient to enter the number of units of food insulin using the numeric keypad. For example, as shown in FIG. 25B, the patient has injected 12 units of food insulin. When the patient presses the Next button, MMA proceeds to the screen shown in FIG. 25C, where the patient can select any health factors he or she is currently exposed to, such as stress, activity, disease, steroids, and/or menstruation. Alternatively, the patient can click the Skip button if the patient is not exposed to any of these health factors. In FIG. 25D MMA displays, for patient confirmation, the selected number of units of dietary insulin, as well as any selected health factors. The patient can confirm by pressing the Next button.

Returning to the consideration of FIG. 19, note that in step 1912 (used for the Meal Carbohydrate Calculator Dosing Scheme), the MMA receives from the patient the choice of the size of the meal, as well as any health factors that apply. For example, the illustrative screenshots shown in FIG. 26A-26D allow the patient to indicate if he or she is going to take a non-meal dose (FIG. 26A), with a Small Meal (FIG. 26B), with a Medium Meal (FIG. 26C), or with a large meal (fig. 26D). These selected meal sizes translate into expected carbohydrates in accordance with the pre-established meal definitions described above. Regardless of which meal size the patient chooses, the patient can also choose any health factors they are currently exposed to, such as stress, activity, disease, steroids, and/or menstruation. MMA uses this information to calculate the recommended dose of insulin according to the typical algorithms described above for the Meal Carbohydrate Recipe Calculator. Returning to the consideration of FIG. 19, after collecting information from the patient in steps 1906, 1908, 1910 or 1912, the MMA proceeds to step 1914 where it calculates and presents the recommended insulin dose. Algorithms for calculating the recommended insulin dose differ depending on which drug dosing regimen is currently prescribed and activated, and have been described previously. The MMA then presents this dose to the user as shown in the exemplary screenshot in FIG. 27A (which in this example recommends a dose of 10 units of food insulin). The patient will also be given the option to edit the recommended dose, for example,

- 33 040777 touching the Edit dose button in FIG. 27A.

In step 1916, the MMA determines if the user has edited the recommended dose. If so, MMA proceeds to step 1918 where it updates the submitted dose. This process is shown in Fig. 27B, where the patient can increase the recommended dose by pressing the + button to the right of the presented dose, or decrease the recommended dose by pressing the - button to the left of the presented dose. When the patient finishes editing the recommended dose, they can click the Save button, which will return the patient to the screen shown in FIG. 27A. In the event that a daily titration regimen has been initiated/activated, the MMA may optionally display an additional message as shown in FIG. 27C, which reminds the patient that it is important to check his or her blood sugar level before the next meal, as the daily titration regimen uses this value to adjust tomorrow's insulin dose.

If the patient has not edited the submitted dose, the MMA proceeds to step 1920 where it determines if the user has confirmed the dose. Otherwise, MMA returns to step 1916. If so, MMA proceeds to step 1922 where it logs the dose. This process is shown in Fig. 27A and 27C, where the patient can confirm that he has taken a dose by pressing the button labeled I took this dose. When this button is pressed, the MMA records the dose presented in the patient log.

In FIG. 28 depicts an alternate user interface display 2800 showing the dose of insulin to be administered to the patient, is currently being administered to the patient, and/or has recently been administered to the patient. The dose of insulin may have been recommended by one of the insulin dosing regimens discussed previously, or may have been manually administered by the patient or adjusted by the patient. The user interface display 2800 may be displayed on the MMA instead of or in addition to the screenshots shown in FIG. 27A-27C. Alternatively, or in addition, the user interface display 2800 may be displayed on a drug delivery device, such as a visual screen mounted on an insulin pen.

The user interface display 2800 contains a number of panels. The panel may contain data displayed by the processor on a portion of the display screen. The first panel 2802 displays the number of units of insulin to be administered to the patient, is currently being administered to the patient, or has recently been administered to the patient - in the illustrated illustrative example, the first panel 2802 shows 3.5 units of insulin.

The second panel 2804 displays the amount of carbohydrate that is expected to be provided by the number of units of insulin displayed in the first panel. As used herein in the specification and claims, the amount X of carbohydrates expected to be provided by a given number of units of insulin Y should correspond to the estimated amount of carbohydrates that, when ingested by a diabetic patient, would require Y units of insulin to be delivered to the patient in order to maintain the patient's glucose level after ingestion of said amount of X carbohydrates to be the same as the patient's glucose level prior to ingestion of said amount of X carbohydrates. In the illustrated illustrative example, the second panel 2804 indicates that 28 grams of carbohydrates are expected to be provided by the 3.5 units of insulin represented. The amount of carbohydrates displayed on the second panel 2804 can be calculated by dividing the number of units of insulin displayed on the first panel 2802 by the insulin to carbohydrate ratio (ICR). The user interface display 2800 may use a default ICR value that applies to all patients, or a specific patient ICR value that is provided by the patient, caregiver, or HCP. In some embodiments, the ICR may be both patient-specific and time-of-day-specific if it is known that the ICR for a particular patient varies in a predictable pattern with time of day. In this illustrative example, if the ICR used by the user interface display 2800 is 0.125, then the number of grams of carbohydrates displayed on the second panel 2804 (28 g) can be obtained by dividing the number of units of insulin displayed on the first panel 2802 (3.5 units ) per ICR of 0.125.

The third panel 2806 indicates whether the carbohydrate amount displayed by the second panel corresponds to a small meal size or a large meal size. In the example shown in FIG. 28, this third panel 2806 takes the form of a spectrum that displays a range of meal sizes between a small meal size, a medium meal size, or a large meal size, and also includes an indicator 2810 that indicates where the amount of carbohydrate displayed by the second panel 2804 falls within this spectrum. In other embodiments (not shown), the third panel 2806 may simply display a letter, word, or symbol that indicates the classification of the meal. In the simplest case, a single meal can simply be divided into one of two categories: small or large. In some embodiments of the invention, a single meal can be divided into one of three categories: small, medium, or large. In other embodiments, a meal can be divided into four or more meal size classifications.

The third panel 2806 can be calculated based on adjustable parameters that are determined

- 34 040777 There are various classifications of the size of a single meal. For example, in embodiments that categorize meal sizes into three categories (e.g., small, medium, or large), such configurable parameters may include a minimum carbohydrate threshold for an average meal size (e.g., 30 g) and the maximum carbohydrate threshold for the average size of a single meal (for example, 60 g). Any amount of carbs that falls between these minimum and maximum carb thresholds can be classified as a medium-sized meal. Any amount of carbs that falls below the minimum carb threshold can be classified as a small meal, and any carb that rises above the maximum carb threshold can be classified as a large meal. Panels that include a spectrum displaying a range (as shown in FIG. 28) can also determine where to place the indicator based on these meal definitions, for example by scaling the placement of the indicator along the spectrum depending on the meal definitions. As discussed earlier, these meal size definitions can be customized by the patient, caregiver, or HCP.

The fourth panel 2808 displays the expected drop in the patient's glucose level as a result of administering the number of units of insulin displayed in the first panel 2802. In the depicted illustrative example, the fourth panel 2808 indicates that as a result of administering 3.5 units of insulin displayed in the first panel 2802, a drop in blood glucose of 75 mg/dl is expected. The drop in glucose level displayed by the fourth panel 2808 may be calculated by multiplying the number of units of insulin displayed by the first panel 2802 by the insulin sensitivity factor (ISF). The user interface display 2800 may use a default ISF value that applies to all patients, or a patient-specific ISF value that is provided by the patient, caregiver, or HCP. In some embodiments, the ISF value can be both patient-specific and time-of-day-specific if it is known that the ISF value for a particular patient varies in a predictable pattern with time of day. In this illustrative example, if the ISF value is 21.4, the expected drop in BG displayed on the fourth panel 2808 (75 mg/dL) can be obtained by multiplying the number of units displayed on the first panel 2802 (3.5 units) by the ISF , equal to 21.4. Although FIG. 28 displays a user interface display 2800 that includes all four panels 2802, 2804, 2806 and 2808, some embodiments of the invention may display only a subset of these four panels or may display additional panels. For example, some embodiments of the invention may include only the first panel 2802, the second panel 2804, and the third panel 2806, and may not display the fourth panel 2808. In other embodiments, the user interface display 2800 may include only the first panel 2802 and the fourth panel 2808, and may not display the second panel 2804 or the third panel 2806. In still other embodiments, the user interface display 2800 may include only the first panel 2802 and the second panel 2804. The panels need not be arranged in the same order, configuration, or with the same the same relative dimensions as shown in Fig. 28.

Regardless of which panels are displayed, all displayed panels can be updated as the user adjusts the number of units of insulin to be administered, is currently being administered, or has recently been administered.

Fig. 29 shows the user interface display sequence as the number of units of insulin is adjusted from 3.5 units on the 2900a display to 4.0 units on the 2900b display to 4.5 units on the 2900c display. As shown, the number of units displayed in the first panel changes from 3.5 in panel 2902a to 4.0 in panel 2902b and then to 4.5 in panel 2902c. Similarly, the amount of carbohydrates displayed on the second panel (see panels 2904a, 2904b, and 2904c), the meal size indicator on the third panel (see panels 2906a, 2906b, and 2906c), and the expected drop in glucose levels on the fourth panel (see panels 2908a, 2908b and 2908c) are automatically updated when the number of units of insulin changes.

Although the illustrative example shown in FIG. 29 shows an example in which the number of units of insulin is adjusted in increments of 0.5 units, this is not necessary. In general, the granularity with which the number of units can be adjusted in the disclosed user interface may depend on the granularity with respect to the dosage of the administration device with which the user interface is associated. If, for example, an administration device (such as an insulin pen) is capable of delivering different doses in 1.0 unit increments, then the user interface can also be configured to allow dose adjustment in 1.0 unit increments. If the administration device is capable of delivering different doses in increments of 2.0 units, then the user interface can also be configured to allow adjustment in increments of 2.0 units. The same is true for other dosage granularity of the inserter, eg 0.1 units, 5.0 units, or any other dosage granularity. exhibiting

- 35 040777 dosage granularity in the user interface according to the dosage granularity of the patient's administration device allows the patient to easily decide how to set the dose on his administration device. In some cases, the user interface may be designed to work with a number of types of administration devices that have varying degrees of granularity with respect to dosage. In such embodiments, the dosage granularity on the user interface can be configured by the patient, caregiver, or HCP to match the dosage granularity on a particular patient's administration device.

Displaying the number of carbohydrates provided, an indication of the size of a single meal, and/or the expected drop in glucose levels simultaneously with the number of units of insulin that must be administered / is currently administered / has recently been administered, provides several advantages for patients. Patients often inject insulin to provide a certain amount of carbohydrates, meet a certain meal size, or achieve a certain drop in glucose levels. By displaying some or all of this information to the patient, the patient can easily determine whether the displayed dose will achieve his or her goals and can adjust the displayed dose accordingly.

The simultaneous display of this information also solves a technical problem present in the user interfaces of prior art administration devices by reducing the possibility of overdosing or underdosing due to rounding errors. For example, when patients are trying to calculate a dose to provide a particular meal, patients often start with an assumption about the amount of carbohydrate in the previous meal. Once patients are receiving their intended amount of carbohydrates, patients will calculate the dose size based on the estimated amount of carbohydrates. However, when calculating the dose size, patients often round to the nearest unit or half unit of insulin, depending on the level of granularity regarding the dosage of their drug delivery device. This process requires the patient to go through two stages of rounding or estimating in order to obtain an insulin dose: the first stage, in which the patient estimates the amount of carbohydrates per meal, and the second stage, in which the patient converts this carbohydrate estimate into the number of units of insulin. This two-step process increases the risk of overdosing or underdosing to meet a given meal.

This is best illustrated using a typical scenario. Consider the case where a patient estimates that he is going to consume a meal with 75 g of carbohydrates. The patient comes to this assessment based solely on the appearance of the food and his previous experience. The user then calculates the dose based on an insulin to carbohydrate ratio of 8, resulting in a dose of 75 g/8 = 9.375 units. However, due to the granularity regarding the dosage of his administering device, he can only inject whole units of insulin, so he rounds up and injects only 9 units. In this case, if the patient underestimated the amount of carbohydrates in a meal (for example, if the patient's meal actually contained 80 g of carbohydrates earlier) and then rounded down, then the patient may have underestimated the amount needed to provide a meal by half. If such an insufficient dose of insulin is not compensated, it may make it difficult for the patient to achieve glycemic targets. By showing the amount of carbohydrate to be provided as well as the number of units of insulin, the user interface display reduces rounding errors. By calibrating between 9 units and 10 units on the user interface, the patient can quickly determine that 9 units provide 72 g of carbohydrates and 10 units provide 80 g of carbohydrates. The user can then evaluate whether the meal in front of them will be closer to 72g or 80g of carbs. Unlike the previously discussed scenario, which required two calculation or evaluation steps, this calculation includes only one simple patient evaluation step. This increases the chance that the patient will receive the correct dose to provide the amount of food that is in front of him. For example, before choosing between 72 g and 80 g, the patient may be more likely to decide that the amount of food in front of him is actually closer to 80 g, and may choose to administer 10 units of insulin.

The disclosed user interface may also reduce the possibility of rounding error in other scenarios, which includes situations where a patient makes dosage decisions not based on carbohydrates, but on meal size and/or target glucose drop. By displaying the size of a single meal and/or the estimated drop in glucose along with the presented insulin dose, the disclosed user interface similarly reduces the number of evaluation/rounding steps required for the patient and thus increases the chances that the patient will receive the correct dose to provide a particular meal, or in order to reach a certain glucose level.

As previously discussed, the disclosed user interface 2800 may be displayed when MMA is executed on a mobile device instead of or in addition to the previously disclosed screenshots in FIG. 27A-27C. However, in addition to this, the disclosed user interface 2800

-

Claims (41)

may also be displayed on a mobile device for drug administration, such as an attached insulin pen. One such exemplary implementation is shown in FIG. 30, which shows an attached insulin pen 3002 with a screen 3000 that displays the previously discussed user interface. Such an attached insulin pen 3002 can communicate wirelessly with a mobile device, such as mobile device 104, using Bluetooth, WiFi, NFC, or another wireless communication channel. Through this wireless communication channel, the connected insulin pen 3002 can receive various parameters for calculating information displayed using panels in the user interface, such as insulin and carbohydrate ratio (ICR), insulin sensitivity factor (ISF) and / or determinations size of a single meal, such as the minimum and maximum carbohydrate threshold for an average single meal (as discussed earlier). Fig. 31 is a flowchart illustrating an exemplary process performed by a mobile device (such as a smartphone or a drug administration device). At step 3102, the mobile device presents a number of panels at the same time using a visual display on the mobile device. These panels may include a first panel that displays the number of units of insulin being administered to the patient, a second panel that displays the amount of carbohydrate expected to be provided by the number of units of insulin displayed on the first panel, a third panel that indicates whether the amount of carbohydrates displayed by the second panel corresponds to a small meal, a medium meal or a large meal, and / or a fourth panel that displays the expected drop in the patient's glucose level as a result of the administration of the number of units of insulin that is displayed on the first panels. As discussed earlier, in some embodiments of the invention, not all four panels may be displayed, but only a subset of these panels. Some embodiments of the invention may also display additional panels. At 3104, the mobile device receives user input adjusting the number of units of insulin to be administered to the patient, currently administered to the patient, and/or recently administered to the patient. For example, this user input can be obtained using the plus or minus buttons on the MMA screen, similar to those discussed above in FIG. 27V, or using the digital keypad. Alternatively, user input may be obtained by turning the user's dial with a numeric dial on a connected insulin delivery device, such as an insulin pen. At 3106, the mobile device updates the first panel, the second panel, the third panel, and/or the fourth panel in accordance with the adjusted number of insulin units. As previously described, this adjustment can be made using parameters that convert the number of units of insulin to the amount of provided carbohydrates (for example, the insulin-to-carbohydrate ratio, or ICR), which convert the number of units of insulin to the expected drop in glucose (for example, the insulin sensitivity factor , or ISF) or converting the amount of provided carbohydrates to the size of a single meal. Although the present invention has been described as having a typical construction, the embodiments of the present invention may be further modified within the spirit and scope of the present invention. Thus, this application is intended to cover any variation, use, or adaptation of the disclosed embodiments of the invention using its general principles. CLAIM 1. A method for remotely prescribing drug dosage regimens, the method comprising presenting, using a healthcare professional portal (HCP) application, multiple dosage regimens related to a patient, each presented dosage regimen being associated with a corresponding, different other drug dosing algorithms; using the HCP Portal application to select the HCP of at least one of the presented drug dosing regimens and transmitting to the medical mobile application (MMA) on the mobile device associated with the patient, data on the selected HCP scheme indicating at least one selected HCP drug dosing regimen. 2. The method according to claim 1, characterized in that the presented drug dosing regimens include one or more insulin dosing regimens; and at least one selected HCP drug dosing regimen includes - 37 040777 at least one HCP-selected insulin dosing regimen. 3. The method of claim 2 wherein the one or more insulin dosing regimens provided include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens. 4. The method of claim 2, wherein the at least one selected HCP insulin dosing regimen includes a daily titration bolus insulin dosing regimen that is linked to a daily titration bolus insulin dosing algorithm. 5. The method of claim 2, wherein the at least one selected HCP insulin dosing regimen includes a fixed bolus insulin dosing regimen that is associated with a fixed bolus insulin dosing algorithm. 6. The method of claim 2, wherein the at least one selected HCP insulin dosing regimen includes a bolus insulin dosing regimen using a carbohydrate bolus calculator that is linked to a bolus insulin dosing regimen using a carbohydrate bolus calculator. 7. The method of claim 2, wherein the at least one selected HCP insulin dosing schedule includes a bolus insulin dosing schedule using a calculator based on the amount of carbohydrates per meal that is linked to a bolus insulin dosing algorithm using a calculator. based on the amount of carbohydrates in a single meal. 8. The method of claim 1, further comprising receiving from the MMA a pattern confirmation indication indicating that the MMA has received, via the user interface of the mobile device, a patient confirmation indication associated with at least one selected HCP dosage regimen. . 9. The method of claim 1 further comprising receiving from the MMA a schema rejection indication indicating that the MMA has received, via the mobile device user interface, a patient rejection indication associated with at least one selected HCP schema. dispensing drugs; and deactivating MMA on a mobile device associated with the patient in response to an indication of patient refusal. 10. The method according to claim 1, characterized in that the data of the selected HCP regimen allows you to unlock at least one selected HCP dosing regimen of drugs on the MMA. 11. The method according to claim 10, characterized in that the MMA is configured to access implementation data previously stored on the mobile device for at least one selected HCP dosing regimen only after at least one selected The HCP dosing regimen was unlocked using the data of the selected HCP regimen. 12. The method according to claim 10, characterized in that the MMA is configured to download data regarding the implementation of at least one selected HCP drug dosing scheme to a mobile device only after at least one selected HCP drug dosing scheme was unlocked using the data of the selected NSR scheme. 13. The method according to claim 10, characterized in that the data of the selected HCP regimen allows at least one selected HCP dosing regimen to be unlocked on the MMA, provided that the MMA receives a patient confirmation indication in relation to at least one selected HCP dosing regimen. 14. The method of claim 1, wherein the MMA is configured to provide, via the user interface of the mobile device, dosage determination recommendations based on at least one selected HCP drug dosing regimen. 15. The method of claim 1, further comprising simultaneously presenting, by MMA, a plurality of panels on a visual display of the mobile device, wherein the plurality of panels comprises a first panel that displays the number of units of insulin administered to the patient and a second panel that displays the amount of carbohydrate expected to be provided by the number of units of insulin displayed in the first panel; receiving on the mobile device a user input representing the requested adjustment to the number of units of insulin displayed in the first panel; and updating, with MMA, each panel of the plurality of panels according to the requested adjustment to the number of insulin units displayed by the first panel, the update including displaying the adjusted number of insulin units on the first panel and the adjusted amount of carbohydrate expected to be provided by the adjusted the number of units of insulin from the second panel. 16. Server system for the exchange of medical information for the remote prescription of drug dosing regimens, which contains - 38 040777 one or more servers, each of which contains one or more information exchange interfaces, one or more processors and a data storage device, while the data storage device of one or more servers in the aggregate contains commands that, when executed by one or more processors of one or several servers cause the server system for the exchange of medical information for the remote prescription of dosing regimens of drugs to perform a set of functions of the server system, which include the presentation using the application program of the portal for medical professionals (HCP) in the information exchange mode with at least one of the exchange interfaces information from one or more servers of multiple dosing regimens related to the patient, with each presented dosing regimen associated with a corresponding, different dosing algorithm. drugs; receiving, using the HCP portal application, the selection of the HCP of at least one of the presented drug dosing regimens and transmitting, using at least one of the information exchange interfaces, one or more servers to a medical mobile application (MMA) on a mobile device associated with the patient , schedule data selected by the HCP, indicating at least one selected HCP drug dosing regimen. 17. The system according to claim 16, characterized in that the presented drug dosing regimens include one or more insulin dosing regimens; and at least one selected HCP dosing regimen includes at least one selected HCP insulin dosing regimen. 18. The system of claim 17 wherein the one or more insulin dosing regimens provided include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens. 19. The system of claim 17 wherein the at least one selected HCP insulin dosing regimen includes a daily titration bolus insulin dosing regimen that is linked to a daily titration bolus insulin dosing algorithm. 20. The system of claim 17 wherein the at least one selected HCP insulin dosing regimen includes a fixed bolus insulin dosing regimen that is associated with a fixed bolus insulin dosing algorithm. 21. The system of claim 17, wherein the at least one selected HCP insulin dosing schedule includes a bolus insulin dosing schedule using a carbohydrate bolus calculator that is linked to a bolus insulin dosing algorithm using a carbohydrate bolus calculator. 22. The system of claim 17, wherein the at least one HCP-selected insulin dosing schedule includes a bolus insulin dosing schedule using a calculator based on the amount of carbohydrates per meal that is linked to a bolus insulin dosing algorithm using a calculator. based on the amount of carbohydrates in a single meal. 23. The system of claim 16, wherein the server system functionality further comprises receiving from the MMA a pattern confirmation indication indicating that the MMA has received, via the user interface of the mobile device, a patient confirmation indication associated with at least one selected HCP dosing regimen. medicines. 24. The system of claim 16, wherein the server system functionality further comprises receiving from the MMA a schema rejection indication indicating that the MMA has received, via the mobile device user interface, a patient rejection indication associated with at least one selected HCP drug dosing regimen, and deactivation of MMA on a mobile device associated with the patient, in response to an indication of the patient abandoning the regimen. 25. The system according to claim 16, characterized in that the data of the selected HCP regimen allow at least one selected HCP drug dosing regimen to be unlocked on the MMA. 26. The system according to claim 25, characterized in that the MMA is configured to access implementation data previously stored on the mobile device for at least one selected HCP drug dosing regimen only after at least one selected The HCP dosing regimen was unlocked using the data of the selected HCP regimen. 27. The system according to claim 25, characterized in that the MMA is configured to download data regarding the implementation of at least one selected HCP drug dosing scheme to a mobile device only after at least one selected HCP drug dosing scheme was unlocked using the data of the selected NSR scheme. - 39 040777 28. The system according to claim 25, characterized in that the data of the selected HCP scheme allows you to unlock at least one selected HCP dosing regimen of drugs on the MMA, provided that the MMA receives a patient confirmation indication in relation to at least one selected HCP dosing regimen of drugs. 29. The system of claim 16, wherein the MMA is configured to provide, via the user interface of the mobile device, dosage determination recommendations based on at least one selected HCP drug dosing regimen. 30. One or more non-volatile computer-readable storage media (CRMs) that store instructions that, when executed by one or more processors, are capable of causing one or more processors to execute a set of functions, the set of functions including presenting, by means of a portal application, an HRM the number of drug dosing regimens related to the patient administered by the method of claim 1, each presented drug dosing regimen being associated with a respective, distinct drug dosing algorithm; using the HCP Portal application to select the HCP of at least one of the presented drug dosing regimens; HCP drug dosing regimen. 31. CRM according to claim 30, characterized in that the presented drug dosing regimens include one or more insulin dosing regimens; and at least one selected HCP dosing regimen includes at least one selected HCP insulin dosing regimen. 32. The CRM of claim 31, wherein the one or more insulin dosing regimens provided include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens. 33. The CRM of claim 31, wherein the at least one selected HCP insulin dosing regimen includes a daily titration bolus insulin dosing regimen that is linked to a daily titration bolus insulin dosing algorithm. 34. The CRM of claim 31, wherein the at least one selected HCP insulin dosing regimen includes a fixed bolus insulin dosing regimen that is associated with a fixed bolus insulin dosing algorithm. 35. The CRM of claim 31, wherein the at least one selected HCP insulin dosing schedule includes a bolus insulin dosing schedule using a carbohydrate bolus calculator that is linked to a bolus insulin dosing algorithm using a carbohydrate bolus calculator. 36. The CRM of claim 31, wherein the at least one selected HCP insulin dosing schedule includes a bolus insulin dosing schedule using a calculator based on the amount of carbohydrates per meal that is linked to a bolus insulin dosing algorithm using a calculator. based on the amount of carbohydrates in a single meal. 37. CRM according to claim 30, characterized in that the set of functions further comprises receiving from the MMA a scheme confirmation indication indicating that the MMA has received, using the user interface of the mobile device, a patient confirmation indication associated with at least one selected HCP dosing regimen. . 38. CRM according to claim 30, characterized in that the set of functions further comprises receiving from the MMA a scheme rejection indication indicating that the MMA has received, using the user interface of the mobile device, a patient rejection indication associated with at least one selected HCP scheme. dispensing drugs; and deactivating MMA on a mobile device associated with the patient in response to an indication of patient refusal. 39. CRM according to claim 30, characterized in that the data of the selected HCP regimen allows you to unlock at least one selected HCP drug dosing regimen on the MMA. 40. CRM according to claim 39, characterized in that the MMA is configured to access implementation data previously stored on the mobile device for at least one selected HCP dosing regimen only after at least one selected The HCP dosing regimen was unlocked using the data of the selected HCP regimen. 41. CRM according to claim 39, characterized in that the MMA is configured to download data regarding the implementation of at least one selected HCP drug dosing scheme to a mobile device only after at least one selected HCP scheme -