:information_source: **Note:** If the `currentStatePointer` is at index 0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo` command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user rather
-than attempting to perform the undo.
+![Sequence diagram of Add Medical Entry Feature](diagrams/AddMedicalEntrySequenceFeatureDiagram1.png)
+
:information_source: **Note:** The lifeline for `PatientBookParser` and `AddMedicalEntryCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-The following sequence diagram shows how the undo operation works:
+**Execute a:AddMedicalEntryCommand**
-![UndoSequenceDiagram](images/UndoSequenceDiagram.png)
+![Sequence diagram of Add Medical Entry Feature](diagrams/AddMedicalEntryFeatureSequenceDiagram.png)
-
:information_source: **Note:** The lifeline for `UndoCommand` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
+The following activity diagram summarises what happens within `AddMedicalEntryCommandParser` when the user executes an Add Medical Entry command.
-
+![Activity diagram of Add Medical Entry Feature](diagrams/AddMedicalEntryFeatureActivityDiagram.png)
+
+**Design considerations**
+
+| Alternative Considered | Current implementation | Rationale for current implementation |
+| ---------- | ------------------------ | ------------------------ |
+| Implementing a `MedicalHistoryBookParser` to invoke the `AddMedicalEntryCommandParser` | Having `PatientBookParser` invoke `AddMedicalEntryCommandParser` | Since `MedicalHistory` is an attribute of `Patient`, it makes sense to use the `PatientBookParser`. It also takes more effort to implement a new `Parser` that requires an entirely new command word prefix to add a `MedicalEntry`. |
+
+
+#### Delete Medical Entry feature
+
+**Overview**
-The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer` once to the right, pointing to the previously undone state, and restores the address book to that state.
+The Delete Medical Entry feature allows users to delete medical entries from the `MedicalHistory` of a `Patient`.
-
:information_source: **Note:** If the `currentStatePointer` is at index `addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will return an error to the user rather than attempting to perform the redo.
+Below is a class diagram of the components involved in the Delete Medical Entry feature.
+![Class diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureClassDiagram.png)
+
+**Implementation details of feature**
+
+The Delete Medical Entry feature is implemented via the `DeleteMedicalEntryCommand`, which is supported by the `DeleteMedicalEntryCommandParser`. The `DeleteMedicalEntryCommandParser` implements the `PatientParser` interface.
+1. `LogicManager` receives the user input which is parsed by the `AddressBookParser`.
+2. The `AddressBookParser` invokes the `PatientBookParser` based on the regex pattern of the user input, splitting the user input into `commandWord` and `arguments`.
+3. The `PatientBookParser` invokes the `DeleteMedicalEntryCommandParser` based on the `commandWord`, calling the method `parsePatientCommand` with `arguments` as the method argument.
+4. `DeleteMedicalEntryCommandParser` takes in the argument string and invokes an `ArgumentMultiMap`, which tokenizes the `arguments`.
+5. If the required `patientIndex` and `medicalIndex` is present, the `DeleteMedicalEntryCommandParser` will invoke the `DeleteMedicalEntryCommand` after calling the `parseIndex` method provided by `ParserUtil`, which returns an `Index` to specify the `patient` and the `medicalEntry` to be deleted.
+6. `LogicManager` calls the `execute` method of the `DeleteMedicalEntryCommand`, which calls the `deleteMedicalHistory` of the `Patient` specified by the `Index`.
+7. The `DeleteMedicalEntryCommand` will then call the methods `setPatient`, `updateAppointmentBook`, `updateFilteredPatientList` and `updateFilteredAppointmentList` provided by the `Model`, editing the patient's medical history information.
+8. The `DeleteMedicalEntryCommand` returns a `CommandResult`, which will be returned to the `LogicManager`.
+
+Below is a sequence diagram illustrating the interactions between the `Logic` and `Model` components when the user inputs `pt md 1 i/1` command. Note that the full command string has been abbreviated to `...`. The illustration has been split into two parts: (1) Parse User Input, (2) Execute command.
+
+**Parse User Input**
+
+![Sequence diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureSequenceDiagram1.png)
+
+
:information_source: **Note:** The lifeline for `PatientBookParser` and `DeleteMedicalEntryCommandParser` should end at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as `list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`. Thus, the `addressBookStateList` remains unchanged.
+**Execute d:DeleteMedicalEntryCommand**
+
+![Sequence diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureSequenceDiagram.png)
+
+The following activity diagram summarises what happens within `DeleteMedicalEntryCommandParser` when the user executes a DeleteMedicalEntry command.
+
+![Activity diagram of Delete Medical Entry Feature](diagrams/DeleteMedicalEntryFeatureActivityDiagram.png)
+
+**Design Considerations**
+
+| Alternative Considered | Current implementation | Rationale for current implementation |
+| ---------- | ------------------------ | ------------------------ |
+| Implementing a `MedicalHistoryBookParser` to invoke the `DeleteMedicalEntryCommandParser` | Having `PatientBookParser` invoke `DeleteMedicalEntryCommandParser` | Since `MedicalHistory` is an attribute of `Patient`, it makes sense to use the `PatientBookParser`. It also takes more effort to implement a new `Parser` that requires an entirely new command word prefix to delete a `MedicalEntry`. |
+
+
+
+### Appointment composed of a Valid Patient when added, loaded and stored
+
+#### How Appointment is implemented
+
+![AppointmentClassDiagram](images/AppointmentClassDiagram.png)
+
+Each `Appointment` in memory contains a reference to a valid `Patient` object. To ensure this valid reference is maintained while the app is running and between different running instances, `Appointment` is stored in JSON with the index of the `Patient` in the corresponding `AddressBook`.
+
+Major changes involved to implement this feature:
+* Add a new appointment
+* Load appointments on app launch
+* Save appointments after every command
+* Delete a patient that has made an appointment
+
+#### Add a new Appointment
+
+**Overview**
+
+`AddAppointmentCommand#execute()` gets patient at the given index in the address book to create a new appointment referencing that patient.
+
+**Detailed Implementation**
+
+The user executes `apmt add i/1 d/2021-10-19 1800` to add an appointment to the first patient of the address book. The `apmt add` command calls `Model#getFilteredPatientList()`to receive a list of patients and gets the Patient object at the inputted index. A new Appointment of that patient is instantiated, and the `AddAppointmentCommand` calls `Model#addAppointment()` to add this appointment to the appointment book. A `CommandResult` is instantiated and returned.
+
+![AddAppointmentSequenceDiagram](images/AddAppointmentSequenceDiagram.png)
+
+
+**Design considerations**
+
+**Aspect: How Appointments are instantiated**
+
+| Design Choice | Justification | Pros | Cons |
+| ---------- | ------------------------ | ------------------------ | ------------------------ |
+| **Appointment is composed of a Patient (current choice)** | Appointment can only be instantiated with a Patient, and without Patients, Appointments cannot exist. Hence, for an appointment to be instantiated, it requires a reference to the related Patient object. |
Enforces 1 multiplicity requiring one Appointment to be associated with exactly one Patient. Easy to find the patient of the appointment.| Need to locate corresponding Patient before Appointment can be instantiated. Thus, `AddressBook` must be loaded to memory before `AppointmentBook`. |
+| Patient and Appointment have an association such that Patient has a link to Appointment and Appointment only requires date and time to instantiate. | - | Able to load `AppointmentBook` without loaded `AddressBook`. |
Appointments may not be unique objects as there may be patients with multiple appointments at the same date and time at the same clinic that can be served by different doctors. Difficult to find Patient of each Appointment when Appointment is extracted from Patients and listed because Appointment has no Patient field. |
+
+
+#### Load Appointments on App Launch
+
+**Overview**
+
+* The app first loads address book, then passes the address book as argument to `Storage#readAppointmentBook()`.
+* `Storage#readAppointmentBook()` gets the corresponding patient from the patient index in `JSONAdaptedAppointments` and instantiates appointments.
+
+**Detailed Implementation**
-![UndoRedoState4](images/UndoRedoState4.png)
+The user launches the application. `MainApp` runs `MainApp#initModelManager` to initialize the model. First, the address book of patients is loaded to memory in `StorageManager#readAddressBook()`. Referencing the order of patients in this loaded address book, `StorageManager#readAppointmentBook()` loads the appointment book. Under `Storage`, the JSON file is loaded to `JsonAdaptedAppointment` object and its `JsonAdaptedAppointment#toModelType()` is executed. `JsonAdaptedAppointment#toModelType()` runs `AddressBook#getPatientOfIndex()` to get the patient of the appointment at the index loaded from the JSON file. The Appointment object is then instantiated.
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern desktop applications follow.
+![LoadAppointmentSequenceDiagram](images/LoadAppointmentSequenceDiagram.png)
-![UndoRedoState5](images/UndoRedoState5.png)
+#### Save Appointments after every command
-The following activity diagram summarizes what happens when a user executes a new command:
+**Overview**
-
+* The app runs `LogicManager#saveAppointmentBook()`.
+* `LogicManager#saveAppointmentBook()` gets the index of the patient referenced by the appointment, that is to be stored as `JSONAdaptedAppointments` in JSON file.
-#### Design considerations:
+**Detailed Implementation**
-**Aspect: How undo & redo executes:**
+After every command that the user makes, appointments are saved. In `LogicManager#executes`, after every command is executed, `LogicManager` calls `StorageManager#saveAppointmentBook`, passing in the appointment book and address book from `Model` as arguments. In converting model-type Appointments to `JSONAdaptedAppointment`, `AddressBook#getIndexOfPatient()` is called to get the corresponding index of the patient for storage.
-* **Alternative 1 (current choice):** Saves the entire address book.
- * Pros: Easy to implement.
- * Cons: May have performance issues in terms of memory usage.
+![SaveAppointmentSequenceDiagram](images/SaveAppointmentSequenceDiagram1.png)
-* **Alternative 2:** Individual command knows how to undo/redo by
- itself.
- * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted).
- * Cons: We must ensure that the implementation of each individual command are correct.
+The diagram below is a more in-dcannnepth look at how `JSONAdaptedAppointment` is instantiated.
-_{more aspects and alternatives to be added}_
+![SaveAppointmentSequenceDiagram](images/SaveAppointmentSequenceDiagram2.png)
-### \[Proposed\] Data archiving
-_{Explain here how the data archiving feature will be implemented}_
+**Design considerations**
+**Aspect: How Appointments are loaded and saved**
---------------------------------------------------------------------------------------------------------------------
+| Design Choice | Justification | Pros | Cons |
+| ---------- | ------------------------ | ------------------------ | ------------------------ |
+| **Save `Appointment` as the index of corresponding patient in `AddressBook` and datetime. (current choice)** | The order of `AddressBook` does not change when saving or loading `AppointmentBook`. The order of `AddressBook` is saved each time `AppointmentBook` is saved. |
Index of patient requires less code then implementing a unique ID and fits with our theme of using indices in commands. Index of patient is guaranteed to be a unique identifier.| Order of the `AddressBook` is important. If the order of patients is changed in the json file, the appointments will become incorrect. |
+| Implement a hash or Universally Unique Identifier (UUID) to for each Patient and Appointment object. Save `Appointment` with Patient UUID and save `Patient` with Appointment UUID. | - | Changing the order of appointments and patients in saved JSON file will not change affect loading of data. |
Requires more code to implement a unique hash or UUID and find the corresponding Patient and Appointment by traversing the `AddressBook` and `AppointmentBook` respectively. Takes more computational work when loading compared to finding the `Patient` at an index at O(1) time. |
+
+
+#### Delete Patient that has made an Appointment
+
+**Overview**
+
+Delete all `Appointments` containing that `Patient` object when `Patient` object is deleted.
+
+
+**Detailed Implementation**
+
+The user executes `pt delete 1` to delete the first patient in the address book. The patient is deleted and the corresponding appointments and archive appointments with that patient are deleted. The `pt delete` command calls `AddressBook#deleteAppointmentsWithPatient()` to delete all appointments to that patient before deleting the patient.
+
+![DeletePatientActivityDiagram](images/DeletePatientActivityDiagram.png)
+
+**Design considerations**
+
+**Aspect: When a patient that has appointment is deleted**
+
+| Design Choice | Justification | Pros | Cons |
+| ---------- | ------------------------ | ------------------------ | ------------------------ |
+| **Delete all appointments that the patient has (current choice)** | `Appointments` is a class that is instantiated with a `Patient` object. When that corresponding `Patient` object is deleted, the `Patient`s appointment objects should be deleted as well so there will be no reference to deleted `Patient` objects. |
Ensures `Patient` object is deleted completely from the system, and no objects holds references to deleted `Patient` objects. No `Appointment` objects will reference an invalid `Patient` object.|
Accidental deleting of a `Patient` will delete all corresponding `Appointments` which may cause extra hassle to enter in all the `Appointment` details again.No past appointment data of deleted `Patients` can be kept because their `Appointment` objects are deleted to garbage collect and truly delete `Patient` objects. |
+| **Delete patient without deleting the patient's appointments** | - | Past appointment data of `Patient` object can be kept as archives in the system. `Patient` object is not truly deleted and can be restored if needed. |
Requires more code to implement an indicator if `Patient` of an `Appointment` has been deleted to safeguard against Upcoming `Appointments` made for deleted `Patients`. Deleted `Patient` object will need to be saved and loaded from JSON which would require corresponding storage classes such as `DeletedPatientBook` to be created. |
+
+
+
+#### Archiving an Appointment
+
+**Overview**
+
+A user is able to archive an appointment when the appointment is _expired_, i.e. the patient has either missed his/her appointment
+or already attended the scheduled appointment. In this case, the appointment should be archived, so that clinic staff
+are able to view what medicine was prescribed to the patient during previous appointments.
+
+**Implementation Details**
+
+![Sequence diagram of Archive Command](diagrams/ArchiveCommandSequenceDiagram.png)
+
+
+Users may archive specific appointments manually to remove visual clutter. This is done through the `ArchiveAppointmentCommand`.
+
+The above sequence diagram displays how the archive command works. The parsing mechanism has been abstracted out from the above diagram as it
+has been covered in previous diagrams. An example input can be viewed in our [User guide](UserGuide.md). It first retrieves the Appointment to archive from the
+appointment index parsed through the user input, removes the appointment from upcoming appointments, and adds it to archived appointments.
+
+Archiving is facilitated by the `ArchivedAppointmentBook`. As opposed to the regular `AppointmentBook`, it does not allow
+users to directly modify the data of appointments as archived data should not be edited. Hence, the following operations
+have the `private` access modifier:
+
+- `ArchivedAppointmentBook#setAppointment(Appointment target, Appointment editedAppointment)` - edits the `target` Appointment
+ to be replaced with `editedAppointment`.
+- `ArchivedAppointmentBook#removeAppointment(Appointment key)` - removes the target Appointment `key`.
+
+The reason these methods exist in the class is so to support the methods `ArchivedAppointmentBook#updatePatient(Patient target, Patient editedPatient)`
+and `ArchivedAppointmentBook#removePatient(Patient target)`, which are called to accurately reflect any updates/removals of patient
+details.
+
+![Class diagram of Archive Storage](diagrams/ArchivedStorageClassDiagram.png)
+
+In the `Storage` component, the addition of `ArchivedAppointmentBook` also necessitates the implementation of a separate storage system
+for archived appointments. This forms under `ArchivedAppointmentBookStorage`, alongside `AddressBookStorage` and `AppointmentBookStorage`.
+The .json file for archived appointments is named 'archivedappointmentbook.json'.
+
+**Design Considerations**
+
+| Alternative Considered | Current implementation | Rationale for current implementation |
+| ---------- | ------------------------ | ------------------------ |
+| Implementing archived appointments as a second `UniqueAppointmentList` attribute under the `AppointmentBook` class | Have a separate class `ArchivedAppointmentBook` | Having a separate class `ArchivedAppointmentBook` separates the two types of appointments better to facilitate data management. It ties in better with our Storage framework, and archivedappointmentbook.json files can be easily used by the user, instead of having to split one appointmentbook.json files into two segments. |
+
+
+#### Auto-Archiving Feature
+
+The archiving implementation involves scanning through all appointments in a day and comparing it to
+the current date and time of the user system. If the current date and time is 24 hours ahead of the scheduled
+appointment time (24-hour buffer), i.e. by our definition, _expired_, the appointment is automatically archived. This auto-archiving implementation is handled
+by the `ModelManager` class in two ways.
+
+![Sequence diagram of Auto-Archive Feature](diagrams/AutoArchiveSequenceDiagram.png)
+
+1. Upon initialisation of the application, the application automatically archives expired appointments (24-hours past their
+ scheduled time). This is called through `ModelManager#archivePastAppointments()`.
+
+
+2. A `ScheduledExecutorService` object schedules the task `AutoArchiveApmts` which implements the `Runnable` interface.
+ Every day at the `ModelManager.UPDATE_HOUR`th hour, the `Runnable` object executes the `ModelManager#archivePastAppointments()`
+ method.
+
+
+In the case where there are many scheduled appointments, this saves the user trouble of archiving past appointments when
+they are already over.
+
+### Recording a Patient's Prescription feature
+
+During appointments, the doctor can provide prescription of drugs for patients.
+Recording this information together with appointment information helps clinic staff to keep track of prescriptions given to a patient.
+Past prescriptions can also be viewed with past appointments.
+
+#### How Prescription is implemented
+Prescription derives from the original Tags class from AB3 and is modified with extra fields and checks.
+* Each `Prescription` class contains fields recording Medicine, Volume and Duration.
+* Each `Appointment` class contains 0 or more `Prescription` objects.
+
+![Class diagram of Prescription](diagrams/PrescriptionClassDiagram.png)
+
+The implementation of the Prescription class is done with a ```Prescription``` class. The ```Prescription``` class keep records of the medicine given, volume of medicine, and the duration which the medicine is taken.
+```Prescription``` objects are composed under ```Appointment``` objects, and will be deleted along with the parent ```Appointment``` object.
+Within each ```Appointment``` class, a collection of these ```Prescription``` objects are stored.
+
+The following commands are available from the ```Appointment``` class to interact with ```Prescription``` objects.
+
+* ```addPrescription(Prescription prescription)```- adds a new prescription for that appointment.
+* ```deletePrescription(String medicineName)```- removes an existing prescription based on the name of the medicine.
+
+#### Reason for implementation of Prescription
+
+```Prescription``` and ```Appointment``` forms a whole-part relationship and hence ```Prescription``` is suitable to be stored as a field of ```Appointment```.
+```Prescription``` will also be deleted when appointment is deleted due to this whole-part relationship. As an ```Appointment``` can have multiple ```Prescription``` objects, the multiplicity is many to one.
+
+
+#### Prescription commands
+The flow of how a command for prescription is processed is shown in the diagram below.
+![Activity diagram of Prescription commands](diagrams/PrescriptionActivityDiagram.png)
+
+##### Add Prescription command
+The command structure for add prescription command follows the sequence diagram below.
+![Sequence diagram diagram of Add Prescription commands](diagrams/AddPrescriptionCommandSequenceDiagram.png)
+
+##### Delete Prescription command sequence
+The command structure for delete prescription command follows the sequence diagram below.
+![Sequence diagram diagram of Delete Prescription commands](diagrams/DeletePrescriptionCommandSequenceDiagram.png)
+
+##### General Prescription command sequence
+When `execute()` is called upon the prescriptionCommand object, the prescriptionCommand object checks if the appointment to be targeted
+exists by calling the getAppointmentBook() function of the model, which returns a list of available appointments. Once verified that
+the appointment to be targeted exists, the respective add/delete prescription command is called in the `Model` object. The `Model` object
+then checks for the validity of the prescription command by checking for existence of the same prescription in the targeted appointment.
+Once the check has been done, the prescription in question is added/removed and a CommandResult is returned.
+
+---
## **Documentation, logging, testing, configuration, dev-ops**
-* [Documentation guide](Documentation.md)
-* [Testing guide](Testing.md)
-* [Logging guide](Logging.md)
-* [Configuration guide](Configuration.md)
-* [DevOps guide](DevOps.md)
+* [Documentation guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Documentation.html)
+* [Testing guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Testing.html)
+* [Logging guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Logging.html)
+* [Configuration guide](https://ay2122s1-cs2103-w14-1.github.io/tp/Configuration.html)
+* [DevOps guide](https://ay2122s1-cs2103-w14-1.github.io/tp/DevOps.html)
---------------------------------------------------------------------------------------------------------------------
+---
## **Appendix: Requirements**
@@ -257,121 +633,504 @@ _{Explain here how the data archiving feature will be implemented}_
**Target user profile**:
-* has a need to manage a significant number of contacts
-* prefer desktop apps over other types
-* can type fast
-* prefers typing to mouse interactions
-* is reasonably comfortable using CLI apps
+* Authorised staff from small family clinics (both receptionist and doctors)
+* Clinic staff from clinics that lack access to cloud and are undeveloped compared to hospitals
+* Clinic staff from young clinics that do not have technological capabilities
+* Prefer a type-first experience, and can type fast
-**Value proposition**: manage contacts faster than a typical mouse/GUI driven app
+**Value proposition**:
+* Provide a centralised platform for clinic staff to manage patient records, reducing man hours from managing paper documents
+Today, small family clinics often record patient information using paper application forms.
+Such recording of patient information results in the clinic having a messy and inefficient patient record information;
+the family clinic will have to flip through files and documents in order to find the patient. Doc’it aims to provide a
+centralised platform for authorised staff from small family clinics to view, update and onboard patients.
+With Doc’it, small family clinics are able to reduce man hours from managing paper documents,
+and translate these ‘saved’ hours into providing better frontline service to patients, focusing on what they do best.
### User stories
Priorities: High (must have) - `* * *`, Medium (nice to have) - `* *`, Low (unlikely to have) - `*`
-| Priority | As a … | I want to … | So that I can… |
-| -------- | ------------------------------------------ | ------------------------------ | ---------------------------------------------------------------------- |
-| `* * *` | new user | see usage instructions | refer to instructions when I forget how to use the App |
-| `* * *` | user | add a new person | |
-| `* * *` | user | delete a person | remove entries that I no longer need |
-| `* * *` | user | find a person by name | locate details of persons without having to go through the entire list |
-| `* *` | user | hide private contact details | minimize chance of someone else seeing them by accident |
-| `*` | user with many persons in the address book | sort persons by name | locate a person easily |
+
+| Priority | As a … | I want to … | So that I can… |
+| ---------- | ------------------------ | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------- |
+| `* * *` | clinic staff | create new patient details | add data of new patients in our clinic |
+| `* * *` | clinic staff | add medical history to patient details | have a background on the patient |
+| `* * *` | clinic staff | view patient details | better prescribe medication and treatments to my out-patients |
+| `* * *` | clinic staff | delete patient details | manage patients’ need for privacy when patients no longer visit the clinic |
+| `* * *` | clinic staff | view the prescriptions currently prescribed to my patients | provide correct prescriptions to them |
+| `* * *` | clinic staff | create new appointments from patients | track upcoming appointments |
+| `* * *` | clinic staff | view appointments from patients | know at-a-glance what are the upcoming appointments and the patients involved |
+| `* * *` | clinic staff | delete appointments from patients | re-organise appointments when either side cancels their appointments |
+| `* * *` | clinic staff | have appointments moved to appointment history | separate what are the upcoming appointments from past appointments |
+| `* * *` | clinic staff | view past appointments | track their medical history |
+| `* *` | clinic staff | edit appointments from patients | ensure appointment records are up-to-date |
+| `* *` | clinic staff | modify patient details | ensure that any changes in their information are up-to-date |
+| `* *` | clinic staff | edit prescriptions | ensure my patients’ current prescriptions are up-to-date |
+| `* *` | clinic staff | view the duration of prescriptions | decide whether they should be given additional prescriptions |
+| `* *` | clinic staff | move prescriptions to prescription history when patients have finished that prescription | |
+| `* *` | clinic staff | view the prescription history of patients | know what drugs my patients have taken before |
+| `* *` | clinic staff | cannot edit past prescriptions | prevent erroneous edits |
+| `* *` | clinic staff | verify that the patient has paid for his appointment | record that the patient has paid the bills |
+| `* *` | clinic staff | input the bill and price of the patient appointment | record the amount that the patient has paid |
+| `* *` | clinic staff | prevent editing past appointments | ensure past records cannot be incorrectly modified |
+| `* *` | clinic staff | filter patients by name | pull up patient records easily when requested |
+| `* *` | clinic staff | filter patients by the date of their appointment | know the list of patients per appointment day |
+| `* *` | clinic staff | filter patients by their prescriptions | gauge the demand of prescription_drug needed by the clinic |
+| `* *` | new clinic staff | go through a tutorial at the beginning | familiarise myself with how the app works and what it can do |
+| `* *` | new clinic staff | type a command to get all available commands and how they work | easily refer to the commands I can make |
+| `* *` | clinic staff | purge all current data | delete any experimental records |
+| `* *` | long term clinic staff | use shortened command aliases | speed up my work |
+| `* *` | clinic staff | easily make changes to the patient records without too many commands | my work can be done faster |
+| `* *` | clinic staff | view information on an appealing GUI | view information that is neatly organised |
+| `* *` | clinic staff | share a single patient database with other clinic staff | ensure all changes are synced |
*{More to be added}*
### Use cases
-(For all use cases below, the **System** is the `AddressBook` and the **Actor** is the `user`, unless specified otherwise)
+(For all use cases below, the **System** is the ``Doc'it`` and the **Actor** is the `user`, unless specified otherwise)
+
+**Use case: UC01 - List all patients**
+
+**MSS**
+
+1. User requests to list patients.
+2. `Doc'it` displays all patients.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The list is empty.
+
+ Use case ends.
+
+**Use case: UC02 - Add a patient**
+
+**MSS**
+
+1. User requests to add a patient.
+2. `Doc'it` adds the patient with necessary information.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. Necessary details of patient are absent (name, address, phone number).
+
+ * 1a1. `Doc'it` shows an error message.
-**Use case: Delete a person**
+ Use case resumes at step 1.
+* 1b. Patient details conflict with existing patient list.
+
+ * 1b1. `Doc'it` shows an error message.
+
+ Use case resumes at step 1.
+
+**Use case: UC03 - Delete a patient**
**MSS**
-1. User requests to list persons
-2. AddressBook shows a list of persons
-3. User requests to delete a specific person in the list
-4. AddressBook deletes the person
+1. `Doc'it` shows a list of patients.
+2. User requests to delete a specific patient in the list.
+3. `Doc'it` deletes the patient.
- Use case ends.
+ Use case ends.
**Extensions**
* 2a. The list is empty.
Use case ends.
+* 2b. The given index is invalid.
+
+ * 2b1. `Doc'it` shows an error message.
+
+ Use case resumes at step 2.
+
+
+**Use case: UC04 - List all appointments**
+
+**MSS**
+
+1. User requests to list appointments.
+2. `Doc'it` displays all appointments.
+
+ Use case ends.
+
+**Extensions**
+
+* 1a. The list is empty.
+
+ Use case ends.
+
+**Use case: UC05 - Add an appointment**
+
+**MSS**
+
+1. `Doc'it` displays all patients.
+2. User adds an appointment, matching the appointment to the specific patient.
+3. `Doc'it` adds the appointment and associates it to the patient.
+
+ Use case ends.
+
+**Extensions**
-* 3a. The given index is invalid.
+* 2a. The date of the appointment AND/OR the specified patient are invalid.
- * 3a1. AddressBook shows an error message.
+ * 2a1. `Doc'it` shows an error message.
Use case resumes at step 2.
-*{More to be added}*
+**Use case: UC06 - Edit an appointment**
-### Non-Functional Requirements
+**MSS**
-1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
-2. Should be able to hold up to 1000 persons without a noticeable sluggishness in performance for typical usage.
-3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+1. `Doc'it` displays all patients and appointments.
+2. User edits an appointment, specifying new appointment details to replace old appointment details.
+3. `Doc'it` edits the appointment details.
-*{More to be added}*
+ Use case ends.
-### Glossary
+**Extensions**
-* **Mainstream OS**: Windows, Linux, Unix, OS-X
-* **Private contact detail**: A contact detail that is not meant to be shared with others
+* 2a. The date of the appointment AND/OR the specified patient are invalid.
---------------------------------------------------------------------------------------------------------------------
+ * 2a1. `Doc'it` shows an error message.
-## **Appendix: Instructions for manual testing**
+ Use case resumes at step 2.
-Given below are instructions to test the app manually.
+**Use case: UC07 - Delete an appointment**
-
:information_source: **Note:** These instructions only provide a starting point for testers to work on;
-testers are expected to do more *exploratory* testing.
+**MSS**
-
+1. `Doc'it` displays all appointments.
+2. User requests to delete a specific appointment in the list.
+3. `Doc'it` deletes the appointment and removes the appointment association from the originally associated patient.
-### Launch and shutdown
+ Use case ends.
-1. Initial launch
+**Extensions**
- 1. Download the jar file and copy into an empty folder
+* 2a. The list is empty.
- 1. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
+ Use case ends.
+* 2a. The given index is invalid.
-1. Saving window preferences
+ * 2a1. `Doc'it` shows an error message.
- 1. Resize the window to an optimum size. Move the window to a different location. Close the window.
+ Use case resumes at step 2.
- 1. Re-launch the app by double-clicking the jar file.
- Expected: The most recent window size and location is retained.
+**Use case: UC08 - Archive an appointment**
-1. _{ more test cases … }_
+**MSS**
-### Deleting a person
+1. `Doc'it` displays all appointments.
+2. User requests to archive all appointments that are past its date.
+3. `Doc'it` archives all appointments that are past its date.
-1. Deleting a person while all persons are being shown
+ Use case ends.
- 1. Prerequisites: List all persons using the `list` command. Multiple persons in the list.
+**Extensions**
- 1. Test case: `delete 1`
- Expected: First contact is deleted from the list. Details of the deleted contact shown in the status message. Timestamp in the status bar is updated.
+* 2a. There are no appointments in the Appointment panel.
- 1. Test case: `delete 0`
- Expected: No person is deleted. Error details shown in the status message. Status bar remains the same.
+ Use case ends.
+* 2b. No appointments are past its date.
- 1. Other incorrect delete commands to try: `delete`, `delete x`, `...` (where x is larger than the list size)
- Expected: Similar to previous.
+ Use case ends.
-1. _{ more test cases … }_
+**Use case: UC09 - Add a prescription**
-### Saving data
+**MSS**
-1. Dealing with missing/corrupted data files
+1. User requests to list appointments.
+2. `Doc'it` displays all appointments.
+3. User adds a prescription, matching the prescription to the specific appointment by index.
+4. Doc'it adds the prescription and associates it to the appointment.
+
+ Use case ends.
+
+**Extensions**
+
+3a. The index of the appointment is invalid.
+* 3a1. Doc'it shows an error message.
+ Use case resumes at step 3.
+* 3b. The input field of medicine name, volume or duration is invalid.
+ * 3a1. Doc'it shows an error message.
+ Use case resumes at step 3.
+
+**Use case: UC010 - Delete a prescription**
+
+**MSS**
- 1. _{explain how to simulate a missing/corrupted file, and the expected behavior}_
+1. User requests to list appointments.
+2. `Doc'it` displays all appointments.
+3. User deletes a prescription, matching the prescription to the specific appointment by index and medicine name.
+4. Doc'it deletes the prescription
-1. _{ more test cases … }_
+
+
+**Extensions**
+* 3a. The index of the appointment is invalid.
+ * 3a1. Doc'it shows an error message.
+ Use case resumes at step 3.
+* 3b. The input field of medicine name is invalid.
+ * 3a1. Doc'it shows an error message.
+ Use case resumes at step 3.
+
+
+**Use case: UC11 - Add a Medical Entry to Patient**
+
+**MSS**
+
+1. `Doc'it` displays all patients.
+2. User requests to add a medical entry to a specified patient.
+3. `Doc'it` adds the medical entry and records the date of entry.
+
+ Use case ends.
+
+**Extension**
+* 2a. The given index is invalid.
+ * 2a1. `Doc'it` shows an error message.
+ Use case resumes at step 1.
+
+**Use case: UC12 - Delete a Medical Entry from a Patient**
+
+**MSS**
+
+1. `Doc'it` displays all patients.
+2. User requests to delete a specified medical entry from a specified patient.
+3. `Doc'it` deletes the specified medical entry from the patient.
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. The given index specifying the medical entry is invalid.
+
+ * 2a1. `Doc'it` shows an error message.
+
+ Use case resumes at step 1.
+
+* 2b. The given index specifying the patient is invalid.
+
+ * 2b1. `Doc'it` shows an error message.
+
+ Use case resumes at step 1.
+
+* 2c. The patient specified has an empty medical history.
+
+ * 2c1. `Doc'it` shows an error message.
+
+ Use case resumes at step 1.
+
+
+**Use case: UC13 - Find patient**
+
+**MSS**
+
+1. `Doc'it` displays all patients.
+2. User requests to find patients whose names or medical histories match the given set of keywords.
+3. `Doc'it` lists a filtered list of patients that satisfy the keywords given by the user.
+
+ Use case ends.
+
+
+**Use case: UC14 - Exit program**
+
+**MSS**
+
+1. User requests to exit the program.
+2. `Doc'it` saves and writes all files.
+3. `Doc'it` exits and closes.
+
+ Use case ends.
+
+**Extensions**
+
+* 2a. `Doc'it` is unable to save file.
+
+ * 2a1. `Doc'it` shows an error message.
+
+ Use case resumes at step 1.
+
+### Non-Functional Requirements
+
+1. Should work on any _mainstream OS_ as long as it has Java `11` or above installed.
+2. Should be able to hold up to 1000 patients without noticeable sluggishness in performance for typical usage.
+3. A user with above average typing speed for regular English text (i.e. not code, not system admin commands) should be able to accomplish most of the tasks faster using commands than using the mouse.
+4. Should not require an external installer or launcher.
+5. Data should be stored locally in an easily-editable text file.
+6. Should not depend on any cloud-based remote server.
+7. Data should not be stored in an external Database Management System (DBMS) or data warehouse.
+8. Clinic staff inexperienced in using computers should be able to easily use Doc'it.
+9. The GUI should work well and not result in resolution-related inconveniences to the user for screen resolutions 1920x1080 and higher, and screen scale at 100% and 125%.
+10. The GUI should be usable, defined as the ability to carry out all functions, even if resolution is not optimal, for resolutions 1280x720 and higher and screen scale at 150%.
+
+### Glossary
+
+| Term | Definition |
+|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------|
+| Mainstream OS | Windows, Linux, Unix, OS-X |
+| Appointment | A scheduled consult between a patient and the clinic's doctor at an exact date and time. The doctor may or may not prescribe medication. |
+| Archive | Storage for data that is non-urgent, e.g. appointment records that are past their date. |
+| Patient Record | A record of a patient's name, phone number, address, email and medical history. |
+| Prescription | The issued medication/treatment for a patient along with a duration and volume. |
+| Expired Appointment | An appointment that is 24-hours past its scheduled time. |
+| Medical History | A patient's set of recorded medical complications from the past. |
+| Medical Entry | A specific past health complication of a patient. There can be multiple medical entries within a patient's medical history.
+
+---
+
+## **Appendix: Instructions for manual testing**
+
+Given below are instructions to test the app manually.
+
+
:information_source: **Note:** These instructions only provide a starting point for testers to work on;
+testers are expected to do more *exploratory* testing.
+
+
+### Launch and shutdown
+
+1. Initial launch
+
+ 1. Download the jar file and copy into an empty folder
+ 2. Double-click the jar file Expected: Shows the GUI with a set of sample contacts. The window size may not be optimum.
+
+### Deleting a patient
+
+1. Deleting a patient while all patients are being shown
+
+ 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list.
+ 2. Test case: `pt delete 1`
+ Expected: First patient is deleted from the list. Details of the deleted patient shown in the status message.
+ 3. Test case: `pt delete 0`
+ Expected: No patient is deleted. Error details shown in the status message.
+ 4. Other incorrect patient delete commands to try: `pt delete`, `delete 1`, `pt delete x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+2. Deleting a patient that has an appointment
+
+ 1. Prerequisites: Add an appointment to that patient at index 1 e.g. `apmt add i/1 d/2022-12-31 1200`
+ 2. Test case: `delete 1`
+ Expected: First patient is deleted from Patient Panel. Patient's appointments in Appointment panel is deleted as well.
+
+### Adding a patient
+1. Adding a patient
+
+ 1. Test case: `pt add n/John Doe p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25 m/diabetes`.
+ Expected: Patient is added to the end of the list. Details of the added patient shown in the status message.
+ 2. Test case: `pt add p/98765432 e/johnd@example.com`.
+ Expected: No patient is added. Error details shown in the status message.
+ 3. Other incorrect patient add commands to try: `pt add`, `add 1`, `pt add m/diabetes`, `...`
+ Expected: Similar to previous.
+
+### Editing a patient
+1. Editing a patient
+ 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list.
+ 2. Test case: `pt edit 1 n/Joshen Lim`
+ Expected: Name of first patient is edited. Details of the edited patient shown in the status message.
+ 3. Test case: `pt edit 1 n/`
+ Expected: No edit is executed. Error details shown in the status message.
+ 4. Other incorrect patient add commands to try: `pt edit`, `edit 1 n/Joshen Lim`, `pt edit x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+### Adding a Medical Entry to a Patient's Medical History
+1. Adding a medical Entry
+ 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list.
+ 2. Test case: `pt ma 1 m/diabetes`
+ Expected: Medical History of first patient has the new medical entry added to the back of the list. The medical entry should have the corresponding date recorded. Details of the patient shown in the status message.
+ 3. Test case: `pt ma 1 i/`
+ Expected: No medical entry is added. Error details shown in the status message.
+ 4. Other incorrect patient add commands to try: `pt ma`, `ma 1 m/high blood pressure`, `pt ma x m/lovesick`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+### Deleting a Medical Entry from a Patient's Medical History
+1. Deleting a medical entry from a patient's non-empty medical history
+ 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list.
+ 2. Test case: `pt md 1 i/1`
+ Expected: Medical Entry of the specified index within the Medical History of first patient is deleted. If there are other entries within the Medical History, the list of entries will re-index from 1. If there are no other entries within the Medical History, "No medical history recorded." is shown on the Patient Card. Details of the patient shown in the status message.
+ 3. Test case: `pt md 1 i/`
+ Expected: No medical entry is deleted. Error details shown in the status message.
+ 4. Other incorrect patient add commands to try: `pt md`, `md 1 i/1`, `pt md x i/1`, `pt md 1 i/x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+2. Deleting a medical entry from a patient's with an empty medical history
+ 1. Prerequisites: List all patients using the `pt list` command. Multiple patients in the list.
+ 2. Test case: `pt md 1 i/1`
+ Expected: Nothing is changed. Status message reflects that there is "No medical history record to delete from the patient".
+ 3. Test case: `pt md 1 i/`
+ Expected: Nothing is changed. Error details shown in the status message.
+ 4. Other incorrect patient add commands to try: `pt md`, `md 1 i/1`, `pt md x i/1`, `pt md 1 i/x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+### Saving data
+
+1. Dealing with missing/corrupted data files
+ 1. If JSON files are missing, `Doc'it` will start with a sample AddressBook and AppointmentBook with sample Patients and sample Appointments respectively.
+ 2. If JSON files are corrupted, `Doc;it` will start with a blank address book and blank appointment book.
+ 2. Save appointment
+ 1. Prerequisite: Create an appointment e.g. `apmt add i/1 d/2022-12-31 1200`
+ 2. Test case: Close and reopen the application
+ Expected: Appointments reference the same patients as previous session before it was closed.
+
+### Adding an appointment
+
+Prerequisites: Use sample addressbook or the same list of patients from index 1 to 2.
+1. Test case: `apmt add i/1 d/2999-12-31 2359`
+ Expected: New appointment added in Upcoming tab of Appointments panel for Patient 1 on 31 Dec 2999 2359.
+2. Test case: Conduct test case 1, then enter `apmt add i/2 d/2999-12-31 2359`
+ Expected: New appointment added in Upcoming tab of Appointments panel for Patient 2 on 31 Dec 2999 2359 even if test case 1 appointment exists.
+3. Test case: `apmt add i/1 d/2000-1-1 0000`
+ Expected: New appointment added in Archived tab of Appointments panel for Patient 1 on 1 Jan 2000 0000.
+4. Test case: Conduct test case 3, then enter `apmt add i/2 d/2000-1-1 0000`
+ Expected: New appointment added in Archived tab of Appointments panel for Patient 2 on 1 Jan 2000 0000 even if test case 3 appointment exists.
+5. Test case: `apmt add i/1 d/2039-2-29 1200`
+ Expected: No new appointment is created because 2039 is not a leap year and Feb 2039 only has 28 days. Error message shown.
+
+Editing an appointment test cases are similar to adding an appointment except for an additional appointment index to be specified before Patient Index and Datetime.
+
+### Deleting an appointment
+
+1. Deleting an appointment while all appointments are being shown
+
+ 1. Prerequisites: List all appointments in the Upcoming tab using the `apmt list` command. At least one appointment in list.
+ 2. Test case: `apmt delete 1`
+ Expected: First appointment is deleted from the list. Details of the deleted appointment shown in the status message.
+ 3. Test case: `apmt delete 0`
+ Expected: No appointment is deleted. Error details shown in the status message.
+ 4. Other incorrect delete commands to try: `apmt delete`, `apmt delete x`, `...` (where x is larger than the list size)
+ Expected: Similar to previous.
+
+
+### Adding a prescription
+Prerequisites: All test cases below must be independent and fulfills these assumptions:
+All appointments listed using the `apmt list` command. 5 appointments shown in the list. All appointments have no prescriptions.
+1. Test case: `apmt pa 1 n/Penicillin v/400 ml d/2 times a week`
+ Expected: First appointment now contains a prescription label `penicillin | 400ml | 2 times a week`.
+2. Test case: enter `apmt pa 1 n/Penicillin v/400 ml d/2 times a week` twice
+ Expected: No new prescription is created. Error message `Operation would result in duplicate prescriptions` is shown.
+3. Test case: `apmt pa 1 n/PenicillinPenicillinPenicillin v/400 ml d/2 times a week`
+ Expected: No new prescription is created. Error message `Medicine name can only be 20 characters long.` is shown.
+4. Test case: `apmt pa 1 n/Penicillin v/400000000000000000000 ml d/2 times a week`
+ Expected: No new prescription is created. Error message `Volume can only be 20 characters long.` is shown.
+5. Test case: `apmt pa 1 n/Penicillin v/400 ml d/99999999999999999999999999999999 times a week `
+ Expected: No new prescription is created. Error message `Duration can only be 40 characters long.` is shown.
+6. Test case: `apmt pa 0 n/Penicillin v/400 ml d/2 times a week `
+ Expected: No new prescription is created. Error message `Index is not a non-zero unsigned integer.` is shown.
+7. Test case: `apmt pa 6 n/Penicillin v/400 ml d/2 times a week `
+ Expected: No new prescription is created. Error message `The appointment index provided is invalid.` is shown.
+
+### Deleting a prescription
+Prerequisites: All test cases below must be independent and fulfills these assumptions:
+All appointments listed using the `apmt list` command. Multiple appointments shown in the list.
+First appointment has a single prescription `penicillin | 400ml | 2 times a week`. All other appointments have no prescriptions.
+1. Test case: `apmt pd 1 n/Penicillin`
+ Expected: First appointment now do not contain any prescriptions.
+2. Test case: enter `apmt pa 0 n/Penicillin` twice
+ Expected: No new prescription is created. Error message `Index is not a non-zero unsigned integer.` is shown.
+3. Test case: `apmt pa 1 n/Panadol`
+ Expected: No new prescription is created. Error message `Medicine name not found in prescription list.` is shown.
diff --git a/docs/SettingUp.md b/docs/SettingUp.md
index 275445bd551..9ddcd45d18a 100644
--- a/docs/SettingUp.md
+++ b/docs/SettingUp.md
@@ -23,7 +23,7 @@ If you plan to use Intellij IDEA (highly recommended):
1. **Import the project as a Gradle project**: Follow the guide [_[se-edu/guides] IDEA: Importing a Gradle project_](https://se-education.org/guides/tutorials/intellijImportGradleProject.html) to import the project into IDEA.
:exclamation: Note: Importing a Gradle project is slightly different from importing a normal Java project.
1. **Verify the setup**:
- 1. Run the `seedu.address.Main` and try a few commands.
+ 1. Run the `seedu.docit.Main` and try a few commands.
1. [Run the tests](Testing.md) to ensure they all pass.
--------------------------------------------------------------------------------------------------------------------
diff --git a/docs/Testing.md b/docs/Testing.md
index 8a99e82438a..e3d24a62b0b 100644
--- a/docs/Testing.md
+++ b/docs/Testing.md
@@ -29,8 +29,8 @@ There are two ways to run tests.
This project has three types of tests:
1. *Unit tests* targeting the lowest level methods/classes.
- e.g. `seedu.address.commons.StringUtilTest`
+ e.g. `seedu.docit.commons.StringUtilTest`
1. *Integration tests* that are checking the integration of multiple code units (those code units are assumed to be working).
- e.g. `seedu.address.storage.StorageManagerTest`
+ e.g. `seedu.docit.storage.StorageManagerTest`
1. Hybrids of unit and integration tests. These test are checking multiple code units as well as how the are connected together.
- e.g. `seedu.address.logic.LogicManagerTest`
+ e.g. `seedu.docit.logic.LogicManagerTest`
diff --git a/docs/UserGuide.md b/docs/UserGuide.md
index 3716f3ca8a4..6a38cd6d297 100644
--- a/docs/UserGuide.md
+++ b/docs/UserGuide.md
@@ -3,40 +3,125 @@ layout: page
title: User Guide
---
-AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized for use via a Command Line Interface** (CLI) while still having the benefits of a Graphical User Interface (GUI). If you can type fast, AB3 can get your contact management tasks done faster than traditional GUI apps.
-
-* Table of Contents
-{:toc}
+![Doc'it icon](images/DocitHeader.png)
+
+`Doc'it` provides a centralised platform for authorised staff from small family clinics to view, update, and onboard
+patient records, solving the inefficient paper records and files used today. With `Doc'it`, small family clinics can
+reduce man-hours in managing paper files, translating this saved time into better front-line care services.
+
+#### Table of Contents
+
+1. [Quick Start](#quick-start)
+2. [Overview of Features](#overview-of-features)
+ 1. [Basic Commands](#general-commands)
+ - [Clear all records](#clear-all-records-doc-clear)
+ - [Help](#help-doc-help)
+ - [Exit the program](#exit-the-program-doc-exit)
+ 2. [Patient-related Commands](#patient-commands)
+ - [Add a patient](#add-a-patient-pt-add)
+ - [List all patients](#list-all-patients-pt-list)
+ - [Edit a patient](#edit-a-patient-pt-edit)
+ - [Delete a patient](#delete-a-patient-pt-delete)
+ - [Add to medical history](#add-a-medical-history-pt-ma)
+ - [Delete to medical history](#delete-a-medical-history-pt-md)
+ - [Find patient\(s\)](#find-a-patient-with-keywords-pt-find-keywords)
+ 3. [Appointment-related Commands](#appointment-commands)
+ - [Add an appointment](#add-an-appointment-apmt-add)
+ - [List all appointments](#list-all-appointments-apmt-list)
+ - [List all archived appointments](#list-all-archived-appointments-apmt-alist)
+ - [Edit an appointment](#edit-an-appointment-apmt-edit)
+ - [Delete an appointment](#delete-an-appointment-apmt-delete)
+ - [Archive an appointment](#archive-an-appointment-apmt-archive)
+ - [Sort all appointments](#sort-all-appointments-apmt-sort)
+ - [Add prescription](#add-prescription-apmt-pa)
+ - [Delete prescription](#delete-prescription-apmt-pd)
+4. [FAQ](#faq)
+5. [Command Summary](#command-summary)
+6. [Glossary](#glossary)
--------------------------------------------------------------------------------------------------------------------
## Quick start
-
1. Ensure you have Java `11` or above installed in your Computer.
-1. Download the latest `addressbook.jar` from [here](https://github.com/se-edu/addressbook-level3/releases).
+2. Download the latest `docit.jar` from [here](https://github.com/AY2122S1-CS2103-W14-1/tp/releases).
-1. Copy the file to the folder you want to use as the _home folder_ for your AddressBook.
+3. Copy the file to the folder you want to use as the _home folder_ for your `Doc'it`.
-1. Double-click the file to start the app. The GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
+4. Double-click the file to start the app. The GUI similar to the below should appear in a few seconds. Note how the app contains some sample data.
+
![Ui](images/Ui.png)
-1. Type the command in the command box and press Enter to execute it. e.g. typing **`help`** and pressing Enter will open the help window.
+5. Type the command in the command box and press Enter to execute it. e.g. typing **`doc help`** and pressing Enter will open the help window.
Some example commands you can try:
- * **`list`** : Lists all contacts.
+ * **`pt list`** : Lists all patients.
- * **`add`**`n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01` : Adds a contact named `John Doe` to the Address Book.
+ * **`doc exit`** : Exits the app.
- * **`delete`**`3` : Deletes the 3rd contact shown in the current list.
+6. Refer to the **Features** section below for details of each command.
+this on
+7. Doc'it is built specifically for small clinic staff based in Singapore. Hence, the date and time run in Singapore time.
- * **`clear`** : Deletes all contacts.
+--------------------------------------------------------------------------------------------------------------------
- * **`exit`** : Exits the app.
+## Overview of Features
-1. Refer to the [Features](#features) below for details of each command.
+
+
+This section provides a brief overview of `Doc'it`. The intention is for users to gain a better
+understanding of basic functionalities of `Doc'it`, before diving into specific commands.
+
+
+
+1. **Basic functionality**
+ 1. Clear all records
+ 2. Get Help
+ 3. Exit app
+2. **Managing Patient Records**
+ 1. Create a new Patient Record
+ 2. View details of Patient Record
+ 3. Delete Patient Record
+ 4. Edit Patient Record
+ 5. Add Medical History from a Patient Record
+ 6. Delete Medical History of a Patient Record
+ 7. Find filtered patient records based on keywords
+3. **Managing Patient Appointments**
+ 1. Create a new appointment
+ 2. View appointment
+ 3. Delete appointment
+ 4. Archive appointment
+ 5. List appointments
+ 6. Sort appointments (in order of urgency)
+ 7. Managing appointment prescriptions
+ 1. Add prescription
+ 2. Remove prescription
+
+##Navigating Doc'it
+This section details the various components of Doc'it interface and how you could go about navigating Doc'it.
+
+ ![Navigability](images/Navigability.png)
+
+### Patient View
+![Navigability](images/PatientView.png)
+In this view, you can view all Patients. Each Patient has a name, phone number, address, email and a Medical History.
+
+All patient-related commands will have change parts of the Patient View.
+
+### Appointment View
+![Navigability](images/AppointmentView.png)
+In this view, you can view all Appointments. Each Appointment has the patient, date and time.
+
+The AppointmentView comprises of two types of Appointments: Upcoming and Archive. Upcoming appointments are scheduled appointments, while Archived appointments are previous appointments that have been archived. You can switch between the two with the `apmt list` and `apmt alist` command. Alternatively, you could also click on the corresponding tab.
+
+### Command Result Status Display
+![Navigability](images/CommandResultStatusDisplay.png)
+In this component, you can view the messages and feedback from Doc'it after every command.
+
+### Command Box
+![Navigability](images/CommandBox.png)
+This is the component where you will input your commands. After inputting your commands, you may click the `Enter` key on your keyboard. Alternatively, you can click the `Send` button displayed here.
---------------------------------------------------------------------------------------------------------------------
## Features
@@ -48,145 +133,442 @@ AddressBook Level 3 (AB3) is a **desktop app for managing contacts, optimized fo
e.g. in `add n/NAME`, `NAME` is a parameter which can be used as `add n/John Doe`.
* Items in square brackets are optional.
- e.g `n/NAME [t/TAG]` can be used as `n/John Doe t/friend` or as `n/John Doe`.
+ e.g. `n/NAME [m/MEDICAL_HISTORY]` can be used as `n/John Doe m/cancer` or as `n/John Doe`.
-* Items with `…` after them can be used multiple times including zero times.
- e.g. `[t/TAG]…` can be used as ` ` (i.e. 0 times), `t/friend`, `t/friend t/family` etc.
+* Items with `…` after them can be used multiple times including zero times.
+ e.g. `[m/MEDICAL_HISTORY]… ` can be used as ` ` (i.e. 0 times), `m/Diabetes`, `m/Scoliosis m/High Blood Pressure` etc.
* Parameters can be in any order.
e.g. if the command specifies `n/NAME p/PHONE_NUMBER`, `p/PHONE_NUMBER n/NAME` is also acceptable.
-* If a parameter is expected only once in the command but you specified it multiple times, only the last occurrence of the parameter will be taken.
+* If a parameter is expected only once in the command, but you specified it multiple times, only the last occurrence of the parameter will be taken.
e.g. if you specify `p/12341234 p/56785678`, only `p/56785678` will be taken.
* Extraneous parameters for commands that do not take in parameters (such as `help`, `list`, `exit` and `clear`) will be ignored.
e.g. if the command specifies `help 123`, it will be interpreted as `help`.
+* `INDEX` must a positive integer of the given item in the panel.
+
+* `DATETIME` must be in the format `yyyy-mm-dd HHmm` for all commands, with time using 24-Hour notation.
+ e.g. `2021-10-28 1530` indicates 28 Oct 2021 at 3.30pm
+
-### Viewing help : `help`
+--------------------------------------------------------------------------------------------------------------------
-Shows a message explaning how to access the help page.
+## Basic Commands
+This section covers basic application-related commands. All of these commands have `doc` in front of them.
-![help message](images/helpMessage.png)
+### Clear all records: `doc clear`
-Format: `help`
+Clears all patient records and appointment records (upcoming and archived). This is an irreversible operation.
+Format: `doc clear`
-### Adding a person: `add`
+---
-Adds a person to the address book.
+### Help: `doc help`
-Format: `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
+Shows the user manual for `Doc'it` explaining how to access the help page.
-
+Format: `doc help`
-Examples:
-* `add n/John Doe p/98765432 e/johnd@example.com a/John street, block 123, #01-01`
-* `add n/Betsy Crowe t/friend e/betsycrowe@example.com a/Newgate Prison p/1234567 t/criminal`
+![DocHelp](images/DocHelp.png)
-### Listing all persons : `list`
+---
-Shows a list of all persons in the address book.
+### Exit the program: `doc exit`
-Format: `list`
+Exits the program.
-### Editing a person : `edit`
+Format: `doc exit`
-Edits an existing person in the address book.
+---
-Format: `edit INDEX [n/NAME] [p/PHONE] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
+## Patient Commands
+Patient is the primary entity in `Doc'it`. This section documents how to perform create, update, read and delete operations on patient
+records.
-* Edits the person at the specified `INDEX`. The index refers to the index number shown in the displayed person list. The index **must be a positive integer** 1, 2, 3, …
-* At least one of the optional fields must be provided.
-* Existing values will be updated to the input values.
-* When editing tags, the existing tags of the person will be removed i.e adding of tags is not cumulative.
-* You can remove all the person’s tags by typing `t/` without
- specifying any tags after it.
+>:information_source: All patient-related commands have the keyword `pt` in front of them.
-Examples:
-* `edit 1 p/91234567 e/johndoe@example.com` Edits the phone number and email address of the 1st person to be `91234567` and `johndoe@example.com` respectively.
-* `edit 2 n/Betsy Crower t/` Edits the name of the 2nd person to be `Betsy Crower` and clears all existing tags.
+### Add a patient: `pt add`
-### Locating persons by name: `find`
+Creates a new patient record.
-Finds persons whose names contain any of the given keywords.
+**Format:** `pt add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [m/MEDICAL_HISTORY]...`
-Format: `find KEYWORD [MORE_KEYWORDS]`
+- `MEDICAL_HISTORY` is optional; if `MEDICAL_HISTORY` is not given, an empty string of text will be used.
+- `MEDICAL_HISTORY` can be added multiple times within a single `pt add` command, as indicated by the ```...``` used.
-* The search is case-insensitive. e.g `hans` will match `Hans`
-* The order of the keywords does not matter. e.g. `Hans Bo` will match `Bo Hans`
-* Only the name is searched.
-* Only full words will be matched e.g. `Han` will not match `Hans`
-* Persons matching at least one keyword will be returned (i.e. `OR` search).
- e.g. `Hans Bo` will return `Hans Gruber`, `Bo Yang`
+**Examples:**
+- `pt add n/Joshen Lim p/99998888 e/joshen@gmail.com a/123 Clementi Road SG293821`
-Examples:
-* `find John` returns `john` and `John Doe`
-* `find alex david` returns `Alex Yeoh`, `David Li`
- ![result for 'find alex david'](images/findAlexDavidResult.png)
+**Expected Outcome:**
+```
+New patient added:
+Joshen Lim; Phone: 99988888; Email: joshen@gmail.com; Address: 123 Clementi Road SG293821
+```
-### Deleting a person : `delete`
+**GUI Display:**
+![PtAdd](images/PtAdd.png)
-Deletes the specified person from the address book.
-Format: `delete INDEX`
+---
-* Deletes the person at the specified `INDEX`.
-* The index refers to the index number shown in the displayed person list.
-* The index **must be a positive integer** 1, 2, 3, …
+### List all patients: `pt list`
-Examples:
-* `list` followed by `delete 2` deletes the 2nd person in the address book.
-* `find Betsy` followed by `delete 1` deletes the 1st person in the results of the `find` command.
+Shows a list of all patients in the record system.
-### Clearing all entries : `clear`
+Format: `pt list`
-Clears all entries from the address book.
+**Expected Outcome:**
+```
+Listed all patients
+```
-Format: `clear`
+**GUI Display:**
+![Patient Card](images/PatientCard.png)
+---
-### Exiting the program : `exit`
+### Edit a patient: `pt edit`
-Exits the program.
+Edits the details of a specified patient.
-Format: `exit`
+**Format:** `pt edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [m/MEDICAL_HISTORY]`
+- All fields are optional but if stated, must not be null or empty
+- `INDEX` is compulsory when making an edit to patient details
-### Saving the data
+**Examples:**
+- `pt edit 1 n/Joshen Tan m/Heartache`
-AddressBook data are saved in the hard disk automatically after any command that changes the data. There is no need to save manually.
+**Expected outcome:**
+```
+Edited Patient:
+Joshen Tan; Phone: 12345678; Email: google@gmail.com; Address: 311 clementi SG540192; Medical History: Heartache, recorded 31 Oct 2021
+```
-### Editing the data file
+---
-AddressBook data are saved as a JSON file `[JAR file location]/data/addressbook.json`. Advanced users are welcome to update data directly by editing that data file.
+### Delete a patient: `pt delete`
-
:exclamation: **Caution:**
-If your changes to the data file makes its format invalid, AddressBook will discard all data and start with an empty data file at the next run.
-
+Deletes a patient record, including all information about the patient.
+
+**Format:** `pt delete INDEX`
+
+- Deletes the patient at the specified `INDEX` (one-indexed).
+
+**Examples:**
+```
+pt list
+pt delete 1
+```
+
+**Expected Outcome:**
+```
+Deleted patient:
+Joshen Tan; Phone: 12345678; Email: google@gmail.com; Address: 311 clementi SG540192; Medical History: Heartache, recorded 31 Oct 2021
+```
+
+---
+
+### Add a Medical Entry: `pt ma`
+
+Adds a medical entry to the Medical History of a Patient Record, saving the medical history and ```today``` as the date of entry.
+
+**Format:** `pt ma INDEX m/MEDICAL_HISTORY...`
+
+- Adds a medical history to the patient at the specified `INDEX` (one-indexed).
+- Multiple entries of medical history can be added in one command: e.g. `m/Diabetes`, `m/Scoliosis m/High Blood Pressure` etc.
+- `m/MEDICAL_HISTORY` is a required field in this command
+
+**Examples:**
+```
+pt list
+pt ma 1 m/diabetes
+```
+
+**Expected Outcome:**
+```
+Updated:
+Charlotte Oliveiro; Phone: 93210283; Email: charlotte@example.com; Address: Blk 11 Ang Mo Kio Street 74, #11-04; Medical History: diabetes, recorded 8 Nov 2021
+```
+
+**GUI Display:**
+![Add Medical History](images/AddMedicalHistory.png)
+
+**Restrictions:**
+- Can only add up to 8 medical entries per patient
+- Each medical entry can only have up to 50 characters
+
+---
+
+### Delete a Medical History: `pt md`
+
+Deletes a medical history to the Patient Record.
+
+**Format:** `pt md INDEX i/MEDICAL_HISTORY_INDEX`
+
+- Deletes a medical history from the patient at the specified `INDEX` (one-indexed). The entry deleted is specified by the `MEDICAL_HISTORY_INDEX`
+
+**Examples:**
+- `pt md 1 i/1`
+
+**Expected Outcome:**
+```
+Updated:
+Charlotte Oliveiro; Phone: 93210283; Email: charlotte@example.com; Address: Blk 11 Ang Mo Kio Street 74, #11-04
+```
+
+---
+
+### Find a Patient with keywords: `pt find [keywords...]`
+
+Finds all patients that match any one of the keywords listed. These keywords can come from
+either the Patient's Name or Medical History.
+
+**Format:** `pt find [keywords...]`
+
+- Finds all patients that match any one of the keywords listed.
+
+**Examples:**
+- `pt find Alex David diabetes high blood pressure`
+
+**Expected Outcome:**
+```
+4 patients listed!
+```
+
+---
-### Archiving data files `[coming in v2.0]`
+## Appointment Commands
+A patient in `Doc'it` may have appointments to visit the clinic.
-_Details coming soon ..._
+In the Appointments panel, upcoming appointments are shown in the Upcoming tab, and past appointments are archived in the Archived tab.
+
+One appointment stores these details:
+* Index of patient: The index of an existing patient in the Patients panel
+* Date and time: The date and time of the appointment
+
+>:information_source: All appointment-related commands have the keyword `apmt` in front of them.
+These commands modify the Appointments panel of `Doc'it`.
+
+### Add an appointment: `apmt add`
+Adds an appointment for the patient at the specified index in the Patients panel.
+
+**Format:** `apmt add i/PATIENT_INDEX d/DATETIME`
+
+- `PATIENT_INDEX`: Index of patient who should have this appointment
+- `DATETIME`: Date and time of appointment in format `yyyy-mm-dd HHmm`
+ - Year must be between 2000 to 2999 inclusive.
+
+**Examples:**
+* `apmt add i/1 d/2021-10-05 1500` adds appointment on 5 Oct 2021 at 3pm to patient at index 1.
+* `apmt add i/2 d/2022-12-31 0700` adds appointment on 31 Dec 2022 at 7am to patient at index 2.
+
+**Example Usage:**
+- `apmt add i/1 d/2021-12-28 1500`
+
+**Expected Outcome:**
+```
+New appointment added:
+Patient: Alex Yeoh; Datetime: 28 Dec 2021 1500; Prescription: []
+```
+
+### List all appointments: `apmt list`
+Shows the list of all appointments.
+
+**Format:** `apmt list`
+
+**Examples:**
+* `apmt list` Lists all appointments.
+
+**GUI Display:**
+![Appointment Card](images/AppointmentCard.png)
+
+### List all archived appointments: `apmt alist`
+Shows the list of all archived appointments.
+
+**Format:** `apmt alist`
+
+**Examples:**
+* `apmt alist` Lists all archived appointments.
+
+**GUI Display:**
+![Show Archived](images/ShowArchiveAppointments.png)
+
+### Edit an appointment: `apmt edit`
+
+Edits the details of an appointment at the specified index in the Appointments panel.
+
+**Format:** `apmt edit APMT_INDEX [i/PATIENT_INDEX] [d/DATETIME]`
+
+- `APMT_INDEX`: Index of appointment in the Appointments panel
+- `PATIENT_INDEX`: Index of patient who should have this appointment
+- `DATETIME`: Date and time of appointment in format `yyyy-mm-dd HHmm`
+ - Year must be between 2000 to 2999 inclusive.
+- At least one of the optional fields should be present
+
+> :bulb: Use `i/PATIENT_INDEX` to change whose appointment it belongs to.
+> e.g. `apmt edit 1 i/2` modifies the first appointment to belong to the patient at index 2
+
+**Examples:**
+- `apmt edit 1 i/2`
+- `apmt edit 1 d/2021-10-28 1500`
+- `apmt edit 1 i/1 d/2021-10-28 1500`
+
+**Example Usage:**
+- `apmt edit 1 i/1 d/2021-12-25 1500`
+
+**Expected Outcome:**
+```
+Edited Appointment:
+Patient: Alex Yeoh; Datetime: 25 Dec 2021 1500; Prescription: []
+```
+
+
+### Delete an appointment: `apmt delete`
+Deletes the appointment at the specified index in the Appointments panel.
+
+**Format:** `apmt delete INDEX`
+* Deletes 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, ...
+
+**Examples:**
+* `apmt list` Display Upcoming appointments tab.
+* `apmt delete 1` Deletes appointment at index 1.
+
+**Example Usage:**
+- `apmt delete 1`
+
+**Expected Outcome:**
+```
+Deleted Appointment:
+Patient: Alex Yeoh; Datetime: 28 Oct 2021 1500; Prescription: []
+
+```
+
+
+### Archive an appointment: `apmt archive`
+Archives an old appointment that is already past its date.
+
+**Format:** `apmt archive INDEX`
+* Archives 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, ...
+
+**Examples:**
+* `apmt archive 1` Archives appointment at index 1.
+
+**Expected Outcome:**
+```
+Archived Appointment:
+Patient: Alex Yeoh; Datetime: 31 Dec 2012 1200; Prescription: []
+```
+
+### Sort all appointments: `apmt sort`
+Shows a sorted list of all appointments based on urgency (appointments today > ascending date > ascending name).
+
+**Format:** `apmt sort`
+
+**Examples:**
+* `apmt sort` Lists all sorted appointments.
+
+**GUI Display:**
+![Sorted Appointments](images/SortAppointments.png)
+
+## Add prescription: `apmt pa`
+Adds a prescription to the designated appointment.
+
+
+**Format:** `apmt pa APMT_INDEX n/MEDICINE_NAME v/MEDICINE_VOLUME d/MEDICINE_DURATION`
+* The names of medicine added to the prescription list must be unique.
+
+**Examples:**
+* `apmt pa 1 n/Penicillin v/400 ml d/2 times a week`
+
+**Expected Outcome:**
+```
+New prescription added:
+Medicine: Penicillin
+Volume: 400 ml
+Duration: 2 times a week
+```
+
+**GUI Display:**
+![Add Prescription](images/AddPrescription.png)
+
+## Delete prescription: `apmt pd`
+Deletes a prescription from the designated appointment.
+
+**Format:** `apmt pd APMT_INDEX n/MEDICINE_NAME`
+
+**Examples:**
+* `apmt pd 1 n/panadol`
+
+**Expected Outcome:**
+```
+Deleted prescription:
+Medicine: panadol
+
+from John Doe's appointment.
+```
--------------------------------------------------------------------------------------------------------------------
## FAQ
**Q**: How do I transfer my data to another Computer?
-**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous AddressBook home folder.
+**A**: Install the app in the other computer and overwrite the empty data file it creates with the file that contains the data of your previous `Doc'it` home folder.
--------------------------------------------------------------------------------------------------------------------
## Command summary
-Action | Format, Examples
---------|------------------
-**Add** | `add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [t/TAG]…`
e.g., `add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 t/friend t/colleague`
-**Clear** | `clear`
-**Delete** | `delete INDEX`
e.g., `delete 3`
-**Edit** | `edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [t/TAG]…`
e.g.,`edit 2 n/James Lee e/jameslee@example.com`
-**Find** | `find KEYWORD [MORE_KEYWORDS]`
e.g., `find James Jake`
-**List** | `list`
-**Help** | `help`
+### Basic Commands
+
+| Command | Format |
+|-------------|---------------|
+| User Manual | `doc help` |
+| Clear | `doc clear` |
+| Exit | `doc exit` |
+
+### Patient-related Commands
+
+| Command | Format | Example |
+|---------|-------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
+| Add | `pt add n/NAME p/PHONE_NUMBER e/EMAIL a/ADDRESS [m/MEDICAL_HISTORY]...` | `pt add n/James Ho p/22224444 e/jamesho@example.com a/123, Clementi Rd, 1234665 m/cancer` |
+| Delete | `pt delete INDEX` | `pt delete 3` |
+| Edit | `pt edit INDEX [n/NAME] [p/PHONE_NUMBER] [e/EMAIL] [a/ADDRESS] [m/MEDICAL_HISTORY]` | `pt edit 2 n/James Lee e/jameslee@example.com` |
+| Find | `pt find n/NAME` | `pt find n/James Jake` |
+| List | `pt list` | - |
+| Add Medical History | `pt ma INDEX m/MEDICAL_HISTORY` | `pt ma 1 m/diabetes` |
+| Delete Medical History | `pt md INDEX i/MEDICAL_HISTORY_INDEX` | `pt md 1 i/1` |
+
+### Appointment and Prescription-related Commands
+
+| Command | Format | Example |
+|----------------------|-------------------------------------------------------------------|--------------------------------------------------------|
+| Add | `apmt add INDEX d/DATETIME` | `apmt add 1 d/2021-10-05 1600` |
+| Edit | `apmt edit APMT_INDEX [i/PATIENT_INDEX] [d/DATETIME]` | `apmt edit 1 d/2021-10-05 1600` |
+| Delete | `apmt delete INDEX` | `apmt delete 1` |
+| Archive | `apmt archive INDEX` | `apmt archive 1` |
+| List | `apmt list` | - |
+| List Archived | `apmt alist` | - |
+| Sort | `apmt sort` | - |
+| Add Prescription | `apmt pa APPOINTMENT_INDEX n/MEDICINE v/VOLUME d/DURATION ` | `apmt pa 1 n/Penicillin v/400 ml d/2 times a week ` |
+| Delete Prescription | `apmt pd APPOINTMENT_INDEX n/MEDICINE` | `apmt pd 1 n/Penicillin ` |
+
+--------------------------------------------------------------------------------------------------------------------
+
+## Glossary
+
+| Term | Definition |
+|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------|
+| Appointment | A scheduled consult between a patient and the clinic's doctor at an exact date and time. The doctor may or may not prescribe medication. |
+| Archive | Storage for data that is non-urgent, e.g. appointment records that are past their date. |
+| Patient Record | A record of a patient's name, phone number, address, email and medical history. |
+| Prescription | The issued medication/treatment for a patient along with a duration and volume. |
+| Expired Appointment | An appointment that is 24-hours past its scheduled time. |
+| Medical History | A list of past medical conditions faced by a patient. Each medical condition is stored as a Medical Entry. |
+| Medical Entry | Description of the past medical condition of a patient, with a date of record when the entry was recorded. |
diff --git a/docs/_config.yml b/docs/_config.yml
index 6bd245d8f4e..c42d6b04820 100644
--- a/docs/_config.yml
+++ b/docs/_config.yml
@@ -1,4 +1,4 @@
-title: "AB-3"
+title: "Doc'it"
theme: minima
header_pages:
@@ -8,7 +8,7 @@ header_pages:
markdown: kramdown
-repository: "se-edu/addressbook-level3"
+repository: "AY2122S1-CS2103-W14-1/tp"
github_icon: "images/github-icon.png"
plugins:
diff --git a/docs/_sass/minima/_base.scss b/docs/_sass/minima/_base.scss
index 0d3f6e80ced..e280cedfdb2 100644
--- a/docs/_sass/minima/_base.scss
+++ b/docs/_sass/minima/_base.scss
@@ -288,7 +288,7 @@ table {
text-align: center;
}
.site-header:before {
- content: "AB-3";
+ content: "Doc'it";
font-size: 32px;
}
}
diff --git a/docs/diagrams/AddAppointmentSequenceDiagram.png b/docs/diagrams/AddAppointmentSequenceDiagram.png
new file mode 100644
index 00000000000..3f3e43f0a41
Binary files /dev/null and b/docs/diagrams/AddAppointmentSequenceDiagram.png differ
diff --git a/docs/diagrams/AddAppointmentSequenceDiagram.puml b/docs/diagrams/AddAppointmentSequenceDiagram.puml
new file mode 100644
index 00000000000..a614428b44e
--- /dev/null
+++ b/docs/diagrams/AddAppointmentSequenceDiagram.puml
@@ -0,0 +1,49 @@
+@startuml
+!include style.puml
+
+box Logic LOGIC_COLOR_T1
+participant ":AddAppointmentCommand" as AddAppointmentCommand LOGIC_COLOR
+participant ":CommandResult" as CommandResult LOGIC_COLOR
+end box
+
+box Model MODEL_COLOR_T1
+participant ":Model" as Model MODEL_COLOR
+participant "lastShownList:LastShownList" as LastShownList MODEL_COLOR
+participant "toAdd:Appointment" as Appointment MODEL_COLOR
+end box
+
+[-> AddAppointmentCommand : execute()
+activate AddAppointmentCommand
+
+AddAppointmentCommand -> Model : getFilteredPatientList()
+activate Model
+
+Model --> AddAppointmentCommand : lastShownList
+deactivate Model
+
+AddAppointmentCommand -> LastShownList : get(targetPatientIndex)
+activate LastShownList
+LastShownList ---> AddAppointmentCommand : patientToMakeAppointment
+deactivate LastShownList
+
+create Appointment
+AddAppointmentCommand -> Appointment
+activate Appointment
+Appointment ---> AddAppointmentCommand
+deactivate Appointment
+
+AddAppointmentCommand -> Model : addAppointment(toAdd)
+activate Model
+Model ---> AddAppointmentCommand
+deactivate Model
+
+create CommandResult
+AddAppointmentCommand -> CommandResult
+activate CommandResult
+CommandResult ---> AddAppointmentCommand
+deactivate CommandResult
+
+[<--AddAppointmentCommand : result
+deactivate AddAppointmentCommand
+
+@enduml
diff --git a/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png
new file mode 100644
index 00000000000..79e16ad3ca8
Binary files /dev/null and b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.png differ
diff --git a/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml
new file mode 100644
index 00000000000..99344ff9f35
--- /dev/null
+++ b/docs/diagrams/AddMedicalEntryFeatureActivityDiagram.puml
@@ -0,0 +1,16 @@
+@startuml
+
+start
+:User inputs Add Medical Feature command;
+if () then ([user input is valid])
+: Find specified target patient from Patient Book;
+: Produce patient copy of target patient;
+: Add medical entry into patient copy's medical history;
+: Replace target patient in Patient Book with the patient copy;
+: Display updated Patient Book;
+else ([else])
+: Display Error Message;
+endif
+stop
+
+@enduml
diff --git a/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png
new file mode 100644
index 00000000000..f6b8780ee18
Binary files /dev/null and b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.png differ
diff --git a/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml
new file mode 100644
index 00000000000..cadd4696950
--- /dev/null
+++ b/docs/diagrams/AddMedicalEntryFeatureClassDiagram.puml
@@ -0,0 +1,52 @@
+@startuml
+!include style.puml
+skinparam arrowThickness 1.1
+skinparam arrowColor LOGIC_COLOR
+
+Package Model {
+Package Patient {
+class Patient MODEL_COLOR {
+}
+class MedicalHistory MODEL_COLOR {
+}
+}
+}
+Patient *-down-> "1"MedicalHistory MODEL_COLOR : contains >
+
+Package Logic <