System and method for remotely prescribing a medication dosing regimen

Abstract

Disclosed herein are systems and methods for remotely prescribing medication dosing regimens. One embodiment takes the form of a method that includes presenting multiple medication dosing regimens associated with a patient via an HCP portal user interface of a healthcare professional (HCP) system. 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 data of the HCP-selected regimen to a medical mobile application (MMA) on a mobile device associated with the patient, the data indicating the at least one HCP-selected medication dosing regimen.

Description

Technical Field

[0001] The present disclosure relates to medical devices and medical information systems, and in particular to systems and methods for remotely prescribing medication dosing regimens. Background Art

[0002] There are numerous diseases and other medical conditions for which patients receive medical treatment. Such treatment very often involves one or more dosing regimens of one or more drugs. Summary of the invention

[0003] Disclosed herein are systems and methods for remotely prescribing medication dosing regimens. The present system and method are applicable to many types of medications for many types of diseases and other medical conditions. Patients are treated by people referred to as health care professionals (HCPs) in this disclosure for these medical conditions. As used herein, HCPs include both people and / or entities (e.g., doctors, nurses, nurse practitioners, physician assistants (PAs), etc.) that directly provide health care to patients, and people and / or entities (e.g., administrators, database managers, other information technology personnel, insurance and / or other payment-related personnel, etc.) that do not directly provide health care to patients but indirectly support the provision of health care to patients. In the case of other treatments described herein, where the HCP prescribes medication dosing regimens and / or requires prescribing, it is assumed that the HCP has the appropriate education, training, certification, licensing and / or the like that would be required to issue such a regulation. Examples of drugs governed by the drug dosing regimen include 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 that can be delivered by a drug delivery device or can be taken by a patient without relying on a drug delivery device (e.g., orally or by application to the patient's skin). The drug can be formulated with one or more excipients.

[0004] An example area of ​​applicability of the present systems and methods is diabetes (sometimes also referred to as diabetes mellitus), which is a general term for a group of metabolic disorders that are generally characterized by elevated glucose (e.g., blood glucose or blood sugar) levels in the human body that persist for a period of time. As known in the art and in the medical community, another term for elevated glucose levels is hyperglycemia, which is generally defined as a glucose level greater than 180 milligrams (mg) per deciliter (dL) (mg / dL) - which can also be expressed as a threshold of 10 millimoles (mmol) per liter (L) (mmol / L). The opposite situation (i.e., insufficient glucose levels) is called hypoglycemia, which is generally defined as a glucose level equal to or less than 70 mg / dL (3.9 mmol / L).

[0005] There are two main types of diabetes, known as type 1 diabetes and type 2 diabetes, each of which is related in different ways to insulin, a hormone that is critical to the body's ability to metabolize glucose into energy for immediate use or storage for later use. Type 1 diabetes is generally considered an autoimmune disease in which the patient's immune system mistakenly attacks the "beta cells" in the pancreas that produce insulin. Type 2 diabetes is generally characterized by the pancreas' inability to produce enough insulin for the body's needs or the patient's body losing its ability to respond to insulin.

[0006] Among the therapies used for type 1 and / or type 2 diabetes is the subcutaneous injection of synthetic insulin. In general, synthetic insulins are classified according to a number of dimensions, including onset (i.e., how quickly they typically work), peak (i.e., how much time typically passes before reaching maximum efficacy), duration (i.e., the amount of time the effect typically lasts), and concentration. The typical expression of concentration is the number of units per milliliter (mL); as an example, a concentration of 100 units per mL is typically expressed as U100.

[0007] In the case of type 1 and / or type 2 diabetes, there are two main types of synthetic insulins that are usually prescribed by HCPs, usually for subcutaneous injection: basal insulin and bolus insulin. Basal insulin is also known by several other terms (such as background insulin and long-acting insulin), and is generally taken once or twice daily by diabetic patients on a regular basis and in a consistent dosage for the purpose of maintaining a certain baseline insulin level in the patient during times such as fasting, sleeping, between meals, etc. Bolus insulin also has several known names, including mealtime insulin, mealtime insulin, and rapid-acting insulin, and is generally taken by diabetic patients more on an as-needed basis, most often at mealtimes, for the purpose of dealing with glucose level spikes that are typical of mealtimes but can also occur at other times.

[0008] Although certainly applicable to many types of drugs for many types of diseases, conditions, etc., the present method and system are intended to at least partially assist HCPs and patients with type 1 or type 2 diabetes in managing (sometimes enhanced) basal insulin and / or bolus insulin regimens. In fact, although some examples in the present disclosure generally relate to the provision and implementation of bolus insulin dosing regimens for diabetic cases, it should be understood that this is intended to be illustrative rather than limiting, and in no way excludes the present system and method related to dosing regimens for other types of insulin (e.g., basal insulin) and / or for other types of diseases. Generally and as described above, it should be understood that the present system and method are applicable to a variety of dosing regimens for a variety of diseases, conditions, etc.

[0009] The inventors of the present system and method realize that the complexity of managing insulin therapy can be challenging, especially on the patient side, but also on the HCP side. The present system and method solve several technical problems of the prior art, including the following technical problems: Existing medical devices and medical technology implementations generally do not provide a mechanism by which an HCP can select and even customize at least one drug dosing scheme (e.g., a bolus insulin dosing scheme) for a specific patient from a plurality of predetermined and preprogrammed dosing schemes, and then further prescribe at least one scheme to the patient on a data network by remotely interacting with an application running on a mobile device associated with the patient. According to some embodiments of the present system and method, logic for the plurality of predetermined and preprogrammed dosing schemes can be provided with an application running on the patient's mobile device, but can be initially locked so as to be inaccessible to the patient. Further according to some embodiments, the HCP can remotely unlock at least one specific HCP-selected scheme from the plurality of preprogrammed dosing schemes for the patient on the mobile device, which can then provide instructions to the patient for implementing the at least one scheme, and in some cases, direct one or more additional medical devices (which are also associated with the patient) to execute some or all of the at least one HCP-selected dosing scheme. The present system and method represent a technical solution to at least this technical problem. And it is worth noting that this paragraph does not mean that the present disclosure does not represent other technical solutions to other technical problems.

[0010] One embodiment takes the form of a method that includes presenting a plurality of medication dosing regimens associated with a patient via an HCP portal application executed on an HCP system. Each presented medication dosing regimen is associated with a corresponding different medication dosing algorithm. The method also includes receiving, via the HCP portal user application, an HCP selection of at least one of the presented medication dosing regimens. The method also includes transmitting data indicating an HCP-selected regimen of at least one HCP-selected medication 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 of which includes one or more communication interfaces, one or more processors, and a 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 contains one or more instructions executable by the processors of the one or more servers for causing the connected care server system to perform a set of server system functions, the set of server system functions including the functions listed in the preceding paragraphs. Yet another embodiment takes the form of one or more non-transitory computer-readable media (CRM) having instructions stored thereon, the instructions being operable when executed by one or more processors to cause the one or more processors to perform a set of functions, the set of functions including the functions listed in the preceding paragraphs. In conjunction with any embodiment, the CRM may take the form of any non-transitory data storage medium mentioned herein and / or any other non-transitory data storage medium deemed suitable for a given implementation by a person skilled in the art. Examples include any suitable form of memory (including both volatile and non-volatile memory), disk storage, optical storage, and / or the like.

[0012] Another embodiment takes the form of a method including receiving data of an HCP-selected regimen at an MMA executed on a mobile device associated with a patient, the data of the HCP-selected regimen indicating an HCP selection of an HCP-selected medication dosing regimen from among a plurality of medication dosing regimens, each of the plurality of medication dosing regimens being associated with a corresponding different medication dosing algorithm. The HCP has made the HCP selection for the patient via an HCP portal application executed on the HCP system. The method also includes unlocking the indicated HCP-selected medication dosing regimen on the MMA at least in part in response to having received the data of the HCP-selected regimen.

[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 contains instructions executable by the mobile device processor for causing the mobile device to execute MMA to perform a set of MMA functions, including the functions listed in the preceding paragraphs. Yet another embodiment takes the form of one or more non-transitory CRMs having instructions stored thereon, the instructions being operable when executed by one or more processors to cause the one or more processors to perform a set of functions, including the functions listed in the preceding paragraphs.

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

[0015] Another embodiment takes the form of a method, which includes: simultaneously presenting, by a processor on a mobile device associated with a patient, a plurality of panels on a visual display of the mobile device, wherein the plurality of panels include: 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 covered by the number of units of insulin displayed by the first panel; receiving user input at the mobile device representing a requested adjustment to the number of units of insulin displayed by the first panel; and updating, by the processor, each of the plurality of panels in accordance with the requested adjustment to the number of units of insulin displayed by the first panel, wherein the updating includes displaying the adjusted number of units of insulin by the first panel and displaying the adjusted amount of carbohydrates expected to be covered by the adjusted number of units of insulin using the second panel.

[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 carbohydrates displayed by the second panel, and wherein the update includes displaying an indication of an adjusted meal size corresponding to the adjusted amount of carbohydrates. Alternatively, or in addition, the plurality of panels may further include a panel displaying a spectrum and an indicator indicating where the amount of carbohydrates displayed by the second panel falls on the spectrum, the spectrum displaying a range of meal sizes between a small meal size and a large meal size. Alternatively, or in addition, the plurality of panels may further include a panel indicating whether the amount of carbohydrates 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 drop in the patient's glucose level expected to be caused by administering the number of units of insulin displayed by the first panel, and wherein the update includes displaying an adjusted drop in the patient's glucose level expected to be caused by administering the adjusted number of units of insulin.

[0017] In some embodiments, the method may further include: receiving a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size at a mobile device, wherein one of the multiple panels indicates whether the amount of carbohydrates 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 the minimum carbohydrate threshold. The method may further include receiving an insulin to carbohydrate ratio (ICR) associated with the patient at the mobile device, 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. The method may further include receiving an insulin sensitivity factor (ISF) associated with the patient at the mobile device, wherein the decrease in the patient's glucose level displayed by one of the multiple panels is calculated based on the number of units of insulin displayed by the first panel and the received ISF.

[0018] Several variations and permutations of the embodiments listed above are described herein. Moreover, it is particularly noted that any variation or permutation described in this disclosure may be implemented with respect to any type of embodiment. For example, variations or permutations primarily described in conjunction with method embodiments may be implemented in conjunction with system embodiments and / or CRM embodiments. Furthermore, this flexibility and cross-applicability of the embodiments exist despite any language (e.g., process, method, step, function, feature set, etc.) used to describe and / or characterize such embodiments being slightly different. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] A more detailed understanding may be obtained from the following description, which is presented by way of example, taken in conjunction with the following drawings in which like reference numerals are used in conjunction with like elements across the various figures.

[0020] Figure 1 An example communication scenario in accordance with at least one embodiment is depicted that includes an example HCP system, an example health information technology (IT) system, an example mobile device associated with an example patient and in communication with multiple example personal medical devices also associated with the example patient, an example server system including one or more example servers (e.g., a connected care cloud server) that are communicatively interconnected with each other via an example network, and an example administrator-portal system.

[0021] Figure 2 Described in accordance with at least one embodiment Figure 1 Example physical architecture of an example HCP system.

[0022] Figure 3 Described in accordance with at least one embodiment Figure 1 An example physical architecture of an example mobile device.

[0023] Figure 4A Described in accordance with at least one embodiment Figure 1 An example physical architecture of an example server in an example server system.

[0024] Figure 4B Described in accordance with at least one embodiment Figure 1 Example physical architecture for the sample administrator-portal system.

[0025] Figure 5 Described in accordance with at least one embodiment Figure 1 An example functional architecture of an example server system.

[0026] Figure 6 Various entities in an example communication and processing ecosystem in accordance with at least one embodiment are depicted.

[0027] Figure 7 A first example method in accordance with at least one embodiment is described, which may be performed by Figure 1 The server system executes.

[0028] Figure 8 A second example method in accordance with at least one embodiment is described, which may be performed by Figure 1 The example execution of the MMA is performed on a mobile device.

[0029] Figures 9 to 18 Described in accordance with at least one embodiment for Figure 1 The sample HCP system shows various example screenshots.

[0030] Fig.19 A flow chart illustrating an exemplary process for calculating, presenting, and editing a recommended dose of insulin implemented by an MMA is depicted in accordance with at least one embodiment.

[0031] Fig. 20 Depicted are exemplary screenshots from the MMA where the MMA automatically synchronizes with a patient's glucose sensor in accordance with at least one embodiment.

[0032] Fig.21A , 21B and 21C depict exemplary screen shots from the MMA according to at least one embodiment, wherein the MMA receives a patient's glucose level.

[0033] Fig.22A , 22B , 22C, and 22D depict exemplary screen shots from the MMA used by the MMA for a daily titration dosing regimen, in accordance with at least one embodiment.

[0034] Fig.23A , 23B , 23C, and 23D depict exemplary screen shots from the MMA as used by the MMA for a fixed dose dosing regimen, in accordance with at least one embodiment.

[0035] Fig.24A , 24B , 24C, and 24D depict exemplary screen shots from the MMA used by the MMA to receive a carbohydrate quantity for a carbohydrate bolus calculator dosing regimen in accordance with at least one embodiment.

[0036] Fig.25A , 25B , 25C, and 25D depict exemplary screen shots from the MMA used by the MMA to receive units of mealtime insulin for a carbohydrate bolus calculator dosing regimen in accordance with at least one embodiment.

[0037] Fig.26A , 26B , 26C, and 26D depict exemplary screen shots from the MMA used by the MMA for a carbohydrate-based meal size calculator dosing regimen, in accordance with at least one embodiment.

[0038] Fig.27A , 27B 27C depict exemplary screenshots from the MMA used by the MMA to present and / or edit a recommended dose of insulin, in accordance with at least one embodiment.

[0039] Fig.28 An exemplary user interface display having four information panels related to presented insulin dosages in accordance with at least one embodiment is depicted.

[0040] Fig.29 Depicted is a series of exemplary user interface displays showing how four information panels are updated as a presented insulin dose is adjusted in accordance with at least one embodiment.

[0041] Fig.30 An example embodiment is described in accordance with at least one embodiment, wherein Fig.28 and 29 A user interface is displayed on the connected drug delivery device.

[0042] Fig.31 A flowchart illustrating a method executed by a mobile device to display and update a Fig.28 , 29 and an exemplary process of a user interface of 30.

[0043] For the purpose of promoting an understanding of the principles of the present disclosure, reference is made below to the embodiments illustrated in the accompanying drawings, which are described below. The embodiments disclosed herein are not intended to be exhaustive or to limit the disclosure to the precise forms disclosed in the detailed description below. Specifically, the embodiments are selected and described so that others skilled in the art can utilize their teachings. Therefore, it is not intended to limit the scope of the present disclosure thereby.

[0044] In some examples throughout this disclosure and in the claims, numerical modifiers such as first, second, third, and fourth are used with respect to various components, data such as various identifiers, and / or other elements. Such use is not intended to represent or indicate a particular order or required order of elements. Rather, the numerical terms are used to help the reader identify the referenced element and distinguish it from other elements, and should not be narrowly interpreted as adhering to any particular order.

[0045] Furthermore, before proceeding to this detailed description, it is noted that the entities, arrangements, and the like depicted in the various figures—and described in conjunction with the various figures—are presented as examples and not as limitations. As such, any and all statements or other indications as to what a particular figure "depicts," what a particular element or entity in a particular figure "is" or "has," and any and all similar statements—which might be taken in isolation and out of context as absolute and therefore as limiting—are properly considered constructive only (unless actually) preceded by a clause such as "In at least one embodiment, ..." And for reasons of brevity and clarity similar to the presentation, no nauseating (or otherwise) statements are made in this detailed description. ad nauseum ) repeats the implied introductory clause. DETAILED DESCRIPTION

[0046] 1. Sample Architecture

[0047] A. Example Communication Scenarios

[0048] Figure 1 An example communication scenario 100 is depicted in accordance with at least one embodiment, including an example HCP system 102, an example health IT system 118, an example mobile device 104 associated with an example patient 124 and in communication with a plurality of example personal medical devices (in this depiction, an example glucose meter 126 and an example connected injection device 134) also associated with the example patient 124, an example server system 106 including one or more example servers 140-146 communicatively interconnected with each other via an example private network 138, and an example administrator-portal system 148. Figure 1Also depicted are data network 108, communication links 110, 112, 114, 116, 128, 136, 150, 152, and 154; display 120 of HCP system 102; and display 122 of mobile device 104. Further shown are association arrows 125, conceptual information flow arrows 130, and conceptual information flow arrows 132, both of which are described below. It should be understood that Figure 1 The entities and their arrangements and interconnections depicted in are for illustration and are provided as examples rather than limitations, and other entities, arrangements, and interconnections may be implemented and deemed appropriate for a given situation by a person skilled in the art.

[0049] Combine the following Figure 2 The HCP system 102 (including the display 120) is more fully described from a physical architecture standpoint, but can generally take the form of any computing device that is 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 interacts with the HCP using voice, augmented reality (AR), or virtual reality (VR). In some embodiments, the HCP system 102 is any electronic device capable of supporting and running an Internet browser (i.e., a web browser—perhaps as a standalone application, or as a capability of another application, to name a few examples). Figure 1 As depicted in FIG. 1 , the HCP system 102 is communicatively connected to the health IT system 118 via a communication link 116 and is communicatively connected to the data network 108 via a communication link 110. Although the communication link 116 is depicted as being separate from the data network 108, it should be understood that in some instances, all or a portion of the link 116 may pass through at least a portion of the data network 108. In some instances, the HCP system 102 may communicate indirectly with the HIT system 118 via the data network 108, rather than as described above. Figure 1 102 as depicted in FIG. 104 through a direct link 116. Among other examples, HCPs with prescribing roles (e.g., physicians, physician assistants (PAs), nurse practitioners, etc.) and non-prescribing HCPs as part of a care team, as well as users associated with an integrated delivery network (IDN), are also typical users of the HCP system 102.

[0050] In various embodiments, the HCP system 102 provides and supports functions such as prescribing medication dosing schemes (e.g., insulin dosing schemes such as basal insulin dosing schemes, bolus insulin dosing schemes, and / or analogs), modifying existing dosing scheme provisions, setting and / or modifying dosing scheme parameters, and viewing individual patient data, in addition to other examples that may be listed here. The HCP helps the patient determine medication dosing via the HCP system 102 provisions and parameter settings regarding dosing schemes. Among other functions, the HCP system 102 also provides the HCP with the ability to download patient EHR data from the health IT system 118 via a communication link 116 and view EHR data in the HCP portal, view available medication dosing schemes, select a dosing scheme prescribed to the patient, and assign values ​​to the desired parameters of the selected dosing scheme (in the example case of an insulin dosing scheme, such as a starting dose, insulin to carbohydrate ratio, etc.). The HCP system 102 further provides data visualization features that enable the HCP user to review patient historical data. In various embodiments, the patient history data may be viewed in chart form, graphical form, tabular form, and / or in one or more other forms deemed appropriate for a given implementation by one of ordinary skill in the art.

[0051] Combine the following Figure 3 The mobile device 104 (including the display 122) is more fully described from a physical architecture standpoint, but it can generally take the form of any computing device that is equipped, configured, and programmed to perform the mobile device functions described herein. Some options for the mobile device 104 include a cell phone, a smart phone, a personal digital assistant (PDA), a tablet computer, a laptop computer, a wearable device, a mobile device that interacts with its user via voice or virtual reality, etc. Figure 1 , mobile device 104 is communicatively connected to glucose meter 126 via communication link 128, to connected injection device 134 via communication link 136, and to data network 108 via communication link 112. As depicted by double-ended and dashed association arrow 125, mobile device 104 is associated with patient 124—e.g., by subscription account, ownership, possession, and / or in one or more other ways.

[0052] Regarding the C3 server system 106, Figure 4A An example of a C3 server 140-146 is described more fully from a physical architecture standpoint. Figure 5The C3 server system 106 as a whole is more fully described from the perspective of a functional architecture (e.g., software architecture). However, in general, the C3 server system 106 can take the form of any collection of one or more servers that are collectively equipped, configured, and programmed to collectively perform the C3 server system functions described herein. Figure 1 As depicted in , the C3 server system 106 is communicatively connected to the data network 108 via a communication link 114 .

[0053] Note that Figure 1 As depicted in , each respective C3 server 140-146 in the C3 server system 106 can have its own respective communication link 114 with the data network 108; and or alternatively, a single communication link 114 can communicatively connect the C3 server system 106 with the data network 108, perhaps via a firewall, a network access server (NAS), and / or the like. For clarity of presentation, in the remainder of this disclosure, the one or more communication links 114 are referred to as "communication links 114." In addition, as also shown in Figure 1 As depicted, the respective C3 servers 140-146 are communicatively interconnected with each other 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 appropriate for a given implementation by one skilled in the art. In some embodiments, the depicted network 138 will not exist as a separate network as currently depicted - in such embodiments, the respective C3 servers 140-146 communicate with each other via their links to the data network 108. The communication connectivity between the C3 server system 106 and the administrator-portal system 148 is discussed below.

[0054] In general, the C3 server system 106 acts 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 particularly with respect to one or more applications, such as one or more MMAs executing 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 provide the HCP portal application 572 described in 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 able to serve any of these three entities. Regardless of the specific architectural implementation, the C3 server system 106 acts as at least one cloud with a specific purpose for those entities. As such, in at least one embodiment, all communications to and from the C3 server system 106 with any one or more other entities are secure communications - as an example, such communications may be encrypted and / or signed as known in the art. Such communications may also be inside a tunnel such as a VPN, in addition to other communications security and data security options that may be implemented as deemed appropriate by those skilled in the art in various scenarios.

[0055] In various embodiments, and as further described below, the C3 server system 106 - for the mentioned entities and possibly other entities - provides and supports functionality such as securely and reliably transmitting information and data (related to, e.g., prescriptions) between the HCP system 102 and an MMA, data storage running on a mobile device associated with a patient, managing relationships between patients and HCPs, IDNs, etc., and in some embodiments, alternatively or additionally, provides and supports one or more other functions deemed appropriate by one skilled in the art for a given implementation. Furthermore, in some embodiments, the C3 server system 106 facilitates data sharing involving payers (e.g., insurance companies); in some such embodiments, such data sharing with payer entities is conditional upon the associated patient opting in to allow such communications. And other examples of the functionality provided and supported may also be listed here.

[0056] Combine the following Figure 4B The administrator-portal system 148 is more fully described from a physical architecture standpoint, but it can generally take the form of any computing device that is equipped, configured, and programmed to perform the administrator-portal-system functions described herein. Some options for the administrator-portal system 148 include desktop computers, laptop computers, tablet computers, workstations, etc. Figure 1As depicted 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 (and particularly in the depicted example via a private network 138). In other embodiments, as also shown in FIG. Figure 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. And in some embodiments, the administrator-portal system 148 is operable to do both.

[0057] Generally speaking, in various embodiments, the administrator-portal system 148 provides various services with respect to the HCP portal 102, the MMA executed on the mobile device 104, and / or the C3 server system 106. One example class of such services are those related 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 change and / or manage various settings of the HCP portal 102, the MMA executed on the mobile device 104, and / or the C3 server system 106. In some cases, changes made via the administrator-portal system 148 affect only a single MMA, a single user, a single HCP, and / or the like; in other cases, such changes affect multiple MMAs, multiple user accounts, multiple HCPs, and / or the like. For example, an administrator-portal system 148 that manages the accounts of patients registered in an integrated delivery network (IDN) (e.g., a network of a healthcare organization) can be provided. In some embodiments, the administrator-portal system 148 is operable to push out updates, upgrades, and the like. In some embodiments, the administrator-portal system 148 is operable to manage individual HCP accounts, individual patient accounts, and / or the like. And of course many other example management functions that the administrator-portal system 148 can be used for can be listed here.

[0058] exist Figure 1In the example scenario depicted in FIG. 1 , the data network 108 is communicatively connected to the HCP system 102 via a communication link 110, is communicatively connected to the mobile device 104 via a communication link 112, is communicatively connected to the C3 server system 106 via a communication link 114, and is communicatively connected to the administrator-portal system 148 via a communication link 152. In at least one example scenario, the data network 108 includes one or more Internet Protocol (IP) networks, such as the global network of networks generally and broadly referred to as the Internet, one or more public IP networks, one or more private (e.g., corporate) IP networks, and / or any other type of one or more IP networks deemed appropriate for a given implementation by a person skilled in the art. Entities communicating via the data network 108 may be identified by an address such as an IP address (e.g., an IPv4 address or an IPv6 address). However, it is not required that the data network 108 be or include an IP network, as this is merely an example.

[0059] As used herein, a "communication link" includes one or more wired communication (e.g., Ethernet, Universal Serial Bus (USB), and / or the like) links and / or one or more wireless communication (e.g., cellular, Wi-Fi, Bluetooth, and / or the like), and may also include any suitable number of relay devices, such as routers, switches, bridges, and / or the like. The communication link 112 may specifically include at least one wireless communication link to facilitate two-way data communication with the mobile device 104. In addition, one or both of the communication links 128 and 136 may take the form of or include at least one of the following: 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. Furthermore, communication links 128 and 136 may be, but need not be, point-to-point links between (i) mobile device 104 and (ii) glucose meter 126 and connected injection device 134, respectively: in some embodiments, one or both of communication links 128 and 136 are indirect links via, for example, a Wi-Fi or ZigBee router, or a cellular network or tower (not depicted). And of course other implementation examples may be listed here as well.

[0060] exist Figure 1In the example scenario depicted in , the health IT system 118 is communicatively connected to the HCP system 102 via a communication link 116, and can 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, perhaps in addition to other functions deemed appropriate by those skilled in the art for a health IT system, the health IT system 118 also optionally provides and supports secure maintenance, secure storage, and secure access to patient electronic health records (EHR - also referred to in the industry as electronic medical records or EMR). In addition, the health IT system 118 is communicatively coupled to the data network 108 via a communication link 154. The health IT system 118 can 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 the Fast Healthcare Interoperability Resources (FHIR) protocol or the Smart Medical Applications and Reusable Technologies (SMART) protocol, as examples.

[0061] In the example scenario described herein, the patient 124 has been diagnosed with diabetes and is being treated by an HCP associated with the HCP system 102, but this is by way of example only and not limitation. In the described embodiment, the mobile device 104 (and at least one MMA running thereon), the glucose meter 126, and the connected injection device 134 are each associated with the patient 124, and are associated with each other in at least this manner. The above-mentioned association arrow 125 is intended to represent the general association and user-interface-level interaction of the patient 124 with the mobile device 104.

[0062] Note further that although Figure 1The mobile device 104 is shown to be connected to both the glucose meter 126 and the connected injection device 134, but in some cases, only one of the glucose meter 126 and the connected injection device 134 can appear in various different scenarios, and neither is required. In fact, some scenarios do not involve additional medical devices connected to the mobile device 104 at all, such as the case of a system that requires the patient to measure the glucose level separately and manually and / or log the dosage information, or as oral medication and does not require equipment to monitor or otherwise test one or more levels, conditions or other parameters of the patient 124. In some cases, the patient can connect more than one glucose meter and / or more than one connected injection device to the MMA-for example, the patient may have a glucose meter and / or injection device at home, and may have a glucose meter and / or injection device at work. The MMA can be configured to support multiple connections of each. In addition, in some cases, in addition to the glucose meter and / or the connected injection device, there are one or more connected medical devices. Some examples include blood pressure monitors, pulse / oxygen monitors, and / or the like. And of course many other examples can be listed here.

[0063] 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 above-mentioned communication link 128. The glucose meter 126 may include a blood glucose meter (BGM), a continuous glucose meter (CGM), a rapid glucose monitor (FGM), or other devices that measure the blood glucose or other glucose level sources of the patient 124 (e.g., a contact lens device or a device that uses near-IR radiation to measure glucose levels). BGM takes discrete point measurements of the patient's blood glucose level (e.g., by pricking the patient's finger to take point measurements of the patient's capillary whole blood glucose level). Both CGM and FGM use sensors to measure interstitial glucose. The CGM system may include a sensor, a transmitter, and a receiver / app. CGM can take more frequent (i.e., more continuous) measurements of the patient's interstitial glucose level, and can optionally be worn continuously by the patient for a relatively extended period of time (e.g., several hours or several days at a time). An example of such a CGM is the G6 sensor manufactured by Dexcom. The FGM system may include a sensor worn on or inserted into a portion of the patient's body, and a reader (e.g., a handheld reader) that receives a glucose level reading from the sensor when activated or placed in close proximity to the sensor. An example of such an FGM is the FreeStyle Libre device manufactured by Abbott Diabetes Care. In some embodiments, the FGM does not require fingerstick calibration. And of course one or more other types of glucose meters may also be included.

[0064] CGM and FGM systems can measure interstitial glucose levels, while BGM systems can measure blood glucose levels. For simplicity and readability, the remainder of this disclosure refers only to "glucose" levels or "GL." It is to be understood that such references may refer to blood glucose or interstitial glucose, as the case may be.

[0065] 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 above-mentioned communication link 136. The device 134 may further include a drug or medication. In some embodiments, the system may include one or more devices and a drug or medication, the device including the device 134. The term "drug" or "drug" refers to one or more therapeutic agents, including but not limited to insulin, insulin analogs such as lispro or glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agent that can be delivered by the above device. The drug or medication used in the device 134 can be formulated with one or more excipients. The device is operated by the patient, caregiver, or healthcare professional in a manner generally as described herein to deliver the drug to the person.

[0066] 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 with an integrated and / or attachable electronic device to automatically detect and report the amount of insulin injected to another electronic device). In various 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 hereby incorporated herein by reference in its respective entirety:

[0067] ● PCT Application No. PCT / US17 / 65251, filed on December 8, 2017 and entitled Medication Delivery Device with Sensing System (Attorney Docket No. X21353);

[0068] ● PCT Application No. PCT / US18 / 19156, filed on February 22, 2018 and entitled Dose Detection and Drug Identification for a Medication Delivery Device (Attorney Docket No. X21457); and

[0069] ● U.S. Provisional Patent Application No. 62 / 552,659, filed on August 31, 2017 and entitled Dose Detection with Piezoelectric Sensing for a Medication Delivery Device (Attorney Docket No. P21462).

[0070] Furthermore, in some cases, one or more of the capabilities of one of the two devices in the present disclosure may also or alternatively be covered by the other of the two devices and / or by one or more additional devices. In one example, a single device may both monitor glucose (and report back the results) and inject insulin (and report back the amount injected). And of course other combinations of capabilities may be listed here.

[0071] In addition, and also as described below, in some embodiments, the MMA executed on the mobile device 104 communicates with one or more connected medical devices (such as the example glucose meter 126 and the connected injection device 134) for various reasons (e.g., sending a dosing command, receiving a dosing amount confirmation report, requesting a (e.g., glucose) reading, receiving one or more measured values, and / or the like). Such communication can be performed in a unidirectional or bidirectional manner with a given device. Additional examples of information that can be communicated from a connected medical device to the MMA include error codes, device indicators, dosing records, and / or dosing confirmations. And of course other examples can be listed here. In addition, in some cases, there is a direct communication link between various connected medical devices, such as between the glucose meter 126 and the connected injection device 134.

[0072] Conceptual information flow arrow 130 is meant to graphically and conceptually depict that, among other information and as described more fully below, the HCP system 102 transmits, either directly or via the data network 108, via the C3 server system 106, or via some other intermediate component or network, HCP-selected medication dosing regimen (e.g., bolus dosing regimen) prescriptions to the MMA executing on the mobile device 104. Similarly, conceptual information flow arrow 13 is meant to graphically and conceptually depict that, among other information and as described more fully below, the MMA executing on the mobile device 104 transmits, either directly or via the C3 server system 106, patient-tracked and patient-shared health data regarding the patient's diabetes and / or one or more other health-related conditions, topics, etc.

