WO2025147641A1

WO2025147641A1 - Protocol engine for individualized patient treatment

Info

Publication number: WO2025147641A1
Application number: PCT/US2025/010275
Authority: WO
Inventors: Daniel M. Abal
Original assignee: CareFusion 303 Inc
Current assignee: CareFusion 303 Inc
Priority date: 2024-01-05
Filing date: 2025-01-03
Publication date: 2025-07-10
Anticipated expiration: 2026-07-05

Abstract

A system and method for intelligently controlling an individualized infusion is described. A machine learning model is trained to simulate progression of a plurality of conditions across a patient population under a care of a plurality of physicians, and to determine how the progression of each condition is affected by respective medication decisions made by one or more physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications. A condition to be treated is selected for a patient and the system monitors patient biomarkers and determines, in real time, a dose of a medication to administer to the patient to maintain at least one of the biomarkers in a predetermined effective range. The system causes an infusion pump to administer the dose of the medication to the patient and adjusts the dose continuously based on reevaluation of the biomarkers.

Description

PROTOCOL ENGINE FOR INDIVIDUALIZED PATIENT TREATMENT

TECHNICAL FIELD

[0001] The present disclosure is generally related to a control device configured to facilitate operation of a medical device.

BACKGROUND

[0002] Current practice for intravenous (IV) infusions of medication for treatment involve clinicians making decisions on the dosing and timing of medication to achieve the desired clinical effect. The decisions may be based on standard protocols or clinical experience. This can involve imprecise judgements and using simple calculations to determine the dosing based on the pharmacokinetic properties of the drug and particular patient particulars. Typically, this results in following a standard protocol for an average patient and not necessarily fit the individual patient. As a result, this can lead to over or under dosing the medication and repeated titration changes to reach the desired clinical response. Which in turn can lead to extended treatment times, cost, and other undesirable effects for the patient. This is especially critical with drugs that have narrow therapeutic ranges which require a patient specific targeted range. Some examples are for chemotherapy of cancer treatment, and the timely response required for treatment of sepsis.

SUMMARY

[0003] The subject technology incorporates multiple features to define an infusion protocol coupled with a protocol engine that allows individualized treatment for the patient. In this regard, the subject technology includes a Device Control Module that incorporates a Protocol Definition Tool that applies model based treatment and approved protocols, coupled with a protocol generating mechanism, to provide optimized infusion strategy for individualized patient treatment. The protocol definition tool allows a clinician to select the treatment condition from a register containing multiple types of patient demographics, conditions, and the desired treatment.

[0004] The disclosed system integrates biosensing to monitor the patient’s response to the treatment and adjust it as necessary. The biosensing can come from both biophysical sensors and or laboratory tests. The disclosed system can use mathematical models that simulate the progression of the disease and in combination with PK (Pharmacokinetics) models of the medication can determine an administration profile for an individual being treated for one of several different disease states. [0005] The disclosed combination of Model Based Infusion Control can optimize the medication delivery and reduce the burden and errors that involve manual calculations, and trial and error to achieve a desired clinical response in an individual patient. Machine learning algorithms are used to select and define the appropriate clinical treatment protocol. With the ability for the clinician to adjust settings and see a modelled response to determine the best treatment strategy.

[0006] In this regard, the subject technology includes a machine-implemented method for intelligently controlling an individualized infusion, comprising: training one or more machine learning models to simulate progression of a plurality of conditions across a patient population under a care of a plurality of physicians in a healthcare organization, and to determine how the progression of each of the plurality of conditions is affected by respective medication decisions made by one or more of the plurality of physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications; receiving an identification of a patient and a selection of a condition to be treated in the patient; identifying a characteristic of the patient; monitoring, in real time, one or more biomarkers associated with the patient; determining, in real time by the one or more machine learning models, based on the monitoring and inputs of the characteristic of the patient and the condition to be treated, a dose of a medication to administer to the patient to maintain at least one of the biomarkers in a predetermined effective range for a treatment of the condition; and causing an infusion pump to administer the determined dose of the medication to the patient. Other aspects include corresponding devices, systems, and computer program products for implementation of the corresponding method and its features.

[0007] It is understood that other configurations of the subject technology will become readily apparent to those skilled in the art from the following detailed description, wherein various configurations of the subject technology are shown and described by way of illustration. As will be realized, the subject technology is capable of other and different configurations and its several details are capable of modification in various other respects, all without departing from the scope of the subject technology. Accordingly, the drawings and detailed description are to be regarded as illustrative in nature and not as restrictive.

BRIEF DESCRIPTION OF THE FIGURES

[0008] The accompanying drawings, which are included to provide further understanding and are incorporated in and constitute a part of this specification, illustrate disclosed implementations and together with the description serve to explain the principles of the disclosed implementations. In the drawings:

[0009] FIG. 1A depicts an example of an institutional patient care system of a healthcare organization, according to aspects of the subject technology.

[0010] FIG. IB illustrates an example patient care unit, including a control unit and connected medication delivery modules, according to aspects of the subject technology.

[0011] FIG. 2 is a conceptual diagram illustrating an example infusion control system configured to dynamically connect to and receive data from different sensors to control different infusion therapies and to integrate with a cloud based data consolidation analytics and control system, according to aspects of the subject technology.

[0012] FIG. 3 depicts a first example process and workflow for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology.

[0013] FIG. 4 depicts a second example process for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology.

[0014] FIG. 5 is a conceptual diagram illustrating an example electronic system for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology.

DESCRIPTION

[0015] Reference will now be made to implementations, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth in order to provide an understanding of the various described implementations.

However, it will be apparent to one of ordinary skill in the art that the various described implementations may be practiced without these specific details. In other instances, well- known methods, procedures, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the implementations.

[0016] The subject technology provides, as part of the overall disclosed system, an intelligent Device Control Module (or Decision Control Module) (DCM), including a unit that provides processing for control algorithms, and connectivity to enable closed and semi-closed-loop control capabilities over one or medical devices at a point of use. In some implementations, the DCM provides an external interface between an IV infusion pump and one or more different physiological sensors, and provide input parameters that are to be used for controlling the titration of IV infusions of medications to a patient. In this regard, the DCM can incorporate control software (including, e.g., one or more algorithms) that can be tailored to specific or general medical treatments.

Patient / clinical procedure optimizer

[0017] The system uses a multi factorial classification for model extraction to determine the optimal model that describes the patient’s condition. Using for example the following parameters as well as others that may also be input and considered by the system:

[0018] Demographics; i.e., gender, age, weight, height, race, ethnicity, genetic background, etc.

[0019] Patient Background History; i.e., physical activity, smoking, drinking, job conditions, past medical conditions, etc.

[0020] Comorbidity / Chronic disease factors; i.e., diabetes, high blood pressure, cancer, COPD, obesity, etc.

Disease Models

[0021] Disease models are available for various conditions, some are simple, others are extremely complicated. For example, mathematical models for cancer behavior including tumor growth models and interaction between normal, immune, and cancerous cells. Because of highly nonlinear, high dimensional and sophisticated nature of mathematical models the modeling can be complicated to comprehend and use. Combining them with PK modeling for the administration of various drugs with multicompartment models can also be time consuming and difficult to use. However, with computer modeling and combining machine learning to extract and model different strategies displayed through the user interface (UI) of the disclosed (Argus) system (e.g., in a display of the disclosed DCM), makes it more practical and help to address individual patient needs.

