CN116097370A - Automatic device configuration - Google Patents

Abstract

The present invention provides methods and systems for configuring therapy settings of a medical device for a particular patient. Patient data entered via a non-medical device may be received. A value for the total daily dose of insulin for the particular patient may be obtained from the patient data. Based on the value of the total daily dose, a therapy set for the particular patient may be calculated. The medical device may be automatically programmed with the therapy set to complete the setting of the medical device such that the medical device is configured for the particular patient.

Description

Automatic device configuration

Technical Field

The present technology relates generally to device auto-configuration and, more particularly, to auto-device configuration.

Background

In an increasing number of fields, portable computing devices (e.g., smart phones, laptops, and tablets) are used to control other devices. For example, in the field of medical devices, the use of portable computing devices to control personal medical devices (such as insulin infusion devices worn by patients) has shown a growing trend. Portable computing devices may even be used to control and communicate with medical devices on the body, such as patch pumps (patch pumps) and sensors. The use of such non-medical devices as part of a medical device system may provide a number of advantages.

These advantages include eliminating the need for dedicated control devices. This may make the cost of ownership lower. In addition, patients can carefully manage their disease and use a familiar user interface that shortens the learning curve. This may also provide connectivity to a server system (e.g., a cloud-based system) that monitors the patient and controls drug delivery to the patient. The non-medical smart device may upload data for analysis by a healthcare provider (HCP) and AI-based system. The non-medical smart device may also receive periodic updates of the treatment management software. For example, these updates may update the medical control application software (or key parameters thereof) to customize and improve the treatment. Connectivity also provides a means to alert caregivers and HCPs in emergency situations when an alarming trend is present. The medical control application may also use health related data from non-medical smart devices and other applications/systems to improve treatment of the patient.

Many insulin pump systems are designed to deliver accurate and measured doses of insulin via an infuser (e.g., an infuser that delivers insulin through a small diameter tube that terminates in a cannula inserted under the patient's skin). Instead of a syringe, the patient may simply activate an insulin pump to administer an insulin bolus as needed (e.g., in response to the patient's current Blood Glucose (BG) level). The patient may measure his BG level using a BG measurement device, such as a test strip meter, a continuous glucose measurement system, or the like. BG measurement devices use various methods to measure BG levels of a patient, such as a blood sample of the patient, a sensor in contact with a body fluid, an optical sensor, an enzyme sensor, or a fluorescence sensor. When the BG measurement device has generated a BG measurement result, the measurement result is typically displayed on the BG measurement device. The continuous glucose monitoring system may monitor a patient's Sensor Glucose (SG) level (e.g., subcutaneous tissue glucose level) in real-time. This allows for real-time calculation of insulin delivery dosage by a software algorithm (e.g., a closed loop algorithm) based on measured sensor glucose levels.

Insulin pumps, continuous Glucose Monitoring (CGM) devices, and other devices such as smartphones and Blood Glucose Monitors (BGM) may be different parts of an insulin infusion system. The various devices that are part of the insulin infusion system may form a wireless body area network that may be used to exchange monitoring and therapy (control) data, for example, between a plurality of medical devices worn on or near the patient's body. For example, the number of the cells to be processed,the measured glucose value (SG value) can be transmitted wirelessly between devices within the body area network. The insulin pump and CGM device may also be configured to communicate with a remote control device, a monitoring or display device, a BG meter, and other devices associated with such infusion systems. For example, the CGM sensor may include or be coupled to a wireless radio frequency ("RF") transmitter that communicates with other devices that are part of the infusion system, such as a hand-held remote control (also known as a Command Control Device (CCD)), which uses wireless communication techniques, such as conventional

(BT) or Bluetooth Low->

(BLE) technology) is in communication with the infusion pump device. />

Complex medical devices, such as insulin pumps, often require configuration prior to use. The process of configuring a system for insulin infusion therapy requires a certain time and a certain level of expertise and knowledge. Many patients do not have the expertise or knowledge required to properly configure their systems because such configuration may depend on patient-specific system parameters (e.g., therapy settings, control algorithm settings, or other parameters). In most cases, a physician or other healthcare provider helps each patient configure their device with patient-specific system parameters that are unique to each patient. The therapy settings, control algorithm settings, or other parameters may affect the operation of the medical device for therapy purposes, and may also alter device behavior such as modes of operation, treatment methods, or safety limitations. The process of configuring a medical device and keeping patient-specific system parameters up-to-date can be time consuming and burdensome.

Accordingly, it is desirable to reduce the time and effort involved in configuring devices (e.g., insulin pumps, glucose sensors, and other medical devices) and enable simplified configuration of medical devices. For example, it would be desirable to simplify the process of setting patient-specific therapy settings and parameters for such devices. Furthermore, other desirable features and characteristics will become apparent from the subsequent detailed description and the appended claims, taken in conjunction with the accompanying drawings and the foregoing technical field and background.

Disclosure of Invention

Methods and systems for automatically configuring a first medical device are provided. According to the method and the system, a computing system may obtain prescription information for a patient. The prescription information includes a device prescription. The computing system may translate the prescription information into first configuration data including therapy settings for a first medical device indexed by the device prescription. The computing system may cause automatic configuration of the first medical device based on communicating the first configuration data to the first medical device. In some embodiments, the first medical device comprises at least one of the group comprising an insulin infusion device and a glucose sensor.

In some embodiments, the device prescription comprises: identification information for the patient, a model of the first medical device, and a type of therapy prescribed for the patient. In some embodiments, the prescription information includes one or more of the following: basic patient-specific data for a patient, the basic patient-specific data comprising: physical, metabolic or anatomical data about the patient, and information about the medical condition; patient lifestyle data for a patient, the patient lifestyle data comprising: data about the patient's diet and data about the patient's exercise characteristics; information about medical conditions targeted for therapy, and information about medical conditions other than conditions targeted for therapy; information about the patient's therapy history; as well as known therapy settings from prior medical devices of the patient.

In some embodiments, the prescription information may be converted into the first configuration data by: the method further includes selecting an appropriate therapy configuration for the first medical device based on the prescription information, and determining therapy parameters and settings for the first medical device based on the prescription information. In some embodiments, the appropriate therapy configuration comprises: one or more therapy algorithms to be performed by the first medical device for the patient; and one or more modes of operation of the first medical device to be used with the patient.

In some embodiments, the therapy parameters and settings include: appropriate device configuration parameters or settings for configuring the first medical device of the patient, and therapy configuration parameters for configuring the first medical device of the patient. In some embodiments, the computing system may combine the appropriate therapy configuration and therapy parameters and settings for the first medical device into first configuration data and save the first configuration data in a database. In some embodiments, the first configuration data is structured as at least one software image.

In some embodiments, the computing system may convert the prescription information into second configuration data that includes therapy settings for a second medical device indexed by the prescription information, wherein the first medical device is a different model than the second medical device.

Methods and systems for configuring therapy settings of a medical device for a particular patient are provided. Patient data entered via a non-medical device may be received. A value of the total daily dose of insulin for a particular patient may be obtained from patient data. Based on the value of the total daily dose, a therapy set for a particular patient may be calculated. The medical device may be automatically programmed with the therapy set to complete the setting of the medical device such that the medical device is configured for a particular patient. The therapy set for a particular patient may include, for example: basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, and basal increment for a particular patient. Depending on the implementation, the therapy set for a particular patient may be calculated by one of the following: non-medical devices, and server systems hosting cloud-based services.

In some embodiments, the patient data includes a weight of the particular patient, and the value of the total daily dose of insulin for the particular patient may be obtained from the patient data by calculating the value of the total daily dose based on the weight of the particular patient. Depending on the implementation, the value of the total daily dose may be calculated by one of the following: non-medical devices, and server systems hosting cloud-based services.

In some embodiments, the patient data includes a value of a total daily dose of insulin for the particular patient, and the value of the total daily dose of insulin for the particular patient may be obtained from the patient data by extracting the value of the total daily dose of insulin for the particular patient from the patient data

In some embodiments, the non-medical device may confirm whether the value of the total daily dose is correct. This may, for example, involve displaying the total daily dose to the patient or healthcare provider for viewing and for making a decision as to whether the value is correct. When the value of the total daily dose is incorrect, an updated value of the total daily dose may be received via the non-medical device (e.g., by manual input by the patient or healthcare provider), and a therapy set for the particular patient may be calculated based on the updated value of the total daily dose. If the value of the total daily dose is determined to be correct, a therapy set for the particular patient may be calculated based on the value without updating.

There is provided a computing system comprising: at least one processor device; and a non-transitory processor-readable medium operatively associated with the at least one processor device, the processor-readable medium containing executable instructions configurable to cause the at least one processor device to perform a method. According to the method, patient data entered via a non-medical device may be received, and a value of a total daily dose of insulin for a particular patient may be obtained from the patient data. A therapy set for a particular patient may be calculated based on the value of the total daily dose, and the medical device may be automatically programmed with the therapy set to complete the setting of the medical device such that the medical device is configured for the particular patient.

There is provided an electronic device including: at least one processor device; and a non-transitory processor-readable medium operatively associated with the at least one processor device, the processor-readable medium containing executable instructions configurable to cause the at least one processor device to perform a method. According to the method, patient data entered via a non-medical device may be received, and a value of a total daily dose of insulin for a particular patient may be obtained from the patient data. Based on the value of the total daily dose, a therapy set may be calculated for automatically programming the medical device of the particular patient such that the medical device is configured for the particular patient and the therapy set may be transmitted to the medical device of the particular patient.

There is provided an electronic device including: at least one processor device; and a non-transitory processor-readable medium operatively associated with the at least one processor device, the processor-readable medium containing executable instructions configurable to cause the at least one processor device to perform a method. According to the method, patient data entered via a non-medical device may be received, and a value of a total daily dose of insulin for a particular patient may be obtained from the patient data. Based on the value of the total daily dose, a therapy set for a particular patient may be calculated. The processor means may be automatically programmed with a therapy set for a particular patient such that the medical device is configured for the particular patient. In some embodiments, the medical device comprises an insulin infusion device, and the therapy set for the particular patient comprises: basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, and basal increment for a particular patient.

This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the detailed description. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.

Drawings

A more complete understanding of the subject matter may be derived by referring to the detailed description and claims when considered in conjunction with the following figures, wherein like reference numbers refer to similar elements throughout the figures.

FIG. 1 is a schematic illustration of an infusion system;

FIG. 2 is a simplified block diagram representation of an exemplary embodiment of a communication system;

FIG. 3 is a simplified block diagram representation of a computer-based or processor-based apparatus according to the disclosed embodiments;

FIG. 4 is a block diagram of a patient monitoring system according to the disclosed embodiments;

FIG. 5 is a flow chart illustrating an automated medical device configuration method for configuring one or more medical devices to be provided to a patient in accordance with the disclosed embodiments;

FIG. 6 is a flow chart illustrating a setting generation method for generating a setting with which to configure one or more medical devices to be provided to a patient in accordance with the disclosed embodiments;

FIG. 7 is a flow chart illustrating an automated medical device configuration method for configuring one or more medical devices to be provided to a patient in accordance with the disclosed embodiments;

fig. 8 is a flowchart illustrating a method for configuring therapy settings of a medical device for a particular patient during a start-up mode of the medical device, in accordance with the disclosed embodiments;

FIG. 9 is a flow chart illustrating a method for configuring therapy settings of a medical device for a particular patient during a start-up mode of the medical device according to the disclosed embodiments;

FIG. 10 is a flow chart illustrating another method for configuring therapy settings of a medical device for a particular patient during a start-up mode of the medical device according to the disclosed embodiments; and is also provided with

Fig. 11 is a flow chart illustrating another method for configuring therapy settings of a medical device for a particular patient during a start-up mode of the medical device according to the disclosed embodiments.

Detailed Description

The following detailed description is merely illustrative in nature and is not intended to limit embodiments of the subject matter or the application and uses of such embodiments. As used herein, the word "exemplary" means "serving as an example, instance, or illustration. Any implementation described herein as exemplary is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, there is no intention to be bound by any expressed or implied theory presented in the preceding technical field, background, brief summary or the following detailed description.

Techniques and technologies may be described herein in terms of functional and/or logical block components, and with reference to symbolic representations of operations, processing tasks, and functions that may be performed by various computing components or devices. Such operations, tasks, and functions are sometimes referred to as being computer-executed, computerized, software-implemented, or computer-implemented. It should be understood that the various block components shown in the figures may be implemented by any number of hardware, software, and/or firmware components configured to perform the specified functions. For example, embodiments of the system or component may employ various integrated circuit components, e.g., memory elements, digital signal processing elements, logic elements, look-up tables, and the like, which may carry out a variety of functions under the control of one or more microprocessors or other control devices.

When implemented in software, firmware, or processor-readable instructions, the various elements of the systems described herein are essentially the code segments or instructions that perform various tasks. In certain embodiments, the program or code segments are stored in a tangible processor readable medium, which may include any medium capable of storing or transmitting information. Examples of non-transitory and processor-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, and the like.

Exemplary embodiments of the subject matter are described herein in terms of patients and medical devices, such as portable electronic medical devices. However, it should be understood that the techniques disclosed herein are equally applicable to users and devices in non-medical environments. While many different applications are possible, the following description focuses on embodiments that incorporate an insulin infusion device (or insulin pump) as part of an infusion system deployment. For the sake of brevity, conventional techniques related to infusion system operation, insulin pump and/or infusion set operation, and other functional aspects of the systems (and the individual operating components of the systems) may not be described in detail herein. Examples of infusion pumps may be of the type described in, but are not limited to, the following U.S. patents: 4,562,751; 4,685,903; 5,080,653; 5,505,709; 5,097,122; 6,485,465; 6,554,798; 6,558,320; 6,558,351; 6,641,533; 6,659,980; 6,752,787; 6,817,990; 6,932,584; and 7,621,893; each of these us patents is incorporated herein by reference.

In general, fluid infusion devices include a motor or other actuation arrangement operable to displace a plunger (or stopper) of a fluid reservoir provided within the fluid infusion device to deliver a dose of fluid, such as insulin, to a user's body. The dose command governing motor operation may be generated in an automated manner according to a delivery control scheme associated with a particular mode of operation, and the dose command may be generated in a manner affected by current (or recent) measurements of the physiological condition of the user's body. For example, in a closed loop or automatic mode of operation, a dose command may be generated based on a difference between a current (or most recent) measurement of interstitial fluid glucose level in the user's body and a target (or reference) glucose set-point value. In this regard, the infusion rate may vary with fluctuations in the difference between the current measurement and the target measurement. For purposes of illustration, the subject matter is described herein in the context of infusion of insulin with a fluid for regulating glucose levels in a user (or patient); however, it should be understood that many other fluids may be administered by infusion, and that the subject matter described herein is not necessarily limited to use with insulin.

