WO2019036747A1

WO2019036747A1 - Patient fluid balance monitoring system and method

Info

Publication number: WO2019036747A1
Application number: PCT/AU2018/000148
Authority: WO
Inventors: Qianping LUO
Original assignee: Butterfly Healthcare Pty. Ltd.
Priority date: 2017-08-25
Filing date: 2018-08-24
Publication date: 2019-02-28

Abstract

A system comprising an IV pump, a wireless network, and a computing device, the computing device configured to: receive, via the wireless network, a fluid prescription for a patient; transmit, via the wireless network, fluid administration instructions to an IV pump associated with the patient, the fluid administration instructions based on the received fluid prescription; receive, from the IV pump via the wireless network, real-time information regarding fluid delivery to the patient; receive, via the wireless network, fluid measurements relating to the patient; and determine a fluid balance of the patient based on the received measurements and the real-time information.

Description

PATIENT FLUID BALANCE MONITORING SYSTEM AND METHOD

Reference to related applications

This application claims Convention priority from Australian Patent Application No. 2017903441 , filed 25 August 2017, the contents of which are incorporated by reference in their entirety.

Technical Field

The present invention relates generally to patient fluid balance monitoring and, in particular, to a system and method of monitoring fluid balance levels of a patient pre- and post-surgery.

Background

Hospitals and healthcare facilities operate in a generally complex manner using complex systems, and face significant challenges in relation to ensuring a high quality level of patient care. Healthcare facilities are typically rapidly-changing environments, and suffer inefficiencies due to poor integration of different processes and systems across departments as well as poor maintenance of information. In addition to the lack of integration between different departments, a large number of variables are constantly changing, such as the location of patients, changes in medical status of patients, availability of resources and medications and the like.

Patient fluid balance levels pre- and post-surgery are very relevant to patient recovery, suitability to undergo surgery, or suitability for discharge. In particular, ensuring patient fluid balance levels, such as hydration and electrolyte level, post-surgery represents a considerable challenge in terms of the quality of service provided to patients.

For example, a single hospital may have more than 500 different types of IV fluids available, each having a range of treatment or delivery levels. The correct fluid must be acquired from the hospital pharmacy and administered to the correct patient at the correct delivery rates. Further, changes of overall patient fluid balance need be monitored accurately. However, many methods currently used for monitoring patient fluid balance levels detect variations sometime after occurrence, often affecting quality of care of the patient.

While some hospitals have digitalised some processes, this is largely segmented into different groups and different departments sitting in isolation from each other. Patients are typically moved and assigned to different departments several times between admission and discharge. As a result, inefficiencies exist within the existing processes and systems relating to patient care, such as monitoring of fluid balance levels. Indeed, hospitals and similar healthcare facilities often face significant logistical challenges in monitoring a patient's location so that required treatment can be identified and administered in a timely manner.

The lack of integration of processes and systems between departments and the difficulties that arise in determining changes in patient status such as fluid balance levels can be hazardous to patient wellbeing and place patient recovery in jeopardy.

Summary

It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements.

The arrangements described relate to a system for real-time monitoring of a patient's fluid balance level. The system or method is for monitoring patients' fluid balance levels in real time and for allowing the assessment of patients fluid balance status, which may be pertinent when reviewing intravenous fluid prescriptions or making an assessment of early clinical deterioration. Further, the system or method may be used to determine the location of the patient based on a determination of the user of a device being used to enter fluid balance data or the device itself, and the determined location based on that user and/or device.

According to a first aspect of the present disclosure, there is provided a system comprising: an IV pump, a wireless network, and a computing device, the computing device configured to: receive, via the wireless network, a fluid prescription for a patient; transmit, via the wireless network, fluid administration instructions to an IV pump associated with the patient, the fluid administration instructions based on the received fluid prescription; receive, from the IV pump via the wireless network, real-time information regarding fluid delivery to the patient; receive, via the wireless network, fluid measurements relating to the patient; and determine a fluid balance of the patient based on the received measurements and the real-time information.

According to a second aspect of the present disclosure, there is provided a computer- implemented method of monitoring patient fluid balance levels, the method comprising: receiving, via a wireless network, a fluid prescription for a patient; transmitting, via the wireless network, fluid administration instructions to an IV pump associated with the patient, the fluid administration instructions on the received fluid prescription; receiving, from the IV pump via the wireless network, real-time information regarding patient fluid delivery; receiving, via the wireless network, fluid measurements relating to the patient; and determining a fluid balance of the patient based on the received measurements and the real-time information.

Other aspects are also disclosed.

Brief Description of the Drawings

At least one example embodiment of the present invention will now be described with reference to the drawings, in which:

Fig. 1 A shows a system for monitoring fluid balance levels of a patient;

Figs. l B and 1 C collectively form a schematic block diagram representation of an electronic device upon which described arrangements can be practised;

Fig. 2 shows a typical series of steps between admission and discharge of a patient having surgery;

Fig. 3 shows an example of an existing form for determining a patient's fluid balance level;

Fig. 4 shows a method of determining a fluid balance of a patient in real-time;

Fig 5 shows a method of determining whether an alarm is required in relation to a patient's fluid balance level;

Fig. 6 shows a method of determining a location of a patient in a healthcare facility;

Fig. 7 shows an example screenshot of how the fluid intake of a patient may be entered into a device; and

