QuickDocs - Developer Guide

This project follows oss-generic coding standards. IntelliJ’s default style is mostly compliant with ours but it uses a different import order from ours. To rectify,

Optionally, you can follow the UsingCheckstyle.adoc document to configure Intellij to check style-compliance as you write code.

After forking the repo, the documentation will still have the SE-EDU branding and refer to the se-edu/addressbook-level4 repo.

If you plan to develop this fork as a separate product (i.e. instead of contributing to se-edu/addressbook-level4), you should do the following:

Set up Travis to perform Continuous Integration (CI) for your fork. See UsingTravis.adoc to learn how to set it up.

After setting up Travis, you can optionally set up coverage reporting for your team fork (see UsingCoveralls.adoc).

Optionally, you can set up AppVeyor as a second CI (see UsingAppVeyor.adoc).

When you are ready to start coding,

QuickDocs supports customized organization of medicine inventory.

The figure below illustrates the implementation of the inventory system for medicine.

In medicine module, information about a medicine is encapsulated into the Medicine class.

Directory is a container for medicines, and sub-directories as well.

The MedicineManager keeps a list of reference of all unique medicines in the storage, so that no two medicine in the storage could share the same name to avoid confusion.

As the directory-medicine structure resembles the tree data structure, it is possible to support tree-like operations, such as setting the same threshold for the "subtree" of a directory.

The figure below illustrates how is a patient represented and how are patients are stored in QuickDocs.

A patient in QuickDocs consists of an address, name, NRIC, Contact, Email, Date of Birth, Gender and any number of tags.

The PatientManager keeps a list of patients by chronological order of addition. PatientManager supports searching patients by NRIC, name and tags.

The figure below illustrates how consultations with patients are recorded and organized in QuickDocs.

A Consultation in QuickDocs is defined to one patient and it consists of an optional Diagnosis and a list of Prescription of medicine.

A diagnosis is then consisting of an assessment, the final conclusion of patient’s illness, and a list of symptoms.

Past consultations are kept as a list in ConsultationManager, and the manager supports listing consultations of the same patient by his/her NRIC.

Every monetary transaction happened in the clinic, such as prescriptions to patients, is recorded by QuickDocs, and statistics report could be generated upon user requests.

The figure below illustrates how such records are organized in QuickDocs, and how the statistics reports are generated.

Monetary transactions in the clinics are categorized to two forms, i.e purchasing of medicine and revenue from consulting patients.

Both forms have corresponding classes to record such transactions. Every successful execution of purchase medicine command and every successful consultation will create its corresponding record.

MonthStatistics holds records of purchases of medicines and consultations happened in a particular month.

The overall StatisticsManager has a list of MonthStatistics arranged in chronological order.

The Appointment module manages time slots for appointment requests from the patients.

The figure below illustrates how AppointmentManager is organized.

A Slot is used to represent a time block during clinic’s opening hour available for appointments.

Appointment extends slot and each appointment is assigned exactly one patient.

AppointmentManager holds a list of appointments which can then be operated on upon user commands.

QuickDocs supports reminding our users about upcoming appointments and warns users about medicines that is low in stock.

QuickDocs also supports customized reminders that could be set up by the users themselves.

The figure below illustrates how reminder module is implemented.

Reminder extends from slot, and has a starting date and end date. Users are free to customize reminders' title and comments for user-initiated reminders.

ReminderManager keeps a list of reminders sorted by the date of reminder. Reminders that expires, i.e passed the end date, will automatically be hidden from the panel list of reminders shown to the user.

Upon every subtraction or addition of medicine quantity in the inventory, the ModelManager calls the ReminderManager to check the sufficiency of medicine against the set threshold and update the reminder panel accordingly, so that the reminders for medicines in low stock is managed automatically upon every change in medicine quantity.

API : Storage.java

The Storage component,

All data are stored in a json file, with a default filepath data/quickdocs.json. This filepath can be customised in the preferences.json file.

When QuickDocs is launched, all information in the quickdocs.json file will be read. As mentioned in the previous section, the json file contains 8 different lists, and each list will have their information converted to their corresponding model types by their respective toModelType() methods of the 8 different JsonAdapted classes.

These converted objects will then be added into their respective class managers. As mentioned in the Model Component section, the QuickDocs class is responsible for storing all these data as it holds all the different class managers.