[0073] In general, it should be understood that 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 executed thereon), the C3 server system 106, and the administrator-portal system 148 - can, in at least one embodiment, communicate with any of those entities without routing the 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 the information having to pass through the C3 server system 106. However, in some embodiments, one or more entities do communicate with each other via at least one additional entity; as an example, in at least one embodiment, data (e.g., data of a regimen selected by the HCP) is transmitted from the HCP system 102 to the MMA executed on the mobile device 104 via the C3 server system 106.

[0074] B. Example HCP system (example physical architecture)

[0075] Figure 2 An example physical architecture of the HCP system 102 is depicted in accordance with at least one embodiment. This architecture is provided as an illustration and not a limitation, as other architectures deemed suitable by one skilled in the art may be implemented. Figure 2 As depicted in , the HCP system 102 includes a communication interface 202, a processor 204, a data storage 206, and a user interface 208, which includes the display 120 described above.

[0076] The communication interface 202 may include one or more components for wired communication, such as an Ethernet card and / or the like, and / or one or more components for wireless communication, such as a Wi-Fi chip and / or the like. 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 a memory (e.g., a read-only memory (ROM), a random access memory (RAM), a flash memory, a solid-state drive, an optical memory, and / or the like), and may contain instructions executable by the processor 204 for at least implementing the HCP portal system functions described herein. In addition to the display 120, the user interface 208 may also include one or more output devices, such as a speaker, an indicator LED, and / or the like, and may further include one or more input devices, such as a keyboard, a mouse, a touchpad, a microphone, and / or the like, as known in the art. The various components of the HCP system 102 are depicted as being interconnected via a system bus 210 for communication.

[0077] Furthermore, it should be understood that in at least one embodiment of the present systems and methods, the HCP system 102 operates or implements (in Figure 5 102 and also referred to herein as "HCP portal application 572"). The HCP portal 572 can be a software or firmware application executed on the hardware of the HCP system 102. For example, the HCP portal 572 can take the form of a widget executed within the HCP's electronic health record (EHR) system. Such a widget can be integrated with the HCP's EHR system using protocols such as SMART (Alternative Medical Apps, Reusable Technologies) about FHIR (Fast Healthcare Interoperability Resources). In some embodiments, the HCP portal 572 can take the form of a web application running within a web browser. In an illustrative example, the HCP logs in to the HCP portal 572 by pointing a web browser on the HCP system 102 to a hyperlink, and then the 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 to no patient data (e.g., patient medical records, dosing regimen data, and / or the like), and instead acts as a pure conduit for such patient data between its HCP users and the C3 server system 106. In some such embodiments, there is data stored locally in the form of code for the web browser itself (e.g., Microsoft Edge, Google Chrome, Apple Safari, and / or the like), and perhaps code for a web application (e.g., Java) add-on. And of course other variations—regarding the centralized and / or distributed nature of the operational code and / or other substantive data—that one skilled in the art might deem appropriate for a given implementation could be listed here.

[0078] C. Example Mobile Device (Example Physical Architecture)

[0079] Figure 3 An example physical architecture of a mobile device 104 is depicted in accordance with at least one embodiment. As can be seen by inspection, Figure 3 In many ways Figure 2Similar, and therefore not described in great detail here. However, since the mobile device 104 is a mobile device, those skilled in the art will understand that there may be corresponding differences in each component, such as the communication interface 302 may be equipped, programmed and configured for wireless wide area network (WWAN) communication (according to, for example, LTE) and wireless local area network (WLAN) communication (according to, for example, Wi-Fi) and has additional wireless communication capabilities, such as NFC, Bluetooth, RFID, RF and / or the like. In addition, in at least one embodiment, the processor 304 is selected to be suitable for mobile device implementation, as is the data storage 306, which contains instructions executable by the processor 304 to at least implement 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 also includes one or more user input and / or user output components suitable for installation on the mobile device (e.g., touch screen, stylus, pointing and clicking device, soft keys, keyboard, microphone, speaker, camera, data port and / or the like). The various components of the mobile device 104 are depicted as being communicatively interconnected via the system bus 310.

[0080] D. Example C3 Server (Example Physical Architecture)

[0081] Figure 4A An example physical architecture of a C3 server 140 is depicted, which is selected as an example of a C3 server 140-146 of a C3 server system 106, in accordance with at least one embodiment. As noted above, the C3 server system 106 can take the form of any number of servers, including only one server and also including more than one server. Figure 1 , the four C3 servers 140-146 with ellipses between the third and fourth servers are intended to illustrate this number elasticity. As can also be seen, Figure 4A In many ways Figure 2 and Figure 3 are similar, and therefore not described in great detail herein.

[0082] In most scenarios, the architecture of the C3 server 140 will generally be more similar to the architecture of the HCP system 102 than the architecture of the mobile device 104, if only because of the level of performance and data processing that such a varied architecture can provide. However, even compared to the HCP system 102, in at least one embodiment, there are differences in the architecture of the C3 server 140. For reasons of data security, the communication interface 402 may include only wired communication hardware (e.g., an Ethernet card) and may include a greater number of data communication interfaces than the HCP system 102.

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

[0084] As depicted 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 for causing the C3 server system to perform various combinations of the C3 server system functions described herein. Figure 7 Method 700 is one such example combination. In fact, 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, hardware (e.g., data storage, processor capacity, web servers, switches, routers, communication links, etc.) for facilitating specific access requests and / or the like is dynamically provisioned so that different sets of hardware can facilitate different access requests. Such hardware can be dynamically provisioned for specific access requests based on various factors, such as the geographic location of the request, load balancing, required quality of service (QoS), parameters of the service agreement, and / or the like. The C3 server system can then be considered a "cloud," as the term is used in the art, where the cloud includes a distributed network of servers that jointly and dynamically run virtual services. In at least one embodiment, each such virtual service is its own self-contained software process. Moreover, one (or more) specific hardware servers that actually execute a given instance of a given virtual service are dynamically allocated on the fly based on one or more factors (such as those mentioned in this paragraph).

[0085] E. Sample Administrator-Portal System (Sample Physical Architecture)

[0086] Figure 4B An example physical architecture of an administrator-portal system 148 in accordance with at least one embodiment is depicted. As can be seen by inspection, Figure 4B In many aspects Figure 2 , Figure 3 and Figure 4AEach of the embodiments is similar and therefore not described in great detail here. As described above, some options for the administrator-portal system 148 include desktop computers, laptop computers, tablet computers, workstations, etc. The administrator-portal system 148 can take the form of any one or more computing devices that are appropriately equipped, programmed, and configured to perform at least the administrator-portal system functions described herein. Figure 4B As depicted, the administrator-portal system 148 includes a communication interface 452, a processor 454, a data storage device 456, and a user interface 458, all of which are communicatively connected to each other via a system bus 460, and the data storage device 456 contains instructions that can be executed by the processor 454 to at least perform the administrator-portal system functions described herein.

[0087] In addition, it should be understood that in at least some embodiments, similar to the HCP system 102, the administrator-portal system 148 runs or implements an administrator-portal application (not shown). The administrator-portal application can be a software or firmware application executed on the hardware of the administrator-portal system 148. For example, the administrator-portal application can take the form of a web application running in a web browser. An administrator or user can log in to the administrator-portal application by pointing a web browser on the administrator-portal system to a hyperlink, and then the administrator-portal application opens in the browser. In such an embodiment, the content within the administrator-portal application can be hosted by the C3 server system 106, and patient data (e.g., patient medical records, data of dosing regimens, and / or the like) can be stored almost nowhere locally on the administrator-portal system 148. Alternatively, the administrator-portal system 148 acts as a pure conduit for patient data between its administrator / user and the C3 server system 106.

[0088] F. Example C3 Server System (Example Functional Architecture)

[0089] Figure 5 An example functional architecture of the C3 server system 106 in accordance with at least one embodiment is depicted. It should be understood that the functional architecture is provided as an illustration and not a limitation, and that other functional architectures deemed suitable by those skilled in the art may be implemented in a variety of different scenarios. 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 deemed suitable by those skilled in the art (where the firmware and / or software runs on the hardware). Also note that in Figure 5Entities other than the C3 server system 106 are also depicted in the architecture 500 shown in FIG. 1. This is illustrated by the left bracket labeled “106” for the C3 server system 106—components outside of the left bracket are associated with entities other than the C3 server system 106.

[0090] As in Figure 5 , architecture 500 includes what are known in the computing and programming arts as "layers" separated by "interfaces"; these are logical compositions that, among other benefits, facilitate encapsulation and manageability of complex systems. Architecture 500 includes a data layer 502, an internal web services (IWS) layer 504, an external facing services (EFS) layer 506, and an application layer 508. Data layer 502 is separated from IWS layer 504 by a data IWS interface 503, which is separated from EFS layer 506 by an IWS-EFS interface 505, which is separated from application layer 508 by an EFS application interface 507. Further note that interface 509 represents the logical portion of architecture 500 where the user will interact with the overall system and, in particular, directly with application layer 508 - in other words, interface 509 is what is often referred to in the art as a "human-machine interface."

[0091] In the depicted embodiment, the data layer 502 includes multiple data warehouses 510a-e. Each data warehouse 510a-e corresponds to one of the microservices 514, 516, 518, 520 and / or 522 described herein. The data warehouses 510a-e collectively contain patient and / or medical data, including personally identifiable information (PII) such as name, address, phone number, email address, social security number, etc. The data warehouses 510a-e may also collectively contain information other than PII, such as medical treatments, definitions, dosing regimens (i.e., templates), etc. In at least one embodiment, the data layer 502 is implemented using an on-demand cloud computing platform and service operated and provided 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 a PostgreSQL product developed by Heroku, San Francisco, California. And of course other options can also be listed here. In at least one embodiment, the data layer 502 is organized according to the FHIR standard, which is proposed by the International Health Level Seven (HL7) in Ann Arbor, Michigan.

[0092] The IWS layer 504 includes a plurality of microservices 514, 516, 518, 520, and 522. The ellipsis between service 520 and service 522 is meant to indicate that there may be any number of services in the IWS layer 504 as deemed appropriate by one skilled in the art for a given implementation. Each microservice is a data gateway implemented as a software service responsible for handling a certain type of data or functionality. Exemplary microservices include: a "people" microservice for handling PII related to registered or future patients; an "order" microservice for handling data related to prescribed orders; an "observation" microservice for handling data related to patient observations entered by an HCP or observed by an MMA running on a mobile device; a "user access" microservice for handling data related to a user's 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 handling data related to the type of medication handled by or administered to a patient. Each microservice 514-522 is capable of accessing a data warehouse 510a-e via a corresponding communication link 511a-e.

[0093] In at least one embodiment, each internal service 514-522 is designed to make access to data stored in the data warehouse 510a-e, including both read access and write access, available only to the various gateways 524-530 of the EFS layer 506 in a manner defined and permitted by the corresponding internal service 514-522. In at least one embodiment, the IWS layer 504 is implemented using Amazon Web Services. In another embodiment, the IWS layer 504 is implemented using the HerokuPlatform, also developed by Heroku. And of course other options can also be listed here.

[0094] Further note that combined Figure 5 The "link" described herein refers to a logical access link and does not necessarily refer to a physical communication link; in at least the described embodiments, Figure 5 The presence of a logical access link in indicates that appropriate configuration, authorization, authentication, permissions, and / or the like have been put in place to facilitate communications between corresponding entities.

[0095] The EFS layer 506 includes an HCP portal gateway 524, an MMA gateway 526, an MMA gateway 528, and a management gateway 530. In addition, the ellipsis between the MMA gateways 526 and 528 is meant to indicate that any suitable number of MMA gateways can be implemented; the ellipsis between the mobile devices 104 and 532 in the application layer 508 indicates the same meaning. Each MMA gateway corresponds to a specific type or version of MMA. The implementation of a dedicated MMA gateway instance for each type or version of MMA is a design choice, and other design choices can be made. Across the IWS-EFS interface 505, it can be seen - through the system bus-like depiction of the IWS-EFS interface 505 - that in the depicted embodiment, any gateway of the EFS layer 506 is able to call any internal service in the internal services 514-522 as needed. In at least one embodiment, each gateway 524-530 in the EFS layer 506 is designed to make access to the internal services 514-522 of the IWS layer 502 available to entities in the application layer 508 only in a manner defined and permitted by the corresponding gateway 524-530. For example, in an embodiment, the HCP portal 572 running on the HCP system 102 can access the internal services 514-522 through the HCP portal gateway 524; similarly, the 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 layer 506 is implemented using Amazon webServices. In at least one other embodiment, the EFS layer is implemented using the Heroku Platform. And of course other options can also be listed here.

[0096] The application layer 508 includes the HCP system 102 executing a health information technology user interface (HIT UI) 574, which in turn executes an HCP portal 572. The application layer 508 further includes the above-mentioned mobile device 104 (which executes MMA 568 in accordance with the present disclosure), a second mobile device 532 (which executes another type or version of MMA depicted as MMA 570 in accordance with the present disclosure), an administration portal 534, and an administration portal 536. As with the ellipses mentioned previously, 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. In addition, a single MMA gateway (e.g., MMA gateway 526) may be connected to multiple mobile devices, each running the same type or version of 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 appropriate by one skilled in the art in a given context. In one embodiment, the management portal 534 is a clinical C3 management server that is configured to manage the C3 server system 106 in conjunction with clinical aspects. In one embodiment, the management portal 536 is a production-support C3 management server that is configured to manage the C3 server system 106 in conjunction with production-support aspects. And of course other examples can be listed here. In at least one embodiment, one or both of the management portal 534 and the management portal 536 are processes executed on the administrator-portal system 148. In addition, although in Figure 5 No ellipses or additional HCP portals are depicted with respect to the HCP portal, but it is also the case that any suitable number of HCP portals may be implemented in a given scenario.

[0097] 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 otherwise interact with patient or non-patient data and records stored in the HIT 118. The HIT UI 574 may then, at the command of the HCP, launch an HCP portal 572 as a separate user interface within the HIT UI 574—an exemplary screenshot of the HCP portal 572 is provided as Figure 9-18As previously described herein, the HCP portal 572 can take the form of a web application running within a web browser that allows the HCP to access patient data from or provide patient data to the C3 server system 106. In at least some embodiments, the HCP portal 572 can also interface with the HIT 118 and access patient data from or provide patient data to the HIT 118. In this manner, the HCP can launch the HCP portal 572 with the click of a button or key while viewing a particular patient's record within the HIT UI 574 in order to prescribe a medication dosing regimen, view patient observations or a logged dosing history, or access other features of the HCP portal described herein.

