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
  • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
  • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
  • G16H20/17—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients delivered via infusion or injection
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
  • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
  • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
  • A61M5/16804—Flow controllers
  • A61M5/16827—Flow controllers controlling delivery of multiple fluids, e.g. sequencing, mixing or via separate flow-paths
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M5/00—Devices for bringing media into the body in a subcutaneous, intra-vascular or intramuscular way; Accessories therefor, e.g. filling or cleaning devices, arm-rests
  • A61M5/14—Infusion devices, e.g. infusing by gravity; Blood infusion; Accessories therefor
  • A61M5/168—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body
  • A61M5/172—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic
  • A61M5/1723—Means for controlling media flow to the body or for metering media to the body, e.g. drip meters, counters ; Monitoring media flow to the body electrical or electronic using feedback of body parameters, e.g. blood-sugar, pressure
• • 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
  • G16H40/63—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 for local operation
• • 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
  • G16H40/67—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 for remote operation
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M2205/00—General characteristics of the apparatus
  • A61M2205/18—General characteristics of the apparatus with alarm
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M2205/00—General characteristics of the apparatus
  • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M2205/00—General characteristics of the apparatus
  • A61M2205/50—General characteristics of the apparatus with microprocessors or computers
  • A61M2205/502—User interfaces, e.g. screens or keyboards
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M2205/00—General characteristics of the apparatus
  • A61M2205/58—Means for facilitating use, e.g. by people with impaired vision
  • A61M2205/582—Means for facilitating use, e.g. by people with impaired vision by tactile feedback
• • A—HUMAN NECESSITIES
  • A61—MEDICAL OR VETERINARY SCIENCE; HYGIENE
  • A61M—DEVICES FOR INTRODUCING MEDIA INTO, OR ONTO, THE BODY; DEVICES FOR TRANSDUCING BODY MEDIA OR FOR TAKING MEDIA FROM THE BODY; DEVICES FOR PRODUCING OR ENDING SLEEP OR STUPOR
  • A61M2205/00—General characteristics of the apparatus
  • A61M2205/60—General characteristics of the apparatus with identification means
  • A61M2205/6063—Optical identification systems
  • A61M2205/6072—Bar codes

Definitions

