Systems and methods for remote prescription of medication-dosing regimens

Abstract

To provide systems and methods for remote prescription of medication-dosing regimens.SOLUTION: A method takes the form that includes presenting, via a healthcare professional (HCP)-portal user interface of an HCP system, multiple medication-dosing regimens pertaining to a patient. Each presented medication-dosing regimen is associated with a corresponding different medication-dosing algorithm. The method also includes receiving, via the HCP-portal user interface, an HCP selection of at least one of the presented medication-dosing regimens. The method also includes transmitting, to a medical mobile application (MMA) on a mobile device associated with the patient, HCP-selected-regimen data indicative of the at least one HCP-selected medication-dosing regimen.SELECTED DRAWING: Figure 7

Description

[Technical field]

[0001] FIELD OF THE DISCLOSURE The present disclosure relates to medical devices and medical information systems, and in particular to systems and methods for remote prescription of drug administration regimens. [Background technology]

[0002] There are a myriad of diseases and other conditions for which patients are treated. Quite often, this treatment involves one or more administration regimens of one or more medications.

[0003] overview Disclosed herein are systems and methods for remote prescription of drug administration regimens. The systems and methods are applicable to many types of drugs for many types of diseases and other medical conditions. Patients are treated for these medical conditions by what are referred to in this disclosure as healthcare professionals (HCPs). As used herein, HCPs include both persons and / or entities that provide direct medical care to patients (e.g., physicians, nurses, advanced practice nurses, physician assistants (PAs), etc.), as well as persons and / or entities that do not provide direct medical care to patients but indirectly support the provision of health care to patients (e.g., clerical personnel, database management personnel, other information technology personnel, insurance and / or other payment personnel, etc.). In situations described herein where an HCP prescribes a drug administration regimen and / or other treatment that requires a prescription, it is assumed that the HCP who would be required to issue such a prescription will have the appropriate education, training, certification, licensure, etc. Examples of drugs administered by the drug dosing regimen include, but are not limited to, one or more therapeutic agents, including insulin, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agent that can be delivered by a drug delivery device or taken by the patient without the aid of a drug delivery device (e.g., orally or through application to the patient's skin). The drug may be formulated with one or more excipients.

[0004] One example area of ​​applicability of the present system and method is diabetes (sometimes referred to as diabetes mellitus), which is a general term for a group of metabolic disorders that are generally characterized by high levels of glucose (e.g., blood glucose, or blood glucose levels) in the human body for extended periods of time. As known in the art and medical community, another term for high glucose levels is hyperglycemia, typically defined as a glucose level with a threshold above 180 milligrams (mg) per deciliter (dL) (mg / dL), which can also be expressed as a quantity of 10 millimoles (mmol) per liter (L) (mmol / L). The opposite condition (i.e., insufficient levels of glucose) is known as hypoglycemia, typically defined as a glucose level below 70 mg / dL (3.9 mmol / L).

[0005] There are two main types of diabetes, known as type 1 and type 2 diabetes, each of which is differently related to insulin, a hormone central to the body's process of metabolizing glucose into energy that is either used immediately or stored for later use. Type 1 diabetes is generally considered an autoimmune disease in which the patient's immune system mistakenly attacks the insulin-producing "beta cells" of the pancreas. Type 2 diabetes is generally characterized by the inability of the pancreas to produce enough insulin that the body needs, or the patient's body losing the ability to respond to insulin.

[0006] Among the treatments for type 1 and / or type 2 diabetes are subcutaneous injections of synthetic insulin. As a general matter, synthetic insulins are classified according to a number of dimensions, including onset (i.e., how quickly they typically take effect), peak (i.e., the time that typically elapses until maximum efficacy is achieved), duration (i.e., the amount of time that the effect typically lasts), and concentration. A typical way to express concentration is in units per milliliter (mL); as an example, a concentration of 100 units per mL would typically be expressed as U100.

[0007] For type 1 and / or type 2 diabetes, there are two main categories of synthetic insulins typically prescribed by HCPs, typically for subcutaneous injection: basal insulin and bolus insulin. Basal insulin is also known by many other terms, such as background insulin and long-acting insulin, and is generally taken by diabetic patients once or twice a day at regular intervals and in fixed doses, with the aim of maintaining a certain baseline level of insulin in the patient during times such as fasting, sleeping, and between meals. Bolus insulin is also known by many names, including prandial insulin, prandial insulin, and fast-acting insulin, and is generally taken by diabetic patients more as needed, most typically at mealtimes, with the aim of controlling spikes in glucose levels that are typical at mealtimes, but may occur at other times as well.

[0008] While the present methods and systems are certainly applicable to many types of medications for many types of diseases, conditions, etc., they are intended to at least partially assist HCPs and patients with type 1 or type 2 diabetes in managing (sometimes intensive) basal and / or bolus insulin regimens. Indeed, while some of the examples of the present disclosure relate generally to the prescription and implementation of bolus insulin dosing regimens for cases of diabetes, it should be understood that this is by way of example and not limitation, and in no way excludes the present systems and methods relating to dosing regimens for other types of insulin (e.g., basal insulin) and / or other types of diseases. In general, and as noted above, it should be understood that the present systems and methods are applicable to a wide variety of dosing regimens for a wide variety of diseases, conditions, etc.

[0009] The inventors of the present system and method recognize that managing the complexity of insulin therapy can be difficult, especially on the patient side, but also on the HCP side. The present system and method address many technical problems with the prior art, including the technical problem that the implementation of conventional medical devices and medical technologies generally does not provide a mechanism for an HCP to select and even customize at least one drug administration regimen (e.g., bolus-insulin administration regimen) of multiple pre-determined and pre-programmed administration regimens for a particular patient, and then further prescribe the at least one regimen to the patient through a data network by remotely interacting with an application that runs on a mobile device associated with the patient. According to some embodiments of the present system and method, the logic of the multiple pre-determined and pre-programmed administration regimens can be provided using an application that runs on the patient's mobile device, but can be locked from the beginning so that it is inaccessible to the patient. Further, according to some embodiments, the HCP can remotely unlock at least one particular HCP-selected regimen of a plurality of pre-programmed dosing regimens for the patient on the mobile device, which then provides instructions to the patient to implement the at least one regimen, and in some cases can instruct one or more additional medical devices (either native or also associated with the patient) to execute part or all of the at least one HCP-selected dosing regimen. The present system and method represent at least a technical solution to the technical problem. It should also be noted that this paragraph does not imply that other technical solutions to other technical problems do not represent this disclosure.

[0010] One embodiment takes the form of a method including presenting a plurality of drug dosing regimens associated with a patient via an HCP portal application executing on an HCP system. Each of the presented drug dosing regimens is associated with a respective different drug dosing algorithm. The method also includes receiving an HCP selection of at least one of the presented drug dosing regimens via the HCP portal user application. The method also includes transmitting HCP selected regimen data indicative of the at least one HCP selected drug dosing regimen to a medical mobile application (MMA) on a mobile device associated with the patient.

[0011] Another embodiment takes the form of a connected care server system including one or more servers each including one or more communication interfaces, one or more processors, and data storage. In at least some embodiments, the connected care server system is a connected care cloud (C3) server system, and each of the one or more servers is a cloud server. The data storage of the one or more servers collectively includes instructions executable by one or more processors of the one or more servers to cause the connected care server system to perform a set of server system functions including the functions listed in the preceding paragraph. Yet another embodiment takes the form of one or more non-transitory computer readable media (CRM) storing instructions operable, when executed by the one or more processors, to cause the one or more processors to perform a set of functions including the functions listed in the preceding paragraph. In connection with any embodiment, the CRM may take the form of any non-transitory data storage medium referred to herein and / or any other non-transitory data storage medium deemed suitable for a given implementation by one of ordinary skill in the art. Examples include any suitable form of memory (including both volatile and non-volatile memory), disk storage, optical storage, and the like.

[0012] Another embodiment takes the form of a method that includes receiving, at an MMA executing on a mobile device associated with a patient, HCP-selected regimen data indicating an HCP selection of an HCP-selected drug dosing regimen from among a plurality of drug dosing regimens, each associated with a respective different drug dosing algorithm, the HCP selection having been made for the patient by an HCP via an HCP portal application executing on the HCP system, and the method also includes unlocking the indicated HCP-selected drug dosing regimen on the MMA, at least in part in response to receiving the HCP-selected regimen data.

[0013] Another embodiment takes the form of a mobile device associated with a patient. The mobile device includes a mobile device communication interface, a mobile device processor, and a mobile device data storage. The mobile device data storage includes instructions executable by the mobile device processor to cause the mobile device to execute the MMA to perform a set of MMA functions including the functions recited in the preceding paragraph. Yet another embodiment takes the form of one or more non-transitory CRMs storing instructions operable, when executed by the one or more processors, to cause the one or more processors to execute a set of functions including the functions recited in the preceding paragraph.

[0014] Another embodiment takes the form of a system including the connected care server system described above and the mobile device described above. At least one embodiment further includes the HCP system described above.

[0015] Another embodiment takes the form of a method comprising: presenting, by a processor on a mobile device associated with the patient, a plurality of panels simultaneously on a visual display of the mobile device, the plurality of panels including a first panel displaying a number of units of insulin to be administered to the patient and a second panel displaying an amount of carbohydrates expected to be compensated for by the number of units of insulin displayed by the first panel; receiving user input at the mobile device representing an adjustment required to the number of units of insulin displayed by the first panel; and updating, by the processor, each panel of the plurality of panels according to the adjustment required to the number of units of insulin displayed by the first panel, the updating including displaying the adjusted number of units of insulin by the first panel and displaying with the second panel the adjusted amount of carbohydrates expected to be compensated for by the adjusted number of units of insulin.

[0016] In some embodiments, the plurality of panels may further include a panel displaying an indication of a meal size corresponding to the amount of carbohydrate displayed by the second panel, and the updating includes displaying an indication of an adjusted meal size corresponding to the adjusted amount of carbohydrate. Alternatively, or in addition, the plurality of panels may further include a panel displaying an area displaying a range of meal sizes between a small meal size and a large meal size, and an indicator indicating where the amount of carbohydrate displayed by the second panel falls within this area. Alternatively, or in addition, the plurality of panels may further include a panel indicating whether the amount of carbohydrate displayed by the second panel corresponds to a small meal size, a medium meal size, or a large meal size. Alternatively, or in addition, the plurality of panels may further include a panel displaying a decrease in the patient's glucose level expected to result from administration of the number of units of insulin displayed by the first panel, and the updating includes displaying an adjusted decrease in the patient's glucose level expected to result from administration of the adjusted number of units of insulin.

[0017] In some embodiments, the method may further include receiving at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, where one of the plurality of panels indicates whether the carbohydrate value displayed by the second panel corresponds to a small meal size, a medium meal size, or a large meal size based on the received maximum carbohydrate threshold and minimum carbohydrate threshold. The method may also include receiving at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, where the amount of carbohydrate 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 include receiving at the mobile device an insulin effect value (ISF) associated with the patient, where a reduction in the patient's glucose level displayed by one of the plurality of panels is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

[0018] Many variations and permutations of the above-listed embodiments are described herein. Moreover, it is particularly noted that any variation or permutation described in this disclosure can be implemented with respect to any type of embodiment. For example, a variation or permutation that is primarily described in connection with a method embodiment can be implemented in connection with a system embodiment and / or a CRM embodiment in the same way. Moreover, this flexibility and interoperability of the embodiments exists regardless of any slight differences in terms (e.g., process, method, step, function, set of functions, etc.) used to describe and / or characterize such embodiments. [Brief description of the drawings]

[0019] A more detailed understanding can be had from the following description, presented by way of example in conjunction with the following drawings, in which like reference numerals are used to refer to like elements throughout, and in which: [Figure 1]1 illustrates an exemplary communication context including an exemplary HCP system, an exemplary health information technology (IT) system, an exemplary mobile device associated with an exemplary patient and in communication with a plurality of exemplary personal medical devices associated with the exemplary patient, an exemplary server system including one or more exemplary servers (e.g., connected care cloud servers) communicatively interconnected with each other via an exemplary network, and an exemplary administrator portal system, according to at least one embodiment. [Diagram 2] 2 illustrates an example physical architecture of the example HCP system of FIG. 1 according to at least one embodiment. [Diagram 3] 2 illustrates an example physical architecture of the example mobile device of FIG. 1, according to at least one embodiment. [Figure 4A] 2 illustrates an example physical architecture of an example one of the servers in the example server system of FIG. 1 according to at least one embodiment. [Figure 4B] 2 illustrates an example physical architecture of the example administrator portal system of FIG. 1 in accordance with at least one embodiment. [Diagram 5] 2 illustrates an example functional architecture of the example server system of FIG. 1 according to at least one embodiment. [Figure 6] 1 illustrates various entities in an exemplary communication and processing ecosystem in accordance with at least one embodiment. [Figure 7] 2 illustrates a first exemplary method that may be performed by the server system of FIG. 1 according to at least one embodiment. [Figure 8] 1 illustrates a second exemplary method that may be performed by the mobile device of FIG. 1 executing an exemplary MMA, according to at least one embodiment. [Figure 9] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 10] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 11] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 12] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 13] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 14] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 15A] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 15B] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 16] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 17] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 18] 2 illustrates various example screenshots for display via the example HCP system of FIG. 1 in accordance with at least one embodiment. [Figure 19]1 illustrates a flowchart showing an exemplary process for calculating, presenting, and editing recommended insulin doses implemented by an MMA, according to at least one embodiment. [Figure 20] 13 illustrates an example screenshot from the MMA automatically syncing with a patient's glucose sensor, in accordance with at least one embodiment. [Figure 21A] 1 illustrates an example screenshot from the MMA in which the MMA receives a patient's glucose level, in accordance with at least one embodiment. [Figure 21B] 1 illustrates an example screenshot from the MMA in which the MMA receives a patient's glucose level, in accordance with at least one embodiment. [Figure 21C] 1 illustrates an example screenshot from the MMA in which the MMA receives a patient's glucose level, in accordance with at least one embodiment. [Figure 22A] 1 illustrates exemplary screenshots from the MMA used by the MMA for a daily titration dosing regimen, according to at least one embodiment. [Figure 22B] 1 illustrates exemplary screenshots from the MMA used by the MMA for a daily titration dosing regimen, according to at least one embodiment. [Figure 22C] 1 illustrates exemplary screenshots from the MMA used by the MMA for a daily titration dosing regimen, according to at least one embodiment. [Figure 22D] 1 illustrates exemplary screenshots from the MMA used by the MMA for a daily titration dosing regimen, according to at least one embodiment. [Figure 23A] 1 illustrates an exemplary screenshot from the MMA used by the MMA for a fixed dose administration regimen, according to at least one embodiment. [Figure 23B]1 illustrates an exemplary screenshot from the MMA used by the MMA for a fixed dose administration regimen, according to at least one embodiment. [Figure 23C] 1 illustrates an exemplary screenshot from the MMA used by the MMA for a fixed dose administration regimen, according to at least one embodiment. [Figure 23D] 1 illustrates an exemplary screenshot from the MMA used by the MMA for a fixed dose administration regimen, according to at least one embodiment. [Figure 24A] 14 illustrates an exemplary screenshot from the MMA used by the MMA to receive carbohydrate values ​​for a carbohydrate bolus calculator dosing regimen, in accordance with at least one embodiment. [Figure 24B] 14 illustrates an exemplary screenshot from the MMA used by the MMA to receive carbohydrate values ​​for a carbohydrate bolus calculator dosing regimen, in accordance with at least one embodiment. [Figure 24C] 14 illustrates an exemplary screenshot from the MMA used by the MMA to receive carbohydrate values ​​for a carbohydrate bolus calculator dosing regimen, in accordance with at least one embodiment. [Figure 24D] 14 illustrates an exemplary screenshot from the MMA used by the MMA to receive carbohydrate values ​​for a carbohydrate bolus calculator dosing regimen, in accordance with at least one embodiment. [Figure 25A] 1 illustrates an exemplary screenshot from the MMA used by the MMA to receive units of prandial insulin for a carbohydrate bolus calculator dosing regimen, according to at least one embodiment. [Figure 25B] 1 illustrates an exemplary screenshot from the MMA used by the MMA to receive units of prandial insulin for a carbohydrate bolus calculator dosing regimen, according to at least one embodiment. [Figure 25C] 1 illustrates an exemplary screenshot from the MMA used by the MMA to receive units of prandial insulin for a carbohydrate bolus calculator dosing regimen, according to at least one embodiment. [Figure 25D] 1 illustrates an exemplary screenshot from the MMA used by the MMA to receive units of prandial insulin for a carbohydrate bolus calculator dosing regimen, according to at least one embodiment. [Figure 26A] 1 illustrates an exemplary screenshot from the MMA used by the MMA for computer dosing regimens based on carbohydrate meal size, according to at least one embodiment. [Figure 26B] 1 illustrates an exemplary screenshot from the MMA used by the MMA for computer dosing regimens based on carbohydrate meal size, according to at least one embodiment. [Figure 26C] 1 illustrates an exemplary screenshot from the MMA used by the MMA for computer dosing regimens based on carbohydrate meal size, according to at least one embodiment. [Figure 26D] 1 illustrates an exemplary screenshot from the MMA used by the MMA for computer dosing regimens based on carbohydrate meal size, according to at least one embodiment. [Figure 27A] 1 illustrates an exemplary screenshot from the MMA that is used by the MMA to present and / or edit recommended insulin doses, according to at least one embodiment. [Figure 27B] 1 illustrates an exemplary screenshot from the MMA that is used by the MMA to present and / or edit recommended insulin doses, according to at least one embodiment. [Figure 27C] 1 illustrates an exemplary screenshot from the MMA that is used by the MMA to present and / or edit recommended insulin doses, according to at least one embodiment. [Figure 28] 1 illustrates an exemplary user interface display having four panels of information related to suggested insulin doses, according to at least one embodiment. [Figure 29] 1 illustrates a series of exemplary user interface displays showing how four panels of information are updated as the suggested insulin dose is adjusted, according to at least one embodiment. [Diagram 30] 28 and 29 are displayed on a connected drug delivery device according to at least one embodiment. [Diagram 31] 28, 29, and 30. FIG. 29 illustrates a flowchart showing an example process performed by a mobile device to display and update the user interfaces of FIGS. 28, 29, and 30 according to at least one embodiment.

[0020] For the purpose of facilitating an understanding of the principles of the present disclosure, reference is made below to the embodiments shown in the drawings described below. The embodiments disclosed herein are not intended to be exhaustive or to limit the present disclosure to the precise forms disclosed in the following detailed description. Rather, the embodiments have been chosen and described so that others skilled in the art may utilize their teachings. As such, they are not intended to limit the scope of the present disclosure.

[0021] Throughout this disclosure and claims, in some cases, numerical modifiers such as first, second, third, and fourth are used in reference to various components, data such as various identifiers, and / or other elements. Such use is not intended to indicate or refer to a particular or required order of the elements. Rather, the numerical terms are used to aid the reader in identifying the referenced element and distinguishing that element from other elements, and should not be construed narrowly as insisting on any particular order.

