Protocol engine for personalized patient therapy

Abstract

A system and method for intelligently controlled personalized infusion are described. A machine learning model is trained to simulate the development of multiple conditions in a patient population under the care of multiple physicians and to determine how the development of each condition is influenced by corresponding drug decisions made by one or more physicians regarding (i) the dosage of one or more drugs and (ii) the corresponding pharmacokinetic models of one or more drugs. The system selects the condition to be treated for the patient, monitors the patient's biomarkers, and determines the drug dosage to be administered to the patient in real time to maintain at least one biomarker within a predetermined effective range. The system drives an infusion pump to administer that dosage of drug to the patient and continuously adjusts the dosage based on reassessment of the biomarkers.

Description

Technical Field

[0001] This disclosure generally relates to a control device configured to facilitate the operation of a medical device. Background Technology

[0002] Current practice of intravenous (IV) administration of therapeutic drugs involves clinicians making decisions about drug dosage and timing to achieve the desired clinical effect. These decisions can be based on standard protocols or clinical experience. This can involve imprecise judgment and the use of simplistic calculations to determine the dosage based on the drug's pharmacokinetic properties and the specific circumstances of a particular patient. Typically, this leads to following standard protocols for general patients, which may not be suitable for individual patients. Consequently, this can result in overdosing or underdosing, and repeated titrations to achieve the desired clinical response. This, in turn, leads to prolonged treatment time, increased costs, and other adverse effects on the patient. This is particularly important for drugs with a narrow therapeutic range, requiring a patient-specific target range. Some examples are chemotherapy for cancer and the need for a timely response in the treatment of sepsis. Summary of the Invention

[0003] This technology incorporates multiple features to define infusion protocols in conjunction with a protocol engine, allowing for personalized treatment for patients. In this regard, the technology includes a device control module containing a protocol definition tool that applies model-based treatments and approved protocols, combined with a protocol generation mechanism, to provide optimized infusion strategies for personalized patient care. The protocol definition tool allows clinicians to select treatment conditions from a registry containing various patient demographics, conditions, and required treatments.

[0004] The disclosed system integrates biosensors to monitor patient response to treatment and adjust accordingly. The biosensors can originate from biophysical sensors and / or laboratory tests. The disclosed system can use mathematical models simulating disease development, combined with pharmacokinetic (PK) models of drugs, to determine dosing for individuals treating one of several different disease states.

[0005] Model-based infusion control, through open combinations, can optimize drug delivery and reduce the burden and errors involved in manual calculations and trial-and-error to achieve the desired clinical response in individual patients. Machine learning algorithms are used to select and define appropriate clinical treatment regimens. Clinicians are able to fine-tune settings and review modeled responses to determine the optimal treatment strategy.

[0006] In this regard, the subject matter technology includes a method for the machine implementation of intelligent control of personalized infusion, comprising: training one or more machine learning models to simulate the development of multiple conditions in a patient population under the care of multiple physicians in a healthcare organization, and determining how the development of each of the multiple conditions is influenced by corresponding drug decisions made by one or more physicians regarding (i) the dosage of one or more drugs and (ii) the corresponding pharmacokinetic models of one or more drugs; receiving patient identification and selection of the patient's condition to be treated; identifying patient characteristics; monitoring one or more biomarkers associated with the patient in real time; determining, by one or more machine learning models in real time, the dosage of a drug to be administered to the patient based on the monitoring and input of patient characteristics and the condition to be treated, to maintain at least one biomarker within a predetermined effective range for treating the condition; and driving an infusion pump to administer the determined dose of drug to the patient. Other aspects include corresponding devices, systems, and computer program products for implementing the corresponding method and its features.

[0007] It should be understood that, through the following detailed description, those skilled in the art will readily understand other configurations of the subject matter, wherein various configurations in the subject matter are illustrated and described. As will be appreciated, the subject matter can have other and different configurations, and certain details thereof can be modified in various other ways without departing from the scope of the subject matter. Therefore, the accompanying drawings and detailed description should be considered illustrative in nature, rather than restrictive. Attached Figure Description

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

[0009] Figure 1A An example of an institutional patient care system for a healthcare organization based on aspects of the technology in this subject is depicted.

[0010] Figure 1B An example patient care unit according to aspects of the subject matter is shown, including a control unit and a connected drug delivery module.

[0011] Figure 2 This is a conceptual diagram illustrating an example infusion control system according to an aspect of the subject matter technology. The system is configured to dynamically connect to and receive data from different sensors to control different infusion therapies and to integrate with a cloud-based data integration analysis and control system.

[0012] Figure 3This paper describes a first example process and workflow for intelligent and personalized control of an infusion device using a model-based scheme engine, based on aspects of the technology in this subject matter.

[0013] Figure 4 A second example process is described, illustrating the use of a model-based scheme engine to achieve intelligent and personalized control of an infusion device, based on aspects of the technology in this subject matter.

[0014] Figure 5 This is a conceptual diagram illustrating an example electronic system for intelligent personalized control of an infusion device using a model-based scheme engine, based on aspects of the technology in this subject matter. Detailed Implementation

[0015] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. Numerous specific details are set forth in the following description to provide an understanding of the various described embodiments. However, it will be apparent to those skilled in the art that the various described embodiments can be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail to avoid unnecessarily obscuring various aspects of the embodiments.

[0016] This subject matter technology provides an intelligent device control module (or decision control module) (DCM) as part of a broader system, including units for control algorithm processing and connectivity to achieve closed-loop and semi-closed-loop control capabilities at the point of use for one or more medical devices. In some embodiments, the DCM provides an external interface between the IV infusion pump and one or more different physiological sensors, and provides input parameters for controlling the titration of IV drug infusions to a patient. In this regard, the DCM may include control software (including, for example, one or more algorithms) that can be customized for specific or general medical treatments.

[0017] Patient / Clinical Procedure Optimizer

[0018] This system uses multifactor classification for model extraction to determine the best model to describe the patient's condition. For example, the following parameters can be used, as well as other parameters that the system can also input and consider:

[0019] Demographic characteristics, namely, gender, age, weight, height, race, ethnicity, genetic background, etc.

[0020] Patient background history; that is, physical activity, smoking, alcohol consumption, work status, past medical history, etc.

[0021] Comorbid / chronic disease factors; namely, diabetes, hypertension, cancer, COPD, obesity, etc.

[0022] Disease Model

[0023] Disease models can be used in a variety of situations, some simple, others extremely complex. For example, mathematical models of cancer behavior include tumor growth models and the interactions between normal cells, immune cells, and cancer cells. Due to the highly nonlinear, high-dimensional, and complex nature of these mathematical models, modeling can be difficult to understand and use. Combining them with PK modeling of various drug administrations for multi-compartment models can also be time-consuming and difficult to use. However, by using computer modeling and incorporating machine learning to extract and model different strategies displayed through the user interface (UI) of the disclosed (Argus) system (e.g., in the display of the disclosed DCM), it becomes more practical and helps meet the needs of individual patients.

[0024] Pharmacokinetic (PK) model

[0025] The disclosed system uses a PK model to describe how the IV drug administered to a patient will define the absorption and physical areas for the desired treatment. PK models are available from studies conducted by the pharmaceutical companies developing the drugs. The direction of administration can be defined based on different compartmentalized models identified for the body site being treated.

[0026] MBIC Personalized Drug Administration Using Model Reference and Adaptive Control

[0027] The disclosed Model-Based Infusion Control (MBIC) is a system that combines disease model databases, PK drug model databases, patient demographic models, and protocol databases, incorporating them into a population-level database. This is achieved by combining population-level machine learning analysis and identifying cohort groups to determine cohort models describing individual patients.

