Ambulance Dispatch System

Software Design Document (Deliverable3)

CS 6354 – Advanced Software Engineering, Section 581

Summer 2007

The Fantastic 9

Arturo Saracho / / 11120701
Denis Stetsenko / / 10829000
Sarthak Dudhara / / 11138921
Abdullah Azzouni / / 11152135
Russell Smith / / 11126187
Anitha John / / 10480080
Abhishek Goyal / / 11139363
Nate Gardner / / 10080880
Sheetal Umeshkumar / / 11108292

Revision History

Version / Date / Comments / Author
1.0 / 6/26/2007 / Initial Version -- Template / A. Azzouni
1.1 / 7/1/2007 / Consolidated Version / A. Azzouni

Table of Contents

Purpose of this document

Audience

1.Introduction

1.1.Purpose of the system

1.2.Design goals

1.3.Definitions, acronyms, and abbreviations

1.4.References

1.5.Overview

2.Current Software Architecture

3.Proposed System

3.1.Overview

3.2.Subsystem Decomposition

3.3.Hardware/software mapping

3.4.Persistent data management

3.5.Access Control and Security

3.6.Global Software Control

3.7.Boundary Conditions

4.Subsystem Services

4.1.The User Interface (UI) Subsystem

4.2.The Main Subsystem

4.3.The Hospital Subsystem

4.4.The Emergency Subsystem

4.5.The Ambulance Subsystem

4.6.The Caller Subsystem

4.7.The Case Subsystem

4.8.The Database Subsystem

Glossary

Purpose of this document

System design is documented in the System Design Document (SDD). It describes design goals set by the project, subsystem decomposition (with UML class diagrams), hardware/software mapping (with UML deployment diagrams), data management, access control, control flow mechanisms, and boundary conditions. The SDD is used to define interfaces between teams of developers and serve as a reference when architecture-level decisions need to be revisited.

Audience

The audience for the SDD includes the project management, the system architects (i.e., the developers who participate in the system design), and the developers who design and implement each subsystem.

1.Introduction

1.1.Purpose of the system

The system is designed toimplement a solution toan application domain which consists of an ambulance dispatch system. This will be achieved by delivering a software system that will interact with the corresponding actors, such asa caller that dials 911, a dispatcher that handles the call and dispatches ambulances, the ambulances, a relative looking for information about a patient, and an emergency room. The system willbe an online based software system that can be accessed from any computer with a connection to the internet.

The solution implemented will allowbetter control of an emergencysituation by properly tracking the case from the moment the call is placed until the patient is delivered toan emergency room,by providing the means necessary for the dispatcher and the ambulances to communicatewith each other to exchange the necessary information and by providing the electronic resources needed to complete all tasks required, such as finding an address, locating the nearest available ambulance and providing case status to a third party (relative).

1.2.Design goals

The goal of the system is to satisfy the functional and non functional requirements as specified in the requirements specification document.

1.3.Definitions, acronyms, and abbreviations

ADS / Ambulance Dispatch System
EMT / Emergency Medical Technician
GPS / Global Positioning System
HTML / Hyper Text Markup Language
SDD / Software Design Document
SRR / Software Requirements Specification
UI / User Interface

1.4.References

[1]Lawrence Chung, Advanced Software Engineering syllabus, CS 6354 section 581, Summer 2007.

[2]Bernd Bruegge, Allen H. Dutoit, Object-Oriented Software Engineering using UML, second edition. Prentice Hall, 2003.

1.5.Overview

The purpose of this design document is to provide the design models and methodologiesthat are developedand used to satisfy the requirements. This document presents detailed diagrams that represent the functionality of the system from the system's point of view to provide the necessary interfaces to the users.

2.Current Software Architecture

Currently there is no software architecture for the ambulance dispatch system. The current system is a phone a paper based system that is outdated and unorganized. When the dispatcher receives an emergency call s/he then radios to an ambulance to see if they are available to take the emergency. If they are not available then s/he must continue to track down an ambulance that is available. Once finding an available ambulance the dispatcher then communicates to the EMT the location of the emergency and status of the injured parties. This information is recorded by hand by the non-driving EMT. Once finished at the scene the EMT must then radio near by hospitals to ensure that the hospital can accommodate their patient. Once dropping the patient off at the hospital, the EMT must then notify the dispatcher of the final details of the patient's condition and other pertinent information about the case. The dispatcher records this information by hand and then files the necessary paperwork.

This current system leaves a paper trail that is difficult to follow later if necessary. In addition, precious time is lost as the dispatcher attempts to locate available ambulances and hospitals. The lost time could ultimately be the difference between life and death for the patients. Our new software architecture will address these issues by allowing the dispatcher to always have available a real time list of available ambulances and hospitals. Our software architecture will also electronically send all necessary information to the ambulance along with a GPS map of the emergency location. This will both remove the unnecessary paper trail andallow the EMTs to focus on handling the emergency.

3.Proposed System