From the perspective of healthcare providers and end users, the process of configuring a medical device (such as an insulin pump) can be time consuming and burdensome. Physicians often prescribe a particular type of medical device that would be the best model for a particular patient given the particular characteristics of the patient, and manually configure the different parameters of that particular type of medical device according to a therapy regimen that the physician deems appropriate to meet the patient's needs. For example, in some cases, a physician may select a particular model of medical device (e.g., a device having certain feature sets or capabilities for therapy/treatment) that may provide an appropriate therapy for a particular patient. The medical device may then be configured or programmed with the configuration parameters by a user (such as a patient or healthcare provider) by entering the configuration parameters into the medical device. For example, in many cases, a physician may configure or program a particular medical device by calculating and manually entering configuration parameters that are determined based on a particular patient's therapy settings/needs (such as his/her therapy history, insulin dosage, insulin sensitivity, etc.). For example, in the case of insulin pumps, a doctor or other healthcare provider often needs to manually configure certain parameters and settings of the insulin pump. This configuration is typically different for each patient, as it takes into account the individual characteristics of each patient. The prescribed therapy regimen for each patient can vary significantly from patient to patient. Each patient may not only have their own regimen, but the regimen may also vary over time according to a number of variables. Thus, configuration of medical devices can be a very laborious and time-consuming process.

Some devices may require more frequent or complex configurations for various reasons. For example, some devices may be at least partially disposable (e.g., patch-type insulin pumps that are delivered to an end user in large volumes, used, and then replaced after a period of use). As another example, a particular patient may have an insulin pump that includes a disposable component and a durable component, where the particular patient may use the durable component for an extended period of time, but the disposable component may have a limited life and may be used for a relatively short period of time, after which it is removed and replaced with a new disposable component that may be used with the existing durable component. In some cases, the medical device or components thereof (e.g., durable components) may be delivered to an end user in a large volume. In such cases, the configuration process is typically repeated for each of the medical devices or components (e.g., each device may be configured separately for that particular patient to account for the needs of that particular patient).

In addition, multiple devices may be issued to a patient to support maintenance without interrupting therapy (e.g., charging one device while another device is in use). It is commonplace for a particular patient to have multiple ambulatory medical devices for use in providing insulin therapy. For example, a particular patient may have several insulin pumps for their use in turn (e.g., from switching for maintenance, charging, etc.).

Currently, some device manufacturers make and sell several different medical device models (e.g., insulin pump models) to provide different therapies to patients. Although the device hardware may be common between different medical device models, different medical device models may use different software and may use different part numbers for inventory and shipment. The device manufacturer may provide the patient with devices that require hardware and/or software configuration for each particular patient before being used. In this case, the configuration process needs to be performed by the prescribing physician, and as mentioned above, the configuration of the medical device can be a very laborious and time-consuming process. This may include, for example, selection of advanced therapy features (such as closed loop algorithm type) and low-level therapy parameters. The configuration process may also take into account the medical needs of the patient, the physician's assessment of the patient's ability to manage different therapy features, and cost considerations (if the therapy options are priced at different levels).

Future medical devices may support a wider variety of configurable therapy parameters or selectable therapy algorithms, requiring even more configuration effort to adjust each device to the patient. Future technological developments may make current device configuration methods extremely difficult to implement. The number of configurable therapy parameters may grow as the therapy algorithms become more complex, thereby increasing the burden of manual input and the risk of error. As automation increases and the need for manual patient control decreases, future devices may also have more limited or no on-board user interface at all.

To address these issues, techniques related to automatic device configuration via web services are disclosed herein. In some embodiments, such techniques may be practiced in the context of a medical device system (such as an insulin infusion system). The medical device system may include a cloud-based server system for physician input of configuration parameters and partial automation or guidance in selecting these values. This input process may be accomplished, for example, when the patient is first assigned a device. When a patient's medical device is received by the patient and put into use, the cloud-based system may automatically feed configuration information to the patient's medical device. This procedure reduces physician effort, improves patient experience, and reduces the risk of error during repeated input of configuration data.

Thus, instead of configuring a particular medical device by calculating configuration parameters and manually entering the configuration parameters into the particular medical device for a particular patient, the disclosed embodiments may allow at least some of the configurations to be automated (as opposed to applying rules of thumb or using equations or graphs to calculate values, etc.). In some embodiments, the cloud-based system allows a user (e.g., a physician or other healthcare provider) to simply enter a data set for a particular patient, and the system then automatically generates and delivers configuration parameters to a particular medical device that can be used to configure that particular medical device for that particular patient (as well as potentially other medical devices for that particular patient).

This allows the medical device to be delivered to the patient in an unconfigured state and then configured "on site" without the need for manual configuration or assistance of a healthcare provider. This simplifies the process of programming or configuring the device and reduces the need for intervention by the healthcare provider during the configuration process. Automating the initial configuration of device parameters not only reduces physician workload, but also improves patient experience and reduces the risk of error during repeated input of configuration data. Preferably, the unconfigured medical device is non-functional and becomes active only when it receives an initial configuration of device parameters. This reduces the risk of performing operations with parameter "factory set" values that may be inappropriate for a particular patient. Automation may also lead to an improved patient experience during the initial phase of treatment, as cloud-based solutions for automatically determining therapy parameters may result in better device configurations than manual methods. In addition to allowing initial configuration, the cloud-based system also allows multiple medical devices to be updated without manual configuration or assistance from a healthcare provider.

These benefits are even more pronounced for future devices that require more frequent configuration (e.g., because the patient is being issued multiple devices or because the devices have a shorter useful life). For example, a cloud-based system may be used to configure a plurality of medical devices for a particular patient with appropriate configuration parameters (e.g., configuration data and appropriate settings) for the particular patient such that the medical devices operate in unison and are synchronized in their operating characteristics. In other words, the device configuration parameters may be automatically sent to and used to configure different medical devices for a particular patient, thereby eliminating the need for the patient or the patient's healthcare provider to manually configure many different medical devices for that particular patient.

Another advantage of the disclosed embodiments is that universal commercial off-the-shelf (COTS) medical devices can be delivered to many different patients and then customized for each particular patient such that the medical devices are configured with the appropriate configuration data and the appropriate settings for that particular patient. For example, a generic medical device in an unprogrammed/unconfigured state (e.g., with a blank configuration payload and not yet configured for a particular patient) may be shipped to a number of different patients. Each generic medical device may then be programmed with the correct therapy model and configuration parameters so that the generic medical device becomes customized for the particular patient. In some implementations, when a particular customer receives one of these generic pumps, they can log into the cloud-based computing system and download an open/appropriate therapy model to customize the generic pump so that it operates according to (i.e., as) the particular therapy model. Furthermore, all configuration parameters may also be downloaded so that the pump is configured with the appropriate configuration parameters (configuration data and appropriate settings) for that particular patient. Once the patient receives the medical device, a complete configuration package (bundle) may be sent to the medical device. The configuration composition package may be structured in a number of different ways: a single common software image with configurable therapy algorithms and parameters; one software image for each therapy algorithm with configurable parameters; or a unique software image for each patient. Optionally, operation of the universal pump/medical device is disabled before the universal pump/medical device receives a configuration combination package containing appropriate configuration parameters (configuration data and appropriate settings) for that particular patient.

The disclosed embodiments may also simplify inventory management for medical device manufacturers and distributors by reducing the number of different models of medical devices that need to be produced for different patients (as the operation of generic medical devices may be customized for many different patients). The generic medical device may be sent to a customer (such as a patient) and then configured with an appropriate therapy model, thereby becoming a patient-specific medical device. Thus, instead of storing a plurality of different pump models (e.g., 12 different pump models), a single configurable pump may be shipped to different customers. This procedure may enable a more streamlined approach to providing different therapy types. In addition, the patient does not need to worry about ordering a particular model. Instead, he/she may log into the cloud-based computing system, for example, by using, for example, their smart phone (e.g.,

) To order and configure a generic model, and the cloud-based computing system delivers all configuration information needed to configure the device according to a particular therapy model. This configuration process allows the physician to exercise the necessary control over the patient device settings without unduly limiting future device design possibilities. This not only simplifies the end user and healthcare provider to do, but also simplifies supply chain management by reducing storage, inventory, turnaround time, etc. If the generic medical device is non-functional before receiving the configuration combination package, the risk of operating with a wrongly entered configuration or with a "factory set" configuration that may be wrong for the specific patient is eliminated. The medical device may be rendered nonfunctional in any of a variety of ways. For example, the configuration package may include firmware necessary for operation of the medical device. Alternatively, the device may contain a hardware or software lock that is released upon receipt of code or other data in the configuration composition package. The download and/or installation of the portfolio can be based upon authentication (e.g., by ID/password) by the patient or their healthcare provider.

Turning now to fig. 1, an infusion system 100 includes, but is not limited to, a fluid infusion device (e.g., an infusion pump) 102, a sensing arrangement 104, a Command Control Device (CCD) 109, and a computer 106. The components of infusion system 100 may be implemented using different platforms, designs, and configurations, and the embodiment shown in fig. 1 is not intended to be exhaustive or limiting. In practice, as shown in fig. 1, the infusion device 102 and the sensing arrangement 104 are fixed at a desired location on the body of a user (e.g., patient). In this regard, the location at which the infusion device 102 and sensing arrangement 104 of fig. 1 are secured to the body of the user is provided as a representative, non-limiting example only. The elements of the infusion system 100 may be similar to those described in U.S. patent No. 8,674,288, the subject matter of which is hereby incorporated by reference in its entirety.

In the illustrated embodiment of fig. 1, the infusion device 102 is designed as a portable medical device suitable for infusing fluids, liquids, gels, and/or medications into a user's body. In an exemplary embodiment, the infusion fluid is insulin, but many other fluids may be administered by infusion, such as, but not limited to, HIV drugs, drugs for treating pulmonary hypertension, iron chelating drugs, analgesics, anticancer therapeutic drugs, vitamins, hormones, and the like. In some embodiments, the fluid may include nutritional supplements, dyes, tracking media, saline media, hydration media, and the like.

The sensing arrangement 104 generally represents a component of the infusion system 100 configured to sense, detect, measure, or otherwise quantify a condition of a user, and may include sensors, monitors, etc. for providing data indicative of the condition sensed, detected, measured, or otherwise monitored by the sensing arrangement. In this regard, the sensing arrangement 104 may include electronics and enzymes that are responsive to a biological condition of the user, such as blood glucose level, and provide data indicative of the blood glucose level to the infusion device 102, the CCD 109, and/or the computer 106. For example, the infusion device 102, the CCD 109 and/or the computer 106 may include a display for presenting information or data to the user (such as, for example, a current glucose level of the user, a graph or chart of glucose level of the user versus time, a device status indicator, an alarm message, etc.) based on the sensor data received from the sensing arrangement 104. In other embodiments, the infusion device 102, the CCD 109, and/or the computer 106 may include electronics and software configured to analyze the sensor data and operate the infusion device 102 to deliver fluid to the body of the user based on the sensor data and/or preprogrammed delivery routines. Thus, in an exemplary embodiment, one or more of the infusion device 102, the sensing arrangement 104, the CCD 109, and/or the computer 106 includes a transmitter, a receiver, and/or other transceiver electronics that allow communication with other components of the infusion system 100 such that the sensing arrangement 104 may transmit sensor data or monitor data to one or more of the infusion device 102, the CCD 109, and/or the computer 106.

Still referring to fig. 1, in various embodiments, the sensing arrangement 104 may be secured to or embedded in the body of the user at a location remote from where the infusion device 102 is secured to the body of the user. In various other embodiments, the sensing arrangement 104 may be incorporated within the infusion device 102. In some embodiments, the sensing arrangement 104 may be separate and remote from the infusion device 102 and may be part of, for example, the CCD 109. In such embodiments, the sensing arrangement 104 may be configured to receive biological samples, analytes, and the like to measure a condition of a user.

In some embodiments, the CCD 109 and/or computer 106 may include electronics and other components configured to perform processing, deliver daily storage, and control the infusion device 102 in a manner that is affected by sensor data measured by and/or received from the sensing arrangement 104. By including control functions in the CCD 109 and/or the computer 106, the infusion device 102 may be made of more simplified electronics. However, in other embodiments, the infusion device 102 may include all control functions and may operate without the CCD 109 and/or the computer 106. In various embodiments, the CCD 109 may be a portable electronic device. Further, in various embodiments, the infusion device 102 and/or the sensing arrangement 104 may be configured to transmit data to the CCD 109 and/or the computer 106 to display or process the data through the CCD 109 and/or the computer 106.

In some embodiments, the CCD 109 and/or the computer 106 may provide the user with information that facilitates subsequent use of the infusion device 102 by the user. For example, the CCD 109 may provide information to the user to allow the user to determine the rate or dosage of the drug to be administered into the user's body. In some embodiments, the CCD 109 may provide information to the infusion device 102 to autonomously control the rate or dosage of drug administered into the user's body. In some embodiments, the sensing arrangement 104 may be integrated into the CCD 109. Such embodiments may allow a user to monitor a condition by, for example, providing his or her blood sample to the sensing arrangement 104 to assess his or her condition. In some embodiments, the sensing arrangement 104 and the CCD 109 may be used to determine the glucose level in the blood and/or body fluid of the user without the use or need for a wired or cable connection between the infusion device 102 and the sensing arrangement 104 and/or the CCD 109.

In some embodiments, the sensing arrangement 104 and/or the infusion device 102 are cooperatively configured to deliver fluid to a user using a closed-loop system. Examples of sensing devices and/or infusion pumps that utilize a closed loop system can be found in, but are not limited to, the following U.S. patents: 6,088,608, 6,119,028, 6,589,229, 6,740,072, 6,827,702, 7,323,142, and 7,402,153, or U.S. patent application publication 2014/0066889, all of which are incorporated herein by reference in their entirety. In such embodiments, the sensing arrangement 104 is configured to sense or measure a condition of the user, such as a blood glucose level or the like. The infusion device 102 is configured to deliver fluid in response to a condition sensed by the sensing arrangement 104. The sensing arrangement 104 continues to sense or otherwise quantify the current condition of the user, allowing the infusion device 102 to continuously deliver fluid in response to the current (or most recently) sensed condition of the sensing arrangement 104. In some embodiments, the sensing arrangement 104 and/or the infusion device 102 may be configured to utilize a closed loop system only for a portion of the day, such as only when the user is asleep or awake.

Fig. 2 is a simplified block diagram representation of an exemplary embodiment of a communication system 200 suitably configured to support the techniques and methods described in more detail below. The system 200 supports a user of an insulin infusion device and performs various techniques and methods to help the user (patient, caregiver, healthcare provider, parent, etc.) manage the use of the insulin infusion device. It should be appreciated that fig. 2 depicts one possible implementation of a communication system, and that other arrangements, architectures, and deployments may be provided, if desired. The system 200 (which has been simplified for purposes of illustration) generally includes or cooperates with, but is not limited to, the following: a mobile device 206; insulin infusion device 202; a blood glucose meter 207; a continuous glucose sensor 204; and an optional data upload 209. The mobile device 206 (which may, in some embodiments, serve the role of a client device) is owned or operated by the user (i.e., diabetic). Insulin infusion device 202, blood glucose meter 207 and glucose sensor 204 are components of an insulin infusion system used by a patient to treat diabetes. The system 200 can also include or cooperate with an optional data uploader component 209.

The various components of the system 200 may be used to collect and analyze input data of a patient that may originate from various sources, including an insulin infusion device, a glucose sensor or glucose meter, a mobile device operated by a user of an insulin infusion device, or other components or computing devices compatible with the system, such as a data upload. The present disclosure contemplates these and other alternative arrangements. To this end, some embodiments of the system may include additional devices and components that function as data sources, data processing units, and the like. For example, the system may include, but is not limited to, any or all of the following elements: a computer device or system; a patient monitor; a healthcare provider system; a data communication device; etc. It should be appreciated that in some applications (e.g., for type 2 diabetics), insulin infusion device 202 may be an optional component. For such applications, another diabetes management device and/or mobile device 206 may operate in an equivalent manner to support the system 200.