[0028] The disclosed MBIC utilizes data-driven guidance to simulate dosing strategies that combine patient models and PK model algorithms for drug administration. The system can then provide guidance to clinicians on when and how to adaptively modify the dosage in real time, or to automatically administer the drug under closed-loop control.

[0029] This system uses a combination of monitoring and modeling algorithms for precise quantification. Therefore, by targeting the individual patient's desired drug exposure, both subtherapeutic and supertherapeutic doses can be avoided.

[0030] The system uses real-time and near real-time inputs from biophysical sensors and / or biomarkers that can be identified in laboratory tests, which can be input into a publicly available DCM or downloaded from the patient's EMR. The range of biomarkers is controlled by taking into account drug concentration levels from laboratory results to update the PK model and adjust infusion therapy as needed. This thus produces an improved PK model corresponding to the individual patient. This can also generate a PK model if one is not available for the drug being used.

[0031] circadian rhythm

[0032] Another factor this system uses to implement optimized drug therapy is the timing of drug administration based on circadian rhythms. Circadian rhythms are physiological cycles that can be associated with treatment. For example, in chemotherapy, this can be due to genetic mutations that may exhibit reduced adaptability or increased susceptibility, and / or other metabolic diseases that can vary throughout the day based on daily hormonal changes. Furthermore, drug efficacy and toxicity often vary with the time of day, significantly impacting treatment strategies. The MBIC system can use a population database and correlate it with different time intervals, as well as assess time-based periodic trends in biosensor responses, to determine the individual patient's circadian rhythm, thereby customizing optimized drug infusion therapy.

[0033] Biosensor sampling

[0034] Sampling time is a crucial aspect of pharmacokinetic analysis, significantly impacting inferences drawn from the resulting data. A balance must be struck between having sufficient time points to ensure data usefulness and applicability, cost, and other considerations regarding the quantity of blood samples collected from patients.

[0035] In clinical practice, the area under the curve (AUC) is used to assess drug administration in relation to blood concentration effects. Larger sample sizes may lead to better fits to pharmacokinetic (PK) results, but they also increase the number of samples and shorten the time intervals between samples. Therefore, it is necessary to optimize the time samples used to determine the AUC of PK data. A typically used approach is the Optimized Time Samples Using Trapezoidal Error Reduction (OTTER) algorithm, which aims to acquire PK data from a single individual or an average aggregate and return the optimal sampling time based on that data. This system can also be adjusted based on the testing frequency, and thus allows for smaller, more frequent interventions, resulting in more accurate quantification.

[0036] Integrating OTTER into the MBIC processor provides additional benefits to the infusion process. This will prevent subtherapeutic doses by targeting the desired drug exposure range. The program will recommend the timing and intervals for laboratory testing, as well as the types of laboratory tests to be performed.

[0037] Systems based on clinicians or standard hospital protocols

[0038] If needed, the disclosed system can incorporate a model based on hospital-recommended protocols. This model will be used to populate dosage parameters. Based on the preferences or choices of specific clinicians stored in a clinician database, intelligence can be introduced into specific steps or parts of established protocols.

[0039] The system will also allow for treatment modeling to compare MBIC protocols with standard protocols, allowing clinicians to tailor prescriptions to individual patients.

[0040] Clinician Adaptive System

[0041] The disclosed system will have a database collected for individual clinicians using the system. It will record user-selectable options for specific treatments, which are downloaded to the DCM when a clinician logs in and selects a treatment. The system will then populate the UI display with user preferences.

[0042] The system will learn based on type, frequency, and decisions made by clinicians, and can adjust itself based on historical clinician updates / corrections. For example, if a clinician consistently reduces the recommended value for a particular step by 10%, the system can suggest updating the protocol for that step. Furthermore, the system can learn when to stop asking questions or suggest switching to a closed loop instead of a semi-closed loop. For instance, if a clinician confirms the algorithm's decision 99 out of 100 times, it might suggest canceling confirmation of that decision step.

[0043] Clinician confirmation and notification can be selected by the user based on risk levels, and the user can determine the restrictions and levels to be set for notifications. For example, if a clinician wants to be notified when a certain parameter reaches a certain level, the algorithm of this subject matter technology can calculate the trend, determine the time point when that specific level will be reached, and provide the notification.

[0044] Post-treatment analysis

[0045] At the end of the treatment cycle, the collected data can then be incorporated into the system database, where machine learning can be used to further refine and improve the model and optimize future treatments.

[0046] This system provides documentation and record keeping for specific patients and treatments, which will be incorporated into the patient's EMR. The system will also save alert records and clinician notes.

[0047] Summary of clinical safety analysis

[0048] The disclosed system will record safety outcomes, as well as adverse events during treatment for each individual treatment event, and these will be aggregated to establish a data source for machine learning models, used to modify treatment, provide alerts, and / or offer alternative treatment recommendations to clinicians.

[0049] IV. Pipeline Blockage Detection

[0050] By tracking specific biomarkers recorded by biosensors connected to the patient, or by synchronously tracking laboratory tests in real time, and combining this with pressure in the IV tubing monitored by the IV pump using its in-line pressure monitor, the patient's pharmacokinetic (PK) response can be correlated. Through trend analysis of increased pressure and decreased clinical response in the patient, the disclosed system can issue alerts or warnings, allowing clinicians to take corrective action before the patient suffers any serious harm due to endoleaks / exoleaks or blockages in the IV tubing.

[0051] Figure 1A An example of an institutional patient care system 100 for a healthcare organization based on aspects of the technology of this subject is depicted. Figure 1A In this system, patient care devices (or generally "medical devices") 12 are connected to the hospital network 10. The term "patient care device" (or "PCD") may be used interchangeably with the term "patient care unit" (or "PCU"), either of which may include various assistive medical devices such as infusion pumps, vital sign monitors, medication dispensing devices (e.g., cabinets, briefcases), medication preparation devices, automated dispensing devices, modules coupled to one of the aforementioned devices (e.g., infusion pump modules configured to be attached to infusion pumps), or other similar devices. Each element 12 is connected to the internal healthcare network 10 via a transmission channel 31. The transmission channel 31 is any wired or wireless transmission channel, such as an 802.11 wireless local area network (LAN). In some embodiments, the network 10 also includes computer systems located in various departments throughout the hospital. For example, Figure 1A Network 10 may optionally include computer systems associated with admissions departments, billing departments, biomedical engineering departments, clinical laboratories, central supply departments, one or more unit station computers, and / or medical decision support systems. As further described below, network 10 may include discrete subnetworks. In the depicted example, network 10 includes a device network 40 through which patient care devices 12 (and other devices) communicate under normal operation.

[0052] Furthermore, the institutional patient care system 100 may include a separate information system server 30, the functions of which will be described in more detail below. Additionally, although the information system server 30 is shown as a separate server, its functionality and programming can be integrated into another computer if required by the engineers designing the institutional information system. The institutional patient care system 100 may also include one or more device terminals 32 for connecting to and communicating with the information system server 30. Device terminals 32 may include personal computers, personal data assistants, mobile devices such as laptops, tablets, augmented reality devices, or smartphones, configured with software for communicating with the information system server 30 via network 10.

[0053] Patient care device 12 includes a system for providing patient care. Patient care device 12 may include or contain pumps, physiological monitors (e.g., heart rate, blood pressure, ECG, EEG, pulse oximeter, and other patient monitors), treatment devices, and other drug delivery devices that may be utilized according to the teachings set forth herein. In the depicted example, patient care device 12 includes a control module 14, also referred to herein as interface unit 14, which is connected to one or more functional modules 16, 18, 20, 22. Interface unit 14 includes a central processing unit (CPU) 50 connected to memory (e.g., random access memory (RAM) 58), and one or more interface devices, such as a user interface device 54, an encoded data input device 60, a network connection 52, and an auxiliary interface 62 for communicating with additional modules or devices. Although not strictly necessary, interface unit 14 also includes a primary 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 components.

