SOFTWARE SPECIFICATION FOR BV OUTPATIENT MANAGEMENT SYSTEM

1. SOFTWARE SPECIFICATION FOR
BV OUTPATIENT MANAGEMENT SYSTEM
TEAM NAME: BV SYSTEMS COPORATION.
TEAM MEMBERS:
BILLY ZIMBA. (2820140030)
VALERI KOPALEISHVILI. (2820140018)
Attention: Wu Jiang.
Object Oriented Methodologies and Technologies.
COPYRIGHT 2014

2. Contents
1. Introduction...........................................................................................................................4
1.1 Purpose..........................................................................................................................................4
1.2 Scope.............................................................................................................................................4
1.3 Existing System.............................................................................................................................4
1.4 Objective of the System .................................................................................................................5
1.5 Overview.......................................................................................................................................5
2.0 Glossary ...............................................................................................................................6
3.0 Use case modeling................................................................................................................7
3.1 Use case Diagram ..........................................................................................................................7
3.2 Requirement Description ...............................................................................................................8
R1: Login ........................................................................................................................................8
R2: Update Personal Detail..............................................................................................................9
R3: Register Patient .........................................................................................................................9
R4: Update Patient Detail...............................................................................................................10
R5: Search Patient .........................................................................................................................11
R6: Manage Appointment..............................................................................................................11
R7: View Patient Bills ...................................................................................................................12
R8: Create Prescription..................................................................................................................12
R9: Update Prescription.................................................................................................................13
R10: Print Bill ............................................................................................................................... 13
R11: Create User ..........................................................................................................................13
R12: Update User Detail................................................................................................................14
R13. Prescribe test. ........................................................................................................................15
R14. View appointment. ................................................................................................................15
R15. Confirm prescription .............................................................................................................15
R16.Check medicine list ................................................................................................................15
R17 Create lab report.....................................................................................................................15
R18 View lab report.......................................................................................................................16
3.3 Activity Diagrams........................................................................................................................16
4.0 Supplementary Specification ............................................................................................20
4.1 User Characteristics .................................................................................................................20

3. 4.2 Non-Functional Requirement .......................................................................................................21
R19. Performance Requirements ....................................................................................................21
R20. Security .................................................................................................................................21
R21. Maintainability......................................................................................................................22
R22. Scalability ............................................................................................................................. 22
3.4 Software and hardware requirements............................................................................................22
5. Screenshot............................................................................................................................23
5.1 Home Page ..................................................................................................................................23
5.2 Create User..................................................................................................................................24
5.3 Search Patient .............................................................................................................................. 25
5.4 Managing Prescription .................................................................................................................25
5.5 Managing Patient Information......................................................................................................26
6.0 Potential for Further development ...................................................................................26
7.0 Challenges and Risks associated with the project............................................................26
8.0 References..........................................................................................................................27

4. 1. Introduction
1.1 Purpose
This document outlines the software requirements for the Outpatient Hospital Management
System for the XYZ Medicare Centre. It describes the functional and non-functional
requirements, modelling requirements, diagrams and user profiles of the proposed system. It
enables seamless sharing of the patient’s health record between hospital processes. Parties
interested in this documentation would include but not be limited to the system owners, the
system users, the project manager and the design team.
1.2 Scope
It can be used in any Hospital or Dispensary for maintaining patient details and their billing
information. The software is customized software as we are developing it for a client. The client
in question is XYZ Medicare Centre.
The Software covers the following as it core functions:-
 Maintaining Patient details.
 Providing Prescription.
 Billing and Report generation.
 Making Appointments
The software will be deployed on the hospital network therefore it will be web based and will
access and store all its information on the hospitals central database.
1.3 Existing System
Our Clients Hospital currently uses a manual system for the management and maintenance of
critical information. The current system requires numerous paper forms, with data stores spread
throughout the hospital management infrastructure. Often information (on forms) 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. Therefore it is time consuming and lack of security.
To avoid all these limitations and make the system working more accurately it needs to be
computerized.

