SDD-IEEE NeurologyDepartmentManagementSystem Sample

Download as pdf or txt
Download as pdf or txt
You are on page 1of 53

Software Design Description for NeuroSystem Page 1

1. Introduction
1.1 Purpose

The purpose of the proposed web application is to improve the efficiency and effectiveness of
patient management in the neurology department of hospitals in Malaysia. By introducing this
system, hospitals will be able to manage patient data more effectively, schedule appointments
efficiently, and perform early MRI screening of the brain with a high degree of accuracy. This will
enable hospitals to diagnose patients early and allocate the necessary resources for treatment,
ultimately reducing patients' waiting time to meet doctors and improving the quality of healthcare
services. The system's goal is to alleviate the issues of overcrowdedness, workforce shortage, and
lack of proper management systems currently faced by hospitals in Malaysia, particularly in the
departments that manage cancer patients.

A. Manage patient data : Neuro system provides a centralized platform to store, organize, and
manage patient data. This includes information of the patients, diagnoses and other
relevant healthcare information. The system enables healthcare professionals to access
and update patient records in a secure and efficient manner.

B. Appointment Scheduling : The application enables nurses to schedule patient’s


appointments with their preferred doctors. This involves the coordination of available time
slots, patient preferences, and provider availability to ensure seamless scheduling and
optimal utilization of resources.

C. The Statistics feature : It provides healthcare professionals with a consolidated view of


showcasing the number of patients having each diagnosis, enabling them to make informed
decisions, monitor progress, and provide appropriate care. It streamlines the retrieval and
review of patient data, promoting efficient and effective healthcare delivery.

D. AI diagnosis : The AI assists users in detecting their diagnosis by sending predictions of the
specific diagnosis of a patient from the patient MRI scan.

1.2 Definitions, Acronyms and Abbreviations

● AI Artificial Intelligence

● NEURODMS Neurology Department Management System

● GPU Graphics Processing Unit

● GUI Graphical User Interface

● HTTP Hypertext Transfer Protocol

● HTML Hypertext Markup Language

● MySQL My Structured Query Language

● PHP Hypertext Preprocessor


Software Design Description for NeuroSystem Page 2

● RAM Random-Access Memory

● SDD Software Design Description

● XAMPP X-operating system, Apache, MySQL, PHP, Perl

1.3 Intended Audience and Reading Suggestions

The SDD document is intended for a diverse audience with a range of jobs and responsibilities.
The following table breaks down the many reader categories the publication is intended for, along
with their specific areas of interest:

1. Developers : the technical details and requirements of the software system are especially
important for developers. They will focus on sections that describe the system as well as
the software components, data structures, algorithms, and programming interfaces. They
might also be intrigued by any specific standards or development methodologies mentioned
in the document.

2. Project Managers : Resource management, scheduling, and overall project planning are
the responsibilities of project managers. They will pay attention to sections that provide an
overview of the project's objectives, deliverables, due dates, and dependencies. The parts
on project hazards, restrictions, and quality assurance practices will also get their attention.

3. Marketing Staff : Marketing staff members are interested in comprehending the key
features and benefits of the software product in order to effectively promote the software
product to potential clients. They will pay close attention to the sections that describe the
unique selling points of the product, the target market, market research, and any marketing
strategies or variables.

4. Users : Individuals who will use the software system are interested in how it will fulfil their
demands and be beneficial to them. They will be particularly interested in sections that
cover the system's capabilities, user interface, and user experience.

5. Testers : Testers need to be aware of the system requirements in order to create effective
test cases and provide enough test coverage. They will focus on the sections that describe
the user scenarios, functional and non-functional requirements, and acceptance criteria for
the system. Additionally, they will be impacted by any specific testing standards or practices
included in the text.

6. Documentation Writers : The sections describing the specifications for documents like
user manuals, installation guides, and system management manuals will be of interest.
They will also refer to any additional guidelines for creating documentation as well as
sections that provide an overview of the system's capabilities and usage.
Software Design Description for NeuroSystem Page 3

While the Software Design Description(SDD) document targets a broader audience, this particular
document is specifically aimed at individuals directly engaged in the development of the Neurology
Department Management System (NEURODMS). Sequential reading of this document is not
necessary. Users are encouraged to navigate directly to the sections that are most relevant to
them.

1. Introduction : An overview of the DMS project is provided, which includes a summary of its
goals, objectives, project scope, as well as general and significant system constraints
related to the platform being discussed.

