PROJECT: DocX

Overview

DocX is a desktop application designed for receptionists in clinics. It features patient management, doctor management, medical history management and appointment management. The user interacts with it using a CLI, and it has a GUI created with JavaFX. It is written in Java, and has about 10 kLoC.

Summary of contributions

  • Major enhancement: added appointment management features

    • What it does: allows the user to manage appointments between patients and doctors.

    • Justification: This is a core feature to allow appointments to be managed in an organized manner.

    • Highlights: Appointments can be prone to many issues as it deals with date and time. Therefore, extreme care must be taken when handling user input to prevent any issues with invalid date and time combinations. Also there are numerous constraints, such as new appointments can only be created during business hours, be in the future and patients can only complete their appointments after they are over.

  • Minor enhancement:

    • UI: Enhanced the user interface to include 4 sections, a section to display patients, a section to display doctors, a section to display medical history, a section to display appointments. Also added the ability to switch an entire panel to display the current relevant content.

    • Model: Utilized the singleton design pattern is synchronize the generation of unique patient and doctor IDs across the entire application to ensure there are no duplicate IDs.

  • Code contributed: https://nus-cs2103-ay1819s2.github.io/cs2103-dashboard/#=undefined&search=amuletxheart

  • Other contributions:

    • Project management:

      • Managed releases v1.1 - v1.4 (4 releases) on Github

      • Managed disputes regarding features and missed internal deadlines between teammates.

    • Documentation:

      • Updated the AboutUs and ContactUs page with correct photos and links (#6)

      • Wrote the user stories and use case sections of the DeveloperGuide (#49)

    • Community:

      • PRs reviewed and gave suggestions to improve workflow and boost productivity (examples: 1, 2)

      • Assigned user stories and tasks to team members (list)

      • Reported bugs and suggestions for other teams in the class (list)

      • Parts of the appointment management features I added were utilized by several teammates (examples: 1, 2)

Contributions to the User Guide

Given below are sections I contributed to the User Guide. They showcase my ability to write documentation targeting end-users.

Introduction

DocX is a desktop clinic management application designed for receptionists in small clinics. Even today, many receptionists in small clinics are still using pen and paper to track patients' information, which can be prone to human errors and reduced productivity if the number of patients is large. Our clinic management application is designed specifically to make this process much easier for them.

The features we provide include:

  • Record and manage patients coming to the clinic

  • Record and manage doctors in the clinic

  • Record and manage medical histories of patients

  • Make and manage appointments for patients

  • Record and manage medicines in the clinic and prescriptions given by doctors

While it has a GUI, most of the user interactions happen using a CLI (Command Line Interface). More importantly, DocX is optimized for those who prefer to work with a Command Line Interface (CLI) while still having the benefits of a Graphical User Interface (GUI). No technical knowledge on programming or terminal commands is needed. If you can type normal words fast, DocX can get your clinic management tasks done faster than traditional GUI apps.

Interested? Jump to the [Quick Start] to get started. Enjoy!

Adding an appointment: add-appt

Adds an appointment between a patient and a doctor
Format: add-appt pid/PATIENT_ID did/DOCTOR_ID d/DATE_OF_APPT t/START_TIME

  • All of the fields must be provided.

  • Appointments can only be made in the future, as determined by system time.

  • New appointments default to the ACTIVE status. Appointments cannot be deleted once created, only marked as CANCELLED if required.

  • Doctors are free during office hours from 9am to 12pm and 1pm to 5pm. (12pm to 1pm not availabe)

  • Appointments are in 1-hour blocks.

  • User is notified if the doctor is not available during the specified time.

  • PATIENT_ID and DOCTOR_ID are positive integers and must refer to existing patients and doctors in the system.

  • DATE_OF_APPT must be in the format YYYY-MM-DD and be a valid date on the calendar.

  • START_TIME must be in the 24-hour format HH:00 with no minutes specified as each appointment is 1 hour long.

Examples:

  • add-appt pid/1 did/7 d/2019-06-01 t/09:00
    Adds an appointment with patient ID '1' and doctor ID '7' on 1st June 2019 at 9am.

  • add-appt pid/3 did/9 d/2019-06-01 t/13:00
    Adds an appointment with patient ID '3' and doctor ID '9' on 1st June 2019 at 1pm.

Listing appointments : list-appt

Shows a list of appointments in the system. Can be used with or without optional keywords to filter the result.
Format: list-appt [pid/PATIENT_ID] [did/DOCTOR_ID] [d/DATE_OF_APPT] [t/START_TIME] [s/STATUS] [c/CHRONOLOGY]

  • If none of the optional fields are provided, all appointments are shown.

  • Appointments are filtered by patient ID, doctor ID, date of appointment, start time, appointment status, and appointment chronology respectively.

  • All the optional filters can be mixed and matched independently to obtain the required output.

  • PATIENT_ID and DOCTOR_ID are positive integers and refer to valid patients and doctors in the system.

  • DATE_OF_APPT must be in the format YYYY-MM-DD and be a valid date on the calendar.

  • START_TIME must be in the format HH:00 and be in 1 hour blocks, i.e. 09:00, 10:00.

  • STATUS is case insensitive and must be one of the valid statuses: ACTIVE, CANCELLED, MISSED, COMPLETED.

  • CHRONOLOGY is case insensitive refers to whether an appointment is in the past or future. Can be PAST or FUTURE.

Examples:

  • list-appt
    Lists all appointments.

  • list-appt c/FUTURE
    Lists all appointments that are in the future.

  • list-appt pid/1
    Lists all appointments with patient ID 1.

  • list-appt pid/1 did/7
    Lists all appointments with patient ID 1 and doctor ID 7.

  • list-appt d/2018-06-01 t/09:00
    Lists all appointments with date 2018-06-01 and time 09:00.

  • list-appt s/ACTIVE
    Lists all appointments that are marked as ACTIVE.

Changing an appointment status : mark-appt

Mark an appointment as ACTIVE, CANCELLED, MISSED or COMPLETED
Format: mark-appt INDEX s/NEW_STATUS

  • All of the fields must be provided.

  • Appointment status is not cases sensitive. i.e. both ACTIVE and active is allowed.

  • Change appointment status of the appointment at the specified INDEX.

  • The index refers to the index number shown in the displayed appointment list. The index must be a positive integer 1, 2, 3, …​

  • Status meaning: ACTIVE - The appointment is scheduled and active. CANCELLED - The appointment has been cancelled. MISSED - The appointment was missed by the patient. COMPLETED - The patient successfully completed the appointment.

  • Only appointments in the past can be marked as MISSED or COMPLETED. Appointments in the future can only be marked ACTIVE or CANCELLED.

Examples:

  • mark-appt 1 s/CANCELLED
    The appointment with INDEX 1 is cancelled.

  • mark-appt 3 s/MISSED
    The appointment with INDEX 3 was missed. Note that this can only be done to elapsed appointments.

APPOINTMENT COMMANDS

  • Add a new appointment add-appt pid/PATIENT_ID did/DOCTOR_ID d/DATE_OF_APPT t/START_TIME
    e.g. add-appt pid/1 did/1 d/2019-06-01 t/09:00

  • Listing appointments list-appt [pid/PATIENT_ID] [did/DOCTOR_ID] [d/DATE_OF_APPT] [t/START_TIME] [s/STATUS] [c/CHRONOLOGY]
    e.g. list-appt

  • Changing an appointment status : mark-appt INDEX s/NEW_STATUS e.g. mark-appt 1 s/CANCELLED

Contributions to the Developer Guide

Given below are sections I contributed to the Developer Guide. They showcase my ability to write technical documentation and the technical depth of my contributions to the project.

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 add-appt pid/1 did/7 d/2019-06-01 t/09:00.

LogicComponentSequenceDiagram AddAppointment
Figure 1. Component interactions for add-appt pid/1 did/7 d/2019-06-01 t/09:00 command

The sections below give more details of each component.

Logic component

LogicClassDiagram
Figure 2. Structure of the Logic Component

API : Logic.java

  1. Logic uses the DocXParser class to parse the user command.

  2. This results in a Command object which is executed by the LogicManager.

  3. The command execution can affect the Model (e.g. adding a new appointment).

  4. The result of the command execution is encapsulated as a CommandResult object which is passed back to the Ui.

  5. In addition, the CommandResult object can also instruct the Ui to perform certain actions, such as displaying help to the user or showing a different panel (appointment panel).

Given below is the Sequence Diagram for interactions within the Logic component for the execute("add-appt pid/1 did/7 d/2019-06-01 t/09:00") API call. Interactions with other components such as UI or Model is omitted or simplified for clarity.

AddAppointmentSequenceDiagramForLogic
Figure 3. Interactions Inside the Logic Component for the add-appt …​ Command

Add Appointment Feature

Appointments are created to facilitate future appointments between patients and doctors. A patient can have none or multiple appointments, a doctor can have none or multiple appointments. An appointment cannot overlap with a patient’s or doctor’s existing appointments. This is determined if the date and time overlaps. An appointment must specify a patient ID, doctor ID, date and time.

The following class diagram shows the modelling of appointments in our application. Details in Patient and Doctor are omitted for clarity.

AppointmentClassDiagram

Current Implementation

The add appointment feature is enabled by the classes: Appointment, FutureAppointment, AddAppointmentCommandParser, AddAppointmentCommand and JsonAdaptedAppointment.

  • Appointment - This is an entity class to store information regarding an appointment, such as patient ID, Doctor ID, date, time and status.

  • FutureAppointment - This is an entity class that extends Appointment. This class ensures that a newly created appointment is always in the future compared to the system time. The comparison between date and time is done using java.time.LocalDateTime. It is not recommended to perform such checks manually, as there are many edge case in a calendar.

  • AddAppointmentCommandParser - This is a class that parses a user input string to an AppointmentCommand object. Validation for user input data that do not require access to the model is performed here.

  • AddAppointmentCommand - This is where the actual logic of the add appointment command is mainly performed. It will access the model to ensure there is no duplicate appointment before adding the appointment to the model.

  • JsonAdaptedAppointment - This class functions as an adapter between Appointment and the Storage layer. It specifies how to convert from Java appointment object to JSON file format and vice versa. This is also where validation for correct data format is performed when the save file is loaded back into memory.

The following sequence diagram shows how add appointment works on a high level:

AddAppointmentSequenceDiagram

Steps:

  1. When a user enters an add appointment command, the input is first validated by AddAppointmentCommandParser. Here, inputs that do not require access to the model is validated, such as ensuring patient ID, doctor ID, date and time are of the correct format, as well as ensuring the appointment is in the future. A new AddAppointmentCommand object is created.

  2. The Logic layer then executes the AddAppointmentCommand. Here, the appointment is checked against existing appointments in the model to ensure there are no duplicates. The appointment object is then sent to the Model layer.

  3. The model adds the appointment to its internal list. The internal list is a javafx.collections.ObservableList and the UI layer through a ListChangeListener is notified and updated following the observer pattern.

  4. The Logic layer will be notified that the model has been modified through an InvalidationListener and then it stores the new appointment to disk using the Storage layer. The Storage layer will convert the appointment Java object into the JSON file format using the format specified in JsonAdaptedAppointment. The next time the application is opened, the Storage layer will use JsonAdaptedAppointment again to convert appointments in the JSON file back into appointment objects.

Appointment

  1. Adding a new appointment

    1. Prerequisites: There are existing patients and doctors in the system.

    2. Test case: add-appt pid/1 did/7 d/2019-06-01 t/09:00
      Expected: A new appointment with the given patient, doctor, date and time is added.

    3. Test case: add-appt
      Expected: No appointment is added. All fields must be filled and not left empty. The correct command format is shown.

    4. Other incorrect add-appt commands to try: add-appt pid/1 did/7, add-appt d/2019-06-01 t/09:00.
      Expected: Similar to previous.

    5. Test case: add-appt add-appt pid/1 did/7 d/2019-02-29 t/30:00
      Expected: No appointment is added. The date and time should be in the valid format and be a valid date on the calendar.

  2. Marking an appointment as "CANCELLED" (or back to ACTIVE)

    1. Prerequisites: List all appointments using the list-appt command. All appointments are in the list.

    2. Test case: mark-appt 1 s/CANCELLED
      Expected: First appointment in the list is marked as "CANCELLED".

    3. Test case: mark-appt 1 s/ASDF
      Expected: No appointment is changed. A list of valid appointment status that can be input is shown.

    4. Other incorrect mark-appt commands to try: mark-appt, mark-appt 1 s/123.
      Expected: Similar to previous.

  3. Listing appointments

    1. Prerequisites: There are existing appointments in the system.

    2. Test case: list-appt
      Expected: All appointments in the system are shown.

    3. Test case: list-appt pid/1
      Expected: Appointments made by patient ID 1 are shown.

    4. Test case: list-appt did/7
      Expected: Appointments made by doctor ID 7 are shown.

    5. Test case: list-appt c/PAST
      Expected: Only appointments in the past are shown.

    6. Test case: list-appt d/2019-06-99
      Expected: No appointments are shown. A message prompting the user to enter the correct command format is shown.

    7. Other incorrect list-appt commands to try: list-appt t/99:00, list-appt s/ASDF, list-appt c/TOMORROW.
      Expected: Similar to previous.