EP3759719A1 - Système de d'administration de médicament autonome - Google Patents

Système de d'administration de médicament autonome

Info

Publication number
EP3759719A1
EP3759719A1 EP19710910.1A EP19710910A EP3759719A1 EP 3759719 A1 EP3759719 A1 EP 3759719A1 EP 19710910 A EP19710910 A EP 19710910A EP 3759719 A1 EP3759719 A1 EP 3759719A1
Authority
EP
European Patent Office
Prior art keywords
diagnostic model
criterion associated
patient
model corresponds
substance
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP19710910.1A
Other languages
German (de)
English (en)
Inventor
Jerome J. Novak
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Masimo Corp
Original Assignee
Masimo Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US15/909,359 external-priority patent/US11259745B2/en
Application filed by Masimo Corp filed Critical Masimo Corp
Publication of EP3759719A1 publication Critical patent/EP3759719A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
    • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
    • G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
    • G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices

Definitions

  • Pulse oximetry is a widely accepted noninvasive procedure for measuring the oxygen saturation level of arterial blood, an indicator of a person's oxygen supply.
  • a typical pulse oximetry system utilizes an optical sensor attached to a fingertip to measure the relative volume of oxygenated hemoglobin in pulsatile arterial blood flowing within the fingertip.
  • Oxygen saturation (Sp02), pulse rate and a plethysmograph waveform which is a visualization of pulsatile blood flow over time, are displayed on a monitor accordingly.
  • Advanced pulse oximetry is described in at least U.S. Pat. Nos. 6,770,028; 6,658,276; 6,157,850; 6,002,952; 5,769,785 and 5,758,644, which are assigned to Masimo Corporation (“Masimo”) of Irvine, California and are incorporated in their entirety by reference herein.
  • Corresponding low noise optical sensors are disclosed in at least U.S. Pat. Nos. 6,985,764; 6,813,511; 6,792,300; 6,256,523; 6,088,607; 5,782,757 and 5,638,818, which are also assigned to Masimo and are also incorporated in their entirety by reference herein.
  • Advanced pulse oximetry systems including Masimo SET® low noise optical sensors and read through motion pulse oximetry monitors for measuring Sp02, pulse rate (PR) and perfusion index (PI) are available from Masimo.
  • Optical sensors include any of Masimo LNOP®, LNCS®, SofTouchTM and BIueTM adhesive or reusable sensors.
  • Pulse oximetry monitors include any of Masimo Rad-8®, Rad-5®, Rad®-5v or SatShare® monitors.
  • Advanced blood parameter measurement systems include Masimo Rainbow® SET, which provides measurements in addition to Sp02, such as total hemoglobin (SpHbTM), oxygen content (SpOCTM), methemoglobin (SpMet®), carboxyhemoglobin (SpCO®) and PVI®.
  • Advanced blood parameter sensors include Masimo Rainbow® adhesive, ReSposableTM and reusable sensors.
  • Advanced blood parameter monitors include Masimo Radical-7TM, Rad-87TM and Rad-57TM monitors, all available from Masimo.
  • Such advanced pulse oximeters, low noise sensors and advanced blood parameter systems have gained rapid acceptance in a wide variety of medical applications, including surgical wards, intensive care and neonatal units, general wards, home care, physical training, and virtually all types of monitoring scenarios.
  • opioids are often given to post-surgical patients for pain management, and while opioid use is safe for most patients, opioid analgesics are often associated with adverse reactions, such as respiratory depression as a result of excessive dosing, improper monitoring, medication interactions and adverse reactions with other drugs. Complications from opioid use are inevitable and not always avoidable. However, when a patient dies because such complications were not timely recognized or treated appropriately, it is termed a“failure to rescue.”
  • ADDS autonomous drug delivery system
  • An autonomous drug delivery system advantageously utilizes physiological monitor outputs so as to automatically give at least one bolus of at least one drug or medicine when certain criteria and confidence levels are met.
  • an emergency button is provided to manually trigger administration of such a rescue drug or medicine. In an embodiment, the emergency button may be triggered remotely.
  • ADDS advantageously responds with a rescue drug when delay in clinician response would otherwise result in patient injury or death.
  • One aspect of an autonomous drug delivery system is a housing with a front panel and a drug compartment.
  • a display and buttons are disposed on the front panel.
  • An IV injector is disposed in the drug compartment, and a nozzle extending from the housing is in mechanical communications with the IV injector.
  • the IV injector has a drug reservoir, a piston partially disposed within and extending from the drug reservoir and a drive motor in mechanical communications with the piston.
  • the drive motor actuates so as to drive the piston against a drug containing bolus disposed within the drug reservoir.
  • the piston causes the drug to extrude from the nozzle.
  • Another aspect of an autonomous drug delivery system is receiving a physiological parameter indicative of a medical state of a person and calculating a trigger condition and a corresponding confidence indicator. An alarm occurs if the trigger condition exceeds a predetermined threshold. A drug is administered to the person if the alarm is not manually acknowledged within a predetermined time interval.
  • FIGS. 1A-C are front, front partial-cutaway, and cutaway drug reservoir views of an autonomous drug delivery system (ADDS) embodiment
  • FIG. 2 is a front view of an autonomous drug delivery system configured with a conventional IV drip
  • FIG. 3 is a front view of an autonomous drug delivery system configured with an IV drip and a patient controlled analgesia (PCA) pump;
  • PCA patient controlled analgesia
  • FIG. 4 is a block diagram of an autonomous drug delivery system having fluid connectivity to a patient and electronic communications with sensor(s) and monitor(s);
  • FIG. 5 is a single-rail drug administration decision flow chart
  • FIG. 6 is a cutaway dual drug reservoir view of an autonomous drug delivery system embodiment
  • FIG. 7 is a dual-rail drug administration decision flow chart
  • FIG. 8 is a block diagram of an autonomous drug delivery system signal processing and instrument management.
  • FIG. 9 is a block diagram of an example automated first responder system.
  • FIG. 10 is a block diagram of an example automated first responder process.
  • FIG. 11 is a block diagram of example diagnostic models.
  • FIG. 12 is a block diagram of another example automated first responder process.
  • FIGS. 1A-C illustrate an autonomous drug delivery system (ADDS) 100 that inputs physiological parameters generated by one or more patient monitors, such as Sp02, PR, RR, EtC02 and BP, and evaluates certain criteria and confidence levels based upon those parameters, so as to automatically give a bolus of a rescue drug.
  • the autonomous drug delivery system 100 has a control section 102 and a drug section 108.
  • the control section 102 has a front panel 104 and an electrical interface (not visible).
  • the front panel 104 provides a user interface including a user display 110, such as an LED or LCD readout of device and patient status, among other data; control buttons 120 such as power on/off, reset, mode among other functions, and an emergency button 130 to manually trigger administration of the rescue drug.
  • the emergency button 130 may have a flip-up cover or other safety mechanism, such as a simultaneous press with another button, so as to prevent inadvertent drug administration.
  • the electrical interface communicates with patient monitor(s), alarm(s) and the drug section 108.
  • the drug section 108 has a cover 109 concealing a drug administration device installed within a recessed compartment, described below.
  • the cover 109 once flipped-up, slid-open, removed or otherwise opened, exposes an IV injector 150 having a drug reservoir 170, a piston 180 and a drive motor 190 disposed within a drug compartment 152.
  • the drug reservoir 170 is configured to accept a disposable bolus of a rescue drug.
  • the motor 190 drives the piston 180 into the drug reservoir 170 so that the rescue drug contained in the drug reservoir 170 is expelled out of the nozzle 178 (FIG. 1C) and into an attached IV tube that carries the rescue drug to the patient, as described with respect to FIGS. 2-3, below.
  • the bolus remains in the drug reservoir 170 until it is used or expires.
  • the expiration date can optionally be read from the bolus or otherwise entered into the ADDS memory (part of the DSP 810 FIG. 8)
  • the drug reservoir 170 has a generally-cylindrical enclosure 172 containing an unused rescue drug 174 and a piston 180.
  • the piston 180 has a piston head 182 disposed within the enclosure 172 and a piston shaft 184 extending from the enclosure 172.
  • the motor acts on the piston shaft 184 so as to move the piston head 182 from a first position (shown) distal the nozzle 178 to a second position proximate the nozzle, thus expelling the rescue drug from the reservoir 170 and into an IV tube (not shown) attached to the nozzle 178.
  • FIG. 2 illustrates a conventional IV drip configuration 200 incorporating an autonomous drug delivery system 100.
  • an IV pole 10 mounts an IV bag 20 in fluid communications with a patient 1 via an IV line 30.
  • Splicing the IV line is a one-way valve 50 in communications with the ADDS 100 via a line shunt 40.
  • the ADDS 100 injects its rescue drug 174 (FIG. 1C) into the shunt 40 and into the IV line 30 via the one-way valve 50, which shuts off the IV bag drip 20 blocking further IV bag 20 fluid.
  • FIG. 3 illustrates another conventional IV drip configuration 300 incorporating an autonomous drug delivery system 100 in addition to a patient controlled analgesia (PCA) pump 70.
  • an IV pole 10 mounts an IV bag 20 in fluid communications with a patient 1 via an IV line 30.
  • Splicing the IV line is a one-valve 50 in communications with the rescue device 100 via a line shunt 40.
  • Also splicing the IV line is a one-valve 60 in communications with the PCA pump.
  • the ADDS 100 injects its rescue drug 174 (FIG. 1C) into the shunt 40 and into the IV line 30 via the one-way valve 50, which shuts off the IV bag drip 20 and the PCA analgesia 72.
  • the ADDS 100 may be used for a variety of medical emergencies and conditions in conjunction with a variety of rescue drugs.
  • the ADDS is advantageously used in conjunction with a patient controlled analgesia (PCA) device that delivers pain medication upon patient demand.
  • PCA patient controlled analgesia
  • a patient can push a button to request a morphine injection.
  • a patient is particularly vulnerable to inadvertently overdosing themselves to the point of respiratory failure.
  • the ADDS inputs one or more parameters such as respiration rate, oxygen saturation, pulse rate, blood pressure and end- tidal C02 according to sensors attached to the patient and corresponding monitors and delivers an opioid antagonist such as Naloxone (Narcan), as described in further detail with respect to FIG. 4, below.
  • the ADDS 100 can optionally be responsive to heart arrhythmias and deliver a rescue drug specific to the type of rhythm detected; can optionally be responsive to a high heart rate or low heart rate so as to deliver a heart rate regulating drug; can optionally be responsive to high or low blood pressure so as to deliver a blood pressure regulating drug; can optionally be responsive to hypoglycemia so as to deliver glucagon; or can be responsive to other specific conditions and deliver appropriate medicine.
  • the ADDS 100 delivers compounded (mixed) formulas of more than one drug. This is accomplished through a mixture of drugs stored in a single reservoir or the use of multiple reservoirs. In all of these embodiments, the response is always a bolus (reservoir) administration.
  • the drug is infused in a single administration step all at once (as opposed to over a prescribed amount of time as in a pump).
  • the ADDS is capable of delivering multiple bolus doses, where subsequent bolus doses are ideally enabled after manual review of the initial, automatically delivered dose.
  • the ADDS can be configured to administer the bolus at a specific date and time, rather than in response to a monitored condition.
  • the bolus administration can be at multiple discrete times or over a specified time interval.
  • a prescribed minimum and or maximum interval from a previous dose or start time may be used.
  • physiological“guard rails” must be maintained.
  • a hypotensive drug may be used to raise a patient's blood pressure during emergencies.
  • a drug to regulate heart rhythm or suppress arrhythmias may be used.
  • the display 110 (FIG. 1A) indicates the device is working and receiving proper inputs.
  • the ADDS 100 has a memory that records data that can be recalled to indicate a trigger cause for administering a rescue drug, such as the time and amount of drug administered and other logged conditions.
  • the rescue drug is administered in a progression rather than all-at-once.
  • a 10% dose may be given and the patient monitored for improvement, with additional doses spaced at intervals as needed.
  • a spring driven piston with a releasable catch is used to administer the rescue drug in lieu of a motor-driven piston.
  • an ADDS is advantageously integrated with a PCA device as a single instrument.
  • FIG. 4 illustrates an autonomous drug delivery system 400 having fluid connectivity to a patient 412 and electronic communications 424 with one or more monitors 420.
  • One or more sensors 430 interface 432 with the patient 412, either by direct patient attachment or by remote sensing.
  • an optical sensor 430 may clip to a fingertip site 432 and provide pulsatile blood flow data via cable 422 to a pulse oximeter or blood parameter monitor 420.
  • the pulse oximeter or blood parameter monitor 420 calculates physiological parameters 424, such as oxygen saturation and pulse rate, which are transmitted to the ADDS 410.
  • the ADDS 410 responds to the parameters 424 by regulating (starting, increasing, decreasing or halting) the drug dosage 412 accordingly.
  • the ADDS 410 may generate one or more alarms 414 to alert a caregiver.
  • the caregiver may reset 416 an alarm upon responding to the alert.
  • communication between the ADDS 410 and a caregiver may be via a wired or wireless network and received at a nurses' station or equivalent.
  • FIG. 5 illustrates example single-rail drug administration decisions.
  • a single threshold maximum or minimum
  • One or more parameters 501 are input to the ADDS device.
  • An ADDS algorithm 510 calculates a trigger condition and an associated confidence indicator 512. If the ADDS trigger threshold is exceeded 520, an alarm 530 is triggered 522. Otherwise 524, ADDS does nothing. If the alarm 532 is timely acknowledged 540, such as by a caregiver pressing an ADDS acknowledge button 544, then ADDS exits 560 and the alarm is silenced. If the alarm 532 is not acknowledged 542, then ADDS administers a rescue drug 550.
  • ADDS has a manual trigger 570 (button press), so as to manual trigger 572 drug administration 550 (see 130 FIG. 1A).
  • alarms 530 and corresponding acknowledgment times 540 may progress from a local alarm, a network alarm and finally a pager alarm before autonomous drug delivery is triggered.
  • FIG. 6 illustrates a dual drug reservoir embodiment 600 of an autonomous drug delivery system.
  • a first drug reservoir 670 and a second drug reservoir 680 may each contain the same drug for one or two separate doses or may contain different drugs for different single doses depending on the monitored condition. See, for example FIG. 7.
  • the drug reservoirs 670, 680 share a common nozzle 662.
  • the nozzle 662 has a junction 660 that connects fluid tubes 678, 688 to respect first 676 and second 686 reservoir nozzles.
  • a clinician has to re-enable the ADDS before a second dose is administered.
  • FIG. 7 illustrates dual-rail drug administration decisions.
  • One or more parameters 701 are input to the ADDS device.
  • ADDS algorithms 710 and 760 calculate maximum (HI) trigger conditions and minimum (LO) trigger conditions and associated confidence indicator. If either the HI or LO ADDS trigger thresholds are exceeded 720, 770 the corresponding alarm 730, 780 is triggered. Otherwise 724, 774 ADDS does nothing. If a HI or LO alarm 730, 780 is timely acknowledged, such as a caregiver pressing an ADDS acknowledge button 744, 794, then ADDS exits 741, 791 and the alarm is silenced. If the alarm 730, 780 is not acknowledged 742, 792 then ADDS administers the appropriate HI rail 745 or LO rail 795 rescue drug. Note that ADDS has manual triggers 799 (LO or HI button presses), so as to manually trigger either the LO rail drug 745 or the HI rail drug 795.
  • FIG. 8 illustrates an autonomous drug delivery system (ADDS) controller 800 having a digital signal processor (DSP) 810, an instrument manager 820 and interfaces 830.
  • the DSP 810 has algorithms, such as described with respect to FIGS. 5-7, above, for determining trigger conditions, alarms and trigger timing 812.
  • the instrument manager 820 interfaces with the DSP 810 so as to drive the ADDS displays 832 and alarms 834, to receive inputs from the buttons/keypad 835, to communicate with external monitors 837 that derive triggering parameters from patient sensors, to control the injector motor(s) and read injector status 839, such as bolus full/empty and injector active (delivering rescue drug).
  • DSP firmware records in memory the time and duration of events that triggered drug delivery, including a before and after history of monitor parameters that triggered drug administration.
  • FIG. 9 depicts an example automated first responder system 900.
  • a patient 902 is shown in communication with a patient monitor 910 and an autonomous drug delivery device 920.
  • the patient monitor 910 may be in wireless or electrical communication with one or more sensors coupled with the patient. Examples of such sensors are described above, and may include, for example, optical sensors, acoustic respiratory sensors, ECG sensors, brainwave measurement sensors, blood pressure sensors, and the like.
  • the patient monitor 910 and the autonomous drug delivery device 920 can have some or all of the features of similar devices described above.
  • the patient monitor 910 can include any of the controller features described above with respect to FIG. 8.
  • the patient monitor 910 may include one or more hardware processors, memory, and a display.
  • the display may be optional, and the patient monitor 910 can output patient data to a separate display.
  • the autonomous drug delivery device 920 can have some or all the features of the ADDS embodiments described above.
  • the patient monitor 910 is shown in communication with a gateway device 940.
  • the patient monitor 910 may communicate with the gateway device 940 wired or wirelessly over a hospital network (not shown).
  • the hospital network may include a local area network, a wide area network, an intranet, the Internet, combinations of the same, or the like.
  • the gateway device 940 can facilitate communication across the network between multiple devices shown in the system 900. These devices can include clinician devices 960, which may include tablets, pagers, smart phones, laptops, computers, nurses’ station computers, and the like.
  • the gateway 940 is shown in communication with an electronic medical record (EMR) database 950, which can store lab results 930 obtained from laboratory tests applied to the patient 902.
  • EMR electronic medical record
  • the patient monitor 910 may access the EMR 950 through the gateway 940 to obtain access to the lab results 930 as well as other data, including data regarding charting of the patient’s conditions, medications, tests, and the like applied during a hospital stay.
  • the system 900 can also be applied in any clinical setting, and not just in a hospital. However, for convenience, this specification refers specifically to hospital embodiments, without loss of generality.
  • the automated first responder system 900 can implement any of the features described above with respect to FIGS. 1-8.
  • the automated first responder system 900 can also implement the additional features discussed below.
  • the patient monitor 910 can initiate treatment workflows automatically based on an analysis of patient data.
  • the patient data can include data measured from physiological sensors, as well as data obtained from lab results and the like. Using this patient data, the patient monitor 910 can determine whether the data corresponds with or matches any diagnostic model or models stored in physical computer storage.
  • a diagnostic model can be represented as a data structure or the like and can relate a set of patient data inputs to a possible diagnosis and to a treatment workflow to address the possible diagnosis. Example treatment workflows are described below with respect to FIG. 11.
  • the patient monitor 910 can initiate a treatment workflow automatically to begin treatment of the patient.
  • the treatment workflow can include administration of a substance, such as a drug, using any of the techniques described above.
  • the treatment workflow can also include other actions, such as ordering lab tests, alerting clinicians, and the like.
  • the patient monitor 910 may communicate an instruction or signal to the autonomous drug delivery device 920 to cause the autonomous drug delivery device 920 to supply a dose or bolus of medication to the patient 902.
  • the autonomous drug delivery device 920 is an intravenous therapy device, such as an intravenous (IV) drip device.
  • IV intravenous
  • the autonomous drug delivery device 920 may administer substances other than drugs to the patient 902, such as saline solution.
  • a saline solution may be combined with a drug to be administered to the patient 902.
  • the treatment workflow may include initially administering a first dosage of a substance to a patient without requiring initiation by a clinician.
  • the patient monitor 910 may produce an output (for example, on the display) that provides the clinician with an option to intervene and stop administration of a substance or stop any other aspect of a treatment workflow.
  • the treatment workflow may include alerting a clinician instead of administrating the second dosage.
  • a clinician instead of administrating the second dosage.
  • the patient monitor 910 upon detecting that a diagnostic model has been matched, can alert a clinician who may be remote from the patient of the patient’s potential condition. The clinician can then respond to the alert in various ways, discussed below.
  • the alert to the clinician may be sent as a message over a network, such as the hospital network, to a clinician’s device (such as a smartphone, tablet, laptop, desktop, or other computing device).
  • a clinician’s device such as a smartphone, tablet, laptop, desktop, or other computing device.
  • the alert may be sent as an electronic mail message, a text message, or as another type of message, including a custom message for a custom mobile application or web application installed or accessed on the clinician’s device.
  • the alert can include any subset of the following information: patient identifying and/or demographic information, the patient data or a summary thereof (such as waveform(s) and/or physiological parameter value(s)), an indication of the patient’s condition such as an indication that a specific diagnostic model has been met (such as“this patient may have sepsis” or“possible opioid overdose detected”), and a recommended treatment course (such as a recommendation to administer a bolus of medication, order a lab test, or any other aspect of a workflow discussed herein).
  • patient identifying and/or demographic information such as waveform(s) and/or physiological parameter value(s)
  • an indication of the patient’s condition such as an indication that a specific diagnostic model has been met (such as“this patient may have sepsis” or“possible opioid overdose detected”)
  • a recommended treatment course such as a recommendation to administer a bolus of medication, order a lab test, or any other aspect of a workflow discussed herein).
  • the clinician’s device can output the message to the clinician optionally with functionality for the clinician to respond.
  • the clinician’s device may have a mobile application or browser installed that can receive the alert and output a user interface with the alert for presentation to the clinician.
  • the user interface may include buttons, input fields, or other user interface controls that allow the clinician to interact with the alert.
  • the user interface may provide functionality for the clinician to accept or adjust the recommended treatment.
  • the software on the clinician’s device can transmit the acceptance to the patient monitor 910, which can cause the autonomous drug delivery device 920 to deliver the recommended dosage to the patient (or order a lab or perform another workflow action). Should the clinician adjust the recommended treatment, this adjustment may be communicated to the patient monitor 910, which can cause the autonomous drug delivery device 920 to deliver the adjusted dosage to the patient (or order a lab or perform another workflow action).
  • the clinician can remotely create or adjust a treatment workflow, whether lab order or drug administration or other workflow, and can cause this adjustment to be sent to the patient monitor 910 for application to the patient.
  • the clinician may receive patient data with or without a recommendation for treatment.
  • the clinician can then access a user interface on the clinician’ s device to input a desired treatment or workflow, even if one was not recommended by the patient monitor 910.
  • the clinician device can transmit this selected treatment or workflow to the patient monitor 910.
  • the patient monitor 910 can cause the autonomous drug delivery device 920 to deliver the selected dosage to the patient.
  • Any of the autonomous drug delivery devices described herein can include a plurality of different intervention medications ready to be injected or supplied to the patient intravenously as desired.
  • FIG. 10 depicts an example automated first responder process 1000.
  • the automated first responder process 1000 can be implemented by any of the systems described above.
  • the patient monitor 910 can implement the process 1000.
  • at least part of the process 1000 can be implemented in any server, for instance, in a cloud computing environment.
  • the process 1000 can be implemented in a server that receives information from the patient monitor 910, and which provides outputs to the monitor 910 to enable the monitor 910 to perform portions of a treatment workflow (such as initiate delivery of substance by the autonomous drug delivery device 920).
  • a treatment workflow such as initiate delivery of substance by the autonomous drug delivery device 920.
  • the process 1000 is described as being implemented primarily by the patient monitor 910.
  • the patient monitor 910 receives patient data including one or more physiological parameter values.
  • the one or more physiological parameter values may include values of one or more physiological parameters, such as respiration rate, oxygen saturation, blood pressure, heart rate, and the like (as well as any other parameters discussed above).
  • the patient monitor may receive additional patient data, such as lab test values.
  • a lab test value that may be useful is white blood cell count (WBC). More generally, any blood test value, urine test value, stool test value, or any other lab test value may be used.
  • the patient monitor 910 analyzes patient data based on one or more diagnostic models.
  • the patient monitor 910 can compare the patient data to any diagnostic models stored in memory or other physical computer storage.
  • the diagnostic models may include one or more criteria for determining whether to initiate a treatment workflow. Evaluating this criteria can involve performing a comparison of the patient data with specific values, thresholds, trends, changes, combinations, ratios, and the like. A specific combination of parameter trends, for instance, may indicate that a patient is likely experiencing an opioid overdose, sepsis, hypovolemia, or any of a number of other conditions. Specific examples of diagnostic models are presented below with respect to FIG. 11.
  • the patient monitor 910 determines whether the patient data matches a diagnostic model. If not, the process 1000 loops back to block 1002, and the patient monitor 910 continues to receive patient data. If the patient monitor 910 identifies a match in a diagnostic model, however, the process 1000 proceeds to block 1008, where the patient monitor 910 determines whether this is the first time that the patient data matches this model. If so, at block 1010 the patient monitor 910 initiates a treatment workflow specific to the diagnostic model. The process 1000 then loops back to block 1002.
  • Diagnostic models can be represented as data structures or data definitions stored in physical computer storage or memory. Diagnostic models can also be generated empirically by collecting data from a plurality of patients, measuring the same or similar physiological parameters, and by analyzing patient treatments and subsequent outcomes. Diagnostic models can also be rule-based models, or a combination of empirical and rule-based models. Some example rule-based models are described below with respect to FIG. 11.
  • the patient monitor 910 calculates a confidence value that represents a likelihood that the patient data matches the diagnostic model.
  • the confidence value can be a percentage value, a score on any scale, or the like.
  • the patient monitor 910 can calculate a higher confidence value based on the patient data more closely matching the diagnostic model or a lower confidence value based on the patient data less closely matching the diagnostic model.
  • the confidence value can also be based determined at least in part on parameter value confidence.
  • the patient monitor 910 can calculate a confidence value for a parameter value, indicating a likelihood of the parameter value being accurate.
  • the confidence value for matching the diagnostic model can therefore take into account parameter confidence values. For example, if two parameters are analyzed with respect to a diagnostic model, and the two parameters have a calculated confidence of 95% and 75% respectively, the patient monitor 910 can calculate a confidence value that is the mean of these two values (85%) or some other combination of these two values (such as selecting the lower confidence value as the overall confidence value). Then, the patient monitor 910 can compare the two parameter values with the diagnostic model and determine how closely the parameters match the model.
  • the patient monitor 910 can give a high confidence score, but the patient monitor 910 may then modify this high confidence score based on the parameter value confidence scores. For instance, if the confidence value for matching the model is 95%, but the parameter value confidence is 75%, the patient monitor 910 may lower the confidence for matching the model (e.g., by multiplying the two numbers to reach -71%). Many other ways for calculating confidence are possible.
  • the patient monitor 910 can determine that if the confidence value is too low, that the diagnostic model is not met. Alternatively, the patient monitor 910 can determine that the diagnostic model is met even when a confidence value is low but may output an indication of the confidence value (for example, on a display) so that a clinician can determine whether to trust the diagnostic model match.
  • the patient monitor 910 can output an indication of the confidence value regardless of the value, whether it be high or low.
  • the indication can be the value itself or some representation of that value, such as a graphic representation (for example, a bar with a size corresponding to the confidence value).
  • the patient monitor 910 alerts a clinician so that the clinician can determine whether to give an additional substance or perform an additional action associated with the treatment workflow.
  • the patient monitor 910 can alert the clinician by outputting the alert or alarm audibly and/or visually.
  • the patient monitor 910 can also alert the clinician by transmitting an alert or alarm message to the clinician over a network, such as a hospital network, a local area network (LAN), a wide area network (WAN), the Internet, an Intranet, or the like.
  • the process 1000 can provide an automated treatment of the patient as a first response and defer clinician intervention until a subsequent response. For instance, a first time when it is determined that the patient data indicates a possible opioid overdose, the patient monitor can cause an initial dosage of an overdose-treating medication like Narcan to be supplied to the patient. However, if later the patient data again indicates that the patient is suffering from a possible overdose, the patient monitor 910 can alert a clinician to determine whether the patient needs an additional dose.
  • the patient monitor 910 can automatically supply a second dose to the patient.
  • the patient monitor 910 may be restricted from supplying a second dose to the patient unless the patient data includes a life-threatening parameter value or values (such as a very low pulse rate, oxygen saturation value, or blood pressure).
  • the patient monitor 910 can take into account any of the following variables when determining whether to administer a subsequent dose of a drug to a patient, among others: time elapsed since an alarm without a clinician disabling the alarm or otherwise responding to the alarm; severity of the patient data; amount of the earlier and/or subsequent dosage (a lower dose may be less harmful, and thus subsequent low doses might be permitted without clinician intervention); the type of drug administered (some drugs may have less risk for administering subsequent doses than others); specific facts about the patient including demographics, comorbidities, or the like (for example, a neonate might be at higher risk than an adult for a subsequent dose, or a patient with a certain disease might be at a higher risk than patients without that disease for a certain dose); other medications taken by the patient (a subsequent dose might be potentially more harmful if a patient is taking other medication that can react adversely upon a subsequent dose); prior permission by a clinician (the patient monitor 910 can output a user interface that enables a clinician to explicitly give permission for one or more variables
  • FIG. 11 depicts example diagnostic models 1110, 1120, and 1130. These diagnostic models show example criteria corresponding to possible diagnoses and associated example treatment workflows.
  • the first model 1110 is an opioid overdose model. In this model, if respiratory rate, heart rate, and blood pressure have decreased (for example, are trending downward or pass below a threshold), then these parameter changes may indicate an opioid overdose and may trigger a treatment workflow. A decrease in temperature can also be indicative of opioid overdose in the model.
  • the example treatment workflow shown includes an administration of Narcan and informing a clinician. Informing a clinician may include sending an alert or alarm to clinician as described above, recording an indication in the patient’s chart (such as in the EMR), combinations of the same or the like.
  • the treatment workflow shown may be modified to include more or fewer steps. In addition, the steps of the treatment workflow and other treatment workflows described herein may be implemented in any order.
  • the second model 1120 is a hypovolemia model.
  • this model 1120 if blood pressure has decreased (for example, trending downward or below a threshold), heart rate is increased (for example, trending upward or above a threshold), and hemoglobin level (whether measured noninvasively (SpHb) or in a lab (THb)) is steady (for example, no positive or negative trend, or slope of the average trend is within a tolerance, or the parameter value has not changed more than a threshold amount for a period of time), this may be an indication that the patient is suffering from hypovolemia.
  • SpHb noninvasively
  • THb lab
  • the treatment workflow that may be triggered may include increasing a saline infusion rate (to increase blood volume and/or sodium levels in the blood), supplying oxygen (not shown; can increase the efficiency of the patient’s remaining blood supply), and informing a clinician (similar to above).
  • a saline infusion rate to increase blood volume and/or sodium levels in the blood
  • oxygen not shown; can increase the efficiency of the patient’s remaining blood supply
  • informing a clinician similar to above.
  • other steps may be included in these and other treatment workflows, such as ordering other drugs, recommending possible surgery (for example, to stop internal bleeding for some hypovolemic patients), and so on.
  • the third model 1130 shown is a sepsis model.
  • the patient may be suffering from sepsis.
  • Increased heart rate for example, above a threshold
  • increased respiratory rate for example, above a threshold
  • decreased systolic blood pressure for example, below a threshold
  • the example treatment workflow shown includes activating a sepsis team (for example, informing a team of clinicians having different tasks that can assist with treating sepsis), administering drugs, and ordering labs, drugs, and radiology tests.
  • the treatment workflow can also include automatically administering intravenous fluids and/or antibiotics.
  • the treatment workflow can also include recommending transfer of the patient to an intensive care unit (ICU).
  • ICU intensive care unit
  • administration of some drugs can cause side effects, which may be detected or inferred from the patient data.
  • administration of some drugs can impact blood pressure negatively. Detecting a change in blood pressure after a drug has been administered may cause a treatment workflow to begin that stops administration of the drug (if being administered automatically) or that recommends to a clinician to consider stopping administration of the drug.
  • a diagnostic model may be provided for detecting bedsore formation (or risk factors for bedsore formation).
  • This diagnostic model may take input from a pressure mat on the patient’s bed or on the floor next to the bed, which can provide an electrical signal output when a patient moves or steps on the mat. Lack of movement or lack of stepping on a mat may indicate that the patient is not moving enough and is therefore susceptible to a bedsore.
  • a possible treatment workflow may be executed, including alerting a caregiver that the patient should be moved in some manner to attempt to prevent bedsore formation.
  • Diagnostic models may also take into account more than the physiological parameters and lab tests described herein as examples of patient data. Additional patient data may be relevant to evaluating whether a particular model is applicable. For instance, data regarding the patient’s gender, age, or other comorbidities may impact whether or not the patient monitor determines that a particular diagnostic model is applicable. Likewise, any of these factors may be used to modify a treatment workflow when a diagnostic model is indicated as being applicable.
  • a treatment workflow that involves applying ventilation from a ventilator may include supplying more carbon dioxide than would be supplied to a non-smoking patient because the smoker’ s lungs are adapted to higher carbon dioxide levels when breathing.
  • a previous or current treatment may be an input into a diagnostic model as part of the patient data.
  • a previous or current treatment may affect whether a diagnostic model is applied and/or how a treatment workflow is executed.
  • the patient monitor may be on heightened alert to search for indications of sepsis.
  • the patient monitor may therefore be more sensitive to changes in blood pressure, temperature, and white blood cell count to determine whether sepsis is occurring. More specifically, a lower change in blood pressure, white blood cell count, or temperature than for other patients not having had hip replacement recently may be applied to trigger a sepsis treatment workflow.
  • the level of alert provided to a clinician may vary depending on the seriousness of the diagnostic model detected. With sepsis, for instance, an entire team may be alerted, whereas with other conditions, like hypovolemia, a single clinician may be alerted. Of course, the number of clinicians alerted for any given condition can depend on the severity of that condition, the severity of the physiological parameter values, and so on, and may deviate from that shown in FIG. 11.
  • Static thresholds can include predetermined thresholds that are the same for a class of patients, such as the same set of thresholds for all adults or a different set of thresholds for all neonates.
  • Dynamic thresholds can include thresholds that are based on the current patient’ s mean or baseline physiological parameter values. Table 1 below depicts example static thresholds and dynamic thresholds for adult patients for some physiological parameters:
  • the static threshold category may be further subdivided into two subcategories—critical thresholds and normal thresholds.
  • Critical thresholds may represent thresholds below (or above) which a physiological parameter is at a critical or life-threatening value.
  • Normal thresholds can represent less-critical or less life threatening values that still nevertheless may be indicative of a diagnosis per a diagnostic model.
  • Some diagnostic models can use critical thresholds, while others may use normal thresholds.
  • Some diagnostic models may use a critical threshold for one parameter and a normal threshold for another parameter.
  • the patient monitor can evaluate static thresholds or dynamic thresholds to determine whether a diagnostic model is met.
  • the patient monitor can evaluate both static and dynamic thresholds to determine whether a diagnostic model is met.
  • the patient monitor can perform a logical“OR” operation based on a comparison of physiological models to both static and dynamic thresholds.
  • a logical“OR” operation based on a comparison of physiological models to both static and dynamic thresholds.
  • the patient monitor performs a logical “AND” operation (or some other logical operation) based on a comparison of physiological models to both static and dynamic thresholds.
  • the patient monitor can rely on static thresholds early in a patient’s hospital stay, where mean or baseline values of the patient’s parameters are unknown or less reliable to calculate based on lack of patient data. Later in the patient’s hospital stay (possibly even some minutes or hours after admission), the patient monitor can rely on dynamic thresholds after enough data about the patient is available to determine mean or baseline values.
  • FIG. 12 depicts another example automated first responder process 1200.
  • the automated first responder process 1200 can be implemented by any of the systems described above.
  • the patient monitor 910 can implement the process 1200.
  • at least part of the process 1200 can be implemented in a server, for instance, in a cloud computing environment.
  • the process 1200 can optionally be implemented in a server that receives information from the patient monitor 910, and which provides outputs to the monitor 910, to enable the monitor 910 to perform portions of a treatment workflow.
  • the process 1200 is described as being implemented primarily by the patient monitor 910.
  • Blocks 1202 through 1206 can proceed the same or similar to blocks 1002 through 1006 of the process 1000 (see FIG. 10).
  • the patient monitor 910 outputs an alarm or alert to a clinician.
  • This alarm or alert can be provided in a similar manner to the alarm or alert output in block 1012 of the process 1000 (see FIG. 10).
  • the patient monitor 910 determines at block 1210 whether the alarm (or alert) has been acknowledged within a predetermined time period (such as 30 seconds, 1 minute, 2 minutes, or some other time period). For instance, the patient monitor 910 can determine whether a clinician disabled the alarm as an indication that the alarm was acknowledged. Disabling of the alarm can indicate that the clinician visited the patient’s bedside and explored the situation that led to the alarm.
  • the process 1200 can end. If the alarm was not acknowledged within the predetermined time period, then at block 1212, the patient monitor 910 can initiate a treatment workflow specific to the diagnostic model, as explained above with respect to block 1010 of FIG. 10.
  • This process 1200 therefore enables the patient to receive some form of medical attention, such as specified by a treatment workflow, if a clinician is unable to treat the patient within a certain amount of time.
  • This process 1200 can save lives and increase patient comfort in busy hospitals or in other triage situations.
  • the patient monitor 910 can implement blocks 1008 and 1012 of the process 1000 or the like.
  • acts or events can be performed concurrently, for example, through multi-threaded processing, interrupt processing, or multiple processors or processor cores or on other parallel architectures, rather than sequentially.
  • different tasks or processes can be performed by different machines and/or computing systems that can function together.
  • a hardware processor comprising digital logic circuitry, a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein.
  • DSP digital signal processor
  • ASIC application specific integrated circuit
  • FPGA field programmable gate array
  • a general purpose processor can be a microprocessor, but in the alternative, the processor can be a controller, microcontroller, or state machine, combinations of the same, or the like.
  • a processor can include electrical circuitry configured to process computer-executable instructions.
  • a processor includes an FPGA or other programmable device that performs logic operations without processing computer-executable instructions.
  • a processor can also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.
  • a computing environment can include any type of computer system, including, but not limited to, a computer system based on a microprocessor, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or a computational engine within an appliance, to name a few.
  • a software module can reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other form of non-transitory computer-readable storage medium, media, or physical computer storage known in the art.
  • An example storage medium can be coupled to the processor such that the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium can be integral to the processor.
  • the storage medium can be volatile or nonvolatile.
  • the processor and the storage medium can reside in an ASIC.
  • Conditional language used herein such as, among others, “can,” “might,” “may,” “for example,” and the like, unless specifically stated otherwise, or otherwise understood within the context as used, is generally intended to convey that certain embodiments include, while other embodiments do not include, certain features, elements and/or states. Thus, such conditional language is not generally intended to imply that features, elements and/or states are in any way required for one or more embodiments or that one or more embodiments necessarily include logic for deciding, with or without author input or prompting, whether these features, elements and/or states are included or are to be performed in any particular embodiment.
  • the terms“comprising,”“including,”“having,” and the like are synonymous and are used inclusively, in an open-ended fashion, and do not exclude additional elements, features, acts, operations, and so forth.
  • the term“or” is used in its inclusive sense (and not in its exclusive sense) so that when used, for example, to connect a list of elements, the term“or” means one, some, or all of the elements in the list.
  • the term“each,” as used herein, in addition to having its ordinary meaning, can mean any subset of a set of elements to which the term“each” is applied.
  • Disjunctive language such as the phrase“at least one of X, Y and Z,” unless specifically stated otherwise, is to be understood with the context as used in general to convey that an item, term, etc. may be either X, Y, or Z, or a combination thereof. Thus, such conjunctive language is not generally intended to imply that certain embodiments require at least one of X, at least one of Y and at least one of Z to each be present.
  • phrases such as“a device configured to” are intended to include one or more recited devices. Such one or more recited devices can also be collectively configured to carry out the stated recitations.
  • “a processor configured to carry out recitations A, B and C” can include a first processor configured to carry out recitation A working in conjunction with a second processor configured to carry out recitations B and C.

Landscapes

  • Health & Medical Sciences (AREA)
  • Engineering & Computer Science (AREA)
  • Biomedical Technology (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Infusion, Injection, And Reservoir Apparatuses (AREA)
  • Measuring And Recording Apparatus For Diagnosis (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

Système d'administration de médicament autonome utilisant avantageusement des sorties de moniteur physiologiques de façon à donner automatiquement un bolus d'un médicament de sauvetage ou d'un autre médicament nécessaire lorsque certains critères et niveaux de confiance sont satisfaits. Un bouton d'urgence est prévu pour déclencher manuellement l'administration du médicament de sauvetage. Le médicament de sauvetage peut être un antagoniste opioïde en réponse à une surdose d'analgésie, un médicament hypotenseur pour éviter une chute excessive de la pression artérielle ou un médicament anti-arythmie pour supprimer des battements cardiaques anormaux, pour en citer quelques-uns.
EP19710910.1A 2018-03-01 2019-02-27 Système de d'administration de médicament autonome Pending EP3759719A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US15/909,359 US11259745B2 (en) 2014-01-28 2018-03-01 Autonomous drug delivery system
PCT/US2019/019885 WO2019169026A1 (fr) 2018-03-01 2019-02-27 Système de d'administration de médicament autonome

Publications (1)

Publication Number Publication Date
EP3759719A1 true EP3759719A1 (fr) 2021-01-06

Family

ID=65763842

Family Applications (1)

Application Number Title Priority Date Filing Date
EP19710910.1A Pending EP3759719A1 (fr) 2018-03-01 2019-02-27 Système de d'administration de médicament autonome

Country Status (3)

Country Link
EP (1) EP3759719A1 (fr)
JP (1) JP7299230B2 (fr)
WO (1) WO2019169026A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11259745B2 (en) 2014-01-28 2022-03-01 Masimo Corporation Autonomous drug delivery system

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5632272A (en) 1991-03-07 1997-05-27 Masimo Corporation Signal processing apparatus
CA2105682C (fr) 1991-03-07 2003-09-02 Mohamed K. Diab Methode et appareil de traitement de signaux
US5638818A (en) 1991-03-21 1997-06-17 Masimo Corporation Low noise optical probe
JP3409399B2 (ja) * 1993-11-30 2003-05-26 セイコーエプソン株式会社 投薬制御装置
US5758644A (en) 1995-06-07 1998-06-02 Masimo Corporation Manual and automatic probe calibration
US6002952A (en) 1997-04-14 1999-12-14 Masimo Corporation Signal processing apparatus and method
US6770028B1 (en) 1999-01-25 2004-08-03 Masimo Corporation Dual-mode pulse oximeter
US6658276B2 (en) 1999-01-25 2003-12-02 Masimo Corporation Pulse oximeter user interface
JP2004532526A (ja) 2001-05-03 2004-10-21 マシモ・コーポレイション フレックス回路シールド光学センサ及び該フレックス回路シールド光学センサを製造する方法
JP2011005262A (ja) * 2001-12-28 2011-01-13 Scott Lab Inc 患者の応答性を自動的に評価およびモニタする装置および方法
WO2006094109A1 (fr) 2005-03-01 2006-09-08 Masimo Laboratories, Inc. Moniteur non invasif a parametres multiples destine a un patient
US20070060874A1 (en) * 2005-09-12 2007-03-15 Nesbitt Matthew T Apparatus and methods for controlling and automating fluid infusion activities
BR112012000778A8 (pt) * 2009-07-15 2018-02-20 Koninklijke Philips Electronics Nv Método para o provimento de um alerta de parâmetro fisiológico com variação de tempo, mídia de leitura por computador, e sistema que fornece um alerta de parâmetro fisiológico com variação de tempo para um usuário
EP2512545A2 (fr) * 2009-12-18 2012-10-24 K&Y Corporation Système de gestion des fluides d'un patient
US10453157B2 (en) * 2010-01-22 2019-10-22 Deka Products Limited Partnership System, method, and apparatus for electronic patient care
US20130046197A1 (en) * 2011-08-16 2013-02-21 Daniel F. Dlugos, Jr. Docking station for patient bedside monitoring units
JP7148253B2 (ja) 2018-03-27 2022-10-05 アサヒ飲料株式会社 炭酸飲料

Also Published As

Publication number Publication date
JP2021515613A (ja) 2021-06-24
WO2019169026A1 (fr) 2019-09-06
JP7299230B2 (ja) 2023-06-27

Similar Documents

Publication Publication Date Title
US11883190B2 (en) Autonomous drug delivery system
US10086138B1 (en) Autonomous drug delivery system
JP4970045B2 (ja) 患者モニタリングシステムを用いる患者自己管理鎮痛法
RU2295361C2 (ru) Система для инфузии лекарственного средства с контролированием двуокиси углерода
AU2003232110B2 (en) System and method for transparent early detection, warning, and intervention during a medical procedure
CN112512406A (zh) 阿片类药物过量监测
JP2017537753A (ja) 呼吸パラメータによって誘導される自動静脈内投与および静脈内チューブクランプアクティブ化
JP7299230B2 (ja) 自律型薬物送達システム
AU2008201331B2 (en) Co2 monitored drug infusion system

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20201001

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20230925