2. High Level Design : High-level design includes an overview of the system architecture,
including components, modules, and their interactions.and highlight the functional and
non-functional requirements that drove the high-level design as well as describing the major
use cases and their interactions to showcase how the system will meet the user's needs.

3. Detailed Design : This section includes all the details related to software architects, system
designers, developers, and testers. They are interested in understanding the low-level
details of the system, including component design, interfaces, algorithms, and data
structures. Provide in-depth explanations of each module, including class diagrams,
sequence diagrams, and state diagrams.

4. GUI Mockups : This section shows screen layouts or user interface mockups for the
NEURODMS project.

5. Appendix A Approval : The essential details on the document's approval procedure are
often included in the approval section of the software design description report. It might
have the project managers', key stakeholders', or other personnel's signatures or approvals.
have examined and approved the description of the software design. This appendix serves
as formal documentation indicating the document has been examined and given the
go-ahead for implementation or further development.

6. Appendix B Glossary : The software design description has a glossary that defines and
discusses technical jargon, acronyms, abbreviations, and domain-specific language. The
vocabulary used in the text must be understood by all readers, including stakeholders and
developers, thanks to the help of this appendix. By providing a consolidated reference for
subjects that some readers might not be familiar with, it improves clarity and prevents
ambiguity.

7. Appendix C Sequence Diagram : Order Diagram offers intricate sequence diagrams that
show how different software system objects, actors, or components interact with one
another. Sequence diagrams show the direction of control and the timing of message
exchanges when certain scenarios or use cases are carried out. These diagrams aid in
understanding the logic and process flows by giving a visual representation of the system's
dynamic activity.
Software Design Description for NeuroSystem Page 4

1.4 Product Scope

The scope of the Neurology Department Management System (NEURODMS) is to provide users
with a comprehensive and convenient platform for managing and consulting their diagnosis and
care needs. NEURODMS aims to detect patients’ diagnosis, promote regular check-ups, and
enhance the overall health care experience to their patients. This SDD is also aimed at specifying
requirements of software to be developed and it can also be applied to assist in the usage of the
system. It focuses on the system, the users and the admin itself. The subsystem will handle all of
the activities between the users.
Software Design Description for NeuroSystem Page 5

1.5 References

● Taya, M., & Karexeprt. (2023). Detailed Introduction of Hospital Management System

(HMS). KareXpert.

https://www.karexpert.com/blogs/what-is-hospital-management-system/#:~:text=What

%20is%20Hospital%20Management%20System,are%20completed%20swiftly%20an

d%20effectively
Software Design Description for NeuroSystem Page 6

2. High Level Design

2.1 Design Considerations


1. Scalability

The NEURODMS system is designed to handle a growing number of users, patients, and
data volumes. Consider architectural patterns and technologies that support scalability,
such as distributed computing, load balancing, and horizontal scaling.

2. Reliability and Availability

The system is highly reliable and available to ensure uninterrupted access to critical
functionality. Incorporate redundancy, fault tolerance mechanisms, and backup and
recovery strategies to minimize downtime and data loss.

3. Performance

The system should be designed to provide optimal performance for critical operations such
as patient record retrieval, appointment scheduling, and real-time monitoring. Consider
performance optimizations such as caching, efficient algorithms, and database indexing.

4. Security

Security is crucial to protect patient data and comply with privacy regulations. Design the
system with robust authentication, authorization, and encryption mechanisms. Ensure
secure communication channels and implement security best practices to prevent
unauthorized access and data breaches.

2.2.1 Design Options

Design Option : MRI Scan System Detection by AI

Design Objective : The objective of the MRI Scan System Detection using AI design is to develop
a system that utilizes artificial intelligence (AI) techniques to accurately detect and identify the
presence of MRI scan systems within a given environment. The design aims to leverage AI
algorithms and machine learning models to achieve highly reliable and automated detection
capabilities.

Option 1 : The AI assists users in detecting their diagnosis by sending predictions of the specific
diagnosis of a patient from the patient MRI scan.

a) Data Collection and Preparation : The design should include mechanisms to collect and
prepare a comprehensive dataset of MRI scan system images or relevant data. This
dataset will be used for training AI models to recognize and classify MRI machines
accurately.

b) AI Model Development : The design should involve the development of AI models, such
as convolutional neural networks (CNNs) or deep learning architectures, for MRI scan
Software Design Description for NeuroSystem Page 7

