Sim Jia Zhi - Project Portfolio

I am an undergraduate from National University of Singapore, School of Computing (SOC). This is one of the software development projects i am involved in during my tenure in SOC.

What is QuickDocs?

For our software engineering module, we were tasked with transforming a working application (consisting of 10,000 lines of code) into a new product to tackle a real-world issue.

Our team decided to address the problem of limited manpower in family clinics. We realized that Doctors usually have to handle a multitude of tasks when running their clinics, and the lack of manpower can potentially affect the quality of healthcare services provided negatively.

We decided to create QuickDocs to help doctors ensure their service quality despite their limited manpower. QuickDocs is an all-in-one application that can help doctors manage their patient records, inventory, appointments and conduct consultations. QuickDocs can also generate useful financial statistics for doctors to make more informed decisions for their businesses.

For more information, you can visit our github project page for QuickDocs here.

Summary of contributions

I am in charge of developing the patient and consultation modules for this project.

The patient module is responsible for registering, listing, updating and deleting patient records
The consultation module is responsible for conducting the consultation session and listing of past consultation records belonging to each patient.

The consultation process not only expedite an actual clinical operation, it is also the most integrated feature i have developed in QuickDocs. As such, it will be the main feature showcased in this document.

Main Features developed

Created the consultation process of QuickDocs
Code Contributed: [Functional code]
- What it does: Doctors can record the patient symptoms and prescribe drugs to patients using one-shot commands on a single interface.
- Why is it needed: Doctors no longer need to navigate through multiple menus to perform these actions. Recording of symptoms and prescribing medicine can be done with minimal keystrokes. This will help to expedite the consultation process, and the doctor can tend to other patients more quickly.
- How is it convenient: The diagnosis and prescription synergizes with the command history. Doctors can simply navigate to the command previously entered, make changes before re-entering the diagnosis or prescription command to rectify errors or make changes.
- Highlights: The prescription command is integrated with the medicine inventory. If the clinic have insufficient amount of medicine to support the prescriptions, the doctor can be alerted and the incomplete prescription can be prevented.
- Who / what to acknowledge: My inspiration for the replacement style of the diagnosis and prescription editing is drawn from the original AddressBook Level 4's edit command. It uses this mechanism to provide a more efficient way to make changes to the person’s particulars.

Other features and enhancements:

Created the functionalities for the patient management module
- Features include the registration, update, search and deletion of patient particulars in QuickDocs
Adapted the history command from the original sample application for use in QuickDocs
- Allow editing and repeating of commands to be expedited by allowing users to navigate to previously entered command

Other contributions:

As the team lead, I am also responsible for the overall project coordination, making sure the deliverables are ready before the deadlines.

Project management:
- Managed releases from v1.2.1 to v1.4 (3 releases) for QuickDocs on GitHub
- Managed milestone goals and the issue tracker on QuickDocs' GitHub project page
Team collaboration:
- Assisted in setting up integration tools for QuickDocs' Github projects such as coveralls and TravisCI
- Helped team member to develop QuickDoc’s storage mechanism, allowing data generated across all modules to be saved in the Json format: #95
- Created the UI for QuickDocs and provided means for the different modules to display results from entered commands: #28
- Reviewed pull requests #103 and #125 to enhance the edits on the user guide made by team members
Documentation and tools:
- Created a tool for team members to generate diagrams for documentations.
- Designed templates for writing sections in both the user and developer guides for QuickDocs

Contributions to the User Guide

The following section showcase my additions to QuickDocs' user guide. As mentioned earlier, the content covered in this section will be pertaining to the consultation process. The diagnosis and prescription forms the core of the consultation process and we shall look into how the the diagnose and prescription commands can be performed in QuickDocs:

Diagnosing a patient: `diagnose`

After the consultation session has began, you can start recording the patient’s ailments. The various symptoms the patients have can be recorded down, along with the final assessment of the illness the patient is currently having.

To complete the diagnosis, the record must have one assessment and at least one symptom.

Format: diagnose s/SYMPTOM [s/SYMPTOM] … a/ASSESSMENT
Alias : d

Example:

diagnose s/runny nose s/sore throat s/phlegmy cough a/influenza

The order of symptoms and assessment does not matter here. You record as many symptoms per diagnosis.

Results:
After entering the command, QuickDocs will show the symptoms and assessment recorded on the main display as demonstrated in the following diagram.

Figure 1. Result of the diagnose command

Whenever you make a mistake, you can always press the UP and DOWN button on your keyboard to navigate to the commands you have entered previously. You can then rectify your errors by making the changes and re-entering the diagnose command. Doing so will replace the current erroneous diagnosis with the correct symptoms and assessment you have just entered.