At a minimum, mobile device 206 is communicatively coupled to network 210. In certain embodiments, insulin infusion device 202, blood glucose meter 207, and/or continuous glucose sensor 204 are also communicatively coupled to network 210 to facilitate uploading of relevant data to a remote server system (not shown). Alternatively or in addition, insulin infusion device 202, blood glucose meter 207 and continuous glucose sensor 204 provide relevant data to data upload component 209, which in turn uploads the data to other systems (not shown) via network 210.

Fig. 2 depicts a network 210 in a simplified manner. In practice, system 200 may cooperate with and utilize any number of wireless data communication networks and any number of wired data communication networks maintained or operated by various entities and providersA network. Thus, communication between the various components of system 200 may involve multiple network links and different data communication protocols. In this regard, network 210 may include or cooperate with, but is not limited to, any of the following: a local area network; a wide area network; the Internet; a personal area network; a cellular communication network; a satellite communications network; video services or television broadcast networks; a vehicle-mounted network; etc. In addition, the various components may also communicate directly with each other using the following communications: NFMI radio communication; NFeMI radio communication,

Communication, classical->

(BT) communications, WLAN (or "Wi-Fi") communications, or indirectly communicate with each other using WLAN or cellular communications, as will be described below. The components of the system may be suitably configured to support various wireless and wired data communication protocols, techniques, and technologies as required for compatibility with network 210.

The mobile device 206 may be implemented using a variety of different device platforms. For example, mobile device 206 may be implemented as any one of (without limitation): a cellular phone or smart phone; a portable computer (e.g., a laptop computer, a tablet computer, or a netbook computer); a portable media player; a portable video game device; a portable medical device; navigation devices, such as Global Positioning System (GPS) devices; a wearable computing device; an electronic toy or game; etc. According to certain example embodiments, the mobile device 206 supported by the system 200 is implemented as a computer-based or processor-based component. For simplicity and ease of illustration, fig. 2 depicts only one mobile device 206. In practice, however, the system 200 is suitably configured to support a plurality of mobile devices 206, wherein a patient or user owns or operates at least one of the supported mobile devices 206. An exemplary embodiment of a device suitable for implementation as a mobile device 206 is described below with reference to fig. 3.

The remainder of this description assumes that mobile device 206 is a smart phone used by a particular patient. To this end, the configuration and general functionality of the mobile device 206 may be substantially identical to conventional smart phone designs. In this regard, a suitably designed mobile application is installed on the mobile device 206 to allow the patient to receive, view, and interact with messages and notifications provided by the system. The mobile application installed on the mobile device 206 may also be used to provide relevant data to other systems (not shown) for storage and analysis. For example, the mobile application may manage and upload the following information (not limited to): calendar data (time of day, day of week, month, season, etc.); user profile data; GPS data indicating a geographic location of the mobile device 206; map or navigation data associated with the operation of the mobile device 206; meal consumption, food content and/or food ingredient data entered by the user; carbohydrate data entered by the user; exercise related data entered by the user; drug related data entered by a user; user response data associated with the receipt of the blood glucose insight message; user feedback related to blood glucose insight messages; accelerometer data; contact list information; web browser data; purchasing data by a consumer; etc.

In certain embodiments, the insulin infusion device 202 is a portable patient worn or patient carried component that operates to deliver insulin into a patient via, for example, an infuser. According to certain exemplary embodiments, each insulin infusion device 202 supported by the system 200 is implemented as a computer-based or processor-based component. For simplicity and ease of illustration, fig. 2 depicts only one insulin infusion device 202. In practice, however, the system 200 is suitably configured to support a plurality of insulin infusion devices 202, wherein each patient or each user owns or operates at least one of the insulin infusion devices 202. An exemplary embodiment of a device suitable for implementation as an insulin infusion device 202 is described below with reference to fig. 3.

The system 200 obtains input data from one or more sources, which may include various diabetes management devices (insulin infusion devices, continuous glucose monitoring devices, glucose sensors, monitoring devices, etc.). In this regard, insulin infusion device 202 represents the input data source of system 200. In certain embodiments, the insulin infusion device 202 provides data associated with its operation, status, insulin delivery events, and the like. As previously mentioned, depending on the particular implementation of the system 200, the relevant data generated or collected by the insulin infusion device 202 may be transmitted directly or indirectly to other components of the system, including the data upload component 209. The particular type of data provided by the insulin infusion device 202 is described in more detail below.

The patient or user may own or operate the blood glucose meter 207. The blood glucose meter 207 is configured to measure a blood glucose level of a user by analyzing a blood sample. For example, the blood glucose meter 207 may include a container for receiving a blood sample test strip. In this regard, the user inserts the test strip into the glucose meter 207, which analyzes the sample and displays a blood glucose level corresponding to the test strip sample. The blood glucose meter 207 may be configured to communicate the measured blood glucose level to the insulin infusion device 202 (e.g., for storage and processing), to the mobile device 206, or to the data upload component 209. In some scenarios, the patient is responsible for inputting each blood glucose measurement into the insulin infusion device 202. The measured blood glucose data may be provided to any component of the system for analysis.

The glucose sensor 204 may be owned or operated by the patient or user. The glucose sensor 204 is suitably configured to measure glucose levels (e.g., interstitial glucose levels) of the patient in real-time. Glucose sensor 204 may include a wireless transmitter that facilitates transmission of sensor glucose data to other devices, such as insulin infusion device 202 or data upload component 209 or other components of the system, which may be received for further processing.

Depending on the particular embodiment and application, the system 200 may include or cooperate with other devices, systems, and sources of input data. Devices within system 200 may be configured to support transmission of data to various external devices, such as (but not limited to): a stationary monitor device, such as a bedside monitor or a piece of hospital monitoring equipment; a portable computer such as a laptop PC, a palmtop PC or a tablet PC; desktop computers, such as desktop PCs; a personal digital assistant, which may also be a portable email device; one or more additional computing devices or databases; etc. The above list of possible external devices is not exhaustive and implementations of system 200 may be designed to accommodate communication with other systems, devices, computing devices, components, and elements external to system 200. For example, in certain embodiments, the system 200 includes one or more sources of contextual information or data, which may include, but are not limited to: an activity tracker device; meal recording means or applications; an emotion tracking device or application; etc.

The system 200 includes a local infusion system having one or more local devices configured to wirelessly communicate with each other. The present specification may refer to a local infusion system as its "personal area network" or "body area network" that constitutes the device. The local device may be configured to transmit and receive local communications within the local infusion system, wherein such local communications are transmitted and received according to one or more specified local data communication protocols. For example, local communications may be exchanged between local devices using one or more wireless data communication protocols (which may utilize RF, infrared, magnetic induction, or other wireless technologies) and/or using one or more wired data communication protocols. Thus, in the context of this specification, one or more of the local devices may be considered wireless medical devices. The local infusion system may be flexibly configured such that any given local device may communicate with any other local device, and the communication link or path between the two local devices may be unidirectional or bidirectional. Fig. 2 depicts an exemplary embodiment in which each communication link or path is bi-directional (represented by double-headed arrows).

Further, a local device in a local infusion system may be capable of communicating (unidirectional or bidirectional) with one or more "external" devices that are not considered part of the local infusion system. The manner in which a given local device within a local infusion system communicates with a given external device may vary depending on the particular configuration of the system 200, the characteristics of the local device, and the characteristics of the external device. For example, data may be routed between the local infusion system and the external device using one data communication network, using multiple data communication networks, using a direct wireless or wired connection, and so forth.

As mentioned above, the system 200 includes or cooperates with computer-based and/or processor-based components having suitably configured hardware and software that are programmed to perform the functions and methods necessary to support the features described herein. For example, insulin infusion device 202, mobile device 206, blood glucose meter 207, and data upload component 209 may each be implemented as processor-based electronic components.

An exemplary embodiment of an apparatus suitable for implementing the various components of the system will be described below with reference to fig. 3. In this regard, fig. 3 is a simplified block diagram representation of an exemplary embodiment of a computer-based or processor-based device 300 suitable for deployment in the systems shown in fig. 1 and 2. In this regard, each of the devices or components described above with reference to fig. 1-2 may be implemented as a computer-based or processor-based device/component 300. Furthermore, each of the devices or components described below with reference to fig. 4-7 may also be implemented as a computer-based or processor-based device/component 300.

The illustrated embodiment of apparatus 300 is intended as a high-level and general representation of one suitable platform. In this regard, any of the computer-based or processor-based components of system 200 may utilize the architecture of device 300. The illustrated embodiment of the apparatus 300 generally includes (without limitation): at least one processor 302; a suitable amount of memory 304; device-specific hardware, software, firmware, and/or features 306; a user interface 308; a communication module 310; and a display element 311. Of course, implementations of apparatus 300 may include additional elements, components, modules, and functionality configured to support various features unrelated to the subject matter described herein. For example, the apparatus 300 may include certain features and elements to support conventional functions that may be relevant to a particular implementation and deployment of the apparatus 300. In practice, the elements of apparatus 300 may be coupled together via a bus or any suitable interconnect architecture 301.

Processor 302 may be implemented or performed with a general purpose processor, a content addressable memory, a digital signal processor, an application specific integrated circuit, a field programmable gate array, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination designed to perform the functions described herein. Further, the processor 302 may be implemented as a combination of computing devices, e.g., a combination of a digital signal processor and a microprocessor, a combination of multiple microprocessors, a combination of one or more microprocessors with a digital signal processor core, or any other such configuration.

Memory 304 may be implemented as RAM memory, flash memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of storage medium known in the art. In this regard, the memory 304 may be coupled to the processor 302 such that the processor 302 can read information from and write information to the memory 304. In the alternative, the memory 304 may be integral to the processor 302. As an example, the processor 302 and the memory 304 may reside in an ASIC. At least a portion of memory 304 may be implemented as a computer storage medium, such as a tangible computer-readable medium having computer-executable instructions stored thereon. The computer-executable instructions, when read and executed by the processor 302, cause the device 300 to perform certain tasks, operations, functions, and processes that are specific to particular implementations. In this regard, the memory 304 may represent one suitable implementation of such computer-readable media. Alternatively or in addition, the apparatus 300 may receive and cooperate with a computer-readable medium (not separately shown) implemented as a portable or mobile component or platform, such as a portable hard drive, USB flash drive, optical disk, or the like.

The device-specific hardware, software, firmware, and features 306 may vary among different embodiments of the device 300. For example, device-specific hardware, software, firmware, and features 306 will support: smart phone functions and features when the apparatus 300 is implemented as a mobile phone; conventional personal computer functions and features in the case where the apparatus 300 is implemented as a laptop computer or tablet computer; insulin pump operation when the device 300 is implemented as an insulin infusion device; etc. In practice, certain portions or aspects of the device-specific hardware, software, firmware, and features 306 may be implemented in one or more of the other blocks depicted in fig. 3 and 4.

The user interface 308 may include or cooperate with various features to allow a user to interact with the apparatus 300. Thus, the user interface 308 may include various human-machine interfaces, such as a keypad, keys, keyboard, buttons, switches, knobs, touch pad, joystick, pointing device, virtual tablet, touch screen, microphone, or any device, component, or function that enables a user to select options, enter information, or otherwise control the operation of the device 300. The user interface 308 may include one or more Graphical User Interface (GUI) control elements that enable a user to manipulate or otherwise interact with an application via the display element 311.

The communication module 310 facilitates data communication between the device 300 and other components as needed during operation of the device 300. In the context of this specification, the communication module 310 may be used to transmit or stream device-related control data, patient-related data, device-related status or operational data, blood glucose insight messages and notifications, and the like. It should be appreciated that the particular configuration and functionality of the communication module 310 may vary depending on the hardware platform and particular implementation of the apparatus 300. Thus, the communication module 310 is used to obtain input data from various sources and to transmit output data to other components or devices described above with reference to fig. 1 and 2. In practice, embodiments of apparatus 300 may support wireless using various data communication protocolsData communication and/or wired data communication. For example, the communication module 310 may support one or more wireless data communication protocols, techniques, or methods, including (without limitation): RF; irDA (infrared);

(and other variants of the IEEE 802.15 protocol); IEEE 802.11 (any variation); IEEE 802.16 (WiMAX or any other variant); direct sequence spread spectrum; frequency hopping spread spectrum; cellular/wireless/cordless telecommunications protocols; a wireless home network communication protocol; paging network protocol; magnetic induction; satellite data communication protocol; wireless hospital or healthcare facility network protocols, such as network protocols operating in the WMTS band; GPRS; and proprietary wireless data communication protocols, such as variants of wireless USB. In addition, the communication module 310 may support one or more wire/cable data communication protocols, including (without limitation): an Ethernet network; a power line; a home network communication protocol; a USB; IEEE 2394 (firewire); a hospital network communication protocol; and proprietary data communication protocols. In one particular implementation, the communication module 310 includes a far field communication module and a body area network communication module, as well as a controller (not shown).

The far-field communication module includes various far-field communication interfaces that may be used to communicate electromagnetic signals to other devices that are part of the body area network. In this non-limiting example, the various far-field communication interfaces may include (but are not limited to) bluetooth low energy

Communication interface, classical->

A (BT) communication interface, a Wireless Local Area Network (WLAN) communication interface (e.g., wi-Fi interface), and a cellular communication interface. The communication interface may conform to any known standard. For example, a->

The communication interface may follow any +.>

Versions (e.g., versions 1.0 through 5.1) communicate with any Physical (PHY) layer specification defined therein. For example, a->

5.0 includes three PHY layer variants called LE 1M, LE M and LE encoded. Each PHY variant has its own specific characteristics and is designed for a specific purpose. As another non-limiting example,/a->

The communication interface may follow->

Mesh network protocols (defined in mesh profile specifications and mesh model specifications employed in 2017, 7, 13) communicate. />

The mesh protocol is based on Bluetooth Low->

Is allowed to pass->

The radio performs many-to-many communication.

When a signal from the far field communication interface is transmitted by the antenna, it is attenuated in distance to a point where the signal cannot be effectively detected. This is known as far field transmission and works well if the signal needs to be transmitted over long distances. However, far field communication interfaces can be problematic if wireless communication requires very low power and is limited to a relatively short distance in the vicinity of the body area. Incorrect placement of devices close to the human body may result in detuned antenna input impedance, reduced antenna efficiency, and distorted antenna radiation patterns. Penetration of electromagnetic signals generated by far-field communication interfaces into the human body is Another problem is that electromagnetic signals can be rapidly absorbed and greatly attenuated due to the strong electrical conductivity of human tissue. Further, since a plurality of far-field communication interfaces (e.g., BT,

Wi-Fi and->

) The interference can be very large. Power consumption may also limit continuous operation. Finally, far field communication interfaces can present potential security issues because electromagnetic signals can be intercepted and decrypted after propagating into free space.

In another aspect, the body area network communication module includes various near field communication interfaces that may be used to deliver magnetic signals to other devices that are part of the body area network. In this non-limiting example, the various near field communication interfaces may include, but are not limited to, a Near Field Magnetic Induction (NFMI) radio communication interface, a near field electromagnetic induction (nfemii) radio communication interface (not shown), a Near Field Communication (NFC) interface, an RFID High Frequency (HF) communication interface, and one or more Low Power Wide Area Network (LPWAN) communication interfaces. Near field communication interfaces may provide more reliable, safer, and much lower power radio links within, on, and near the human body.

