Medical Equipment Inventory & Location System

1. Medical Equipment Inventory & Location System Tomer Peled Al Yaros Kobi Ruham http://www.cs.bgu.ac.il/~peledto

2. Background • Today location and tracking equipment at the hospitals is a major problem. Ranging from bed facilities, IV pumps, surgical equipment, to wheel chairs, ECG carts, etc. • Barcode is one of the automated identification technologies that reduce the time and labor needed to input and manage data manually, thereby improving operations and data accuracy. • ScanTask Company has invented a patent for using the barcode readers in a convenient way with the wearable barcode glove which allow the users to operate the system in a hands-free style.

3. Problem Domain • Introduction: • Hospital logistics become more complicated during the last years through the progress of medical science, such as Biomedical engineering – more and more new and expensive equipment are purchased by the hospitals, which need to be managed in an efficient way. • The situation of a nurse looking urgently for an infusion pump or other medical device while a multitude of those are lying “secretly” in a neighboring section is a known picture that can be easily solved by a dynamic real time inventory and location system.

4. The implications are: • Labor costs - associated with individuals to search for the equipment when needed. • Time lost - Equipment not being available when needed. • Increased inventory costs - purchase or rent the equipment due to lack of availability. • Staff frustration with operational inefficiencies • Wrong Verification of a product – Usages of wrong equipment. • “Loss” – of critical equipment. • In this era of severe budget constraints these problems should receive increased attention and implementation of efficient systems is critical.

5. Unbalanced usage of equipment : one cart is traveling between rooms numerous number of times, while other available carts are laying unused.

6. Current Situation • Current hospital equipment management are inefficient and require manual processes. • The hospital staff spend roughly 10% of shipment time looking for some sort of critical equipment. • Common used equipment is distributed unevenly between various department with different needs. • Hospital equipment theft – awareness for stolen hospital equipment is usually discovered on critical times even though it could be discovered earlier.

7. Proposed Solution – Towards Smart Hospital • A System that will use the ScanTask mobile solution of cellular bar-code readers to accomplish an availability (inventory and location) system for medical equipment in hospital facilities. • Deployment scenario: • Each equipment will be coded with an unique barcode. • Each room will be coded with an unique barcode. • Each user will be equipped with barcode reader glove patent and a mobile phone – wirelessly paired with the reader.

8. Each usage scenario will be accompanied with barcode scanning process by the users. For example: scanning the room and the ECG cart when entering the surgery room. • When deployed in a hospital, mobile technologies such as real-time location services (RTLS) and barcode scanning can offer significant benefits in terms of increasing the speed and improving the accuracy of patient care.

9. System Architecture • ScanTask Barcode reader glove • 2 types of clients : • Mobile Client • Desktop Smart Client – Administration and BI module • Web Server • Database Server

10. System Architecture And Technologies • The system will be written purely with java in order to allow maximum portability between different platforms. • The database server will be based on MySql And hibrnate accessing method which allows flexible database environment. • mobile client will be written with j2me (java micro edition)

11. The web server will be an XML based webservice. • The desktop client: • will be a smart client - deployed with JWS (java web start) which ensures that the current desktop running application is the most updated version at any given moment - such as in web client style while enjoying the powerful features of desktop client. • Open source BI module which allows the manager to produce building reports.

12. Functional Requirments • The system will contain 3 groups of users: • Normal user • Manager • Administrator • We will consider each hospital product as a 3 state FSM with the following states: • In use • Not in use • Damaged

13. Normal User: • Update Product Status - Normal user will be able to declare product as in: "In Use" or "not In Use". • Update product position Normal user will be able to declare the product current location. • Locate Normal user will be able to locate a specific product type.  • User Authentication – Login/Logout

14. Manager: • Built In reports The manager will be able to produce a report from a set of pre defined reports only over the desktop client by navigating to "Reports" section and selecting the desirable report. Tor example : X users that used a cretin product type. • Dynamic report builder The system will give the manger the ability to produce reports at run time. • Update Damage state for a certain product • The manager will be able to mark a specific product as damaged \ not damaged.

15. Admin: • System equipment management The admin will be able to add\remove\update the system equipment data. • System users management The admin will be able to add\remove\update the system users data.

16. Non-Functional Requirments • We expect that the average number of simultaneously Users will be 250 spread among Desktop clients and mobile clients. • The glove is connected (paired) with the mobile client at all time with Bluetooth. • The database server and the web server will be connected at all time through the Hospital infrastructure.

17. The desktop client is connected to the web server through the Hospital infrastructure. • The mobile client should have the ability to connect to the internet And send messages in size up to 100kb. • Database housekeeping and backup – the database server will contain built in housekeeping jobs such as automatically backup and logs cleanup. • The transactions between the web server and the mobile client will secure with SSL protocol

18. The system does not contain at any stage confidential medical data about patients. • Usability - The system will require minimal knowledge and training. • The update functionality , which is performed by the mobile client application, should not cause a delay to the user.

19. Major Use-cases

22. Risks • The system is based upon a well known platforms that are currently in use on the market, therefore we don't expect any major risks that might cause our project to fail.

23. Thank You !