WO2025199010A1

WO2025199010A1 - System for managing adherence to an intermittent catheterization regime

Info

Publication number: WO2025199010A1
Application number: PCT/US2025/020190
Authority: WO
Inventors: Badiger VISHAL
Original assignee: Hollister Inc
Current assignee: Hollister Inc
Priority date: 2024-03-21
Filing date: 2025-03-17
Publication date: 2025-09-25
Anticipated expiration: 2026-09-21

Abstract

A device for managing patient adherence to an intermittent catheterization regime and a system thereof are disclosed. The wearable device provides input and output ports for receiving input data and transmitting output data respectively. The input port includes a tag reader to receive product identification information from the urinary catheter in use. The system includes a wearable device, a catheter embedded with product identification information, a computing device, a network and/or a server. The system is configured to provide interfaces for receiving/transmitting the product identification information associated with the catheter and remote communication between the intermittent catheter user and the health care provider.

Description

System for Managing Adherence to an Intermittent Catheterization Regime

The present application claims the benefit of and priority to U.S. Provisional Application No. 63/568,321 , filed March 21 , 2024, which is hereby incorporated herein by reference.

FIELD OF THE INVENTION

[0001 ] The present disclosure generally relates to devices and systems for managing patient’s adherence to an intermittent catheterization treatment regime. More particularly, the present disclosure relates to a wearable device that receives input data and outputs output data to assist patients in managing intermittent urinary catheterization and bladder health.

BACKGROUND

[0002] Neurogenic bladder patients lack control over their bladders due to either spinal cord injury or other conditions. It is desirable for the patients to practice proper bladder management to promote bladder health. Intermittent catheterization is a procedure that includes periodically inserting a urinary catheter through the urethra and into the bladder to drain urine from the bladder. After the bladder has been drained, the urinary catheter is removed from the bladder and the urethra. Failure in complying with a regime of using intermittent urinary catheters (a common bladder management approach) as prescribed or recommended by the healthcare practitioner, usually 4-5 catheter per day, may result in an increased risk of poor bladder health, such as increased risks of infection. Not having the bladder emptied in a timely manner can cause multiplication of contaminant bacteria in the bladder for a prolonged period, which can result in various complications, including but not limited to, bladder infection, vesicoureteral reflux further developed from bladder overfilling and/or high bladder pressures. Vesicoureteral reflux is a condition in which urine flows backwards from bladder into one or both ureters and sometimes, in severe cases, into kidneys.

[0003] Thus, there remains a need for systems and devices that assist in supporting the users to meet their daily intermittent catheterization schedule as prescribed and educating users about the potential risk associated with a poor intermittent catheterization regime. SUMMARY OF INVENTION

[0004] There are several aspects of the present subject matter which may be embodied separately or together in the devices and systems described and claimed below. These aspects may be employed alone or in combination with other aspects of the subject matter described herein, and the description of these aspects together is not intended to preclude the use of these aspects separately or the claiming of such aspects separately or in different combinations as set forth in the claims appended hereto.

[0005] In one aspect, a smart wrist band for intermittent urinary catheter users includes a housing configured to be worn on a wrist of an intermittent urinary catheter user. The housing includes at least one input port configured to receive input data and at least one output port configurated to transmit output data; and the at least one input port comprises a tag reader configured to receive tag input data from a tag associated with a urinary catheter, wherein the tag includes at least one catheter identification information of the urinary catheter.

[0006] In another aspect, a system for managing intermittent catheter use includes a product identification information transmitting subsystem comprising a tag containing at least one identification information associated with the catheter; and a tag reader configured to retrieve the at least one catheter identification information associated with the catheter from the tag; and a wearable device comprising a housing having at least one input port to receive input data and at least one output port to transmit output data; the at least one input port includes configured to receive input from the user; and the at least one output port configured to transmit output to the user; the at least one input port including the tag reader further configured to receive the input data including the at least one catheter identification information associated with the catheter from the tag.

BRIEF DESCRIPTION OF DRAWINGS

[0007] Fig. 1 is an exemplary system for managing a patient’s intermittent catheterization regime.

[0008] Fig. 2a is a perspective view of an exemplary wearable device.

[0009] Fig. 2b is bottom view of an exemplary wearable device.

[00010] Fig. 3 is a schematic block diagram of an exemplary system including a wearable device having a processor and other active components connected thereto.

[0001 1] Fig. 4 is a flow diagram illustrating one implementation of a system for triggering alert system in accordance with different time status for catheterization [00012] Fig. 5 is a block diagram illustrating an exemplary external computing device.

DETAILED DESCRIPTION

[00013] The embodiments disclosed herein are for the purpose of providing a description of the present subject matter, and it is understood that the subject matter may be embodied in various other forms and combinations not shown in detail. Therefore, specific embodiments and features disclosed herein are not to be interpreted as limiting the subject matter as defined in the accompanying claims.

[00014] Devices for managing users’ adherence to an intermittent catheterization regime and/or managing bladder health and the system thereof according to the present disclosure and their individual components may be variously configured without departing from the scope of the present disclosure, but in one embodiment, a management system is configured as shown in Figure 1 .

[00015] As will be described in greater detail herein, a system for managing a patient’s adherence to an intermittent catheterization regime includes a digital health app (mobile app) executed in a computing device, a monitoring device and server. The system provides a hybrid platform for the patient and health care provider to monitor intermittent catheterization and empower interaction between the patient and health care provider to facilitate an effective catheterization regime, which is implemented to improve the patient’s bladder health. In a specific use, the management system serves as an intermittent catheterization reminder that notifies the patient as to the need to timely initiate an intermittent catheterization procedure. The system may have multilevel alerting and/or messaging capabilities. For example, the system may alert the patient about the need to take an action, and if the patient does not respond, the management system may send a further alert to the patient to indicate that the patient did or did not take the expected action. The system may also provide automated realtime information of a patient's catheterization time status/schedule, thus assisting the patient in adhering to a prescribed catheterization regime.

[00016] One part of the management system 10 is the mobile app, which may provide a user interface for a computing device to be used by the patient. In the case where the monitoring device 12 is not with the patient, the mobile app may provide the ability to send real-time reminders to the patient and a monitoring service that allows real-time alerts (notifications or text) to be sent to one or more destinations (e.g., telephone numbers, e-mail addresses, URLs, etc.) of remote health caregiver and others. This could, for example, allow healthcare professionals to remotely monitor the patient's adherence to the recommended catheterization schedule and allow the patient to respond to the messages or alerts.

[00017] Fig. 1 illustrates an exemplary intermittent urinary catheterization management system 10, which includes a wearable device 12 adapted to be worn by a person at different locations on the wearer's body (i.e., the wearer being the person who monitors his/her catheterization schedule). The PCB substrate (not shown), having the active components mounted thereon and employed in the monitoring device 12 is flexible and designed to be bendable. Therefore, it provides the wearable device 12 a degree of flexibility to be shaped as, e.g., a strap, wrist band, ring, bracelet, wrap, etc. for encircling around the wearer’s body such as wrist, ankle or neck. The wearable device may also be placed around an apparatus used by the user, such as a wheelchair handle or bedrail.

[00018] In an exemplary embodiment, the wearable device is a wrist-worn device, such as wristband 12 as illustrated in Figs. 1 , 2a and 2b. The wristband 12 is designed so that the user can remove the device from the wrist and put the device back on the wrist again as with any wristband, such as a conventional wristband for a common watch. For ordinary watches this typically is accomplished by either of two mechanisms. One common design is an elastic band that the user can stretch while removing the watch or putting it on. A second common design is to use a releasable fastening, such as, for example, a clasp or buckle.