For example, NFMI is a short-range wireless technology that uses tightly coupled magnetic fields for communication between devices. NFMI enables human-friendly, reliable, secure, and power efficient wireless communications. As used herein, the term "Near Field Magnetic Induction (NFMI) radio communication system" may refer to a short range wireless physical layer that communicates by coupling a tight, low power, non-propagating magnetic field between devices. The transmitter coil in one device may modulate the magnetic field measured by the receiver coil in the other device. For further explanation, in NFMI-based communication systems, the modulated signal emanating from the transmitter coil is in the form of a magnetic field. The magnetic field induces a voltage on the receive coil, which in turn will be measured by the NFMI receiver. NFMI radio communication system communicating with other wireless Except that most conventional wireless RF systems use antennas to generate, transmit and propagate electromagnetic waves, where all of the transmitted energy is designed to radiate into free space. This type of transmission is referred to as the "far field". NFMI systems are designed to contain the transmitted energy within a local magnetic field. This magnetic field energy resonates around the communication system but does not radiate into free space. For further explanation, and

the power density of the NFMI signal decays at a rate inversely proportional to the distance to the sixth power compared to the second power of the signal. This means that for the same distance, if the two transmission powers are equal, the power density ratio of the NFMI signal is +.>

The signal is 10000 times weaker. This type of wireless transmission is referred to as "near field". Various modulation schemes (e.g., amplitude modulation, phase modulation, and frequency modulation) used in typical RF communications may also be used in near field magnetic induction communication systems.

As used herein, the term "near field electromagnetic induction (NFeMI) radio communication interface" may refer to a communication interface that may operate in the vicinity of the human body by a combination of magnetic and electric fields without using transverse radiated waves. Such NFEMI systems improve the signal link budget of wearable devices and extend their range to the entire human body. Whereas RF wireless communication can be achieved by propagating RF plane waves in free space, NFEMI communication utilizes non-propagating quasi-static fields.

As used herein, the term "Near Field Communication (NFC)" may refer to a set of communication protocols and data exchange formats that enable two or more electronic devices (e.g., medical devices such as insulin pumps and portable devices such as smartphones) to establish communication with each other by bringing them within a short range of separation (e.g., 2 meters or less) of each other. NFC allows one-way and two-way communication between endpoints, suitable for many applications. NFC uses electromagnetic induction between two loop antennas (located in the near field of each other) to effectively form a hollow core transformer that allows them to exchange information. The NFC interface operates based on a similar principle as the NFMI interface 322 and uses the same High Frequency (HF) band. However, NFMI extends the range of NFC (e.g., a distance from 1 inch to 4 inches of NFC to up to 9 feet of NFMI). At about 13MHz, NFMI uses time division to provide data rates in excess of 400Kbps per channel, up to 10 separate channels and 10 sub-channels per channel (e.g., 100 separate radio links within a single WBAN). In one non-limiting implementation, the NFC-enabled devices described herein can exchange information according to any NFC standard that covers communication protocols and data exchange formats. The NFC standard encompasses communication protocols and data exchange formats and is based on existing Radio Frequency Identification (RFID) standards including ISO/IEC 14443. The standard includes ISO/IEC 18092 and the standard defined by the NFC forum. In addition to the NFC forum, the GSM association (GSMA) group defines a platform for deploying GSMA NFC standards within mobile handsets.

RFID systems can operate in Low Frequency (LF), high Frequency (HF), and Ultra High Frequency (UHF) bands, and thus can be classified by the frequency band in which they operate: low frequency, high frequency and ultra high frequency. In addition, there are two broad classes of systems-passive and active RFID. The LF band covers frequencies from 30KHz to 300KHz (e.g., some LF RFID systems operate at 125KHz, while other LF RFID systems operate at 134 KHz). The RFID HF communication interface 326 may operate in the HF band of 3MHz to 30MHz, with a communication range between 10cm and 1 m. There are several HF RFID standards, such as the ISO 15693 standard for tracking items, and the ECMA-340 and ISO/IEC 18092 standards for Near Field Communication (NFC), ISO/IEC 14443A and ISO/IEC 14443 standards. The UHF band covers a range from 300MHz to 3GHz, and some UHF systems can range up to 12m with faster data transfer rates than LF or HF. The UHF band is regulated by a single global standard called the ECPglobal Gen2 (ISO 18000-63) UHF standard.

The Low Power Wide Area Network (LPWAN) communication interface may include interfaces such as a long term evolution (LTE-M) communication interface (LTE-Cat M1) and/or a narrowband-IoT (NB-IoT) communication interface (not shown) for the machine. NB-IOT and LTE-M are two newer Low Power Wide Area (LPWA) technologies developed for IOT applications. Both protocols are protocols for low bandwidth cellular communication connected to internet devices that need to transmit small amounts of data, with lower costs (hardware and subscription) and higher battery life.

The various communication interfaces mentioned above are non-limiting and may be implemented according to any known standard including those mentioned above. However, it should be understood that the number of communication interfaces included as part of the communication module 310 may vary depending on the implementation.

A controller (not shown) may be configured to control which communication interfaces are selected and used by a device or component of the wireless body area network to communicate data with other devices or components that are part of the wireless body area network. For example, the controller is configured to select which of the communication interfaces to use at any particular time and switch between which of the communication interfaces is enabled and used by a device or component of the wireless body area network to communicate data with other devices or components that are part of the wireless body area network.

Referring again to fig. 3, the display element 311 is suitably configured to enable the apparatus 300 to present and display various screens, insight messages, notifications, GUIs, GUI control elements, drop-down menus, autofill fields, text input fields, message fields, and the like. Of course, the display element 311 may also be used to display other information during operation of the device 300, as is well understood. It is noted that the particular configuration, operating characteristics, size, resolution, and functionality of the display element 310 may vary depending on the actual implementation of the device 300. For example, if the device 300 is a laptop computer, the display element 311 may be a relatively large monitor. Alternatively, if the device 300 is a cellular telephone device (e.g., a smart phone), the display element 311 may be a relatively small integrated display screen, such as a touch-sensitive screen.

Fig. 4 depicts an exemplary embodiment of a patient monitoring system 400. The patient monitoring system 400 includes a medical device 402 communicatively coupled to a sensing element 404 that is inserted into or otherwise worn by a patient to obtain measurement data indicative of a physiological condition in the patient's body, such as a sensed glucose level. Medical device 402 is communicatively coupled to non-medical device 406 via a communication network 410, wherein non-medical device 406 is communicatively coupled to a server system 414 via another communication network 412. In this regard, the non-medical device 406 may serve as an intermediate for uploading or otherwise providing measurement data from the medical device 402 to the server system 414. It should be appreciated that fig. 4 depicts a simplified representation of a patient monitoring system 400 for purposes of explanation, and is not intended to limit the subject matter described herein in any way. In particular, although the term "client" is used to describe the role of the device 406 with respect to the medical device 402 and the server system 414, it should be understood that in other embodiments, the device 406 may not exhibit the same relationship. For example, in some embodiments, the device 406 may be a client device relative to the medical device 402 and a server device relative to the server system 414.

In an exemplary embodiment, non-medical device 406 is implemented as a mobile phone, smart phone, tablet computer, or other similar mobile electronic device; however, non-medical device 406 may be implemented as any kind of electronic device capable of communicating with medical device 402 via network 410, such as a laptop or notebook computer, desktop computer, or the like. In an exemplary embodiment, network 410 is implemented as a BLUETOOTH network, a ZIGBEE network, or another suitable personal area network. Nonetheless, in some embodiments, the network 410 may be implemented as a wireless ad hoc network, a Wireless Local Area Network (WLAN), or a Local Area Network (LAN). The non-medical device 406 includes or is coupled to a display device (such as a monitor, screen, or another conventional electronic display) that is capable of graphically presenting data and/or information related to the physiological condition of the patient. The non-medical devices 406 also include or are otherwise associated with user input devices (such as keyboards, mice, touch screens, etc.) that are capable of receiving input data and/or other information from a user of the non-medical devices 406.

