Electronic Medical Records

EMR

Software Requirements Specification

Version 2
November 2023

Prepared by
Electronic Medical Records

1. Introduction
The (SRS) provides an overview of the entire SRS with purpose, scope, definitions, acronyms,
abbreviations, references and overview of the SRS. The aim of this document is to gather and
analyze and give an in-depth insight of the complete Electronic Medical Records system by
defining the problem statement in detail.

i. Purpose
The purpose of the document is to
1. Collect and analyze all assorted ideas that have come up to define the system, its
requirements with respect to consumers.
2. Provide a detailed overview of our software product, its parameters and goals.
3. Describe the project's target audience and its user interface, hardware and software
requirements.
4. Defines how our client, team and audience see the product and its functionality.
5. Helps any designer and developer to assist in software development lifecycle (SDLC)
processes.

ii. Scope
The scope of this project is to develop a system that allows companies, organizations, or
individuals (called clients) manage users, patients, medications, locations, vendors, services and
contacts.
Mainly the system will include clients information along with all users registered under the
client, groups that is a collections of clients with the access to the same functions, and functions
that are system actions which are distributed to client groups and managed by super admin user

iii. Definitions, Acronyms, and Abbreviations

This subsection should provide the definitions of all terms, acronyms, and abbreviations required
to properly interpret the SRS. This information may be provided by reference to one or more
appendixes in the SRS or by reference to other documents.
- Client: A company, corporation, organization, or person to manage users, patients,
medications, locations, vendors, services and contacts.
- EMR: Electronic Medical Records
- Patient:
- A person receiving services from a client or client’s user.
- The patient is the focus of services for the client
- A client provides services through users and other means.
- User: An email address

Software Requirements Specification Page 1

Electronic Medical Records

iiii. Overview
- Section 2: General description and main functions of the project and user characteristics
and system users are also discussed.
- Section 3: Requirements
- Gives the functional requirements, data requirements and assumptions made while
designing the EMR.
- Gives the user viewpoint of the product.
- Gives the specific requirements of the product.
- Discusses the external interface requirements and gives detailed description of
functional requirements.
- Section 4: Analysis is for diagrams to support the development of the software.

2. General Description
i. Product Functions
The main function the system will perform is to help healthcare organizations, individuals, or
businesses (referred to as “clients”) manage and patient health and other information as a SaaS.

There are 2 types of functions

1. Basic User Functions: Common user actions such as update personal information, change
password, etc.
2. System Functions: Similar to role policies or permissions that are distributed, system
functions are entity-related functions such as add patient, edit patient, create user group,
etc.
a. These functions can assigned to client groups by super admin.
b. Once assigned to a client group, a user that is the client admin has the same
functions as the client group.
c. Functions are further managed by the client admin for distribution to users and
user groups.
Basic User Functions
1. Register
1. Three types of users would use this app: Super Admin, Client Admin, Client User.
2. Super Admin would be created by seeder.
3. Registration module is only for client users
4. Client Admin can signup using a standard registration form, providing email, password,
and basic info and select a client group.
5. Client user can also sign up using the same registration page by selecting, client group
group and client. Client user can also be added by another client user.
6. Both Client Admin and Client User can change their basic info, reset password, change
password, verify identity, and perform other registration features.

Software Requirements Specification Page 2

Electronic Medical Records

7. Registration includes basic fields; additional information provided in the database guide.
8. Formatting, auth configuration like verifying identity using one time code, max three tries
of verifying identity in 15 mins, captcha implementation on every new attempt and other
important features for auth.
Client user registration
1. Sign up as a New user
2. Sign up as an Existing user
3. Add a new user by an Existing user
4. Add an existing user by an Existing user

A Sign up as a New user

