Thursday, September 5, 2019

The Well Meadows Hospital Management System

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 hospitals 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 hospitals 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 doesnt 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 hospitals 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 doesnt 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 DFDs 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 doesnt 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 @[emailprotected]@CHARACTER_SET_CLIENT */; /*!40101 SET @[emailprotected]@CHARACTER_SET_RESULTS */; /*!40101 SET @[emailprotected]@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 [emailprotected]_CHARACTER_SET_CLIENT */; /*!40101 SET [emailprotected]_CHARACTER_SET_RESULTS */; /*!40101 SET [emailprotected]_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 sup

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.