nus-se-script
commented
1 day ago Team's Response
We do allow the users to add multiple medicines and sickness.
The multiplicity refers to having medicine/not having medicine - the workaround is to write all of the medicine together,. Similarly, this can be done for sickness.
However, we understand the confusion, and this is something we can change for future iterations
Items for the Tester to Verify
:question: Issue response
Team chose [response.NotInScope]
- [x] I disagree
Reason for disagreement: Hi, thanks for the reply. I understand the presence of a workaround may allow users to continue using the app as-is.
However, I believe the existence for a workaround itself may imply the presence of a feature flaw, albeit lower severity, especially when implementation for parsing multiple sicknesses and diseases fields in an Appointment input could have easily been done by replicating parsing for Tags in a Person input.
Even if the feature flaw is not present, I still believe there is a case for a type.DocumentationBug in this incident for a lack of communication on this workaround with a severity.Medium since it does affect users' understanding of the app's abilities. This is because there is no comment explicitly conveying this workaround, or an example exemplifying it in the documentation or the app, if I am not mistaken.
For example, as per the diagram attached in my original report, the multiplicities are implying that each Appointment's AppointmentDescriptor has either 0 to 1 Sickness and either 0 to 1 Medicine each. The use of the singular terms 'sickness' and 'medicine' may mislead the user to consider they can only (as I have been).
Furthermore, in all examples for add appt or edit appt commands in the DG test cases or UG examples, I cannot seem to find an explanation of this workaround.
The misleading nuance for only being able to add one sickness or medicine per appointment also appears in the User Guide, stating that an Appoinment can have an optional, and NOT multiple Sickness fields and Medicine fields. Please see the screenshot below.
With all due respect, I believe failure to communicate relevant behaviors of existent features should still be considered in-scope, especially if it may make or break whether the target audience believes they could use this product seamlessly over their current alternatives, particularly for the team's mentioned value proposition of monitoring their patients.
Thank you for reading!
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.High`] - [x] I disagree **Reason for disagreement:** As mentioned above, miscommunication regarding functionality that is highly relevant to the target audience and the product scope should constitute at least a `severity.Medium` (I take back the High rating as this doesn't really hinder or strongly prevent GPs from using the application.)
According to the DocTrack DG, each Appointment can have 0 to 1 sickness and 0 to 1 medicine (given to patient) in the AppointmentDescriptor.
Expected: Sometimes patients obtain multiple diagnoses in a single appointment, possibly due to health complications and pre-existing conditions.
Even more likely, for small conditions such as common cold (respiratory infections), because the symptoms are so diverse, patients receive multiple different medicines to treat these different symptoms.
Particularly about medicines, GPs need to know which medicines patients are currently taking to make sure on a follow-up prescription, they do not prescribe something that could cause major side-effects or complications with other medicine.
Actual: Only allowing 0 to 1 sickness and 0 to 1 medicine per appointment could be very unrealistic for the problem at hand, preventing doctors from effectively monitoring and retrieving patient health records with DocTrack. Thus, I am marking this as a
severity.Highand atype.FeatureFlawbug.