Thesis (CLIS)

COMSATS Institute of Information Technology, Vehari
The Department of Computer Science (CS)

Author: Sadia Razaq & Sana Kousar
E-mail address: sadiarazaq55@gmail.com
Reg No: SP13-BS(CS)-028 & 037
Study programme: Bachelor in Computer Science , 134 credits
Examiner:
Tutor: Kalim Sattar
Scope:
BS(CS). Thesis
within Computer Science, 6 credit hours
Clinical Laboratory Information System
Sadia Razaq & Sana kousar
1
Abstract
A medical laboratory or clinical laboratory is a laboratory where tests are done on clinical specimens
in order to get information about the health of a patient as pertaining to the diagnosis, treatment,
and prevention of disease. The critical and important part of any clinical laboratory is to maintain
the patient’s clinical test record. Clinical laboratory management requires to keep accurate and up
to date and historical patient’s test records that could be helpful for medical consultant to identify
the progress and side effects of medicine in patient’s body.
In the clinical laboratory Information system there are two basic modules (1) User (2) Employee and
administrator to manage the website.
Keywords: HTML, PHP, CSS3.
2
Acknowledgements
First and foremost We would like to thank HOD computer science department of C.I.I.T Vasari
(Dr.Imran Qureshi) and Our project supervisor (Sir Kalim Sattar ) for supporting and encouraging us
all the time giving us opportunity to enhance our technical skills and complete this project.
We would like to thank Our parents and family members for supporting Us during Our academic
career, who always support Us so that We could focus on Our project work.
Finally, We would like to thanks all of Our class mates and friends whose names are not mentioned
here but have helped Us in some way to accomplish Our project work.
3
Contents
Introduction.........................................................................................................................................4
1.1 Present System...........................................................................................................................5
1.2 Present System components.....................................................................................................5
Figure 1.1 present system component..................................................................................................6
1.3 Flow Diagram of Existing System................................................................................................7
Figure 1.2 Flow Diagram of Existing System...................................................................................7
2 Proposed System.............................................................................................................................7
2.1 System Overview........................................................................................................................7
2.1.1 Patient...............................................................................................................................8
2.1.2 Employee...........................................................................................................................8
2.1.3 Administrator.....................................................................................................................8
2.2 System Flow Diagrams..................................................................................................................8
2.2.1 Flow Chart...........................................................................................................................8
2.2.2 DFD Level 0..........................................................................................................................9
2.2.3 DFD level 1.........................................................................................................................10
3 SRS..................................................................................................................................................11
3.1 Use cases..................................................................................................................................11
3.1.1 Use case Diagram...............................................................................................................12
3.1.2 Use case Discription...........................................................................................................13
3.2 Sequence Diagram....................................................................................................................37
3.2.1 Patient...............................................................................................................................37
Figure 3.1 Patient sequence Diagram.................................................................................................37
3.2.2 Employee.........................................................................................................................38
Figure 3.2 Employee sequence diagram.........................................................................................38
3.2.3 Administrator....................................................................................................................39
Figure 3.3 sequence diagram of Administrator...................................................................................39
3.3 Database..................................................................................................................................40
3.4 ERD...........................................................................................................................................41
5 Testing.......................................................................................................................................44
5.1 The Testing Process.............................................................................................................44
5.1.1 Testing Schedule..............................................................................................................44
5.2 Testing Methods..................................................................................................................44
5.2.1 Statistical Testing.............................................................................................................44
4
5.2.2 Defect Testing..................................................................................................................45
5.3 UNIT Testing........................................................................................................................45
5.3.1 LOOP Testing...................................................................................................................45
5.3.2 BLACK-BOX Testing..........................................................................................................45
5.3.3 WHITEBOX Testing...........................................................................................................47
5.3.4 Structure Testing.............................................................................................................47
5.4 Integration Testing..............................................................................................................47
5.5 Performance Testing............................................................................................................48
5.6 Condition Testing.................................................................................................................48
5.7 Interface Testing..................................................................................................................48
5.8 Test Cases.................................................................................................................................50
5
Terminology
Acronyms
PHP Hypertext Pre processor
HTML Hyper Text Mark-up Language
CSS Cascading Style Sheets
Specimen Samples (e.g, Blood, urine)
User Patient
Employee Lab Workers
DFD Data flow diagram
ERD Entity relationship diagram
6
Introduction
A medical laboratory or clinical laboratory is a laboratory where tests are done on clinical specimens in
order to get information about the health of a patient as pertaining to the diagnosis, treatment, and
prevention of disease. The critical and important part of any clinical laboratory is to maintain the
patient’s clinical test record. Clinical laboratory management requires to keep accurate and up to date
and historical patient’s test records that could be helpful for medical consultant to identify the progress
and side effects of medicine in patient’s body.
CLIS will enhance the quality of work substantially. The majority of the errors in the laboratory are
caused by human acts. These errors can be reduced by the automation of the laboratory process by the
introduction of a CLIS. The CLIS will also reduce the work load of the technicians.
The Clinical Laboratory information system (CLIS) is a data processing and dissemination technique used
in the laboratory to deliver accurate and understandable results within a reasonable timescale as
requested by clinicians. The system entails a sequence of events which include, delivery of samples to
the laboratory, sample accessioning, analyzing, verifying and approving results or reanalyzing samples
and releasing results to the clinicians who requested the tests . In short, the concept of CLIS refers to the
computerization of the laboratory system or automation of clerical labor-intensive activities associated
with the processing of laboratory results to improve accuracy and turnaround time of results.
Automation of laboratory activities removes the element of manual reporting, increases productivity
and allows access to retrospective data for analysis . Previous studies have reported an improvement in
the accuracy of data and turnaround time of laboratory results after installation of the CLIS .
The increase in clinical specimens as well as the consolidation and integration of laboratories and tests
have resulted in the generation of significant volumes of tests and data. The complex and large quantity
of data that these laboratories accumulate as well as the continued demand for data to support public
health surveillance for effective disease prevention has resulted in the need for operational CLIS.
1.1 Present System