[0022] Furthermore, before proceeding with this detailed description, it should be noted that the entities, arrangements, and the like shown in and described in connection with the various drawings are presented by way of example and not limitation. As such, any and all statements or other indications regarding what a particular drawing "shows," what a particular element or entity in a particular drawing "is" or "has," and any and all similar descriptions (which alone and out of context may be understood to be absolute and thus limiting) can only be properly understood if interpreted as preceded by a phrase such as "in at least one embodiment" (unless in fact this is not the case). This also means that the preceding phrase will not be repeated more than once in this detailed description, for reasons similar to brevity and clarity of presentation. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0023] I. Exemplary Architecture A. Exemplary Communication Context 1 illustrates an exemplary communication context 100 including an exemplary HCP system 102, an exemplary health IT system 118, an exemplary mobile device 104 associated with an exemplary patient 124 and in communication with a plurality of exemplary personal medical devices associated with the exemplary patient 124 (in this illustration, an exemplary glucose meter 126 and an exemplary connected injection device 134), an exemplary server system 106 including one or more exemplary servers 140-146 communicatively interconnected with each other via an exemplary private network 138, and an exemplary administrator portal system 148, according to at least one embodiment. Also illustrated in FIG. 1 are a data network 108, communication links 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. Also illustrated are an association arrow 125, a conceptual information flow arrow 130, and a conceptual information flow arrow 132, both of which are described below. It should be understood that the entities and arrangements, and their interconnections, illustrated in FIG. 1 are provided by way of example and not limitation, and that other entities, arrangements, and interconnections can be implemented as well as deemed suitable in a given context by those skilled in the art.

[0024] The HCP system 102 (including the display 120), from the perspective of its physical architecture, will be described more fully below in connection with FIG. 2, but may generally take the form of any computing device equipped, configured, and programmed to perform the HCP portal functions described herein. Some options for the HCP system 102 include a desktop computer, a laptop computer, a tablet computer, a mobile device such as a smartphone, or a device that uses voice, augmented reality (AR) or virtual reality (VR) to interact with the HCP. In some embodiments, the HCP system 102 is any electronic device capable of supporting and operating an Internet browser (i.e., a web browser, perhaps as a stand-alone application, perhaps as a separate application feature, just to name a few). As illustrated in FIG. 1, the HCP system 102 is communicatively connected to a health IT system 118 via a communication link 116 and to a data network 108 via a communication link 110. Although the communication link 116 is illustrated as separate from the data network 108, it should be understood that in some cases, all or a portion of the link 116 may be routed through at least a portion of the data network 108. In some cases, the HCP system 102 can communicate with the HIT system 118 indirectly via the data network 108 instead of through a direct link 116 as illustrated in Figure 1. Among typical users of the HCP system 102 are HCPs with prescribing roles (e.g., physicians, physician assistants (PAs), advanced practice nurses, etc.), as well as non-prescribing HCPs and users who are part of a care team associated with an Integrated Delivery Network (IDN), among other examples.

[0025] In various different embodiments, among other examples that may be enumerated herein, the HCP system 102 provides and supports functions such as prescribing drug dosing regimens (e.g., insulin dosing regimens such as basal insulin dosing regimens, bolus insulin dosing regimens), modifying existing dosing regimen prescriptions, setting and / or modifying dosing regimen parameters, and viewing individual patient data. Prescribing and parameter setting for dosing regimens by the HCP via the HCP system 102 assists the patient in determining drug dosage. Among other functions, the HCP system 102 provides the HCP with the ability to download patient EHR data from the health IT system 118 via the communication link 116, view the EHR data in the HCP portal, view a selection of available drug dosing regimens, select a dosing regimen to prescribe to the patient, and assign values ​​to the required parameters for the selected dosing regimen (e.g., starting dose, insulin to carbohydrate ratio, etc., in the case of insulin dosing regimens). The HCP system 102 further provides a data visualization function that allows the HCP user to review the patient's historical data. In various embodiments, this historical patient data is viewable in chart form, graph form, table form, and / or one or more other formats deemed suitable for a given implementation by those of skill in the art.

[0026] The mobile device 104 (including the display 122), in terms of its physical architecture, will be described more fully below in connection with FIG. 3, but may generally take the form of any computing device equipped, configured, and programmed to perform the mobile device functions described herein. Some options for the mobile device 104 include mobile phones, smartphones, personal digital assistants (PDAs), tablet computers, laptop computers, wearable devices, mobile devices that interact with a user via voice or virtual reality, and the like. As illustrated in FIG. 1, the mobile device 104 is communicatively connected to a glucose meter 126 via a communication link 128, to a connected injection device 134 via a communication link 136, and to a data network 108 via a communication link 112. As illustrated by the double-ended dotted association arrow 125, the mobile device 104 is associated with the patient 124, for example, by subscription account, ownership, possession, and / or one or more other manners.

[0027] With respect to the C3 server system 106, an exemplary one of the C3 servers 140-146 is described more fully below in terms of its physical architecture in connection with FIG. 4A. Additionally, the C3 server system 106 is described more fully below in terms of its functional architecture (e.g., software architecture) in connection with FIG. 5. In general, however, the C3 server system 106 may take the form of any set of one or more servers collectively equipped, configured, and programmed to collectively perform the C3 server system functions described herein. As illustrated in FIG. 1, the C3 server system 106 is communicatively coupled to a data network 108 via a communication link 114.

[0028] As illustrated in FIG. 1, it should be noted that each of the respective C3 servers 140-146 in the C3 server system 106 may have its own respective communication link 114 with the data network 108, or alternatively, a single communication link 114 may communicatively connect the C3 server system 106 to the data network 108, perhaps via a firewall, a network access server (NAS), or the like. For clarity of presentation, the one or more communication links 114 will be referred to as "communication link 114" in the remainder of this disclosure. Additionally, as also illustrated in FIG. 1, the respective C3 servers 140-146 are communicatively interconnected with one another via a private network 138, which may take the form of or include a local area network (LAN), a virtual private network (VPN), and / or one or more other options deemed suitable for a given implementation by those skilled in the art. In some embodiments, the illustrated network 138 does not exist as a separate network as currently illustrated, and in such embodiments, each of the C3 servers 140-146 communicates with one another via their links to the data network 108. The communication connections between the C3 server system 106 and the administrator portal system 148 are discussed below.

[0029] As a general matter, the C3 server system 106 functions as a "cloud" as that term is used in the art with respect to entities such as the HCP system 102, the health IT system 118, and the mobile device 104 (and specifically one or more applications, such as one or more MMAs running on the mobile device 104). In some embodiments, a subset of the C3 servers 140-146 may be dedicated to serving at least one of the HCP system 102 (e.g., to serve the HCP portal application 572, described in more detail below), the health IT system 118, and the mobile device 104. However, in some embodiments, each of the C3 servers 140-146 may be capable of fulfilling the role of any of these three entities. Regardless of the particular architecture implementation, the C3 server system 106 functions as at least one cloud with the particular purpose of those entities. As such, in at least one embodiment, all communications between the C3 server system 106 and any one or more other entities are secure communications, and by way of example, such communications may be encrypted and / or signed as known in the art. Such communications may be within a tunnel, such as a VPN, among other communication and data security options that may be implemented as deemed suitable for various contexts by those skilled in the art.

[0030] In various different embodiments, and as further described below, the C3 server system 106 provides and supports the functionality of the mentioned entities and possibly other entities, such as secure and reliable transfer of information and data (e.g., related to prescriptions), data storage, management of the relationship between the patient and the HCP, IDNs, etc., between the HCP system 102 and the MMA operating on the mobile device associated with the patient, and in some embodiments, instead or in addition, provides and supports one or more other functions deemed suitable for a given implementation by those skilled in the art. Furthermore, in some embodiments, the C3 server system 106 facilitates data sharing involving a payer (e.g., an insurance company), and in some such embodiments, such data sharing with the payer entity is contingent on the associated patient choosing to allow such communication. Other examples of the functionality provided and supported may also be enumerated herein as well.

[0031] The administrator portal system 148, in terms of its physical architecture, is described more fully below in connection with FIG. 4B, but may generally take the form of any computing device equipped, configured, and programmed to perform the administrator portal system functions described herein. Some options for the administrator portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. As illustrated in FIG. 1, in at least one embodiment, the administrator portal system 148 is operable to communicate with the C3 server system 106 via a communication link 150 (specifically, in the illustrated example, via the private network 138). In other embodiments, as also illustrated in FIG. 1, the administrator portal system 148 is operable to communicate with the HCP system 102, the mobile device 104, and / or the C3 server system 106 via the data network 108. Also, in some embodiments, the administrator portal system 148 is operable to do both.

[0032] As a general matter, in various different embodiments, the administrator portal system 148 provides various services with respect to the HCP portal 102, the MMAs executing on the mobile device 104, and / or the C3 server system 106. One example category of such services pertains to user management, login, access levels, and the like. In at least one embodiment, a user with sufficient permissions can use the administrator portal system 148 to modify and / or manage various settings of the HCP portal 102, the MMAs executing on the mobile device 104, and / or the C3 server system 106. In some cases, changes made via the administrator portal system 148 only affect a single MMA, a single user, a single HCP, and the like, while in other cases, such changes affect multiple MMAs, multiple user accounts, multiple HCPs, and the like. For example, an integrated delivery network (IDN) (e.g., a network of healthcare organizations) may be provided with an administrator portal system 148 that manages the accounts of patients enrolled in the IDN. In some embodiments, the administrator portal system 148 is operable to deploy updates, upgrades, and the like. In some embodiments, the administrator portal system 148 is operable to manage individual HCP accounts, individual patient accounts, etc. Certainly numerous other exemplary administrative functions for which the administrator portal system 148 may be used may also be enumerated herein.

[0033] In the exemplary situation illustrated in FIG. 1, the data network 108 is communicatively connected to the HCP system 102 via communication link 110, to the mobile device 104 via communication link 112, to the C3 server system 106 via communication link 114, and to the administrator portal system 148 via communication link 152. In at least one exemplary scenario, the data network 108 typically includes one or more Internet Protocol (IP) networks, such as a global network of networks broadly referred to as the Internet, one or more public IP networks, one or more private (e.g., corporate) IP networks, and / or one or more IP networks of any other type deemed suitable for a given implementation by those skilled in the art. Entities communicating over the data network 108 may be identified by addresses, such as IP addresses (e.g., IPv4 addresses or IPv6 addresses). However, as this is merely an example, the data network 108 need not be or include an IP network.

[0034] As used herein, a "communication link" may include one or more wired communication (e.g., Ethernet, Universal Serial Bus (USB), etc.) links and / or one or more wireless communication (e.g., cellular, Wi-Fi, Bluetooth, etc.) links, and may include any suitable number of relay devices, such as routers, switches, bridges, etc. In particular, communication link 112 may include at least one wireless communication link to facilitate bidirectional data communication with mobile device 104. Additionally, either or both of communication links 128 and 136 may take the form of or include at least one of a near field communication (NFC) link, a Bluetooth link, a radio frequency identification (RFID) link, a direct radio frequency (RF) link, and / or one or more other types of wireless communication links. Further, although the communication links 128 and 136 may be point-to-point links between (i) the mobile device 104 and (ii) the glucose meter 126 and the connected injection device 134, respectively, they need not be, and in some embodiments one or both of the communication links 128 and 136 are indirect links, for example, via a Wi-Fi or ZigBee router, or a cellular network or tower (not shown), and other implementations may certainly be enumerated herein as well.

[0035] In the exemplary scenario illustrated in FIG. 1, the health IT system 118 is communicatively connected to the HCP system 102 via a communication link 116 and may generally take the form of one or more servers. The health IT system 118 may or may not have its own local user interface, such as its own monitor display, keyboard, mouse, touch screen, or other user interface. In various different embodiments, the health IT system 118 optionally provides and supports secure maintenance, secure storage, and secure access of the patient's electronic health record (EHR - also referred to in the industry as electronic medical record or EMR), perhaps among other functions deemed suitable for a health IT system by those skilled in the art. Additionally, the health IT system 118 is communicatively coupled to the data network 108 via a communication link 154. The health IT system 118 may also communicate with the C3 server system 106 via the data network 108. In some embodiments, the health IT system 118 interfaces with the C3 server system 106 and / or the HCP system 102 via a standardized protocol, such as, for example, the Fast Healthcare Interoperability Resources (FHIR) protocol or the Substitutable Medical Applications and Reusable Technologies (SMART) protocol.

[0036] In the exemplary scenario described herein, the patient 124 has been diagnosed with and is being treated for diabetes by an HCP associated with the HCP system 102, but this is purely by way of example and not limitation. In the described embodiment, both the mobile device 104 (and at least one MMA operating on the mobile device), the glucose meter 126, and the connected injection device 134 are each associated with the patient 124 at least in a manner that is mutually associated. The association arrow 125 above is intended to represent a general association and user interface level interaction between the patient 124 and the mobile device 104.

[0037] It is further noted that while in FIG. 1 the mobile device 104 is shown connected to both the glucose meter 126 and the connected injection device 134, in some cases only one of the glucose meter 126 and the connected injection device 134 may be present in various different scenarios and not both are required. Indeed, some scenarios, such as in the case of a system where the patient is required to separately and manually measure glucose levels and / or record dosage information, or where medication is taken orally and no device is required to monitor or test one or more levels, conditions, or other parameters of the patient 124, do not include any additional medical devices connected to the mobile device 104 at all. In some cases, a patient may connect more than one glucose meter and / or more than one connected injection device to the MMA, for example, a patient may have one glucose meter and / or injection device at home and one glucose meter and / or injection device at work. The MMA can be configured to support multiple connections of each. Additionally, in some cases, there are one or more connected medical devices other than the glucose meter and / or the connected injection device. Some examples include blood pressure monitors, pulse / oxygen monitors, etc. Certainly many other examples could also be enumerated herein.

[0038] The glucose meter 126 is associated with the patient 124 for medical, diabetes treatment purposes and is communicatively connected to the mobile device 104 via the communication link 128 described above. The glucose meter 126 may include a blood glucose meter (BGM), a continuous glucose meter (CGM), a flash glucose meter (FGM), or other devices that measure the patient's 124 blood glucose or other sources of glucose level (e.g., a contact lens device, or a device that measures glucose levels using near-IR radiation). A BGM makes a discrete spot measurement of the patient's blood glucose level (e.g., by pricking the patient's finger to make a spot measurement of the patient's capillary whole blood glucose level). Both the CGM and FGM use sensors to measure interstitial fluid glucose. A CGM system may include a sensor, a transmitter, and a receiver / app. A CGM may make more frequent (i.e., more continuous) measurements of the patient's interstitial fluid glucose level and may, optionally, be worn continuously by the patient for relatively long periods of time (e.g., hours or days at a time). An example of such a CGM is the G6 sensor manufactured by Dexcom, Inc. An FGM system may include a sensor attached to or inserted into a portion of the patient's body, and a reader (e.g., a handheld reader) that receives glucose level readings from the sensor when activated or placed proximal to the sensor. An example of such an FGM is the FreeStyle Libre device manufactured by Abbott Diabetes Care Inc. In some embodiments, the FGM does not require finger-prick calibration. Certainly one or more other types of glucose meters may be included as well.

[0039] CGM and FGM systems can measure interstitial fluid glucose levels, and BGM systems can measure blood glucose levels. For brevity and ease of reading, the remainder of this disclosure will refer simply to "glucose" levels, or "GL." It will be understood that such references may refer to either blood glucose or interstitial fluid glucose, as appropriate.

[0040] The connected injection device 134 is also associated with the patient 124 for medical, diabetes treatment purposes and is communicatively connected to the mobile device 104 via the communication link 136 described above. The device 134 may further include a drug or medication. In some embodiments, the system may include one or more devices, including the device 134, and a drug or medication. The term "drug" or "medication" refers to one or more therapeutic agents, including but not limited to insulin, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agent capable of delivery by the above device. Drugs or medications as used in the device 134 may be formulated with one or more excipients. The device is operated by the patient, caregiver, or medical practitioner in a manner to deliver the drug to the person, as generally described herein.

[0041] 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 a pen having integrated and / or attachable electronics for automatically detecting and reporting the amount of insulin injected to another electronic device). In various different embodiments, the connected injection device 134 takes the form of or includes one or more of the insulin delivery devices described in any of the following patent applications, each of which is incorporated herein by reference in its respective entirety: PCT Application No. PCT / US17 / 65251, entitled Medication Delivery Device with Sensing System, filed on December 8, 2017 (Attorney Docket No. X21353); PCT Application No. PCT / US18 / 19156, entitled Dose Detection and Drug Identification for a Medication Delivery Device, filed on February 22, 2018 (Attorney Docket No. X21457); and U.S. Provisional Patent Application No. 62 / 552,659, entitled Dose Detection with Piezoelectric Sensing for a Medication Delivery Device, filed on August 31, 2017 (Attorney Docket No. P21462).

[0042] Moreover, in some cases, one or more of the functions of one of these two devices of the present disclosure are or are instead supplemented by the other of the two devices, and / or one or more additional devices. In one example, a single device can both monitor glucose (and report the results) and inject insulin (and report the amount injected). Certainly other combinations of functions can also be enumerated herein.

[0043] Additionally, and as described below, in some embodiments, the MMA executing on the mobile device 104 communicates with one or more connected medical devices, such as the exemplary glucose meter 126 and connected injection device 134, for various reasons (e.g., sending administration commands, receiving administration confirmation reports, requesting (e.g., glucose) readings, receiving one or more measurements, etc.). Such communication may be in a one-way or two-way manner with a given device. Additional examples of information that may be communicated from the connected medical device to the MMA include error codes, device metrics, administration records, and / or administration confirmation. Certainly other examples may also be enumerated herein. Additionally, in some cases, direct communication links exist between various connected medical devices, such as between the glucose meter 126 and the connected injection device 134.

[0044] Conceptual information flow arrow 130 is meant to diagrammatically illustrate, among other information, the HCP system 102 transmitting, either directly, via data network 108, via C3 server system 106, or via some other intermediate component or network, a prescription for an HCP-selected drug dosing regimen (e.g., a bolus dosing regimen), to the MMA executing on the mobile device 104, as described more fully below. Similarly, conceptual information flow arrow 132 is meant to diagrammatically illustrate, among other information, the MMA executing on the mobile device 104 transmitting, either directly or via C3 server system 106, health data tracked and shared by the patient regarding the patient's diabetes and / or one or more other health-related conditions, topics, etc.

[0045] As a general matter, it should be understood that in at least one embodiment, any of the entities described herein, including but not limited to the HCP system 102, the health IT system 118, the mobile device 104 (including the MMA running on the mobile device), the C3 server system 106, and the administrator portal system 148, can communicate with any other of those entities without having to route that communication through one or more other entities. For example, in at least one embodiment, the HCP system 102 and the mobile device 104 can exchange information without having to pass the information through the C3 server system 106. However, in some embodiments, one or more of the entities communicate with each other through at least one additional entity, and as one example, in at least one embodiment, data (e.g., HCP selected regimen data) is communicated from the HCP system 102 to the MMA running on the mobile device 104 via the C3 server system 106.

[0046] B. Exemplary HCP System (Exemplary Physical Architecture) 2 illustrates an exemplary physical architecture of an HCP system 102 according to at least one embodiment. This architecture is provided by way of example and not limitation, as other architectures may be implemented as deemed suitable by those skilled in the art. As illustrated in FIG. 2, the HCP system 102 includes a communication interface 202, a processor 204, data storage 206, and a user interface 208 including the display 120 discussed above.

[0047] The communication interface 202 may include one or more components, such as an Ethernet card for wired communication, and / or one or more components, such as a Wi-Fi chip for wireless communication. The processor 204 may be a general-purpose microprocessor, such as a central processing unit (CPU). The data storage 206 may be or include any suitable non-transitory computer-readable medium (CRM), such as memory (e.g., read-only memory (ROM), random access memory (RAM)), flash memory, solid-state drive, optical memory, etc.), and may include instructions executable by the processor 204 to perform at least the HCP portal system functions described herein. In addition to the display 120, the user interface 208 may include one or more output devices, such as a speaker, indicator LEDs, and may further include one or more input devices, such as a keyboard, mouse, trackpad, microphone, etc., as known in the art. The various components of the HCP system 102 are illustrated as communicatively interconnected via a system bus 210.

