Introduction
Human casualties from the Great East Japan Earthquake that occurred in Japan on March 11, 2011 numbered 15,892 deceased and 2,576 missing.Reference Ishii, Nakayama, Abe, Takayama, Kamei, Abe, Yamadera, Amito and Morino 1 Of these, the most affected area was the Ishinomaki medical zone in Miyagi Prefecture located in Eastern Japan, which recorded 5,385 deceased, 710 missing, 2 and a peak of 46,480 evacuees in shelters according to study data. 3 At the onset of the disaster, Japanese Red Cross Ishinomaki Hospital (JRCIH; Ishinomaki, Miyagi, Japan), a designated hospital of the Ishinomaki medical zone, was the only fully functioning medical facility among 86 medical institutions in this area. With the Ishinomaki City administration and health centers damaged, and their function severely reduced in the immediate wake of the disaster, a headquarters for local medical and relief activity was set up in the Red Cross Hospital. The members of the Ishinomaki Zone Joint Relief Team (IZJRT) consulted with organizations such as Tohoku University, Miyagi Prefecture; the municipal government; medical/dental/pharmacy associations; and other relevant authorities and got agreement to grant full coordination. 3 , Reference Ishii 4 The IZJRT was launched to unify all teams dispatched from across Japan working together in a coordinated effort. Given the extensive, widespread damage, the Ishinomaki medical zone (723.5 km2; population of 220,000) was divided into 14 areas and the Area-based/Line-linking Support System was introduced to allocate relief teams to each area, as needed. 3 , Reference Ishii 4 Furthermore, given the state of dysfunction for Ishinomaki City administration and its health centers, the IZJRT continuously was performing assessments of the living and sanitary conditions, tallying of the injured and sick, and other similar items for all of the shelters in the zone—328 at their initial peak.Reference Ishii 4 The IZJRT not only performed simple medical treatments, but also aggressively decided policies to support basic health management of damaged areas based on the assessment data.
Specifically, the activity included: 3 , Reference Ishii 4 (1) conducting shelter medical visits (main activity); (2) for the 35 shelters with food shortages, petitioning the government for rations, and to the extent possible, redistributing relief supplies sent to JRCIH; (3) for the 100 shelters with poor sanitary conditions, dispatching contamination-control certified nurses, distributing 116 wrap-type portable toilets, and installing small water-supply systems in 11 shelters; (4) establishing two satellite aid stations to mitigate hospital loads from the flood of victims; (5) establishing two fixed aid stations for areas with no doctors; (6) establishing four fixed aid stations for use by house-ridden victims to support areas of lagging recovery; (7) running free medical aid bus services to ensure means of transportation for victims; (8) holding a “caregiver’s meeting” to discuss support for people in need of care, and take assessment surveys of people in need of care in the shelters; (9) supporting the municipal government to establish two shelters with nursing capabilities; (10) establishing a quality shelter for those weakened by the disaster; and (11) creating a delayed delivery system for medicines prescribed during shelter medical visits.
The IZJRT ended its activity on September 30, 2011. With a total of 955 registered teams covering a maximum of 328 shelters, the teams treated 53,696 patients in the shelters and fixed aid stations. 3 As a result of specific activities, infection did not spread in the Ishinomaki medical zone, and by late June, very few symptomatic patients were reported in the shelters according to IZJRT investigations.Reference Ymanouchi, Ishii and Morino 5 These assessment data, which have become the indicator of relief activity, involved an enormous amount of cumbersome work, and have been questioned for their accuracy.
However, the data collected using the paper-type survey alongside relief team activity in the shelters were hand-tabulated by area, consolidated at the IZJRT headquarters, and finally analyzed by only 18 staff members. The mean number of working hours per day for a single staff member was 8.39 hours (SD=1.67 hours) with a mean of 3.56 staff members (SD = 1.54 staff members) working per day. In addition, 10 members admitted to having made some form of mistake when entering handwritten data and digitizing it, and nine admitted to having made a mistake when sorting or saving data after data conversion. These results show the difficulties in converting handwritten data to digital data and sorting and saving without mistakes. Results from post-disaster questionnaires also show the difficulties in avoiding mistakes in digitally converting, sorting, and saving handwritten data.
Thus, to prepare for the next major disaster, an assessment system must be developed that can tabulate shelter assessment data correctly and efficiently. To solve this problem, the Rapid Assessment System of Evacuation Center Condition featuring Gonryo and Miyagi (RASECC-GM) application, with financial support from Miyagi Prefecture, has been developed. Unique to this system is the use of smartphones, tablets, and other mobile devices to digitize entry, tabulation, and management of assessment data when online or offline. Furthermore, a verification test for configuration and actual operation of RASECC-GM was performed. The objective of this report was to describe the development and verification of a system to rapidly assess evacuation centers in preparation for the next major disaster.
Report
The RASECC-GM Configuration (Figure 1)
Figure 1 The RASECC-GM System. It is software to computerize the entering, tabulating, and managing of shelter assessment data. Abbreviation: RASECC-GM, Rapid Assessment System of Evacuation Center Condition featuring Gonryo and Miyagi.
The RASECC-GM was developed jointly with Eyes, Japan Co., Ltd (Aizu, Fukushima, Japan). First, a disaster headquarters started in times of disaster is to pre-register the dispatched relief teams and shelters in charge of them using the “Relief Team/Shelter Management screen” in the system application (ruby 2.0.0-p451, ruby on rails 4.2. HTML5, MongoDB 2.4.9; MongoDB Inc.; New York, New York USA and Palo Alto, California USA). Then, when the dispatched relief teams go on their medical visits to the shelters, they are to collect shelter information for each shelter, covering living and sanitary conditions, tallying of the injured and sick, and any of 19 other items (Table 1) thought necessary for health care of evacuees during the acute stages of the disaster. Once assessment data are entered at each site by opening the “Data Entry screen” on any smartphone, tablet, or other mobile device with the system installed, it will be sent to a server in a non-affected area via the Internet and tabulated. The system is built such that a list of data for each shelter is viewable at disaster headquarters by launching the software on a system administrator’s computer and opening a new administrator’s “Data Tabulation screen.” This should allow for quick, accurate tabulation, sorting, and management of shelter assessment data, as well as permit more appropriate relief activity.
Table 1 Shelter Assessment Items
The RASECC-GM is a web-based assessment application system for tablets divided into client and server systems. The client system is divided into data entry users and administrators differentiated with user IDs at login. Users can toggle between the “Data Entry screen,” “Data Tabulation screen,” and “Relief Team/Shelter Management screen.”
The data entry user application is supported for iPad 2 and newer Apple tablets using Safari on iOS7 (Apple Inc.; Cupertino, California USA) and higher for operating system and browser. Functions are as given below:
-
∙ Input assessment data;
-
∙ Registration of new shelters; and
-
∙ Closed shelter request.
The data entry user system is a web-based application (ruby 2.0.0-p451, ruby on rails 4.2. HTML5, MongoDB 2.4.9; MongoDB Inc.) accessible via the Safari web browser on an Apple iPad. Users can enter assessment data for the selected shelter from pre-registered shelters in the system. The entry screen for assessment items displays one question on the page at a time, while JavaScript-enabled screen features (AOI Inc.; New York, New York USA) allow dynamic touch panel operation to swipe or drag elements for a native-like implementation. Entered data are stored temporarily as a local file in the browser with the HTML5 local storage feature so that data are not lost when the device is not connected to the Internet. This allows the user to upload the data to the server whenever they get online. Locally cached assessment data are sent to the server via wireless network using a server-side web application programming interface (API). Once sent to the server (OS: Ubuntu 14.04 LTS; versions/server requirements: AWS EC2 t2.micro or equivalent; Amazon Inc.; Seattle, Washington USA), the data are saved together with time-stamped metadata in a MongoDB database and either can be viewed or deleted using the administrator API. All forms of communication infrastructures supported by the iPad are accepted as wireless networks: public Wi-Fi, mobile base stations, satellite phones, tethered mobile phones, etc.
The data entry user application is implemented using HTML5 application caching, meaning that if loaded once when online, the application can be accessed from the local cache to allow assessment data to be entered and new shelters to be registered when offline.
Functions for the administrator application are as follows:
-
∙ View assessment data for admin zones;
-
∙ Approve closed shelter requests for admin zones;
-
∙ View/add/edit/delete user accounts for admin zones;
-
∙ View/add/edit/delete shelters for admin zones;
-
∙ View/add/edit/delete regions for admin zones; and
-
∙ View/add/edit/delete areas for admin zones.
The administrator system is a web-based application (ruby 2.0.0-p451, ruby on rails 4.2. HTML5, MongoDB 2.4.9; MongoDB Inc.) accessible via browsers in both Windows (Microsoft Co.; Redmond, Washington USA) and Mac (Apple Inc.) platforms. The system accesses assessment data, shelters, user information, closure information, and other data stored on the server database with the Web API for the administrator to view, edit, or delete. The administrator system assumes Internet connectivity for use of assessment data and so is not implemented with HTML5 application cache or local storage.
The server is a server API installed to provide clients with the Ruby on Rails Web API or send clients the web application. The API data are generated, read, updated, and deleted by JavaScript Object Notation data communication.
Overview of RASECC-GM Features
Data Entry Users (Relief Teams)
Relief teams enter a pre-registered ID and password to login to the data entry user RASECC-GM application. After confirming team data (skipped after the first login), the user selects the shelter for which assessment data are to be entered (Figure 2). From the next screen, data entry begins. For the aforementioned 19 entry items (Table 1), to make data entry more efficient, the user swipes to flip through individual pages for entering each item. For four-choice assessment items, drag-and-drop is used to drag the selected assessment and drop it in the specified answer box (Figure 3). After all 19 items are entered, the user confirms all answers on the final page and presses the send button to send the answers to the server where the data are stored. Finally, if the data entry user discovers a new shelter in the field, they can register it as a new shelter on the spot. They can also submit a closed shelter request via the system for shelters confirmed to be closed.
Figure 2 Selecting Shelters for Assessment. The user taps the screen to select the shelter for which assessment data are to be entered.
Figure 3 Operating Four-choice Assessment Screens. Drag-and-drop is used to drag the selected assessment and drop it in the specified answer box.
Administrators
After administrators enter their pre-registered ID and password to login to the administrator RASECC-GM application, they can use the two screens, the “Relief Team/Shelter Management screen” and “Data Tabulation screen.” The “Relief Team/Shelter Management screen” is comprised of the relief team list screen and shelter list screen. Administrators can register, delete, or edit relief teams on the relief team list screen, or do the same for shelters on the shelter list screen. Meanwhile from the “Data Tabulation screen,” administrators can view a list of shelter assessment data as input by data entry users (Figure 1). They also can sort data by item.
Test for Feasibility and Usability (Figure 4)
Test Structure
Figure 4 Testing for Feasibility and Usability in the “Michinoku Alert” (large-scale disaster prevention drill by the Self-Defense Force).
A verification test was performed on November 8, 2014, to coincide with “Michinoku Alert 2014,” a large-scale Self-Defense Force (SDF) training exercise by the Ground SDF North Eastern Army from November 6-8. The verification test proceeded as follows, with two Disaster Medical Assistant Teams (DMATs: Tohoku University Hospital [TUH; Sendai, Miyagi, Japan] and Kesennuma City Hospital [KCH; Kesennuma, Miyagi, Japan]) participating in the training at the JRCIH training ground, acting as data entry users and the mock disaster headquarters at JRCIH as an administrator.
Test Objectives
The objective of the test was to verify the feasibility, usability, and accuracy of RASECC-GM. Specifically, the first objective was to verify whether mock data could be entered for multiple shelters by the user (TUH DMAT) to their device using the data entry user RASECC-GM application from an offline site (as is expected immediately after a major disaster), stored on the device, uploaded to the server upon moving within range of a Local Area Network set up via satellite link (established by the Resilient ICT Research Center [Sendai, Miyagi, Japan]), and then viewed via the “Data Tabulation screen” on the computer in the JRCIH disaster headquarters. The second objective was to verify whether data for multiple shelters input by another user (KCH DMAT) to their tablet device while separately offline in the field could be uploaded to the server by a commercial satellite line, and then viewed on the “Data Tabulation screen” on the same headquarters’ computer.
Preparations
First, one small satellite ground station (owned by the Resilient ICT Research Center and can transmit at 24 Mbps while moving) was placed in front of JRCIH (Figure 5a). Ultra-fast Internet satellite “Kizuna” was held on standby (“Kizuna” is a satellite developed by the Japan National Institute of Information and Communications Technology [Koganei, Tokyo, Japan] and Japan Aerospace Exploration Agency [Chofu, Tokyo, Japan] for technical demonstrations to eliminate the digital divide in the Asia-Pacific region and establish the gigabit-level, ultra-fast, satellite communications technology needed for sophisticated satellite use).Reference Ishii 6
Figure 5a A Small Satellite Ground Station.
Second, two tablet devices (iPad Air2, Wi-Fi model) and one satellite communication terminal (Figure 5b) for a commercial satellite line (INMARSAT [Inmarsat plc.; London, UK] BGAN [Broadband Global Area Network] services [KDDI Co., Shinjuku, Tokyo, Japan]), which enabled packet communication as used by TUH DMAT on-site, were prepared at Higashimatsushima City Hall (Higashimatsushima, Miyagi, Japan).
Figure 5b A Satellite Communication Terminal for a Commercial Satellite Line (INMARSAT BGAN services).
Third, a data administration computer was placed in JRCIH mock disaster headquarters.
Fourth, five completed paper-type assessment sheets (Figure 5c) and three other sheets (one set of mock shelter data per sheet) were pre-distributed to Higashimatsushima City Hall, 10.7 km west of the mock headquarters, and Ishinomaki Senshu University (Ishinomaki, Miyagi, Japan), 3.7 km east of the mock headquarters, respectively.
Figure 5c A Completed Assessment Sheet.
Test Procedure
First, TUH DMAT (Figure 4; A) collected five sets of mock shelter data at Higashimatsushima City Hall, and KCH DMAT (Figure 4; B) collected mock shelter data at Ishinomaki Senshu University. The DMATs entered their data on-site using a data entry user RASECC-GM application installed on their tablet devices (iPad Air2, Wi-Fi model; Figure 5d). The KCH DMAT moved into the local network area established by the small satellite ground station. At this point, data were uploaded to the server (via Kizuna).
Figure 5d The TUH DMAT Entered Data On-site using a Data Entry User RASECC-GM. Abbreviations: DMAT, Disaster Medical Assistance Team; RASECC-GM, Rapid Assessment System of Evacuation Center Condition featuring Gonryo and Miyagi; TUH, Tohoku University Hospital.
Second, TUH DMAT uploaded their data to the server via public Internet connection using the satellite-based mobile phone.
Third, at JRCIH, the administrator attempted to see if the assessment data were viewable on the “Data Tabulation screen” in the administrator RASECC-GM application on the computer in the mock disaster headquarters.
Measurement of the Verification Test
Data input was verified in the mock shelters and disaster headquarters. The on-paper assessment data had been prepared in each mock shelter, as stated above. First, research assistants staying with the DMAT helped with correct input of the data and then confirmed whether the inputted data on the site were correct. Second, the data sets were confirmed on the “Data Tabulation screen” on the headquarters’ computer (Figure 6a). Finally, the headquarters confirmed the successful transmission of the data by comparing the original, on-paper data with the data displayed on the “Data Tabulation screen” (Figure 6b).
Figure 6a The “Data Tabulation Screen” on the Headquarters’ Computer. The data sets were confirmed on this screen.
Figure 6b Headquarters Confirmed the Successful Transmission of Data by Comparing the Original, On-paper Data with the Data Displayed on the “Data Tabulation Screen.”
Result of the Verification Test
Data were uploaded successfully to the server by public connection using the satellite-based mobile phone. Data were input and stored on the mobile device and then successfully uploaded to the server by the satellite link established by the Resilient ICT Research Center. Both data sets were viewed successfully on the “Data Tabulation screen” on JRCIH headquarters’ computer. Secondary processes, such as sorting, were also successful from the “Data Tabulation screen.” Uploaded and received data all matched the inputted data.
Discussion
As mentioned above, during the Great East Japan Earthquake, assessments of more than 300 shelters were very complex and took an enormous amount of time and effort due to the process of using a paper-type survey and then manually tabulating the data using Microsoft Excel. Based on this experience, RASECC-GM was developed and verified to work properly, whether online or offline, and was confirmed with the aforementioned verification test to work properly whether online or offline.
Development and standardization of such tools are believed to be extremely important in a country like Japan, where several massive earthquakes such as the Nankai Trough Earthquake 7 and Tokai Earthquake 8 are predicted to produce damage exceeding even that of the Great East Japan Earthquake. Even so, a few issues must be resolved before RASECC-GM can become a standard tool for major disasters.
First, Japan still has no standard for assessment items that should be collected rapidly. Because of this, RASECC-GM, developed as a tool for rapid assessment of shelters, tentatively uses the aforementioned 19 assessment items, which were based on the assessment sheet used in disaster response in Ishinomaki and many of the suggestions from public health nurses active during the Great East Japan Earthquake. Hopefully, rapid assessment items to be collected will be standardized in the future. The Japanese Ministry of Health, Labour, and Welfare (MHLW; Tokyo, Japan) has earmarked work towards standardization as health labor sciences research in fiscal 2015. The RASECC-GM is scheduled for an interim update so that assessment items can be aligned with the standard if assessment items are standardized.
Second, how to use RASECC-GM is another issue. As RASECC-GM is implemented as a web-based application using a browser, input data are stored temporarily as a local file in the browser with HTML5 local storage so that data are not lost when the device is not connected to the Internet. Even so, the server must be accessible, even in the acute stages of a disaster when normal Internet connectivity can be impossible, because the tablet device must go online at least initially to access the server and locally cache the application itself, and inputted data can only be sent from the devices and viewed from headquarters via the server. In order to solve this issue for the verification test in this report, Local Area Networks were established with satellite links using an ultra-fast Internet satellite and a small satellite ground station. In addition, a satellite-based mobile phone was made ready to secure public connections. A system similar to the one in this experiment will need to be established in an affected area quickly if normally available communications are not served in the next acute disaster situation. Sadly, the current system in place in Japan for maintaining communications functionality during a disaster is insufficient. It is hoped that such a system will be put in place soon.
Third, assuming that communications are maintained and shelter assessment data can be consolidated on the server, another issue moving forward will be to establish a system for properly sharing the collected data with the relevant authorities. How to share RASECC-GM data with the “Emergency Medical Information System” for DMATs in Japan and the MHLW “Health Crisis and Risk Information Supporting Internet System” currently is being arranged.
Fourth, to properly contribute to public health care, this application should be used quickly and extensively during a sudden-onset disaster to gather data from each shelter. This, however, will require that the collected data be secure. Because most security incidents are web application vulnerability attacks, such as SQL injection, known as cross-site scripting (XSS), implementation of a defense in RASECC-GM against these types of attacks is planned. Furthermore, although data stored in RASECC-GM are not encrypted at this time, a data encryption system is planned in future versions of RASECC-GM.
Conclusion
The RASECC-GM was developed based on firsthand disaster experience and proven to be sufficiently robust for actual use through a verification test. Simulations confirm that users of this system would be able to easily and accurately assess vast quantities of data from multiple shelters following a major disaster and immediately manage the inputted data at the disaster headquarters.
Acknowledgement
The authors wish to thank the Japan National Institute of Information and Communications Technology (Koganei, Tokyo, Japan), the Japan Aerospace Exploration Agency (Chofu, Tokyo, Japan), and the SDF for their valuable cooperation in realizing this test for feasibility and usability. The authors are deeply grateful to Mr. Azuma (The Japan Research Institute, Ltd.; Tokyo, Japan) who offered continuing support and constant encouragement. The authors are also indebted to Assistant Prof. Kikuchi (Keio University; Minato, Tokyo, Japan) whose comments contributed greatly to this work. Finally, the authors would like to thank the Miyagi Prefecture Third Phase Area Medical Revitalization Plan (Miyagi, Japan) for a grant that made it possible to complete this study.