There are many laboratory Information systems working in market. The main purpose of the these
LIS websites is to facilitates user to Use these sites to get their reports online.
The National MedLIS project will improve the delivery of diagnostic laboratory medicine, healthcare
quality, efficiency and outcomes for patients in the Irish healthcare system. The project will replace
all of the laboratory systems throughout the country and is being supported by the MedLIS and HSE
national technology teams.
7
MedLIS will allow for laboratory information to be shared with the relevant health care providers in
line with clinical need and data protection requirements. The system will also have full audit trail
capability to support data breach detection.
Laboratory Information Management systems play a central role in the operational management
of pathology laboratory workflow as well as providing the infrastructure to facilitate the
electronic communication of patient laboratory examination requests and results from/to hospital
clinicians, wards, etc., and their primary care counterparts, general practitioners, and other relevant
healthcare providers in fixed and mobile settings. It is imperative that the laboratory service should
be supported by a modern information management system underpinned by technology to meet
world-class standards in healthcare. Laboratories cannot effectively function without such systems.
The MedLIS project will deliver significant benefits to the patients, clinicians and local health care
providers who use the laboratory services. These benefits will primarily be manifested by the
reduction in test duplication, the wider availability of results to healthcare providers; faster
electronic accessing of these results, enhanced clinical audit, and a more comprehensive and
robustly stored patient laboratory record.
1.2 Present System components
The main components of existing LIS system as follow:

 Admin
 Lab Technician
 Patient
 Lab analyzer
 Lab Validating physician
 Equipment Manager
 Accountant
8
Figure 1.1 present system component
1.3 Flow Diagram of Existing System
Here is a flow diagram of a existing system of LIS Website name Laboratory Information System Analysis
According to Yourdon Modern Structured Methodology Developed by Lenka Bartonova.
Figure 1.2 Flow Diagram of Existing System
9
2 Proposed System
The proposed system should provide strong user management features – including the concept of
authentication and authorization. Authentication relates to the process of establishing the identity
of a user. In detail, this requires the users to log in and identify themselves, typically with a
password. Authorization relates to the privileges that a user may be given in order to do something
to (for example edit or delete) a record. Most security-conscious enterprises today implement
some form of authentication and authorization for accessing system. The benefits to this approach
are clear – user permissions can be verified before granting access to system, and user activity can
be monitored through various logging mechanisms.
2.1 System Overview
Clinical Laboratory Information system is based on the following basic modules.
1) Patient
2) Employee
3) Administrator
2.1.1 Patient
In the user module following functions are included.
 Download reports
 Check reports history
 View tests list
 View laboratory packages
 Comment on late reports results
2.1.2 Employee
Employee can perform the following functionalities that are included.
 Reports upload
 Reports update
 Check All user reports
 Add Equipments
 Update equipments
 Assign Room to Patient
 Registered Patient
 Collect samples
 Enter reports results
 Create billing lists of patient reports
 Check reports bills records
10
2.1.3 Administrator
Administrator can perform different functions like.
 Assign employee type

 View Employee
 Add employees
 View employee type
 View Lab attendant report
 Assign test to employee
 Add new test
 View patient record
 View test
2.2 System Flow Diagrams