Figure 2. Editing the diagnosis

Prescribing medicine for a patient: `prescribe`

After you are done recording the symptoms and assessing the illness of the patient, you can start prescribing medicine to your patient.

For each medicine prescribed, the quantity must be specified. Like the Diagnose patient command, you can always reenter the command to override the current prescription should there be any errors made.

A minimum of one medicine and one quantity is required to record a prescription entry. The order of quantity entered corresponds to the order of the medicine entered.

Format: prescribe m/MEDICINE [m/MEDICINE] … q/QUANTITY [q/QUANTITY]
or : prescribe m/MEDICINE q/QUANTITY [m/MEDICINE] [q/QUANTITY] …
Alias : p

Example:

prescribe m/penicillin q/1 m/Afrin spray q/1 m/ibuprofen q/2
Prescription now consist of 1 unit of penicillin, 1 unit of afrin spray and 2 units of ibuprofen.
prescribe m/penicillin m/Afrin spray m/ibuprofen q/1 q/1 q/2
Same as above example, quantity ordered based on medicine order.

Results:
After the medicine-quantity pairings are entered, the prescription to address the patient’s current condition will be displayed on the main display area of QuickDocs. Changes can still be made to the prescription as long as the consultation session is still ongoing.

Figure 3. Prescribing medicines to tackle the patient’s current conditions

Contributions to the Developer Guide

For the developer guide, I was in charge of explaning the design of the User Interface and also the technicalities involved in my assigned module. An in-depth explanation of how the commands of the consultation process, particularly its diagnosis and prescription parts, will be shown in this section:

Consultation process current implementation:

The consultation process comprises of four stages:

starting the consultation with a selected patient
entering the symptoms, assessment of the patient’s current condition
entering the medicine to be prescribed
ending the consultation

The consultation process is facilitated by the ConsultationManager class. The consultationManager class holds the current consultation session and a list of past consultation records for all the patients.

Methods in the ConsultationManager comprises of:

createConsultation(Patient) — Starts a consultation session with the current selected patient
diagnosePatient(Diagnosis) — Record symptoms patient mentioned and the assessment of the current condition.
prescribeMedicine(List of Prescriptions) — Prescribe the medicine and the quantities to be administered.
endConsultation() — Ends the consultation session. No further edits can be made to both prescription and diagnosis.

Both diagnosePatient and prescribeMedicine are repeatable. The values entered during the repeated command will simply replace the existing diagnosis / prescription.

QuickDocs only permit one ongoing consultation. During diagnosis and prescription, changes are only made to the current consultation session. The previous consultations should not be edited to prevent falsification of medical records. The current consultation session can only end after both the diagnosis and prescription are finalized.

Given below is an example usage scenario:

Step 1. A previously registered patient arrives and the doctor starts the session by entering the consult command in this manner: consult r/NRIC of the patient. A message to indicate the start of the consultation will be shown in the results display.

if the patient is new and his or her details are not recorded in QuickDocs, the command will not be executed and the doctor will be alerted that the consultation cannot continue since no patient records with the entered Nric can be found. An invalid nric entered will also prompt the same response

Step 2. The patient will tell the doctor what are his / her ailments. The doctor will record the symptoms down. The doctor will then make the assessment of the illness the patient is having and execute the command by clicking on the Enter on the keyboard.

The symptoms and assessment have to be prepended by the s/ and a/ prefix respectively
The command entered by the doctor will look something like this: diagnose s/constant coughing s/sore throat a/throat infection

Step 3. Should the patient inform the doctor of additional symptoms after the diagnosis is given, the doctor can simply press the up and down key to display the previously entered command on the userInput area. The doctor can then add the new symptom in and press Enter, replacing the previously recorded diagnosis.

Step 4. The doctor will then add the medicine to the prescription list, followed by the quantities. Medicine are prepended by the m/ prefix while quantities are prefixed by q/.The order of the quantity entered corresponds with the order the medicine is added in the command:

prescribe m/Dextromethorphan m/ibuprofen q/1 q/2 In this case q/1 represents one unit of Dextromethorphan cough syrup is issued while 2 units of ibuprofen (inflammatory tablets) are issued to the patient
Alternatively, the doctor can enter the quantity right after the medicine: prescribe m/Dextromethorphan q/1 m/ibuprofen q/2

If any of the medicine issued are insufficient to complete the prescription, or is simply not in the inventory, a message will be displayed in the inputFeedback area. The command will not be executed and remains in the userInput text field. The doctor can then make the changes to the command.

Step 5. Just like the diagnosis command, prescription can be replaced by reentering the command.

Step 6. After explaining the medicine intake to the patient, the doctor can then end the consultation session on QuickDocs by using the command endconsult. No further changes to the consultation records can be made from this point on.

