MEDICAL DEVICE TRACKING AND REPROCESSING SYSTEM

Abstract

The system describes a software implementation to track use and cleaning of medical devices in hospitals and other medical settings. Further, the system may track cleaning (e.g. temperature, movement) and location (e.g. RSSI, etc.) of a medical device. The system may include boxes that sit on the wall in the cleaning rooms, sensors on the medical devices, sensors on the individuals who handle the devices, and a separate Wi-Fi wireless network that relays information from the box to a computer in the facility, that relays the information back to the cloud. In some embodiments, a supervisor or other superior gets notified if proper cleaning and reprocessing methods are not used. In other embodiments, the surgeon/doctor can scan a medical device when presented for use and see its use and cleaning history.

Claims

1. A medical device cleaning and tracking system comprising: a processor having a memory, the memory having computer readable instructions stored thereon that when executed by the processor, enable monitoring of at least one medical device having a first tag, wherein the first tag is configured to measure at least location, movement, battery status, and temperature of the at least one medical device; a second tag operably coupled to the processor, the second tag being configured to monitor the at least one medical device, wherein the second tag is configured to communicate with the first tag and receive information pertaining to the at least one medical device therefrom; and, wherein the memory further comprises instructions, that when executed by the processor, issues an alarm in response to failure to detect a proper temperature.

2. The system as recited in claim 1, further comprising: at least one additional tag configured to monitor the at least one medical device.

3. The system as recited in claim 1, wherein the at least one medical device is an endoscope.

4. The system as recited in claim 1, wherein the battery status includes an analysis of a charge of a battery.

5. The system as recited in claim 1, wherein the alarm includes a powering on of at least one alert light.

6. The system of claim 1, wherein the memory further comprises instructions, that when executed by the processor, cause the processor to perform the steps of: recording a location history for the at least one medical device; and issuing an alarm in response to determining an absence of a sink record within a predetermined number of previous locations within the recorded location history.

7. The system of claim 1, wherein the memory further comprises instructions, that when executed by the processor, cause the processor to perform the steps of: detecting a distance between the at least one medical device and a sink; activating additional broadcast data from the at least one device when the detected distance is below a predetermined threshold.

8. The system of claim 1, wherein the memory further comprises instructions, that when executed by the processor, cause the processor to perform the steps of: detecting a distance between the at least one medical device and a sink; and deactivating additional broadcast data from the at least one device when the detected distance is below a predetermined threshold.

9. A method of tracking a medical device, the method comprising the steps of: monitoring, via a processor, a location of at least one medical device; monitoring, via the processor, a temperature of the at least one medical device; monitoring, via the processor, a movement of the at least one medical device; monitoring, via the processor, a battery status of the at least one medical device; logging, via the processor, the location, the temperature, and the movement of the at least one medical device; storing, on a computer readable memory operably coupled to the processor, the location, the temperature, and the movement of at least one medical device; wherein if a location, temperature, or movement of the at least one medical device meets a predetermined threshold, then no alert is generated; and wherein if a location, temperature, or movement of the at least one medical device does not meet a predetermined threshold, then an alert is sent to at least one electronic device.

10. The method as recited in claim 9, further comprising: at least one additional tag configured to monitor the at least one medical device.

11. The method as recited in claim 9, wherein the at least one medical device is an endoscope.

12. The method as recited in claim 9, further comprising: recording a location history for the at least one medical device; and issuing an alarm in response to determining an absence of a sink record within a predetermined number of previous locations within the recorded location history.

13. The method as recited in claim 12, wherein the predetermined number of previous locations within the recorded location history is five.

14. The method as recited in claim 12, further comprising: determining if the first tag is found in a bad light array.

15. The method as recited in claim 14, further comprising: if the first tag is determined to be found in a bad light array: if an alert light is off, sending a signal to turn the alert light on.

16. The method as recited in claim 9, further comprising: detecting a distance between the at least one medical device and a sink; and activating additional broadcast data from the at least one device when the detected distance is below a predetermined threshold.

17. The method as recited in claim 16, wherein the additional broadcast data includes temperature data.

18. The method as recited in claim 12, further comprising: detecting a distance between the at least one medical device and a sink; and deactivating additional broadcast data from the at least one device when the detected distance is below a predetermined threshold.