Flow diagrams are the diagrams that show the basics flow of the system here are the basic flow diagram
include flow chart, DFD Level 0 and DFD level 1.
2.2.1 Flow Chart
User
Administrator Type Employee
Login
Not valid
Login form
Patient
Valid info Not valid
Validate info
ew tes Interface View em Login form
Not valid Enter

Add Emp Assigne Interface report
Validate info
emp type results
Add test
Assigne Interface Rep upload Rep update
test
Check Emp
Assign room pat Chk user rep
reports
New lab pkg view lab test Add eqp Assign eq place
View emp Req pat Update equ
type Chk history
Download rep rslt
Collect sample Chk bill rep
ew lab atten
port View pat comment
record
11
2.2.2 DFD Level 0
Admin
Database
Website Website Management
Store data Activity
Fetch data
System
Show information Login
Upload reports Validation

User patient
Employee
12
2.2.3 DFD level 1
user
Login Admin
Employee
System
Admin Interface
Employee interface
Patient interface
Assign AssigneEm
test p type
Online get
Upload Update
reports Add emp Check Emp
reports reports
report
Register Check
patient sample Add test
status View
View test
laboratory
list
Add Check package
equipment reports of
all users
Profile
Database
13
3 SRS
Clinical Laboratory Information system is based on the following basic modules.
1) Patient
2) Employee
3) Administrator
In this chapter we discuss use cases and their detail, system sequence diagrams, ERD of system and
system database.
3.1 Use cases
There are three primary actors of the system
1) Patient
2) Employee
3) Administrator
There are certain function regarding to each actor these functions shows the tasks that the actor can be
performed.
14
3.1.1 Use case Diagram
Add new Employee
Assign test to employee
Add new test
Check emp reports
login
logout
Download reports
Check reports history
View test list
View lab package
Comment on reports
Check sample status
Report upload
Report update
Check user report
Add equipment
Update equipment
Register user
Assign eq place
Collect sample
Enter report results
Create
Checkbills list bill rec
report
3.1.2 Use case Discription
15
Primary Use Cases :
Actor :
Patient: 1. Login
2. Edit profile
3. Logout
4. Download reports
5. Check report history
6. View test list
7. View lab package
8. Comment on late reports
Employee 1. Login
2. Logout
3. Check sample status
4. Reports upload
5. Report update
6. Check user report
7. Add equipment
8. Register user
9. Assign equipment place
10. Collect sample
11. Enter report results
12. Create bills list
13. Check report bill record
Administration 1. Add new employee
2. Assign test to employee
3. Add new test
4. Check employee reports weekly
5. Login
6. Logout
Use cases Uc-1 Login

Scope: Clinical Laboratory Information System
16
Level: User goal
Primary Actor: Patient
preconditions: The user must be already signup on the web site.
Post conditions:
User type the user name and password and click on the login button to
login in the system.
Basic Flows:
1. User type the address of the web site.
2. After loading the web site user can view different Lab test which are
available.
3. On the main page user can find the option of login.
4. By clicking on the login link it shows a login form.
5. If user is already signup on the website user can type Email id and
password and click on the login button and logged in the system.
Alternative Flows
1. If user type wrong Email id or password it will show error to type
user name and password again to logged in the system.
2. If user forget the password click on the link forget password on the
page.
3. The system will send a mail on the given mailing id where user can
select new password.
Special None.
requirements:
Priority: High
17
Use cases Uc-2 Edit profile
Level: User goal
preconditions: User must login to the system.
Post conditions:
1. After login to the system user click on the edit profile button here
user can edit his profile user can edit picture, phone number and other
options.
Basic Flows:
1. User enter the mailing id and password to login the sys-tem.
2. After login the website user can view user interface.
3. In user interface on the top menu user click on the but-ton profile.
4. Here user can view his profile
5. In user profile user click on the option edit profile.
6. On clicking edit profile different entries box appears.
7. In these entries box user can edit there profile information.
8. After editing information user click on the submit but-
Alternative Flows
1. If any information is incorrect then display error.
Special None.
requirements:
Priority: Medium
Use cases Uc-3 download reports

18
Level: User goal
preconditions: The user must be login on the website.
Post conditions: After login user click on the button of download reports which is
available to the user in pdf form.
Basic Flows:
1. User must login to the website
2. After loading the web site user can see its profile then find the button
of download.
3. On the main page user can find the option of download report.
4. By clicking on the download reports link it shows a download form.
5. system is ready to download the report.
Alternative Flows
If the reports are not ready the it will not be downloaded and user can
see the expected time to get the reports.
Special None.
requirements:
Priority: Medium
Use cases Uc-4 check report history

Level: User goal
19
preconditions: None.
Post conditions:
Any one report of patient must be issued to see the history of report.
Basic Flows: 1. In the main page user will fine the option of check history.
2. Here user will press the button of check history.
3. System will display the history of the report.
Alternative Flows
1. If here is no any record then it will display empty history.
Special None.
requirements:
Priority: Medium
Use cases Uc-5 view test list

