1. Introduction
The International Committee of the Red Cross (ICRC) states that the identification of victims of the events is a necessary task and it is their inalienable right, and in terms of humanitarian actions, it is the right of their relatives and family members to know under what circumstances and where their family members are. Also, it is the people’s right to be identified after death [1].
In natural disasters such as earthquakes, because of a large number of casualties and communication problems, in most cases, sufficient and accurate information, especially on the place of transfer or accommodation of patients is not in hand. On the other hand, event managers are not aware of the capacity of hospitals and the number of vehicles available, also hospital personnel has troubles and confusion in the admission of such casualties, as there’s no information about their number and medical conditions. This situation may jeopardize the safety of patients in the process of service delivery, in other words, the disaster is transferred from a scene to a hospital [2,3,4,5,6,7].
Furthermore, following the initial impact of the events, the relatives of the patient want to know where their patient is being treated. In most cases, patients may be transferred to different locations or cities, or referred directly to medical centers and hospitals without their pre-hospital emergency intervention, or referred by their relatives. In the 9/11 incident, only 6.8% of patients were transported by ambulances [8].
Therefore, there is a need for real-time documentation and management of identity and medical information, location information of the injured and the transferred, and tracking and organizing them during the process of evacuation from the site of the event to the designated health center. In this regard, the development of new technologies to respond to this need for the safety of the patient and the management of the evacuation process is crucial [9,10,11].
Patient tracking systems are designed and implemented for a variety of reasons, such as the visibility of the care provided, the return of families to each other, the management and allocation of resources, patient’s distribution guidelines, humanitarian goals, prevention of disease prevalence among them, as well as sharing information between pre-hospital emergency groups and hospitals [12, 13]. 
The primary purpose of tracking patients in events is to identify the patients' identities and locations at all times and to inform their relatives or supervisors in real-time about their medical status and this is no less important than the patient’s care and medication process [14]. It also aims to monitor the transfer of people in need of evacuation assistance, so that each patient is being transferred to a safe and appropriate area. For many patients, timely transfer to an appropriate health care facility is crucial, so that delay in these conditions can threaten their lives.
It also provides the institutions (hospitals, shelters) that are going to receive the patient, some information about the people who will arrive there, and eventually, the family members need to know where the rest of their family members are to find them and join together [15].
Given the importance of documenting the medical status and locations of patient transfer in natural disasters and the lack of infrastructure and a comprehensive and systematic system for tracking them in the country, practicing and evaluating a software program developed in this field to identify its weaknesses and strengths and providing an executive context on larger scales is very important.

2. Materials & Methods
Event Scenario
The simulated scenario is an earthquake that occurs at the Esfahan Red Crescent Rescue Department on June 3, at 9:30 AM. Five hypothetical victims in the event need to be investigated. The mobile data network for rescuers and the Internet network for the incident command is available and this is holding in an area of 32000 m2. Three Red Crescent rescuers attend the scene to respond to the earthquake. They are trained in using the application and provided with Near Field Communication (NFC) triage tags and smartphones equipped with NFC and Global Positioning System (GPS) and cellular data network. 
The tags use the Internet network and the third layer network socket platform to communicate with the server and transfer data to the database. There is an ambulance equipped with a smartphone with features of rescuers' smartphones to transfer patients to the field hospital at the scene of the event. The incident commander is in charge of supervising the operation of rescuing and tracking patients from the event scene by having desktop software available to plan and direct the operation. A laptop for project team monitoring, with a technical consultant, is stationed at the scene of the event. Rescuers are asked to install triage tags on patients and determine the priority of triage using their smartphones. The application also automatically adds the patient's location, time, and date, which is sent to the server along with the rescuer ID, triage status, and injured ID. 
It is assumed that after a few minutes the priority of the two patients will change. As a result, the rescuer tests the application’s ability in updating triage information. The rescuer can also see the patient's triage status at any time. The patients are transferred to the field hospital, with a report of the triage status and location of patients at the scene of the event, in an ambulance, and at the hospital for the event commander.