1. The system must allow a person to register as a client by directing him/her to register
page
2. The registration process contains 3 steps:
a. Enter Email: Email conditions mentioned below should be checked
b. One Time Code
i. The user can enter a new email address if the code was not received. If
Send Code Again is clicked, the previous screen should be loaded
(Entering Email Screen) so the user can enter a different email address
ii. The user has 3 tries to enter the code or 15 minutes to enter a code.
iii. Fail: An history entry is made on the SA user overview page. Save the IP
address for multiple sign in attempts. Redirect the user to the login page.
Show a toast message to contact support for assistance.
iv. Password: the information page is loaded.
c. Information page: This page is broken up into 3 parts:
i. User information: The top 3 fields should be saved to SA user overview
page (First name - last name - phone number)
ii. Client information: The middle radio buttons determine client group.All
the client groups that have been enabled by super admin for sign up must
be available.
iii. Password: Saved as the user's password that is used for login.
3. The user that creates the new client becomes the creator of the client and considered as a
client admin.
Email Conditions:
1. The field should be checked for proper formatting. The formatting should follow these
rules.
2. Errors should appear below the field in red text.
3. Continue button should remain inactive until a proper email address is entered.
4. After the continue button is clicked, the CAPTCHA should load. The CAPTCHA should
pass before sending any one time passcode.
5. On successful CAPTCHA, the one time code page is loaded. CAPTCHA is disabled on
the development URL for testing purposes.
End Process Results:
From user side:

Software Requirements Specification Page 3

Electronic Medical Records

1. The user will receive an email confirming the user on signing up

2. The user can log in and the dashboard will load.
3. The user can perform the functions
4. The user can access the functions page. This page shows the functions that are granted to
the client group.

From super admin side:

1. A new SA user overview page is created with a timeline history of the sign up process.
2. A new client overview page is created with a reference to the user.
3. The client overview page should show the user with the title "client admin".

B Sign up as an Existing user

1. This process describes a user that already exists in the system and will sign up again.
2. A user can sign up for one client group per email.
3. Register process for an existing user is as follow:
A. Enter Email: The email address should be checked to see if the user previously
signed up with the same email. As this process for existing users (email exists in
the database) the check result must be that the email exists. And email conditions
must be checked.
B. One Time Code: All the steps in 1) Sign up as a new user for one time code
should be repeated.
C. Information Page: This page is broken up into 3 parts:
I. User Information: The top 3 fields should be saved to the SA user
overview page (First name - last name - phone number). First name, last
name, contact information, profile pictures, etc... should be kept separately
and contained within each client.
II. Client Information: The middle radio buttons that represent client groups
should be available all for selection except the one that the user has signed
up with before and he is the creator of that client group.
III. Password: The set password part of the information page should be hidden
since the user already has a password set.
4. If the user signed up with the same email for all available client groups one by one and
there is only one option left for him/her or there are no client groups options left. Here is
the process that should be taken:
- When the page loads that has only one client group left to sign up a warning
message appears to warn the user that he has only one client group left to sign up
with this email.
- If the user signs up with the last client group option left and then tries to sign up
again a message appears that this email has signed up with all available client
groups and directs him/her to the login page.

End Process Results

Software Requirements Specification Page 4

Electronic Medical Records

From user side:

1. The user will receive an email confirming the user on signing up

2. User Can login and a selection page will load if the user is registered with 2 or more
active (status) clients. If the user is registered with 1 active client, the selection page is
skipped and the dashboard loads.
3. User can perform basic functions

From super admin side:

1. A timeline entry should be made on the users existing SA user overview page. a new
history entry should be made "Signed up. OTP sent to [email address]" and timestamped.

C Add a new user by an Existing user

1. This process describes a new user that is added by an existing user.

2. The existing user (already registered with a client) adds the new user by email. The "Add
new user" form should ask for email, first name, last name.
3. The new user is added to the client's users with a "Pending" status.
4. The new user receives an email with a link. The link should open a page called the "Set
password" page. Here the user should enter a password.
5. After successfully entering a password
a. The user should be redirected to the login page.
b. A toast message should inform the user that their password has been successfully
saved and they can log in.

D Add an existing user by an Existing user

1. This process describes the existing user (already registered with a client) adds another
existing user. The "Add new user" form should ask for email, first name, last name.
2. As the existing user completes the "Add new user" form, the user is added to the client's
users with a "Pending" status.
3. The new user receives an email with a link. The link should state "You have been added
as a user to [client name]", [link], "If you are unaware of this, you can ignore this email."
4. The user will not receive a link to set password as he/she already are registered in the
system.
5. The link should should
1. Change the user's pending status to active
2. Add a timeline entry on the SA user overview for the status change. The client
table should show the new status of active from pending.

2. Login
When a user logs in, the system should go through these checks in this order:

Software Requirements Specification Page 5

Electronic Medical Records

1. User enters email and password successfully. If login is unsuccessful after the 3rd
attempt, the user's account is inactivated
2. Check system status in SA user overview. Should be active. If inactive, contact support.
3. Client level checks
1. Check for active clients. A user can have associations with 1 or more clients. If all
clients have inactive status, contact support
2. Check the user status for the active clients.
3. If the user has 2 or more client associations with active status, the client selection
page should be presented.
4. If the user has an active user status with 1 active client, skip the client selection
page (Explained in the following C section) and continue to step 4.
4. Load dashboard

Failed Login Attempts

1. After the third failed attempt of logging in,

2. A toast message should notify the user that their account has been inactivated due failed
login attempts.
3. The user's system-status should be changed from active to inactive since all user accounts
are linked to a single login.
4. A timeline entry should be made on the SA user overview.
5. An email should be sent about the change in status from active to inactive. The link
6. should contain a link to a Set new password page. The password should not be the same
as previously used passwords.

3. Dashboard Selection
1. A selection screen will be presented to the user if a user is associated with 2 or more
active clients.
2. After login, a page loads with the clients he/her is associated with and the user will select
the client to log into. After the selection is made, the dashboard should load.

4. Modify User’s own Information

All users (system admin and client users) should be able to perform this function
1. The system must allow users to view their profile details
2. The system must allow users to update their information
a. Profile picture
b. Name
c. Gender
d. Email
e. Phone
f. Address
g. Password
If it’s client admin or Super Admin:

Software Requirements Specification Page 6

Electronic Medical Records

1. Status: can set to active, away

2. Phone 1. Can have up to 3 phone numbers with different labels
3. Phone 1 label
4. Email address
5. Home address: individual fields for street, unit , city, state, zip code
6. Gender
7. Languages: different fields for primary, secondary
8. Password: Separate process

5. Password

Reset Password from Profile Page

1. The system must allow the user to reset the password from the profile page by clicking on
password and requesting a change.
2. A link is sent to the user’s email. The user clicks the link then the user is allowed to
change his or her password.
3. The user must first enter the current password then 2 new fields for the new password,
then repeat the new password.

Reset Password from Login Page

1. From the login page the user clicks Forgot Password.

2. User is directed to the Email address page and enters his/her email, then one of two
situations is encountered:
a. Email exists in database: Page loads to check email address for link or one time
password
b. Email does not exist in the database: Page loads and informs user that the email
does not exist.

6. Logout and timeout

Users must be able to log out from their account.
Time out will automatically log the user off if there is no activity while logged in.

System Functions
General Overview
1. Basic Flow: Functions represent more like role policies or permissions that will be
assigned to client admin or client user in the following manner
a. Super Admin would assign functions to client group
b. Client group would be linked with 1 or more than one client admin
c. Client admin can further either assign functions to client users or create a user

Software Requirements Specification Page 7

Electronic Medical Records

group and assign to multiple client-users

d. Client admin and client users would view a tree of functions assigned to them
i. Client users can’t change anything except to report bug against any
function.
ii. Client admin can change user or user group access
e. Client admin and client users can also report a bug from any module as there will
be an option to each module screen to report a bug and it would auto linked to
corresponding functions.
2. Function Nature: Functions could be based on different activities such as CRUD (create,
read, update, delete). Few more that depend on the nature of function. Etc
3. Development Life Cycle: Function would also be used to track the development life cycle
of each function like which modules are in development phase, testing phase, active
which mean functions are fully tested and deployed.
4. Seeder:
a. All functions are created by seeders
b. Only a few fields like icons, status or descriptions could be modified by super
admin.
c. Default Status would be development and would proceed according to function
development flow.
d. Every function is auto linked with corresponding module like patients, client
users, contacts, forms, etc by seeders.
e. Seeders would create a default function key which would be hidden because
function-keys are hard coded and auto linked to different system modules and
module entities.
5. Function Detail Page: The function details page is accessed by the super admin user when
saving a new function, or by selecting a function from the functions page. The super
admin function details page contains:
a. Icon: This icon will be used throughout the system.
b. Name
c. Description
d. Status: Indicates the function stage. The status does not affect the action of the
function.
i. Development
ii. Testing
iii. Active
iv. Bug: A client user reported a bug. A report made by a client user should
trigger a change in status and the super admin user should be notified.
v. Hidden: This status hides the function on the main list. To unhide a
function, super admin can change the status to any other status than
hidden.
e. Timeline
i. Bugs reported, assigned to client groups, changes of status, etc.
ii. Activities will be tracked like when/what status is changed, when bugs
reported and fixed and when become active again. It would also log other