Fig. 8 shows an example screenshot of a fluid balance display for a patient.

Detailed Description including Best Mode

Where reference is made in any one or more of the accompanying drawings to steps and/or features, which have the same reference numerals, those steps and/or features have for the purposes of this description the same function(s) or operation(s), unless the contrary intention appears. It is to be noted that the discussions contained in the "Background" section and that above relating to prior art arrangements relate to discussions of documents or devices which form public knowledge through their respective publication and/or use. Such should not be interpreted as a representation by the present inventor(s) or the patent applicant that such documents or devices in any way form part of the common general knowledge in the art.

As discussed above, healthcare facilities such as hospitals typically have inefficiencies in the processes and systems that are used relating to maintaining patient information and providing care. In particular, inefficiencies exist relating to determination of a patient's fluid (hydration) levels both before and after surgery. Failure to identify changes in a patient's fluid balance in a timely manner can significantly endanger a patient's wellbeing and recovery. For example, a procedure may be started when the patient is not ready for the procedure, incorrect treatment may be given, or patients may be discharged too early.

Some hospitals have started digitalising processes. However, inefficiencies still often exist as digitalisation typically relates to a given department or single procedure and so the digitalised information may not be available to other departments at all, or for certain procedures.

Fig. 2 shows an example of a typical series 200 of steps involved in a patient's surgery indicating the variety of different hospital departments involved. The series 200 starts at a surgery booking step 210. The booking typically originates from a particular doctor's surgery (for example a doctor from a neurology department), and involves entry of patient details (for example a patient identifier, gender height, weight, medical history and the like) and the required surgical procedure. The patient details and required surgical procedure are typically received by a surgery booking department and assigned a surgical venue, time and staff. The surgery booking department typically orders surgeries based on factors such as urgency, availability of resources and the like.

Once a surgical procedure has been booked, the patient is received at or moved to a preoperative preparation step 220. A "pre-ops" team prepares the patient for surgery, for example by taking measurements, running tests and performing preparative procedures. Typical hospital departments involved at step 220 include radiology, pathology, anaesthesiology, operating theatres, recovery wards and the like.

The series 200 then continues to an inter-operative step 230, in which surgery is performed on the patient in an operating theatre. Departments involved at step 230 may include one or more surgery departments (for example neurologists, anaesthetists, paediatricians and the like), and surgery-specific staff such as theatre nurses.

After surgery, the series 200 proceeds to a recovery step 240. At step 240, the patient may be treated by a number of different teams in different locations within the healthcare facility. For example, a patient may be moved to a recovery area and treated by recovery nurses, and/or moved to an intensive care unit and treated by intensive care specialist nurses.

The recovery step is followed by a discharge step 250, which may for example involve medical professionals from a given area or department within the healthcare facility providing sign-off, and completion of administrative procedures by staff of an administrative department.

Finally, the patient can return to their home after discharge at step 260.

At any of the steps 210 to 250 of the series 200, the patient may be temporarily transferred or moved to another department, e.g., pathology, imaging or radiology and the like, if the patient's condition changes or anomalies in the patient's condition are observed, before being returned to the originating department. As seen from the series 200, a large number of departments can be involved in the flow for a single surgical procedure. Further, the patient may be moved to any of a number of locations around a hospital according to the relevant department administering care. Resultantly, hospital staff can have difficulty (i) recognising who is currently treating a patient and for what purposes, and (ii) physically locating the patient to administer treatment. Further, difficulties can occur in determining the latest records and data associated with the patient. Typically, identifying patient status and data involves locating the patient and reviewing a paper, manually recorded, chart that is attached to the patient's bed.

Ideally, monitoring of patient fluid balance levels should begin the night before surgery (i.e., between steps 210 and 220). However, the monitoring typically begins between step 220 and step 230, for example within 6 hours of surgery at step 230. Further, monitoring of patient fluid balance levels typically stops at step 250. Ideally, patient fluid balance levels would continue to be monitored for at least a period of time after the patient has been discharged and has returned home or back into residential care, e.g. by a community nurse for example.

Inefficiencies in typical healthcare systems, even those digitised, can be particularly relevant to monitoring a patient's fluid balance levels. Fluid balance levels are currently recorded manually, and typically determined at roughly 2-hour intervals. Further, monitoring a patient's fluid levels at home may be problematic as it is not easy to determine the fluid balance levels. Fig. 3 shows a typical example of the data used in determining patient fluid balance levels, and how the data is recorded.

Fig. 3 shows an example of a paper form 300 used for determining a patient's fluid balance levels. The form 300 is filled in manually and includes a column 360 to indicate time of manually entry. The column 360 is segmented into 2-hour intervals as indicated by a series of times 340. A patient's fluid balance is determined based on fluid measurements associated with the patient. The intake 310 is determined in terms of oral intake (310a), for example if a patient is given and consumes a quantity of water, juice or jelly. The intake 310 also includes IV delivery of fluids (e.g., 31 a, 310c), entered manually from a reading of an IV pump. Measurement times are recorded in a corresponding row of the column 360. A 2 out of 24 hour subtotal (2/24 ST) fluid intake 31 Od is manually determined as the sum of 310a, 310b and 310c. A total progressive intake 31 Oe is determine as all 2/24 ST intakes determined in a given 24 hour period.