[0054] In various embodiments, the user interface device 54 is a touchscreen for displaying information to a user and allowing the user to input information by touching a defined area of ​​the screen. Additionally, or alternatively, the user interface device 54 may include any means for displaying and inputting information, such as a monitor, printer, keyboard, soft keys, mouse, trackball, and / or light pen. The data input device 60 may be a barcode reader capable of scanning and interpreting data printed in barcode format. Additionally, or alternatively, the data input device 60 may be any device for inputting encoded data into a computer, such as a device for reading magnetic stripes, a radio frequency identification (RFID) device, wherein digital data encoded in an RFID tag or smart tag (defined below) is captured by the reader 60 via radio waves, a PCMCIA smart card, an RFID card, a memory stick, a CD, DVD, or any other analog or digital storage medium. Other examples of the data input device 60 include voice-activated or recognition devices or portable personal data assistants (PDAs). Depending on the type of interface device used, the user interface device 54 and the data input device 60 may be the same device. Although the data input device 60 is... Figure 1A While shown as being housed within interface unit 14, it will be appreciated that data input device 60 may be integrated within pharmacy system 34 or located externally and communicate with pharmacy system 34 via an RS-232 serial interface or any other suitable communication means. Auxiliary interface 62 may be an RS-232 communication interface; however, without departing from the art of the subject, any other means for communicating with peripheral devices such as printers, patient monitors, infusion pumps, or other medical devices may be used. 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.

[0055] Network connection 52 can be a wired or wireless connection, such as via Ethernet, WiFi, BLUETOOTH, Integrated Services Digital Network (ISDN) connection, Digital Subscriber Line (DSL) modem, or cable modem. Any direct or indirect network connection can be used, including but not limited to telephone modems, MIB systems, RS232 interfaces, auxiliary interfaces, optical links, infrared links, radio frequency links, microwave links, or WLAN connections or other wireless connections.

[0056] Functional modules 16, 18, 20, and 22 are any devices used to provide care to patients or monitor their condition. For example... Figure 1AAs shown, at least one of functional modules 16, 18, 20, and 22 can be an infusion pump module, such as an intravenous infusion pump for delivering medications or other fluids to a patient. For the purposes of discussion, functional module 16 is an infusion pump module. Each of functional modules 18, 20, and 22 can be any patient treatment or monitoring device, including but not limited to infusion pumps, syringe pumps, PCA pumps, epidural pumps, enteral pumps, blood pressure monitors, pulse oximeters, EKG monitors, EEG monitors, heart rate monitors, or intracranial pressure monitors. Functional modules 18, 20, and / or 22 can be printers, scanners, barcode readers, or any other peripheral input, output, or input / output device.

[0057] Each functional module 16, 18, 20, 22 communicates directly or indirectly with interface unit 14, whereby interface unit 14 provides overall monitoring and control of device 12. Functional modules 16, 18, 20, 22 can be physically and electronically connected to one or both ends of interface unit 14 in a serial manner, such as... Figure 1A As shown, or as detailed by Eggers et al. However, it will be appreciated that other means for connecting functional modules to the interface unit can be utilized without departing from the art of the subject matter. It will also be understood that devices such as pumps or patient monitoring devices, which provide sufficient programmability and connectivity, can be operated as stand-alone devices and can communicate directly with the network without connection via a separate interface unit (or control unit) 14. As described above, attached medical devices or peripheral devices can be connected to the patient care device 12 via one or more auxiliary interfaces 62.

[0058] Each functional module 16, 18, 20, 22 may include a module-specific component 76, a microprocessor 70, volatile memory 72, and non-volatile memory 74 for storing information. It should be noted that, although Figure 1A Four functional modules are shown, but any number of devices can be directly or indirectly connected to the interface unit (or control module) 14. The number and type of functional modules described herein are for illustrative purposes and in no way limit the scope of the subject matter. Module-specific components 76 include any components required for operating a particular module, such as display devices and / or pumping mechanisms for the infusion pump module 16.

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

[0060] The patient care device 12 can operate in several different modes or personalities, each defined by a configuration database. The configuration database can be an internal database 56 or an external database 37. A particular configuration database is selected based at least in part on patient-specific information such as patient location, age, physical characteristics, or medical characteristics. Medical characteristics include, but are not limited to, patient diagnosis, treatment prescriptions, medical history, medical records, patient care provider identification, physical characteristics, or psychological characteristics. As used herein, patient-specific information also includes care provider information (e.g., physician identity) or the location of the patient care device 10 within the hospital or hospital computer network. Patient care information can be input via interface devices 52, 54, 60, or 62 and can come from anywhere within network 10, such as, for example, from a pharmacy server, admission server, and laboratory server.

[0061] Medical devices incorporating various aspects of the subject matter technology can be equipped with a Network Interface Module (NIM), allowing the medical device to participate as a node in a network. Although for clarity, the subject matter technology will be described as operating in an Ethernet environment using the Internet Protocol (IP), it is understood that the concepts of the subject matter technology are equally applicable to other network environments, and these environments are intended to be within the scope of the subject matter technology.

[0062] Existing technologies can be used to convert data destined for and from various data sources into network-compatible data, and information movement between medical devices and networks can be achieved through various means. For example, patient care device 12 and network 10 can communicate via automatic interaction, manual interaction, or a combination of automatic and manual interaction. Automatic interaction can be continuous or intermittent and can be achieved through direct network connection 54 (e.g., ...). Figure 1A (As shown) or via RS232 links, MIB systems, RF links (such as BLUETOOTH), IR links, WLAN, digital cable systems, telephone modems, or other wired or wireless communication means. Manual interaction between patient care device 12 and network 10 involves the intermittent or periodic physical transfer of data between systems using, for example, a user interface device 54, an coded data input device 60, barcodes, computer disks, portable data assistants, memory cards, or any other medium used for storing data. In all aspects, the communication devices are bidirectional and can access data from as many distributed data source points as possible. Decision-making processes can occur in various locations within network 10. For example, but not limited to, decisions can be made in server 30, decision support, remote data servers, hospital departments or unit stations 32, or within the patient care device 12 itself.

[0063] According to the present invention, all direct communication with medical devices operating on the network can be performed through an information system server 30, referred to as a Remote Data Server (RDS). According to various aspects of the present invention, the network interface module integrated with the medical device (such as an infusion pump or vital sign measuring device) ignores all network traffic not originating from the certified RDS. The primary responsibility of the RDS in this invention is to track the location and status of all networked medical devices with NIM and to maintain open communication.

[0064] Figure 1B An example PCU 12 according to aspects of the subject matter is shown, comprising a control module 14 and connected drug delivery modules 16, 18, 20, 22. In some embodiments, drug delivery modules 16, 18, 20, 22 include insertion ports for expansion. Thus, new drug delivery modules can be attached to the PCU 12 via insertion port coupling connectors, the insertion ports including electrical terminals, such that the added drug delivery modules 16, 18, 20, 22 can transmit and receive information from the control module 14. In some embodiments, the added drug delivery modules 16, 18, 20, 22 can also receive power from the control module 14 via the insertion ports. The control module 14 may include a main display 201, memory, and a processor (see...). Figure 4 The module display can be configured to display operating parameters and drug delivery status, as well as other information associated with each of the drug delivery modules 16, 18, 20, and 22. According to various embodiments, the module display can also display physiological data associated with the patient (e.g., vital signs).

