jwdavis0200 / pe

0 stars 0 forks source link

Person with same name not allowed in HealthContact #1

Open jwdavis0200 opened 1 year ago

jwdavis0200 commented 1 year ago

Context: HealthContact is a software for the receptionist of a family clinic who arranges telemedicineservices between doctors and patients. It helps to keep track of patient data, patientappointments and patient bills for the family clinic.

Problem: It is possible that a family clinic has multiple patients from different families that have the same name. Users will encounter problem when entering patients with the same name into the book which may cause inconvenience.

To reproduce: 1) ap n/John p/91234565 e/john@gmail.com a/blk 123 as first command to be entered. 2) ap n/John p/94567898 e/johndave@gmail.com a/blk 321 as second command entered.

Expected: Application allows for person with same name , since other fields are different, highly possible for a real use case by the receptionist. Actual: Applcation does not allow with a warning of person already in book.

Screenshot:

image.png

nus-se-script commented 1 year ago

Team's Response

Same as issue 5514.

The 'Original' Bug

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

Duplicate detection for people with same name

It is possible for two different people to have the same name but different personal details. However, the uniqueness of a patient is verified by the name here.

For instance, ap n/muhammad bin p/91850603 a/113 singapore street e/muhammede@gmail.com and ap n/muhammad bin p/91850600 a/114 singapore street e/muhammed@gmail.com are considered the same person, despite them having different personal particulars such as phone number, email and address.

It should be accepted to add patients with same names but different contact details.

This is marked as medium since certain names can be quite common like John Tan and Jun Jie.

Screenshot 2022-11-11 at 4.27.15 PM.png


[original: nus-cs2103-AY2223S1/pe-interim#5377] [original labels: type.FeatureFlaw severity.Medium]

Their Response to the 'Original' Bug

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

image.png

Indicated in UG that new patient must have different name from existing patient and name is case insensitive.

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)

Reason for disagreement: [replace this with your explanation]


:question: Issue response

Team chose [response.NotInScope]

Reason for disagreement: As stated in the module website,

image.png

"Features that work as specified by the UG but should have been designed to work differently (from the end-user's point of view) fall in this category too."

The nature of your target audience would mean that this feature is essential as names are often not unique. The details of your patience should be preserved since this is sort of a medical record for your receptionist. Hence, the product may be better off implementing it in such a way it checks duplicates by email (which is unique to each Person ie. at worst case many email to one person mapping, since email is generally mapped to one person, or via phone number for the same reason).

This would have been much more useful to a receptionist who has a reasonable chance of having to cater to two patients of the same name and I would imagine the effort that is needed to detect by phone number/email instead of name would not be excessive to make your product much more optimised for your target audience (convenience).

I also agree with the other tester's comments for the above reasons.