A MAIN PROJECT INITIAL REPORT ON

Online Laboratory System with Visual

Authentication Protocol
IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE
AWARD OF THE DEGREE IN

BACHELOR OF COMPUTER APPLICATIONS

OF

MAHATMA GANDHI UNIVERSITY

KERALA

Submitted by

Najiya Nazrin P.N.

170021096215

DEPARTMENT OF COMPUTER APPLICATIONS

(2017-2020)

M.E.S COLLEGE MARAMPALLY

ALUVA -7
 M E S COLLEGE, MARAMPALLY

ALUVA-7

DEPARTMENT OF COMPUTER APPLICATIONS

Certificate

This is to certify that the report entitled

Online Laboratory System with Visual Authentication Protocol

Has been submitted by

Najiya Nazrin P.N.

In partial fulfillment of the award of the degree in

BACHELOR OF COMPUTER APPLICATIONS

OF

MAHATMA GANDHI UNIVERSITY

During the academic year 2019-2020

Register No: 170021096215

Project Guide Head of the Department

Submitted for the examination held on ………………………………………...
Examiners
1.
2.
 MES COLLEGE MARAMPALLY

MARAMPALLY, ALUVA-7
DEPARTMENT OF COMPUTER APPLICATIONS

PROFORMA FOR APPROVAL OF B.C.A. PROJECT REPORT (2019-2020)

1. Roll Number : 170021096215

2. Name of the Student : Najiya Nazrin P.N

3. Title of the Project : Online Laboratory System with Visual

Authentication Protocol
4. Name and address of the firm : Riss Technologies, IInd Floor, Manjali
Building, Amman Kovil Cross Road, YMCA
Junction, Ernakulam, Kerala – 682 035
Phone number : 0484 4034445

Name of the Guide : Sreejesh

(Firm/ Organization)

5. Software used in the Project : Windows

6. Date of submission : 06-01-2020

Signature of the Student Signature of the Guide

(Firm/Organization)

Signature of staff in charge

Suggestions for reformulating the Project if any:

Signature of the internal guide with date

 ACKNOWLEDGEMENT

Firstly, I am very thankful to our almighty for making me to complete this project. I sincerely
express my thanks and gratitude to our principal Dr. A. Biju Sir, MES College, Marampally and
head of the department Dr. Murugan R Sir for their kind and support. I would like to take this
opportunity to express my sincere gratitude towards my guide Mr. Joseph Deril, Assistant
Professor, Department of Computer Applications, for his invaluable guidance during the
progress from beginning to the completion of the project. I’m wholeheartedly thankful for
giving his valuable time and attention and for proving a systematic way for completing the
project in time. I thank him for the timely suggestions and constant encouragement that
boosted up my morale and led to the accomplishment of this project. Last, but not least I
express my heartfelt thanks to my parents, my friends, my well-wishers, and each and every
one who helped me from the starting till the completion of this project.

NAJIYA NAZRIN PN
 Table of Contents

1. Introduction
1.1. Overview of the system
1.2. Problem definition and objective
2. Requirement and Analysis
2.1. Problem definition
2.2. Select the software development model
2.3. Requirement specification includes existing system and
proposed system
2.4. Project Planning
2.5. Project Scheduling
2.6. Feasibility Study
3. Software Requirement Specification (SRS)
3.1. Introduction
3.1.1 Purpose
3.1.2 Scope
3.1.3 Definitons, acronyms, and abbreviations
3.1.4 References
3.1.5 Overview
3.2. Overall description
3.2.1. Product perspective
3.2.2. Product functions
3.2.3. User characteristics
3.2.4. Constraints
3.2.5. Assumptions and dependencies
3.3. Specific requirements
3.3.1. External interfaces
3.3.2. Functional requirements
3.3.3. Performance requirements
3.3.4. Logical database requirements
3.3.5. Design constraints
3.3.6. Software system attributes
3.3.7. Organizing the specific requirements
4. Software and hardware requirement
5. System Design
5.1. Introduction
5.2. Input design
5.3. Output design
5.4. Number of modules and their description
5.5. Functional diagram
5.6. Database design
5.7. E R Diagram
5.8. Data Flow Diagram
6. Future Scope of the Project
1. INTRODUCTION
1.1 Overview of the system

