The Well Meadows Hospital Management System
This document describes an online management system for a small hospital named as wellmeadows. This system creates online data storage for all the information related to the proceedings of the hospital and hence making the information available as well as more reliable to the users. The information becomes easily accessible as well as more secure with the system being secured by user credentials.
The hospital’s current functionality is based on a register based system that involves the maintaining of every transaction, records of patients, doctors, nurses in huge files that are stored in hospital’s store room. It is not only difficult to search for certain information but also very difficult to maintain historical data. The old files are prone to get damaged and it is very difficult to manage this huge collection of documents and keep it organized.
The new system is based on a database management system that allows secure, easy and reliable storage of data and retrieval is also very easy. In the old system, a user needed to know in which register particular information is stored but in the new system a user has a graphical interface, where he can simply search for the information by doing some clicks and selecting the correct options (Liang 2010). The ease in accessing information not only improves the information management but also impacts the day to day activities of the hospital. It reduces the delay in information retrieval and the delay in providing necessary treatment to the patients as per their historic records is also reduced that will improve the efficiency and effectiveness of the treatment (Prokosch & Dudeck 1995).
Intended Audience and Reading Suggestions
This document is meant for the users of the system i.e. the administrators and staff of the wellmeadows hospital. This document explains the system design and its usage and not meant for external users. This document not only guides the user how to operate the system but also tells how to use the system efficiently to match with requirements of the user and let him take the profit out of it. This document will also help the developers in the situation where modifications are required in the system.
Project Scope
The project currently is limited to the internal use of the hospital and is simply meant to store and provide useful information. The system doesn’t generate any information or predictions of its own. The system will be helpful in better management of the hospital and will provide all the information in an organized manner. This project is not meant for users outside the hospital and will not allow any person outside the hospital to see the internal and personal information of the people connected to the system. The system will keep the information secure and will keep it limited to people with proper access only.
Overall Description
Product Perspective
This product is a change of methodology for the hospitals and firstly, it will be implemented in the Wellmeadows hospital. There are several similar systems in other big hospitals but this system is designed to meet the cost and utility requirements of the small hospital. This product is an evolutionary product that will be improved in the future and more functionality will be added to it.
Product Features
The product is useful to the hospital in a number of ways as it provides following features to the hospital:-
Easy, storage and retrieval of all patients’ information that not only helps to maintain track record but also helps the doctors as they can know the treatment history of the patients.
Store the entire information about doctors that allow the hospital to decide, which patient will be treated by which doctor. This product not only helps in providing better treatment to the patients but also helps in building trust with patients. It also helps to know about the doctors, who are preferred by patients (Sumathi & Esakkirajan 2007).
Storage of staffs’ information that helps in smooth running of the hospital.
Storage of all drugs used in the hospital and all drugs being prescribed to the patients that allows more control over the quality of drugs used. It also ensures uniformity among various doctors and to maintain the stock of drugs as per their requirements (Sumathi & Esakkirajan 2007).
User Classes and Characteristics
The system will be used by internal users only and will be accessible to outside users in a limited form. Following are the users of the system: –
Hospital receptionists: – The hospital receptionist will act as system administrators and will make all the entries in the system. They will have access to all the information in system and will take control of the normal proceedings of the hospital. Receptionists will register the patients, allocate staff to various wards, give appointments to patients and will maintain the central stock of medicines and drugs.
Charge Nurses: – The charge nurses will manipulate the information related to their specific ward and will be able to see all patients’ information in their ward and provide medication accordingly. They will also be able to see which staff is on duty in their ward and also will be able to see the stock of medicines in their ward.
Consultants: – The consultants will able to see the patients’ information and the list of appointments that have been allocated to them. The will be also able to see the wards in which they are assigned duties and will also be able to prescribe medicines to their patients.
Patients: – Patients will be able to see the appointments they have in the hospital and will be able to see the medicines that have been prescribed to them from the system.
Operating Environment
The system will be a web based system and can be accessed within and outside the hospital through a link over hospital’s website. The users will login the system using a username and password that will be provided to them by the system administrator and the system will be independent of the operating system.
Assumptions and Dependencies
The system assumes that the information being added to the system is correct and authenticated. It is also assumed that the username and password will be kept secret and will not be shared with anyone. The users will be themselves responsible for losing passwords. This system doesn’t include a mailing feature and hence the user should not lose their passwords in any case. The passwords will have to be reset by the database administrator only.
System Flow
A data flow diagram as its name suggests represents the flow of data in any system. There is a huge flow of data and information in any information system. This flow is analyzed with the help of data flow diagrams. Data flow diagrams can be used for visualization of data processing. On a DFD, data items flow from an external data source or an internal data store to an internal data store or an external data sink via an internal process (Calmet & Pfalzgraf 1996). A data flow diagram is composed of several components: –
Entities: – Entities are the sources of information in any system. These entities are the external sources of information in any system. It is very important to mention all the entities in a system. This ensures the proper flow of information in a system. These also act as external sinks for the system (Dennis, Wixom & Roth 2006).
Database or data store: – A database stores the information in any system. These act as internal data sources for a system. It stores the information from one process and provides information to other processes. It also acts as internal sinks in the system.
Processes: – A process is a function performed by the system. Each process helps to access the information from database or an entity and provide the information back to the entity or database (Dennis, Wixom & Roth 2006).
The DFD’s are represented in several levels. With increase in each level the details in the diagram also increased. Level-0 would contain minimum details, while level 1 would contain more details than level 0 and so on.
This section explains flow of the system, how the system operates and its functionalities with the help of data flow diagrams. The level of details increases with each diagram. The system at the highest level is nothing but a hospital management system; the inner details are not specified in the data flow diagram level-0 (Johns 2002). Here is the zero level data flow diagram –
(DFD level: 0)
The above diagram shows the four entities that will be involved in the system- patients, doctors, hospital staff and nurses. These are the four main sources of information in the system.
As the system is broken down into several modules, these entities match up their desired roles (Johns 2002). This breakdown gives us the exact information about the operations performed by the system and the entities involved in each operation.
(DFD level:1)
In the DFD level -1, the system is divided into three major domains namely patient management system, stock management system and staff management system. Patient management system is related to patients that includes two types of patients- inpatients and outpatients. Inpatients are those, which get admitted in the hospital and stay there while the outpatients take appointments and visit the hospital at given date and time (Johns 2002).
The second major section of the system is stock management system. In this, the requirements of the hospital are analyzed and accomplished such as clinical and non clinical requirements like drugs, bandages and other requirements. This part also maintains the division of these items among various wards and among various departments of the hospital.
The third section of the system is about the staff allocation system that ensures that all staff is being assigned proper duties and each wards getting proper number of employees and nurses for its daily operations and also for emergency situations. It also ensures that the consultants are visiting the wards on time and each patient is getting proper attention.
External Interface Requirements
User Interfaces
The user interface is simply a web interface, which is presented to the user through a web browser. This allows user to enter data and select from various drop down menus. These drop down menus show the content read from the database. By simply clicking to submit buttons, user can save data into database. The user interfaces will also implement checks for null values being entered into database (Galitz 2009). It displays the format for date values to be entered, but doesn’t validate them. If there is any error in entering any values to the database, the system generates the error message and asks the user to retry. This helps the user to be ensured that the values have been entered and hence a consistency in the system is maintained (Galitz 2009).
Hardware Interfaces
As the system is a web based system, the website will be hosted on a central server machine with other machines getting access to it through the network. The other machines could be simple computers or especially dedicated machines that provide access only to the content. For our current implementation, we will rely on general desktop systems.
Communications Interfaces
The system uses HTTP (hypertext transfer protocol) for sending and receiving data over the internet (Groth, Skandier, Lammle & Tedder 2005). When the system is used within the hospital, it is presented on same network hence its generally faster as the server is also located within the hospital, but outside the hospital the system is accessible via internet and hence a domain is needed to be registered with the DNS servers hosted at the ISP.
Data Model
This section explains the data model used for the system. The section begins with recognizing all the entities to be used in the system and their relationships and then converting those entities and relations to tables. These tables will be normalized to 3NF form. This section captures the cardinality and referential integrity rules needed to ensure that the data is of good quality for the users. The main aim of data models is to support the development of information systems by providing the definition and format of data.
Entity-relationship model
The E-R (entity-relationship) data model views the real world as a set of basic objects (entities) and relationships among these objects (Bai 2010). It is intended primarily for the DB design process by allowing the specification of an enterprise scheme. If the information system, being designed, is based on a database then the conceptual data model will later be mapped on to a logical data model, which in turn will be mapped on to a physical model during the physical design process (Bai 2010). The E-R diagram shows all objects involved in the system as entities and the function among them as relationships. Here is a description of entities used in our system:-
Entity: – An entity is nothing but an object that exists and is distinguishable from other objects. Entities could be concrete such as a person or it could be an abstract entity that is nothing but a concept (Stallings 2008). An entity could also be considered as a source of information for the system. There are following entities in well meadows:-
Doctor or consultant (concrete)
Change nurse (concrete)
Patients (concrete)
Wards (abstract)
Drugs (concrete)
Administrator (concrete)
Staff (concrete)
Qualification (abstract)
Inpatient (concrete)
Outpatient (concrete)
Attributes: – Attributes are unique qualities that can be possessed by both relationships and entities. Attributes are represented by ovals that are connected to the entity sets that possess them by a line. With the exception of weak entities, all entities have to a minimum amount of attributes. These make up the primary key of the entity (Stallings 2008). Following are the attributes of the various entities described above:-
Doctor: – id, name, address, telephone, duty shift, date of birth
Change nurse: – id, name, address, telephone, date of birth, ward allocated.
Patients: – id, name, address, telephone, date of birth
Ward : – ward_num, ward_name, location, in charge nurse, number of beds
Drugs: – id, name, type, dosage, methodology, price, stock
Administrator:- username, password, name, address, telephone, date of birth
Staff: – id, name, address, telephone, date of birth, ward allocated.
Qualification:- institution name, qualification name
Inpatient:- id, name, address, telephone, date of birth, date of admit, expected stay, expected date of leaving, actual date of leaving
Outpatient: – id, name, address, telephone, date of birth, date of appointment, consultant name, location, time of appointment.
Here is an entity relationship diagram for the given system:-
(Entity Relationship Digram)
The patients are categorized into inpatients and outpatients as explained above while the staff has two categories doctors and nurses. The remaining staff is covered under staff itself. Wards are there in the hospital that is controlled by the nurses while drugs are referred by the doctors and they are taken by the patients. Both the inpatients and outpatients are treated by the doctors, while inpatients have a separate relationship with wards that they are admitted to it.
Database design and normalization
Normalization can be defined as the process in which data is taken from problem and reduced to a set of relations through data integrity and elimination of data redundancy (Gunderloy & Jorden 2008).
Data integrity: The data in the database is consistent and satisfies the all integrity constraints.
Data redundancy – Data redundancy incurs if it is found in two different locations (direct redundancy). At the same time the calculation of data from other items (indirect redundancy) also creates redundancy (Oppel 2004).
First normalized form: – The multi valued attributes are removed that facilitate a single value at the intersection of each row and column in a table.
Second Normal form: – In second normal form, all the non key attributes must be dependent on complete primary key and not on a single part of primary key.
Third normal form: – In a third normal form, all the non keys are determined only by the primary keys (Oppel 2004).
Boyce-Codd normal form: – The anomalies have been removed that resulted from the functional dependancies (Gunderloy & Jorden 2008).
The normalized schemas of the tables used in our database are given below:-
Drug
drug_ID
drug_name
description
dosage
method
Stock
Reorder
cost
Patient
patient_id
First Name
Last name
Address
telephone
Date of birth
Sex
Marital status
Date of registration
Staff
Staff_id
First Name
Last name
Address
telephone
position
Inpatient
id
Patient_id
Ward number
Bed number
Date placed
Expected Stay
Expected Date of leaving
Actual date of leaving
Ward
Ward number
Name
location
extension
Charge nurse id(staff.staff id)
Outpatient
id
patient id
Consultant id
Date
Time
location
Qualification
id
Staff_id
Type
Institution
Completion date
Weekly allocation
Ward number
Staff id
shift
date
Prescription
Patient_id
drug_id
Start Date
Units per day
End date
Database implementation
The database defined above needs to be implemented over a database system. We use a relational database management system as our designs are based on relational model. Considering the requirements of hospital that are not very large, we can use an open source, free of cost database management system named as MySQL. MySQL is a relational database management system (RDBMS) that runs as a server providing multi-user access to a number of databases. It works on most of the available operating systems and is generally the most popular choice for implementing small database applications. It also has a plug-in named as phpmyadmin that provides a GUI access to the database (Lambrix 2010). Here are the implementations of SQLs for the database:-
— phpMyAdmin SQL Dump
— version 3.2.4
— http://www.phpmyadmin.net
—
— Host: localhost
— Generation Time: Dec 12, 2010 at 08:58 AM
— Server version: 5.1.41
— PHP Version: 5.3.1
SET SQL_MODE=”NO_AUTO_VALUE_ON_ZERO”;
/*!40101 SET @[email protected]@CHARACTER_SET_CLIENT */;
/*!40101 SET @[email protected]@CHARACTER_SET_RESULTS */;
/*!40101 SET @[email protected]@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8 */;
—
— Database: `hospital`
—
— ——————————————————–
—
— Table structure for table `drug`
—
CREATE TABLE IF NOT EXISTS `drug` (
`drug_num` int(11) NOT NULL AUTO_INCREMENT,
`name` varchar(100) NOT NULL,
`description` varchar(100) NOT NULL,
`dosage` varchar(100) NOT NULL,
`method` varchar(100) NOT NULL,
`stock` int(11) NOT NULL,
`reorder` int(11) DEFAULT NULL,
`cost` decimal(10,0) NOT NULL,
PRIMARY KEY (`drug_num`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
—
— Dumping data for table `drug`
—
— ——————————————————–
—
— Table structure for table `inpatient`
—
CREATE TABLE IF NOT EXISTS `inpatient` (
`inpatient_id` int(11) NOT NULL AUTO_INCREMENT,
`patient_id` int(11) NOT NULL,
`expected_stay` int(11) NOT NULL,
`date_placed` date NOT NULL,
`date_leave` date DEFAULT NULL,
`actual_leave` date DEFAULT NULL,
`ward_num` int(11) NOT NULL,
`bed_num` int(11) NOT NULL,
`spouse_id` int(11) DEFAULT NULL,
PRIMARY KEY (`inpatient_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;
—
— Dumping data for table `inpatient`
—
INSERT INTO `inpatient` (`inpatient_id`, `patient_id`, `expected_stay`, `date_placed`, `date_leave`, `actual_leave`, `ward_num`, `bed_num`, `spouse_id`) VALUES
(1, 1, 5, ‘2010-08-12’, ‘0000-00-00’, ‘0000-00-00’, 1, 45, 0);
— ——————————————————–
—
— Table structure for table `outpatient`
—
CREATE TABLE IF NOT EXISTS `outpatient` (
`appointment_num` int(11) NOT NULL AUTO_INCREMENT,
`consultant_id` int(11) NOT NULL,
`patient_id` int(11) NOT NULL,
`date` date NOT NULL,
`time` time NOT NULL,
`location` varchar(100) NOT NULL,
PRIMARY KEY (`appointment_num`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
—
— Dumping data for table `outpatient`
—
— ——————————————————–
—
— Table structure for table `patient`
—
CREATE TABLE IF NOT EXISTS `patient` (
`patient_id` int(11) NOT NULL AUTO_INCREMENT,
`firstname` varchar(50) NOT NULL,
`lastname` varchar(50) NOT NULL,
`address` varchar(500) NOT NULL,
`tel` varchar(20) NOT NULL,
`dob` date NOT NULL,
`sex` varchar(10) NOT NULL,
`mar_status` varchar(20) NOT NULL,
`reg_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`patient_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=3 ;
—
— Dumping data for table `patient`
—
INSERT INTO `patient` (`patient_id`, `firstname`, `lastname`, `address`, `tel`, `dob`, `sex`, `mar_status`, `reg_date`) VALUES
(1, ‘yash’, ‘yash’, ‘yash’, ‘7799’, ‘0000-00-00’, ‘Male’, ‘UnMarried’, ‘2010-12-08 00:03:10’);
— ——————————————————–
—
— Table structure for table `prescription`
—
CREATE TABLE IF NOT EXISTS `prescription` (
`prescription_id` int(11) NOT NULL AUTO_INCREMENT,
`patent_id` int(11) NOT NULL,
`drug_num` int(11) NOT NULL,
`units per day` int(11) NOT NULL,
`startdate` date NOT NULL,
`enddate` date NOT NULL,
PRIMARY KEY (`prescription_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
—
— Dumping data for table `prescription`
—
— ——————————————————–
—
— Table structure for table `qualification`
—
CREATE TABLE IF NOT EXISTS `qualification` (
`q_id` int(11) NOT NULL AUTO_INCREMENT,
`staff_id` int(11) NOT NULL,
`type` varchar(100) NOT NULL,
`institution` varchar(100) NOT NULL,
`date` date NOT NULL,
PRIMARY KEY (`q_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
—
— Dumping data for table `qualification`
—
— ——————————————————–
—
— Table structure for table `requets`
—
CREATE TABLE IF NOT EXISTS `requets` (
`request_id` int(11) NOT NULL AUTO_INCREMENT,
`ward_num` int(11) NOT NULL,
`drug_num` int(11) NOT NULL,
`quantity` int(11) NOT NULL,
`date` date NOT NULL,
`processed` int(11) NOT NULL DEFAULT ‘0’,
`process_date` date DEFAULT NULL,
PRIMARY KEY (`request_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1 ;
—
— Dumping data for table `requets`
—
— ——————————————————–
—
— Table structure for table `staff`
—
CREATE TABLE IF NOT EXISTS `staff` (
`staff_id` int(11) NOT NULL AUTO_INCREMENT,
`firstname` varchar(50) NOT NULL,
`lastname` varchar(50) NOT NULL,
`address` varchar(500) NOT NULL,
`sex` varchar(10) NOT NULL,
`dob` date NOT NULL,
`tel` varchar(20) NOT NULL,
`position` varchar(50) NOT NULL,
PRIMARY KEY (`staff_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;
—
— Dumping data for table `staff`
—
INSERT INTO `staff` (`staff_id`, `firstname`, `lastname`, `address`, `sex`, `dob`, `tel`, `position`) VALUES
(1, ‘abcd’, ‘pqrs’, ‘asasd’, ‘Male’, ‘0000-00-00’, ‘123123’, ‘Charge Nurse’);
— ——————————————————–
—
— Table structure for table `staffhier`
—
CREATE TABLE IF NOT EXISTS `staffhier` (
`id` int(11) NOT NULL,
`description` varchar(100) NOT NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
—
— Dumping data for table `staffhier`
—
INSERT INTO `staffhier` (`id`, `description`) VALUES
(1, ‘consultant’),
(2, ‘Charge Nurse’),
(3, ‘physiotherapist’),
(4, ‘nurse’);
— ——————————————————–
—
— Table structure for table `tblusers`
—
CREATE TABLE IF NOT EXISTS `tblusers` (
`username` varchar(50) NOT NULL,
`password` varchar(50) NOT NULL,
`name` varchar(50) NOT NULL,
`wrong_count` int(11) NOT NULL DEFAULT ‘0’,
PRIMARY KEY (`username`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;
—
— Dumping data for table `tblusers`
—
INSERT INTO `tblusers` (`username`, `password`, `name`, `wrong_count`) VALUES
(‘admin’, ‘123456’, ‘administrator’, 1);
— ——————————————————–
—
— Table structure for table `ward`
—
CREATE TABLE IF NOT EXISTS `ward` (
`ward_num` int(11) NOT NULL AUTO_INCREMENT,
`ward_name` varchar(50) NOT NULL,
`location` varchar(100) NOT NULL,
`ext` int(11) NOT NULL,
`num_beds` int(11) NOT NULL,
`nurse_id` int(11) NOT NULL,
PRIMARY KEY (`ward_num`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=2 ;
—
— Dumping data for table `ward`
—
INSERT INTO `ward` (`ward_num`, `ward_name`, `location`, `ext`, `num_beds`, `nurse_id`) VALUES
(1, ‘ank’, ‘asasd’, 6666, 3, 1);
— ——————————————————–
—
— Table structure for table `weeklyallocation`
—
CREATE TABLE IF NOT EXISTS `weeklyallocation` (
`allocation_id` int(11) NOT NULL AUTO_INCREMENT,
`staff_id` int(11) NOT NULL,
`ward_num` int(11) NOT NULL,
`shift` varchar(50) NOT NULL,
`startdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (`allocation_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=4 ;
—
— Dumping data for table `weeklyallocation`
—
INSERT INTO `weeklyallocation` (`allocation_id`, `staff_id`, `ward_num`, `shift`, `startdate`) VALUES
(1, 1, 1, ‘EARLY’, ‘2010-12-07 18:52:40’),
(2, 1, 1, ‘NIGHT’, ‘2010-12-07 23:33:40’),
(3, 0, 1, ”, ‘2010-12-08 00:05:25’);
/*!40101 SET [email protected]_CHARACTER_SET_CLIENT */;
/*!40101 SET [email protected]_CHARACTER_SET_RESULTS */;
/*!40101 SET [email protected]_COLLATION_CONNECTION */;
This script will create the database and will make few entries in the tables as well. The username and passwords are stored in a table named as tblUsers. The admin password is also stored in the same table. This is the dump of the database exported by using phpmyadmin. Same script can be executed using the tool or also can be imported using the import option in phpmyadmin (Lambrix 2010). This will setup the database and the application can now be configured.
System implementation
The software package we choose for this system is XAMPP. Xampp is a software package that is used for hosting websites and the combination of four software packages namely php, apache, mysql and phpmyadmin. Xampp is a simple program that can be run on any machine; it does not require any specific hardware. Xampp is free software and it is available for various operating systems such as Linux, Windows, Mac OS, and Solaris etc. The programs sets up a mysql server on the system as well as an apache web server on the machine. The package also configures php for the machine and also provides phpmyadmin for managing the mysql database (Newman & Thomas 2008). Xampp provides a root directory named as htdocs that works for the web server. Xampp is the easiest way to host a website. Xampp is very easy to install and uninstall as compared to the separate installation and configuration of the services it provides. Xampp also includes support for filezilla, mercury etc.
Developers
Xampp is open source software developed by www.apachefriends.com. Apache friends were founded in 2002 by Oswald and Kay. Oswald is their webmaster, while Kay is the maintainer of apache for windows. Apache friends have Xampp as their only project (Newman & Thomas 2008). There are no new projects till date. The software package is available through Sourceforge that hosted the download files on their website www.sourceforge.net and made this whole project possible.
Benefits
Xampp has several benefits that make web hosting easy. These are as below: –
It is available in many languages such as English, Dutch, Italian, French, Portuguese and Chinese etc.
It makes database management very easy with support of phpmydmin.
The support for filezilla makes file transfer via FTP very easy and hence easy to upload files from a remote location (Hudlicka 2007).
It configures php by itself that can be a very tedious task if installed separately.
Xampp can also be installed as a system service that allows it be started by itself.
Xampp easily creates a local server that can be used for development of websites.
Backend Database: We expanded the existing database of the University. It was implemented on MySql. For the robustness and to remove the redundancy in the database, the database tables were converted to BCNF normal form. The centralized database server was implemented as a Master and for the backup of it, slave was created. The 2 were kept in synchronization by running a crone job that keeps running 24×7 to eliminate the loss of information (Hudlicka 2007).
Graphical User Interface (GUI): Php with html was used for the GUI. All the web pages were designed in php as a server side scripting language. JavaScript was also used for the graphics display.
Programming Languages: Php was used for web interface and SQL for the database implementation (Hudlicka 2007).
Security
The system is susceptible to a lot of security breaches. The following are the risks at the system: –
Somebody may try to hack the network from outside.
One user might try to access another user’s account.
Somebody might capture all the information being sent on the network.
The following solutions are suggested:-
A strong firewall should be maintained and updated regularly.
Each user should be prompted to change the password after regular intervals.
System Testing
In this section, we will describe the methods of testing the system, its implementation, maintenance and evaluation. Testing is the process of executing a program with the intent of finding errors. We first describe the functional testing of the system, i.e. to test each function separately. We will prepare test cases for each function and test the function with those test cases. These cases are developed for two methods of testing – White-box Testing and Black-box Testing (Mosley & Posey 2002). In White box testing we find the input that might cause erroneous outputs in our system. In black-box testing we choose random inputs for testing the system.
Smoke Testing: – This testing means to check whether the system burns if switched on. This testing was initially done for electric circuits, means if there was smoke then the circuit has burnt and there are some problems with the design (Mosley & Posey 2002). For our system smoke testing would be to see if the website is opening, each links takes us to correct page.
Black-Box testing: -Black Box testing includes tests that validate business requirements. Test cases are derived from the requirements specification of the software. No knowledge of internal program structure is used. It is also known as functional, data-driven, or Input/output testing.
White-Box testing: -White Box testing includes the tests that validate internal program logics (control flow, data structures, data flow). Test cases are derived by examination of the internal structure of the program. It is also known as structural or logic-driven testing (Mosley & Posey 2002).
System Testing: –
System testing is done by a careful selection of relevant test cases. We try to cover each and every possible error by minimum number of test cases. For this, the following testing methods will be used for black box testing (Mosley & Posey 2002).
Equivalence class partitioning
Boundary value analysis
Cause-effect graphing
Error guessing
For white box testing
Statement coverage
Basis Path Testing
Decision coverage
Loop testing
Condition coverage
Decision-condition coverage
Data flow testing
Multiple condition coverage (Mosley & Posey 2002).
Conclusion
From the above discussion, it can be concluded that the new system will be effective to improve the effectiveness of hospital and also the treatment for patients. The use of appropriate hardware and software will also be effective to reduce the cost of hospital to implement the new system for the data management.
Order Now