3.1.Overview

The ADS system in general will consist of 4 major parts: a phone system, a dispatching system, a location-tracking system, and an ambulance system. The combination of these 4 components will realize the full potential of the ADS system.

The phone system will connect emergency callers through to ADS dispatchers. The call first will be received by an operator. If the operator identifies the call as a medical emergency, the call will be put through to the system dispatchers. The city’s phone system is already in place. An interface between ADS and the telecommunication network will need to be built. The phone system will provide the physical address of the caller if available, especially when calling from a land-line phone. In case of cell phones, the caller area will be provided using the location of the communication tower the call is routed through.

The dispatching system is the main part of ADS. The whole system is controlled through this component. It tracks all ambulances on duty. Hospitals in the coverage area are also monitored. Communication between dispatchers and ambulances and between dispatchers and hospitals is initiated through the dispatching system. This system is detailed in the following sections.

The location-tracking system is an external (third-party) system that has the capability to locate objects using satellite system. Each ambulance will be equipped with a tracking device. The tracking system will provide ADS with real-time information about each ambulance’s location. An interface between ADS and this system will have to be built.

The ambulance system is installed in each ambulance. An ambulance will have a tracking device installed as described in the location-tracking system. Each ambulance will also have an online terminal. A terminal consists of a laptop computer connected to the internet using a broadband card. These devices will be comfortably installed in the vehicle such that the driver and paramedic response is not hindered. Communication between the dispatching system and the ambulance system will be through the internet. A dispatching message will show on the paramedic workstation once an emergency has been assigned to the ambulance. The dispatcher can call the ambulance driver or paramedic using the phone or some sort of a walkie-talkie device. This alternative communication method is especially important in case of communication failure through the internet.

The following diagramshows a general overview of the whole system. The location-tracking system, telephone system, and internet are already existing systems that ADS will interface with.

Figure 1 - System Birdseye View

3.2.Subsystem Decomposition

Figure 2 - Subsystem Decomposition of the Ambulance Dispatch System UML Class Diagram

For better readability, we do not show the attributes and operations of the classes. The object model of the RAD provides the classes in more detail.

3.2.1.The User Interface (UI) Subsystem is responsible for all interaction between the users (Dispatchers, Managers, and Administrators) and patient relatives. The UI is decomposed into a set of HTML pages loaded and displayed in a web-browser (Microsoft Internet Explorer, Netscape, etc). All entry of data, modification of data, and deletion of data will be handled directly through the UI.

3.2.2.The Main Subsystem is responsible for all interactions between the UI Subsystem and the Hospital Subsystem, Emergency Subsystem and Ambulance Subsystem. The Main Subsystem is also responsible for interactions between the Main Controller class and the Map, User, Log and Report classes that make up the Main Subsystem. The Main Subsystem is also responsible for the interactions between the Map, User, Log, Report and Main Controller classes/objects to the Database Subsystem. Each class, Main Controller, Log, User, Report and Map is responsible forutilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from withineach of the classes themselves.

3.2.3.The Hospital Subsystem is responsible for all interactions involving Hospitals. All interactions withany Hospital will be handled through and by the Hospital List class, except forDatabase access,from within the Hospital Subsystem. The Hospital Subsystem is also responsible for the interactions between the Hospital List and Hospital classes/objects to the Database Subsystem. Both the Hospital List and Hospital class will each be responsible for utilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from within each of the classes themselves.

3.2.4.The Emergency Subsystem is responsible for all interactions involving Emergencies. All interactions with any Emergency will be handled through and by the Emergency List class, except Database access, from within the Emergency Subsystem. The Emergency Subsystem is also responsible for the interactions between the Emergency List and Emergency classes/objects to the Database Subsystem. Both the Emergency List and Emergency classes will each be responsible utilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from within each of the classes themselves.

3.2.5.The Ambulance Subsystem is responsible for all interactions involving Ambulances. All interactions with any Ambulance will be handled through and by the Ambulance List class, except for Database access, from within the Ambulance Subsystem. The Ambulance Subsystemis also responsible for the interactions between the Ambulance List and Ambulance classes/objects to the Database Subsystem. Both the Ambulance List and Ambulance classes will each be responsible utilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from within each of the classes themselves.

3.2.6.The Caller Subsystem is responsible for all interactions involving Callers. All interactions with any Caller will be handled through and by the Caller List class, except Database access, from within the Caller Subsystem. The Caller Subsystem is also responsible for the interactions between the Caller List and Caller classes/objects to the Database Subsystem. Both the Caller List and Caller classes will each be responsible for utilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from within each of the classes themselves.

3.2.7.The Case Subsystem is responsible for all interactions involving Cases. All interactions with any Case will be handled through and by the Case List class, except Database access, from withinthe Case Subsystem. The Case Subsystem is also responsible for the interactions between the Case List and Case classes/objects to the Database Subsystem. Both the Case List and Case classes will each be responsible for utilizing the appropriate and necessary methods within the Database class to insert, read, update and delete all corresponding data from within each of the classes themselves.

