Extracted from wipo site
SYSTEMS AND METHODS FOR
REMOTE PRESCRIPTION OF MEDICATION-DOSING REGIMENS
FIELD OF INVENTION
[0001] The present disclosure relates to medical devices and medical -information systems, and in particular to systems and methods for remote prescription of medication-dosing regimens.
BACKGROUND
[0002] There are myriad diseases and other medical conditions for which patients receive medical treatment. Quite often this treatment involves one or more dosing regimens of one or more medications.
OVERVIEW
[0003] Disclosed herein are systems and methods for remote prescription of medication dosing regimens. The present systems and methods are applicable to numerous types of medications for numerous types of diseases and other medical conditions. Patients are treated for these medical conditions by what are referred to in this disclosure as healthcare professionals (HCPs). As used herein, HCPs includes both people and/or entities that directly provide medical care to patients (e.g., doctors, nurses, nurse practitioners, physician assistants (PAs), and the like) as well as people and/or entities that do not directly provide medical care to patients but which indirectly support the provision of health-care to patients (e.g., administrative personnel, database-management personnel, other information-technology personnel, insurance and/or other payment-related personnel, and the like). In situations described herein in which an HCP prescribes a medication-dosing regimen and/or other treatment for which a prescription is required, that HCP is assumed to have the proper education, training, certification, licensing, and/or the like that would be required to issue such prescriptions. Examples of medications governed by said medication dosing regimens include one or more therapeutic agents including but not limited to insulins, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agent that is capable of delivery by a medication delivery device, or that may be taken by a patient without the aid of a medication delivery device (e.g., orally or through application to the patient’s skin). The medications may be formulated with one or more excipients.
[0004] One example area of applicability of the present systems and methods is diabetes (also referred to at times as diabetes mellitus), which is a general term for a group of metabolic disorders that are generally characterized by elevated levels of glucose (e.g., blood glucose, or blood sugar) in the human body for sustained periods of time. As is known in the art and in the medical community, another term for elevated glucose levels is hyperglycemia, which is typically defined as a glucose level of greater than 180 milligrams (mg) per deciliter (dL) (mg/dL), a threshold that is also expressible as the quantity 10 millimoles (mmol) per liter (L) (mmol/L). The converse condition (i.e., an insufficient level of glucose) is known as hypoglycemia, which is typically 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-l diabetes and type-2 diabetes, each of which is related in a different way to insulin, which is a hormone that is central to the body’s metabolic processing of glucose into energy that is either immediately used or stored for later use. Type-l diabetes is generally considered an autoimmune disease in which the patient’s immune system mistakenly attacks insulin-producing“beta cells” in the pancreas. Type-2 diabetes is generally characterized by the pancreas failing to produce enough insulin for the body’s needs, or the patient’s body losing its ability to respond to insulin.
[0006] Among the treatments for type-l and/or type-2 diabetes is the subcutaneous injection of synthetic insulin. As a general matter, synthetic insulins are classified according to a number of dimensions including onset (i.e., how quickly they typically take effect), peak (i.e., how much time typically elapses until maximum efficacy is achieved), duration (i.e., the amount of time that the effect typically lasts), and concentration. The typical manner of expression for concentration is in units per milliliter (mL); as an example, a concentration of 100 units per mL would typically be expressed as U 100.
[0007] In cases of type-l and/or type-2 diabetes, there are two main categories of synthetic insulin that are typically prescribed by HCPs, typically for subcutaneous injection: basal insulin and bolus insulin. Basal insulin is also known by a number of other terms such as background insulin and long-acting insulin, and is generally taken by diabetes patients once or twice daily at regular intervals and in consistent dosages for the purpose of maintaining a certain baseline level of insulin in the patient during times such as fasting, sleeping, being in between meals, and the like. Bolus insulin also has a number of names by which it is known, including prandial insulin, mealtime insulin, and rapid-acting insulin, and is generally taken by diabetes patients on more of an as-needed basis, most typically at mealtimes, for the purpose of handling the glucose-level spikes that are typical of meal times but that can occur at other times as well.
[0008] Though certainly applicable to numerous types of medications for numerous types of diseases, conditions, and the like, the present methods and systems are intended at least in part to assist HCPs and patients with type-l or type-2 diabetes in the management of (sometimes intensive) basal-insulin and/or bolus-insulin regimens. Indeed, although some of the examples in this disclosure generally relate to prescription and implementation of bolus-insulin dosing regimens for cases of diabetes, it should be understood that this is by way of illustration and not limitation, and is in no way to the exclusion of the present systems and methods pertaining to dosing regimens for other types of insulin (e.g., basal-insulin) and/or for other types of diseases. In general and as stated above, it should be understood that the present systems and methods are applicable to a wide variety of dosing regimens for a wide variety of diseases, conditions, and the like.
[0009] It is recognized by the inventors of the present systems and methods that managing the complexity of insulin therapy can be challenging, especially on the patient side, but also on the HCP side. The present systems and methods address a number of technical problems with the prior art, including the technical problem that prior medical-device and medical-technology implementations in general do not provide a mechanism by which an HCP can select and even customize at least one medication-dosing regimen (e.g., a bolus-insulin-dosing regimen) out of a plurality of pre-determined and pre-programmed dosing regimens for a particular patient and then further prescribe that at least one regimen to that patient over a data network by interacting remotely with an application running on a mobile device associated with the patient. In accordance with some embodiments of the present systems and methods, logic for the plurality of pre determined and pre-programmed dosing regimens can be provided with the application running on the patient’s mobile device, but may be initially locked so as to be inaccessible to the patient. Further in accordance with some embodiments, the HCP can remotely unlock at least one particular HCP-selected regimen out of the plurality of pre-programmed dosing regimens for that patient on that mobile device, which then can provide instructions to the patient for implementing the at least one regimen, and in some cases direct one or more additional medical devices (that is or are also associated with the patient) to carry out some or all of the at least one HCP-selected dosing regimen. The present systems and methods represent a technical solution to at least that technical problem. And it is respectfully noted that this paragraph in no way implies that other technical solutions to other technical problems are not represented by this disclosure.
[0010] One embodiment takes the form of a method that includes presenting, via an HCP-portal application executing on an HCP system, multiple medication-dosing regimens pertaining to a patient. Each presented medication-dosing regimen is associated with a respective 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, to a medical mobile application (MMA) on a mobile device associated with the patient, HCP-selected-regimen data indicative of the at least one HCP-selected medication-dosing regimen.
[0011] Another embodiment takes the form of a connected-care server system that includes one or more servers that each include one or more communication interfaces, one or more processors, and data storage. In at least some embodiments, the connected-care server system is a connected-care-cloud (C3) server system, and each of the one or more servers are cloud-servers. The data storage of the one or more servers collectively contains instructions executable by one or more of the processors of the one or more servers for causing the connected-care server system to carry out a set of server-system functions that includes the functions that are listed in the preceding paragraph. Yet another embodiment takes the form of 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 carry out a set of functions that includes the functions that are listed in the preceding paragraph. In connection with any embodiment, a CRM could take the form of any non-transitory data-storage medium mentioned herein and/or any other non-transitory data-storage medium deemed suitable by those of skill in
the art for a given implementation. Examples include any suitable forms 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 that includes receiving, at an MMA that is executing on a mobile device that is associated with a patient, HCP-selected-regimen data that is indicative of an HCP selection of an HCP-selected medication-dosing regimen from among a plurality of medication-dosing regimens, each of which is associated with a respective different medication-dosing algorithm. The HCP selection had been made for the patient by the HCP via an HCP-portal application that is executing on a HCP system. The method also includes unlocking the indicated HCP-selected medication-dosing regimen on the MMA responsive at least in part to having received the HCP-selected-regimen data.
[0013] Another embodiment takes the form of a mobile device that is associated with a patient. The mobile device includes a mobile-device communication interface, a mobile-device processor, and mobile-device data storage. The mobile-device data storage contains instructions executable by the mobile-device processor for causing the mobile device to execute an MMA for carrying out a set of MMA functions that includes the functions that are listed in the preceding paragraph. Yet another embodiment takes the form of one or more non-transitory CRMs having stored thereon instructions that, when executed by one or more processors, are operable to cause the one or more processors to carry out a set of functions that includes the functions that are listed in the preceding paragraphs.
[0014] Another embodiment takes the form of a system that includes the above-described connected-care server system and the above-described mobile device. At least one embodiment further includes the above-described HCP system.
[0015] Another embodiment takes the form of a method comprising: presenting, by a processor on a mobile device associated with a patient, a plurality of panels simultaneously on a visual display of the mobile device, wherein the plurality of panels comprise: a first panel that displays a number of units of insulin to be administered to the patient, and a second panel that displays an amount of carbohydrates expected to be covered by the number of units of insulin displayed by the first panel; receiving at the mobile device user input representative of a requested adjustment to the number of units of insulin displayed by the first panel; and updating, by the processor, each panel of the plurality of panels according to the requested adjustment to the number of units of insulin displayed by the first panel, wherein the updating includes displaying an adjusted number of units of insulin by the first panel and an adjusted amount of carbohydrates expected to be covered by the adjusted number of units of insulin with the second panel.
[0016] In some embodiments, the plurality of panels may further comprise a panel that displays an indication of a meal size corresponding to the amount of carbohydrates displayed by the second panel, and wherein the updating 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 comprise a panel that displays a spectrum that displays a range of meal sizes between a small meal size and a large meal size, and an indicator that indicates where the amount of carbohydrates displayed by the second panel falls on the spectrum. Alternatively, or in addition, the plurality of panels may further comprise a panel that 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. Alternatively, or in addition, the plurality of panels may further comprise a panel that displays a drop in the patient’s glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and wherein the
updating includes displaying an adjusted drop in the patient’s glucose level that is expected to result from administration of the adjusted number of units of insulin.
[0017] In some embodiments, the method may further comprise receiving at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, wherein one of the plurality of panels indicates whether the number 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 minimum carbohydrate threshold. The method may also further comprise receiving at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, 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 also further comprise receiving at the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the drop in the patient’s glucose level displayed by one of the plurality of panels is calculated based on the number of units of insulin displayed by the first panel and the received ISF.
[0018] A number of variations and permutations of the above-listed embodiments are described herein. Moreover, it is expressly noted that any variation or permutation that is described in this disclosure can be implemented with respect to any type of embodiment. For example, a variation or permutation that is primarily described in connection with a method embodiment could just as well be implemented in connection with a system embodiment and/or a CRM embodiment. Furthermore, this flexibility and cross-applicability of embodiments is present in spite of any slightly different language (e.g., process, method, steps, functions, set of functions, and the like) that is used to describe and/or characterize such embodiments.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] A more detailed understanding may be had from the following description, which is presented by way of example in conjunction with the following drawings, in which like reference numerals are used across the drawings in connection with like elements.
[0020] FIG. 1 depicts an example communication context 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 that are also associated with the example patient, an example server system that includes one or more example servers (e.g., connected-care cloud servers) that are communicatively interconnected with one another via an example network, and an example administrator-portal system, in accordance with at least one embodiment.
[0021] FIG. 2 depicts an example physical architecture of the example HCP system of FIG. 1, in accordance with at least one embodiment.
[0022] FIG. 3 depicts an example physical architecture of the example mobile device of FIG. 1, in accordance with at least one embodiment.
[0023] FIG. 4A depicts an example physical architecture of an example one of the servers in the example server system of FIG. 1, in accordance with at least one embodiment.
[0024] FIG. 4B depicts an example physical architecture of the example administrator-portal system of FIG. 1, in accordance with at least one embodiment.
[0025] FIG. 5 depicts an example functional architecture of the example server system of FIG. 1, in accordance with at least one embodiment.
[0026] FIG. 6 depicts various entities in an example communication-and-processing ecosystem, in accordance with at least one embodiment.
[0027] FIG. 7 depicts a first example method, which may be carried out by the server system of FIG. 1, in accordance with at least one embodiment.
[0028] FIG. 8 depicts a second example method, which may be carried out by the mobile device of FIG. 1 executing an example MMA, in accordance with at least one embodiment.
[0029] FIGS. 9 through 18 depict various example screenshots for display via the example HCP system of FIG. 1, in accordance with at least one embodiment.
[0030] FIG. 19 depicts a flowchart illustrating an exemplary process for calculating, presenting, and editing a recommended dose of insulin implemented by a MMA, in accordance with at least one embodiment.
[0031] FIG. 20 depicts an exemplary screenshot from a MMA in which the MMA automatically synchronizes with a patient’s glucose sensor, in accordance with at least one embodiment.
[0032] FIGS. 21 A, 21B, and 21C depict exemplary screenshots from a MMA in which the MMA receives a patient’s glucose level, in accordance with at least one embodiment.
[0033] FIGS. 22A, 22B, 22C, and 22D depict exemplary screenshots from a MMA used by the MMA for a daily titration dosing regimen, in accordance with at least one embodiment.
[0034] FIGS. 23 A, 23B, 23C, and 23D depict exemplary screenshots from a MMA used by the MMA for a fixed-dose dosing regimen, in accordance with at least one embodiment.
[0035] FIGS. 24A, 24B, 24C, and 24D depict exemplary screenshots from a MMA used by the MMA to receive a number of carbohydrates for a carb bolus calculator dosing regimen, in accordance with at least one embodiment.
[0036] FIGS. 25A, 25B, 25C, and 25D depict exemplary screenshots from a MMA used by the MMA to receive a number of units of mealtime insulin for a carb bolus calculator dosing regimen, in accordance with at least one embodiment.
[0037] FIGS. 26A, 26B, 26C, and 26D depict exemplary screenshots from a MMA used by the MMA for a carb meal-size-based calculator dosing regimen, in accordance with at least one embodiment.
[0038] FIGS 27 A, 27B, and 27C depict exemplary screenshots from a 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 depicts an exemplary user-interface display having four panels of information related to a presented insulin dose, in accordance with at least one embodiment.
[0040] FIG. 29 depicts an exemplary sequence of user-interface displays that show how the four panels of information update as the presented insulin dose is adjusted, in accordance with at least one embodiment.
[0041] FIG. 30 depicts an example embodiment in which the user-interface of FIGS. 28 and 29 is displayed on a connected drug-delivery device, in accordance with at least one embodiment.
[0042] FIG. 31 depicts a flow-chart illustrating an exemplary process executed by a mobile device to display and update the user-interface of FIGS. 28, 29, and 30, in accordance with at least one embodiment.
[0043] For the purposes of promoting an understanding of the principles of the present disclosure, reference is made below to the embodiments illustrated in the drawings, which are described below. The embodiments disclosed herein are not intended to be exhaustive or to limit the present disclosure to the precise form disclosed in the following detailed description. Rather, the embodiments are chosen and described so that others skilled in the art may utilize their teachings. Therefore, no limitation of the scope of the present disclosure is thereby intended.
[0044] In some instances throughout this disclosure and in the claims, numeric modifiers such as first, second, third, and fourth are used in reference to various components, data such as various identifiers, and/or other elements. Such use is not intended to denote or dictate a specific or required order of the elements. Rather, this numeric terminology is used to assist the reader in identifying the element that is being referenced and in distinguishing that element from other elements, and should not be narrowly interpreted as insisting upon any particular order.
[0045] Moreover, before proceeding with this detailed description, it is noted that the entities, arrangements, and the like that are depicted in— and described in connection with— the various drawings are presented by way of example and not by way of limitation. As such, any and all statements or other indications as to what a particular drawing“depicts,” what a particular element or entity in a particular drawing“is” or“has,” and any and all similar statements— that could in isolation and out of context be read as absolute and therefore limiting— can only properly be read as being constructively (unless actually) preceded by a clause such as “In at least one embodiment, . . . ” And it is for reasons akin to brevity and clarity of presentation that this implied leading clause is not repeated ad nauseum in this detailed description.
DETAILED DESCRIPTION OF THE DRAWINGS
I. Example Architecture
A. Example Communication Context
[0046] FIG. 1 depicts an example communication context 100 that includes 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 multiple example personal medical devices (in
this depiction, an example glucose meter 126 and an example connected injection device 134) that are also associated with the example patient 124, an example server system 106 that includes one or more example servers 140-146 that are communicatively interconnected with one another via an example private network 138, and an example administrator-portal system 148, in accordance with at least one embodiment. Also depicted in FIG. 1 are a data network 108, communication links 110, 112, 114, 116, 128, 136, 150, 152, and 154; a display 120 of the HCP system 102; and a display 122 of the mobile device 104. Further displayed are an association arrow 125, a conceptual-information-flow arrow 130, and a conceptual-information-flow arrow 132, both of which are described below. It should be understood that the entities and the arrangement and interconnection thereof that are depicted in FIG. 1 are provided for illustration and by way of example and not limitation, and that other entities, arrangements, and interconnections could be implemented as well as deemed suitable by those of skill in the art for a given context.
[0047] The HCP system 102 (including the display 120) is described from a physical-architecture standpoint more fully below in connection with FIG. 2, but in general could take the form of any computing device that is equipped, configured, and programmed to carry out 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, 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, perhaps as a capability of another application, to name but a few examples). As depicted in FIG. 1, the HCP system 102 is communicatively connected to the health IT system 118 via the communication link 116 and to the data network 108 via the communication link 110. Although communication link 116 is
depicted as being separate from data network 108, it should be understood that in some instances, all or part of link 116 may traverse at least a portion of data network 108. In some instances, the HCP system 102 may communicate with HIT system 118 indirectly via the data network 108, instead of through a direct link 116 as depicted in FIG. 1. Among the typical users of the HCP system 102 are HCPs with prescribing roles (e.g., doctors, physician assistants (PAs), nurse practitioners, and the like), as well as non-prescribing HCPs who are part of a care team, and users associated with integrated delivery networks (IDNs), among other examples.
[0048] In various different embodiments, the HCP system 102 provides and supports functions such as prescribing medication-dosing regimens (e.g., insulin-dosing regimens such as basal-insulin-dosing regimens, bolus-insulin-dosing regimens, and/or the like), modifying existing dosing-regimen prescriptions, setting and/or modifying dosing-regimen parameters, and viewing individual patient data, among other examples that could be listed here. The prescription and parameter-setting with respect to dosing regimens by an HCP via the HCP system 102 assists patients in determining medication doses. Among other functions, the HCP system 102 provides the HCP with the capability to download patient EHR data from the health IT system 118 via the communication link 116 and view the EHR data in the HCP portal, view a selection of available medication-dosing regimens, select a dosing regimen to prescribe to the patient, and assign values to required parameters for the selected dosing regimen (such as starting dose, insulin-to-carb ratio, and the like, in the example case of an insulin-dosing regimen). The HCP system 102 further provides data-visualization features that enable the HCP users to review patient historical data. In various embodiments, this patient historical data is viewable in chart form, graphical form, tabular form, and/or one or more other forms deemed suitable by those of skill in the art for a given implementation.
[0049] The mobile device 104 (including the display 122) is described from a physical-architecture standpoint more fully below in connection with FIG. 3, but in general could take the form of any computing device that is equipped, configured, and programmed to carry out 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, and the like. As depicted in FIG. 1, the mobile device 104 is communicatively connected to the glucose meter 126 via the communication link 128, to the connected injection device 134 via the communication link 136, and to the data network 108 via the communication link 112. As is depicted by the double-ended-and-dashed association arrow 125, the mobile device 104 is associated— e.g., by a subscription account, ownership, possession, and/or in one or more other ways— with the patient 124.
[0050] With respect to the C3 -server system 106, an example one of the C3 servers 140-146 is described from a physical-architecture standpoint more fully below in connection with FIG. 4A. Moreover, the C3 -server system 106 as a whole is described from a functional-architecture (e.g., software-architecture) perspective more fully below in connection with FIG. 5. In general, however, the C3 -server system 106 could take the form of any set of one or more servers that are collectively equipped, configured, and programmed to collectively carry out the C3 -server-system functions described herein. As depicted in FIG. 1, the C3-server system 106 is communicatively connected to the data network 108 via the communication link 114.
[0051] It is noted that, as depicted in FIG. 1, each respective C3 server 140-146 in the C3-server system 106 could have its own respective communication link 114 with the data network 108; also or instead, a single communication link 114 could 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, the one or more communication links 114 are referred to as“the communication link 114” in the balance of this disclosure. Moreover, as is also depicted in FIG. 1, the respective C3 servers 140-146 are communicatively interconnected with one another via a private network 138, which could take the form of or include a local area network (LAN), a virtual private network (VPN), and/or one or more other options deemed suitable by those of skill in the art for a given implementation. In some embodiments, the depicted network 138 would not exist as a separate network as currently depicted— in such embodiments, the respective C3 servers 140-146 communicate with one another via their links to data network 108. The communicative connectivity between the C3 -server system 106 and the administrator-portal system 148 is discussed below.
[0052] As a general matter, the C3-server system 106 functions as“the 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 in particular to one or more applications such as one or more MMAs executing on the mobile device 104). In some embodiments, a subset of 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. In some embodiments, however, each of the C3 servers 140-146 may be capable of serving any of these three entities. Regardless of the specific architectural implementation, the C3 -server system 106 functions as at least one cloud with particular purposes for those entities. As such, in at least one embodiment, all communication to and from the C3 -server system 106 with any one or more other entities is secure communication— as examples, such communication could be encrypted and/or signed as is known in the art. Such communication could be inside a tunnel such as a VPN, among other communication- security and data-security options that could be implemented as deemed suitable by those of skill in the art in various contexts.
[0053] In various different embodiments, and as is further described below, the C3 -server system 106 provides and supports functions— for the mentioned entities and perhaps others— such as secure and reliable transfer of information and data (related to, e.g., prescriptions) between the HCP system 102 and MMAs running on mobile devices associated with patients, data storage, management of relationships between patients and HCPs, IDNs, and the like, and in some embodiments, instead or in addition, provides and supports one or more other functions deemed suitable by those of skill in the art for a given implementation. Moreover, in some embodiments, the C3-server system 106 facilitates data sharing that involves payers (e.g., insurance companies); in some such embodiments, such data sharing with payer entities is conditional upon the associated patients opting in to allow such communication. And other examples of provided and supported functions could be listed here as well.
[0054] The administrator-portal system 148 is described from a physical-architecture standpoint more fully below in connection with FIG. 4B, but in general could take the form of any computing device that is equipped, configured, and programmed to carry out the administrator-portal-system functions described herein. Some options for the administrator-portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. As depicted in FIG. 1, the administrator-portal system 148 in at least one embodiment is operable to communicate with the C3 -server system 106 (and in particular in the depicted example via the private network 138) via the communication link 150. In other embodiments, as is also depicted in FIG. 1, the administrator-portal system 148 is operable to communicate with the HCP system
102, the mobile device 104, and/or the C3-server system 106 via the data network 108. And in some embodiments, the administrator-portal system 148 is operable to do both.
[0055] As a general matter, in various different embodiments, the administrator-portal system 148 provides various services with respect to the HCP -portal 102, an MMA executing on the mobile device 104, and/or the C3-server system 106. One example category of such services are those that pertain to user management, login, access level, 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, an MMA executing 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 Integrated Delivery Network (IDN) (e.g., a network of health care organizations) may be provided with an administrator-portal system 148 that governs accounts of patients enrolled in the IDN. In some embodiments, the administrator-portal system 148 is operable to roll 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 certainly numerous other example administrative functions for which the administrator-portal system 148 could be used could be listed here.
[0056] In the example situation that is depicted in FIG. 1, the data network 108 is communicatively connected with the HCP system 102 via the communication link 110, with the mobile device 104 via the communication link 112, with the C3-server system 106 via the communication link 114, and with the administrator-portal system 148 via the communication link 152. In at least one example scenario, the data network 108 includes one or more Internet Protocol (IP) networks such as the worldwide network of networks typically referred to broadly as the Internet, one or more public IP networks, one or more private (e.g., corporate) IP networks, and/or one or more IP networks of any other type deemed suitable by those of skill in the art for a given implementation. Entities that communicate 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). It is not required that the data network 108 be or include an IP network, however, as this is merely an example.
[0057] 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 in particular may include at least one wireless-communication link to facilitate two-way data communication with the mobile device 104. Moreover, either or both of the communication links 128 and 136 may take the form of or at least include at least one of a near-field communication (NFC) link, a Bluetooth link, a radio-frequency identification (RFID) link, a direct radio frequency (RF) link, and/or one or more other types of wireless-communication links. Moreover, the communication links 128 and 136 could but need not be point-to-point links between (i) the mobile device 104 and (ii) the glucose meter 126 and connected injection device 134, respectively: in some embodiments, one or both of the communication links 128 and 136 are an indirect link via, e.g., a Wi-Fi or ZigBee router, or a cellular network or tower (not depicted). And other implementation examples could certainly be listed here as well.
[0058] In the example scenario that is depicted in FIG. 1, the health IT system 118 is communicatively connected to the HCP system 102 via the communication link 116, and in general could 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, touchscreen, or other user interface. In various different embodiments, the health IT system 118 optionally provides and supports secure maintenance of, secure storage of, and secure access to patient Electronic Health Records (EHRs - also referred to as Electronic Medical Records or EMRs in the industry), perhaps among other functions deemed suitable for a health IT system by those of skill in the art. Moreover, health IT system 118 is communicatively coupled to data network 108 via communication link 154. Health IT system 1 18 may also communicate with C3 -server system 106 via data network 108. In some embodiments, the health IT system 118 interfaces with the C3-server system 106 and/or HCP system 102 via a standardized protocol, such as the Fast Healthcare Interoperability Resources (FHIR) protocol, or the Substitutable Medical Applications and Reusable Technologies (SMART) protocol, as examples.
[0059] In the example scenarios described herein, the patient 124 has been diagnosed and is being treated by an HCP— that is associated with the HCP system 102— with diabetes, though this is purely by way of example and not limitation. In the described embodiments, both 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 in at least that way with one another. The above-mentioned association arrow 125 is intended to represent a general association and a user-interface-level interaction of the patient 124 with the mobile device 104.
[0060] It is further noted that while FIG. 1 shows mobile device 104 being connected to both glucose meter 126 and connected injection device 134, in some cases, only one of the glucose meter 126 and the connected injection device 134 may be present in various different scenarios, and that both are not required. Indeed, some scenarios involve no additional medical devices connected to mobile device 104 at all, such as is the case with systems that require patients to separately and manually measure glucose levels and/or log dosage information, or as is the case with medication that is taken by mouth and where no devices are required to monitor or otherwise test one or more levels, conditions, or other parameters of the patient 124. In some cases, a patient may connect more than one glucose meter, and/or more than one connected injection device, to the MMA - for example, a patient may have one glucose meter and/or injection device at home, and one glucose meter and/or injection device at work. The MMA may be configured to support multiple connections of each. Moreover, in some cases, one or more connected medical devices other than a glucose meter and/or a connected injection device are present. Some examples include a blood-pressure monitor, a pulse/oxygen monitor, and/or the like. And certainly many other examples could be listed here.
[0061] The glucose meter 126 is associated with the patient 124 for medical, diabetes-treatment purposes, and is communicatively connected with the mobile device 104 via the above-described communication link 128. The glucose meter 126 could include a blood-glucose meter (BGM), a continuous glucose meter (CGM), a flash glucose monitor (FGM), or other devices that measure the patient 124’ s blood glucose or other sources of glucose levels (e.g., contact lens devices, or devices that use near IR radiation to measure glucose levels). A BGM takes discrete spot measurements of the patient’s blood-glucose level (e.g., by pricking the patient’s finger to conduct spot measurements of the patient’s capillary whole blood glucose level). Both CGM and FGM use sensors to measure interstitial glucose. A CGM system may include a sensor, transmitter and receiver/app. A CGM may take more frequent (i.e., more continuous) measurements of the patient’s interstitial glucose levels, and may optionally be continuously worn by the patient for relatively extended periods of time (e.g., several hours or days at a time). One example of such a CGM is the G6 sensor manufactured by Dexcom, Inc. A FGM system may comprise a sensor worn
on or inserted into a portion of the patient’s body, and a reader (e.g., a handheld reader) that, when activated or when placed in close proximity to the sensor, receives a glucose level reading from the sensor. One example of such a FGM is the FreeStyle Libre device, manufactured by Abbott Diabetes Care Inc. In some embodiments, a FGM does not require finger-stick calibration. And certainly one or more other types of glucose meters could be included as well.
[0062] CGM and FGM systems may measure interstitial glucose levels, while BGM systems may measure blood glucose levels. For simplicity and readability, the balance of this disclosure refers simply to a“glucose” level, or“GL.” It is understood that such references may refer to either blood glucose or interstitial glucose, as appropriate.
[0063] The connected injection device 134 is also associated with the patient 124 for medical, diabetes-treatment purposes, and is communicatively connected with the mobile device 104 via the above-described communication link 136. Device 134 may further comprise a drug or medication. In some embodiments, a system may comprise one or more devices including device 134 and a drug or medication. The term“drug” or“medication” refers to one or more therapeutic agents including but not limited to insulins, insulin analogs such as insulin lispro or insulin glargine, insulin derivatives, glucagon, glucagon analogs, glucagon derivatives, and any therapeutic agent that is capable of delivery by the above device. The drug or medication as used in the device 134 may be formulated with one or more excipients. The device is operated in a manner generally as described herein by a patient, caregiver or healthcare professional to deliver the drug to a person.
[0064] In at least one embodiment, the connected injection device 134 is or at least includes what is referred to at times in the art as a connected insulin-delivery device (e.g., a connected insulin pen, such as a pen having integrated and/or attachable electronics to auto-detect and report to another electronic device an amount of injected insulin). In various different embodiments, the connected injection device 134 takes the form of or includes one or more of the insulin-delivery devices described in any of the following patent applications, each of which is hereby incorporated herein by reference in its respective entirety:
• PCT Application No. PCT/US 17/65251 filed December 8, 2017 and entitled Medication Delivery Device with Sensing System (Attorney Docket No. X21353);
• PCT Application No. PCT/US18/19156 filed February 22, 2018 and entitled Dose Detection and Drug Identification for a Medication Delivery Device (Attorney Docket No. X21457); and
• U.S. Provisional Patent Application No. 62/552,659 filed August 31, 2017 and entitled Dose Detection with Piezoelectric Sensing for a Medication Delivery Device (Attorney Docket No. P21462).
[0065] Moreover, in some cases, one or more of the capabilities of one of those two devices in this disclosure are also or instead covered by the other of those two devices and/or by one or more additional devices. In one example, a single device can both monitor glucose (and report back results) and inject insulin (and report back injected amounts). And certainly other combinations of capabilities could be listed here.
[0066] Furthermore, and as also described below, in some embodiments, an MMA executing on the mobile device 104 communicates for various reasons (e.g., sending dosing commands, receiving dosed-amount confirmation reports, requesting (e.g., glucose) readings, receiving one or more measured values, and/or the like) with one or more connected medical devices such as the example glucose meter 126 and connected injection device 134. Such communication may be in
one-way or two-way manner with a given device. Additional examples of information that could be conveyed from a connected medical device to an MMA include error codes, device metrics, dosing records, and/or dosing confirmations. And certainly other examples could be listed here. Moreover, in some cases, direct communication links exist between various connected medical devices, such as between the glucose meter 126 and the connected injection device 134.
[0067] The conceptual-information-flow arrow 130 is meant to graphically and conceptually depict that, among other information and as is described more fully below, the HCP system 102 transmits, either directly, via 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, the conceptual-information-flow arrow 132 is meant to graphically and conceptually depict that, among other information and as is 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, and the like.
[0068] As a general matter, 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 an MMA executing thereon), the C3-server system 106, and the administrator-portal system 148— can communicate in at least one embodiment with any other of those entities without being required to route that communication through one or more other entities. For example, in at least one embodiment, the HCP system 102 and the mobile device 104 can exchange information without that information having to pass through the C3-server system 106. In some embodiments, however, one or more entities do communicate with one another via at least one additional entity; as an example, in at least one embodiment, data (e.g., HCP-selected-regimen data) is communicated from the HCP system 102 to the MMA executing on the mobile device 104 via the C3-server system 106.
B. Example HCP system (Example Physical Architecture)
[0069] FIG. 2 depicts an example physical architecture of the HCP system 102, in accordance with at least one embodiment. This architecture is provided by way of illustration and not limitation, as other architectures deemed suitable by those of skill in the art could be implemented. As depicted in FIG. 2, the HCP system 102 includes a communication interface 202, a processor 204, data storage 206, and a user interface 208 that includes the aforementioned display 120.
[0070] The communication interface 202 could include one or more components such as Ethernet cards and/or the like for wired communication and/or one or more components such as Wi-Fi chips and/or the like for wireless communication. The processor 204 could be a general-purpose microprocessor such as a central processing unit (CPET). The data storage 206 could be or include any suitable non-transitory computer-readable medium (CRM) such as memory (e.g., read-only memory (ROM), random-access memory (RAM)), flash memory, a solid-state drive, optical memory, and/or the like), and may contain instructions executable by the processor 204 for carrying out at least the HCP-portal-system functions described herein. The user interface 208, in addition to the display 120, may include one or more output devices such as speakers, indicator LEDs, and/or the like, and may further include one or more input devices such as a keyboard, a mouse, a trackpad, a microphone, and/or the like, as is known in the art. The various components of the HCP system 102 are depicted as communicatively interconnected via system bus 210.
[0071] Moreover, it should be understood that, in at least one embodiment of the present systems and methods, HCP system 102 runs or implements a HCP portal 572 (depicted in FIG. 5,
and also referred to herein as a“HCP-portal application 572”). HCP portal 572 can be a software or firmware application executing on the hardware of HCP system 102. For example, HCP portal 572 can take the form of a widget executing within a HCP’s Electronic Health Record (EHR) system. Such a widget could integrate with a HCP’ s EHR system using a protocol such as SMART (Substitutable Medical Apps, Reusable Technology) on FHIR (Fast Healthcare Interoperability Resources). In some embodiments, HCP portal 572 can take the form of a web application running within a web browser. In an illustrative example, an HCP logs into the HCP portal 572 by pointing a web browser on the HCP system 102 to a hyperlink, whereupon 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 mere conduit of such patient data between its HCP user and the C3-server system 106. In some such embodiments, there is locally stored data in the form of code for the web browser itself (e.g., Microsoft Edge, Google Chrome, Apple Safari, and/or the like), as well as perhaps code for a web-application (e.g., Java) add-on. And certainly other variations could be listed here— with respect to the centralized and/or distributed nature of operable code and/or other substantive data— that those of skill in the art may deem suitable for a given implementation.
C. Example Mobile Device (Example Physical Architecture)
[0072] FIG. 3 depicts an example physical architecture of the mobile device 104, in accordance with at least one embodiment. As can be seen by inspection, FIG. 3 is similar in a number of ways to FIG. 2, and thus is not described here in as great of detail. Due to the mobile device 104 being a mobile device, however, those of skill in the art will understand that corresponding differences may be present in each of the components, such as the communication
interface 302 perhaps being equipped, programmed, and configured for both wireless-wide-area-network (WWAN) communication (according to, e.g., LTE) and wireless-local-area-network (WLAN) communication (according to, e.g., Wi-Fi), as well as having additional wireless-communication capabilities such as NFC, Bluetooth, RFID, RF, and/or the like. Moreover, the processor 304 is selected in at least one embodiment to be suitable for mobile-device implementations, as is the data storage 306, which contains instructions executable by the processor 304 to carry out at least the mobile-device functions described herein, including but not limited to executing the herein-described MMA. Finally, in addition to the display 122, the user interface 308 includes one or more user-input and/or user-output components suitable for mobile-device installations (e.g., touchscreen, stylus, pointing and clicking devices, soft keys, keyboard, microphone, speaker, camera, data ports, and/or the like). The various components of the mobile device 104 are depicted as being communicatively interconnected via system bus 310.
D. Example C3-Server (Example Physical Architecture)
[0073] FIG. 4A depicts an example physical architecture of the C3 server 140, selected as an example one of the C3 servers 140-146 of the C3 -server system 106, in accordance with at least one embodiment. As noted above, the C3 -server system 106 could take the form of any number of servers, including just one and also including more than one. In FIG. 1, the four C3 servers 140-146 with an ellipsis between the third and fourth is intended to illustrate this numerical flexibility. As can also be seen, FIG. 4A is similar in many respects to both FIG. 2 and FIG. 3, and thus is not described herein in as great detail.
[0074] In most scenarios, the architecture of the C3 server 140 would typically be more akin to that of the HCP system 102 than that of the mobile device 104, if for no other reason than the level of performance and data processing of which such varied architectures are capable. Even in
comparison with the HCP system 102, however, there are differences in the architecture of the C3 server 140 in at least one embodiment. For data-security reasons, the communication interface 402 may include only wired-communication hardware (e.g., Ethernet cards), and may include a greater number of data-communi cation interfaces as compared with the HCP system 102.
[0075] Similarly, the processor 404 and the data storage 406 would typically be selected so as to handle more communication, storage, data processing, and the like than would typically be asked of the HCP system 102. The data storage 406 contains instructions executable by the processor 404 for carrying out at least the C3 -server functions described herein. Lastly, the user interface 408 is depicted in dashed lines to indicate that it is not present in all embodiments. For example, in some cases, the C3 server 140 is only accessible in a user-interface-like manner via data connections such as remote-desktop connections, shell connections, and/or the like. The various components of the C3 server 140 are depicted as being communicatively interconnected via system bus 410.
[0076] As described herein, in at least one embodiment, the C3 -server system 106 collectively contains instructions that are 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 carry out various combinations of the C3 -server-system functions that are described herein. The below-described method 700 of FIG. 7 is one such example combination. Indeed, in at least one embodiment, the logic for implementing the C3-server system 106 is distributed across multiple physical servers. In at least one embodiment, the hardware (e.g., data storage, processor capacity, web servers, switches, routers, communication links, and the like) that are used to facilitate particular access requests and/or the like are dynamically provisioned such that different access requests may be facilitated different sets of hardware. Such hardware may be dynamically provisioned for a particular access request based on various factors such as the geographic location of the request, load balancing, required quality of service (QoS), service-agreement parameters, and/or the like. The C3 -server system, then, can be thought of as a“cloud” as that term is used in the art, where that cloud includes a distributed network of servers that collectively and dynamically run virtual services. In at least one embodiment, each such virtual service is its own self-contained software process. Moreover, the particular hardware server (or servers) that actually execute a given instance of a given virtual service is dynamically allocated on the fly depending on one or more factors such as those mentioned in this paragraph.
E. Example Administrator-Portal System (Example Physical Architecture)
[0077] FIG. 4B depicts an example physical architecture of the administrator-portal system 148, in accordance with at least one embodiment. As can be seen by inspection, FIG. 4B is similar in a number of ways to each of FIG. 2, FIG. 3, and FIG. 4A, and thus is not described here in as great of detail. As stated above, some options for the administrator-portal system 148 include a desktop computer, a laptop computer, a tablet computer, a workstation, and the like. The administrator-portal system 148 can take the form of any one or more computing devices that are suitably equipped, programmed, and configured to carry out at least the administrator-portal-system functions described herein. As depicted in FIG. 4B, the administrator-portal system 148 includes a communication interface 452, a processor 454, a data storage 456 containing instructions executable by the processor 454 for carrying out at least the administrator-portal-system functions described herein, and a user interface 458, all of which are communicatively connected with one another via a system bus 460.
[0078] Moreover, 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 executing on the hardware of the administrator-portal system 148. For example, the administrator-portal application can take the form of a web application running within a web browser. An administrator or user may log into the administrator-portal application by pointing a web browser on the administrator-portal system to a hyperlink, whereupon the administrator-portal application opens in the browser. In such embodiments, the content within the administrator-portal application may be hosted by the C3-server system 106, and little to no patient data (e.g., patient medical records, dosing-regimen data, and/or the like) may be stored locally on the administrator-portal system 148. Instead, the administrator-portal system 148 instead acts as a mere conduit of patient data between its administrator / user and the C3-server system 106.
F. Example C3-Server System (Example Functional Architecture)
[0079] FIG. 5 depicts an example functional architecture of the C3 -server system 106, in accordance with at least one embodiment. It should be understood that this functional architecture is provided by way of illustration and not limitation, and that other functional architectures could be implemented as deemed suitable by those of skill in the art in various different contexts. The functional architecture of the C3-server system 106— including each of the various data stores, services, gateways, links, and interfaces— could be implemented using any combination of hardware, firmware, and/or software (wherein the firmware and/or software are run on hardware) deemed suitable by those of skill in the art. It is also noted that entities in addition to the C3 -server system 106 are depicted in the architecture 500 that is shown in FIG. 5. This is clarified by the left brace labeled“106” for C3 -server system 106 - components outside of said left brace are associated with entities in addition to the C3 -server system 106.
[0080] As can be seen in FIG. 5, the architecture 500 includes four of what are known in the computing and programming arts as“layers” separated by“interfaces”; these are logical constructs that foster, among other benefits, encapsulation and manageability of complex systems. The architecture 500 includes a data layer 502, an internal -web-services (IWS) layer 504, an externally-facing-services (EFS) layer 506, and an application layer 508. The data layer 502 is separated by a data-IWS interface 503 from the IWS layer 504, which is separated by an IWS-EFS interface 505 from the EFS layer 506, which is separated by an EFS-application interface 507 from the application layer 508. It is further noted that an interface 509 represents the logical part of the architecture 500 at which users would interact with the overall system, and in particular interact directly with the application layer 508— in other words, the interface 509 is what is often referred to in the art as the“man-machine interface.”
[0081] In the depicted embodiment, the data layer 502 includes a plurality of data stores 5 l0a-e. Each data store 5 l0a-e corresponds to one of the micro-services 514, 516, 518, 520, and/or 522 described herein. Data stores 5 l0a-e collectively contain patient and/or medical data, including personally-identifiable-information (PII) such as names, addresses, telephone numbers, e-mail addresses, social security numbers, and the like. Data stores 5 l0a-e may also collectively information other than PII, such as medical treatments, definitions, dosing regimens (i.e., templates), and the like. In at least one embodiment, the data layer 502 is implemented using the on-demand cloud computing platforms and services operated and offered by Amazon Web Services, a subsidiary of Amazon.com, Inc. of Seattle, Washington. In at least one other embodiment, the data layer 502 is implemented using the PostgreSQL product developed by Heroku of San Francisco, California. And certainly other options could be listed here as well. In at least one embodiment, the data layer 502 is organized according to the FHIR standards, which are put forth by Health Level Seven International (HL7) of Ann Arbor, Michigan.
[0082] The IWS layer 504 includes a plurality of micro-services 514, 516, 518, 520, and 522. The ellipsis between the service 520 and the service 522 is meant to indicate that there could be any number of services in the IWS layer 504 as deemed suitable by those of skill in the art for a given implementation. Each micro-service is a data gateway implemented as a software service responsible for handling data or functionality of a certain type. Exemplary micro-services include a“person” micro-service for handling PII related to enrolled or prospective patients; an“order” micro-service for handling data related to prescription orders; an“observation” micro-service for handling data related to patient observations input by a HCP or observed by the MMA running on a mobile device; a“user access” micro-service for handling data related to users’ access rights and permissions; a“client compatibility” micro-service for verifying that a user’s mobile device is compatible with the functionality provided by C3 -system 106, and a“substance” micro-service for handling data related to types of drugs handled or administered to/by patients. Each micro-service 514-522 has access to one data-store 5 l0a-e via a corresponding communication link 51 la-e.
[0083] Each internal service 514-522 is, in at least one embodiment, designed such that access— including read access and write access— to the data stored in the data stores 5 lOa-e is only available— to the various gateways 524-530 of the EFS layer 506— in the manner defined and permitted by the respective internal services 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 Heroku Platform, also developed by Heroku. And certainly other options could be listed here as well.
[0084] It is further noted that the“links” that are described in connection with FIG. 5 represent logical-access links, not necessarily physical communication links; a logical-access link being present in FIG. 5 indicates that, in at least the described embodiment, proper configurations, authorizations, authentications, permissions, and/or the like have been put in place to facilitate communication between the corresponding entities.
[0085] The EFS layer 506 includes an HCP-portal gateway 524, an MMA gateway 526, an MMA gateway 528, and an admin gateway 530. Moreover, the ellipsis between the MMA gateways 526 and 528 is meant to indicate that any suitable number of MMA gateways could be implemented; the ellipsis between the mobile devices 104 and 532 in the application layer 508 indicate the same. Each MMA gateway corresponds to a specific type or version of MMA. The implementation of a dedicated MMA-gateway instance per type or version of MMA is a design choice, and others could be made. Across the IWS-EFS interface 505, it can be seen— by the system-bus-like depiction of the IWS-EFS interface 505— that any of the gateways of the EFS layer 506 are able, in this depicted embodiment, to call any of the internal services 514-522 on an as-needed basis. Each gateway 524-530 in the EFS layer 506 is designed in at least one embodiment such that access to the internal services 514-522 of the IWS layer 502 is only available to entities in the application layer 508 in the manner defined and permitted by the respective gateways 524-530. For example, in an embodiment, the HCP portal 572 running on HCP system 102 can access internal services 514-522 through HCP portal gateway 524; similarly, MMA 568 running on mobile device 104 can access internal services 514-522 through MMA gateway 526. In at least one embodiment, the EFS layer 506 is implemented using Amazon Web Services. In at least one other embodiment, the EFS layer is implemented using the Heroku Platform. And certainly other options could be listed here as well.
[0086] The applications layer 508 includes the HCP system 102 executing a Health Information Technology User Interface (HIT UI) 574, which in turn is executing a HCP portal 572. The applications layer 508 further includes the above-mentioned mobile device 104 (executing an MMA 568 in accordance with the present disclosure), a second mobile device 532 (executing another type or version of MMA, depicted as MMA 570, in accordance with the present disclosure), an admin portal 534, and an admin portal 536. As with the previously mentioned ellipses, the ellipsis between mobile device 104 and mobile device 532 is meant to indicate that any suitable number of mobile devices may be present in the application layer 508. Furthermore, 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 ellipsis between the admin portal 534 and the admin portal 536 is meant to indicate that any suitable number of system-administrator-level portals could be implemented as deemed suitable in a given context by those of skill in the art. In an embodiment, the admin portal 534 is a clinical C3 admin server, configured for administration of the C3-server system 106 in connection with clinical aspects. In an embodiment, the admin portal 536 is a production-support C3 admin server, configured for administration of the C3-server system 106 in connection with production-support aspects. And certainly other examples could be listed here. In at least one embodiment, one or both of the admin portal 534 and the admin portal 536 are processes executed on the administrator-portal system 148. Furthermore, although no HCP -portal-related ellipsis or additional HCP portals are depicted in FIG. 5, it is also the case that any suitable number of HCP portals could be implemented in a given context.

