Running Head: SOSTWARE REQUIREMENTS SPECIFICATION DOCUMENT FOR
HOSPITAL INFORMATION SYSTEM
PROJECT NAME: SOFTWARE REQUIREMENTS SPECIFICATION FOR HOSPITAL
INFORMATION SYSTEM
STUDENT NAME:
COURSE NUMBER:
COURSE NAME: SOFTWARE REQUIREMENTS ENGINEERING
PROFESSOR:
SCHOOL:
DATE: Dec 9 th
, 2013
2
Executive Summary
This SRS document for the Hospital Information System describes the tasks, functions and goals of the system’s performance. The development team will refer to this document to describe the design plan and the project scope as well as the final implementation of the new proposed HIS. The document also serves as the contract basis between the system team developing team and the hospital. The following high-level system requirements have been listed for this document. The system will satisfy the following;
Management of Wards by coordinating and planning management of rooms
Scheduling work by assigning doctors to different patients and nurses to doctors
Managing surgery by organizing and planning work done in the operating rooms by nurses and surgeons
Waiting list monitoring and management to ensure waiting patients are attended toby assigning them beds and doctors
Patient care by thoroughly monitoring patients visiting the hospital
Admissions which is done by assigning patients rooms or appropriate wards after admission
This SRS document also has classified the requirements into non-functional and functional requirements. Functional requirements are directly related to the proposed HIS software while the non-functional requirements improve the computer system’s functioning which does not cover the entire HIS.
3
Abstract
The hospital currently has a paper system and requires a system used to store hospital records in a database and maintaining the HIS. This proposed software will be used to manage all operations of the hospital which includes; patient address, names of patients, information on doctors and other staff information. It will also store calculated billing information.
4
Table of Contents
5
6
Appendix A ......................................................................... Ошибка! Закладка не определена.
7
Revision History
Name
HIS Proposal
HIS SRS
HIS SRS
HIS SRS
HIS SRS
HIS SRS
Date Reason For Changes Version
11/21/13 User Requirements
11/24/13 Initial HIS overview
Draft
Draft (V 1.0)
12/2/13 Requirements Elicitation Rough Draft 1(V 2.0)
12/09/13 Requirements Analysis and Specification Rough Draft 2 (V 3.0)
12/xx/13 Requirements and Quality In progress
12/xx/13 Requirements Verification and Validation In progress
8
Project Outline
Introduction
The SRS for the proposed HIS is prepared after the successful culmination of the requirement’s analysis. This document follows the IEEE Recommended Practice for Software
Requirements Specifications (IEEE Std 830-1998). Performance and functions allocated to the software as elements of the SE process are refined to establish complete detailed description of functions, description of information, system behavior representation, performance requirements indication and constraint identified at the design phase among other information associated to requirements. This is a technical requirements specification of the HIS and it describes the functionality of the proposed system without necessarily describing how the operations are done.
Purpose
The chief reason of this proposed system is to develop a HIS software that will replace the current paper system and make hospital operational tasks easier. The automated HIS SRS will guide the developing team of the proposed system. The HIS purpose can be broken down into the following key point;
Maintaining details for patients
Automation of hospital operations and management
Report generation and billing
Maintaining two user levels; User level and Administrator level
Providing Precautions, Diet Advice and Prescriptions
9
Maintaining and providing patient tests
Payroll system management
Scope
This document contains both requirement specification statements for non-functional and functional requirements
The HIS will capture patient information and save it for future reference
Reducing pay for overtime and provide service accuracy
The paper based system currently in use does not have mechanisms for quick data retrieval and it is too slow.
Document Overview
This SRS document will exhaustively illustrate and define the overall proposed HIS project requirements which include non-functional and functional requirements. Following standard Software Requirements Specification practices the document describes functions of the product, constraints, specific project requirements and the analysis of the specified requirements.
The analysis in this case will include use case diagrams because the final document is primarily a developer’s tool that defines the design and modeling structure of the HIS. Additionally the SRS document defines the characteristics of different users and any related identified project development constraints.
This SRS addresses the overall objective and goals of the proposed system. It will first illustrate the functions of the system as well as the interfaces. The sections following the introductory summary of the system’s functionality will systematically address the larger system
10 software and its components. The phases describe specifications identified for every system module in all aspects of the design of the system’s components.
Overall Descriptions
Perspective of Product
The proposed HIS is a self-contained management system that will be used to organize and manage patient information among other hospital activities. This HIS will also provide procedural patient treatment approach as well as details on room allocation, dates of treatment and billing.
System Modules
The system consists of the following modules that will be integrated for the installation and implementation of the final HIS. They include;
Module for Management of Inpatients
Module for Reception Management
Payments Module
Store Module
Module for Managing Registration of Patients
Pharmacy Module
Module for Financial Accounting
Module to Manage User Accounts
Radiology Module
Module for Outpatient Management
Module for Channeling Services
Payroll Module
11
Maintenance Module
Dental Module
Module for Reports Generation
Implementation and Design Constraints
Operating System
The environment for development will be windows 7 professional
Database
The open source and free MS SQL database will be used
Web-based the HIS will be a web based software application
The GUI will be in English only
Dependencies and Assumptions
The assumptions are that the hospital will have enough trained staff members to operate and maintain the new system.
It is also assumed that by the end of the project’s development there will be 70 installed and tested computers.
User Characteristics
The total appearance for this proposed software product should be user friendly with each system user being issued a password and username for access.
12
Requirements Elicitation
Elicitation of requirements is done through the feasibility study process. The data elicitation tools and techniques were designed to sufficiently provide information used to make decisions on the validity of the HIS project. The results of the information gathering determine whether or not a project should go on with consideration to other existing systems of management. The collection of requirement specifications from the hospital HIS users was an important aspect of the study carried out. The overall procedure used to undertake this task is as follows;
Identification of information sources for different user levels
Identification of user expectations from the new proposed computerized HIS
Analysis of limitations in the current system
System Stakeholders
The requirements elicitation took three approaches to collect information from the immediate main stakeholders. The identified stakeholders who were actively and directly involved for this project include had the following characteristics;
Hospital Staff
The Receptionist – handles doctors’ schedules and consultations as well as patient registration enquiries. They are also mandated with managing allocations of time slots and enquiries on doctor consultation fees. Some of the tasks involved at this user module include; o Scheduling appointments for doctors
13 o Finding patient historical information as requested o Scheduling visits to various doctors for patients o Answering other patient or visitor enquiries
The Doctors – they update and have access to every patient’s prescriptions, lab test results/ reports and general scheduled routine checkup information.
The Lab Attendants – the main responsibility is updating lab result reports for different patients.
Administrators – administrators in the system will have the rights to create new users as well as inspecting the general system performance in their various capacities. The HR management administrators are in charge of the payroll system and generating pay slips.
Inventory Manager – the chief responsibility of the inventory manager is updating medical store information and keeping record of remaining stocks.
Project Development Team
Project Leader – Managing overall project development process and assigning tasks to other team members.
Team Member – Carrying out different project tasks as assigned by the project leader including requirements elicitation.
Quality Assurance Manager – ensuring the proposed system is up to quality standards expected and requested by the client.
14
Techniques and Tools used
Observation – a group from the project development team was sent to the hospital to observe the daily operational tasks in each level of employment at the hospital. From observation we could not get detailed requirements from the expected system users.
However, it was important to have an idea of information flow and how information is channeled between departments (Leffingwell & Widrig, 2003).
Questionnaires – using this data collection tool gave us more insight on the user expectations and detailed requirements from different user levels (Leffingwell & Widrig,
2003). This is where all technical and functional requirements were gathered. Specific question leading to specific requirement specification by different users gave an abstraction of user expectations.
Interviews – one on one interviews with randomly selected departmental representatives also helped the development get more detailed information on what the client really required for the proposed HIS system. This gave the analysis and data collection teams formulate a complete requirements document (Leffingwell & Widrig, 2003).
Summary experience of elicitation
The process of eliciting requirements is essential for the success of the project. It is very crucial that stakeholders of the business participate in the requirement elicitation actively. The procedure was carried out with the help of questionnaires, interviews, observations as well as informal discussions with the entities involved. These entities are hospital medical and nonmedical staff that includes doctors, administrators, patients and lab attendants. Some of the
15 problems experienced by the project team throughout the requirements elicitation process included;
Not having access to all required staff members when required. It is important that active stakeholders should be accessible and cooperate with the team clarify their actual expectations from the project.
It was a difficult task to plan the face to face interviews with nurses and doctors who have extremely demanding schedules. The interviews were therefore shorter than expected and provided a sketchy overview of the overall HIS requirements for both groups. However some of the hospital staff members like stores, pharmacy and maintenance managers were available to give insightful information on their expectations in their modules.
The observation exercise took longer than planned because the team members had difficulty in following the precise movement of staff members and information through the daily routines. Sometimes because of the high human traffic, it was also very difficult to stay focused on the agenda.
The use of questionnaires eventually gave better results in gathering the expected user requirements from all staff members. Each hospital employee in their different capacities were allowed to carry home their questionnaires and given a time limit of 2 days to return the completed form. Even though some of the forms never made it back enough of them did and they provided a good overview of the
HIS requirements.
16
Requirements Analysis and Specifications
Use Case Analysis
Use Case Analysis is used to identify a project’s main user requirements when the system is observed as a whole. It is basically a high –level depiction of the proposed system’s functionality. A Use Case may require different sequential steps that individually lead to an action. Use Cases show the main roles played by key users of the system as well as identifying ways the system will be used for example the receptionists scheduling an appointment. The behavioral characteristics of the HIS are described in a convenient way that documents the supported system functions. The use case models for the different project’s stakeholders are as explained below. Identified stakeholders include administrators of the database as well as the overall system, doctors, inventory/ store attendants, lab technicians and receptionists.
Specific Requirement Analysis Recommendations
The system should allow the receptionist to add and update both in and out patient details as required.
Doctors accessing the system should clearly view their patients’ medical reports and history with ease. It should equally be simple to add prescriptions and recommendations.
The medical store attendants will be facilitated with a mechanism to reorder new stock and update details about suppliers. They will also keep track of overall medicine usage.
The HIS should run seamlessly on a windows environment.
17
The HR department is also provided with a module to calculate and generate pay checks for all hospital employees.
Lab technicians will also be able to update and manage lab test results for all patients with different test recommendations.
Administrators are given the overall responsibility of ensuring smooth transition and maintenance of the new system after installation.
The system to operate at an optimum level will require the sufficient and effective management of passwords, protection from viruses and archiving.
The analysis phase provided the project team with a clear picture of the final product’s functional requirements as specified by the hospital staff during the elicitation of requirements.
The questionnaires provided the most relevant and detailed information used for the final analysis. Observation and Interviews only provided an insightful overview but not enough data for a comprehensive use case analysis. The analysis process underwent a few setbacks like time constraints due to the questionnaires’ sorting and categorizing exercise that preceded the thorough analysis.
Analyzing the data from the questionnaires required this exercise to have a clear understanding of the requirements needed for each user group module to be integrated into the final HIS. It was however difficult to translate some of the user requirement into system functional procedures. Therefore most of the specified requirements were summarized or combined into simple tasks. Some of the functionalities in the system will be added and refined as the project progresses. Overall the process was a success and an example of some of the use cases developed is discussed below.
18
Functional Requirements Specifications
The Functional Requirements for Doctors
SRS001 Viewing results from labs
– doctors use this activity to analyses and view patient test results from different departments.
SRS002 Medicine Prescription – the patient records will be appropriately updated when doctors prescribe medicine to them. The updated records are stored in the central repository database.
SRS003 Patient checkup data updating – this lets the doctor make any necessary updates to patient records that carry information about their routine checkup history.
Fig. 1 Doctor’s Use Case Diagram
19
The Functional Requirements for Receptionists
SRS004 Scheduling patient visits – the receptionists will also be updating information regarding schedules for visiting and full time doctors.
SRS005 Scheduling appointments for doctors – all doctors’ appointments with their patients will be recorded and kept by the receptionists.
SRS006 Finding enquired patient history – this activity in the system will allow the receptionist to easily find information about different patients’ histories when enquiries are made.
SRS007 Patient information enquiries – various patient registration enquiries are the responsibility of the reception desk.
Fig. 2 Use Case Diagram for the Reception Desk
20
The Functional Requirements for Lab Attendants
SRS008 Test report updates – the generation of reports will be facilitated by manual entry of updated lab results. All generated reports will include precautions and remarks by the different respective doctors and related to the particular tests done.
Fig. 3 Lab Technician Use Case Diagram
The Functional Requirements for Administrators of the HIS
SRS009 Assigning user rights – the HIS administrators will be responsible for creating user accounts and grant each of the system users’ access permission accordingly.
SRS010 Performance inspection – the overall inspection of the system is the sole responsibility of the identified system administrators.
Fig. 4 System Admin Use Case Diagram
21
The Functional Requirements for inventory/ stores manager
SRS011 Maintaining stock of medicine – the manager or attendant of the inventory module will keep records about medical usage and acquisition. The acquisition process is divided into donations and purchases as well as maintaining reorder levels. The records will be updated when new medicine orders are received or when patients buy prescriptions or have the prescribed medicine delivered to their premises.
Fig. 5 Use Case Diagram for Store Attendant
The Functional Requirements for Payroll Module
SRS012 Managing Employees’ Pay checks – this involves determining the correct amount due to each employee every month. The system automatically calculates the net salary with all necessary subtractions and taxations. The administrators or HR clerks in using this module monitor the working hours recorded for each employee for the entire month on a daily basis. Salaries are calculated from the worked hours logged into the system.
SRS013 Generating Pay slips
– the pay slips for each employee is generated, printed and delivered accordingly to each employee as the bank transfers are disbursed.
22
Fig. 6 Use Case Diagram for Payroll module
23
HIS Functional Description
Managing the Reception
This is the first stage of interaction for all the people visiting the hospital for various reasons. This module comprises of information about doctors, patients, departments and all other hospital activities. The reception module also facilitates for scheduling appointments and enquiries. a) Enquiries related to patients;
Patient discharge details
Details for bed, room or ward allotment
Details for patient payments
Details about patient admission b) Enquiries related to Doctors;
Schedules for operation
Doctor availability details
Scheduling doctor/patient appointments
Registering Patients
Prior to any treatment, consultations or tests all patients are required to get registered.
This process has several inputs which include demographic and other general patient descriptive information. A unique patient identification number and a registration number are allocated to all
24 successfully accepted and added patients’ details. However, the system will assign the patient a new patient registration number for every visit while the patient maintains the same patient ID throughout their subsequent hospital visits. Receipts can be generated from OPD patient details collected during the patient’s registration charging on consultation fees where applicable. Details collected from OPD patients to facilitate successful registration include address, name, telephone number, sex and age among other details like insurance status (Pfleeger S., & Atlee, 2010). The consultant to be seen and the department are prerequisite for a patient’s registration record.
Managing Inpatients
This module takes care of all tasks regarding inpatients’ management in the hospital. It automates daily administrative tasks leading to better caring for patients and comprehensive patient admissions information and ward/ room allocation. This process depends of among other factors; prior admission booking, availability of rooms/ beds, estimations and emergencies. This module is responsible for queries such as;
Collections made in advance
Admission of inpatients
Details for discharging patients
Day to day patient progress
Entries from patient visit to consultant
Daily dosages for prescribed drugs
25
Surgery details for the patients
Bed transfer and allocation details
Suggestion or indication of nearing discharge dates for patients
Summarized notifications for patient discharge
Details of the patient’s consultant
Managing Outpatients
The consultation chamber is the next step after successfully registration of a patient.
Consultants then record the patient’s diagnosis, tests, history of previous visits, next visit and prescriptions (Prokosch, 1995). The patient’s OPD card has the following details noted by the attending consultant;
Patient History
Medicine or Prescriptions
Tests or Investigations carried out
Advice to patient or pharmacy
Diagnosis
Complaints by patient
Date for next visit where necessary
26
All the above information is then entered into the system by operators at the OPD station or by the attending consultant. It facilitates for future analysis and research on a patient’s history of hospital visits. Prescriptions are also recorded.
Channeling Services
Details regarding all outpatient and inpatient appointments are maintained using this module.
Payments
Significant Inpatient Payment Features;
Final and provisional hospital bills
Payments collection by Debit or Credit cards, Cash, Cheque or on Credit
Managing partial and full payments
Sending payment requests
Automatically determining available patients’ credit limits
Facilitation of patient billing through another account such as a donor or company account
Additional ambulance charges at the patient’s discharge if necessary
Significant Outpatient Payment Features
Charges for consultations are picked from the system automatically according to the prevailing emergency or general charges.
Defining Credit and Cash OPD patients.
Recording all payments charged to the patient.
27
Patient categories are used to determine charges for various services which are automatically picked from the system.
Dispensations as well as dispensation authority details are recorded.
Time of service provided any patient also is a factor considered in picking charges.
The patient’s ID number will be used to retrieve their details throughout subsequent visits.
The department overseeing the investigation of patient details receives a copy of the information recorded.
Inventory/ Central Store
All hospital’s Medicine, Equipment, Implants, Materials, all Assets and Consumables
Inventory are dealt with in this module. The above information is archived along with other important details such as suppliers and purchase details. Hospital requisitions are sent from the various departments to the stores managing department (Prokosch, 1995). The stores attendant then distributes the required equipment/ items or creates orders for purchases accordingly.
Master tables that contain records of items, stock, equipment, purchases, materials and a list of suppliers are maintained using this module. The module is designed to ensure constant
28 availability of consumables as well as drugs in a seamless mode at all times. The most significant features in this module include;
Strictly observing the dates of expiry for the Consumables and Drugs
Maintain purchase and supplier details for all for all items
Generate orders for patient requested purchases
Categorizing items into varied clusters
Defining items such that any user will only view departmental related items
LIFO and/or FIFO can be used to issue requested items
Warning for reorder level to maintain different items accordingly
Maintenance of stocks for several sub stores as well as the central store
Maintaining vendor details for all purchased items
Acknowledgement of returned purchases
The sub stores can also return wrong deliveries to the central store
Radiology Module
Scheduling of radiology services and resources is made possible using this module. The radiology services under this module include Scanning, X-ray and Ultra sound tests. The system records all tests and generates reports according to the results for both out-patients and inpatients (Pfleeger S., & Atlee, 2010).
29
Reports Generation Module
A user can use this module to view database population reports like;
Hospital reports
Reports for revenues
Patient reports
Reports for payments
Reports on financials
Payment reports
Doctor related reports
Reports from payroll
Financial Accounting Module
The significant features of this module include;
Cost Centre’s user definition
The billing module transfers all revenue related entries automatically to the accounting department.
Accounts and Ledger groups defined by users
Printing cheques
30
Generating main reports with associated graphs
Maintaining details of income from all departments
Payroll Module
All employees’ deductions, attendance and details of arranged leave as well as generating pay checks are managed in this module. The main features include;
Salaries are set on wages or monthly basis
Maintaining the complete employees’ record that has details such as demographic data, salary amount, name of employee, code, designation, ESI and PF accounts
User defined leave’s
Employee records of attendance
Determining final salary as per specified formula
Salary increment application formula
Records of overtime, time in and time out
Details of employees’ long term and short term loans
Pharmacy Module
This module typically deals with issuing of medicine to in-patients and retailed medicine to out-patients patients. Functions of this module include managing the billing and inventory of medicines, prescription of drugs online, sutures and consumables. This module works closely
31 with the inpatient and payments module where patient related drugs requests can be indented from a variety of sub stores (Pfleeger S., & Atlee, 2010). Significant features include;
Automatically billing inpatients
Complete control of out-patient and in-patient details of issuance or purchases in the pharmacy
Items reorder level maintenance
Checking for expiry dates before approving issuing of drugs
Distributing requested items in accordance to LIFO or FIFO
Classification of drugs either by appearance or content
Acknowledging returns
Transaction details from each vendor are kept
Dental Module
Services provided at the dentists and their details are dealt with in this module. Progress and treatment reports related to this module are stored for referencing during a patient’s future hospital dental visits.
Maintenance Module Features
Maintenance of Hospital Wards
Maintenance of Medicines
32
Maintaining Rooms
Maintaining Departments
Maintenance of Services at the Hospital
Maintenance of Doctors
HIS Technical issues
The system will be developed in a Visual Studio 2012 environment with the inclusion of
MS SQL server 2005 for the relational database.
Operational Requirements
The proposed HIS will be expected to be primarily a tool for the receptionist desk which will need people with competent or moderate skills in computer operations. This is the chief source of daily data and information that is disseminated to other departments through the central repository database system. Other users like doctors will only need the system sporadically and mostly to look at reports and rarely to enter any information or generate reports themselves. The new HIS is also projected to seamlessly integrate all hospital operations and computerizing daily routine tasks. Different users will access and modify information from different modules of the
HIS according to their assigned rights. The system should be available around the clock.
Technical Requirements
This HIS will work on MS Windows 7, XP professional and Windows Vista. It will also be able to run on generic computers running on Windows but cross platform portability is encompassed into the design of the system. The proposed system will require a menu driven GUI with a comprehensive help manual for the users. Issues with system initial usage will be covered
33 in the documentation of the help manual which will also assist in new user training on the job.
The system will also be able to calculate payments for patient billing and employees’ salaries.
Non-Functional Requirements
Security
The proposed HIS provides security in a way that the database contents will not be universally accessible to anyone. Different users will be able to access only what is related to their daily operations.
Identification of Patients
– patients are required by the system to use their assigned PHN to identify themselves.
Rights of Receptionists
– staff at the front desk will be able to insert new patients and view all HIS information but will not be able to change any further associated patient information henceforth.
Database Modification
– any modifications done to the database (delete, insert or update) will be synchronized only by the administrator(s).
Logon ID
– all system users will be issued with an appropriate username and password for system access.
Rights of Administrators
– the system administrators will be able to modify and view all information held by the HIS.
Availability
The system is also expected to be available at all times of the day
34
Performance
Conformity
– the new HIS should be conventional to Microsoft Accessibility
System Response Time
– the response time after checking information about patients should be 2 seconds or less.
System Capacity
– the system is also expected to support 1000 users at any single time seamlessly without major crashes or downtime.
User Interface – the user interface screen is designed to respond in under 5 minutes
Reliability
The general simplicity of the form generation language vs. the form’s functionality should speed up the development of forms without limiting functionality.
Reusability
The code produced should be independently usable elsewhere to develop other related modules.
Safety
The detrimental consequences of ordinary human errors have to be limited since human beings are error-prone. Users should for example be provided with the choice to go ahead with deletion of data, undo or cancel the action.
Maintainability
Errors
– all system errors should be logged into the system for future reference.
35
Back up
– data backup capabilities shall be provided by the system as required.
36
Use cases and fully dressed use cases
1
2
3
4
5
6
7
8
Use case Schedule Appointment
Actors Receptionist
Type Primary
Description: when an out-patient comes to receptionist or calls from phone and asks to receptionist for appointment. Then see the schedule of specific doctor and fix a time for appointment of patient.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Schedule Appointment fix checkup time with doctor
User goal
Receptionist
Patient, doctor
Login to system
Allocate appointment slip to patient
1.
Login to system
2.
View schedule of specific doctor
3.
Fix appointment
4.
Print out appointment slip.
View schedule
Register patient
Receptionist could search all doctor schedules by their name or id.
6
7
8
1
2
3
4
5
37
Use case Admit patient
Actors Receptionist
Type Primary
Description: when a patient comes to hospital then the receptionist admit him. Patient may be in-door or out-door. In case of in-door patient would allocated a bed. In case of out-door patient the patient would get treatment according to schedule
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Admit patient
Admit in-door and out-door patient
User goal
Receptionist
Patient
Login to system
Allocate admit slip to patient
1.
Login to system
2.
Select admit
3.
Select indoor/outdoor
4.
Register patient
5.
Allocate bad
6.
Give admit slip to patient
Register patient
Search bed
Allocate bed
Receptionist could search bed by specific ward.
6
7
8
1
2
3
4
5
38
Use case Discharge patient
Actors Receptionist
Type Primary
Description: when a patient gets treatment in the hospital then he will discharge from hospital. Receptionist will discharge him. Receptionist will create bill for patient according to his services that he used in hospital.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Discharge patient
Generate bill for patient
User goal
Receptionist
Patient , accountant
Login to system
Allocate bill patient
1.
Login
2.
Select discharge
3.
Select indoor/outdoor discharge
4.
Vie services
5.
Generate bill
6.
Print out bill
View services
Record services
Bill contains details of all services and next visit date
1
2
3
4
5
6
7
8
39
Use case Give prescription
Actors Doctor
Type Primary
Description: After getting registration patient would get treatment from doctor. Doctor would give prescription to the patient and record in the patient’s record.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Give prescription
Record prescription given to patient
User goal doctor
Patient, nurse
Login to system
Give prescription slip to patient
1.
Login
2.
Select prescription
3.
Entre patient id
4.
Record prescription
5.
See massage prompt
Wrong patient id
Doctor could record drug prescription and food prescription separately
5
6
7
8
1
2
3
4
40
Use case Give suggestion
Actors Doctor
Type Primary
Description: when doctor give treatment to the patient he could suggest suggestion may be for tests, operations and to admit.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Give suggestion
Suggest tests, operation or to admit in hospital primary doctor patient
Login to system
Give suggestion slip to patient
1.
Login
2.
Select specific suggestion
3.
Enter patient id
4.
Record suggestion
5.
Print out suggestion slip
Wrong patient id
There are separate suggestion slip for admit, surgery or to admit in hospital.
6
7
8
1
2
3
4
5
41
Use case view patient record
Actors Doctor, Nurse
Type Primary
Description: when doctor give treatment to patient he could see pervious record of the patient. He could see the reports of different test of the patient. He could see operations details, previous prescription etc.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case view patient record
Doctor could view treatment history
Primary
Doctor
Patient
Login
Get patient record
Login
Select view record
Select specific record
Enter patient id
View record
Wrong patient id
Doctor has different option to view record.
Ex. Last visit, specific visit
1
2
3
4
5
6
7
8
42
Use case File reports
Actors Nurse
Type Primary
Description: when reports of test are generated these reports would give to the nurse who records these reports. These reports would become the permanent part of the patient record.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
File reports
Record test reports, daily reports and operation details primary
Nurse patient
Login to system
Record report
1.
Login
2.
Select file report
3.
Select specific report
4.
File report details
5.
Prompt message
Wrong patient id
Report should be detail, Date of report mention
6
7
8
1
2
3
4
5
43
Use case Manage User
Actors Admin
Type Primary
Description: Admit control system. He could create users, update user and delete users.
Update include different tasks like change user name, change password etc. whenever he create a user he allocate him a user name and password to user.
9
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Fully Dressed Use Case
Manage User
Admin manage accounts of different users of system primary
Admin staff
Login to system
Update user accounts
1.
Login
2.
Select manage accounts
3.
Select create/delete/update
4.
Enter account id
5.
Enter admin password
6.
Enter data
7.
Prompt message
Wrong patient id , wrong admin password
4
5
6
7
8
1
2
3
44
Use case Manage Inventory
Actors Medical store attendant
Type Primary
Description: Medical store attendant manage inventory. He/She could issue inventory on request of employee. He/She could see current status of inventory. He/She could also purchase inventory. He/She can see add item in request list. He/She will see request list when he will going to the purchase inventory.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Manage Inventory
Manage inflow and out floe of inventory
Primary
Medical store attendant
Employers
Login
Record transaction
1.
Login
2.
Select issue/purchase/request /add item
3.
Enter inventory id
4.
Enter quantity
5.
Prompt message
Wrong inventory id
Inventory not in stock
After transaction prompt message give last quantity of inventory item.
1
2
3
4
5
6
7
8
45
Use case Manage schedule
Actors Shift In-charge
Type Primary
Description: shift in-charge handle schedule of staff. He allocates duties according to the rank of doctor, nurses. Doctors and doctor have to follow this schedule.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
`Fully Dressed Use Case schedule duties
Allocate duties of doctors and nurses
User goal
Shift In-charge
Doctor, nurses patient
Login
Assign duties
Print out schedule
1.
Login in
2.
Select nurse/doctor duties
3.
Enter id
4.
Enter select indoor/outdoor duty
5.
Enter ward id
6.
Enter time /date
7.
Prompt message
Wrong employee id, wrong ward id
Date and time should mention clearly
1
2
3
4
5
6
7
46
Use case view schedule
Actors doctor/nurses / shift in-charge
Type Primary
Description: doctor and nurses can view there are schedule in order to perform their duties. This schedule is maintained by shift in-charge
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case view schedule
View schedule of duties
User goal
Nurse /doctor
Doctor, nurses
Login
Get schedule
Login in
Select view schedule
Enter date / week/month
View schedule
Wrong date
Employee should different to view schedule.
1
2
3
4
5
6
7
8
47
Use case Manage employee record
Actors Admin
Type Primary
Description: when an employee get hire in the hospital. Then admin will record his all details. Details include bio data, joining date, rank and thumb impression etc. admin could update record of the employee.
9
10
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Special Req
Fully Dressed Use Case
Manage employee record
Manage all details of employee
User goal
Admin
Employees
Login
Authority letter from higher management
Record employee information
1.
Login in
2.
Select hire employee/fire employee/update employee
3.
Enter id (not in first case)
4.
Enter date
5.
Print out information
Wrong employee id
Print out paper include all information
1
2
3
4
5
6
7
8
48
Use case Handle transaction
Actors Accountant
Type Primary
Description: Accountant would handle all transaction. He could collect bills for patient.
He also gives salary to the employees and gives funds for purchasing for inventory.
9
Use case name
Scope
Level
Primary actor
Stakeholder
Precondition
Post condition
Success scenario
Extensions
Fully Dressed Use Case
Handle transaction
Handle inflow and outflow of cash primary
Accountant
Employee / patient
Enter issue slip number /bill number
Collect bill / pay cash
1.
Login
2.
Select inflow/outflow
3.
Select salary/inventory/maintain (outflow case)
4.
Enter bill/ issue slip number
5.
Verify bill/ fund slip
6.
Collect bill / pay cash
Verify issue fund slip
Wrong issue fund/bill number
Cash not available
49
Extended use case Diagrams
Schedule Appointment view schedule
<<extend>>
(from i ncl uded use cases)
Schedule Appointment
(from HMS)
Receptionist
(f rom HMS)
Admit patient
<<include>>
Admit patient
(from HMS)
Register patient
(from i ncl uded use cases)
<<extend>>
Verify appoinment
(from extended use cases)
Admit outdoot patient
(from HMS)
<<include>>
Admit indoor patient
(from HMS)
Allotment of bed
(from i ncl uded use cases)
<<extend>>
Receptionist
(f rom HMS) check doctor reference
(from extended use cases)
50
Discharge patient
<<extend>>
Generate bill
(from i ncl uded use cases)
<<include>> view patient services
(from extended use cases)
Discharge out-patient
(from classes )
Discharge patient
(from HMS)
Receptionist
(f rom HMS)
Discharge in-patient
(from classes )
Give prescription & suggestion
<<extend>> view patient record
(from HMS)
Doctor
(f rom HMS)
Give suggestion
(from HMS)
Give prescription
(from HMS)
Give drug food prescription
(from classes )
Give food prescription
(from classes )
<<include>> suggest test
(from classes )
<<extend>> suggerst surgery
(from classes )
<<include>>
Refer to Opreate
(from i ncluded use cases) suggest admit
(from classes )
Refer to Admit
(from i ncluded use cases)
51
View patient record
Doctor
(f rom HMS)
Nurse
(f rom HMS)
File reports view patient record
(from HMS)
view old prescription
(from classes ) view opreation report
(from classes ) view daily report
(from classes ) view test reports
(from classes ) view report
(from classes )
File reports
(from HMS)
File opreation reports
(from classes )
File daily reports
(from classes )
Nurse
(f rom HMS)
File test reports
(from classes )
52
Manage User
Admin
(f rom HMS)
Manage Inventory stockeeper
(f rom HMS)
Manage User
(from HM S) create user
(from classes ) suspent user
(from classes ) delete user
(from classes ) update user
(from classes ) check avalibility
(from extended use cases)
<<extend>> issue inventory
(from classes )
Manage Inventory
(from HMS)
Add inventory
(from classes )
53
Issue funds check funds avability
(from extended use cases)
<<extend>>
Issue inventory fund
(from cl asses )
Treasure officer
(f rom HMS)
Issue fund
(from HM S)
Issue salary fund
(from cl asses )
Issue maintaince fund
(from cl asses )
Handle transaction
Accountant
(f rom HMS)
Handle transaction
(from HMS)
Handla bill
(from classes )
<<include>>
Handle funds
(from classes )
Handle salary transaction
(from classes )
Handle inventory transaction
(from classes )
Handle maintaince transaction
(from classes ) verify fund
(from i ncl uded use cases)
54
Accountant
(f rom HMS) stockeeper
(f rom HMS)
Treasure officer
(f rom HMS)
Doctor
(f rom HMS)
Nurse
(f rom HMS)
Admin
(f rom HMS)
Receptionist
(f rom HMS)
Schedule Appointment
(from HMS)
Discharge patient
(from HMS)
Admit patient
(from HMS)
Give prescription
(from HMS) view patient record
(from HMS)
Give suggestion
(from HMS)
File reports
(from HMS)
Handle transaction
(from HMS)
Manage User
(from HMS)
Manage Inventory
(from HMS)
Issue fund
(from HMS)
Sequence Diagrams
Schedule Appointment
: Receptionist view schedule doctor schedule
: schedule
55
: appoiment enter appoiment conformation of appoinment
56
Admit patient
: Receptionist req.admit
: admit : patient : indoorAdmit register
(for indoor admit) details
(for outdoor admit) details admit conform conform admit patient id
: outdoorAdmit
Discharge patient
: Receptionist enter pat-id
: discharge verify patient conform patient
: patient
Allow discharge enter discharge detail conform discharge
57
Give prescription
: Doctor req prescription
: prescription verify patient conform patient
: patient
Allow prescription enter prescription confrom prescription
58
File reports
: Nurse enter patient_id
: Report verift patient conform patient
: patient allow report enter report details confrom report
Give suggestion
: Doctor req suggestion
: suggestion verify patient conform patient
: patient
Allow suggestion enter suggestion complete suggestion
59
Handle transaction
: Accountant req tnanc
: tranction
(for in tranctions)
: Bill : Funds verfy patient conform
: patient
(for out tranction) conform allow tranction enter tranction complete tranction
Issue funds
: Treasure officer req fund
Allow funds enter fund complete fund
: Funds verift employer conform
: staff
Class diagram
60
61
Requirements and Quality
Quality of Software
Quality Management Plans are sets of planned activities that help during the project’s planning and development phases to ensure quality is achieved. The main purpose of a QMP is focusing on the activities that will bring customer satisfaction regarding their quality expectations. The company delivering the service or product defines the Quality Assurance tasks basing the process upon its set quality standards. In this case, Our Lady of Mercy Hospital will be dependent on the efficiency and seamless interaction of the new proposed HIS to provide quality services to its patients.
Therefore the system’s ability to deliver on the specified requirements optimally is essential for the successful completion of this project. An example is the warning mechanism incorporated into the stores management module. If there are any malfunctions in this module then the hospital runs the risk of going out of stock for certain drugs and/ or consumables or distributing expired products. Slow operation or downtime at the receptionists’ desk can also create a long queue of angry patient waiting to be checked in. Some patients will often formulate their own assumptions on the expected quality of service from a single situation like this.
There are several metrics that could be considered during Quality Management Planning by the project team and they include; a) Customer Satisfaction – this metric is used to indicate perceived real world quality of services and products. Service metrics for customer satisfaction may represent the ratio of complains per unit survey. It uses customer suggestions to plan for future quality improvements.
62 b) Outcome Metrics – this is the service or product’s end result and it measures the overall quality. Combined events and factors are the basis of this metric which include; number of complaints received and service completion time. c) Promotion and Innovation – the innovation metric encourages working teams to refresh their service approach. After distinguishing between impractical and practical methods, they use the promotion metric to measure how well they have sold their idea to the target public. d) Cost Indices – these are used to measure the cost of quality for businesses. They indicate whether sufficient quality control measures are in place or otherwise. Cost indices may include negative publicity costs from a poorly produced product or service reflecting also on lost opportunities.
Stakeholders Quality System Interaction Requirements
Software Interface
The new Hospital Information System needs to run on Windows OS and interface with the SQL database server. Other software interfaces required for the system include browsers like
Internet Explorer or Mozilla Firefox. The use of standard regular OS and browsers as an interaction platform allows for ease of system operation, access and navigation. The windows
GUI technology is a good tool for encapsulation of object classes in OO programming.
63
Hardware Interface
The HIS is expected to be functioning at an optimal level on desktops running on windows OS that interface with network printers. The keyboard and mouse will be the supported devices used for input of data into the system. The computers are required to have at least 80 GB of Hard disk space, over 1GB of Ram and a Dual-Core processor 2.3GHz. This will facilitate faster responses from the system. The receptionists will be the busiest system users and the need to have a good computer with high processing capabilities will help in better data capturing and retrieval.
Communications Interface
The proposed HIS requires internal communication protocols that will automatically be mounted on the Windows OS. This will enable the ease of networking the computers used with the system and thus better peer to peer communication or communication to other network devices like network printers. There will be no need for a separate installation of the two main protocols which are;
TCP/IP and
HTTP protocols.
Windows as the primary display
User Interface
User Interfaces facilitate the interaction of the users with the intended system and entering data into the designated database. Users input information that is saved in the database and use it to generate various reports.
64
Different criteria will be used for both the search facility and verification of stock
The proposed HIS provides an easy to use and straight forward GUI (Graphical
User Interface) for the system users to perform required hospital activities effectively
Allowing users to view various generated reports and ensuring the entire system screens will include a facility for help
65
Requirements Verification and Validation
The process of Validation and Verification of requirements entails reviewing of a predefined checklist used to evaluate a system’s correctness of its desired attributes. The goal of verification and validation is the discovery and early resolution of high-risk issues in the development of software projects. Developing new software products sometimes may require the testing and documentation of various software parts. This is done to ensure the project is proceeding as intended.
Fig. 7 Verification and Validation in a simple SDLC
66
Verification deals with establishing the complete correspondence of the proposed software product and the specified requirements. Validation on the other hand seeks to establish the worth of the system with regard to its operational requirements. The main informal questions answered by these two processes are;
Validation – “Are we building the correct product?”
Validation can be defined as the checking of a software product’s design to establish whether it satisfies the intended functions. This seeks to determine the closeness to real life application of the product being developed according to the set standards (Torp, 2003).
Validation ensures that predetermined data formats are fully satisfied and the correct criterion for input is complied to. Only real or true data is allowed for entry and storage into the system database. The proposed Hospital Information System (HIS) software validation plan has three main dimensions;
1.
Operational Validity – it is the behavioural subjective evaluation of the software development model. o Sensitivity of Model: this refers to the degree to which the stability of a model can be affected by small parameter changes on the data o Improvement Degree: how robust the results of the model turn out due to the suggested improvements. A 60 percent performance improvement on a system may suggest insignificant error impacts o Model Implementation Ability: the model should have the ability to produce adoptable practical results
2.
Technical Validity – this is the comparison made against rational criteria sets.
67 o Validity of Model: this refers to the degree the system will represent real situations. To accomplish this following procedure will be implemented.
Vet and make a clear list of assumptions made casually and mathematical content.
Develop the system’s conceptual model
All elements and boundaries in the system to be clearly defined
Vet the assumptions and the model with both technical experts and content experts o Validity of Data: this refers to the level to which used data for decision making instances represents real situations. This will cover the following;
Identification of sources of the data
Identification of the actual data that will be needed to successfully complete the validation process
Identification and correcting of aggregated data through the initial analysis
Conducting test to basically determine reasonability of data
Validity of data statement development o Logical Validity: this refers to the correctness of the translated computer code from the intended theoretical system model. The success of this process depends on the following elements.
Using available tools like debuggers, compilers and trace elements in when developing the software
Scepticism and assuming the system is not correctly done and building correction testing elements for the model
68
Using content professionals to check the system throughout the developmental cycle and conducting a comprehensive structured system walk through with the help of technical specialists.
Developing the system model using the evolutionary approach by building and testing individual small system modules. o Validity of Predictability: this is the checking for the system’s conformity through produced results. This is achieved through the following;
Comparing the existing system’s actual output against the simulation
Comparing the known system performance theories against the simulation
3.
Dynamic Validity – this defines the system’s utility over time. o Process of Updating: this refers to the completeness and accuracy of the periodic process of updating the parameters in the model o Maintainability: the simplicity that changes can be made on the model over a period of time o Process of Reviewing: this is the ensured checking and reviewing of a system’s conformity to reality periodically
69
Fig. 8 Validation process Flowchart
70
Validation Report
Documentation of all activities during the validation of any software project may seem like an overwhelming task but it is important. However this exercise will be reasonably easy if the recommendations provided in this validation plan are keenly followed. The two activities associated with validation during software projects are;
Initial Work: this involves summarizing and/or specifying the user requirements, managing the design phase and the actual project development, making the test validation plan, precaution documentation and installation preparation. Finally planning for the maintenance process. Signing and dating all activities and documents is a must.
Testing and Peer Reviewing: this involves the reviewing of documents concerning the process of validation, installation and testing. All resulting actions and documents from these processes should also be signed and dated.
This HIS software is intended to handle vital procedures in terms of whom, when, why and where that are applied for the duration of the operation of the HIS. Traceability of these events all through the development cycle of the HIS is also very important and should be included in the validation report. Signing approved requirements should be done before designing commences (Torp, 2003). Tests should be carried out after the signing of approved test specifications. Another important aspect is the identification of key persons that are authorized to sign the approved reports. Other major elements include;
Testing the product should be carried out by other people who are not directly involved in the development process.
The authors of the documents should not be the approving authority.
71
The acceptance testing of the system should not be carried out by the development team but rather the system owners.
Verification – “Are we building the product correctly?”
Verification is a complex and broad software engineering discipline that seeks to guarantee satisfaction of the expected software’s requirements. The verification plan process for this HIS will follow two key approaches;
Static Verification – this process also known as analysis is useful in determining the correctness of project software. It is however common to have false positives when using this procedure. This process usually checks for the physical bugs that include; o Detecting bad coding practices o Formal verification o Verification of code conventions o Calculating metrics in software
Dynamic Verification – also known as experimentation, this process is used during a project’s execution to find bugs through dynamic system behavioral checks. The tests scope are categorized into three expandable families; o Small Testing – which is a test used for unit testing to check a single class functions o Large Testing – this testing is used to check groups of function classes like integration testing for more than one module, single module testing and the entire system testing.
72 o Testing for Acceptance - this test is formally used to check for the criteria for a project software testing. It includes non-functional and functional testing to determine performance stress levels.
Test cases are verification tools used to determine right software product development process. They are also used in validating the user requirement specifications.
Traceability Matrix
A TM (Traceability Matrix) is a table used to trace requirements to their verification test cases and determine if the user specifications have been properly met. Good traceability matrix tables should be bidirectional in that one should be able to trace a test to user requirements and vice versa. A TM is also used for Quality Assurance to ensure the clients get the correct product as requested (Periyasamy, 2013).
Benefits of Traceability Matrix Tables
Ensure developers only create requested program features
Making it obvious to the customer that the specified requirements have been fulfilled
Ease of identifying functionalities that are missing from the final product
Knowing which test cases to update if requirement change requests are made by users
73
Project Name:
Project
Description:
Functional Module
Reception
Payroll
REQUIREMENTS TRACEABILITY MATRIX
Our Lady of Mercy HIS
Hospital Information System
Use Case ID /
Req #
SRS005
SRS001
SRS007
SRS013
Req Description / Use Case Description
Scheduling appointments for doctors
Admission of inpatients
Patient information enquiries
Generating Pay slips
Test
Case_ID
TC-1
TC-1.1
TC-1.3
TC-2
Remarks
Success
Success
Success
Success
Central Store
Pharmacy
SRS014
SRS011
Reports Generation SRS018
SRS019
Payments SRS016
Radiology SRS008
Maintain purchase and supplier
details for all for all items
Maintaining stock of medicine
Patient reports
Doctor related reports
Final and provisional hospital bills
Test report updates
TC-3
TC-3.1
TC-4
TC-4.1
TC-5
TC-6
Success
Failed
Success
Success
Failed
Success
74
References
Blum, B. I. (1986). Clinical information systems . New York: Springer-Verlag.
IEEE recommended practice for software requirements specifications . (1998). New York, NY:
Institute of Electrical and Electronics Engineers, Retrieved from http://math.uaa.alaska.edu/~afkjm/cs401/IEEE830.pdf
Leffingwell, D. & Widrig, D. (2003). Managing Software Requirements-A User Case
Approach ,2nd Ed. Addison-Wesley.
Periyasamy, J. (2013, April 21). Traceability matrix in software testing Software Testing
Tutorials - Manual and Automation Questions Answers , Retrieved from http://www.jobsnewstoday.com/2013/04/what-is-traceability-matrix-in-software-testingwhy-it-is-needed.html
Pfleeger S., and Atlee J. (2010), Software Engineering Theory and Practice. New York, Prentice
Hall, pp. 1–44
Prokosch, H. U. (1995). Hospital information systems: design and development characteristics, impact and future architecture . Amsterdam: Elsevier.
Torp, C. E. (2003). Method of software validation. NT TECHN REPORT , (535), doi: TR 535