[00019] Wristband 12 can be made of any suitable material. For example, the materials may be, but are not limited to, leather, vinyl, rubber, thermoplastic polyurethane (TPU), silicone or other similar material that provides the wristband 12 sufficient flexibility to be folded. In an exemplary embodiment, the wristband 12 may provide comfort to the user, an aesthetic appearance, and added strength to the antenna and circuitry.

[00020] Optionally, system 10 may include a portable computing device 18 (mobile phone, smartphone, tablet, etc.). The wearable device 12 is capable of wirelessly communicating with a urinary catheter 14 tagged with catheter identification information (CID) via product identification sensing system such as RFID, barcode or QR code.

[00021 ] The wearable device 12 houses circuitry interacting with the urinary catheter 14 at a first interface or receiving interface configured to provide an input port or channel to receive the identification information stored in the RFID tag on the package of the catheter 14. Optionally, the circuitry provides communication module to allow communication between the wearable device 12 and external computing device 18 at a second interface or transmitting interface. The second (transmitting) interface is configured to provide an output port or channel to transmit data from the wristband 12 to the computing device 18 by establishing communication link therebetween within system 10.

[00022] The wearable device 12 is configured for wireless communication via accessory connection 19 with the portable computing device 18. Optionally, the computing device 18 is configured to communicate with a server 20 of the management system 10 e.g. via network 1 1 such as cloud-based network. The computing device 18 may be wirelessly connected via network 1 1. The server 20 may be operated and/or controlled by the catheter manufacturer and/or a service center. Identification information associated with the catheter 14 is obtained from a reader or scanner depending on the choice of the product identification sensing/transmitting system (which will be described in more detail below) included in the circuitry of the wearable device 12. The wearable device 12 processes the identification data of the catheter 14 which will be transmitted to the computing device 18 via the accessory connection 19. In the illustrated management system 10, the computing device 18 is a mobile phone, however the computing device 18 may be embodied as another handheld device, such as a tablet device, or a wearable, such as a watch or other wrist-worn electronic device. Accordingly, the wearable device 12 is configured to transmit the identification data such as catheter (CID) and user’s identification information (UID) and/or daily logged time for catheterization to the computing device 18.

[00023] Figs. 2a and 2b illustrate different views of an exemplary wearable device 12. The wearable device 12 having a housing 100 enclosing a receiving interface having at least one input port and a transmitting interface having at least one output port communicating with the user. The input port(s) are configured to receive input from the user and the output port(s) are configured to transmit output to the user. The at least one of the input port(s) may include a reader or scanner 140 configured to communicate with the tag/label and retrieve the identification information associated with the catheter from the tag when the catheter with its corresponding tag is brought to a defined range depending on the type of product identification sensing/transmitting system employed by the wearable device. The product identification sensing/transmitting system may be a contactless identifier technology. For example, the sensing/transmitting system may be: (i) optical label codes such as barcodes or QR codes and (ii) tag identifier such as RFID tag. Both of which include or contain embedded information, such as product details, manufacturing date and batch information etc. In embodiments that use an RFID system, RFID tag 15 on the catheter 14 receives signal from the reader/scanner 140 in the wearable device 12 and the tag 15 responds to the reader/scanner 140 with the identification information requested. In another exemplary embodiment, NFC is used in the communication between the terminal (wearable device 12) and the tag 15. Both RFID and NFC are similar contactless communication technologies for product identification but differ by the range of communication. RFID can be used to receive and transmit radio waves over distances of 100 meters or more (for active tags equipped with on-board battery), NFC is limited to no more than 20 cm. For example, in the illustrated embodiment, wearable device 12 is wirelessly communicating with RFID tag on the urinary catheter 14.

[00024] In an exemplary system, identification information associated with the catheter 14 (CID) is unique and can be obtained from the catheter tagged with an RFID on its package, for example. The tag 15 can be placed anywhere peripheral to the catheter without departing from the scope of the present disclosure. The CID is interactive with other on-board electronics in wearable device 12 and with the user in the computing device 18.

[00025] The person having such a wearable device 12 and whose catheterization is being managed or monitored is referred to as the user but it should be understood that the device might be used unchanged in situations where the person catheterizing, the person monitoring, and the person evaluating feedback need not all be the same person. It will be understood that the wearable device 12 and the system 10 may be used to generally track catheterization schedule and catheterization patterns. For example, when a person is providing assistance to a catheter user, the person providing assistance may wear the wearable device 12.

[00026] Optionally, the at least one input communication port may include power terminal 104, power switch 1 11 and RFID reader/scanner 140, and the output communication ports may include visual indicators LEDs 108, 110, 112, buzzer/vibrator or speaker 105, wireless transceiver module 124 as illustrated in Fig.3. The first (receiving) interface is therefore an entryway for data and/or power input, whereas the second (transmitting) interface is an exit for processed data output.

[00027] These are the exemplary input/output (I/O) communication ports employed in system 10 of the present disclosure. Depending on the nature of the bladder health management designed for a subject, and the principles described herein, the system 10 and/or wearable device 12 may be employed with other I/O communication ports without departing from the scope of the present disclosure.

[00028] Now turning to the active components enclosed in the housing 100 as illustrated in Fig. 3, which include a processor 101 , and active components connected thereto including but not limited to a memory 1 16, at least one I/O ports aforementioned, and a charging circuitry 121. Processor 101 is configured to communicate with the RFID reader 140 and process at least one identification information associated with the catheter received by the reader 140. Optionally, processor 101 may be programmed to map the identification information associated with the catheter (CID) with the user’s identification information (UID) preprogrammed in processor 101. The uniqueness of mapping of CID with UID may be inherent from the unique nature in both CID and UID. The CID mapped with the UID may be saved and logged in memory 1 16. Optionally, processor 101 may have an on-board timer 102 configured to be set with a value of zero at the initial catheterization. Timer 102 may be configured to characterize or set the time status for catheterization and each alert defined in the alert system which will be discussed in more detail below.

[00029] Product identification information transmitting subsystem

[00030] The present disclosure also includes a product identification, sensing, and tagging subsystem that allows wearable device 12 to identify the catheter 14 being used by interacting with the tag 15 associated with the catheter 14. In one embodiment, the interaction is retrieval of at least one identification information associated with catheter 14. The information may be contained in a tagged, labeled or some other appropriate information storage element associated with the catheter 14 and/or the catheter package and can be read or otherwise obtained by wearable device 12. Two types of contactless identifier technology that may be used by wearable device 12 or the subsystem include: (i) optical label codes such as barcodes or QR codes and (ii) tag identifier such as RFID tag. Both of which include or contain embedded information, such as product details, manufacturing date and batch information etc. [00031] In an exemplary system, the product identification transmitting subsystem may employ RFID tagging. RFID uses radio waves (radio frequency RF) to identify, track, and manage an object. RFID may include three main components: RFID tags, RFID readers, and a backend system for data processing and management. RFID tag 15 is a small electronic device with an antenna 15a and a microchip 15c. The microchip 15c stores unique identification data, which can range from a serial number to more complex information about the tagged object. In some embodiments, antenna 15a is a single turn coil. However, antenna 15a may have multiple turns (two or more) or loops or other configurations, as may be required for different power levels and/or operating frequencies.