[0048] Further, it should be appreciated that in at least one embodiment of the present systems and methods, HCP system 102 operates or implements HCP portal 572 (illustrated in FIG. 5 and also referred to herein as “HCP portal application 572”). HCP portal 572 may be a software or firmware application running on the hardware of HCP system 102. For example, HCP portal 572 may take the form of a widget running within the HCP’s electronic health record (EHR) system. Such a widget may integrate with the HCP’s EHR system using a protocol such as Substitutable Medical Apps, Reusable Technology (SMART) over Fast Healthcare Interoperability Resources (FHIR). In some embodiments, HCP portal 572 may take the form of a web application running within a web browser. In an illustrative example, the HCP logs into HCP portal 572 by pointing a web browser on HCP system 102 to a hyperlink, after which HCP portal 572 opens in the browser. In at least one such embodiment, 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, dosing regimen data, etc.), instead acting as merely a conveyance of such patient data between its HCP users and the C3 server system 106. In some such embodiments, there is locally stored data in the form of code for the web browser itself (e.g., Microsoft Edge, Google Chrome, Apple Safari, etc.), as well as possibly code for web applications (e.g., Java) add-ons. Other variations regarding the centralized and / or distributed nature of the operable code and / or other substantive data that may be deemed suitable for a given implementation by one of ordinary skill in the art may certainly be enumerated herein.

[0049] C. Exemplary Mobile Device (Exemplary Physical Architecture) FIG. 3 illustrates an exemplary physical architecture of a mobile device 104 according to at least one embodiment. As can be appreciated by inspection, FIG. 3 is similar to FIG. 2 in many ways and is therefore not described in detail herein. However, since the mobile device 104 is a mobile device, those skilled in the art will appreciate that corresponding differences may exist in each of the components, such as the communication interface 302, which is likely equipped, programmed, and configured for both wireless wide area network (WWAN) communication (e.g., via LTE) and wireless local area network (WLAN) communication (e.g., via Wi-Fi), as well as those having additional wireless communication capabilities such as NFC, Bluetooth, RFID, RF, etc. Additionally, the processor 304 is selected in at least one embodiment as suitable for implementation in a mobile device, and the data storage 306 includes instructions executable by the processor 304 to perform at least the mobile device functions described herein, including but not limited to executing the MMA described herein. Finally, in addition to the display 122, the user interface 308 includes one or more user input and / or user output components suitable for incorporation in a mobile device (e.g., a touch screen, a stylus, a pointing and clicking device, soft keys, a keyboard, a microphone, a speaker, a camera, a data port, etc.). The various components of the mobile device 104 are illustrated as communicatively interconnected via a system bus 310.

[0050] D. Exemplary C3 Server (Exemplary Physical Architecture) FIG. 4A illustrates an exemplary physical architecture of a C3 server 140, selected as an exemplary one of the C3 servers 140-146 of the C3 server system 106, according to at least one embodiment. As noted above, the C3 server system 106 may take the form of any number of servers, including only one, including two or more. In FIG. 1, the four C3 servers 140-146 with an ellipsis between the third and fourth are intended to illustrate this numerical flexibility. As can also be appreciated, FIG. 4A is similar in many respects to both FIG. 2 and FIG. 3, and therefore will not be described in detail herein.

[0051] In most scenarios, the architecture of the C3 server 140 will typically be more similar to that of the HCP system 102 than to that of the mobile device 104, if for no other reason than the level of performance and data processing for which such a different architecture is possible. However, there are differences in the architecture of the C3 server 140 in at least one embodiment compared to the HCP system 102. For data security reasons, the communication interface 402 may include only wired communication hardware (e.g., an Ethernet card) and may include more data communication interfaces compared to the HCP system 102.

[0052] Similarly, the processor 404 and data storage 406 will typically be selected to handle more communication, storage, data processing, etc. than would typically be required for the HCP system 102. The data storage 406 includes instructions executable by the processor 404 to perform at least the C3 server functions described herein. Finally, the user interface 408 is illustrated with dashed lines to indicate that it is not present in all embodiments. For example, in some cases, the C3 server 140 is only accessible in a user interface-like manner via a data connection, such as a remote desktop connection, a shell connection, etc. The various components of the C3 server 140 are illustrated as communicatively interconnected via a system bus 410.

[0053] As described herein, in at least one embodiment, the C3 server system 106 collectively includes instructions executable by one or more of the one or more processors of the one or more C3 servers 140-146 to cause the C3 server system to perform various combinations of the C3 server system functions described herein. The method 700 described below in FIG. 7 is one such exemplary combination. Indeed, in at least one embodiment, the logic for implementing the C3 server system 106 is distributed across multiple physical servers. In at least one embodiment, the hardware (e.g., data storage, processor functionality, web servers, switches, routers, communication links, etc.) used to facilitate a particular access request, etc., is dynamically provisioned such that different access requests can be facilitated with different sets of hardware. Such hardware can be dynamically provisioned for a particular access request based on various factors such as the geographic location of the request, load balancing, required quality of service (QoS), service agreement parameters, etc. The C3 server system can then be considered a "cloud" as that term is used in the art, which includes a distributed network of servers that collectively and dynamically operate the virtual services. In at least one embodiment, each such virtual service is its own self-contained software process. Moreover, the particular hardware server (or servers) that actually runs a given instance of a given virtual service is dynamically allocated on the fly, depending on one or more factors such as those mentioned in this paragraph.

[0054] E. Exemplary Administrator Portal System (Exemplary Physical Architecture) FIG. 4B illustrates an exemplary physical architecture of an administrator portal system 148 according to at least one embodiment. As can be seen by inspection, FIG. 4B is similar in many ways to each of FIG. 2, FIG. 3, and FIG. 4A, and therefore will not be described in detail herein. As mentioned above, some options for the administrator portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. The administrator portal system 148 may take the form of any one or more computing devices suitably equipped, programmed, and configured to perform at least the administrator portal system functions described herein. As illustrated in FIG. 4B, the administrator portal system 148 includes a communication interface 452, a processor 454, a data storage 456 including instructions executable by the processor 454 to perform at least the administrator portal system functions described herein, and a user interface 458, all of which are communicatively coupled to one another via a system bus 460.

[0055] Additionally, it should be appreciated that, in at least some embodiments, similar to the HCP system 102, the administrator portal system 148 operates or implements an administrator portal application (not shown). The administrator portal application may be a software or firmware application that executes on the hardware of the administrator portal system 148. For example, the administrator portal application may take the form of a web application that runs within a web browser. An administrator or user may log into the administrator portal application by pointing a web browser to a hyperlink on the administrator portal system, which then opens in the browser. In such an embodiment, the content within the administrator portal application may be hosted by the C3 server system 106, and little or no patient data (e.g., patient medical records, dosing regimen data, etc.) may be stored locally on the administrator portal system 148. Instead, the administrator portal system 148 instead serves merely as a vehicle for patient data between its administrators / users and the C3 server system 106.

[0056] F. Exemplary C3 Server System (Exemplary Functional Architecture) FIG. 5 illustrates an exemplary functional architecture of the C3 server system 106, according to at least one embodiment. This functional architecture is provided by way of example and not limitation, and it should be understood that other functional architectures may be implemented as deemed suitable by those skilled in the art for a variety of different contexts. The functional architecture of the C3 server system 106, including each of the various data stores, services, gateways, links, and interfaces, may be implemented using any combination of hardware, firmware, and / or software (wherein the firmware and / or software operates on the hardware) as deemed suitable by those skilled in the art. It should also be noted that entities in addition to the C3 server system 106 are illustrated in the architecture 500 shown in FIG. 5. This is made clear by the left curly bracket labeled "106" for the C3 server system 106, and components outside of the left curly bracket are associated with entities in addition to the C3 server system 106.

[0057] As can be seen in FIG. 5, architecture 500 includes four of what are known in the computing and programming arts as "tiers" separated by "interfaces," which are logical constructs that facilitate encapsulation and manageability of complex systems, among other benefits. Architecture 500 includes a data tier 502, an internal web services (IWS) tier 504, an externally facing services (EFS) tier 506, and an application tier 508. Data tier 502 is separated from IWS tier 504 by a data IWS interface 503, the IWS tier is separated from EFS tier 506 by an IWS-EFS interface 505, and the EFS tier is separated from application tier 508 by an EFS application interface 507. Additionally, it should be noted that interface 509 represents the logical portion of architecture 500 where a user will interact with the system as a whole and specifically with application tier 508 directly; in other words, interface 509 is what is often referred to in the art as a "man-machine interface."

[0058] In the illustrated embodiment, the data layer 502 includes multiple data stores 510a-e. Each data store 510a-e corresponds to one of the microservices 514, 516, 518, 520, and / or 522 described herein. The data stores 510a-e collectively include patient and / or medical data, including personally identifiable information (PII), such as name, address, phone number, email address, social security number, etc. The data stores 510a-e may also collectively include information other than PII, such as treatments, definitions, and dosing regimens (i.e., templates). In at least one embodiment, the data layer 502 is implemented using an on-demand cloud computing platform and services operated and offered by Amazon Web Services, a subsidiary of Amazon.com, Inc. (Seattle, Washington). In at least one other embodiment, the data layer 502 is implemented using the PostgreSQL product developed by Heroku (San Francisco, California). Certainly other options may be enumerated herein as well. In at least one embodiment, data layer 502 is organized according to the FHIR standard put forward by Health Level Seven International (HL7) of Ann Arbor, Michigan.

[0059] The IWS layer 504 includes multiple microservices 514, 516, 518, 520, and 522. The ellipsis between service 520 and service 522 is meant to indicate that any number of services may be present in the IWS layer 504 as deemed suitable for a given implementation by one of ordinary skill in the art. Each microservice is a data gateway implemented as a software service responsible for processing a particular type of data or functionality. Exemplary microservices include a "Personal" microservice for processing PII related to registered or prospective patients, an "Order" microservice for processing data related to prescription orders, an "Observation" microservice for processing data related to patient observations entered by an HCP or observed by an MMA running on a mobile device, a "User Access" microservice for processing data related to user access rights and permissions, a "Client Compatibility" microservice for verifying that a user's mobile device is compatible with the functionality provided by the C3 system 106, and a "Substance" microservice for processing data related to the type of medication processed by and / or administered to a patient. Each microservice 514-522 can access one data store 510a-e via a corresponding communication link 511a-e.

[0060] Each internal service 514-522, in at least one embodiment, is designed such that access, including read and write access, to data stored in the data stores 510a-e is only available to the various gateways 524-530 of the EFS tier 506 in a manner defined and permitted by the respective internal service 514-522. In at least one embodiment, the IWS tier 504 is implemented using Amazon Web Services. In another embodiment, the IWS tier 504 is implemented using the Heroku Platform, also developed by Heroku, and certainly other options may be enumerated herein as well.

[0061] It should be further noted that the "links" described in connection with FIG. 5 represent logical access links and not necessarily physical communication links, and that the logical access links present in FIG. 5, at least in the described embodiment, indicate that appropriate configuration, authorization, authentication, permissions, etc. are in place to facilitate communication between corresponding entities.

[0062] The EFS layer 506 includes an HCP portal gateway 524, an MMA gateway 526, an MMA gateway 528, and an administration gateway 530. Additionally, the ellipsis between the MMA gateways 526 and 528 indicates that any suitable number of MMA gateways may be implemented, and the ellipsis between the mobile devices 104 and 532 in the application layer 508 is meant to indicate the same. Each MMA gateway corresponds to a particular type or version of MMA. Implementing a dedicated MMA gateway instance for each type or version of MMA is a design choice, and others are possible. In this illustrated embodiment, it can be understood that, through the depiction of the IWS-EFS interface 505 as a system bus throughout the IWS-EFS interface 505, any of the gateways in the EFS layer 506 can call any of the internal services 514-522 as needed. In at least one embodiment, each gateway 524-530 in the EFS tier 506 is designed such that access to the internal services 514-522 of the IWS tier 502 is available only to entities in the application tier 508 in a manner defined and permitted by the respective gateway 524-530. For example, in one embodiment, an HCP portal 572 running on the HCP system 102 can access the internal services 514-522 through the HCP portal gateway 524, and similarly, an MMA 568 running on the mobile device 104 can access the internal services 514-522 through the MMA gateway 526. In at least one embodiment, the EFS tier 506 is implemented using Amazon Web Services. In at least one other embodiment, the EFS tier is implemented using the Heroku Platform. Certainly other options may be enumerated herein as well.

[0063] The application layer 508 includes the HCP system 102 running a Health Information Technology User Interface (HIT UI) 574, which in turn runs an HCP portal 572. The application layer 508 further includes the above-mentioned mobile device 104 (running an MMA 568 in accordance with the present disclosure), a second mobile device 532 (running another type or version of an MMA illustrated as MMA 570 in accordance with the present disclosure), an administration portal 534, and an administration portal 536. As with the ovals above, the ellipses between the mobile device 104 and the mobile device 532 are meant to indicate that any suitable number of mobile devices may be present in the application layer 508. Additionally, a single MMA gateway (e.g., MMA gateway 526) may be connected to multiple mobile devices each running the same type or version of an MMA (e.g., MMA 568). Similarly, the ellipses between the administration portal 534 and the administration portal 536 are meant to indicate that any suitable number of system administrator level portals may be implemented as deemed suitable for a given context by one of ordinary skill in the art. In one embodiment, the administration portal 534 is a clinical C3 administration server configured for administration of the C3 server system 106 in relation to clinical aspects. In one embodiment, the administration portal 536 is a manufacturing-support C3 administration server configured for administration of the C3 server system 106 in relation to manufacturing-support aspects. Certainly other examples may also be enumerated herein. In at least one embodiment, one or both of the administration portal 534 and the administration portal 536 are processes executed on the administrator portal system 148. Additionally, ellipsis or additional HCP portals related to HCP portals are not illustrated in FIG. 5, although it is also true that any suitable number of HCP portals may be implemented in a given context.

[0064] The HCP system 102 may provide the HCP with a Health Information Technology User Interface (HIT UI) 574. 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 interact with patient or non-patient data and records stored in the HIT 118. The HIT UI 574 may in turn, at the command of the HCP, launch an HCP portal 572 as a separate user interface within the HIT UI 574, exemplary screenshots of the HCP portal 572 being provided as part of FIGS. 9-18. As previously described herein, the HCP portal 572 may take the form of a web application running within a web browser that allows the HCP to access or provide patient data to or from the C3 server system 106. In at least some embodiments, the HCP portal 572 may also interface with the HIT 118 and access or provide patient data to or from the HIT 118. In this manner, the HCP can launch the HCP Portal 572 by clicking a button or key while viewing a particular patient's record within the HIT UI 574 to prescribe a medication dosing regimen, view the patient's observed or recorded dosing history, and access other features of the HCP Portal described herein.

[0065] In some embodiments, the HIT UI 574 and the HCP portal 572 may both be provided by the same vendor. In other embodiments, the HIT UI 574 may be provided by a first vendor and the HCP portal 572 may be provided by a second vendor. The HCP portal 572 may be integrated into the HIT UI 574 using industry standards such as SMART over FHIR as described above. Integrating the HCP portal 572 in this manner allows the HCP to access patient data from the HIT 118 through the portal 572 without having to manually enter data, and allows the HCP to select an appropriate dosing regimen and review important patient data such as medications, medical history, lab results, past blood glucose records, insulin dosage information, etc., without having to return to the HIT UI 574. In some cases, the HCP portal 572 may also be configured to pull a minimum set of demographic data related to a particular patient from the HIT 118 (e.g., patient name, date of birth, patient unique identifier, or patient EHR unique identifier) ​​and display this demographic data in a banner or other prominently displayed area. This can help ensure that HCPs are working with the correct patient record.

[0066] Although the HCP portal 572 is illustrated encapsulated within the HIT UI 574, the HCP portal 572 may also be implemented as a stand-alone application outside of any health IT system. In such a case, the HCP system 102 would execute or implement the HCP-portal 572 without the HIT UI 574. In such an embodiment, the HCP portal 572 may optionally still pull patient data from the health IT system, but may not be launched as a separate window or graphical user interface from within the health IT system's user interface. Of course, the HCP portal 572 may also be configured not to communicate with the health IT system at all, and in such an embodiment, patient medical and personal data may need to be manually entered and stored in the HCP portal 572.

[0067] Throughout the EFS application interface 507, only the HCP system 102 can access the HCP portal gateway 524 via link 558, only the MMA 568 (on the mobile device 104 or on multiple mobile devices) can access the MMA gateway 526 via link 560, only the MMA 570 (on the mobile device 532 or on multiple mobile devices) can access the MMA gateway 528 via link 562, and the C3 management gateway 530 is accessible by both the C3 management portal 534 (via link 564) and the C3 management portal 536 (via link 566). Such restricted access, in the illustrated embodiment, is bidirectional, where the C3 server system 106 can only access the HCP system 102 via the HCP portal gateway 524 and link 558, and the C3 server system 106 can only access the MMA 568 via the MMA gateway 526 and link 560, and similarly can access the MMA 570 via the MMA gateway 528 and link 562, and the respective C3 management portals 534 and 536 via the C3 management gateway 530 and links 564 and 566.

[0068] G. Exemplary Ecosystem FIG. 6 illustrates various entities in an exemplary communication and processing ecosystem 600, according to at least one embodiment. Of course, the term ecosystem is used herein in the context of computing communication and processing, not in the biological sense. Where appropriate, elements discussed above in connection with FIGS. 1-5 are also labeled in FIG. 6 to aid the reader's understanding by placing such elements in the context of the ecosystem 600, which includes an HCP engagement area 602, a patient engagement area 604, a population management area 606, and a care management area 608, all of which communicatively interact and correlate with one another via the C3 server system 106, which in FIG. 6 is shown in this illustration including a data analytics engine. As noted above, in some embodiments, the C3 server system 106 communicatively connects with payer entities, such as insurance companies, Medicare, etc. (e.g., shares data (perhaps only on the condition that the patient opts in) and receives data from the payer).

[0069] The data analytics engine may be configured to analyze data collected by or accessible through a patient's mobile device and / or health record data to drive insights regarding the patient's behavior or symptoms related to a disease or condition. The analyzed data is specific to a single patient and can be used to derive insights specific to that patient. For example, the data analytics engine may determine through analysis of a diabetic patient's log of glucose readings that the patient is prone to exhibiting hyperglycemia or hypoglycemia under certain conditions, e.g., at certain times of the day, after eating certain types of meals, on certain days of the week, entering or leaving certain geographic locations, before / during / after certain types of physical activity, and in other types of conditions. Based on these insights, the data analytics engine may take a variety of actions, such as notifying the patient's HCP, recommending educational content to the patient related to the observed hyperglycemic or hypoglycemic episodes, or prompting the patient to change their behavior at certain times or places where it would be most effective (e.g., prompting the patient to take medication just before bed, immediately after exercise, or when entering or leaving a particular geographic location).

[0070] The HCP engagement area 602 of the ecosystem 600 includes the HCP systems 102 and the health IT systems 118, as described in FIG. 6, and enables HCPs to order products from companies or other organizations that operate the C3 server system 106, access insights into such products, and integrate current systems and methods into existing clinical workflows.

[0071] The patient engagement area 604 of the ecosystem 600 includes the mobile device 104 running the MMA 568, the patient 124, the glucose meter 126, the connected injection device 134, and many other patient related medical devices such as blood pressure or other measurements. In the patient engagement area 604 of the ecosystem 600, the goal of the system and method includes providing relevant, high value decision support to reduce patient burden and improve outcomes, as described in FIG.

[0072] The population management area 606 of ecosystem 600 includes computing devices (possibly similar in physical architecture to that of HCP system 102) and EMR / HIE (health information exchange) systems for proper storage and maintenance of multiple patient's personal medical information. In the population management area 606 of ecosystem 600, the goals of the system and method include enabling clinical and financial stakeholders (payers, health plans, etc.) to assess populations and better serve high-risk patients, as set forth in FIG.

