National University of Modern Languages

Rawalpindi

Software Design & Architecture

CCP

Department: Software Engineering-IV

Submitted by:

Itrat Fatima…..(RCF-30156)
Aiman Ishtiaq…..(RCF-30185)
Muhammad Usman…..(RCF-30147)

Submitted to: Ms. Laraib Zainab

Dated: 20 May, 2025

 Software Design Description (SDD)

Online Healthcare Management System

1. Purpose of the Document:

This Software Design Description (SDD) provides a comprehensive overview of the design
architecture for the Online Healthcare Management System. The document is intended to
guide the development team in translating the Software Requirements Specification (SRS)
into a structured and organized implementation.

The goal of this document is to:

 Present a clear and complete design blueprint for all major components of the system.
 Ensure that every module aligns with the system’s functional and non-functional
requirements.
 Serve as a communication bridge between stakeholders, developers, testers, and
project managers.
 Establish a standard reference for maintaining consistency throughout the
development process.
 Minimize ambiguity during implementation by defining data flows, interactions,
interfaces, and dependencies.

This SDD ensures that all technical stakeholders have a common understanding of the
system’s internal workings, thereby enabling a smooth transition from planning to execution.
 2. Scope of the System:

The Online Healthcare Management System is a web-based platform designed to improve

the efficiency, accuracy, and convenience of healthcare administration for hospitals, clinics,
and diagnostic centers. It will provide secure, role-based access to doctors, patients, and
administrative staff, enabling them to perform their respective functions through an integrated
digital interface.

Core Functionalities:

 User Authentication & Role Management

o Secure registration and login for patients, doctors, and admins.
o Role-based access controls and session management.
 Patient Management
o Patient profile creation, updating personal and health information.
o Access to medical history, prescriptions, and appointment records.
 Doctor Management
o Doctor registration with specialization, availability schedule, and credentials.
o Ability to view patient history, add diagnosis, and prescribe treatment.
 Appointment Scheduling
o Real-time calendar for booking appointments.
o Viewing, rescheduling, and canceling appointments by patients or doctors.
 Electronic Medical Records (EMR)
o Digital storage of patient health records including reports, diagnoses,
treatment plans, and prescriptions.
 Billing and Invoicing
o Auto-generation of bills based on services rendered.
o Viewing payment history and exporting invoices.
 Admin Dashboard
o Monitor system activity, manage users, and configure settings.

Out-of-Scope:

 Integration with third-party insurance or payment gateways.

 Telemedicine (video/audio consultations).
 Mobile application for offline access.
 AI-based diagnosis or chatbot services.
 Direct integration with diagnostic lab equipment.

This scope defines the operational boundaries of the system and ensures that the project stays
focused and manageable in its initial release.
3. Intended Audience:

This document is intended for all technical and managerial personnel involved in the design,
development, deployment, and evaluation of the Online Healthcare Management System.

Audience and Benefits:

Audience Purpose and Benefits

To understand system architecture, design patterns, and
Software Developers
module responsibilities for accurate implementation.
Quality Assurance To develop and execute test plans, unit testing, integration
(QA)/Testers testing, and system testing based on the defined design.
To monitor development progress, resource allocation, and
Project Managers
ensure consistency between SRS and system design.
To verify and validate that the system design supports
System Architects
performance, security, and scalability needs.
Stakeholders (Hospital To gain visibility into how the system will be structured and
Admins/Investors) how it supports operational goals.

Having a detailed SDD helps each of these groups collaborate effectively and deliver a
product that meets expectations.

4. Overall Architecture:

The Online Healthcare Management System will be developed using the Model-View-
Controller (MVC) architectural pattern. This pattern ensures clear separation of concerns,
allowing independent development, testing, and scaling of different components.

4.1 Architectural Pattern: MVC

 Model:
Manages the data, logic, and rules of the application. Includes database schemas,
patient records, doctor profiles, and billing data.
 View:
Represents the user interface (UI) that displays data to users and captures their inputs.
Developed using responsive front-end technologies like HTML5, CSS3, JavaScript
(React.js/Bootstrap).
 Controller:
Handles user input, communicates with models, and updates the view. Responsible
for processing business logic and request routing.

4.2 Technologies Used:

  Front-End: React.js / Angular, HTML5, Bootstrap
 Back-End: Django (Python) / Node.js (Express)
 Database: MySQL / PostgreSQL
 API Communication: RESTful APIs
 Authentication: JSON Web Tokens (JWT) or session-based
 Hosting/Deployment: AWS / Heroku / Local server (for testing)

4.3 System Modules and Interactions:

1. Authentication & User Management Module

 Handles login, logout, and registration.

 Role-based access for patients, doctors, and admins.
 Password encryption and session/token management.

2. Patient Module

 Patient profile dashboard.

 Medical record access.
 Appointment viewing and cancellation.

3. Doctor Module

 Schedule availability settings.

 Appointment handling.
 Patient health record updates and prescription entry.

4. Appointment Scheduling Module

 Integrated calendar interface.

 Real-time appointment slot validation.
 Notification system (email/SMS, if integrated).

5. EMR Module

 Secure storage of health data.

 Upload and download options for reports and prescriptions.
 Only accessible by authorized users (patients and doctors).

6. Billing & Invoicing Module

 Automatic billing generation.

 Invoice viewing, download, and print options.
 Admin monitoring of transactions.

7. Admin Module

 Access to all system activities.

 Management of users, appointments, and content.
 Reporting tools and analytics (optional).
4.4 Module Interaction Diagram (Described Textually):

 A patient logs in through the Authentication Module, navigates the Appointment

Module to book a doctor, and views their profile through the Patient Module.
 A doctor, after logging in, accesses the Doctor Module to view their schedule and
write/update EMRs through the EMR Module.
 The Admin interacts with all modules, primarily through the Admin Panel,
overseeing activities, generating reports, and resolving conflicts.
 All modules access and modify data in the central database via RESTful APIs,
coordinated by the controller logic.

5. Developing a Sequence Diagram:

The sequence diagram for the Online Healthcare Management System illustrates the process
of booking an appointment by a patient. First, the patient logs into the system, which sends
the credentials to the authentication controller for verification against the database. Upon
successful login, the patient searches for available doctors based on criteria like specialization
or date, and the system retrieves matching results from the database through the doctor
service. Once a doctor and time slot are selected, the system sends the booking request to the
appointment controller, which forwards it to the appointment service for validation. The
appointment service checks slot availability in the database, saves the appointment if
available, and optionally triggers a notification service to send a confirmation message.
Finally, the confirmation is sent back through the controller to the system, and the
appointment is added to the doctor's schedule, which the doctor can later view through their
own dashboard.
1. Patient registration:
2. Appointment booking:

3. Patient record management:

4. E prescription flow:

5. Complete system diagram:

6. Design and Present Use Case Diagrams:
The Use Case Diagram for the Online Healthcare Management System represents the primary
interactions between different user roles and the system functionalities. The main actors
include the Patient, Doctor, healthcare provider and Administrator. Patients can register,
log in, search for doctors, book or cancel appointments, view medical records, and receive
prescriptions. Doctors can log in, manage their availability, view patient appointments, access
medical histories, and add diagnoses or prescriptions. Administrators have broader control,
including managing user accounts (patients and doctors), overseeing appointment data, and
generating system reports. The diagram visually outlines these interactions, helping to define
system boundaries and clarify user responsibilities within the system.
Complete System diagram:

7. Create a Deployment Diagram:

The Deployment Diagram for the Online Healthcare Management System illustrates the
physical distribution of hardware nodes and software components required for secure,
scalable, and efficient system operation. The client-side includes patient devices
(laptops/smartphones), doctor devices (laptops/tablets), and admin desktops, all running the
frontend web or mobile application. These clients communicate with a cloud-based web
server, which connects to an application server hosting backend services like user
management, appointment scheduling, medical records, and billing. An authentication server
(such as AWS Cognito or Firebase Auth) handles secure login and role-based access. The
database server stores all critical data, including user profiles, appointments, and health
records, using a relational database system. The architecture also integrates with external
APIs for services like lab systems or payment gateways. To ensure reliability and
performance, the deployment supports HTTPS communication, OAuth2 authentication,
encrypted data storage, load balancing, and auto-scaling across cloud platforms like AWS,
GCP, or Azure, with optional hybrid or on-premise configurations for regulatory compliance.

8. Create a Component Diagram:

The Component Diagram for the Online Healthcare Management System outlines the internal
software structure by showing how different functional modules are organized and interact
with one another. At the core, the Frontend Component (web or mobile app) interfaces with
users such as patients, doctors, and administrators. It communicates with various Backend
Components, including the User Management Module (handles registration, login, and role
management), Appointment Module (manages doctor availability and bookings), Medical
Records Module (stores and retrieves patient history, diagnoses, and prescriptions), and
Billing Module (handles payments and invoice generation). An Authentication Component
ensures secure access and session management, typically through OAuth2 or third-party
services like Firebase Auth. These backend components interact with a centralized
Relational Database Component, which stores persistent data such as user details, medical
information, and transactions. Additionally, the system may integrate with External Service
Components such as lab APIs or payment gateways. The diagram helps visualize the
modularity of the system, supporting maintainability, reusability, and clear separation of
concerns.

9. Create a state Diagram:

The state diagram illustrates the various states a user (typically a patient) transitions through
while interacting with the Online Healthcare Management System, from registration to
appointment booking. The process begins in the Idle state, where the user initiates interaction
by providing personal details. After submitting the information, the system moves to the
Details Provided state, followed by a validation process. If the data is valid, the user
transitions to the Registration Successful state and then to Registration Confirmed. If the
data is invalid, the system prompts the user to re-enter valid data. Once registered, the user
provides login credentials, moving to the Provided Credentials state. If credentials are
correct, the system logs the user in, transitioning to the Logged In state; otherwise, it prompts
for correction. From there, the user checks doctor availability. If available, the system moves
to Slot Selected and then to Appointment Booked upon confirmation. If a slot is not
available, the user is prompted to select an alternate. The final state after completing tasks or
logging out is Logged Out, which ends the session. This diagram effectively represents the
user journey and system responses at each stage, ensuring clarity in behavior modeling.
10. Create a Class Diagram:

The Class Diagram for the Online Healthcare Management System models the structure and
relationships between the key entities involved in the system. At the core is the User class,
which includes attributes like userId, name, email, and phone, along with a method LogIn().
Inheritance is used where Patient, Doctor, and Admin classes extend from the User class,
adding their specific properties and behaviors. The Patient class includes a medicalHistory
attribute and methods such as BookAppointment() and CancelAppointment(). The Doctor
class contains specialization, a list of availableSlots, and a method to viewAppointments().
The Admin class manages system operations through methods like manageUsers(),
manageDoctors(), and generateReports(). The Appointment class holds details like
appointmentId, date, status, and links to the Patient, Doctor, and a TimeSlot, showing
associations. The TimeSlot class defines startTime, endTime, and a method isBooked() to
check availability. Lastly, the Report class is used to store appointment-related information,
with attributes such as reportId, generatedDate, and content. The diagram effectively
represents object-oriented relationships, such as inheritance and associations, supporting
system scalability, modularity, and ease of maintenance.

Conclusion:
The UML diagrams provide a clear and structured overview of the Online Healthcare
Management System. The Use Case Diagram outlines user interactions, while the Class
Diagram defines system entities and their relationships. The State Diagram shows dynamic
changes during processes like registration and booking, and the Sequence Diagram
illustrates the flow of interactions between users and the system. The Component Diagram
breaks the system into manageable modules, and the Deployment Diagram presents the
physical setup and cloud infrastructure. Together, these diagrams form a solid foundation for
designing, developing, and deploying a reliable healthcare management solution.
____________________________