[00032] Reader 140 included in wearable device 12 may have at least one antenna that emits radio waves and receives signals back from the RFID tag 15 within a predefined range. Reader 140 sends out radio waves, which activates the RFID tag 15 within the predefined range. Tag 15 responds by transmitting its unique identification data associated with catheter 14 back to the reader 140. RFID tags can be passive or active depending on the nature of the application. Active RFID tags are powered by an on-board battery and periodically transmits its ID signal. Passive RFID tags, while having a small battery on board, are activated in the presence of the RFID reader.

[00033] The data collected by RFID reader is sent to a backend system for processing, storage, and analysis. The backend system may include software applications such as a mobile app in the computing device 18 and databases linked to the medical device (catheter) manufacturers that manage the RFID data, such as inventory databases, to ensure integrity and uniqueness of the catheter being used, and ultimately the uniqueness of mapping CID and UID, to avoid conflicting data or overwriting data unnecessarily. The data collected from RFID tag can be integrated with other systems such as health care systems to provide real-time visibility for the health care provider to adjust the regime (if necessary) so that the treatment efficacy can be improved.

[00034] In one alternative, the subsystem may employ one type of label coding of QR codes having the visual representation of the data in the form of geometric patterns and spaces. Hardware-wise, wearable device 12 may be equipped with a scanner specialized for reading the QR codes pattern. Software-wise, processor 101 may include a QR code scanning and decoding software to retrieve catheter information from the code. Depending on the nature of application, the information stored and encoded in the QR code may include various types of information associated with the product (i.e. catheter in the present disclosure), such as product details, serial numbers, manufacturing dates, expiration dates, and links to additional resources like manuals or support pages.

[00035] In another alternative, the subsystem may employ another type of label coding barcodes having the visual representation of the data in the form of parallel lines and spaces. Wearable device 12 may include an optical barcode scanner having a light source to decode the information encoded in the barcode. The decoded data is then sent to processor 101 for further processing.

[00036] Alert System - Events Triggered by Timer

[00037] Upon the detection of an initial catheterization event, periodic multiple alerts may be sent to the patient (before the next catheterization event) to remind the patient of the next catheterization event. These alerts may be in the forms of visual, audio or haptic/vibration or a combination thereof. The choice of alert type or combination depends on various factors such as user preferences, the context of use, and accessibility consideration. For example, a visual alert may be used for applications where immediate attention is needed. Audio alert is effective in situations where immediate attention is required, and users can hear the alert without paying attention to visual indicator. Haptic vibration alert may be used for users who may need to be discreet or when neither visual nor audible alert is suitable. Alternatively, a combination of visual, audio and haptic alerts may be implemented for a more comprehensive notification/alert system. In some variations, the wristband device 12 may utilize the indicators to alert the user regarding device/battery power status, communication status, combinations thereof, and the like. For example, a visual indicator may include an LED or LCD configured to display battery life, operation status, and communication status.

[00038] In an exemplary system, the visual alert may illuminate or show in one color. In some embodiments, the visual alert system may use or show at least two colors or at least three different colors. In the illustrated embodiment, the visual alert system (and thereby the wearable device 12) includes illumination elements 108, 1 10, 1 12, as illustrated in Figs. 1 and 2a. The illumination elements may be LEDs or any other suitable light source. Additionally, the illumination elements may have different frequencies designating different time statuses for catheterization or for the user to take some other action, such as charge the wearable device, synchronize the wearable device with the mobile device, attend to a device error, etc.

[00039] Optionally, wearable device 12 may include additional LEDs to indicate the count for catheters used during the day. In an exemplary system, more than one static LEDs may be included to indicate the used catheters count. A first static LED indicating the first catheter used may be activated as soon as after the first catheter has been scanned and the UID and CID have been mapped successfully. The number of indicators (i.e. static LEDs as exemplified) representing the used catheters count provided on the wearable device 12 may be any suitable number. For example, in system the number of indicators may be four to five based on the recommended intermittent catheterization frequency 4 to 5 times daily according to common practice. Due to limited space available on the wearable device, optionally a digital display such as mini LCD may be incorporated. In another exemplary system, the alert operation may compare the used catheters count to the required daily catheterization frequency predefined in the system. If the count is equal to the predefined catheterization frequency, the alert cycle comes to an end and/or resets.

[00040] Fig. 4 is a flow diagram illustrating one method of alert system operation 400 for triggering the alert system in accordance with different time statuses for catheterization. As indicated in block 402, the initial catheterization may be started with all alerts being deactivated and/or cleared. Each user in the system is assigned a unique user ID and each product (catheter) is associated with a unique product ID. One way to implement assigning the user with a unique ID may include having the unique UID pre-programmed as shown in block 404 in processor 101 having an on-board timer 102. The unique combination key includes UID mapped with the catheter identification information CID and the time stamp at the occurrence of the mapping retrieved from the system clock. The mapping of these IDs indicates which catheters the user is associated with or using during catheterization and serves as unique identifiers, and together with the logging time stamp, all the information will be accessed by the user for review at a later time. The unique combination key (UID mapped with CID together with the time stamp at mapping the identifiers) ensures that each catheter a user associates with is logged only once per user, preventing duplication or confusion in the review process. [00041] The alert system operation may include keeping track of the number of catheterization on that day by checking the used catheters count in each alert cycle. In doing so, the method may have the used catheter count (denoted as Count Catheter) predefined as zero and a maximum catheter count (denoted as Count_max) predefined as associated with the recommended catheterization frequency (e.g. 4 or 5 counts per day) as shown in block 404. These predefined settings may be used at a later stage in the alert cycle for determining if the used catheters count reaches the required daily frequency and thereby allowing the alert cycle to come to an end.

[00042] In block 406, the tag reader 140 may be configured to detect and scan the catheter tag 15 when it is within a range of detection designed in the product (catheter) identification information (CID) transmitting subsystem. Such configuration may be implemented in a manner which allows the system to continuously detect any tag containing CID that comes into the vicinity of the tag reader 140 and within the range of detection according to the chosen product identification transmitting protocol, such as RFID, as exemplified in the present disclosure.

[00043] In block 408, CID is received by the tag reader 140 and the system 400 is prepared to proceed with further processing based on the information (assuming it is determined that CID is received successfully in processor 101 via the reader 140). In 408, the system may also be configured to clear any alerts triggered previously.

