1.

Identifying the Problem, Requirements, Objectives, Scope, and Expected Outcomes

Identifying the Problem

In traditional healthcare settings, patients often carry their medical documents,

prescriptions, and test results manually. This leads to:

Loss or damage of medical history.

Di iculty for doctors to access complete patient data.

Wasted time during diagnosis and treatment.

Lack of centralized data management.

There are diseases that require a medical record to determine the first appearance of the
disease in order to know the patient’s condition and to make it easier for doctors to
diagnose diseases that are di icult to diagnose by more than one doctor (the doctor will
write or tell the patient his condition or diagnosis, and this prevents the patient, if he goes
to another doctor, from diagnosing him with the same diagnosis but giving him an
alternative treatment, and thus the problem is repeated).

Requirements

A web-based system that allows patients to store and access their complete medical
history digitally.

Secure access for doctors to review patient records upon permission.

Ability to upload and manage medical files (e.g., PDFs, images).

Data privacy, authentication, and encryption for patient data.

Objectives

To create a digital medical record system accessible from web browsers and mobile
devices.

To simplify the sharing of medical information between patients and healthcare providers.

To reduce paperwork and improve accuracy in medical diagnosis and treatment.

Educating the patient on the correct way to enter data, especially high-resolution images or
X-rays

Scope

The system will support two main user types: patients and doctors.

Patients can create accounts, upload medical records, and grant access to doctors.

Doctors can view shared records, add notes, and provide feedback.

The system will initially focus on web browsers and mobile-friendly design.
Expected Outcomes

A secure, e icient, and user-friendly medical record management system.

Easier and faster access to medical history for both patients and [Link]
communication and decision-making in healthcare.

2. Search for Alternatives

Before finalizing the proposed solution, the following alternatives were considered:

Manual System: Continue using physical files and folders for patient data.

Disadvantages: Prone to loss/damage, di icult to share, time-consuming.

Existing EHR Systems: Use commercial electronic health record (EHR) platforms.

Disadvantages: Expensive, complex, and may not suit local or small clinics.

Custom Web Application (Proposed): Build a lightweight, secure, and customizable

system.

Advantages: Cost-e ective, flexible, easy to maintain, and privacy-focused.

→ The proposed solution (custom web application) is the most feasible option.

3. Assessing Technical Feasibility

Technical Resources:

Languages: Python (Flask) / JavaScript / HTML / CSS

Database: SQLite or PostgreSQL

Hosting: Cloud-based (Azure)

Tools: As the developer like

Technical Skills Required:

Web development (frontend + backend)

Database management

Security and authentication

Feasibility Result:

The project is technically feasible, as the required technologies are open-source, well-
documented, and within the developers’ skill level.

4. Assessing Economic Feasibility

Estimated Costs:

Development tools: Free (open-source)

Hosting: Low-cost shared hosting or free tiers (Heroku, Vercel)

Maintenance: Minimal

Expected Benefits:

Saves time and paper costs.

Reduces storage and administrative e ort.

Enhances medical accuracy and e iciency.

Feasibility Result:

The project is economically feasible, as it requires low investment and provides long-term
value.

5. Assessing Operational Feasibility

The system will simplify patient–doctor communication.

It requires minimal training for both users (simple web interface).

Feasibility Result:

Operationally feasible with smooth adoption by both patients and doctors.

6. Assessing Legal Feasibility

The system must ensure patient privacy and data protection.

Patient consent must be required before any data sharing.

Feasibility Result:

Legally feasible if proper data security and privacy policies are implemented.

7. Schedule Feasibility

Estimated Development Timeline (MVP): ~7–9 weeks

Stage Duration

Requirements & Design 2 week

Backend Development 2 weeks
Frontend Development 2 weeks
Testing & Debugging 1 week
Deployment & Review 1–2 weeks

Feasibility Result:

The project schedule is feasible, achievable within a typical semester or short-term project
timeline.
System Requirements
Identifier Requirement
REQ1 The system must allow patients to create secure accounts and log in
using valid credentials such as email and password, ensuring privacy
and authentication.

REQ2 Patients should be able to upload, view, and organize their full
medical history, including documents, reports, and medical images,
through an easy-to-use interface.

REQ3 Doctors shall only access a patient's records once permission is

granted by the patient, maintaining strict confidentiality and
controlled access.

REQ4 Doctors should be able to add professional notes or feedback to