Similarly a patient's fluid measurements relate to a fluid output or outtake 320. The fluid output 320 is recorded manually at given times reflected in the column 360. Output is determined in terms of fluid in a volume of urine passed (320a), a volume of gastric aspirate expelled (320b), a volume of vomitus regurgitated (320c), and specific gravity (S/G) of urine passed 320d. A 2/24 hour subtotal 320e is determined by appropriate summing of the outputs 320a to 320d. A total progressive output 320f over the 24 hour period is determined using each calculated output 320e. Finally, a progressive balance 300 is determined at the end of each 2-hour period. The progressive balance 330 is determined by subtracting the progressive output 320f from the progressive intake 31 Oe. The progressive balance represents an estimation of the patient's net fluid balance levels. In many arrangements, such as using the form 300, the progressive balance is determined manually approximately every 2 hours.

Accuracy of the progressive balance 330 depends firstly on IV intakes 310b and 310c being correctly monitored and entered. Further, changes in progressive balance are only determined when appropriate medical staff have time, and may be up to two hours apart, or sometimes more. Further, if the patient outputs fluid, e.g., by vomiting, immediately after the progressive balance 330 has been calculated, even if the output 320c is promptly updated, the progressive balance may not be determined until 2 hours later.

Additionally, other factors, e.g., patient mood or energy may provide indicators relating to patient recovery and fluid balance levels but are not recorded or factored in determining whether the progressive balance 330 requires specialist attention or medical treatment. The arrangements described relate to an integrated solution for determining patient fluid balance levels on a real-time in a manner that can address problems presented due to lack of departmental integration and the dynamic, ever-changing nature of hospital and healthcare environments.

Fig. 1 A shows a system 100 for monitoring patient fluid balance levels. In Fig. 1A a staff device 101 is provided. The staff device is preferably a mobile electronics device such as a tablet computer, a laptop computer or the like. A hospital or healthcare facility will include a number of staff devices 101 distributed at various locations around a hospital, for example one device 101 in each ward, at each nursing station, at each bed, one device provided to each staff member or the like. For ease of reference, one staff device 101 is included in Fig. 1A. In other

arrangements, the staff device 101 may be a fixed device, such as a desktop computer.

However, given the dynamic nature of hospital procedures, and mobility of patient staff, mobile devices, and particularly tablet devices, are preferable. It will also be understood that smart telephones may also be used. For example, a smart telephone may be used to provide the same functionality as, or a more limited set of functions (given the smaller screen size) than, a tablet device.

The example of Fig. 1A also includes a central device 195. The central device 195 is typically a hospital server computer, or may be another type of central device, such as a desktop computer, a cloud server or the like. The system 100 also includes an IV pump 193. The IV pump 193 may be any pump suitable for controlled delivery of one or more intravenous fluids to a patient. The arrangements described relate to the IV pump 193 being capable of wireless communications to receive instructions regarding administration of one or more fluids and to transmit details of fluid delivery provided to a patient over a given period. A suitable example of the IV pump 193 is the Alaris™ System with Guardrails™ Suite MX, manufactured by

CareFusion™. While a hospital can include hundreds of IV pumps 193, a single example is shown in Fig. 1 A for ease of reference. Further, although the herein description relates to the administration of a single fluid type or drug via a single IV line, it will be understood that more than one fluid and/or drug may be administered by different IV lines by a single pump.

The staff device 101 is capable of communication with the IV pump 193, as illustrated in broken lines in Fig. 1A. The central device 195 can also communicate with the staff device 101 and IV pump 193, as shown in solid lines in Fig. 1A. Communication between the devices 101 , 193 and 195 is typically wireless, but may include a combination of wired and wireless communication, as described in relation to Fig. 1 B. In some arrangements, the staff device 101 communicates directly with the IV pump 193 as illustrated in broken lines. In other arrangements, all communications with the IV pump 193 are via the central device 195. For ease of reference, the arrangements described below relate to direct communication between the staff device 101 .

Embedded Electronic Device Description

Figs. 1 B and 1 C collectively form a schematic block diagram of a general purpose electronic device, the staff or patient device 101 , including embedded components, upon which the methods to be described are desirably practiced. The electronic device 101 may be, for example, a tablet device or a mobile phone, in which processing resources are limited.

Nevertheless, the methods to be described may also be performed on higher-level devices such as desktop computers, server computers, and other such devices with significantly larger processing resources. The central device 195 operates in a similar manner to the staff or patient device 101 , albeit typically with relatively larger processing resources.

As seen in Fig. 1 B, the electronic device 101 comprises an embedded controller 102.

Accordingly, the electronic device 101 may be referred to as an "embedded device." In the present example, the controller 102 has a processing unit (or processor) 105 which is bi- directionally coupled to an internal storage module 109. The storage module 109 may be formed from non-volatile semiconductor read only memory (ROM) 160 and semiconductor random access memory (RAM) 170, as seen in Fig. 1 C. The RAM 170 may be volatile, nonvolatile or a combination of volatile and non-volatile memory.

The electronic device 101 includes a display controller 107, which is connected to a video display 1 14, such as a liquid crystal display (LCD) panel or the like. The display controller 107 is configured for displaying graphical images on the video display 1 14 in accordance with instructions received from the embedded controller 102, to which the display controller 107 is connected.