Software Requirements Specification Page 8

Electronic Medical Records

function activities like when assigned to which client-group.

iii. Any activity on a function such as updating status or granting the function
to a client group should be added to the timeline of the function in the
function details page.
f. Level: This indicates if the function is a main category function such as user,
patient, location, etc. or a sub-function.
g. Client Information: This is the information presented to the client
i. Name: The name of the function shown to the client.
ii. Media: Images and video about the function
iii. Accessibility: How the function is accessed.
iv. Report a bug:
1. If client admin or client user want to report any bug then that bug
would be marked to corresponding function which later be fixed
and admin would mark it fixed.
2. In case of any bug, there will be red icon appear next to function
label.
3. Once the bug is fixed, red icon would be removed.
6. There’s a list of functions on this page https://xntral.net/g4/emr/functions#top. I see some
functions like chat, set client user to admin, co field in patient function. Can you elaborate
these functions?
a. CO field: This allows the user to set a custom label for a patient. The field would
be used for sorting and filtering purposes
b. Chat: Allows users to chat with other client users. The idea was to build it out like
slack.
c. Set client user to admin:
i. This allows client admin the ability to grand another user a client admin.
ii. The user will have the same functions as the client group
iii. A client must have at least 1 client admin.
7. New Functions can’t be added by super admin at run time because of its mapping
behaviour. Functions are bound to different system modules and system entities and if we
allow to add a new function then we would also need to write a module which would be
called Functions Mapping to their corresponding modules and entities. So, Functions can
be modified upto some extent like icon, description, bug description.
8. Also Explain the concept of forms, what will be the impact of different forms in this
system? See the forms section

Deployment
1. Deploying a function means granting a function to a client group. When a function is
deployed by super admin, it becomes available for a new or existing client group.
2. To activate a function for a client group, the super admin navigates to the clients page.
3. Select a client group from the list and a client group details page is displayed from where
he can choose the new function he wants to grant.
4. If a new function is added to a client group, all the client admins should be notified about
the new function.

Software Requirements Specification Page 9

Electronic Medical Records

ii. User Characteristics

It's expected that users of this system have basic computer skills for navigating the internet to be
able to access the system. A simple and user-friendly UIs will make use of the system easy, and
training can be offered to the users in case of any difficulties.

iii. System Users

There are 3 main user groups for the system
1. Super Admin
2. Client Admin
3. Client User
Super Admin
1. No permission implemented for Super Admin as super admin have all the permissions
2. Only Super Admin can create client groups and assign different functions to different
client groups.
3. In a new deployment, a single Super Admin user will be created via seeders.
4. There will be a parent menu with child menus like functions, location types, client
groups.
5. Admin can mark any client as active/inactive, impacting the client user access
permissions to the app.
6. If a client admin become inactive, all the client user under that client admin would
become inactive and can’t login
7. If admin can change permission to any client group which is already assigned to any
client admin and client admin already assigned permissions to client users. In this case,
all the permissions would be applied to all client admins and client users as well. It’s
complicated to achieve but it’s important.
8. Admin includes basic fields, and additional information is provided in the database guide.

System administrator is a type of user group that has irrevocable administrative permissions that
should not be used in the day-to-day administration of the organization.

Super admin is a special user that has the most access to the application. All other users are
considered standard users and belong to different client groups and user groups.

Summary

1. Access the main functions page and it’s details

2. Add a new function
3. Deploy a function
4. Manage the clients page
5. Create a new client group
6. Manage a client group
7. Set a client group as a sign up option.

Software Requirements Specification Page 10

Electronic Medical Records

8. View user groups overview

9. Activate a user
10. View reported bugs

Client Admin
Client admin is the administrator for the client. A summary of functions performed by Client
Admin:

1. Client admin has the same functions as the client group that the client belongs to. These
functions are set by super admin.
2. Client admin does not create functions. A request for functions can be made to the system
by contacting support.
3. Client Admin can view the list of granted functions from the Functions Page.
4. Clicking on any function will open the function details page. This page will show
a. information about the function
b. sub-functions
c. timeline (inside right-pane)
d. users and user groups with access to the function
5. Functions (or sub-function to an existing function) can be granted / added to a user group.
In this situation, the client admin should be notified through email and notifications in the
system.
6. Client admin should be able to report a bug regarding any function.

Client Users
All users (except super admin) belong to clients. A client can have a user in these ways: A
person:

1. Signs up for an account with their email addresses. The user that signs up becomes the
client admin for the client.
2. Is added by another user of a client.

Summary

1. Perform basic user functions( Register, Login, Reset Password, Update Profile) Explained
below.
2. Perform functions that client admin grants to them.
3. Report a bug on a function. Reported bugs are tracked on the function details page for
super admin.

Software Requirements Specification Page 11

Electronic Medical Records

iiii. Assumptions and Dependencies

1. Some of the use-cases can't work without the others. It's all part of one cohesive program
in which classes are shared so that use-cases may assist other use-cases.
2. All of the use-case flow being the most common or standard typical flow of use-case
events. Cases made with the typical full functionality should be implemented for alternate
flows, since they are the key features of the system.
3. Additional functionality may be created and changes might be made in the future while
developing the system.

3. Requirements
i. External Interface Requirements
User Interfaces
The user interface for the software shall be compatible with any modern web browser such as
Chrome, Firefox, Opera, Brave, or Edge by which users can access to the system. The same
applies for the mobile version.

Hardware Interfaces
All clients and users shall be responsible for hardware issues since the application requires
internet access.

Software Interfaces
No 3rd party software is used till now

Communications Interfaces
No communication Interfaces will be integrated in the system now. A chat-bot will be integrated
in the future for customer support.

ii. Seeder Module Implementation:

1. The Seeder module should be executed using the command npm run database:seeder.
2. Insert static and fixed data, including predefined icons.
3. Create functions with function_key, basic description, and fixed predefined icon.
4. Create an admin user with a default user ID and password.
5. Create basic location types; allow admin to add new types.

iii. Functional Requirements

b. Functions

Managed by Super admin

Software Requirements Specification Page 12

Electronic Medical Records

1. Anything outside of Basic User Functions is a system function.

2. Functions are system actions that are distributed to client groups and managed by super
admin users. System actions like adding new users, changing user’s status and updating
client information,... etc.
3. Functions are listed and categorized in a hierarchy manner.
a. Level 1: Top, main level category
b. Level 2: First level sub category function of a main category function.
c. Level 3: These are subcategories of a sub-category
4. Active functions will only be listed and other functions can be shown by clicking “show
hidden”
a. clicking it only functions with "Hidden" status should be shown and all others
should be hidden.
b. "Show hidden" button should change to "Show all". Clicking "Show all" should
show the default functions page.
c. A function with a hidden status should be hidden on the default functions page.
5. Functions have status ( Development - Testing - Active)

4. Function Examples

1. Users
a. Level 1
2. Add user
a. This process describes adding a new user by an existing user. Example: User Bob
is a user with client ABC. User Steve is new to the system. Steve's email address
will be added which makes him a new user.
b. The existing user (already registered with a client) adds the new user by email.
The "Add new user" form should ask for email, first name, last name.
c. The new user is added to the client's users with a "Pending" status.
d. On the back end, a new SA user overview page should be created when the email
is sent.
i. The user's information should be saved: First name, last name, and email
address.
ii. A timeline entry should be added
e. The new user receives an email with a link. The link should open a page called the
"Set password" page. Here the user should enter a password.
f. After successfully entering a password
i. The user should be redirected to the login page.
ii. A toast message should inform the user that their password has been
successfully saved and they can log in
iii. The system must allow client user to logout
3. Manage users (CRUD operations)
a. Client Admin can navigate to Users page through the dashboard.
b. Users page contains List of Users, List of User Groups.

Software Requirements Specification Page 13

Electronic Medical Records