Level: User goal
Post conditions:
User can see the list of test which are available.
20
Basic Flows:
1. User enter the website URL
2. On the main page of the website user can find the branch test.
3. On clicking on the branch test user can also see those test which are
available website.
Alternative Flows
None.
Special None.
requirements:
Priority: Medium
Use cases Uc-6 view lab package

Level: User goal
Post conditions:
User can see the lab packages according to the test.
Basic Flows: 1. On clicking on the branch test user can also see the test.
2. By clicking the test button user can see the package of that test.
Alternative Flows
21
None.
Special None.
requirements:
Priority: Low
22
Use cases Uc-7 comment on late reports
Level: User goal
preconditions: The user must be already login on the web site.
Post conditions:
Click the comment button get the comment page.
Basic Flows:
1. Open the profile.
2. Find the feedback button after open the feedback page.
3. Find the comment button.
4. Comment about late report.
Alternative Flows
None.
Special None.
requirements:
Priority: Low

23
Level: Employee goal
Primary Actor: Employee
preconditions: The Employee must be already signup on the web site.
Post conditions:
Employee type the Employee name and password and click on the login
button to login in the system.
Basic Flows:
1. Employee type the address of the web site.
2. After loading the web site Employee can view different Lab test which
are available.
3. On the main page Employee can find the option of login.
4. By clicking on the login link it shows a login form.
5. If Employee is already signup on the website Employee can type Email
id and password and click on the login button and logged in the system.
Alternative Flows
1. If Employee type wrong Email id or password it will show error to
type Employee name and password again to logged in the system.
2. If Employee forget the password click on the link forget password on
the page.
3. The system will send a mail on the given mailing id where Employee
can select new password.
Special None.
requirements:
Priority: High
Use cases Uc-9 check sample status

24
preconditions: The Employee must be login on the website.
Post conditions:
After login the website employee select option sample status by click
this option employee can check the sample status.
Basic Flows:
1. On website the main page display the option login.
2. After login it will display the menu bar.
3. On this interface employee press the option sample status.
4 By click this option employee can check the sample status.
Alternative Flows
1. If there is no any sample status it will show a message.
Special None.
requirements:
Priority: High
Use cases Uc-10 Report upload

25
Post conditions:
After login the website employee ready to report upload.
Basic Flows:
On website the main page display the option report upload.
On this interface employee press the option report upload.
By click this option employee can upload the report.
Alternative Flows
None.
Special None.
requirements:
Priority: High
Use cases Uc-11 Report update

Post conditions:
After login the website employee ready to report update.
Basic Flows:
On website the main page display the option report update.
On this interface employee press the option report update.
By click this option employee can update the report.
Alternative Flows
None.
Special None.
requirements:
Priority: Medium
26
Use cases Uc-12 check user report
Post conditions:
System verifies the information and save the information in database.
Basic Flows: 1. Type the Email id and password to login.