The electronic device 101 also includes user input devices 1 13 which are typically formed by keys, a keypad or like controls. In some implementations, the user input devices 1 13 may include a touch sensitive panel physically associated with the display 1 14 to collectively form a touch-screen. Such a touch-screen may thus operate as one form of graphical user interface (GUI) as opposed to a prompt or menu driven GUI typically used with keypad-display combinations. Other forms of user input devices may also be used, such as a microphone (not illustrated) for voice commands or a joystick/thumb wheel (not illustrated) for ease of navigation about menus. As seen in Fig. 1 B, the electronic device 101 also comprises a portable memory interface 106, which is coupled to the processor 105 via a connection 1 19. The portable memory

interface 106 allows a complementary portable memory device 125 to be coupled to the electronic device 101 to act as a source or destination of data or to supplement the internal storage module 109. Examples of such interfaces permit coupling with portable memory devices such as Universal Serial Bus (USB) memory devices, Secure Digital (SD) cards, Personal Computer Memory Card International Association (PCMIA) cards, optical disks and magnetic disks.

The electronic device 101 also has a communications interface 108 to permit coupling of the device 101 to a computer or communications network 120 via a connection 121. The connection 121 may be wired or wireless. For example, the connection 121 may be radio frequency or optical. An example of a wired connection includes Ethernet. Further, an example of wireless connection includes Bluetooth™ type local interconnection, Wi-Fi (including protocols based on the standards of the IEEE 802.1 1 family), Infrared Data Association (IrDa) and the like. For example, the staff or patient device 101 can communicate with the central device 195via the network 120. Further, the staff device may communicate with the IV pump 193 via the network 120. As the IV pump 193 uses wireless communication, all communication therewith must include at least some wireless component.

Typically, the electronic device 101 is configured to perform some special function. The embedded controller 102, possibly in conjunction with further special function components 1 10, is provided to perform that special function. For example, the device 101 may be a mobile telephone handset. In this instance, the components 1 10 may represent those components required for communications in a cellular telephone environment. Where the device 101 is a portable device, the special function components 1 10 may represent a number of encoders and decoders of a type including Joint Photographic Experts Group (JPEG), (Moving Picture Experts Group) MPEG, MPEG-1 Audio Layer 3 (MP3), and the like. In the preferred implementation where the staff device is a tablet device, the special function components 1 10 may relate to implementation of the touch screen 1 14.

The methods described hereinafter may be implemented using the embedded controller 102, where the processes of Figs. 4 to 6 may be implemented as one or more software application programs 133 executable within the embedded controller 102. It will be understood that the software application program that is provided to a staff device may be different to the software application program that is provided to a patient device. For example, a patient device may only require limited software functionality to enable the patient to record fluid intake and fluid output and transfer that data to the central device 195.

The electronic device 101 of Fig. 1 B implements the described methods. In particular, with reference to Fig. 1 C, the steps of the described methods are effected by instructions in the software 133 that are carried out within the controller 102. The software instructions may be formed as one or more code modules, each for performing one or more particular tasks. The software may also be divided into two separate parts, in which a first part and the corresponding code modules performs the described methods and a second part and the corresponding code modules manage a user interface between the first part and the user.

The software 133 of the embedded controller 102 is typically stored in the non-volatile ROM 160 of the internal storage module 109. The software 133 stored in the ROM 160 can be updated when required from a computer readable medium. The software 133 can be loaded into and executed by the processor 105. In some instances, the processor 105 may execute software instructions that are located in RAM 170. Software instructions may be loaded into the RAM 170 by the processor 105 initiating a copy of one or more code modules from ROM 160 into

RAM 170. Alternatively, the software instructions of one or more code modules may be pre- installed in a non-volatile region of RAM 170 by a manufacturer. After one or more code modules have been located in RAM 170, the processor 105 may execute software instructions of the one or more code modules.

The application program 133 is typically pre-installed and stored in the ROM 160 by a manufacturer, prior to distribution of the electronic device 101. However, in some instances, the application programs 133 may be supplied to the user encoded on one or more CD-ROM (not shown) and read via the portable memory interface 106 of Fig. 1 B prior to storage in the internal storage module 109 or in the portable memory 125. In another alternative, the software application program 133 may be read by the processor 105 from the network 120, or loaded into the controller 102 or the portable storage medium 125 from other computer readable media. Computer readable storage media refers to any non-transitory tangible storage medium that participates in providing instructions and/or data to the controller 102 for execution and/or processing. Examples of such storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, USB memory, a magneto-optical disk, flash memory, or a computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external of the device 101. Examples of transitory or non-tangible computer readable transmission media that may also participate in the provision of software, application programs, instructions and/or data to the device 101 include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. A computer readable medium having such software or computer program recorded on it is a computer program product.

The second part of the application programs 133 and the corresponding code modules mentioned above may be executed to implement one or more graphical user interfaces (GUIs) to be rendered or otherwise represented upon the display 1 14 of Fig. 1 B. Through manipulation of the user input device 1 13 (e.g., the keypad), a user of the device 101 and the application programs 133 may manipulate the interface in a functionally adaptable manner to provide controlling commands and/or input to the applications associated with the GUI(s). Other forms of functionally adaptable user interfaces may also be implemented, such as an audio interface utilizing speech prompts output via loudspeakers (not illustrated) and user voice commands input via the microphone (not illustrated).

