Electronic Health Record System
Electronic Health Record System
Bhaskaracharya College of
Applied Sciences
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.
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:
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
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:
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.
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 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.
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.
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.
The process until we did is for the user’s, who are using it for the first time.
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.
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 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 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.
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
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
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.
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
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.
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
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).
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.
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.
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
class MainWindow:
def __init__(self,master):
self.master = master
self.master.geometry("800x500+0+0")
self.master.config(bg="powder blue")
self.frame.pack()
self.Username = StringVar()
self.Password = StringVar()
P a g e | 21
#======================
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)
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.grid(row=0,column=1)
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.grid(row=3,column=0)
self.btnExit.grid(row=3,column=1)
P a g e | 22
def Login_system(self):
S1=(self.Username.get())
S2=(self.Password.get())
self.newWindow = Toplevel(self.master)
self.app = Menu(self.newWindow)
self.newWindow = Toplevel(self.master)
self.app = Menu(self.newWindow)
else:
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
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