1. Team 16 : MedFRS Device Diagnostic Software Misha DowdProject Manager Delnaz GundeviaLife Cycle Planner Anfal Abdul JaleelSystem Architect Nanda Kishore Kollaje RaoSystem Requirements Engineer Anupam KumarFeasibility Analyst Jackie ChengIIV & V

2. Overview Current first responder systems that provide emergency health care in the field consist of a somewhat archaic paper tagging system in the case of a major catastrophe. Current system have added many systems over time, such as barcode tracking, to help the first responders treat people. However these systems are expensive and still faulty. The MedFRS is a system that will integrate a variety of first responder systems onto a single platform, preferably a ruggedized commercial laptop computer or handheld device, and will simplify the operation and inter- operation of these systems while providing for patient privacy and safety. The MedFRS integration includes the patient monitoring and treatment systems and the standardization of system protocols, interfaces, and key data (e.g., electronic patient records).

3. Requirements Capability Goals 1.The system should allow the first responders to record the victim information that they have collected with ID, location and triage category (enables information propagation). 2.The system should collate all the data entered by the first responders. 3.The system should provide the EMT with a list of victims sorted by category ( immediate>delayed) and then location (alphabetically). 4.The system should allow the EMT to retrieve a victim’s information by entering the victim’s ID. 5.The system should allow the supervisor to record in which ambulance the victim was taken and to which hospital. 6.Only authorized individuals should have access to the system and data (security). 7.The system should have a web interface.

4. Requirements Capability Goals 1.The transmission of data should be reliable. Reliability of transmission needs to very high because the system deals with medial data Low to medium network latency is acceptable because the system addresses disaster scenarios and networks would not be at their optimal level of service LOS GoalsDesired LevelAcceptance Level Reliability of transmission100%85% Network Latency30ms300ms

5. Risks There are many risks which could affect our project, some are : 1.The data collected has to be kept secure and we need to prevent unauthorized individuals from misusing it. For that purpose we need an authentication mechanism and a secure transmission mechanism. 2.The volunteer’s device may be temporarily out of range of the network, so we need a mechanism that stores the data and syncs it to the hub when the device comes back in range. 3. In the case of natural calamities there may be network failure but that is too large a scope, so we are working under the assumption that the network exists. 4.Volunteers can make a mistake while entering data which is a risk by human error.

6. Risk Item- Authentication Authentication is a primary risk Any user can generate and send data which may lead to clog the server Tracking volunteers Applications Validating Data

7. Volunteer Registers One Time Pass will be sent to the volunteer Volunteer Activates the Application using OTP A new Device ID will generated and sent to the App All Communication will be sent using this server generated ID DecryptionAuthentication Server Generated ID RSA Encrypted Authentication

8. Risk Item - Data Sync Data Sync is the process of communicating the victim information from Volunteer’s device to the cloud and from cloud to the EMT’s device, securely.

9. Data Sync  Why is it a risk? Security of the data may be compromised Network Connectivity may be hindered Data sent/received may not be consistent

10. Data Sync – When There is no Network Store the information in file on iOS file system[1] Another thread keeps checking network status in the background

11. Data Sync – When network Comes back Server Checksum DB Checker Thread Notifies of Network Connectivity Digital Signature of data is computed Data is then encrypted and transmitted Server decrypts the data Server verifies the digital signature Server stores the data if the signatures match

12. Bar Code is Entered or scanned Data is embedded with the Device ID and Barcode Number Data is Encrypted with RSA and updated in the Server EMS Personnel Scans the Bar code and gets Victim Data Store Data based on Barcode Number Send Data for the received Bar Code Number EMT Device RSA Encrypted Feature 1 : Barcode Tagging

13. Feature 2-Victim Location & Prioritization Table Automatically gets populated as data from volunteer starts pouring in Table stores information sorted based on the urgency of victim’s condition (Immediate, delayed) and on the alphabetic order of names of buildings assigned to him

14. References RSA Reference iOS Developer Guide https://developer.apple.com/library/ios/documentation/Security/Reference/cer tifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157 Property List iOS Developer Guide https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Pr opertyLists/AboutPropertyLists/AboutPropertyLists.html#//apple_ref/doc/uid /10000048i-CH3-SW2 Checksum https://developer.apple.com/library/mac/documentation/Darwin/Reference/M anPages/man1/cksum.1.html