[00044] In decision block 410, processor 101 may be configured to determine whether CID has been received successfully. The determination may be indicated by visual indicators, audio indicator, haptic indicator, or combination thereof. In an exemplary system, a visual indicator, e.g., green LED 108, may be illuminated, optionally with a single blink, to signal the completion of successful scanning and mapping ID information in block 414. Alternatively, a long vibration can be felt indicating the successful scanning and mapping information. Optionally, an audible indicator such as a beeping sound may be used to notify the user about the successful scanning and mapping information. Upon successful scanning and mapping the UID and CID as shown in block 414, the timer value t may be set to zero as shown in block 416. On the contrary, the system may encounter difficulty in receiving CID in at least two situations: (i) the catheter tag 15 has not been scanned successfully as shown in block 410; or (ii) the first catheter is scanned and found contaminated under any circumstances as presented in block 418. Both of which may allow for another read-in event 408, only differ by situation (ii) having bound by time constraint whereas situation (i) not. In situation (i), if it is determined that the tag has not been read successfully, the user may re-scan the initial catheter as illustrated in block 412. The re-scanning of the initial catheter may be continuous without any constraint until the CID in the tag is read successfully. In situation (ii), if the first scanned catheter is determined to be contaminated, the user may scan a new catheter as shown in block 419. In an exemplary system, scanning the new catheter in 419 may be imposed with a predefined time constraint. Processor 101 may be pre-programmed with a preset time off timer value in 404 designating a time window for scanning the new catheter in block 419. In block 420, the alert system operation 400 may determine if the system has reached the time off for scanning the new catheter. The determination may be implemented by comparing the elapsed time between scanning the first (initial) catheter and the second (new) catheter to the preset time off period. If the elapsed time is less than the preset time off period, then the system is configured to allow for reading in the information from the tag of the new catheter as provided in block 408. Any alert indicator triggered during scanning the initial catheter may be cleared at this point in 408. Otherwise, the alert system operation may set the system timer off in 423 and end as shown. Optionally, the user may reboot the system by turning the power switch off and turning it back on to restart the alert operation. In an exemplary system, if the system determines that the CID of the second (new) catheter has been captured by the tag reader 140 successfully, processor 101 may be configured to map CID of the second (new) catheter with UID as provided in block 414. In that case, processor 101 may be configured to overwrite the identification information of the first catheter with that of the new second catheter and to map the second CID with the UID. In another exemplary system, the time off is preset as 300 s (i.e. 5 mins). In a situation where a user determines that an initial catheter is contaminated after it is scanned (timer value t=0 s as soon as the catheter is scanned and CID is mapped with UID), the user may scan a new catheter within the time window, for example at t=68 s. The time lapse between scanning the first (initial) catheter and the second (new) catheter (i.e. 68 s) is less than the preset time off 300 s. In other words, the system has not reached the time-off. Therefore, when the system detects the scan of the new catheter, the CID of the new catheter overwrites the CID of the initial catheter prior to mapping information. On the contrary, if the first (initial) catheter is received successfully without contamination in 418, the system may be configured to increment the used catheter count by one (1 ) as shown in block 421 . At this point, the system may check if the used catheter count reaches the maximum catheter count in decision block 422. One way to implement checking the used catheter count may include comparing Count_Catheter to Count_max. If Count_Catheter equals to the preprogrammed Count_max in 422, the system may turn off the timer in 423 and allow the alert operation end as shown. Otherwise, the system may proceed to trigger alert according to the time status of catheterization.

[00045] The alert system as disclosed herein may include a plurality of alert cycles represented by corresponding indicators. Duration of each alert cycle may be preprogrammed or preset in the system, essentially in processor 101. In an exemplary system, three visual indicators green, yellow and red LEDs 108, 110, 112 may be used. In block 424, a first alert indicated by illuminating for example green LED 108, may be activated for a preset period of time (denoted as PT_alert_1 -2), e.g., 2 hours or 120 minutes when the tag reader 140 retrieves the identification information from the tagged catheter 14. The illumination of green LED 108 may pulse or blink with a certain frequency (denoted as first alert frequency Alert_F_1 ), for example, every 30 minutes after mapping the IDs in 414 and upon resetting the timer to zero in 416. In decision block 426, the system may determine if the alert is acknowledged by the user based on whether catheterization has been taking place, and thereby deactivate the alert as provided in block 402. Otherwise, the timer 102 continues to increment, and the system determines whether the system reaches an end of the first alert in block 430. If the system determines that the alert is not acknowledged by the user in 426 and the system has not come to the end of first alert cycle in block 430, the timer 102 will continue to increment, the alert operation returns to block 424, where the first alert remains activated, and the alert system will look for alert acknowledgement in decision block 426. On the contrary, if the first alert is not acknowledged by the user in block 426 and the system comes to the end of the first alert cycle in block 430, the system will transit to a second alert cycle and a second alert may be activated in block 432. One way to determine the end of first alert cycle in block 430 is to compare the instant timer value t to a preset period of time for having the first alert activated PT_alert_1 -2 (i.e. 120 minutes in the example). In one embodiment, if the timer value t equals to or greater than PT_alert_1 -2 (120 minutes in the example), then the system transits to a second alert cycle and activates a second alert in block 432, wherein the timer value t is 0+120 minutes. At this point the first alert may be deactivated.

[00046] In block 432, the second alert, indicated by illuminating for example yellow LED 1 10, may be activated for a preset period of time (denoted as PT_alert_2-3), e.g. 45 minutes after the first alert cycle terminates, where the timer value t is 0+120 minutes as exemplified. The yellow LED 1 10 may be illuminated with a blinking frequency (denoted as second alert frequency Alert_F_2), e.g., every 15 minutes after the second alert is activated. The alert may be acknowledged by the user as shown in decision block 434 by initiating catheterization. The system may determine if catheterization is initiated at any point before the third alert is activated. If it is determined that the user initiates catheterization by scanning the tag on a new catheter, the yellow LED 110 (second alert) and/or any previous alerts may be deactivated as provided in block 402. Otherwise, the timer 102 continues to increment and the alert system operation 400 determines whether the system reaches an end of the second alert in block 438. If the alert is not acknowledged by the user in 434 and the system has not come to the end of second alert cycle in block 438, the timer 102 will continue to increment, the alert system operation 400 will return to block 432, where the second alert remains activated and the alert system will look for alert acknowledgement in decision block 434. On the contrary, if the alert is not acknowledged by the user and the operation 400 comes to the end of the second alert cycle in block 438, the alert operation will transit to a third alert cycle and a third alert may be activated in block 440. One way to determine the end of second alert cycle in block 438 is to compare the instant timer value t to the sum of the preset period of time for having the first alert activated (PT_alert_1 -2) and the preset period of time for having the second alert activated (PT_alert_2-3). In one embodiment, if the timer value t equals to or is greater than the sum of PT_alert_1 -2 (120 minutes as exemplified) and PT_alert_2-3 (45 minutes as exemplified), wherein the timer value t is 0+165 minutes, then the operation transits to a third alert cycle and activates a third alert in block 440. At this point the second alert may be deactivated.

[00047] In an exemplary system, the third alert may be represented by continuously lit red LED 1 12 without blinking for a preset period of time (denoted as PT_alert_3-1 ), e.g. 15 minutes, when the second alert cycle terminates, where the timer value t is 0+165 minutes as exemplified. The alert may be acknowledged by the user as shown in decision block 442 by initiating catheterization. The system may determine if catheterization is initiated at any point during the time when the third alert is activated. If it is determined that the user initiates catheterization by scanning the tag on a new catheter, the yellow LED 110 (second alert) and/or any previous alerts may be deactivated as provided in block 402. If the third alert is not acknowledged in decision block 442, the system may determine if a snooze is selected by the user in block 444. If no snooze is detected and the alert system operation 400 has not come to an end of third alert cycle in block 448, the timer 102 will continue to increment, the alert operation 400 will return to block 440, where the third alert will remain activated and the system will look for alert acknowledgement in decision block 442. Otherwise, if the alert is not acknowledged by the user in 442, the snooze is not selected in 444 and the alert system operation 400 has come to the end of third alert cycle in block 448, the alert operation may end as shown. One way to determine the end of third alert cycle is to compare the instant timer value t to the sum of the preset periods of time for having the first, second and third alert activated (i.e. 0+180 minutes in the example). In one embodiment, if the timer value t is equal to or greater than the sum of PT_alert_1 -2, PT_alert_2-3 and PT_alert_3-1 (i.e. 180 minutes in the example), then it is determined that the third alert cycle is ended.

