search

woke02 / pe

0 stars 0 forks source link

Editing doctor phone or email does not reflect in the other patients (Edit Command) #7

Open woke02 opened 1 week ago

woke02 commented 1 week ago

When I add two patients with the same doctor (same name, phone number, email address), and when i edit the details of that doctor in the first patient (eg editing doctor phone number), the change is not reflected in the other patient's doctor. This is a feature flaw, as realistically in the real life, doctors will the same name, email and phone number will refer to the same doctor, and one doctor will be taking care of many patients instead of one doctor to one patient. If a doctor takes care of multiple patients eg 100, and one day he changes his phone number, i will have to edit all 100 patients' doctor for that particular doctor.

soc-pe-bot commented 3 days ago

Team's Response

No details provided by team.

The 'Original' Bug

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

edit allow editting doctor to have duplicate phone number with other

image.png

Here Doctor Xvier charles and Doctor RonaldPeterParkerLee has same phone number, which is an obvious anomaly

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

Their Response to the 'Original' Bug

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

The primary purpose of the app is to manage patient information, not to centralize and manage shared contact details like those of doctors. The inability to propagate updates for shared doctors 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 doctor details directly associated with individual patients. Having doctors as a separate entity and adding the functionality to link doctors 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.

We acknowledge manually editing the doctor’s details for multiple patients under them would be tedious. However, we decided to leave the current design as such to keep it flexible and avoid unnecessary restrictions for the following reasons:

  1. Nursing homes often prioritize personalized care, and it is common for each patient to have their own attending doctor based on their specific medical needs, conditions, or preferences. Patients may have unique specialists for various conditions (e.g., cardiologists, neurologists) or general practitioners assigned based on availability and specific health plans, making overlap in doctors less likely. Given that only few patients would have overlapping doctors, this makes it merely a "minor inconvenience".

  2. While doctors often care for multiple patients, scenarios where the same doctor is assigned to numerous patients and changes contact details frequently are relatively rare. For example, phone number or email changes are uncommon and would only affect a small subset of users. Hence, this would be "unlikely to affect normal operations of the product", which is primarily to manage patient information and would only "appear in very rare situations" where a doctor changes contact details.

  3. Allowing independent doctor details for each patient gives users flexibility to input slight variations in doctor information (e.g., different phone numbers for different clinics/departments the doctor is attached to, same doctor using multiple emails specific to the clinics/departments), which might otherwise be restricted if records were linked.

As such, editing multiple records manually, while time-consuming, ensures the user has control over the accuracy of each patient's information. Automating changes might unintentionally affect unrelated records(e.g. similarly named but different doctors) if not implemented with proper safeguards. The current design avoids these pitfalls by isolating records, hence we are classifying this as low severity.

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: # Argument: This is Not a Duplicate Bug

Context of the Original Bug

Bug Description:

Context of the Marked Duplicate Bug

Bug Description:

Why This Bug is Not a Duplicate

  1. Distinct Problem Areas:

    • The original bug highlights the lack of synchronization between shared doctor records across multiple patients, emphasizing the need for linked doctor records.
    • The marked duplicate focuses on validation issues within the edit command, which allows duplicate phone numbers for different doctor records.
    • These are fundamentally different issues: one pertains to data propagation and linkage, while the other pertains to validation rules for editing.

  2. Different Use Cases:

    • The original bug is concerned with the workflow and usability for administrators managing shared doctor details across patients, which affects efficiency and accuracy in real-world scenarios.
    • The duplicate bug deals with an anomaly in the system’s ability to enforce uniqueness in doctor records, impacting data integrity.

  3. Non-Overlapping Root Causes:

    • The root cause of the original bug is the lack of a shared doctor entity in the data model, leading to independent doctor records for each patient.
    • The root cause of the duplicate bug is insufficient validation logic during edits, allowing duplicate entries for phone numbers.

  4. Severity and Scope Differences:

    • The original bug impacts scalability and user experience, particularly for elderly care homes where doctors are shared among multiple patients.
    • The duplicate bug addresses a validation edge case that does not have as significant an impact on the app’s usability.

  5. Mutually Exclusive Fixes:

    • Resolving the original bug would require the introduction of a shared doctor entity and synchronization mechanisms.
    • Resolving the duplicate bug would involve enhancing the validation logic for the edit command.
    • Fixing one does not automatically resolve the other, proving they are not inherently connected.

Conclusion

Given these differences, the two bugs cannot be classified as duplicates. The original bug addresses a critical feature flaw related to data management and usability in the app, while the duplicate bug pertains to validation inconsistencies in the editing process. These issues must be treated separately to ensure the app functions effectively and aligns with its intended purpose of supporting healthcare administrators in elderly care homes.

