Reanalyze
Version: v3.0.0 Status: Normative (text), Illustrative (diagrams only) Scope: Reanalysis of PCR run results including Westgard control management Domain: REANALYZE
Statement
The system shall support reanalyzing PCR run results after initial processing, enabling users to define final well outcomes with complete data visibility while maintaining quality control integrity.
The Reanalyze capability reframes result management from "fixing an error on the well" to "defining the well outcome." This approach allows resolution of rule violations without triggering cascading errors, manages Westgard QC control exclusions, handles date-based error propagation, and tracks resolution proposals across controls and patient wells.
Behavior Overview (Illustrative)
This diagram illustrates the high-level behavior. It does not specify UI layout, styling, or interaction details.
Definitions
| Term | Definition |
|---|---|
| SKIP Resolution Code | A resolution code that instructs the system to bypass all further rule processing for a well |
| LIMS Export | The act of exporting well outcome data to the Laboratory Information Management System |
| Westgard Rules | Statistical quality control rules used to detect systematic and random errors in control measurements |
| Westgard In Error | A status indicating a control has failed one or more Westgard rules |
| LJ Plot | Levey-Jennings plot displaying control values over time with statistical limits |
| Resolution Proposal | A user-defined action to resolve an error condition on a well |
| Extraction Date | The date when the sample was extracted, used for Westgard series ordering |
Functional Requirements
Rule Processing Control (REQ-REANALYZE-001)
FR-REANALYZE-001 Bypass Rule Processing with SKIP Resolution Code
The system shall bypass all subsequent rule processing for a patient well when the user sets a LIMS Export with a SKIP resolution code.
Acceptance Criteria:
Rule Bypass Behavior:
- Setting a LIMS Export with SKIP resolution code shall prevent further rules from executing on that well
- SKIP behavior shall apply to all resolution types: RPT, RXT, TNP, Do Not Report
- SKIP behavior shall apply to patient wells with LIMS Export values of: DETECTED, NOT DETECTED, INCONCLUSIVE, RPT, RXT, or TNP
Export Modification:
- Users shall be able to modify a LIMS Export for a patient well after initial export
- The system shall require confirmation when a user exports a well more than once
Configuration:
- The system shall require a 'skip all' concept configured in the config sheet 'resolution_codes' column
Trace: Source: 3.0.0-Reanalyze (Row 1, 2, 5) | Jira: BT-220 | Tests: REQ-REANALYZE-001 Tests
Export Status Display (REQ-REANALYZE-002)
FR-REANALYZE-002 Display Outcome Messages with Export Status
The system shall display an outcome message for each well indicating the current export status, updating the message when the well outcome changes.
Acceptance Criteria:
- After export, each well shall display an outcome message with format "Exported: {LIMS Export Status Message}"
- When a user modifies a well outcome post-export, the outcome message shall update to reflect the new outcome
- Upon subsequent export, the outcome message shall update to reflect the new exported status
Trace: Source: 3.0.0-Reanalyze (Row 3, 4) | Jira: BT-218 | Tests: REQ-REANALYZE-002 Tests
Westgard Control Management (REQ-REANALYZE-003, REQ-REANALYZE-004, REQ-REANALYZE-005)
FR-REANALYZE-003 Exclude Resolved Controls from Westgard Calculations
The system shall exclude resolved controls from all Westgard rule calculations and prompt users to reanalyze affected runs.
Acceptance Criteria:
Exclusion Behavior:
- A resolved control shall be excluded from all Westgard rule calculations
- Resolving a control shall remove the Westgard In Error status from that control
- A subsequent control failing at a lower sigma level shall not trigger compounding rules using the resolved control
Reanalysis Prompt:
- The system shall prompt the user to reanalyze any runs with well errors triggered by the now-resolved Westgard In Error state
- The reanalysis prompt shall be presented for each resolution option: exclude well, reamplify positive samples, re-extract positive samples
Trace: Source: 3.0.0-Reanalyze (Row 6, 7) | Jira: BT-219, BT-201 | Tests: REQ-REANALYZE-003 Tests
FR-REANALYZE-004 Apply Date-Based Westgard Error Propagation
The system shall apply Westgard In Error statuses only to controls with extraction dates equal to or later than the control that triggered the error.
Acceptance Criteria:
Date-Based Logic:
- Westgard In Error statuses shall not affect control uploads with an extraction date earlier than the triggering control
- For controls with identical date/time (same run, run creation date as extraction date), the second control processed shall check the first control as history
Same-Run Handling:
- When two controls in the same run are between 2 and 3 SD from mean, the system shall apply 1.2S warning to one and 2.2S warning to the other
Trace: Source: 3.0.0-Reanalyze (Row 8, 9) | Jira: BT-219 | Tests: REQ-REANALYZE-004 Tests
FR-REANALYZE-005 Display Control Status on LJ Plots
The system shall display visual indicators on LJ plots distinguishing between resolved controls, unresolved error controls, and normal controls.
Acceptance Criteria:
Visual Distinction:
- The system shall visually distinguish resolved controls from unresolved error controls and normal controls
- A legend describing control status indicators shall be available
Visibility Toggle:
- By default, resolved controls shall be hidden from the LJ plot
- Users shall be able to toggle visibility of resolved controls
Trace: Source: 3.0.0-Reanalyze (Row 10, 11, 12, 13, 14) | Jira: BT-219 | Tests: REQ-REANALYZE-005 Tests
Resolution Proposal Management (REQ-REANALYZE-006, REQ-REANALYZE-007)
FR-REANALYZE-006 Select Resolution Proposals
The system shall allow users to select and apply resolution proposals through the manage results interface.
Acceptance Criteria:
- Users shall be able to select a primary resolution option without selecting a secondary option
- Secondary options shall require the corresponding primary option to be selected first
- Selected proposals shall be applicable to the target well
Trace: Source: 3.0.0-Reanalyze (Row 15) | Jira: BT-678 | Tests: REQ-REANALYZE-006 Tests
FR-REANALYZE-007 Prevent Conflicting Resolution Proposals
The system shall prevent users from creating resolution proposals that would affect the same patient well from multiple controls.
Acceptance Criteria:
Conflict Detection:
- Users shall not be able to propose a resolution to a control that would affect a patient well with an existing pending resolution
- In two-step resolution workflows, conflict detection shall occur when a resolution is proposed but not yet confirmed
- In one-step resolution workflows, conflict detection shall occur prior to saving proposed changes
Error Handling:
- Conflicting resolution proposal: The system shall display an error indicating the patient well already has a pending resolution from another control
Trace: Source: 3.0.0-Reanalyze (Row 16) | Jira: [Missing - requires investigation] | Tests: REQ-REANALYZE-007 Tests
Westgard Series Management (REQ-REANALYZE-008)
FR-REANALYZE-008 Update Reanalysis Status for Westgard Series Changes
The system shall update the reanalysis status of affected runs when the Westgard series is modified by adding, removing, or reassigning runs.
Acceptance Criteria:
Series Modification:
- Adding a run into the middle of a Westgard series shall trigger "Reanalysis required (Westgard)" status on affected future runs
- Removing a run from the middle of a Westgard series shall trigger "Reanalysis required (Westgard)" status on affected future runs
Role Changes:
- Changing control role assignments shall trigger "Reanalysis required (Westgard)" status on runs affected by the role change
Trace: Source: 3.0.0-Re-analyzing Required Status for Future Runs When Westgard Series Changes (Row 1) | Jira: BT-4919 | Tests: REQ-REANALYZE-008 Tests
REQ-REANALYZE-008 covers Westgard series changes as a reanalysis trigger. For the dependency tracking sub-group (v3.0.1) covering archive, edit, and resolution triggers, see REQ-REANALYZE-009 through REQ-REANALYZE-013 below.
Dependency Tracking (REQ-REANALYZE-009, REQ-REANALYZE-010, REQ-REANALYZE-011, REQ-REANALYZE-012, REQ-REANALYZE-013)
REQ-REANALYZE-009 through REQ-REANALYZE-013 were added in v3.0.1. They form a coherent "dependency tracking" sub-group:
- Infrastructure: REQ-REANALYZE-009 (track dependencies), REQ-REANALYZE-011 (user confirmation modal)
- Triggers: REQ-REANALYZE-010 (archive), REQ-REANALYZE-012 (well edit), REQ-REANALYZE-013 (well resolution)
FR-REANALYZE-009 Track Archive Well Dependencies
The system shall track which wells from other runs were used during analysis of each well, storing these cross-run dependencies for archive impact assessment.
Acceptance Criteria:
Dependency Recording:
- During rule analysis, the system shall record the IDs of wells from other runs that contributed to the current well's outcome in the
archive_dependent_well_idsfield - Dependency tracking shall apply to all multi-run rules: WG7T, WG7T13S, WG22S, WG22S13S, WGInError, WREP, AdjZika, Picqual, CombinedOutcome, MissingMixes
Cache Behavior:
- The dependency cache shall build incrementally as runs are analyzed; an empty cache shall not alter system behavior
- Wells from the same run shall not be recorded as archive dependencies (only cross-run wells)
Trace: Source: archive-dependent-wells-caching.md (Sections 1-4) | Jira: TBD | Tests: REQ-REANALYZE-009 Tests
FR-REANALYZE-010 Flag Dependent Runs on Archive Status Change
The system shall automatically flag runs for reanalysis when their archive dependencies are affected by an archive or unarchive operation.
Acceptance Criteria:
Forward Dependency Flagging:
- When a run is archived, all future runs whose wells depend on the archived run's wells (via
archive_dependent_well_ids) shall have theirresolution_statusset to the archive reanalysis message
History Dependency Flagging:
- When a run is archived, all history runs whose wells appear in the archived run's wells'
archive_dependent_well_idsshall also be flagged
Guard Conditions:
- When no archive status change occurs in a tag operation, no dependency updates shall be performed
- Indirect (transitive) dependencies shall not be flagged; only direct dependencies are updated
Trace: Source: archive-dependent-wells-caching.md (Section 6: Archive Status Change Handling) | Jira: TBD | Tests: REQ-REANALYZE-010 Tests
FR-REANALYZE-011 Confirm Archive Dependency Reanalysis
The system shall present a confirmation dialog to the user when a run is flagged for reanalysis due to archive dependency changes, allowing the user to accept or defer reanalysis.
Acceptance Criteria:
Modal Presentation:
- When a user opens a run whose
resolution_statusindicates archive dependency reanalysis, a confirmation modal shall appear
Confirmation Behavior:
- If the user confirms, the run shall be reanalyzed and an audit message shall be recorded: "This run was re-analysed following changes to archived run dependencies."
- If the user declines, the run shall remain in its current state without reanalysis
UX Consistency:
- The confirmation dialog shall follow the same UX pattern as existing Westgard and Missing Mixes reanalysis prompts
Trace: Source: archive-dependent-wells-caching.md (Section 10: Frontend User Confirmation) | Jira: TBD | Tests: REQ-REANALYZE-011 Tests
FR-REANALYZE-012 Flag Dependent Runs When Wells Are Edited
The system shall automatically flag runs for reanalysis when wells they depend on have their role_alias property modified, using the archive dependency tracking infrastructure to identify affected runs.
Acceptance Criteria:
Trigger Conditions:
- When a well's
role_aliasis changed via the edit wells workflow, the system shall flag dependent runs for reanalysis - Changes to other well properties (accession, extraction_date, etc.) shall NOT trigger reanalysis of dependent runs
- When
role_aliaschanges along with other fields, reanalysis shall still be triggered (presence of role_alias change is sufficient)
Dependency Resolution:
- Future runs whose wells list the edited well in their
archive_dependent_well_idsshall be flagged with the edited-wells resolution status message - History runs whose wells appear in the edited well's
archive_dependent_well_idsshall also be flagged - The resolution status message shall be: "Results for wells in this run may be affected by recently edited wells. Reanalysis required."
User Confirmation:
- When a user opens a run flagged for edited-wells reanalysis, a confirmation modal shall appear following the same pattern as archive dependency reanalysis (REQ-REANALYZE-011)
- If confirmed, the audit trail shall record: "This run was re-analysed following changes to edited wells."
Trace: Source: edited-resolved-wells-reanalysis.md (Edited Wells Flow, Sections 2-4) | Jira: TBD | Tests: tests/Feature/Runs/DependentRunsReanalysisTest.php, REQ-REANALYZE-012 Tests
FR-REANALYZE-013 Flag Dependent Runs When Wells Are Resolved
The system shall automatically flag runs for reanalysis when wells they depend on have resolution codes applied, using the archive dependency tracking infrastructure to identify affected runs.
Acceptance Criteria:
Trigger Conditions:
- When resolution codes are applied to wells via the manage results workflow, the system shall flag dependent runs for reanalysis
- Flagging shall occur after resolution codes are persisted and well events are stored, before transaction commit
Dependency Resolution:
- Future runs whose wells list the resolved well in their
archive_dependent_well_idsshall be flagged with the resolved-wells resolution status message - History runs whose wells appear in the resolved well's
archive_dependent_well_idsshall also be flagged - The resolution status message shall be: "Results for wells in this run may be affected by recently resolved wells. Reanalysis required."
User Confirmation:
- When a user opens a run flagged for resolved-wells reanalysis, a confirmation modal shall appear following the same pattern as archive dependency reanalysis (REQ-REANALYZE-011)
- If confirmed, the audit trail shall record: "This run was re-analysed following changes to resolved wells."
Trace: Source: edited-resolved-wells-reanalysis.md (Resolved Wells Flow, Sections 3-4) | Jira: TBD | Tests: tests/Feature/Runs/DependentRunsReanalysisTest.php, REQ-REANALYZE-013 Tests
Configuration Options
| Option | Default | Description | Affects |
|---|---|---|---|
show_resolved_controls | false | Whether resolved controls are visible on LJ plots | REQ-REANALYZE-005 |
Assumptions
SME confirmed 2026-01-20.
- Users have appropriate role permissions to modify well outcomes and export results
- If no mixes are configured when a run is imported, all mixes are imported as "disabled" (unknown mix) and wells receive an unknown mix error; users can then configure mixes and reanalyze
- Westgard rules are configured for the applicable control types
- The system has access to historical control data for Westgard calculations
UI Notes (Illustrative)
FR-REANALYZE-002 UI Specifications
Outcome Message Display:
- Example workflow:
- Runfile imported - A1 shows "Not Detected"
- Export runfile - A1 shows "Exported: Not Detected"
- User changes to Re-extract - A1 shows "This well is marked for re-extract"
- Export again - A1 shows "Exported: Re-extracted"
FR-REANALYZE-005 UI Specifications
Control Status Indicators:
- Resolved controls: Green triangle with white outline
- Unresolved error controls: Red square with white outline
- Normal controls: Filled circles (current controls in runfile widget have border)
Legend Contents:
- Control - Standard control point
- Control in current run - Filled circle with border (only shows when LJ viewed in Runfile Widget)
- Resolved Error Control - Green triangle with white outline
- Unresolved Error Control - Red square with white outline
LJ Settings:
- Option text: "Show resolved controls"
- Default: Not selected
- Option type: Checkbox
- Location: Inside the Settings widget
Design Notes:
- LJ plot has background colors of yellow, green, red for sigma bands
- Control foreground color needs to be distinct for visibility
- White outline ensures visibility against colored backgrounds
- Legend design should be consistent with curve modal design
FR-REANALYZE-006 UI Specifications
Manage Results Widget:
- Radio buttons for selecting primary resolution proposals
- Dropdowns for selecting secondary options (only enabled when corresponding radio button is selected)
Implementation (Illustrative)
| Component | Type | Path | Requirements |
|---|---|---|---|
| Well | Model | code/app/Well.php | REQ-REANALYZE-001, REQ-REANALYZE-002, REQ-REANALYZE-006, REQ-REANALYZE-007 |
| ErrorCode | Model | code/app/ErrorCode.php | REQ-REANALYZE-003, REQ-REANALYZE-004, REQ-REANALYZE-005 |
| RunsController | Controller | code/app/Http/Controllers/RunsController.php | REQ-REANALYZE-008 |
| WellsController | Controller | code/app/Http/Controllers/WellsController.php | REQ-REANALYZE-001, REQ-REANALYZE-006 |
| ResolutionCodesController | Controller | code/app/Http/Controllers/ResolutionCodesController.php | REQ-REANALYZE-001 |
| RunAnalyseJob | Job | code/app/Jobs/RunAnalyseJob.php | REQ-REANALYZE-003, REQ-REANALYZE-008 |
| RunUpdateJob | Job | code/app/Jobs/RunUpdateJob.php | REQ-REANALYZE-008 |
| RunAnalyzeStarted | Event | code/app/Events/RunAnalyzeStarted.php | REQ-REANALYZE-008 |
| RunAnalyseProgressUpdated | Event | code/app/Events/RunAnalyseProgressUpdated.php | REQ-REANALYZE-008 |
| RunUpdated | Event | code/app/Events/RunUpdated.php | REQ-REANALYZE-008 |
| ArchiveDependentWellsRelation | Model | code/app/ArchiveDependentWellsRelation.php | REQ-REANALYZE-009 |
| ArchiveDependentRunsUpdater | Action | code/app/Actions/RunTags/ArchiveDependentRunsUpdater.php | REQ-REANALYZE-010 |
| StoreRunTagsAction | Action | code/app/Actions/RunTags/StoreRunTagsAction.php | REQ-REANALYZE-010 |
| UpdateArchiveDependentWells | Action | code/app/Actions/Runs/UpdateArchiveDependentWells.php | REQ-REANALYZE-009 |
| RequiredArchivedRunsReanalyze | Vue | code/resources/frontend/src/views/run/support/required-reanalyzes/support/RequiredArchivedRunsReanalyze.js | REQ-REANALYZE-011 |
| EditedResolvedWellsDependentRunsUpdater | Action | code/app/Actions/Runs/EditedResolvedWellsDependentRunsUpdater.php | REQ-REANALYZE-012, REQ-REANALYZE-013 |
| RequiredEditedWellsReanalyze | Vue | code/resources/frontend/src/views/run/support/required-reanalyzes/support/RequiredEditedWellsReanalyze.js | REQ-REANALYZE-012 |
| RequiredResolvedWellsReanalyze | Vue | code/resources/frontend/src/views/run/support/required-reanalyzes/support/RequiredResolvedWellsReanalyze.js | REQ-REANALYZE-013 |
Traceability Matrix
| Requirement | Title | Verification | Implementation | Test Cases | Status |
|---|---|---|---|---|---|
| REQ-REANALYZE-001 | Bypass Rule Processing with SKIP Resolution Code | Test | Well, WellsController, ResolutionCodesController | TC-REANALYZE-001 | Draft |
| REQ-REANALYZE-002 | Display Outcome Messages with Export Status | Test | Well | TC-REANALYZE-002 | Draft |
| REQ-REANALYZE-003 | Exclude Resolved Controls from Westgard Calculations | Test | ErrorCode, RunAnalyseJob | TC-REANALYZE-003 | Draft |
| REQ-REANALYZE-004 | Apply Date-Based Westgard Error Propagation | Test | ErrorCode | TC-REANALYZE-004 | Draft |
| REQ-REANALYZE-005 | Display Control Status on LJ Plots | Test | ErrorCode | TC-REANALYZE-005 | Draft |
| REQ-REANALYZE-006 | Select Resolution Proposals | Test | Well, WellsController | TC-REANALYZE-006 | Draft |
| REQ-REANALYZE-007 | Prevent Conflicting Resolution Proposals | Test | Well | TC-REANALYZE-007 | Draft |
| REQ-REANALYZE-008 | Update Reanalysis Status for Westgard Series Changes | Test | RunsController, RunAnalyseJob, RunUpdateJob | TC-REANALYZE-008 | Draft |
| REQ-REANALYZE-009 | Track Archive Well Dependencies | Test | Analyzer rules, ArchiveDependentWellsRelation | TC-REANALYZE-009 | Draft (v3.0.1) |
| REQ-REANALYZE-010 | Flag Dependent Runs on Archive Status Change | Test | ArchiveDependentRunsUpdater, StoreRunTagsAction | TC-REANALYZE-010 | Draft (v3.0.1) |
| REQ-REANALYZE-011 | Confirm Archive Dependency Reanalysis | Test | RequiredArchivedRunsReanalyze.js | TC-REANALYZE-011 | Draft (v3.0.1) |
| REQ-REANALYZE-012 | Flag Dependent Runs When Wells Are Edited | Test | EditedResolvedWellsDependentRunsUpdater | TC-REANALYZE-012 | Draft (v3.0.1) |
| REQ-REANALYZE-013 | Flag Dependent Runs When Wells Are Resolved | Test | EditedResolvedWellsDependentRunsUpdater | TC-REANALYZE-013 | Draft (v3.0.1) |
Notes
- The Reanalyze feature reframes "fixing an error on the well" to "defining the well outcome"
- This approach allows users to decide on final well outcome with all necessary data
- Avoids scenarios where resolving one error triggers another error on the same well
Out of Scope Items (Captured for Future Reference):
- Make the legend in the LJ plot visible upon rollover of an icon next to the settings icon
- Semi-transparent legend overlay
- Handling edge case: Control has a Ct discrep - how to know the Westgard status
Acceptance Tests
Test: REQ-REANALYZE-001
Test: Verify general export with SKIP works
Given: Import a runfile with multiple patient wells (mix of pos, neg wells, inhibition in one well)
When: Set LIMS Export = Re-extract for one patient well (no errors)
And: Set LIMS Export = Re-amplify for another patient well (no errors)
And: Set LIMS Export = TNP for another patient well (no errors)
And: Set LIMS Export = Exclude for another patient well (no errors)
And: Export run
Then: Export file contains correct values for each well
Test: Verify SKIP prevents further rules
Given: Import a runfile with a well that has a CLS discrep AND the IC is inhibited
When: Set LIMS Export on that well to report 'Detected'
And: Export run
Then: The well has 'Detected' in the results column (no additional errors triggered)
Test: Verify LIMS Export can be changed
Given: Import a runfile with multiple patient wells (mix of pos, neg wells)
When: Set LIMS Export = Re-extract for one patient well
And: Change LIMS Export = TNP for the same well
And: Export the runfile
Then: Export has TNP for that well
When: Change LIMS Export = Re-amplify for the same well
And: Export the runfile
Then: Export has REAMP for that well
Test: REQ-REANALYZE-002
Test: Verify outcome message after export
Given: Import a runfile with multiple patient wells (mix of pos, neg wells)
When: Export the runfile
Then: Each patient well has the correct outcome message with "Exported:" prefix
Test: Verify outcome message updates post-export
Given: Runfile imported - A1 has outcome "Not Detected"
When: Export runfile
Then: A1 shows "Exported: Not Detected"
When: User changes outcome to "Re-extract"
Then: A1 shows "This well is marked for re-extract"
When: Export runfile
Then: A1 shows "Exported: Re-extracted"
Test: REQ-REANALYZE-003
Test: Verify resolved control excluded from Westgard rules
Given: Upload a runfile with a control that is more than 3sd from mean
When: Resolve the error in the runfile control
And: Upload a runfile with a control that is more than 2sd from the mean
Then: The error message is NOT a WG 2.2s error (resolved control is ignored)
Test: Verify reanalysis prompt after resolution
Given: Upload a runfile with a control more than 3sd from mean
And: Upload a runfile with a control less than 2sd from mean
And: Open the 2nd runfile - control shows 'In Error from previous failed control'
When: Open the first runfile
And: Resolve the 1.3s error in the control
And: Open the second runfile
Then: User is prompted to re-analyse due to resolved westgard
Test: REQ-REANALYZE-004
Test: Earlier extraction date not affected
Given: Upload a runfile with a control more than 3sd from mean
When: Upload a runfile with a control less than 2sd from mean that was created EARLIER than the first runfile
And: Open the 2nd runfile
Then: The control does not have a Westgard in error message
Test: Same date controls check history
Given: Upload a runfile with 2 controls that are between 2 and 3 SD from the mean
Then: 1 control should have 1.2S warning
And: The other control should have 2.2S warning
Test: REQ-REANALYZE-005
Test: Verify resolved control display
Given: Upload a runfile with a failed Westgard rule
When: Resolve the error
And: Enable display of resolved controls in settings
And: Check the LJ plot
Then: Resolved control is visually distinguished from other controls
Test: Verify unresolved control display
Given: Upload a runfile with a failed Westgard rule
When: Check the LJ plot
Then: Unresolved error control is visually distinguished from normal controls
Test: Verify legend availability
Given: LJ plot is populated
When: Check plot area
Then: No legend is visible in plot area
When: Open settings
Then: Legend describing control status indicators is displayed
Test: Verify legend context sensitivity
Given: Runfile widget LJ view
When: Check the legend
Then: "Control in current run" indicator is available
Given: LJ report view
When: Check the legend
Then: Legend is displayed (may not include "Control in current run")
Test: REQ-REANALYZE-006
Test: Verify primary and secondary option interaction
Given: Manage results interface is displayed with resolution options
When: User selects a primary option
Then: Primary option is selected without requiring secondary option selection
When: User tries to select a secondary option without selecting primary option
Then: Secondary option selection is not allowed
When: User selects primary option first, then selects secondary option
Then: Secondary option is successfully selected
Test: REQ-REANALYZE-007
Test: Verify conflict prevention
Given: Run with multiple controls (CC1, CC2) affecting overlapping patient wells
When: User proposes "re-amplify all neg" on CC1
And: User tries to propose "re-extract all neg" on CC2 (affects same wells)
Then: Error is displayed
And: Second proposal is not allowed
Test: REQ-REANALYZE-008
Test: Verify reanalysis status when run added to series
Given: Run A with well A1, date: Date A, outcome: westgard 12s
When: Add new run B with well A1, date < Date A, outcome: westgard 12s
Then: Run A status updates to "Reanalysis required (Westgard)"
Test: Verify reanalysis status when role changes
Given:
Run A: well A1, role: Role A, date: Date A, outcome: westgard 12s
Run B: well A1, role: Role A, date > Date A, outcome: westgard 22s
Run C: well A1, role: Role B, date > Date A, outcome: westgard 12s
When: Change Run A well A1 role to Role B
Then: Run B status updates to "Reanalysis required (Westgard)"
And: Run C status updates to "Reanalysis required (Westgard)"
Test: REQ-REANALYZE-009
Test: Verify cross-run dependencies are tracked
Given: Run A is analyzed with multi-run rules (e.g., WG7T, WREP)
And: Run A wells reference wells from Run B (a prior run)
When: Run A analysis completes
Then: Run A wells' archive_dependent_well_ids contain well IDs from Run B
And: Run A wells' archive_dependent_well_ids do NOT contain well IDs from Run A itself
Test: Verify empty cache does not alter behavior
Given: A run with no cross-run dependencies (first run in series)
When: The run is analyzed
Then: The run's archive_dependent_well_ids field is empty
And: The analysis results are unchanged from baseline
Test: REQ-REANALYZE-010
Test: Verify future runs flagged on archive
Given: Run A was analyzed and its wells appear in Run B's archive_dependent_well_ids
When: Run A is archived via tag operation
Then: Run B's resolution_status is set to the archive reanalysis message
Test: Verify no flagging when no archive status change
Given: Run A has a non-archive tag applied
When: The tag operation completes
Then: No dependent runs are flagged for reanalysis
Test: REQ-REANALYZE-011
Test: Verify confirmation modal on flagged run
Given: Run B is flagged for archive dependency reanalysis
When: User opens Run B
Then: A confirmation modal is presented
When: User confirms reanalysis
Then: Run B is reanalyzed
And: Audit trail records "This run was re-analysed following changes to archived run dependencies."
Test: Verify decline leaves run unchanged
Given: Run B is flagged for archive dependency reanalysis
When: User opens Run B
And: User declines reanalysis
Then: Run B remains in its current state without reanalysis
Test: REQ-REANALYZE-012
Test: Verify role_alias change triggers reanalysis flagging
Given: Run A well W1 is referenced in Run B's archive_dependent_well_ids
When: User changes W1's role_alias via edit wells workflow
Then: Run B's resolution_status is set to "Results for wells in this run may be affected by recently edited wells. Reanalysis required."
Test: Verify non-role_alias changes do not trigger flagging
Given: Run A well W1 is referenced in Run B's archive_dependent_well_ids
When: User changes W1's accession (but not role_alias)
Then: Run B's resolution_status is NOT changed
Test: REQ-REANALYZE-013
Test: Verify resolution triggers reanalysis flagging
Given: Run A well W1 is referenced in Run B's archive_dependent_well_ids
When: Resolution codes are applied to W1 via manage results
Then: Run B's resolution_status is set to "Results for wells in this run may be affected by recently resolved wells. Reanalysis required."
Test: Verify confirmation and audit trail
Given: Run B is flagged for resolved-wells reanalysis
When: User opens Run B and confirms reanalysis
Then: Run B is reanalyzed
And: Audit trail records "This run was re-analysed following changes to resolved wells."
Related Design Documents
| Design Document | Relevant Sections |
|---|---|
| SDD Algorithms | Westgard Rules, Westgard in error |
| SDD Configuration | Error Resolutions Configurations |
Appendix: Process Artifacts
Completion Checklist
- All requirements are capability-level (describe behavior, not UI)
- Requirement variants consolidated (no requirement explosion)
- UI details are fully demoted to Illustrative section
- Configuration options are not encoded as requirements
- Acceptance criteria describe behavior, not UI mechanics
- Every requirement has acceptance criteria and source traceability
- Error handling addressed for I/O, validation, and external system requirements
- Open questions documented with owners assigned
- Consolidations documented in Reviewer Notes with reversibility info
- Module can survive a full UI redesign unchanged
- All ACs describe testable conditions
- Traceability matrix is complete
Reviewer Notes
Conversion Notes
No consolidation was performed for this domain. The 8 requirements represent distinct system capabilities:
| Requirement | Capability | Disposition |
|---|---|---|
| REQ-REANALYZE-001 | Rule processing bypass | Preserved as FR-REANALYZE-001 |
| REQ-REANALYZE-002 | Outcome message display | Preserved as FR-REANALYZE-002 |
| REQ-REANALYZE-003 | Westgard exclusion for resolved controls | Preserved as FR-REANALYZE-003 |
| REQ-REANALYZE-004 | Date-based Westgard propagation | Preserved as FR-REANALYZE-004 |
| REQ-REANALYZE-005 | LJ plot control status indicators | Preserved as FR-REANALYZE-005 |
| REQ-REANALYZE-006 | Resolution proposal selection | Preserved as FR-REANALYZE-006 |
| REQ-REANALYZE-007 | Conflict prevention | Preserved as FR-REANALYZE-007 |
| REQ-REANALYZE-008 | Westgard series change management | Preserved as FR-REANALYZE-008 |
| REQ-REANALYZE-009 | Track archive well dependencies | Added in v3.0.1 as FR-REANALYZE-009 |
| REQ-REANALYZE-010 | Flag dependent runs on archive | Added in v3.0.1 as FR-REANALYZE-010 |
| REQ-REANALYZE-011 | Confirm archive dependency reanalysis | Added in v3.0.1 as FR-REANALYZE-011 |
| REQ-REANALYZE-012 | Flag dependent runs on well edit | Added in v3.0.1 as FR-REANALYZE-012 |
| REQ-REANALYZE-013 | Flag dependent runs on well resolution | Added in v3.0.1 as FR-REANALYZE-013 |
Rationale: Each requirement represents a distinct capability that cannot be reasonably consolidated. Unlike filter variants or UI mechanics variants, these requirements describe separate functional responsibilities.
AC Transformations Applied:
- REQ-REANALYZE-006: Transformed "radio button" and "dropdown" references to "primary option" and "secondary option" for UI-agnostic language
Readability Improvements:
- Added Statement section for quick understanding
- Added Mermaid flowchart showing resolution workflow, SKIP processing, Westgard management, and export status flows
- Grouped ACs by concern (Rule Bypass Behavior, Export Modification, Configuration, etc.)
- Moved tests to end with back-links
- Changed "(Non-normative)" to "(Illustrative)" throughout
- Added blank lines before bullet lists for PDF rendering
v3.0.1 Changes
REQ-REANALYZE-009 through REQ-REANALYZE-013
Change: Added 5 new requirements forming the "dependency tracking" sub-group Reason: v3.0.1 introduced archive dependency tracking, edited-wells reanalysis, and resolved-wells reanalysis features Version: v3.0.1 Date: 2026-03-05
REQ-REANALYZE-008
Change: Added cross-reference note linking to REQ-REANALYZE-009 through REQ-REANALYZE-013 Reason: Westgard series changes are now one of four reanalysis trigger categories; cross-reference aids navigation Version: v3.0.1 Date: 2026-03-05
Reversibility: To reference original structure:
- Source:
output/srs/reanalyze.md - Confluence: 3.0.0-Reanalyze