[0065] The main display 201 is configured to display one or more user interfaces for displaying operating parameters or other data associated with modules 16, 18, 20, and 22, and / or physiological parameters associated with the patient. The main display 201 may include multiple user interfaces, each graphically displaying information for a corresponding drug module, including information also displayed on the corresponding module's display. In some embodiments, the control module 14 includes a communication module (including, for example, an antenna) configured to wirelessly communicate with a controller or network.

[0066] Reference Figure 1A and Figure 1BWhen drug delivery modules 16, 18, 20, and 22 initiate drug infusion to a patient, control module 14 is configured to create and manage an infusion session within the memory of the control module (or related modules). For the purposes of this disclosure, the infusion session includes status information of the PCU 12, its control module 14, and / or its related modules, which is recorded and stored in memory during a specific time period. The status information includes, but is not limited to, records of parameter values ​​used by the PCU, its control module, and / or its related modules during that time period, and / or records of physiological data collected during that time period. During infusion, patient-associated physiological data is recorded in the session, as are operating parameter values ​​and any modifications to the operating parameters of the PCU, its control module, and / or modules.

[0067] If not already logged into PCU 12, a clinician can scan his or her badge near sensors (e.g., 54, 60) on PCU 12, and the PCU can attempt to authenticate the clinician by sending the scanned identifier to server 30. The clinician's badge may contain a radio frequency identification (RFID) device, which is read by a scanner integrated with the PCU or a portable scanner associated with the PCU. The clinician can scan his or her badge at control module 14 to identify and authorize the clinician to begin medication administration. Once the clinician is associated with the PCU and / or module, the clinician's identifier is associated with the session. The same applies to patients. The clinician can scan the patient's wristband with a portable scanner or use sensors on PCU 12 (or its control module) to associate the patient with the PCU and / or module (and the session).

[0068] The control unit 14 of the PCU 12 is configured to generate a graphical representation of the infusion session and display (e.g., on display 201) that graphical representation, including graphical visualization of all parameters infused during the session and any modifications to the parameters, as well as physiological data acquired during the session. The graphical representation may include pseudo-identifiers for unknown data until these data are replaced by known identifiers. At this point, the graphical representation is displayed along with the known patient identifier.

[0069] Figure 2 This is a conceptual diagram illustrating an example infusion control system according to an aspect of the subject matter technology. The system is configured to dynamically connect to and receive data from different sensors to control different infusion therapies and to integrate with a cloud-based data integration analysis and control system.

[0070] The 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, thereby helping clinicians develop infusion protocols for personalized patient care. 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 relevant treatment information to the MLM and database 204. Figure 2 As shown, the communication interface device 206 can also receive patient-related information 208 from one or more external devices, including, for example, multi-parameter monitor data, patient demographic data, biophysical sensor data connected to the patient, and laboratory test results. The communication interface device can be connected to the data coordination module 210 (software or hardware) for coordinating the reception and transmission of data.

[0071] The DCM can be simultaneously connected to one or more medical devices 12 via pump device interface 212, including, for example, infusion pumps 12 such as actuator pumps, syringe pumps, high-volume infusion pumps, or modular infusion pumps. The DCM can be combined with algorithm 224, which remotely controls the IV infusion of drugs or fluids via the infusion pump. As will be further described, the DCM can be configured to dynamically determine and / or load one or more algorithms to control the infusion in different ways. For example, the algorithm can control PharmaKinetic (PK) infusions, Titration Controlled Infusion (TCI) infusions, Proportional-Integral-Derivative (PID) infusions, or other proprietary controlled infusions.

[0072] The disclosed DCM integrates with and / or communicates with a machine learning database 214, which provides PK patient models based on demographic, disease models, and clinical test and / or test data. In addition to PK drug models 218 and clinician protocol preferences and clinical decision choices 220 (from a clinician database), the machine learning and data integrator receives 216 these models as input to provide model-based precise quantification 222, which is then used by the DCM to control and / or manage infusions. The DCM 202 also includes a control optimizer 226 for receiving input from the user / clinician to further optimize and / or control the treatment provided by the entire system, including connected devices. In this regard, the control optimizer 226 is configured to receive operational parameters, including clinician and / or patient identification, and the selection of the patient's condition to be treated (and controlled by the DCM), and to provide further adjustments to treatment-related parameters, including adjustments to monitored drug dosages. The control optimizer 224 can receive such input from connected input devices, such as a keyboard, a touchscreen interface (e.g., on the DCM's display) or via another connected device. Therefore, the entire system collectively defines the infusion protocol in conjunction with the protocol engine, which allows for personalized treatment of patients. The EMR and / or cloud-based system 204 can be implemented, for example, by one or more information system servers 30 and / or databases 37 as described in Figure 1.

[0073] IV infusion device 12 or other delivery devices can be directly controlled by DCM 202 using serial, wired, or wireless network connections (Ethernet or Wi-Fi), or other wireless connections (such as BLE). Where a dedicated connection may be required, a pre-defined I / O module corresponding to the device type can be connected. Therefore, external devices that can be connected to the DCM may include, for example, badge RFID readers (e.g., for tasks such as NFC tapping to associate patients, sensors, pumps, or clinician logins), biometric devices (e.g., fingerprint or retinal scanners), or backup batteries for use in power outages or when in motion.

[0074] The DCM may also include a display 228 configured to provide a user interface for displaying information related to the patient's physiological state and system control status. In some embodiments, the display module circuitry within the DCM housing can provide display information to an external display device. The ability 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 graphics), a larger, higher-resolution display can be used. If the use case requires a display with minimal information and UI to support configuration, a smaller, space-saving, and lower-cost locally connected display can be used.

[0075] The DCM can be connected to a local display via cable or directly attached to form a combined module pair. The DCM can also be configured to have minimal or no local display (e.g., "headless") functionality and be configured to wirelessly connect to a mobile device such as a smartphone or tablet (e.g., via BLUETOOTH) and display information via a mobile application operating on the remote device. The displayed information can also be provided to an external clinician display or portal for display along with other portal-specific information. In some embodiments, the DCM may include an integrated display device. In some embodiments, the DCM may share a display with one or more medical devices. For example, an infusion pump and the DCM may share a single external display for presenting information and / or controlling infusion parameters.

[0076] The DCM may also include network hardware for wireless connectivity to wireless hubs or other network devices on networks 10 and 40, thereby providing network communication (e.g., via networks 10 and 40) with server 30, PCU 12, or other supporting network devices operatively connected to a cloud-based system. For example, patient information may be downloaded by the DCM from an external system, infusion limits associated with the DCM may be set based on the patient information, and the infusion flow rate provided by the connected infusion device may be controlled by the DCM based on the limits and / or patient information. In some embodiments, the DCM 202 may be remotely connected to the PCU 12 or infusion pump via server 30 and / or networks 10 and 40. For example, the DCM may be implemented as a mobile device or remote device 32.

[0077] The DCM and / or other systems disclosed herein can also integrate biosensing via input from one or more biophysical sensors coupled to the patient to the communication interface device 204 to monitor the patient's response to treatment and adjust as needed. The biosensing can originate from biophysical sensors and / or laboratory tests. The system can use mathematical models simulating disease development, combined with pharmacokinetic (PK) models of drugs, to determine dosing patterns for individuals being treated for one of several different disease states.

[0078] Figure 3 This paper describes a first example process and workflow 300 for intelligent personalized control of an infusion device using a model-based scheme engine, based on aspects of the technology described in this subject matter. The depicted workflow can be achieved, for example, through input and processing at the DCM, combined with the previously described cloud system and / or database, and... Figure 2 Other processes described herein are used to implement this. In this regard, the disclosed protocol definition tool allows clinicians to select treatment criteria from a registry containing various types of patient demographics, conditions, and required treatments.