Pharmacokinetic (PK) Models

[0022] PK models are used by the disclosed system to describe how the IV medication administered to the patient will define the absorption and physical region for the desired treatment. PK models are available from the research performed by the pharmaceutical companies that developed the medications. And can define the directions for the use based on the different compartment models for identified for the body areas being treated.

MBIC Personalized drug administration using Model Reference and Adaptive Control

[0023] The disclosed Model Based Infusion Control (MBIC) is a system that combines the Disease Model Database, PK Drug Model Database, Patient Demographics Models, and Protocol databases incorporating them into a population level database. These are used by incorporating population level machine learning analytics and identify cohort groups to determine a cohort model that describes the individual patient.

[0024] The disclosed MBIC utilizes the data driven guidance to model a dosing strategy incorporating the patient model, and PK model algorithm to administer the medication. The system can then provide guidance to the clinician when and how to modify the dose in realtime, adaptively, or in the case of closed loop control will administer the medication automatically.

[0025] The system uses a combination of monitoring and modeling algorithms for precision dosing. As a result, sub-therapeutic and super-therapeutic doses can be avoided by targeting a desired drug exposure for the individual patient.

[0026] The system uses real time and near real time inputs from biophysical sensors and or biomarkers that can be identified in Laboratory tests that are entered into the disclosed DCM or downloaded from the patient’s EMR. The range of the biomarker will be controlled by taking into account the drug concentration levels from lab results to update the PK model and adjust the infusion therapy as needed. So, this results in a refined PK model that corresponds to the individual patient. This can also generate a PK model if one doesn’t exist for the medication being used.

Circadian body rhythm

[0027] Another factor that the system uses to implement an optimized drug therapy is by the timing of the administration of the medication infusion based on circadian body rhythm. The circadian rhythms are physical cycles that can be relevant for therapeutic treatments. For example, in chemotherapy since gene mutants can show reduced fitness, or increased susceptibility, and or other metabolic diseases that can vary during the day based on the daily variation of hormones. In addition, drug efficacy and toxicity can often vary with time of day having drastic effects for therapeutic strategies. The MBIC system can use the population database and correlate it to different time intervals. As well as evaluate time based cyclical trends in biosensor response to determine the individual patient’s circadian clock rhythm to tailor an optimized drug infusion therapy.

Biosensor sampling

[0028] Sampling times are an important aspect of PK analysis that can heavily influence the inferences that are made from the resulting data. A balance is required between having sufficient time points for the data to be useful and the practicality, cost and other considerations of the number of blood concentrations taken from patient.

[0029] In clinical practice, the Area Under the Curve (AUC) is used to evaluate the drug administration in relation to the blood concentration effect. A large sample size may result in better fit of the PK results but increases the quantity and reduces the time intervals between samples, for this reason it is necessary to optimize the time samples for determining AUC of PK data. One method typically used is the ‘Optimization of Time samples using Trapezoidal Error Reduction’ algorithm (OTTER) which is designed to take a single individual’s or mean pooled PK data and return the optimal sampling times based on that data. The system can also adapt based on the frequency of testing, and as a result can make smaller more frequent interventions allowing precision dosing.

[0030] Incorporating OTTER into the MBIC processor provides this additional benefit to the infusion process. This will prevent sub-therapeutic doses by targeting a desired drug exposure range. The program will suggest time and intervals to take lab tests as well as the type of laboratory test.

System using clinician or Standard hospital based Protocol

[0031] If desired, the disclosed system has the capability of incorporating a model based on a hospital’s recommended protocol. The system will use this to populate the dosing parameters. Intelligence can be introduced to specific steps or parts of the established protocol, based on a specific clinician’s preferences or choices that are stored in a clinician database.

[0032] The system will also allow modelling of the treatment to compare the MBIC protocol to the standard protocol, allowing the clinician to tailor the prescribing regimens to individual patients.

Clinician adaptive system

[0033] The disclosed system will have a database that it collects for the individual clinicians using the system. It will record user selectable options for a specific treatment, these are downloaded to the DCM when the clinician logs in and selects a treatment. The system will then populate the UI display with the user preferences.

[0034] The system will learn based on the type, frequency and decisions made by the clinician and it may learn how to adjust based on historical clinician updates/corrections. For example, if the clinicians always reduces a recommended value for a specific step by 10%, the system may recommend an update to the protocol for that step. And the system may learn when to stop asking or recommend switching to closed loop rather than semi-closed loop. For example, if 99 times out of 100 the clinician confirms the decision of the algorithm, it may recommend removing the confirmation of that decision step.

[0035] Clinician confirmations and notifications can be user selectable based on a risk hierarchy that he can determine the limits and levels to set for notifications. For example, if a clinician wants to be notified when a certain parameter reaches a level, an algorithm of the subject technology can calculate the trend and determine the point in time when that particular level will be reached and provide a notification.

Post treatment analytics

[0036] At the completion of a treatment cycle the data collected can then be incorporated into the system databases, where machine learning can be used to further refine and improve models and optimize future treatments.

[0037] The system provides for documentation and record keeping for a specific patient and treatment that will be incorporated into the patient’s EMR. The system will keep a record of the alerts, and clinician annotations.

Pooled clinical safety analyses

[0038] The disclosed system will record safe results, together with adverse events across the treatment for the medications administered for each individual treatment event and will be pooled together to establish a data source for the machine learning model to use for modifying the treatment, providing alerts, and or provide alternate treatment suggestions to the clinician.

IV line Occlusion Detection

[0039] By correlating the patient PK response thru the tracking of specific biomarkers that are recorded from the biosensors connected to the patient, or lab tests which are tracked together in real-time with the pressure in the IV line monitored by IV pumps using their inline pressure monitoring. By trending increased pressure and decrease in clinical response in the patient, the disclosed system can issue an alert or alarm, allowing the clinician to take corrective measures before the patient suffers any serious damage because of intravasation/extravasation or occlusions in the IV line.

[0040] FIG. 1A depicts an example of an institutional patient care system 100 of a healthcare organization, according to aspects of the subject technology. In FIG. 1A, a patient care device (or “medical device” generally) 12 is connected to a hospital network 10. The term patient care device (or “PCD”) may be used interchangeably with the term patient care unit (or “PCU”), either which may include various ancillary medical devices such as an infusion pump, a vital signs monitor, a medication dispensing device (e.g., cabinet, tote), a medication preparation device, an automated dispensing device, a module coupled with one of the aforementioned (e.g., a syringe pump module configured to attach to an infusion pump), or other similar devices. Each element 12 is connected to an internal healthcare network 10 by a transmission channel 31. Transmission channel 31 is any wired or wireless transmission channel, for example an 802. 11 wireless local area network (LAN). In some implementations, network 10 also includes computer systems located in various departments throughout a hospital. For example, network 10 of FIG. 1A optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers and/or a medical decision support system. As described further below, network 10 may include discrete subnetworks. In the depicted example, network 10 includes a device network 40 by which patient care devices 12 (and other devices) communicate in accordance with normal operations.