5. 1.4 Objective of the System
A significant part of the operation of any hospital involves the acquisition, management and
timely retrieval of great volumes of information. This information typically involves; patient
personal information and medical history, staff information, staff scheduling and various
facilities waiting lists. All of this information must be managed in an efficient and cost wise
fashion so that an institution's resources may be effectively utilized HMS will automate the
management of the outpatient section of the hospital making it more efficient and error free. It
aims at standardizing data, consolidating data ensuring data integrity and reducing
inconsistencies.
Hospital Outpatient Software system enables you to improve your work effectiveness and
quality. Managing the key processes efficiently is critical to the success of the hospital helps you
manage your processes.
Outpatient Hospital Management System includes registration of patients, storing their details
into the system and also computerized billing. Our software has the facility to give a unique id
for every patient and stores the details of every patient and the staff automatically. User can
search availability of a doctor and the details of a patient using the id. The Outpatient Hospital
Management System can be entered using a username and password. It is accessible either by a
doctor or receptionist. Only they can add data into the database. The data can be retrieved easily.
The interface is very user-friendly. The data are well protected for personal use and makes the
data processing very fast.
In summary the system enables hospitals and doctors to better serve their patients
 Improved quality of patient care
 Increased nursing productivity
 Reducing the time spent
 Better quality of care, procedures and service to Patients
 Control over the costs incurred by diagnosis-related groups
1.5 Overview
This specification includes a brief product perspective and a summary of the functions the
software will provide. User characteristics are discussed and any general constraints or
assumptions and dependencies are listed.
Requirement statements are categorized as functional requirements, non-functional requirements,
or design constraints. Functional requirements are describer=d through Use Case modeling and
Activity Diagrams. Non-functional requirements are categorized in terms of security,
maintainability, and scalability.

6. 2.0 Glossary
HMS  Outpatient Hospital Management System
GUI  Graphical User Interface
Pid  Patient Hospital Identification Number
Use case  Functionality provided by the System to meet business purpose
Post Condition  These are things that must be true before a use case can execute.
Pre Condition  These are things that must be true at the end of a use case.
Main Flow  The steps in the use case.
Actors  System user/other system participating in use case/business process.
Alternative Flow  List of alternatives path to main flow.
Outpatient  Getting some type medical procedure done without getting admitted to
the hospital.
Prescription  An order that a pharmacist dispense and that a patient take certain
medications
Appointment  An agreement to meet with available Doctor at a particular date and time
Activity Diagram  Show the steps of actions and conditions of interaction in a business
process.
Diagnosis  A statement or conclusion that describes the reason for a disease
Lab  Laboratory.
Search Criteria  This is range of possible search terms relating to the domain.
Relationships  Meaningful relationships between actors and use cases
Patient  Client to the hospital
Participants  Admin, Doctor, nurse, lab technician, pharmacist, user
System  The software is referred to as system or application

7. 3.0 Use case modeling
The HMS is designed to help the hospital administrator to handle patient, nurse, pharmacist,
doctors and billing information. It enables seamless sharing of the patient’s health record with
the Clients network of hospitals. The current design goal is to build an internal system to achieve
the functionality outlined in this specification. The HMS will allow the user to manage
information about patients, nurses, pharmacist, doctors and billing. The HMS will also support
the automatic backup and protection of data.
3.1 Use case Diagram
Figure 1: Use Case Diagram show business process.

8. 3.2 Requirement Description
R1: Login
Use case name Login
Use case ID 1
Brief Description The System allow user access
Actors All users
Preconditions Application URL is accessed and system interface is loaded.
Main Flows 1. The use case starts when the user enters the application
URL in the browser and the application is loaded in the
browser.
2. The system provides the user with input dialog box
containing username field, password field, submit and
cancel button.
3. The user is expected to enter the username and password.
4. If the user presses the submit button.
4.1 While the user details are invalid
4.1.1 The system asks the user to enter their
details comprising username and
password again.
4.1.2 The system validates the user details.
5. The system allows user access.
Post condition The Application is open and display user functions.
Alternative Flows InvalidPasswordorUsername
Alternative Flow Login: InvalidPasswordorUsername
ID 1.1
Brief Description The system informs the user that username or password is
invalid.
Actors All users
Preconditions User has entered invalid username or password
Alternative Flows 1. The alternative flow begins after step after 4.1.2
2. The system informs the user that his or her username or
password entered is invalid.
Post condition None

