Software specification for

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

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

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

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.

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.

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

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.

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

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

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.


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.


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.


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

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.

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

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.



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.


Alternative Flow Update User Detail: InvalidEmailPhone ID 12.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 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.

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

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.

Figure 4: Create New User

Above diagram illustrate step by step flow of creating a new system user. Illustration alternative flow where possible.

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.

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:

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

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 –

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

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

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

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

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.