Note that there are only 6 managers but there are 8 JsonAdapted classes. This is because converted JsonAdaptedStatistics and JsonAdaptedMonthStatistics objects are both stored in the StatisticsManager. Similarly, both JsonAdaptedMedicine and JsonAdaptedDirectory objects are stored in MedicineManager.

QuickDocs saves data whenever there is modification of any information in the current session.

Note that the user mainly interacts with QuickDocs by executing commands, and only some user commands will modify its data. For example, commands such as listmed, to list medicines, or listapp, to list appointments, will not affect the data. However, commands such as editpat, to edit a patient’s particulars, or addapp, to add an appointment, will change the information stored in QuickDocs.

Hence, only methods that modifies data will indicate to the QuickDocs class that a modification occurred. All methods that interact with the various class managers are contained in the ModelManager class, which holds a reference to the main QuickDocs object and references to all class managers. The following are the steps taken when one of these methods, in this case Model#addApp(), is called, which leads to data being saved:

Patient records consist of Name, NRIC, Email, Address, Contact, Gender, Dob (Date of Birth) and tagList fields. The addpat command require users to enter the value of these fields prepended by prefixes. The prefixes are used to separate the parameters and assign the values to these fields.

To edit a patient, a PatientEditedFields is first created. It consist of all the fields of a Patient object but all its values are null initially. This means that only when the user enter a value for a specific field will it be assigned to the PatientEditedFields.

A temporary Patient object is then created with the values of the existing patient record to be edited. The PatientEditedFields will then be checked against this temporary patient object and replace the fields which are non-null.

An additional check for NRIC will be done on the list of patient records to ensure that the editing of NRIC does not cause a conflict with existing Patient records. When this additional check is passed, the temporary patient object will replace the existing patient record designated for editing.

Each patient have a unique NRIC value. This is how QuickDocs differentiate between the different patient records in the patient list in the PatientManager class.

To delete a patient record, the deletepat and a nric is specified. The patient list will be iterated and the record whose NRIC matches the specified value will be removed.

Since the patient records are stored in a list, their position in the list (index) can be used to view the details of a specific patient record.

The user can narrow down their patient record searches using the names, nric and tags assigned to each patient, and this results in a sublist of patient records, with their index reflected to be shown on the main display of QuickDocs. The specific session can then be viewed by calling listpat along with the index.

Internally, a ListCommand can be created using four different constructors and each of them have a constructedBy field. The constructedBy field will indicate whether the search is done by indexing, or filtering by name, nric or tags.

Lastly, if listpat is called without any search parameters, QuickDocs will simply list the first 50 patients in the patient list.

The consultation process comprises of four stages:

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

Methods in the ConsultationManager comprises of:

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

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.

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.

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:

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.

The following sequence diagrams summarizes what happens when a user perform the entire consultation process, starting with the session initialisation:

Followed by the adding of the diagnosis:

prescribing the medicine to tackle the patient’s condition:

finally, saving the consultation record into QuickDocs:

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

Although the selected option require more input and lengthier commands, it guarantees the flexibility and efficiency QuickDocs aim to deliver for doctors in neighbourhood clinics.

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

Although the selected option require more user input and involve lengthier commands, a doctor with fast typing speed will be able to circumvent the issues of slightly more verbose command lines easily.

If the doctor enters an erroneous command or simply want to make changes, the command history can be used in conjunction with the one shot commands to make changes quickly.

The selected option also do not restrict doctors to just consultation-related commands. He or she can perform other operations such as checking the inventory or view free appointment slots during the consultation itself.

The selected implementation guarantees the flexibility and efficiency that QuickDocs aim to deliver for doctors in neighbourhood clinics.

An Appointment is a subclass of the Slot class, and has the following 5 compulsory fields:

The user can add an appointment to his/her schedule to keep track of future meetings, by using the addapp command. All 5 fields of an appointment, as mentioned in the Appointments section, must be specified together with the command.

The user can list his/her past or future appointments using the listapp command. The user can either provide a range of dates to list out all appointments in those dates, or provide an NRIC to list out all appointments for the patient with the given NRIC.

The user can delete any appointments created using the deleteapp command. Since there cannot be any clash in timings for appointments, any appointment can be identified uniquely by its date and start time. Hence the user can specify the appointment to be deleted only with those two fields, after which the following steps are taken:

Before deciding on an appointment timing, the user can execute the freeapp command to list out all the timings available for a new appointment booking.

A Reminder is a subclass of the Slot class, and has the following 5 fields:

Only the title, date and start attributes are compulsory fields for a reminder.