2. It shows the option check user report.
3. Employee check the user report while it is pending or sanded.
4. System verifies the data.
Alternative Flows
If there is no any report it will show a message.
Special None.
requirements:
Priority: Medium
27
Use cases Uc-13 Add equipment
Post conditions:
After login to the system employee select option add equipment fills all
the requirement and click on the save button.
Basic Flows:
1. On the main page Employee find the option of login.
2. After login to the system Employee interface display.
3. On this interface employee find the button add equipment.
4. Fills all the requirement and click on save button.
Alternative Flows None.
Special None.
requirements:
Priority: High
28
Use cases Uc-14 register user
preconditions: User cannot register itself.
Post conditions:
Employee fill all the requirement and submit. All the requirement are
correct, and system successfully save the data and then user can login
by given email and password.
Basic Flows:
1. Employee open the signup page to register the user.
2. If user do not register already employee click on the register
button it can view a form.
3. Employee fill all the requirement.
4. If all the entries are correct the data will store in the database.
5. Employee give an email and password to the user.
Alternative Flows
1. If employee entered any wrong entry or any entry not matched
with the standards (define Rules) it will show an error to write
that entry again.
2. Employee have to submit again after re-entering the entry.
Special None.
requirements:
Priority: High
29
Use cases Uc-15 Assign equipment place
Post conditions: After login to the system employee select option assign equipment place
fills all the requirement and click on the save button.
Basic Flows: 1. On the main page Employee find the option of login.
3. On this interface employee find the button assign equipment
place.
Alternative Flows
If equipment will put on wrong place it will show an error.
Special None.
requirements:
Priority: Medium
30
Use cases Uc-16 Collect sample
Post conditions: After login to the system employee select option collect sample fills all
3. On this interface employee find the button collect sample
Alternative Flows If equipment will put on wrong place it will show an error.
Special None.
requirements:
Priority: Medium
31
Use cases Uc-17 Enter report result
Post conditions:
After login the website select the option of report results fill it and save.
3. On this interface employee find the button report results.
4. Fills the results of report and click on save button.
Alternative Flows
If reports results are invalid then it will display error.
Special None.
requirements:
Priority: High
32
Use cases Uc-18 Create bill list
Post conditions:
Type the basic entries of bill list and click on the create button, system
verify the information and save the information in database.
Basic Flows:
1. Type Email Id and password to login to the system.
2. It show the option to create bill list here.
3. Employee fills all the entries box mention there.
4. After filling all the entries click on the button create.
5. System verify the data.
Alternative Flows
1. If user didn’t fill all the basic requirement it shows error.
2. If any entry is invalid like(date) system will show error.
Special None.
requirements:
Priority: High
33
Use cases Uc-19 check report bill list
Post conditions:
After login the website employee select option report bill list by click
this option employee can check the report bill list.
Basic Flows: 1. On website the main page display the option login.
3. On this interface employee press the option report bill list.
4. By click this option employee can check the option report bill list.
Alternative Flows
If there is no any report bill list it will show error message.
Special None.
requirements:
Priority: Medium
34
Level: Administration goal
Primary Actor: Administration
Post conditions: 1. Admin type the user name and password and click on the login
button to login in the system.
Basic Flows:
1. Admin type the address of the web site.
2. After loading the web site user can view different lab tests.
3. On the main page Admin can find the option of login as admin.
4. By clicking on the login as admin link it shows a login form.
5. If Admin is already signup on the website admin can type Email
id and password and click on the login button and logged in the
system.
Alternative Flows
1. If admin type wrong Email id or password it will show error to
type user name and password again to logged in the system.
Special
requirements: 1. Admin user name and password is initially set in data-base admin
can edit is after login.
Priority: High
35
Use cases Uc-21 Add new employee
preconditions: The admin must be login on the website.
Post conditions:
After login to the system admin select option add new employee fills all
Basic Flows:
1. On website main page admin can find the option of log-in.
2. After log in the system admin interface display.
3. On interface admin can view the button to add new employee.
4. After clicking on the option a form display.
5. Admin fills all the requirements and click on save button.
6. If requirements are valid it will display employee info will be
save.
Alternative Flows
1. If there is any Invalid requirement system will show an error to
write it again.
Special None.
requirements:
Priority: High
36
Use cases Uc-22 Assign test to employee
Post conditions:
After login to the system admin select option assign test to employee
fills all the requirement and click on the save button.
Basic Flows:
1. On website main page admin can find the option of login.
2. After login the system admin interface display.
3. On interface admin can view the button to assign test to
employee
4. Admin assign the test to employee according to their skills.
6. If requirements are valid it will display employee info will be
save.
Alternative Flows
1. If there is any Invalid requirement system will show an error to
write it again.
Special None.
requirements:
Priority: High
37
Use cases Uc-23 Add new test
Post conditions:
After login to the system admin select option add new test fills all the
requirement and click on the save button.
Basic Flows:
1. On website main page admin can find the option of log-in.
2. After log in the system admin interface display.
3. On interface admin can view the button to add new test.
7. After clicking on the option a form display.
9. If requirements are valid it will display test info will be save.
Alternative Flows If there is any Invalid requirement system will show an error to write it
again.
Special None.
requirements:
Priority: Medium
38
Use cases Uc-24 check employee report weekly
Post conditions:
After login the website admin select option employee report.
Basic Flows:
5. On website the main page display the option login.
7. On this interface employee press the option employee report.
1. By click this option admin can check the employee report weekly.
Alternative Flows  If there is no any report it will display error.
Special None.
requirements:
Priority: Low
39
3.2 Sequence Diagram
UML sequence diagrams model the flow of logic within your system in a visual manner, enabling you
both to document and validate your logic, and are com-monly used for both analysis and design
purposes.
The sequence diagrams of each module of online job recruitment system are following.
3.2.1 Patient
Figure 3.1 Patient sequence Diagram
Figure (3.1) shows over all sequence of Patient module Patient can login on online job recruitment
system. After successful login Patient access to the Patient interface here user can search Report history
and can get information related to his/her search. Patient can edit their profile and can also Download
reports And can view lab test Packages and test list and can also comment and can also receive reply.
40
3.2.2 Employee
Figure 3.2 Employee sequence diagram
Figure (3.2) shows over all sequence of Employee module Employee can login on Clinical laboratory
information system. After login Employee can access Employee module functionality. Here Employee
can upload the reports. Reports results store in the database .Employee can update reports and can
enter the reports result and can assign the room to the patient and can create the test bill list and can
also view the bill record. Employee can manage the equipments add the equipments. Equipments result
store in data base. Employee can update the equipment. All patients reports data store in data base.
41
3.2.3 Administrator
Figure 3.3 sequence diagram of Administrator
Figure (3.3) shows sequence of Administrator module. Admin first login on the system after login Admin
person can Add new tests on the website. Admin can view patients reports and can also view employee
work report weekly or monthly. Admin can also add new Employee and can assign type to employee and
can also assign test to employee. These are the main functionality and sequence of admin that shows in
Admin sequence diagram.
42
3.3 Database
Database diagram of clinical laboratory information system is following.
43
3.4 ERD
ER diagram of clinical laboratory information system is following
Phone Address
Admin
Email
Manage
Name
Control
Name
Type
Employee Test Code no.
Conduct
Conduct
Manage
Name
Place
Has Equipment
Sample
Code no.
Submit Patient
Conduct
Conduct
test
Email Phone Name
Address
44
In ER Diagram we focus on three main things
 Entity
 Attributes
 Relationship