3.2.8.The Database Subsystem is responsible for all insertion, reading, updating and deletion of all data by all classes within the Main, Hospital, Emergency, Ambulance, Caller, and Case Subsystems. No data will be accessed in any way except through and by the Database Subsystem. Each class from within the Subsystems described aboveare responsible for inserting, updating and modifying their own data by utilizing the corresponding methods belonging to the Database Class within the Database Subsystem.

3.3.Hardware/software mapping

The diagram shown below depicts the outline of the deployment scheme for the Ambulance Dispatch System.

The following components make up the Ambulance Dispatch System:

Dispatcher's Workstation
Phone Answering Device
Web Browser
Communication Device (for communication with ambulance)
Relative's Computer
Web Browser
ADS Server
Tomcat Application Server
Third Party GPS Mapping Software
Ambulances
Wireless Enabled Communication Module
Third Party GPS Mapping Software
Database Server
mySQL Database

The Dispatcher's Computer and Relative's Computer communicate with the ADS server via HTTP/HTTPS protocol using the Browser in their respective computers. The ADS Server has a Tomcat Application Server running on a particular port listening for requests from the Dispatcher's as well as the Relative's computer. The ADS server also has a third-party GPS mapping software to interface with the cl. It also communicates with the Emergencies Database Server using the JDBC API for connecting an application with the mySQL database. The Ambulance also communicates with the ADS server using the Wi-Fi internet. It also has the third-party GPS mapping software installed in it to track its real-time location.

- 1 -

Figure 3 - Hardware Mapping

- 1 -

3.4.Persistent data management

3.4.1.Introduction

Ambulance Dispatch system will largely depend on a relational database to perform day-to-day operations and storing log data. Data will be stored in a mySQL 5.0 DBMS and manipulated through the Database Subsystem, which will ensure data integrity and consistency. Database Subsystem will contain all necessary SQL queries that will be accessible by the rest of the Subsystems.

Database will be hosted on Emergencies Database Server and will be accessible 24/7 via a local area network. Database shall be able to process up to 86,400,000 queries per day (up to 1,000 queries per second) with the average query length of 5Kb.

The data stored in the database will include:

Emergencies
Cases
Ambulances
Hospitals
Callers
Patients
ADS Users and Groups

The database will be backed up on a daily basis to ensure data security.

3.4.2.Database Schema

Figure 4 - Database Schema

3.5.Access Control and Security

The Access control Matrix for the Ambulance Dispatch System is as follows:

Administrator / Dispatcher / Manager / Ambulance/Driver / Relative
Logging In / Yes / Yes / Yes / Yes / No
User Settings / Yes / Yes / Yes / Yes / No
Data Entry / Yes / Yes / Yes / No / No
Ambulance Allocation / Yes / Yes / Yes / No / No
Communication with the Ambulance / Yes / Yes / Yes / Yes / No
Hospital Availability / Yes / Yes / Yes / No / No
Monitor Performance and position / Yes / Yes / Yes / No / No
Monitor Display / Yes / Yes / Yes / No / No
Monitoring Complete / Yes / Yes / Yes / Yes / No
Information logging / Yes / No / Yes / No / No
Emergency Transfer/Sharing / Yes / Yes / Yes / No / No
Logging Out / Yes / Yes / Yes / Yes / No
Reporting / Yes / No / Yes / No / No
Track Case / Yes / Yes / Yes / Yes / Yes

Security:

Authentication mechanism: LDAP will be used for authenticating the user login.
Encryption: SSL will be used for data encryption that will be sent over the internet.
Database Security: Varying level of access control will be provided to different users of the system to maintain the database security. Access control will be differentiated based on the access privilege provided to each user for each table. Admin user will have update privileges on all the tables.

3.6.Global Software Control

The ADS architecture is to have an explicit, decentralized software control. The system's dynamic control is distributed among different controllers such that each object delegates some responsibility to other objects. The request initiations are event-driven:

The dispatcher initiates the UI Subsystem by logging into the system.
The ADS Main Subsystem is initiated when an emergency call is routed to the dispatcher.
The Main Subsystem initiates the Emergency Subsystem by activating an emergency.
The Emergency Subsystem initiates the Caller Subsystem by gathering information from the caller.
The Emergency Subsystem initiates the Case Subsystem by logging the case.
The Main Subsystem initiates the Ambulance Subsystem by forwarding the emergency location and dispatching ambulance(s) to the case site
The Main Subsystem initiates the Hospital Subsystem by checking the availability and notifying of the emergency.
The Database Subsystem can be initiated at any point by all Subsystems except the UI Subsystem. Any request (add/update/delete/retrieve) to the repository initiates the Database Subsystem. The system stores its contents in the database between executions. When the application is run again, it retrieves the contents from the previous execution. Any change in the contents during this execution updates the database.

3.7.Boundary Conditions