Developer Guide
- Design
- Implementation
- Documentation, logging, testing, configuration, dev-ops
-
Appendix: Requirements
- Product scope
- User Stories
-
Use Cases
- Use case: UG01 - Create Patient Record
- Use case: UG02 - List Patients
- Use case: UG03 - Edit Patient Record
- Use case: UG04 - Delete Patient Record
- Use case: UG05 - Add Appointment
- Use case: UG06 - List All Appointments
- Use case: UG07 - Edit Appointment
- Use case: UG08 - Delete Appointment
- Use case: UG09 - Add Medical History
- Use case: UG10 - List Medical History
- Use case: UG11 - Edit Medical History
- Use case: UG12 - Delete Medical History
- Use case: UC13 - Find Patient by Name
- Use case: UC14 - Clear All Listed Patients
- Use case: UC15 - Switch Between Different Tabs
- Use case: UC16 - Access Help Page
- Use case: UC17 - Exit Application
- Non-Functional Requirements
- Glossary
- Appendix: Instructions for manual testing
- Appendix: Planned Enhancements
Design
Architecture
The Architecture Diagram given above explains the high-level design of the App.
Given below is a quick overview of main components and how they interact with each other.
Main components of the architecture
Main
(consisting of
classes Main
and MainApp
) is in
charge of the app launch and shut down.
- At app launch, it initializes the other components in the correct sequence, and connects them up with each other.
- At shut down, it shuts down the other components and invokes cleanup methods where necessary.
The bulk of the app’s work is done by the following four components:
-
UI
: The UI of the App. -
Logic
: The command executor. -
Model
: Holds the data of the App in memory. -
Storage
: Reads data from, and writes data to, the hard disk.
Commons
represents a collection of classes used by multiple other components.
How the architecture components interact with each other
The Sequence Diagram below shows how the components interact with each other for the scenario where the user issues the command delete-patient 1
.
Each of the four main components (also shown in the diagram above),
- defines its API in an
interface
with the same name as the Component. - implements its functionality using a concrete
{Component Name}Manager
class (which follows the corresponding APIinterface
mentioned in the previous point.
For example, the Logic
component defines its API in the Logic.java
interface and implements its functionality using
the LogicManager.java
class which follows the Logic
interface. Other components interact with a given component
through its interface rather than the concrete class (reason: to prevent outside component’s being coupled to the
implementation of a component), as illustrated in the (partial) class diagram below.
The sections below give more details of each component.
UI component
The API of this component is specified
in Ui.java
The UI consists of a MainWindow
that is made up of parts
e.g.CommandBox
, ResultDisplay
, PatientListPanel
, AppointmentListPanel
, MedicalHistoryPanel
, StatusBarFooter
etc. All these, including the MainWindow
,
inherit from the abstract UiPart
class which captures the commonalities between classes that represent parts of the
visible GUI.
The UI
component uses the JavaFX UI framework. The layout of these UI parts are defined in matching .fxml
files that
are in the src/main/resources/view
folder. For example, the layout of
the MainWindow
is specified
in MainWindow.fxml
The UI
component,
- executes user commands using the
Logic
component. - listens for changes to
Model
data so that the UI can be updated with the modified data. - keeps a reference to the
Logic
component, because theUI
relies on theLogic
to execute commands. - depends on some classes in the
Model
component, as it displaysPatient
object residing in theModel
.
Logic component
API : Logic.java
Here’s a (partial) class diagram of the Logic
component:
The sequence diagram below illustrates the interactions within the Logic
component, taking execute("delete-patient 1")
API
call as an example.
DeleteCommandParser
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
How the Logic
component works:
- When
Logic
is called upon to execute a command, it is passed to anClinicBookParser
object which in turn creates a parser that matches the command (e.g.,DeleteCommandParser
) and uses it to parse the command. - This results in a
Command
object (more precisely, an object of one of its subclasses e.g.,DeleteCommand
) which is executed by theLogicManager
. - The command can communicate with the
Model
when it is executed (e.g. to delete a person). - The result of the command execution is encapsulated as a
CommandResult
object which is returned back fromLogic
.
Here are the other classes in Logic
(omitted from the class diagram above) that are used for parsing a user command:
How the parsing works:
- When called upon to parse a user command, the
ClinicBookParser
class creates anXYZCommandParser
(XYZ
is a placeholder for the specific command name e.g.,AddCommandParser
) which uses the other classes shown above to parse the user command and create aXYZCommand
object (e.g.,AddCommand
) which theClinicBookParser
returns back as aCommand
object. - All
XYZCommandParser
classes (e.g.,AddCommandParser
,DeleteCommandParser
, …) inherit from theParser
interface so that they can be treated similarly where possible e.g, during testing.
Model component
API : Model.java
The Model
component,
- stores the clinic book data i.e., all
Patient
objects (which are contained in aUniquePatientList
object). - stores the currently ‘selected’
Patient
objects (e.g., results of a search query) as a separate filtered list which is exposed to outsiders as an unmodifiableObservableList<Patient>
that can be ‘observed’ e.g. the UI can be bound to this list so that the UI automatically updates when the data in the list change. - stores a
UserPref
object that represents the user’s preferences. This is exposed to the outside as aReadOnlyUserPref
objects. - does not depend on any of the other three components (as the
Model
represents data entities of the domain, they should make sense on their own without depending on other components)
Storage component
API: Storage.java
The Storage
component,
- can save both clinic book data and user preference data in JSON format, and read them back into corresponding objects.
- inherits from both
ClinicBookStorage
andUserPrefStorage
, which means it can be treated as either one (if only the functionality of only one is needed). - depends on some classes in the
Model
component (because theStorage
component’s job is to save/retrieve objects that belong to theModel
)
Common classes
Classes used by multiple components are in the seedu.cc.commons
package.
Implementation
Patient
A Patient
has the following fields:
- Each
Patient
has a unique combination ofName
,Age
,Nric
,Email
andPhone
- Each
Patient
has aPatientCMedicalHistory
. - Each
Patient
has aPatientAppointmentList
. - Each class has their respective getter methods
The class diagram below is an overview of the Patient
class.
Implementation of Patient Commands
Commands related to Patient
:
-
AddCommand
- Adds aPatient
to theClinicBook
. -
DeleteCommand
- Deletes aPatient
from theClinicBook
. -
EditCommand
- Edits aPatient
in theClinicBook
. -
FindCommand
- Finds aPatient
in theClinicBook
. -
ListCommand
- Lists allPatient
in theClinicBook
.
All the commands above are parsed by the ClinicBookParser
and then by the corresponding parsers (i.e. AddCommandParser
,
DeleteCommandParser
etc.) After which, the command (i.e. AddCommand
, DeleteCommand
) will be executed.
Medical History
User can add a MedicalHistoryEvent
with the Date
with format YYYY-MM-DD,
the MedicalCondition
and the Treatment
received by the patient.
The MedicalHistoryEvent
will then be shown as a list of MedicalHistoryEvent
in the Patient
’
s PatientMedicalHistory
.
The MedicalHistory will be facilitated using the FilteredList, although the current implementation does not allow
filtering.
When the user starts an application, there will be an empty ClinicBookMedicalHistory
. It will be populated when the
user executes list-medical-history
command.
The PatientMedicalHistory
for each Patient
will be stored in clinicbook.json as a nested attribute.
The difference between PatientMedicalHistory
class and ClinicBookMedicalHistory
class is
that PatientMedicalHistory
is a list of
MedicalHistoryEvent
while ClinicBookMedicalHistory
is a list of MedicalHistoryEvent
that is currently being
displayed.
Commands related to MedicalHistoryEvent
:
-
AddMedicalHistoryEventCommand
- Adds aMedicalHistoryEvent
to aPatient
. -
DeleteMedicalHistoryEventCommand
- Deletes aMedicalHistoryEvent
of aPatient
. -
EditMedicalHistoryEventCommand
- Edits aMedicalHistoryEvent
of aPatient
. -
ListMedicalHistoryEventCommand
- Lists allMedicalHistoryEvent
of aPatient
.
An example usage scenario and how the medical history mechanism behaves at each step is shown below.
- The user launches the application for the first time.
ClinicBookMedicalHistory
contains no default list ofMedicalHistoryEvent
. - The user inputs
list-medical-history
to list all medical history.Ui
passes the input toLogic
.Logic
then uses a fewParser
classes to extract layers of information out as seen from steps 3 to 5. -
Logic
passes the user input toClinicBookParser
.ClinicBookParser
identifies that this is aListMedicalHistoryEventCommand
through the word “list-md”. It then creates aListMedicalHistoryEventCommandParser
to parse it into aListMedicalHistoryEventCommand
and return. - Logic finally gets the
ListMedicalHistoryEventCommand
and execute it. The execution firstly callsModel#getFilteredPatientList()
to get the patients that are currently being displayed. It then gets thePatient
from the list using the index provided by the user. It then callsModel#listMedicalHistoryEvents(Patient patient)
to setClinicBookMedicalHistory
as the list ofMedicalHistoryEvent
that belongs to the patient. This execution then returns aCommandResult
toUi
, containing the response to the user. - UI displays the response in the CommandResult. In addition, UI will change to display the list
of
MedicalHistoryEvent
after model updatesfilteredMedicalHistoryEvents
, sinceUi
is constantly listening for the change inModel
.
The Sequence Diagram below shows how the components interact with each other for the above mentioned scenario
Appointment
The appointment-related features are facilitated by the appointment
package. The appointment
package
includes AppointmentEvent
, PatientAppointmentList
and ClinicBookAppointmentList
.
The PatientAppointmentList
is an attribute for each Patient
and stores a list of AppointmentEvent
; and the attribute will be stored in clinicbook.json
The ClinicBookAppointmentList
is a list of AppointmentEvent
that is used for display purposes.
When the user starts an application, there will be an empty ClinicBookCLinicBookAppointment
. It will be populated when the
user executes list-appointments
command.
Commands related to AppointmentEvent
:
-
AddAppointmentEventCommand
- Adds aAppointmentEvent
to aPatient
. -
DeleteAppointmentEventCommand
- Deletes aAppointmentEvent
of aPatient
. -
EditAppointmentEventCommand
- Edits aAppointmentEvent
of aPatient
. -
ListAppointmentEventsCommand
- Lists allAppointmentEvent
of aPatient
.
An example usage scenario and how the appointment event mechanism behaves at each step is shown below.
- The sequence starts with a user inputting the command “list-appointments 1” into the application’s main user interface (UI), specifically in the
MainWindow
. - This input is then passed from the
MainWindow
to theLogicManager
. - The LogicManager forwards the command string to the ClinicBookParser for parsing. The ClinicBookParser identifies the
command as an ListAppointmentEventsCommand and creates an ListAppointmentEventsCommandParser, which parses the details of the command
and creates an
ListAppointmentEventsCommand
object. - The
LogicManager
then calls theexecute
method on theListAppointmentEventsCommand
object. - The
ListAppointmentEventsCommand
then interacts with theModel
to retrieve the list ofAppointmentEvent
of thePatient
. TheModel
then returns the list ofAppointmentEvent
to theListAppointmentEventsCommand
. - After retrieving the list of
AppointmentEvent
, theListAppointmentEventsCommand
returns aCommandResult
object to theLogicManager
, which then returns theCommandResult
object to theMainWindow
for display to the user.
The sequence diagram below illustrates the interactions of the components for the scenario where the user issues the command list-appointments
Prescription
The prescription-related features are facilitated by the Prescription
class. The Prescription
class is included in the appointment
package.
The set of Prescription
class is an attribute for each AppointmentEvent
, each Prescription
contains one Medicine name and the attribute will be stored in clinicbook.json
.
Each Prescription
is associated with a AppointmentEvent
and the Prescription
will be shown as a list of Prescription
in the AppointmentEvent
.
Commands related to Prescription
:
-
AddPrescriptionCommand
- AddsPrescription
of anAppointmentEvent
of aPatient
. -
DeletePrescriptionCommand
- DeletesPrescription
of anAppointmentEvent
of aPatient
. -
EditPrescriptionCommand
- Edits thePrescription
of anAppointmentEvent
of aPatient
.
An example usage scenario and how the prescription mechanism behaves at each step is shown below.
- The process begins with the user inputting a command to add a prescription (“add-prescription 1 pi/1 mn/Panadol”) into the system main window.
- This input is then passed from the
MainWindow
to theLogicManager
. - The LogicManager forwards the command string to the ClinicBookParser for parsing. The ClinicBookParser identifies the
command as an AddPrescriptionCommand and creates an AddPrescriptionCommandParser, which parses the details of the command
and creates an
AddPrescriptionCommand
object. - The
LogicManager
then calls theexecute
method on theAddPrescriptionCommand
object, which interacts with anAppointmentEvent
object, and encapsulates the details of the patient’s appointment and prescription to be added. - The
AddPrescriptionCommand
then interacts with theModel
to update the patient’s appointment with the new prescription. - After updating the model, the
AddPrescriptionCommand
returns aCommandResult
object to theLogicManager
, which then returns theCommandResult
object to theMainWindow
for display to the user.
The sequence diagram below illustrates the interactions of the components for the scenario where the user issues the command add-prescription
[Proposed] Undo/redo feature
Proposed Implementation
The proposed undo/redo mechanism is facilitated by the VersionedClinicBook
class. The VersionedClinicBook
class
extends ClinicBook
with an undo/redo history, stored internally as clinicBookStateList
and currentStatePointer
.
Additionally, it implementes the following operations:
-
VersionedClinicBook#commit()
— Saves the current clinic book state in its history. -
VersionedClinicBook#undo()
— Restores the previous clinic book state from its history. -
VersionedClinicBook#redo()
— Restores a previously undone clinic book state from its history.
These operations are exposed in the Model
interface as Model#commitClinicBook()
, Model#undoClinicBook()
and Model#redoClinicBook()
respectively.
Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
Step 1. The user launches the application for the first time. The VersionedClinicBook
will be initialized with the initial clinic book state, and the currentStatePointer
pointing to that single clinic book state.
Step 2. The user executes delete-patient 5
command to delete the 5th patient in the clinic book. The delete-patient
command calls Model#commitClinicBook()
, causing the modified state of the clinic book after the delete 5
command executes to be saved in the clinicBookStateList
, and the currentStatePointer
is shifted to the newly inserted clinic book state.
Step 3. The user executes add-patient n/David …
to add a new patient. The add-patient
command also calls Model#commitClinicBook()
, causing another modified clinic book state to be saved into the clinicBookStateList
.
Model#commitClinicBook()
, so the clinic book state will not be saved into the clinicBookStateList
.
Step 4. The user now decides that adding the patient was a mistake, and decides to undo that action by executing the undo
command. The undo
command will call Model#undoClinicBook()
, which will shift the currentStatePointer
once to the left, pointing it to the previous clinic book state, and restores the clinic book to that state.
currentStatePointer
is at index 0, pointing to the initial ClinicBook state, then there are no previous ClinicBook states to restore. The undo
command uses Model#canUndoClinicBook()
to check if this is the case. If so, it will return an error to the user rather
than attempting to perform the undo.
The following sequence diagram shows how the undo operation works:
UndoCommand
should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
The redo
command does the opposite — it calls Model#redoClinicBook()
, which shifts the currentStatePointer
once to the right, pointing to the previously undone state, and restores the clinic book to that state.
currentStatePointer
is at index clinicBookStateList.size() - 1
, pointing to the latest clinic book state, then there are no undone ClinicBook states to restore. The redo
command uses Model#canRedoClinicBook()
to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
Step 5. The user then decides to execute the command list-patients
. Commands that do not modify the clinic book, such as list-patients
, will usually not call Model#commitClinicBook()
, Model#undoClinicBook()
or Model#redoClinicBook()
. Thus, the clinicBookStateList
remains unchanged.
Step 6. The user executes clear
, which calls Model#commitClinicBook()
. Since the currentStatePointer
is not pointing at the end of the clinicBookStateList
, all clinic book states after the currentStatePointer
will be purged. Reason: It no longer makes sense to redo the add n/David …
command. This is the behavior that most modern desktop applications follow.
The following activity diagram summarizes what happens when a user executes a new command:
[Proposed] Pharmacy Integration
Proposed Implementation
The proposed pharmacy integration is facilitated by the Pharmacy
class. The Pharmacy
class extends ClinicBook
with
a list of Medicine
and Prescription
that is stored internally as medicineList
and prescriptionList
.
Additionally, it implementes the following operations:
-
Pharmacy#addMedicine()
— Adds aMedicine
to themedicineList
. -
Pharmacy#deleteMedicine()
— Deletes aMedicine
from themedicineList
. -
Pharmacy#addPrescription()
— Adds aPrescription
to theprescriptionList
. -
Pharmacy#deletePrescription()
— Deletes aPrescription
from theprescriptionList
. -
Pharmacy#findMedicine()
— Finds aMedicine
from themedicineList
. -
Pharmacy#listMedicine()
— Lists allMedicine
from themedicineList
. -
Pharmacy#listPrescription()
— Lists allPrescription
from theprescriptionList
. -
Pharmacy#updateMedicine()
— Updates aMedicine
from themedicineList
. -
Pharmacy#updatePrescription()
— Updates aPrescription
from theprescriptionList
.
Documentation, logging, testing, configuration, dev-ops
Appendix: Requirements
Product scope
Target user profile:
- medical administrators who need to oversee the operations of a clinic who has a substantial number of patients
- favor desktop applications over other platforms
- prefer a CLI-based interface over a GUI-based interface
- are comfortable typing commands
Value proposition: The app helps the user to manage patient records, medical histories and appointments.
User Stories
Priorities: High (must have) - * * *
, Medium (nice to have) - * *
, Low (unlikely to have) - *
Priority | As a … | I can … | To fulfill … |
---|---|---|---|
* * * |
medical administrator | add a patient record | Efficiently maintain patient records |
* * * |
medical administrator | list all patients | Easily view the complete patient list |
* * * |
medical administrator | edit a patient record | Keep patients’ information up to date |
* * * |
medical administrator | delete a patient record | Remove patients who are no longer under care |
* * |
medical administrator | give patients different priorities | Prioritize patient care effectively |
* |
medical administrator | list patients by priority | Quickly access patients based on priority |
* * * |
medical administrator | add an appointment | Schedule appointments for patients |
* * * |
medical administrator | list all appointments of a patient | Access a patient’s complete appointment history |
* * * |
medical administrator | edit an appointment | Modify appointment details as needed |
* * * |
medical administrator | delete an appointment | Eliminate unnecessary appointments |
* |
medical administrator | cancel an appointment | Efficiently manage appointment cancellations |
* * |
medical administrator | sort appointments by date | Easily view appointments in chronological order |
* |
medical administrator | mark an appointment as missed | Record the status of missed appointments |
* |
medical administrator | mark an appointment as attended | Record the status of attended appointments |
* * |
medical administrator | add prescriptions to an appointment | Easily document prescribed medications for patients |
* * * |
medical administrator | add a medical history | Keep comprehensive medical histories for patients |
* * * |
medical administrator | list a patient’s medical history | Access and review patient medical histories |
* * * |
medical administrator | edit a medical history | Update patient medical histories as necessary |
* * * |
medical administrator | delete a medical history | Remove outdated or irrelevant medical histories |
* * * |
medical administrator | find a patient | Quickly locate specific patients |
* * |
medical administrator | find an appointment | Easily search for specific appointments |
* * |
medical administrator | find a medical history | Quickly retrieve specific patient medical histories |
* |
medical administrator | undo previous action | Correct any inadvertent actions |
* |
medical administrator | redo previous action | Reapply actions that were previously undone |
* * * |
medical administrator | exit the app | Close the application with ease |
* * * |
medical administrator | get help | Access a list of available commands and assistance |
Use Cases
Use case: UG01 - Create Patient Record
Actor: Medical Staff
MSS
- User issues the command to add a new patient record with the required details.
- System adds the new patient record.
-
System displays a success message along with the details of the added patient.
Use case ends.
Extensions
- 2a. The input details are invalid.
-
2a1. System shows an error message.
Use case ends.
-
Use case: UG02 - List Patients
Actor: Medical Staff
MSS
- User requests to list all patients.
-
System retrieves and shows a list of patients.
Use case ends.
Extensions
- 2a. The list is empty.
-
2a1. System informs the user that the list is empty.
Use case ends.
-
Use case: UG03 - Edit Patient Record
Actor: Medical Staff
MSS
- User requests to edit a specific patient record using the patient’s index in the list and provides the new details.
- System validates the input details.
- System updates the patient record with the new details.
-
System displays a success message along with the updated details of the patient.
Use case ends.
Extensions
- 2a. The given index or details is invalid.
-
2a1. System shows an error message with the correct input format.
Use case ends.
-
Use case: UG04 - Delete Patient Record
Actor: Medical Staff
MSS
- User requests to delete a specific patient record using the patient’s index in the list.
- System deletes the patient record.
-
System displays a success message.
Use case ends.
Extensions
- 1a. The given index is invalid.
-
1a1. System shows an error message.
Use case ends.
-
Use case: UG05 - Add Appointment
Actor: Medical Staff
MSS
- User issues the command to schedule a new appointment for a patient using the patient’s index and provides the appointment details.
- System validates the input details.
- System adds the new appointment.
-
System displays a success message along with the details of the added appointment.
Use case ends.
Extensions
- 2a. The input details are invalid.
-
2a1. System shows an error message.
Use case ends.
-
Use case: UG06 - List All Appointments
Actor: Medical Staff
MSS
- User requests to list all appointments.
-
System retrieves and shows a list of appointments.
Use case ends.
Extensions
- 2a. The list is empty.
-
2a1. System informs the user that there are no appointments.
Use case ends.
-
Use case: UG07 - Edit Appointment
Actor: Medical Staff
MSS
- User requests to edit a specific appointment using the appointment’s index in the list and provides the new details.
- System validates the input details.
- System updates the appointment with the new details.
-
System displays a success message along with the updated details of the appointment.
Use case ends.
Extensions
- 2a. The given index is invalid.
-
2a1. System shows an error message.
Use case ends.
-
- 2b. The input details are invalid.
-
2b1. System shows an error message.
Use case ends.
-
Use case: UG08 - Delete Appointment
Actor: Medical Staff
MSS
- User requests to delete a specific appointment using the appointment’s index in the list.
- System deletes the appointment.
-
System displays a success message.
Use case ends.
Extensions
- 1a. The given index is invalid.
-
1a1. System shows an error message.
Use case ends.
-
Use case: UG09 - Add Medical History
Actor: Medical Staff
MSS
- User issues the command to add a medical history for a patient using the patient’s index and provides the medical history details.
- System validates the input details.
- System adds the medical history to the patient’s record.
-
System displays a success message along with the details of the added medical history.
Use case ends.
Extensions
- 2a. The input details are invalid.
-
2a1. System shows an error message.
Use case ends.
-
Use case: UG10 - List Medical History
Actor: Medical Staff
MSS
- User requests to list the medical history of a specific patient using the patient’s index.
-
System retrieves and shows the medical history of the patient.
Use case ends.
Extensions
- 2a. The given index is invalid.
-
2a1. System shows an error message.
Use case ends.
-
- 2b. There is no medical history for the selected patient.
-
2b1. System informs the user that there is no medical history for the selected patient.
Use case ends.
-
Use case: UG11 - Edit Medical History
Actor: Medical Staff
MSS
- User requests to edit a specific medical history record using the medical history’s index and the patient’s index, and provides the new details.
- System validates the input details.
- System updates the medical history record with the new details.
-
System displays a success message along with the updated details of the medical history.
Use case ends.
Extensions
- 2a. The given indexes are invalid.
-
2a1. System shows an error message.
Use case ends.
-
- 2b. The input details are invalid.
-
2b1. System shows an error message.
Use case ends.
-
Use case: UG12 - Delete Medical History
Actor: Medical Staff
MSS
- User requests to delete a specific medical history record using the medical history’s index and the patient’s index.
- System deletes the medical history record.
-
System displays a success message.
Use case ends.
Extensions
- 1a. The given indexes are invalid.
-
1a1. System shows an error message.
Use case ends.
-
Certainly! Below are the use cases created from the user stories:
Use case: UC13 - Find Patient by Name
Actor: Medical Staff
MSS
- Medical Staff requests to find a patient using the patient’s name.
- System searches for the patient and displays the relevant patient records.
-
Medical Staff views the patient’s information.
Use case ends.
Extensions
- 2a. No patient record matches the given name.
-
2a1. System informs the Medical Staff that no matching record was found.
Use case ends.
-
Use case: UC14 - Clear All Listed Patients
Actor: Medical Staff
MSS
- Medical Staff selects the option to clear all listed patients.
- System removes all patient records from the current view.
-
Medical Staff views the cleared list.
Use case ends.
Use case: UC15 - Switch Between Different Tabs
Actor: Medical Staff
MSS
- Medical Staff selects the tab they wish to view (patient details, medical history, or appointments).
-
System displays the content of the selected tab.
Use case ends.
Use case: UC16 - Access Help Page
Actor: Medical Staff
MSS
- Medical Staff selects the option to view the help page.
- System displays the help page with guidance on how to use the application.
-
Medical Staff views and interacts with the help page as needed.
Use case ends.
Use case: UC17 - Exit Application
Actor: Medical Staff
MSS
- Medical Staff chooses the option to exit the application.
-
System securely closes the application.
Use case ends.
Non-Functional Requirements
- Performance Requirements: The app should be able to handle up to 500 patient records without significant performance degradation.
- Security Requirements: All patient data must be stored securely to ensure confidentiality and privacy.
- Usability Requirements: The app should be user-friendly, with a clean and intuitive CLI interface that can be easily navigated by healthcare professionals.
- Compatibility Requirements: The app should be compatible with both iOS and Android devices, ensuring accessibility for a wide range of users.
Glossary
- App: Refers to the CareCentral application.
- Healthcare Professional: A user who is a certified medical practitioner, including doctors, nurses,
- and other medical staff.
- Patient Record: A digital file within the app containing all relevant information about a patient, including
- medical history, prescriptions, and appointmentEvent records.
- User: Refers to the healthcare professionals using the CareCentral app.
Appendix: Instructions for manual testing
Given below are instructions to test the app manually.
Launch and shutdown
-
Initial launch
-
Download the jar file and copy into an empty folder
-
Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
-
-
Saving window preferences
-
Resize the window to an optimum size. Move the window to a different location. Close the window.
-
Re-launch the app by double-clicking the jar file.
Expected: The most recent window size and location is retained.
-
Deleting a patient
-
Deleting a patient while all patients are being shown
-
Prerequisites: List all patients using the
list-patients
command. Multiple patients in the list. -
Test case:
delete-patient 1
Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated. -
Test case:
delete-patient 1
Expected: No patient is deleted. Error details shown in the status message. Status bar remains the same. -
Other incorrect delete commands to try:
delete
,delete x
,...
(where x is larger than the list size)
Expected: Similar to previous.
-
Saving data
Dealing with missing/corrupted data files:
-
If the application is launched and shut down at least once, there will be one local database in json format, i.e.
clinicbook.json
. Make sure that the generatedclinicbook.json
is not modified to ensure the completeness and accuracy of the data. -
In the case of
clinicbook.json
being corrupted,i. Look up for the corrupted part of the
clinicbook.json
, manually delete the corrupted entry of patient, this method requires more technical skills on handling json file.ii. If attempt above is in vain, delete
clinicbook.json
, and launch CareCentral again. All user manipulation on entries and diaries will be cleared.
Appendix: Planned Enhancements
Consistent Naming of Commands
Current State
The current system exhibits inconsistency in command naming. For example, add-appt
is used for adding an appointment, while list-appointments
is used for listing appointments.
Planned Enhancement
We aim to standardize command naming for better consistency and user experience. The proposed changes include renaming commands like add-appt
to add-appointment
and similarly, aligning other command names to this format. This change will bring uniformity and predictability to the command structure, making it more intuitive for users.
Implementation Details
- Command Mapping: A mapping will be created between old and new command names to assist in the transition.
- Documentation Update: All references in the documentation will be updated to reflect the new command names.
Unique NRIC Validation
Current State
The system does not currently validate the uniqueness of the National Registration Identity Card (NRIC) of a patient, leading to potential data integrity issues.
Planned Enhancement
We will implement a validation mechanism to ensure that each patient’s NRIC is unique within the system.
Implementation Details
- Database Constraint: Introduce a unique constraint on the NRIC field in the patient database.
- Error Handling: Implement error handling to provide a clear message if a user attempts to enter a duplicate NRIC.
- Data Migration: Review current data for duplicates and provide a strategy for resolving them.
Warning for Clear Command
Current State
The clear
command executes without any prior warning, risking accidental deletion of all patient records.
Planned Enhancement
We plan to introduce a confirmation step before the execution of the clear
command.
Implementation Details
- Confirmation Prompt: Introduce an interactive prompt requiring explicit user confirmation before proceeding with the clear operation.
- Command-Line Argument: Optionally, provide a command-line argument to bypass the confirmation for automated scripts.
Validation for Appointment Date
Current State
Appointment dates are not validated to be in the future, allowing for potential scheduling errors.
Planned Enhancement
We plan to enforce a validation rule ensuring that all appointment dates are set in the future.
Implementation Details
- Date Validation Logic: Introduce logic to check the appointment date against the current date.
- User Feedback: Provide immediate feedback to the user if an entered date is not in the future.
- Adjustable Threshold: Allow a configurable threshold for how far in the future an appointment must be.
Enhanced Find Function
Current State
The current find
function is limited to searching only by full names of patients.
Planned Enhancement
We plan to enhance the find
function to allow searching for patients using other fields, not just full names, and to enable partial name matching.
Implementation Details
-
Extended Search Capabilities: Modify the
find
function to search within fields like phone number, NRIC, address, etc., in addition to names. - Partial Name Matching: Implement an algorithm that allows for partial matching of names, making the search more flexible and user-friendly.
- Updated User Interface: Adjust the user interface to accommodate these new search capabilities and provide clear instructions on how to use them.
- Performance Considerations: Ensure that the enhanced search function remains efficient, even with the expanded search capabilities.