[0098] In some embodiments, both the HIT UI 574 and the HCP portal 572 can be provided by the same supplier. In other embodiments, the HIT UI 574 can be provided by a first supplier, and the HCP portal 572 can be provided by a second supplier. The HCP portal 572 can be integrated into the HIT UI 574 using the above-mentioned industry standards such as SMART about FHIR. Integrating the HCP portal 572 in this way allows the HCP to access patient data from the HIT 118 through the portal 572 without having to manually enter the data, and allows the HCP to select an appropriate dosing scheme without having to return to the HIT UI 574 to review key patient data, such as medications, medical history, test results, historical blood glucose logs, insulin dosage information, etc. In some instances, the HCP portal 572 can also be configured to extract a minimum set of demographic data related to a specific patient from the HIT 118 (e.g., patient name, date of birth, unique identifier of the patient or unique identifier of the patient's EHR), and display the demographic data in a banner or other highlighted area. This can help ensure that the HCP works in the correct patient record.

[0099] Although the HCP portal 572 is depicted as being encapsulated within the HIT UI 574, the HCP portal 572 may also be implemented as a standalone application external to any health IT system. In such a case, the HCP system 102 will execute or implement the HCP portal 572 without any HIT UI 574. In such an embodiment, the HCP portal 572 may still optionally fetch patient data from the health IT system, but may not be launched as a separate window or graphical user interface from within the user interface of the health IT system. Of course, the HCP portal 572 may also be configured to communicate with no health IT system at all-in such an embodiment, it may be necessary to manually enter patient medical and biographical data and store it in the HCP portal 572.

[0100] Across the EFS application interface 507, the HCP system 102 is independently capable of accessing the HCP portal gateway 524 via link 558; the MMA 568 (on the mobile device 104 or on multiple mobile devices) is independently capable of accessing the MMA gateway 526 via link 560; the MMA 570 (on the mobile device 532 or on multiple mobile devices) is independently capable of accessing 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). In the depicted embodiment, such restricted access is bidirectional, as the C3 server system 106 can only access the HCP system 102 via the HCP portal gateway 524 and link 558; the C3 server system 106 can only access the MMA 568 via the MMA gateway 526 and link 560, and similarly, access the MMA 570 via the MMA gateway 528 and link 562, and access the corresponding C3 management portals 534 and 536 via the C3 management gateway 530 and links 564 and 566.

[0101] G. Example Ecosystem

[0102] Figure 6 Various entities in an example communication and processing ecosystem 600 are depicted in accordance with at least one embodiment. Of course, the term ecosystem is not used here in a biological sense, but rather in the computing context of communication and processing. Where appropriate, Figure 6 The above combination is also marked Figure 1-5 Elements discussed in order to aid the reader's understanding by placing such elements in the context of an ecosystem 600 that includes an HCP engagement area 602, a patient engagement area 604, a population management area 606, and a care management area 608 that all communicatively interact and are interrelated with one another via the C3 server system 106 that is implemented in a manner that is consistent with the C3 server system 106. Figure 6 As mentioned above, it is also contemplated that in some embodiments, the C3 server system 106 is communicatively connected to (e.g., sharing data with (perhaps only conditional on patient opt-in) and receiving data from) a payer entity such as an insurance company, Medicare, etc.

[0103] The data analysis engine can be configured to analyze data and / or health record data collected by or accessible by the patient's mobile device to drive insights about patient behavior or symptoms related to a disease or condition. The analyzed data may be unique to a single patient and used to derive insights specific to the patient. For example, the data analysis engine can determine that the patient tends to show hyperglycemia or hypoglycemia in certain conditions (e.g., at certain times of the day, after eating certain types of meals, on certain days of the week, at certain geographic locations or on the way to / from certain geographic locations, before / during / after certain types of physical activity, and other types of conditions) by analyzing the log of the glucose readings of the diabetic patient. Based on these insights, the data analysis engine can take a variety of actions, such as notifying the patient's HCP, pushing educational content related to the observed hyperglycemia or hypoglycemia episodes to the patient, or prompting the patient to change his / her behavior at a specific time or location where they may be most effective (e.g., prompting the patient to take medication just before going to bed, immediately after exercise, or when they are at a specific geographic location or on the way to / from a specific geographic location).

[0104] The HCP engagement area 602 of the ecosystem 600 includes the HCP system 102 and the health IT system 118, and as Figure 6 As stated in , HCPs are enabled to order products from a company or other organization operating the C3 server system 106, access insights into such products, and integrate the present systems and methods into their existing clinical workflows.

[0105] The patient engagement area 604 of the ecosystem 600 includes the mobile device 104 executing the MMA 568, the patient 124, the glucose meter 126, the connected injection device 134, and a number of other patient-related medical devices, such as a blood pressure monitor or other meters. Figure 6 As stated in , in the patient engagement area 604 of the ecosystem 600, goals of the present systems and methods include providing relevant and valuable decision support to reduce patient burden and improve outcomes.

[0106] The population management area 606 of the ecosystem 600 includes computing equipment (perhaps similar in physical architecture to that of the HCP system 102), and an EMR / HIE (health information exchange) system for appropriately storing and maintaining the patient's personal medical information. In the population management area 606 of the ecosystem 600, as Figure 6 As stated in , the goals of the present system and approach include enabling clinical and financial stakeholders (payers, health systems, etc.) to assess populations and better serve at-risk patients.

[0107] The care management area 608 of the ecosystem 600 also includes computing equipment similar to that 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) involving what is often referred to as a given patient's "care team." This care team may include multiple different HCPs (different types of doctors, different types of nurses, therapists, paramedics, etc.) with a variety of different roles that are related to the patient's health and well-being. Figure 6 As stated in , in the care management area 608 of the ecosystem 600, objectives of the present system and method include enabling a care team to identify and prioritize patients who need help, and also enable direct interaction between the patient and the care team.

[0108] In at least one embodiment, a companion MMA is provided that allows caregivers, loved ones, and / or the like 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 (including, for example, glucose measurements, usage information, information related to meals, and / or the like) as well as (multiple) prescribed dosing regimens and / or any other type of data deemed appropriate for a given implementation by a person skilled in the art. Depending on the design parameters of a given implementation, the amount and / or type of data viewable via the companion MMA may be set to a default value and may also be adjustable by the HCP, the patient 124, and / or one or more other individuals.

[0109] In accordance with the present systems and methods, the C3 server system 106 provides and supports several features that facilitate the above-described and other goals in the ecosystem 600. One such feature is data storage, as the C3 server system 106 securely stores data in at least one embodiment, which allows the HCP system 102 and the MMA 568 to securely communicate with each other. The C3 server system 106 further enables MMA users to securely back up their medical data and achieve data consistency across multiple devices (e.g., in embodiments where 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 fairly common, and / or in embodiments where the patient 124 is able to access similar functionality and information via, for example, a web portal, as is also commonly accomplished in the art).

[0110] In various embodiments, as described herein, the HCP establishes dosing regimens via the HCP system 102 and the C3 server system 106 and sends them to the MMA 568 via the secure data transfer capabilities of the C3 server system 106. Further, in various embodiments, the C3 server makes available patient history data, dosing regimen status, etc. via the HCP system 102 and / or the MMA 568. Further, in at least one embodiment, the C3 server system 106 facilitates secure communications (i.e., messaging or inbox functionality) between the HCP via the HCP system 102 and the patient 124 via the MMA 568 and the mobile device 104. Further, in various different embodiments, the C3 server system 106 facilitates software updates, recall notifications, and / or other functionality that one skilled in the art deems appropriate for a given implementation or in a given context.

[0111] I. Sample Operation

[0112] A.HCP Portal

[0113] Figure 7 An example method 700 is depicted that may be performed by the C3 server system 106 in accordance with at least one embodiment. It should be understood that the description herein of the C3 server system 106 performing the method 700 is provided for illustration and not by way of limitation, and that the method 700 may be performed by any device or collection of devices that are suitably equipped, programmed, and configured to do so.

[0114] At step 702, the C3 server system 106 presents a plurality of medication dosing regimens associated with the patient 124 via the HCP portal 572 utilizing the user interface 208 of the HCP system 102. In at least one embodiment, each of the presented medication dosing regimens is associated with a corresponding different medication dosing algorithm. Exemplary medication dosing regimens and algorithms are discussed in more detail below.

[0115] Any one or more of the presented drug dosing schemes can be what is referred to in the art as an open-loop scheme or a closed-loop scheme. Generally speaking, a closed-loop scheme is based at least in part on automatically sensed feedback such as about the measurement results (such as glucose levels) taken by the patient, and the dosage of one or more drugs is iteratively adjusted in an automated manner (about, for example, amount, timing and / or the like), while an open-loop scheme does not iteratively adjust the dosage of the drug in an automated manner. However, it is often the case that an open-loop drug dosing scheme is more of a manual approach to similar historical data, wherein the patient manually inputs feedback parameters. An open-loop drug dosing scheme may also require the patient to manually control the distribution of the drug. More generally, the present system and method are not limited to any particular type of dosing scheme, any particular drug or drug type, or any particular way of delivering (such as, injection, intravenous injection, oral administration, etc.) drugs to the patient.

[0116] At step 704, the C3 server system 106 receives (for the patient 124) an HCP selection of at least one of the presented medication dosing regimens via the HCP portal 572 utilizing the user interface 208 of the HCP system 102. In the parlance of the present disclosure, the selected at least one regimen is referred to as "at least one HCP-selected medication dosing regimen," "at least one HCP-selected regimen," and / or the like.

[0117] In at least one embodiment, the medication dosing scheme presented in step 702 includes one or more insulin dosing schemes, and the medication dosing scheme selected by the at least one HCP includes at least one insulin dosing scheme selected by the HCP. Any number of presented schemes can be basal insulin dosing schemes, and any number of presented schemes can be bolus insulin dosing schemes. In some cases, the HCP selects a basal insulin dosing scheme or a bolus insulin dosing scheme for the patient 124. In some cases, the HCP simultaneously prescribes both one or more basal insulin dosing schemes and one or more bolus insulin dosing schemes to the patient 124.

[0118] 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, which is associated with a class of dosing algorithms referred to herein as daily titrated bolus insulin dosing algorithms. Other types of HCP-selected bolus insulin dosing regimens include: a type referred to herein as a fixed-dose bolus insulin dosing regimen, which is associated with a class of dosing algorithms referred to herein as fixed-dose bolus insulin dosing algorithms; a type referred to herein as a carbohydrate bolus calculator bolus insulin dosing regimen, which is associated with a class of dosing algorithms referred to herein as carbohydrate bolus calculator bolus insulin dosing algorithms; and a type referred to herein as a carbohydrate meal-based calculator bolus insulin dosing regimen, which is associated with a class of dosing algorithms referred to herein as a carbohydrate meal-based calculator bolus insulin dosing algorithm. Examples of each of the four types of open-loop bolus insulin dosing regimens / algorithms described above are described below in the subsections of the corresponding titles.

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

[0120] Although the example method 700 has been 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 via 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 medication dosing regimens to the HCP (step 702), receives the HCP selection from among the presented medication dosing regimens (step 704), and transmits data of the HCP selected regimen to the MMA 568, all without any assistance from and communication with the C3 server system 106. In such embodiments, the HCP system 102 may communicate directly with the mobile device 104 via the data network 108 without the need to pass or process the data through the C3 server system 106.

[0121] Regardless of whether the method 700 is implemented by the C3 server system or by the HCP portal 102, in at least some embodiments, the MMA 568 is configured to provide a dosing recommendation based on the at least one HCP selected regimen via the user interface 308. In some embodiments, the MMA 568 presents a prompt via the user interface 308 that provides the patient 124 with the option of accepting or rejecting 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 a regimen rejected indication, the regimen rejected indication indicating that the MMA 568 has received a patient rejection indication associated with the at least one HCP selected regimen via the user interface 308. Disabling the MMA 568 may include preventing a user from accessing some or all of the functions 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 the HCP. In other cases, the C3 server system 106 instead receives a regimen accepted indication indicating that the MMA 568 has received, via the user interface 308 , a patient acceptance indication associated with the at least one HCP-selected regimen.

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

[0123] In some cases, the unlocking occurs only in response to the MMA 568 receiving a patient acceptance indication of the at least one HCP selected regimen via the user interface 308. Allowing the MMA 568 to unlock or download a specific HCP selected regimen only after receiving data of the HCP selected regimen may be useful to 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 to patients with only provisions from qualified and licensed physicians. By limiting access to the dosing regimen until data of the HCP selected regimen is received, the MMA 568 in those embodiments ensures that the patient cannot access the dosing regimen without the required provisions.

[0124] Embodiments that perform the following operations provide several technical advantages that improve the efficiency and / or functionality of the present systems and methods: Storing the implementation data for all regimens presented to the HCP on the mobile device 104 and selectable by the HCP at steps 702 and 704 (e.g., as part of the MMA 568) and unlocking one or more regimens on the mobile device only after receiving the data for the regimen selected by the HCP transmitted in step 706. For example, storing the implementation data for all regimens on the mobile device 104 allows the HCP to implement a particular prescribed regimen on the patient's mobile device 104 without requiring the mobile device 104 to download additional, potentially sizable implementation data for the prescribed regimen. This allows the patient to more easily access and implement the prescribed regimen if the patient's mobile device 104 has only an intermittent or low-bandwidth communication link 112 with the data network 108 (e.g., in the event of a network failure or if the mobile device is placed in airplane mode).

[0125] Embodiments involving bundling implementation data for all regimens as part of the MMA 568 also allow for the publication of the MMA 568 for easy access by patients on certain popular online repositories for mobile applications. Such online mobile application repositories may include repositories managed by third-party entities other than the entity (or entities) that owns, maintains, and / or is affiliated with the HCP system 102, the administrator portal 148, or the patient 124; such online mobile application repositories may include the App Store maintained by Apple Inc. or the Google Play maintained by Google LLC. Such online repositories typically require that published applications include all implementation logic at the time of publication. In other words, to ensure the security and stability of applications running on mobile devices, administrators of such online repositories may prohibit application developers from updating or changing the code of published applications unless each update is submitted, reviewed, and / or approved by a third-party entity (e.g., Apple or Google) that maintains the online repository. As such, embodiments involving 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. This is a problem that is unique to and particularly arises in the field of medical mobile applications, which implement access to dosage regimens that should only be accessible to prescribed patients according to FDA regulations. By bundling the implementation data for all regimens as part of the MMA 568 at the time of release, and selectively unlocking the prescribed regimen only upon receipt of data for the regimen selected by the HCP, the MMA 568 avoids the need for such a time-consuming submission, review and / or approval process each time a new dosage regimen is prescribed to a patient. This bundling also improves the security and stability of the MMA.

[0126] As described above, in at least one embodiment, the MMA 568 is communicatively connected to one or more insulin delivery and / or insulin monitoring devices associated with the patient 124 via its host mobile device 104. 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 connected to an insulin delivery device associated with the patient 124, the MMA 568 communicates with the insulin delivery device to execute the regimen selected by the at least one HCP. 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 forwarded by the MMA 568 from the insulin delivery and / or monitoring device, examples of which (such as insulin injection record data and glucose measurement data) are described herein.

[0127] B. MMA on mobile devices

[0128] Figure 8 An example method 800 is depicted that may be performed by a mobile device 104 executing an MMA 568 in accordance with at least one embodiment. It should be understood that the description herein of the method 800 as being performed by an MMA 568 executing on a mobile device 104 is provided for illustration and not by way of limitation, and that the method 800 may be performed by any device or collection of devices that are suitably equipped, programmed, and configured to do so.

[0129] At step 802, the MMA 568 receives data of a HCP-selected regimen, the data indicating the HCP selection of at least one medication dosing regimen from among a plurality of medication dosing regimens, each of the medication dosing regimens being associated with a corresponding different medication dosing algorithm. In at least one embodiment, the HCP selection is 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 may receive data of the HCP-selected regimen directly from the HCP system 102 or from the C3 server system 106 as described in the present example. The at least one HCP-selected medication dosing regimen may include any possible regimen or regimen combination described herein.

[0130] At step 804, the MMA 568 unlocks the indicated HCP-selected medication dosing regimen on the MMA 568, at least in part in response to having received data for the HCP-selected regimen at step 802. As previously discussed, in at least one embodiment, step 804 involves accessing previously inaccessible implementation data for the HCP-selected regimen 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 involves downloading previously inaccessible implementation data for the HCP-selected regimen.

[0131] In at least one embodiment, after performing step 802 and before performing step 804, the MMA 568 presents a prompt for patient acceptance or patient rejection of the at least one HCP-selected medication dosing regimen via the user interface 308 of the mobile device 104, and then receives user input corresponding to the presented prompt via the user interface 308; in at least one such embodiment, the MMA 568 performs step 804 conditional on the received user input being a patient acceptance indication regarding the at least one HCP-selected medication dosing regimen. Additionally, 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.