[0073] The care management area 608 of the ecosystem 600 also includes computing devices similar to those of the HCP system 102, as well as its own EMR / HIE system, and is generally dedicated to remote monitoring and clinical decision support (CDS), including what is often referred to as a "care team" for a given patient. This care team may include multiple different HCPs (different types of doctors, different types of nurses, therapists, caregivers, etc.) with a variety of different roles all related to the health and well-being of the patient. In the care management area 608 of the ecosystem 600, the goal of the system and method includes enabling the care team to identify and prioritize patients who need assistance, as well as enabling direct interaction between the patient and the care team, as described in FIG. 6.

[0074] In at least one embodiment, a companion MMA is provided that allows a caregiver, next of kin, etc. to access some or all of the data received, recorded, tracked, or entered by the patient 124 via the MMA 568. In at least one such embodiment, a person using the companion MMA is able to view the patient's logbook (e.g., including glucose measurements, dosage information, information related to meals, etc.), as well as the prescribed dosing regimen(s), and / or other types of data deemed suitable for a given implementation by those of skill in the art. The amount and / or type of data viewable via the companion MMA can be set to default values ​​and may be adjustable by the HCP, the patient 124, and / or one or more other individuals depending on the design parameters of a given implementation.

[0075] In accordance with the present systems and methods, the C3 server system 106 provides and supports many functions that facilitate the above and other goals in the ecosystem 600. One such function is data storage, where the C3 server system 106 in at least one embodiment securely stores data, thereby enabling the HCP system 102 and the MMA 568 to securely communicate with each other. (In embodiments where, for example, the MMA app 568 is instantiated on the mobile device 104 and perhaps another mobile device associated with the patient 124, who may have both a smartphone and a tablet, as is very common, and / or where the patient 124 can access similar functionality and information via, for example, a web portal, as is also commonly implemented in the art.) The C3 server system 106 further enables MMA users to securely back up their medical data and achieve data consistency across multiple devices.

[0076] In various embodiments, the HCP sets up a dosing regimen via the HCP system 102 and the C3 server system 106, and transmits the dosing regimen to the MMA 568 via the secure data transfer functionality of the C3 server system 106, as described herein. Additionally, in various embodiments, the C3 server makes patient history data, dosing regimen status, and the like available via the HCP system 102 and / or the MMA 568. Additionally, in at least one embodiment, secure communications (i.e., messaging or inbox functionality) are facilitated by the C3 server system 106 between the HCP via the HCP system 102 and the patient 124 via the MMA 568 and mobile device 104. Additionally, in various different embodiments, the C3 server system 106 facilitates software updates, recall notifications, and / or other functionality deemed suitable for a given implementation or given context by those of skill in the art.

[0077] I. Exemplary Operations A.HCP Portal 7 illustrates an exemplary method 700 that may be performed by a C3 server system 106, according to at least one embodiment. The description herein of a C3 server system 106 performing the method 700 is provided for purposes of illustration and not limitation, and it should be understood that the method 700 may be performed by any device or set of devices suitably equipped, programmed, and configured to perform the method.

[0078] In step 702, the C3 server system 106 utilizes the user interface 208 of the HCP system 102 via the HCP portal 572 to present a plurality of drug dosing regimens pertaining to the patient 124. In at least one embodiment, each of the presented drug dosing regimens is associated with a respective different drug dosing algorithm. Exemplary drug dosing regimens and algorithms are discussed in more detail below.

[0079] Any one or more of the proposed drug administration regimens may be known in the art as open loop or closed loop regimens. As generally stated, a closed loop regimen repeatedly adjusts the dose (e.g., amount, timing, etc.) of one or more drugs in an automated manner based at least in part on auto-sensing feedback such as measurements (e.g., glucose levels) taken on the patient, while an open loop regimen does not repeatedly adjust the dose of the drug in an automated manner. However, in many cases, an open loop drug administration regimen is configured with similar historical data in a more manual manner in which the patient manually inputs feedback parameters. An open loop drug administration regimen may also require the patient to manually control drug dispensing. More generally, the present system and method are not limited to any particular type of administration regimen, any particular drug or type of drug, or a particular mode of delivery of the drug to the patient (e.g., injection, intravenous, oral, etc.).

[0080] In step 704, the C3 server system 106 receives an HCP selection (for the patient 124) of at least one of the proposed drug dosing regimens utilizing the user interface 208 of the HCP system 102 via the HCP portal 572. In the terminology of this disclosure, the at least one selected regimen is referred to as "at least one HCP selected drug dosing regimen," "at least one HCP selected regimen," etc.

[0081] In at least one embodiment, the drug dosing regimens proposed in step 702 include one or more insulin dosing regimens, and at least one HCP-selected drug dosing regimen includes at least one HCP-selected insulin dosing regimen. Any number of the proposed regimens can be basal insulin dosing regimens, and any number can be bolus insulin dosing regimens. In some cases, either the basal insulin dosing regimen or the bolus insulin dosing regimen is selected by the HCP for the patient 124. In some cases, the HCP prescribes both one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens simultaneously to the patient 124.

[0082] In at least one embodiment, the at least one HCP-selected bolus insulin dosing regimen includes a type referred to herein as a daily titrated bolus insulin dosing regimen associated with a type of dosing regimen referred to herein as a daily titrated bolus insulin dosing algorithm. Other types of HCP-selected bolus insulin dosing regimens include a type referred to herein as a fixed dose bolus insulin dosing regimen associated with a type of dosing algorithm referred to herein as a fixed dose bolus insulin dosing algorithm; a type referred to herein as a carbohydrate bolus calculator bolus insulin dosing regimen associated with a type of dosing algorithm referred to herein as a carbohydrate bolus calculator bolus insulin dosing algorithm; and a type referred to herein as a carbohydrate meal size based calculator bolus insulin dosing regimen associated with a type of dosing algorithm referred to herein as a carbohydrate meal size based calculator bolus insulin dosing algorithm. Examples of each of these above four types of open loop bolus insulin dosing regimens / algorithms are described in the correspondingly titled subsections below.

[0083] In step 706 , the C3 server system 106 transmits HCP selected regimen data indicating the at least one HCP selected regimen of step 704 to the MMA 568 on the mobile device 104 associated with the patient 124 .

[0084] Although the exemplary method 700 is described above as being implemented by the C3 server system 106, the method 700 may also be implemented directly by the 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 include a user interface hosted and executed locally by the HCP system 102. In these cases, the HCP system 102 presents a plurality of drug administration regimens to the HCP (step 702), receives an HCP selection from among the presented drug administration regimens (step 704), and transmits the HCP-selected regimen data to the MMA 568, without assistance from or any communication with the C3 server system 106. In such embodiments, the HCP system 102 may communicate directly with the mobile device 104 over the data network 108, without requiring the data to pass through or be processed by the C3 server system 106.

[0085] Regardless of whether the method 700 is implemented by the C3 server system or the HCP portal 102, in at least some embodiments, the MMA 568 is configured to provide, via the user interface 308, a dosing recommendation based on at least one HCP-selected regimen. In some embodiments, the MMA 568 presents a prompt via the user interface 308 to provide the patient 124 with an option to accept or reject the recommended (i.e., prescribed) dosing regimen. In at least one embodiment, the C3 server system 106 is configured to disable the MMA 568 in response to receiving, via the user interface 308, a regimen rejection indication indicating that the MMA 568 has received a patient rejection indication associated with at least one HCP-selected regimen. Disabling the MMA 568 may include preventing a user from accessing some or all of the functionality of the MMA 568 or preventing a user from accessing some or all of the data stored in the MMA 568. For example, disabling the MMA 568 may include preventing a user from accessing or using a dosing regimen prescribed or recommended by an HCP. In other cases, the C3 server system 106 instead receives a regimen acceptance indication via the user interface 308 indicating that the MMA 568 has received a patient acceptance indication associated with at least one HCP-selected regimen.

[0086] In at least one embodiment, it is the receipt by the MMA 568 of the HCP selected regimen data in step 706 that unlocks the at least one HCP selected regimen on the MMA 568. In some cases, this unlocking includes allowing the MMA 568 to access implementation data already stored on the mobile device 104 (potentially as part of the MMA 568) of the at least one HCP selected regimen only after receipt of the HCP selected regimen data. In other implementations, this unlocking includes transitioning the MMA 568 from inoperable to operable for downloading implementation data of the at least one HCP selected regimen only after receipt of the HCP selected regimen data. In these implementations, the implementation data of the at least one HCP selected regimen can be downloaded from the C3 server system 106 and / or the HCP system 102.

[0087] In some cases, this unlocking occurs only in response to the MMA 568 receiving a patient acceptance indication via the user interface 308 for at least one HCP-selected regimen. Allowing the MMA 568 to unlock or download a particular HCP-selected regimen only after receiving HCP-selected regimen data may help ensure compliance with regulations implemented by the U.S. Food and Drug Administration (FDA). Such FDA regulations may require that certain dosing regimens be accessible only by patients with a prescription from a licensed and qualified physician. By limiting access to the dosing regimen until receiving the HCP-selected regimen data, the MMA 568 in these embodiments ensures that a patient cannot access the dosing regimen without the required prescription.

[0088] The embodiment of storing implementation data of all regimens presented to and selectable by the HCP in steps 702 and 704 on the mobile device 104 (e.g., as part of the MMA 568) and unlocking one or more regimens on the mobile device only after receipt of the HCP-selected regimen data transmitted in step 706 provides several technical advantages that improve the efficiency and / or functionality of the present systems and methods. For example, storing implementation data of all regimens on the mobile device 104 allows the HCP to activate a particular prescribed regimen on the patient's mobile device 104 without requiring the mobile device 104 to download additional, potentially large implementation data of the prescribed regimen. This allows the patient to more easily access and implement the prescribed regimen when the patient's mobile device 104 has only an intermittent or low-bandwidth communication link 112 with the data network 108 (e.g., during a network failure event or when the mobile device is in airplane mode).

[0089] The embodiment including bundling all regimen implementation data as part of the MMA 568 also allows the MMA 568 to be written for easy access by the patient on certain popular online repositories for mobile applications. Such online mobile application repositories may include repositories managed by a third party entity other than the entity (or entities) owned, maintained, and / or affiliated with the HCP system 102, the administrator portal 148, or the patient 124, such as the App Store maintained by Apple, Inc., or Google Play maintained by Google LLC. Such online repositories typically require that written applications include all implementation logic at the time of writing. In other words, to ensure the safety and stability of applications running on mobile devices, administrators of such online repositories may prohibit application developers from updating or modifying the code of written applications unless each update is submitted, reviewed, and / or approved by the third party entity (e.g., Apple or Google) that maintains the online repository. As such, embodiments that involve downloading implementation data to the mobile device 104 each time a new dosing regimen or algorithm is prescribed may require a time-consuming submission, review, and / or approval process by a third party entity, a problem that is inherent and particularly prevalent in the realm of medical mobile applications that enable access to dosing regimens that, per FDA regulations, should only be accessible to patients with a prescription.By bundling all regimen implementation data as part of the MMA 568 at the time of writing and selectively unlocking prescribed regimens only upon receipt of HCP-selected regimen data, the MMA 568 avoids the need for such time-consuming submission, re-review, and / or approval processes each time a patient is prescribed a new dosing regimen. This bundling also increases the safety and stability of the MMA.

[0090] As discussed above, in at least one embodiment, the MMA 568 is communicatively coupled via its host mobile device 104 to one or more insulin delivery and / or insulin monitoring devices associated with the patient 124. The glucose meter 126 is an example of such an insulin monitoring device. In at least some embodiments in which the MMA 568 is communicatively coupled to an insulin delivery device associated with the patient 124, the MMA 568 communicates with the insulin delivery device to execute at least one HCP-selected regimen. The connected injection device 134 is an example of such an insulin delivery device. In some embodiments, the C3 server system 106 and / or the HCP system 102 receive patient data from the insulin delivery and / or monitoring devices, such as, for example, insulin injection record data and glucose measurement data as described herein, that is relayed by the MMA 568.

[0091] B. MMA on Mobile Devices 8 illustrates an example method 800 that may be performed by a mobile device 104 executing an MMA 568, according to at least one embodiment. It should be understood that the description herein of the method 800 performed by an MMA 568 executing on a mobile device 104 is provided for purposes of illustration and not limitation, and that the method 800 may be performed by any device or set of devices suitably equipped, programmed, and configured to perform the method.

[0092] In step 802, the MMA 568 receives HCP-selected regimen data indicating an HCP selection of at least one drug dosing regimen from among a plurality of drug dosing regimens, each associated with a different drug dosing algorithm. In at least one embodiment, the HCP selection was made for the patient 124 via the HCP system 102 (e.g., via a web interface (HCP portal 572) provided by the C3 server system 106 and accessed by the HCP via the HCP system 102). As described above, the MMA 568 can receive the HCP-selected regimen data directly from the HCP system 102 or, as described in this example, from the C3 server system 106. The at least one HCP-selected drug dosing regimen may include any of the possible regimens or combinations of regimens described herein.

[0093] In step 804, the MMA 568 unlocks the indicated HCP-selected drug administration regimen on the MMA 568, at least in part in response to receiving the HCP-selected regimen data in step 802. As mentioned above, in at least one embodiment, step 804 includes accessing previously inaccessible implementation data of the HCP-selected regimen that was pre-stored on the mobile device 104. These embodiments may be desirable for at least the technical reasons discussed above. In some embodiments, step 804 includes downloading previously inaccessible implementation data of the HCP-selected regimen.

[0094] In at least one embodiment, after performing step 802 and before performing step 804, the MMA 568 presents a prompt via the user interface 308 of the mobile device 104 for patient acceptance or patient rejection of the at least one HCP-selected drug dosing regimen and then receives user input via the user interface 308 corresponding to the presented prompt, and in at least one such embodiment, the MMA 568 performing step 804 is conditioned on the received user input being an indication of patient acceptance for the at least one HCP-selected drug dosing regimen. Further, in at least one embodiment, the MMA 568 transmits the received user input to the C3 server system 106 and / or the HCP system 102.

[0095] In at least one embodiment where the prescribed regimen is or includes a bolus insulin dosing regimen, upon receiving a patient acceptance indication indicating that the user has accepted the dosing regimen prescription, the MMA 568 presents the user with the option to enter a recommended bolus dose workflow, during which, in at least one embodiment, the MMA 568 prompts the user to select a meal time, prompts the user to enter and / or confirm a glucose measurement, and presents the user with a recommended bolus dose accordingly. The user can indicate to the MMA 568 that they have taken a recommended dose, in which case the MMA 568 will record the recommended dose in memory. Alternatively, the user can indicate to the MMA 568 that they have taken a dose of insulin that differs from the recommended dose, and the MMA 568 will record the amount of insulin actually taken. The record may include the time the dose was taken, which may be automatically set to the time the user confirmation was received or the time indicated by the user.

[0096] In at least one embodiment, the MMA 568 via the mobile device 104 communicatively connects with an insulin delivery (and / or glucose monitoring) device associated with the patient, and in at least one such embodiment, the MMA 568 communicates with the insulin delivery device to execute an HCP-selected regimen or receive information regarding doses manually delivered by the patient using the 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. The patient data may include insulin injection record data (e.g., including the time and amount of insulin delivered in previous doses) and / or glucose measurement data, among numerous other examples that may be enumerated herein. In at least one embodiment, the MMA 568 provides dosing recommendations based on the HCP-selected regimen via the user interface 308 of the mobile device 104.

[0097] In at least one embodiment, the MMA 568 may include a safety feature that prompts the patient if it detects that the patient may be taking an unsafe or incorrect dose. For example, the MMA 568 may calculate an expected "baseline" amount of drug expected for each dose. This "baseline" dose may be determined in multiple ways. For example, the "baseline" dose may be a pre-set amount of drug programmed by the HCP and / or the patient, or may be algorithmically and automatically derived from the patient's medical or personal information (e.g., gender, age, weight, type and severity of disease, etc.). The "baseline" dose may also be derived from a moving average, mode, or median mean of a certain number of previous doses (e.g., the last 3, 5, 10, or more doses), or doses taken in a moving window of previous time (e.g., the last 3, 5, 10, or more days). In some embodiments, the "baseline" dose may vary based on time of day, or on upward or downward trends detected in previous doses. Before recommending a dose based on the HCP-selected regimen, the MMA 568 can compare the recommended dose to this "baseline" dose. If the MMA 568 detects that it is recommending a dose that differs significantly from this baseline dose, such as if the recommended dose differs from the baseline by a certain absolute amount of medication or a certain percentage, the MMA 568 can alert the patient and prompt the patient to confirm the dose. For example, the recommended dose may be based on incorrectly entered patient input, such as an incorrectly entered insulin on-board parameter, meal size value, or current glucose level. Alternatively, or in addition, if the user indicates to the MMA that they plan to take an amount of medication that differs from the recommended amount, the MMA 568 can similarly determine whether the amount indicated by the user differs significantly from the baseline dose. If the amount indicated by the user differs significantly, the MMA 568 can alert the patient that the indicated dose is significantly higher or lower than the baseline dose.This additional prompt and warning can help warn the user that they may be about to take an unsafe or incorrect amount of medication. If desired, the user can override the warning.

[0098] In at least one embodiment, the MMA 568 provides at least two levels of access: general access, available for anyone to download, self-register, and use, and prescription access, which provides additional functionality unlocked through prescription of an electronic dosing regimen. In one embodiment, general access provides functionality including (i) recording of data related to diabetes, which may include, by way of example, glucose levels (GL), basal insulin, bolus insulin, carbohydrate input, and exercise / stress / sickness factors, and (ii) access to visualizations (e.g., graphs) of user data, while in one embodiment, prescription access unlocks bolus insulin dosage recommendations through implementation of a dosing regimen. In some embodiments, the appearance of the user interface of the MMA 568 changes depending on whether the MMA 568 is in general access mode or prescription access mode (and / or possibly other modes). Such changes may include, but are not limited to, additional and / or fewer menu items, changes in color scheme, changes in icons, changes in layout, etc.

[0099] In at least some embodiments, the general access (non-prescription) mode of the MMA 568 provides one or more of the following features: Data Entry · Users can enter diabetes related data to facilitate tracking and viewing by HCPs. · The user is able to enter bolus insulin doses, basal insulin doses, glucose readings (manually or through a wireless connection to a glucose meter), and carbohydrate intake. · Users can also record the following modifiers, if applicable: activity, stress, illness, steroids, and menstruation, as well as yes / no data points. Patients can input values ​​into the MMA such as glucose values ​​(either automatically or manually from a sensor), current activity level, food currently being eaten, carbohydrate content of food, weight and other physiological characteristics. Digital logbook Users can track their diabetes related data so all their data is easily accessible and viewable in one place. -Users can view any of the data they have entered in the form of a digital logbook. Pairing your glucose meter Simplify the glucose entry process for users who want to store all of their data in one place or who want to receive dosage recommendations using their glucose data. · The user may select the option to pair a device such as a blood glucose meter, continuous glucose meter, flash glucose monitor, or other glucose monitoring device. Once a glucose monitoring device is paired, the MMA will display the most recent glucose reading when the user navigates to the Recommended Bolus Dose workflow (only available in Prescription mode) or Data Entry workflow (available in General Access mode). Users can pair with connected glucose meters that require compliance with the Continua standard (also known as the Continua Design Guidelines) published by the Personal Connected Health Alliance (PCHAlliance) (Arlington, Virginia). In some embodiments, a user may conduct experiments by performing an activity and measuring the effect on glucose levels. The user may review the experiments that they have conducted. Such experiments may be based on activity, food, and / or other factors. In some embodiments, a third party data source (e.g., HealthKit, FitBit, etc.) creates experiments for the user. Indeed, in some embodiments, the MMA may connect and communicate with wearables such as FitBit, Apple Watch, etc. to facilitate monitoring and / or integration of insights regarding one or more physiological parameters. Data Visualization · Users can view the collected data over a period of time to make the data easier to understand. Users can navigate to the section of the MMA that hosts the data visualizations. They can then select the type and time period of data they wish to view. · The MMA will also display a pie chart of the recorded glucose values, showing values ​​above range, within range, below range, and values ​​that fall into the hypoglycemic level (≦70 mg / dL). Reminders Helps to remind users to test glucose or enter recommended bolus dose workflow when they have a busy schedule. · Users can set reminders for desired times to test glucose levels and / or take insulin. The user will receive a message on their mobile device with a reminder. Onboarding · Users can register MMA and learn about useful features. Users can register to use MMA by creating login credentials, entering basic information about themselves and accepting the Terms of Use. The MMA will provide select activities (e.g., tutorials) to help users learn about useful features, including pairing a glucose meter or setting personal reminders. Diabetes education Help users learn about diabetes from trusted sources. Users can access links to diabetes education from within the MMA. Such links may launch within the MMA or launch a browser application, among other possibilities.