Design considerations

In a family clinic setting, doctors usually tend to only one patient at a time. This is why QuickDocs only allow a single ongoing session in the consultation process.
In Singapore, every person is given a unique NRIC / FIN number regardless of their citizenship statuses. As such the NRIC is used to search for the patient records to start the consultation session.
The prescription and diagnosis commands are made to override their previous states to ease the modification of consultation data. Doctors can simply use the command history to navigate to the previous command entered, make the changes and then execute the command. This allow them to simply add a few words to change consultation data rather than re-entering the entire command line.
Prescription can actually be added before the diagnosis is recorded. The doctor could be expecting a patient for regular checkup and prepare the prescription before the patient enters the room. If the condition remains the same as before, the doctor can simply enter the diagnosis to complete the consultation session, cutting down the time spent on the consultation session.

Alternatives considered

Prior to the current implementation, a few options for the overall consultation process was considered:

Alternative Description Pros Cons

Alternative	Description	Pros	Cons
Consultation as one single command	Doctor enter `consult` followed by all the symptoms, assessment, prescriptions and then execute	Consultation is now restricted to just one class The consultation creation will truly be one-shot	Input will be verbose, easy for the doctor to make mistakes Harder to spot and navigate to the erroneous part to make changes No room for the doctor to make changes as the consultation could have ended with erroneous information recorded
Iterative consultation creation	Doctor enter `consult`. Subsequently QuickDocs will prompt the doctor to enter the diagnosis, followed by the prescription before ending the session.	Less likely to enter erroneous data as consultation is now broken down to different stages	Commands will take a longer time to complete Doctors can only diagnose and prescribe during the session, while other related actions (such as listing past records) can only be done after the consultation
Separate commands for start, diagnose, prescribe and end (Alternative selected and implemented)	Doctors begin and end session with `consult` and `endconsult`. Prescriptions and diagnosis can be added or replaced using the `diagnose` and `prescribe` commands before the session ends.	commands can be reused to perform both add and edit operations. The command history can be used to make changes to a previously entered command and edit the diagnosis or prescription. Consultation do not need to follow a strict order. Other commands can be executed while a session is ongoing.	Potentially more commands will be called when compared to the other options. diagnosis and prescription commands entered could be verbose and doctors might make mistakes more easily.

Consultation as one single command

Doctor enter consult followed by all the symptoms, assessment, prescriptions and then execute

Consultation is now restricted to just one class

The consultation creation will truly be one-shot

Input will be verbose, easy for the doctor to make mistakes

Harder to spot and navigate to the erroneous part to make changes

No room for the doctor to make changes as the consultation could have ended with erroneous information recorded

Iterative consultation creation

Doctor enter consult.

Subsequently QuickDocs will prompt the doctor to enter the diagnosis, followed by the prescription before ending the session.

Less likely to enter erroneous data as consultation is now broken down to different stages

Commands will take a longer time to complete

Doctors can only diagnose and prescribe during the session, while other related actions (such as listing past records) can only be done after the consultation

Separate commands for start, diagnose, prescribe and end

(Alternative selected and implemented)

Doctors begin and end session with consult and endconsult.

Prescriptions and diagnosis can be added or replaced using the diagnose and prescribe commands before the session ends.

commands can be reused to perform both add and edit operations. The command history can be used to make changes to a previously entered command and edit the diagnosis or prescription.

Consultation do not need to follow a strict order.

Other commands can be executed while a session is ongoing.

Potentially more commands will be called when compared to the other options.

diagnosis and prescription commands entered could be verbose and doctors might make mistakes more easily.

Here are some of the considerations taken before the decision was made:

Since QuickDocs aim to provide a single interface for doctors to perform clinical operations more efficiently, the consultation process will require one shot commands to fulfill the efficiency requirement of the overall product.
It is highly possible for doctors to make mistakes with the one-shot commands, especially when there are so many parameters involved in a single command. Therefore the implementation must provide a convenient form of error recovery.
There could be interleaving operations between the modules, such as viewing past consultation records or checking medicine inventory in the midst of the consultation. The implementation must be flexible enough to allow cross module commands during a consultation.

The selected option features lengthier one-shot commands and this could lead to doctors making mistakes more easily. However, doctors can recover from erroneous commands very quickly by making use of the command history.

While a consultation session is ongoing, doctors can still perform operations beyond the consultation module as well, and not just be restricted to diagnosing the patient or prescribing medicine.

As the selected option guarantees the flexibility and efficiency QuickDocs aim to deliver for doctors in family clinics, it is currently implemented to help doctors conduct their consultation sessions much more smoothly.