The software methodology followed in this project includes the object-oriented methodology and Iteration methodologies. It starts with an initial planning and ends with deployment with the cyclic interactions in between. The basic idea behind this method is to develop a system through repeated cycles (iterative) and in smaller portions at a time (incremental), allowing software developers to take advantage of what was learned during development of earlier parts or versions of the system. We will use three fact finding techniques to find the correct information on the development of our system.
The techniques which were used by us include: * Interview One of the most important ways of gathering information are interviews ,the interview simply is talk to employee. * Document Sampling * Work Site Observation Significance of the Project The main significance of this project to introduce the computerize system for Felege HiwotReferal Hospital, which gives effective services for patients. The system enables hospitals and doctors to better serve their patients, improve quality of patient care, reducing the time spent. Chapter Two: SYSTEM FEATURES 1. Existing System Description
Hospitals currently use a manual system for the management and maintenance of critical information. The current system requires numerous paper forms, with data stores spread throughout hospital customer information management infrastructure. Often information is incomplete, or does not follow management standards. Forms are often lost in transit between departments requiring a comprehensive auditing process to ensure that no vital information is lost. Multiple copies of the same information exist in the hospital and may lead to inconsistencies in data in various data stores. 2.
... power, human capital and both equipment and financial resources. Information systems (IS) projects are often seen as being vulnerable to cutbacks in resources ... the organization meet its objectives. They might identify an upgraded data processing department or a new integrating network facility to support ...
Proposed System Description The Hospital Customer Information Management System is designed for Any Hospital to replace their existing manual, paper based system. The new system is to control the overall patient information. These services are to be provided in an efficient, cost effective manner, with the goal of reducing time and resources usage. 3. Specific Requirements 3. 1 Tools and Material Requirement Software Requirement| purposes| Microsoft visual studio 2010 using c# csharp| To easily develop the system | SQL server 2005/2008| For database designing| Notepad++| For editing code|
Microsoft Visio| For system designing like relational mapping, ER_diagram, entity and so on. | Crystal report software| To generate report from the database| Table [ 1 ]. Software Requirement Hardware Requirement| Purposes| Computers| For system develops | Table [ 2 ]. Hardware Requirement 3. 1 User Requirements 3. 1. 1 Functional Requirements * Req1. The system shall add a patient. * Req3. The system shall search a Patient. * Req4. The system shall generate patient information report. * Req7.
The system shall modify an account. * Req8. The system shall allow new users to create account. * Req9. The system shall request patient full information. * Req10. The system shall check login validity. 3. 1. 2 Non Functional Requirements * The system should be easy to use for the user. * The system shall be available work 24 hours. * The system shall be efficient to full fill patient needs. * The system should be secured from any user. * The system shall recover from error within a short period of time. * The system shall minimize errors and clear error message must be displayed that guide user to handle it. . 1. 3 System requirements R1. The system should have a database to store data and information about the user. R1. 1. the system shall store data from the user. R1. 2. the system shall check the patient information that is complete or not. R1. 3. the system checks that all information are entered. R1. 4. the system saves information about the user. R2. The system should be ready for the user to login on the system by displaying a login on interface. R2. 1. the user want to login. R2. 2. the system displays the login form interface for the user. R2. 3. the user submits his/her password and user name. R2. . the system verifies his or her password and user name. R2. 5. the system displays a message if the user name or password not correct. R2. 6. the system login the user if user name and password is correct. R4. The system shall be able to search all users. R4. 1 the system wants to search. R4. 2 the user enters the wanted data. R5. The system should prevent the data base management system from any an authorized access. R6. The system gives service for the patients from local access where there is internet access. R7. The system should be able to display error message if users missing some information. R8.
... either internal or external to the organization. These users need information to help them make informed or reliable decisions ... demands for the financial information contained in a set of accounts. Information needs of internal users These include; Management; ... needs depend on its own particular interests. They require information on; Annual Reports (including financial statements) social costs ...
The system should add,search and update patients Analysis Models DFD Patient OPD Patient register Department Special Doctors Pharmacy Laboratory Patient Ok Operation Figure [ 1 ]. Data Flow Diagram Use case diagram Figure 2. Use Case Diagram. Use Case Description. Use Case Id:| UC-001| Use Case Name| Patient Register | Use Case Description| In this business use cases those Patients will going to the hospital and will be registered in the system. | Actors:| Patient| Preconditions:| * List of accepted patients are registered to the registration form. | Flow of Events:| 1. The Patient asks for registration. . The receptionist checks if patient’s name is in the list of registration form. 3. The Patient submits all required details. 4. receptionist validates all submitted details. 1. patient registered. 5. End use case| Alternate Flow:| 2. 1 patient details is not found in the system 2. 2. 1 The receptionist informs the patient that he/she can’t register. 2. 2. 2 The registration process terminates. | Post condition| patients are registered to the system and get services. | Goal| To register patients with appropriate information| Table [ 3 ]. Use Case Description. Use Case Id:| UC-002|
... Patient case study. Part I: I would like to start by ... China, where the doctor besides doing his job would engage in a social conversation with the patient, speak about the ... is a disease that damages the body's immune system (the system that helps fight off illnesses). When a person's ... a cold and distant as they get from the other doctors. The family values their children more than themselves. Thus, ...
Use Case Name:| Treat Patients| Use Case Description| This business use case is used to treat patients who are registered . The treatment is based on patient’s problem/diseases level. | Actors:| * Doctor * OPD * Department| Preconditions:| * patient details resisted in to the system and checked. | Triggers:| * Notification letter from Zone| Flow of Events:| 1. OPD calls patient who is registered. 2. OPD ask the patient what kinds of symptoms he/she has. 3. If the patient easily treated, the OPD prescribe the patient, otherwise he/she send to one of the department as the patient type. 4.
The Doctor checks if the patient is under goes operation or prescribe medicine. 5. The patient perform operation. 6. The patient prescribe medicine. 7. The patient completes treatment. 8. The use cased end. | Exceptions:| | Information Requirements:| | Assumptions:| | Table [ 4 ]. Use Case Description. Use case id| UC_003| Use case name| Check patient examination| Actor | Doctor| Description | Doctor verifies patient diseases by using powerful instrument. | Precondition | Patients should be treated by Opd. | Basic course of action| 1) Doctors show patient result transferred from OPD 2) Check whether the instrument has or not. ) If the instrument have treat patient. 4) Check patient result. 5) Record result into system. 6) The system check the data is record correctly. 7) Send data into other department. 8) Check the data correctly. 9) The use case end. | Post condition| Patient information is checked. | Goal| To check Patient status is valid or not| Table [ 5 ]. Use Case Description Use case id| UC_004| Use case name| View report| Actor | Opd| Description | Allow managers to view the overall daily patient registered. | Precondition | The system should generate report| Basic course of action| 1. Open the home page 2. Enter username and password 3.
The system validates username and password 4. Opd View system generated report 5. The use case ends| Alternative course of action| A3. The system Determine the entered username and password invalid. A4. The system notifies the Opd the username and password is invalid and prompts to renter. | Post condition| The Opd view report. | Goal| To view timely report of patient| Table [ 6 ]. Use Case Description Use Case Id:| UC-005| Use Case Name| Login| Use Case Description| In this business use cases Doctors, receptionist, each department will going to the developed system and will be login first to start some applications/services. Actors:| Doctors, receptionist, department| Preconditions:| * Doctors, receptionist, department are login to the system form. | Flow of Events:| 1. The Doctor should login first. 2. The Doctor checks if registered patients in the system. 3. The Doctor identifies what type of patients are registered. 4. The Doctor identifies which department belongs to. 5. the patient goes to the department accordingly. 6. the patient will treat . 7. End use case| Alternate Flow:| 2. 2 The doctor doesn’t login to the system 2. 3. 3 The doctor doesn’t have user login account.
... Add/Edit/Delete patients, Add/Edit/Delete Doctors, Add/Edit/Delete Beds, Search for patients, Assign patients to doctors. Doctor can access a patient’s record and ... be assigned to the patient. * A doctor will be assigned to each patient before the patient meets the doctor. Only one doctor can be assigned to ...
2. 3. The registration process terminates. | Post condition| Doctors are login to the system and they give appropriate services for registered patients. | Goal| Doctors are create their login account in order to make the system secure and then use that account to start their work. | Use Case Id:| UC-006| Use Case Name| Record| Use Case Description| In this business use cases receptionist will going store each patient data for the purpose of treating patients in a good manner. | Actors:| Receptionist| Preconditions:| Receptionists are login to the system and collect patient data finally store the record. Flow of Events:| 1. The receptionist should login first. 2. The receptionist checks if registered patients in the system. 3. The receptionist identifies what type of patients are registered. 4. The receptionist identifies which department belongs to. 5. thereceptionist record each patients’ data as well. 6. End use case| Alternate Flow:| 2. 3 The receptionist doesn’t login to the system 2. 4. 5 The receptionist doesn’t have user login account. 2. 4. 6 The system process terminates. | Post condition| receptionist are login to the system and they record appropriate patient data. Goal| receptionist should store the correct patient data. | Class diagram Figure [ 3 ]. Class Diagram Activity diagram Login Figure [ 4 ] Activity Diagram for Login Registration Figure [ 5 ]. Activity Diagram for registration. Record Data Figure [ 6 ] Activity diagram for insert data Payment Figure [ 7 ] Activity diagram for payment Check Examine Figure [ 8 ] Activity diagram for check examine Sequence diagram Figure [ 9 ] Sequence diagram for patient information management system Chapter Three: SYSTEM DESIGN Deployment Diagram System Architectural Design Data Sql server Presentation Tier
The Term Paper on Foreign Policy Analysis : Compare and Contrast Nigeria’s Relationship with the U.S.A.
... of a decision. Okere, (2000:115) NIGERIA’S FOREIGN POLICY OBJECTIVES Foreign policy objectives are built upon some general principles or ... friendship between the two nations and Nigeria emerged as a key partner of the U.S on the continent. (Msn ... conclusion, this work was introduced within the frame work of foreign policy analysis, a conceptual clarification of relevant theoretical framework ...
Database tier Business tier Data Structure Design Database Design Database design is used to manage large bodies of information. In this database we describe all the 4 tables available in the software, which are used to store all the records. 2. Entities with attributes,Data types and Relationship Patient Attributes| Data Type| Relationships| Patient first name| Varchar(50)| Not Null| Patient middle name| Varchar(50)| Not Null| Patient last name| Varchar(50)| Not Null| Pid| Int| Primary Key| Age| Int| Not Null| Date_of_birth| Date/time| Not Null| Sex| Varchar(5)| Not Null| Address| Varchar(5)| Not Null|
Disease| Varchar(5)| Not Null| Doc_id| Int| Foreign Key| Dep_cod| Int| Foreign Key| Date_of_registeration| Date/time| Not Null| Region| Nvarchar(50)| Not Null| Woreda_subcity| Nvarchar(50)| Not Null| Ketema_gott| Nvarchar(50)| Not Null| Kebela| Int| Not Null| House_no| Int| Not Null| Phone_no| Int| Not Null| Opd_code| Int| Foreign Key| Rec_id| Int| Foreign Key| Table [ 7 ]. Patient Doctor Attributes| Data Type| Relationships| Doctor First Name| Varchar(50)| Not Null| Doctor Middle Name| Int| Not Null| Doctor Last Name| Varchar(5)| Not Null| Doctor_Id| Int| Primary Key| Laboratory_No| Int| Foreign Key|
Specialization| Nvarchar(50)| Not Null| Phone_No| Int| Not Null| Address| Nvarchar(50)| Not Null| Department_Cod| Int| Foreign Key| Table [ 8 ]. Doctor table Lab report Attributes| Data Type| Relationships| Lab_No| Varchar(5)| Primary Key| Patient_Id| Int| Foreign Key| Doctor_Id| Varchar(5)| Foreign Key| Date| Date/Time| Not Null| Category| Varchar(15)| Not Null| Patient_Type| Varchar(15)| Not Null| Amount| Int| Not Null| Table [ 9 ]. Lab Report table Inpatient Attributes| Data Type| Relationships| Inpatient First Name| Varchar(50)| Not Null| Inpatient Middle Name| Varchar(50)| Not Null|
Inpatient Last Name| Varchar(50)| Not Null| Inpatien_Id| Int| Primary Key| Sex| Varchar(5)| Not Null| Room_No| Int| Not Null| Bed_No| Int| Foreign Key| Phone_No| Int| Not Null| Date Of Addmission| Date/Time| Not Null| Lab_No| Int| Foreign Key| Date Of Discharge| Date/Time| Not Null| Status| Varchar(50)| Not Null| Table [ 10 ] Inpatient Outpatient Attributes| Data Type| Relationships| Outpatient First Name| Varchar(50)| Not Null| Outpatient Middle Name| Varchar(50)| Not Null| Outpatient Last Name| Varchar(50)| Not Null| Outpatien_Id| Int| Primary Key| Age| int| Not Null|
... in Palestine, bring different perspectives to foreign policy.Foreign policy is also formed by organizations representing a group of governments ... the community. In similar fashion, business, through its foreign establishments, represents an important source of local income ... Today many nongovernmental organizations play an important role in foreign policy. Groups as diverse as Amnesty International, a ...
Gender| Varchar(5)| Not Null| Address| Nvarchar(50)| Not Null| Phone_No| Int| Not Null| Date Of Addmission| Date/Time| Not Null| Lab_No| Int| Foreign Key| Opration_Date| Date/Time| Not Null| Assigned_Doctor| Nvarchar(50)| Not Null| Status| Varchar(50)| Not Null| Table [ 11 ]. OutPatient Payment Attributes| Data Type| Relationship| Bill_No| Int| Primary Key| Medicine_Charge| Varchar(50)| Not Null| Patient_Type| Int| Not Null| Patient_Id| Int| Forign Key| No Of Date| Date/Time| Not Null| Health_Card| Nvarchar(50)| Not Null| Table [ 12 ]. Payment table Room Attributes| Data Type| Relationship|
Inpatient First Name| Int| Not Null| Inpatient Middle Name| Int| Foreign Key| Inpatient Last Name| Varchar(50)| Not Null| Room_No| Int| Foreign Key| Bed_No| Int| Primary Key| Inpatient_Id| Int| Foreign Key| Table [ 13 ]. Room Table Receptionist Attributes| Data Type| Relationships| Receptionist First Name| Varchar(50)| Not Null| Receptionist Middle Name| Varchar(50)| Not Null| Receptionist Last Name| Varchar(50)| Not Null| Receptionist_Id| Int| Primary Key| Patient_Id| Int| Foreign Key| Sex| Varchar(5)| Not Null| Age| Int| Not Null| Address| Varchar(50)| Not Null| Table [ 14 ]. Receptionist
Pharmacy Attributes| Data Type| Relationships| Medicine_Id| Int| Primary Key| Medicin_Name| Varchar(50)| Not Null| Medicin_Type| Varchar(50)| Not Null| Expire_Date| Date/Time| Not Null| Manfuctured_Date| Date/Time| Foreign Key| Price| Varchar(5)| Not Null| In_Id| Int| Foreign Key| Op_Id| Int| Foreign Key| Table [ 15 ]. Pharmacy Table Department Attributes| Data Type| Relationships| Department Name| Nvarchar(50)| Not Null| Department_Cod| Int| Primary Key| Opd_Cod| Int| Foreign Key| Laboratory_No| Int| Foreign Key| Table [ 16 ]. Department table OPD Attributes| Data Type| Relationships|
OPD_Cod| Nvarchar(50)| Primary Key| Patient_Id| Int| Foreign Key| Services| Nvarchar| Not Null| Diagnisis| Nvarchar(Max)| Not Null| Departmement_Cod| Int| Foreign Key| Laboratory_No| Int| Foreign Key| Cost| Int| Not Null| Table 17. OPD ER_Diagram Figure [ 10 ]. ER_diagram User Interface Design Login page Figure [ 11 ]. login page Home Page Figure [ 12 ]. Home page Patient type page Figure [ 13 ]. Patient page Patient registration page Figure [ 14 ]. Patients registration page Inpatient form Figure [ 15 ]. Inpatient form Outpatient form Figure [ 16 ]. Outpatient form Receptionist form
Figure [ 17 ]. Receptionist form Opd form Figure [ 18 ]. Opd form Department form Figure [ 19 ]. Department form Doctor form Figure [ 20 ]. Doctor form Room form Figure [ 21 ]. Room form Lab report form Figure [ 22 ]. Lab report form Pharmacy form Figure [ 23 ]. Pharmacy form Payment form Figure [ 24 ]. Payment form Conclusion Reference Bibliography Appendix Services and locations | ?????????????????? (Type of services provided by the hospital): Clinical services| Laboratory services| Diagnostic service| Other services| Remark| Emergency| Stool examination| X-ray | Pharmacy| |
Out patient| Bacteriology examination| Ultrasound| MCH| | Inpatient| U inalysis| Doppler ultrasound | Physiotherapy| | Gyn. & maternity| Hematology| Pathology| Cervical cancer screening| | Pediatric And child health care| C/chemistry| ECG| HIV/ART care| | Minor & major surgery& Orthopedics| Serology| | PMTCT| | Internal medicine| Blood film examination| | VCT service| | Dental health| Blood transfusion| | Hygiene and sanitation| | Dermatology| Immunology| | Health education| |
Ophthalmic care| Skin test and body fluid analysis| | Endoscopy service| | Psychiatry| Culture and drug sensitivity| | | | ICU| AFB| | | | | CD4 count| | | | | HUMAN RESOURCES PROFILES | Health Staff by Profession| M| F| T M&F| | Health Staff by Profession| M| F| T M&F| Internist| 0| 0| 0| | Lab. Tech. (Bsc)| 5| 4| 9| Surgeon| 0| 0| 0| | Lab. Technician(Dip)| 5| 5| 10| Obs. Gynecologist. | 1| 0| 1| | Lab.
Technician (Jun)| 0| 0| 0| Pediatrician| 0| 0| 0| | Lab. aid| 1| 2| 3| Ophthalmologist| 0| 0| 0| | Pharmacist (Bsc) | 7| 2| 9| Orthopedic | 0| 0| 0| | Pharmacy technician| 4| 11| 15| Pathologist| 1| 0| 1| | Pharmacy technician(Jun)| 0| 0| 0| Radiologist| 1| 0| 1| | Radio GrapherBsc| 2| 0| 2| Dermatologist| 0| 0| 0| | X-Ray technician (dip)| 4| 0| 4| Psychiatrist| 0| 0| 0| | Sanitarian (Bsc)| 1| 2| 3| Epidemiologist| 0| 0| 0| |
Sanitarian (Dip) | 0| 0| 0| Neurologist| 0| 0| 0| | Sanitarian (Jun)| 0| 0| 0| Dentist ( GP)| 2| 0| 2| | Malaria technician| 0| 0| 0| Physiotherapist (BSC)| 1| 2| 3| | Primary Health Worker| 0| 0| 0| General Practitioner| 8| 10| 18| | Primary Midwife| 0| 0| 0| Health Officer| 2| 3| 5| | Health Education (BSC)| 1| 0| 1| Bsc. Nurse| 4| 13| 17| | Cataract surgeon| 0| 1| 1| Clinical Nurse (Dip)| 36| 87| 123| | Ophthalmic Officer | 1| 3| 4| Midwife) Bsc)| 2| 7| 9| | Optometry| 1| 0| 1| Midwife (Dip)| 3| 8| 11| | Emergency surgery | 1| 0| 1| Health Assist. 1| 0| 1| | | | | | Health Assist. (Jun)| 0| 3| 3| | S. Total| 33| 30| 63| Psychiatric Nurse(BSC)| 0| 1| 1| | Total Technical staff| 100| 172| 270| Psychiatric Nurse(Dip)| 0| 3| 3| | Administration workers| 56| 131| 187| Ophthalmic Nurse (dip)| 0| 2| 2| | Temporary worker | 6| 17| 23| Ophthalmic. Assistant| 1| 0| 1| | | | | | Anesthetist Nurse (Bsc)| 4| 2| 6| | G. total | 156| 303| 459| Anesthetist. Nurse (Dip)| 1| 1| 2| | ????????? | 12| 14| 26| Dental Nurse(Bsc)| 2| 0| 2| | | | | | S. Total| 70| 142| 212| | | | |