[0100] C. Example HCP Portal Screenshots As described below, FIGS. 9-21 illustrate various screenshots of various different embodiments of the HCP system 102.

[0101] 9 is a screenshot 900 of an HCP user navigating the “Select [Administration] Method” tab with four bolus insulin dosing regimens listed as options for the HCP to select from, which are described in more detail below. In one embodiment, clicking on any one of the presented regimens presents a pop-up window providing further details. In at least one embodiment, once the HCP selects one of the four dosing regimens, the HCP system 102 transmits the HCP selected regimen data to the mobile device 104, which allows the patient to access the selected dosing regimen on the mobile device.

[0102] 10 is a screenshot 1000 showing electronic health record (EHR) data relating to one exemplary patient, illustrating various patient data in graphical form. In this screenshot 1000, the exemplary patient has not yet been prescribed a dosing regimen.

[0103] 11 is a screenshot 1100 in which a warning message 1102 is displayed indicating that pending changes to a dosing recommendation or prescription are still awaiting patient acceptance. In this screenshot 1100, the patient does not have a valid prescribed dosing regimen and has no past recorded data regarding glucose values ​​or dosage information. The patient has been prescribed a fixed meal bolus dosing regimen, but the patient has not yet accepted the prescribed dosing regimen.

[0104] 12 is a screenshot 1200 in which a warning message 1202 is displayed regarding pending changes to dosing recommendations or the prescription is still awaiting patient acceptance. In this screenshot 1200, the patient was previously prescribed a carbohydrate bolus calculator-bolus insulin dosing regimen and is now prescribed a fixed dose-bolus insulin dosing regimen. The patient has not yet accepted the newly prescribed dosing method.

[0105] FIG. 13 is a screenshot 1300 illustrating the “Configuration Settings” tab where the selected dosing regimen is a daily titrated bolus insulin dosing regimen, also referred to simply as the “daily titrated” regimen. As shown in FIG. 13, the daily titration regimen settings tab gives the HCP the option to prescribe bolus dose options for three meals: breakfast, lunch, and dinner. The HCP can select either “titrated”, “stable”, or “none” for each meal. The titration option results in titration with the recommended dose for that meal according to the algorithm described herein below. The “stable” option allows the HCP to specify a fixed bolus dose for that meal time. The “none” option means that no bolus dose is prescribed for that time.

[0106] 14 is a screenshot 1400 illustrating the “Review and Confirm” tab where the selected dosing regimen is again “Daily Titration.” The HCP can now review and confirm the future daily titration dosing regimen before prescribing it to the patient.

[0107] 15A and 15B are screenshots 1500 illustrating the "Configuration Settings" tab where the selected dosing regimen is a fixed dose bolus insulin dosing regimen, also referred to simply as a "fixed meal dosing" regimen. The HCP user is presented with an opportunity to review the customizable details of the particular patient's regimen. For example, the HCP user can customize the bolus dose settings for three time blocks: (i) morning, (ii) afternoon, and (iii) evening and night. The start time of each time block can be adjusted by the HCP. For each time block, the HCP user can select a target glucose level, an insulin effect value (described in more detail below), a bolus dose, various health factors (such as activity, illness, stress, steroids, and menstruation, described in more detail below), settings permissions (which, when enabled, allow the patient to change their prescription settings), and an option to enable effective insulin (described in more detail below).

[0108] 16 is a screenshot 1600 illustrating the “Review and Confirm” tab where the selected dosing regimen is again a fixed dietary dosing regimen. The HCP can now review and confirm the future fixed dietary dosing regimen again before prescribing it to the patient.

[0109] FIG. 17 is a screenshot 1700 illustrating the “configuration settings” tab where the selected dosing regimen is a calculator bolus insulin dosing regimen based on carbohydrate meal size, also referred to simply as the “carbohydrate meal size” regimen. As shown in FIG. 17, the carbohydrate meal size regimen settings tab gives the HCP the option to prescribe bolus dose options for three time blocks: (i) morning, (ii) afternoon, and (iii) evening and night. The start time of each time block can be adjusted by the HCP. For each time block, the HCP user can select a target glucose level, an insulin effect value (described in more detail below), and an insulin to carbohydrate ratio (described in more detail below). Regardless of duration, the HCP user can also select the expected grams of carbohydrate from each of the “small”, “medium”, and “large” meals. Finally, the HCP user can select the insulin duration.

[0110] 18 is a screenshot 1800 illustrating the "Configuration Settings" tab where the selected dosing regimen is the Carbohydrate Bolus Calculator Bolus Insulin Dosing Algorithm, also referred to simply as the "Carb Count" regimen. As shown in FIG. 18, the Carbohydrate Count Regimen Settings tab is similar to the Carbohydrate Meal Size Regimen Settings tab, except that it does not give the HCP user the option to select the expected grams of carbohydrate for "small," "medium," and "large" meals.

[0111] II. Exemplary Open-Loop Bolus Insulin Dosing Algorithms and Associated Regimens Some or all of the exemplary open loop bolus insulin dosing algorithms and associated regimens described herein can calculate the recommended bolus based on insulin on board (IOB). IOB is a calculated value that describes the amount of insulin expected to still be available in the patient's body from a previously injected bolus insulin dose. This value may reduce the amount of insulin that the algorithm recommends injecting the patient. IOB can be calculated using at least two different approaches.

[0112] The first approach can calculate the IOB by considering only the portion of the previous dose that was required to correct the higher than desired glucose reading. The single dose of insulin taken at a discrete time point can be determined based on several parameters, including any or all of: (i) the amount of insulin required to correct the higher than desired glucose reading, (ii) the amount of additional insulin required to "make up" or make up for the amount of carbohydrates the patient ingests in a meal immediately before, during, or after administration, and (iii) any adjustments (positive or negative) required to account for lifestyle or health factors that may affect the amount of insulin required (e.g., whether the patient is ill, whether the patient is exercising or is expected to exercise, whether the patient is menstruating, whether the patient is taking steroids, and / or whether the patient is experiencing stress). This first approach can calculate the IOB by considering only parameter (i), i.e., the amount of insulin required to correct the higher than desired glucose reading. The first approach can eliminate either parameter (ii) or (iii) when calculating the IOB.

[0113] The second approach may calculate the IOB by considering all insulin taken as part of the previous dose. In other words, the second approach calculates the IOB by considering not only parameter (i), but also parameter (ii) (i.e., the amount of insulin needed to "make up" for the amount of carbohydrate in the meal), and parameter (iii) (any adjustments to account for health factors). This second approach will generally result in a higher calculated IOB, as long as the negative adjustments from parameter (iii) are not more than offset by the positive contributions from parameter (ii).

[0114] Other approaches to calculating IOB are certainly possible. For example, other approaches may calculate IOB taking into account parameters (i) and (iii) but not parameter (ii). It is understood that references to insulin on-board or IOB in the following discussion may be calculated using any of the aforementioned approaches. In some embodiments, the HCP, the patient, or both may instruct the insulin dosing algorithm to use a particular approach to calculate IOB. For example, screenshot 1500 in FIG. 15B shows that the HCP may select either a “conservative” option or a “standard” option for calculating effective insulin (e.g., IOB). The “standard” option corresponds to the first approach discussed above, and the “conservative” option corresponds to the second approach. The MMA may include logic capable of calculating IOB using both the first and second approaches, and the patient, HCP, and / or both may be given the option to choose between the two approaches when calculating a recommended bolus.

[0115] A. Daily titration An exemplary daily titration algorithm and associated dosing regimen is described below.

[0116] The recommended dose starts with an initial value set by the HCP when prescribing the dosing regimen. The default starting dose is 10% of the total daily basal insulin for breakfast or lunch titrations and 5% for dinner titrations. The recommended dose for each subsequent day is calculated based on the glucose readings recorded on the previous day; that is, the recommended dose for day 2 is calculated based on the glucose readings for day 1, the recommended dose for day 3 is calculated based on the glucose readings for day 2, and so on. Some exemplary rules for calculating each recommended dose for the subsequent days are provided in the table below. [Table 1]

[0117] An exemplary daily titration dosing regimen is appropriate for users aged 18-85 years with T2DM (type 2 diabetes mellitus) who meet the following criteria: Failure to achieve glycemic targets despite optimization of basal insulin, regardless of metformin administration - Intensified mealtime insulin therapy is required Those with an appropriate glucose target range of 85-114 mg / dL

[0118] To enable an exemplary daily titration dosing regimen, the HCP sets the following parameters: Daily total basal insulin (TBI) in insulin units Initial starting dose and meal titration in insulin units

[0119] In addition, the HCP can set the following parameters: Stable dose(s) per meal(s) in insulin units

[0120] The MMA will calculate the recommended dose using the following additional inputs: Current GL in mg / dL: Current GL is used by the MMA to prevent recommending insulin doses when the patient has hypoglycemia (glucose ≤ 70 mg / dL) Preprandial GL (GL) in mg / dL: Preprandial GL is the GL taken following the previous day's titration dose

[0121] In at least one embodiment, the exemplary daily titration dosing regimen does not take into account correction doses, IOB (insulin on board), or adjustment factors as inputs for calculating the recommended dose.

[0122] In at least one embodiment, the MMA 568 uses the glucose values ​​entered by the patient to provide recommendations for initiating and titrating basal insulin to be administered at a meal, and is intended to be used in this manner multiple times per day under direction from an HCP to enter glucose levels and receive dosing recommendations.

[0123] B. Fixed dose An exemplary fixed dose algorithm and associated regimen is described below, which may allow the HCP to set a "fixed" bolus amount for each meal, modified by any adjustments necessary to correct for the patient's glucose level being outside of a desired range.

[0124] Meal choices can include no meal (e.g., correction dose only), breakfast, lunch, or dinner. The HCP can assign a fixed dose value to a single mealtime, the same fixed dose value to multiple mealtimes, or different fixed dose values ​​to multiple mealtimes. Dosing regimens can include insulin on-board (IOB) dose adjustments, correction of glucose levels (GL) above or below GL targets, and lifestyle or health factors (e.g., exercise, stress, illness, steroids, or menstruation).

[0125] An exemplary fixed dose regimen may be appropriate for users with type 1 diabetes mellitus (T1DM) or type 2 diabetes mellitus (T2DM) who are inexperienced with bolus therapy or require optimization of bolus doses. In some cases, users may require multiple daily injections of prandial insulin using fast-acting insulin analogs.

[0126] To enable an exemplary fixed dose regimen, the HCP can set the following parameters: Fixed dose (FD) in insulin units per meal type selected by the patient Target GL in mg / dL (GL T ) Insulin Sensitivity Factor (ISF) in mg / dL / insulin Insulin duration in hours (ID)

[0127] In some embodiments, the HCP can control whether the user is able to change settings specific to the regimen. For example, the user may not be able to change the insulin to carbohydrate ratio unless such changes are enabled by the HCP. Certainly other examples can be enumerated herein as well. Additionally, in some embodiments, the HCP can enable any, all, or none of the following lifestyle modifiers and set corresponding adjustment amounts: When enabled, the lifestyle modifiers allow the MMA patient-user to indicate, for example, via a user interface on the mobile device, whether they are experiencing certain conditions that may affect the amount of insulin needed by the body, such as whether the patient is exercising or physically active, whether the patient is experiencing stress, whether the patient is ill, whether the patient is taking steroids, or whether the patient is menstruating. For each of these lifestyle modifiers, the HCP sets the adjustment amount in percentages. The percentage value is converted to a decimal value for use in the equation. If the HCP has not enabled the modifier, the dosing regimen will use a value of 0. Activity Factor (AF) in percentage Stress factor (SF) in percent Percentage of disease factors (IF) Steroid Factor (StF) in percent Menstrual Factor (MF) in percentage

[0128] The MMA will calculate the recommended dose using the following additional inputs: Meal selection (no meal, breakfast, lunch, dinner) to determine FD value in insulin units Current GL in mg / dL (GL) · Current time in hours (t) · Note: The current time may include hours, minutes, and seconds, but may be used in calculations as a fraction of a time.

[0129] Insulin on board (IOB), i.e. all insulin doses that are still valid for the current period, will be incorporated into the calculation. A previous dose is considered "valid" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the previous dose can be calculated using the following parameters: -Delivery bolus in insulin units (DB) Bolus delivery time in hours (t DB ) ·Magnification (X) When individual delivery boluses are administered within 0.5 hours, X=0 When an individual delivery bolus is administered more than 0.5 hours prior to the ID time, X=1

[0130] As mentioned above, the DB parameter in the IOB calculation of a particular previously administered insulin dose can be defined in one of two ways. According to these two methods, the DB parameter can be set as either (i) only the glucose correction portion of the previous dose, or (ii) the entire amount of insulin injected in the previous dose. Option (i) corresponds to the first approach discussed above, and is also referred to as the "standard" option in FIG. 15B herein. Under this option, the glucose correction portion of the previous dose is calculated according to the following formula:

number

[0131] According to an exemplary fixed dose regimen, the bolus insulin recommended dose (RD) can be calculated using the following formula:

number

[0132] The term FD represents the fixed dose portion of the formula.

number

number

[0133] The following considerations apply to the formula: If the patient selects no meal, the fixed dose value is 0; however, the patient will still receive a correction dose if applicable. ·Correction dose

number

number