## :question: Issue response Team chose [`response.NotInScope`] - [x] I disagree **Reason for disagreement:** # Why This Bug is Not NotInScope ## Definition of NotInScope (Quoted from Textbook) Feature flaws can be claimed as **NotInScope**, if they qualify as per rules explained above, **except for these cases**: 1. **If fixing the feature flaw is essential for the app to be reasonably useful.** 2. **If the feature is implemented to work in a certain way but it could have been implemented to work in a better way (from the end-user's point of view) without much additional effort.** --- ## Why Fixing This Flaw is Essential for the App to Be Reasonably Useful ### 1. Contradiction with the App's Purpose The **User Guide** explicitly states the app is designed to: > "Consolidate crucial contact information into a single, accessible database, allowing administrative staff to manage patient and doctor contacts efficiently under high-pressure conditions." This feature flaw directly contradicts this stated goal: - **Efficient Management is Undermined**: The inability to propagate updates for shared doctors’ details across patients adds a tedious, error-prone task to the workflow, making the app inefficient and unsuitable for high-pressure scenarios. - **Single, Accessible Database is Incomplete**: Treating doctors' details as patient-specific duplicates rather than a shared entity fragments the data, contradicting the goal of providing a single, unified database. --- ### 2. Real-World Relevance of Shared Doctors #### The Team's Claim: "Overlap in doctors is rare." This assumption does not align with real-world scenarios in elderly care homes: - **Doctors Regularly Oversee Multiple Patients**: Due to resource constraints and the need for specialized care, it is common for doctors to manage multiple patients simultaneously. For example: - A general practitioner may oversee dozens of patients in the same care home. - Specialists like cardiologists and neurologists often consult for multiple patients with similar conditions. - **Consistency in Contact Information is Crucial**: When a doctor oversees multiple patients, any change in contact information must be updated across all relevant records. Failure to do so risks: - **Misinformation during emergencies**: Outdated contact information can lead to delays in critical situations. - **Operational inefficiencies**: Staff must manually verify and update every instance of the doctor’s contact details. #### The Team's Claim: "Contact changes are rare and affect few users." While updates may not occur daily, they are inevitable over time: - **The Impact of Even One Change is High**: A doctor who manages 30 patients represents 30 manual updates when their contact details change. In practice, this is a significant administrative burden. - **Scalability Issue**: As the patient base grows, the problem compounds, making the app increasingly cumbersome to use. --- ### 3. The App Fails in High-Pressure Scenarios The inability to handle shared doctor details effectively makes the app unsuitable for high-pressure scenarios: - **Delays in Critical Situations**: During emergencies, administrative staff must ensure doctor contact details are accurate and accessible immediately. Having to rely on outdated or inconsistent data due to manual updates increases the risk of delays and errors. - **Administrative Inefficiency**: Requiring manual updates for every patient is labor-intensive, reducing staff efficiency when time is of the essence. This directly undermines the app’s purpose, as highlighted in the **User Guide**. --- ### 4. Minimal Effort to Improve Implementation The flaw can be resolved with minor changes to the app’s architecture: - **Centralized Doctor Management**: The app could introduce a centralized list for doctors. Updates to a doctor’s details in this list would automatically propagate to all associated patients. - **Incremental Changes, Not Overhaul**: This adjustment leverages existing patterns in the codebase, such as the `UniquePersonList`. Implementing a similar `UniqueDoctorList` would provide an efficient solution without introducing significant complexity. The effort required is minimal compared to the substantial improvement in usability and efficiency. --- ### 5. Troublesome Manual Updates Undermine Usability #### Example Scenario A doctor oversees 50 patients and changes their phone number: - **Current Behavior**: The user must manually update the doctor’s contact details in all 50 patient records. This is: - **Error-Prone**: Missing even one record can lead to outdated information. - **Time-Consuming**: Each update takes time, reducing staff productivity. - **Unmanageable at Scale**: As the number of patients grows, so does the administrative burden. - **Expected Behavior**: Updating the doctor’s contact information in a centralized location should automatically reflect in all associated records. This is consistent with the app’s stated purpose of consolidating contact information for efficient management. --- ## Why This Bug Does Not Qualify as NotInScope ### 1. Fixing the Flaw is Essential for the App to Be Reasonably Useful The app claims to "manage patient and doctor contacts efficiently under high-pressure conditions." This flaw creates inefficiencies and risks that are fundamentally at odds with the app’s purpose. Without addressing this issue, the app cannot fulfill its intended role. ### 2. Minimal Effort Required to Improve the Implementation Addressing this flaw requires a straightforward enhancement—introducing centralized management for shared doctor details. This approach does not necessitate a complete redesign but significantly improves usability. ### 3. The Team’s Arguments Are Flawed - **Shared Doctors Are Common**: The assumption that overlap is rare is unrealistic in the context of elderly care homes. - **Impact of Updates is High**: While updates may not happen daily, when they do, the consequences of inefficient handling are severe. - **Flexibility Argument is Weak**: While slight variations in doctor details might occasionally be required, these edge cases do not justify sacrificing core functionality for the majority of users. --- ## Conclusion This bug does not qualify as NotInScope for the following reasons: 1. Fixing this flaw is essential for the app to be reasonably useful, as it directly impacts the efficiency and reliability of managing doctor contact information. 2. A better implementation requires minimal effort and would align with the app’s stated purpose. 3. The current behavior contradicts the User Guide's promise of efficient contact management, particularly under high-pressure conditions. This flaw must be addressed to ensure the app meets its stated objectives and provides value to its target users in elderly care homes.
## :question: Issue severity Team chose [`severity.Low`] Originally [`severity.Medium`] - [x] I disagree **Reason for disagreement:** # Why This Bug is Severity.Medium, Not Low ## Definitions of Bug Severity (Quoted from Guidelines) 1. **severity.Low**: A flaw that is unlikely to affect normal operations of the product. Appears only in very rare situations and causes a minor inconvenience only. 2. **severity.Medium**: A flaw that causes occasional inconvenience to some users, but they can continue to use the product. --- ## Why This Bug is Not Low ### 1. **This is Not a Rare Situation** The claim that this issue "appears only in very rare situations" is an **understatement of the reality in healthcare management**: - **Shared Doctors Are Commonplace**: In elderly care homes, it is routine for doctors to oversee multiple patients. Updating doctor details is a foreseeable and recurrent task, not a rare occurrence. - **High-Volume Scenarios**: If a doctor oversees 50 patients and their phone number changes, the current design would require the staff to manually update 50 separate patient records. This is not just inconvenient but **operationally infeasible** in a high-pressure environment. --- ### 2. **This is Not a Minor Inconvenience** The problem is not a mere annoyance; it directly impacts the operational efficiency and reliability of the product: - **Operational Inefficiency**: Manually updating dozens or even hundreds of patient records to reflect a single change in doctor information is a massive **waste of time and resources**. - **Error-Prone Process**: Manual edits increase the risk of errors, such as inconsistent or outdated records. These errors can lead to delays in contacting doctors during emergencies, directly undermining patient care. - **Critical Hindrance**: This flaw hinders the ability of staff to respond quickly, which is critical in high-pressure scenarios, such as medical emergencies. This is far from a "minor inconvenience." --- ### 3. **Real-World Impact on Target Users** The app’s **target users**—administrators in elderly care homes—operate under high-stakes conditions where every second counts: - **High-Pressure Scenarios**: In emergencies, having to verify or update multiple records due to this flaw can cause **life-threatening delays**. The inability to ensure up-to-date and consistent doctor contact information is a serious flaw. - **Core Task Undermined**: The app is intended to streamline the management of patient and doctor information. However, this flaw forces users to revert to **manual, inefficient processes**, undermining the app’s very purpose. From the app's **User Guide**: > *It consolidates crucial contact information into a single, accessible database, allowing administrative staff to manage patient and doctor contacts efficiently under high-pressure conditions.* This bug directly contradicts this promise. Far from being efficient, it imposes an **unsustainable administrative burden** on staff. --- ### 4. **Far-Reaching Consequences** The severity of this issue is compounded by its **real-world implications**: - **Delays in Urgent Situations**: A delay in contacting a doctor due to inconsistent or outdated information can have **life-altering consequences** for patients. - **Loss of Trust**: Users will lose trust in the product if it fails to deliver on its promise of efficient and centralized management. --- ## Why This Bug is Medium Severity ### 1. **Predictable, Recurring Inconvenience** This issue causes **frequent and predictable disruptions** in real-world use. Shared doctors are common in healthcare settings, and updating their details manually is an **inevitable burden**. ### 2. **Significant Operational Impact** While users can technically continue to use the product, the flaw imposes a **crippling inefficiency**: - The time and effort required to manually update doctor records across multiple patients is **unacceptable** in a professional healthcare environment. - The risk of errors in such a manual process introduces **serious vulnerabilities** that can compromise patient care. ### 3. **Contradicts the App’s Core Purpose** The app is marketed as a tool to manage patient and doctor contacts **efficiently under high-pressure conditions**. This bug directly undermines that claim, rendering the product far less reliable and usable than advertised. --- ## Conclusion This bug is **not Low Severity** because: - It occurs frequently in real-world scenarios involving shared doctors. - It imposes a **substantial operational burden** on users, making efficient use of the app nearly impossible in such cases. - It directly contradicts the app’s promise of efficient and centralized management. This flaw aligns with **severity.Medium**, as it causes **serious inconvenience** to users and compromises the app’s ability to fulfill its core purpose effectively.