i. There must be a FAB in the bottom right. When clicked two options
appear: Add user and Add user group.
c. If the client admin is the same one who created the account for the client there
will be no users except himself/herself in the list and highlighted as a client
admin.(Note: Client admin can add user if granted this function)
d. Clicking on any user will open CA user overview
e. Client admin can add/remove users
f. Client admin can manage the status of the user. Active/Inactive if not active the
user will not be able to login in his/her account.Client admin is not privileged to
edit any of other user's information.
g. Client admin can add/remove functions for a user
h. Removing any user by the client admin will remove the user from any user group
he/she is a member of.
4. Manage user group (CRUD operations)
a. Client admin can view all user groups.
b. Clicking on any of the user groups will open the user group overview.
c. There should be a sample user group shown to the client admin if there are no user
groups created yet.
d. Client admin can create a new user group.
e. Client admin can update details of each user group such as names of user groups.
f. Client admin can add/remove user groups.
g. Client admin can add/remove users from user groups.
h. Client admin can add/remove functions from the user group.

c. Client groups
1. A client group is a collection of clients with access to the same system functions.
2. Client groups would be listed on registration page if set by super admin.
3. Client group can't be deleted if it's already assigned to any client.
4. Client Admin possesses only the permissions assigned to their client group.
5. Client Group includes basic fields, and additional information is provided in the database
guide.
6. Super admin
a. Manages client groups and the client group functions.
b. Creates the client group and selects the functions and forms which he/her wants to
be associated with the group.
c. Can update the functions granted to a group.
d. Can change the client group of any client and can also change any permission.
e. Can create/modify/delete new client groups.
f. Can assign different functions as permissions to client groups.

Software Requirements Specification Page 14

Electronic Medical Records

1. Clients

1. A client is a company, organization, or individual that manages users, locations, and other
person's health information
2. Information (such as users, patients, locations, etc.) generated by the client admin should
be contained within the client. Any client can’t access information of another client.
3. The system must allow the super admin to access client’s overview page which shows
client details

Clients details include

1. Name
2. Assets,
3. Type(group type),
4. Status (Active - Inactive - Hidden)
5. Timeline Link: If the user clicks this tab, the timeline contents will load in the info
content space.
6. Address
7. Timezone
8. Creation date
9. Phone
a. Client's can have up to 5 phone numbers.
b. If 1 phone is provided, it is primary. If more than 1, a phone number must be set
as primary.
10. Email
a. Clients can have up to 3 email addresses.
b. If 1 email is provided, it is primary. If more than 1, an email address must be set
as primary.

2. Client Status

1. Client status is a higher priority than user status. If a client status changes from active to
inactive, all users will not be able to log in to the client until the client status changes
back to active.
2. Client status will affect all of the users of the client. Only system administrator can access
and modify client status.

Status
1. Active
a. After the client has the first user with active status, the client status will
automatically change to active.
b. Client status should automatically change to active after the first user status is
changed to active. Users are added with a pending status. The pending status is

Software Requirements Specification Page 15

Electronic Medical Records

changed to active after the user clicks the verification email link and the user's
email is verified.
c. The first user for all clients should be the client admin.
d. A user that logs in to a client with Active status has full read-write permissions
based on the user's title
2. Inactive
a. All client users will not have access to the website when client status is changed
to inactive. Only Super Admin can change a client's status.
b. All client users will be redirected to another page when logging in if client status
is inactive.
c. Client status comes before user status. This means user can not log in if client
status is inactive
3. Hidden
a. Clients with hidden status will not be shown on the client's main list.
4. Read
a. A user that belongs to a client with read status can’t make any updates. The user
can only view / read the existing information. If the user of the client wants to
make updates or changes, the client status must be changed to active by client
admin.

4. Client Group Attributes

Group attributes describe the group. Client users and client admins do not have access to this
information.

1. Name: Title of the user group

2. Acronym: Shortened name
3. Sign Up: Allows client groups to be available on the sign up page. If this is active, the
user will be assigned to the "Default User Group" on sign up.
4. Status: Affects visibility of the group in the list of client groups. Client group status
should not affect client or user status. Example: a client group can be hidden from the list.

Software Requirements Specification Page 16

Electronic Medical Records

e. General Other Functions or Requirements

iiii. Use Cases

a. Super Admin Use Case

b. Client Admin Use Case

