0% found this document useful (0 votes)
32 views25 pages

Electronic Health Record System

report on the software of electronic health record system

Uploaded by

gamingbuddy24
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
32 views25 pages

Electronic Health Record System

report on the software of electronic health record system

Uploaded by

gamingbuddy24
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 25

Page |1

Bhaskaracharya College of
Applied Sciences

Software Engineering Project

Topic: Electronic Health Record System

Group members:
B. Venkata Sai Teja (2102013)
Rohit Kumar (2102052)
Sourav (2102061)
Sumit Bharti (2102063)
Page |2

Problem Statement
The Electronic Health Record (EHR) is a digital version of a patient's medical history that is
maintained by healthcare providers, including doctors, administrators, and receptionists. It
includes information about the patient's health conditions, medical history, medications,
allergies, and test results. The EHR system aims to improve the quality and safety of patient
care, increase efficiency, and reduce healthcare cost.

However, implementing and using an EHR system can pose challenges for different
stakeholders, including doctors, administrators, patients, and receptionists.

For doctors, one challenge is adapting to the new system and learning how to use it efficiently.
They may also need to spend more time entering data into the EHR, which can take away
from time spent with patients. Another challenge is ensuring the accuracy and completeness of
the information entered into the EHR.

Administrators may face challenges in selecting and implementing an EHR system that meets
the needs of their organization and integrating it with other systems. They may also need to
ensure the security and privacy of patient data and comply with regulatory requirements.

Patients may have concerns about the confidentiality of their medical information and may
need assistance in accessing and understanding the information in their EHR.

Receptionists may need to be trained on how to use the EHR system and handle patient data,
including scheduling appointments and managing patient records.

Roles and Responsibilities:


Doctor:

 Responsible for entering patient information and medical history into the system
 Able to view and update patient records, including lab results, prescriptions, and
appointments
 Responsible for maintaining the confidentiality of patient information
 Should provide accurate and up-to-date information to ensure proper treatment and
care of patients

Admin:

 Responsible for creating and managing user accounts for doctors, receptionists, and
patients
 Should be able to set access levels for each user, based on their roles and
responsibilities
 Responsible for maintaining the system and ensuring its security and stability
 Should provide technical support to users as needed

Receptionist:

 Responsible for scheduling patient appointments and updating patient information


Page |3

 Should be able to verify patient insurance information and collect payments


 Should maintain accurate and up-to-date records of patient appointments and
activities

Patient:

 Able to access their own medical records and update personal information
 Responsible for providing accurate and up-to-date information about their medical
history and current condition
 Should follow the treatment plan prescribed by the doctor and attend scheduled
appointments
 Should maintain the confidentiality of their own medical information

Overall, the EHR system can improve patient care, but it also requires careful consideration
and management to ensure its effectiveness and protect the privacy and security of patient
data.

Therefore, there is a pressing need for an Electronic Health Record (EHR) system that can
provide a unified and secure platform for the storage, management, and exchange of patient
data among healthcare providers. This system should have the ability to integrate with other
healthcare systems and should be designed to ensure patient privacy and security.

Process Model
There are various process models that can be used for the development and implementation
of an electronic health record (EHR) system, but we decided to use an iterative and
incremental development process. The reason we chose this model is to enable us to show the
customer, iteratively, a system that can demonstrate some new functionality in action early in
the development process without having to develop the whole system. As a result, we get
feedback from the customer early and the customer gets the opportunity to evaluate if their
requirements are being met early. The general iteration process in the iterative and
incremental development process looks as follows:

When applying the spiral model to EHR (Electronic Health Record) development, the following
phases can be identified:
Page |4

1. Discussion with the customer to gather new or additional requirement specifications.

2. Study the specification for realism, consistency and completeness. Requirements that do not
meet these criteria are further discussed with the customer.

3. Design how to best implement the specifications. Here data structures, interface
representations and algorithmic details are designed.

4. Implement the design. This includes writing (or improving) source code, creating the
database (data and data structures) and testing.

5. Function testing is performed to ensure that the system(new added functionalities) is working
correctly and efficiently