system detection. The models should be trained on the collected dataset, optimizing their
performance to achieve high accuracy and robustness in identifying MRI machines.

c) Detection and Localization : The design should enable the AI models to detect and
localize the presence of MRI scan systems within the given environment. The models
should analyze input images or sensor data to identify regions or patterns associated with
MRI machines, allowing for precise localization of their positions.

d) Type Identification : The design should include AI algorithms capable of accurately


identifying the type or model of the detected MRI scan systems. The models should be
trained to analyze distinctive features, such as machine appearance, components, or
operational specifications, enabling them to classify the MRI machines into specific types or
models.

e) Real-time Detection and Monitoring : The design should enable real-time detection and
monitoring of MRI scan systems using the trained AI models. The system should
continuously analyze incoming data or images to detect the presence of MRI machines and
provide real-time updates regarding their locations, types, and operational status.

Alternative Option :

In the future, the design can explore the use of ensemble learning techniques to further improve
the accuracy of MRI scan system detection. Ensemble methods, such as combining multiple AI
models or using boosting algorithms, can help mitigate errors and enhance overall detection
performance.

2.2.2 Assumptions

● Availability of Sufficient Computing Resources


The design assumes the availability of sufficient computing resources to support the
system's performance and scalability requirements.

● Availability of Skilled Development and Operational Teams


The design assumes the availability of skilled personnel for development, deployment, and
maintenance of the system.

2.2.3 Constraints

1. Regulatory Compliance

The design must adhere to regulatory requirements such as HIPAA to ensure data privacy
and security.

2. Integration with Existing Systems

The design needs to consider integration requirements with existing hospital systems to
enable seamless data exchange and interoperability.

3. Performance and Scalability


Software Design Description for NeuroSystem Page 8

The design should meet performance requirements and be scalable to handle increasing
user load and data volumes.

2.2 System Level Desired Behavior

1. Login: Allows users to authenticate and access the system. Users will be required to
provide their login credentials, such as a username and password, to gain access to their
accounts and the system's features.

2. Register: Enables new users to create an account in the system. Users will need to provide
necessary information, such as their name, contact details, and desired login credentials, to
register as a new user. Once registered, users can log in to the system using their chosen
credentials.

3. Add New Patient: Allows authorized users to add new patient information to the system.
Users can input relevant details, including the patient's name, contact information, medical
history, and any other required data. This functionality ensures that patient records are
accurately recorded and stored in the system.

4. Delete Patient: Enables authorized users to remove patient information from the system.
Users can select a patient record and confirm the deletion, ensuring that outdated or
unnecessary patient data is appropriately removed from the system.

5. Update Patient Data: Allows authorized users to modify and update patient information in
the system. Users can edit specific fields, such as contact details, medical history, or other
relevant data, ensuring that patient records remain up to date and accurate.

6. Update Patient Schedule: Permits authorized users to make changes to a patient's


schedule within the system. Users can adjust appointment dates, times, or locations,
ensuring efficient management of patient appointments and minimizing scheduling conflicts.

7. Search Patient Data: Enables users to search and retrieve specific patient information
from the system. Users can input search criteria, such as a patient's name, ID number, or
diagnosis, to retrieve relevant patient records. This functionality streamlines the process of
accessing specific patient information within the system.

8. Detect Patient Diagnosis: Utilizes AI-trained models to detect specific diagnoses from
patient MRI scans. The system employs advanced image processing algorithms and
machine learning techniques to analyze MRI images and provide insights into the patient's
diagnosis. This functionality assists healthcare professionals in accurately identifying and
classifying patient conditions based on MRI scan data.

9. View Patient Stats: Allows users to access and view statistical data related to patients.
This includes graphical representations, such as bar charts or graphs, showcasing the
distribution of diagnoses among the patient population. For example, the system can
display the number of patients with different types of tumors (e.g., Glioma tumor,
Meningioma tumor, No tumor) to provide a visual overview of the patient demographics.
This functionality helps in analyzing patient data and identifying patterns or trends for
research or decision-making purposes.
Software Design Description for NeuroSystem Page 9

2.3 Logical Representation of the Architecture

1. User Authentication and Management:


● This component handles user registration, login, password management, and
authentication processes.
● It ensures that only registered and authenticated users can access the system.
● The component communicates with the database to store and retrieve user account
information.
2. Nurses Functionality
● Assist doctors in patient management and care.
● Need to access patient data, update schedules, and record vital signs or other
relevant information.
● Able to add new patient information, delete and update patient Information, update
patient schedule, search patient information, use Ai Trained model in detecting the
specific diagnosis of a patient from the patient MRI scan, view patient statistical data
and view patient to doctor schedule.
3. Doctors Functionality
● Able to search patient data, view patient and doctor schedules and view patient
statistics.
● Benefit from the AI-trained model for assisting in diagnosing patients based on MRI
scans.