19. The method as recited in claim 18, wherein the additional broadcast data includes motion data.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0032] FIG. 1 is a flowchart illustrating an embodiment of the present system reading the tags in a clean room.

[0033] FIG. 2 is a flowchart illustrating an embodiment of the present system reading the tags near a sink.

[0034] FIG. 3 is a flowchart illustrating an embodiment of the present system reading the tags near an automated endoscope reprocessor.

[0035] FIG. 4 is a flowchart illustrating an embodiment of the present system reading the tags in a closet.

[0036] FIG. 5 is a flowchart illustrating is an embodiment of the present system reading the tags in an examination/procedure room.

[0037] FIG. 6 is a flowchart illustrating processing of a tag or beacon to manage temperature, movement, location, etc. of the medical device.

[0038] FIG. 7 is a flowchart illustrating a management of collected data and reporting of the data.

[0039] FIG. 8 is a flowchart illustrating a process of finding a location room of the medical device.

[0040] FIG. 9 is a flowchart illustrating a process to report alerts when protocols relating to the medical device are not adhered.

[0041] FIG. 10 is a flowchart illustrating another embodiment of a process of finding a location room of the medical device.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0042] The preferred embodiments of the present invention will now be described with reference to the drawings. Identical elements in the various figures are identified with the same reference numerals.

[0043] Reference will now be made in detail to each embodiment of the present invention. Such embodiments are provided by way of explanation of the present invention, which is not intended to be limited thereto. In fact, those of ordinary skill in the art may appreciate upon reading the present specification and viewing the present drawings that various modifications and variations can be made thereto.

[0044] Generally, the present system refers to a software system capable of tracking use and cleaning of medical devices, particularly endoscopes, in medical settings. The system may include boxes that sit on the wall, floor, etc. of various rooms throughout the medical setting (e.g. hospital rooms). For example, a box may be present in the cleaning rooms, sinks, cleaners, closets, etc. Sensors or tags are operably coupled to the medical device and persons working in the medical setting. According to an embodiment, the medical device may include, but is not limited to, sensing equipment, measuring equipment, IV drips, gurneys, wheelchairs, and/or any other suitable medical device. According to an embodiment, the tags may further be operably coupled to medical material such as, e.g., vaccines, blood shipments, organ shipments, and/or any other suitable medical material. In some embodiments, there is a separate communications network (e.g. Wi-Fi wireless communication network) that is configured to relay information from the box to another computer in the facility for storage and interpretation. The information may then also be stored, under encryption, in the cloud. The boxes described in the present invention are referred to as PD boxes or branded as The Observer.

[0045] Referring now to FIG. 1, illustrating an embodiment of the present system reading the tags in a clean room. The tag coupled to the medical device is primarily intended to be broadcasting a signal such that the location of the medical device can be readily ascertained. In some embodiments, this is a continuous signal broadcast, whereas in other embodiments, the signal is sent intermittently. The boxes, positioned throughout the medical setting, are configured to receive information from the tags associated with the medical devices. Preferably, the boxes can read information on a tag when the tag is positioned from up to about 50 m away from the particular box's location. If more than two boxes are in the same vicinity an average of the location reading may be used to definitively pinpoint the location of the medical device. FIG. 1 describes the process flow of the clean room. The Scope Tag or Nurse Tag at the sink 10a, Automated endoscope reprocessors (herein AER) 10b, or Room 10c sends a Received Signal Strength Indicator (herein RSSI) and an identification (herein ID) Values over Bluetooth to the PD Box located in the Clean room, 20. The PD Box 20 located in the clean room then collects a sample of RSSI values 30 and gets the average per tag 40. The averages with data stamps are then sent to the personal computers (herein PC) at that location 50. Every 45 seconds 60, the PD box then sends a location check 70a, 70b in to the sequel database (herein SQL) and then collects the latest tag list from the SQL database. The PD box also sends a script change check 80 to the SQL and if needed, will update and reboot the process if there are any new changes to the scripts 90. In the event a new timing interval is created, a timer can resent this function with a new second or minute interval 100.