6. The final step is to demonstrate the result to the customer for feedback. The work was
divided into smaller iteration cycles and reported as various demos during the last step of
every iteration phase. The project was intended to have the following iteration cycles:

1. An initial graphical user interface.

2. A more refined GUI and login functionality that goes all the way to a database
were developed.

3. The rest of the functionality (except converting medical records to pdf) were
implemented e.g., creatin g and deleting (inactivating) a patient or user, adding
records to a patient, giving different rights to a user etc.

Requirement Analysis
1. Use case diagram:
Page |5

2. Use Cases:
1.) Manage Personal Record
1.1Brief Description

This use case describes how a user login into the Electronic Health Record System for
editing his/her personal details.

1.2Actors

The following actor(s) interact and participate in this use case: User Patient.

1.3Flow of Events

(i)Basic Flow

This use case starts when the actor wishes to edit his/her personal data.

The actor should log (i.e., User ID, password and role) onto the System to edit
his/her personal data.

After logging into the system, she/he should click “profile” option. Next to select edit
personal data.

After editing his/her personal data, actor should click on “update” option.

Then your updated personal data will be saved in EHR system.

1.4Pre-Conditions

All users must have an account created for them in EHR System, prior to executing the
use cases.

1.5Post-Conditions

If the use case was successful, the actor’s personal data will be edited successfully. If
not, the System state was unchanged.

2.) Login
2.1Brief Description

This use case describes how a user logs into the Electronic Health Record (EHR)System.

2.2Actors

The following actor(s) interact and participate in this use case: User-Patient and User-
Medical officer.

2.3Flow of Events

(i)Basic Flow
Page |6

This use case stars when the actor wishes to Login to the EHR System.

The system requests the actor for his/her Username, password and role for Login.

The actor enters his/her name, password and role.

The System validates the entered name, password, role and logs the actor into the
System.

After logged into EHR System he/she can use EHR facility.

2.4Pre-Conditions

All users must have a User-Account (i.e. User ID, password and role) created for them
in EHR System, prior to executing the use cases.

2.5Post-Conditions

If the use case was successful, the actor is logged into the System. If not, the System
state was unchanged.

If the actor has the role ‘User-Patient’ he/she access to only screens corresponding to
View Personal data, View Medical record, Edit Personal Data etc.

If the actor has the role ‘User-Medical Officer’ he/she access to screens
corresponding to Insert Medical Record, Refine Medical Record, View Medical Record
etc.

3.) View Medical Record


3.1Brief Description

This use case describes how a user should view his/her Medical Record in the EHR
System.

3.2Actors

The following actor(s) interact and participate in this use case: User Patient and User
Medical Officer.

3.3Flow of Events

(i)Basic Flow

This use case stars when the actor wishes to view his/her Medical Record in the EHR
System.

After logged onto the system you can select “Medical Record” option to view the
record.

 The saved Medical Record will be viewed by Medical Officer to know about the
health of patient.
Page |7

Also, patient can view his/her health record to know about the health. If patient
having any health issue, he/she can book an appointment to meet doctor.

3.4Pre-Conditions

All users must be logged onto the EHR System, prior to executing the use cases.

3.5Post-Conditions

If the use case was successful, then actor knows about the health, which was saved in
EHR System. Otherwise, the system was unchanged.

4.) Insert Medical Record


4.1Brief Description

This use case describes how a Medical Officer will Insert the Medical Record of a
patient into the EHR System.

4.2Actors

The following actor can interact and participate in this use case: User Medical Officer.

4.3Flow of Events

(i)Basic flow

This use case starts when the actor wishes to insert the Medical Record of a patient into
the EHR System.

During login process you should select the role of Medical Officer for inserting an
medical record of a patient.

These options are only available for Medical Officer, he/she should select “Insert
Medical Record” option.

The actor should enter the patient’s name and need to upload the health document
of that particular patient.

After uploading actor should proceed with “save” option.

The process until we did is for the user’s, who are using it for the first time.

If he/she is already a member, then their record will be updated.

4.4Pre-Conditions

The user must have been logged into the EHR System to insert his/her Medical Record,
prior to executing the use cases.