2.4 Architectural Component Overview

1. Authentication and Image Verification Component


● This component is responsible for handling user authentication and image
verification processes.
● It ensures that only authorized users can access the system by validating their
credentials and verifying the authenticity of uploaded images.
● The component includes modules or services for user login, password
management, and image verification.
● It communicates with the user database to retrieve user account information and
validate user credentials.
● The image verification module uses image processing algorithms or AI models to
verify the authenticity of uploaded images, such as MRI scans.

2. Patient Management Component


● This component handles the management of patient-related information and
processes.
● It provides functionalities for adding, updating, and deleting patient information.
Software Design Description for NeuroSystem Page 10

● The component includes modules or services for managing patient demographics,


medical history, diagnoses, and treatment plans.
● It communicates with the patient database to retrieve and store patient information.
● The component may also integrate with other systems or modules for generating
reports, tracking patient progress, or scheduling appointments.

3. Scheduling and Appointment Component


● This component manages the scheduling and appointment processes within the
hospital system.
● It allows users to schedule and manage appointments for patients.
● The component includes modules or services for appointment creation, scheduling
conflicts resolution, and sending appointment notifications to users.
● It communicates with the scheduling database to store and retrieve appointment
information.
● The component may also integrate with other systems or modules for calendar
management and resource allocation.

4. AI Diagnosis Component
● This component leverages AI models and algorithms for assisting in patient
diagnosis based on MRI scans.
● It uses trained models to analyze MRI images and provide diagnostic insights or
predictions.
● The component includes modules or services for uploading and processing MRI
images, running the AI models, and presenting the diagnosis results.
● It may communicate with external AI platforms or frameworks for model training or
utilize local AI infrastructure.

5. Reporting and Analytics Component:


● This component handles the generation and presentation of reports and analytics
related to patient data and system usage.
● It provides functionalities for generating statistical reports, visualizing patient data,
and monitoring system performance.
● The component includes modules or services for data aggregation, analysis, and
visualization.
● It communicates with the patient database and other relevant data sources to
retrieve data for reporting and analytics purposes.

2.4.1 Software Dependencies

The requirements stated in the SDD are influenced by several assumed factors and dependencies.
Firstly, it is assumed that the Neurology Department will have access to high-quality MRI scans for
accurate diagnosis using the AI module. If the availability or quality of the scans is compromised, it
can impact the effectiveness of the system. Secondly, the technical proficiency of users, including
doctors and nurses are expected to vary. The web application should cater to different skill levels
and provide a user-friendly interface to ensure usability and adoption. In terms of dependencies,
the successful integration of the PHP system with the AI module is crucial.

Seamless communication and accurate diagnosis rely on bridging the technological gap between
the two components. Additionally, the web application depends on popular browsers like Chrome,
Firefox, Microsoft Edge, Opera, or Safari for user access. Compatibility with Windows (7, 8, 10, or
11) or MacOS is necessary for the server-side components. Finally, stable and reliable network
Software Design Description for NeuroSystem Page 11

connectivity is a dependency to ensure users can access and utilize the system effectively. These
assumed factors and dependencies should be carefully considered, validated, and communicated
to stakeholders throughout the project to minimize risks and ensure the successful implementation
of the software system.

2.5 Process Architecture

Process Architecture for User Authentication and Management:

1. User Registration:
● User initiates the registration process by providing necessary information.
● The system validates the provided information, ensuring its completeness and
accuracy.
● If the information is valid, the system creates a new user account and stores the
user's details in the database.

2. User Login:
● User enters their login credentials (username and password) on the login page.
● The system verifies the provided credentials by comparing them with the stored user
account information in the database.
● If the credentials are valid, the system grants access to the user and authenticates
their session.

3. Password Management:
● Users can request a password reset if they forget their password.
● The system provides options for password recovery, such as sending a password
reset link to the user's registered email or answering security questions.
● Once the user completes the password reset process, the system updates the
password in the database.

4. User Authentication:
● Each time a user tries to access a protected resource or perform a restricted action,
the system checks their authentication status.
● The system verifies the user's identity by validating their session and comparing it
against the stored user account information.
● If the user is authenticated, the system allows them to proceed with the requested
action.