In an exemplary embodiment, a user (such as a patient, a patient's doctor or another healthcare provider, etc.) manipulates a non-medical device 406 to execute a client application 408 that supports communication with the medical device 402 via a network 410. In this regard, the client application 408 supports establishing a communication session with the medical device 402 over the network 410 and receiving data and/or information from the medical device 402 via the communication session. Medical device 402 may similarly execute corresponding applications or processes that support establishing a communication session with client application 408. Client application 408 generally represents a set of instructions that are executed by non-medical device 406 to perform or facilitate performance of at least some of the processes described herein. Accordingly, non-medical device 406 generally includes a processing system and a data storage element (or memory) capable of storing programming instructions for execution by the processing system that, when read and executed, cause the processing system to perform or facilitate the performance of the processes, tasks, operations, and/or functions described herein. Depending on the implementation, the processing system may be implemented using any suitable processing system and/or device, such as one or more processor devices, central Processing Units (CPUs), controllers, microprocessors, microcontrollers, processing cores configured to support the operation of the processing system described herein, and/or other hardware computing resources. Similarly, the data storage elements or memories may be implemented as Random Access Memory (RAM), read Only Memory (ROM), flash memory, magnetic or optical mass storage, or any other suitable non-transitory short-term or long-term data storage or other computer readable medium and/or any suitable combination thereof.

In one or more embodiments, non-medical device 406 and medical device 402 establish an association (or pairing) with each other through network 410 to support a subsequent establishment of a peer-to-peer or peer-to-peer communication session between medical device 402 and non-medical device 406 via network 410. For example, according to one embodiment, network 410 is implemented as a BLUETOOTH network in which medical device 402 and non-medical device 406 pair with each other (e.g., by obtaining and storing network identification information for each other) based on performing a discovery process or another suitable process. Pairing information obtained during the discovery process may allow either the medical device 402 or the non-medical device 406 to initiate establishment of a secure communication session via the network 410.

In one or more exemplary embodiments, client application 408 is further configured to store or maintain address and/or other identifying information for server system 414 on second network 412. In this regard, the second network 412 may be physically and/or logically distinct from the network 410, such as the internet, a cellular network, a Wide Area Network (WAN), and the like. In some embodiments, the server system 414 represents a server or other computing device hosting a cloud-based service 415 and configured to receive and analyze or otherwise monitor measurement data, event log data, and potentially other information obtained for a patient associated with the medical device 402. In an exemplary embodiment, the server system 414 is coupled to a database 416 configured to store or hold data associated with individual patients. In practice, the server system 414 may reside at a location physically distinct and/or separate from the medical device 402 and the non-medical device 406, such as at a facility owned and/or operated by or otherwise affiliated with the manufacturer of the medical device 402. For purposes of explanation and not limitation, the server system 414 may alternatively be referred to herein as a server. It should be appreciated that in some embodiments, the server system 414 may be a client device, both a server device and a client device, or neither a server device nor a client device.

Still referring to fig. 4, the sensing element 404 generally represents a component of the patient monitoring system 400 configured to generate, and/or output one or more electrical signals indicative of a physiological condition sensed, measured, and/or quantified by the sensing element 404. In this regard, the physiological condition of the patient affects the characteristics of the electrical signal output by the sensing element 404 such that the characteristics of the output signal correspond to or are otherwise related to the physiological condition to which the sensing element 404 is sensitive. In an exemplary embodiment, the sensing element 404 is implemented as an interstitial glucose sensing element inserted at a location on the patient's body that generates an output electrical signal having a current (or voltage) associated therewith that is related to an interstitial fluid glucose level sensed or otherwise measured by the sensing element 404 in the patient's body.

The medical device 402 generally represents a component of the patient monitoring system 400 that is communicatively coupled to an output of the sensing element 404 to receive or otherwise obtain a measurement data sample (e.g., measured glucose and characteristic impedance values) from the sensing element 404, store or save the measurement data sample, and upload or otherwise transmit the measurement data to the server system 414 or server via the non-medical device 406. In one or more embodiments, the medical device 402 is implemented as an infusion device 102, 200 configured to deliver a fluid (such as insulin) to a patient's body. Nonetheless, in some other embodiments, the medical device 402 may be a stand-alone sensing or monitoring device separate from and independent of the infusion device (e.g., sensing arrangement 104, 404). It should be noted that although fig. 4 depicts the medical device 402 and the sensing element 404 as separate components, in practice the medical device 402 and the sensing element 404 may be integrated or otherwise combined to provide a unitary device that may be worn by a patient.

In an exemplary embodiment, the medical device 402 includes a controller 422, a data storage element 424 (or memory), and a communication interface 426. Controller 422 generally represents hardware, circuitry, logic components, firmware, and/or other components of medical device 402 that are coupled to sensing element 404 to receive electrical signals output by sensing element 404 and to perform or facilitate performance of various additional tasks, operations, functions, and/or processes described herein. Depending on the implementation, controller 422 may be implemented or realized using general purpose processor devices, microprocessor devices, controllers, microcontrollers, state machines, content addressable memories, application specific integrated circuits, field programmable gate arrays, any suitable programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof, designed to perform the functions described herein. In some embodiments, controller 422 includes an analog-to-digital converter (ADC) or another similar sampling arrangement that samples or otherwise converts the output electrical signal received from sensing element 404 into a corresponding digital measurement data value. In other embodiments, the sensing element 404 may incorporate an ADC and output a digital measurement.

Communication interface 426 generally represents hardware, circuitry, logic, firmware, and/or other components of medical device 402 that are coupled to controller 422 to output data and/or information from medical device 402 to/from non-medical device 406. For example, the communication interface 426 may include or otherwise be coupled to one or more transceiver modules capable of supporting wireless communication between the medical device 402 and the non-medical device 406. In an exemplary embodiment, the communication interface 426 is implemented as a bluetooth transceiver or adapter configured to support Bluetooth Low Energy (BLE) communications.

In an exemplary embodiment, the server system 414 receives measurement data values (e.g., sensor glucose measurements, acceleration measurements, etc.) associated with a particular patient that were obtained using the sensing element 404 from the non-medical devices 406, and the server system 414 stores or otherwise saves the historical measurement data in a database 416 associated with the patient (e.g., using one or more unique patient identifiers). In addition, server system 414 may also receive meal data or other event log data from or via non-medical device 406 that may be entered or otherwise provided by the patient (e.g., via client application 408), and store or otherwise save historical meal data and other historical event or activity data associated with the patient in database 416. In this regard, the meal data includes, for example, a time or timestamp associated with a particular meal event, a meal type or other information indicative of the content or nutritional characteristics of the meal, and an indication of the size associated with the meal. In an exemplary embodiment, the server system 414 also receives historical fluid delivery data corresponding to a fluid base or bolus dose delivered by the infusion device 102, 200 to the patient. For example, the client application 408 may communicate with the infusion device 102, 200 to obtain the amount of insulin delivery dose and the corresponding timestamp from the infusion device 102, 200, and then upload the insulin delivery data to the server system 414 for storage in association with a particular patient. The server system 414 may also receive geographic location data and potentially other context data associated with the devices 402, 406 from the non-medical devices 406 and/or the client application 408, and store or otherwise save historical operational context data associated with a particular patient. In this regard, one or more of the devices 402, 406 may include a Global Positioning System (GPS) receiver, or similar module, component, or circuitry capable of outputting or otherwise providing data representative of the geographic location of the respective device 402, 406 in real-time.

The historical patient data may be analyzed by one or more of the server system 414, the non-medical device 406, and/or the medical device 402 to alter or adjust the operation of the infusion device 102, 200 to affect fluid delivery in a personalized manner. For example, the patient's historical meal data and corresponding measurement data or other background data may be analyzed to predict a future time at which the patient may consume the next meal, a likelihood of a future meal event within a particular time period, a likely size or quantity of carbohydrates associated with the future meal, a likely type or nutritional composition of the future meal, and so forth. Further, historical measurement data of the patient's post-meal period following a historical meal event may be analyzed to model or otherwise characterize the patient's predicted size and type of glycemic response to a meal of the current context (e.g., time of day, day of week, geographic location, etc.). One or more aspects of the infusion device 102, 200 that control or regulate insulin delivery may then be modified or adjusted to actively take into account the patient's likely dining activity and glycemic response.

In one or more exemplary embodiments, the server system 414 utilizes machine learning to determine which combination of historical sensor glucose measurement data, historical delivery data, historical assistance measurement data (e.g., historical acceleration measurement data, historical heart rate measurement data, etc.), historical event log data, historical geographic location data, and other historical or background data relates to or predicts the occurrence of a particular event, activity, or metric for a particular patient, and then determines a corresponding equation, function, or model for calculating the parameter value of interest based on the set of input variables. Thus, the model can characterize a particular combination of one or more of current (or recent) sensor glucose measurement data, assistance measurement data, delivery data, geographic location, patient behavior or activity, etc., or map that particular combination to a value representing a current probability or likelihood of a particular event or activity or a current value of a parameter of interest. It should be noted that because each patient's physiological response may be different from the other population, the subset of input variables predicted or associated with a particular patient may be different from the other patient. Additionally, based on different correlations between a particular input variable and historical data for that particular patient, the relative weighting applied to the respective variables of the prediction subset may also be different from other patients who may have a common prediction subset. It should be noted that the server system 414 may utilize any number of different machine learning techniques to determine what input variables predict a patient of current interest, such as artificial neural networks, genetic programming, support vector machines, bayesian networks, probabilistic machine learning models or other bayesian techniques, fuzzy logic, combinations of heuristic derivatives, and the like.

The insulin infusion device may incorporate or utilize control algorithms, processing schemes and operating methods (or appropriately modified, updated or customized versions thereof) of the type described in U.S. patent No. 9,526,834 and international (PCT) patent publication No. WO 2014/035570; the contents of these publications are incorporated herein by reference.

Fig. 5 is a flow chart illustrating a medical device configuration method 500 for configuring one or more medical devices 402 to be provided to a patient 501 in accordance with the disclosed embodiments. For illustrative purposes, the following description of method 500 may refer to elements mentioned above in connection with fig. 1-4, and method 500 will be described with reference to certain elements of fig. 4 to illustrate one possible non-limiting implementation; however, it should be understood that the method 500 may be implemented in a variety of different system architectures. Fig. 5 illustrates interactions that occur involving a prescriber 510 (e.g., a doctor or other healthcare provider) of a medical device 402, a server system 414 of a medical device manufacturer hosting a cloud-based service 415, a fulfillment system 520 of the medical device manufacturer, and a payor 522. The device configuration method 500 may be used to automatically and properly configure any number of unprogrammed/unconfigured medical devices that have been prescribed to a particular patient such that those medical devices are specifically configured for that particular patient. For example, an unprogrammed medical device may refer to a device that lacks firmware, while an unconfigured medical device may refer to a device that is programmed with firmware but lacks user-specific configuration parameters.

At 530, the healthcare provider 510 prescribes a particular medical device 402 to the patient 501. At 532, the healthcare provider 510 can enter a device prescription, which is sent to the service 415 provided by the cloud-based server system 414. The service 415 may be provided, for example, by the manufacturer of the medical device. The prescription may include various types of information including, but not limited to, patient identification information, therapy type, and health data for the patient 501 (e.g., device model, patient diagnosis, etc.).

At 534, the service 415 provided by the cloud-based server system 414 communicates an approval/authorization request to the payer 522 (e.g., insurance company). The approval request may include conditions such as patient identification information, therapy type, and the like. At 536, the payer 522 may confirm approval of the device prescription for the patient 501 and send an approval confirmation to the service 415 provided by the cloud-based server system 414. The approval confirmation may also include information such as patient identification information, therapy type, and the like. At 538, the service 415 may send an approval confirmation to the healthcare provider 510.

At 540, the service 415 provided by the cloud-based server system 414 may submit a device order including patient identification information to the medical device manufacturer's fulfillment system 520. At 542, the fulfillment system 520 of the medical device manufacturer may ship one or more unprogrammed/unconfigured medical devices 402 to the patient 501. At 544, the service 415 provided by the cloud-based server system 414 may generate a parameter load. The parameter load may be a file or some other data set that includes, for example, configuration data for therapy settings for the medical device 402 based on information such as patient-specific data, device prescriptions, and/or therapy types prescribed for the particular patient 501. In some implementations, the parameter load may be a customized patient-specific firmware image (e.g., a snapshot or some other representation of the device state at a particular point in time, including parameter values and settings). In some embodiments, the service 415 may process patient-specific data, therapy types prescribed for a particular patient, and device prescriptions to select an appropriate therapy configuration (e.g., algorithm/software/mode of operation) for the medical device for the particular patient 501, and may process patient-specific data (as well as other potential inputs, such as therapy types prescribed for a particular patient, and device prescriptions) to calculate, estimate, select, or otherwise determine detailed therapy parameters and settings, such as appropriate device configuration parameters or settings for configuring the medical device for the particular patient 501, and therapy configuration parameters for configuring the medical device for the particular patient 501. Service 415 may then combine all of this information into a parameter load. Thus, the parametric load may include, but is not limited to, configuration data for therapy settings, including: appropriate therapy configuration (e.g., algorithm/software/mode of operation) for the medical device of the particular patient 501, and therapy parameters and settings for the medical device (e.g., appropriate device configuration parameters or settings for configuring the medical device of the particular patient 501, and therapy configuration parameters for configuring the medical device of the particular patient 501).

At 546, once the configuration data for the therapy settings is generated, the service 415 provided by the cloud-based server system 414 may optionally send a confirmation request to the healthcare provider 510. Thus, in some embodiments, the parameter load may be generated without review by the healthcare provider 510. In the example of fig. 5, the confirmation request may include, for example, information (such as patient identification information) and parameter load. At 548, the healthcare provider 510 can view the confirmation request to ensure that the configuration data for the proposed therapy setting is correct for the particular patient 501. Once the healthcare provider 510 confirms that the configuration data for the proposed therapy settings is correct for the particular patient 501, the healthcare provider 510 may send a confirmation message.

At 550, in response to the confirmation message, the service 415 provided by the cloud-based server system 414 may provide configuration data (e.g., including parameter loads) for the therapy settings to the medical device 402 of the patient 501. In some implementations, the cloud-based server system may push configuration data for therapy settings to the medical device. In some other implementations, configuration data for a therapy setting may be extracted by a medical device from the cloud-based server system 414. Further, it should be noted that cloud-based server system 414 may provide configuration data for therapy settings to the medical device through a direct connection or an indirect connection (e.g., via a WLAN connection to the device itself or via a smart phone application on the internet). Once the device is configured according to the configuration data set for the therapy, the medical device 402 may be activated at 552 and the patient 501 may begin receiving the therapy. The medical device 402 may be activated in a variety of different ways, depending on the embodiment. In some embodiments, the medical device 402 may be activated when the medical device 402 is powered on. In some embodiments, the medical device 402 may be activated when the medical device 402 receives instructions, commands, or other user input to begin providing therapy to the user. Instructions, commands, or other user inputs may be initiated through interaction with a user interface element, such as a physical button or equivalent on a medical/non-medical device, a graphical user interface element displayed on a display device/component included in or coupled to a medical/non-medical device, or any other device that is selectable by a user to activate medical device 402. For example, the patient may press one or more buttons to activate the medical device 402 according to the order of the one or more presses that were made. Alternatively, the patient may interact with one or more user interface elements of the medical device 402 or another non-medical device to activate the medical device 402. In some embodiments, the medical device 402 may be activated when the medical device 402 is placed on or within a patient's body (e.g., mounted on or within the patient's body). In some embodiments, the medical device 402 may be activated when the medical device 402 detects deployment (e.g., detects that it has been placed on the patient's body). This may be accomplished by a variety of means including, but not limited to: activation of the cannula insertion mechanism, signals from skin contact sensors (e.g., indicative of sweat detection, body impedance detection, optical identification/detection, capacitance detection, or temperature detection), signals from mechanical switches between the device and the patient, signals from integrated glucose sensors that detect contact with interstitial fluid, and the like. In some embodiments, the medical device 402 may be activated when the medical device 402 performs and/or detects any combination of the above.

Fig. 6 is a flow chart illustrating a setting generation method 600 for generating a setting with which to configure one or more medical devices 402 to be provided to a patient 501 in accordance with the disclosed embodiments. For illustrative purposes, the following description of method 600 may refer to elements mentioned above in connection with fig. 1-5, and method 600 will be described with reference to certain elements of fig. 4 to illustrate one possible non-limiting implementation; however, it should be understood that the method 600 may be implemented in a variety of different system architectures. Fig. 6 illustrates interactions that occur involving a prescriber 510 (e.g., a doctor or other healthcare provider) of a medical device 402, a server system 414 of a medical device manufacturer hosting a cloud-based service 415, and a payer 522. Method 600 may be used with method 500 of fig. 5. The method 600 may be used to generate one or more settings for configuring any number of unprogrammed/unconfigured medical devices appropriately for a particular patient 501, such that those medical devices may be specifically configured for that particular patient 501.

At 620, the healthcare provider 510 may prescribe a particular medical device to the patient 501 by: the inputs are, for example, medical device prescriptions and therapy types for the patient 501 that are sent to the service 415 provided by the cloud-based server system 414. The medical device prescription for the patient 501 may include, for example, patient identification information for the patient 501 as well as other information (such as a diagnosis for the particular patient 501). While this is one possible implementation, it should also be noted that in other implementations, this information may be provided to the service 415 in other ways as well. In some implementations, the type of therapy prescribed for a particular patient can be prescribed, for example, in the following cases: when the system generates settings, then the HCP approves the settings before deploying them to the medical device. This can be applied to the following cases: when the patient is out of the device, or later when a therapy update may be needed due to a change in patient condition or the availability of new therapies that may not require a new device. In some implementations, the type of therapy for a particular patient can be prescribed, for example, in the following cases: when the HCP initiates an update and the system runs the analysis to suggest updated parameters. In some implementations, the type of therapy prescribed for a particular patient can be prescribed, for example, in the following cases: when the HCP updates the settings based on its analysis, but uses the system to download updated parameters determined based on its analysis. In some implementations, the type of therapy prescribed for a particular patient can be prescribed, for example, in the following cases: when the system periodically automatically generates an update-based analysis, or when triggered by some measured parameter (e.g., BG level that is not within the desired range). In some implementations, the type of therapy prescribed for a particular patient can be prescribed, for example, in the following cases: when the downloaded updated parameters may not require approval from the HCP. The system may download the updates directly to the patient's medical device.

At 622, the service 415 provided by the cloud-based server system 414 communicates the request for approval to the payer 522 (e.g., insurance company). The request for approval may include things such as the patient 501 identifier, a diagnosis, etc.

At 624, the payer 522 may confirm approval of the device prescription for the patient 501, and send an approval confirmation to the service 415 provided by the cloud-based server system 414. The approval confirmation may also include information such as the patient 501 identifier. At 626, service 415 provided by cloud-based server system 414 may send an approval confirmation to healthcare provider 510.

At 628 through 634, the healthcare provider 510 may enter various patient-specific data that may be used by the service 415 to generate configuration data for the therapy settings for the particular patient 501. The particular order of entering patient-specific data may vary with the particular implementation. The patient-specific data may include various types of information including, but not limited to: basic patient data (entered at step 628), patient lifestyle data (entered at step 630), information about medical conditions targeted for therapy, information about medical conditions other than conditions targeted for therapy (entered at step 632, such as diabetes therapy history), previously known therapy parameters (entered at step 634), and the like. Examples of basic patient data may include physical data, metabolic data, or anatomical data about a patient, including things such as patient identification information, age, height, weight of a patient, information about other medical conditions (or complications), and the like. The patient lifestyle data may include things like habits of the patient, such as data about the patient's diet, data about the patient's exercise characteristics, sleep habits, and so forth. The information about the medical condition targeted for therapy and the information about medical conditions other than the condition targeted for therapy (which in the case of diabetes) may include information about the patient's diabetes therapy history (e.g., diabetes treatment details/history), including information such as patient identification information, clinical diagnosis, daily insulin dose to the patient, A1C to the patient, time in range to the patient, therapy targets (e.g., preference for actively controlling diabetes and preference for minimizing burden), and the like. The previously known therapy parameters may include such things as patient identification information, therapy algorithms or device modes of operation, patient's insulin sensitivity coefficient, patient's insulin to carbohydrate ratio, patient's insulin delivery rate limit, basal rate profile for the patient, target glucose level for the patient, and the like.

Generally, the selection of the therapy algorithm and software configuration and the calculation of the therapy parameters are a function of the inputs provided by the prescribing healthcare provider 510. However, in some embodiments, other information provided by the manufacturer of the medical device, such as patient history, statistics, mathematical models, etc., may also be utilized to select an appropriate therapy algorithm and software configuration, and/or to calculate therapy parameters, configuration data, settings, etc. Additionally or alternatively, in some implementations, a computer-based or software-based system may collect information about the patient from different sources, and this information may then be used to calculate or look up device configuration data, settings, parameters, and the like.

Based on the information entered by the healthcare provider 510 at step 620 and steps 628-634, the service 415 may select an appropriate therapy configuration (e.g., algorithm/software/mode of operation) for the medical device for configuring the medical device for the particular patient 501 at 636.

Each different model of medical device can be configured for a different therapy configuration. At least some of the patient-specific data may be used to configure or adjust therapy parameters of the therapy algorithm/software to configure the medical device for the particular patient 501. At 638, the service 415 may calculate, estimate, select, or otherwise determine appropriate detailed therapy parameters and settings (e.g., appropriate device configuration parameters or settings for configuring the medical devices of the particular patient 501, and therapy configuration parameters for configuring the medical devices of the particular patient 501). Appropriate therapy parameters and settings may be determined or generated based on at least some of the information entered by the healthcare provider 510 at steps 628-634 and at step 620 (e.g., the type of therapy prescribed for a particular patient and the device prescription). As described above, service 415 may combine all of this information into a parameter load.

At 640, once the service 415 provided by the cloud-based server system 414 selects the appropriate therapy configuration (e.g., appropriate therapy algorithms/software) for the medical device and generates the appropriate therapy parameters and settings to be used to configure the medical device, the service 415 may communicate a confirmation request to the healthcare provider 510. The confirmation request may include information such as patient identification information and configuration data for the therapy settings, including: appropriate therapy types/algorithms/software for the particular patient 501, appropriate device configuration parameters or settings for configuring the medical device of the particular patient 501, therapy configuration parameters for configuring the medical device of the particular patient 501, and the like.

At 642, the healthcare provider 510 can view the confirmation request to ensure that the suggested therapy settings are appropriate and correct for the particular patient 501. Once the healthcare provider 510 confirms that the proposed therapy settings are correct for the particular patient 501, the healthcare provider 510 may send a confirmation message (which includes patient identification information for the particular patient 501) to the service 415 provided by the cloud-based server system 414 to confirm that the proposed therapy settings are appropriate and correct for the particular patient 501.

At 644, in response to the confirmation message, service 415 may save configuration data for the confirmed therapy settings for the particular patient 501 in a database (not shown) of server system 414. Some of the information included in the configuration data for the therapy settings (e.g., required for proper configuration of the medical device) may be sensitive. Instead of requiring the patient and physician to store a human-readable copy of this information, the process allows the physician to enter all therapy data into a secure online system. The settings generated by this process may be stored and transmitted to the patient's device entirely within an encrypted, authenticated channel to prevent unauthorized disclosure.

Although not shown in fig. 6, the service 415 may retrieve from the database and send configuration data for validated (i.e., appropriate for the particular patient 501) therapy settings to the medical devices of the patient 501 so that the medical devices may be configured according to the configuration data for the therapy settings for the particular patient 501. This may be done before or after the device is shipped or delivered to the patient.

For example, in some implementations, configuration data for a therapy setting may be programmed into the device by the manufacturer at or prior to shipment to the patient. In other words, the medical device may be programmed "on the fly" prior to shipment to the patient. In some other implementations, the configuration data for the therapy settings may be programmed into the unconfigured device after the device is delivered to the patient (e.g., via a direct internet connection or by means of an auxiliary device such as a smart phone or PC). Alternatively, configuration data for a therapy setting may be electronically transmitted to a patient in human readable form for manual input.

In some implementations, the configuration process may occur a number of times to populate alternative or alternative devices with the same configuration data. For example, in some cases, multiple devices may be sent to the patient in a single shipment to support alternate use (one device operating while another device is charging) or as part of a disposable device model. Alternatively, when existing devices reach their useful life, new devices may be sent to the patient again.

These variations can extend the behavior of the system in a number of ways. Each device may be programmed with the same therapy configuration by the cloud service, all simultaneously (as received by the patient) or as each device enters the service. Each device may be programmed with an updated therapy configuration by the cloud service as it enters the service. The therapy configuration may be updated based on data sent back from a prior device, updates made by the prescribing physician, or other information known to the cloud service. Each new device may receive updated therapy configurations from the previous device over a local data network (such as bluetooth or Wi-Fi). The transfer process may not involve cloud services. Once the medical device is properly configured and activated, the patient 501 may begin receiving therapy.

Fig. 7 is a flow chart illustrating a medical device configuration method 700 for configuring one or more medical devices to be provided to a patient in accordance with the disclosed embodiments. As a preliminary matter, it should be appreciated that the method 700 is provided in a non-limiting example. Fig. 7 shows one possible embodiment of the prescribing process. In the description of fig. 7, a particular example is described in which a cloud-based service 415 provided by a cloud-based server system 414 performs certain prescribing actions by interacting with prescribing physicians and payors as described above with reference to fig. 1-6.

Referring to method 700, tasks may be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that method 700 may include any number of additional or alternative tasks, the tasks shown in fig. 7 need not be performed in the illustrated order, and that method 700 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Further, one or more of the tasks shown in fig. 7 may potentially be omitted from an embodiment of method 700 as long as the intended overall functionality remains intact. It should also be appreciated that the illustrated method 700 may be stopped at any time.

Method 700 is computer-implemented in that the various tasks or steps performed in connection with method 700 may be performed by software, hardware, firmware, or any combination thereof. In some embodiments, some or all of the tasks and/or substantially equivalent tasks of the process are performed by execution of processor readable instructions stored or embodied on a processor readable medium. For illustrative purposes, the following description of method 700 may refer to elements mentioned above in connection with fig. 1-6, and method 700 will be described with reference to certain elements of fig. 4 to illustrate one possible non-limiting implementation; however, it should be appreciated that the method 700 may be implemented in a variety of different system architectures. For example, in the description of fig. 7 below, cloud-based services 415 provided by cloud-based server system 414 will be described as performing various actions, tasks, or steps, but it should be understood that this refers to the processing systems of these entities executing instructions to perform these various actions, tasks, or steps. Depending on the implementation, method 700 may be performed by an application or service 415 hosted at cloud-based server system 414.

At 702, the physician enters an initial prescription, and at 704, the payer approves the prescription. At 706, the physician may enter patient-specific data. Patient specific data is used to select therapy types and parameters. Patient-specific data may include, but is not limited to, basic patient data (e.g., age, height, weight, complications, etc.), patient lifestyle data (e.g., diet and exercise habits, etc.), diabetes therapy history (e.g., total daily dose of insulin (TDD), A1C, time-in-range, etc.), any known configuration parameters from prior therapy devices (e.g., ISF, I2 CHO).

At 708, the therapy settings may be determined by the cloud-based service 415 provided by the cloud-based server system 414. Step 708 may include selecting an appropriate therapy configuration for the medical device for the particular patient 501 and calculating detailed therapy parameters. In some embodiments, the service 415 may process the patient-specific data, therapy type, and device prescription and select an appropriate therapy configuration (e.g., algorithm/software/mode of operation) for the medical device for the particular patient 501, and may process the patient-specific data, therapy type, and device prescription to calculate or otherwise determine detailed therapy parameters and settings for the medical device, such as appropriate device configuration parameters or settings for configuring the medical device for the particular patient 501, and appropriate therapy configuration parameters for configuring the medical device for the particular patient 501. Service 415 may combine all of this information into a parameter load.

Thus, the parameter load may include configuration data for therapy settings, including, but not limited to: an appropriate therapy configuration (e.g., algorithm/software/mode of operation) for the medical device of the particular patient 501, an appropriate device configuration parameter or setting for configuring the medical device of the particular patient 501, and an appropriate therapy configuration parameter for configuring the medical device of the particular patient 501.

At 710, the physician may approve the therapy prescription if the therapy prescription (specified by the parameter load) is appropriate/correct, or not approve the therapy prescription if the therapy prescription (specified by the parameter load) is inappropriate or incorrect. If the therapy prescription is approved, at 712, cloud-based service 415 may store configuration data for the therapy settings in a storage device at cloud-based server system 414 so that the therapy settings may be transmitted to the patient's medical device. At 714, cloud-based service 415 provides configuration data for approved therapy settings (which are appropriate for the particular patient 501) to the medical device of patient 501 so that the medical device can be configured according to the configuration data for the therapy settings for the particular patient 501.

In some examples, the insulin infusion device may be configured with patient-specific therapy settings and parameters (e.g., prior to entering an automatic mode of operation and beginning closed-loop therapy). These therapy settings may include, for example, basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, and basal increment for a particular patient. An extended warm-up period is typically required to set these therapy settings and parameters. For example, one commercially available insulin infusion device requires a minimum of two Total Daily Dose (TDD) values for a whole day before entering an automatic mode of operation and initiating closed loop therapy. This period is sometimes referred to as a long warm-up period.

Many patients prefer that their medical devices be easy to deploy. In accordance with the disclosed embodiments, systems and methods for configuring therapy settings and parameters of a medical device are provided. These systems and methods may be automated by utilizing patient data including the patient's weight and/or the patient's estimated total daily insulin dose (TDD). The patient data may be obtained via a non-medical device (e.g., a patient's smartphone or HCP's computer) or through a cloud-based service during system startup. According to certain embodiments, the estimated insulin TDD of the patient may be determined based on the weight of the patient. TDD can then be used to calculate various therapy settings for that particular patient. These therapy settings may then be automatically programmed into the medical device during system startup and used, for example, by a closed loop algorithm in place of the therapy settings that would otherwise be determined after a long warm-up period (e.g., two-day TDD requirements).

The disclosed embodiments may allow the medical device to enter an automatic mode of operation and initiate closed loop therapy while bypassing the conventional long warm-up period. This may allow the patient to simplify the system start-up procedure and initiate closed loop therapy more quickly. To help simplify the process of configuring an insulin infusion device, cloud services and mobile devices (such as smartphones) may be utilized to help improve the setup process. This may be particularly helpful, for example, for therapy devices that do not include a local graphical user interface (e.g., patch-type pumps). Various embodiments will be described below with reference to fig. 8 to 11.

Fig. 8 is a flowchart illustrating a method 800 for configuring therapy settings of a medical device 402 for a particular patient during a start-up mode of the medical device 402, in accordance with the disclosed embodiments. As a preliminary matter, it should be appreciated that the method 800 is provided in a form that illustrates a non-limiting example of one possible embodiment of a method 800 for configuring therapy settings. Referring to method 800, tasks may be added, omitted, and/or performed simultaneously without departing from the scope of the appended claims. It should be appreciated that method 800 may include any number of additional or alternative tasks, the tasks shown in fig. 8 need not be performed in the illustrated order, and that method 800 may be incorporated into a more comprehensive procedure or process having additional functionality not described in detail herein. Further, one or more of the tasks shown in fig. 8 may potentially be omitted from an embodiment of method 800 as long as the intended overall functionality remains intact. It should also be appreciated that the illustrated method 800 may be stopped at any time.

Method 800 is computer-implemented in that the various tasks or steps of method 800 may be performed by software, hardware, firmware, or any combination thereof. In some embodiments, some or all of the tasks and/or substantially equivalent tasks of the process are performed by execution of processor readable instructions stored or embodied on a processor readable medium. For illustrative purposes, the following description of the method 800 may refer to elements mentioned above in connection with fig. 1-6. Method 800 will be described with reference to certain elements of fig. 4 to illustrate one possible non-limiting implementation; however, it should be appreciated that the method 800 may be implemented in a variety of different system architectures. For example, in the description of fig. 8 below, medical device 402, non-medical device 406, and/or cloud-based service 415 provided by cloud-based server system 414 will be described as performing various actions, tasks, or steps, but it should be understood that this refers to the processing systems of these entities executing instructions to perform those various actions, tasks, or steps. Depending on the implementation, method 800 may be performed by medical device 402, non-medical device 406, and/or cloud-based service 415 provided by cloud-based server system 414. Specific implementations will be described below with reference to fig. 9 through 11.

In some embodiments, the method 800 begins at 802, where the non-medical device 406 establishes a communication link with the medical device 402 and/or the server system 414 hosting the cloud-based service 415. Alternatively, in another embodiment, the medical device 402 may establish a communication link with the non-medical device 406 and/or the server system 414. In another embodiment, server system 414 may establish a communication link with medical device 402 and/or non-medical device 406. In any of these embodiments, the communication links may be established automatically, or may be established in response to an action by a particular patient that causes the communication links to be established.

At 804, patient data for a particular patient may be entered and optionally sent to and received by one or more of medical device 802, non-medical device 406, and/or cloud-based service 815 at server system 814. For example, patient data may be sent from the cloud-based service 815 to the medical device 402 and/or to the non-medical device 406, or from the non-medical device 406 to the cloud-based service 815 and/or to the medical device 802. In some embodiments, the patient data may be entered using a graphical user interface of the non-medical device 406 (e.g., the patient's device). In other embodiments, patient data may be entered by the healthcare provider via another non-medical device, stored at the server system 414, and subsequently retrieved from the server system 414 by the non-medical device 406.

The patient data may include one or more of a weight of the particular patient and/or a value (unit) of TDD for insulin of the particular patient. In some embodiments, the patient data entered at 804 may also include other product information and/or patient health information. The product information may include things such as: a firmware version to be installed for the medical device 402; operating parameters for the medical device 402; a date and time service for synchronizing the devices; the feature set to be activated, e.g. CGM integration, closed loop therapy, teleoperation of the infusion device, etc. Patient health information may include things such as one or more of the following: the age of the particular patient, the age of the particular patient at the time of diabetes diagnosis, the Body Mass Index (BMI) of the particular patient, the sex of the particular patient, the prescription from the physician of the patient (e.g., physician-approved therapy settings for the particular patient), etc.

At 805, a value (unit) of TDD for insulin for a particular patient may be obtained. How this value is obtained may vary depending on the implementation. In some cases, the value may be entered at 804, while in other cases, the value may be calculated based on other patient data and/or adjusted by a user. At 806, it may be determined whether a value for the total daily dose is entered as part of the patient data. When a value for TDD is entered (at 804) as part of patient data, method 800 may proceed to 810.

When a value for TDD is not entered (at 804) as part of the patient data, method 800 may proceed to 808, where the patient weight entered at 804 may be used to calculate the value for TDD. When the patient's weight is in a lower range (e.g., between 15 kg and 38 kg), the calculation at 808 may be performed by scaling the patient's weight according to a constant scaling factor.

For example, in one embodiment, the patient's weight may be converted to a value for TDD using a conversion factor, as TDD is a function of the patient's weight. For example, in one implementation, the patient's weight may be input in pounds (lb.) and may be converted to a value for TDD by multiplying the weight by a conversion factor or constant value. In another implementation, the patient's weight may be input in kilograms (kg) and may be converted to a value for TDD by multiplying the weight by a conversion factor or constant value.

When the patient's weight is in a higher range (e.g., between 38 kg and 200 kg), the calculation at 808 may be performed by scaling the patient's weight according to a patient-dependent scaling formula. Depending on the implementation, the value of TDD may be calculated (at 808) by the non-medical device 406, the cloud-based service 415 at the server system 414, or the medical device 402. When the value of TDD is calculated (at 808) by the cloud-based service 415 or the medical device 402, the value may be sent back to the non-medical device 406 for viewing or confirmation.

At 810, it may be confirmed whether the value of TDD (which may be a value entered by a user (e.g., patient or HCP) at 804 or a value calculated from the patient's weight at 808) should be used to calculate a therapy setting (at 814) or should be changed/adjusted (at 812).

In some embodiments, at 810, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of the value by the user (e.g., the particular patient or their healthcare provider). In this way, the user can confirm whether the TDD value (from 804 or 808) is acceptable and should be used to calculate the therapy settings. The user of the non-medical device 406 may confirm the value of TDD (at 810) or adjust the value of TDD (at 812).

When the user enters information (at 810) to confirm that the value of TDD is acceptable and should be used to calculate a therapy setting, the method proceeds to 814. Conversely, when the user inputs information (at 810) to indicate that the calculated value of TDD (from 804 or 808) is unacceptable and should not be used to calculate a therapy setting, the method proceeds to 812.

At 812, the value of TDD may be adjusted/changed. According to an embodiment, the value of TDD may be adjusted/changed based on user input or algorithmically. For example, in one embodiment, a user (e.g., a patient or HCP) may input an adjusted value for TDD, and the method 800 loops back to 810 to confirm that the adjusted value for TDD should be used to calculate a therapy setting. In another embodiment, at 812, an algorithm implemented at the non-medical device 406 (e.g., a smart phone or other device), the cloud-based service 415 at the server system 414 (e.g., a server), or the medical device 402 may adjust the value of TDD, and the method 800 loops back to 810 to confirm that the adjusted value of TDD should be used to calculate the therapy setting. In some embodiments, the algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the value of TDD is suitable for use in calculating a therapy setting, and if not, the algorithm may adjust the value of TDD to an acceptable value for use in calculating a therapy setting.

At 814, the value of TDD (which may be the value entered by the user (e.g., patient or HCP) at 804 or the value calculated at 808 or the adjusted value set or calculated at 812) may be used to calculate the therapy setting. Depending on the implementation, the therapy settings may be calculated (at 808) by the non-medical device 406, the cloud-based service 415 at the server system 414, or the medical device 402. For example, in one embodiment, the non-medical devices 406 may calculate therapy settings and communicate them to the medical devices 402. In another embodiment, cloud-based service 415 may calculate therapy settings and communicate the therapy settings to medical device 402. In another embodiment, cloud-based service 415 may calculate therapy settings, communicate them to non-medical device 406, and non-medical device 406 may communicate the therapy settings to medical device 402. In another embodiment, the medical device 402 may locally calculate the therapy settings based on the value of TDD.

The therapy settings for a particular patient calculated at 814 may include, but are not limited to, for example: basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, basal increment for a particular patient, and the like. In some implementations, certain parameters (e.g., insulin sensitivity coefficient and insulin to carbohydrate ratio) may be a set of values that are calculated and applied over a specified period of time (such as a twenty-four hour period). In other implementations, certain parameters (e.g., insulin sensitivity coefficient and insulin to carbohydrate ratio) may be individual values that are calculated and applied over a specified period of time (such as a twenty-four hour period).

Further, in some embodiments, product information and/or patient health information may also be communicated to the medical device 402 at 814. The product information may include, for example: a firmware version to be installed for the medical device 402; operating parameters for the medical device 402; date and time services for synchronizing devices, and the like. Patient health information may include, for example: the age of the particular patient, the age of the particular patient at the time of diagnosis of diabetes, the Body Mass Index (BMI) of the particular patient, the sex of the particular patient, the weight of the patient, the value of TDD, the basal pattern with at least one time period, the time of insulin activity (hours), the BG target range, the prescription from the physician of the patient (e.g., physician approved therapy settings for the particular patient, etc.).

In some embodiments, after calculating the therapy settings at 814, the method may proceed to 815, where it may be confirmed whether the calculated therapy settings are correct or appropriate. In other words, the therapy settings may be sent, for example, to the non-medical device 406 for confirmation or adjustment by a user (e.g., a patient or HCP) and then used to automatically program the medical device 402 (at 816). Depending on the implementation, the calculated therapy settings (from 814) may be algorithmically adjusted/changed (at 817) before being used to automatically program the medical device 402, or adjusted/changed by the user (at 817) before being used to automatically program the medical device 402. For example, in one embodiment, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of a therapy setting by a user (e.g., a particular patient or healthcare provider). In this way, the user may confirm whether the therapy settings (from 814) are acceptable or whether they need to be changed/adjusted, in which case the user may change/adjust one or more of the therapy settings. When the user enters information to indicate that the calculated therapy settings (from 814) are unacceptable and should not be used to program the medical device 402, the user may enter one or more adjusted therapy settings and the method 800 then proceeds to 816. When the user enters information to confirm that the therapy settings are acceptable, the therapy settings may be used without adjustment or change at 816. In another embodiment, the algorithm may confirm (at 815) whether the calculated therapy setting (from 814) is to be used to program the therapy setting (at 816). The algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the calculated therapy settings (from 814) are suitable for use as programmed therapy settings (at 816), and if not, at 817, one or more values of the calculated therapy settings (from 814) may be adjusted/changed to other values acceptable for programming therapy settings (at 816).

At 816, the processor device or controller of the medical device 402 may be automatically programmed with a therapy set for a particular patient to complete the setting of the medical device 402 such that the medical device is properly configured for the particular patient. The therapy set for a particular patient used to automatically program the medical device 402 may be the therapy set calculated at 814 or an adjusted therapy set that is adjusted/changed after calculation at 814.

Fig. 9 is a flowchart illustrating a method 900 for configuring therapy settings for a particular patient of a medical device 402 during a start-up mode of the medical device 402, in accordance with the disclosed embodiments. The method 900 begins at 902, where the non-medical device 406 establishes a communication link with the medical device 402. Alternatively, in another embodiment, the medical device 402 may establish a communication link with the non-medical device 406. In any of these embodiments, the communication links may be established automatically, or may be established in response to an action by a particular patient that causes the communication links to be established.

At 904, patient data may be entered via a non-medical device 406 (e.g., a device of a patient or healthcare provider). In some embodiments, the patient data may be entered using a graphical user interface of the non-medical device 406 (e.g., during a pairing process with the medical device 402). In another embodiment, patient data may be entered by a healthcare provider via another non-medical device. The patient data may include one or more of a weight of the particular patient and/or a value (unit) of TDD for insulin of the particular patient. As described above with reference to fig. 8, in some embodiments, the patient data entered at 904 may also include other product information and/or patient health information.

At 905, patient data may be transmitted from the non-medical device 406 to the medical device 402. At 906, the medical device 402 may determine whether a value for TDD is entered as part of the patient data. When the medical device 402 determines that the value of TDD is entered (as indicated by arrow 907) as part of the patient data (at 904), the method 900 may proceed to 910.

When the medical device 402 determines that the value of TDD is not entered as part of the patient data (at 904), the method 900 may proceed to 908, wherein the medical device 402 may calculate the value of TDD using the patient weight entered at 904. The calculation may be performed as described above with reference to fig. 8. After calculating the value of TDD by the medical device 402 (at 908), the medical device 402 may send the value back to the non-medical device 406 for viewing or confirmation by a user (e.g., a patient or HCP).

At 910, the non-medical device 406 may confirm whether the value of TDD (which may be the value entered by the user (e.g., patient or HCP) at 904 or the value calculated as a function of patient weight at 908) should be used to calculate the therapy setting (at 914) or whether it should be changed/adjusted algorithmically or by the user (at 912).

In some embodiments, at 910, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of the value by a user (e.g., a particular patient or healthcare provider). In this way, the user can confirm whether the value of TDD (from 904 or 908) is acceptable and should be used to calculate therapy settings (at 914), or whether the calculated value of TDD should be adjusted/changed at 912. The user of the non-medical device 406 may confirm the value of TDD (at 910) or adjust the value of TDD (at 912).

When the user enters information (at 910) to confirm that the value of TDD (from 904 or 908) is acceptable and should be used to calculate a therapy setting, the value of TDD may be sent (at 911) to the medical device 402. Further, in some embodiments, product information and/or patient health information may also be communicated to the medical device 402 at 911 (or alternatively at 905 or 913).

Conversely, when the user inputs information (at 910) to indicate that the value of TDD (from 904 or 908) is unacceptable and should not be used to calculate a therapy setting, the method proceeds to 912, where the value of TDD may be adjusted/changed. According to an embodiment, the value of TDD may be adjusted/changed based on user input or algorithmically. For example, in one embodiment, at 912, a user (e.g., a patient or HCP) may enter an adjusted value for TDD that should be used to calculate a therapy setting. In another embodiment, at 912, an algorithm at the non-medical device 406 may adjust/change the value of TDD to an adjusted value of TDD that should be used to calculate a therapy setting. In some embodiments, the algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the value of TDD is suitable for use in calculating a therapy setting, and if not, the algorithm may adjust the value of TDD to an acceptable value for use in calculating a therapy setting. At 913, the adjusted value may be transmitted from the non-medical device 406 to the medical device 402. Further, as described above with reference to fig. 8, in some embodiments, the non-medical device 406 may also communicate product information and/or patient health information to the medical device 402 at 913 (or alternatively 905 or 911 as described above).

At 914, the medical device 402 may calculate a therapy setting based on the value of TDD, which may be a value entered by a user (e.g., patient or HCP) at 904, a value calculated at 908, or an adjusted value adjusted/changed at 912. The therapy set for a particular patient calculated at 914 may include, but is not limited to, for example: basal rate, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, basal increment for a particular patient, and the like. In one non-limiting implementation, the therapy settings may be calculated as described above with reference to fig. 8.

Although not shown in fig. 9, in one embodiment, after the therapy settings are calculated at 914, the therapy settings may be sent to the non-medical device 406 for confirmation or adjustment by a user (e.g., a patient or HCP) and then used to automatically program the medical device 402 (at 916). Depending on the implementation, the calculated therapy settings (from 914) may be algorithmically adjusted/changed before being used to automatically program the medical device 402 or adjusted/changed by the user before being used to automatically program the medical device 402. For example, in one embodiment, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of a therapy setting by a user (e.g., a particular patient or healthcare provider). In this way, the user may confirm whether the therapy settings (from 914) are acceptable or whether they need to be changed/adjusted, in which case the user may change/adjust one or more of the therapy settings. When the user enters information to indicate that the calculated therapy settings (from 914) are unacceptable and should not be used to program the medical device 402, the user may enter one or more adjusted therapy settings and the method 900 then proceeds to 916. When the user enters information to confirm that the therapy settings are acceptable, the therapy settings may be used without adjustment or change at 916. In another embodiment, an algorithm that may be implemented at the non-medical device 406 may confirm whether the calculated therapy settings (from 914) are to be used for programming the therapy settings (at 916). The algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the calculated therapy setting (from 914) is suitable for use as a programmed therapy setting (at 916), and if not, may adjust/change one or more values of the calculated therapy setting (from 914) to other values acceptable for the programmed therapy setting (at 916).

At 916, the processor device or controller of the medical device 402 may be automatically programmed with the therapy set for the particular patient (e.g., without user input at the medical device 402) to complete the setting of the medical device 402 such that the medical device is properly configured for the particular patient. The therapy set for a particular patient used to automatically program the medical device 402 may be the therapy set calculated at 914 or an adjusted therapy set that is adjusted/changed after calculation at 914.

Fig. 10 is a flowchart illustrating a method 1000 for configuring therapy settings for a particular patient of a medical device 402 during a start-up mode of the medical device 402, in accordance with the disclosed embodiments.

In some embodiments, the method 1000 begins at 1002, where the non-medical device 406 establishes a communication link with the medical device 402. Alternatively, in another embodiment, the medical device 402 may establish a communication link with the non-medical device 406. In any of these embodiments, the communication links may be established automatically, or may be established in response to an action by a particular patient that causes the communication links to be established.

At 1004, patient data may be entered via a non-medical device 406 (e.g., a device of a patient or healthcare provider). In some embodiments, the patient data may be entered using a graphical user interface of the non-medical device 406 (e.g., during a pairing process with the medical device 402). In another embodiment, patient data may be entered by a healthcare provider via another non-medical device. The patient data may include one or more of a weight of the particular patient and/or a value (unit) of TDD for insulin of the particular patient. As described above with reference to fig. 8, in some embodiments, the patient data entered at 904 may also include other product information and/or patient health information.

At 1005, patient data may optionally be sent from the non-medical device 406 to the medical device 402. At 1006, the non-medical device 406 may determine whether a value for TDD is entered as part of the patient data. When the non-medical device 406 determines that the value of TDD is entered (as indicated by arrow 1007) as part of the patient data (at 1004), the method 1000 may proceed to 1010.

When the non-medical device 406 determines that the value of TDD is not entered as part of the patient data (at 1004), the method 1000 may proceed to 1008, where the non-medical device 406 may calculate the value of TDD using the patient's weight (entered at 1004). The calculation at 1008 may be performed as described above with reference to fig. 8.

At 1010, the non-medical device 406 may confirm whether the value of TDD (which may be a value entered by the user (e.g., patient or HCP) at 1004 or calculated as a function of patient weight at 1008) is applied to calculate the therapy setting (at 1014), or whether it should be changed/adjusted algorithmically or by the user (at 1012).

In some embodiments, at 1010, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of the value by a user (e.g., a particular patient or healthcare provider). In this way, the user can confirm whether the calculated value of TDD (from 1004 or 1008) is acceptable and should be used to calculate therapy settings (at 1014), or whether the calculated value of TDD should be adjusted/changed at 1012. The user of the non-medical device 406 may confirm the value of TDD (at 1010) or adjust the value of TDD (at 1012).

When the user enters information (at 1010) to confirm that the value of TDD (from 1004 or 1008) is acceptable and should be used to calculate a therapy setting, the value of TDD may be sent (at 1011) to the medical device 402. Conversely, when the user enters information (at 1010) to indicate that the value of TDD (from 1004 or 1008) is unacceptable and should not be used to calculate therapy settings, the method proceeds to 1012, where the value of TDD may be adjusted/changed. According to an embodiment, the value of TDD may be adjusted/changed based on user input or algorithmically. For example, in one embodiment, at 1012, a user (e.g., a patient or HCP) may input an adjusted value for TDD that should be used to calculate a therapy setting. In another embodiment, at 1012, an algorithm at the non-medical device 406 may adjust/change the value of TDD to an adjusted value of TDD that should be used to calculate a therapy setting. In some embodiments, the algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the value of TDD is suitable for use in calculating a therapy setting, and if not, the algorithm may adjust the value of TDD to an acceptable value for use in calculating a therapy setting.

At 1014, the non-medical device 406 may locally calculate a therapy setting based on the value of the TDD, which may be a value entered by a user (e.g., patient or HCP) at 1004, a value calculated at 1008, or an adjusted value adjusted/changed at 1012. The set of therapy settings for a particular patient calculated at 1014 may include, but are not limited to, for example: basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, basal increment for a particular patient, and the like. In one non-limiting implementation, the therapy settings may be calculated as described above with reference to fig. 8.

Although not shown in fig. 10, in one embodiment, after the therapy settings are calculated at 1014, the therapy settings may be displayed at the non-medical device 406 for confirmation or adjustment by a user (e.g., patient or HCP) and then used to automatically program the medical device 402 (at 1016). Depending on the implementation, the calculated therapy settings (from 1014) may be algorithmically adjusted/changed before being used to automatically program the medical device 402, or adjusted/changed by the user (e.g., without user input at the medical device 402) before being used to automatically program the medical device 402. For example, in one embodiment, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of a therapy setting by a user (e.g., a particular patient or healthcare provider). In this way, the user can confirm whether the therapy settings (from 1014) are acceptable or whether they need to be changed/adjusted, in which case the user can change/adjust one or more of the therapy settings. When the user enters information to indicate that the calculated therapy settings (from 1014) are unacceptable and should not be used to program the medical device 402, the user may enter one or more adjusted therapy settings and the method 1000 then proceeds to 1016. When the user enters information to confirm that the therapy settings are acceptable, the therapy settings may be used without adjustment or change at 1016. In another embodiment, an algorithm that may be implemented at the non-medical device 406 may confirm whether the calculated therapy settings (from 1014) are to be used for programming the therapy settings (at 1016). The algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the calculated therapy setting (from 1014) is suitable for use as a programmed therapy setting (at 1016), and if not, may adjust/change one or more values of the calculated therapy setting (from 1014) to other values acceptable for the programmed therapy setting (at 1016).

At 1015, the non-medical device 406 may send the calculated therapy setting (or alternatively the adjusted therapy setting) to the medical device 402. Further, as described above with reference to fig. 8, in some embodiments, product information and/or patient health information may also be communicated to the medical device 402 at 1015 (or alternatively at 1005).

At 1016, the processor device or controller of the medical device 402 may be automatically programmed with a therapy set for a particular patient to complete the setting of the medical device 402 so that the medical device is properly configured for the particular patient. The therapy set for a particular patient used to automatically program the medical device 402 may be the therapy set calculated at 1014, or an adjusted therapy set that is adjusted/changed after calculation at 1014.

Fig. 11 is a flow chart illustrating another method 1100 for configuring therapy settings for a particular patient of a medical device 402 during a start-up mode of the medical device 402, in accordance with the disclosed embodiments. In some embodiments, the method 1100 begins at 1102, where the non-medical device 406 establishes a communication link with the medical device 402 and the server system 414 hosting the cloud-based service 415. Alternatively, in another embodiment, the medical device 402 may establish a communication link with the non-medical device 406 and the server system 414. In another embodiment, the server system 414 may establish a communication link with the medical device 402 and the non-medical device 406. In any of these embodiments, the communication links may be established automatically, or may be established in response to an action by a particular patient that causes the communication links to be established.

At 1104, patient data may be entered via a non-medical device 406 (e.g., a device of a patient or healthcare provider). In some embodiments, the patient data may be entered using a graphical user interface of the non-medical device 406 (e.g., during a pairing process with the medical device 402). In another embodiment, patient data may be entered by a healthcare provider via another non-medical device. The patient data may include one or more of a weight of the particular patient and/or a value (unit) of TDD for insulin of the particular patient. As described above with reference to fig. 8, in some embodiments, the patient data entered at 904 may also include other product information and/or patient health information.

At 1105, patient data may be sent, for example, from the non-medical device 406 to a cloud-based service 415 at a server system 414. At 1106, the cloud-based service 415 may determine whether the value of TDD is entered as part of the patient data. When the cloud-based service 415 determines (at 1106) that the value of TDD is entered (at 1104) as part of the patient data, the method 1100 may proceed to 1110.

When the cloud-based service 415 determines (at 1106) that the value of TDD is not entered (at 1104) as part of the patient data, the method 1100 may proceed to 1108, wherein the cloud-based service 415 calculates the value of TDD using the patient weight entered at 1104. The calculation at 1108 may be performed as described above with reference to fig. 8.

The calculated value of TDD (at 1108) may be sent (at 1109) by the cloud-based service 415 to the non-medical device 406 for viewing or confirmation. At 1110, the non-medical device 406 may determine whether the value of TDD (which may be the value entered by the user (e.g., patient or HCP) at 1104 or the value calculated as a function of patient weight at 1108) should be used to calculate the therapy setting (at 1114) or whether it should be changed/adjusted algorithmically or by the user (at 1112).

In some embodiments, at 1110, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of the value by the user (e.g., the particular patient or their healthcare provider). In this way, the user can confirm whether the calculated value of TDD (from 1104 or 1108) is acceptable and should be used to calculate therapy settings (at 1114), or whether the calculated value of TDD should be adjusted/changed at 1112. The user of the non-medical device 406 may confirm the value of TDD (at 1110) or adjust the value of TDD (at 1112).

When the user inputs information (at 1110) to confirm that the value of TDD (from 1104 or 1108) is acceptable and should be used to calculate therapy settings, the value of TDD may be sent (at 1111) to the cloud-based service 415. Conversely, when the user inputs information (at 1110) to indicate that the value of TDD (from 1104 or 1108) is unacceptable and should not be used to calculate therapy settings, the method proceeds to 1112, where the value of TDD may be adjusted/changed. According to an embodiment, the value of TDD may be adjusted/changed based on user input or algorithmically. For example, in one embodiment, at 1112, a user (e.g., a patient or HCP) may enter an adjusted value for TDD that should be used to calculate a therapy setting. In another embodiment, at 1112, an algorithm at the non-medical device 406 may adjust/change the value of TDD to an adjusted value of TDD that should be used to calculate a therapy setting. In some embodiments, the algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the value of TDD is suitable for use in calculating a therapy setting, and if not, the algorithm may adjust the value of TDD to an acceptable value for use in calculating a therapy setting.

At 1114, the cloud-based service 415 may calculate therapy settings based on the value of TDD, which may be a value entered by a user (e.g., patient or HCP) at 1104, a value calculated at 1108, or an adjusted value adjusted/changed at 1112. In this embodiment, cloud-based service 415 may calculate therapy settings, communicate the therapy settings to non-medical device 406, and non-medical device 406 may communicate the therapy settings to medical device 402 (at 1115). In another embodiment, cloud-based service 415 may calculate therapy settings and communicate the therapy settings directly to medical device 1102. The therapy set for a particular patient calculated at 1114 may include, but is not limited to, for example: basal rate for a particular patient, insulin sensitivity coefficient for a particular patient, insulin to carbohydrate ratio for a particular patient, insulin activity time for a particular patient, maximum bolus limit for a particular patient, maximum basal rate for a particular patient, bolus increment for a particular patient, basal increment for a particular patient, and the like. In one non-limiting implementation, the therapy settings may be calculated as described above with reference to fig. 11.

Although not shown in fig. 11, in one embodiment, after the therapy settings are calculated at 1114 and sent to non-medical device 406 (at 1115), non-medical device 406 may confirm or adjust/change one or more of the therapy settings, which are then sent to medical device 402 and used to automatically program the medical device (at 1116). The calculated therapy settings (from 1114) may be algorithmically changed or adjusted by the user before being sent to the medical device 402 and used to automatically program the medical device (e.g., without user input at the medical device 402).

For example, in one embodiment, a GUI may be displayed at the non-medical device 406 that includes an interface element requesting confirmation of a therapy setting by a user (e.g., a particular patient or healthcare provider). In this way, the user may confirm whether the therapy settings (from 1114) are acceptable or whether they need to be changed/adjusted, in which case the user may change/adjust one or more of the therapy settings. When the user enters information to indicate that the calculated therapy settings (from 1114) are not acceptable and should not be used to program the medical device 402, the user may enter one or more adjusted therapy settings and the method 1100 then proceeds to 1116. The therapy settings may be used at 1116 when the user enters information to confirm that the therapy settings are acceptable.

In another embodiment, the calculated therapy settings (from 1114) may be validated for programming the therapy settings (at 1116) via an algorithm that may be implemented at the non-medical device 406. The algorithm may employ various artificial intelligence and/or machine learning techniques to determine whether the calculated therapy settings (from 1114) are appropriate for programming the therapy settings (at 1116), and if not, may adjust one or more values of the calculated therapy settings (from 1114) to other values acceptable for programming the therapy settings (at 1116).

At 1115, cloud-based service 415 may calculate therapy settings, communicate the therapy settings to non-medical device 406, and non-medical device 406 may communicate the calculated therapy settings (or alternatively the adjusted therapy settings) to medical device 402. Further, as described above with reference to fig. 8, in some embodiments, product information and/or patient health information may also be communicated to the medical device 402 at 1115.

At 1116, the processor device or controller of the medical device 402 may be automatically programmed with a therapy set for a particular patient to complete the setting of the medical device 402 so that the medical device is properly configured for the particular patient. The therapy set for a particular patient used to automatically program the medical device 402 may be the therapy set calculated at 1114 or an adjusted therapy set that is adjusted/changed after calculation at 1114.

It should be understood that the various aspects disclosed herein may be combined in different combinations than specifically set forth in the description and drawings. It should also be appreciated that, depending on the example, certain acts or events of any of the processes or methods described herein can be performed in a different order, may be added, combined, or omitted entirely (e.g., not all of the described acts or events may be required to perform the techniques). Additionally, although certain aspects of the present disclosure are described as being performed by a single module or unit for clarity, it should be understood that the techniques of the present disclosure may be performed by a unit or combination of modules associated with, for example, a medical device.

In one or more examples, the techniques described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. Computer-readable media may include non-transitory computer-readable media corresponding to tangible media, such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer).

The instructions may be configured to be executed by one or more processors, such as one or more Digital Signal Processors (DSPs), general purpose microprocessors, application Specific Integrated Circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the foregoing structure or any other physical structure suitable for implementation of the described techniques. Moreover, the techniques may be fully implemented in one or more circuits or logic elements.

While at least one exemplary embodiment has been presented in the foregoing detailed description, it should be appreciated that a vast number of variations exist. For example, while the specific embodiments describe specific examples in which the configured medical device is an insulin infusion or delivery device for treating diabetes, it should be understood that the same or similar principles may be used to configure other types of medical devices for embodiments that address different medical conditions by changing the type of input data entered by a physician, the type of therapy, parameters, and the like. It should also be appreciated that the exemplary embodiment or exemplary embodiments described herein are not intended to limit the scope, applicability, or configuration of the claimed subject matter in any way. Rather, the foregoing detailed description will provide those skilled in the art with a convenient road map for implementing the described embodiment or embodiments. It should be understood that various changes can be made in the function and arrangement of elements without departing from the scope defined by the claims, including known equivalents and foreseeable equivalents at the time of filing this patent application.

The invention is defined in the appended claims. A second inventive aspect of the present disclosure is set forth in the following paragraphs:

paragraph 1. A method comprising:

obtaining prescription information for a patient, wherein the prescription information includes a device prescription;

converting prescription information into first configuration data, the first configuration data comprising information specific to the package

Setting a therapy of the first medical device indexed by the prescription; and

the automatic configuration of the first medical device is caused based on communicating the first configuration data to the first medical device.

Paragraph 2. The method of paragraph 1, wherein the device prescription comprises: identification information for the patient, a model of the first medical device, and a type of therapy prescribed for the patient.

Paragraph 3. The method of any of paragraphs 1 to 2, wherein the prescription information further comprises one or more of:

basic patient-specific data for a patient, the basic patient-specific data comprising: physical, metabolic or anatomical data about the patient, and information about the medical condition;

patient lifestyle data for a patient, the patient lifestyle data comprising: with respect to

Data on the patient's diet and data on the patient's exercise characteristics;

Information about medical conditions targeted for therapy and information about conditions other than those targeted for therapy

Information of medical conditions other than the condition;

information about the patient's therapy history; and

known therapy settings from a prior medical device of a patient.

Paragraph 4. The method of any of paragraphs 1 to 3, wherein converting the prescription information into the first configuration data comprises:

selecting a therapy configuration for the first medical device based on the prescription information; and

therapy parameters and settings for the first medical device are determined based on the prescription information.

Paragraph 5. The method of paragraph 4, wherein the therapy configuration comprises:

one or more therapy algorithms to be performed by a first medical device for the patient; and

one or more modes of operation of the first medical device to be used with the patient.

Paragraph 6. The method of paragraphs 4 or 5, wherein the therapy parameters and settings comprise:

device configuration parameters or settings for configuring a first medical device of a patient; and

therapy configuration parameters for configuring a first medical device of a patient.

Paragraph 7. The method of any of paragraphs 4 to 6, the method further comprising:

combining therapy configuration and therapy parameters and settings for a first medical device into a first

Configuration data; and

the first configuration data is stored in a database.

Paragraph 8. The method of any of paragraphs 1 to 7, wherein the first configuration data is structured as at least one software image.

Paragraph 9. The method of paragraph 8, wherein the at least one software image further comprises firmware defining operation of the first medical device.

Paragraph 10. The method of any of paragraphs 1 to 8, the method further comprising disabling operation of the first medical device before the automatic configuration is complete.

Paragraph 11. The method according to any of paragraphs 1 to 10, the method further comprising:

the prescription information is converted to second configuration data including therapy settings for a second medical device indexed by the prescription information, wherein the first medical device is a different model than the second medical device.

The method of any of paragraphs 1-11, wherein the first medical device comprises at least one of the group consisting of an insulin infusion device and a glucose sensor.

Paragraph 13. A computing system, the computing system comprising:

at least one processor device; and

a non-transitory processor-readable medium operatively associated with at least one processor device, the processor-readable medium containing executable instructions configurable to cause the at least one processor device to perform the method of any one of paragraphs 1 to 12.

Paragraph 14. A healthcare network for servicing a plurality of patients, the network comprising a server on a cloud-based network and a medical device for each patient, wherein the healthcare network further comprises a processing system configured to perform the method according to any one of paragraphs 1 to 12 with respect to each patient of the plurality of patients to configure the respective medical device.

Paragraph 15. A method of obtaining a medical device, such as an insulin pump, the method comprising:

a. ) Ordering medical devices in a non-functional, unprogrammed state from a device manufacturer or dealer;

b) Providing health data, therapy type, and patient ID to a computer system comprising a cloud-based server, the computer system being equipped with a program for calculating parameters required to program ordered medical devices for therapy types for a particular patient;