[0132] In at least one embodiment where the scheme specified therein is or includes a bolus insulin dosing scheme, once a patient acceptance indication is received, indicating that the user has accepted the dosing scheme provision, MMA 568 presents the user with the option of entering a bolus dosage recommendation workflow, during which, in at least one embodiment, MMA 568 prompts the user to select a mealtime, prompts the user to enter and / or confirm its blood glucose measurement result and presents the bolus dosage recommendation to the user accordingly. The user can indicate to MMA 568 that he / she has taken the recommended dose, in which case MMA 568 will record the recommended dose in a memory. Alternatively, the user can indicate to MMA 568 that he / she has taken a dose of insulin different from the recommended dose, and MMA 568 will record the amount of insulin actually taken. The record can include the time of taking the dose, which can be automatically set when receiving the user's confirmation or at the time indicated by the user.

[0133] In at least one embodiment, the MMA 568 is communicatively connected to an insulin delivery (and / or glucose monitoring) device associated with the patient via the mobile device 104; in at least one such embodiment, the MMA 568 communicates with the insulin delivery device to execute the regimen selected by the HCP or receive information about the dose 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 forwards the received patient data to the C3 server system 106 and / or the HCP system 102. In addition to many other examples that can be listed here, the patient data can also include insulin injection record data (e.g., including the time and amount of insulin delivered in the previous dose) and / or glucose measurement data. In at least one embodiment, the MMA 568 provides a dosing recommendation based on the regimen selected by the HCP via the user interface 308 of the mobile device 104.

[0134] In at least one embodiment, 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, MMA 568 can calculate the expected "baseline" amount of the drug expected for each dose. The "baseline" dosage can be determined in multiple ways. For example, the "baseline" dosage can be a preset amount of the drug programmed by the HCP and / or the patient, or it can be algorithmically and automatically derived from the patient's medical or biographical information (e.g., gender, age, weight, type and severity of the disease, etc.). The "baseline" dosage can also be derived from a certain number of previous doses (e.g., the past three, five, ten or more doses) or in the previous sliding time window (e.g., in the past three, five, ten or more days) of the sliding mean, mode or average median of the dosage taken. In some embodiments, the "baseline" dosage can vary based on the time of day or based on the rising or falling trend detected in the previous dosage. Before recommending a dosage based on the regimen selected by the HCP, MMA 568 can compare the recommended dosage with the "baseline" dosage. If MMA 568 detects that it is recommending a dosage that is significantly different from the baseline dosage, such as if the recommended dosage differs from the baseline by a certain absolute drug amount or a certain percentage, then MMA 568 may remind the patient and prompt him / her to confirm the dosage. For example, the recommended dosage may be based on incorrectly entered patient input, such as incorrectly entered body insulin (insulin-on-board) parameters, meal amount values, or current glucose levels. Alternatively or in addition, if the user indicates to MMA that he / she intends to take a drug of an amount different from the recommended amount, then MMA 568 can similarly determine whether the amount indicated by the user is significantly different from the baseline dosage. If the amount indicated by the user is significantly different, then MMA 568 can remind the patient that the indicated dosage is significantly higher or lower than the baseline dosage. This additional prompt and reminder can help remind the user that he or she may be about to take an unsafe or incorrect amount of medicine. If appropriate, the user can ignore the reminder.

[0135] In at least one embodiment, the MMA 568 provides at least two access levels: general access, which can be downloaded, self-registered, and used by anyone; and prescribed access, which provides additional functionality unlocked by electronic dosing regimen provisions. In an embodiment, general access provides features including: (i) logging of diabetes-related data, which, as an example, may include glucose levels (GL), basal insulin, bolus insulin, carbohydrate input, and exercise / stress / disease factors, and (ii) access visualization of user data (e.g., charts), whereas in an embodiment, prescribed access unlocks bolus insulin dosage recommendations through the 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 prescribed access mode (and / or perhaps other modes). Such changes may include, but are not limited to, additional and / or fewer menu items, color scheme changes, icon changes, layout changes, and / or the like.

[0136] In at least some embodiments, the general access (non-prescribed) mode of the MMA 568 provides one or more of the following features:

[0137] ■ Data input

[0138] ● Users can enter diabetes-related data to facilitate HCP tracking and review of data.

[0139] ● Users can log bolus insulin doses, basal insulin doses, glucose readings (manually or via wireless connection to a glucose meter), and carbohydrate intake.

[0140] ● Users can also log the following modifiers (if applicable) and yes / no data points: Activity, Stress, Illness, Steroids, and Menstruation.

[0141] ● Patients can enter values ​​into their MMA, such as glucose values ​​(automatic from a sensor or manual), current activity level, food currently eaten, carbohydrate content of food, physiological characteristics (such as weight), etc.

[0142] ■ Digital diary

[0143] ● Users can track diabetes related data so that all of their data can be easily accessed and viewed in one location.

[0144] ● Users can view any data they have entered in a digital logbook format.

[0145] ■ Glucose meter pairing

[0146] ● Simplify the glucose entry process for users who want to store all of their data in one location or want to use glucose data to receive dosage recommendations.

[0147] ● Users can select the option to pair a device such as a blood glucose meter, continuous glucose meter, rapid glucose monitor, or other glucose monitoring device. Once they have paired their glucose monitoring device, MMA will display their most recent glucose measurement when the user navigates to the Bolus Dosing Recommendation workflow (available only in Prescription Mode) or the Data Entry workflow (available in General Access Mode).

[0148] ● Users can pair with connected glucose meters that claim to comply with the Continua standard (also known as the Continua Design Guidelines), which is published by the Personal Connected Health Alliance (PCHAlliance) in Arlington, Virginia.

[0149] ● In some embodiments, users can conduct experiments by doing activities and measuring the impact on their glucose levels. Users can review experiments they have completed. Such experiments can be based on activity, food, and / or other factors. In some embodiments, third-party data sources (e.g., HealthKit, FitBit, and / or the like) create experiments for users. Indeed, in some embodiments, the MMA can connect and communicate with wearable devices such as FitBit, Apple Watch, and / or the like to facilitate monitoring of one or more physiological parameters and / or integration of insights about said one or more physiological parameters.

[0150] ■ Data Visualization

[0151] ● Users can view the data they have collected over a range of time periods to make the data more understandable.

[0152] ● Users can navigate to the section of the MMA that hosts data visualizations. They can then select the type and time period of data they want to view.

[0153] • The MMA will also show a pie chart of the recorded glucose values ​​to show numbers that are above range, in range, below range, and those that fall into low blood glucose levels (≤ 70 mg / dL).

[0154] ■ Reminder

[0155] ● Help users remember to test their glucose or enter a bolus dose recommendation workflow when their schedule is busy.

[0156] ● Users can set reminders for when they want to test their glucose levels and / or administer insulin.

[0157] ● Users will receive a message on their mobile device regarding the reminder.

[0158] ■ Guidance process

[0159] ● Users can register for MMA and learn about useful functions.

[0160] ● Users may register to use MMA by creating login credentials, entering basic information about themselves and accepting the Terms of Use.

[0161] ● MMA will provide optional activities (such as tutorials) to help users understand useful features, including pairing a glucose meter or setting personalized reminders.

[0162] ■ Education about diabetes

[0163] ● Help users learn about their diabetes from reputable sources.

[0164] ● Users can access links to diabetes education from within the MMA. Such links can launch or start a browser application within the MMA, among other possibilities.

[0165] C. Sample HCP Portal Screenshot

[0166] As described below, Figure 9-2 1 depicts various screen shots of various different embodiments of the HCP system 102.

[0167] Fig. 9 900, wherein the HCP user is operating in the "Select [Dosing] Method" tab, and wherein four bolus insulin dosing regimens are listed as options for the HCP to select - the four bolus insulin dosing regimens are described in further detail below. In an embodiment, clicking on any of the presented regimens presents a pop-up window providing further details. In at least one embodiment, when the HCP selects one of the four dosing regimens, the HCP system 102 sends the data of the regimen selected by the HCP to the mobile device 104, which enables the patient to access the selected dosing regimen on the mobile device.

[0168] Fig.10 1 is a screen shot 1000 showing electronic health record (EHR) data relating to an exemplary patient, depicting various patient data in graphical form. In the screen shot 1000, a dosing regimen has not yet been prescribed to the exemplary patient.

[0169] Fig.111 is a screen shot 1100 in which an alert message 1102 is displayed indicating that a pending change to a dosing recommendation or prescription is still pending patient acceptance. In this screen shot 1100, the patient has no prescribed active dosing method and no historical data regarding glucose values ​​and usage information. A fixed meal bolus dosing method has been prescribed to the patient, but the patient has not yet accepted the prescribed dosing method.

[0170] Fig.12 12 is a screen shot 1200 in which an alert message 1202 is displayed regarding a pending change to a dosing recommendation or prescription that is still awaiting patient acceptance. In this screen shot 1200, the patient had previously been prescribed a carbohydrate bolus calculator bolus insulin dosing regimen, but has now been prescribed a fixed dose bolus insulin dosing regimen. The patient has not yet accepted the new prescribed dosing method.

[0171] Fig.13 13 is a screenshot 1300 depicting a “Configuration Settings” tab, wherein the selected dosing regimen is a daily titrated bolus insulin dosing regimen, also referred to as a “daily titration” regimen. Fig.13 As shown in , the daily titration regimen settings tab gives the HCP the option of prescribing bolus options for the following three meals: breakfast, lunch, and dinner. For each meal, the HCP can choose between "titration", "stable" and "none". The titration option results in a dose recommended for the meal to be titrated according to the algorithm described below in this article. 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.

[0172] Fig.14 14 is a screenshot 1400 depicting a “Review and Confirm” tab, where again the selected dosing regimen is “Daily Titration.” Here, the HCP can review and confirm the regimen before prescribing a future daily titration dosing regimen to the patient.

[0173] Fig.15A and Fig. 15B15 is a screenshot 1500 depicting a "Configuration Settings" tab, wherein the selected dosing regimen is a fixed-dose bolus insulin dosing regimen, also referred to as a "fixed meal dosing" regimen. The HCP user is presented with an opportunity to confirm the customizable details of the regimen for the specific patient in question. For example, the HCP user can customize the bolus dosage settings for the following 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 sensitivity factor (described in further detail below), a bolus dose, options for implementing various health factors (e.g., activities, diseases, stress, steroids, and menstruation described in further detail below), setting permissions (which, if implemented, allow patients to change their own prescribed settings) and effective insulin (described in further detail below).

[0174] Fig.16 16 is a screen shot 1600 depicting a "Review and Confirm" tab, wherein the dosage scheme selected again is a fixed meal dosage scheme. Here, the HCP can review and confirm the scheme before prescribing a future fixed meal dosage scheme to the patient.

[0175] Fig.17 17 is a screenshot 1700 depicting a "Configuration Settings" tab, wherein the selected dosing scheme is a carbohydrate meal-based calculator bolus insulin dosing scheme, also referred to as a "carbohydrate meal" scheme. Fig.17 As shown in , the carbohydrate meal amount scheme setting tab gives the HCP the option of specifying a large bolus dosage option for the following 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 sensitivity coefficient (described in further detail below), and an insulin to carbohydrate ratio (described in further detail below). Independent of the time period, the HCP user can also select the expected grams of carbohydrates from each of the "small", "medium" and "large" meals. Finally, the HCP user can select the insulin duration.

[0176] Fig.18 18 is a screenshot 1800 depicting a “Configuration Settings” tab, wherein the selected dosing scheme is the Carbohydrate Bolus Calculator Bolus Insulin Dosing Algorithm, also referred to as the “Carbohydrate Counting” scheme. Fig.18 As shown in , the Carbohydrate Counting Program Settings tab is similar to the Carbohydrate Meal Size Program Settings tab, except that it does not give the HCP user the option to select the expected number of grams of carbohydrates for "Small," "Medium," and "Large" meals.

[0177] II. Example Open-Loop Bolus Insulin Dosing Algorithms and Associated Protocols

[0178] Some or all of the exemplary open-loop bolus insulin dosing algorithms and associated protocols described herein can calculate a recommended bolus based on insulin on body (IOB). IOB is a calculated value that describes the amount of insulin expected to remain effective in the patient's body from a previously injected bolus insulin dose. This value can reduce the amount of insulin the algorithm recommends the patient inject. At least two different methods can be used to calculate IOB.

[0179] The first method can calculate IOB by taking into account only a portion of the previous dose necessary to correct a higher-than-expected glucose reading. A single dose of insulin taken at a discrete time point can be determined based on several parameters including any or all of the following: (i) the amount of insulin necessary to correct a higher-than-expected glucose reading, (ii) the additional amount of insulin necessary to "cover" or account for the amount of carbohydrates consumed by the patient in a meal shortly after, shortly before, or during the dose, and (iii) any (positive or negative) adjustments necessary 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 has, is, or expects to exercise, whether the patient is menstruating, whether the patient is taking steroids, and / or whether the patient is experiencing stress). The first method can calculate IOB by taking into account only parameter (i), which is the amount of insulin necessary to correct a higher-than-expected glucose reading. The first method may not take parameters (ii) or (iii) into account when calculating IOB.

[0180] The second method may calculate the IOB by taking into account all insulin taken as part of the previous dose. In other words, the second method calculates the IOB by taking into account not only parameter (i) but also parameter (ii) (i.e., the amount of insulin necessary to "cover" a certain amount of carbohydrates in the meal) and parameter (iii) (taking into account any adjustments for health factors). This second method will generally result in a higher calculated IOB unless the negative adjustment from parameter (iii) more than offsets the positive contribution from parameter (ii).

[0181] Of course, other methods for calculating IOB are possible. For example, other methods can calculate IOB by taking into account parameters (i) and (iii) but not taking into account parameter (ii). It is to be understood that any of the above methods can be used to calculate references to body insulin or IOB in the following discussion. In some embodiments, the HCP, the patient, or both can instruct the insulin dosing algorithm to use a specific method to calculate IOB. For example, Fig. 15B Screen shot 1500 in shows that the HCP can select a "conservative" option for calculating effective insulin (e.g., IOB), or a "standard" option. The "standard" option corresponds to the first method discussed above, while the "conservative" option corresponds to the second method. The MMA may include logic that can calculate IOB using both the first method and the second method, and the patient, the HCP, and / or both may be given the option to choose between the two methods when calculating the recommended bolus.

[0182] A. Daily titration

[0183] An exemplary daily titration algorithm and associated dosing regimen are described below.

[0184] The recommended dose starts with the initial value set by the HCP when the dosing regimen is prescribed. The default starting dose is 10% of the total daily basal insulin for breakfast or lunch titration and 5% for dinner titration. The recommended dose for each subsequent day is calculated based on the glucose reading logged from the previous day. That is, the recommended dose for the second day is calculated based on the glucose reading from the first day; the recommended dose for the third day is calculated based on the glucose reading from the second day, and so on. Some exemplary rules for calculating the recommended dose for each subsequent day are provided in the following table.

[0185]

[0186] Abbreviations: GL = glucose level, TBI = total basal insulin, U = unit.

[0187] * Previous day's GL reading (mg / dL).

[0188] An exemplary daily titrated dosing regimen is for users with T2DM (type 2 diabetes mellitus) between the ages of 18 and 85 who meet the following criteria:

[0189] ● Failure to achieve glycemic goals despite optimization of basal insulin with or without metformin

[0190] ● Request for intensification of treatment regarding mealtime insulin

[0191] ● For them, a glucose target range of 85-114 mg / dL is appropriate.

[0192] To implement the exemplary daily titration dosing regimen, the HCP sets the following parameters:

[0193] ● Total daily basal insulin (TBI), in insulin units

[0194] ● Initial starting doses and meals to be titrated, measured in insulin units.

[0195] In addition, the HCP can set the following parameters:

[0196] ● One (or more) steady doses in insulin units for each (or more) meal(s).

[0197] The MMA will use the following additional inputs to calculate the recommended dose:

[0198] ● Current GL in mg / dL: MMA uses the current GL to prevent recommended insulin doses when the patient has hypoglycemia (glucose ≤70 mg / dL)

[0199] ● Pre-meal GL (GL), in mg / dL: The pre-meal GL is the GL taken after the titration dose from the previous day.

[0200] In at least one embodiment, the exemplary daily titration dosing regimen does not take a correction dose, IOB (insulin on body), or adjustment factor as input to calculate the recommended dose.

[0201] In at least one embodiment, the MMA 568 provides recommendations for once-a-meal initiation and titration of basal insulin dosing using glucose values ​​entered by the patient, and it is intended that the MMA 568 be used in this manner multiple times daily under the guidance of the HCP for entering glucose values ​​and receiving dosage recommendations.

[0202] B. Fixed dose

[0203] An exemplary fixed dose algorithm and associated regimen are described below.The fixed dose algorithm may allow the HCP to set a "fixed" bolus amount per meal, as modified by any adjustments needed to correct for patient glucose levels outside of a desired range.

[0204] Meal options may include skipping a meal (e.g., correction dose only), breakfast, lunch, or dinner. The HCP may 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 may include adjustments to insulin on-body (IOB), corrections for glucose levels (GL) above or below GL target, and lifestyle or health factors (e.g., exercise, stress, illness, steroids, or menstruation).

[0205] An exemplary fixed dose regimen may be suitable for users with type 1 diabetes mellitus (T1DM) or type 2 diabetes mellitus (T2DM) who are new to bolus therapy or who require bolus dose optimization. In some cases, users may require multiple daily injections of mealtime insulin with rapid-acting insulin analogs.

[0206] To achieve an exemplary fixed dose regimen, the HCP may set the following parameters:

[0207] ● Fixed dose (FD), in units of insulin for each patient-selected meal type

[0208] ● Target GL (GL T ), in mg / dL

[0209] ● Insulin Sensitivity Factor (ISF), in mg / dL / insulin unit

[0210] ● Insulin duration (ID), in hours.

[0211] In some embodiments, HCP can control whether the user can change the specific setting of their scheme. For example, the user may not be able to change the ratio of their insulin to carbohydrates unless HCP realizes such a change. And other examples can also be listed here of course. In addition, in some embodiments, HCP can realize any lifestyle modifier, all lifestyle modifiers or do not realize any one of the following lifestyle modifiers in the following lifestyle modifiers, and set the corresponding adjustment amount. If realized, lifestyle modifiers allow MMA patient users to indicate whether they are experiencing certain conditions of the amount of insulin that may affect their body needs via the user interface of their mobile device, for example, such conditions include: whether he / she is exercising or performing physical activities, whether he / she is experiencing stress, whether he / she is sick, whether he / she is taking steroids or whether she is menstruating. For each of these lifestyle modifiers, HCP sets the adjustment amount in percentage. The percentage value is converted into a decimal value for use in an equation. If HCP does not realize modifiers, the dosing scheme will use a 0 value.

[0212] ● Activity Factor (AF), in percent

[0213] ● Stress Factor (SF), in percentage

[0214] ● Disease Factor (IF), in percentage

[0215] ● Steroid Factor (StF), in percent

[0216] ● Menstrual factor (MF), expressed as a percentage.

[0217] The MMA will use the following additional inputs to calculate the recommended dose:

[0218] ● Meal choices used to determine FD values ​​(skipping meals, breakfast, lunch, dinner) in insulin units

[0219] ● Current GL (GL), in mg / dL

[0220] ● Current time (t), in hours

[0221] ● Note: The current time may include hours, minutes, and seconds, but may be used as a fraction of hours in calculations.

[0222] The insulin on body (IOB), i.e., all insulin doses still effective in the current time period, will be incorporated into the calculation. A previous dose is considered "effective" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the following parameters may be used to calculate the previous dose:

[0223] ● Delivered large bolus (DB), measured in insulin units

[0224] ● Time for delivery of large bolus (t DB ), in hours

[0225] ● Multiplication factor (X)

[0226] ○ X = 0 when the individual delivered bolus was administered less than and including 0.5 hours ago

[0227] ○ X = 1 when the individual's delivered bolus was administered more than 0.5 hours and less than ID hours ago.

[0228] As previously discussed, the DB parameter in the IOB calculation can be defined in one of two ways for a particular previously administered insulin dose. According to both approaches, the DB parameter can be set to: (i) only the glucose correction portion of the previous dose, or (ii) the total amount of insulin injected in the previous dose. Option (i) corresponds to the first approach discussed above, and is also referred to herein as Fig. 15B In this option, the glucose correction portion of the previous dose is calculated as , where GL DB is the GL entered when calculating the previous dose. Tis the target GL, and ISF is the insulin sensitivity factor (discussed below). Option (ii) corresponds to the second approach discussed above, and is also referred to in this article as Fig. 15B The HCP can select which of these two methods is used to calculate the DB parameters, such as Fig. 15B Alternatively, the patient or both the HCP and the patient may have the option to specify which method is to be used to calculate the DB parameters.

[0229] According to an exemplary fixed dose regimen, the bolus insulin dose recommendation (RD) may be calculated using the following formula:

[0230] .

[0231] The term FD indicates the fixed dose part of the formula. represents the correction dose portion of the formula, e.g., based on the patient's glucose level (GL) exceeding the target glucose level (GL T ) portion of the formula that adjusts the recommended dose by the amount of insulin needed to treat an individual. ISF is the insulin sensitivity factor, which indicates how much one unit of insulin (e.g., rapid-acting insulin) is expected to lower an individual's glucose level. Generally, to correct a high glucose level, one unit of insulin is required to lower the glucose level by 50 mg / dl. However, this drop in glucose levels can range from 15-100 mg / dl or more, depending on the individual's insulin sensitivity and other circumstances. The term (1 + AF + SF + IF + StF + MF) takes into account the lifestyle factors discussed previously. Terminology All previous doses of IOB were taken into account.

[0232] The following considerations apply to this formula:

[0233] • If the patient chooses not to take a meal, the fixed dose value will be 0; however, the patient will still receive the correction dose, if applicable.

[0234] ● Correction dose Can be positive, negative, or 0.

[0235] ● Each IOB is calculated Can be positive or 0. During this calculation, if the IOB calculation returns a negative value, the MMA will use a value of 0 valid insulin units.