4.5Post-Conditions
Page |8

If the use case was successful, then actor was successfully inserted Medical Record of a
patient into the system. Otherwise, the system was unchanged.

5.) Make Appointment


5.1Brief Description

The use case "Making Appointment" involves the process of creating appointments for
patients in the Electronic Health Record (EHR) system.

5.2Actors

The following actor can interact and participate in this use case: User Medical Officer,
Patient.

5.3Flow of Events

(i)Basic flow

 The healthcare provider selects the option to create a new appointment.

 The EHR system prompts the healthcare provider to enter the patient's name, date
of birth, contact information, reason for the appointment, and preferred date and
time.

 The healthcare provider enters the required information.

 The EHR system checks the healthcare provider's schedule to verify the availability
of the preferred date and time.

 If the preferred date and time are available, the EHR system schedules the
appointment and displays a confirmation message to the healthcare provider. If the
preferred date and time are not available, the EHR system prompts the healthcare
provider to select a different date and time.

5.4Pre-Conditions

The healthcare provider is logged in to the EHR system. The patient is present in the
healthcare facility or contacts the healthcare provider via phone or email.

5.5Post-Conditions

If the use case was successful, then appointment was successfully updated in the
medical record of a patient in the system. Otherwise, the system was unchanged.

3. Sequence Diagram: The sequence diagram illustrates a basic patient-provider


interaction with an EHR system, including record updating, and sharing through the
patient portal.
Page |9

Fig 1. Sequence diagram to login or register

Fig 2. Sequence diagram to view medical details of employee/patient


P a g e | 10

Fig 3. Sequence diagram to make an appointment


4. Dataflow Diagram:
a) DF diagram level 0 (Context Diagram):

b) DF diagram level 1:
P a g e | 11

5. Data Dictionary:
Login [Username + Password]
Username [Alphabet]
Password [Alphabet + Digit + Special Character]
Patient ID [Digit]
Patient name [Alphabet]
Sex [Alphabet]
Date of Birth [YYYY-MM-DD]
Blood Group [Alphabet + Special Character]
Contact Number [Digit]
Alternate Contact Number [Digit]
Email [Alphabet + Digit + Special Character]
Consulting Team/Doctor [Alphabet]
Address [Alphabet + Digit + Special Character]
Doctor ID [Digit]
Appointment Time [HH:MM:SS]
P a g e | 12

Appointment Date [YYYY-MM-DD]


Appointment No [Digit]
Description [Alphabet + Digit]
Room Type [Digit]
Room Number [Digit]
Date Admitted [YYYY-MM-DD]
Date Discharged [YYYY-MM-DD]
Employee ID [Digit]
Salary [Digit]
Employee Name [Alphabet]
Age [Digit]
Employee Designation [Alphabet]
Salary [Digit]
Experience [Digit]
Treatment [Alphabet]
Treatment Code [Digit]
Treatment Cost [Digit]
Medicine [Alphabet]
Medicine Quantity [Digit]
Medicine Price [Digit]

Software Requirement Specification


1. Introduction
An Electronic Health Record (EHR) system is a digital record-keeping system that
captures, stores, and manages patient health information. It is a comprehensive and
secure electronic repository that contains a patient's medical history, diagnoses,
medications, allergies, lab results, imaging reports, and other critical health
information. EHRs can be accessed by authorized healthcare providers, making it
possible to share patient data in a timely and secure manner, thus facilitating continuity
of care.

EHR systems have been designed to replace paper-based medical records and offer a
number of benefits over traditional record-keeping methods. EHRs provide a more
accurate, complete, and up-to-date view of a patient's health status, which can lead to
improved clinical decision-making, and better patient outcomes. EHRs also improve the
efficiency of healthcare delivery by eliminating redundant or unnecessary tests and
procedures, reducing the time spent on administrative tasks, and improving care
coordination among different healthcare providers.

Moreover, EHR systems offer a secure and confidential platform for managing patient
information, providing granular access controls, and audit trails to ensure patient
privacy and data security. EHRs also provide robust analytics and reporting
capabilities, enabling healthcare providers to track and analyze population health
data, identify trends, and implement targeted interventions to improve health
outcomes.
P a g e | 13