[00048] While the algorithm for determining the completion of the alert cycle as disclosed herein is based on comparing the instant timer value t with the sum of the preset periods of time associated with the previous and present alerts, alternate arithmetic operation defining the end of an alert cycle may be implemented according to any suitable approach based on the applicable parameters without departing from the scope of the disclosure. For example, in some embodiments, the timer 102 may be reset to zero when the alert operation is transitioning to any subsequent alert after the first alert, e.g. in blocks 432 and 440. That way the algorithm may be simplified by comparing the instant timer value t with the preset period of time for the present alert instead of the sum of preset periods of time for previous and present alerts in determining the completion of alert cycle.

[00049] Snoozing Feature in Last Alert in the Alerting Cycle

[00050] Optionally, the system may include a mechanism, such as a snooze feature, which allows the user to temporarily delay or postpone the alert without disrupting their current activity. This feature acknowledges that the activity the user engaging in is important or time-sensitive and provides the user with the flexibility to manage the alert effectively without departing from the intended purpose of the present disclosure - aiding the user to adhere to an intermittent catheterization treatment regime. The snooze feature may be triggered by a dedicated button/switch separate from the power switch. Alternatively, to minimize hardware complexity, the system may be designed to use the power switch as an input for activating the snooze. Specifically, processor 101 may be configured to recognize or detect a momentary press or a specific pattern from the power switch to trigger a snooze action.

[00051] Turning now Fig. 4 again, if a snooze is recognized by the system via the user hitting snooze button or power switch on the wearable device 12, the system enters snooze mode for a preset snooze cycle time period (denoted as PT_snooze_cycle), e.g., 60 minutes. The snooze mode may be available at any point during the last (e.g. third as exemplified) alert cycle. The snooze cycle includes a plurality of snooze intervals. Therefore, duration of snooze interval is within the duration of snooze cycle. The operation 400 may be configured to preset a snooze interval time period (denoted as PT snoozeJnterval), e.g. 15 minutes. In this implementation, the snooze cycle has four snooze intervals. The user may choose to initiate catheterization at any point within the snooze cycle. Upon entering into snooze mode, the instant timer value t is recorded as snooze time initiated by the user (denoted as ST user init) designating a starting time of a snooze cycle, which will be stored in memory 1 16 in block 446 for later use in determining when the snooze cycle ends. Then the snooze interval starts by recording the instant timer value t as snooze interval time (denoted as STJnterval), which will be stored in memory 1 16 in block 450 for later use in determining when a snooze interval ends.

[00052] In block 452, the third alert is disabled for the preset snooze interval time period PT_snooze_interval before the snooze interval ends. Timer value t continues to increment within the snooze cycle and is used in determining when the snooze interval and snooze cycle end within the respective nested event loops. After the third alert is disabled in 452, the alert system operation 400 may first determine if the snooze interval is not over in block 454. One way to determine the snooze interval is not over in block 454 is to compare the instant system timer value t to the sum of the snooze interval time STJnterval and the preset snooze interval time period PT snoozeJnterval. In one embodiment, if the instant system timer value t is less than the sum of STJnterval and PT snoozeJnterval, then the snooze interval period is not over and the operation 400 returns to block 452 to continue disable the third alert. Otherwise, the snooze interval is over and the operation 400 proceed to determine if it is the end of snooze cycle. One way to determine the snooze cycle is not over in block 456 is to compare the instant system timer value t to sum of the snooze time initiated by the user ST user init and the preset snooze cycle time period PT_snooze_cycle. In another embodiment, if the instant system timer value t is less than the sum of ST user init and PT_snooze_cycle, then the snooze cycle is not over and the operation 400 may proceed to determine if catheterization is initiated in block 458. If no catheterization is initiated, the operation 400 may activate the third alert in block 460, return to record timer value as STJnterval in 450 and proceed to another snooze interval in 452 and 454 until the snooze cycle is over in 456. If the system determines that the snooze duration is over, the system will exit the snooze cycle and the alert system operation ends as shown.

[00053] When the alert system 400 operation ends as shown and exits the alert and/or snooze cycle, optionally, the third alert may or may not be deactivated. Optionally, the system may be configured to transmit an alert signal requiring immediate action from the user to the computing device 18 (at this point, the wireless communication port in the computing device 18 is assumed opened) and communicate with the health care provider, via the digital health app (mobile app) equipped in the computing device 18, about the user’s delay in catheterization. The health care provider thereby provides timely reminder to the catheter user to catheterize immediately.

[00054] In another exemplary system, the alerts can be in the form of vibrations via buzzer 105. For example, a first vibration alert with a pulse of first alert frequency, e.g. every 30 minutes may be activated, for a preset period of time PT_alert_1 -2, for example 120 minutes, from mapping of the IDs (i.e. timer value t is reset to zero in block 416). The system may determine if the first vibration alert is acknowledged by the user based on whether catheterization has been initiated, and thereby the alert is deactivated. If the first vibration alert is not acknowledged by the user and the first alert cycle is not over, the first alert remains activated and the timer continues to increment until the timer value t reaches the preset period of time PT_alert_1 -2, (i.e. 0+120 minutes). If the first vibration alert is not acknowledged by the user and the first alert cycle is over, then a second vibration alert with a pulse of second alert frequency, e.g. every 15 minutes may be activated for a preset period of time PT_alert_2-3 (e.g. 45 minutes). The system may determine if the second vibration alert is acknowledged by the user based on whether catheterization has been initiated, and thereby deactivates the alert. If the second vibration alert is not acknowledged by the user and the second alert cycle is not over, the second alert remains activated and the timer continues to increment until the timer value t reaches the sum of PT_alert_1 -2 and PT_alert_2-3 (i.e. 0+165 minutes as exemplified). If the second vibration alert is not acknowledged by the user when the second alert cycle is over, where timer value t is 0+165 minutes, the alert system operation may transit to third alert cycle to activate a third vibration alert. The third vibration alert may be configured as continuous vibration with or without pulse, for a preset period of time (denoted as PT alert 3-1 ), e.g. 15 minutes, until another tagged catheter is scanned for the next catheterization, the third vibration alert may then be deactivated. Otherwise, the third alert remains activated and the timer continues to increment before the system comes to an end of the third alert cycle. The system may determine if the third vibration alert is acknowledged by the user based on whether catheterization has been initiated, and thereby the alert is deactivated. If the third vibration alert is not acknowledged by the user and the third alert cycle is not over, the third alert remains activated and the timer continues to increment until the timer value t reaches the sum of PT_alert_1 -2, PT_alert_2-3 and PT_alert_3-1 (i.e. 0+180 minutes as exemplified). If the third vibration alert is not acknowledged by the user when the second alert cycle is over, the alert system operation may come to an end.

[00055] Optionally, if the third alert cycle is over, where timer value t is 0+180 minutes, the alert system operation 400 may transmit an alert signal requiring immediate action from the user to the computing device 18 (at this point, the wireless communication port in the computing device 18 is assumed opened) and communicate with the health care provider, via the digital health app (mobile app) equipped in the computing device 18, about the user’s delay in catheterization. The health care provider thereby provides timely reminder to the intermittent catheter user to catheterize immediately. Other settings for the intensity of vibrations and the snoozing feature disclosed herein may be employed without departing from the scope of the present disclosure. Optionally, the user or health care provider can select the length of vibration or beeping sound through configuring the mobile app subscribed with the medical device (catheter) manufacturers.