9. R2: Update Personal Detail
Use case name Update Personal Detail
Use case ID 2
Brief Description The System Update user details
Actors Nurse and Admin
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User select edit on profile menu.
2. The system provides the user with form populated with current
personal details.
3. If user is Nurse or Doctor
3.1 The system does not display the user role for editing.
4. Else
4.1 The system does display user role for editing.
5. User overwrites data of their choice based on the displayed
information.
6. While the user updated details are invalid.
6.1 The system asks the user to enter their email address/phone number
6.2 The system validates the email address/phone number.
7. The system updates user information.
Post condition Information is updated, System populates the form with Updated information
Alternative InvalidEmailPhone
Alternative Flow Update Personal Detail: InvalidEmailPhone
ID 2.1
Brief Description The system informs the user that email address or phone number
is invalid.
Actors Nurse, Doctor and Admin
Preconditions User has entered invalid email address or phone number
Alternative Flows 1. The alternative flow begins after step after 6.2
2. The system informs the user that his or her email address
or phone number entered is invalid.
3. The system resets form information to initial state
Post condition None
R3: Register Patient
Use case name Register Patient
Use case ID 3
Brief Description The system registers new patient
Actors Nurse and Admin
Preconditions User is logged into the System

10. Main Flows 1. The use case starts when the User select register on the Main system
menu.
2. The system provides the user with a form consisting of all required
fields.
3. While Patient details are invalid.
3.1 System asks the user to enter details email address/phone number
3.2 The system validates the email address/phone number.
4. System adds new patient.
Post condition Information is updated, System populates the form with Updated information
Alternative InvalidEmailPhone
Alternative Flow Register Patient: InvalidEmailPhone
ID 3.1
Brief Description The system informs the user that email address or phone number
is invalid.
Actors Nurse, Doctor and Admin
Preconditions User has entered invalid email address or phone number
Alternative Flows 1. The alternative flow begins after step after 6.2
2. The system informs the user that his or her email
address/phone number entered is invalid.
Post condition None
R4: Update Patient Detail
Use case name Update Patient Detail
Use case ID 4
Brief Description The System Update user details
Actors Nurse, Doctor and Admin
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User select edit on profile menu.
2. The system provides the user with form populated with current
personal details.
3. If user is Nurse or Doctor
3.1 The system does not display the user role for editing.
4. Else
4.1 The system does display user role for editing.
5. User overwrites data of their choice based on the displayed
information.
6. While the user updated details are invalid.
6.1 The system asks the user to enter their email Address/phone
number
6.2 The system validates the email address/phone number.

11. 7. The system updates user information.
Post condition Information is updated, System populates the form with Updated information
Alternative InvalidEmailPhone
Alternative Flow Update Patient Detail: InvalidEmailPhone
ID 4.1
Brief Description The system informs the user that email address or phone number is invalid.
Actors Nurse, Doctor and Admin
Preconditions User has entered invalid email address or phone number
Alternative Flows 1. The alternative flow begins after step after 6.2
2. The system informs the user that his or her email Address or phone
number entered is invalid.
3. System resets form information to initial state.
Post condition None
R5: Search Patient
Use case name Search Patient
Use case ID 5
Brief Description The System finds patient details based on the search criteria and displays.
Actors All users
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User selects Search Record.
2. The system ask the user for search criteria
3. The user enters the requested criteria
4. The System searches for patient that matches the search criteria.
5. If System finds a match then
5.1 The system displays Patient information
6. Else
6.1 The system tells the user there is no matching patient data.
Post condition None
Alternative None
R6: Manage Appointment
Use case name Manage Appointment
Use case ID 6
Brief Description The User create, deletes or update an appointment for a client
Actors Nurse, Doctor and Admin
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User selects Appointment

12. 2. The system ask to choose Create, Delete or Update Appointment
Details for a Client/Patient
3. If the User Selects Create Appointment
3.1 The system provides a form to select available Doctor and date.
4. If the User Selects Delete/Update Appointment.
4.1 The system displays a waiting List
4.2 If the user select an appointment
4.2.1 The System displays appointment information
4.2.2 The user can delete or update the time to next available
time.
5. System updates the waiting list.
Post condition Waiting List is Altered.
Alternative None
R7: View Patient Bills
Use case name View Patient Bills.
Use case ID 7
Brief Description The System displays the bill to the user
Actors Nurse, Doctor and Admin
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User selects Bill.
2. The system display a list of recent Bill payments order in descending
date time
3. The system asks the user to enter the patient identity number.
4 If System finds a match then
4.1 The system displays all Patient Bills.
4.2 The User selects Bill
4.3 The system displays Bill information.
5 Else
5.1 The system tells the user there is no matching patient data.
Post condition The system has display the Patient Bills
Alternative None
R8: Create Prescription
Use case name Create Prescription
Use case ID 8
Brief Description The user create a prescription
Actors Doctor and Admin
Preconditions User is logged into the System and Patient Information has been retrieved
Main Flows 1. The use case starts when the User selects create prescription
2. The system asks the user enter medicine name.