[0079] When the DCM 202 is connected to the infusion pump 12, the user can initiate 302 treatment under the disclosed model-based infusion control (MBIC) or standard protocols of a healthcare organization. For example, the user can place the DCM in bypass mode to use a standard protocol for programmed infusion. Such a protocol may include automated programming requests initiated using a standard drug library and / or via EMR. Alternatively, the DCM 202 can activate the disclosed MBIC to provide data-driven guidance for drug administration based on patient model and PK model algorithms. In this regard, the MBIC provides guidance to clinicians on when and how to modify the dose adaptively in real time, or to provide closed-loop control of the connected infusion pump 12 for automated drug administration.

[0080] When the MBIC is activated, the DCM 202 (e.g., via an input device) is capable of receiving various types of input 304. Inputs include, for example, patient parameters (e.g., demographic information, patient identity, etc.), the condition / disease to be treated, medications used in treatment (e.g., controlled by the MBIC), clinician identifiers, and / or biosensor and biomarker information. On the 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 related to... Figure 2 This describes a cloud-based machine learning model (MLM) and related database 204. According to various implementations, the MLM is trained to simulate the development of various diseases / conditions in a patient population under the care of a physician group in a healthcare organization, and to determine how the development of each condition is influenced by corresponding drug decisions made by one or more physicians regarding (i) the dosage of one or more drugs and (ii) the corresponding pharmacokinetic models of one or more drugs.

[0081] Based on input 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 input 304, the MLM may determine the dosage of medication administered to the patient by infusion device 12 to maintain one or more predetermined biomarkers within predetermined effective ranges for the treatment of the condition / disease to be treated. The DCM may also include an infusion protocol generator 310 coordinated with the MLM, which determines a set of rules for the ongoing medication administration. For example, generator 310 may determine limits and / or ranges that patient biomarkers should be maintained for appropriate outcomes of the relevant treatment. Generator 310 may also formulate rules whereby the infusion protocol can be adjusted when certain conditions are met (e.g., biomarkers meet predetermined thresholds, after a predetermined time period, etc.). For example, the sampling rate or frequency of sensing biomarkers may be increased (e.g., biosensor optimization), and / or the dosage of medication administered to the patient may be titrated or reduced (e.g., protocol smart modifier). The conditions to be met can be provided by, for example, a lookup table within database 220, and indexed based on one or more inputs 304.

[0082] The execution 312 of the determined protocol includes, for example, programming the infusion pump 12 to administer IV infusions of medication according to rules implemented by the protocol generator 310, biosensor monitoring, and continuous control 314 of the IV infusion. During execution 312, the DCM may store infusion-related data, including dosage parameters related to medication and condition treatment (e.g., dosage determined by the MLM). When certain conditions defined by the protocol generator 310 are met, the DCM may automatically terminate treatment, or the user may manually terminate treatment (e.g., via input 304). Upon receiving an indication that treatment for the condition has been terminated, the DCM may perform and / or generate a post-treatment analysis 316, including, for example, determining treatment outcomes related to the condition, and updating the training of the MLM based on the stored data and treatment outcomes. The DCM may also include a report generator 318, which can generate reports based on the post-treatment analysis for transmission to and storage at the server 30 / database 37 as part of the patient's EMR. Additionally or as an alternative, the report can be enhanced with EMR data from the server / database and displayed on the monitor of the DCM or other relevant equipment.

[0083] Figure 4A second example process 350 for intelligent personalized control of an infusion device using a model-based scheme engine, according to aspects of the subject matter, is depicted. For illustrative purposes, various blocks of the example process 350 are described herein with reference to Figures 1-3 and the relevant components and / or processes described herein. According to various embodiments, process 350 is a simplified variant of process 300. One or more blocks of process 350 may be implemented, for example, by a DCM 202, which includes one or more associated computing devices, such as server 30 and infusion pump 12. In some embodiments, as described herein, one or more blocks may be implemented based on one or more machine learning algorithms. In some embodiments, one or more blocks may be implemented separately from other blocks and by one or more different processors or devices. Furthermore, for illustrative purposes, while the blocks of example process 350 are described as occurring serially or linearly, in some embodiments, multiple blocks of example process 350 may occur in parallel. Furthermore, the blocks of example process 350 do not need to be executed in the order shown and / or one or more blocks of example process 350 need not be executed.

[0084] According to various implementations, one or more machine learning models are trained (352) to simulate the development of multiple conditions in a patient population under the care of multiple physicians in a healthcare organization. According to various implementations, these MLMs are also trained (352) to determine how corresponding drug decisions made by one or more physicians among the multiple physicians regarding (i) the dosage of one or more drugs and (ii) the corresponding pharmacokinetic models of one or more drugs affect the development of each of the multiple conditions. (See also: ...) Figure 2 The MLM discussed here can utilize data from the ML database 214, the PK drug model 218, and the database 220 that stores clinicians' protocol preferences and clinical decision choices. (Reference) Figure 3 In some implementations, the MLM uses (306) which of these databases can be based on input 304 received from the user operating the DCM.

[0085] In the depicted example, input 304 received by the DCM (e.g., from a user and / or an external system) includes a patient identifier and a selection of the condition the patient is to be treated (354). Based on the patient identifier, the DCM can obtain patient information, including patient characteristics (356). Characteristics may be associated with patient identifiers in a database or may be manually entered or selected by the user on the DCM's user interface. These characteristics may include demographic features such as sex, age, weight, height, race, ethnicity, genetic background, etc., or background history such as physical activity history, smoking history, drinking history, working conditions, and past medical conditions, etc. In some implementations, a clinician identifier may be received. If received, the MLM can receive or obtain access to data related to the identified clinician from database 220, including, for example, a history of medication decisions (e.g., prescription decisions) based on the patient's condition. In this respect, the identified clinician may be one of the doctors training the machine learning model, and therefore the clinician's history may be considered in the determination of the model.

[0086] The system monitors one or more biomarkers associated with the patient in real time (358). Monitoring can be performed by receiving signals and / or measurement data from biophysical sensors connected to the patient. For example, the system can monitor heart rate, blood pressure, oxygenation, FiO2, and ECG / EEG data, etc. In some implementations, monitoring includes receiving measurement data associated with patient-related laboratory tests. For example, the system can obtain the blood concentration of a drug (e.g., provided during treatment) from laboratory results published to the patient's EMR.

[0087] The system, based on monitoring and input of patient characteristics and the condition to be treated, uses one or more machine learning models to determine the dosage of medication to be administered to the patient in real time, in order to maintain at least one biomarker within a predetermined effective range (360°) for the treatment of the condition. As previously mentioned, the model can access multiple databases across the healthcare organization, including patient population data over time, pharmacokinetic drug models, clinician historical data, disease models, clinical trial data (which may be anonymized), and demographic models, etc. Therefore, the machine learning model uses one or more of these models to determine how the drug affects the patient's condition and to determine the optimal dosage of the drug to be administered (or an adjustment to the current dosage) to achieve the best therapeutic effect from the patient.

[0088] The system then drives (362) the infusion pump 12 to administer a predetermined dose of the drug to the patient. In this respect, the system can adjust the current dose of the drug delivered by the infusion pump (e.g., increase or decrease the flow rate of the drug, or the volume to be infused (VTBI)). According to various embodiments, the monitoring step (358), the determination step (360), and the driving step (362) are continuously repeated during the treatment of the condition.

