Duplicate check for patients could be improved to check beyond just matching NRICs

[prave1n]

Steps to reproduce:

• add n/John Doe i/S9999999A d/2000-01-01 g/M p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25
• add n/John Doe i/S9999999B d/2000-01-01 g/M p/98765432 e/johnd@example.com a/311, Clementi Ave 2, #02-25

Expected Output:
Although it has been mentioned in the UG that duplicates will only be flagged if an existing patient has the same NRIC, it is unreasonable to expect two patients with exact matching details except for having different NRICs. Hence, I would expect the app to throw an error alerting the user that they may be adding a duplicate patient

Actual Output:
Both commands were executed and two patients with almost identical details were added to the address book

Potentially problematic behaviour: There is a good chance that the user keying in the details had just made an error when entering the NRIC. This could lead to the user accidentally adding duplicate patients without being aware. It would be beneficial to add further checks to see if all other key information like their phone number, email address and residential addresses match as well to warn the user.

[nus-pe-script]

Team's Response

2372 and #2666 address the same core problem: the lack of comprehensive duplicate detection for patient records.

• 2666 highlights that the system only flags duplicates based on NRIC, even when all other details (name, phone number, email, address) are identical.

• 2372 points out that duplicate phone numbers or emails are allowed without a warning, which can lead to unintended duplicate patient entries.

Both issues indicate that the application needs a more robust duplicate detection mechanism that goes beyond just checking NRICs, incorporating other key attributes to prevent unintentional duplicate records. Thus, #2666 is effectively a duplicate of #2372, as they both propose a similar enhancement to improve data integrity and prevent user errors.

The 'Original' Bug

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

Duplication handling does not consider email and phone number.

Description Duplication of email and phone number is allowed.

Steps to reproduce error:

1. Open the .jar application
2. Type edit s1234567a p/ 99272758 (this is a duplicate phone number of the sample contact Bernice Yu)

Expected Output A warning/error message that says you cannot edit the person to have duplicate email/phone number.

Actual Output The command goes through.

Reason for severity Medium. It is uncommon for 2 patients to have the same phone number. Thus, when such cases happen, it is likely due to a typo. Hence, the application should warn the user that there is a duplicate phone number :,)

---

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

Their Response to the 'Original' Bug

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

We appreciate the concern about potential typographical errors leading to unintended duplication of contact information. However, we believe that allowing duplicate phone numbers or emails is beneficial for the following reasons:

• Phone numbers and emails are sometimes shared between multiple individuals. For example:

  • Parent who is managing medical appointments for their children
  • Guardians / LPA donees caring for someone not able to manage their own contacts
  • Aging elders or minors under care of guardians who do not have their own point of contact

• Avoiding Overzealous Input Validation: Restricting contact information to unique values only could lead to frustrations, who may intentionally use duplicate values across different patients for valid reasons.

• User Responsibility: We believe that users should review their inputs for accuracy, especially in cases where contact information is shared. Typographical errors can be mitigated by user vigilance.

Future Improvement

We will make this clearer in the User Guide about why this is an intended feature in the future. This will help users understand the rationale behind allowing duplicate contact details and avoid potential confusion :'(

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`] - [x] I disagree **Reason for disagreement:** I did not wish to contest if this is a duplicate of the other bug report but I feel like your response largely addresses the concerns raised in the other bug report and might have overlooked the points raised in this bug report. To reiterate, I had reported this as a bug because: - It is highly improbable for two distinct patients to share identical information across all fields except for their NRIC - There is a significant risk that users might accidentally enter a slightly incorrect NRIC, resulting in duplicate entries for the same patient. - The application should have a more robust duplicate-checking mechanism that includes additional fields to detect potential duplicates and alert users, preventing errors and improving data integrity. I also want to differentiate the points raised in this bug report form the other by emphasising that my concern was not with the fact that the application allows duplicate phone numbers and email addresses but is rather with the lack of robustness in detecting duplicates. I understand that you believe that allowing duplicate phone numbers and email addresses have their own benefits. While that may validate allowing duplicates for certain contact details, it does not address the issue of possibly allowing duplicate entries for the same patients to be stored in the address book. While you may argue that these can be taken into consideration for future versions, I believe that it is non-negotiable to ensure that duplicate entries for the same patient cannot be created in an application used by doctors to manage patients for the following reasons: - Duplicate records can lead to fragmented and inconsistent data, where vital information (e.g. allergies or medical conditions) is split between two entries. This increases the risk of medical errors, such as prescribing incorrect medication or overlooking critical health conditions. - Priority statuses associated with one patient record may not reflect in the duplicate entry, leading to delays in care or misallocation of resources. For these above reasons, I do not agree that this is not in scope.

---

## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** Duplicate entries disrupt the normal operation of the application by creating confusion and inefficiency. Doctors may inadvertently reference or update the wrong record, leading to operational delays and errors. Resolving duplicates requires manual intervention by the user (e.g., cross-checking and manually deleting one of the entries), which is an occasional inconvenience to the workflow. The application's core purpose is to provide doctors with a reliable system for managing patients. Duplicate entries compromise this reliability by splitting essential medical information across multiple records. The occurrence of duplicates directly interferes with its intended purpose, elevating the impact beyond a minor inconvenience.

---