NJ Community Blood Bank

Stevens Institute of Technology

SENIOR DESIGN PROJECT 2005-2006 FINAL REPORT

E M E RG E N C Y C O M M U N I C AT I O N S SYSTEMS
BLOOD BANK INVENTORY MANAGEMENT SYSTEM DATABASE

Project Coordinator: Professor Bruce McNair Project Advisor: Group Number: Group Members: Professor Hong Man 23 Shamim Akhtar Ravi Amin Imtiazur Rahman Ndiritu Muriuki Date: May 1, 2006 I pledge my honor that I have abided by the Stevens Honor System _________________________________ _________________________________ _________________________________ _________________________________ _________________________________

TABLE OF CONTENTS
I. Abstract 1. Acknowledgement ................................................................................................ ................................................................................................ 3 5

II. Implemented System 1. 2. 3. 4. 5. Introduction Specifications

Performance and Evaluation

.................................................................................................. 6 ................................................................................................ ................................................................................................ ................................................................................................ ................................................................................................ ................................................................................................ ................................................................................................ ................................................................................................ ................................................................................................ 7 8 22 24 25 27 28 29

Financial Budget Project Schedule

III. Conclusion IV. References V. Appendices

Page 2 of 31

I. ABSTRACT

The Emergency Communications Systems (ECS) will address the need of the blood banks to coordinate blood units in conjunction with the Emergency Management Services (EMS) including hospitals, police and local authorities. Communication between hospitals and the blood centers supplying blood and blood products is essential for the provision of appropriate patient care. The ECS will be successful in times of crisis such as natural disasters and terrorist activities.

The tragic circumstances surrounding the events of September 11, 2001, the massive power outage of August 2003 and the recent upgrade to orange under the terror alert program have brought to light major weaknesses in the Tri-state areas blood delivery supply system. The blood bank centers in Northern New Jersey serve much of the state and parts of the greater New York City metropolitan area. This fact makes it an integral part of the relief effort of any catastrophe. Using the ECS system the blood bank centers would be able to respond in an effective and timely manner during catastrophic emergencies. This would provide them an adequate, coordinated emergency communication system between blood suppliers, hospitals, and emergency response personnel.

Cataclysmic events cause unforeseen disruptions which often require large supplies of blood, platelets and plasma to treat the injured and affected. It is therefore important to have in place a system of communications between hospitals, blood centers and local emergency responders, which does not rely solely on our present communications infrastructure. The ECS will be able to act as a conduit during inter-agency communication. This system will
Page 3 of 31

provide a computer database interface which will confirm the inventory of supplies located at various blood banks thus providing assistance to the most affected region in an efficient manner.

Page 4 of 31

I-1. ACKNOWLEDGEMENT

We would like to acknowledge the following People and organizations as they have provided us with invaluable support as subject matter experts and also as financial sponsors:

Hong Man Assistant Professor, Department of Electrical & Computer Engineering Bruce McNair Distinguished Service Professor, Department of Electrical & Computer Engineering Audrey Curtis Project Director of Telecommunications Management Program Management, Wesley J. Howe School of Technology Dr. Dennis Todd President and CEO Community Blood Services, NJ Stevens Institute IT Department: Frank Cataruozolo, Director of the Computer Service Center, Joseph Formoso, Senior Systems Administrator, Management Team Members: Praveen Tanguturi, Phd Student Joel Perez (Business Technology) Sarah Quinn (Business Technology) Nick Mabunay (Business Technology).

Page 5 of 31

II. IMPLEMENTED SY STEM

The goal of the project was to design a relational database with a web interface as a front end that the NJ blood banks can use to store their blood unit inventories. Other blood banks, police, hospitals and emergency response units in the ECS network can easily access this database in emergency situations as a central repository. After each individual blood bank has entered its data into their respective databases the blood inventories from the different NJ blood banks can be viewed in a single webpage. To achieve this, our database has to have the characteristics and requirements as described in the following section II-2 entitled Specification.

Page 6 of 31

II-1. INTRODUCTION

The Emergency Communications System that has been designed during the course of Senior Design is based on a core network linking eight blood banks across North Jersey. The core network will consist of centralized and local databases used to manage, organize and view the blood banks inventories. The local database will allow the blood banks to keep track of their own inventory, while updating their inventory to the centralized database, allows others to access and view when an emergency situation arises. Hospitals will also be given access to the centralized database, allowing them to also view inventory during emergency situations. This core network will also provide a communication medium between the blood banks and hospitals.