patient records to enhance diagnosis accuracy and communication.

REQ5 The system shall automatically log all actions, such as uploads, edits,
and access attempts, to ensure accountability and traceability.

REQ6 Patients must have the ability to revoke or grant access to specific
doctors at any time to maintain full control over their data.

REQ7 All medical data stored or transmitted within the system shall be
encrypted using secure standards like AES or SSL to ensure data
protection.

REQ8 The web application should be responsive and optimized for di erent
devices, including smartphones and tablets, ensuring ease of use
anywhere.

REQ9 Doctors should be able to search and filter patient data using various
parameters such as date, type of record, or diagnosis for faster
navigation.

REQ10 The system shall include a help section guiding patients on how to
properly upload and format medical files for best readability and
accuracy.

REQ11 The platform must follow all privacy and consent regulations,
ensuring no medical data is shared without explicit patient approval.

REQ12 The application shall be deployed on a secure and reliable cloud

platform with continuous backup and minimal downtime.
Priority
Requirement Description Priority

REQ1 System allows patients to High (Must)

create secure accounts and log
in with authentication
credentials.

REQ2 Patients can upload, store, and High (Must)

manage medical records
(PDFs, images, X-rays)

REQ3 Doctors can access patient High (Must)

records only after receiving
patient permission
REQ4 Doctors can add notes and High (Should)
feedback to patient records for
diagnosis
REQ5 System maintains a log of all Medium (Should)
actions (uploads, updates,
access requests)
REQ6 Patients can grant or revoke High (Must)
access for specific doctors
anytime
REQ7 All stored and transmitted High (Must)
medical data must be
encrypted for privacy
REQ8 System supports responsive Medium (Should)
design for mobile and tablet use

REQ9 Doctors can search and filter Medium (Should)

patient data e iciently

REQ10 Patients can access a guide Low (Could)

explaining how to upload
medical files correctly
REQ11 System ensures compliance High (Must)
with privacy laws and patient
consent before sharing data

REQ12 Hosted securely on a reliable cloud High (Must)

platform with backup support
User Stories
Identifier User Story

ST-1 As a patient, I can create an account with (email or phone number

and password) so that I can securely store my medical history
online.

ST-2 As a patient, I can upload medical documents (PDFs, images, X-

rays) so that my doctor can review them.

ST-3 As a patient, I can grant or revoke access to my medical records to

specific doctors.

ST-4 As a doctor, I can log in securely to view the medical records

shared with me.

ST-5 As a doctor, I can add notes and instructions to a patient’s record

after reviewing it.

ST-6 As a patient, I can view a list of all doctors who currently have
access to my records.

ST-7 As a patient, I can download my own medical reports anytime for

personal backup

ST-8 As a system, all medical data should be encrypted during storage

and transmission.

ST-9 As a system, I can guide patients to help them easily use the
website.

ST-10 As a user (patient or doctor), I can reset my password securely

using email verification.

ST-11 As a patient, I can receive notifications when my doctor adds new

notes or updates my records.

ST-12 As a patient, I can contact my doctor through a secure messaging

feature for quick questions.
Use Cases for Functional Requirements
Actor Actor’s Goal (What the Use Case Name
actor intends to
accomplish)

Patient To create a secure account UC1: CreateAccountAndLogin

and log in to the system.

Patient To upload, store, and UC2: ManageMedicalHistory

manage their complete
medical history (PDFs,
images, X-rays).

Doctor To securely access patient UC3: AccessPatientRecords

medical records only when
permitted.

Doctor To add diagnostic notes or UC4: AddDoctorNotes

comments to patient
records.

System To keep a complete activity UC5: MaintainActionHistory

log of actions by both
patients and doctors.

Patient To grant or revoke doctor UC6: ManageDoctorAccess

access permissions.

System To encrypt all stored and UC7: EncryptData

transmitted data for privacy
and security.

Patient / Doctor To use the system easily UC8: MobileAccessInterface

from mobile or tablet
devices.

Doctor To search and filter patient UC9: SearchPatientData

data e iciently.
Patient To view guidance on UC10: ViewUploadGuide
uploading proper files and
images.

System To ensure compliance with UC11:

medical privacy and EnforcePrivacyCompliance
consent regulations.

System To maintain uptime, UC12: CloudHostingReliability

backups, and hosting
security on the cloud
platform.