Planned enhancement: Removal of Appointment Date

[juliantayyc]

For the following planned enhancement:

Removing the ability for users to manually input the log date and time might be overly restrictive. The development team assumes that therapists are taking logs using their application in real time. However, some therapists may choose to take their logs on other platforms and only migrate the information over at the end of the day, for example.

The team can consider making the date flag optional, and set the real-time date and time as default, but keep the ability for users to manually input the appointment date and time. Understanding the need for accountability, the team can implement a log added on field to distinguish between appointment date and time and log time.

[soc-se-bot]

Team's Response

We understand your concern and appreciate the suggestion. The value of this application lies in consolidating note taking as well as management into 1 single application, not to use a separate the log taking method only to migrate it at the end of the day.

As such in the future, if the app is robust enough, the importing of old appointments and taking new appointment will be separate. As such, removal of appointment seem to allow for less friction that therapists may face.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [x] I disagree

Reason for disagreement: I apologise for phrasing my bug report in such a way, in the interests of time I was not able to fully put into words what I meant by that, please allow me to clarify.

My concern is not about the data migration but rather the dual-role of date that the development team is currently suggesting.

Currently, my understanding is that the application uses entries/logs (the UG makes no distinction between these two words) as a means to keep track of the session information. In other words, a consultation with John on 10th July 2024, 3pm to 4pm will have an entry with the session notes associated with that appointment. Thus, the date here would refer to 10th July 2024, 3pm to 4pm, as that is the date and time that the appointment was scheduled for. This is useful for administrative and scheduling purposes as as a therapist it provides me an easy way of referencing appointments with patients (e.g. my appointment with John last Thursday at 3pm). This is implied in the application as well:

In planned enhancements, the team states that:

As we enhance the tracking of changes in session logs, our goal is to ensure full compliance with the code of conduct required by medical applications. We will only introduce edit and delete log commands once we are certain that they meet all necessary regulatory standards.

This is further elaborated in FAQ:

Q: Why can't I edit or delete logs? A: With regard to medical records, our research shows that it seems unethical to post-date or back-date medical information (1). Moreover, our software is not designed to keep track of time stamps and medical information changes. As such there will be no way of detecting malicious practices. Hence, given the potential legal issues, we have decided to disallow the editing and deletion of logs. However, there are mechanisms in place to prevent accidental inputs. The existence of save buttons in the text box being designed in a way that completely disallows users from saving empty logs. addentry helps prevent accidental saves as well as the text box being designed in a way that completely disallows users from saving empty logs. (1) Singapore Medical Council. (2016). Ethical Code and Ethical Guidelines. Section B3.6 and B4.5. Retrieved from https://www.healthprofessionals.gov.sg/docs/librariesprovider2/guidelines/2016-smc-ethical-code-and-ethical-guidelines--- (13sep16).pdf

It is my understanding that due to these concerns, the team has also planned for the following enhancement:

The appointment date field will be removed, as future commands will automatically tag session logs with the current date and time from the device, improving logging efficiency and eliminating the need for manual entry.

This planned enhancement implies that date is instead used as an official logging mechanism to track when logs are added/updated.

Although this is also valid, I feel that the team should not replace one use case for the date field for the other, but instead implement both as their own separate fields. This is why I have categorised this particular planned enhancement as a feature flaw.

Also, addressing:

The value of this application lies in consolidating note taking as well as management into 1 single application, not to use a separate the log taking method only to migrate it at the end of the day.

I appreciate the application's value in being a centralised platform for contact management for therapists. However, I feel that there is additional value in providing therapists with the option of using specific features as per their desired workflows, instead of forcing them to commit to the suggested workflow as prescribed by the development team. For example, as a therapist I may prefer to take handwritten session notes during an appointment to make my patients feel more comfortable (as opposed to constantly typing on my laptop). As a responsible therapist, I then need to analyse these session notes after the appointment has concluded and add in any potential treatment or follow up plans. I therefore may not necessarily update my logs on the application until I have completed all these, and would like to see functionality for such workflows.

---