13. 3. While the User Selects medicine name.
3.1 The system display medicine and available doses.
3.2 The user selects dose.
4. The system adds new prescription
Post condition New Prescription for Patient has been Added
Alternative None
R9: Update Prescription
Use case name Update Prescription
Use case ID 9
Brief Description The user update existing patient prescription
Actors Doctor and Admin
Preconditions User is logged into the System and patient prescription has been retrieved.
Main Flows 1. The use case starts when the User selects update prescription
2. The system converts retrieved patient prescription into a form.
3. The user changes or adds new medicine name.
4. While the User Selects medicine name.
4.1 The system display medicine and available doses.
4.2 The user selects dose.
5. The system update selected prescription
Post condition Initial Prescription for Patient is updated.
Alternative None
R10: Print Bill
Use case name Print Bill
Use case ID 10
Brief Description The User print bill payment
Actors Nurse and Admin
Preconditions User is logged into the System and Bill has been created
Main Flows 1. The use case starts when the User selects a patient bill.
2. The system displays a patient bill.
3. The user preview bill information
.
4. The system prints the bill payment
Post condition Bill is printed.
Alternative None
R11: Create User
Use case name Create User
Use case ID 11
Brief Description The system creates a new user.
Actors Admin
Preconditions User is logged into the System

14. Main Flows 1. The use case starts when the User select create user.
2. The system provides the user with a form consisting of all required
fields.
3. While User details are invalid.
3.1 System asks the user to enter details email address/phone number
3.2 The system validates the email address/phone number.
4. System adds new user.
Post condition System creates a new User.
Alternative InvalidEmailPhone
Alternative Flow Create User: InvalidEmailPhone
ID 11.1
Brief Description The system informs the user that email address or phone number
is invalid.
Actors Admin
Preconditions User has entered invalid email address or phone number
Alternative Flows 1. The alternative flow begins after step after 6.2
2. The system informs the user that his or her email
address/phone number entered is invalid.
Post condition None
R12: Update User Detail
Use case name Update User Detail
Use case ID 12
Brief Description The System Update user details
Actors Admin
Preconditions User is logged into the System
Main Flows 1. The use case starts when the User select edit on profile menu.
2. The system provides the user with form populated with current
personal details.
3. User overwrites data of their choice based on the displayed
information.
4. While the user updated details are invalid.
4.1 The system asks the user to enter their email address/phone number
4.2 The system validates the email address/phone number.
5. The system updates user information.
Post condition Information is updated, System populates the form with Updated information
Alternative InvalidEmailPhone
Alternative Flow Update User Detail: InvalidEmailPhone
ID 12.1

15. Brief Description The system informs the user that email address or phone number is
invalid.
Actors Nurse, Doctor and Admin
Preconditions User has entered invalid email address or phone number
Alternative Flows 1. The alternative flow begins after step after 4.2
2. The system informs the user that his or her email Address
or phone number entered is invalid.
3. The system resets form information to initial state
Post condition None
R13. Prescribe test.
The system shall allow doctor to assign patient a lab test if need arise. This involves setting an
appointment with the lab for taking samples to help doctor with diagnosis. This will enable
doctor come to a firm a diagnosis with the help of findings from the lab test. The Administrator
and Doctor are the only user types to have access to this functionality.
R14. View appointment.
The system shall allow doctor to view appointment created by the nurse/reception for each
patient. The system keeps an appointment list ordered by date from which the doctor view his
patients. This allows an organized and efficient way of attending to clients. The Administrator
Nurse and Doctor are the only user types to have access to this functionality.
R15. Confirm prescription
The system shall allow the pharmacist to check prescription and gives client medication as
specified on the doctor’s prescription. On checking and allocating the medication the pharmacist
confirms the prescription which also determines the total bill based on the medication given. The
Administrator and Nurse are the only user types to have access to this functionality.
R16.Check medicine list
The system shall allow the user to check the list of medicines .This allows the pharmacist to
determine the medication level in the hospital. In order to place more orders and know whether
the quantity is available prior to giving patient medication as per prescription. The Administrator
and Pharmacist are the only user types to have access to this functionality.
R17 Create lab report
The system allows the user to create a lab report based on doctor prescription. When the Doctor
prescribes a lab test for a patient the Lab technician will be able to view this prescription and
create a lab report based on the findings from the samples collected from the patient. The
Administrator and Lab Technician are the only user types to have access to this functionality.

