`add` command allows duplicate emergency contact phone number

[mrnobody0505]

I can anomaly add 2 entire different persons, with 2 entire different emergency contact persons but has same phone number.

I expect atleast a warning that this emergency contact has been used, or just a suggestion (could work or not, just suggestion) the dev team can introduce a new tag indicate the allowance of sharing emergency contact.

In this example Beatrice Bean and Pepper Pott has the same phone number

[nus-pe-bot]

Team's Response

No details provided by team.

The 'Original' Bug

[The team marked this bug as a duplicate of the following bug]

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

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.

---

_{[original: nus-cs2103-AY2425S1/pe-interim#3482] [original labels: severity.Medium type.FunctionalityBug]}

Their Response to the 'Original' Bug

[This is the team's response to the above 'original' bug]

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 duplicate status

Team chose to mark this issue as a duplicate of another issue (as explained in the Team's response above)

• [ ] I disagree

Reason for disagreement: [replace this with your explanation]

---

## :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.FeatureFlaw`] - [x] I disagree **Reason for disagreement:** [replace this with your reason]

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** [replace this with your reason]

---