Prerequisites
A. Hardware components of the system
I. NFC tags: The tags used in this model were labeled with 862-bytes memory with the capacity to record information records (95-bytes records), including unique tag ID, triage priority, patient’s location, triage date and time, and specifications (patient’s name, hospital), attached to the patient's wrist for the ease of use with stiff cardboard and a plastic bracelet.
Tag's features:
● Function frequency: 13.56 MHz 
● Standard: ISO 14443
● Saving data without the need for a battery
● Having an antenna for NFC reader identification for sending data and equipped with a sent data storage chip
● Having a range less than 10 cm (about 4 inches)
● Functioning based on radio wave identification technology
● Data storage ranging from 106 bytes to 424 kB
● Easy access, high security, low cost,  application in different situations, easy to use, compatible with RFID infrastructure
● No manual configuration required
● No need to buy new hardware and people's smartphones were used to read and write.
II- Smartphones:The next infrastructure was the smartphone with NFC reading and writing applications. The rescuer himself is unable to manually record location and time, and the application automatically collects location information from GPS based on the north, south, west, east, and altitude from the sea level. The date and time are also automatically set. Another feature of this phone is the ability to connect to the Internet either through a SIM card or wireless or wireless hubs.
Smartphones features 
● Equipped with Android OS version 4.2.2 at least
● NFC reading and writing capability
● Equipped with GPS universal positioning
● Internet connectivity via mobile data or wireless network
Laptop features: Windows OS (the server is basically designed; therefore, it can also be installed on a Linux OS in special conditions)
System software components: I- Server software is basically designed and implemented in a way that it can operate on any server, including Linux or Windows. My SQL database is designed to store patients' data. The QT programming language is based on C ++.
II. Android Software: It is installed on the rescuer's phone device responsible to read/write NFCs, automatically records locations (patient’s triage, transfer, and deployment) and stores and retrieves the records at the event scene in the tag, and sends to the server.
III. Event commander software: The event commander retrieves information from the server and can view and display that information.
System architecture: One platform was designed using NFC tags, including a mobile application, server, and client under Windows. Communications in this platform are not web-based communications but based on the third-party network communication rules (third-party network sockets) that allow for greater security rules. In other words, the information sent and received on the socket is more specialized and secure in terms of security and subsequent encryption. The tags themselves can be read by anyone at any time and encrypted in subsequent phases to prevent unauthorized access to read, write or modify information, and only those having the mobile application of this system can access the information in the system. Communication security between the server and the client is also possible.

3. Results

The Functioning 
Step one: Reading the tags
After attaching the tags to the patients, NFC and GPS must be first activated to read the tag information. The rescuer then goes to “the Read Data” tab and touches “the Read NFC” button. The mobile device then approaches the NFC tag and after a few seconds, the device receives and displays the NFC tag information.

Step two: Writing tags
To record the patient's triage status, the rescuer returns to “the Write Data” tab to select the patient’s triage status (one of the green, yellow, red, and black preferences). Then touches “the Compose” button on NFC and bring the phone closer to the NFC tag. After a few seconds, the information is transferred from the phone to the NFC tag.
The message “Data has been written successfully” indicates the success of the operation.

Step three: Sending the information to the server
The rescuer first goes to “the Server” tab to verify the address and server port. After making sure of the accuracy, he touches the “Test Connection” button.
Connected to server message indicates a successful connection to the server.
Then, he touches “the Send” button to the server and after a few seconds, the information is transferred to the server.
The three-step process was conducted at various locations, including the scene of the hypothetical event, ambulance, and rescue post.

Patient Tracking System Platform Evaluation Stage
Having completed the maneuver, a joint meeting was held with the presence of the research team, technical advisor, maneuver team, including the rescue and relief officer, crisis management department director, information and communications expert, rescuers, and other maneuvers operational personnel and the suggested solutions were discussed regarding the problems of the patient tracking system platform.
The evaluation results in the following five sections were then approved by the members of the meeting.
1. The system was implemented satisfactorily and smoothly in terms of the infrastructure and tools used and the operation mode.
2. The training time for the rescuers was insufficient which lowered their performance.
3. The fields defined for each record in the program were insufficient for recording more patients.
4. The updatability of patient status along the transfer route needs further investigation.
The essential solutions presented for removing the above limitations were as follows:
1. To increase the operation speed of the system in reading and writing tag information, the process should reduce from three to two steps if possible.
2. Rescuers will also receive additional training and training on how to use their phone application before participating in the next maneuver (plane crash incident).
3. The software fields should be designed so that the patient's medical information can be selectively recorded and check marked so that the rescuer does not need to spend time typing the information.
4. To update the patient's medical status along the transfer route, it was suggested that composite tags be designed and used and the necessary study be conducted.
5. Finally, given the limitations mentioned, it was decided to develop the second version of the system with more information records and re-tested in the crash plane incident in July.

