didymental.md

layout	title
page	Didymus' Project Portfolio Page

Project: Doc'it

Overview

Doc’it provides a centralised platform for authorised staff from small family clinics to view, update, and onboard patient records and schedule appointments, 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 frontline care services.

Summary of Contributions

Given below are my contributions to the project:

• New Feature: Create MedicalHistory class to store the medical history of Patient Records.
  • What it does: allows clinic staff to record medical histories when a patient is created.
  • Justification: This feature improves the product significantly because clinic staff can have more medical information about a Patient, which allows for better diagnosis.
  • Highlights: This feature was challenging and required an in-depth analysis of design alternatives. The final design chosen was to build MedicalHistory class to compose multiple MedicalEntry subclasses, which required the use OOP composition and polymorphism principles. The implementation also introduced wrapper classes, Entry and EntryList for the purpose of defensive programming. It also required changes to Json serialisation for storage of the new MedicalHistory information. Storage was particularly challenging given the need to record the date of recording, and reboot the date according to what was saved. CRUD operations inherited from Ab3's Person class, now Patient, also needed to be modified to accommodate the new MedicalHistory attribute. Existing test cases for parser and CRUD operations inherited from AB3 needed modification.
• New Feature: Add and Delete MedicalEntry to the MedicalHistory of a Patient Record.
  • What it does: allows clinic staff to add and delete specified medical histories for an existing patient, with an automatic record of the date the description of the medical history was entered (for adding).
  • Justification: This feature improves the product significantly because clinic staff can record important medical details about the patient to have a stronger medical understanding. The automatic date of entry also ensures the medical history can be checked and updated. They can also delete wrong or irrelevant entries.
  • Highlights: This features requires a new Command to be created. It required some analysis of design alternatives. The implementation required modifications to existing commands, test cases and the Parser set of class.
  • Credits: The design of the code was modelled after existing AB3 command codes, due to the existing Parser and Command associations.
• New Feature: Modified GUI for Prescription.
  • What it does: allows clinic staff see Prescription added after executing command to add prescription to an appointment.
  • Justification: This feature improves the product significantly because clinic staff can visually view and record the prescriptions prescribed after an appointment.
  • Highlights: This features was challenging. It required a strong understanding of ObservableList and how ObservableList worked with the GUI. As Prescription was a class encapsulated by Appointment, merely changing the Prescription would not trigger an event for GUI to change as the ObservableList only observes Appointment objects. Thus, for every modification to Prescription, we needed to update the Appointment object by creating a copy of the Appointment object.
• Code contributed: RepoSense link
• Enhancements to existing features:
  • FIND PATIENT feature:
    • Enhanced pt find to be able to find a list of patients based on their medical history description. This enhancement allows clinic staff to find patients by their name and any description of their medical history.
  • Justification: clinic staff can find a list of patients not only by their name but by their medical history, making it easier to track patients with similar past conditions.
  • Wrote additional tests for existing features and new features, specifically add medical entry, delete medical entry
• Project management:
  • Managed releases v1.1 - v1.4 (4 releases) on Github
  • Coordinated forking workflow
  • Coordinated weekly tasks and delegated to individual members
• Coordinating and Maintaining Issue Tracker:
  • Coordinated sprint issues by dividing tasks and assigning tasks to group members (examples: #54, #55, #56, #57, #67, #75, #76, #77, #78, #79, #80, #81, #102, #108, and more)
• Documentation:
  • User Guide:
    • Added documentation for the section on MedicalHistory and all MedicalHistory related features expected outcomes #179, #240
    • Fix formatting of User Guide #255
  • Developer Guide:
    • Added implementation details of the MedicalHistory class, Add Medical Entry feature, Delete Medical Entry feature. #282
    • Drew the UML class diagram which captures the associations between MedicalHistory, MedicalEntry and Patient classes. #304
    • Drew the sequence and activity diagram which captures the associations between Logic and Model components for AddMedicalEntry, DeleteMedicalEntry features #282, #304, #321
    • Wrote 8 initial use cases #38,
    • Updated previous use cases and added 3 new use cases #38, #321
    • Added manual testing test cases for Adding a Patient, Deleting a Patient, Adding a Medical Entry, Deleting a Medical Entry from patient with non-empty medical history, Deleting a Medical Entry from patient with empty medical history #321
    • Updated target user profile and value proposition. #321
• Community:
  • PRs reviewed (with non-trivial review comments): #71, #29, #18, #61
  • Contributed to forum discussions (examples: 1, 2)
  • Reported bugs and suggestions for other teams in the class (example: 1)