Fig. 1 C illustrates in detail the embedded controller 102 having the processor 105 for executing the application programs 133 and the internal storage 109. The internal storage 109 comprises read only memory (ROM) 160 and random access memory (RAM) 170. The processor 105 is able to execute the application programs 133 stored in one or both of the connected

memories 160 and 170. When the electronic device 101 is initially powered up, a system program resident in the ROM 160 is executed. The application program 133 permanently stored in the ROM 160 is sometimes referred to as "firmware". Execution of the firmware by the processor 105 may fulfil various functions, including processor management, memory management, device management, storage management and user interface.

The processor 105 typically includes a number of functional modules including a control unit (CU) 151 , an arithmetic logic unit (ALU) 152, a digital signal processor (DSP) 153 and a local or internal memory comprising a set of registers 154 which typically contain atomic data elements 156, 157, along with internal buffer or cache memory 155. One or more internal buses 159 interconnect these functional modules. The processor 105 typically also has one or more interfaces 158 for communicating with external devices via system bus 181 , using a connection 161.

The application program 133 includes a sequence of instructions 162 through 163 that may include conditional branch and loop instructions. The program 133 may also include data, which is used in execution of the program 133. This data may be stored as part of the instruction or in a separate location 164 within the ROM 160 or RAM 170. In general, the processor 105 is given a set of instructions, which are executed therein. This set of instructions may be organised into blocks, which perform specific tasks or handle specific events that occur in the electronic device 101. Typically, the application program 133 waits for events and subsequently executes the block of code associated with that event. Events may be triggered in response to input from a user, via the user input devices 1 13 of Fig. 1 B, as detected by the processor 105. Events may also be triggered in response to other sensors and interfaces in the electronic device 101.

The execution of a set of the instructions may require numeric variables to be read and modified. Such numeric variables are stored in the RAM 170. The disclosed method uses input variables 171 that are stored in known locations 172, 173 in the memory 170. The input variables 171 are processed to produce output variables 177 that are stored in known locations 178, 179 in the memory 170. Intermediate variables 174 may be stored in additional memory locations in locations 175, 176 of the memory 170. Alternatively, some intermediate variables may only exist in the registers 154 of the processor 105.

The execution of a sequence of instructions is achieved in the processor 105 by repeated application of a fetch-execute cycle. The control unit 151 of the processor 105 maintains a register called the program counter, which contains the address in ROM 160 or RAM 170 of the next instruction to be executed. At the start of the fetch execute cycle, the contents of the memory address indexed by the program counter is loaded into the control unit 151. The instruction thus loaded controls the subsequent operation of the processor 105, causing for example, data to be loaded from ROM memory 160 into processor registers 154, the contents of a register to be arithmetically combined with the contents of another register, the contents of a register to be written to the location stored in another register and so on. At the end of the fetch execute cycle the program counter is updated to point to the next instruction in the system program code. Depending on the instruction just executed this may involve incrementing the address contained in the program counter or loading the program counter with a new address in order to achieve a branch operation.

Each step or sub-process in the processes of the methods described below is associated with one or more segments of the application program 133, and is performed by repeated execution of a fetch-execute cycle in the processor 105 or similar programmatic operation of other independent processor blocks in the electronic device 101.

Fluid Balance Monitoring Application In particular, the software 133 includes a fluid balance monitoring application executable on the staff device 101. In arrangements where communication with the IV pump 193 is via the central device 195, a similar application can be implemented on both the devices 101 and 195, or implemented partially on each of the devices 101 and 195. Members of staff of the healthcare facility are able to access the application 133 via the staff device 101 and a login procedure (e.g., using a password or biometric data).

The fluid balance monitoring application can access a number of databases stored in a memory of the central device 195 or the memory 109.

The databases include at least an employee database including details every employee (staff member) of the healthcare facility, and a patient database populated with details for every patient of the healthcare facility.

Details stored in the employee database include a staff identifier (typically a staff number), department of employment, role, and access controls (e.g. login or biometric key details), and permissions. Permissions depend on the role of the staff member, and identify what inputs are allowed from an employee, or if the staff member only has read access to data. For example, only a doctor may be allowed enter a prescription for an IV fluid and delivery rates. A nursing unit manager may have increased permissions compared to other nurses in a unit, who may be allowed enter measurements or observations only.

The patient database includes reference details such as name, identifier, gender, weight, previous admissions and procedures, as well as current information associated with the patient. The current information typically relates to latest procedure, location, current department providing treatment and medical records such as fluid balance levels.

Further, the application may access (e.g. read and/or retrieve) parameter settings that have been set by a doctor for progressive fluid balance on each patient, where these parameter settings include oral intake, IV line 1 , IV line 2, urine output and specific gravity test results, vomit, patient mood monitoring, pathology results and the like.

Once a patient has returned home, for example, the patient may use their electronic device 101 to communicate fluid balance data to the central device 195. For example, when a patient returns home after a procedure, continued fluid balance levels may still be determined by the patient's electronic device based on inputs received via the software application. It will be understood that the device used by the patient may have similar but limited functionality to the staff device 101. The patient may download a suitable software application for use at home to record fluid intake as well as fluid output. The software application may require the patient's unique ID as well as other data in order to verify the patient and associate them with the correct patient records. Guidance may be given to the patient prior to leaving the health facility to assist them in determining fluid intake and output and to show them how to carry out the data recordal. The patient device communicates the data to the central device 195 for storage in the patient's records and for generating alerts if needed.