4. Discussion
In this study, the NFC architecture was used for the patient tracking system and tags with a capacity of 862 bytes were used by the rescuers. By attaching the tags, the process of tracking the injuries begins with using radio waves and the global positioning system. The results indicated that rescuers could easily send the information to the server by attaching the tags to the patients and reading the tags, and experiencing no problems in connecting to the server. In the Maltz and Takizawa study, the patient’s tracking was evaluated using appropriate radio waves and the global positioning network [16, 17]. In the Maltz study, RFID tags with a 100-mV battery were used for storing and transmitting data to the server, but the present study used NFC tags without the need for a battery and with further data storage, which could be an advantage for this study. However, these tags can only be read from an NFC-equipped device at a distance of less than 10 cm and the rescuer should read the tag from a close distance, but this feature is crucial for keeping the patient’s data secure.
In the study conducted by Lennert and White, intelligent triage tags capable of monitoring vital signs and measuring patient’s blood oxygen levels were used, which can even show warnings for the need for urgent medical attention which is an advantage of the present study [18, 19]. But this technology is not available in our country. Therefore, in developing the second version of the system, tags should send and alert caregivers about specific patients who need more care compared to others. In addition to tracking activities and signaling tools, these tags can also facilitate the retrieval of care data for the rescuers and the event commander at the event scene until the patient arrives at the hospital. To achieve this, it is necessary to consider specifications for the physical structure of the smart triage label and software capabilities, including the integration of the present system with the hospital information system.
In this study, Nasu used electronic cards to record the patient’s data. Its advantage over the present study was that if the communication infrastructures of the cards were not established, then it could record, scan, and send the print and information to the server, and attach the card to the patient [20]. However, in our country, the existing triage tags, which follow a standard format, can be used during the event as an auxiliary tool for definitive compensation of the patient tracking system until the necessary infrastructure is established at the scene for using the system.
   In the present study, a mobile application was installed for reading and writing tags on the Android smartphone of the event scene rescuers, ambulance team, and medical teams present at the rescue post and did not need to purchase separate pocket computers. There were no specific restrictions on the model and manufacturer of the phone, and NFC readability was the only feature required, needless to say, most phones from 2014 onwards have this feature. In the studies conducted by Maltz, Takizawa, Lennert, and White, a variety of pocket computers were used to read and write tags. In Lennert's study, pocket computers were used for the rescuers and a tablet for event commanders. Rescuers' pocket computers in this study were capable of displaying patients' triage status and receiving alert signals along the route to timely alert the event response team due to the use of triage smart tags in his study. Pointing out that the use of mobile phones has become very common, Takizawa concluded that instead of pocket computers, smartphones can be used to store and send tags information [16,17,18,19].
The three-software used in the current system included a mobile application, with which the rescuers were able to read and write tags and send patient’s information to a server over the Internet, such as a wireless SIM card or wireless hubs. 

5. Conclusions
The results of evaluating the pilot platform of this system in the Isfahan Red Crescent earthquake maneuver indicated that the system was implemented satisfactorily without problems in terms of infrastructure and tools used. However, because of the short duration of the program using training, rescuers evaluated the speed of data recording and sending as low. To fix the problem and speed up the system's ability to read and write tags, the research team concluded that the reading and writing tags process should be reduced to two steps (from three steps). The rescuers should also receive additional training on how to use their phone application before participating in the next maneuver (plane crash accident).
Also, according to the opinion of participants in the maneuver, the fields defined for each record in the program were insufficient for recording more patients. In this regard, since the content of the model proposed in this study consists of recording demographic, spatial, and medical data of patients in several stages from the scene of the accident to the end of hospital discharge, the researcher deems more data elements in the system necessary for the next versions.
The updatability of the patient’s status along the transfer route was another notable issue raised by the maneuvering team where the multifunction tags could be a good alternative.
Eventually, considering the limitations and capabilities of the current system, a second version was prepared and tested for use in plane crash maneuvering.

Ethical Considerations
Compliance with ethical guidelines
All ethical principles were considered in this article.(Ethical Code: IR.MUI.REC.1394.3.812).

Funding
This research was granted by Isfahan University of Medical Sciences (Grant No: 394812).

Authors' contributions
All authors contributed in preparing this article.

Conflict of interest
The authors declared no conflict of interest.

Acknowledgments
The authors would like to thank Esfahan Red Crescent Rescue Department for collaborating in exercise.