[0134] If the calculated recommended dose returns a negative value, the MMA will recommend 0 units of insulin. Alternatively, if the MMA detects that the patient is or will be in a hypoglycemic state and / or if the MMA determines that the patient has too high an IOB (insulin on board, i.e., the amount of insulin in the patient's body), the MMA can recommend that the patient eat a meal or a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is or will be in a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other medication that will increase the patient's glucose levels.

[0135] This exemplary fixed dosing regimen can reduce the complexity of bolus insulin dosing by allowing the user to receive a recommended dose based on a fixed dosing regimen configured by the HCP. If the user accepts the dosing regimen prescription, the user can enter the app and select to enter the recommended bolus dose workflow. The user selects a meal, enters and / or confirms a glucose measurement, selects any additional modifiers such as changes in activity or stress, and receives a recommended bolus dose. The fixed dosing regimen takes into account the amount of insulin assigned by the HCP to compensate for the meal, a correction dose based on current and target blood glucose levels, and insulin onboarding based on internal insulin PKPD data.

[0136] C. Carbohydrate Bolus Calculator An exemplary carbohydrate bolus calculator algorithm and associated regimen is described below.

[0137] The exemplary carbohydrate bolus calculator regimen is based on rules for "topping up" the carbohydrate content of meals, a method recommended in clinical guidelines as an individualized method of matching pre-prandial insulin to meal intake. Therefore, it can be used at any time of the day and does not need to be fixed to a specific meal. The regimen calculates the recommended bolus insulin dose based on insulin sensitivity, carbohydrate intake, GL target, and current GL. It will also take into account correction doses, IOB, and optional adjustment factors.

[0138] The bolus can be calculated based on two factors: (i) the insulin needed to compensate for food or carbohydrates, and (ii) the insulin needed to correct hyperglycemia.

[0139] Bolus doses for food or carbohydrate replacement are prescribed based on the insulin-to-carbohydrate ratio (ICR), which represents the number of grams of carbohydrate that are replaced or processed by one unit of insulin. Generally, one unit of fast-acting insulin will process 12-15 grams of carbohydrate, however, this parameter can vary from 4 to 30 grams of carbohydrate or more, depending on the individual's sensitivity to insulin. Insulin sensitivity can vary by time of day, individual, and is affected by physical activity and stress.

[0140] The exemplary carbohydrate bolus calculator regimen is appropriate for T1DM or T2DM users who perform accurate carbohydrate counting or, in the judgment of the HCP, can learn to perform accurate carbohydrate counting. In some cases, users may require multiple daily injections of prandial insulin using fast-acting insulin analogs.

[0141] To enable an exemplary carbohydrate bolus calculator regimen, the HCP can set the following parameters: Target GL in mg / dL (GL T ) Insulin Sensitivity Factor (ISF) in mg / dL / insulin Insulin-to-Carb Ratio (ICR), carbohydrate in grams / insulin units Insulin duration in hours (ID),

[0142] In addition, the HCP can enable any, all, or none of the following lifestyle modifiers and set the corresponding adjustment amounts. The HCP sets the lifestyle factor adjustments using percentages appropriate for the patient. The percentage values ​​are converted to decimal values ​​for use in the equation. If the HCP does not enable a modifier, the dosing regimen will use a value of 0. Activity Factor (AF) in percentage Stress factor (SF) in percent Percentage of disease factors (IF) Steroid Factor (StF) in percent Menstrual Factor (MF) in percentage

[0143] The MMA will calculate the recommended dose using the following additional inputs: Current GL in mg / dL (GL) · Current time in hours (t) Carbohydrate intake (CHO), carbohydrates in grams, or meal insulin in insulin units (MI)

[0144] Insulin on board (IOB), i.e. all insulin doses that are still valid for the current period, will be incorporated into the calculation. A previous dose is considered "valid" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the previous dose can be calculated using the following parameters: -Delivery bolus in insulin units (DB) Bolus delivery time in hours (t DB ) ·Magnification (X) o When individual delivery boluses are administered within 0.5 hours, X=0 o When an individual delivery bolus is administered more than 0.5 hours prior to the ID time, X=1

[0145] As mentioned above, the DB parameter in the IOB calculation can be defined in multiple ways. For example, the DB parameter can be set as either (i) the total amount of insulin from the previous dose, or (ii) only the glucose correction portion of the previous dose.

[0146] The MMA user can choose to enter either a carbohydrate intake (CHO) (e.g., an expected number of carbohydrates in a meal) or a prandial insulin (MI) (e.g., expressed in units of insulin). If the MMA user chooses to enter prandial insulin, the MMA user can enter the number of units of insulin that the user expects to compensate for a particular meal. 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 compensate for that type of meal, the MMA user can choose to enter the number of units of prandial insulin instead of the expected carbohydrate intake. Depending on whether the MMA user enters carbohydrate intake or prandial insulin, the recommended dose will be calculated using the appropriate formula below.

[0147] Once the user has entered the carbohydrate intake value, the bolus insulin recommended dose (RD) is calculated using the following formula:

number

number

[0148] Once the user has entered their meal insulin value, the bolus insulin recommendation is calculated using the following formula:

number

[0149] The following considerations apply to the formula: ·Correction dose

number

number

[0150] If the calculated recommended dose returns a negative value, the MMA will recommend 0 units of insulin. Alternatively, if the MMA detects that the patient is or will be in a hypoglycemic state and / or if the MMA determines that the patient has too high an IOB (insulin on board, i.e., the amount of insulin in the patient's body), the MMA can recommend that the patient eat a meal or a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is or will be in a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other medication that will increase the patient's glucose levels.

[0151] The exemplary carbohydrate bolus calculator regimen helps reduce the complexity of bolus insulin dosing by allowing the user to receive a recommended dose based on the bolus calculator regimen configured by the HCP. If the user accepts the dosing regimen prescription, the user can choose to enter the app and enter the recommended bolus dose workflow. The user will enter and / or confirm glucose level measurements, enter the number of carbohydrates planned to be ingested, select any additional modifiers such as changes in activity or stress, and receive the recommended bolus dose. The user can choose to enter the number of units of insulin needed to compensate for the meal instead of the amount of carbohydrates, which helps with dose corrections using the regimen and takes into account insulin onboarding. The carbohydrate bolus calculator dosing regimen takes into account the amount of insulin to compensate for the planned carbohydrate intake, the correction dose based on the current blood glucose level and the target blood glucose level, and insulin onboarding based on internal insulin PKPD data.

[0152] D. Carbohydrate Meal Size Based Calculator An exemplary carbohydrate meal size based calculator algorithm and associated regimen is described below. The exemplary carbohydrate meal size based calculator regimen utilizes the functionality of the exemplary carbohydrate bolus calculator regimen described above, with additional configuration by the HCP for a qualitative assessment of small, medium, and large meals of carbohydrate meal content. For example, instead of the MMA user inputting the expected carbohydrate number in a meal, or the amount of insulin at the meal, the MMA user may simply indicate that he or she plans to have a "small", "medium", or "large" meal. The MMA user's selection is then converted into an estimated carbohydrate number based on preset values ​​(configurable by the HCP and / or the MMA user) for a "small", "medium", or "large" meal.

[0153] The exemplary carbohydrate meal size based calculator regimen is suitable for users with T1DM and T2DM who can estimate meal size, specifically the carbohydrate content of a meal. In some cases, users may require multiple daily injections of prandial insulin using fast-acting insulin analogs.

[0154] To enable a computerized regimen based on exemplary carbohydrate meal sizes, the HCP can set the following parameters: Target GL in mg / dL (GL T ) Insulin Sensitivity Factor (ISF) in mg / dL / insulin Insulin-to-Carb Ratio (ICR), carbohydrate in grams / insulin units Insulin duration in hours (ID), Carbohydrate estimate for a "small" meal size in grams of carbohydrate Estimated carbohydrate amount for a "medium" meal size in grams of carbohydrate Estimated carbohydrate content for a "large" meal size in grams of carbohydrate

[0155] In addition, the HCP can enable any, all, or none of the following lifestyle modifiers and set the corresponding adjustment amounts. The HCP sets the lifestyle factor adjustments using percentages appropriate for the patient. The percentage values ​​are converted to decimal values ​​for use in the equation. If the HCP does not enable a modifier, the dosing regimen will use a value of 0. Activity Factor (AF) in percentage Stress factor (SF) in percent Percentage of disease factors (IF) Steroid Factor (StF) in percent Menstrual Factor (MF) in percentage

[0156] The MMA will calculate the recommended dose using the following additional inputs: Current GL in mg / dL (GL) · Current time in hours (t) Carbohydrate intake meal size (MS) as a choice of small, medium, large, or none The MMA will replace meal sizes with the corresponding grams of carbohydrate based on the HCP's pre-defined meal size. If the patient selects the no meal option, the MMA replaces the meal size with a value of 0.

[0157] Insulin on board (IOB), i.e. all insulin doses that are still valid for the current period, will be incorporated into the calculation. A previous dose is considered "valid" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the previous dose can be calculated using the following parameters: -Delivery bolus in insulin units (DB) Bolus delivery time in hours (t DB ) ·Magnification (X) When individual delivery boluses are administered within 0.5 hours, X=0 When an individual delivery bolus is administered more than 0.5 hours prior to the ID time, X=1

[0158] As mentioned above, the DB parameter in the IOB calculation can be defined in multiple ways. For example, the DB parameter can be set as either (i) the total amount of insulin from the previous dose, or (ii) only the glucose correction portion of the previous dose.

[0159] The recommended bolus insulin dose (RD) is calculated using the following formula:

number

number

[0160] The following considerations apply to the formula: ·Correction dose

number

number

[0161] If the calculated recommended dose returns a negative value, the MMA will recommend 0 units of insulin. Alternatively, if the MMA detects that the patient is or will be in a hypoglycemic state and / or if the MMA determines that the patient has too high an IOB (insulin on board, i.e., the amount of insulin in the patient's body), the MMA can recommend that the patient eat a meal or a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is or will be in a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other medication that will increase the patient's glucose levels.

[0162] The exemplary carbohydrate meal size based calculator regimen can help reduce the complexity of bolus insulin dosing by allowing the user to receive a recommended dose based on a meal size based calculator regimen configured by the HCP. If the user accepts the dosing regimen prescription, the user can enter the app and select to enter the recommended bolus dose workflow. The user will enter and / or confirm glucose measurements, select meal size, select any additional modifiers such as changes in activity or stress, and receive a recommended bolus dose. The carbohydrate meal size based calculator dosing regimen takes into account the amount of insulin to compensate for the planned carbohydrate intake, correction doses based on current and target blood glucose levels, and insulin on-board based on internal insulin PKPD data.

[0163] 19 is a flow chart illustrating an example process 1900 implemented by an MMA running on a mobile device (e.g., MMA 568 running on mobile device 104 or MMA 570 running on mobile device 532). The MMA uses process 1900 to collect information about a patient's condition and recommend insulin doses on the MMA according to a prescribed and effective insulin administration regimen.

[0164] In step 1902, the MMA receives a glucose reading from the patient. This can be done in a variety of ways. For example, FIG. 20 illustrates an example screenshot from the MMA where the MMA automatically syncs with the patient's connected glucose sensor, such as a continuous glucose meter (CGM). As shown in FIG. 20, the MMA may display the time the glucose meter reading was taken from the connected glucose meter (in this example, 9:31 AM), the blood glucose level (in this case, 355 mg / dL), and also allow the patient to edit the blood glucose reading by touching a button labeled "OR EDIT GLUCOSE". If the patient agrees with the glucose level received from the connected glucose meter, or if the patient is finished editing the glucose level, the patient can touch a button labeled "CONFIRM GLUCOSE", at which point the MMA will record the presented glucose level in the patient's log.

[0165] Alternatively, the MMA can allow the patient to manually enter their glucose level or prompt the MMA to sync with a connected glucose meter. These methods of receiving the patient's glucose level are shown in FIGS. 21A, 21B, and 21C. In FIG. 21A, the MMA prompts the patient to enter their glucose level. If the patient touches the button labeled "Enter Blood Glucose Level," the MMA transitions to a screen shown in FIG. 21B, where the patient can manually enter their glucose level. Once the patient has entered their glucose level, the patient can touch a "Next" button to instruct the MMA to record the entered glucose level in the patient's log. If the patient touches the button labeled "Or Sync with Meter," the MMA transitions to a screen shown in FIG. 21C, where the MMA syncs with the patient's connected glucose meter (e.g., BGM, CGM, or FGM). In this case, as shown in FIG. 21C, the MMA receives a glucose level of 355 mg / dL from the patient's connected glucose meter. Alternatively, if the patient touches the "Or Sync with Meter" button in Figure 21B, the MMA also transitions to the screen shown in Figure 21C. Once the MMA receives the glucose level from the connected meter, the patient can instruct the MMA to record the glucose level in the patient's log by touching the "Next" button.

[0166] Returning to FIG. 19, once the MMA receives a glucose reading, the MMA moves to step 1904. At this point, the MMA determines which dosing regimen is prescribed / active on the MMA. If a daily titration regimen is prescribed / active, the process 1900 branches to step 1906. If a fixed dose regimen is prescribed / active, the process 1900 branches to step 1908. If a carbohydrate bolus calculator regimen is prescribed / active, the process 1900 branches to step 1910. If a carbohydrate meal size based calculator regimen is prescribed / active, the process 1900 branches to step 1912.

[0167] In step 1906 (used for daily titration regimens), the MMA receives a selection of meal type or time of day from the patient. For example, the exemplary screenshots shown in FIGS. 22A-22C allow the patient to indicate whether they plan to take a dose at breakfast (FIG. 22A), lunch (FIG. 22B), dinner (FIG. 22C), or bedtime (FIG. 22D). The MMA uses this information to calculate a recommended insulin dose according to the exemplary algorithm described above for the "daily titration" dosing regimen.

[0168] In step 1908 (used for fixed dose regimens), the MMA receives from the patient a meal type selection, as well as any health factors that apply. For example, the exemplary screenshots shown in FIGS. 23A-23D allow the patient to indicate whether they plan to take a dose that is not associated with any meal (FIG. 23A), at breakfast (FIG. 23B), at lunch (FIG. 23C), or at dinner (FIG. 23D). Regardless of the meal selection the patient selects, the patient can also select any health factors the patient is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. The MMA uses this information to calculate a recommended insulin dose according to the exemplary algorithm described above for the "fixed dose" dosing regimen.

[0169] In step 1910 (used for carbohydrate bolus calculator regimens), the MMA receives the expected number of grams of carbohydrates the patient plans to ingest and / or the expected number of units of prandial insulin the patient predicts will be sufficient to compensate for the carbohydrates the patient plans to ingest. The MMA also receives any health factors that apply from the patient. For example, FIG. 24A prompts the patient to enter the expected number of grams of carbohydrates to be ingested. The patient can enter the estimated number of carbohydrates using the numeric keypad. As illustrated in FIG. 24B, the patient has indicated that he plans to ingest 96 grams of carbohydrates. If the patient presses the "Next" button, the MMA transitions to the screen shown in FIG. 24C, where the patient can select any health factors that he is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. Once the patient has finished selecting health factors, the patient can touch the "Next" button (not shown), which is displayed once at least one health factor has been selected. Alternatively, if the patient is not experiencing any of these health factors, the patient can press the "Skip" button. If at least one health factor has been selected or if the patient presses the "Skip" button, the MMA transitions to the screen shown in Figure 24D, where the MMA displays the selected grams of carbohydrates, as well as any selected health factors, for confirmation by the patient. The patient can confirm by touching the "Next" button.

[0170] Alternatively, the patient may decide to enter the number of units of prandial insulin that the patient expects (e.g., based on experience) to supplement the meal that he or she plans to take. The patient may indicate to the MMA that he or she will be entering prandial insulin by selecting the "Meal Insulin" radio button in FIG. 24A. If the "Meal Insulin" radio button is selected, the MMA transitions to a series of screens shown in FIGS. 25A-D. In FIG. 25A, the MMA prompts the patient to enter the number of units of prandial insulin using a numeric keypad. For example, as illustrated in FIG. 25B, the patient has entered 12 units of prandial insulin. If the patient presses the "Next" button, the MMA transitions to a screen shown in FIG. 25C, where the patient may select any health factors that the patient is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. Alternatively, if the patient is not experiencing any of these health factors, the patient may press the "Skip" button. In FIG. 25D, the MMA displays the selected number of units of prandial insulin, as well as any selected health factors, for confirmation by the patient. The patient can be confirmed by pressing the "Next" button.

[0171] Returning to FIG. 19, in step 1912 (used for carbohydrate meal size based calculator regimen), the MMA receives a meal size selection from the patient, as well as any health factors that apply. For example, the exemplary screenshots shown in FIGS. 26A-D allow the patient to indicate whether they plan to take a dose that is not associated with any meal (FIG. 26A), a "small" meal (FIG. 26B), a "medium" size meal (FIG. 26C), or a "large" size meal (FIG. 26D). These meal size selections are converted into expected carbohydrate numeric values ​​according to the pre-set meal size definitions discussed above. Regardless of the meal size selection the patient selects, the patient may also select any health factors the patient is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. The MMA uses this information to calculate a recommended insulin dose according to the exemplary algorithm described above for the "Carbohydrate Meal Size Based Calculator" regimen.

[0172] Returning to FIG. 19, after collecting information from the patient in steps 1906, 1908, 1910, or 1912, the MMA branches to step 1914 where it calculates and presents a recommended dose of insulin. The algorithm for calculating the recommended dose of insulin varies depending on which dosing regimen is currently prescribed and in effect, and has been described above. The MMA then presents this dose to the user (in this example, recommending a dose of 10 units of prandial insulin), as shown in the exemplary screenshot of FIG. 27A. The patient may also be given the opportunity to edit the recommended dose, for example, by touching the "Edit Dose" button in FIG. 27A.

[0173] In step 1916, the MMA determines if the user has edited the recommended dose. If so, the MMA branches to step 1918 where it updates the suggested 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 suggested dose, or decrease the recommended dose by pressing the "-" button to the left of the suggested dose. Once the patient has finished editing the recommended dose, the patient can touch the "Save" button, which returns the patient to the screen shown in FIG. 27A. If a daily titration dosing regimen is prescribed / active, the MMA can optionally display an additional message shown in FIG. 27C, reminding the patient that it is important to check their blood glucose value before their next meal, as the titration dosing regimen will use this value to adjust the next day's insulin dose.

[0174] If the patient has not edited the proposed dose, the MMA branches to step 1920 where it determines if the user confirmed taking the dose. If not, the MMA returns to step 1916. If edited, the MMA proceeds to step 1922 where it records the dose. This process is shown in Figures 27A and 27C, where the patient can confirm that they have taken the dose by touching a button labeled "Took This Dose." Touching this button causes the MMA to record the proposed dose in the patient's logbook.

[0175] FIG. 28 illustrates an alternative user interface display 2800 presenting doses of insulin to be administered to the patient, currently being administered to the patient, and / or recently administered to the patient. The doses of insulin may be recommended by one of the insulin administration regimens described above, or may be manually entered or adjusted by the patient. The user interface display 2800 may be displayed on the MMA instead of, or in addition to, the screenshots illustrated in FIGS. 27A-27C. Alternatively, or in addition, the user interface display 2800 may be displayed on a drug delivery device, such as on a visual screen attached to an insulin pen.

[0176] The user interface display 2800 includes multiple panels. A panel may contain data that is displayed by a processor on a portion of a visual display screen. A first panel 2802 displays the number of units of insulin that are to be administered to the patient, are currently being administered to the patient, or have recently been administered to the patient, in the illustrated example, the first panel 2802 shows 3.5 units of insulin.

[0177] The second panel 2804 displays the amount of carbohydrates that is expected to be covered by the number of units of insulin displayed by the first panel. As used in the specification and claims herein, an amount of carbohydrates X that is "expected to be covered" by a certain number of units Y of insulin should correspond to an estimated amount of carbohydrates that, if taken by a patient with diabetes, would require the administration of Y units of insulin to keep the patient's glucose level after ingestion of the amount X of carbohydrates the same as the patient's glucose level before ingestion of the amount X of carbohydrates. In the illustrated example, the second panel 2804 indicates that 28 g of carbohydrates are expected to be covered by the proposed 3.5 units of insulin. The carbohydrate value displayed by the second panel 2804 can be calculated by dividing the number of units of insulin displayed by the first panel 2802 by the insulin-to-carbohydrate ratio (ICR). The user interface display 2800 can use a default ICR value that applies to all patients or a patient-specific ICR provided by the patient, caregiver, or HCP. In some embodiments, the ICR may be both patient and time-of-day specific if the ICR for a particular patient is known to vary according to a predictable pattern with time of day. In this example, if the ICR used by the user interface display 2800 is 0.125, the grams of carbohydrates (28g) displayed by the second panel 2804 may be derived by dividing the units of insulin (3.5 units) displayed by the first panel 2802 by the ICR of 0.125.

[0178] The third panel 2806 indicates whether the carbohydrate value displayed by the second panel corresponds to a small or large meal size. In the example illustrated in FIG. 28, this third panel 2806 takes the form of an area displaying a range of meal sizes between "small", "medium", or "large" meal sizes, and includes an indicator 2810 indicating where the carbohydrate value displayed by the second panel 2804 falls within this area. In other embodiments (not shown), the third panel 2806 may simply display letters, words, or symbols indicating a meal size classification. In the simplest case, meals may be simply classified into one of two categories, "small" or "large". In some embodiments, meals may be classified into one of three categories, "small", "medium", or "large". In still other embodiments, meals may be classified into four or more meal size classifications.

[0179] The third panel 2806 may be calculated based on adjustable parameters that define different meal size classifications. For example, in an embodiment that classifies meals into three categories (e.g., "small", "medium", or "large"), such adjustable parameters may include a minimum carbohydrate threshold for a "medium" size meal (e.g., 30g) and a maximum carbohydrate threshold for a "medium" size meal (e.g., 60g). Any carbohydrate value that falls between the minimum and maximum carbohydrate thresholds may be classified as a "medium" size meal. Any carbohydrate value that falls below the minimum carbohydrate threshold may be classified as a "small" size meal, and any carbohydrate value that falls above the maximum carbohydrate threshold may be classified as a "large" size meal. Panels that include regions that display ranges (as illustrated in FIG. 28) may also determine where the indicator is located based on these meal size definitions, for example, by measuring the position of the indicator along the region depending on the meal size definitions. As previously discussed, these meal size definitions may be customizable by the patient, caregiver, or HCP.

[0180] The fourth panel 2808 displays the expected drop in the patient's glucose level resulting from administration of the number of units of insulin displayed by the first panel 2802. In the illustrated example, the fourth panel 2808 indicates that a drop in blood glucose of 75 mg / dL is expected to result from administration of 3.5 units of insulin displayed by the first panel 2802. The glucose drop displayed by the fourth panel 2808 can be calculated by multiplying the number of units of insulin displayed by the first panel 2802 by an insulin effectiveness value (ISF). The user interface display 2800 can use a default ISF that applies to all patients or a patient-specific ISF provided by the patient, caregiver, or HCP. In some embodiments, the ISF can be both patient and time-of-day specific if a particular patient's ISF is known to vary according to a predictable pattern with time of day. In this example, if the ISF is 21.4, the predicted BG drop (75 mg / dL) displayed by the fourth panel 2808 can be derived by multiplying the number of units displayed by the first panel 2802 (3.5 units) by the ISF of 21.4.

[0181] While FIG. 28 shows a user interface display 2800 including all four panels 2802, 2804, 2806, and 2808, some embodiments may display only a subset of these four panels or may display additional panels. For example, some embodiments 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 order, configuration, or relative sizes displayed in FIG. 28.

[0182] Regardless of which particular panel is displayed, all displayed panels may be updated when the user adjusts the number of units of insulin to be administered, currently administered, or recently administered. Figure 29 illustrates a series of user interface displays as the number of units of insulin is adjusted from 3.5 units in display 2900a to 4.0 units in display 2900b, and 4.5 units in display 2900c. 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 2902c. Similarly, the carbohydrate numbers displayed in the second panel (see panels 2904a, 2904b, and 2904c), the meal size indicator in the third panel (see panels 2906a, 2906b, and 2906c), and the predicted glucose drop in the fourth panel (see panels 2908a, 2908b, and 2908c) are automatically updated as the number of insulin units changes.

[0183] The example shown in FIG. 29 shows an example where the number of units of insulin is adjusted in 0.5 unit increments, but it does not have to be the same. In general, the granularity with which the number of units can be adjusted on the disclosed user interface may depend on the dose resolution of the delivery device with which the user interface is associated. For example, if the delivery device (such as an insulin pen) is capable of delivering different doses in 1.0 unit increments, the user interface may also be configured to allow dose adjustment in 1.0 unit increments. If the delivery device is capable of delivering different doses in 2.0 unit increments, the user interface may also be configured to allow adjustment in 2.0 unit increments. The same is true for other delivery device dose resolutions, such as 0.1 units, 5.0 units, or any other dose resolution. Matching the dose resolution of the user interface to the dose resolution of the patient's delivery device allows the patient to easily determine how to set the dose on their delivery device. In some cases, the user interface may be designed to work with multiple types of delivery devices with different dose resolutions. In such an embodiment, the dose analysis capabilities on the user interface may be configurable by the patient, caregiver, or HCP to match the dose analysis capabilities on the delivery device for a particular patient.

[0184] Displaying the number of units of insulin administered / currently administered / recently administered along with the number of carbohydrates to be covered, an indication of meal size, and / or an expected glucose decline provides multiple benefits to the patient. Patients often administer insulin to cover a certain carbohydrate number, to cover a certain meal size, or to achieve a certain decline in glucose levels. By displaying some or all of this information to the patient, the patient can easily determine if the displayed dose will achieve their goal and can adjust the displayed dose accordingly.

[0185] Also, displaying this information simultaneously solves a technical problem present in the user interfaces of prior known delivery devices by reducing overdosing or underdosing due to rounding errors. For example, when a patient attempts to calculate a dose to supplement a particular meal, the patient often begins by estimating the number of carbohydrates in the meal at hand. Once the patient arrives at an estimated number of carbohydrates, the patient then calculates a dose size based on the estimated number of carbohydrates. However, when calculating a dose size, depending on the dosimetry capabilities of the drug delivery device, the patient often rounds to the nearest unit or half unit of insulin. This process requires the patient to go through two rounding or estimation steps to arrive at an insulin dose: a first step where the patient estimates the number of carbohydrates in the meal, and a second step where the patient converts that carbohydrate estimate into units of insulin. This two-step process increases the risk of over-estimating or under-estimating the dose needed to supplement a particular meal.

[0186] This is best explained using an exemplary scenario. Consider the case where a patient estimates that they are about to ingest a meal containing 75g of carbohydrates. The patient arrives at this estimate based solely on the appearance of the meal and their own previous experience. The user then calculates the dose based on an insulin to carbohydrate ratio of 8, which results in a dose of 75g / 8=9.375 units. However, due to the dose resolution capabilities of the user's drug delivery device, the user can only administer every unit of insulin, so rounds down and administers only 9 units. In this case, if the patient underestimates the number of carbohydrates in the meal (e.g., the meal in front of the patient actually contains 80g of carbohydrates) and then rounds down, the patient may doubly underestimate the dose needed to supplement the meal. If not supplemented, this underdosing of insulin may make it more difficult for the patient to achieve their glycemic goal.

[0187] By displaying the number of carbohydrates to be supplemented, as well as the number of units of insulin, the user interface display reduces errors that occur due to rounding. By dialing 9 units to 10 units on the user interface, the patient can quickly determine that 9 units will supplement 72 grams of carbohydrates and 10 units will supplement 80 grams of carbohydrates. The user can then estimate whether their meal in front of them is closer to 72 grams of carbohydrates or closer to 80 grams of carbohydrates. In contrast to the previous scenario, which required two calculation or estimation steps, this calculation involves only a single simple estimation step by the patient. This increases the chances that the patient will arrive at the correct dose to supplement their meal in front of them. For example, when faced with a choice of 72 grams to 80 grams, the patient may be more likely to determine that their meal in front of them is actually closer to 80 grams and may choose to administer 10 units of insulin.

[0188] The disclosed user interface can also reduce rounding errors in other scenarios, including situations where a patient makes dosing decisions based on meal size and / or a target drop in glucose level rather than carbohydrates. By displaying the meal size and / or estimated drop in glucose level along with the suggested insulin dose, the disclosed user interface also reduces the number of estimation / rounding steps required by the patient, thus increasing the chances that the patient will arrive at the correct dose to compensate for a particular meal or achieve a particular glucose level.

[0189] As mentioned above, the disclosed user interface 2800 can be displayed on an MMA running on a mobile device instead of or in addition to the screenshots previously disclosed in Figures 27A-27C. In addition, however, the disclosed user interface 2800 can also be displayed on a mobile drug delivery device, such as a connected insulin pen. One such exemplary implementation is illustrated in Figure 30, which shows a connected insulin pen 3002 having a screen 3000 displaying the aforementioned user interface. Such a connected insulin pen 3002 can wirelessly communicate with a mobile device, such as the mobile device 104, via Bluetooth, WiFi, NFC, or other wireless link. Through this wireless link, the connected insulin pen 3002 can receive various parameters for computing information displayed by the panels of the user interface, such as insulin-to-carbohydrate ratio (ICR), insulin sensitivity value (ISF), and / or meal size definitions, such as minimum and maximum carbohydrate thresholds for a "medium" size meal (as discussed above).

[0190] FIG. 31 illustrates a flow chart showing an exemplary process performed by a mobile device (such as a smartphone or drug delivery device). In step 3102, the mobile device simultaneously presents multiple panels via a visual display on the mobile device. These panels may include a first panel displaying the number of units of insulin administered to the patient, a second panel displaying the carbohydrate value expected to be covered by the number of units of insulin displayed by the first panel, a third panel indicating whether the carbohydrate value displayed by the second panel corresponds to a small, medium, or large meal size, and / or a fourth panel displaying the expected drop in the patient's glucose level resulting from administration of the number of units of insulin displayed by the first panel. As previously mentioned, some embodiments may display only a subset of these panels rather than all four panels. Some embodiments may also display additional panels.

[0191] In step 3104, the mobile device receives user input to adjust the number of units of insulin to be administered to the patient, currently being administered to the patient, and / or recently administered to the patient. For example, this user input can be received via "plus" or "minus" buttons on an MMA screen similar to that discussed above in FIG. 27B, or using a numeric keypad. Alternatively, the user input can be received by the user dialing a knob on a connected insulin delivery device, such as an insulin pen.

[0192] In step 3106, the mobile device updates the first panel, the second panel, the third panel, and / or the fourth panel according to the adjusted number of units of insulin. As described above, this adjustment can be made using a parameter that converts the number of units of insulin to a number of carbohydrates to be supplemented (such as the insulin to carbohydrate ratio, or ICR), a parameter that converts the number of units of insulin to an expected drop in glucose level (such as the insulin effect value, or ISF), or a parameter that converts the number of carbohydrates to be supplemented to a meal size.

[0193] While the present invention has been described as having an exemplary design, the embodiments of the disclosure may be further modified within the concept and scope of the disclosure. This application is therefore intended to cover any variations, uses, or adaptations of the embodiments of the disclosure using its general principles. It should be noted that the present invention includes the following aspects. [Aspect 1] 1. A method comprising: Multiple medications related to a patient can be accessed through a healthcare professional (HCP) portal application. providing dosage regimens, each of the provided drug dosage regimens being a different and presenting a medication dosing algorithm associated with the medication. via the HCP portal application, receiving at least one HCP selection from the HCPs; A medical mobile application (MM) on a mobile device associated with the patient A) a HCP selected regimen showing said at least one HCP selected drug administration regimen; and transmitting the data. [Aspect 2] the proposed drug dosing regimen comprises one or more insulin dosing regimens; The at least one HCP selected drug administration regimen is The method of embodiment 1, comprising an insulin administration regimen. [Aspect 3] The one or more proposed insulin dosing regimens include at least one or more basal insulins. and one or more bolus insulin dosing regimens. The method according to [Aspect 4] The at least one HCP selected insulin dosing regimen is A basal insulin regimen of choice and at least one bolus insulin of the HCP's choice The method of embodiment 3, comprising a dosing regimen. [Aspect 5] Electronic Health Record (EHR) data relating to said patient is collected from a Health Information Technology (HIT) system. access to the data and presenting the EHR data via the HCP portal application; 2. The method of embodiment 1, further comprising: [Aspect 6] The at least one HCP selected insulin dosing regimen comprises a daily titrated bolus insulin. A daily titrated bolus insulin dosing regimen associated with the insulin dosing algorithm The method of embodiment 2, comprising: [Aspect 7] The at least one HCP selected insulin dosing regimen comprises a fixed dose bolus insulin Includes fixed-dose bolus insulin dosing regimens linked to phosphorus dosing algorithms 3. The method according to claim 2, [Aspect 8] The at least one HCP selected insulin dosing regimen includes a carbohydrate bolus calculator. Carbohydrate bolus calculator with associated bolus insulin dosing algorithms The method of embodiment 2, comprising an insulin administration regimen. [Aspect 9] The at least one HCP selected insulin dosing regimen is based on carbohydrate meal size. Based on carbohydrate meal size associated computer bolus insulin delivery algorithm 3. The method of embodiment 2, comprising a computer bolus insulin dosing regimen based on [Aspect 10] via a mobile device user interface of the mobile device, A patient intake table associated with said at least one HCP selected drug administration regimen. and further receiving a regimen acceptance indication from said MMA indicating that said regimen acceptance indication has been received. The method of embodiment 1, comprising: [Aspect 11] via a mobile device user interface of the mobile device, The MMA shall provide a patient refusal indication associated with at least one HCP-selected medication regimen. receiving a regimen rejection indication from the MMA indicating that the patient has rejected the regimen; In response to the indication, disable the MMA on the mobile device associated with the patient. 2. The method of embodiment 1, further comprising: [Aspect 12] The HCP selected regimen data is 2. The method of claim 1, wherein the MMA is operable to unlock the [Aspect 13] The at least one HCP selected drug dosing regimen is The MMA can be pre-stored on the mobile device only after it has been unlocked by accessing implementation data for said at least one HCP-selected medication regimen that has been 13. The method of embodiment 12, wherein the method is operable to [Aspect 14] The at least one HCP selected drug dosing regimen is The MMA is capable of binding to the at least one HCP selected drug only after the MMA has been unlocked by and operable to download implementation data of a drug administration regimen onto the mobile device. 13. The method of embodiment 12, wherein the [Aspect 15] A patient acceptance indication for said at least one HCP selected drug dosing regimen is provided by said and, upon receipt by the MA, the HCP selected regimen data is and operable on the MMA to unlock one more HCP-selected drug administration regimen. The method of embodiment 12. [Aspect 16] The MMA is communicatively coupled to an insulin delivery device associated with the patient. The method of embodiment 1, [Aspect 17] The MMA, via a mobile device user interface of the mobile device, and providing a dosing recommendation based on said at least one HCP selected drug dosing regimen. 2. The method of embodiment 1, wherein the method is configured as follows: [Aspect 18] A connected care server system, comprising: One or more servers, each server having one or more communication interfaces, one or more one or more servers, each of which includes a processor, a processor for a processor, and data storage; When executed by one or more of the processors of the one or more servers, and a TedCare server system operable to perform a set of server system functions. instructions, the data storage of the one or more servers collectively including instructions, the server system A set of system functions is A communication interface for communicating with at least one of the communication interfaces of the one or more servers. Through a healthcare professional (HCP) portal application, multiple medications related to a patient can be viewed. providing dosage regimens, each of the provided drug dosage regimens being a different and presenting a medication dosing algorithm associated with the medication. via the HCP portal application, receiving at least one HCP selection; via at least one of the communication interfaces of the one or more servers A medical mobile application (MM) on a mobile device associated with the patient. A) a HCP selected regimen showing said at least one HCP selected drug administration regimen; and transmitting the data. [Aspect 19] the proposed drug dosing regimen comprises one or more insulin dosing regimens; The at least one HCP selected drug administration regimen is 20. The system of embodiment 18, comprising an insulin administration regimen. [Aspect 20] The one or more proposed insulin dosing regimens include at least one or more basal insulins. In one embodiment, the method comprises administering to the patient a bolus insulin administration regimen and one or more bolus insulin administration regimens. 9. The system according to claim 9. [Aspect 21] The at least one HCP selected insulin dosing regimen is A basal insulin regimen of choice and at least one bolus insulin of the HCP's choice 21. The system of embodiment 20, comprising a dosing regimen. [Aspect 22] The set of server system functions: Electronic health record data (EH) related to said patient is collected from a health information technology (HIT) system. R) and presenting the EHR data via the HCP portal application; 20. The system of claim 18, comprising: [Aspect 23] The at least one HCP selected insulin dosing regimen comprises a daily titrated bolus insulin. A daily titrated bolus insulin dosing regimen associated with the insulin dosing algorithm 20. The system of claim 19, further comprising: [Aspect 24] The at least one HCP selected insulin dosing regimen comprises a fixed dose bolus insulin Includes fixed-dose bolus insulin dosing regimens linked to phosphorus dosing algorithms 20. The system according to claim 19, [Aspect 25] The at least one HCP selected insulin dosing regimen includes a carbohydrate bolus calculator. Carbohydrate bolus calculator with associated bolus insulin dosing algorithms 20. The system of embodiment 19, comprising an insulin administration regimen. [Aspect 26] The at least one HCP selected insulin dosing regimen is based on carbohydrate meal size. Based on carbohydrate meal size associated computer bolus insulin delivery algorithm 20. The system of embodiment 19, comprising a computer bolus insulin dosing regimen based on [Aspect 27] via a mobile device user interface of the mobile device, A patient acceptance indication associated with at least one HCP-selected drug administration regimen is provided to said MM. A regimen acceptance indication indicating that A has received the regimen is transmitted to the set of server system functions of the M The system of embodiment 18, further comprising receiving from the MA. [Aspect 28] via a mobile device user interface of the mobile device, The MMA shall provide a patient refusal indication associated with at least one HCP-selected medication regimen. a regimen rejection indication from the MMA indicating that the set of server system functions has received the regimen rejection indication from the MMA; and in response to the regimen rejection indication, transmitting a medical record to the mobile device associated with the patient. and disabling the MMA on the mobile device. Stem. [Aspect 29] The HCP selected regimen data is 20. The system of claim 18, wherein the MMA is operable to unlock the [Aspect 30] The at least one HCP selected drug dosing regimen is The MMA can be pre-stored on the mobile device only after it has been unlocked by accessing implementation data for said at least one HCP-selected medication regimen that has been 30. The system of embodiment 29, wherein the system is operable to: [Aspect 31] The at least one HCP selected drug dosing regimen is The MMA is capable of binding to the at least one HCP selected drug only after the MMA has been unlocked by and operable to download implementation data of a drug administration regimen onto the mobile device. 30. The system of claim 29, [Aspect 32] A patient acceptance indication for said at least one HCP selected drug dosing regimen is provided by said and, upon receipt by the MA, the HCP selected regimen data is and operable on the MMA to unlock one more HCP-selected drug administration regimen. The system of embodiment 29. [Aspect 33] The MMA is communicatively coupled to an insulin delivery device associated with the patient. 20. The system of claim 18, [Aspect 34] The MMA, via a mobile device user interface of the mobile device, and providing a dosing recommendation based on said at least one HCP selected drug dosing regimen. 20. The system of claim 18, wherein the system is configured as follows: [Aspect 35] When executed by one or more processors, the set of functions is transmitted to the one or more processors. One or more non-transitory computer-readable media storing instructions operable to cause the A medium (CRM), the set of functions comprising: Through the HCP portal application, multiple medication regimens related to the patient can be managed and providing a drug administration regimen for each of the proposed drug administration regimens, each of which is a different drug administration regimen. associated with the algorithm, via the HCP portal application, receiving at least one HCP selection from the HCPs; A medical mobile application (MM) on a mobile device associated with the patient A) a HCP selected regimen showing said at least one HCP selected drug administration regimen; and transmitting the data. [Aspect 36] the proposed drug dosing regimen comprises one or more insulin dosing regimens; The at least one HCP selected drug administration regimen is The CRM of embodiment 35, comprising an insulin dosing regimen. [Aspect 37] The one or more proposed insulin dosing regimens include at least one or more basal insulins. and one or more bolus insulin dosing regimens. CRM as described in 6. [Aspect 38] The at least one HCP selected insulin dosing regimen is A basal insulin regimen of choice and at least one bolus insulin of the HCP's choice The CRM of embodiment 37, comprising a dosing regimen. [Aspect 39] The set of functions is Electronic Health Record (EHR) data relating to said patient is collected from a Health Information Technology (HIT) system. access to the data and presenting the EHR data via the HCP portal application; The CRM of embodiment 35, further comprising: [Aspect 40] The at least one HCP selected insulin dosing regimen comprises a daily titrated bolus insulin. A daily titrated bolus insulin dosing regimen associated with the insulin dosing algorithm The CRM of embodiment 36, comprising [Aspect 41] The at least one HCP selected insulin dosing regimen comprises a fixed dose bolus insulin Includes fixed-dose bolus insulin dosing regimens linked to phosphorus dosing algorithms 37. A CRM according to embodiment 36. [Aspect 42] The at least one HCP selected insulin dosing regimen includes a carbohydrate bolus calculator. Carbohydrate bolus calculator with associated bolus insulin dosing algorithms The CRM of embodiment 36, comprising an insulin administration regimen. [Aspect 43] The at least one HCP selected insulin dosing regimen is based on carbohydrate meal size. Based on carbohydrate meal size associated computer bolus insulin delivery algorithm 37. The CRM of embodiment 36, comprising a computer bolus insulin dosing regimen based on [Aspect 44] via a mobile device user interface of the mobile device, A patient acceptance indication associated with at least one HCP-selected drug administration regimen is provided to said MM. The set of functions receives from the MMA a regimen acceptance indication indicating that A has received the regimen. The CRM of embodiment 35, further comprising: [Aspect 45] via a mobile device user interface of the mobile device, The MMA shall provide a patient refusal indication associated with at least one HCP-selected medication regimen. receiving a regimen reject indication from the MMA by the set of functions indicating that the regimen reject indication has been received; in response to the patient rejection indication, The CRM of embodiment 35, further comprising disabling the MMA. [Aspect 46] The HCP selected regimen data is The CRM of embodiment 35, wherein the CRM is operable on the MMA to unlock the [Aspect 47] The at least one HCP selected drug dosing regimen is The MMA can be pre-stored on the mobile device only after it has been unlocked by accessing implementation data for said at least one HCP-selected medication regimen that has been The CRM of embodiment 46, operable to [Aspect 48] The at least one HCP selected drug dosing regimen is The MMA is capable of binding to the at least one HCP selected drug only after the MMA has been unlocked by and operable to download implementation data of a drug administration regimen onto the mobile device. 47. The CRM of embodiment 46, [Aspect 49] A patient acceptance indication for said at least one HCP selected drug dosing regimen is provided by said and, upon receipt by the MA, the HCP selected regimen data is and operable on the MMA to unlock one more HCP-selected drug administration regimen. The CRM of embodiment 46. [Aspect 50] The MMA is communicatively coupled to an insulin delivery device associated with the patient. The CRM of embodiment 35, [Aspect 51] The MMA, via a mobile device user interface of the mobile device, and providing a dosing recommendation based on said at least one HCP selected drug dosing regimen. The CRM of embodiment 35, wherein the CRM is configured as follows: [Aspect 52] 1. A method comprising: A plurality of drug administration regimens, each associated with a different drug administration algorithm. Healthcare professionals (HCs) who indicated HCP selection of at least one medication regimen from among P) The selected regimen data is then processed by a medical device executed on a mobile device associated with the patient. and receiving, at a mobile application (MMA), the HCP selection, receiving, via a P Portal application, made for said patient; In response at least in part to receiving the HCP selected regimen data, unlocking at least one HCP selected drug administration regimen on said MMA; A method comprising: [Aspect 53] Receiving the HCP selected regimen data is performed by the HCP portal application. 53. The method of embodiment 52, comprising receiving said HCP selected regimen data from a [Aspect 54] Receiving the HCP selected regimen data is performed by the HCP portal application. The HC is connected to a connected care server system that communicates with both the MMA and the connected care server system. 53. The method of embodiment 52, comprising receiving P selection regimen data. [Aspect 55] After the receiving step and before the unlocking step, via a mobile device user interface, presenting a prompt for patient acceptance or rejection of the dosing regimen; responding to the presented prompt via the mobile device user interface; receiving a corresponding user input; Performing the unlocking step is performed by the received user input being Provided that all of the above are patient acceptance indications for one HCP-selected drug regimen. 53. The method of embodiment 52, [Aspect 56] The received user input is transmitted to the HCP portal application and the HCP portal. A connected care server system that communicates with both the mobile application and the MMA. 56. The method of embodiment 55, further comprising transmitting the signal to one or both of the stem. [Aspect 57] The unlocking step includes: Access to implementation data for at least one HCP-selected drug dosing regimen that was not previously available 53. The method of embodiment 52, comprising accessing the [Aspect 58] The unlocking step includes: unlocking the previously inaccessible at least one HC; downloading implementation data of the selected drug administration regimen onto the mobile device; 53. The method of embodiment 52, comprising: [Aspect 59] The MMA is communicatively coupled to an insulin delivery device associated with the patient. 53. The method of embodiment 52, wherein [Aspect 60] via a mobile device user interface of the mobile device, and further comprising providing dosing recommendations based on at least one HCP-selected drug dosing regimen. 53. The method according to claim 52. [Aspect 61] A mobile device associated with a patient, the mobile device comprising: a mobile device communication interface; A mobile device processor; A medical mobile application (MMA) for performing a set of MMA functions. and a processor executable by the mobile device to cause the mobile device to execute the and a mobile device data storage including instructions, wherein the set of MMA functions includes: A plurality of medication administration registers, each associated with a different medication administration algorithm. HCP selection of at least one medication regimen from among receiving HCP) selected regimen data at the MMA, wherein the HCP selection is , receiving, made for said patient through the HCP Portal application; , In response at least in part to receiving the HCP selected regimen data, unlocking at least one indicated HCP-selected drug dosing regimen on said MMA; and including a mobile device. [Aspect 62] Receiving the HCP selected regimen data is performed by the HCP portal application. 62. The method of claim 61, further comprising receiving said HCP selected regimen data from a device. [Aspect 63] Receiving the HCP selected regimen data is performed by the HCP portal application. The HC is connected to a connected care server system that communicates with both the MMA and the connected care server system. 62. The mobile device of embodiment 61, further comprising receiving P selection regimen data. [Aspect 64] The mobile device further includes a user interface, the set of MMA functions comprising: After the receiving step and before the unlocking step, the mobile device user and administering to the patient, via the interface, at least one HCP selected drug administration regimen. presenting a prompt for acceptance or patient refusal; responding to the presented prompt via the mobile device user interface; receiving a corresponding user input; Performing the unlocking step is performed by the received user input being Provided that all of the above are patient acceptance indications for one HCP-selected drug regimen. 62. A mobile device as described in embodiment 61. [Aspect 65] The MMA function set transmits the received user input to the HCP portal application. application and a computer that communicates with both the HCP Portal Application and the MMA. and transmitting the information to a connected care server system or both. 64. A mobile device as described in claim 64. [Aspect 66] The unlocking step includes: Access to implementation data for at least one HCP-selected drug dosing regimen that was not previously available 62. The mobile device of embodiment 61, further comprising: [Aspect 67] The unlocking step includes: unlocking the previously inaccessible at least one HC; downloading implementation data of the selected drug administration regimen onto the mobile device; 62. The mobile device of embodiment 61, comprising: [Aspect 68] The MMA is communicatively coupled to an insulin delivery device associated with the patient. 62. The mobile device of embodiment 61, [Aspect 69] The mobile device further includes a user interface, the set of MMA functions being via a mobile device user interface, 62. The mobile therapy method of claim 61, further comprising providing a dosing recommendation based on a therapeutic agent dosing regimen. device. [Aspect 70] When executed by one or more processors, the set of functions is transmitted to the one or more processors. One or more non-transitory computer-readable media storing instructions operable to cause the A medium (CRM), wherein the set of functions comprises: A plurality of drug administration regimens, each associated with a different drug administration algorithm. Healthcare professionals (HCs) who indicated HCP selection of at least one medication regimen from among P) The selected regimen data is then processed by a mobile device associated with the patient. receiving, at a medical medical application (MMA), the HCP selection receiving, via a P Portal application, made for said patient; In response at least in part to receiving the HCP selected regimen data, unlocking at least one HCP selected drug administration regimen on said MMA; and, a non-transitory computer-readable medium comprising: [Aspect 71] Receiving the HCP selected regimen data is performed by the HCP portal application. 71. The CRM of embodiment 70, comprising receiving said HCP selected regimen data from a . [Aspect 72] Receiving the HCP selected regimen data is performed by the HCP portal application. The HC is connected to a connected care server system that communicates with both the MMA and the connected care server system. The CRM of embodiment 70, comprising receiving P selection regimen data. [Aspect 73] The set of functions is After the receiving step and before the unlocking step, via a mobile device user interface, presenting a prompt for patient acceptance or rejection of the dosing regimen; responding to the presented prompt via the mobile device user interface; receiving a corresponding user input; Performing the unlocking step is performed by the received user input being Provided that all of the above are patient acceptance indications for one HCP-selected drug regimen. The CRM of embodiment 70. [Aspect 74] The set of functions communicates the received user input with the HCP portal application. A connection associated with both the HCP portal application and the MMA. 73. The method of claim 72, further comprising: transmitting the information to one or both of the TedCare server system and the TedCare server system. CRM as described in. [Aspect 75] The unlocking step includes: Access to implementation data for at least one HCP-selected drug dosing regimen that was not previously available The CRM of embodiment 70, comprising accessing the CRM. [Aspect 76] The unlocking step includes: unlocking the previously inaccessible at least one HC; downloading implementation data of the selected drug administration regimen onto the mobile device; The CRM of embodiment 70, comprising: [Aspect 77] The MMA is communicatively coupled to an insulin delivery device associated with the patient. The CRM of embodiment 70, [Aspect 78] via a mobile device user interface of the mobile device, provides a dosing recommendation based on said at least one HCP selected drug dosing regimen. The CRM of embodiment 70, further comprising: [Aspect 79] 1. A method comprising: A processor on a mobile device associated with the patient, presenting multiple panels simultaneously on a visual display of a computer, said multiple panels being Nell, a first panel displaying the number of units of insulin to be administered to the patient; and The number of units of insulin displayed by the first panel is expected to be compensated for. a second panel displaying an amount of carbohydrates anticipated; the adjustment required to the number of units of insulin displayed by the first panel; receiving user input at the mobile device representing The number of units of insulin required for the number of units displayed by the first panel. updating, by said processor, each panel of said plurality of panels according to said adjustment. Thus, the updating includes updating an adjusted number of units of insulin by the first panel. and the adjusted number of insulin units is expected to be compensated for. updating the adjusted carbohydrate amount on the second panel. Includes, a method. [Aspect 80] The plurality of panels correspond to the amount of carbohydrate displayed by the second panel. and a third panel displaying an indication of a meal size to be measured, said updating further comprising: displaying an indication of an adjusted meal size corresponding to an adjusted amount of carbohydrate. The method of claim 79. [Aspect 81] The third panel represents a range of meal sizes between a small meal size and a large meal size. and the amount of carbohydrates displayed by the second panel is displayed in said area. 81. The method of embodiment 80, comprising an indicator of where in the region the input is to enter. [Aspect 82] The carbohydrate amount displayed by the second panel can be a small meal size, a medium meal size, or a medium meal size. the third panel indicating whether the meal size corresponds to a medium meal size or a large meal size. 80. The method according to claim 80. [Aspect 83] Maximum carbohydrate threshold for a medium meal size and minimum carbohydrate threshold for a medium meal size and receiving a value at the mobile device and displaying the value by the second panel. The carbohydrate value received is adjusted to the maximum carbohydrate threshold and the minimum carbohydrate threshold received. Based on the size of the meal, it corresponds to a small meal size, a medium meal size, or a large meal size. 83. The method of embodiment 82, wherein the third panel indicates. [Aspect 84] an insulin-to-carbohydrate ratio (ICR) associated with the patient, and receiving the amount of carbohydrates displayed by the second panel. based on the number of units displayed by the first panel and the received ICR. 80. The method of claim 79, wherein the calculated value is calculated by the processor. [Aspect 85] The plurality of panels includes a first panel and a second panel. A third panel displaying the reduction in glucose levels in said patient that is expected to result from administration. and updating is predicted to result from administration of the adjusted number of units of insulin. and displaying the adjusted decrease in glucose level of the patient. 79. The method according to claim 79. [Aspect 86] The plurality of panels includes a first panel and a second panel. A fourth panel displaying the reduction in glucose levels in said patient that is expected to result from administration. and updating is predicted to result from administration of the adjusted number of units of insulin. and displaying the adjusted decrease in glucose level of the patient. 80. The method according to claim 80. [Aspect 87] receiving at the mobile device an insulin sensitivity value (ISF) associated with the patient; and determining whether the glucose level of the patient is greater than the glucose level of the patient displayed by the third panel. The decrease in insulin is correlated with the number of units of insulin displayed by the first panel and the number of units of insulin prior to the The method of embodiment 85, wherein the ISF is calculated based on the received ISF. [Aspect 88] receiving at the mobile device an insulin sensitivity value (ISF) associated with the patient; and determining whether the glucose level of the patient is greater than the glucose level of the patient displayed by the fourth panel. The decrease in insulin is correlated with the number of units of insulin displayed by the first panel and the number of units of insulin prior to the 87. The method of embodiment 86, wherein the ISF is calculated based on the received ISF. [Aspect 89] The method of embodiment 79, wherein the mobile device is a mobile smartphone. [Aspect 90] 80. The method of embodiment 79, wherein the mobile device is a drug delivery device. [Aspect 91] The drug delivery device is in wireless communication with a mobile smartphone, and the drug delivery device The insulin-to-carbohydrate ratio (ICR), insulin sensitivity factor (ISF), and moderate meal the lesser of the maximum carbohydrate threshold for a medium meal size and the minimum carbohydrate threshold for a medium meal size 91. The method of embodiment 90, wherein at least one of the plurality of devices is received from the mobile smartphone. [Aspect 92] Executed by one or more processors on a mobile device associated with the patient. and, presenting multiple panels simultaneously on a visual display of said mobile device; wherein the plurality of panels are: a first panel displaying the number of units of insulin to be administered to the patient; and The number of units of insulin displayed by the first panel is expected to be compensated for. a second panel displaying an amount of carbohydrates anticipated; the adjustment required to the number of units of insulin displayed by the first panel; receiving user input at the mobile device representing the requested adjustment to the number of units of insulin displayed by the first panel; and updating each panel of the plurality of panels according to: displaying the adjusted number of units of insulin displayed by said first panel; and and the adjusted carbohydrate intake expected to be compensated for by the adjusted number of insulin units. and updating the one or more processors, including displaying an amount of the object on the second panel. A non-transitory computer-readable storage medium storing instructions operable to cause a processor to execute the Reading media (CRM). [Aspect 93] The plurality of panels correspond to the amount of carbohydrate displayed by the second panel. and a third panel displaying an indication of a meal size to be measured, said updating further comprising: displaying an indication of meal size adjusted according to the adjusted carbohydrate content. Item 92. A CRM as described in item 92. [Aspect 94] The third panel represents a range of meal sizes between a small meal size and a large meal size. and the amount of carbohydrates displayed by the second panel is displayed in said area. 94. The CRM of embodiment 93, comprising an indicator of where in the zone it falls. [Aspect 95] The carbohydrate amount displayed by the second panel can be a small meal size, a medium meal size, or a medium meal size. the third panel indicating whether the meal size corresponds to a medium meal size or a large meal size. CRM as described in 93. [Aspect 96] The instructions, when executed by the one or more processors, Maximum carbohydrate threshold for a medium meal size and minimum carbohydrate threshold for a medium meal size and further operating the mobile device to cause the one or more processors to receive the value. and the carbohydrate value displayed by the second panel is Based on the maximum and minimum carbohydrate thresholds, small, medium and 9. The third panel indicates whether the serving size corresponds to a full meal size or a large meal size. CRM as described in 5. [Aspect 97] The instructions, when executed by the one or more processors, An insulin to carbohydrate ratio (ICR) associated with the patient is determined by the one or more profiles. and a second processor operable to receive the second signal from the mobile device. The amount of carbohydrates displayed by the panel is displayed by the first panel. 93. The CRM of embodiment 92, wherein the CRM is calculated based on the number of units and the received ICR. [Aspect 98] The plurality of panels includes a first panel and a second panel. A third panel displaying the reduction in glucose levels in said patient that is expected to result from administration. and updating is predicted to result from administration of the adjusted number of units of insulin. and displaying the adjusted decrease in glucose level of the patient. CRM as described in 92. [Aspect 99] The plurality of panels includes a first panel and a second panel. A fourth panel displaying the reduction in glucose levels in said patient that is expected to result from administration. and updating is predicted to result from administration of the adjusted number of units of insulin. and displaying the adjusted decrease in glucose level of the patient. CRM as described in 93. [Aspect 100] The instructions, when executed by the one or more processors, an insulin sensitivity factor (ISF) associated with said patient to said one or more processors; and a third panel, the third panel further operable to receive a second signal from the mobile device. The decrease in the patient's glucose level displayed by the first panel The amount of insulin to be administered is calculated based on the number of units of insulin indicated and the received ISF. The CRM of claim 98. [Aspect 101] The instructions, when executed by the one or more processors, an insulin sensitivity factor (ISF) associated with said patient to said one or more processors; and a fourth panel, the fourth panel being further operable to receive the second signal from the mobile device. The decrease in the patient's glucose level displayed by the first panel The amount of insulin to be administered is calculated based on the number of units of insulin indicated and the received ISF. The CRM of claim 99. [Aspect 102] The CRM of embodiment 92, wherein the mobile device is a mobile smartphone. . [Aspect 103] The CRM of embodiment 92, wherein the mobile device is a drug delivery device. [Aspect 104] The drug delivery device is in wireless communication with a mobile smartphone, and the drug delivery device The insulin-to-carbohydrate ratio (ICR), insulin sensitivity factor (ISF), and moderate meal the lesser of the maximum carbohydrate threshold for a medium meal size and the minimum carbohydrate threshold for a medium meal size The CRM of embodiment 103, wherein the CRM receives at least one of the plurality of messages from the mobile smartphone.