16. R18 View lab report
The system shall allow the user to view lab report .This allow the user to view test results from
the lab. It is upon viewing the lab results that the doctor will be able to make a sound diagnosis
or the lab technician will be able to check reports added in case of any changes. The
Administrator, Doctor and Lab Technician are the only user types to have access to this
functionality.
3.3 Activity Diagrams
Figure 2: Activity Flow of HMS

17. The above activity diagram describes the overview of the interaction between the system user
and patient. Illustrating how the system will generally organize work and automate outpatient
process.
Figure 3 : Search Patient
Above diagram illustrates the Search Patient use case showing interaction and process flow
between user and the system. All system users are able to use this business process. Illustration
alternative flow where possible.

18. Figure 4: Create New User
Above diagram illustrate step by step flow of creating a new system user. Illustration alternative
flow where possible.

19. Figure 5: Update Patient Details
The above diagram shows step by step activities between the system user and system involved in
updated patient details. Illustration alternative flow where possible. The system user can be a
nurse or system administrator.

20. Figure 6: Create Prescription
Above diagram illustrates the Create Prescription use case showing interaction and process flow
between user and the system. Illustration shows multiple selections by means of a loops and
alternative flow where possible. System user can be doctor or administrator.
4.0 Supplementary Specification
4.1 User Characteristics
There are three different types of users for the HMS system:
1. Admin:
The System Administrator will have full access to the system. This will be
someone from the IT support department who understand IT technology and
operations.
2. Doctor:

21. Handle data entry for patient information, prescription and diagnosis in the HMS
system. User should have basic computer knowledge. Otherwise they will have to be
provided with data entry training and familiarized with basic computer operations.
3. Nurse/Receptionist :
Handle data entry for patient’s information and appointments. User should have
basic computer knowledge and data entry knowledge. Otherwise they will have to be
provided with data entry training and familiarized with basic computer operations.
4. Lab technician:
Handle laboratory task using system therefore the user should have basic computer
knowledge and data entry knowledge. Otherwise they will have to be provided with
data entry training and familiarized with basic computer operations.
4.2 Non-Functional Requirement
Based on the previous sections categorizations, in order to meet user's needs the following
precautions should be taken:
 the interface should be easy to understand
 data entry masks should recognize and correct improperly entered data
 for deleting or revising a record the system should ask the users for confirmation
 report generation should occur in a timely fashion
 diverse computer education levels should be considered
 online help is important
 error messages should be used
 system design should follow the manual process as closely as possible
 users should be consulted throughout design
R19. Performance Requirements
The HMS shall respond to user's retrieving information quickly. The waiting time for any
retrieve operation must be under 3 seconds.
R20. Security
The security requirements are concerned with security and privacy issues. All patient medical
information is required by law to be kept private.
R20.1 The HMS shall support different user access privileges. Each user will have privileges
strictly on what roles they play in the hospital.
R20.2 The HMS shall protect patient illness history information. Every system action and access
to patient information will be log if access logs of the system

22. R21. Maintainability
The maintainability requirements are concerned with the maintenance issues of the system. The
system shall provide sufficient documentation for reduced downtime.
R22. Scalability
The scalability requirements are concerned with the scalable issues of the system.
R 22.1 The HMS shall be able to scale up to support more workstations. System performance
shall not degrade if up to twenty percent (20%) more workstations are added.
3.4 Software and hardware requirements
Operating
Systems
 Solaris 2.9, 10, or later (SPARC/x86)
 Modern Linux operating systems (Ubuntu 8, SuSE 10, 11, OpenSuSE
11, Red Hat Enterprise Linux 4, 5)
 Microsoft Windows 2003 Server, XP Professional, 2007, 2008 R2,
Vista 32–bit
Java Platform  Java Runtime Environment 1.6.0_7 or later (1.5 or later on Mac OS X)
 Java JDK 1.6.0_7 or later (1.5 or later on Mac OS X)
Web
Container
 Sun GlassFish Enterprise Server v2.1
Note –
Other versions of Sun GlassFish will work with Web Space Server, such
as GlassFish v3 Prelude, but are recommended for evaluation or testing
purposes only, rather than a production environment.
 Oracle WebLogic Server 10g Enterprise Edition
Database  HSQL
 MySQL
 Microsoft SQL
 Oracle 10g, 11g
Apache Ant  Apache Ant 1.7 or later
Note –

23. The version of Ant bundled with Sun GlassFish v2 or later does not work with
Web Space Server 10.0. Make sure that Ant 1.7 or later is installed on your
system, and that your ANT_HOME environment variable points to this newer
version.
System
Memory
(RAM)
 Solaris, Linux: 1 GB minimum, at least 2 GB recommended
 Windows: 2 GB minimum, at least 3 GB recommended
 MacOS X: 1 GB minimum, at least 2 GB recommended