• APRs automated programming requests
• an infusion system includes an infusion control unit configured to receive a protocol-based automated programming request (pAPR).
• pAPR protocol-based automated programming request
• the pAPR includes a criterion for a therapy. Additionally, the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device. The pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion. In addition to receiving the pAPR, the infusion control unit is also configured to obtain the medical test result from the first electronic device based at least in part on the pAPR.
• a non-transitory, computer- readable medium includes instructions that, when executed by an infusion control unit, cause the infusion control unit to perform various functions.
• the functions include receiving a pAPR.
• the pAPR includes a criterion for a therapy.
• the pAPR instructs the infusion control unit to obtain a medical test result from a first electronic device.
• the pAPR also instructs the infusion control unit to cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion.
• pAPRs are defined at a server level.
• a server may receive an order to execute a protocol (e.g., an open-heart surgery) for a patient.
• the protocol may include gates, times, drug orders, vital sign readings, patient checks and corresponding confirmations, other electronic medical record (EMR) data, and the like.
• EMR electronic medical record
• the server can leverage one or more infusion control units (or patient care units) to present the protocol steps to a clinician. Further, the server can leverage the infusion control unit to track times, alert the clinician of steps, and so on. Additionally, or alternatively, the server can send protocol-related information to a portable electronic device of the clinician.
• An example clinician workflow implementing aspects of the pAPR technology disclosed herein might include: reviewing patient infusion orders at the start of the clinician’s shift, selecting a therapy “profile” for each patient, determining whether the therapy profiles deviate from standard profiles (e.g., to accommodate for patient needs), and sending the respective multi-step infusion therapies and associated pAPRs to the respective infusion control units. For the remainder of the clinician’s shift, all parts of each therapy for each patient would be available to the clinician (e.g., via the clinician’s portable electronic device, via a device terminal, or via the respective infusion control units). Moreover, if any of the infusion control units are interrupted, the clinician can pull up a list of the steps remaining for the respective pAPR and resume therapy accordingly.
• modules may be connected to the infusion pumps 130-133 or to the control unit 104 such as a syringe pump module, patient controlled analgesic module, end-tidal CO2 monitoring module, oximeter monitoring module, or the like.
• pressure measurements from upstream and/or downstream pressure sensors in the infusion pumps 130-133 are transmitted to a server or other coordination device, and the methods disclosed herein are implemented on the server or other coordination device.
• a server or other coordination device For example, more sophisticated and computationally intensive approaches like machine-learning can be implemented on the server (or on a PCU with a larger memory and/or CPU resources).
• machine learning is used to identify empty conditions based on pressure signals received from the pump.
• FIG. 2 depicts an example institutional patient care system 200 of a healthcare organization, according to various aspects of the subject technology.
• a patient care device 202 e.g., patient care device 102 of FIGS. 1 A-1B
• an internal healthcare network 236 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 ancillary medical devices such as an infusion pump (e.g., infusion pumps 130-133 of FIG.
• an infusion pump e.g., infusion pumps 130-133 of FIG.
• the internal healthcare network 236 also includes computer systems located in various departments throughout a hospital.
• the network 236 optionally includes computer systems associated with an admissions department, a billing department, a biomedical engineering department, a clinical laboratory, a central supply department, one or more unit station computers, and/or a medical decision support system.
• the internal healthcare network 236 may include discrete subnetworks.
• network 10 includes a device network 238 by which the patient care device 202 and other devices communicate in accordance with normal operations.
• patient care device 202 comprises a control unit 204 (e.g., control unit 104 of FIGS. 1A-1B), also referred to as interface unit 204, connected to one or more functional modules 206-209 (e.g., infusion pumps 130-133 of FIG. 1 A).
• Control unit 204 includes a central processing unit (CPU) 218 connected to a memory, for example, random access memory (RAM) 222, and one or more interface devices such as user interface device 230, a coded data input device 232, a network connection 220, and an auxiliary interface 226 for communicating with additional modules or devices.
• CPU central processing unit
• RAM random access memory
• interface devices such as user interface device 230, a coded data input device 232, a network connection 220, and an auxiliary interface 226 for communicating with additional modules or devices.
• Control unit 204 also, although not necessarily, includes a main non-volatile storage unit 228, such as a hard disk drive or non-volatile flash memory, for storing software data. Additionally, control unit 204 may include one or more internal buses 224 for interconnecting the aforementioned elements.
• main non-volatile storage unit 228, such as a hard disk drive or non-volatile flash memory for storing software data.
• control unit 204 may include one or more internal buses 224 for interconnecting the aforementioned elements.
• Data input device 232 may be a bar code reader capable of scanning and interpreting data printed in bar coded format. Additionally, or in the alternative, data input device 232 can be any device for entering coded data into a computer, such as a device(s) for reading magnetic strips, radio-frequency identification (RFID) devices whereby digital data encoded in RFID tags or smart labels (defined below) are captured by the data input device 232 via radio waves, PCMCIA smart cards, radio frequency cards, memory sticks, CDs, DVDs, or any other analog or digital storage media. Other examples of the data input device 232 include a voice activation or recognition device or a portable personal data assistant (PDA).
• PDA portable personal data assistant
• the user interface device 230 and the data input device 232 may be the same device.
• the data input device 232 is shown in FIG. 2 as being disposed within the control unit 204, it is recognized that the data input device 232 may be external to the control unit 204 (e.g., at the device terminal 240).
• Auxiliary interface 226 may be an RS-232 communications interface, however any other means for communicating with a peripheral device (e.g., a printer, a patient monitor, an infusion pump, or another medical device) may be used without departing from the subject technology.
• the data input device 232 may be a separate functional module (e.g., functional modules 206-207) configured to communicate with the control unit 204 or any other system on the network using suitable programming and communication protocols.
• Network connection 220 may be a wired or wireless connection, such as by Ethernet, WiFi, BLUETOOTH, an integrated services digital network (ISDN) connection, a digital subscriber line (DSL) modem or a cable modem. Any direct or indirect network connection may be used, including, but not limited to a telephone modem, an MIB system, an RS232 interface, an auxiliary interface, an optical link, an infrared link, a radio frequency link, a microwave link or a WLANS connection or other wireless connection.
• the functional modules 206-209 are devices (e.g., infusion pumps 130-133 of FIG. 1A) for providing care to a patient or for monitoring patient conditions. As shown in FIG.
• At least one of functional modules 206-209 may be an infusion pump module such as an intravenous infusion pump for delivering medication or other fluid to a patient.
• functional module 206 is an infusion pump module.
• Each of functional modules 206-209 may be any patient treatment or monitoring device including, but not limited to, an infusion pump, a syringe pump, a PCA pump, an epidural pump, an enteral pump, a blood pressure monitor, a pulse oximeter, an EKG monitor, an EEG monitor, a heart rate monitor, an intracranial pressure monitor, or the like.
• the functional modules 206-209 may be a printer, a scanner, a bar code reader, a near-field communication reader, an RFID reader, or any other peripheral input, output or input/output device.
• Each functional module 206-209 communicates directly or indirectly with control unit 204, providing overall monitoring and control of the patient care device 202. Additionally, the functional modules 206-209 may be connected physically and electronically in serial fashion to one or both ends of control unit 204 as shown in FIG. 2.
• Each of the functional modules 206-209 may include a microprocessor 216, a volatile memory 214, a nonvolatile memory 212, and module-specific components 210. It should be noted that while four functional modules are shown in FIG. 2, any number of devices may be connected directly or indirectly to the control unit 204. The number and type of functional modules described herein are intended to be illustrative, and they in no way limit the scope of the subject technology.
• the module-specific components 210 include any components necessary for operation of a particular module, such as a pumping mechanism for the functional module 206.
• the control unit 204 monitors and controls overall operation of the patient care device 202. For example, as will be described in more detail below, the control unit 204 provides programming instructions to the functional modules 206-209 and monitors the status of each of the functional modules 206-209.
• Medical devices incorporating aspects of the subject technology may be equipped with a network interface module (NIM), allowing the medical device to participate as a node in a network.
• NIM network interface module
• IP Internet Protocol
• Data to and from the various data sources can be converted into network-compatible data with existing technology, and movement of the information between the medical device and network can be accomplished by a variety of means.
• the patient care device 202 and the internal healthcare network 236 may communicate via automated interaction, manual interaction, or a combination of both automated and manual interaction.
• Automated interaction may be continuous or intermittent and may occur through direct network connection 220, as shown in FIG. 2, or through RS232 links, MIB systems, RF links such as BLUETOOTH, IR links, WLANS, digital cable systems, telephone modems, or other wired or wireless communication means.
• Manual interaction between the patient care device 202 and the internal healthcare network 236 involves physically transferring, intermittently or periodically, data between systems using, for example, the user interface device 230, the coded data input device 232, bar codes, computer disks, portable data assistants, memory cards, or any other media for storing data.
• the communication means in various aspects is bidirectional with access to data from as many points of the distributed data sources as possible. Decision-making can occur at a variety of places within the internal healthcare network 236. For example, and not by way of limitation, decisions can be made in the information system server 242, decision support, a remote data server, hospital department or unit stations, or within the patient care device 202 itself.
• the information system server 242 includes a formulary and/or pharmacy information system.
• Pharmacy information systems may enable a safer physician medication order process.
• a pharmacy website e.g., provided by the information system server 242 may provide the physician with a list of available drugs from which the physician may select.
• the pharmacy website may contain a drug library having the list of available drugs but may also contain and present to the physician the drug names associated with recommended dosages and dose limits that have been established or adopted by the healthcare facility.
• the physician need only select items from the computer screen rather than having to manually type in drug names and drug administration numbers (such as infusion rates, times, etc.) associated with administration of the medication, a more accurate medication process should result.
• a clinical order is for administration of a particular medication regimen, the order will be transmitted to the pharmacy’s system server (e.g., information system server 242).
• the pharmacy reviews the order, and once the order has been prepared, the order may be transmitted to the nurse station for matching with the appropriate patient.
• a formulary there may be indication for use information and/or concentrations and drug ranges approved for the facility.
• a formulary is an approved list of drugs for use (e.g., available to order for a patient) within a medical facility.
• a formulary may be used to define one or more medical device drug libraries, which may then be provided to infusion pumps within a hospital network (e.g., internal healthcare network 236).
• medication information such as drug names, concentration, diluent volume, strength, minimum or maximum infusion parameters for a drug, and other parameters.
• the establishment of these parameters, along with parameters for off- formulary orders, via the information pharmacy’s system server is useful for maintaining consistency across the healthcare environment and ensuring an order is intelligible and executed according to expectations by other devices (e.g., patient care device 202) within the pharmacy’s system server.
• the patient care device 202 is capable of operating in several different modes, or personalities, with each personality defined by a configuration database.
• the configuration database may be a database 226 internal to the patient care device 202, or an external database 244.
• a particular configuration database is selected based, at least in part, by patient-specific information such as patient location, age, physical characteristics, or medical characteristics.
• Medical characteristics include, but are not limited to, patient diagnosis, treatment prescription, medical history, medical records, patient care provider identification, physiological characteristics or psychological characteristics.
• patient-specific information also includes care provider information (e.g., physician identification) or the location of the patient care device 202 location in the hospital or hospital computer network.
• Patient care information may be entered through any of the network connection 220, the user interface device 230, the data input device 232, or the auxiliary interface 226. Additionally, patient care information may originate from anywhere in the internal healthcare network 236, such as from a pharmacy server, an admissions server, a laboratory, and the like.
• the memory of the control unit 204 may contain a drug library, an event log, and/or infusion pump configuration settings, such as profiles to be used in particular practice areas (e.g., ICU, PED, etc.).
• the control unit 204 memory may be electronically loadable memory such as non-volatile memory (e.g., EEPROM).
• Drug libraries stored on pumps which illustratively contain such information as the drug names, ranges of delivery parameter values such as proper concentrations, dosage units, and dose limits, can be used to perform drug-calculation-based infusions in a clinical setting.
• a drug library stored within the pump’s memory may include clinical order settings such as limits set by the clinical institution for each drug of the library (also termed as “guardrails” herein). Such limits may take the form of maximum and minimum dosages for each drug which may be made dependent on patient factors or other factors associated with delivery of the drug. For example, the dosage limits may vary depending on the weight of the patient or body surface area (“BSA”), depending on the unit or ward of the medical institution in which the drug is being used (for example neonatal care unit (NCU), the intensive care unit (ICU), etc.), and/or other factors.
• BSA body surface area
• An alarm may be provided if the nurse sets the pump to operate outside the range between the limits for a particular drug. In some cases, the alarm may be overridden and in other cases it may not.
• the medical facility may establish “soft” limits for each drug, which may be overridden by the nurse, and “hard” limits which may not.
• a pump data log or other processor in communication with the infusion pump may record each such limit event for later analysis where the attempted setting is higher than the maximum or lower than the minimum dosage.
• the pump also includes a display for displaying a user interface, including a control panel through which the user can program the programmable controller and a display screen for displaying drug entries from the drug library.
• Each of the associated sets of drug delivery parameters includes information selected from a group of parameters including drug concentration, drug delivery rate, drug dose, and bolus size.
• the electronically loaded drug library contains a list of available mode options specifying the units available for expressing drug delivery information, and the drug infusion pump offers the user the list of available mode options from which to make a selection when the electronically loaded drug library is in the pump.
• the electronically loaded drug library may include a list of names of syringe manufacturers identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of names of syringe manufacturers from which to make a selection when the electronically loaded drug library is in the pump.
• the loaded drug library may include a list of syringe sizes identifying syringes that can be used in the drug infusion pump, and the drug infusion pump offers the user the list of syringe sizes from which to make a selection when the electronically loaded drug library is in said pump.
• the electronically loaded drug library may include a list of infusion set manufacturers.
• a loaded drug library may include a set of features, each of which is either be toggled on or off, and the pump offers the user only the features from among the set of features that are toggled on when the electronically loaded drug library is in said pump.
• FIG. 3 depicts an example system 300 for automatically programming a medical device, according to various aspects of the subject technology.
• Interoperability between a hospital electronic medical records (EMR) server e.g., information system server 242 of FIG. 2
• medical devices e.g., patient care device 102 of FIGS. 1A-B, patient care device 202 of FIG. 2
• EMR electronic medical records
• Pre-population of infusion parameters may reduce the number of programming screens and key presses required with manually programming a pump.
• the implementation of interoperability does not preclude a clinician from manually programming the infusion device. Manual programming may be required in the event of a failure in any component of the interfaced system.
• features may be described with reference to an EMR server, the features are applicable to provide scan-less auto-programming of medical devices using similar hospital information systems such as pharmacy data management systems (PDMS).
• PDMS pharmacy data management systems
• the features may be described using an infusion pump as the example medical device, the features are applicable to provide scan-less auto-programming of other medical devices using barcodes for association such as patient monitors, patient association management systems, or alarms management systems.
• a drug formulary 304 determines which medications can be dispensed within a hospital network (e.g., internal healthcare network 236 of FIG. 2).
• a hospital committee may be formed to determine how medications within that formulary would be applied to an infusion device 310 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2).
• Configuration definitions e.g., by hospital unit such as ICU, NICU, Pediatrics, Oncology, Surgery, etc.
• the drugs and typical infusion protocols are established in a medical device drug library.
• limitation conditions are defined in the drug library.
• a configuration can then be released including the drug library.
• Infusion devices at the institution are then updated by transferring the configuration databases into some or all of their pumps.
• Corresponding updates to the drug formulary 304 may be shared with other hospital systems such as the pharmacy ordering system or an EMR system 302 which may use formulary information to generate a patient order to deliver a particular drug to a particular patient (see operation 320).
• a clinician may scan a medical item such as an infusate package using a scanner associated with a medical device, such as the infusion device 310.
• a bar code reader or other data input device is used to scan the coded drug label, the patient’s coded ID band and the caregiver’s ID badge, and optionally supplementary prescription information or medical device configuration instructions (including configuration database ID) printed on the label or an accompanying order.
• the reader/scanner is not required to be integrated with a medical device.
• the scanner may be part of a separate device such as an EMR terminal 306 (e.g., device terminal 240 of FIG. 2) connected to the same network (e.g., device network 238 of FIG. 2) as the infusion device 310 and configured with software to function in an overall workflow involving the infusion device 310.
• the scanning initiates a process by which information pertaining to the item (e.g., scanned from a code affixed to or transmitted by the item) is automatically sent to the hospital EMR system 302 via a network (e.g., internal healthcare network 236) (see operation 322).
• the EMR system 302 may confirm the item and generate (see operation 324) and send an automated programming request (APR) to the infusion device 310 to load parameters pertaining to the item.
• the parameters may be stored in the infusion device 310, but loaded in response to an identifier received from the server. While the examples herein involve an infusion device, any medical device may be configured in the same or similar manner and employ the automated programming error mitigation described herein.
• a coordination engine 308 coordinates messages sent from the EMR system 302 to the infusion device 310.
• the EMR system 302 transmits an APR (see operation 326) to the pump coordination engine 308 with a device identifier, also known as a “device ID,” of the infusion device 310 to receive the APR.
• the pump coordination engine 308 determines whether the infusion device 310 identified by the EMR system 302 is available and, if so, forwards the APR to the infusion device 310 (see operation 328).
• the infusion device 310 programs itself according to the parameters of the APR.
• the APR activates a drug library stored on the infusion device 310, and the infusion device 310 is programmed according to parameters stored in the drug library for medication identified in the APR.
• the infusion device may automatically initiate operation based on the parameters.
• the infusion device 310 may confirm the automatically entered parameters (see operation 330). The confirmation may include presenting one or more user interface screens including the parameters and values along with a control element (e.g., a button) that, when activated, causes the infusion device to begin operation based on the parameters.
• the user interface may include additional or alternative control elements to allow a clinician to adjust an automatically entered parameter based on, for example, professional judgement or changes in patient condition.
• FIGS. 4A and 4B depict example flow diagrams 400 and 450 for automatically programming one or more medical devices, according to various aspects of the subject technology.
• the various blocks of example flow diagrams 400 and 450 are described herein with reference to FIGS. 1 A-3, as well as the associated components and/or processes described herein.
• FIG. 4A depicts a first example flow diagram 400 for automatically programming one or more medical devices using an automated programming request (APR), according to various aspects of the subject technology.
• APR automated programming request
• an identifier of a patient and/or a medical device e.g., infusion device 310 of FIG. 3
• an EMR terminal 404 e.g., device terminal 240 of FIG. 2, or EMR terminal 306 of FIG. 3
• an identifier of the medical device may be scanned from a barcode affixed to the medical device in conjunction with parameters entered into the terminal for selecting and generating an APR (see operation 322 of FIG. 3).
• Entering the patient or medical device identifier initiates a process whereby information pertaining to the patient and/or the medical device is automatically sent to an EMR server 406 (e.g., information system server 242 of FIG. 2, or EMR system 302 of FIG. 3) of a hospital, and the EMR server 406 performs certain actions pertaining to the patient and/or the medical device and generates and sends an APR to the medical device to configure the medical device.
• an EMR server 406 e.g., information system server 242 of FIG. 2, or EMR system 302 of FIG.
• the subject technology provides a mechanism to automatically program a medical device without a scanner or manual translation of identifiers between the medical device and a terminal such as the EMR terminal 404.
• the scan-less device identification functionality of the subject technology enables a user to explicitly publish a message from a medical device to any data consumer (e.g., the EMR server 406) based on automated device identification propagation.
• the identifier is automatically sent to the consumer, which then correlates the identifier with other data to generate the APR and send the APR instructions back to the medical device.
• a hospital system implementing the subject technology may include one or more infusion devices 402 (e.g., patient care device 102 of FIGS. 1A-1B, patient care device 202 of FIG. 2, or infusion device 310 of FIG. 3).
• the infusion device(s) 402 may additionally or alternatively include other devices for carrying out a medical protocol, such as a syringe pump, or a smartphone or tablet computer (e.g., for monitoring the medical protocol). These devices may also be referred to as “protocol devices” or “therapy devices.”
• the hospital system may also include the EMR terminal 404 and the EMR server 406 connected to a connectivity gateway 408.
• the connectivity gateway 408 is part of or associated with a coordination engine (e.g., pump coordination engine 308 of FIG. 3).
• the connectivity gateway 408 is a separate system.
• the connectivity gateway 408 may include one or more computing devices such as servers apart from the EMR server 406.
• the connectivity gateway 408 may be implemented by or interchangeable with the pump coordination engine 308 of FIG. 3.
• the EMR server 406 and the connectivity gateway 408 may co-exist as a single server or group of servers.
• the information system server 242 of FIG. 2 may be representative of the EMR server 406 and/or the connectivity gateway 408.
• the infusion device(s) 402 includes a user interface element that, when activated, is configured to transmit, via a communication network (e.g., internal healthcare network 236 of FIG. 2), a message indicating that the infusion device is ready to receive automated programming.
• a communication network e.g., internal healthcare network 236 of FIG. 2
• the infusion device(s) 402 may display on its display screen (e.g., display 114 of FIG. IB) a virtual button as the interface element.
• the virtual button may be activated by touch activation in implementations where the display screen is a touch screen, or may be activated by selecting a corresponding control key (e.g., control keys 116A-C of FIG. IB).
• a clinician interacts with (e.g., authenticates at) the EMR terminal 404 (see operation 410).
• the EMR terminal 404 may then obtain the clinician’s identification by way of the clinician interaction.
• the clinician inputs additional identifiers, such as a care area identifier, a patient identifier, a drug identifier, or other identifying information for requesting an APR be sent to the infusion device(s) 402.
• the identifying information obtained via the terminal 404 is then transmitted to the EMR server 406 as a request to automatically program an infusion device (see operation 411).
• the request does not include an identification of the infusion device(s) 402 to be programmed. Accordingly, the infusion device to programmed may not yet be known by the system.
• the interface element is activated and the infusion device(s) 402 or a module connected thereto sends a message to the connectivity gateway 408 indicating that the infusion device(s) 402 is ready to receive automated programming.
• the message may include, for example, parameters such as an identifier of the infusion device(s) 402 (e.g., a serial number), an identifier of a clinician assigned to the infusion device 402 (e.g., an identifier of a clinician logged into the device), a care area of the device, a patient care unit identifier (e.g., if the device is part of a PCU device), and/or an identifier of a patient associated with the infusion device, and the like.
• parameters such as an identifier of the infusion device(s) 402 (e.g., a serial number), an identifier of a clinician assigned to the infusion device 402 (e.g., an identifier of a clinician logged into the device), a care area of the device, a patient care unit identifier (e.g., if the device is part of a PCU device), and/or an identifier of a patient associated with the infusion device, and the like.
• the interface element is activated after a determination is made (e.g., by the infusion device(s) 402, by a hospital information system) that the infusion device(s) 402 is in an operational state to be programmed for performing a therapy (e.g., administration of a medication to a patient).
• a therapy e.g., administration of a medication to a patient.
• the interface element is a virtual button displayed on a touchscreen (e.g., display 114 of FIG. IB).
• the interface element includes a control key (e.g., control keys 116A-C of FIG. IB) associated with the option of sending the message indicating that the device is ready to receive automated programming.
• each active channel on the infusion device(s) 402 may be associated with a virtual button and/or a control key, and the clinician may select the appropriate interface element to send the message on behalf of the channel.
• the connectivity gateway 408 informs the EMR server 406 that the infusion device(s) 402 is ready to receive automated programming via messaging (see operation 413).
• the EMR server 406 based on the request sent by the EMR terminal 404, searches for and identifies all active medical devices that have indicated they are ready to receive automated programming (see operation 414) and returns a list of the active and ready devices to the EMR terminal 404 (see operation 415). The clinician then finds the infusion device(s) 402 within the list and selects the infusion device(s) 402 for automated programming according to the previously entered request.
• the EMR terminal 404 sends the selected identification of the infusion device(s) 402 to the connectivity gateway 408 (see operation 416), and the connectivity gateway 408 associates the device identifier with the APR and sends the APR to the infusion device(s) 402 (see operation 417).
• the infusion device(s) 402 will start and begin to infuse a medication according to the programming provided by the APR. After the infusion has begun, the infusion device(s) 402 will send one or more status messages to the EMR server 406.
• a status message informs the EMR system what was started and includes certain values on which the infusion device(s) 402 is reporting. This information may reflect the APR data and/or may include changes made at the device.
• the EMR server 406 may wait for the status message and, upon receiving the message, close out the workflow pertaining to the APR.
• FIG. 4B depicts a second example flow diagram 450 for automatically programming one or more medical devices using an APR, according to various aspects of the subject technology.
• a request for APR originating at the EMR terminal 404 and the APR is associated with one or more infusion device(s) 402 at the connectivity gateway 408 automatically rather than at the EMR server 406 as shown in FIG. 4 A.
• the EMR terminal 404 may request auto-programming for a patient or a drug order for a patient, for example, without including a device identifier (see operation 460).
• the connectivity gateway 408 receives the request from the terminal 206 (see operation 461) in addition to separate indications that one or more infusion devices 402 are ready to receive an APR (see operation 462). In this regard, multiple available devices may be identified (425) by the connectivity gateway for execution of a given protocol.
• the connectivity gateway 408 Based at least in part on the received request and indication (see operations 461- 462), the connectivity gateway 408 automatically associates the infusion device(s) 402 and the EMR terminal 404 (see operation 463). This allows the previously unassociated APR request from the EMR terminal 404 to be routed to the infusion device(s) 402.
• the medical device(s) 402 may provide a clinician identifier, a care area identifier, and/or a patient identifier. Similarly, the clinician may enter the same information at the EMR terminal 404. If these data points correspond, then the connectivity gateway 408 may automatically provide the APR without further human interaction.
• the association may be based on therapies required by a given medical order and/or protocol.
• a protocol may be identified for a patient, and the system may then determine available medical devices for the protocol based on the patient identifier and/or protocol requirements or other information within the protocol.
• FIGS. 5A-5C depict example flow diagrams for automatically programming one or more medical devices according to a given medical protocol (e.g., a pAPR), according to various aspects of the subject technology.
• a given medical protocol e.g., a pAPR
• FIG. 5 A depicts a first example flow diagram 500 for automatically programming one or more medical devices using a protocolbased APR (pAPR), according to various aspects of the subject technology.
• pAPR protocolbased APR
• one or more infusion devices 502 are associated with a patient (see operation 520).
• the infusion device(s) 502 may be associated with a patient when a clinician enters an identifier of the patient into the infusion device(s) 502.
• the data pertaining to the association e.g., identifiers of the infusion device(s), the patient care unit, or the patient is sent to the connectivity gateway 508.
• a clinician interacts with a health information system (HIS) terminal 504 (e.g., an EMR terminal) (see operation 521) and selects a protocol via the HIS terminal 504 (see operation 522).
• HIS health information system
• the protocol may be a chemotherapy treatment or a multi-step infusion protocol.
• the protocol may correspond to a protocol-based automated programming request (pAPR) that includes instructions for instructing infusion device(s) 502 and/or other therapy devices for administering the protocol.
• pAPR protocol-based automated programming request
• Interaction with the HIS terminal 504 may occur before or after associating the infusion device(s) 502 with the patient (see operation 520).
• Selecting the protocol may cause the HIS terminal 504 to send information relevant to the protocol to an HIS server 506 (e.g., an EMR server).
• HIS server 506 e.g., an EMR server
• the HIS terminal 504 may send to the HIS server 506 a clinician identifier, a care area identifier, a patient identifier, a protocol identifier, and/or option indicators (e.g., indicating preference with regard to optional aspects of the protocol).
• the system can also present a second screen 812 that introduces additional information regarding the patients.
• the information may indicate whether a patient has an ongoing protocol, whether the protocol requires immediate or urgent attention, whether the protocol is complete or nearing completion, and so on.
• This information is suggested in the second screen 812 by the check mark (e.g., indicating completion) and the exclamation point (e.g., indicating urgency).
• the second screen 812 also includes addition signs for each of the patients, suggesting that the clinician can add a new protocol or add a new step to an ongoing protocol for the respective patient.
• Presentation of the second screen 812 may occur, for example, after the device at which the screen is displayed receives one or more protocols (e.g., pAPRs) for the respective patients. This is indicated by step 806, which relates to receiving the protocols. Additionally, step 808 describes adjusting the screen content to include the indicators regarding the received protocols - thus switching from displaying the first screen 810 to displaying the second screen 812.
• protocols e.g., pAPRs
• FIG. 9 is a conceptual diagram illustrating an example electronic system 900 for automatically programming one or more medical devices to operate according to a given medical protocol, according to various aspects of the subject technology.
• Electronic system 900 may be a computing device for execution of software associated with one or more portions or steps of the processes outlined in FIGS. 4A-6. Additionally, electronic system 900 may be a computing device including components provided by FIGS.
• electronic system 900 may be a specifically configured personal computer or a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or similar computer-related electronic device having network connectivity.
• a mobile device such as a smartphone, tablet computer, laptop, PDA, an augmented reality device, a wearable such as a watch or band or glasses, or combination thereof, or other touch screen or television with one or more processors embedded therein or coupled thereto, or similar computer-related electronic device having network connectivity.
• the electronic system 900 may include various types of computer readable media and interfaces for various other types of computer readable media.
• the electronic system 900 includes a bus 908, one or more processing unit(s) 912, a system memory 904, a read-only memory (ROM) 910, a permanent storage device 902, an input device interface 914, an output device interface 906, and one or more network interfaces 916.
• the electronic system 900 may include or be integrated with other computing devices or circuitry specifically configured for operation of the various components and methods previously described.
• the bus 908 collectively represents all system, peripheral, and chipset buses that communicatively connect the numerous internal devices of the electronic system 900. For instance, bus 908 communicatively connects processing unit(s) 912 with the ROM 910, the system memory 904, and the permanent storage device 902.
• the processing unit(s) 912 retrieves instructions to execute and data to process, in order to execute the processes of the subject disclosure.
• the processing unit(s) 912 can be a single processor or a multi-core processor in different implementations.
• the ROM 910 stores static data and instructions that are needed by processing unit(s) 912 and other modules of the electronic system.
• Permanent storage device 902 is a read-and-write memory device. This device is a non-volatile memory unit that stores instructions and data even when electronic system 900 is off. Some implementations of the subject disclosure use a mass-storage device (such as a magnetic or optical disk and its corresponding disk drive) as permanent storage device 902.
• the bus 908 connects to input and output device interfaces 914 and 906.
• Input device interface 914 enables the user to communicate information and select commands to the electronic system 900.
• Input devices used with input device interface 914 include, for example, alphanumeric keyboards and pointing devices (also called “cursor control devices”).
• Output device interfaces 906 enables, for example, display of images generated by the electronic system 900.
• Output devices used with output device interface 906 include, for example, printers and display devices, such as cathode ray tubes (CRT) or liquid crystal displays (LCD). Some implementations include devices such as a touchscreen that functions as both input and output devices.
• CTR cathode ray tubes
• LCD liquid crystal displays
• the bus 908 also couples the electronic system 900 to a network through the network interfaces 916.
• the network interfaces 916 may include, for example, a wireless access point (e.g., a Bluetooth or WiFi access point) or radio circuitry for connecting to a wireless access point.
• the network interfaces 916 may also include hardware (e.g., Ethernet hardware or a network interface module) for connecting the computer to a part of a network of computers such as a local area network (“LAN”), a wide area network (“WAN”), wireless LAN, or an Intranet, or a network of networks, such as the Internet.
• LAN local area network
• WAN wide area network
• wireless LAN wireless local area network
• Intranet or a network of networks, such as the Internet.
• Any or all components of the electronic system 900 can be specially configured to be used in conjunction with the subject disclosure.
• Some implementations include electronic components, such as microprocessors, storage and memory that store computer program instructions in a machine-readable or computer-readable medium (also referred to as computer-readable storage media, machine- readable media, or machine-readable storage media).
• computer- readable media include RAM, ROM, read-only compact discs (CD-ROM), recordable compact discs (CD-R), rewritable compact discs (CD-RW), read-only digital versatile discs (e.g., DVD- ROM, dual-layer DVD-ROM), a variety of recordable/rewritable DVDs (e.g., DVD-RAM, DVD-RW, DVD+RW, etc.), flash memory (e.g., SD cards, mini-SD cards, micro-SD cards, etc.), magnetic and/or solid state hard drives, read-only and recordable Blu-Ray® discs, ultra density optical discs, other optical or magnetic media, and floppy disks.
• CD-ROM compact discs
• CD-R recordable compact discs
• the computer-readable media can store a computer program that is executable by at least one processing unit and includes sets of instructions for performing various operations.
• Examples of computer programs or computer code include machine code, such as is produced by a compiler, and files including higher-level code that are executed by a computer, an electronic component, or a microprocessor using an interpreter.
• ASICs application specific integrated circuits
• FPGAs field- programmable gate arrays
• the terms “computer,” “server,” “processor,” and “memory” all refer to electronic or other technological devices specifically configured with one or more of the features described above. These terms exclude people or groups of people.
• display or displaying means displaying on an electronic device.
• computer readable medium and “computer readable media” are entirely restricted to tangible, physical objects that store information in a form that is readable by a computer. These terms exclude any wireless signals, wired download signals, and any other ephemeral signals.
• implementations of the subject matter described in this specification can be implemented on a computer having a display device, e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, for displaying information to the user and a keyboard and a pointing device, e.g., a mouse or a trackball, by which the user can provide input to the computer.
• a display device e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor
• keyboard and a pointing device e.g., a mouse or a trackball
• Other kinds of devices can be used to provide for interaction with a user as well.
• feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, tactile feedback), and input from the user can be received in forms such as acoustic, speech, gesture, or tactile input.
• a computer can interact with a user by sending documents to and receiving documents from a device that is used by the
• Implementations of the subject matter described in this specification can be implemented in a specifically configured computing system that includes a back end component (e.g., a data server), or that includes a specifically configured middleware component (e.g., an application server), or that includes a specifically configured front end component (e.g., a client computer having a graphical user interface or a Web browser through which a user can interact with an implementation of the subject matter described in this specification), or any combination of one or more such back end, middleware, or front end components.
• the components of the system can be interconnected by one or more forms or mediums of digital data communication, such as a communication network. Examples of communication networks include a LAN and a WAN, an inter-network (e.g., the Internet), and peer-to-peer networks (e.g., ad hoc peer-to-peer networks).
• the computing system can include specifically configured clients and servers.
• a client and server are generally remote from each other and may interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
• a server transmits data (e.g., an HTML page) to a client device (e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device).
• client device e.g., for purposes of displaying data to and receiving user input from a user interacting with the client device.
• Data generated at the client device e.g., a result of the user interaction
• Clause 7 The infusion system of any one of clauses 5 or 6, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.
• Clause 9 The infusion system of any one of clauses 1 through 8, wherein the infusion control unit is further configured to: provide a list of workflow protocols for display on a display device associated with the infusion control unit; receive a patient identifier and a selected workflow protocol from the list; identify, based on the received patient identifier, the first therapy device and one or more second therapy devices; and send the pAPR to the first therapy device and the one or more second therapy devices responsive to identifying the first therapy device and the one or more second therapy devices based on the received patient identifier, wherein the pAPR provides the selected workflow protocol to the first therapy device and the one or more second therapy devices.
• the infusion control unit is further configured to: receive two or more selected patients from the list; and provide, for each respective patient of the two or more selected patients, a second graphically displayed control for activating the pAPR for the respective patient, wherein selection of the second graphically displayed control initiates a display of a protocol definition interface for configuring one or more parameters of the pAPR including setting the criterion for the therapy.
• the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
• Clause 16 The non-transitory, computer-readable medium of any one of clauses 14 or 15, wherein the secondary amount or the secondary IV fluid is selected based on the medical test result obtained from the first electronic device.
• Clause 17 The non-transitory, computer-readable medium of any one of clauses 12 through 17, further comprising a display device, wherein performing the secondary operation comprises displaying a notice requiring completion of an action, receiving an indication that the action was completed, and performing the primary operation responsive to receiving the indication.
• a computer-implemented method for handling a pAPR comprising: receiving, at an infusion control unit, a pAPR that includes a criterion for a therapy and that instructs the infusion control unit to (1) obtain a medical test result from a first electronic device and (2a) cause a first therapy device to perform a primary operation associated with the therapy if the medical test result satisfies the criterion or (2b) cause the first therapy device to perform a secondary operation associated with the therapy if the medical test result does not satisfy the criterion; obtaining, at the infusion control unit, the medical test result from the first electronic device based at least in part on the pAPR; selecting, at the infusion control unit, the primary operation responsive to determining that the medical test result satisfies the criterion, or select the secondary operation responsive to determining that the medical test result does not satisfy the criterion; and performing, at the infusion control unit, the selected operation based at least in part on the
• Clause 20 The computer-implemented method of any one of clauses 18 or 19, wherein the first therapy device comprises a first infusion pump and performing the primary operation comprises activating the first infusion pump to administer a primary amount of a primary IV fluid, wherein performing the secondary operation comprises activating the first infusion pump to provide a secondary amount of the primary IV fluid different from the primary amount of the primary IV fluid.
• a processor configured to monitor and control an operation or a component may also mean the processor being programmed to monitor and control the operation or the processor being operable to monitor and control the operation.
• a processor configured to execute code can be construed as a processor programmed to execute code or operable to execute code.
• the term “automatic,” as used herein, may include performance by a computer or machine without user intervention, for example, by instructions responsive to a predicate action by the computer or machine or other initiation mechanism.
• the word “example” is used herein to mean “serving as an example or illustration.” Any aspect or design described herein as “example” is not necessarily to be construed as preferred or advantageous over other aspects or designs.
• a phrase such as an “aspect” does not imply that such aspect is essential to the subject technology or that such aspect applies to all configurations of the subject technology.
• a disclosure relating to an aspect may apply to all configurations, or one or more configurations.
• An aspect may provide one or more examples.
• a phrase such as an aspect may refer to one or more aspects and vice versa.
• a phrase such as an “implementation” does not imply that such implementation is essential to the subject technology or that such implementation applies to all configurations of the subject technology.
• a disclosure relating to an implementation may apply to all implementations, or one or more implementations.
• An implementation may provide one or more examples.
• a phrase such as an “implementation” may refer to one or more implementations and vice versa.
• a phrase such as a “configuration” does not imply that such configuration is essential to the subject technology or that such configuration applies to all configurations of the subject technology.
• a disclosure relating to a configuration may apply to all configurations, or one or more configurations.
• a configuration may provide one or more examples.
• a phrase such as a “configuration” may refer to one or more configurations and vice versa.
• a “user interface” (also referred to as an interactive user interface, a graphical user interface, or a UI) may refer to a network-based interface including data fields or other control elements for receiving input signals or providing electronic information or for providing information to the user in response to any received input signals.
• Control elements may include dials, buttons, icons, selectable areas, or other perceivable indicia presented via the UI that, when interacted with (e.g., clicked, touched, selected, etc.), initiates an exchange of data for the device presenting the UI.
• a UI may be implemented in whole or in part using technologies such as hyper-text mark-up language (HTML), FLASHTM, JAVATM, .NETTM, C, C++, web services, or rich site summary (RSS).
• HTTP hyper-text mark-up language
• FLASHTM FLASHTM
• JAVATM JAVATM
• .NETTM C, C++
• web services or rich site summary (RSS).
• a UI may be included in a stand-alone client (for example, thick client, fat client) configured to communicate (e.g., send or receive data) in accordance with one or more of the aspects described.
• the communication may be to or from a medical device or server in communication therewith.
• determining may include calculating, computing, processing, deriving, generating, obtaining, looking up (e.g., looking up in a table, a database, or another data structure), ascertaining and the like via a hardware element without user intervention.
• determining may include receiving (e.g., receiving information), accessing (e.g., accessing data in a memory) and the like via a hardware element without user intervention.
• Determining may include resolving, selecting, choosing, establishing, and the like via a hardware element without user intervention.
• the terms “provide” or “providing” encompass a wide variety of actions.
• “providing” may include storing a value in a location of a storage device for subsequent retrieval, transmitting a value directly to the recipient via at least one wired or wireless communication medium, transmitting or storing a reference to a value, and the like.
• “Providing” may also include encoding, decoding, encrypting, decrypting, validating, verifying, and the like via a hardware element.
• a message encompasses a wide variety of formats for communicating (e.g., transmitting or receiving) information.
• a message may include a machine-readable aggregation of information such as an XML document, fixed field message, comma separated message, JSON, a custom mode, or the like.
• a message may, in some implementations, include a signal utilized to transmit one or more representations of the information. While recited in the singular, it will be understood that a message may be composed, transmitted, stored, received, etc. in multiple parts.
• a “selective” process may include determining one option from multiple options.
• a “selective” process may include one or more of: dynamically determined inputs, preconfigured inputs, or user-initiated inputs for making the determination.
• an n-input switch may be included to provide selective functionality where n is the number of inputs used to make the selection.
• correspond encompasses a structural, functional, quantitative and/or qualitative correlation or relationship between two or more objects, data sets, information and/or the like, preferably where the correspondence or relationship may be used to translate one or more of the two or more objects, data sets, information and/or the like so to appear to be the same or equal. Correspondence may be assessed using one or more of a threshold, a value range, fu5y logic, pattern matching, a machine learning assessment model, or combinations thereof.
• data generated or detected can be forwarded to a “remote” device or location, where “remote,” means a location or device other than the location or device at which the program is executed.
• a remote location could be another location (e.g., office, lab, etc.) in the same city, another location in a different city, another location in a different state, another location in a different country, etc.
• office, lab, etc. e.g., office, lab, etc.
• the two items can be in the same room but separated, or at least in different rooms or different buildings, and can be at least one mile, ten miles, or at least one hundred miles apart.
• “Communicating” information references transmitting the data representing that information as electrical signals over a suitable communication channel (e.g., a private or public network).
• a suitable communication channel e.g., a private or public network.
• “Forwarding” an item refers to any means of getting that item from one location to the next, whether by physically transporting that item or otherwise (where that is possible) and includes, at least in the case of data, physically transporting a medium carrying the data or communicating the data. Examples of communicating media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the internet or including email transmissions and information recorded on websites and the like.