Claims

1. 1. A method comprising: presenting, by a processor on a mobile device associated with the patient, a plurality of panels simultaneously on a visual display of the mobile device, the plurality of panels comprising: a first panel displaying the number of units of insulin to be administered to the patient; and a second panel displaying an amount of carbohydrates that is expected to be covered by the number of units of insulin displayed by the first panel; receiving a user input at the mobile device indicating a desired adjustment to the number of units of insulin displayed by the first panel; updating, by the processor, each panel of the plurality of panels according to the requested adjustment to the number of units of insulin displayed by the first panel, said updating including displaying by the first panel an adjusted number of units of insulin and displaying by the second panel an adjusted amount of carbohydrates that is expected to be covered by the adjusted number of units of insulin; The method further includes receiving at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient; The method, wherein the amount of carbohydrates 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.

2. the plurality of panels further comprising a third panel displaying an indication of a meal size corresponding to the amount of carbohydrates displayed by the second panel, and said updating comprises displaying an indication of an adjusted meal size corresponding to the adjusted amount of carbohydrates; 2. The method of claim 1, further comprising receiving at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, and wherein the third panel indicates whether the carbohydrate value displayed by the second panel corresponds to a small meal size, a medium meal size, or a large meal size based on the received maximum and minimum carbohydrate thresholds.