[0089] In some implementations, the system may prompt (e.g., on the DCM's display 228 or via the DCM's display module) the user to confirm the determined dose before the DCM instructs the infusion pump 12. In some implementations, the system may adjust the prompts based on the clinician's action history. For example, the system may prompt the clinician to confirm the dose each time the infusion pump is driven to deliver (or adjust) the determined dose, but begin skipping prompts after a threshold number of times the clinician cancels the prompts without providing confirmation. In some implementations, the system may determine the current state of the condition the patient is treating and adjust the drug dosage accordingly based on one or more historical adjustments made by the clinician in light of the current state of the condition. For example, a clinician may have a history of reducing the medication by 10% when a biomarker (e.g., blood pressure) reaches a predetermined threshold when treating an arrhythmia. Therefore, when the threshold is reached, the system may automatically prompt for a reduction of the same amount.

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

[0091] Example processes 300 and 350, along with their associated features and applications, can also be implemented as software processes. These software processes are specified as a set of instructions recorded on a computer-readable storage medium (also known as a computer-readable medium) and can be executed automatically (e.g., without user intervention). When these instructions are executed by one or more processing units (e.g., one or more processors, processor cores, or other processing units), they cause the processing units 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 disk drives, EPROMs, etc. Computer-readable media do not include carrier waves and electronic signals transmitted via wireless or wired connections.

[0092] The term "software" means, where appropriate, firmware residing in read-only memory or an application stored in magnetic storage, which can be read into memory for processing by a processor. Furthermore, in some embodiments, the multiple software aspects disclosed herein may be implemented as sub-parts of a larger program while maintaining the distinct software aspects disclosed herein. In some embodiments, the multiple software aspects may also be implemented as separate programs. Finally, any combination of separate programs that collectively implement the software aspects described herein is within the scope of this disclosure. In some embodiments, when a software program is installed to operate on one or more electronic systems, the software program defines one or more specific machine implementations of the operations performed and executed by the software program.

[0093] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, objects, or other units suitable for a computing environment. A computer program may, but does not need to, correspond to a file in a file system. A program may be stored as 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 harmonizing files (e.g., a file storing one or more modules, subroutines, or code sections). A computer program can be deployed to execute on one or more computers located at a single site or distributed across multiple sites and interconnected via a communication network.

[0094] Figure 5 This is a conceptual diagram illustrating an example electronic system 400 for intelligent personalized control of an infusion device using a model-based scheme engine, according to aspects of the subject matter. Electronic system 400 may be a computing device for performing software associated with one or more parts or steps of process 350 or with the components and processes provided by Figures 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, corresponding modules 16, 18, 20, 22, or remote device 32 (e.g., mobile device). In conjunction with the disclosure regarding Figures 1-3, electronic system 400 may be representative. In this respect, electronic system 400 may be a personal computer or mobile device, such as a smartphone, tablet, laptop, PDA, augmented reality device, wearable device (such as a watch or watchband or glasses) or a combination thereof, or other touchscreen or television in which one or more processors are embedded or coupled, or any other computer-related electronic device with network connectivity.

[0095] 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, a processing unit 412, system memory 404, read-only memory (ROM) 410, permanent storage device 402, input device interface 414, output device interface 406, and one or more network interfaces 416. In some embodiments, electronic system 400 may include or be integrated with other computing devices or circuits for the operation of the various components and processes described above.

[0096] Bus 408 collectively represents all system, peripheral, and chipset buses that communicate with the numerous internal devices of electronic system 400. For example, bus 408 communicates with processing unit 412, ROM 410, system memory 404, and permanent storage device 402.

[0097] From these different storage units, processing unit 412 retrieves instructions to be executed and data to be processed in order to perform the processes disclosed in this subject matter. In different embodiments, the processing unit may be a single processor or a multi-core processor.

[0098] ROM 410 stores static data and instructions required by the processing unit 412 and other modules of the electronic system. On the other hand, permanent storage device 402 is a read-write memory device. This device is a non-volatile memory cell that stores instructions and data even when the electronic system 400 is off. Some embodiments disclosed in this subject matter use mass storage devices (such as disks or optical discs and their corresponding disk drives) as permanent storage device 402.

[0099] Other embodiments use removable storage devices (such as floppy disks, flash drives, and their corresponding disk drives) as permanent storage device 402. Like permanent storage device 402, system memory 404 is a read-write memory device. However, unlike storage device 402, system memory 404 is volatile read-write memory, such as random access memory. System memory 404 stores some instructions and data required by the processor during operation. In some embodiments, the processes disclosed in this subject matter are stored in system memory 404, permanent storage device 402, and / or ROM 410. From these different memory units, processing unit 412 retrieves instructions to be executed and data to be processed in order to perform the processes of some embodiments.

[0100] Bus 408 is also connected to input and output device interfaces 414 and 406. Input device interface 414 enables a user to communicate information to the electronic system and select commands. Input devices used with input device interface 414 include, for example, alphanumeric keypads and pointing devices (also known as "cursor control devices"). Output device interface 406 is capable of, for example, displaying images generated by electronic system 400. Output devices used with output device interface 406 include, for example, printers and display devices such as cathode ray tube (CRT) or liquid crystal display (LCD). Some implementations include devices such as touchscreens, which function as both input and output devices.

[0101] In addition, such as Figure 5 As shown, bus 408 also couples electronic system 400 to a network (not shown) via network interface 416. Network interface 416 may include, for example, a wireless access point (e.g., Bluetooth or WiFi) or radio circuitry for connecting to a wireless access point. Network interface 416 may also include hardware (e.g., Ethernet hardware) for connecting a computer to a part of a computer network such as a local area network (“LAN”), wide area network (“WAN”), wireless LAN or intranet, or a network of networks such as the Internet. Any or all components of electronic system 400 may be used in conjunction with the disclosure of this subject matter.

[0102] These functions can be implemented in computer software, firmware, or hardware. These technologies can be implemented using one or more computer program products. Programmable processors and computers can be included in or packaged as mobile devices. Processes and logical flows can be executed by one or more programmable processors and one or more programmable logic circuits. General-purpose and special-purpose computing devices and storage devices can be interconnected through communication networks.

[0103] Some implementations include electronic components, such as microprocessors, storage devices, and memories, that store computer program instructions in a machine-readable or computer-readable medium (also referred to as a computer-readable storage medium, machine-readable medium, or machine-readable storage medium). Examples of such computer-readable media include RAM, ROM, read-only optical discs (CD-ROM), recordable optical discs (CD-R), rewritable optical discs (CD-RW), read-only digital versatile optical discs (e.g., DVD-ROM, dual-layer DVD-ROM), various 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 disk drives, read-only and recordable Blu-ray® optical discs, ultra-high-density optical discs, any other optical or magnetic media, and floppy disks. Computer-readable media may store computer programs executable by at least one processing unit and include a set of instructions for performing various operations. Examples of computer programs or computer code include machine code, such as machine code generated by a compiler, and files that include high-level code executed by a computer, electronic component, or microprocessor using an interpreter.

[0104] While the above discussion primarily concerns microprocessors 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 stored on the circuit itself.

[0105] As used in this specification and any claim of this application, the terms "computer," "server," "processor," and "memory" refer to electronic or other technical devices. These terms do not include individuals or groups. For the purposes of this specification, the terms "display" or "displaying" mean displaying on an electronic device. As used in this specification and any claim of this application, the terms "computer-readable medium" and "computer-readable medium" are strictly limited to tangible physical objects that store information in a computer-readable form. These terms do not include any wireless signals, wired download signals, or any other transient signals.

[0106] To provide interaction with the user, embodiments of the subject matter described in this specification can be implemented on a computer having a display device for displaying information to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and pointing device, such as a mouse or trackball, through which the user can provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Furthermore, the computer can interact with the user by sending and receiving documents to and from a device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.