The user can take note of a task to do by creating a reminder using the addrem command. As mentioned in the Reminders section, only the title, date and start attributes are compulsory fields and must be specified together with the addrem command. Fields end and comment are optional. Below are the steps taken after the user executes the addrem command.

The reminders displayed on the reminder sidebar can be filtered using the listrem command.

Deleting a reminder is simple, as the user only needs to specify the index of the reminder shown on the sidebar, together with the deleterem command. The process, when deleterem is called, described below is similar to the process when listrem is called to display a single reminder.

The statistics command is started through the command stats START_MMYY [END_MMYY]. The two MMYY corresponds to a range of dates. The end range is optional,

The consultation fee of the clinic is stored as a BigDecimal in the StatisticsManager of QuickDocs, which is loaded from the quickdocs.json file through the storage component. The consultation fee is used for calculating financial statistics for any ConsultationRecord objects.

The statistics command is started through the command stats START_MMYYYY [END_MMYYYY]. The two MMYYYY corresponds to a range of dates. The end range is optional, and is defaulted to the start range by the StatisticsCommandParser if it does not exist.

The start date is not allowed to be before January 2019, and the end date cannot be before the start date. Hence, QuickDocs currently does not support adding old records before January 2019 due to the implementation of the StatisticsManager. This will be explained in the section below.

The statistics class stores 6 types of information:

Number of consultations is stored as an int, while the financial variables are stored using BigDecimals. The number of medicines prescribed and symptoms diagnosed are stored by using a HashMap.

The implementation of Statistics and Record has 3 parts:

The following table lists out the alternatives designs considered for implementing the storage of the Records and Statistics.

The current implementation takes a similar form as the Windows file browser. The user is free to determine for himself/herself how he/she wants the medicines to be arranged.

Code: MedicineManager.java

To organize the inventory, the following methods in MedicineManager are used:

From the initial empty state of the storage, the users could arrange their storage in these following ways:

Given below is an example of organizing medicine from an initial empty QuickDocs.

Step 1: Initially, the storage only consists of an empty directory called root.

The list of unique medicine in MedicineManager is empty.

Step 2: Via adddirec root Internal, a new directory called "Internal" is added under root.

The list of unique medicine is still empty.

Step 3: Via a few more adddirec commands, the figure below is an illustration of a sample inventory’s framework.

The list of unique medicine is still empty.

Step 4: Now the user can add new medicines into the storage via addmed root\Internal\General paracetamol p/40 q/50.

The list of unique medicine is also updated.

Step 5: Via a few more addmed commands, some more new medicines are added to the inventory. The following figure shows the result after that

The list of unique medicine is also updated.

Step 6: Now, the user found out that aspirin can also be used to treat high blood pressure and decides to put it under "Cardiology" as well.

Via the addmed root\Internal\Cardiology aspirin, a reference to the existing aspirin medicine will be placed under the "Cardiology" directory.

The figure below shows the result of this command.

However, the list of unique medicine is not changed, as now new medicine is added.

This six-step example illustrates the basic implementation of how medicines and directories are organized in QuickDocs.

When typing the directory path in the command box in the ui, QuickDocs supports intelligent suggestions about the next field.

After the user entered at least one \ character to indicate he is inputting a path, the suggestion mode will be turned on.

The user could press Page Up / Page Down bottom to iterate to the previous or the next valid name of sub-directory or medicine in alphabetical order, given that the path given before the previous \ character is valid.

Using the above sample inventory as an example:

The figure below illustrates how this feature is implemented to make user’s life more convenient.

QuickDocs also supports setting alarm level for medicines. Every time a medicine’s storage falls below the designated level, a reminder is thrown.

To convenient the users, QuickDocs allow not only threshold setting for individual medicines, but also threshold setting for directories.

Taking the above sample inventory as an example:

Setting a threshold for a directory is effectively the same as setting the threshold for every medicine in the "subtree" of that directory. This is down by a tree-like traversal.

For example, alarm root\Internal 400 command sets the alarm level of all medicine in the subtree of "Internal" directory to 400.

The table illustrates some of the alternatives I considered during development of this medicine module, the relative advantages they have over the current implementation, and why they are not selected at the end.

Since QuickDocs aims to provide the most convenient experience given a large set of medicine in a clinic inventory, the medicine management module needs to provide a model that makes both typing commands, identifying the correct medicine and massive operation possible.

Combined with the suggestion mode, the current design is the best way to implement all of the three.