Software Requirements Specification Page 17

Electronic Medical Records

Software Requirements Specification Page 18

Electronic Medical Records

c. Client User Use Case

v. Non-Functional Requirements
a. Performance
Approaches How can we do speed optimization:

Implementing Brotli Compression

When a client makes a request on the browser, it sent to our server where the server returns the
response along with all assets. What we do with brotli, we first compress assets and responses
and then send to browser where browser auto decompress the assets and in that way, we reduce
initial page load time upto 25%. We only need to implement brotli compression algorithms at
server not on client because modern browsers come with built in decompression algorithms.

Software Requirements Specification Page 19

Electronic Medical Records

Brotli is a newer compression algorithm that can achieve higher compression ratios than GZIP.
Typically, Brotli can reduce file sizes by 20-30% compared to GZIP. This means that a 1MB file
could be compressed to 700-800KB with Brotli, while it would be compressed to 800-900KB
with GZIP.

Here is a table comparing the compression ratios of Brotli and GZIP for different file types:

File type Brotli compression ratio GZIP compression ratio

HTML 26% 21%
CSS 21% 17%
JavaScript 14% 10%
JPEG 2-5% 2-3%
PNG 5-10% 3-5%

Images
● All Images are powered with lazy loading
● All Images must in optimized size and in webP format
● Separate image versions for mobile and desktop versions.
There are around 300+ Images that are being used. I need to compress images in webp extension
which is modern and low size file type. I need to change all these 300+ pictures in term of
compression and file type.
I also need to implement lazy loading in images so that not all images are loaded once rather than
load only those images that are in viewport area. View Port is the visible web page not the web
page which is hidden and gets visible upon scrolling.
Also, we need to change image sizes for galleries. We must different versions like thumbnail
large images, thumbnail images should be loaded in sliders but large images only loaded when
use navigate through the images. It would required to work in backend as well.

DOM
We need to optimize Dom Manipulation. VUE uses virtual DOM called vNode to auto update
Dom based on states changes. We need to rerender the components only when it would be
required otherwise it would Kept our Dom Busy and will effect user experience

Static Site Generation (SSG)

All our static pages would not be the part of VUE Components as it will come under a main JS
package and will be rendered on browser which is not needed. We will create static pages using
Static Site Generator like VuePress or any other third party library. It will be loaded only once it
will be required. It won’t be bundled in main bundler file which comes to browser and start
organizing components.

Software Requirements Specification Page 20

Electronic Medical Records

Server-Side Rendering (SSR)

All those pages that need to be SEO optimized would first be rendered on server so that all SEO
parts of websites will be generated on server so that the search engines could get the content
from our web pages. It’s not possible in client side rendering because content render once
website is loaded to browser and in that way, search engine can’t access the content specially
meta tags, semantic HTML and over all content.

Component Lazy loading

Don’t Bundle all components at once and send back to browser. If you budle all components in
single bundler, it will increase bundle size which will effect first time website loads. Instead of
that implement lazy loading by implementing asycn components that would be loaded from
server once it would be needed.

Cache
Make sure all static resources are properly cached so that if user visit the website again, browser
won’t send new requests to server to fetch assets again. Mark every asset with unique IDs
because if you updated an asset in server with same name, browser won’t fetch it because
browser would see that the asset is already in cache with same name so we need to assign
separate unique IDs along with asset name. Typically it’s auto done using Web Pack and we need
to write necessary configuration.

Separation of critical and non critical assets

When user visit the website for the first time, website loads all assets one by one and then it
cached all those assets to use it next time. So, there are two kind fo assets, critical and
non-critical.
Critical assets are those which are necessary for website parsing in browser from beginning then
are those assets that are not necessary right away. I mean if we skip those assets and complete
website parsing and then load the remaining assets in background, out website would be visible
to use and keep loading remaining assets in background those are call non-critical assets. So, we
need to separate critical and non-critical assets. For Example, our logo is critical assets, Hero
video is critical asset, and css which making upper part of the website is critical but assets are
responsible for footer and other rarely viewed pages should be added in non critical assets and it
laods in website when all critical assets are loaded.

APIs Integration Optimization