[0236] If the calculated recommended dose returns a negative value, the MMA will recommend 0 insulin units. Alternatively, if the MMA detects that the patient is in or about to enter a hypoglycemic state, and / or if the MMA determines that the patient has too much IOB (systemic insulin, i.e., the amount of insulin in the patient's system), the MMA can recommend that the patient eat a meal or eat a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is in or about to enter a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other drug that increases the patient's glucose level.

[0237] This exemplary fixed dosing regimen can reduce the complexity of bolus insulin dosing by allowing the user to receive dosage recommendations based on the fixed dosing regimen as configured by the HCP. If the user has accepted the dosing regimen provisions, the user will enter the app and can choose to enter the bolus dosage recommendation workflow. They will select a meal, enter and / or confirm their glucose measurement results, select any additional modifiers (such as changes in activity or stress), and receive bolus dosage recommendations. The fixed dosing regimen takes into account the amount of insulin assigned by the HCP to cover the meal, the correction dose based on current and target blood glucose, and the body insulin based on internal insulin PKPD data.

[0238] C. Carbohydrate Pill Calculator

[0239] An exemplary carbohydrate bolus calculator algorithm and associated protocol are described below.

[0240] The exemplary carbohydrate bolus calculator protocol is based on rules for "covering" the carbohydrate content of a meal, and this method is recommended in clinical guidelines as a personalized way to match mealtime insulin to meal intake. Therefore, it can be used at any time of the day and may not be associated with a specific meal. It calculates the recommended bolus insulin dose based on insulin sensitivity, carbohydrate intake, GL target, and current GL. It will also account for correction doses, IOB, and optional adjustment factors.

[0241] The bolus can be calculated based on two factors: (i) the insulin needed for food or carbohydrate coverage, and (ii) the insulin needed to correct high blood sugars.

[0242] Bolus doses for food or carbohydrate coverage are prescribed based on the insulin to carbohydrate ratio (ICR). The insulin to carbohydrate ratio indicates how many grams of carbohydrates are covered or addressed by 1 unit of insulin. Generally, one unit of rapid-acting insulin will address 12-15 grams of carbohydrates; however, this parameter can vary from 4 to 30 or more grams of carbohydrates, depending on the individual's sensitivity to insulin. Insulin sensitivity can vary from person to person, depending on the time of day, and is affected by physical activity and stress.

[0243] The exemplary carbohydrate bolus calculator protocol is suitable for users with T1DM or T2DM who accurately count carbohydrates or who can learn to do so at the discretion of the HCP. In some cases, users may require multiple daily injections of mealtime insulin and rapid-acting insulin analogs.

[0244] To implement the exemplary Carbohydrate Bolus Calculator protocol, the HCP may set the following parameters:

[0245] ● Target GL (GL T ), in mg / dL

[0246] ● Insulin Sensitivity Factor (ISF), in mg / dL / insulin unit

[0247] ● Insulin to Carbohydrate Ratio (ICR), measured in grams of carbohydrate per unit of insulin

[0248] ● Insulin duration (ID), in hours.

[0249] In addition, the HCP may implement 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 their patients. The percentage values ​​are converted to decimal values ​​for use in equations. If the HCP does not implement a modifier, the dosing regimen will use a value of 0.

[0250] ● Activity Factor (AF), in percent

[0251] ● Stress Factor (SF), in percentage

[0252] ● Disease Factor (IF), in percentage

[0253] ● Steroid Factor (StF), in percent

[0254] ● Menstrual factor (MF), expressed as a percentage.

[0255] The MMA will use the following additional inputs to calculate the recommended dose:

[0256] ● Current GL (GL), in mg / dL

[0257] ● Current time (t), in hours

[0258] ● Carbohydrate intake (CHO), in grams of carbohydrate, or dietary insulin (MI), in units of insulin.

[0259] The insulin on body (IOB), i.e., all insulin doses still effective in the current time period, will be incorporated into the calculation. A previous dose is considered "effective" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the following parameters may be used to calculate the previous dose:

[0260] ● Delivered large bolus (DB), measured in insulin units

[0261] ● Time for delivery of large bolus (t DB ), in hours

[0262] ● Multiplication factor (X)

[0263] ○ X = 0 when the individual delivered bolus was administered less than and including 0.5 hours ago

[0264] ○ X = 1 when the individual's delivered bolus was administered more than 0.5 hours and less than ID hours ago.

[0265] As previously discussed, the DB parameter in the IOB calculation can be defined in a number of ways. For example, the DB parameter can be set to: (i) the total amount of insulin from the previous dose, or (ii) only the glucose correction portion of the previous dose.

[0266] The MMA user may choose to enter either carbohydrate intake (CHO) (e.g., the expected amount of carbohydrates in a meal) or mealtime insulin (MI) (e.g., expressed in units of insulin). If the MMA user chooses to enter mealtime insulin, the MMA user may enter the number of units of insulin that the user expects will cover 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 cover that type of meal, the MMA user may choose to enter the number of units of mealtime insulin instead of the expected carbohydrate intake. Depending on whether the MMA user enters carbohydrate intake or prandial insulin, the appropriate formula below will be used to calculate the recommended dose.

[0267] When the user enters a carbohydrate intake value, the bolus insulin dose recommendation (RD) is calculated using the following formula:

[0268]

[0269] in Represents the carbohydrate intake portion of the formula.

[0270] When the user enters a prandial insulin value, the bolus insulin dose recommendation is calculated using the following formula:

[0271]

[0272] in MI Indicates insulin used to cover meal intake.

[0273] The following considerations apply to this formula:

[0274] ● Correction dose Can be positive, negative, or 0.

[0275] ● Each IOB is calculated Can be positive or 0. During calculations, if the IOB calculation returns a negative value, the MMA will use a valid insulin unit value of 0.

[0276] If the calculated recommended dose returns a negative value, the MMA will recommend 0 insulin units. Alternatively, if the MMA detects that the patient is in or about to enter a hypoglycemic state, and / or if the MMA determines that the patient has too much IOB (systemic insulin, i.e., the amount of insulin in the patient's system), the MMA can recommend that the patient eat a meal or eat a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is in or about to enter a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other drug that increases the patient's glucose level.

[0277] The exemplary carbohydrate bolus calculator scheme helps to reduce the complexity of bolus insulin dosing by allowing the user to receive a dosage recommendation based on the bolus calculator scheme as configured by the HCP. If the user has accepted the dosing scheme provisions, the user will enter the app and can choose to enter the bolus dosage recommendation workflow. They will enter and / or confirm their glucose level measurement results, enter the number of carbohydrates they intend to consume, select any additional modifiers (such as changes in activity or pressure), and receive bolus dosage recommendations. Users can choose to enter the amount of insulin required to cover the meal instead of the amount of carbohydrates, using this scheme helps to correct the dose and take into account body insulin. The carbohydrate bolus calculator dosing scheme takes into account the amount of insulin used to cover the expected carbohydrate intake, the correction dose based on current and target blood sugars, and the body insulin based on internal insulin PKPD data.

[0278] D. Carbohydrate-based dietary calculator

[0279] An exemplary calculator algorithm based on the amount of carbohydrate meals and associated schemes are described below. The exemplary calculator scheme based on the amount of carbohydrate meals utilizes the functionality of the exemplary carbohydrate bolus calculator scheme described above, wherein the HCP has made additional settings for the qualitative assessment of the small, medium, and large carbohydrate meal content. For example, instead of allowing the MMA user to input the expected number of carbohydrates in the meal or the amount of mealtime insulin, the MMA user can simply indicate that he / she will eat a "small" meal, a "medium" meal, or a "large" meal. Then based on the preset values ​​(possibly configurable by the HCP and / or the MMA user) for a "small" meal, a "medium" meal, or a "large" meal, the MMA user's selection is converted into an estimated number of carbohydrates.

[0280] The exemplary carbohydrate-based meal size calculator program is suitable for users with T1DM and T2DM who can estimate meal sizes, and in particular the size of the carbohydrate content in a meal. In some cases, a user may require multiple daily injections of mealtime insulin with a rapid-acting insulin analog.

[0281] To implement the exemplary carbohydrate-based meal size calculator protocol, the HCP may set the following parameters:

[0282] ● Target GL (GL T ), in mg / dL

[0283] ● Insulin Sensitivity Factor (ISF), in mg / dL / insulin unit

[0284] ● Insulin to Carbohydrate Ratio (ICR), measured in grams of carbohydrate per unit of insulin

[0285] ● Insulin duration (ID) in hours

[0286] ● Estimated amount of carbohydrate in a "small" meal, in grams of carbohydrate

[0287] ● Estimated amount of carbohydrate in a "medium" meal, in grams of carbohydrate

[0288] ● The estimated amount of carbohydrate in a “large” meal size, in grams of carbohydrate.

[0289] In addition, the HCP may implement 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 their patients. The percentage values ​​are converted to decimal values ​​for use in equations. If the HCP does not implement a modifier, the dosing regimen will use a value of 0.

[0290] ● Activity Factor (AF), in percent

[0291] ● Stress Factor (SF), in percentage

[0292] ● Disease Factor (IF), in percentage

[0293] ● Steroid Factor (StF), in percent

[0294] ● Menstrual factor (MF), expressed as a percentage.

[0295] The MMA will use the following additional inputs to calculate the recommended dose:

[0296] ● Current GL (GL), in mg / dL

[0297] ● Current time (t), in hours

[0298] ● Carbohydrate intake meal size (MS), such as small, medium, large or no choice

[0299] ○ MMA will replace the meal amount with the corresponding grams of carbohydrates based on the HCP preset for the selected meal

[0300] ○ If the patient selects the “no meal” option, the MMA will replace the meal size with a value of 0.

[0301] The insulin on body (IOB), i.e., all insulin doses still effective in the current time period, will be incorporated into the calculation. A previous dose is considered "effective" if it was taken less than ID (insulin duration) hours ago. In some embodiments, the following parameters may be used to calculate the previous dose:

[0302] ● Delivered large bolus (DB), measured in insulin units

[0303] ● Time for delivery of large bolus (t DB ), in hours

[0304] ● Multiplication factor (X)

[0305] ○ X = 0 when the individual delivered bolus was administered less than and including 0.5 hours ago

[0306] ○ X = 1 when the individual's delivered bolus was administered more than 0.5 hours and less than ID hours ago.

[0307] As previously discussed, the DB parameter in the IOB calculation can be defined in a number of ways. For example, the DB parameter can be set to: (i) the total amount of insulin from the previous dose, or (ii) only the glucose correction portion of the previous dose.

[0308] The following formula will be used to calculate the bolus insulin dose recommendation (RD):

[0309]

[0310] in Indicates carbohydrate intake.

[0311] The following considerations apply to this formula:

[0312] ● Correction dose Can be positive, negative, or 0.

[0313] ● Each IOB is calculated Can be positive or 0. During calculations, if the IOB calculation returns a negative value, the MMA will use a value of 0 valid insulin units.

[0314] If the calculated recommended dose returns a negative value, the MMA will recommend 0 insulin units. Alternatively, if the MMA detects that the patient is in or about to enter a hypoglycemic state, and / or if the MMA determines that the patient has too much IOB (systemic insulin, i.e., the amount of insulin in the patient's system), the MMA can recommend that the patient eat a meal or eat a certain amount of carbohydrates. In some embodiments, if the MMA determines that the patient is in or about to enter a hypoglycemic state, the MMA can recommend that the patient inject glucagon or some other drug that increases the patient's glucose level.

[0315] An exemplary carbohydrate meal-based calculator protocol can help reduce the complexity of bolus insulin dosing by allowing the user to receive a dosage recommendation based on a meal-based calculator protocol as configured by the HCP. If the user has accepted the dosing protocol provisions, the user will enter the app and can choose to enter the bolus dosage recommendation workflow. They will enter and / or confirm their glucose measurement results, select their meal size, select any additional modifiers (such as changes in activity or stress), and receive bolus dosage recommendations. The carbohydrate meal-based calculator dosing protocol takes into account the amount of insulin used to cover the expected carbohydrate intake, the correction dose based on current and target blood glucose, and the body insulin based on internal insulin PKPD data.

[0316] Fig.19 1 is a flow chart illustrating an exemplary 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 the patient's condition and recommend an insulin dosage according to whichever insulin dosing regimen has been prescribed and implemented on the MMA.

[0317] At step 1902, the MMA receives a glucose reading from the patient. This can be done in a variety of ways. For example, Fig. 20 Depicted are exemplary screenshots from an MMA that automatically synchronizes with a patient's connected glucose sensor, such as a continuous glucose meter (CGM). Fig. 20 As shown in FIG, the MMA may depict the time at which the glucose meter reading was taken from the connected glucose meter (9:31 AM in this example), the blood glucose level (355 mg / dL in this case), and also allow the patient to edit the blood glucose reading by touching a button labeled “or Edit Blood Glucose.” If the patient agrees with the glucose level received from the connected glucose meter, or if the patient has finished editing the glucose level, the patient may touch a button labeled “Confirm Blood Glucose,” at which point the MMA will record the presented glucose level in the patient's log.

[0318] Alternatively, the MMA may allow the patient to manually enter his or her glucose level, or prompt the MMA to synchronize with a connected glucose meter. Fig.21A , 21B These methods of receiving a patient's glucose level are illustrated in 21C and 21D. Fig.21A In the MMA, the patient is prompted to enter his or her glucose level. If the patient touches the button labeled "Enter Blood Glucose," the MMA transitions to Fig.21B , where the patient can manually enter his or her glucose level. Once the patient has entered the glucose level, the patient can touch the "Next" button to command 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 Fig. 21C , where the MMA is synchronized with a patient's connected glucose meter (e.g., BGM, CGM, or FGM). In this case, Fig. 21C As shown in , the MMA receives a glucose level of 355 mg / dL from the patient's connected glucose meter. Fig.21B Sync with Meter" button, the MMA will also change to Fig. 21C Once the MMA receives the glucose level from the connected meter, the patient can command the MMA to record the glucose level in the patient's diary by touching the "Next" button.

[0319] return Fig.19 Once the MMA receives the glucose reading, the MMA moves to step 1904. At this point, the MMA determines which dosing regimen has been prescribed and implemented on the MMA. If a daily titration regimen has been prescribed / implemented, the process 1900 branches to step 1906. If a fixed dose regimen has been prescribed / implemented, the process 1900 branches to step 1908. If a carbohydrate bolus calculator regimen has been prescribed / implemented, the process 1900 branches to step 1910. If a carbohydrate meal size based calculator regimen has been prescribed / implemented, the process 1900 branches to step 1912.

[0320] At step 1906 (for the daily titration regimen), the MMA receives a selection from the patient of a meal type or time of day. For example, Figures 22A-22C The illustrative screen shot shown in allows the patient to indicate whether he or she is about to have breakfast ( Fig.22A ), during lunch time ( Fig. 22B ), at dinner time ( Fig. 22C ) or at bedtime ( Fig.22D) Take a dose. The MMA uses this information to calculate the recommended insulin dose according to the exemplary algorithm described above for the "daily titration" dosing regimen.

[0321] At step 1908 (for a fixed dose regimen), the MMA receives from the patient a selection of meal type and any health factors that apply. For example, Figures 23A-23D The illustrative screen shot shown in allows the patient to indicate whether he or she is about to have breakfast ( Fig. 23B ), during lunch time ( Fig.23C ) or at dinner time ( Fig.23D ) Do not take with any meal ( Fig.23A ) associated with the patient's meal plan. Regardless of which meal option the patient selects, the patient can select any health factors the patient is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. According to the exemplary algorithm described above for the "fixed dose" dosing regimen, the MMA uses this information to calculate the recommended insulin dose.

[0322] At step 1910 (for the Carb Big Pill Calculator protocol), the MMA receives the expected number of grams of carbohydrates that the patient intends to consume, and / or the expected number of units of mealtime insulin that the patient predicts will be sufficient to cover the carbohydrates he or she intends to consume. The MMA also receives from the patient any health factors that apply. For example, Fig.24A Prompt the patient to enter the expected number of grams of carbohydrates to be consumed. The patient can use the numeric keypad to enter the estimated amount of carbohydrates. Fig. 24B As depicted in FIG. 1 , the patient has indicated that he or she intends to consume 96 grams of carbohydrates. When the patient presses the “Next” button, the MMA transitions to Fig.24C , where the patient can select any health factors he or she is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. Once the patient has finished selecting health factors, the patient can touch a "Next" button (not shown), which appears when at least one health factor has been selected. Alternatively, if the patient is not experiencing any of these health factors, the patient can press a "Skip" button. If at least one health factor is selected, or if the patient presses the "Skip" button, the MMA transitions to Fig.24D The screen shown in Fig.24D , the MMA displays the grams of carbohydrates selected and any selected health factors for the patient's confirmation. The patient can confirm by touching the "Next" button.

[0323] Alternatively, the patient may decide to enter the number of units of mealtime insulin that the patient expects (e.g., based on experience) will cover the meal he or she is about to consume. The patient may select Fig.24A to indicate to the MMA that he or she will be entering mealtime insulin. If the "Mealtime Insulin" radio button is selected, the MMA transitions to Fig.25A -D shows a series of screens. Fig.25A In the MMA, the patient is prompted to enter the number of units of mealtime insulin using the numeric keypad. For example, Fig.25B As depicted in FIG, the patient has already infused 12 units of mealtime insulin. When the patient presses the “Next” button, the MMA transitions to Fig.25C , where the patient can select any health factors he or she 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 can press the "Skip" button. Fig.25D , the MMA displays the number of units of mealtime insulin selected and any selected health factors for the patient's confirmation. The patient can confirm by pressing the "Next" button.

[0324] return Fig.19 At step 1912 (for the carbohydrate-based meal size calculator protocol), the MMA receives from the patient a selection of meal size and any health factors that apply. For example, Fig.26A The illustrative screen shot shown in -D allows the patient to indicate whether he or she is about to take the drug without any meals ( Fig.26A ), and "small" meals ( Fig.26B ), and a "medium" diet ( Fig.26C ) or with a "large" meal ( Fig.26D ) associated with the meal size. These meal size selections are converted into expected carbohydrate quantities based on the preset meal size definitions described previously. Regardless of which meal size selection the patient selects, the patient may also select any health factors that the patient is currently experiencing, such as stress, activity, illness, steroids, and / or menstruation. MMA uses this information to calculate the recommended insulin dose based on the exemplary algorithm described above for the "Carbohydrate Based Meal Size Calculator" protocol.

[0325] return Fig.19 After collecting information from the patient in steps 1906, 1908, 1910, or 1912, the MMA branches to step 1914 where the MMA calculates and presents the recommended dose of insulin. The algorithm used to calculate the recommended dose of insulin varies depending on which dosing regimen is currently prescribed and implemented, and has been previously described. The MMA then presents the dose to the user, as shown in FIG. Fig.27A(in this example, it recommends a dose of 10 units of mealtime insulin). Fig.27A Click the "Edit Dose" button in the Dose Guide to give the patient the opportunity to edit the recommended dose.

[0326] At step 1916, the MMA determines whether the user has edited the recommended dose. If so, the MMA branches to step 1918 where it updates the presented dose. Fig.27B , where the patient can increase the recommended dose by clicking the "+" button to the right of the presented dose, or decrease the recommended dose by clicking the "-" button to the left of the presented dose. When the patient has finished editing the recommended dose, the patient can touch the "Save" button, which will return the patient to the Fig.27A If a daily titrated dosing regimen has been prescribed / implemented, the MMA may optionally display Fig.27C , which reminds the patient that it is important to check his or her blood sugar before the patient's next meal because the daily titration regimen uses this value to adjust tomorrow's insulin dosage.

[0327] If the patient has not edited the presented dose, the MMA branches to step 1920 where it determines whether the user has confirmed taking the dose. If not, the MMA branches back to step 1916. If so, the MMA proceeds to step 1922 where it logs the dose. Fig.27A and 27C This process is illustrated in , where the patient can confirm that they have taken the dose by touching a button labeled "I took this dose." Touching this button causes the MMA to record the presented dose in the patient's logbook.

[0328] Fig.28 An alternative user interface display 2800 is depicted that presents the dose of insulin to be administered to the patient, currently being administered to the patient, and / or recently administered to the patient. The dose of insulin may have been recommended by one of the insulin dosing regimens previously discussed, or may have been manually entered or adjusted by the patient. Figures 27A-27C In addition to the screenshots depicted in Figures 27A-27C In addition to the screenshots depicted in , the user interface display 2800 can be displayed on the MMA. Alternatively or in addition, the user interface display 2800 can be displayed on a drug delivery device, such as a visual screen mounted on an insulin pen.

[0329] The user interface display 2800 includes a plurality of panels. A panel may include data displayed by a processor on a portion of a visual display screen. A first panel 2802 displays the number of units of insulin to be administered to a patient, currently being administered to a patient, or recently administered to a patient—in the depicted example, the first panel 2802 shows 3.5 units of insulin.

[0330] The second panel 2804 shows the amount of carbohydrates expected to be covered by the number of insulins displayed by the first panel. As used in the specification and claims herein, the amount X of carbohydrates "expected to be covered by a certain number of units Y of insulin" will correspond to the estimated amount of carbohydrates, which, if ingested by a patient with diabetes, will need to be given Y units of insulin to keep the patient's glucose level after ingesting the amount of carbohydrates X the same as the patient's glucose level before ingesting the amount of carbohydrates X. In the depicted example, the second panel 2804 indicates that 28g of carbohydrates are expected to be covered by 3.5 units of insulin presented. The number of carbohydrates 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 ratio of insulin to carbohydrates (ICR). The user interface display 2800 can use a default ICR value that is applicable to all patients or to a patient-specific ICR provided by a patient, a caregiver, or an HCP. In some embodiments, if it is known that the ICR for a specific patient varies according to a predictable pattern according to the time of day, the ICR can be specific to both the patient and the time of day. In this example, if the user interface display 2800 uses an ICR of 0.125, the grams of carbohydrates (28 g) displayed by the second panel 2804 can be derived by dividing the number of units of insulin displayed by the first panel 2802 (3.5 units) by the ICR of 0.125.

[0331] The third panel 2806 indicates whether the amount of carbohydrates displayed in the second panel corresponds to a small meal size or a large meal size. Fig.28In the example depicted in , the third panel 2806 takes the form of a spectrum that displays a range of dietary amounts between a "small" dietary amount, a "medium" dietary amount, or a "large" dietary amount, and also includes an indicator 2810 that indicates where the number of carbohydrates displayed by the second panel 2804 falls on the spectrum. In other embodiments (not shown), the third panel 2806 can simply display letters, words, or symbols indicating dietary amount categories. In the simplest case, the meals can be simply classified into one of the following two categories: "small" or "large". In some embodiments, the meals can be classified into one of the following three categories: "small", "medium", or "large". In yet other embodiments, the meals can be classified into four or more dietary amount categories.

[0332] 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" meal (e.g., 30 g) and a maximum carbohydrate threshold for a "medium" meal (e.g., 60 g). Any carbohydrate value that falls between the minimum and maximum carbohydrate thresholds may be classified as a "medium" meal. Any carbohydrate value that falls below the minimum carbohydrate threshold may be classified as a "small" meal, and any carbohydrate value that falls above the maximum carbohydrate threshold may be classified as a "large" meal. (As in Fig.28 A panel including a spectrum showing a range of meal size definitions (as depicted in FIG. 1 ) may also determine where to place an indicator based on these meal size definitions (e.g., by scaling the placement of the indicator along the spectrum according to the meal size definitions). As previously discussed, these meal size definitions may be customizable by the patient, caregiver, or HCP.

[0333] The fourth panel 2808 shows the expected drop in the patient's glucose level caused by the administration of the number of units of insulin displayed by the first panel 2802. In the depicted example, the fourth panel 2808 indicates that a 75 mg / dL drop in blood glucose is expected to be caused by the administration of 3.5 units of insulin displayed in 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 in the first panel 2802 by the insulin sensitivity factor (ISF). The user interface display 2800 can use a default ISF that is applicable to all patients or to a patient-specific ISF provided by a patient, a caregiver, or an HCP. In some embodiments, if it is known that the ICR for a specific patient varies according to a predictable pattern according to the time of day, the ISF can be specific to both the patient and the time of day. In this example, if the ISF is 21.4, the expected BG drop (75 mg / dL) shown in the fourth panel 2808 can be derived by multiplying the number of units shown in the first panel 2802 (3.5 units) by the ISF of 21.4.

[0334] although Fig.28 A user interface display 2800 is shown that includes all four panels 2802, 2804, 2806, and 2808, but some embodiments may display only a subset of the 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. It is not necessary to press Fig.28 Arrange panels in the order, configuration, or relative size shown in the .

[0335] Regardless of which specific panels are displayed, all displayed panels may be updated when the user adjusts the number of units of insulin to be administered, currently being administered, or most recently administered. Fig.29A series of user interface displays are shown when 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 quantity 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 expected glucose drop in the fourth panel (see panels 2908a, 2908b, and 2908c) are automatically updated as the number of units of insulin changes.

[0336] although Fig.29 The example shown in shows an example in which the number of units of insulin is adjusted in increments of 0.5 units, but this need not be the case. In general, the granularity that can be used to adjust the number of units on the disclosed user interface can depend on the dose resolution of the delivery device associated with the user interface. For example, if a delivery device (such as an insulin pen) can deliver different doses in increments of 1.0 units, the user interface can also be configured to allow dose adjustments in increments of 1.0 units. If the delivery device can deliver different doses in increments of 2.0 units, the user interface can also be configured to allow adjustments in increments of 2.0 units. The same is true for the dose resolutions of other delivery devices, such as 0.1 units, 5.0 units, or any other dose resolution. Aligning the dose resolution of the user interface to the dose resolution of the delivery device of the patient allows the patient to easily decide how to set the dose on his or her delivery device. In some cases, the user interface can be designed to work with multiple types of delivery devices with different dose resolutions. In such an embodiment, the dose resolution on the user interface can be configured by the patient, caregiver, or HCP to meet the dose resolution on the delivery device of a specific patient.

[0337] Displaying the number of covered carbohydrates, a meal size indication, and / or an expected glucose drop at the same time as the number of units of insulin to be administered / currently being administered / most recently administered provides multiple benefits to the patient. Patients often administer insulin in order to cover a certain number of carbohydrates, cover a certain meal size, or reach a specific drop in glucose levels. By displaying some or all of this information to the patient, the patient can easily discern whether the displayed dosage will reach his or her goal, and can adjust the displayed dosage accordingly.

[0338] Simultaneously displaying this information also solves technical problems existing in previously known delivery device user interfaces by reducing over- or under-dosing caused by rounding errors. For example, when a patient attempts to calculate a dose to cover a particular meal, the patient often starts by guessing the number of carbohydrates in the meal before eating. Once the patient obtains an estimated number of carbohydrates, the patient then calculates the dose size based on the estimated number of carbohydrates. However, when calculating the dose size, patients often round to the nearest unit or half unit of insulin based on the dose resolution of their drug delivery device. This process requires the patient to undergo two rounding or estimation steps to obtain the dose of insulin: a first step, in which the patient estimates the number of carbohydrates in the meal; and a second step, in which the patient converts the carbohydrate estimate into the number of units of insulin. This two-step process increases the risk of overestimating or underestimating the dose required to cover a particular meal.

[0339] This is best illustrated using an exemplary scenario. Consider a situation where a patient estimates a meal with 75 grams of carbohydrates that he is about to consume. The patient obtains this estimate based only on the visual appearance of the meal and his 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 of his drug delivery device, he can only administer a whole unit of insulin, and therefore rounds down and administers only 9 units. In this case, if the patient underestimates the number of carbohydrates in the meal (e.g., if the meal in front of the patient actually contains 80g of carbohydrates), and then rounds down, the patient may underestimate the dose required to cover the meal in two ways. If not compensated for, this under-dosing of insulin can make it more difficult for the patient to reach his blood sugar goal.

[0340] By showing the quantity of carbohydrates to be covered and the number of units of insulin, the user interface shows the error introduced by rounding off is reduced.By dialing (dial) between 9 units and 10 units on the user interface, the patient can quickly determine that 9 units will cover 72 grams of carbohydrates, and 10 units will cover 80 grams of carbohydrates.The user can then estimate whether the meal in front of him is closer to 72 grams of carbohydrates or 80 grams of carbohydrates.Contrast with the situation of needing two calculations or estimation steps discussed previously, this calculation only involves a single, simple estimation step performed by the patient.This increases the chance that the patient will obtain the correct dosage to cover the meal in front of him.For example, in the face of the selection between 72 grams and 80 grams, the patient may more likely decide that the meal in front of him is actually closer to 80 grams, and may select to use 10 units of insulin.

[0341] The disclosed user interface may also reduce rounding errors in other scenarios as well, including situations where the patient makes dosing decisions based not on carbohydrates but on a target reduction in meal size and / or glucose level. By displaying the estimated reduction in meal size and / or glucose level along with the presented insulin dose, the disclosed user interface similarly reduces the number of estimation / rounding steps required of the patient and thus increases the chance that the patient will obtain the correct dose to cover a particular meal or to achieve a particular glucose level.

[0342] As discussed previously, instead of Figures 27A-27C Previously published screenshots in or in addition to Figures 27A-27C In addition to the previously disclosed screenshots in , the disclosed user interface 2800 can be displayed on an MMA executed on a mobile device. However, in addition, the disclosed user interface 2800 can also be displayed on a mobile drug delivery device such as a connected insulin pen. Fig.30 , which shows a connected insulin pen 3002 with a screen 3000 displaying the previously discussed user interface. Such a connected insulin pen 3002 can communicate wirelessly with a mobile device such as the mobile device 104 via a Bluetooth, WiFi, NFC, or other wireless link. Through the wireless link, the connected insulin pen 3002 can receive various parameters for calculating the information displayed by the panel in the user interface, such as the insulin to carbohydrate ratio (ICR), the insulin sensitivity factor (ISF), and / or meal size definitions, such as (as previously discussed) minimum and maximum carbohydrate thresholds for a "medium" meal.

[0343] Fig.31 A flow chart illustrating an exemplary process performed by a mobile device, such as a smart phone or a drug delivery device, is depicted. At step 3102, the mobile device simultaneously presents multiple panels via a visual display on the mobile device. These panels may include: a first panel that displays the number of units of insulin to be administered to the patient; a second panel that displays the number of carbohydrates expected to be covered by the number of units of insulin displayed by the first panel; a third panel that indicates whether the number of carbohydrates displayed by the second panel corresponds to a small meal, a medium meal, or a large meal; and / or a fourth panel that displays the expected drop in the patient's glucose level caused by the number of units of insulin displayed by the first panel. As previously discussed, some embodiments may not display all four panels, but only a subset of these panels. Some embodiments may also display additional panels.

[0344] At step 3104, the mobile device receives user input for adjusting 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. Fig.27B The user input may be received by a "plus" or "minus" button on a screen of an MMA similar to those discussed in , or by using a numeric keypad. Alternatively, the user input may be received by the user turning a knob on a connected insulin delivery device such as an insulin pen.

[0345] At 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 previously described, the adjustment can be accomplished using a parameter that converts the number of units of insulin to the number of covered carbohydrates (such as an insulin to carbohydrate ratio, or ICR), a parameter that converts the number of units of insulin to an expected drop in glucose levels (such as an insulin sensitivity factor, or ISF), or a parameter that converts the number of covered carbohydrates to a meal size.

[0346] Although the present invention has been described as having an exemplary design, the embodiments of the present disclosure may be further modified within the spirit and scope of the present disclosure. This application is therefore intended to cover any variations, uses or adaptations of the disclosed embodiments using its general principles.

Claims

1. A method comprising: presenting, via a healthcare professional (HCP) portal application, a plurality of medication dosing regimens associated with a patient, wherein each presented medication dosing regimen calculates a recommended medication dosage for the patient according to a respective different medication dosing algorithm, wherein each medication dosing regimen calculates the recommended medication dosage using a respective set of input parameters; receiving, via the HCP portal application, an HCP selection of at least one of the presented medication dosing regimens; as well as transmitting data of an HCP-selected regimen indicative of the at least one HCP-selected medication dosing regimen to a medical mobile application (MMA) on a mobile device associated with the patient, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA, and wherein the MMA is operable to access implementation data pre-stored on the mobile device for the at least one HCP-selected medication dosing regimen only after the at least one HCP-selected medication dosing regimen has been unlocked by the data of the HCP-selected regimen, wherein the MMA provides at least the following two access rights: general access, available for anyone to download, self-register, and use; and prescription access, which provides additional functionality unlocked by a medication dosing regimen selected by the at least one HCP.

2. The method according to claim 1, wherein: The presented medication dosing regimens include one or more insulin dosing regimens; and The at least one HCP-selected medication dosing regimen includes at least one HCP-selected insulin dosing regimen.

3. A method according to claim 2, wherein: The one or more presented insulin dosing regimens include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens.

4. The method of claim 2, wherein the at least one HCP-selected insulin dosing regimen comprises a daily titrated bolus insulin dosing regimen associated with a daily titrated bolus insulin dosing algorithm.

5. The method of claim 2, wherein the at least one HCP-selected insulin dosing regimen comprises a fixed-bolus insulin dosing regimen associated with a fixed-bolus insulin dosing algorithm.

6. The method of claim 2, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate bolus calculator bolus insulin dosing regimen associated with a carbohydrate bolus calculator bolus insulin dosing algorithm.

7. The method of claim 2, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate meal size-based calculator bolus insulin dosing regimen associated with a carbohydrate meal size-based calculator bolus insulin dosing algorithm.

8. The method of claim 1 , further comprising receiving a regimen accepted indication from the MMA, the regimen accepted indication indicating that the MMA has received a patient acceptance indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device.

9. The method of claim 1 , further comprising receiving a regimen rejected indication from the MMA, the regimen rejected indication indicating that the MMA has received a patient rejection indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device, and disabling the MMA on a mobile device associated with the patient in response to the patient rejection indication.

10. The method of claim 1, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA conditional on the MMA receiving a patient acceptance indication regarding the at least one HCP-selected medication dosing regimen.

11. The method of claim 1, wherein the MMA is configured to provide, via a mobile device user interface of a mobile device, a dosing recommendation based on the medication dosing regimen selected by the at least one HCP.

12. The method according to claim 1, further comprising: A plurality of panels are simultaneously presented on a visual display of the mobile device by the MMA, wherein the plurality of panels include: a first panel displaying the number of units of insulin to be administered to the patient, and a second panel showing the amount of carbohydrates expected to be covered by the unit number of insulin shown in the first panel; receiving, at the mobile device, a user input indicating a requested adjustment to the number of units of insulin displayed by the first panel; and Each of the plurality of panels is updated by the MMA based on the requested adjustment to the number of units of insulin displayed by the first panel, wherein the updating includes displaying the adjusted number of units of insulin by the first panel and displaying an adjusted amount of carbohydrates expected to be covered by the adjusted number of units of insulin using the second panel.

13. A connected care server system, comprising: One or more servers, each server including one or more communication interfaces, one or more processors and data storage, wherein the data storages of the one or more servers collectively contain instructions that, when executed by one or more of the processors of the one or more servers, are operable to cause the connected care server system to perform a set of server system functions, the set of server system functions comprising: presenting a plurality of medication dosing regimens associated with a patient via a healthcare professional (HCP) portal application in communication with at least one of the communication interfaces of the one or more servers, wherein each presented medication dosing regimen calculates a recommended medication dosage for the patient according to a respective different medication dosing algorithm, wherein each medication dosing regimen calculates the recommended medication dosage using a respective set of input parameters; receiving, via the HCP portal application, an HCP selection of at least one of the presented medication dosing regimens; and Transmitting data indicating an HCP-selected medication dosing regimen of at least one HCP-selected medication dosing regimen to a medical mobile application (MMA) on a mobile device associated with the patient via at least one of the communication interfaces of the one or more servers, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA, and wherein the MMA is operable to access implementation data pre-stored on the mobile device for the at least one HCP-selected medication dosing regimen only after the at least one HCP-selected medication dosing regimen has been unlocked by the data of the HCP-selected regimen, wherein the MMA provides at least the following two access rights: general access, which is available for anyone to download, self-register and use; and prescribed access, which provides additional functionality unlocked by the at least one HCP-selected medication dosing regimen.

14. A system according to claim 13, wherein: The presented medication dosing regimens include one or more insulin dosing regimens; and The at least one HCP-selected medication dosing regimen includes at least one HCP-selected insulin dosing regimen.

15. A system according to claim 14, wherein: The one or more presented insulin dosing regimens include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens.

16. The system of claim 14, wherein the at least one HCP-selected insulin dosing regimen comprises a daily titrated bolus insulin dosing regimen associated with a daily titrated bolus insulin dosing algorithm.

17. The system of claim 14, wherein the at least one HCP-selected insulin dosing regimen comprises a fixed-bolus insulin dosing regimen associated with a fixed-bolus insulin dosing algorithm.

18. The system of claim 14, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate bolus calculator bolus insulin dosing regimen associated with a carbohydrate bolus calculator bolus insulin dosing algorithm.

19. The system of claim 14, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate meal size-based calculator bolus insulin dosing regimen associated with a carbohydrate meal size-based calculator bolus insulin dosing algorithm.

20. A system according to claim 13, the set of server system functions further includes receiving a regimen acceptance indication from the MMA, the regimen acceptance indication indicating that the MMA has received a patient acceptance indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device.

21. The system of claim 13, wherein the set of server system functions further comprises receiving a regimen rejection indication from the MMA, the regimen rejection indication indicating that the MMA has received a patient rejection indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device, and disabling the MMA on a mobile device associated with the patient in response to the regimen rejection indication.

22. A system according to claim 13, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA conditional on the MMA receiving a patient acceptance indication regarding the at least one HCP-selected medication dosing regimen.

23. The system of claim 13, wherein the MMA is configured to provide, via a mobile device user interface of a mobile device, a dosing recommendation based on the medication dosing regimen selected by the at least one HCP.

24. One or more non-transitory computer readable media (CRM) having stored thereon instructions that, when executed by one or more processors, are operable to cause the one or more processors to perform a set of functions, the set of functions comprising: presenting, via the HCP portal application, a plurality of medication dosing regimens associated with the patient, wherein each presented medication dosing regimen calculates a recommended medication dosage for the patient according to a respective different medication dosing algorithm, wherein each medication dosing regimen calculates the recommended medication dosage using a respective set of input parameters; receiving, via the HCP portal application, an HCP selection of at least one of the presented medication dosing regimens; as well as transmitting data of an HCP-selected regimen indicative of the at least one HCP-selected medication dosing regimen to a medical mobile application (MMA) on a mobile device associated with the patient, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA, and wherein the MMA is operable to access implementation data pre-stored on the mobile device for the at least one HCP-selected medication dosing regimen only after the at least one HCP-selected medication dosing regimen has been unlocked by the data of the HCP-selected regimen, wherein the MMA provides at least the following two access rights: general access, available for anyone to download, self-register, and use; and prescription access, which provides additional functionality unlocked by a medication dosing regimen selected by the at least one HCP.

25. The CRM of claim 24, wherein: The presented medication dosing regimens include one or more insulin dosing regimens; and The at least one HCP-selected medication dosing regimen includes at least one HCP-selected insulin dosing regimen.

26. The CRM of claim 25, wherein: The one or more presented insulin dosing regimens include at least one or more basal insulin dosing regimens and one or more bolus insulin dosing regimens.

27. The CRM of claim 25, wherein the at least one HCP-selected insulin dosing regimen comprises a daily titrated bolus insulin dosing regimen associated with a daily titrated bolus insulin dosing algorithm.

28. The CRM of claim 25, wherein the at least one HCP-selected insulin dosing regimen comprises a fixed-bolus insulin dosing regimen associated with a fixed-bolus insulin dosing algorithm.

29. The CRM of claim 25, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate bolus calculator bolus insulin dosing regimen associated with a carbohydrate bolus calculator bolus insulin dosing algorithm.

30. The CRM of claim 25, wherein the at least one HCP-selected insulin dosing regimen comprises a carbohydrate meal size based calculator bolus insulin dosing regimen associated with a carbohydrate meal size based calculator bolus insulin dosing algorithm.

31. The CRM of claim 24, wherein the set of functions further comprises receiving a regimen acceptance indication from the MMA, the regimen acceptance indication indicating that the MMA has received a patient acceptance indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device.

32. According to the CRM of claim 24, the set of functions further includes receiving a regimen rejection indication from the MMA, the regimen rejection indication indicating that the MMA has received a patient rejection indication associated with the at least one HCP-selected medication dosing regimen via a mobile device user interface of a mobile device, and disabling the MMA on the mobile device associated with the patient in response to the patient rejection indication.

33. A CRM according to claim 24, wherein the data of the HCP-selected regimen is operable to unlock the at least one HCP-selected medication dosing regimen on the MMA conditional on the MMA receiving a patient acceptance indication regarding the at least one HCP-selected medication dosing regimen.

34. The CRM of claim 24, wherein the MMA is configured to provide, via a mobile device user interface of a mobile device, a dosing recommendation based on a medication dosing regimen selected by the at least one HCP.

Images