Entities:
Entities are main functions of the projects that are need to be stored in database. In Clinical laboratory
information system the main entities are
 Administrator
 Employee
 Patient
 Test
 Equipment
 Sample
Regarding all these Entities data need to be stored.
Attributes:
Different Entities have different attributes. Attributes are different type of information need to be stored
regarding any attributes
Employee:
Employee can perform certain tasks on the website the attributes of the Employee are.
 Name
 Email
 Phone
 Address
 Type
Patient:
Patient can perform certain tasks on the website the attributes of the patient are.
 Name
 Email
 Phone
 Address
Test:
45
Employee conduct Different tests and test list show at user interface on website. The attributes of test
are
 Name
 Code
Sample:
Employee collect sample according to test. The attributes of sample are
 Name
 Code
Equipment:
Employee manage the all equipments. The attributes of equipment are.
 Name
 Code no.
 Place
Relationship:
All the entities have relationship among each other.

If we look Employee then employee can conduct tests and collect sample and conduct patient test and
manage all equipments ,so employee have relationship with.
 Test
 Patient
 Equipment
 Sample
If we look patient then patient can Submit samples and ,so patient have relationship with.
 Sample
 Employee
 Test
Admin can manage Employee. Admin can also control the test so admin have relationship with following
entities
 Test
 Employee
ER diagram shows all these entities attributes of those entities and the relationship among these
entities.
46
4 Main Interface
The user interface is one of the most important parts of any program because it
determines how easily you can make the program do what you want. The user
interface of online clinical laboratory information system is not only online
easy to use but also attractive to the users .the main page of clinical laboratory
information system is following.
Figure 4.1
Figure (4.1)
47
Figure (4.1) is the main page of online job clinical laboratory information system at the front view
user can see the test types there is the options of services, About us, contact us and also most
important Login option will be display. At the bottom of the page different registered organization are
displayed.
Figure 4.2
Laboratory Test
Figure 4.2
Login Employee 4.3

Employee Module 4.3.1
Visitor must also read term and condition of the website before submit information by
clicking on the submit it mean visitor agree with term and condition of the website.
Components of Interface
In online clinical laboratory information system there are different types of
component like
1) Employee
2) Patient
3) Administrator
48
4.3.1 Employee Module
Figure (4.3)
In employee module employee can perform different functionality line visit his/her profile register
patient, view patient , Assign test time, view test time, view pat request and Logout.
4.3.1.1 Patient Register
Figure (4.4)
49
If visitor is not registered already he/she must be registered first on the website
before performing his/her desired tasks.
Figure (4.4) shows registered form for patient. Visitor must fill all the field
before submit patient must fill all the necessary information before submit.
4.3.1.2 View Patient
Figure (4.5)
In figure (4.5) employee can search the patient click on submit see the patient name, father name,
address, password, DOB, gender, CNIC, and employee can update and delete.
4.3.1.3 Assign Time Test
50
Figure (4.6)
In figure(4.6) assign the time test by employee to patient and employee can delete and update.
4.4 Patient Module
Figure (4.7)
In figure (4.7) patient module patient can see the functionality of view report, request test and view
test.
4.4.1.1 View Report
51
Figure (4.8)
In figure (4.8) patient can download the test result in pdf formate file.
4.4.1.2 Request test
Figure (4.9)
Figure (4.9) show that patient can select the option of request test after requesting
Figure (4.9) interface show then user select the test then test charges selected by
default and click Submit.
52
4.5 Administrator
Figure (4.10)
Figure (4.10) shows admin interface admin can perform different function like
view employee, Add employee, Add employee type, view employee type, Lab
attendant Report, view test, Add test, Add test, view test type, Assign test,
View Assign test and view patient record.
53
5 Testing
Generally, it has been specified thought for testing that:
“Testing is the critical element of any software quality assurance and represents
the ultimate review of specification, design and code generation.”
Software testing has a dual function; it is used to establish the presence of
defects in program and it is used to help judge whether or not the program is
usable in practice. Thus software testing is used for validation and verification,
which ensure that software conforms to its specification and meets the need of
the software customer.
Developer resorted Alpha testing, which usually comes in after the basic design
of the program has been completed. The project scientist will look over the
program and give suggestions and ideas to improve or to correct the design.
They also report and give after a program has been created.
5.1 The Testing Process