[00056] Depending on the preference of the user and/or accessibility considerations of the health care provider, other timer value settings for activating plurality alerts via indicators of any sort or combination may be preprogrammed and employed without departing from the scope of the present disclosure.

[00057] Processor 101 includes the hardware that, with the support of program memory and random access memory (RAM) communicates with tag reader or label scanner, receives the CID data, processes the data, stores the processed data in memory, communicates with a transmitter or directly to the database server system 20 via the computing device 18, and manages the power source. Memory 116 may store the processed data until successful transmission of the data to the external computing device 18 is confirmed. The data structure may be the identification data (UID/CID) and/or daily logged time for catheterization.

[00058] The transceiver module 124 provides communication between the wearable device 12 to the computing device 18. The transceiver module 124 may a transmitter or transceiver having short-range transmission protocol (such as Wi-Fi®, Ethernet, Bluetooth®, NFC, RFID, fiber optics, cellular, infrared or other optical communications, or the like) to transmit data wirelessly. In one embodiment, short range radio frequency (RF) principles may be used. In various examples, the communication module may have its internal on-board memory 126, a controlling unit 128 and antenna 122. The communication module receives the identification data ID_D generated from processor 101 , recording it in memory 126 for further processing by the controlling element 128. The controlling element 128 generates a transmission signal embedded with the identification data ID_D to be transmitted to the external computing device via antenna 122.

[00059] Other devices, systems, or means for connection/communication between wearable device 12 and other devices or computers are also possible. For example, wearable device 12 may include a communication port, such as, C-type USB, and/or may be tethered to a device or computer through a wired connection. Wearable device 12 or the computing device with which the monitoring device 12 communicates may optionally be connected to a network (e.g., the internet or a local network) and the data may be shared with and/or processed by other devices or computers connected to the network.

[00060] For example, the external computing device is equipped with algorithm such as mobile app to convert the identification data ID_D to meaningful information, for example, reprocess the data, store the data, retrieve analyzed data and generate catheterization diary log or report for the user and/or health care provider to review and determine how well the patient adheres to recommended catheterization regime. In other examples, summary of catheterization diary log is transmitted to the server. In another example, the transceiver module 124 transmits raw data to a cloud network 1 1 and/or server 20, or another device. In another example, the computing device transmits filtered data to a server 20, or other device for further analysis of the data.

[00061] Additionally, it should be noted that various methods and operations are described as being executed by the sensor and processor 101 in the monitoring device 12 is primarily executing digitized analog signal and processing the digitized data to a format which is ready to be transmitted to external computing devices. Other executions such as user application may be executed in full or in part in the computing device processing element, or other processing elements associated with the healthcare provider device. Discussions of a particular processing element are meant as illustrative only.

[00062] Charging and Power Supply to Device

[00063] Referring to Figs. 2b and 3, the monitoring device 12 comprises a charging circuitry 121 for charging and/or powering the device 12 and active components thereof, i.e. the charging circuitry 121 is connected to a built-in battery (not shown), the power switch 1 1 1 , the charging terminal 104, a fuse (not shown) and the processor 101. In an exemplary embodiment, the charging circuitry is hardwired connecting to a charging terminal 104 or communication port (not shown) disposed on the first interface for wired charging the battery. The charging terminal 104 may be terminal port available in the industry, such as C-type USB. Optionally, the communication port/power terminal 104 may also act as a connection to an external power source or wired communication channel. In one embodiment, the processor 101 acquires the status information of the battery; and on the basis of the battery status information the processor 101 controls the visual indicator such as red LED to blink at a certain preprogrammed frequency to alert the user that the device is in low power and charging of the battery is required.

[00064] Optionally, the charging circuitry 121 may further include an induction coil (not shown) connected to the battery. In this exemplary system, the charging circuitry 121 is configured to wirelessly charge the battery.

[00065] System 10 optionally comprises a charging station (not shown) for inductive or wirelessly charging the device 12 by utilizing an electromagnetic field to transfer energy from the charging station to the monitoring device 12. When the charging station and device 12 are in proximity to one another, there is an inductive coupling and energy generated by the charging station is used to charge a battery or run the device. The inductive charging station utilizes an induction coil to create an alternating electromagnetic field. Device 12 comprises a second induction coil (not shown) that interacts with the electromagnetic field and converts the energy back into electric current to charge the battery or run the device. The induction coil in the charging station and the induction coil in the wristband device 12 form an electrical transformer.

[00066] The processor 101 is further configured to control the charging circuitry 121 powering up the wearable device 12 upon the power switch 1 1 1 is activated. In this embodiment, only the case where power switch 1 1 1 activation is described. However, it should be appreciated that the configuration is equally applicable to other mechanism for powering up the wearable device 12. The wearable device 12, when it not in use, is configured in a low power mode or idle mode to conserve energy. Details regarding power supply to device 12 are described below.

[00067] Power On, Idle and Resume

[00068] To conserve the overall system power use, in an exemplary system, wearable device 12 may operate when the user turns on the power switch 111 to begin preparing for catheterization. In another exemplary embodiment, for purpose of reducing power consumption and extending battery life, device 12 may operate in a low- power idle mode under circumstances where device 12 does not need to actively perform tasks. The low-power idle mode may be defined by selectively having certain components, for example tag reader 140, turned off automatically after a preprogrammed time has elapsed post catheterization. The timer value associated with the idle mode preprogrammed time is greater than zero. In an exemplary system, the timer value associated with the idle mode preprogrammed time is greater than zero, and optionally the preprogrammed time is greater than the time off preset timer value. In another exemplary embodiment, wristband device 12 may be designed to wake up from idle to resume performing tasks in response to triggering specific interrupt events, such as the timer 102 reaches a preset value triggering alert (e.g., second or third alert) for catheterization within the alerting cycle or a specific user input such as activating the power switch 1 1 1. [00069] The devices and systems for monitoring patient’s adherence to intermittent catheterization treatment regime disclosed herein provide a handsfree compliance monitoring solution for intermittent catheterization users without manual intervention. The mobile app associated with the system provides a common platform for both the patent and healthcare provider enhancing communication therebetween. Both patient and healthcare provider have access to the mobile app at their corresponding terminal devices and are prompted to review the latest readings of the catheterization diary log. If the legitimacy of the readings are verified, the user can accept the readings which will be synchronized with the catheterization diary log profile. Otherwise, a notification may be issued which are viewable by both the patent and the healthcare provider. In that case, the healthcare provider can provide timely advice to patient to understand the risks arising from non-compliance with the regime and a method to keep a healthy bladder. In addition, wearable device 12 is designed to be reusable and durable requiring minimal maintenance effort from the user.

[00070] Communications interfacing within the system

[00071] Referring to Fig. 3, a wireless transceiver 124 also denoted transceiver module, is configured for wireless communication with computing device 18, such as configured for connecting the wearable device 12 to computing device 18 of the patient’s adherence to intermittent catheterization management system 10.

[00072] Prior to establishing any communication with the external computing device, processor 101 is configured to receive signals from the reader 140.