[0046] In a preferred embodiment, receive signal strength indication (RSSI) is used to determine the location of the medical device. The boxes can interpret the location signal emanating from the tag on the medical device thereby determining via the signal strength an approximate distance from the box. As noted above, the more boxes that are used in making the determination, the more precise the location will be.

[0047] According to an embodiment, the RSSI values include a battery level as it is sent to the local PC SQL, through Wifi to the cloud based PC, and/or through any other suitable means. According to an embodiment, after the process is reboot 90 if there are any new changes to the scripts, it is determined if the tag is in a bad light array 91. According to an embodiment, the bad light array is an indication that an alert must be sent regarding a component; e.g., the battery. According to an embodiment, the bad light array is an indication that the battery level of the battery is low. If the tag is in a bad light array, it is determined whether the alert light is on 92. If the tag is in a bad light array and the alert light is on, the signal is sent to the PD box 20 and then to the tags. If the tag is in a bad light array and the alert light is off a signal is sent to the PD box and then the tags to turn the alert (or bad) light on 93. If the tag is not in a bad light array, it is determined whether the alert light is on 94. If the tag is not in a bad light array and the alert light is on, a signal is sent to turn the alert light off 95. If the tag is not in a bad light array and the alert light is not on, then no signal to signal an alert is sent. These changes allow the tag to communicate with the PD Boxes a device's battery level and if it needs to have its alert light on. This allows staff to have a physical indication that an alert has been issued for that device. It also allows better oversight of the tag inventory by sending battery level to everyone.

[0048] FIGS. 2-4 are flowcharts illustrating a protocol for the system when the medical device is in the sink area, wash area, or the closet area respectively. If the processor (computer) determines that a medical device bearing a tag is in the cleaning room, near the sink or washer, it tells the sink/washer to turn on additional readings to be broadcast.

[0049] If near the sink, which is generally supposed to be the first step in the reprocessing of a medical device, the computer may tell the medical device tag to turn on and broadcast temperature and motion or movement readings. The temperature readings are preferably captured using a temperature sensor and the motion or movement readings are preferably captured using an accelerometer and/or gyroscope. Then, when near the sink, that box can tell the tag on the medical device to shut off the motion readings.

[0050] When the medical device is located in either the closet or the exam room, the box located in that room may tell the tag on the medical device to turn off the temperature/motion readings if they are not already shut off.

[0051] In FIG. 2, the sink process flow is described. In FIG. 2, the Scope Tag or Nurse Tag at the sink 10a, AER 10b, or Room 10c sends RSSI and ID Values over Bluetooth to the PD Box located above the sink. The PD sink box then collects a sample RSSI, Temperature, and movement values. It takes the average per tag of these values and with a date stamp, sends them to the PC's at that location. Every 45 seconds the PD box then sends a location check in to the SQL database and it then collects the latest tag list from the SQL database. The PD box also sends a script change check to the SQL database and if needed will update and reboot if there are any new changes to the scripts. The PD box determines from the data collected if the closest tag is at the sink PD box 120. If the tag is closest to the sink PD box, it will send a signal or call to the tag to turn on temperature and movement 120.

[0052] According to an embodiment, the RSSI values include a battery level as it is sent to the local PC SQL, through Wifi to the cloud based PC, and/or through any other suitable means. According to an embodiment, after the process is reboot 90 if there are any new changes to the scripts, it is determined if the tag is in a bad light array 91. According to an embodiment, the bad light array is an indication that an alert must be sent regarding a component; e.g., the battery. According to an embodiment, the bad light array is an indication that the battery level of the battery is low. If the tag is in a bad light array, it is determined whether the alert light is on 92. If the tag is in a bad light array and the alert light is on, the signal is sent to the PD box 20 and then to the tags. If the tag is in a bad light array and the alert light is oft a signal is sent to the PD box and then the tags to turn the alert (or bad) light on 93. If the tag is not in a bad light array, it is determined whether the alert light is on 94. If the tag is not in a bad light array and the alert light is on, a signal is sent to turn the alert light off 95. If the tag is not in a bad light array and the alert light is not on, then no signal to signal an alert is sent.