Landscapes

• Health & Medical Sciences (AREA)
• Engineering & Computer Science (AREA)
• Biomedical Technology (AREA)
• General Health & Medical Sciences (AREA)
• Public Health (AREA)
• Primary Health Care (AREA)
• Medical Informatics (AREA)
• Epidemiology (AREA)
• Life Sciences & Earth Sciences (AREA)
• Hematology (AREA)
• Vascular Medicine (AREA)
• Anesthesiology (AREA)
• Veterinary Medicine (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Animal Behavior & Ethology (AREA)
• Heart & Thoracic Surgery (AREA)
• Diabetes (AREA)
• Chemical & Material Sciences (AREA)
• Bioinformatics & Cheminformatics (AREA)
• Medicinal Chemistry (AREA)
• Infusion, Injection, And Reservoir Apparatuses (AREA)

Applications Claiming Priority (1)

Publications (1)

Family

ID=86142720

Family Applications (1)

Country Status (3)

Family Cites Families (2)

• 2023
  • 2023-03-28 WO PCT/US2023/016626 patent/WO2024205577A1/en not_active Ceased
  • 2023-03-28 CN CN202380096361.8A patent/CN120898250A/zh active Pending
  • 2023-03-28 EP EP23719151.5A patent/EP4690223A1/de active Pending

Also Published As

Similar Documents

Legal Events