c) A software image including the parameters and activation code is downloaded to the medical device, causing the medical device to be functional and programmed.

Claims (12)

1. A method for configuring therapy settings of a medical device for a particular patient, the method comprising:

receiving patient data entered via a non-medical device;

Obtaining a value of a total daily dose of insulin for the particular patient from the patient data;

calculating a set of therapy settings for the particular patient based on the value of the total daily dose; and

the medical device is automatically programmed with the therapy set to complete the setting of the medical device such that the medical device is configured for the particular patient.

2. The method of claim 1, wherein the patient data comprises: the weight of the particular patient, and wherein obtaining the value of the total daily dose of insulin for the particular patient from the patient data comprises: the value of the total daily dose is calculated based on the body weight of the particular patient.

3. The method of claim 2, wherein calculating the value of the total daily dose based on the weight of the particular patient is performed by one of: the non-medical devices, the medical devices, and a server system hosting a cloud-based service.

4. The method of claim 1, wherein the patient data includes the value of the total daily dose of insulin for the particular patient, and wherein obtaining the value of the total daily dose of insulin for the particular patient from the patient data includes:

The value of the total daily dose of insulin for the particular patient is extracted from the patient data.

5. The method of any one of claims 1-4, wherein calculating the therapy set for the particular patient based on the value of the total daily dose is performed by one of: the non-medical devices, the medical devices, and a server system hosting a cloud-based service.