[0053] FIG. 3 describes the Washer process and method. In FIG. 3, the Scope Tag or Nurse Tag at the sink, AER, or Room sends RSSI and ID Values over Bluetooth to the PD Box located above the washer. The PD washer box then collects a sample RSSI and Temperature values. It takes the average per tag of these values and with a date stamp sends them to the PC at that location. Every 45 seconds the PD box then sends a location check in to the SQL database and then collects the latest tag list from the SQL database. The PD box also sends a script change check to the SQL and if needed, will update and reboot if there are any new changes to the scripts. The PD box determines from data collected if the closest tag is at the washer PD box. If the tag is closest then it will send a call to the tag to turn on temperature 121.

[0054] According to an embodiment, the RSSI values include a battery level as it is sent to the local PC SQL, through Wifi to the cloud based PC, and/or through any other suitable means. According to an embodiment, after the process is reboot 90 if there are any new changes to the scripts, it is determined if the tag is in a bad light array 91. According to an embodiment, the bad light array is an indication that an alert must be sent regarding a component; e.g., the battery. According to an embodiment, the bad light array is an indication that the battery level of the battery is low. If the tag is in a bad light array, it is determined whether the alert light is on 92. If the tag is in a bad light array and the alert light is on, the signal is sent to the PD box 20 and then to the tags. If the tag is in a bad light array and the alert light is oft a signal is sent to the PD box and then the tags to turn the alert (or bad) light on 93. If the tag is not in a bad light array, it is determined whether the alert light is on 94. If the tag is not in a bad light array and the alert light is on, a signal is sent to turn the alert light off 95. If the tag is not in a bad light array and the alert light is not on, then no signal to signal an alert is sent.

[0055] FIG. 4 describes the Closet process and method of the present invention. In FIG. 4, the Scope Tag or Nurse Tag at the sink, AER, or Room sends RSSI and ID Values over Bluetooth to the PD Box located in the closet. The PD closet box then collects sample RSSI values. It takes the average of these values and with a date stamp, sends them to the PC at that location. Every 45 seconds, the PD box then sends a location check in to the SQL database, and then collects the latest tag list from the SQL database. The PD box also sends a script change check to the SQL database and if needed, will update and reboot if there are any new changes to the scripts. The PD box determines from the data collected if temperature or movement is being collected from the tag 130. If the tag is transmitting temperature and movement it will send a call to the tag to turn off both sensors for temperature and movement 140.

[0056] According to an embodiment, the RSSI values include a battery level as it is sent to the local PC SQL, through Wifi to the cloud based PC, and/or through any other suitable means. According to an embodiment, after the process is reboot 90 if there are any new changes to the scripts, it is determined if the tag is in a bad light array 91. According to an embodiment, the bad light array is an indication that an alert must be sent regarding a component; e.g., the battery. According to an embodiment, the bad light array is an indication that the battery level of the battery is low. If the tag is in a bad light array, it is determined whether the alert light is on 92. If the tag is in a bad light array and the alert light is on, the signal is sent to the PD box 20 and then to the tags. If the tag is in a bad light array and the alert light is oft a signal is sent to the PD box and then the tags to turn the alert (or bad) light on 93. If the tag is not in a bad light array, it is determined whether the alert light is on 94. If the tag is not in a bad light array and the alert light is on, a signal is sent to turn the alert light off 95. If the tag is not in a bad light array and the alert light is not on, then no signal to signal an alert is sent.

[0057] FIG. 5, similar to FIGS. 2-4, illustrates present system reading the tags in an examination/procedure room. FIG. 5 illustrates the procedure. In FIG. 5, the Scope Tag or Nurse Tag at the sink, AER, or Room sends RSSI and ID Values over Bluetooth to the PD Box located in the procedure room. The PD room box then collects sample RSSI and temperature values. It takes the average of these values and with a date stamp sends them to the PC at that location. The PC, using a SQL database then sends a location check in to the PD Box. Every 45 seconds the PD box then sends a location check in to the SQL Database, and then collects the latest tag list from the SQL database. The PD box also sends a script change check to the SQL database and if needed, will update and reboot if there are any new changes to the scripts. The PD box determines from the data collected whether temperature or movement being reported or collected from the tag 150. If the tag is transmitting temperature and movement, the PD box will send a call to the tag or beacon to turn on the temperature and movement sensors 160.