As an alternative, a community nurse may use their own staff device 101 to record the fluid balance data associated with a patient when the patient is at home or in an aged car facility. The staff device 101 may then communicate this fluid balance data back to the central device 195 for storage in the patient's records and for generating alerts if needed.

Fluid Balance Monitoring Method

The fluid balance monitoring application 133 provides a mechanism that delivers monitoring fluids to a patient pre- and post-surgery. Fig. 4 shows a method 400 implemented by the application 133 under control of the processor 105 for monitoring a patient's fluid balance levels.

The method 400 begins at a receiving step 405. At step 405, the staff device 101 receives data associated with a patient's IV fluid prescription, for example by a member of staff entering data into the application 133 via the touchscreen 1 14. When receiving the prescription data, the application 133 also receives identification of the employee providing the prescription, for example via the login procedure. This data is transferred to the central device 195 via the network. The prescription data includes at least a patient identifier, identifier of an IV fluid and/or drug, and an identifier of a corresponding IV fluid rate. It will be understood that there are hundreds of different IV fluids and drugs that can be administered and the associated fluid administration rate is determined by the patient's healthcare team including the doctor and other professionals. The IV pump is associated with the patient by a healthcare professional, such as a nurse, entering the patient's unique ID into the IV pump. The unique ID may be, for example, a unique registration number provided to the patient at the time they were booked in for their procedure. This unique ID is provided to the central device when the pump communicates with the central device to associate the pump data with the patient data stored at the central device.

In some arrangements, the IV pump 193 is selected by a healthcare professional such as a nurse setting up the pump 193. In this instance, the application 133 can receive two sets of inputs associated with the prescription, for example one input from a doctor identifying the patient, the fluid and the rate, and one input from a nurse identifying the pump. The fluid prescription will be accepted if the user of the staff device 101 is associated with appropriate permissions for each particular input. For example, a doctor or a ward manager may have sufficient permissions to prescribe a fluid and a rate. However, if a ward nurse provides instructions prescribing a fluid and a rate but does not have appropriate permissions, the prescription will be refused.

The method 405 continues under execution of the processor to step 410. At step 410, the staff device 101 transmits fluid delivery instructions to the IV pump 193 associated with the patient. The fluid delivery instructions transmitted are based on the prescription and typically include identification of the fluid, the delivery rate and the patient identifier.

Further, the fluid delivery instructions are sent to one or more other staff devices that are associated with, for example, i) the ward nurses, ii) doctors (for alerts and monitoring fluid trends), iii) the patient's ward manager (for operational intelligence), iv) the pharmacy (for drug usage and inventory management).

The method 400 progresses from step 410 to step 415. At step 415, the device 101 operates to receive real-time patient fluid delivery data from the pump 193. The real-time data is received via wireless communication between the IV pump 193 and the staff device 101 (or the central device 195). Pump 193 typically sends the real time data at predetermined intervals, such as, for example every minute, to the staff device 101 (or the central device 195). It will be understood that the data may be transmitted at smaller or longer intervals depending on the patient's health status and/or condition. This can effectively provide real time fluid related data associated with the patient to individual devices or the central device such that the data can then be accessed and monitored by the required professionals through their connected devices..

When the method 400 proceeds from step 415 to step 420, at step 420, the device 101 receives measurements relating to the patient's fluid intake and outtake. For example the measurements may relate to intake 310a (intake measures associated with an IV pump, such as the intake 310b, are received from the IV pump 193 at step 415) and outputs 320a-e of Fig. 3. Rather than being manually recorded on a form, such as that shown in Fig. 3, the measurements are entered into the device and stored in the database associated with the patient. The

measurements are typically entered into the staff device 101 by an employee (member of staff) at the healthcare facility, for example a ward nurse or a theatre nurse. When receiving the measurements, the application 133 also receives identification of the employee providing the measurements, for example via the login procedure.

Fig. 7 shows an example screenshot of how the fluid intake of a patient may be entered into a device 101 e.g. a staff device or a patient device. The patient's data 700 is displayed at the top of the screen, including name, age, gender, surgeon, room, ward and unique ID number (UR No.). According to this example, a number of fluid intake options 701 are provided as visual icons for the user to choose from. Each icon is associated with a particular drink or item of food and has associated with it an amount of fluid, which is stored internally in the memory of the device 101. Upon entering or selecting the relevant icon, the amount of fluid associated with that drink or item of food is added as a fluid intake value for the relevant patient at the relevant time.

A record list 703 is displayed indicating each of the items that have been selected along with the associated date, time, amount, description, and fluid amount. This data is then used in the determination of the patient's fluid balance.

Fluid output may be recorded by a healthcare worker on the staff device 100 after measuring the amount of fluid in one or more forms that has been output by the patient. Also, the patient may be trained, prior to leaving the healthcare facility, in how to record on the patient's device 101 how much fluid has left their own body, e.g. by measuring urine in a pan and manually entering the value into the software application.

In some cases, step 420 may be implemented a number of times or may not be implemented at all. The order of steps 415 and 420 may be interchanged.

Using the example of Fig. 4, the method 400 continues to step 425 to determine the patient's net fluid balance level. The net fluid balance corresponds to the progressive balance. The net fluid balance is determined based upon the received real-time fluid delivery data received at step 415 and the patient measurements received at step 420. The patient's net fluid balance is determined in accordance with standard medical methods.

