Casualty Tracking Project 1
Running head: PROOF OF CONCEPT FOR CASUALTY TRACKING SYSTEM
Proof of Concept for Casualty Tracking Project (CTS)
Draft one
Nitin Nagar
Hawaii Pacific University, Honolulu, HI
Casualty Tracking Project 2
Proof of Concept for Casualty Tracking Project (CTS)
System Specification
Information about casualty status of victims (arrival, treatment, discharge etc) during
emergency situations is crucial and is currently unavailable on a real time basis. Healthcare
Association of Hawaii (HAH) would like to develop a Proof of Concept (POC) during the Phase
1 of the Casualty Tracking Project (CTS). POC is a digital ‘mock-up’ of the package. POC
demonstrates the design to both the team and the client, allowing evaluation and validation of the
design concept (The University of Queensland, 2004). This ends with agreement on major design
issues and then it signals the start of real development on the system. It is important to remember
that the objective of this process of developing POC is to demonstrate and validate the design
and is not actual start of development of the system. HAH plan to use the POC of the CTS
project to explore additional funding opportunities to support development of next phase of the
project.
Goal
To generate a finalized design for phase 2 of development of Casualty Tracking System
(CTS).
Purpose
To design a proof of concept (POC) for Casualty Tracking Project (CTS).
Outputs
A proof of concept for CTS and Project Management documentation.
Casualty Tracking Project 3
Requirements
1. The proof of concept for CTS must have a web based interface.
2. The client software should not require any special download or install of software on
Client’s Machine
3. The interface must be available from any where over Internet.
4. The proof of concept must be easy to use and must not interfere even when wearing
protective clothing
5. The proof of concept must be able to read Disaster Management Group (DMG) triage bar
code (Disaster Management Group, 2004).
6. The proof of concept must be able to transmit this bar code to client’s machine.
7. The proof of concept must be able to show the read barcode in an input box on the clients
web interface.
8. The proof of concept must be able to create a new record in the database, which will be
hosted on the server upon clicking a button on clients web interface.
9. The proof of concept must pull out the existing record from the database and display it on
clients web interface if the same barcode is scanned in succession.
10. The proof of concept must take in data such as (a) Triage barcode number (b) Arrival
date-time
11. Upon rescanning the triage tag, the proof of concept should display existing record in the
database matching with the triage tag and should allow staff to enter additional
information such as (a) Triage date-time (b) Status (Green: Minor/Yellow: Delayed/Red:
Immediate/Black: Morgue)(c) Chief complaint (d) Sex (Male/Female)(e) Age (f) Mode
of Arrival (Walked/Carried/Stretcher)
12. The proof of concept must be able to generate a summary report detailing the number of
admitted patients with their status.
Casualty Tracking Project 4
13. The proof of concept for CTS must be able to provide a basic level of security
(Login/Password) to provide access to client’s web based interface.
14. The proof of concept uses two types of barcode readers, USB barcode reader and
Wireless barcode readers.
Initial assumptions
1. Proof of concept for CTS assumes that this system would be installed at only one location.
For including different locations, a Hospital ID parameter must be included when
scanning the tags of arriving patients.
2. The proof of concept for CTS is assumed to be on a secure channel. For implementing
Secure Socket Layer (SSL) security over web access, HAH must be able to provide a
digital certificate for server, hosting the site.
3. Proof of concept for CTS assumes that the hospital facility it is being implemented always
has sufficient number of staff and beds to host the patients.
4. Proof of concept for CTS considers the hosting hospital facility independent of any
specific location, especially Hawaii.
External requirements
The proof of concept for CTS will be influenced by requirements imposed from external
factors such as hardware. For instance, the staff using wireless barcode scanners will not be able
to find out if a barcode on a triage tag has been scanned earlier from a distance of 50 feet from
base station until and unless he/she is in front of a web based interface. In this case, the staff
would use the wireless barcode scanners to conduct a first scan and staff need to present in front
of web based interface to verify if the scanned bar code is already having a record in the CTS
database.
Casualty Tracking Project 5
Acceptance criteria
The acceptance criteria for proof of concept for CTS project are as given below:
1. The proof of concept must be able to read DMG bar code (Code 39)(Disaster Management
Group, 2004)
2. The proof of concept must be able to transmit DMG triage bar code to client’s machine.
3. The proof of concept must be able to show the read DMG triage barcode in an input box
on the clients web interface.
4. The proof of concept must be able to create a new record in the database, which will be
hosted on the server upon clicking a button on clients web interface.
5. The proof of concept must be able to pull out existing record from the database and display
it on clients web interface if the same DMG triage barcode is scanned in succession.
Casualty Tracking Project 6
References
Disaster Management Group (2004). DMG Triage Tag: Disaster Management Group. Retrieved
April 29, 2004, from http://www.triagetag.com/triagetaginstructions.html
The University of Queensland (2004). Multimedia Authoring Guidelines Home Page: The
University of Queensland. Retrieved April 12, 2004, from
http://http://www.tedi.uq.edu.au/mag/3_Specification/Specification03_ProofOfConcept.h
tml
Casualty Tracking Project 7
If you need to type anything after the reference list then start it on this page