[00073] Referring to Fig. 3, processor 101 is in communication with the reader 140 to process the catheter identification information obtained from the tag or label on the catheter 14. The data processing includes decoding the CID and mapping the CID with the UID. Memory 116 is used to save the processed data ready for transmitting to external computing device 18 for review and evaluation. Optionally, memory 1 16 may be configured to store more than one set of or up to a certain preprogrammed number of CID/UID data. It is also another option that the memory 1 16 or processor’s 101 internal memory (not shown) is configured to store data other than identification information depending on additional catheter information is required for additional review and evaluation.

[00074] Processor 101 is also programmed to convert the RFID signal to data in a format compatible with the communication protocol / bus running between the components. This protocol includes SPI, UART, I2C, CAN USB, IEEE1394 and the like. Processor 101 sends the identification data (UID/CID) and/or daily logged time for catheterization, denoted as monitoring data MD to the transceiver module 124. The transceiver module 124 in communication with processor 101 is configured to receive the monitoring data MD and establish an accessory connection 19 to pair up the wearable device 12 and the computing device 18.

[00075] While it is an option that the monitoring data MD can be converted to transmission signal within the transceiver’s 124 on-board controlling unit 128, for simplicity of the design, described herein is the processor 101 being configured to generate an output signal embedded with the monitoring data MD to be transmitted via the transceiver 124. In an exemplary wearable device 12, the transmission between the wristband device 12 and the computing device 18 is unidirectional from the wristband device 12 to the computing device 18. The transmission signal (also the output signal generated from processor 101 ) embedded with the monitoring data MD (at this point, the wireless communication port in the computing device 18 is assumed opened) will be transmitted via the antenna 122. The transmission signal is a short range radiofrequency (RF) protocol as described in the above. In the exemplary system, “Bluetooth” is used as communication protocol between the wearable device 12 and the computing device 18.

[00076] The device/processor 101 is optionally configured to, in accordance with a determination that the accessory connection criterion is not satisfied, abort the transmission of monitoring data MD to the computing device 18.

[00077] Upon transmitting the monitoring data MD to the computing device 18, the accessary connection 19 is established. The processor 101 is further configured to determine whether the accessary connection 19 is successfully established, for example, whether the accessary connection parameter is above the accessary connection threshold TH_C. The accessary connection parament may be a signal strength indicator, such as a received signal strength indicator (RSSI) or a received channel power indicator (RCPI). The accessary connection parameter AP may be a signal-to-noise ratio. In other words, the accessary connection 19 fails to be established if it is determined that the accessary connection parameter is not above the accessary connection threshold TH_C. [00078] The wristband device 12 is optionally configured to, in accordance with a determination that the accessory connection 19 fails to establish, the wearable device 12/processor 101 is configured to abort transmitting the monitoring data MD to the computing device 18 and notify the user regarding such failure by either displaying a message on the computing device 18 via mobile app associated with the system 10 or indicating by visual or audible indicator in device 12. The user will then need to reestablish the accessary connection.

[00079] Wearable device 12 or the computing device 18 with which the wearable device 12 communicates may optionally be connected to a network (e.g., the internet or a local network) and the data may be shared with and/or processed by other devices or computers connected to the network which is accessible at the health provider end. [00080] Fig. 5 is a block diagram illustrating an exemplary external computing device 500, also denoted as computing device 18 in Figs. 1 and 2 according to the present disclosure. The computing device 500 forms part of a patient’s adherence to intermittent catheterization management system and can support monitoring of the patient’s adherence to intermittent catheterization. The computing device 500 comprises a memory 501 ; a processor 502 coupled to the memory 501 ; and an interface 503, coupled to the processor 502. The interface 503 interacting with the user provides the compliance data collected from the wearable device 12 for the user to review and evaluate. The interface 503 may be in the form mobile application (mobile app) developed by the catheter manufacturer which is installed in and executed by the computing device 500.

[00081] Peripheral devices, such as memory 501 and/or interface 503 can be operatively and communicably coupled to the processor 502 via a bus for communicating data. The processor 502 can be a central processing unit (CPU), but other suitable microprocessors are also contemplated.

[00082] The interface 503 is configured to communicate with the wearable device 12 of the patient’s adherence to intermittent catheterization management system. The interface 503 may comprise a display 503B as a visual interface like in the form of mobile app to the user. The interface 503 is configured to establish an accessory connection between the wearable device 12 and the computing accessory device. The interface 503 is configured to request for and receive monitoring data MD from the monitoring device. Optionally, the interface 503 is configured to establish an accessory connection between the computing device and the network.

[00083] The computing device 500/processor 502 is configured to determine whether the accessory connection is established; and in accordance with a determination that the accessory connection is not established, communicate an indication indicative of loss of accessory connection by displaying a failure message on the interface 503 and prompt the user to reestablish the connection.

[00084] Upon the accessory connection successfully established, the computing device 500 communicates and informs the user of the historical data log for the use of catheters or catheterization during the day or any period of time.

[00085] The data transmitted to the computing device 18 and/or server 20 may be used to record the frequency of catheterization of the user and/or warn the user of changes in the catheterization diary or risks with their bladder health if the user does not comply the recommended catheterization procedure. For example, the computing devices 18 may have software (such as mobile app) that analyzes the data and provides notifications when the data shows otherwise catheterization diary log different from the recommendation. Furthermore, these notifications may also be provided to a healthcare provider via a connection to server 20 such that to healthcare provider can timely advise patient if necessary. Additionally, the catheterization log may be achieved by computing device 18 or server 20 for a healthcare provider to review. It shall be appreciated that integrating a notification system into a healthcare platform can enhance communication between healthcare providers and patients.

[00086] In the foregoing specification, specific embodiments have been described. However, one of ordinary skills in the art appreciates that various modifications and changes can be made without departing from the scope of the invention as set forth in the claims below. Accordingly, the specification and figures are to be regarded in an illustrative rather than a restrictive sense, and all such modifications are intended to be included within the scope of present teachings.

Claims

1 . A smart wrist band for intermittent urinary catheter users, comprising: a housing configured to be worn on a wrist of an intermittent urinary catheter use, the housing comprising: at least one input port configured to receive input data and at least one output port configurated to transmit output data; and the at least one input port comprises a tag reader configured to receive tag input data from a tag associated with a urinary catheter, wherein the tag includes at least one catheter identification information of the urinary catheter.

2. The smart wrist band of claim 1 , wherein the housing includes a processor configured to communicate with the tag reader and process the at least one catheter identification information received by the tag reader.

3. The smart wrist band of claim 2, wherein the processor is configured to map the at least one catheter identification information with programmed identification information associated with the processor.

4. The smart wrist band of claim 2 or 3, wherein the processor includes a timer configured to be set with a value of zero after the at least one catheter identification information is mapped with the programmed identification information associated with the processor; wherein the processor is further configured to determine and record time status for catheterization based on a timer value.

5. The smart wrist band of claim 4, wherein the processor is further configured to map another at least one identification information associated with another catheter with the programmed identification information associated with the processor if the tag reader receives the another at least one identification information associated with the another catheter within a preset time off period; wherein the process is further configured to reset the timer value to zero.

6. The smart wrist band of claim 5, wherein the at least one output port further includes a transceiver module in communication with the processor, wherein the transceiver module is configured for wirelessly connecting a computing device.

7. The smart wrist band of claim 6, wherein the housing comprises a flexible substrate that contains the at least one input port, the at least one output port, the tag reader, the processor and the transceiver module.

8. The smart wrist band of any one of claims 1 to 7, wherein the at least one output port includes at least one catheterization indicator indicating the time status for catheterization and/or power status of the smart wrist band.