The main aim of the project entitled Online Laboratory System with Visual
Authentication Protocol is to develop a website that facilitates the user with an on-
click functionality which is useful to find patient’s lab report. User can get lab report
at any time through this website. The aim of this application is to reduce the manual
effort and time needed to travel and collect the report of a test from laboratory and
this application will be helpful for the administrator also for the maintenance of the
patient’s history.

This application can be used in a laboratory to book a test for the customer, enter
customer’s details and after conducting the test, give test reports to the customer, and
provides efficient management of lab records. Using this system based application
provide a dynamic record keeping and data processing with other advantages for
entire pathology and for end users. The concepts and design of the Online Laboratory
System is to ensure that it can meet the demanding requirements that ideal software
should have to manage today’s busy pathology laboratories.

This project has two visual authentication protocols: one is a one-time-password

protocol, and the other is a password-based authentication protocol. This approach to
solve the problem introduces an intermediate device that bridges a human user and a
terminal. Then, instead of the user directly invoking the regular authentication
protocol, they can invoke a more sophisticated but user-friendly protocol via the
intermediate helping device. For the implementation of this key logger approach uses
a session password authentication scheme. Session passwords can be used only once
and every time a new password is generated. Two techniques are used to generate
session passwords. One of these two use text and the other use colors. These two
methods are resistant to shoulder surfing. So here, the use of user driven
visualization is provided to improve security and user-friendliness of authentication
of various users.
1.2 Problem definition and objective

Problem definition

The problem here is to develop an application which completely automates the

today’s medical laboratory system.

The problem arises when the system gives inaccurate or invalid data. This problem is
faced because of following reasons:

• There are lots of transactions made every day and there is always a chance of
inaccurate data entry.
• A queue for a long time for test registration, collecting his/her receipt, test
report, test bill and/or any other information (There is a big problem of
capacity as a large number of tasks are done every day. A Patient has to wait
in).
• Patient reports cannot be stored forever (It is very difficult to find the test
report of a patient report who has visited the Lab after a long time).

Objective

The current system uses a manual system for the management and maintenance of
critical information. It requires numerous paper forms, with data stores spread
throughout the medical laboratory management infrastructure. Often information (on
forms) is incomplete, or doesn’t follow management standards. Forms are often lost
and require auditing process to ensure that no vital information is lost. Also since
there exists the problem of shoulder surfing, a highly authenticated system is needed.

A significant part of operation of any medical laboratory involves acquisition,

management and timely retrieval of great volume of information. This information
typically involves patient’s personal information and medical history, staff
information, etc,.. All of this must be managed in an efficient and cost fashion so that
resources may be effectively utilized more efficient and error free. It aims at
standardizing data, consolidating data ensuring data integrity and reducing
inconsistencies.

Different users of this system are patient, administrator and lab technicians.
2. REQUIREMENT ANALYSIS
2.1 Problem Definition

Every system consists of several problems. The existing laboratory management

system can be reconstructed in order to overcome the problems faced by the existing
system. The reconstructed new system will have better user interface, making it
easier for users to interact with the system. Existing system is manual in nature. The
necessary details are stored in printed sheets. Existing system is inefficient since all
the data manipulations are carried out manually. This consumes considerable amount
of time and lots of paperwork needed. Also there are chances for error to occur.
Manual work causes considerable delay. So in order to increase the efficiency, manual
system must be computerized.

2.2 Select the Software Development Model

I select the waterfall model for my project as the system development tool.

Waterfall model is the classical model of software development. It was the first
process model to be introduced. It is also referred to as a linear sequential lifecycle
model. It is very simple to understand and use. In waterfall model, each model should
be completed fully before the next phase can begin. In this model the output of one
phase become the input for next phase. This type of model is basically used for a
project which is small and there are no uncertain requirements. In this model, testing
starts only after the development is completed. In waterfall model phases do not
overlap. This model is absolute way for correcting problems and implementing
proposed system.