Fig. 8 shows an example screenshot of a patient's fluid intake and output for a particular day and indicates a P Balance (progressive balance) or fluid balance based on those

measurements.

The method 400 proceeds from step 405 to a check step 435. At step 435, the application 133 executes to determine if an alarm is required based on the determined fluid balance of the patient. A method of 500 of determining whether an alarm is required is described hereinafter in relation to Fig. 5. If an alarm is not required (N at 435), the method 400 continues to a transmitting step 445. At step 445, data relating to patient fluid balance levels is transmitted to pathology and/or pharmacy departments for inclusion in general reports on medical status of the patient. Including real-time, accurate data in the general reports can provide assistance in determine appropriate prescriptions and treatment for the patient. From step 445, the method 400 proceeds back to step 420 to await a next real-time set of data from the pump 193. In some arrangements, the step 445 may be omitted. If at step 435, an alarm is determined to be required (Y at step 435), the method 400 proceeds to step 440. At step 440, the alarm is activated. Activation of the alarm relates to transmitting relevant information to appropriate person(s) to take action in relation to the alarm. The alarm is typically transmitted from the central device 195, but may be transmitted from the staff device 101 to at least one other staff device via the network 120. For example, the alarm may be transmitted to a doctor using a pager system or using a staff device associated with the doctor, or to a nurse or a team of medical professionals. The alarm may be an alarm message (such as a pop-up message, email, pager message etc.), and/or a beeping sound, or the like. The alarm may then be de-activated by a member of staff using the staff device, for example, straight away or upon a doctor's approval. The de-activation may only be allowed upon a doctor's approval if the alarm is a high alert alarm, for example. After activating the alarm, the method 400 continues back to step 445 to provide an update to relevant departments, and then to step 415 to receive a next set of real-time patient fluid delivery data. The method 400 continues until the pump has been switched off, approval from the doctor has been received via the doctor's staff device, or instructions received to discharge the patient via the discharge department's staff device.

At any time, healthcare staff can enter information relating to the patient to the staff device 101. In addition to the fluid measurements described in relation to Fig. 3 and step 420, the information can include observations relating to patient behaviour such as heart rate, blood pressure, mood, energy level, level of consciousness, limb movement and the like. The observations can be included in the determination by the device of whether an alarm is required at step 435, for example in determining a threshold at step 505, and conveyed in a message transmitted as part of the alarm. The observations can also be included in data sent to pathology or pharmacy for recordal in general reports.

Fig. 5 shows a method 500 in determining whether an alarm is required, as executed at step 435 of the method 400. The method 500 is typically implemented as one or more modules of the application 133.

The method 500 starts at a determining step 505. Step 505 executes to determine a hospital department associated with the patient. The determining step is based primarily on the department associated with the surgery (e.g., neurology, orthopaedics, or the like) but also on the department currently treating the patient (for example intensive care or general recovery). Determining the relevant department may also allow the application 133 to identify a look-up table of fluid balance levels and thresholds associated with the patient's procedure and current location. Differentiating between departments may be important, as a drop in fluid balance levels may be more critical in some disciplines than others. For example, drop in fluid balance levels may be very dangerous after neurological surgery or when in intensive care, but less dangerous after orthopaedic surgery or in general recovery.

Alternatively, the determined fluid balance levels may be compared against a parameter setting to determine whether an alarm is to be set. For example, parameter settings may be set by a doctor for each patient based on a number of factors such as, for example, measuring the patient's body weight and height, knowing the procedure the patient is having, and considering other medical conditions of the patient.

Various threshold values may be set in the parameters for different levels of alarm, such as a normal alarm, warning alarm and high alert alarm.

The method 500 continues to step 510. At step 510, the application 133 compares the net fluid balance determined at step 425 to the threshold(s) determined at step 505. Additionally or alternatively, a set of net fluid balance levels determined from a number of iterations of steps 415 to 425 may be compared to a set of thresholds to determine a trend in the patient's net fluid balance level.

The method 500 continues to step 515, determining a degree by which the comparison implemented at step 510 meets or exceeds the determined threshold. For example, the determined level may be 5% or 50% below or above the threshold, or within a range of tolerance overlapping the threshold.

At step 520, the method 500 determines if an alarm is required based on the degree calculated at step 515. Determining whether an alarm is required typically involves determining a level of the alarm and relevant recipients. A lower alarm level can relate to the patient being within a predetermined amount or range of the threshold. Setting an alarm in this event can include selecting a message for delivery to recipients that the patient is approaching a danger zone and should be monitored closely by staff. A high level alarm can occur when the patient has exceeded the threshold by a predetermined amount. Setting the high level alarm can include selecting a message and delivery type (e.g., flashing light) to convey urgency to the selected recipients that the patient requires immediate treatment. The relevant recipients are determined based on the level of the alarm and the permissions associated with the staff. For example, a doctor may receive a high level alarm only, whereas a nursing unit manager may receive both types of alarms. The method 500 ends at step 520.

Fig. 6 shows a method 600 of determining a patient location. The method 600 is typically executed every time an input is provided to the application 133 by a staff member of the healthcare facility in relation to a patient. For example, the method 600 can be implemented upon receiving input at step steps 405 and 420. The method 600 typically executes in parallel with the steps 405 and 420, or may be executed after or as part of the steps 405 and 420. At step 405 for example, an employee enters prescription instructions to the application 133 via the inputs 1 13 of the staff device 101.

