Medicare: Online Medical Appointment
Booking System
EX.NO:1 Medicare: Online Medical Appointment Booking System
Aim
To develop an efficient and user-friendly online appointment booking system,
Medicare, that enables patients to book medical appointments seamlessly,
ensuring minimal delays in accessing healthcare services and improving the
overall patient experience.
Description
Medicare is a comprehensive online appointment booking system tailored to
modern healthcare needs. It is designed to streamline the interaction between
patients and healthcare providers by offering a centralized platform where users
can browse doctor profiles, check availability, and schedule appointments in real-
time. The platform supports various consultation modes, including in-person,
telehealth, and emergency consultations, making it adaptable to diverse patient
requirements.
Key features of Medicare include advanced search filters for specialties,
multilingual support for inclusivity, secure storage of patient records, and
automated reminders to reduce missed appointments. The system also benefits
healthcare providers by optimizing their schedules and reducing administrative
burdens. With a focus on accessibility, Medicare aims to bring healthcare services
to the fingertips of patients, ensuring a seamless, stress-free, and transparent
booking experience for all users.
By integrating modern technology, the platform strives to overcome traditional
barriers in healthcare appointment systems, such as long waiting times,
geographical constraints, and a lack of doctor availability awareness. Ultimately,
Medicare envisions a future where healthcare is more efficient, accessible, and
patient-centered.
PROBLEM STATEMENT
Traditional methods of booking medical appointments, such as
in-person visits or phone calls, are often time-consuming and
inefficient, leading to long wait times and delays in accessing
healthcare services. This issue is particularly significant in
remote areas, where reaching a healthcare provider may already
be challenging. Patients face a lack of transparency regarding
doctor availability, compounded by stress and the risk of
worsening health conditions due to delayed care. There is a
pressing need for an online system like Medicare to simplify
the appointment process, provide real-time scheduling, and
improve communication between patients and doctors,
ensuring timely and efficient healthcare delivery.
EX.NO:2 SOFTWARE REQUIREMENTS SPECIFICATION
1.Introduction
Medicare is an online appointment booking platform designed to simplify
healthcare access by connecting patients with doctors in real time. It reduces
delays, ensures transparency in doctor availability, and offers features like
automated reminders and secure data management. The platform promotes
timely, equitable, and efficient healthcare services for all users.
1.1 Purpose
The purpose of Medicare is to modernize the healthcare appointment process by
providing a digital platform that ensures timely access to medical services. It aims
to minimize delays, improve transparency in doctor availability, and make
healthcare more accessible and efficient for patients, regardless of their location
or circumstances.
1.2 Scope
Medicare is a web-based and mobile application designed to:
• Allow users (patients) to search for doctors by specialization, location, or
availability.
• Provide real-time appointment scheduling and confirmation.
• Support telemedicine consultations for remote healthcare access.
• Include integrated payment options for booking fees.
• Enable notifications and reminders for patients and doctors.
1.3 Definitions, Acronyms, and Abbreviations
• SRS: Software Requirements Specification
• UI: User Interfac
• UX: User Experience
1.4References
• Dot Com Infoway.Consultation app development for doctors and
healthcare professionals viewed by November 3,2021
https://www.dotcominfoway.com/online-medical consultation-app-
development
• National Information Board (UK). Personalised health and care 2020:
using data and technology to transform outcomes for patients and
citizens
2. Overall Description
2.1 Product Perspective
Medicare is a standalone, web-based, and mobile-friendly application that
bridges the gap between patients and doctors for seamless appointment booking.
It integrates with third-party APIs for payments, notifications, and telemedicine
services, ensuring reliable and secure operations.
2.2 Product Features
• User Authentication
• Search and Booking
• Telemedicine Support
• Payments
• Notifications
• Feedback
• Reporting
2.3 User Classes and Characteristics
• Patients: Easy-to-use platform for appointment booking.
• Doctors: Manage schedules and consult patients efficiently.
• Administrators: Oversee system operations and generate reports.
2.4 Operating Environment
• Hardware: Smartphones or PCs for clients; cloud-based server
infrastructure.
• Software: Browsers (Chrome/Firefox), Android/iOS apps,
Linux/Windows server, and scalable databases.
2.5 Constraints
• Regulatory compliance (HIPAA/GDPR).
• Budget and resource limitations for advanced features.
2.6 Assumptions and Dependencies
• Users have devices and internet access.
• Reliant on third-party APIs for payments, notifications, and video calls.
• Doctors maintain up-to-date schedules.
3. Functional Requirements
3.1 User Module
User Registration:
• Patients and doctors can register by providing personal details.
• Support for email/phone verification through OTP.
Login and Profile Management:
• Users can log in using credentials or social media accounts.
• Patients can update personal information, view booking history, and
manage feedback.
• Doctors can update profiles, including specialization, availability, and
fees.
3.2 Appointment Booking Module
Search Functionality:
• Patients can search for doctors by specialization, location, and
availability.
Slot Booking:
• Real-time availability of appointment slots.
• Confirmation of bookings with instant updates.
Rescheduling and Cancellations:
• Patients can reschedule or cancel appointments based on doctor
policies.
3.3 Admin Module
User Management:
• View, verify, and manage registered users (patients and doctors).
System Management:
• Monitor appointment trends and usage analytics.
• Manage notifications, system alerts, and platform updates.
4. Non-Functional Requirements
4.1 Performance Requirements
• Response Time: Ensure system response time does not exceed 3
seconds for any operation.
• Concurrent Users: Support up to 1000 concurrent users initially, with
scalability for growth.
4.2 Security Requirements
• Data Protection: Encrypt sensitive user data, including personal details
and payment information, both at rest and in transit.
• Authentication: Use secure login methods like two-factor
authentication (2FA) and OTP.
• Role-Based Access: Restrict access to data based on user roles (e.g.,
patient, doctor, admin)
4.3 Usability Requirements
• The interface should be intuitive and user-friendly.
• Ensure accessibility for users with disabilities.
4.4 Availability Requirements
• System uptime should be 99.9% annually.
• Provide a fallback mechanism for handling server failures.
5. External Interface Requirements
5.1 User Interfaces
• Responsive Web Design: Compatible with smartphones, tablets, and
desktops for seamless access.
• Simple Navigation: Easy-to-use menus for booking appointments,
searching doctors, and viewing profiles.
5.2 Hardware Interfaces
• Web Servers: Host the application for smooth user experience and fast
load times.
• Database Servers: Store user data, doctor schedules, and appointment
records securely.
5.3 Software Interfaces
• Payment Gateway API: Integrate secure payment methods (e.g.,
Stripe, PayPal).
• Notification API: Use SMS/email APIs (e.g., Twilio, SendGrid) for
reminders and alerts.
6. Future Enhancements
• Mobile App: Launch iOS/Android apps for better portability.
• AI Health Recommendations: AI-driven suggestions for doctors and
treatments based on user history.
• Health Insurance Integration: Future support for insurance claims
and coverage verification.
EX.NO:3 UNIFIED MODELING LANGUAGE(UML) DIAGRAMS
3.1 USE CASE DIAGRAM
Use Cases for Medicare System
1. Manage Appointment
• Actors: Admin, Doctor
• Admin: Admin manages overall system appointments, checks for conflicts,
and ensures no overbooking.
• Doctor: Doctors manage their appointment schedules, accept or reject
requests, and handle adjustments.
• Admin and doctor can view, approve, or reschedule appointments.
• Admin monitors the booking status to prevent conflicts.
2. Manage Doctors
• Actors: Admin
• Admin manages the registration, profile updates, and availability of
doctors.
• Admin can approve or reject doctor profiles based on verification.
• Admin approves doctor profiles and updates their availability.
• Admin manages doctors’ schedules, specialties, and fees.
3. Login
• Actors: User (Patient), Doctor
• User (Patient): Logs in to access their profile, make bookings, and view
appointment history.
• Doctor: Logs in to manage their appointments, profiles, and conduct
consultations.
• Secure login using email/phone and password.
• OTP-based authentication for added security.
4. Booking Appointment
• Actors: User (Patient)
• Patients search for available doctors based on specialization, location, and
availability, then book an appointment.
• Patients choose a doctor, select an available time slot, and confirm the
appointment.
• Real-time availability display and instant booking confirmation.
5. Approved Appointment
• Actors: Admin, Doctor
• Admin: Admin approves pending appointments and monitors system
integrity.
• Doctor: Doctor confirms or rejects appointments based on availability
and other factors.
• Doctors approve or reject appointments.
• Admin monitors appointment status to ensure accurate scheduling and no
double bookings.
6. Cancelled Appointment
• Actors: User (Patient), Doctor
• User (Patient): Patients can cancel their appointments if needed and
receive confirmation of cancellation.
• Doctor: Doctors can also cancel appointments based on their availability.
• Patients can cancel appointments and notify the doctor.
• Doctors can cancel appointments and send notifications to patients.
• System updates and sends alerts for cancellations.
7. Generate Appointment
• Actors: Admin, Doctor
• Admin: Admin generates reports and tracks appointments made through
the system.
• Doctor: Doctors can generate a list of their scheduled appointments for the
day or week.
• Admin generates reports for appointments, cancellations, and patient
statistics.
• Doctors can access and generate daily or weekly appointment schedules.
8. View Appointment
• Actors: User (Patient), Doctor, Admin
• User (Patient): Patients can view all their past, upcoming, and canceled
appointments.
• Doctor: Doctors can view their upcoming appointments and patient details.
• Admin: Admin can view all appointments made in the system for
monitoring and reporting purposes.
• Patients can view their appointment history and status.
• Doctors can view their schedules and patient details.
• Admin can access system-wide appointment records for reporting.
3.2 CLASS DIAGRAM
Classes and Functionalities for Medicare System
1. User Class
• Attributes: userID, userName, userEmail, userPhone,
userPassword.
• Methods:
o register(): Register user (Patient/Doctor).
o login(): User login.
o updateProfile(): Update personal details.
o forgotPassword(): Password recovery.
2. Patient Class (Inherits User)
• Attributes: patientID, medicalHistory, appointmentHistory.
• Methods:
o searchDoctors(): Search doctors by specialty.
o bookAppointment(): Book an appointment.
o cancelAppointment(): Cancel an appointment.
o provideFeedback(): Leave feedback for doctors.
o viewAppointments(): View past and upcoming
appointments.
3. Doctor Class (Inherits User)
• Attributes: doctorID, doctorSpecialization, consultationFee,
availability.
• Methods:
o manageSchedule(): Manage availability.
o approveAppointment(): Approve or reject appointments.
o conductConsultation(): Conduct consultation.
o generatePrescription(): Generate prescriptions for patients.
o viewFeedback(): View feedback from patients.
4. Appointment Class
• Attributes: appointmentID, patientID, doctorID,
appointmentDate, appointmentTime, status.
• Methods:
o createAppointment(): Create an appointment.
o updateAppointment(): Update appointment details.
o cancelAppointment(): Cancel appointment.
o viewAppointment(): View appointment details.
o approveAppointment(): Approve the appointment.
5. Database Class
• Attributes: databaseURL, databaseName, username, password.
• Methods:
o connect(): Connect to the database.
o executeQuery(): Run queries.
o updateRecord(): Update records.
o storeData(): Store new data.
o deleteData(): Delete data.
6. Admin Class (Inherits User)
• Attributes: adminID, adminName, adminEmail.
• Methods:
o manageUsers(): Manage user registrations.
o viewAppointments(): View all appointments.
o approveAppointment(): Approve or reject appointments.
o generateReports(): Generate reports on system activity.
EX.NO:4 INTERACTION DIAGRAM
Purpose
A Sequence Diagram illustrates the interactions between different objects (or
entities) in the system over time. In the context of the Medicare System, the
sequence diagram captures the flow of messages between the Patient, Doctor,
Admin, and the system components like the Database during specific use cases.
Key Components:
1. Patient: The user who books and manages appointments.
2. Doctor: The user who manages availability and conducts consultations.
3. Admin: The user who oversees the system and manages users.
4. System: The backend processes that handle logic and data flow.
5. Database: Stores user and appointment data
Message Flow:
1. Patient → System: Request to search for doctors.
2. System → Database: Query for available doctors.
3. Database → System: Return available doctors.
4. Patient → System: Select a doctor and appointment time.
5. System → Database: Store appointment details.
6. System → Doctor: Notify doctor of the new appointment.
7. Doctor → System: Approve or reject the appointment.
8. System → Database: Update appointment status.
9. System → Patient: Notify patient about the appointment status.
EX.NO:5 STATE CHART DIAGRAM AND ACTIVITY DIAGRAM
Purpose
An Activity Diagram is used to model the workflow of a system or process. It
visually represents the flow of control or data through various activities or steps
within a process. In the context of the Medicare System, the activity diagram
will capture the flow of actions involved in key use cases, such as booking an
appointment, canceling an appointment, or handling doctor availability.
Key Activities and Workflow
• Start Node: The initial point where the process begins.
• Activity/Action Nodes: Represent specific activities or tasks within the
process.
• Decision Nodes: Represent decision points where the flow can branch
based on conditions.
• Merge Nodes: Where different branches of the flow merge back into one.
• End Node: The point where the process terminates.
• Control Flows: Arrows that indicate the direction of the flow between
activities.
• Swimlanes: Used to separate actions performed by different roles (Patient,
Doctor, Admin, System).
Use Case: Booking an Appointment
The following steps illustrate the workflow of booking an appointment in the
Medicare System through an activity diagram:
1. Start: The process begins with the Patient logging into the system.
2. Patient Searches for Doctor: The patient searches for available doctors
based on criteria (e.g., specialization, location, availability).
3. The system fetches a list of available doctors based on the query.
4. Patient Selects Doctor: The patient selects a doctor from the search results.
5. Patient Chooses Appointment Time: The patient chooses a suitable time
slot based on the doctor’s availability.
6. Check Availability:A decision node checks if the selected time is available.
7. Book Appointment:The system stores the appointment details in the
database, creating a new appointment record.
8. A confirmation message is sent to the patient confirming the appointment.
9. Notify Doctor: The system notifies the doctor about the new appointment.
10.The doctor can either approve or reject the appointment.
11.Doctor Approves Appointment:
12.If the doctor approves, the system updates the appointment status to
"Confirmed."
13.If the doctor rejects, the patient is notified, and the process ends.
14.Patient Receives Appointment Confirmation: The patient receives the final
confirmation of the appointment with the doctor.
15.End: The process ends once the appointment is successfully booked and
confirmed.
EX.NO:6 INTERFACE PATTERN
Purpose
An Interface Diagram in the context of an Online Medical Appointment System
(Medicare) outlines the interactions between various system components and the
user interface. The diagram captures the communication between different
interfaces, like the Calendar, Appointment, End User, Schedule, Database, and
Clinic Homepage. These components collectively manage and display user
interactions, appointments, doctor schedules, and clinic details.
Key Components of the Interface Diagram:
Calendar Interface:
• Displays available dates and time slots for doctors.
• Allows users (patients) to select a specific date and time for their
appointments.
• Integrates with the Schedule Interface to ensure doctor availability.
• Fetches available time slots from the Database.
Appointment Interface:
• Manages the appointment process by handling creation, updates, and
cancellations.
• Provides functionalities to book or view appointments for End Users.
• Links with the Calendar Interface to display available slots and the
Schedule Interface for doctor availability.
• Sends and receives data from the Database to store and retrieve
appointment information.
End User Interface (Patient or Admin Interface):
• The interface through which users interact with the system.
• Provides features like logging in, viewing available doctors, managing
appointments, and profile updates.
• Interfaces with the Appointment Interface to book, view, or cancel
appointments.
• Displays doctor information fetched from the Database.
Schedule Interface:
• Manages the doctor's availability and time slots.
• Allows doctors or admins to update their availability.
• Interfaces with the Calendar Interface to show available slots and
Appointment Interface to manage booked slots.
• Data is fetched from and stored in the Database.
Database Interface:
• Acts as the backend for storing data (appointments, user profiles, doctor
schedules, etc.).
• It is the central repository for all interactions, including data storage and
retrieval.
• Interfaces with other components (such as Appointment Interface,
Calendar Interface, and Schedule Interface) for real-time data exchange.
• Ensures data consistency and integrity.
Clinic Homepage Interface:
• Serves as the front page where users (patients) can find general
information about the clinic, services offered, and available doctors.
• Includes navigational links to other interfaces (e.g., End User Interface,
Appointment Interface, Doctor Schedule Interface).
• May display doctor profiles, services, and patient testimonials.
EX.NO:7 PACKAGE DIAGRAM
Purpose
A Package Diagram provides a high-level view of the system's structure,
organizing the major packages (or components) and their relationships in an
Online Medical Appointment System (Medicare). This description outlines the
key packages within the system, focusing on the integration between Database,
Register Form, Book Appointment, Data Verification, and Medical Report
components.
Key Packages and Components:
1. Database Package:
o Description: Contains all the data-related components and
database management classes.
o Includes:
▪ UserDetails (storing user profiles and authentication details).
▪ AppointmentDetails (storing information about booked
appointments).
▪ DoctorAvailability (maintaining doctor schedules and
availability).
▪ MedicalHistory (records patient’s previous consultations and
medical reports).
o Functions:
▪ Handles CRUD operations (Create, Read, Update, Delete)
for storing and retrieving user and appointment data.
▪ Maintains consistency and integrity of the system’s data.
2. Register Form Package:
o Description: Manages the user registration process.
o Includes:
▪ UserRegistrationForm (form for user registration).
▪ UserValidation (checking the integrity of the data before
storing it).
▪ EmailVerification (sending verification emails for new user
registration).
o Functions:
▪ Accepts user input for registration and validates it.
▪ Sends confirmation emails for new user registration.
▪ Stores user credentials in the Database.
3. Book Appointment Package:
o Description: Manages the appointment booking process.
o Includes:
▪ AppointmentForm (form for booking an appointment).
▪ DoctorSelection (allowing patients to choose doctors).
▪ AppointmentConfirmation (finalizing appointment details
and storing them).
o Functions:
▪ Allows patients to select a date, time, and doctor for their
appointment.
▪ Confirms the booking and stores the appointment details in
the Database.
4. Data Verification Package:
o Description: Ensures the accuracy and integrity of input data.
o Includes:
▪ InputValidation (validating user and appointment data).
▪ ErrorHandling (managing validation errors).
o Functions:
▪ Validates user and appointment data before storing in the
Database.
▪ Handles errors or exceptions to maintain data integrity.
5. Medical Report Package:
o Description: Manages the generation and storage of medical
reports.
o Includes:
▪ ReportGeneration (creating reports based on consultation).
▪ MedicalHistoryRecord (storing patient’s medical history).
o Functions:
▪ Generates and stores medical reports for each patient based on
consultations or treatments.
▪ Updates the Database with medical history details
Purpose of the Package Diagram:
• Visual Representation: Illustrates how different system components
(Register Form, Book Appointment, Data Verification, Medical Report) are
organized and interact.
• Clear Division of Responsibilities: Helps identify and organize the roles
and responsibilities of each component in the system.
• Ease of Understanding: By presenting the major packages, stakeholders
can understand how the system’s elements interconnect and how the
system’s architecture is structured.
• Enhanced Maintenance and Development: Facilitates easier updates and
maintenance by breaking down the system into distinct, manageable
components.
EX.NO:8 USER INTERFACE DESIGN
EX.NO:9 IMPLEMENTATION OF BUSSINESS LAYER USING JDBC ADAPTER
// BusinessLayerAdapter.js
class BusinessLayerAdapter {
constructor(appointmentService, userService, doctorService) {
this.appointmentService = appointmentService; // Handles appointment data
this.userService = userService; // Handles user-related data
this.doctorService = doctorService; // Handles doctor-related data
// Register a new user
async registerUser(userData) {
try {
// Business logic: Validate input data
if (!userData.email || !userData.password) {
throw new Error("Email and password are required.");
// Check if user already exists
const existingUser = await this.userService.getUserByEmail(userData.email);
if (existingUser) {
throw new Error("User already exists with this email.");
// Proceed to register the user
const registeredUser = await this.userService.createUser(userData);
return { success: true, data: registeredUser };
} catch (error) {
return { success: false, message: error.message };
// Book an appointment
async bookAppointment(appointmentData) {
try {
// Business logic: Validate appointment details
const { userId, doctorId, appointmentDate } = appointmentData;
if (!userId || !doctorId || !appointmentDate) {
throw new Error("Missing required fields for booking an appointment.");
// Check doctor availability
const isAvailable = await this.doctorService.checkAvailability(doctorId, appointmentDate);
if (!isAvailable) {
throw new Error("Doctor is not available at the selected time.");
// Book the appointment
const newAppointment = await this.appointmentService.createAppointment(appointmentData);
return { success: true, data: newAppointment };
} catch (error) {
return { success: false, message: error.message };
// Fetch user appointments
async getUserAppointments(userId) {
try {
if (!userId) {
throw new Error("User ID is required.");
// Get appointments for the user
const appointments = await this.appointmentService.getAppointmentsByUserId(userId);
return { success: true, data: appointments };
} catch (error) {
return { success: false, message: error.message };
// Generate medical report
async generateMedicalReport(userId) {
try {
if (!userId) {
throw new Error("User ID is required.");
// Fetch user medical history
const medicalHistory = await this.userService.getMedicalHistory(userId);
if (!medicalHistory) {
throw new Error("No medical history found for the user.");
// Business logic: Generate a report (mock implementation)
const report = {
userId: userId,
reportDate: new Date(),
details: medicalHistory,
};
return { success: true, data: report };
} catch (error) {
return { success: false, message: error.message };
// Example usage
export default BusinessLayerAdapter;
EX.NO:10 IMPLEMENTATION OF DATA LAYER USING JDBC MAPPER
// database.js - Database Connection Setup
const mysql = require('mysql2/promise');
// Establish a connection pool
const pool = mysql.createPool({
host: 'localhost',
user: 'root',
password: 'password',
database: 'medicare',
waitForConnections: true,
connectionLimit: 10,
queueLimit: 0,
});
module.exports = pool;
// AppointmentMapper.js - Data Layer for Appointment Table
const pool = require('./database');
class AppointmentMapper {
// Create a new appointment
async createAppointment(appointment) {
const query = `
INSERT INTO appointments (user_id, doctor_id, appointment_date, status)
VALUES (?, ?, ?, ?)
`;
const values = [appointment.userId, appointment.doctorId, appointment.appointmentDate,
appointment.status];
try {
const [result] = await pool.execute(query, values);
return { success: true, appointmentId: result.insertId };
} catch (error) {
console.error('Error creating appointment:', error.message);
return { success: false, error: error.message };
// Retrieve an appointment by ID
async getAppointmentById(appointmentId) {
const query = `SELECT * FROM appointments WHERE id = ?`;
try {
const [rows] = await pool.execute(query, [appointmentId]);
return rows.length > 0 ? { success: true, data: rows[0] } : { success: false, message: 'Appointment not found'
};
} catch (error) {
console.error('Error fetching appointment:', error.message);
return { success: false, error: error.message };
// Update an appointment
async updateAppointment(appointmentId, updatedFields) {
const setClause = Object.keys(updatedFields)
.map((key) => `${key} = ?`)
.join(', ');
const values = [...Object.values(updatedFields), appointmentId];
const query = `UPDATE appointments SET ${setClause} WHERE id = ?`;
try {
const [result] = await pool.execute(query, values);
return result.affectedRows > 0 ? { success: true } : { success: false, message: 'No changes made' };
} catch (error) {
console.error('Error updating appointment:', error.message);
return { success: false, error: error.message };
}
// Delete an appointment
async deleteAppointment(appointmentId) {
const query = `DELETE FROM appointments WHERE id = ?`;
try {
const [result] = await pool.execute(query, [appointmentId]);
return result.affectedRows > 0 ? { success: true } : { success: false, message: 'Appointment not found' };
} catch (error) {
console.error('Error deleting appointment:', error.message);
return { success: false, error: error.message };
module.exports = AppointmentMapper;