[0041] Additionally, institutional patient care system 100 may incorporate a separate information system server 30, the function of which will be described in more detail below. Moreover, although the information system server 30 is shown as a separate server, the functions and programming of the information system server 30 may be incorporated into another computer, if such is desired by engineers designing the institution's information system. Institutional patient care system 100 may further include one or multiple device terminals 32 for connecting and communicating with information system server 30. Device terminals 32 may include personal computers, personal data assistants, mobile devices such as laptops, tablet computers, augmented reality devices, or smartphones, configured with software for communications with information system server 30 via network 10. [0042] Patient care device 12 comprises a system for providing patient care. Patient care device 12 may include or incorporate pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), therapy devices, and other drug delivery devices may be utilized according to the teachings set forth herein. In the depicted example, patient care device 12 comprises a control module 14, also referred to as interface unit 14 herein, connected to one or more functional modules 16, 18, 20, 22. Interface unit 14 includes a central processing unit (CPU) 50 connected to a memory, for example, random access memory (RAM) 58, and one or more interface devices such as user interface device 54, a coded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. Interface unit 14 also, although not necessarily, includes a main non-volatile storage unit 56, such as a hard disk drive or non-volatile flash memory, for storing software and data and one or more internal buses 64 for interconnecting the aforementioned elements.

[0043] In various implementations, user interface device 54 is a touch screen for displaying information to a user and allowing a user to input information by touching defined areas of the screen. Additionally, or in the alternative, user interface device 54 could include any means for displaying and inputting information, such as a monitor, a printer, a keyboard, softkeys, a mouse, a track ball and/or a light pen. Data input device 60 may be a bar code reader capable of scanning and interpreting data printed in bar coded format. Additionally, or in the alternative, data input device 60 can be any device for entering coded data into a computer, such as a device(s) for reading a magnetic strip, radio-frequency identification (RFID) devices whereby digital data encoded in RFID tags or smart labels (defined below) are captured by the reader 60 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage media. Other examples of data input device 60 include a voice activation or recognition device or a portable personal data assistant (PDA). Depending upon the types of interface devices used, user interface device 54 and data input device 60 may be the same device. Although data input device 60 is shown in FIG. 1A to be disposed within interface unit 14, it is recognized that data input device 60 may be integral within pharmacy system 34 or located externally and communicating with pharmacy system 34 through an RS-232 serial interface or any other appropriate communication means. Auxiliary interface 62 may be an RS-232 communications interface, however any other means for communicating with a peripheral device such as a printer, patient monitor, infusion pump or other medical device may be used without departing from the subject technology. Additionally, data input device 60 may be a separate functional module, such as modules 16, 18, 20 and 22, and configured to communicate with controller 14, or any other system on the network, using suitable programming and communication protocols.

[0044] Network connection 52 may be a wired or wireless connection, such as by Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any direct or indirect network connection may be used, including, but not limited to a telephone modem, an MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link or a WLANS connection or other wireless connection.

[0045] Functional modules 16, 18, 20, 22 are any devices for providing care to a patient or for monitoring patient condition. As shown in FIG. 1A, at least one of functional modules 16, 18, 20, 22 may be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluid to a patient. For the purposes of this discussion, functional module 16 is an infusion pump module. Each of functional modules 18, 20, 22 may be any patient treatment or monitoring device including, but not limited to, an infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor or an intracranial pressure monitor or the like. Functional module 18, 20 and/or 22 may be a printer, scanner, bar code reader or any other peripheral input, output or input/output device.

[0046] Each functional module 16, 18, 20, 22 communicates directly or indirectly with interface unit 14, with interface unit 14 providing overall monitoring and control of device 12. Functional modules 16, 18, 20, 22 may be connected physically and electronically in serial fashion to one or both ends of interface unit 14 as shown in FIG. 1A, or as detailed in Eggers et al. However, it is recognized that there are other means for connecting functional modules with the interface unit that may be utilized without departing from the subject technology. It will also be appreciated that devices such as pumps or patient monitoring devices that provide sufficient programmability and connectivity may be capable of operating as stand-alone devices and may communicate directly with the network without connected through a separate interface unit (or control unit) 14. As described above, additional medical devices or peripheral devices may be connected to patient care device 12 through one or more auxiliary interfaces 62. [0047] Each functional module 16, 18, 20, 22 may include module-specific components 76, a microprocessor 70, a volatile memory 72 and a nonvolatile memory 74 for storing information. It should be noted that while four functional modules are shown in FIG. 1A, any number of devices may be connected directly or indirectly to an interface unit (or control module) 14. The number and type of functional modules described herein are intended to be illustrative, and in no way limit the scope of the subject technology. Module-specific components 76 include any components necessary for operation of a particular module, such as a display device and/or a pumping mechanism for infusion pump module 16.

[0048] While each functional module may be capable of a least some level of independent operation, interface unit 14 monitors and controls overall operation of device 12. For example, as will be described in more detail below, interface unit 14 provides programming instructions to the functional modules 16, 18, 20, 22 and monitors the status of each module.

[0049] Patient care device 12 is capable of operating in several different modes, or personalities, with each personality defined by a configuration database. The configuration database may be a database 56 internal to patient care device, or an external database 37. A particular configuration database is selected based, at least in part, by patient-specific information such as patient location, age, physical characteristics, or medical characteristics. Medical characteristics include, but are not limited to, patient diagnosis, treatment prescription, medical history, medical records, patient care provider identification, physiological characteristics or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identification) or a patient care device's 10 location in the hospital or hospital computer network. Patient care information may be entered through interface device 52, 54, 60 or 62, and may originate from anywhere in network 10, such as, for example, from a pharmacy server, admissions server, laboratory server, and the like.

[0050] Medical devices incorporating aspects of the subject technology may be equipped with a Network Interface Module (NIM), allowing the medical device to participate as a node in a network. While for purposes of clarity the subject technology will be described as operating in an Ethernet network environment using the Internet Protocol (IP), it is understood that concepts of the subject technology are equally applicable in other network environments, and such environments are intended to be within the scope of the subject technology. [0051] Data to and from the various data sources can be converted into network-compatible data with existing technology, and movement of the information between the medical device and network can be accomplished by a variety of means. For example, patient care device 12 and network 10 may communicate via automated interaction, manual interaction, or a combination of both automated and manual interaction. Automated interaction may be continuous or intermittent and may occur through direct network connection 54 (as shown in FIG. 1A), or through RS232 links, MIB systems, RF links such as BLUETOOTH, IR links, WLANS, digital cable systems, telephone modems or other wired or wireless communication means. Manual interaction between patient care device 12 and network 10 involves physically transferring, intermittently or periodically, data between systems using, for example, user interface device 54, coded data input device 60, bar codes, computer disks, portable data assistants, memory cards, or any other media for storing data. The communication means in various aspects is bidirectional with access to data from as many points of the distributed data sources as possible. Decision-making can occur at a variety of places within network 10. For example, and not by way of limitation, decisions can be made in server 30, decision support, remote data server, hospital department or unit stations 32, or within patient care device 12 itself.

[0052] All direct communications with medical devices operating on a network in accordance with the subject technology may be performed through information system server 30, known as the remote data server (RDS). In accordance with aspects of the subject technology, network interface modules incorporated into medical devices such as, for example, infusion pumps or vital signs measurement devices, ignore all network traffic that does not originate from an authenticated RDS. The primary responsibilities of the RDS of the subject technology are to track the location and status of all networked medical devices that have NIMs, and maintain open communication