The sequential phases in waterfall model are:

1. Requirement Gathering and analysis: All possible requirements of the system to

be developed like processing speed, data security, acquiring more functions etc,.. are
captured in this phase and then documented in a requirement specification document.

2. System Design: The requirement specifications from first phase are studied in this
phase and system design is prepared. System Design helps in specifying hardware and
system requirements and also helps in defining overall system architecture.

3. Implementation: With inputs from system design, the system is divides as units
named modules which are integrated in the next phase. Each unit is developed and
tested for its functionality which is referred to as Unit Testing.

4. Integration and Testing: All the units developed in the implementation phase are
integrated into a system after testing of each unit. Post integration the entire system
is tested for any faults and failures.

5. Deployment of system: Once the functional and non-functional testing is done, the
software is deployed in the user environment or released it.

6. Maintenance: There are some issues which come up in the user environment. To
fix those issues patches are released. Also, to enhance the product some better
versions are released. Maintenance is done to deliver these changes in the user
environment.
2.3 Requirement Specification Includes Existing System and
Proposed System

Existing System

The existing system is less user-friendly. It is a large manpower process and is

difficult to implement it different platform. The current requires numerous paper
forms, with data stores spread throughout the laboratory management infrastructure.
Often information is incomplete, or doesn’t follow management standards. Forms are
often lost in transit. Multiple copies of same information exist in the laboratory and
may lead to inconsistencies in various data stores. Even though some laboratories
have been digitalized, all modes of payment aren’t available. The user interface of the
system is also poor and main problems faced by these system are eves dropping,
dictionary attack, social engineering and shoulder surfing.

The problems faced by the existing system are described as below:

• Bad user interface

• Time consuming
• Editing of data becomes a tedious job
• Patients must wait for long time to get the test result etc,..

Proposed System

The present system has limitations. It can be reconstructed in order to overcome the
problems faced by the existing system. The Online Laboratory System with Visual
Authentication Protocol is designed for any medical laboratory to replace their
existing manual, paper based system. The new system is to control information such
as patient information, test results, staff and patient invoices etc,.. and also highly
authenticated using Visual Authentication Protocol to avoid shoulder surfing. The
services are to be provided in efficient and cost effective manner, with the goal of
reducing the time and resources currently required for such tasks.
2.4 Project Planning

The approximate time and date planning is as follows:-

TASK START DATE DURATION END DATE

Logic design 12-DEC-2019 2 days 14-DEC-2019

System selection 14-DEC-2019 2 days 16-DEC-2019

System study 16-DEC-2019 10 days 26-DEC-2019

Initial report 26-DEC-2019 10 days 05-JAN-2020

Form design 05-JAN-2020 20 days 25-JAN-2020

Coding and SQL 25-JAN-2020 37 days 29-FEB-2020

Testing 01-MARCH-2020 5 days 05-MARCH-2020

Documentation 05-MARCH-2020 10 days 15-MARCH-2020

2.5 Project Scheduling

Once we have estimates of the effort and time requirement for the different phases, a
schedule for the project can be prepared. Conceptually simple and effective
scheduling techniques like calendar oriented charts are prepared. Progress can be
represented easily by ticking off each milestone when completed. Alternatively, for
each activity another bar can be drawn specifying when the activity actually started
and ended, i.e., when these two milestones were achieved. Once we have estimates of
the effort and time requirement for the different phases, a schedule for the project can
be prepared.

TASK December January February March

Requirement
gathering
System
analysis

System design

Form design

Coding

Testing

Build
2.6 Feasibility Study

Feasibility study is made to see if the project on completion will serve the purpose of
the organization for the amount of work, time and effort spent on it. Study lets the
developer foresee the future of the project and its usefulness. Finding out whether a
new system is required or not. The study is carried out to the best system that meet
performance requirement. This entails identification, description and evaluation of
candidate system and selection of the best system for the laboratory. It simply
identifies whether the proposed system is feasible to the organization or not.

These are three aspects in the feasibility study portion of the preliminary
investigation:

• Economic feasibility
• Technical feasibility
• Operational feasibility
Economic Feasibility
Here an evaluation of development cost weighted against the ultimate income or
benefit derived from the developed system. The cost for the development of the
project has been evaluated and we want to check that the cost does not exceed
beneficial cost of the laboratory system. The economic and financial analysis is used
for evaluating the effectiveness of the laboratory system. This project also undergone
economic feasibility study and found that it is feasible. So, the cost for the
development does not exceed its beneficial cost. This bought to the conclusion that
the system is economically feasible in the context such that it reduces the processing
time and the work load.
Technical Feasibility
The system must be evaluated from technical view point first. The assessment of this
feasibility must be based on outline design of the system requirement in the terms of
input, output, programs and procedure having identified and outline system, the
investigation must go on to suggest the type of equipment, required method of
developing the system, method of running the system once it has been designed. The
project should be developed such that the necessary functions and performance are
achieved within the constraints. The project is developed with the latest technology
programming language (Python) and also prevents shoulder surfing since visual
authentication protocol is used. There are only minimal constraints involved in this
project.
Operational Feasibility
In operational feasibility, the entire application is checked whether the system will be
used if it is developed and implemented. Also it is checked whether there will be
resistance from user that may undermine the possible application benefits. There is
no barrier for implementing the system. The system also helps to access the
information immediately as need arises. Thus, the system is found to be operationally
feasible.
3. SOFTWARE REQUIREMENT SPECIFICATION (SRS)
3.1 Introduction

The Software Requirements Specification is produced at the culmination of the

analysis task. SRS is a document that completely describes what the proposed
software should do without describing how the software will do it. The basic
limitation for this is that the user need keeps changing as environment in which the
system changes with time. This leads to a request for requirement changes even after
the requirement phase is done and the SRS is produced.

The function and performance allocated to software as part of System Engineering are
refined by:

• Establishing a complete information description of the System.

• A detailed functional description.
• A representation of System behaviour.
• An indication of performance requirements and design constraints.
• Appropriate validation criteria
• Other information pertinent to requirements.

3.1.1 Purpose

The document contains the functional, behavioral and non-functional requirements of

the project and it also contains the guidelines for the system engineers and designers
to start working the project. The Online Laboratory System with Visual
Authentication Protocol governs the functions such as:

• Maintaining the patient details

• Providing prescriptions, precautions and diet advice
• Providing and maintaining all kinds of tests for patient
• Maintaining payment
• Avoid shoulder surfing
• Test report generation, etc,..
3.1.2 Scope

This project can be used in any Medical Laboratories for maintaining patient details
and their test results. This project can be worked as both admin and user interface.
We can ass new information and when we require making reusability, it is possible as
there is flexibility in all the modules. The language used for developing this project is
Python which is very efficient.

3.1.3 Definitions, Acronyms, and Abbreviations

Administrator – The person who has control and access to the entire system as well as
the database.

User – One for whom the application is developed for and has limited access to the
system and database. Here users are patient and lab technician.

3.1.4 References

a) K. K. Aggarwal, Yogesh Singh – Software Engineering, 3 rd edition, New Age

International Publications.

b) Marvin Gore and John Stubble – Elements of System Analysis, 4th edition, Galgotia
Book Source.

c) Pankaj Jalote - An Integrated approach to Software Engineering, Second Edition,

Narosa Publishing Company.

3.1.5 Overview

The document contains the detailed documentation of the requirements and functions
of ‘Online Laboratory System with Visual Authentication Protocol’ like product
function, functional requirements, constraints, dependencies, etc. The SRS is
organized as it discuss the product description first then the requirements of the
products, and the dependencies that will be faced by the system etc. The developer is
responsible for:

• Developing the system

• Running the application
• Maintaining the system
3.2 Overall Description

3.2.1 Product Perspective

The Online Laboratory System using Visual Authentication Protocol governs the
maintenance of patient’s information, storing test results, manage test booking, etc.
This project designs the working of a Medical Laboratory. The new system will be
more efficient and easy for managing and manipulating.

3.2.2 Product Functions

The product function can be represented using ER diagram. The main purpose of this
system is to reduce complexity of existing system. The new system is created as a
simple graphical interface to control the entire laboratory.