Page 7 of 31

II-2. SPECIFICATION

The group considered various models for selecting the appropriate design which would be suitable for the blood banks, hospitals and related agencies in the network. The design needed to be easy to use so that the IT department of the blood bank would be able to manage it internally without requiring specialized software or personnel. Also since the blood banks have complicated systems in place for communications the group concentrated on creating a web driven interface which would allow the various agencies to view, modify and delete the database with ease. The specifications for this system can be broadly classified into two distinct components: the database and the website. Details about them are described in the following sections of the report.

Page 8 of 31

II-2.1 DATABASE

The database was designed to run on a Windows platform. The group decided to stay within this bound because the technical personnel available in the blood banks who had been interviewed are well versed in running and maintaining Windows servers and applications that run on the windows platforms. This precluded any databases that run primarily on UNIX or Linux. The disadvantage is the cost implications of hiring technical expertise to run these systems have to be taken into consideration.

Various design considerations were taken into account when selecting the type of database that will be used for this project. The most important of them are described below: The cost of purchasing, developing and maintaining the blood bank database and API has to be kept at a minimum. We have to take into consideration that our clients will be small business enterprises, so the Cost: solution created has to be affordable and cost effective so that operational efficiency can be realized. We have to use technologies that are widely available and can be supported by the IT personnel in the blood banks as they are right now. We decided on using the Windows platform for our database. We had the choice of 32 or 64 Bit Operating Systems, we chose 32 bit, to minimize Platform: interoperability concerns with the blood banks internal systems. The operating system to some extent determined the type, cost and capability of the database we develop. We had the option of Windows, UNIX and Linux. Any Front end we build should be flexible enough to be run on any platform with little or no modification. We have to take into consideration
Page 9 of 31

Portability:

that some parts of our eventual application will be run by institutions and companies that have varying versions and types of operating systems. The database has to have the potential to be easily scaled upwards with little expense and minimal redundancy, should the business expand or Scalability: incorporate new products that would fit into this blood bank model. We also need to make a product that can be easily modified and marketed to other institutions that are the same line as the blood bank. High The blood bank database should be available 24x7 with little or no Availability: interruption. We are striving for 99.9% availability. Given the nature of the business, every minute saved can mean a life saved. Since we would like to give the business continuity during the change over to an electronic database from a manual inventory system, the database Simplicity: front end and backend have to be simple enough to be used and understood by the people working on it daily, and for the IT staff who have to regularly maintain the system. The database front end has to have a method of authenticating users before granting access. Any data that is being transmitted to and from the Security: database has to be transmitted securely and possibly even encrypted because of privacy concerns. The database has to be easily backed up daily and easily recoverable in an Backup & Recoverability: emergency. Interpretability with an API The database will have a front end, and because of this it should be able to easily communicate back and forth with the interface the users will see. The database has to be capable of accepting input and also furnishing output.

Page 10 of 31

The group chose MySQL server because it met our requirements as a relational database that can host multiple tables, and with these tables perform calculations and data manipulation from data entered. This is also a high Availability Cluster that can give us 99.99% uptime when properly maintained. The database has cluster functionality and thus offers us redundancy and high availability in our perceived 24x7 environment. The benefits of using MySQL Server can be summarized as the following: Windows Platform: Runs on Windows server 2003 Enterprise edition, that is the day to day Operating system used by the NJ Blood Banks It is a simple and straight forward installation Has integrated security with Active Directory to maintain Data Integrity This is a true relational database Robust enough to host and process large databases 32 and 64 Bit versions easily available Local resources available at the blood bank can run and manage the database system with ease

For the purposes of Senior Design this MySQL database is installed on a Windows XP Professional computer with IIS installed. The system has also been tested with Apache Server to determine its compatibility with open source platform. The MySQL database is currently running on a managed server at the Computer Service Center at Stevens Institute. This server will act as a backend to the website that will be designed to run PHP-MySQL plugins. In case the blood bank does not have an existing database in place then the ECS team will be able to easily create a suitable database to manage their inventory. The web
Page 11 of 31