[0053] FIG. IB illustrates an example PCU 12, including a control module 14 together with connected medication delivery modules 16, 18, 20, 22, according to aspects of the subject technology. In some embodiments, medication delivery modules 16, 18, 20, 22 include plugin ports for expansion. Accordingly, a new medication delivery module may be attached to PCU 12 by coupling a connector through the plug-in ports, which may include electrical terminals so that the added medication delivery module 16, 18, 20, 22 may transmit and receive information to and from a control module 14. In some embodiments, the added medication delivery module 16, 18, 20, 22 may also receive power from control module 14 through a plug-in port. Control module 14 may include a main display 201, a memory and a processor (see FIG. 4), and may be configured to display operational parameters and medication delivery status, and further information associated with each of medication delivery modules 16, 18, 20, 22. According to various implementations, module displays may also display physiological data (e.g., vital signs) associated with a patient.

[0054] Main display 201 is configured to display one or more user interfaces for the display of operational parameters or other data associated with a module 16, 18, 20, 22, and/or physiological parameters associated with the patient. Main display 201 may include multiple user interfaces, with each individual user interface graphically displaying information for a respective one of medication modules, including information also displayed on a corresponding module displays. In some embodiments, control module 14 includes a communications module (including, e.g., an antenna), configured to communicate wirelessly with a controller, or with a network.

[0055] With reference to FIGS. 1A and IB, when a medication delivery module 16, 18, 20, 22 initiates an infusion of a medication to the patient, the control module 14 is configured to create and manage an infusion session within a memory of the control module (or related module). For the purpose of this disclosure, the infusion session includes state information of the PCU 12, its control module 14, and/or its associated modules, which is recorded and saved to memory during a particular period of time. The state information includes, but is not limited to, records of parameter values utilized by the PCU, its control module, and/or its associated modules during the period of time, and/or records physiological data collected during the period of time. During the infusion, physiological data associated with the patient is recorded within the session, operating parameter values, and any modifications to the operating parameters of the PCU, its control module, and/or modules are also recorded in the session.

[0056] If not already logged into the PCU 12, the clinician may scan his or her badge proximate to a sensor (e.g., 54, 60) on the PCU 12, and the PCU may attempt to authenticate the clinician by sending the clinician’s scanned identification to server 30. The clinician’s badge may incorporate a radio frequency identification device (RFID), which is read by a scanner integrated with the PCU, or a portable scanner associated with the PCU. The clinician may scan his or her badge at the control module 14 to identify and authorize the clinician to initiate the administration of a medication. Once the clinician is associated with the PCU and/or module(s), the clinician’s identification is associated with the session. The same is applicable with a patient. The clinician may scan the patient’s wristband with a portable scanner, or using the sensor on the PCU 12 (or its control module) to associate the patient with the PCU and/or module(s) (and a session).

[0057] The control unit 14 of PCU 12 is configured to generate a graphical representation of the infusion session, and display (e.g., in display 201) the graphical representation, including a graphical visualization of all parameters of the infusion during the session and any modifications any modifications to the parameters, together with physiological data obtained during the session. The graphical representation may include pseudo identifiers for unknown data until such data is substituted with known identifiers. At that time, the graphical representation is displayed with the known patient identifiers.

[0058] FIG. 2 is a conceptual diagram illustrating an example infusion control system configured to dynamically connect to and receive data from different sensors to control different infusion therapies and to integrate with a cloud based data consolidation analytics and control system, according to aspects of the subject technology.

[0059] A Decision Control Module (DCM) 202 integrates with one or more cloud-based machine learning models (MLMs) and related databases 204 to provide a protocol engine with decision control features to assist a clinician in developing an infusion protocol for individualized treatment of a patient. In the depicted example, the DCM 202 includes a standalone device with multiple configurable hardware interfaces that receives input from various sensors and data sources. The DCM includes a communication interface device 206 for communicating with one or more remote servers including, for example, an EMR and for providing parameters and other related therapy information to MLMs and databases 204. As depicted in FIG. 2, the communication interface device 206 may further receive patient- related information 208 from one or more external devices including, for example, multiparameter monitor data, patient demographics, biophysical sensors connected to a patient, and laboratory test results. Communication interface device may be connected to a data coordination module 210 (software or hardware) for coordinating receipt and transmission of data.

[0060] The DCM may be simultaneously connected to, via a pump device interface 212, one or more medical devices 12 including, for example, an infusion pump 12 such as an actuator pump, syringe pump, a large volume infusion pump, or a modular infusion pump. The DCM may incorporate an algorithm 224 that remotely controls an IV infusion of medication or fluids by the infusion pump. As will be described further, the DCM may be configured to dynamically determine and/or load one or more algorithms to control an infusion in different ways. For example, an algorithm may control a Pharma Kinetic (PK) infusion, Titration Controlled Infusion (TCI) infusion, Proportional Integrative Derivative (PID) infusion, or other proprietary control infusion.

[0061] The disclosed DCM integrates and/or communicates with a machine learning database 214, which provides PK patient models based on demographics, disease models, and clinical tests and/or test data. A machine learning and data integrator receives 216 these models as input, in addition to PK drug models 218 and clinician protocol preferences and clinical decision choices 220 (from a clinician database), to provide model based precision dosing 222, which is then used by the DCM in controlling and/or managing an infusion. DCM 202 further includes a control optimizer 226 for receiving input from a user/clinician to further optimize and/or control the treatment provided by the overall system (including connected devices). In this regard, control optimizer 226 is configured to receive operational parameters, including identification of the clinician and/or the patient, and selection of the condition to be treated in the patient (and controlled by the DCM), and to provide further adjustments to parameters associated with the treatment, including adjustments to a monitored dose of medication. Control optimizer 224 may receive such input from a connected input device such as a keyboard, touch screen interface (e.g., on a display of the DCM), or via another connected device. Accordingly, the overall system collectively defines an infusion protocol coupled with a protocol engine that allows individualized treatment for the patient. The EMR and/or the cloud based systems 204 may be implemented, for example, by one or more information system servers 30 and/or databases 37 described in FIG. 1.

[0062] IV infusion devices 12 or other delivery devices may be directly controlled by the DCM 202 using serial, wired or wireless network connectivity (Ethernet or WIFI), Other wireless connectivity such as BLE. Where specialized connectivity might be required then a predetermined I/O module corresponding to the type of device may be connected. Accordingly, external devices that may be connected to the DCM may include, for example, a badge RFID reader (e.g., for tasks such as NFC tap to associate, patients, sensors, pumps, clinician login), a bio identification device (e.g., a fingerprint or retina scanner), or a backup battery for power loss or ambulatory usage.

[0063] The DCM further may further include a display 228 configured to provide a user interface for display of information pertaining to patient physiological status, as well as system control status. In some implementations, display module circuitry within the DCM housing may provide display information to an external display device. Being able to connect to another display provides modular scalability. For example, if the use case requires a rich user interface with clinician displays including data and graphs, a larger high-resolution display could be used. If the use case requires a display with minimal information and UI to support configuration, then a smaller, space saving and lower cost locally connected display could be used.

[0064] The DCM may be connected to a local display by cable or directly attached to form a combined module pair. The DCM may also be configured with minimal or no local display (e.g., “headless”) capabilities, and configured to wirelessly connect to a mobile device such as a smartphone or tablet (e.g., via BLUETOOTH) and to display information via a mobile application operating on the remote device. Display information may also be provided to an external clinician display or portal for display with other information specific to the portal. In some implementations, the DCM may include an integrated display device. In some implementations, the DCM may share a display with one or more medical devices. For example, both an infusion pump and the DCM may share a single external display for the presentation of information and/or control of infusion parameters.