CLAIMS
What is claimed is:
1. A method comprising: presenting, via a healthcare-professional (HCP)-portal application, multiple medication dosing regimens pertaining to a patient, wherein each presented medication-dosing regimen is associated with a respective different medication-dosing algorithm; receiving, via the HCP -portal application, an HCP selection of at least one of the presented medication-dosing regimens; and transmitting, to a medical mobile application (MMA) on a mobile device associated with the patient, HCP-selected-regimen data indicative of the at least one HCP-selected medication dosing regimen.
2. The method of claim 1, wherein: the presented medication-dosing regimens comprise one or more insulin-dosing regimens; and the at least one HCP-selected medication-dosing regimen comprises at least one HCP-selected insulin-dosing regimen.
3. The method of claim 2, wherein: the one or more presented insulin-dosing regimens comprise at least one or more basal-insulin-dosing regimens and one or more bolus-insulin-dosing regimens.
4. The method of claim 3, wherein:
the at least one HCP-selected insulin-dosing regimen comprises at least one HCP-selected basal-insulin-dosing regimen and at least one HCP-selected bolus-insulin-dosing regimen.
5. The method of claim 1, further comprising: accessing, from a health information technology (HIT) system, electronic health record (EHR) data pertaining to the patient; and presenting the EHR data via the HCP-portal application.
6. The method of claim 2, wherein the at least one HCP-selected insulin-dosing regimen comprises a daily-titration bolus-insulin-dosing regimen associated with a daily-titration bolus-insulin-dosing algorithm.
7. The method of claim 2, wherein the at least one HCP-selected insulin-dosing regimen comprises a fixed-dose bolus-insulin-dosing regimen associated with a fixed-dose bolus-insulin-dosing algorithm.
8. 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.
9. 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.
10. The method of claim 1, further comprising receiving, from the MMA, a regimen-accepted indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-acceptance indication associated with the at least one HCP-selected medication-dosing regimen.
11. The method of claim 1, further comprising receiving, from the MMA, a regimen-rejected indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-rejection indication associated with the at least one HCP-selected medication-dosing regimen, and disabling the MMA on the mobile device associated with the patient in response to the patient-rejection indication.
12. The method of claim 1, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA.
13. The method of claim 12, wherein the MMA is operable to access implementation data prestored 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 HCP-selected-regimen data.
14. The method of claim 12, wherein the MMA is operable to download implementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device only after the at least one HCP-selected medication-dosing regimen has been unlocked by the HCP-selected-regimen data.
15. The method of claim 12, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA conditionally upon receipt by the MMA of a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
16. The method of claim 1, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
17. The method of claim 1, wherein the MMA is configured to provide, via a mobile-device user interface of the mobile device, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
18. A connected-care server system comprising:
one or more servers, each server comprising one or more communication interfaces, one or more processors, and data storage, wherein the data storage 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 carry out a set of server-system functions, the set of server-system functions including: presenting, via a healthcare-professional (HCP)-portal application in communication with at least one of the communication interfaces of the one or more servers, multiple medication-dosing regimens pertaining to a patient, wherein each presented medication-dosing regimen is associated with a respective different medication-dosing algorithm; receiving, via the HCP-portal application, an HCP selection of at least one of the presented medication-dosing regimens; and transmitting, via at least one of the communication interfaces of the one or more servers, to a medical mobile application (MMA) on a mobile device associated with the patient, HCP-selected-regimen data indicative of the at least one HCP-selected medication-dosing regimen.
19. The system of claim 18, wherein: the presented medication-dosing regimens comprise one or more insulin-dosing regimens; and the at least one HCP-selected medication-dosing regimen comprises at least one HCP-selected insulin-dosing regimen.
20. The system of claim 19, wherein: the one or more presented insulin-dosing regimens comprises at least one or more basal-insulin-dosing regimens and one or more bolus-insulin-dosing regimens.
21. The system of claim 20, wherein:the at least one HCP-selected insulin-dosing regimen comprises at least one HCP-selected basal-insulin-dosing regimen and at least one HCP-selected bolus-insulin-dosing regimen.
22. The system of claim 18, wherein the set of server-system functions include: accessing, from a health information technology (HIT) system, electronic health record data (EHR) pertaining to the patient; and presenting the EHR data via the HCP-portal application.
23. The system of claim 19, wherein the at least one HCP-selected insulin-dosing regimen comprises a daily-titration bolus-insulin-dosing regimen associated with a daily-titration bolus-insulin-dosing algorithm.
24. The system of claim 19, wherein the at least one HCP-selected insulin-dosing regimen comprises a fixed-dose bolus-insulin-dosing regimen associated with a fixed-dose bolus-insulin-dosing algorithm.
25. The system of claim 19, 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.
26. The system of claim 19, 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.
27. The system of claim 18, the set of server-system functions further comprising receiving, from the MMA, a regimen-accepted indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-acceptance indication associated with the at least one HCP-selected medication-dosing regimen.
28. The system of claim 18, the set of server-system functions further comprising receiving, from the MMA, a regimen -rejected indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-rejection indication associated with the at least one HCP-selected medication-dosing regimen, and disabling the MMA on the mobile device associated with the patient in response to the regimen-rejected indication.
29. The system of claim 18, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA.
30. The system of claim 29, wherein the MMA is operable to access implementation data prestored 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 HCP-selected-regimen data.
31. The system of claim 29, wherein the MMA is operable to download implementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device only after the at least one HCP-selected medication-dosing regimen has been unlocked by the HCP-selected-regimen data.
32. The system of claim 29, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA conditionally upon receipt by the MMA of a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
33. The system of claim 18, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
34. The system of claim 18, wherein the MMA is configured to provide, via a mobile-device user interface of the mobile device, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
35. 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 carry out a set of functions, the set of functions comprising:presenting, via a HCP -portal application, multiple medication-dosing regimens pertaining to a patient, wherein each presented medication-dosing regimen is associated with a respective different medication-dosing algorithm;receiving, via the HCP -portal application, an HCP selection of at least one of the presented medication-dosing regimens; and transmitting, to a medical mobile application (MMA) on a mobile device associated with the patient, HCP-selected-regimen data indicative of the at least one HCP-selected medication dosing regimen.
36. The CRM of claim 35, wherein:the presented medication-dosing regimens comprise one or more insulin-dosing regimens; andthe at least one HCP-selected medication-dosing regimen comprises at least one HCP-selected insulin-dosing regimen.
37. The CRM of claim 36, wherein:the one or more presented insulin-dosing regimens comprises at least one or more basal-insulin-dosing regimens and one or more bolus-insulin-dosing regimens.
38. The CRM of claim 37, wherein:the at least one HCP-selected insulin-dosing regimen comprises at least one HCP-selected basal-insulin-dosing regimen and at least one HCP-selected bolus-insulin-dosing regimen.
39. The CRM of claim 35, wherein the set of functions further comprise:accessing, from a health information technology (HIT) system, electronic health record(EHR) data pertaining to the patient; and presenting the EHR data via the HCP-portal application.
40. The CRM of claim 36, wherein the at least one HCP-selected insulin-dosing regimen comprises a daily-titration bolus-insulin-dosing regimen associated with a daily-titration bolus-insulin-dosing algorithm.
41. The CRM of claim 36, wherein the at least one HCP-selected insulin-dosing regimen comprises a fixed-dose bolus-insulin-dosing regimen associated with a fixed-dose bolus-insulin-dosing algorithm.
42. The CRM of claim 36, 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.
43. The CRM of claim 36, 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.
44. The CRM of claim 35, the set of functions further comprising receiving, from the MMA, a regimen-accepted indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-acceptance indication associated with the at least one HCP-selected medication-dosing regimen.
45. The CRM of claim 35, the set of functions further comprising receiving, from the MMA, a regimen-rejected indication indicating that the MMA had received, via a mobile-device user interface of the mobile device, a patient-rejection indication associated with the at least one HCP-selected medication-dosing regimen, and disabling the MMA on the mobile device associated with the patient in response to the patient-rejection indication.
46. The CRM of claim 35, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA.
47. The CRM of claim 46, wherein the MMA is operable to access implementation data prestored 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 HCP-selected-regimen data.
48. The CRM of claim 46, wherein the MMA is operable to downloadimplementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device only after the at least one HCP-selected medication-dosing regimen has been unlocked by the HCP-selected-regimen data.
49. The CRM of claim 46, wherein the HCP-selected-regimen data is operable to unlock the at least one HCP-selected medication-dosing regimen on the MMA conditionally upon receipt by the MMA of a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
50. The CRM of claim 35, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
51. The CRM of claim 35, wherein the MMA is configured to provide, via a mobile-device user interface of the mobile device, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
52. A method comprising:receiving, at a medical mobile application (MMA) that is executing on a mobile device that is associated with a patient, healthcare-professional-(HCP)-selected-regimen data that is indicative of an HCP selection of at least one medication-dosing regimen from among a plurality of medication-dosing regimens, each of which is associated with a respective different medication-dosing algorithm, the HCP selection having been made for the patient via an HCP-portal application; andunlocking the indicated at least one HCP-selected medication-dosing regimen on the MMA responsive at least in part to having received the HCP-selected-regimen data.
53. The method of claim 52, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from the HCP-portal application.
54. The method of claim 52, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from a connected-care server system that is in communication with both the HCP-portal application and the MMA.
55. The method of claim 52, further comprising:
subsequent to the receiving step and prior to the unlocking step, presenting, via a mobile-device user interface of the mobile device, a prompt for patient acceptance or patient rejection of the at least one HCP-selected medication-dosing regimen; andreceiving, via the mobile-device user interface, a user input corresponding to the presented prompt,wherein carrying out the unlocking step is conditioned upon the received user input being a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
56. The method of claim 55, further comprising transmitting the received user input to one or both of the HCP-portal application and a connected-care server system that is in communication with both the HCP-portal application and the MMA.
57. The method of claim 52, wherein the unlocking step comprises accessing previously inaccessible implementation data prestored on the mobile device for the at least one HCP-selected medication-dosing regimen.
58. The method of claim 52, wherein the unlocking step comprises downloading previously inaccessible implementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device.
59. The method of claim 52, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
60. The method of claim 52, further comprising providing, via a mobile-device user interface of the mobile device, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
61. A mobile device associated with a patient, the mobile device comprising:a mobile-device communication interface;a mobile-device processor; andmobile-device data storage containing instructions executable by the mobile-device processor for causing the mobile device to execute a medical mobile application (MMA) for carrying out a set of MMA functions, the set of MMA functions comprising:receiving, at the MMA, healthcare-professional-(HCP)-selected-regimen data that is indicative of an HCP selection of at least one medication-dosing regimen from among a plurality of medication-dosing regimens, each of which is associated with a respective different medication-dosing algorithm, the HCP selection having been made for the patient via an HCP -portal application; and unlocking the indicated at least one HCP-selected medication-dosing regimen on the MMA responsive at least in part to having received the HCP- selected-regimen data.
62. The mobile device of claim 61, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from the HCP-portal application.
63. The mobile device of claim 61, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from a connected-care server system that is in communication with both the HCP portal application and the MMA.
64. The mobile device of claim 61, further comprising a mobile-device user interface, the set of MMA functions further comprising:subsequent to the receiving step and prior to the unlocking step, presenting, via the mobile-device user interface, a prompt for patient acceptance or patient rejection of the at least one HCP-selected medication-dosing regimen; andreceiving, via the mobile-device user interface, a user input corresponding to the presented prompt,wherein carrying out the unlocking step is conditioned upon the received user input being a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
65. The mobile device of claim 64, the set of MMA functions further comprising transmitting the received user input to one or both of the HCP-portal application and a connected-care server system that is in communication with both the HCP-portal application and the MMA.
66. The mobile device of claim 61, wherein the unlocking step comprises accessing previously inaccessible implementation data prestored on the mobile device for the at least one HCP-selected medication-dosing regimen.
67. The mobile device of claim 61, wherein the unlocking step comprises downloading previously inaccessible implementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device.
68. The mobile device of claim 61, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
69. The mobile device of claim 61, further comprising a mobile-device user interface, the set of MMA functions further comprising providing, via the mobile-device user interface, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
70. 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 carry out a set of functions, the set of functions comprising:receiving, at a mobile medical application (MMA) that is executing on a mobile device associated with a patient, healthcare-professional-(HCP)-selected-regimen data that is indicative of an HCP selection of at least one medication-dosing regimen from among a plurality of medication-dosing regimens, each of which is associated with a respective different medication dosing algorithm, the HCP selection having been made for the patient via an HCP-portal application; andunlocking the indicated at least one HCP-selected medication-dosing regimen on the MMA responsive at least in part to having received the HCP-selected-regimen data.
71. The CRM of claim 70, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from the HCP-portal application.
72. The CRM of claim 70, wherein receiving the HCP-selected-regimen data comprises receiving the HCP-selected-regimen data from a connected-care server system that is in communication with both the HCP-portal application and the MMA.
73. The CRM of claim 70, the set of functions further comprising:
subsequent to the receiving step and prior to the unlocking step, presenting, via a mobile-device user interface of the mobile device, a prompt for patient acceptance or patient rejection of the at least one HCP-selected medication-dosing regimen; andreceiving, via the mobile-device user interface, a user input corresponding to the presented prompt,wherein carrying out the unlocking step is conditioned upon the received user input being a patient-acceptance indication with respect to the at least one HCP-selected medication-dosing regimen.
74. The CRM of claim 73, the set of functions further comprising transmitting the received user input to one or both of the HCP-portal application and a connected-care server system that is associated with both the HCP-portal application and the MMA.
75. The CRM of claim 70, wherein the unlocking step comprises accessing previously inaccessible implementation data prestored on the mobile device for the at least one HCP-selected medication-dosing regimen.
76. The CRM of claim 70, wherein the unlocking step comprises downloading previously inaccessible implementation data for the at least one HCP-selected medication-dosing regimen onto the mobile device.
77. The CRM of claim 70, wherein the MMA is communicatively connected with an insulin-delivery device associated with the patient.
78. The CRM of claim 70, the set of functions further comprising providing, via a mobile-device user interface of the mobile device, dosing recommendations based on the at least one HCP-selected medication-dosing regimen.
79. A method comprising:presenting, by a processor on a mobile device associated with a patient, a plurality of panels simultaneously on a visual display of the mobile device, wherein the plurality of panels comprise:a first panel that displays a number of units of insulin to be administered to the patient, anda second panel that displays an amount of carbohydrates expected to be covered by the number of units of insulin displayed by the first panel;receiving at the mobile device user input representative of a requested adjustment to the number of units of insulin displayed by the first panel; andupdating, by the processor, each panel of the plurality of panels according to the requested adjustment to the number of units of insulin displayed by the first panel, wherein the updating includes displaying an adjusted number of units of insulin by the first panel and an adjusted amount of carbohydrates expected to be covered by the adjusted number of units of insulin with the second panel.
80. The method of claim 79, wherein the plurality of panels further comprise a third panel that displays an indication of a meal size corresponding to the amount of carbohydrates displayed by the second panel, and wherein the updating includes displaying an indication of an adjusted meal size corresponding to the adjusted amount of carbohydrates.
81. The method of claim 80, wherein the third panel comprises a spectrum that displays a range of meal sizes between a small meal size and a large meal size, and an indicator that indicates where the amount of carbohydrates displayed by the second panel falls on the spectrum.
82. The method of claim 80, wherein the third panel 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.
83. The method of claim 82, further comprising receiving at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, wherein the third panel indicates whether the number 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 minimum carbohydrate threshold.
84. The method of claim 79, further comprising receiving at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, 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.
85. The method of claim 79, wherein the plurality of panels comprise a third panel that displays a drop in the patient’s glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and wherein the updating includes displaying an adjusted drop in the patient’s glucose level that is expected to result from administration of the adjusted number of units of insulin.
86. The method of claim 80, wherein the plurality of panels comprise a fourth panel that displays a drop in the patient’s glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and wherein the updating includes displaying an adjusted drop in the patient’s glucose level that is expected to result from administration of the adjusted number of units of insulin.
87. The method of claim 85, further comprising receiving at the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the drop in the patient’s glucose level displayed by the third panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.
88. The method of claim 86, further comprising receiving at the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the drop in the patient’s glucose level displayed by the fourth panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.
89. The method of claim 79, wherein the mobile device is a mobile smartphone.
90. The method of claim 79, wherein the mobile device is a drug-delivery device.
91. The method of claim 90, wherein the drug-delivery device is in wireless communication with a mobile smartphone, and the drug-delivery device receives at least one of an insulin-to-carbohydrate ratio (ICR), an insulin-sensitivity factor (ISF), a maximum carbohydrate threshold for a medium meal size, and a minimum carbohydrate threshold for a medium meal size from the mobile smartphone.
92. Non-transitory computer-readable media (CRM) having stored thereon instructions that, when executed by one or more processors on a mobile device associated with a patient, are operable to cause the one or more processors to:
present a plurality of panels simultaneously on a visual display of the mobile device, wherein the plurality of panels comprise:a first panel that displays a number of units of insulin to be administered to the patient, anda second panel that displays an amount of carbohydrates expected to be covered by the number of units of insulin displayed by the first panel;receive at the mobile device user input representative of a requested adjustment to the number of units of insulin displayed by the first panel; andupdate each panel of the plurality of panels according to the requested adjustment to number of units of insulin displayed by the first panel, wherein the updating includes displaying an adjusted number of units of insulin displayed by the first panel and an adjusted amount of carbohydrates expected to be covered by the adjusted number of units of insulin with the second panel.
93. The CRM of claim 92, wherein the plurality of panels further comprise a third panel that displays an indication of a meal size corresponding to the amount of carbohydrates displayed by the second panel, and wherein the updating includes displaying an indication of an adjusted meal size according to the adjusted amount of carbohydrates.
94. The CRM of claim 93, wherein the third panel comprises a spectrum that displays a range of meal sizes between a small meal size and a large meal size, and an indicator that indicates where the amount of carbohydrates displayed by the second panel falls on the spectrum.
95. The CRM of claim 93, wherein the third panel 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.
96. The CRM of claim 95, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to:receive at the mobile device a maximum carbohydrate threshold for a medium meal size and a minimum carbohydrate threshold for a medium meal size, wherein the third panel indicates whether the number 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 minimum carbohydrate threshold.
97. The CRM of claim 92, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to:receive at the mobile device an insulin-to-carbohydrate ratio (ICR) associated with the patient, wherein the amount of carbohydrates displayed by the second panel is calculated based on the number of units displayed by the first panel and the received ICR.
98. The CRM of claim 92, wherein the plurality of panels comprise a third panel that displays a drop in the patient’s glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and wherein the updating includes displaying an adjusted drop in the patient’s glucose level that is expected to result from administration of the adjusted number of units of insulin.
99. The CRM of claim 93, wherein the plurality of panels comprise a fourth panel that displays a drop in the patient’s glucose level that is expected to result from administration of the number of units of insulin displayed by the first panel, and wherein the updating includes displaying an adjusted drop in the patient’s glucose level that is expected to result from administration of the adjusted number of units of insulin.
100. The CRM of claim 98, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to:receive at the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the drop in the patient’s glucose level displayed by the third panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.
101. The CRM of claim 99, wherein the instructions, when executed by the one or more processors, are further operable to cause the one or more processors to:receive at the mobile device an insulin sensitivity factor (ISF) associated with the patient, wherein the drop in the patient’s glucose level displayed by the fourth panel is calculated based on the number of units of insulin displayed by the first panel and the received ISF.
102. The CRM of claim 92, wherein the mobile device is a mobile smartphone.
103. The CRM of claim 92, wherein the mobile device is a drug-delivery device.
104. The CRM of claim 103, wherein the drug-delivery device is in wireless communication with a mobile smartphone, and the drug-delivery device receives at least one of an insulin-to-carbohydrate ratio (ICR), an insulin-sensitivity factor (ISF), a maximumcarbohydrate threshold for a medium meal size, and a minimum carbohydrate threshold for a medium meal size from the mobile smartphone.
.