Developer tests the software process activity such as design, implementation
and the requirement engineering. Because, design errors are very costly to repair
when the system has been started to operate. Therefore, it is quite obvious to
repair them at early stage of the system. So, analysis is the most important
process of any project.
5.1.1 Testing Schedule

Developer has tested each procedure back to back so that errors and omissions
can be found as earliest as possible. Once the system has been developed by
fully developer tested it on other machines, which differs in configuration.
5.2 Testing Methods
Software testing involves executing an implementation of the software which

tests data and examining the outputs of the software and its operational
behavior to check that it is performing as required.
5.2.1 Statistical Testing

Statistical testing is used to test the program’s performance and reliability and
to check how it works under operational conditions. Tests are designed to
reflect the actual user inputs and their frequency.
The stages involved in the static analysis for online job recruitment system are
follows:
Control Flow Analysis

o Unreachable code
o Unconditional branches into loops
Data Use analysis
o Variable used before initialization
o Variables declared but never used
o Variables assigned twice but never used between assignment
o Declared variables
54
Interface Analysis
o Parameter type mismatches
o Parameter number mismatches
o Non-usage of the results of function
o Uncalled functions and procedures
Storage Management Faults
o Data not stored in proper tables
o Data cannot be fetched from proper table
5.2.2 Defect Testing

Defect testing is intended to find inconsistencies between a program and its
specifications. The goal of defect testing is to discover defects in program.
These inconsistencies are usually due to the program faults or defects.
5.3 UNIT Testing

The Developer carries out unit testing in order to check if the particular module
or unit of code is working fine. The unit testing comes at the very basic level as
it is carried out as and when the unit of the code is developed or a particular
functionality is built.
In this application we test one most important module as task allocation which
is as follows:
5.3.1 LOOP Testing

Tester has tested the some condition in a code of application. So they test the
looping in source code of application for finding miss route or any error or
wrong direction of flow in code.
5.3.2 BLACK-BOX Testing

In black box testing or functional testing, the developer is concerned about the
output of the module and software, i.e. whether the software gives proper output
as per the requirements or not. In another words, these testing aims to test a
program behavior against specification without making any reference to the
internal structure of the program or the algorithms used. Therefore, the source
code is not needed, and so even purchased modules can be tested. The program
just gets a certain input and its functionality is examined by observing the
output.
This can be done in the following way:
 Input Interface
 Processing
 Output Interface
The tested program gets certain inputs. Then the program does its job and
generates a certain output, which is collected by a second interface. This result
is then compared to the excepted output, which has been determined before the
test. The system provide correct output regarding to the input.
An example of black box testing on online job recruitment system
55
Input interface
user type user name and password and click on the login button
Processing
System check whether the authorized or not. System try to match user name and
password in database.
Output Interface
if user is authorized system logged in user like
if user name or password mismatch then shows message of user name or

password is mismatch.
56
5.3.3 WHITEBOX Testing
It is also called ‘GLASS BOX’ or ‘STRUCTURAL’ testing. Tester has examine
following things.
 View source code

 Individual path examine
 Logical path examine one time
 Logical decision on their true and false
White-box testing is used as an important primary testing approach. Here, code
is inspected to see what it does. Tests are designed to exercise the code. Code is
tested using code scripts drivers etc. which are employee to directly interfaced
with and drive the code.
The tester can analyze the code and used the knowledge about the structure of a
component to derive the test data.
Advantages of White box testing:-
 As the knowledge of internal coding structure is prerequisite,
it becomes very easy to find out which type of input / data can
help in testing the application effectively.
 The other advantage of white box testing is that it helps in
optimizing the code.
 It helps in removing the extra lines of code, which can bring
in hidden defects.
In this system the tester analyze the code to perform white box testing.
5.3.4 Structure Testing

