PROJECT: HealthBase

Introduction

This project portfolio page’s purpose is to document my contributions to the project.

HealthBase is a desktop application designed to aid in clinic patient data management. It provides patient data input and management capabilities through a command line interface (CLI) for input and a graphical UI for data display. Its main features include (among others):

  • Management of check-in/check-out status of patients

  • Real-time management of the check-in/out status of patients

  • Patient medication, medical history, dietary restriction(s), and visitor history data entry and retrieval

  • Patient appointment management for doctors

HealthBase was designed and built by me and my team of NUS Year 2 Computer Science students for the CS2103T module. For more information about us, click here.

Summary of Contributions

This section’s purpose is to summarise my contributions to this project. For more details about the contributions, click the link to the corresponding pull request.

  • Major enhancement: Added addmeds command (Pull request(s): #20, #31, #32, #63, #82, #112)

    • What it does: this command adds a medication entry to a given patient. The medication entry includes information about the drug name, the dosage, dosage unit, doses per day, and the duration of the prescription in days.

    • Justification: this command provides a core functionality of HealthBase (medication data entry and retrieval).

    • Highlights: this command affects existing internal representations of the Person class and required significant retooling of tests to fit the new member of the Person class. The implementation was somewhat challenging as it required an extension of the current Person data representation and storage functionality.

  • Major enhancement: Added view command (Pull request(s): #95, #127, #169)

    • What it does: this command adds functionality for users to view patient-specific information in the right-side panel of the UI.

    • Justification: this command provides a core functionality of HealthBase (viewing patient data), while preventing UI clutter.

    • Highlights: this command was designed to be extensible and allows developers to design their own panels for data display without impacting other developers' data displays.

  • Minor enhancement:

    • Added sort command

    • Added gendata command

  • Code contributions: my contributions

  • Other contributions:

    • Project management:

      • nil

    • Enhancements to existing features:

      • Refactored out a large portion of dead code for deprecated features (Pull request(s): #73)

      • Refactored a bloated class to make it more extensible (Pull request(s): #189)

      • Wrote additional tests for existing features to cover modifications to the Person class (Pull request(s): #22)

    • Documentation:

      • Updated User Guide and Developer Guide to reflect changes made (Pull request(s): #29, #75, #85, #109, #130, #140, #212)

      • Updated class diagrams in the User Guide (Pull request(s): #97)

      • Ordered commands in the User Guide in lexicographical order (Pull request(s): #97)

      • Standardised language in the User Guide and Developer Guide (Pull request(s): #97)

    • Community:

      • Reviewed PRs (with non-trivial review comments): (Pull request(s): #76, #77, #79, #209)

      • Contributed to forum discussions (Examples: #91, #94)

      • Adoption by several other class mates of parts of the code for the addmeds feature I wrote (Pull request(s): #42, #64, #76, #77)

Contributions to the User Guide

Given below are (some) sections I contributed to the User Guide. For brevity, not all of the portions of the User Guide that I wrote have been included. They showcase my ability to write documentation targeting end-users.

Sort user view : sort

Sort the current view, if it is sortable.

Format: sort SORT_TYPE SORT_ORDER

SORT_TYPE refers to the order in which the sorting should be done (ascending, descending). It can be either 'a' for ascending, or 'd' for descending.

SORT_ORDER refers to the order in which the sorting should be done. How this affects the sorting exactly depends on each view, and will be explained in greater detail below.

View Name

Sortable?

What SORT_ORDER refers to

Default

No

-

Apppointment

Yes

The columns of the table in the view, one-indexed.

Diet

No

-

Medication

Yes

The columns of the table in the view, one-indexed.

Medical History

Yes

The columns of the table in the view, one-indexed.

Example(s):

  • sort a 123 where the current view is Medication

    • Sorts the table in the medication view by the first column (Drug Name). Any entries with the same drug name will be further sorted by the second column (Dosage), with any entries with the same drug name and dosage being further sorted by the third column (Dosage Unit).

  • sort a 1 where the current view is the default view (blank view).

    • Does nothing (the current view is not sortable).

Select patient: select

Select a patient through pure command-line functionality. The alternative is to click on the patient’s card.

Format: select INDEX

where INDEX refers to the index of the patient’s card (listed in the card)

highlightIndex
Figure 1. Indication of the location of the index on the patient’s card

Example(s):

  • select 1

Add patient medication: addmeds

Add to a patient’s medication history.

Format: addmeds ic/NRIC d/DRUG_NAME q/QUANTITY_PER_DOSE u/DOSAGE_UNIT n/DOSES_PER_DAY t/DURATION_IN_DAYS

Example(s):

  • addmeds ic/S1234567A d/Paracetamol q/2 u/tablets n/4 t/14

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.

Addmeds

Current implementation

The addmeds command provides functionality for users to add prescription-related information for a given patient. This is done by adding prescription-related information to a given person, represented by a Person object. This allows for a patient to build up a history of prescriptions for viewing at a later date.

The adding of prescription-related information is facilitated by the following classes:

  • PrescriptionList, a list of

    • Prescription s, each of which have a

      • Dose and a

      • Duration.

A more detailed description of the classes follows below:

  • PrescriptionList

    • Every Person has a PrescriptionList, the purpose of which is to store the Person 's Prescriptions.

    • A wrapper class around the internal representation of a list of prescriptions that exposes only a few select methods in its API.

      • The methods relevant for the addmeds command execution are: add

  • Prescription

    • Class encapsulating all the information about a given medication prescription.

      • More specifically, the Prescription class encapsulates the name of the drug prescribed, the dosage information (itself stored as a Dose object), and the duration of the prescription (as a Duration object).

  • Dose

    • Class encapsulating all the information about a given medication dosage.

      • More specifically, the Dose class encapsulates the dose, dosage unit, and doses per day to administer.

  • Duration

    • Class encapsulating all the information about a given time period.

      • More specifically, the Duration class encapsulates the duration of the time period in milliseconds, and the calendar dates for the start and end of that time period.

Given below is an example usage scenario and how the relevant classes behave at each step.
At the end of the explanation is a sequence diagram of a typical addmeds command execution.

The user executes addmeds ic/S1234567A d/Paracetamol q/2 u/tablets n/4 t/14 .
This command has the following intent: Prescribe the following medication to a patient with NRIC = S1234567A:

Drug Name

Dosage

Duration

Paracetamol

2 tablets, 4 times a day

14 days, from current date to 14 days from now.

The command text is passed to an instance of the LogicManager class, which in turn executes HealthBaseParser::parse.
The HealthBaseParser parses the command word (addmeds) and executes AddmedsCommandParser::parse.
This causes the AddmedsCommandParser to construct the following objects in the following order:

Index

Information used

Class instances used

Class instance constructed

1

Dosage, Dosage unit, Doses per day

nil

Dose object

2

Duration in days

nil

Duration object

3

NRIC

nil

Nric object

4

Drug name

Dose, Duration

Prescription object

5

nil

Nric, Prescription

AddmedsCommand object

The AddmedsCommandParser::parse method returns an AddmedsCommand object which encapsulates the necessary information to update the Person 's medication(s).
Control then passes back to the LogicManager, which calls AddmedsCommand::execute.

If no/multiple patient(s) with that NRIC exist, then the AddmedsCommand::execute method will throw a CommandException with the appropriate error message and the usage case will end.

The AddmedsCommand::execute method constructs a new Person object using all the details of the old Person, with the sole difference being the PrescriptionList used being a deep copy of the original Person 's PrescriptionList with the new Prescription added. This updated Person object is used to update the existing Person object using the Model::updatePerson method (or an overridden version) of the backing model. Finally, the AddmedsCommand::execute method terminates, returning a CommandResult with a success message. The LogicManager then returns the same CommandResult as the return value of the LogicManager::execute method. The command execution then ends.

The following sequence diagram shows the execution of the addmeds command:

AddmedsSequenceDiagram
Figure 2. Execution sequence of the addmeds command

Design considerations

Aspect: Data structure to support the medication data storage

  • Alternative 1 (Current implementation): Store the data inside multiple POJO classes, with new classes being introduced as necessary to maintain high cohesion of individual classes. For example, the Duration class holds temporal information, whereas the Dose class holds medication dosage-related information.

    • Pros: Maintains the Single Responsibility Principle (e.g. the Prescription class now changes only if there are changes to the structure of a physical prescription, and not due to (e.g.) changes in time representation, or the way that dosage-related information is stored.

    • Cons: Increases the number of classes we will have to maintain.

  • Alternative 2: Store all the data directly as members inside a single Prescription class.

    • Pros: Reduces the number of classes we will have to maintain.

    • Cons: Reduces the cohesion of the Prescription class as it now handles multiple different items e.g. dosage-related information and duration-related information.

Generating test data

  1. Generating patients with mock data

    1. Open the application.

    2. Run the following commands in the following sequence:

      1. dev-mode (Enables developer mode; the next command requires developer mode to run.)

      2. gendata NUMBER_OF_PATIENTS, where NUMBER_OF_PATIENTS is a positive integer value that indicates how many patients you wish to generate.

The application will then generate that number of patients with mock data for their:

  1. Personal particulars

    1. NRIC

    2. Name

    3. Phone number

    4. Email address

    5. Physical address

  2. Drug allergies

  3. Medications

  4. Appointments

  5. Dietary restrictions

  6. Medical history

Details on the exact range of values that the mock data can take on can be found in the related .java files.