It is possible for two emergency contacts to have the same phone number

[notnotmax]

Description

Since two patients cannot have the same phone number, it is implied that emergency contacts also cannot have the same phone number (otherwise they would be the same person).

However, it is possible for two emergency contacts to share a phone number.

Steps to Reproduce

Add a patient with an emergency contact who has phone number 123 by the add command. Then use addec to add an emergency contact to the same patient, and give the emergency contact the same phone number 123.

Expected

The command should not be allowed.

Actual

The command executes successfully.

[nus-pe-bot]

Team's Response

This is not a functionality bug. The app functions as intended - an emergency contact is considered as a duplicate and is hence an invalid input to the addec command if it has the same fields as all fields of another emergency contact (i.e. name, phone number and relationship) of the same patient. This is stated clearly under the valid inputs section.

Section on valid inputs:

We understand that we overlooked revising the addec section. resulting in conflicting information given regarding emergency contact duplicates, making this a documentation error.

Section on addec:

However, since the current implementation is a relaxation of the restriction that we missed out on removing, this is "unlikely to affect normal operations of the product". Regardless, users may add emergency contacts with the same phone number (provided the other fields are different). As such, users that mistakenly adhere to the restricted behaviour that we missed out on removing would only miss out on knowing that they are able to add more emergency contacts with the same phone number. No critical contact information for use in an emergency is lost since the phone numbers would be the same anyways. They could also work around this by simply adding a dummy contact number (e.g. 000), making this only a "minor inconvenience", especially since two people sharing the same phone number would only appear in "rare situations", hence having low severity.

Nevertheless, this is also not a feature flaw but a deliberate design decision to allow for flexibility.

Furthermore, the primary purpose of the app is to manage patient information, not to centralize and manage shared contact details like those of emergency contact. The inability to warn against duplicates or propagate updates for shared emergency contacts does not impair the app's ability to manage patient records or fulfill its main function.

The simplest design, which is the app's current design, would be to treat each patient record as self-contained, with emergency contacts details directly associated with individual patients. As such, this makes duplicate detection across patients difficult unless we have emergency contacts as a separate entity. However, having emergency contacts as a separate entity and adding the functionality to link emergency contacts and patients instead adds significant additional complexity and requires significant effort given that it would likely introduce additional dependencies and potential synchronization issues, hence would be an extension for future versions so we are classifying it as not in scope.

Moreover, introducing a warning for shared numbers could instead be an inconvenience, unnecessarily alarming users when no actual conflict exists, creating noise rather than providing actionable feedback. Suggesting changes or introducing a tag to indicate shared contacts might complicate the interface and confuse users, particularly in cases where the shared number is intentional and valid, which are relatively common as elaborated below. Given that there is no simple solution, we are classifying this as not in scope.

In real-life situations, it is not uncommon for multiple emergency contacts to share the same phone number, particularly in close family settings. For example:

• A husband and wife might both use the same landline or mobile number and also potentially both be emergency contact to the same patient.
• An elderly couple (husband and wife) may list their child as their emergency contact, sharing the same number across multiple records.

Restricting phone numbers to be unique across all emergency contacts would create unnecessary barriers for users managing such scenarios.

The app is designed to prioritise user flexibility and accommodate realistic use cases. Allowing shared phone numbers ensures that users are not restricted from adding valid emergency contacts simply because they happen to share a number. Forcing users to create artificial distinctions (e.g., adding a secondary or invalid number to bypass restrictions) would instead lead to frustration and degrade the user experience.

By keeping emergency contacts flexible, the app can better support all these edge cases, such as contacts who share a number but differ in roles or relationships (e.g. a single caregiver for multiple patients with unique relationships to each).

Items for the Tester to Verify

:question: Issue response

Team chose [response.NotInScope]

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :question: Issue type Team chose [`type.DocumentationBug`] Originally [`type.FunctionalityBug`] - [ ] I disagree **Reason for disagreement:** [replace this with your explanation]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** I understand your argument, and agree with the change to a documentation bug. However, I believe the correct severity to be medium. Here is a screenshot of the PE Readiness quiz on Canvas, which gives an example of a medium severity bug.  The quiz states that in the worst case, the user might never be able to list items in descending order but can still order items in ascending order. The user can continue to use the application. My point is this: In the sample bug, the user might never be able to perform some action, but can still perform some closely related alternative to help them get around the issue. Furthermore, the root cause of the bug is a mistake in the documentation. The quiz lists this as **medium**. This implies that a bug that conforms to a similar situation would fall under **medium** severity. In the (your) app, the user might never be able to add emergency contacts with duplicate phone numbers (not because it has not been implemented, but rather because the documentation is misleading). Even so, the user is able to perform a workaround such as by your suggestion, adding a dummy phone number. The root cause here is indisputably a misleading part of the documentation, as clarified in your own argument. Thus, this bug is of similar nature to the sample provided in the Canvas quiz and should accordingly be labeled medium.

---