[0107] The subject matter described in this specification can be implemented in a computing system that includes backend components, such as a data server, or middleware components, such as an application server, or frontend components, such as a client computer with a graphical user interface or web browser through which a user can interact with embodiments of the subject matter described in this specification, or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), interconnected networks (e.g., the Internet) and peer-to-peer networks (e.g., self-organizing peer-to-peer networks).

[0108] A computing system may include clients and servers. Clients and servers are typically geographically separated but can interact via a communication network. The relationship between clients and servers is established by computer programs running on their respective computers, and they have a client-server relationship. In some embodiments, the server transmits data (e.g., HTML pages) to the client device (e.g., to display data to a user interacting with the client device and to receive user input from it). Data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0109] Those skilled in the art will understand that the various illustrative blocks, modules, elements, components, methods, and algorithms described herein can be implemented as electronic hardware, computer software, or a combination of both. To illustrate this interchangeability between hardware and software, the various illustrative blocks, modules, elements, components, methods, and algorithms have been generally described above according to their functionality. Whether this functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The described functionality can be implemented in different ways for each specific application. Various components and blocks can be arranged differently (e.g., in different orders or divided in different ways) without departing from the scope of the subject matter.

[0110] It should be understood that the specific order or hierarchy of the steps in the disclosed process is illustrative of the method. Based on design preferences, it is understood that the specific order or hierarchy of the steps in the process can be rearranged. Some of the steps may be performed simultaneously. The appended method claims present the elements of the steps in an illustrative order, but this does not imply limitation to the specific order or hierarchy presented.

[0111] Subject matter technology as an explanation of the terms:

[0112] For convenience, various examples of aspects of this disclosure are described as numbered clauses (1, 2, 3, etc.). These are provided by way of example only and do not limit the technical subject matter. The identification of the figures and reference numerals provided below is by way of example and for illustrative purposes only, and the clauses are not limited by these identifications.

[0113] Clause 1. A method for implementing intelligent personalized control of an infusion device, comprising: training one or more machine learning models to simulate the development of multiple conditions in a patient population under the care of multiple physicians in a healthcare organization, and determining how the development of each of the multiple conditions is affected by corresponding drug decisions made by one or more physicians regarding (i) the dosage of one or more drugs and (ii) corresponding pharmacokinetic models of one or more drugs; receiving a patient identifier and a selection of a condition to be treated for the patient; identifying patient characteristics; monitoring one or more biomarkers associated with the patient in real time; determining, based on the monitoring and input of patient characteristics and the condition to be treated, a drug dosage to be administered to the patient in real time by the one or more machine learning models to maintain at least one biomarker within a predetermined effective range for treating the condition; and driving an infusion pump to administer the determined dose of drug to the patient.

[0114] Clause 2. The method of Clause 1 also includes: continuously and repeatedly monitoring, identifying and driving steps during the treatment of the condition.

[0115] Clause 3. The method of Clause 1 or Clause 2 further includes: receiving an identifier of a clinician, wherein the determination by one or more machine learning models is also based on the input of the identifier of the clinician, the clinician being one of a plurality of physicians in a healthcare organization represented by one or more machine learning models.

[0116] Clause 4. The method of Clause 3 further includes: determining the current state of the patient’s condition to be treated; and adjusting the dosage of the drug based on one or more historical adjustments made by the clinician in view of the current state of the condition.

[0117] Clause 5. The method of Clause 3 further includes: repeating the monitoring, determination, and driving steps; and each time a dose is determined: prompting the clinician to confirm the dose before driving the infusion pump to deliver the determined dose; and skipping the prompt after a threshold number of times the clinician cancels the prompt without providing confirmation.

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

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

[0120] Clause 8. The method of Clause 7, wherein the measurement data includes drug concentration levels, the method further comprising: determining a predetermined effective range based on drug concentration levels; or adjusting the sampling rate of monitoring based on drug concentration levels.

[0121] Clause 9. The method of any one of Clauses 1-8, wherein the patient's characteristics include one or more patient demographic characteristics selected from a group of demographic characteristics including age, sex, race, and ethnicity.

[0122] Clause 10. The method of any one of Clauses 1-9 further includes: receiving a request for notification that at least one biomarker has reached a threshold level; and in response to the request for notification: calculating a trend and time point at which at least one biomarker will reach the threshold level; and providing notification of the trend and time point.

[0123] Clause 11. The method of any one of Clauses 1-10 further includes, before driving the infusion pump to administer a predetermined dose of the drug: prompting the user to confirm the predetermined dose; and receiving confirmation of the predetermined dose.

[0124] Clause 12. The method of Clause 11 further includes: displaying an indication of the determined dose and a modeled response to the patient’s condition based on the determined dose on a user interface.

[0125] Clause 13. The method of any one of Clauses 1-12 further includes: storing dosage parameters associated with the drug and the treatment of the condition during treatment of the condition; receiving an indication that treatment of the condition has been terminated; determining treatment outcomes associated with the condition; and updating the training of one or more machine learning models based on the stored dosage parameters and treatment outcomes.

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

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

[0128] Further consideration:

[0129] It should be understood that the specific order or hierarchy of the steps in the disclosed process is illustrative of the method. Based on design preferences, it is understood that the specific order or hierarchy of the steps in the process can be rearranged. Some of the steps may be performed simultaneously. The appended method claims present the elements of the steps in an illustrative order, but this does not imply limitation to the specific order or hierarchy presented.

[0130] The foregoing description is provided to enable those skilled in the art to practice the various aspects described herein. The foregoing description provides various examples of the subject matter, and the subject matter is not limited to these examples. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but should be given the full scope consistent with the language of the claims, wherein, unless specifically stated otherwise, singular elements are not intended to mean “one and only one,” but rather “one or more.” Unless otherwise stated, the term “some” means one or more. Masculine pronouns (e.g., his) include feminine and neuter pronouns (e.g., her and its), and vice versa. Titles and subtitles (if any) are used for convenience only and do not limit the invention described herein.

[0131] The predicates “configured as,” “operable as,” and “programmed as” do not imply any specific tangible or intangible modification to the subject matter, but are intended to be used interchangeably. For example, a processor or component configured to monitor and control operations can also mean a processor programmed to monitor and control operations, or a processor operable to monitor and control operations. Similarly, a processor configured to execute code can be interpreted as a processor programmed to execute code or operable to execute code.

[0132] As used herein, the term "automatic" can include execution by a computer or machine without user intervention; for example, by instructions in response to prior actions or other initiation mechanisms of a computer or machine. The word "example" is used herein to mean "serving as an example or illustration." Any aspect or design described herein as an "example" is not necessarily to be construed as preferred or superior to other aspects or designs.

[0133] Phrases such as "aspect" do not imply that the aspect is essential to the present subject matter or that the aspect is applicable to all configurations of the present subject matter. Disclosures relating to an aspect may apply to all configurations, or one or more configurations. An aspect may provide one or more examples. Phrases such as "aspect" may refer to one or more aspects, or vice versa. Phrases such as "embodiment" do not imply that such an embodiment is essential to the present subject matter or that such an embodiment is applicable to all configurations of the present subject matter. Disclosures relating to an embodiment may apply to all embodiments, or one or more embodiments. An embodiment may provide one or more examples. Phrases such as "embodiment" may refer to one or more embodiments, or vice versa. Phrases such as "configuration" do not imply that such a configuration is essential to the present subject matter or that such a configuration is applicable to all configurations of the present subject matter. Disclosures relating to a configuration may apply to all configurations, or one or more configurations. A configuration may provide one or more examples. Phrases such as "configuration" may refer to one or more configurations, or vice versa.