server will be running IIS as our web engine. The website will be HTML with embedded PHP code primarily for data manipulation and as a link to the database. Users will access the database through a PHP enabled web interface. They will require a HTML browser (IE, Mozilla, Netscape, Firefox, etc) to view and input data into the database.

Page 12 of 31

II-2.2 WEBSITE

The website is based on HTML and the web pages have PHP code embedded in them to display the data from the database. The web pages also have features to update and delete entries and tables from the database and adding new users and setting privileges of existing users to access the database.

Figure II-2.2.1 shows the Log-in screen to access the database

The following lines of code accept the users input for id and password in the webpage shown above. The lines of code shown here drive the login process. The login and password are passed on to verify_login.php file. <form method="POST" action="verify_login.php"> <p>Login: <input type="text" name="login" size="20"></p> <p>Password: <input type="password" name="pwd" size="20"></p> <p><input type="submit" value="Submit" name="B1"></p>

Page 13 of 31

The following shows the Verify_login.php web page. include("config.inc.php"); //this calls the the config_inc.php file that contains all the login variables that are used to connect to the database $login = trim($HTTP_POST_VARS["login"]); $pwd = trim($HTTP_POST_VARS["pwd"]); // here the login and password are trimmed to remove any empty spaces $user = new user; if ($user->verifylogin($con,$usertable,$login,$pwd)) { $usercode = $user->usercode; $usertype = $user->usertype; session_register("usercode","usertype"); header("location: ".$user->page); } else { header("location: log_form.php"); } class user { function get($con,$usertable,$usercode) { $sql = "select * from $usertable where usercode = $usercode"; $result = mysql_query($sql,$con) or die (mysql_error()); $row = mysql_fetch_array($result); $this->usertype = $row["usertype"]; $this->login = $row["login"]; $this->pwd = $row["pwd"]; $this->page = $row["page"]; } function verifylogin($con,$usertable,$login,$pwd) { $sql = "select * from $usertable where login = '$login' and pwd = '$pwd'"; $result = mysql_query($sql,$con) or die (mysql_error()); if (mysql_num_rows($result) > 0) { $row = mysql_fetch_array($result); $this->get($con,$usertable,$row["usercode"]); return true; } } } ?>

Page 14 of 31

The Verify_login.php web page compares the username you have given with the username that exists in the database, it has a class called verify_access.class.php that performs this function. If the username is false it will open the page login.htm that will display a message to the effect that your login information is wrong. If the login name and password have corresponding entries in the database, this page redirects you to your corresponding homepage that is located in the page column that is in the user table.

The sample user table with corresponding home pages is shown below. The administrator creates the usernames and passwords that the users will use. Every user must be given a default login page and a user code that corresponds to their permission level.

Figure II-2.2.2 shows the Users table viewed using MySQL Query Browser

Page 15 of 31

The code below has been extracted from the config_inc.php page. It shows all the variables that are required to connect to the database. It has values for the server where the database is located, the database SID, the username and password of the account that has access to the users and permission tables.

Config_inc.php: $server = "localhost"; // mysql server $mysqluser = "root"; // mysql user $mysqlpass = "password"; //mysql password for user $mysqldb = "database"; // mysql database to use $usertable = "user"; // name of the table witch contains user login, code and password $usertypetable = "usertype"; // name of the table witch contains user types $permtable = "permissions"; // name of the table witch contains website permissions // [end of variables to set] if (is_null($errorpage)) { $errorpage = $default_errorpage; } $con = mysql_connect($server,$mysqluser,$mysqlpass); $db = mysql_select_db($mysqldb); session_start("power2protect");

Once a user has logged in, different users have different permission sets. The Administrator has permissions to Add users and blood banks to the system. The operator has permission to add blood to the blood_info database and the user has permission to view blood inventories in the system.

Page 16 of 31

Below is a sample home page of an administrator when they log into the blood bank list.

Figure II-2.2.3 shows the administration web page for the database

The code below is a template file (create_blood_banks.tpl) that is used to create the fields that are used when data entry into the bloodbank database is being done. The corresponding page created is shown above.

Page 17 of 31