[0058] According to an embodiment, the RSSI values include a battery level as it is sent to the local PC SQL, through Wifi to the cloud based PC, and/or through any other suitable means. According to an embodiment, after the process is reboot 90 if there are any new changes to the scripts, it is determined if the tag is in a bad light array 91. According to an embodiment, the bad light array is an indication that an alert must be sent regarding a component; e.g., the battery. According to an embodiment, the bad light array is an indication that the battery level of the battery is low. If the tag is in a bad light array, it is determined whether the alert light is on 92. If the tag is in a bad light array and the alert light is on, the signal is sent to the PD box 20 and then to the tags. If the tag is in a bad light array and the alert light is off a signal is sent to the PD box and then the tags to turn the alert (or bad) light on 93. If the tag is not in a bad light array, it is determined whether the alert light is on 94. If the tag is not in a bad light array and the alert light is on, a signal is sent to turn the alert light off 95. If the tag is not in a bad light array and the alert light is not on, then no signal to signal an alert is sent.

[0059] Referring now to FIG. 6, there is a flowchart illustrating a management of the medical device. The tag and subsequently the medical device preferably uses a Bluetooth wireless communication protocol. This enables communication with the box and with any other tag of the system. A check may occur to determine how many loops of the broadcast message has occurred. If a read command has been sent, the message is continued to be sent. If a read command has been sent, then the value of the message loop determines what functionality is turned on or off. Each tag may be assigned a specific code thereby identifying the particular medical device or person associated with the tag. The information after being read from the tag may reset the broadcast message.

[0060] FIG. 6 further describes the tag code. The tag broadcasts a standard Bluetooth protocol 601. The tag then determines every 10.sup.th loop of the broadcast 602. If it is the 10.sup.th loop of the broadcast, the tag will then determine if the flag set is off 603. If the flag is set oft it will then clear out any advertisement data string on characters (herein char) 14, 15, 17 set to 000 604 and return to broadcasting standard Bluetooth protocol. Char provides for fixed-length storage of strings and is the length that is an unsigned integer literal designating the length in bytes. The default length for a CHAR is 1, and the maximum size of length is 254. If flag set is on, the tag will check if flag temperature is on 605. If yes, the tag will read temperature and place value in advertisement data string on char 14, 15606 and then check if flag movement is on. If flag temperature was off, the tag will also check if flag movement is on 607. If flag movement is on 607, the tag will read movement and place the value in advertisement data string on char 17 then return to broadcast standard Bluetooth protocol 608. If off, the tag will also return to broadcasting standard Bluetooth protocol. If while checking if it's the 10.sup.th loop and it is not, the tag will then check if a read command has been sent 609. If it hasn't, the system will return to broadcasting standard Bluetooth protocol. If it has been sent, a read command it will react according to the command. For a value of 5 (610), the tag will set a flag for temperature on 611. For a value of 6 (612), the tag will set flag temperature and movement on 613. For a value of 7 (614), the tag will turn off all flags 615.

[0061] In FIG. 7, there is a flowchart illustrating management of the collected data and reporting of said data. Once the data has been captured, a check in process is performed to determine if any new devices are found within a tag reading vicinity. The information associated with each tag such as location, movement, and temperature is logged and stored by the system. Such information may be locally stored, stored in the cloud, or a combination thereof. The information allows a complete history of usage, cleaning, and other general maintenance to be ascertained.

[0062] In FIG. 7, the local PC process and flow is described. Captured data 701 is processed by the PC every 100 seconds 702. The PC's clock starts this process. The PC runs a checked in process 703. If a device is not found 704, the PC will write out device and date to the alarm table 705. If the device is found 704, the PC will scan and compile latest building table for processing 706. The PC will then scan and compile the latest tag type for processing 708. The PC will then scan and compile the last tag or beacon for processing 710. The PC will then scan and compile the latest box types for processing 712. The PC will then scan and compile the latest box for processing 714. After this, the PC will check to see if files need to be updated on the box 716. Then the PC will process the location of each tag 718. Then in order, the PC will process the temperature 720, then movement 722 and then the PC will post summary records to the cloud for processing 724. The cloud on the Internet 726 then will send out the summary data to be viewed 728.

