Team 16 : MedFRS Device Diagnostic Software

Misha Dowd Project Manager

Delnaz Gundevia Life Cycle Planner

Anfal Abdul Jaleel System Architect

Nanda Kishore Kollaje Rao System Requirements Engineer

Anupam Kumar Feasibility Analyst

Jackie Cheng IIV & V

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).

RequirementsCapability 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.

RequirementsCapability 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 Goals Desired Level Acceptance LevelReliability of transmission 100% 85%

Network Latency 30ms 300ms

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.

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

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

Decryption

Authentication

Server Generated ID

RSA Encrypted

Authentication

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.

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

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

Data Sync – When network Comes back

Server

Checksum Checksum

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

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

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

References

• RSA Reference iOS Developer Guide

https://developer.apple.com/library/ios/documentation/Security/Reference/certifkeytrustservices/Reference/reference.html#//apple_ref/doc/uid/TP30000157

• Property List iOS Developer Guide

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/PropertyLists/AboutPropertyLists/AboutPropertyLists.html#//apple_ref/doc/uid/10000048i-CH3-SW2

• Checksum

https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/cksum.1.html