Create_blood_banks.tpl <form action="index.php?section=create_bloodbanks" method="post"> <label for="co_name">Company Name</label> <input type="text" name="co_name" id="co_name" value="" /> <label for="address1">Address</label> <input type="text" name="address1" id="address1" value="" /> <label for="address2">Address Line 2</label> <input type="text" name="address2" id="address2" value="" /> <label for="city">City</label> <input type="text" name="city" id="city" value="" /> <label for="state">State</label> <input type="text" name="state" id="state" value="" /> <label for="zip">ZIP</label> <input type="text" name="zip" id="zip" value="" /> <label for="county">County</label> <input type="text" name="county" id="county" value="" /> <label for="primary_fname">Primary Contact First Name</label> <input type="text" name="primary_fname" id="primary_fname" value="" /> <label for="primary_lname">Primary Contact Last Name</label> <input type="text" name="primary_lname" id="primary_lname" value="" /> <label for="primary_tel">Telelephone</label> <input type="text" name="primary_tel" id="primary_tel" value="" /> <label for="usercode">USER ID</label> <input type="text" name="usercode" id="usercode" value="" /> <input type="submit" name="submit" value="save" /> <input type="button" name="cancel" value="cancel" onclick="document.location='index.php?section=list_bloodbanks';" /> </form>

Page 18 of 31

Figure II-2.2.4 shows the Users web page where the Administrator can control the permissions of the users of the database

Below is the sample code for an operator when the log in to enter blood units into the system.

Figure II-2.2.5 shows the blood unit inventory page where the individual bloodbanks can update their inventory information

Page 19 of 31

The code below is a template file (create_blood_info.tpl) that is used to create the fields that are used when data entry into the blood database is being done. The corresponding page created is shown above. create_blood_info.tpl <form action="index.php?section=create_blood_info" method="post"> <label for="blood_type">Blood Type</label> <input type="text" name="blood_type" id="blood_type" value="" /> <label for="comments">Comments</label> <input type="text" name="comments" id="comments" value="" /> <label for="date_updated">Date Updated</label> <input type="text" name="date_updated" id="date_updated" value="" /> <label for="time_updated">Time Updated</label> <input type="text" name="time_updated" id="time_updated" value="" /> <label for="expiration">Expiration</label> <input type="text" name="expiration" id="expiration" value="" /> <label for="batch_id">Batch NO</label> <input type="text" name="batch_id" id="batch_id" value="" /> <label for="bloodbank_id">Blood Bank ID</label> <input type="text" name="bloodbank_id" id="bloodbank_id" value="" /> <label for="quantity">Quantity</label> <input type="text" name="quantity" id="quantity" value="" /> <input type="submit" name="submit" value="save" /> <input type="button" name="cancel" value="cancel" onclick="document.location='index.php?section=list_blood_info';" /> </form>

Page 20 of 31

Blood inventory information of various blood banks as viewed by the hospitals, Emergency Management Services (EMS), police and state and local officials who have access to the database.

Figure II-2.2.6 shows the webpage that the hospitals and other EMS agencies will see when they log in to the ECS network.

Page 21 of 31

II-3. PERFORMANCE & EVALUATION

The system consisting of the database and the web server are meant to be operational under tenuous circumstances. That is why the system went through extensive testing under varying conditions. The group used the following guidelines to conduct different tests: Database was operational and undamaged during disasters Core data remained uncorrupted All data remained secure and was not exploited If the database instance crashed then it was easily recovered If the database instance was corrupted then it could be easily recovered from existing backups The group believes following these procedures during the testing phase of the project will produce a robust system.

The primary risk considerations that were tested were what-if scenarios. During these simulations it was decided that if all means of data communications fail then the centralized database would not be able to serve its purpose. For the database to be fully functional all the blood banks in the network need to be able to update and retrieve data from it. For the purposes of senior design the centralized server being used is the MySQL database being hosted on the managed server space of the Stevens IT Department.

The primary database has been built according to the specifications provided by the blood banks and input from the members of the ECS team. This database has been uploaded to the managed server space and is accessible to all using proper identification. In order to
Page 22 of 31

maintain the integrity of this production database no test queries or scripts are run directly on it. For this reason the group exported MySQL production database. From the export, an identical instance of the database was created on the local machines of group members as development databases. This was done using MySQL Administrator utility provided by the MySQL development group. There were no errors or warnings during the export or initialization and mounting of the database. This task also ensured that the production database is properly backed up.