Major functions that the application will perform:

• Visitor requests
• Patient records
• Patient billing and test report generation
• Inventory management
• Staff records
• Staff attendance
• Stock management
• Password recovery, etc.

3.2.3 User Characteristics

Administrator

Administrator can manage all level users. He is the super user and main controller of
the system. He controls all the activities of the system. Admin is responsible for
managing tests, managing technicians, patients, viewing test status, viewing
payments, viewing enquiry and sending replies.
Lab Technician

Technician is a registered user and has much less privileges when compared to
administrator. He can login to portal using his username and password with the help
of visual authentication. He is responsible for viewing patients, managing tests
booking, viewing payments, update status, upload results, etc,.

Patients

Patients are also registered users and have much less privileges than lab technician.
Patient can request for registration. Patients are responsible for viewing tests and
costs, booking tests, making payments, viewing booked test status, view and
download result, send enquiry and view reply.

3.2.4 Constraints

• If there is no internet connection, it affects the system.

• Correct username and password must be provided for login.
• Users must aware of entering correct data to the database.
• The system must be user friendly.

3.2.5 Assumptions and Dependencies

The assumptions are:

• The coding should be error free.

• The system should be user friendly so that the user can easily access data.
• The system should have more storage capacity and provide fast access to
database.
• The system should save money and time unlike the existing system.
• The user must provide correct user name and password to enter to the system.

The dependencies are:

• The specific hardware and software due to which the product will run.
• On the basis of listing requirements and specification, the system will be
developed and run.
• Updates are to be made correctly and data entered without any mistakes.
3.3 Specific Requirements

This section provides software requirements to a level of details sufficient to enable

designers to design the system and testers to test the system.

3.3.1 External Interfaces

GUI

The software provides good graphical interface for the user and the administrator can
operate on the system performing the required task such as test management, test
booking management, result updation, user registration, etc. The user interface must
be customizable by the administrator. All the modules provided with the software
must fit into this graphical user interface and accomplish to the standard defined. The
design should be simple and all the different interfaces should follow a standard
template.

Login

It asks the user to type his username and password. If the user enters incorrect
username or password, error message occurs. After login visual authentication is
done and hence corresponding user can enter into their panel.

Administrator Control Panel

This control panel will allow administrator to manage users, test status, payments,
enquiry, etc.

Technician Control Panel

This control panel will allow Lab Technicians to view patients, manage tests booking,
view payments, update status, upload test results, etc.

Patient Panel

Patient can register into the system. Registered Patient can view tests and costs, book
tests, make payments, view booked test status, view and download result, send
enquiry, view reply, etc.
Hardware Interfaces

The recommended configuration (basic requirements of a computer system), smart

phone having registered phone number and no other specific hardware is required to
run the software.

Software Interfaces

It is platform independent, any device with an active internet connection and web
browser can run this.

3.3.2 Functional Requirements

• Provide facility to patients test enquiry

• Provide facility for technicians and patients to create their login id
• Options to download test results and making payments
• Provide simple and attractive interface
• Ensure security for database
• The system should be able to handle high volume of data

3.3.3 Performance Requirements

• The performance of the system should be fast and accurate.

• Response of the system to an operation should be within reasonable time.
• The system should be able to handle large amount of data.
• The system should be capable for updating the data frequently.
The proposed system that we are going to develop will be used as chief performance
system. Therefore, it is expected that the database would perform functionally all the
requirements that are specified by the laboratory.

3.3.4 Logical Database Requirements

• The system should have installed WAMP/LAMP/XAMP server.

• Create different tables for login details, test details, technician details, patient
details, result details, payment details, enquiry details,etc.
• Insert valid data to created tables.
3.3.5 Design Constraints

The program is designed for every platform. Before accepting the system the
developer will have to show through the test cases that all conditions are satisfied.
The total time that will be taken for the completion of the product is expected to be
about four months. The program is designed for and will operate under Windows OS.
The design is reliable with any environment. The system may have to be maintained if
the system needs an outline with upcoming generations.

3.3.6 Software System Attributes