Process Architecture for Nurses Functionality:

1. Accessing Patient Data:


● Nurses log in to the system using their credentials, initiating a session.
● The system verifies the authentication status of the nurse.
● Once authenticated, the nurse can access patient data, including medical records,
treatment plans, and vital sign measurements.

2. Updating Patient Schedules:


● Nurses can view and update the schedules of assigned patients.
● The system provides an interface for nurses to modify appointment times, add or
remove tasks, and reschedule patient visits.
Software Design Description for NeuroSystem Page 12

● The updated schedules are saved in the database and reflected in the system for
other healthcare professionals to see.

3. Recording Vital Signs and Patient Information:


● Nurses can record and update vital signs, symptoms, and other relevant patient
information.
● The system offers forms or templates for data entry, ensuring standardized
documentation.
● The recorded information is stored in the database and can be accessed by
authorized healthcare professionals.

4. Using AI-Trained Model for Patient Diagnosis:


● Nurses can utilize the AI-trained model integrated into the system to assist in
diagnosing patients based on MRI scans.
● The nurse uploads the patient's MRI scan to the system, which processes the data
using the AI model.
● The system provides the nurse with the predicted diagnosis or relevant insights
based on the analysis.

5. Viewing Patient Statistical Data:


● Nurses can access patient statistical data, such as graphs or charts, displaying the
number of patients with specific diagnoses.
● The system generates statistical reports based on the data stored in the database
and presents it to the nurse for analysis or reference.

Process Architecture for Doctors Functionality:

1. Searching Patient Data:


● Doctors log in to the system using their credentials and authenticate their session.
● The system allows doctors to search and retrieve patient data, including medical
history, test results, and treatment plans.
● The search functionality queries the database based on specified criteria and
returns relevant patient information.

2. Viewing Patient and Doctor Schedules:


● Doctors can access their own schedule and view the schedules of patients assigned
to them.
● The system provides a calendar view or a list of appointments, displaying
appointment times, patient names, and visit details.
● The schedules are synchronized with the database, ensuring real-time updates and
avoiding conflicts.

3. Viewing Patient Statistics:


● Doctors can access patient statistical data, such as the distribution of specific
diagnoses or treatment outcomes.
● The system generates statistical reports based on the data stored in the database
and presents it to the doctor for analysis and decision-making.

4. AI-Trained Model for Assisting in Diagnosis:


Software Design Description for NeuroSystem Page 13

● Doctors can leverage the AI-trained model integrated into the system to aid in
diagnosing patients based on MRI scans.
● The doctor uploads the patient's MRI scan to the system, which processes the data
using the AI model.
● The system provides the doctor with the predicted diagnosis or relevant insights to
support their clinical decision-making.

2.6 Deployment Architecture

It is necessary to provide concise explanations of how to use the software system in a range of
Portable Document Format (PDF) document types (including instructions, tutorials, and frequently
asked questions).
Software Design Description for NeuroSystem Page 14

3. Detailed Design
3.1 Class Diagram

3.1.1 Scenarios

Doctors

Scenario 1 : Patient Consultation


● The doctor logs into the hospital system and checks their assigned patients for the day.
● They review the patient list, which includes basic information like name, age, and assigned
ward number.
● The doctor prioritizes their patients based on the severity of their condition or the urgency of
their needs.

Scenario 2 : Appointment
● The doctor checks the appointment schedule to see if they have any scheduled
consultations or follow-up visits.
● They review the details of each appointment, including the patient's name, reason for the
visit, and scheduled time.
Software Design Description for NeuroSystem Page 15

● The doctor ensures they are prepared with the necessary information and resources for
each appointment.

Scenario 3 : Medical Record


● The doctor accesses the medical records system to review the patients' medical history.
● They examine the patients' previous diagnoses, treatment plans, and any relevant test
results or imaging studies.
● The doctor familiarizes themselves with the patients' conditions and notes any changes
since the last visit.

Scenario 4 : Ward Rounds


● The doctor visits the hospital wards to check on their assigned patients who are admitted.
● They review each patient's medical chart, including vital signs, lab results, and nursing
notes.
● The doctor examines the patients, asks about their symptoms, and assesses their progress
or any complications.

Nurses

Scenario 1 : Patient Assessment and Vital Signs Monitoring