9. The smart wrist band of any one of claims 4 to 8, wherein the at least one catheterization indicator comprises a first indicator having a first alerting frequency, wherein the first indicator is activated to pulse with the first alerting frequency when the timer value is zero.

10. The smart wrist band of any one of claims 4 to 9, wherein the at least one catheterization indicator comprises a buzzer having a buzzing frequency, wherein the buzzer is activated to pulse with the buzzing frequency when the timer value is zero.

11. The smart wrist band of any one of claims 4 to 10, wherein the at least one catheterization indicator includes a second indicator having a second alerting frequency, wherein the second indicator is activated to pulse with the second alerting frequency when the timer value equals a first preset time period.

12. The smart wrist band of any one of claims 8 to 11 , wherein the at least one catheterization indicator includes a third indicator having a third alerting frequency and alerting the user that immediate catheterization is required, wherein the third indicator is activated when the timer value equals to a second preset time period.

13. The smart wrist band of claim 12, wherein the third alerting frequency is zero when the third indicator is activated.

14. The smart wrist band of any one of claims 9 to 13, wherein the catheterization indicator is deactivated when the tag reader receives further another at least one identification information associated with further another catheter or the timer value is zero.

15. The smart wrist band of any one of the preceding claims, wherein the smart wrist band further comprises a battery and a charging circuitry connected to the battery powering up the smart wrist band.

16. The smart wrist band of claim 15, wherein the at least one input port further includes a power switch connected to the charging circuitry configured to provide power to the smart wrist band when the power switch is ON.

17. The smart wrist band of claim 15 or 16, wherein the at least one input port further includes a power terminal connected to the charging circuitry and is configured to charge the smart wrist band when the smart wrist band is in low power mode.

18. The smart wrist band of any one of claims 15 to 17, wherein the processor is configured to control the charging circuitry to switch the smart wrist band to an idle mode when the timer value equals to an idle mode preset timer value; wherein the idle mode preset timer value greater than zero.

19. The smart wrist band of claim 18, wherein the processor is further configured to control the charging circuitry to switch the smart wrist band to an active mode in response to activating the at least one catheterization indicator.

20. The smart wrist band of any one of the preceding claims, wherein the smart wrist band further includes a memory connected to the processor, wherein the memory is configured to store at least one set of processed data associated with the at least one catheter identification information and/or the time status recorded.

21 . The smart wrist band of claim 20, wherein the processor is configured to preset a number of sets of the processed data to be stored in the memory.

22. The smart wrist band of any one of claims 6 to 21 , wherein the transceiver module is further configured to: receive the at least one set of the processed data from the processor; establish a connection between the smart wrist band and the computing device; and transmit a transmitted signal embedded with the at least one set of the processed data to the computing device via the connection.

23. The smart wrist band of claim 22, the computing device includes a user interface associated with the smart wrist band, wherein the user interface configured to: prompt the user to review the at least one set of processed data; display the at least one set of processed data; prompt the user to accept the at least one set of processed data when the at least one set of processed data is verified.

24. A system for managing intermittent urinary catheter use: a product identification information transmitting subsystem comprising a tag containing at least one identification information associated with the catheter; and a tag reader configured to retrieve the at least one catheter identification information associated with the catheter from the tag; a wearable device comprising: a housing comprising: at least one input port is configured to receive input data; and at least one output port is configured to transmit output data; the at least one input port comprising the tag reader further configured to receive the input data including the at least one catheter identification information associated with the catheter from the tag.

25. The system of claim 24, wherein the wearable device includes a processor configured to communicate with the tag reader and process the at least one catheter identification information received by the tag reader.

26. The system of claim 25, wherein the processor is configured to map the at least one catheter identification information with programmed identification information associated with the processor.

27. The system of claim 26, wherein the processor includes a timer configured to be set with a value of zero after the at least one catheter identification information mapped with the programmed identification information associated with the processor; wherein the processor is further configured to determine and record time status for catheterization based on a timer value.

28. The system of claim 27, wherein the processor is further configured to map another at least one catheter identification information associated with another catheter with the programmed identification information associated with the processor if the tag reader receives the another at least one catheter identification information associated with the another catheter within a preset time off period; wherein the process is further configured to reset the timer value to zero.

29. The system of claim 28, wherein the at least one output port further includes a transceiver module in communication with the processor, wherein the transceiver module is configured for wirelessly connecting a computing device.

30. The system of claim 29, wherein the housing further comprises a flexible substrate that contains the at least one input port, the at least one output port, the tag reader, the processor and the transceiver module.

31 . The system of any one of claims 24 to 30, wherein the at least one output port includes at least one catheterization indicator indicating the time status for catheterization and/or power status of the wearable device.

32. The system of any one of claims 27 to 31 , wherein the at least one catheterization indicator comprises a first indicator having a first alerting frequency; wherein the first indicator is activated to pulse with the first alerting frequency when the timer value is zero.

33. The system of any one of claims 27-32, wherein the at least one catheterization indicator comprises a buzzer having a buzzing frequency, wherein the buzzer is activated to pulse with the buzzing frequency when the timer value is zero.

34. The system of any one of claims 27 to 33, wherein the at least one catheterization indicator includes a second indicator having a second alerting frequency; wherein the second indicator is activated to pulse with the second alerting frequency when the timer value equals to a first preset time period.

35. The system of any one of claims 27 to 34, wherein the at least one catheterization indicator includes a third indicator having a third alerting frequency alerting the user that immediate catheterization is required; wherein the third indicator is activated if the timer value equal to a second preset time period.

36. The system of claim 35, wherein the third alerting frequency is zero when the third indicator is activated.

37. The system of any one of claims 32 to 36, wherein the catheterization indicator is deactivated when the tag reader receives further another at least one catheter identification information associated with further another catheter or the timer value is zero.

38. The system of any one of the preceding claims, wherein the wearable device further comprises a battery and a charging circuitry connected to the battery powering up the wearable device.

39. The system of claim 38, wherein the at least one input port further includes a power switch connected to the charging circuitry configured to provide power to the wearable device when the power switch is ON.

40. The system of claim 38 or 39, the at least one input port further includes a power terminal connected to the charging circuitry and is configured to charge the wearable device when the wearable device is in low power mode.

41 . The system of any one of claims 38 to 40, wherein the processor is further configured to control the charging circuitry to switch the wearable device to an idle mode when the timer value equals to an idle mode preset timer value; wherein the idle mode preset timer value greater than zero.

42. The system of claim 41 , wherein the processor is further configured to control the charging circuitry to switch the wearable device to an active mode in response to activating the at least one catheterization indicator.

43. The system of any one of the preceding claims, wherein the wearable device further includes a memory connected to the processor, wherein the memory configured to store at least one set of processed data associated with the at least one catheter identification information and/or the time status recorded.

44. The system of claim 43, wherein the processor is configured to preset a number of sets of the processed data to be stored in the memory.

45. The system of any one of claims 29 to 44, wherein the transceiver module is further configured to: receive the at least one set of the processed data from the processor; establish a connection between the wearable device and the computing device; and transmit a transmitted signal embedded with the at least one set of the processed data to the computing device via the connection.

46. The system of claim 45, the computing device includes a user interface associated with the system; wherein the user interface configured to: prompt the user to review the at least one set of processed data; display the at least one set of processed data; prompt the user to accept the at least one set of processed data when the at least one set of processed data is verified.