[0063] FIG. 8 illustrates the process of finding a location room or location of the medical device. About every 5 seconds to about every 5 minutes and more preferably about every 1 minute 802, a message is sent to determine the location of the medical device. This information is preferably stored on both the cloud 726 and the local storage device at the medical facility or setting. The information is captured and stored as needed. In some instances, the data is captured and overwritten to preserve storage space and the data requirements by the system as a whole. The summary data 728 that is sent to the cloud 726 will then start a process every minute 802 that will request time last run and the last date of record processed 804. A request will be sent for all location files from the cloud for one client at time since last time run that is a room record, 806. The request will loop through a data set 808 and it will read the record 810, and then request from the total dataset the last three records for that beacon or tag 812. If a new beacon and tag is found from the last record, then it resets totals and last tag variable 816. If the total reports are 5 or less 818, then it will loop through again and repeat the steps. If more than 5 reports are found then it will determine if total reports are in 5 to 10 (820). If more than ten reports 822, then the location record will be written to final location table 824 and send to the cloud 726. If the total reports are between 5-10 (820) and the last tag is greater than 5 (826), then it will skip ahead of another loop through the dataset and repeat the process starting at reading the record 810.

[0064] In FIG. 9, alerts can be generated and sent to an electronic device (e.g. smartphone) to alert at least one individual(s) that the proper reprocessing procedure has been performed. The cloud software collects all the data from the medical facility, and preferably filters out any noise and detects the location of each device at each second. The cloud software then creates alerts (e.g. if proper sequence isn't used (sink then washer), if proper temperature isn't used, if proper time isn't spent, if scope repairs are needed or performed (scope beacon can be checked out for repairs to scope; repairs can be emergency repairs or routine maintenancenot currently required but expect to be implemented soon) (i.e. alert will be issued if scope is in repair mode).

[0065] The alerts may then go to the mobile application which should be used preferably by the system administrator and any maintenance personnel. Alerts can be cleared by the administrator, as can the repair notes; however, all of the historical data will be kept in the cloud, as will any past versions of any edits made on the app. There may also be alerts for system failure of beacons and/or device units on the app. That way the system will be aware that if units have to be swapped out and/or any medical devices have been stolen, etc.

[0066] FIG. 9 describes the Alert process in detail. The summary data that is in the cloud will then start a process every minute 902 that will request time last run and the last date of record processed 904. A request will be sent for all location files from the cloud 726 for one client at time since last time run that and hour before 906. It will loop through the data set 908 and it will read the record 910 and then run alarm type test 912. If the location is a closet 914, the system will check if the previous location is a washer 916, sink 918, exam room 920 or AER 922. If according to protocols set by client, the previous location is incorrect it will record alarms to process 926 and write the alarms to the system 928. According to an embodiment, prior to recording alarms to process 926 and writing alarms to the system 928, the file is held in a holding area 923. If the system determines that in the last five records, there was no sink 924 in the process or if the wash did not include a wash done via the AER 925, then the system will record alarms and write alarms into the system process.

[0067] FIG. 10 display another embodiment of finding a location of a particular medical device using the present system. FIG. 10 describes the Final location device process procedure. The summary data 728 that is stored in the cloud 726 will then start a process every minute 1002 that will request time last run and the last date of record processed 1004. A request will be sent for all location files from the cloud for one client at time since last time run that is a device record 1006. It will loop through the data set 1008 and it will read the record 1010. If the record states it's a station it will check if the total reports are 2 or less 1012 or 1 or 2 (1014). If yes, it will loop through the data set again. It will keep performing this until the total reports are greater than 2 (1016), then it will write or record the record to the final location table 1018. It will then request from the total the last three records for that tag 1020. If a new tag is found from the last record 1022 it will reset totals and the last tag variable 1024. If when reading the record 1010, the system determines that the tag is located in a closet 1026, and that the last record contained a sink 1028, and that there is a washer record found in the middle of the location 1030 then the washer record will be recorded 1032.

[0068] Although this invention has been described with a certain degree of particularity, it is to be understood that the present disclosure has been made only by way of illustration and that numerous changes in the details of construction and arrangement of parts may be resorted to without departing from the spirit and the scope of the invention.