DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-18 are rejected under 35 U.S.C. 103 as being unpatentable over Wehba et al. (US 2007/0233050A1; hereinafter “D1”) in view of Mills et al. (US 2015/0379237A1; hereinafter “D2”).
In relation to claim 1, claim 1 recites: an infusion pump including a processor, memory operably coupled to the processor, and control logic comprising instructions that, when executed, cause the processor to:
receive programming parameters corresponding to an infusion order from a Hospital
Information System (HIS), the programming parameters having been verified by the
HIS;
determine if the received programming parameters match a drug library protocol in a
drug library of the infusion pump;
when the programming parameters do not match any drug library protocol in the
drug library, queue a no-match error code;
populate a manual mode with the received programming parameters; and
operate the infusion pump in the manual mode using the populated programming
parameters.
Element-by-Element Analysis
Element 1: Infusion pump with processor, memory, and control logic.
D1 discloses an infusion pump system with the required hardware components. Paragraph [0075] states that "the infusion settings or delivery parameters and other information from the MMU 3108 is entered into the memory of the infusion pump 3130," confirming that the pump has memory. Paragraph [0076] describes the pump executing programmed settings, which inherently requires a processor and control logic to manage the infusion delivery.
Element 2: Receive programming parameters from HIS that have been verified.
D1 explicitly discloses this element. Paragraph [0010] states:
The MMU receives medication order and delivery information from an information system directly through an electronic network or indirectly through a wireless handheld point of care (POC) input (scanning) device.
Paragraph [0063] describes how "the patient's doctor 3120, 3220 prescribes medical treatment by entering an order into the CPOE computer terminal or module 3120, 3220 within the HIS system 3110, 3210." Paragraph [0064] further explains that "the pharmacist 3122, 3222 screens the prescribed order, translates it into an order for dispensing medication, and prepares the medication," thereby verifying the parameters through the pharmacy information system (PIS), which is part of the HIS.
Element 3: Determine if received parameters match a drug library protocol.
D1 discloses this element in paragraph [0163]:
...the pump 3130, 3230 checks the entered program settings against the permissible settings specified in the drug library of the pump 3130, 3230 and alerts the nurse of any impermissible settings.
Additionally, paragraph [0011] states that the MMU "checks the delivery order and delivery programming code against a variety of drug library parameters (including but not limited to hard and/or soft limits for drug delivery rates, dose, volume, duration, route and site of administration)."
Element 4: Queue a no-match error code when parameters do not match.
D1 partially discloses this element. Paragraph [0163] teaches that the pump "alerts the nurse of any impermissible settings" when there is a mismatch. Paragraph [0077] states:
If the pump information does not match the order, the PDA 3126 gives a visual, audio or
other type of negative signal, which may include an error message.
However, D1 does not explicitly teach queuing a specific "no-match error code" for the case when parameters do not match any drug library protocol. D2 provides additional teaching on this point. The abstract of D2 states:
When the pump detects an error in the auto-programming request, the pump may generate and display an error message that specifically identifies the cause of the error.
Paragraph [0002] of D2 further explains that "these error codes often do not specifically describe the error to the caregiver at the pump so that the caregiver may immediately respond to the error," and the invention addresses this by displaying detailed error messages directly at the pump.
Element 5: Populate a manual mode with the received programming parameters.
This element is not explicitly disclosed in either D1 or D2. However, D1 provides strong suggestions for this feature. Paragraph [0071] states:
Any data that is not required from the above listing can be left out of the request, then
the MMU 3108 will transmit the incomplete order to the infusion pump 3130 and the
caregiver 3132 can complete or modify the order at the infusion pump 3130, if desired.
More significantly, paragraph [0075] teaches:
The infusion settings or delivery parameters and other information from the MMU 3108 is
entered into the memory of the infusion pump 3130 and the infusion pump 3130 settings
can automatically populate the programming screen(s) of the infuser, just as if the
caregiver 3132 had entered the information and settings manually.
This teaching shows that D1 contemplates automatically populating pump settings with HIS-verified parameters in a manner equivalent to manual entry. While D1 does not explicitly describe this as a "manual mode" that is triggered specifically upon a drug library mismatch, the concept of auto-populating parameters for manual confirmation is clearly disclosed.
Element 6: Operate the pump in manual mode using the populated parameters.
D1 discloses operating the pump with programmed settings after caregiver confirmation.
Paragraph [0076] states:
When the caregiver 3132 presses the button to confirm, the infusion pump 3130 will begin
delivering fluid according to the programmed settings.
Paragraph [0163] similarly describes that "the nurse 3132, 3232 is presented with a start button on the screen 88 to start the infusion in accordance with the final check and confirmed programmed pump settings."
Based on the above comments, a person of ordinary skill in the art, faced with the problem of handling a drug library mismatch in the system of D1, would have been motivated to combine the teachings of D1 and D2 for several reasons. First, D2 provides a solution for improving error feedback to the user by generating specific error messages that identify the cause of the mismatch. This directly addresses a workflow inefficiency in D1, where error handling could be improved. Second, D1 itself teaches the goal of maximizing patient safety and caregiver productivity (paragraph [0004]) and states that "the MMU and/or the POC system saves the caregiver time by automatically populating or programming data entry fields in the pump that previously had to be entered manually" (paragraph [0012]). Given that the programming parameters from the HIS have already been verified by the pharmacy (paragraph [0064]), it would be an obvious design choice to automatically populate these verified parameters for manual confirmation when a drug library match cannot be found, rather than requiring the nurse to re-enter them from scratch. This approach would reduce manual entry errors,
improve efficiency, and maintain patient safety—all stated objectives of D1. The concept of a "manual mode" is simply a logical implementation of D1's teaching that settings can be populated "just as if the caregiver had entered the information and settings manually" (paragraph [0075]). When a drug library match fails, automatically populating a manual mode with the HIS-verified parameters is an obvious next step that streamlines the workflow while preserving the safety checks inherent in manual confirmation.
In relation to claim 2, claim 2 adds the limitation: "output the queued no-match error code to the HIS when the manual mode infusion fails." D1 discloses bidirectional communication between the pump and the HIS/MMU system. Paragraph [0163] states that "the pump 3130, 3230 continuously sends status information (i.e., current settings and state) and event logs (i.e., historical activity, alarms, alerts,
overrides, etc.) to the MMU 3108, 3208." Paragraph [0078] describes that "the nurse electronically signs the record and presses a send button to send the information to the patient's electronic medication administration record (electronic MAR or EMAR)." Accordingly, it would have been obvious to a person of ordinary skill in the art to transmit the specific "no-match error code" back to the HIS, particularly upon failure of the infusion, for purposes of logging, troubleshooting, and maintaining a complete electronic health record. This is standard practice in modern networked medical device systems, where
comprehensive event logging is essential for quality assurance, regulatory compliance, and patient safety monitoring.
In relation to claim 3, claim 3 adds the limitations: "prompt a user with the manual mode operation option; and receive an acceptance of the manual mode operation option prior to populating the received programming parameters."
D1 discloses user confirmation at multiple points in the workflow. Paragraph [0076] states:
The infusion pump 3130 then prompts the caregiver 3132 to start the infusion pump 3130
by pressing the start button. When the caregiver 3132 presses the start button, a
confirmation screen with the infusion settings programmed is presented to them for
confirmation.
Paragraph [0163] similarly describes that the nurse confirms the programmed pump settings before starting the infusion. Prompting the user for acceptance before proceeding with a non-standard workflow, such as a manual mode operation that bypasses the drug library matching requirement, is a fundamental and obvious safety measure. It would be obvious to implement such a prompt to ensure user awareness and explicit confirmation before populating and operating in manual mode.
In relation to claim 4, claim 4 adds the limitation: "determine that an auto programming override is allowed prior to prompting the user with the manual mode operation option." D1 discloses that "the nurse 3132, 3232 can then adjust the pump program settings in an optional step 4026 or override the alert in the case of soft limit violations" (paragraph [0163]). The concept of determining whether an override is allowed is an inherent and obvious prerequisite to presenting the user with an override option. A properly designed system would necessarily check its configuration settings to determine if overrides are permitted before offering such an option to the user. This is a standard safety feature in medical device software design.
In relation to claim 5, claim 5 adds the limitation: "populating the manual mode with the received programming parameters includes entering the received programming parameters without creating a populated or partially populated drug library entry." D1 discloses that "the caregiver 3132 can complete or modify the order at the infusion pump 3130, if desired" (paragraph [0071]). The very definition of a "manual mode" implies operation outside the strict, pre-defined protocols of the drug library. The drug library is typically a curated and controlled database maintained by the pharmacy. Accordingly, it would be an obvious implementation choice to populate parameters in a manual mode without creating a new, permanent entry in the official drug library, as this prevents the library from being cluttered with ad-hoc, non-standard entries that have not undergone the formal review and approval process.
In relation to claim 6, claim 6 adds the limitation: "filter through the drug library of the infusion pump, wherein the no-match error code is based on the filtering and is at least one of a drug not entered in the drug library, a required programming parameter missing, or a dose unit or rate unit
does not match the drug library." D1 discloses checking the order against drug library parameters in paragraph [0011]. The specific reasons for a no-match listed in claim 6 (drug not in library, missing parameter, unit mismatch) are all common and predictable failure modes for any system that matches
order parameters against a library. D1 teaches checking for completeness and proper formatting in paragraph [0070]:
Upon receipt of a program pump request from the PDA 3126, the MMU 3108 validates the
request by making sure that all infuser-required information has been provided and that
any information provided, whether required or optional, is complete, within expected
ranges and correctly formatted.
D2 further teaches that the error message should "specifically identify the cause of the error" (Abstract). Therefore, filtering the drug library and generating a specific error code based on the type of mismatch (drug not found, parameter missing, unit mismatch) is an obvious implementation of the error-handling and validation features taught by D1 and D2.
In relation to claim 7, claim 7 adds the limitation: "verify a hardware limit, a supported unit, and a delivery mode of the manual mode are compatible with the infusion pump prior to operating the infusion pump in the manual mode."
D1 discloses multiple levels of validation and safety checking. Paragraph [0070] teaches that the MMU "validates the request by making sure that all infuser-required information has been provided and that any information provided, whether required or optional, is complete, within expected ranges and correctly formatted." Paragraph [0163] states that "the pump 3130, 3230 checks the entered program settings against the permissible settings specified in the drug library of the pump 3130, 3230."
Verifying fundamental hardware limits, supported units, and delivery modes are all standard, necessary, and obvious safety checks that a person of ordinary skill in the art would implement before operating any medical device. These checks are particularly important when operating in a manual or override mode, as they ensure that the pump's physical capabilities and safety constraints are not exceeded even when operating outside the drug library protocols.
In relation to claim 8, claim 8 adds the limitation: "transmit manual mode information to the HIS." D1 discloses comprehensive bidirectional communication between the pump and the HIS/MMU system. Paragraph [0163] states that "the pump 3130, 3230 continuously sends status information (i.e., current settings and state) and event logs (i.e., historical activity, alarms, alerts, overrides, etc.) to the MMU 3108, 3208." Paragraph [0078] describes sending information to the electronic medication administration record (EMAR). Transmitting information about manual mode operation back to the HIS is an obvious and essential feature for any modern, networked infusion pump. This ensures that the patient's medical record is complete and accurate, reflecting the actual parameters of the infusion as administered. Such documentation is critical for clinical decision-making, billing, regulatory compliance, and legal protection.
In relation to claims 9 and 10-16, claim 9 is a method claim that recites steps corresponding to the functions performed by the apparatus of Claim 1. Claims 10-16 are method claims corresponding to the apparatus of Claims 2-8. The method of performing the functions of an apparatus is obvious when the apparatus itself is obvious. The analysis provided above for Claims 1-8 applies equally to the corresponding method claims 9-16. D1 and D2 disclose not only the structural elements of the infusion pump system but also the processes and workflows by which the system operates. The method steps recited in Claims 9-16 are the natural and obvious implementation of the apparatus and system disclosed in D1 and D2. Specifically, D1 describes the complete workflow from receiving an order from the HIS, through drug library checking, to pump operation and status reporting. The flowcharts in
FIGS. 8A, 8B, 9A, and 9B of D1 explicitly illustrate these method steps. For example, paragraph [0163] describes a multi-step process involving adjusting program settings, checking against the drug library, alerting the nurse, and confirming settings before starting the infusion.
In relation to claims 17 and 18, claim 17 is drafted in means-plus-function format under 35 U.S.C. § 112(f), reciting "means for" performing various functions. Claim 18 depends from claim 17 and adds an additional "means for" limitation.
D1 discloses a processor-based system with multiple processors distributed across the
MMU, POC computer, and the infusion pump itself. These processors perform the core functions recited in Claims 17 and 18, including receiving parameters (paragraph [0069], [0070]), comparing them to a drug library (paragraph [0011], [0071], [0163]), and operating the pump (paragraph [0076]). D2 discloses a processor-based system for generating specific error messages when a mismatch with the drug library occurs (Abstract, paragraph [0005]). The combination of the processor-controlled system of D1 with the error-handling logic of D2 renders the structure for performing the functions of Claims 17 and 18 obvious. The claimed "means" are simply general-purpose processors and memory configured to perform the functions which have already been shown to be obvious for the reasons detailed in the rejections of Claims 1-8.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANUEL A MENDEZ whose telephone number is (571)272-4962. The examiner can normally be reached Mon-Fri 7:00 AM-5:00 PM.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Bhisma Mehta can be reached at 571-272-3383. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Respectfully submitted,
/MANUEL A MENDEZ/ Primary Examiner, Art Unit 3783