# RFID Technology for Management and Tracking: e-Health Applications
## 2 System Architecture
### RFID Software  
RFID software architecture can be divided into two parts: the first one is devoted to managing the readings of RFID tags within the coverage area of the antennas, storing and updating the information in a database. The second one includes the GUI where the information stored in the database is displayed to end-users and administrators, as well as allowing the collecting of their inputs. RFID tags (especially passive ones) can store a limited amount of information about the associated item. Because of this, RFID tags are typically used as pointers to registers in a database where information about the item is stored. In the example shown in Figures 4 and 5, each tagged item has an associated entry in a database containing the following information: (i) _item ID:_ RFID tag identifier or pointer; (ii) _item name:_ name of the medical asset or associated medicine/drug; (iii) event: indicates where the RFID tags are detected; (iv) _action:_ depending on the kind of item and the event, different actions are triggered (e.g., administering the item to the patient on the room); (v) _eventChanged:_ flag that tells if, during the period of two consecutive readings, the event has changed (e.g., if the item has been moved from one room to another); (vi) _timeCount_: counter to consider if the item is active or not within the coverage area of an antenna. This database can be stored in a workstation/server, eventually integrating them together with other information systems and services of the hospital. RFID readers are configured to periodically send interrogation signals, each one associated to the n-th RFID reader port (which is connected to the n-th RFID antenna). If a RFID tag receives this interrogation signal with enough intensity, it will send a response signal. Collision avoidance protocols are implemented for those cases in which two or more RFID tags respond at the same time to the interrogation signal. That means that only one response is received every time. This could result in missed tags for those cases where there are tens of RFID tags within the coverage area of the antenna and the RFID reader throughput is low. This also leads to another problem associated with latency. For example, if there are 10 RFID tags within the coverage area of the n-th antenna, and the RFID reader throughput is 10 tags per second, each tag is detected 1 time per second on average. Thus, a protocol that tells the end-user that the tag is within the coverage area, although it is not constantly read, must be implemented. The solution proposed in this contribution is shown in Figure 4: every time a RFID tag is read, the field _timeCount_ is set to its maximum value (_MAXCOUNT_). Then, the value of this counter is decreased periodically in the database. If the value of the counter reaches zero, then it is considered that the item is no longer within the coverage area of the antenna. However, if a new reading is done before the counter reaches zero it is set back to _MAXCOUNT_. The value of _MAXCOUNT_ can be adjusted depending on the throughput of the RFID readers and the expected maximum number of RFID tags within the coverage area. Thanks to this, items can be considered \"active\" for a few seconds in the location associated to the n-th antenna where they have been detected. RFID tags attached to items that are not stored in the database (e.g., clothing of hospital visitors) will be detected as well, thus reducing the effective throughput of the readers. This issue must be considered when selecting the value of _MAXCOUNT_. As shown in Figure 4, once a RFID tag is detected, the first action is to check whether the item associated to the tag exists in the database and, otherwise, the reading is discarded. The information stored in the database eventually has to be displayed to end-users (doctors, physicians) and system administrators.