3. 3. The method of claim 2, wherein the third panel includes an area displaying a range of meal sizes between a small meal size and a large meal size, and an indicator showing where the carbohydrate amount displayed by the second panel falls within the area.

4. the plurality of panels includes a third panel displaying a decrease in the patient's glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and said updating includes displaying an adjusted decrease in the patient's glucose level that is expected to result from administration of the adjusted number of units of insulin; 2. The method of claim 1, further comprising receiving at the mobile device an insulin sensitivity value (ISF) associated with the patient, and wherein the decrease in the patient's glucose level displayed by the third panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

5. the plurality of panels includes a fourth panel displaying a decrease in the patient's glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and said updating includes displaying an adjusted decrease in the patient's glucose level that is expected to result from administration of the adjusted number of units of insulin; 3. The method of claim 2, further comprising receiving at the mobile device an insulin sensitivity value (ISF) associated with the patient, and wherein the decrease in the patient's glucose level displayed by the fourth panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

6. The method of claim 1 , wherein the mobile device is a mobile smart phone.

7. The method of claim 1 , wherein the mobile device is a drug delivery device.

8. 8. The method of claim 7, wherein the drug delivery device wirelessly communicates with a mobile smartphone, and the drug delivery device receives at least one of the insulin-to-carbohydrate ratio (ICR), insulin sensitivity factor (ISF), maximum carbohydrate threshold for a medium meal size, and minimum carbohydrate threshold for a medium meal size from the mobile smartphone.

9. When executed by one or more processors on a mobile device associated with a patient, presenting a plurality of panels simultaneously on a visual display of the mobile device, the plurality of panels comprising: a first panel displaying the number of units of insulin to be administered to the patient; and a second panel displaying an amount of carbohydrates that is expected to be covered by the number of units of insulin displayed by the first panel; receiving a user input at the mobile device indicating a desired adjustment to the number of units of insulin displayed by the first panel; a non-transitory computer readable medium (CRM) storing instructions operable to cause the one or more processors to: update each panel of the plurality of panels according to the requested adjustment to the number of units of insulin displayed by the first panel, the updating including displaying an adjusted number of units of insulin displayed by the first panel and displaying in the second panel an adjusted amount of carbohydrates that is expected to be covered by the adjusted number of units of insulin; The CRM, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to receive at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, and wherein the amount of carbohydrates displayed by the second panel is calculated based on the number of units displayed by the first panel and the received ICR.

10. the plurality of panels further comprising a third panel displaying an indication of a meal size corresponding to the amount of carbohydrate displayed by the second panel, and said updating comprises displaying an indication of an adjusted meal size according to the adjusted amount of carbohydrate; 10. The CRM of claim 9, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to receive at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, and wherein the third panel indicates whether the carbohydrate value displayed by the second panel corresponds to a small meal size, a medium meal size, or a large meal size based on the received maximum and minimum carbohydrate thresholds.

11. 11. The CRM of claim 10, wherein the third panel includes an area displaying a range of meal sizes between a small meal size and a large meal size, and an indicator showing where the carbohydrate amount displayed by the second panel falls within the area.

12. the plurality of panels includes a third panel displaying a decrease in the patient's glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and said updating includes displaying an adjusted decrease in the patient's glucose level that is expected to result from administration of the adjusted number of units of insulin; 10. The CRM of claim 9, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to receive at the mobile device an insulin sensitivity value (ISF) associated with the patient, and wherein the decrease in the patient's glucose level displayed by the third panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

13. the plurality of panels includes a fourth panel displaying a decrease in the patient's glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and said updating includes displaying an adjusted decrease in the patient's glucose level that is expected to result from administration of the adjusted number of units of insulin; 11. The CRM of claim 10, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to receive at the mobile device an insulin sensitivity value (ISF) associated with the patient, and wherein the decrease in the patient's glucose level displayed by the fourth panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

14. The CRM of claim 9 , wherein the mobile device is a mobile smart phone.

15. The CRM of claim 9 , wherein the mobile device is a drug delivery device.

16. 16. The CRM of claim 15, wherein the drug delivery device wirelessly communicates with a mobile smartphone, and the drug delivery device receives at least one of an insulin-to-carbohydrate ratio (ICR), an insulin sensitivity factor (ISF), a maximum carbohydrate threshold for a medium meal size, and a minimum carbohydrate threshold for a medium meal size from the mobile smartphone.

Images