In summary, EHR systems offer a transformative approach to healthcare delivery,


providing a secure and efficient way to store, manage, and exchange patient health
information. The adoption of EHRs can help healthcare providers deliver high-quality
care, reduce healthcare costs, and improve patient outcomes.

2. Purpose
The purpose of an Electronic Health Record (EHR) system is to improve the quality,
safety, and efficiency of healthcare delivery by providing a comprehensive, accurate,
and up-to-date record of a patient's health information.

3. Scope
 Patient management, including the ability to create, view, edit, and delete
patient records
 Health information management, including the ability to add, view, edit, and
delete health information for a patient
 Appointment and scheduling, including the ability to schedule appointments for
a patient, view upcoming appointments, and cancel or reschedule appointments
as needed
 Reporting, including the ability to generate reports on patient records and
health information
 Security, including encryption of sensitive data, access control based on user
roles and permissions, and logging of user activities for auditing purposes.
4. Functional Requirements
4.1 User Authentication and Access Control

 The system shall provide a login screen for users to enter their username and
password.
 The system shall verify the user's credentials and grant access to the
appropriate features based on their role and permissions.
 The system shall allow the administrator to create, view, edit, and delete user
accounts with specific roles and permissions.

4.2 Patient Management

 The system shall allow the user to create a new patient record by entering their
personal information, such as name, date of birth, gender, and contact
information.
 The system shall prevent duplicate patient records from being created.
 The system shall allow the user to view, edit, and delete patient records as
needed.
 The system shall allow the user to search for patient records by name, date of
birth, or other relevant criteria.
P a g e | 14

4.3 Health Information Management

 The system shall allow the user to add, view, edit, and delete health
information for a patient, such as medical history, allergies, medications, and
test results.
 The system shall validate the input of health information, such as ensuring the
correct data type is entered.
 The system shall provide appropriate error messages when invalid data is
entered.
 The system shall display health information in a clear and concise manner.

4.4 Appointment and Scheduling

 The system shall allow the user to schedule an appointment for a patient,
including selecting the provider, date, and time.
 The system shall prevent scheduling conflicts for the same patient or provider.
 The system shall send appointment reminders to patients and providers as
needed.
 The system shall allow the user to view upcoming appointments and cancel or
reschedule appointments as needed.

4.5 Reporting

 The system shall allow the user to generate reports on patient records and
health information, such as patient demographics, medical history, and lab
results.
 The system shall generate reports that are accurate and up-to-date.
 The system shall allow the user to filter and sort reports as needed.
 The system shall allow the user to export reports in various file formats.

4.6 Security

 The system shall encrypt sensitive data, such as patient records and health
information.
 The system shall enforce access control policies based on user roles and
permissions.
 The system shall log all user activities for auditing purposes.
 The system shall protect against common security vulnerabilities, such as SQL
injection and cross-site scripting (XSS) attacks.
5. Non-functional Requirements
5.1 Performance:
 The system shall be able to handle a large number of patient records and
health information.
 The system shall provide a responsive and smooth user experience, with
minimal lag or delays when performing tasks.
P a g e | 15

 The system shall be able to generate reports quickly and efficiently, even for
large datasets.
5.2 Reliability:
 The system shall be available and accessible to authorized users at all times,
with minimal downtime or interruptions.
 The system shall be able to recover quickly from errors or failures, with minimal
data loss or corruption.
 The system shall be able to detect and prevent data inconsistencies or errors,
such as duplicate patient records or conflicting health information.
5.3 Security:
 The system shall protect sensitive data, such as patient records and health
information, from unauthorized access or disclosure.
 The system shall use encryption to secure data both in transit and at rest.
 The system shall enforce access control policies based on user roles and
permissions, and prevent unauthorized access to sensitive data.
 The system shall maintain an audit trail of user activities and security events, to
enable tracking and investigation of security incidents.
5.4 Usability:
 The system shall be intuitive and easy to use, with a user-friendly interface and
clear navigation.
 The system shall provide appropriate feedback to users, such as error