[0065] The DCM may also include networking hardware for wirelessly connecting with a wireless hub or other network device of network 10, 40, thereby providing network communications with server 30, PCU 12, or other network-enabled devices operably connected to a cloud-based system (e.g., via the network 10, 40). For example, patient information may be downloaded by the DCM from an external system, limits of an infusion associated with the DCM set based on the patient information, and the flow rate of the infusion provided by a connected infusion device controlled by the DCM based on the limits and/or the patient information. In some implementations, the DCM 202 may be connected remotely to a PCU 12 or infusion pump through the server 30 and/or network 10, 40. For example, the DCM may be implemented as a mobile device or remote device 32.

[0066] The DCM and/or other system(s) disclosed herein may further integrate biosensing, via input to the communication interface device 204 from one or more connected biophysical sensors coupled to the patient, to monitor the patient’s response to the treatment and adjust it as necessary. The biosensing can come from both biophysical sensors and or laboratory tests. The system can use mathematical models that simulate the progression of the disease and in combination with PK (Pharmacokinetics) models of the medication can determine an administration profile for an individual being treated for one of several different disease states.

[0067] FIG. 3 depicts a first example process and workflow 300 for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology. The depicted workflow may be implemented by, for example, via inputs and processing at a DCM in combination with the previously described cloud system(s) and/or databases and other processes depicted in FIG. 2. In this regard, the disclosed protocol definition tool allows the clinician to select the treatment condition from a register containing multiple types of patient demographics, conditions, and the desired treatment.

[0068] When the DCM 202 is connected to an infusion pump 12, a user may initiate 302 a therapy under the disclosed Model Based Infusion Control (MBIC) or the healthcare organization’s standard protocol(s). For example, the user may place the DCM in a bypass mode whereby the standard protocol is used to program an infusion. Such protocols may include use of standard drug libraries and/or automated programming requests initiated via an EMR. Alternatively, the DCM 202 may activate the disclosed MBIC to provide data driven guidance based on patient models and PK model algorithm(s) to administer a medication. In this regard, the MBIC provides guidance to the clinician when and how to modify the dose in real-time, adaptively, or assume closed loop control of the connected infusion pump 12 to administer the medication automatically.

[0069] When MBIC is activated, the DCM 202 (e.g., via an input device) is capable of receiving multiple types of inputs 304. Inputs include, for example, patient parameters (e.g., demographic information, an identification of a patient, etc.), a condition/disease to be treated, a medication to be used in the treatment (e.g., to be controlled by the MBIC), a clinician identifier, and/or biosensing and biomarker information. On input of inputs 304, the DCM 202 is configured to access a collection of databases and/or machine learning models 306. These databases/models 306 may include or may be part of the cloud-based machine learning models (MLMs) and related databases 204 described with regard to FIG. 2. According to various implementations, the MLMs are trained to simulate progression of various diseases/conditions across a patient population under a care of a population of physicians in a healthcare organization, and to determine how the progression of each of the conditions is affected by respective medication decisions made by one or more of physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications.

[0070] Based on inputs 304, the DCM monitors biomarkers associated with the patient. For example, the DCM may receive measurements of heart rate, blood pressure, oxygen levels and/or other physiological parameters. Based on this monitoring and inputs 304, the MLMs may determine a dose of the medication for administration to the patient by the infusion device 12 to maintain one or more predetermined biomarkers in a predetermined effective range for a treatment of the condition/disease to be treated. The DCM may further include, in coordination with the MLMs, an infusion protocol generator 310 that determines a set of rules for ongoing administration of the medication. For example, the generator 310 may determine limits and/or ranges in which the patient biomarkers should be maintained for proper outcome of the relevant therapy. The generator 310 may further put in place rules whereby when certain conditions are met (e.g., a biomarker satisfies a predetermined threshold, after or upon satisfying a predetermined period of time, etc.), the infusion protocol can be adjusted. For example, a sample rate or frequency of sensing the biomarkers may be increased (e.g., biosensor optimization), and/or the dose of the medication being administered to the patient may be titrated or reduced (e.g., protocol intelligence modifiers). The conditions to be met may be provided by a lookup table within, for example, databases 220 and indexed based on one or more of inputs 304.

[0071] Execution 312 of a determined protocol includes, for example, programming the infusion pump 12 to administer an IV infusion of the medication, biosensor monitoring, and ongoing control 314 of the IV infusion according to rules implemented by the protocol generator 310. During execution 312, the DCM may store data pertaining to the infusion, including dosing parameters associated with the medication and the treatment of the condition (e.g., the dose(s) determined by the MLMs). The DCM may terminate treatment automatically when certain conditions of put in place by the protocol generator 310 are met, or the user may terminate the treatment manually (e.g., by way of input 304). On receiving an indication that the treatment of the condition has terminated, the DCM may perform and/or generate post-treatment analytics 316 including, for example, determining a treatment outcome(s) related to the condition and updating the training of the MLMs based on the stored data and treatment outcome(s). The DCM may further include a report generator 318 that may generate reports based on the post-treatment analytics for transmission to and storage at server 30/database 37 as part of the patient’s EMR. Additionally or in the altemative, the report may be augmented with EMR data from the server/database and provided on a display of the DCM or other associated device.

[0072] FIG. 4 depicts a second example process 350 for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology. For explanatory purposes, the various blocks of example process 350 are described herein with reference to FIGS. 1-3 and the associated components and/or processes described herein. According to various implementations, process 350 is a streamlined variation of process 300. The one or more of the blocks of process 350 may be implemented, for example, by DCM 202, including one or more associated computing devices including, for example, server 30 and infusion pump 12. In some implementations, and as described herein, one or more of the blocks may be implemented based on one or more machine learning algorithms. In some implementations, one or more of the blocks may be implemented apart from other blocks, and by one or more different processors or devices. Further, for explanatory purposes, to the extent that the blocks of example process 350 are described as occurring in serial, or linearly, in some implementations, multiple blocks of example process 350 may occur in parallel. In addition, the blocks of example process 350 need not be performed in the order shown and/or one or more of the blocks of example process 350 need not be performed.

[0073] According to various implementations, one or more machine learning models are trained (352) to simulate progression of a plurality of conditions across a patient population under a care of a plurality of physicians in a healthcare organization. According to various implementations, these MLMs are also trained (352) to determine how the progression of each of the plurality of conditions is affected by respective medication decisions made by one or more of the plurality of physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications. As discussed with regard to FIG. 2, the MLMs may utilize data from ML databases 214, PK drug models 218, and databases storing clinician protocol preferences and clinical decision choices 220. With reference to FIG. 3, in some implementations, which of these databases are used (306) by the MLMs may be based on inputs 304 received from a user operating the DCM.

[0074] In the depicted example, the inputs 304 received by the DCM (e.g., from the user and/or from an external system) include an identification of a patient and a selection of a condition to be treated in the patient (354). Based on the patient identification, the DCM may obtain patient information, including a characteristic of the patient (356). Characteristics may be associated with the patient identification in a database or may be entered or selected manually by a user at a user interface of the DCM. The characteristics may include demographics such as gender, age, weight, height, race, ethnicity, genetic background and the like, or background history such as a history of physical activity, smoking, drinking, job conditions, past medical conditions and the like. In some implementations, an identification of a clinician may be received. If received, the MLMs may receive or obtain access to data pertaining to the identified clinician from databases 220 including, for example, a history of medication decisions (e.g., prescribing decisions) in view of patient conditions. In this regard, the identified clinician may be one of the physicians upon which the machine learning models was trained, and thus the clinician’s history may be considered in the model’s determinations.