● The nurse logs into the hospital system and receives a handover report from the previous
shift, which includes information about the assigned patients and their conditions.
● They conduct initial patient assessments, including measuring vital signs such as
temperature, blood pressure, heart rate, and respiratory rate.
● The nurse records the vital signs and documents any abnormalities or changes in the
patients' condition.

Scenario 2 : Updating A Patient Schedule


● involves making changes or modifications to their appointment or visit schedule within a
healthcare facility.
● This focused on managing and adjusting the timing, duration, or details of a patient's
scheduled appointments, consultations, treatments, or procedures.
● The nurse's objective is to ensure an accurate and updated schedule that accommodates
changes in the patient's needs, availability, or healthcare requirements.

Scenario 3 : Documentation and Reporting


● The nurse maintains accurate and up-to-date documentation of patient assessments,
interventions, and responses to treatments.
● They record interactions with patients and any changes in the patients' condition.
● The nurse communicates essential information to the healthcare team during shift
handovers and reports any significant developments or concerns.

Scenario 4 : Updating Patient Information


● If there are any changes in the patient's condition, the nurse updates the medical record
accordingly.
● They document the patient's vital signs, symptoms, and any observed changes or
concerns.
● The nurse records the interventions they performed, such as administering medications,
carrying out procedures, or providing patient education.
Software Design Description for NeuroSystem Page 16

3.2 Class Summary

3.2.1 Class: User

Attributes: staffID: int


staffName : String
staffAge: int
staffGender: String
department: String
Software Design Description for NeuroSystem Page 17

register(): Pre-condition:

- The user should not be logged in or


authenticated.
- Required registration information should be
provided.
- The provided username and email address
should not already be associated with an
existing account in the system.

Post-condition:

- The user's registration information is


successfully stored in the system.
- A new user account is created with the
provided username and email address.
- The user can now proceed to log in to the
system using their registered credentials.

Algorithm:

- Check if the provided username and email


address are available and not already
associated with an existing account.
- If the username and email address are
available, create a new user account with the
provided credentials and personal details.
- Store the user account information in the
database.

Error handling/Exception processing:

- Error handling may be necessary if the required


registration information is missing or invalid,
such as an already existing username or email
address.
Software Design Description for NeuroSystem Page 18

login(): Pre-condition:

- The user should not be logged in or


authenticated.
- Valid login credentials, such as a username
and password, should be provided.
- The provided credentials should match an
existing user account in the system.

Post-condition:

- The user is successfully authenticated and


logged in to the system.
- A session or authentication token is generated
and associated with the user.
- The user gains access to the system's
functionalities and personalized data.

Algorithm:

- Check if the provided login credentials


(username and password) match an existing
user account.
- If the credentials are valid, authenticate the
user and generate a session or authentication
token.

Error handling/Exception processing:

- Error handling may be required if the provided


login credentials are invalid or do not match
any existing user accounts in the system.
Software Design Description for NeuroSystem Page 19

logout(): Pre-condition:
- The user should be logged in or authenticated.

Post-condition:
- The user's session or authentication token is
invalidated and no longer valid for accessing
system resources.
- The user is logged out of the system and loses
access to personalized data and functionalities.
- Any unsaved changes or pending actions are
completed or discarded as appropriate.
Algorithm:
- Invalidate the user's session or authentication
token to indicate that they are no longer logged
in.
- Clean up any session-related data or resources
associated with the user.
- Redirect the user to the appropriate logout
page or display a confirmation message.
Software Design Description for NeuroSystem Page 20

3.2.2 Class: Nurse

Attributes: nurseID: String


skills: String
shift: String
Software Design Description for NeuroSystem Page 21

registerPatient(): Pre-condition:
- Required input fields should be
provided.
- The patient's information should not
already exist in the system.

Post-condition:

- The patient's details are successfully


added to the system.
- The patient's information can be
accessed and updated in the future.

Algorithm:

- Check if the patient's information is


complete and valid.
- Check if the patient's information
already exists in the system.
- If the information is valid and not
already present, create a new patient
record.
- Store the patient's details and the
generated ID in the database.

Error handling/Exception processing:

- Error handling may be required if the


required input fields are missing or
invalid.
Software Design Description for NeuroSystem Page 22

viewPatientDetails():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.

Post-condition:

- The system displays the patient's


details, including their name, contact
information, and medical history.
- The information is presented in a
readable and understandable format.

Algorithm:

- Check if the unique identifier exists in


the system.
- Retrieve the patient's details associated
with the unique identifier.
- Display the patient's information on the
screen.