[0134] As used herein, a “user interface” (also referred to as an interactive user interface, graphical user interface, or UI) can mean a web-based interface including data fields and / or other control elements for receiving input signals or providing electronic information and / or for providing information to a user in response to any received input signals. Control elements may include dial pads, buttons, icons, selectable areas, or other perceptible markings presented via the UI that, when interacted with (e.g., click, touch, select, etc.), initiate data exchange between the device used to present the UI. The UI may be implemented wholly or partially using technologies such as Hypertext Markup Language (HTML), Flash™, Java™, .NET™, C, C++, web services, or Rich Site Summary (RSS). In some embodiments, the UI may be included in a separate client (e.g., a thick client, a fat client) configured to communicate (e.g., send or receive data) according to one or more of the described aspects. This communication may be to or from a medical device or server with which it communicates.

[0135] As used herein, the term "determine" or "determining" encompasses a wide variety of actions. For example, "determining" can include performing operations, calculations, processing, derivation, generation, acquisition, searching (e.g., searching in a table, database, or other data structure), and ascertaining information via hardware components without user intervention. Furthermore, "determining" can include receiving (e.g., receiving information) and accessing (e.g., accessing data in memory) via hardware components without user intervention. "Determining" can also include parsing, selecting, picking, and building via hardware components without user intervention.

[0136] As used herein, the terms “provide” or “providing” encompass a wide variety of actions. For example, “providing” can include storing a value in a location on a storage device for later retrieval, transmitting a value directly to a recipient via at least one wired or wireless communication medium, and transmitting or storing a reference to a value. “Providing” can also include encoding, decoding, encrypting, decrypting, acknowledging, and verifying via hardware components.

[0137] As used herein, the term "message" encompasses various formats used to convey (e.g., send or receive) information. A message can include machine-readable aggregates of information, such as XML documents, fixed-field messages, comma-separated messages, JSON, or custom protocols. In some implementations, a message can include signals for transmitting one or more representations of information. Although recorded in the singular, it will be understood that a message can be composed, transmitted, stored, received, etc., in multiple parts.

[0138] As used herein, the term "selectively" or "selective" can encompass a wide variety of actions. For example, a "selective" process may include determining an option from a plurality of options. A "selective" process may include one or more of the following: dynamically determined input, pre-configured input, or user-initiated input for making a determination. In some implementations, n input switches may be included to provide selectivity, where n is the number of inputs used for making a selection.

[0139] As used herein, the term "corresponding" or "corresponding" encompasses a structural, functional, quantitative, and / or qualitative correlation or relationship between two or more objects, datasets, information, and / or the like, preferably wherein the correspondence or relationship can be used to transform one or more of the two or more objects, datasets, information, and / or the like to appear identical or equal. Correspondence can be evaluated using one or more of the following: thresholds, value ranges, fuzzy logic, pattern matching, machine learning evaluation models, or combinations thereof.

[0140] In any embodiment, the generated or detected data may be forwarded to a “remote” device or location, where “remote” means a location or device other than the location or device executing the program. For example, a remote location could be another location in the same city (e.g., an office, laboratory, etc.), another location in a different city, another location in a different state, another location in a different country, etc. Therefore, when an item is indicated as being “remote” to another item, this means that the two items may be in the same room but separate, or at least in different rooms or different buildings, and may be at least one mile, ten miles, or at least one hundred miles apart. “Transmitting” information means transmitting data representing that information as an electrical signal through a suitable communication channel (e.g., a private or public network). “Forwarding” an item means any means of moving the item from one location to another, whether by physically transporting the item or otherwise (where possible), and at least in the case of data, includes physically transporting the medium carrying the data or conveying the data. Examples of communication media include radio or infrared transmission channels and network connections to another computer or networked device, as well as the Internet, or include email transmissions and information recorded on websites, etc.

Claims

1. A method for implementing intelligent personalized control of an infusion device, comprising: Train one or more machine learning models to simulate the development of multiple conditions in a patient population under the care of multiple physicians in a healthcare organization, and determine how the development of each of the multiple conditions is affected by corresponding drug decisions made by one or more of the multiple physicians regarding (i) the dosage of one or more drugs and (ii) the corresponding pharmacokinetic models of the one or more drugs; Receive the patient's identification and the selection of the patient's condition to be treated; Identify the characteristics of the patient; Real-time monitoring of one or more biomarkers associated with the patient; Based on the monitoring and input of the patient characteristics and the condition to be treated, the one or more machine learning models determine in real time the drug dosage to be administered to the patient in order to maintain at least one of the biomarkers within a predetermined effective range for treating the condition. as well as The infusion pump is driven to administer the determined dose of medication to the patient.

2. The method according to claim 1, further comprising: During the treatment of the condition, the monitoring, identification, and driving steps are repeated continuously.

3. The method according to claim 1 or 2, further comprising: Receiving clinician identification, The determination of the one or more machine learning models is also based on the input of the clinician's identifier, which is one of a plurality of doctors in the healthcare organization represented by the one or more machine learning models.

4. The method according to claim 3, further comprising: Determine the current status of the patient's condition requiring treatment; as well as The dosage of the drug is adjusted based on one or more historical adjustments made by the clinician in view of the current state of the condition.

5. The method according to claim 3, further comprising: Repeat the monitoring, identification, and driving steps described above; as well as Each time the dose is determined: Before driving the infusion pump to deliver the determined dose, the clinician is prompted to confirm the dose; and After the clinician cancels the prompt without providing confirmation of reaching the threshold number of times, the prompt is skipped.

6. The method according to any one of claims 1-5, wherein, Monitoring of the one or more biomarkers includes: Measurement data is received from one or more biophysical sensors coupled to the patient.

7. The method according to any one of claims 1-6, wherein, Monitoring of the one or more biomarkers includes: Receive measurement data associated with laboratory tests related to the patient.

8. The method according to claim 7, wherein, The measurement data includes drug concentration levels, and the method further includes: The predetermined effective range is determined based on the drug concentration level; or The sampling rate of the monitoring is adjusted based on the drug concentration level.

9. The method according to any one of claims 1-8, wherein, The patient's characteristics include one or more patient demographic features selected from a group of demographic features including age, sex, race, and ethnicity.

10. The method according to any one of claims 1-9, further comprising: Receive a request to notify when the at least one biomarker reaches a threshold level; as well as In response to the request for the notification: Calculate the trend and time points at which the at least one biomarker will reach the threshold level; and Provide notifications of the trends and the points in time.

11. The method according to any one of claims 1-10, further comprising, before driving the infusion pump to administer the determined dose of the drug: The user is prompted to confirm the determined dosage; and Receive confirmation of the determined dose.

12. The method of claim 11, further comprising: The user interface displays an indication of the determined dose and a modeled response to the patient's condition based on the determined dose.

13. The method according to any one of claims 1-12, further comprising: During the treatment of the condition, dosage parameters associated with the drug and the treatment of the condition are stored; Receive an instruction that treatment for the condition has been terminated; Determine the treatment outcome related to the described condition; as well as The training of the one or more machine learning models is updated based on the stored dose parameters and the treatment results.

14. A non-transitory machine-readable medium having instructions stored thereon, the instructions, when executed by a computing device, causing the computing device to perform the method according to any one of claims 1-13.

15. An infusion control device, comprising: shell; Communication interface; Input devices; monitor; as well as A processor configured to perform the method according to any one of claims 1-14 The communication interface is configured to interface the processor with the infusion pump. The input device is configured to receive the patient's identifier and selection of the condition to be treated, and to receive adjustments to parameters associated with the treatment of the condition and the drug dosage. The display is configured to show an indication of the determined dosage and parameters associated with the treatment of the condition.

Images