soc-se-bot
commented
4 months ago Team's Response
Hello, thank you for raising this issue.
We understand the concern here. Our team did consider using Index instead of NRIC and the other fields.
However, the reason why we deviated away from Index in AB3 to the use of the NRIC (and the other fields) instead was because of the context of the application. CLInic deals with sensitive medical data and the costs of error are extremely high. Erroneously editing the appointment type for the wrong appointment may result in medical treatments not being available to the patient, or worst still, the wrong treatments being given. The same thing applies for notes and the other fields that can be edited.
The problem with using Index is that it increases the chances of error. The user could have seen the number wrongly or typed the wrong number in a rush. Clinic assistants may not always be focused enough to ensure that every index keyed in is correct.
Instead, the use of multiple fields NRIC, DATE and START_TIME reduces the chances of error. The odds of a patient with a similar NRIC having an appointment on the same date and time is extremely small. It is unlikely that erroneous edits will be made.
This was an elaborate explanation of our thought processes. But a trimmed version was also explained in our UG.
By enforcing the use of these fields to identify an appointment, especially the discipline of using the NRIC, it ensures that all changes in the database are intentional.
Hope this clarifies.
Response rejected.
Items for the Tester to Verify
:question: Issue response
Team chose [response.Rejected]
- [x] I disagree
Reason for disagreement: I understand the importance of preventing error in managing medical records. However, the current design of CLInic is undoubtedly too inefficient and less user-friendly as too many efforts are required just to execute a simple command. This is also why I emphasize on appointment-related commands in this bug report, as a simple command (especially mark and unmark) requires to user to type in three fields (NRIC, DATE and START_TIME), especially when these fields accept inputs with complicated characters like symbols and capital letter. For example, just to unmark an appointment, unmark i/T0123456A d/2024-04-10 from/10:00, a command like this which includes capital letters in NRIC, '-' symbol in DATE and : in TIME.
Perhaps another better implementation is to use the index to identify an appointment and prompt the user with a confirmation message after each command. With this modification, a much simpler command like unmark 1, then typing y or n to respond to the confirmation message will achieve the same result. Such design is much efficient and user-friendly, while still effectively preventing erroneous execution.
I believe that in real life, most of the users will prefer a design similar to my suggestion instead of the original design as time efficiency is also a huge consideration when choosing which application to use especially in this modern time. Hence, I will still consider this as a feature flaw as the dev team did not address this in the planned enhancement too.
For commands like deleteAppt, editAppt, mark, unmark, many fields are required (i/NRIC d/DATE from/START_TIME) just to identify that specific appointment which is extremely slow and inconvenient.
Suggestion: Use index instead of those fields to identify an appointment similar to AB3 is better.