The method 600 starts at step 605. Step 605 executes to determine an employee associated with the input, for example by comparison of login details to an identifier of the employee database stored in the memory 109.

The method 600 continues to a determining step 610. The step 610 operates to determine a department associated with the identified employee. For example, if the employee is a recovery nurse the department will be the recovery department. The department associated with the employee typically relates to a particular geographical area of the healthcare facility.

The method 600 continues from step 610 to an updating step 615. Step 615 updates the patient location based on the location of the determined department, or upon a determination that the patient is entering fluid based data themselves and so is at home or in an aged care facility.

Industrial Applicability

The arrangements described are applicable to the healthcare industry and particularly for the patient recovery sector of the healthcare industry.

In allowing and using transmission of prescription information to the IV pump 193 and transmission of real-time fluid delivery data from the pump 193 to the staff device 101 (or central device 195), patient fluid balance levels can be monitored in near real-time rather than at manual intervals. In this manner, sudden decreases in patient fluid balance levels can be immediately detected and acted upon by healthcare staff. The integrated solution using a number of staff devices allows issues of departmental segregation to be addressed in this regard. By using an alarm system described in relation to steps 435 and 440, relevant healthcare staff are informed immediately if the patient needs attention, regardless of the department or change of location of the patient. Delays in providing appropriate care can be at least reduced if not removed, and potential post-surgical complications thereby avoided.

Additionally, delivery of fluids by the pump 193 to the patient can be directed without a doctor having to actually attend the patient and/or the pump. In some instances, an updated

prescription can be transmitted to the pump via the staff device 101 or the central device 195.

Additionally, the arrangements described all provide a means of tracking a patient as described in relation to the method 600. The arrangements described reduce potential for error by receiving readings directly from the IV pump 193. The real-time collection of IV delivery data also provides a mechanism by which up to date data can be provided for general reports for pathology and pharmacy, thereby reducing likelihood of decisions or prescriptions being made using

The arrangements described operate to address problems caused by lack of department integration across hospital departments and reduce resultant risk to patients.

The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive.

In the context of this specification, the word "comprising" means "including principally but not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.

Claims

Claims:

1. A system comprising:

an IV pump,

a wireless network, and

a computing device, the computing device configured to:

receive, via the wireless network, a fluid prescription for a patient;

transmit, via the wireless network, fluid administration instructions to an IV pump associated with the patient, the fluid administration instructions based on the received fluid prescription;

receive, from the IV pump via the wireless network, real-time information regarding fluid delivery to the patient;

receive, via the wireless network, fluid measurements relating to the patient; and determine a fluid balance of the patient based on the received measurements and the realtime information.

2. The system according to claim 1 , wherein the computing device is further configured to determine a fluid threshold associated with the patient based on a healthcare department associated with the patient and comparing the determined fluid balance to the threshold.

3. The system according to claim 2, wherein the computing device is further configured to determine, based on the comparison, if an alarm is required.

4. The system according to claim 3, wherein determining if an alarm is required comprises determining a level of the alarm.

5. The system according to claim 3 or claim 4, wherein determining if an alarm is required comprises determining recipients of the alarm.

6. The system according to any one of the preceding claims, wherein the computing device is one of a portable staff device, portable patient device and a central server.

7. The system according to any one of the preceding claims, wherein the computing device is configured, upon receiving the fluid prescription or the patient fluid measurement, to determine at least one of an employee and a department associated with provision of the input, and a location of the patient based on the determined employee or department.

8. The system according to any one of the preceding claims, wherein the computing device is configured to transmit the determined patient fluid balance to one of a pharmacy and a pathology department.

9. The system according to any one of the preceding claims, wherein the computing device is further configured to receive an observation relating to the patient, and use the observation to determine if an alarm is required based on the observation.

10. A computer-implemented method of monitoring patient fluid balance levels, the method comprising:

receiving, via a wireless network, a fluid prescription for a patient;

transmitting, via the wireless network, fluid administration instructions to an IV pump associated with the patient, the fluid administration instructions on the received fluid

prescription;

receiving, from the IV pump via the wireless network, real-time information regarding patient fluid delivery;

receiving, via the wireless network, fluid measurements relating to the patient; and determining a fluid balance of the patient based on the received measurements and the real-time information.

1 1. The method according to claim 10, further comprising the steps of determining a fluid threshold associated with the patient based on a healthcare department associated with the patient and comparing the determined fluid balance to the threshold.

12. The method according to claim 1 1 , further comprising the step of determining, based on the comparing step, if an alarm is required.

13. The method according to claim 12, wherein determining if an alarm is required comprises the step of determining a level of the alarm.

14. The method according to claim 12 or claim 13, wherein determining if an alarm is required comprises the step of determining recipients of the alarm.

15. The method according to any one of claims 10 to 14, further comprising the step of, upon receiving the fluid prescription or the patient fluid measurement, determining at least one of an employee and a department associated with provision of the input, and a location of the patient based on the determined employee or department.

16. The method according to any one of claims 10 to 15, further comprising the step of transmitting the determined patient fluid balance to one of a pharmacy and a pathology department.

17. The method according to any one of claims 10 to 16, further comprising the steps of receiving an observation relating to the patient, and using the observation to determine if an alarm is required based on the observation.