Using PHP Designer 2006 the group was able to create web-pages that connected to the MySQL database on the local host. These web-pages presented the data from certain tables, as well as, selected columns from multiple tables and views. However the group ran into certain difficulties while running PHP scripts because a certain error repeated itself. It generated the following error message whenever select command was issued to the database: Resource ID#2. However by rephrasing particular queries this error was avoided.

However in spite of all the difficulties, the group was able to complete the project on time. The group created the webpages by developing elegant queries which would be able to serve all the needs of the blood banks, hospitals and other related agencies.

Page 23 of 31

II-4. FINANCIAL BUDGET The financial budget for this project is shown in the following table. It lists costs of parts as well as labor performed and having an office and staff for maintaining the database.

Product Description Direct Labor Employees Materials and Parts Server Personal Computer Printer Office Furniture Stationary Supplies Database MySQL PHP Office Rent Miscellaneous Travel Expenses Total

Quantity 4 people

Price of Product $25/hr (40hrs/week)

Total Cost /year $200,000/year (including bonus) $18,000 $6,000 $1,000 $4,000 $2,000 $4,000 -

2 4 2 4 4 2 2 (In house facility) 30 trips/year

$9,000 $1,500 $500 $1,000 $500 $2,000/server/yr -

$30/trip

$900 $235,900

Table II-4.1 displays the financial budget for the ECS project.

Page 24 of 31

II-5. PROJECT SCHEDULE

The work break down structure and the milestones for the Spring 2006 and Fall 2005 semesters are shown in the following figure. It is evident from the figure that the project consistently stayed on schedule and met the milestones in a timely manner.

Table II-5.1 displays the work breakdown structure for Spring 2006 semester

Page 25 of 31

Table II-5.2 displays the work breakdown structure for Fall 2005 semester

Page 26 of 31

III. CONCLUSION The aim of this project is to develop a system which will allow the participating blood bank centers in New Jersey to coordinate their relief efforts with other agencies during times of misfortune and tragedy. When this system is put in place it will allow the blood banks to monitor each others blood unit supplies. Thus if one center is running short of blood units of a particular type then it can request more units from another center. This system will also allow the blood banks to communicate with other agencies and send appropriate supplies in a timely and efficient manner. The Centralized Inventory Database (CID) will reside in one blood bank. This blood center will act as a node which can act as a Command Center synchronizing supply efforts between the various centers. A preliminary database design is being considered currently. Since the project is being planned for blood centers with a limited and conservative budget, concepts with expensive software are being avoided. The database will contain minimum information needed to demonstrate the state of supplies at each blood center and their immediate requirement for supplies, if any. The other blood banks in the network will be able to access the database with any standard web browser. This would eliminate the cost to purchase, install and maintain any new software and hardware. The implementation of this system will increase the aid efforts following any disaster by efficiently using the available resources. This will help in decreasing the number of injuries and casualties in a variety of tragic scenarios.

Page 27 of 31

IV. REFERENCES Various websites and reference material has been consulted during the course of this project. The most important references have been listed below. 1. MySQL Server (http://www.mysql.com/ ) 2. PHP web component (http://www.php.net/ ) 3. NJ Community Blood Banks (www.state.nj.us/health ) 4. Red Cross Model System (www.redcross.org ) 5. NJ Office of Emergency Management (http://www.state.nj.us/njoem/ ) 6. Blood Center of NJ (www.bloodnj.org/ )

Page 28 of 31

V. APPENDICES
V-1. Block Diagram:

The following Figure V-1.1 shows where the database would be placed in reference to the other relevant components of the ECS network. It also demonstrates how the different agencies would be able to access the database through an active internet connection. The users can be authenticated at the web server and can be re-authenticated at the server hosting the database with standard passwords.

Table V-1.1 displays a data flow diagram showing the design of the ECS system

Page 29 of 31

V-2. Core Network:

The following Figure V-2.1 shows how the different blood banks form the ECS network. The blood unit inventory database will reside inside the core network and will be accessible by the blood banks.

Table V-2.1 displays the core ECS network and the location of the database in this network

Page 30 of 31

V-3. Lines of Communications

Page 31 of 31 Table V-3.1 displays the different types of communications failure that might occur