APIs are well integrated but not properly organized using react hooks carefully. If you open
developer tab of website, you can see that same API is being request again and again because the
API calls are poorly organized so it calls many times.
Also, Listing pages are generating excessive HTTP requests, impacting the overall speed. We
should work on decreasing the number of requests to the server to enhance the website speed.

SVG Image Optimization with Sprites

Throughout the website, numerous SVG icons are being used, such as logos, small icons, stars,
etc. Each of these elements is currently handled with separate requests, contributing to slower

Software Requirements Specification Page 21

Electronic Medical Records

loading times. To streamline this process, we should create sprites for all SVG images so that a
single HTTP request can retrieve all necessary SVG assets.
If there are 100 svg files, browser make 100 separate requests to server causing high page
loading speed. Using Sprite, we compress all Svgs at once and same it as single svg file and then
at browser, we use any svg file from that compressed file.

Control Cache for Specific Resources:

As for now, we are not customizing cache and browser taking care of website cache for us but
browser have standard algorithms which work same for all website and we do need to manage
our resources carefully in cache. If cache is managed good, data load from cache quickly in an
optimized way. We can also optimize the cache by either complete removing or altering the
unnecessary resources. This targeted approach will help in ensuring that only relevant and
essential resources are cached, leading to improved loading times.

Implement CDN (Content Delivery Network):

For our assets specially JS, CSS, fonts and other files, we should use utilize CDN system. It will
significantly enhance optimization by globally distributing our content. This approach aims to
reduce latency for users in specific regions, thereby improving the overall user experience.

Global Implementation of Lazy Loading:

Implementing Lazy Loading across the entire website is crucial for sustained speed optimization.
This ensures that resources are loaded on-demand, preventing unnecessary loading and
enhancing overall performance.

Assets Minification
Assets should be minified properly which is not good in terms of website performance and
securities. Look at the code in a website resources in browser, it’s clearly readable and it also
increase the file size. So, we would build this by implementing custom web pack configuration.
Web Pack is responsible for building website for different environments.

Software Requirements Specification Page 22

Electronic Medical Records

Arrange Depencies carefully

● Separate dev dependencies from production dependencies so that when we deploy project
to server, it only contain production dependencies.
● Implement peer dependencies carefully so that there shouldn’e be any conflict with
between dependenceis that are inter connected.
● All the depencies should be updated and there shouldn’t be any deprecated dependencies.

Encryption
All the keys, tokents, auth info would be encrypted before saving into local storage, cookies,
sessions and cache.
b. Reliability
The system should be available and responsive when needed, and should not experience frequent
failures or crashes.
c. Availability
The system may be available 98 percent of the time and not being down.
d. Security
3.5.4.1 Data Transfer
The system shall use secure sockets that include any confidential client information.
The system shall automatically log out all clients after a period of inactivity.
The system shall not leave any cookies on the client's computer the user’s password.

Software Requirements Specification Page 23

Electronic Medical Records

The system shall not leave any cookies on the client’s computer containing any of the user’s
confidential information.

3.5.4.2 Data Storage

The client’s web browser shall never display a client’s password. It shall always be echoed with
special characters representing typed characters.
The system’s backend servers shall never display a client’s password. The client’s password may
be reset but never shown.
The system’s backend servers shall only be accessible to authenticated administrators.
e. Maintainability
The system should be designed with modularity and extensibility in mind, and should be easy to
test and debug.
f. Usability
The system should provide a uniform look and feel between all the web pages.
The system should provide use of icons and toolbars.

Software Requirements Specification Page 24

Electronic Medical Records

4. Analysis Models
i. Sequence Diagrams
a. Register Sequence Diagram

Software Requirements Specification Page 25

Electronic Medical Records

b. Login Sequence Diagram

This sequence diagram explains the process of the login along with the level checks that are
described in 3.2.3.3 B Section.

c. Password Reset from Profile Page

This sequence diagram describes the process of a user changing his/her password from profile
page. Refer to section 3.2.3.3 F

Software Requirements Specification Page 26

Electronic Medical Records

d. Password Reset from Login Page (Forgot Password)

This sequence diagram describes the process if a user forgets the password. Refer to section
3.2.3.3 G

Software Requirements Specification Page 27

Electronic Medical Records

ii. User Flow Diagrams

User flow diagrams are being designed in Figma

Software Requirements Specification Page 28