PROJECT: HealthBase

1. Overview

This portfolio documents my contributions to the development of application for CS2103T (Software Engineering) project, as part of the team W14-3. My contributions mainly include the addition of several new commands and project management.

HealthBase is a desktop application designed to aid the management of clinics and hospitals. Doctors and nurses can use this application to record patient information such as medical history, medication, dietary requirement and medical appointments, through a command line interface. Besides, receptionists can use this application to register the visitors for each patient. The recorded data can be viewed through a graphical user interface. The application also provides functionality to check out a patient when he/she leaves the hospital, and check in the same patient when he/she returns to the hospital.

2. Summary of contributions

  • Major enhancement: added adddiet command

    • What it does: This command allows the user to enter dietary requirements information for a given patient.

    • Justification: This feature enables the dietary information of a patient to be recorded upon checking in or being registered, and to be reviewed subsequently, so that the nurses can prepare food for patients efficiently.

    • Highlights: This enhancement brings a unique feature for the application, which is not usually included in other hospital management systems. There are three types of dietary requirements included, so the implementation needs to take into consideration how to separate different types of dietary requirements. Also, this feature blocks invalid dietary requirement inputs to ensure data integrity.

  • Major enhancement: added checkout command

    • What it does: This command allows user to check out a patient from the application when the patient leaves the hospital, while still stores his/her information in the system for future usages.

    • Justification: This feature makes the application more suitable for the workflow in hospitals, as patients need to be checked out from the hospital at the end of his/her hospitalization period.

    • Highlights: This enhancement makes the application highly extensible, as the information of the checked out patient are stored, which enables more operations and features to utilize these stored information.

  • Major enhancement: added checkin command

    • What it does: This command allows user to check in a returning patient, and also restores all his/her information (medication, medical history, dietary requirements, appointments etc.) back to the application.

    • Justification: This feature completes the workflow after checking out a patient, by providing a way to admit him/her back to the hospital if he/she is returning to the hospital after a period of time.

    • Highlights: This enhancement makes uses of the information stored by checkout command, and restores these information so that other commands can be valid on a given patient. Besides, this command differentiates whether the given patient is already registered or not, and direct the user to the register command if the patient is on his/her first visit.

  • Minor enhancement: added a view panel that allows the user to inspect the added dietary requirements of a patient.

  • Code contributed: [Functional and Test code]

  • Other contributions:

    • Project management:

      • Managed organisation code repository as administrator.

      • Managed releases v1.1 - v1.4 (5 releases) on GitHub.

      • Managed the project dashboard on Github.

    • Enhancements to existing features:

      • Refactored several *Command classes to avoid code duplication (Pull request #209).

      • Modified the equality definition of Person class to make it suitable for HealthBase (Pull request #209).

    • Documentation:

      • Updated the UserGuide to include adddiet, checkout and checkin command.

      • Updated the DeveloperGuide to include implementation details of the adddiet command.

      • Updated the user interface mockup to be consistent with our proposed product (Pull request #18).

    • Community:

      • PRs reviewed (with non-trivial review comments): #20, #22, #29, #82, #95, #110.

      • Reported several issues related to the UserGuide (Issues: #123, #193, #194, #195, #200).

      • Reported bugs and suggestions for other teams in the class (Examples: #118, #128, #130, #138).

      • Assisted teammates during integration of code for each release.

    • Tools:

      • Set up Reposense for the organisation repository (Pull request #221).

3. 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.

Add patient’s dietary needs: adddiet

Add a patient’s dietary requirements into the system.

Format: adddiet ic/NRIC alg/ALLERGY1 alg/ALLERGY2 cr/CULTURAL_REQUIREMENT pd/PHYSICAL_DIFFICULTY

There are three types of dietary requirements, which can be added to a patient with their own prefixes:

Type of dietary requirement

Prefix

Usage Example

Allergy

alg

alg/Egg

Cultural Requirement

cr

cr/Halal

Physical Difficulty

pd

pd/Hands cannot move
The number of dietary requirements in an adddiet command must adhere to the following rules:

  • All three types are optional to be included, but there must be at least one dietary requirement in the command.

  • For each type, more than one requirements can be specified in the command.

The following inputs are considered as invalid when entering a dietary requirement:

  • Input with non-alphabetical characters. Eg. alg/1Egg

  • Input with only empty whitespaces or blank input. Eg. cr/ pd/

Adding two same dietary requirements to a patient will only result in one copy of the requirements being saved to the patient.

Example(s):

  • adddiet ic/S1234567A alg/Egg alg/Crab cr/Halal pd/Hands cannot move

  • adddiet ic/S1234567A cr/Vegetarian

Result of executing the first example command above:

adddietcommand
Figure 1. Adding dietary requirements for a patient

Check in a returning patient: checkin

Check in a returning patient back to the HealthBase system, and retrieve his/her information from backend and display them in the left panel of the application window. The patient being checked in must have been previously registered to the system and were checked out of the system sometime before by using the checkout command.

Format: checkin ic/NRIC

If there is no record of this patient in our system (which means that the patient with the specified NRIC has not visited the hospital and not been registered in the system, the application will direct the user to use the register command to register this new patient with his/her necessary information.
If the patient with the specified NRIC is still active in the system (which means that the patient in the system has not been checked out yet), the command is considered as invalid.
The checkin command is only considered valid when the patient with the NRIC specified were checked out before by using the checkout command.

Example(s):

  • checkin ic/S1234567A
    Note that the patient with NRIC S1234567A must have been previously registered to the system and were checked out of the system sometime before by using the checkout command.

Check out a patient: checkout

Check out a patient from the HealthBase system, while still keeping the information of the patient at the backend. Upon checking out a particular patient, this patient will not be displayed in the left panel of the application.

Format: checkout ic/NRIC

If the NRIC does not match that of any checked in patient in the system, an error message will be displayed.
After a patient has been checked out from the system, all commands with the NRIC of this patient as parameter (except the checkin command) will be considered as invalid commands.

Example(s):

  • checkout ic/S1234567A

4. 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.

Adddiet

Current implementation

The adddiet command provides functionality for users to add dietary requirements for a given patient.
This command allows users to add three different types of dietary requirements: allergy, cultural requirement and physical difficulty.
This command adds these dietary requirements to a given Person , so that the dietary requirements can be viewed later on.
This command blocks non-alphabetical or empty input as the detail of a dietary requirement.

Classes involved

The adding of the dietary requirements involve the following classes:

  • DietCollection, which is a set of

    • Diet, which consists of the detail of the requirement and its type

      • DietType.

A more detailed description of the classes involved is as follows:

  • Diet Collection

    • Every Person object has a Diet Collection object.

    • This class encapsulates a collection of all the dietary requirements of the given patient.

    • This class is a wrapper class around the internal representation of a Set of Diet s.

  • Diet

    • This class encapsulates the information of a single dietary requirement.

    • Specifically, an instance of this class is composed of

      • a String representing the details of the requirement in text, and

      • a DietType representing the type of this dietary requirement (allergy, cultural requirement, or physical difficulty).

  • DietType

    • This class is an Enum class representing the three different types of dietary requirements.

    • This class is implemented as Enum class to avoid typo and invalid types being entered.

Execution of the command

Given below is a usage scenario and the details when executing adddiet command.
For example, when the user executes adddiet ic/S1234567A alg/Egg alg/Crab cr/Halal pd/Hands cannot move:

  • The command text is passed to an instance of the LogicManager class.

  • The LogicManager instance calls HealthBaseParser#parseCommand, which parses the adddiet command word.

  • Next, the AddDietCommandParser#parse method parses the different dietary requirements into one DietCollection object. An instance of AddDietCommand is returned after the parsing.

  • LogicManager then execute this AddDietCommand by calling AddDietCommand#execute.

  • In the AddDietCommand#execute method, the new DietCollection object is added to a new copy of the Person object.

  • The new Person object is updated to the model by Model#updatePerson method.

  • A new CommandResult is returned and the execution ends.

Here is the sequence diagram of the typical execution of an adddiet command:

AdddietSequenceDiagram
Figure 2. Execution sequence of the adddiet command

Design considerations

Aspect: How to represent different kinds of dietary requirements

  • Alternative 1 (current implementation): Use a Enum inside the Diet class and contain all Diet in one collection.

    • Pros: Results in less repetitive code and cleaner design.

    • Cons: Requires more effort to filter or retrieve different types of Diet from one DietCollection.

  • Alternative 2: Use polymorphism to extends Diet class and add three different collections to a Person.

    • Pros: Makes it easier to retrieve different types of dietary requirements.

    • Cons: Results in a lot of repetitive code since the three different types do not differ much.

Aspect: Data structure to hold the different Diet objects

  • Alternative 1 (current implementation): Use HashSet and override the hashCode for Diet.

    • Pros: Makes it easier to handle duplication in adding dietary requirement.

    • Cons: Causes the order in which dietary requirements are added to be lost. (However, the sequence is not important for the current set of features implemented.)

  • Alternative 2: Use ArrayList.

    • Pros: Preserves the order in which dietary requirements are added.

    • Cons: Makes it harder to handle duplicates.