[0075] The system monitors, in real time, one or more biomarkers associated with the patient (358). The monitoring may be by way of receiving signals and/or measurement data from biophysical sensors connected to the patent. For example, the system may monitor heart rate, blood pressure, oxygenation, FiO2, , ECG/EEG data, and the like. In some implementations, the monitoring includes receiving measurement data associated with a laboratory test associated with the patient. For example, the system may obtain a blood concentration of a medication (e.g., provided during the therapy) from a lab result posted to the patient’s EMR.

[0076] The system determines, in real time by the one or more machine learning models, based on the monitoring and inputs of the characteristic of the patient and the condition to be treated, a dose of a medication to administer to the patient to maintain at least one of the biomarkers in a predetermined effective range for a treatment of the condition (360). As described previously, the models may have access to multiple databases across the healthcare organization, including patient population data over time, pharmacokinetic drug models, clinician historical data, disease models, clinical test data (which may be anonymized), demographic models, and the like. Accordingly, the machine learning model(s) makes a determination of how the medication affects the condition of the patient based on one or more of these models, and determines the best dose (or adjustment to a current dose) of the medication to administer to obtain the most optimal therapeutic outcome from the patient.

[0077] The system then causes (362) an infusion pump 12 to administer the determined dose of the medication to the patient. In this regard, the system may adjust a current dose of the medication being provided by the infusion pump (e.g., increase or decrease the flow rate of the drug, or a volume to be infused (VTBI)). According to various implementations, the monitoring step (358), determining step (360), and causing step (362) are continuously repeating during the treatment of the condition.

[0078] In some implementations, the system may prompt (e.g., on display 228 of the DCM, or via the DCM’s display module) for a user confirmation of the determined dose before the DCM instructs the infusion pump 12. In some implementations, the system may modulate prompting based on a history of the clinician’s actions. For example, the system may prompt the clinician for a confirmation of the dose before each time the infusion pump is caused to deliver (or adjust) a determined dose, but begin to bypass the prompting after the clinician dismisses the prompting without providing the confirmation a threshold number of times. In some implementations, the system may determine a current state of the condition being treated in the patient, and adjust the dose of the medication by an amount based on one or more historical adjustments made by the clinician in view of the current state of the condition. For example, when a biomarker (e.g., blood pressure) reaches a predetermined threshold when treating cardiac arrythmia, the clinician may have a history of reducing the medication by 10%. Accordingly, the system may automatically prompt for a reduction of the same amount when the threshold is reached.

[0079] According to various implementations, the DCM displays, on its display 228 or a related user interface, data related to the patient and the treatment of the condition in real time while the condition is being treated (e.g., during an infusion). In some implementations, the system may display an indication of the determined dose and a modeled response of the condition in the patient based on the determined dose. A user may request (e.g., via input 304) for a notification of when the at least one biomarker reaches a threshold level, and the system may calculate a trend and a point in time when the at least one biomarker will reach the threshold level, and provide the trend and the point in time on the display 228 or related user interface (e.g., as a notification).

[0080] The example processes 300 and 350 and related features and applications, may also be implemented as software processes that are specified as a set of instructions recorded on a computer readable storage medium (also referred to as computer readable medium), and may be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing unit(s) (e.g., one or more processors, cores of processors, or other processing units), they cause the processing unit(s) to perform the actions indicated in the instructions. Examples of computer readable media include, but are not limited to, CD- ROMs, flash drives, RAM chips, hard drives, EPROMs, etc. The computer readable media does not include carrier waves and electronic signals passing wirelessly or over wired connections.

[0081] The term “software” is meant to include, where appropriate, firmware residing in read-only memory or applications stored in magnetic storage, which can be read into memory for processing by a processor. Also, in some implementations, multiple software aspects of the subject disclosure can be implemented as sub-parts of a larger program while remaining distinct software aspects of the subject disclosure. In some implementations, multiple software aspects can also be implemented as separate programs. Finally, any combination of separate programs that together implement a software aspect described here is within the scope of the subject disclosure. In some implementations, the software programs, when installed to operate on one or more electronic systems, define one or more specific machine implementations that execute and perform the operations of the software programs.

[0082] A computer program (also known as a program, software, software application, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and it can be deployed in any form, including as a stand-alone program or as a module, component, subroutine, object, or other unit suitable for use in a computing environment. A computer program may, but need not, correspond to a file in a file system. A program can be stored in a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files that store one or more modules, sub programs, or portions of code). A computer program can be deployed to be executed on one computer or on multiple computers that are located at one site or distributed across multiple sites and interconnected by a communication network.

[0083] FIG. 5 is a conceptual diagram illustrating an example electronic system 400 for intelligent individualized control of an infusion device using a model-based protocol engine, according to aspects of the subject technology. Electronic system 400 may be a computing device for execution of software associated with one or more portions or steps of process 350, or components and processes provided by FIGS. 1-4, including but not limited to the disclosed DCM, information system server 30, database 37, computing hardware within patient care device 12, control unit 14, a respective module 16, 18, 20, 22, or a remote device 32 (e.g., a mobile device). Electronic system 400 may be representative, in combination with the disclosure regarding FIGS. 1-3. In this regard, electronic system 400 may be a personal computer or a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or any other sort of computer-related electronic device having network connectivity.

[0084] Electronic system 400 may include various types of computer readable media and interfaces for various other types of computer readable media. In the depicted example, electronic system 400 includes a bus 408, processing unit(s) 412, a system memory 404, a read-only memory (ROM) 410, a permanent storage device 402, an input device interface 414, an output device interface 406, and one or more network interfaces 416. In some implementations, electronic system 400 may include or be integrated with other computing devices or circuitry for operation of the various components and processes previously described.

[0085] Bus 408 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of electronic system 400. For instance, bus 408 communicatively connects processing unit(s) 412 with ROM 410, system memory 404, and permanent storage device 402.

[0086] From these various memory units, processing unit(s) 412 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure. The processing unit(s) can be a single processor or a multi-core processor in different implementations.

[0087] ROM 410 stores static data and instructions that are needed by processing unit(s) 412 and other modules of the electronic system. Permanent storage device 402, on the other hand, is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when electronic system 400 is off. Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 402.

[0088] Other implementations use a removable storage device (such as a floppy disk, flash drive, and its corresponding disk drive) as permanent storage device 402. Like permanent storage device 402, system memory 404 is a read-and-write memory device. However, unlike storage device 402, system memory 404 is a volatile read-and-write memory, such as a random access memory. System memory 404 stores some of the instructions and data that the processor needs at runtime. In some implementations, the processes of the subject disclosure are stored in system memory 404, permanent storage device 402, and/or ROM 410. From these various memory units, processing unit(s) 412 retrieves instructions to execute and data to process in order to execute the processes of some implementations.

[0089] Bus 408 also connects to input and output device interfaces 414 and 406. Input device interface 414 enables the user to communicate information and select commands to the electronic system. Input devices used with input device interface 414 include, e.g., alphanumeric keyboards and pointing devices (also called “cursor control devices”). Output device interfaces 406 enables, e.g., the display of images generated by the electronic system 400. Output devices used with output device interface 406 include, e.g., printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.