• Reliability
The application should not have any reliability issues. The software will be
thoroughly tested and any issues resolved.

• Availability
The application will execute as a standalone system so as long as the machine
is running, the program will be available. The key to maintaining availability
will be by ensuring a connection to the database server is available. Failure to
connect to the database will make data unavailable.

• Security
This application is intended to communicate over an internal network;
therefore security is of little concern. The user will have to enter the username
and password so the program can connect to the database server. The
username and password will not be stored because encryption of such
information is outside the scope of the project.

• Maintainability
The application will be composed of various modules decreasing the
complexity of expansion.

• Portability
The application will be platform independent.
3.3.7 Organizing the Specific Requirements

In this system the overall functionality is organized by Data flow diagrams and ER
diagrams. Based on these diagrams, data relationships and dependencies are found
and a functional hierarchy is made for organizing the specific requirements.
4. SOFTWARE AND HARDWARE REQUIREMENT
Software Requirements

To develop the application software, we use different types of software. The software
for the development has been selected based on several factors such as Support and
stability, cost effectiveness, development speed ,etc..

The minimal softwares used for storage are:

• Front-end Development: Python, HTML, CSS, JavaScript.

• IDE: Sublime text 3.
• Server: Apache server.
• Back-end: Mysql.

Hardware Requirements

The hardware requirements for developing and implementing for proposed system
are:

• Processor: Intel Core i3.

• RAM: 2GB.
5. SYSTEM DESIGN
5.1 Introduction

The most creative and challenging phase of the system life cycle is system design. The
term design describes a final system and the process by which it is developed. It
refers to the technical specifications that will be applied in implementing the
candidate system.

The first step is to determine how the output is to be produced and in what format.
Samples for the output (and input) are also presented.

The second step is input data and master files (data base) have to be designed to meet
the requirements of the proposed output. The operational (processing) phases are
handled through program construction and testing including a list of the programs
needed to meet the system’s objective and complete documentation. Finally, details
related to justification of the system on the user and the organization are documented
and evaluated by management as a step toward implementation. To design the
system we must note the following points:

• To identify the Software Components which satisfy the System Design.

• To design and document the Software Components and their linkage.

In this component the software components and relevant interfaces such as,
interactions with existing internal and external systems, network connections,
standard input and output formats are to be identified.

After completing the requirement study and documentation, it is time to design the
software based on the requirements. It is easy to start coding without any design and
we may end up developing a product which our customers like. But it may not be easy
to maintain. Customers may keep changing their mind. Only after seeing the product,
they may say 'we want this to behave in a different way', and it is very hard to say 'NO'
to a customer. First step is identifying all the features that we are going to implement
in the software. The requirements document is a good guide in identifying the
features.
According to the requirements specification, we need to develop the following
features in the system.

• Visitor Feedback and Appointments

• Registration of Patients
• Patient Information Management
• Patient Tests and Bill Details
• Search for Patients Information
• Staff Information System
• Stock Information System
• Inventory Management System
5.2 Input Design

Input design, user oriented data are converted to a computer based format. It is the
link between user and the information system. The input design involves determining
what the inputs are, how the data should be performed, how to validate data, how to
minimize data entry and how to provide a multiuser facility.

The main objectives of the input design are:

1. Produce cost effective method of input

2. Achieve highest possible level of accuracy

3. Ensure that the input is acceptable to and understood by user.

The goal of designing input data is to make entry easy, logical and free from errors as
possible. The entering users like faculty need to know the allocated space for each
field; field sequence and which must match with that in the source document.
5.3 Output Design

Efficient, intelligible output design improves the system relationship with the user
and help in decision making. Allowing the user to review sample screen is important
because the user is the ultimate judge of the quality of the output. Computer output is
the most important and direct information source to the user. Output design is a
process that involves designing necessary outputs in the form of reports that should
be given to the users according to the requirements. Since the reports are directing
referred by the management for taking decisions and to draw conclusions they must
be designed with extreme care and the details in the reports must be simple,
descriptive and clear to the user.

Username Password User type