Error handling/Exception processing:

- Error handling may be necessary if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 23

managePatientMedicalRecords():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.

Post-condition:

- The user can access and modify the


patient's medical records.
- New medical records can be added,
existing records can be updated, and
old records can be removed.

Algorithm:

- Check if the unique identifier exists in


the system.
- Retrieve the patient's medical records
associated with the unique identifier.
- Allow the user to add, modify, or
remove medical records as needed.
- Save the updated medical records in
the system.
Software Design Description for NeuroSystem Page 24

managePatientAppointment():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.
- The appointment details, such as date,
time, and doctor/nurse availability,
should be available.

Post-condition:

- The patient's appointment is


successfully scheduled or modified.
- The system updates the doctor’s
schedule accordingly.

Algorithm:

- Check the availability of doctors for the


requested appointment.
- If the desired time slot is available,
schedule the appointment for the
patient.
- Update the doctor's schedule to reflect
the new appointment.
Software Design Description for NeuroSystem Page 25

updatePatientDetails():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.
- The updated patient information should
be available.

Post-condition:

- The patient's details are successfully


updated in the system.
- The updated information is saved and
can be retrieved when needed.

Algorithm:

- Check if the unique identifier exists in


the system.
- Retrieve the patient's details associated
with the unique identifier.
- Allow the user to modify the patient's
information.
- Save the updated patient details in the
system.

Error handling/Exception processing:

- Error handling may be required if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 26

deletePatient():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.

Post-condition:

- The patient's details, medical records,


and appointment information are
permanently removed from the system.
- The patient's information is no longer
accessible.

Algorithm:

- Check if the unique identifier exists in


the system.
- Remove the patient's details, medical
records, and appointment information
from the system.

Error handling/Exception processing:

- Error handling may be necessary if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 27

deleteDoctor():
Pre-condition:

- A unique identifier should be provided.

Post-condition:

- The doctor's details and associated


information, such as appointments and
medical records, are permanently
removed from the system.
- The doctor's information is no longer
accessible.

Algorithm:

- Check if the unique identifier exists in


the system.
- Remove the doctor's details and
associated appointments from the
system.

Error handling/Exception processing:

- Error handling may be required if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 28

updateNurseDetails():
Pre-condition:

- A unique identifier should be provided.


- The updated nurse information should
be available.

Post-condition:

- The nurse's details are successfully


updated in the system.
- The updated information is saved and
can be retrieved when needed.

Algorithm:

- Check if the unique identifier exists in


the system.
- Retrieve the nurse's details associated
with the unique identifier.
- Allow the user to modify the nurse's
information.
- Save the updated nurse details in the
system.

Error handling/Exception processing:

- Error handling may be necessary if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 29

viewDoctorAvailability():
Pre-condition:

- A unique identifier should be provided.

Post-condition:

- The system displays the doctor's


availability schedule, including available
time slots for appointments.
- The information is presented in a
readable and understandable format.

Algorithm:

- Check if the unique identifier exists in


the system.
- Retrieve the doctor's availability
schedule associated with the unique
identifier.
- Display the doctor's available time slots
for appointments on the screen.

Error handling/Exception processing:

- Error handling may be required if the


provided unique identifier is invalid or
not found in the system.
Software Design Description for NeuroSystem Page 30

3.2.3 Class: Doctor

Attributes: doctorID: int


specialty: String
yearExperience: int
certification: String

viewPatientSchedule():
Pre-condition:

- A unique identifier, in this case their IC,


should be provided.

Post-condition:

- The system displays the patient's


schedule.
- The information is presented in a readable
and understandable format.

Algorithm:

- Check if the unique identifier exists in the


system.
- Retrieve the patient's schedule associated
with the unique identifier.
- Display the patient's schedule in a
readable format on the screen.
Software Design Description for NeuroSystem Page 31

updateDoctorDetails():
Pre-condition:

- A unique identifier should be provided.

Post-condition:

- The doctor's details are successfully


updated in the system.
- The updated information is saved and can
be retrieved when needed.
- The updated details are reflected in the
system, ensuring accurate and up-to-date
information about the doctor.

Algorithm:

- Check if the unique identifier exists in the


system.
- Retrieve the doctor's details associated
with the unique identifier.
- Allow the user to modify the doctor's
information.
- Save the updated doctor details in the
system.
Software Design Description for NeuroSystem Page 32