6. The method of any one of claims 1 to 5, further comprising:

confirming, at the non-medical device, whether the value of the total daily dose is correct;

receiving, via the non-medical device, an updated value of the total daily dose when the value of the total daily dose is incorrect; and is also provided with

Wherein calculating the therapy set for the particular patient based on the value of the total daily dose comprises:

the therapy set for the particular patient is calculated based on the updated value of the total daily dose.

7. The method of any one of claims 1 to 6, wherein the therapy set for the particular patient comprises: a basal rate for the particular patient, an insulin sensitivity coefficient for the particular patient, an insulin to carbohydrate ratio for the particular patient, an insulin activity time for the particular patient, a maximum bolus limit for the particular patient, a maximum basal rate for the particular patient, a bolus increment for the particular patient, and a basal increment for the particular patient.

8. The method of any one of claims 1 to 7, further comprising disabling operation of the medical device before the automatic programming step is completed.

9. The method of any one of claims 1 to 8, wherein the automatically programming includes sending a data-combination packet to the medical device, the data-combination packet, when received by the medical device, configuring the medical device for the particular patient.

10. The method of any one of claims 1 to 9, wherein the medical device comprises an insulin infusion device.

11. A computing system, the computing system comprising:

at least one processor device; and

a non-transitory processor-readable medium operatively associated with the at least one processor device, the processor-readable medium containing executable instructions configurable to cause the at least one processor device to perform the method of any one of claims 1 to 10.

12. A healthcare network serving a plurality of patients, the network comprising servers on a cloud-based network and medical devices for each patient, wherein the healthcare network further comprises a processing system configured to perform the method of any one of claims 1 to 10 with respect to each patient of the plurality of patients to configure a respective medical device.

Images