admin admin Admin
Raju Raju01 Technician
Seetha seeth@01 Patient
Riya riya@1 Technician
Baby Baby01 Patient

Patient Blood House

Phone Email Place Pincode
name Group name
Arun 9899799008 arun@gmail.com A- Illickal(H) Kochi 682 022
Aparna 8767673838 appu@gmail.com B+ Vazhad(H) Goa 702020
Blessy 7038373838 bless@gmail.com O+ Alappat(H) Kannur 650222
Gopika 8037372828 gops@gmail.com AB- Pattal(H) Thrissur 656473
Jency 9873638292 jen@gmail.com O+ Theli(H) Pala 683102

Technician name Phone Email Qualification

Pranay 9876543210 manu@gmail.com DMLT
Raghav 8765432190 ragh@gmail.com BMLT
Anu 7890654321 anu@gmail.com MLT
5.4 Number of Modules and their Description

The system comprises of basically three modules named:

1. Administrator module
2. Faculty module
3. Student module
Administrator Module:
• Login and logout
• Change password and forgot password
• Manage tests
• Manage technicians
• View patients
• View test status
• View payments
• View enquiry
• Send reply
Techicians
• Login and logout
• View patients
• Manage tests booking View payments
• Update status
• Upload status
• Upload results
Patient
• Register
• Login and logout
• View tests and costs
• Book tests
• Make payment
• View booked tests status
• View and download result
• Send and view enquiry
5.5 Functional Diagram
5.6 Database Design

Login

log_id Int Primary key

username varchar Not null
password varchar Not null
type varchar Not null

Tests

test_id Int Primary key

test_name varchar Not null
description varchar Not null
Amount decimal Not null

Technicians

tech_id Int Primary key

log_id Int Foreign key (Login)
first_name varchar Not null
last _name varchar Not null
Phone Varchar Not null
Email Varchar Not null
Qualification Varchar Not null
Patients

patient_id Int Primary key

log_id Int Foreign key (Login)
first_name Varchar Not null
last _name Varchar Not null
Phone Varchar Not null
email Varchar Not null
Bloodgroup Varchar Not null
house_name Varchar Not null
Place Varchar Not null
Pincode Varchar Not null

BookingMaster

bm_id Int Primary key

patient_id Int Foreign key (Patients)
Datetime timestamp Not null
total_amount decimal Not null
Status Varchar Not null

BookingChild

bc_id Int Primary key

Foreign key
bm_id Int
(BookingMaster)
test_id Int Foreign key (Test)
Amount Decimal Not null
Status Varchar Not null
Result

result_id Int Primary key

Foreign key
bc_id Int
(BookingChild)
description_note Varchar Not null
file_path Varchar Not null
tech_id Varchar Not null
Datetime Timestamp Not null

Payment

pay_id Int Primary key

patient_id int Foreign key (Patients)
Amount Varchar Not null
booking_id Varchar Not null
Datetime timestamp Not null

Enquiry

enq_id Int Primary key

patient_id Int Foreign key (Patient)
Description Varchar Not null
reply Varchar Not null
Datetime Varchar Not null
Email Timestamp Not null
5.7 E R Diagram
5.8 Data Flow Diagram

Level 0 DFD

Fig 0: Level 0 DFD for Online Laboratory System with Visual Authentication Protocol

Level 1 DFD
6. FUTURE SCOPE OF THE PROJECT
Pathology is always an important part of our lives and the healthcare industry.
Pathologists have their own importance for clinicians to diagnose illnesses and
diseases like cancer, monitor status of improvement, and manage treatments.
Pathology is going digital over the years and it has great potential to transform this
traditional practice. Pathologists use digital pathways to deliver services and
information.

In future, this system can be used for:

• Analyze and extract data to figure out the connections between treatments and
tests and to enhance results.
• Technicians to get the complete insight into patient’s care and health status.
• Technicians can access previous records and data from various sources
instantly.
• People can easily manage their health by accessing electronic records.
• Optimized delivery structure without geographical limitations and boundaries.
• Technicians can interact with patients smoothly.
• There will be no shoulder surfing since the system uses visual authentication
protocol. So the system is highly secure.