[0090] Also, as shown in FIG. 5, bus 408 also couples electronic system 400 to a network (not shown) through network interfaces 416. Network interfaces 416 may include, e.g., a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interfaces 416 may also include hardware (e.g., Ethernet hardware) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet. Any or all components of electronic system 400 can be used in conjunction with the subject disclosure.

[0091] These functions described above can be implemented in computer software, firmware, or hardware. The techniques can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. The processes and logic flows can be performed by one or more programmable processors and by one or more programmable logic circuitry. General and special purpose computing devices and storage devices can be interconnected through communication networks.

[0092] Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media). Some examples of such computer- readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD-ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu- Ray® discs, ultra density optical discs, any other optical or magnetic media, and floppy disks. The computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.

[0093] While the above discussion primarily refers to microprocessor or multi-core processors that execute software, some implementations are performed by one or more integrated circuits, such as application specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs). In some implementations, such integrated circuits execute instructions that are stored on the circuit itself.

[0094] As used in this specification and any claims of this application, the terms “computer”, “server”, “processor”, and “memory” all refer to electronic or other technological devices. These terms exclude people or groups of people. For the purposes of the specification, the terms display or displaying means displaying on an electronic device. As used in this specification and any claims of this application, the terms “computer readable medium” and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.

[0095] To provide for interaction with a user, implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer. Other kinds of devices can be used to provide for interaction with a user as well; e.g., feedback provided to the user can be any form of sensory feedback, e.g., visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input. In addition, a computer can interact with a user by sending documents to and receiving documents from a device that is used by the user; e.g., by sending web pages to a web browser on a user’s client device in response to requests received from the web browser.

[0096] The subject matter described in this specification can be implemented in a computing system that includes a back end component, e.g., as a data server, or that includes a middleware component, e.g., an application server, or that includes a front end component, e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification, or any combination of one or more such back end, middleware, or front end components. The components of the system can be interconnected by any form or medium of digital data communication, e.g., a communication network. Examples of communication networks include a local area network (“LAN”) and a wide area network (“WAN”), an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).

[0097] The computing system can include clients and servers. A client and server are generally remote from each other and may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. In some embodiments, a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device). Data generated at the client device (e.g., a result of the user interaction) can be received from the client device at the server.

[0098] Those of skill in the art would appreciate that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein may be implemented as electronic hardware, computer software, or combinations of both. To illustrate this interchangeability of hardware and software, various illustrative blocks, modules, elements, components, methods, and algorithms have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. The described functionality may be implemented in varying ways for each particular application. Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way) all without departing from the scope of the subject technology. [0099] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[00100] Illustration of Subject Technology as Clauses:

[00101] Various examples of aspects of the disclosure are described as numbered clauses (1, 2, 3, etc.) for convenience. These are provided as examples, and do not limit the subject technology. Identifications of the figures and reference numbers are provided below merely as examples and for illustrative purposes, and the clauses are not limited by those identification

[00102] Clause 1. A machine-implemented method for intelligently individualized control of an infusion device, comprising: training one or more machine learning models to simulate progression of a plurality of conditions across a patient population under a care of a plurality of physicians in a healthcare organization, and to determine how the progression of each of the plurality of conditions is affected by respective medication decisions made by one or more of the plurality of physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications; receiving an identification of a patient and a selection of a condition to be treated in the patient; identifying a characteristic of the patient; monitoring, in real time, one or more biomarkers associated with the patient; determining, in real time by the one or more machine learning models, based on the monitoring and inputs of the characteristic of the patient and the condition to be treated, a dose of a medication to administer to the patient to maintain at least one of the biomarkers in a predetermined effective range for a treatment of the condition; and causing an infusion pump to administer the determined dose of the medication to the patient.

[00103] Clause 2. The method of Clause 1, further comprising: continuously repeating the monitoring, determining and causing steps during the treatment of the condition.

[00104] Clause 3. The method of Clause 1 or Clause 2, further comprising: receiving an identification of a clinician, wherein the determining by the one or more machine learning models is further based an input of the identification of the clinician, the clinician being one of the plurality of physicians in the healthcare organization represented by the one or more machine learning models.

[00105] Clause 4. The method of Clause 3, further comprising: determining a current state of the condition to be treated in the patient; and adjusting the dose of the medication by an amount based on one or more historical adjustments made by the clinician in view of the current state of the condition.

[00106] Clause 5. The method of Clause 3, further comprising: repeating the monitoring, determining and causing steps; and for each time the dose is determined: prompting the clinician for a confirmation of the dose before causing the infusion pump to deliver the determined dose; and bypassing the prompting after the clinician dismisses the prompting without providing the confirmation a threshold number of times.

[00107] Clause 6. The method of any one of Clauses 1-5, wherein the monitoring of the one or more biomarkers comprises: receiving measurement data from one or more biophysical sensors coupled to the patient.

[00108] Clause 7. The method of any one of Clauses 1-6, wherein the monitoring of the one or more biomarkers comprises: receiving measurement data associated with a laboratory test associated with the patient.

[00109] Clause 8. The method of Clause 7, wherein the measurement data comprises a drug concentration level, the method further comprising: determining the predetermined effective range based on the drug concentration level; or adjusting a sample rate of the monitoring based on the drug concentration level.

[00110] Clause 9. The method of any one of Clauses 1-8, wherein the characteristic of the patient includes one or more patient demographics selected from a group of demographics including age, gender, race, and ethnicity.

[00111] Clause 10. The method of any one of Clauses 1-9, further comprising: receiving a request for a notification of when the at least one biomarker reaches a threshold level; and responsive to the request for the notification: calculating a trend and a point in time when the at least one biomarker will reach the threshold level; and providing a notification of the trend and the point in time. [00112] Clause 11. The method of any one of Clauses 1-10, further comprising, prior to causing an infusion pump to administer the determined dose of the medication: prompting for a user confirmation of the determined dose; and receiving a confirmation of the determined dose.

[00113] Clause 12. The method of Clause 11, further comprising: displaying, on a user interface, an indication of the determined dose and a modeled response of the condition in the patient based on the determined dose.

[00114] Clause 13. The method of any one of Clauses 1-12, further comprising: storing, during the treatment of the condition, dosing parameters associated with the medication and the treatment of the condition; receiving an indication that the treatment of the condition has terminated; determining a treatment outcome related to the condition; and updating the training of the one or more machine learning models based on the stored dosing parameters and the treatment outcome.

[00115] Clause 14. A non-transitory machine readable medium storing instructions thereon that, when executed by a computing device, cause the computing device to perform a method according to any one of Clauses 1-13.

[00116] Clause 15. An infusion control device, comprising: a housing; a communication interface; an input device; a display; and a processor configured to perform a method according to any one of Clauses 1-14, wherein the communication interface is configured to interface the processor with the infusion pump, wherein the input device is configured to receive the identification of the patient and the selection of a condition to be treated in the patient and to receive adjustments to parameters associated with the treatment of the condition and to the dose of the medication, and wherein the display is configured to display an indication of the determined dose and the parameters associated with the treatment of the condition.

[00117] Further Consideration:

[00118] It is understood that the specific order or hierarchy of steps in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of steps in the processes may be rearranged. Some of the steps may be performed simultaneously. The accompanying method claims present elements of the various steps in a sample order, and are not meant to be limited to the specific order or hierarchy presented.