Table 1: software and hardware requirements subject to change
5. Screenshot
5.1 Home Page
Figure 7: Home Page
The Home page gives you access to all functionalities. The horizontal menu is the main menu.
It’s give access to all the system function.
Out Patient menu contains menu item as follows
 Patient: Responsible for creating, adding, viewing and updating patient information.
 Appointment: Responsible for managing appointments i.e. create, update, view, delete,
update, etcetera

24.  Prescription: Responsible for managing prescription data i.e. create, add, view, update,
delete, etcetera.
 Search Patient: Quick search tool.
 Users: Responsible for managing user information i.e. create, add, view, update, delete,
etcetera.
 Change Password: Quick tool for updating password.
 Exit: enable closing of the system.
Report menu contains menu items for outpatient reports. Tools menu contains menu items such
as notepad, calculator etcetera. About Developer provides contact details and extra information
about development.
5.2 Create User
Figure 8 : Create user
Figure 8 shows a form for creating users a user details are captured by passing required fields.
The system assigns the user a default password

25. 5.3 Search Patient
Figure 9: Searching for patient
Search Patient use case will be realized through the above diagram. The above diagram shows
input field which retains hints on the fly according to matching names in the system based on
search term.
5.4 Managing Prescription
Figure 10: Create, Update and Delete Prescription

26. The above diagram show prescription information and related functions are listed at the bottom
of the form in order to present prescription manageability.
5.5 Managing Patient Information
Figure 11: Form for managing patient data
Patient information will be managed using the above form. I provide access to patient
information and similar patient functionality such as update, delete and create.
6.0 Potential for Further development
As software is used, the customer/user will recognize additional functions that will provide
benefit. Perceptive maintenance extends the software beyond its original function requirements.
The System has adequate scope for modification in future if it is necessary
7.0 Challenges and Risks associated with the project
 Requirements Inflation - As the project progresses more and more features that were not
identified at the beginning of the project emerge that threaten estimates and timelines.
 Organizational instability - Unstable organizational environment
 Adapt employees this new product- Users adapt to use of system even after committed to
project due to existence of legacy procedures already in place.
 Wrong time estimation

27. 8.0 References
 Hsu EB, Jenckes MW, Catlett CL, Robinson KA, FeuersteinCJ, Cosgrove SE, Green G,
Guedelhoefer OC, Bass EB.Training of Hospital Staff to Respond to a Mass
CasualtyIncident. Summary, Evidence Report/Technology AssessmentNo. 95. (Prepared
by The Johns Hopkins University Evidence-based Practice Center.) AHRQ Publication
No. 04-E015-1.Rockville, MD: Agency for Healthcare Research and Quality.April 2004.
 Carman, J.M., Shortell, S.M., Foster, R.W., Hughes, E.F., Boerstler, H., O’Brien, J.L. et
al. Keys for successful implementation of total quality management in hospitals. Health
Care Management Review. 1996 Winter; 21: 48–60
 Bourne, M., Neely, A., Platts, D., and Mills, J. The success and failure of performance
measurement initiatives, perception of participating manager. The International Journal
of Operation & Production Management. 2002; 22: 1288–1310
 Catlett C, Perl T, Jenckes MW, et al. Training of Clinicians for PublicHealth Events
Relevant to Bioterrorism Preparedness. EvidenceReport/Technology Assessment No. 51.
Rockville, MD: Agency forHealth Care Policy and Research. 2002 Jan. AHRQ
Publication No.02-E011
 Levy K, Aghababian RV, Hirsch EF, et al. An Internet-based exerciseas a component of
an overall training program addressing medicalaspects of radiation emergency
management. Prehospital Disaster Med 2000; 15(2): 18-25
 Wikipedia (Hospital information system), from
http://www.wikipedia.org:http://en.wikipedia.org/wiki/Hospital_information_system
 Policy and Procedure Management Systems for Hospitals (2012)". PolicyStat LLC. 2012-
07-18.Retrieved 2012-07-18. For more information : http://www.policystat.com/hospital-
policy-management/
 https://www.google.com/?gws_rd=ssl#q=software+for+hospitals
 http://www.projectsmart.co.uk/top-five-software-project-risks.php
 Kotonya, G. and Sommerville, I. (1998). Requirements Engineering: Processes and
Techniques. Chichester, UK: John Wiley and Sons.