4. GUI Mockups
Software Design Description for NeuroSystem Page 33
Software Design Description for NeuroSystem Page 34
Software Design Description for NeuroSystem Page 35
Software Design Description for NeuroSystem Page 36
Software Design Description for NeuroSystem Page 37

Appendix A: Approval
The undersigned acknowledge they have reviewed the NeuroSystem Software Design Description and agree
with the approach it presents. Changes to this Software Design Description will be coordinated with and
approved by the undersigned or their designated representatives.

1. Signature: _______________________________________ Date: 23/06/2023


Name: AZLIE BIN JOHARI
Student Id: 2022497838
Role: Team Leader

2. Signature: _______________________________________ Date: 23/06/2023


Name: MUHD. DZIKRULLAH BIN KALANA
Student Id: 2022873958
Role: Software Engineer

3. Signature: _______________________________________ Date: 23/06/2023


Name: LIECOLM AK ROBIN JOHNSON
Student Id: 2022611034
Role: Software Developer

4. Signature: _______________________________________ Date: 23/06/2023


Name: ALIYA SHAHIRAH BINTI ABDUL RAZAK
Student Id: 2022470606
Role: Software Tester

5. Signature: _______________________________________ Date: 26/05/2023


Name: SYAHIRAH BINTI FAIZAL
Student Id: 2022898428
Role: Software Requirement Analyst
Software Design Description for NeuroSystem Page 38

Appendix B: Glossary
● Artificial Intelligence (AI) is the ability of a computer or a machine controlled by a
computer to do tasks that are usually done by humans because they require human
intelligence and discernment

● NEURODMS Neurology Department Management System is implemented to help


students in answering mathematical problems efficiently. The subsystem will handle all of
the activities between the users and the database.

● GPU Graphics Processing Unit is a specialized electronic circuit designed to manipulate


and alter memory to accelerate the creation of images in a frame buffer intended for output
to a display device.

● GUI Graphical User Interface is a form of user interface that allows users to interact with
electronic devices through graphical icons and audio indicators such as primary notation,
instead of text-based UIs, typed command labels or text navigation.

● HTTP Hypertext Transfer Protocol is an application layer protocol in the Internet protocol
suite model for distributed, collaborative, hypermedia information systems.

● HTML Hypertext Markup Language is the standard markup language for documents
designed to be displayed in a web browser. It can be assisted by technologies such as
Cascading Style Sheets and scripting languages such as JavaScript.

● MySQL My Structured Query Language is an open-source relational database


management system (RDBMS) that is widely used for managing and storing structured
data.

● PHP Hypertext Preprocessor is an open-source server-side scripting language designed


specifically for web development. It is widely used to create dynamic and interactive web
pages and applications.

● RAM Random-Access Memory is a type of computer memory that is used to temporarily


store data that the computer's processor needs to access quickly. It plays a crucial role in
providing temporary storage for data that is actively used by the computer's processor. It is
an essential component in determining the speed and efficiency of a computer system.

● SDD Software Design Description is a document that provides a detailed description of


the software design for a specific system or software application. It serves as a reference
for developers, designers, and stakeholders involved in the software development process.

● XAMPP X-operating system, Apache, MySQL, PHP and Perl is a free and open-source
software package that provides a local development environment for creating and testing
dynamic web applications.
Software Design Description for NeuroSystem Page 39

Appendix C: Sequence Diagram


1. Login (Nurse)
Software Design Description for NeuroSystem Page 40

2. Login (Doctor)
Software Design Description for NeuroSystem Page 41

3. Register (Doctor)
Software Design Description for NeuroSystem Page 42

4. Register (Nurse)
Software Design Description for NeuroSystem Page 43

5. Add new patient


Software Design Description for NeuroSystem Page 44

6. Delete a patient data


Software Design Description for NeuroSystem Page 45

7. Inserting a patient diagnosis


Software Design Description for NeuroSystem Page 46

8. Update Patient Data


Software Design Description for NeuroSystem Page 47

9. Update Patient Schedule


Software Design Description for NeuroSystem Page 48

10. Search patient data (Doctor)


Software Design Description for NeuroSystem Page 49

11. Search patient data (Nurse)


Software Design Description for NeuroSystem Page 50

12. View patient statistics (Doctor)


Software Design Description for NeuroSystem Page 51

13. View patient statistics (Nurse)


Software Design Description for NeuroSystem Page 52

14. View patient doctor schedule (Nurse)


Software Design Description for NeuroSystem Page 53

15. View patient doctor schedule (Doctor)

You might also like