m1oojv / pe

0 stars 0 forks source link

Unrealistic very restrictive phone number restrictions #12

Open m1oojv opened 8 months ago

m1oojv commented 8 months ago

Screenshot 2023-11-17 at 4.42.38 PM.png

Since your target group is not specified to be in singapore (only says Head nurses) , and that patients can be from overseas as well, your application should be able to account for country codes in the phone number like US phone numbers or +65 country codes

nus-pe-bot commented 7 months ago

Team's Response

Hi tester, thank you for the suggestion! We actually think that adding this would be a great idea, as it would allow a head nurse to easily deal with foreign patients. However, we do think that foreign patients with foreign phone numbers are much less common than local patients in a hospital, and so the need for users to input complex numbers and add country codes is of lower priority than the other features that have been added which pertain directly to the application's functionality in a hospital. Hence, we are considering this to be not in scope.

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: As argued from my earlier bugs, the target group specified in both UG and DG is on Head nurses in hospitals and did not specify the context of which country or size of hospital. It is fair to assume that your application should be able to serve the purpose of all hospitals of any sizes (especially since your application is able to organize nurses and doctors into specializations anyways so it seems that the dev team intended the application to be used on quite a large scale). In such diverse environments (especially with tourist patients), encountering phone numbers with country code and area code (eg (555) 555-1234) is common and should be expected. The inability to accurately record these phone numbers due to restrictive input limitations is not a rare occurrence but a frequent challenge that directly impacts the core functionality of the application. By not accommodating these variations, MediSync may fail to meet the basic needs of accurate and inclusive record-keeping in many healthcare settings.

Other than that, hospitals also usually have to note down multiple contacts of patients like the contact of the patient's next of kin (eg. +65 1234 1234 (self) , +65 9876 9876 (mother) ) . this is not supported by Medisync and thus is an overzealous input validation. Therefore, it is justified as a feature flaw of the application. The module website also states that overzealous input validation is a noteworthy feature flaw to be reported. Screenshot 2023-11-21 at 4.52.38 PM.png


## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** As argued from my previous text related to this bug, the target group is on Head nurses in hospitals and did not specify the context of which country or size of hospital. It is fair to assume that your application should be able to serve the purpose of all hospitals of any sizes (especially since your application is able to organize nurses and doctors into specializations anyways so it seems that the dev team intended the application to be used on quite a large scale). In such diverse environments (especially with tourist patients), encountering phone numbers with country code and area code (eg (555) 555-1234) is common and should be expected. The inability to accurately record these phone numbers due to restrictive input limitations is not a rare occurrence but a frequent challenge that directly impacts the core functionality of the application. By not accommodating these variations, MediSync may fail to meet the basic needs of accurate and inclusive record-keeping in many healthcare settings. Other than that, hospitals also usually have to note down multiple contacts of patients like the contact of the patient's next of kin (eg. +65 1234 1234 (self) , +65 9876 9876 (mother) ) . this is not supported by Medisync and thus is an overzealous input validation as stated in the module website. The module website's mention of overzealous input validation as a noteworthy feature flaw underscores the seriousness of this issue. ![Screenshot 2023-11-21 at 4.52.38 PM.png](https://raw.githubusercontent.com/m1oojv/pe/main/files/536c37ac-d4a4-45dd-b40e-f88e003feb7a.png) Since the MediSync application is intended for use by head nurses in hospitals, which inherently implies a diverse and international environment, the ability to accommodate global phone number formats is not just a feature but a necessity. This is particularly true in cosmopolitan areas or tourist destinations where foreign patients are not uncommon. The team's response, categorizing this as a low-priority issue and not in scope, fails to recognize the practical realities of modern healthcare environments. Moreover, the need to record multiple contacts for a patient, including those of next of kin, further exemplifies the importance of flexible phone number input. In emergency situations, or when dealing with patient care and communication, having access to accurately record patients contact numbers can be critical. The lack of this functionality in MediSync is not a minor inconvenience; it represents a significant gap in the application's utility for effective patient management. Considering these aspects, the inability to input phone numbers with country codes and area codes or the inability to record multiple phone numbers and label them is a flaw that affects the application's core functionality in a global healthcare context. It should not be classified as a low-severity issue. Rather, given its potential to impact patient care and hospital operations significantly, it is more appropriate to classify this as a medium or even high-severity feature flaw. The application's current limitations in handling phone numbers restrict its usefulness and adaptability in diverse medical settings, which is a major concern for a tool designed for head nurses in hospitals. Therefore, I strongly urge a reevaluation of the severity of this issue, reflecting its substantial impact on the application's functionality and the practical needs of its users in a global healthcare environment.