messages and confirmation dialogs.
 The system shall provide help and documentation for users who need
assistance, such as a user manual or online help system.
 The system shall be accessible to users with disabilities, such as support for
screen readers or alternative input devices.
5.5 Scalability:
 The system shall be able to accommodate future growth and expansion, such as
an increasing number of patients or providers.
 The system shall be able to handle additional features or modules as needed,
such as integration with third-party applications or services.
 The system shall be able to run on a variety of hardware and software
configurations, to enable flexibility and portability.
6. Software Quality Attributes
a) AVAILABILITY: The system shall be available all the time.
b) CORRECTNESS: Bug-free software which fulfils the correct requirements
of the client.
c) MAINTAINABILITY: The ability to maintain, modify information and fix
problems of the system
d) USABILITY: software can be used again and again without distortion.
e) ACCESSIBILITY: Administrator and many other users can access the
system but the access level is controlled for each user according to them
work scope.
f) ACCURACY: The reliability on the information/output. Can depend-on/be
P a g e | 16

sure, of the outcome.

Project Management
1. Timeline Charts

2. Computing FP
Calculation of Function Point:
Function Point (FP) is an element of software development which helps to approximate
the cost of development early in the process. It may measure functionality from user’s
point of view.
1. Does the system require reliable backup and recovery? (3)
2. Is data communication required? (1)
3. Are there distributed processing functions? (1)
4. Is performance critical? (3)
5. Will the system run in an existing heavily utilized operational environment? (3)
6. Does the system require on line data entry? (3)
7. Does the on-line data entry require the input transaction to be built over multiple
screens or operations? (3)
8. Are the master files updated on line? (4)
9. Is the inputs, outputs, files, or inquiries complex? (4)
10. Is the internal processing complex? (3)
11. Is the code designed to be reusable? (3)
12. Are conversion and installation included in the design? (2)
13. Is the system designed for multiple installations in different organizations? (3)
P a g e | 17

14. Is the application designed to facilitate change and ease of use by the user? (4)
Counting Function Point (FP):
Step-1: F = 14 * scale
Scale varies from 0 to 5 according to character of Complexity Adjustment Factor
(CAF). Below table shows scale:
0 - No Influence
1 - Incidental
2 - Moderate
3 - Average
4 - Significant
5 - Essential
Step-2: Calculate Complexity Adjustment Factor (CAF).
CAF = 0.65 + (0.01 * F)
ΣFi = 3 + 1 + 1 + 3 + 3 + 3 + 3 + 4 + 4 + 3 + 3 + 2 + 3 + 4
= 40
CAF = 0.65 + (0.01 * 40)
CAF = 0.65 + (0.4)
CAF = 0.69
Step-3: Calculate Unadjusted Function Point (UFP).

By, considering average weighting factor;


Totals (UFP) = 176 + 20 + 64 + 50 + 63 = 373
Step-4: Calculate Function Point.
FP = UFP * CAF
FP = UFP * CAF = 373 * 0.69
FP = 257.37
3. Effort
Effort = FP / 6.5 [PM]
Effort = 257.37 / 6.5
Effort = 39.59538
Effort = 40 person-month
4. Cost
Assuming the cost is 5,000/- pm
Cost = Cost per person-month * Effort
Cost = 5,000 * 40
P a g e | 18

Cost = 2,00,000/-
5. Risk Table
A risk is a probable problem, it might happen or it might not. There is main two
characteristics of risk
Uncertainty the risk may or may not happen that means there are no 100% risks.
Loss  If the risk occurs in reality, undesirable result or losses will occur.

Risk management is a sequence of steps that help a software team to understand,


analyse and manage uncertainty.

Design Engineering
1. Architectural Design
The Electronic Health Record System can be designed using a three-tier architecture,
which consists of the following layers:

Presentation layer (frontend): This layer is responsible for presenting the user
interface to the end-user. In this project, Python Tkinter can be used to design
the user interface.
P a g e | 19

Application layer (backend): This layer contains the application logic and is
responsible for processing user requests, executing business logic, and
interacting with the database. In this project, Python can be used to implement
the application logic, and SQLite can be used as the database.
Data layer (backend): This layer is responsible for managing data storage
and retrieval. In this project, SQLite can be used as the database management
system.