[00119] The previous description is provided to enable any person skilled in the art to practice the various aspects described herein. The previous description provides various examples of the subject technology, and the subject technology is not limited to these examples. Various modifications to these aspects will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other aspects. Thus, the claims are not intended to be limited to the aspects shown herein, but is to be accorded the full scope consistent with the language claims, wherein reference to an element in the singular is not intended to mean “one and only one” unless specifically so stated, but rather “one or more.” Unless specifically stated otherwise, the term “some” refers to one or more. Pronouns in the masculine (e.g., his) include the feminine and neuter gender (e.g., her and its) and vice versa. Headings and subheadings, if any, are used for convenience only and do not limit the invention described herein.

[00120] The predicate words “configured to”, “operable to”, and “programmed to” do not imply any particular tangible or intangible modification of a subject, but, rather, are intended to be used interchangeably. For example, a processor configured to monitor and control an operation, or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation. Likewise, a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.

[00121] The term automatic, as used herein, may include performance by a computer or machine without user intervention; for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism. The word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.

[00122] A phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology. A disclosure relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. A phrase such as an aspect may refer to one or more aspects and vice versa. A phrase such as an “embodiment” does not imply that such embodiment is essential to the subject technology or that such embodiment applies to all configurations of the subject technology. A disclosure relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. A phrase such as an “embodiment” may refer to one or more embodiments and vice versa. A phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology. A disclosure relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. A phrase such as a “configuration” may refer to one or more configurations and vice versa.

[00123] As used herein a “user interface” (also referred to as an interactive user interface, a graphical user interface or a UI) may refer to a network based interface including data fields and/or other control elements for receiving input signals or providing electronic information and/or for providing information to the user in response to any received input signals. Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI. A UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASH™, JAVA™, .NET™, C, C++, web services, or rich site summary (RSS). In some embodiments, a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described. The communication may be to or from a medical device or server in communication therewith.

[00124] As used herein, the terms “determine” or “determining” encompass a wide variety of actions. For example, “determining” may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database or another data structure), ascertaining and the like via a hardware element without user intervention. Also, “determining” may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention. “Determining” may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention. [00125] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like. “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.

[00126] As used herein, the term “message” encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information. A message may include a machine readable aggregation of information such as an XML document, fixed field message, comma separated message, JSON, a custom protocol, or the like. A message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.

[00127] As used herein, the term “selectively” or “selective” may encompass a wide variety of actions. For example, a “selective” process may include determining one option from multiple options. A “selective” process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination. In some implementations, an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.

[00128] As user herein, the terms “correspond” or “corresponding” encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fuzzy logic, pattern matching, a machine learning assessment model, or combinations thereof.

[00129] In any embodiment, data generated or detected can be forwarded to a “remote” device or location, where “remote,” means a location or device other than the location or device at which the program is executed. For example, a remote location could be another location (e.g., office, lab, etc.) in the same city, another location in a different city, another location in a different state, another location in a different country, etc. As such, when one item is indicated as being “remote” from another, what is meant is that the two items can be in the same room but separated, or at least in different rooms or different buildings, and can be at least one mile, ten miles, or at least one hundred miles apart. “Communicating” information references transmitting the data representing that information as electrical signals over a suitable communication channel (e.g., a private or public network). “Forwarding” an item refers to any means of getting that item from one location to the next, whether by physically transporting that item or otherwise (where that is possible) and includes, at least in the case of data, physically transporting a medium carrying the data or communicating the data. Examples of communicating media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the internet or including email transmissions and information recorded on websites and the like.

Claims

What is claimed is:

1. A machine-implemented method for intelligent individualized control of an infusion device, comprising: training one or more machine learning models to simulate progression of a plurality of conditions across a patient population under a care of a plurality of physicians in a healthcare organization, and to determine how the progression of each of the plurality of conditions is affected by respective medication decisions made by one or more of the plurality of physicians regarding (i) dosing of one or more medications and (ii) a respective pharmacokinetic model of the one or more medications; receiving an identification of a patient and a selection of a condition to be treated in the patient; identifying a characteristic of the patient; monitoring, in real time, one or more biomarkers associated with the patient; determining, in real time by the one or more machine learning models, based on the monitoring and inputs of the characteristic of the patient and the condition to be treated, a dose of a medication to administer to the patient to maintain at least one of the biomarkers in a predetermined effective range for a treatment of the condition; and causing an infusion pump to administer the determined dose of the medication to the patient.

2. The method of Claim 1, further comprising: continuously repeating the monitoring, determining and causing steps during the treatment of the condition.

3. The method of Claim 1 or Claim 2, further comprising: receiving an identification of a clinician, wherein the determining by the one or more machine learning models is further based an input of the identification of the clinician, the clinician being one of the plurality of physicians in the healthcare organization represented by the one or more machine learning models.

4. The method of Claim 3, further comprising: determining a current state of the condition to be treated in the patient; and adjusting the dose of the medication by an amount based on one or more historical adjustments made by the clinician in view of the current state of the condition.

5. The method of Claim 3, further comprising: repeating the monitoring, determining and causing steps; and for each time the dose is determined: prompting the clinician for a confirmation of the dose before causing the infusion pump to deliver the determined dose; and bypassing the prompting after the clinician dismisses the prompting without providing the confirmation a threshold number of times.

6. The method of any one of Claims 1-5, wherein the monitoring of the one or more biomarkers comprises: receiving measurement data from one or more biophysical sensors coupled to the patient.

7. The method of any one of Claims 1-6, wherein the monitoring of the one or more biomarkers comprises: receiving measurement data associated with a laboratory test associated with the patient.

8. The method of Claim 7, wherein the measurement data comprises a drug concentration level, the method further comprising: determining the predetermined effective range based on the drug concentration level; or adjusting a sample rate of the monitoring based on the drug concentration level.

9. The method of any one of Claims 1-8, wherein the characteristic of the patient includes one or more patient demographics selected from a group of demographics including age, gender, race, and ethnicity.

10. The method of any one of Claims 1-9, further comprising: receiving a request for a notification of when the at least one biomarker reaches a threshold level; and responsive to the request for the notification: calculating a trend and a point in time when the at least one biomarker will reach the threshold level; and providing a notification of the trend and the point in time.

11. The method of any one of Claims 1-10, further comprising, prior to causing an infusion pump to administer the determined dose of the medication: prompting for a user confirmation of the determined dose; and receiving a confirmation of the determined dose.

12. The method of Claim 11, further comprising: displaying, on a user interface, an indication of the determined dose and a modeled response of the condition in the patient based on the determined dose.

13. The method of any one of Claims 1-12, further comprising: storing, during the treatment of the condition, dosing parameters associated with the medication and the treatment of the condition; receiving an indication that the treatment of the condition has terminated; determining a treatment outcome related to the condition; and updating the training of the one or more machine learning models based on the stored dosing parameters and the treatment outcome.

14. A non-transitory machine readable medium storing instructions thereon that, when executed by a computing device, cause the computing device to perform a method according to any one of Claims 1-13.

15. An infusion control device, comprising: a housing; a communication interface; an input device; a display; and a processor configured to perform a method according to any one of Claims 1-14, wherein the communication interface is configured to interface the processor with the infusion pump, wherein the input device is configured to receive the identification of the patient and the selection of a condition to be treated in the patient and to receive adjustments to parameters associated with the treatment of the condition and to the dose of the medication, and wherein the display is configured to display an indication of the determined dose and the parameters associated with the treatment of the condition.