Developer has done his path testing to exercise every independent execution
path through a component or program. If every independent path is executed
then all statements in the components must have been executed at least once.
57
The structure of our program is also cheeked.
5.4 Integration Testing

After our individual modules Developer tested out Developer go to the
integrated to create a complete system. This integration process involves
building the system for problems that arise from component interactions.
Developer has applied top-down strategy to validate high-level components of a
system before design and implementations have been completed. Because, our
development process started with high-level components and Developer worked
down the component hierarchy.
5.5 Performance Testing

Performance testing is designed to test the runtime performance of the system
within the context of the system. These tests Developer performed as module
level as developer as system level. Individual modules developers tested for
required performance.
5.6 Condition Testing

Condition testing is a test case design method that exercises the logical
conditions contained in a program module. If the condition is incorrect, then as
least one part of the condition is incorrect. It may include:
 Input Output Connection Exceptions
 Arithmetic expression error
 Image unloaded errors
 User name error
 Already registered error
 User already applied error
 Empty field error
5.7 Interface Testing

Interface testing is integral part of integration testing. Therefore, developer
checked for the following.
 Interface misuse
 Interface misunderstanding
o All the menu functions and sub menu functions have

been checked.
o Validations for all inputs are done.
o All required fields are not left blank.
o No broken links exists in interface.
o Interface is easy to use
The interface of clinical laboratory information system is easy to use for user as main
purpose of clinical laboratory information system is provide knowledge about Lab tests so
there are several types of Lab tests are available on the website. There is no
complexity in user interface that leads user toward misunderstanding. Coloring
scheme used in system is attractive to users and methods of searching jobs,
project and applied on them is very easy.
58
5.8 Test Cases
Test User inputs processing Desired Actual

Object Outputs Outputs
User Employee/ Write a Check user Successful Successfully
name Patient user name name is allocate user executed as
available or name desired
not output
Login Employee/ Enter login Check user successfully Successfully
verify Patient name and name and login executed as
password password desired
are output
registered
and status
is active
Get test Patient Fill form Upload Send Send
time test and Successfully. Successfully.
saved
path in
Empty Employee/ Null value Check filed Error shows Error shows
value on Patient is empty successfully successfully
input /admin then not
form allowed to
submit
Create Patient Fill all Saved data Create Successfully
profile fields in database profile executed as
successfully desired
date Employee/ Select date Check last Date select Successfully
Patient form date must successfully executed as
calendar not be desired
behind output
current
Search Employee/ Search Fetch data Show result Successfully
test Patient title regarding data executed as
results /admin to the desired
search title output
and field
Apply Patient Click on Check user Successfully Successfully
for Lab apply is login or applied for executed as
test button not also job desired
check must output
not already
59
applied for
job
Update Employee/ Edit record Show record saved Successfully
record Patient previous successfully executed as
data user desired
can modify output
it and saved
data
60
61

Thesis (CLIS)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Thesis (CLIS)

Uploaded by

Copyright:

Available Formats

COMSATS Institute of Information Technology, Vehari

The Department of Computer Science (CS)

Keywords: HTML, PHP, CSS3.

PHP Hypertext Pre processor

HTML Hyper Text Mark-up Language

CSS Cascading Style Sheets

Specimen Samples (e.g, Blood, urine)

Employee Lab Workers

DFD Data flow diagram

ERD Entity relationship diagram

1.1 Present System

1.2 Present System components

The main components of existing LIS system as follow:

1.3 Flow Diagram of Existing System

Figure 1.2 Flow Diagram of Existing System

2.1 System Overview

Clinical Laboratory Information system is based on the following basic modules.

Administrator can perform different functions like.

 Assign employee type

2.2 System Flow Diagrams

2.2.1 Flow Chart

Administrator Type Employee

Not valid Enter

Website Website Management

Store data Activity

Show information Login

Upload reports Validation

Clinical Laboratory Information system is based on the following basic modules.

3.1 Use cases

There are three primary actors of the system

Add new Employee

Assign test to employee

Add new test

Check emp reports

Check reports history

View test list

View lab package

Check user report

Enter report results

3.1.2 Use case Discription

Use cases Uc-1 Login

Primary Actor: Patient

preconditions: The user must be already signup on the web site.

Level: User goal

Primary Actor: Patient

preconditions: User must login to the system.

Use cases Uc-3 download reports

Primary Actor: Patient

preconditions: The user must be login on the website.

Use cases Uc-4 check report history

Level: User goal

Primary Actor: Patient

Use cases Uc-5 view test list

Level: User goal

Primary Actor: Patient

Use cases Uc-6 view lab package

Level: User goal

Primary Actor: Patient

Level: User goal

Primary Actor: Patient

preconditions: The user must be already login on the web site.

Use cases Uc-8 Login

Primary Actor: Employee