2. Pseudocode of a small module

1. Define a class called MainWindow


2. Define the init method for the MainWindow class:
a. Set the instance variable master to the argument passed to the method
b. Set the title, size, and background color of the window
c. Create a frame and pack it into the window
d. Create two StringVar objects for the username and password fields
P a g e | 20

e. Create a label with the title of the GUI and pack it into the frame
f. Create two frames for the login and password fields and pack them into the
frame
g. Create labels and entry fields for the username and password fields
h. Create buttons for login and exit
3. Define a method called Login_system
a. Retrieve the values of the username and password fields
b. Check if the values are valid and if so, create a new window for the main menu
c. If the values are invalid, display an error message asking the user to retry or
cancel
4. Define a method called Exit that destroys the window
5. Define a method called new_window that creates a new window for the main menu,
but this method is not used in the code provided
6. Run the application by creating an instance of the MainWindow class

Coding
login.py
from tkinter import *

import tkinter.messagebox

from tkinter import ttk

from tkinter import font

from menu import Menu

#MAIN WINDOW FOR LOG IN

class MainWindow:

def __init__(self,master):

self.master = master

self.master.title("HOSPITAL MANAGEMENT SYSTEM")

self.master.geometry("800x500+0+0")

self.master.config(bg="powder blue")

self.frame = Frame(self.master,bg="powder blue")

self.frame.pack()

self.Username = StringVar()

self.Password = StringVar()
P a g e | 21

self.lblTitle = Label(self.frame,text = "HOSPITAL MANAGEMENT SYSTEM",


font="Helvetica 20 bold",bg="powder blue",fg="black")

self.lblTitle.grid(row =0 ,column = 0,columnspan=2,pady=40)

#======================

self.LoginFrame1 = Frame(self.frame,width=400,height=80,relief="ridge",bg="cadet
blue",bd=20)

self.LoginFrame1.grid(row=1,column=0)

self.LoginFrame2 = Frame(self.frame,width=400,height=80,relief="ridge",bg="cadet
blue",bd=20)

self.LoginFrame2.grid(row=2,column=0)

#======LABEL AND ENTRY=========

self.lblUsername = Label(self.LoginFrame1,text="Username",font="Helvetica 14
bold",bg="cadet blue",bd=22)

self.lblUsername.grid(row=0,column=0)

self.lblUsername = Entry(self.LoginFrame1,font="Helvetica 14 bold",textvariable=


self.Username,bd=2)

self.lblUsername.grid(row=0,column=1)

self.lblPassword = Label(self.LoginFrame1,text="Password ",font="Helvetica 14


bold",bg="cadet blue",bd=22)

self.lblPassword .grid(row=1,column=0)

self.lblPassword = Entry(self.LoginFrame1,font="Helvetica 14
bold",show="*",textvariable= self.Password,bd=2)

self.lblPassword .grid(row=1,column=1)

#===========BUTTONS====

self.btnLogin = Button(self.LoginFrame2,text = "Login" ,font="Helvetica 10 bold", width


=10 ,bg="powder blue",command = self.Login_system)

self.btnLogin.grid(row=3,column=0)

self.btnExit = Button(self.LoginFrame2,text = "Exit" ,font="Helvetica 10 bold", width =10


,bg="powder blue",command = self.Exit)

self.btnExit.grid(row=3,column=1)
P a g e | 22

def Login_system(self):

S1=(self.Username.get())

S2=(self.Password.get())

if(S1=='admin' and S2=='1234'):

self.newWindow = Toplevel(self.master)

self.app = Menu(self.newWindow)

elif(S1=='root' and S2=='4321'):

self.newWindow = Toplevel(self.master)

self.app = Menu(self.newWindow)

else:

tkinter.messagebox.askretrycancel("HOSPITAL MANAGEMENT SYSTEM" , "PLEASE


ENTER VALID USERNAME AND PASSWORD")

def Exit(self):

self.master.destroy()

def new_window(self):

self.newWindow = Toplevel(self.master)

self.app = self.Menu(self.newWindow)

def main():

root = Tk()

app= MainWindow(root)

root.mainloop()

if __name__ == "__main__":

main()

Testing
P a g e | 23

1. Cyclomatic Complexity
Given module:
def Login_system(self):

1 S1=(self.Username.get())
2 S2=(self.Password.get())
3 if(S1=='admin' and S2=='1234'):
4 self.newWindow = Toplevel(self.master)
5 self.app = Menu(self.newWindow)
6 elif(S1=='doctor' and S2=='4321'):
7 self.newWindow = Toplevel(self.master)
8 self.app = Menu(self.newWindow)
9 elif(S1=='receptionist' and S2=='6789'):
10 self.newWindow = Toplevel(self.master)
11 self.app = Menu(self.newWindow)
12 elif(S1=='Pharmacist' and S2=='9876'):
13 self.newWindow = Toplevel(self.master)
14 self.app = Menu(self.newWindow)
15 else:
16 tkinter.messagebox.askretrycancel( "PLEASE ENTER VALID USERNAME AND
PASSWORD")
17 return
18 observer_label.config(text="Login Successful !!!")

Basis Path:

Cyclomatic Complexity:
P a g e | 24

The cyclomatic complexity of code is a software metric that indicates the complexity of
a program by measuring the number of independent paths through the program's
source code. The formula for calculating the cyclomatic complexity is:

M=E-N+2

Where,
M is the cyclomatic complexity
E is the number of edges in the control flow graph
N is the number of nodes in the control flow graph
In the given code, there are 5 conditions that are checked based on the input values of
S1 and S2. Therefore, the control flow graph for this code will have 5 nodes and 5
edges. Applying the above formula, we get:

M=E-N+2
M=5-5+2
M=2

Therefore, the cyclomatic complexity of the above code is 2.

2. Test Cases
Test Case Description Input Expected Output
user can successfully login with
1. Admin, 1234 Menu page for admin opens
correct credentials
shows an error message when the
2. Admin, 4567 Login failed
user enters incorrect credentials
The menu shown here will be
enforces access control policies
3. Doctor, 9876 different than that shown to the
based on user roles and permissions
admin.
P001, Suresh Kumar, Male, 1973-04-29, B-, Upon clicking “SUBMIT” button.
allows the admin to create a new
4. +919988776655, NULL, NULL, Dr. Rakesh Jha, Record created in database
patient record
B-234 Rajpuri New Delhi 110034 message appears.
P001, Suresh Kumar, Male, 1973-04-29, B-, Upon clicking “SUBMIT” button.
system prevents duplicate patient
5. +919988776655, NULL, NULL, Dr. Rakesh Jha, Record already exists in database
records from being created
B-234 Rajpuri New Delhi 110034 message appears.
P001, Suresh Kumar, Male, 1973-04-29, B-, Upon clicking “UPDATE” button.
admin can edit patient records as
6. +919988776655, NULL, [email protected], Record updated in database
needed
Dr. Md. Siraj, B-234 Rajpuri New Delhi 110034 message appears.
Upon clicking “DELETE” button.
user can delete a patient record if
7. P001 Record deleted from database
necessary
message appears.
Upon clicking “SAVE” button.
system allows the user to schedule P001, D003, A001, 14:00:00, 2023-04-23,
8. Appointment booked message
an appointment for a patient Headache and Vomiting
appears.
Upon clicking “SAVE” button.
system prevents scheduling conflicts P003, D003, A003, 14:00:00, 2023-04-23,
9. Appointment already exists
for the same patient or provider Stomach Ache
message appears.
Upon clicking “SEARCH” button.
system displays health information in
10. P003 All the record of the patient
a clear and concise manner
appears on the screen.
Upon clicking “CANCEL” button.
11. system allows the user to cancel A001 Appointment of the patient will be
cancelled.
Upon clicking “SAVE” button.
system allows the user to reschedule P001, D003, A001, 15:00:00, 2023-04-13,
12. Appointment updated message
appointment as needed Headache and Vomiting
appears.
P a g e | 25

You might also like