|
68 | 68 | @pytest.mark.surveillance_regression_tests |
69 | 69 | def test_scenario_8(page: Page, general_properties: dict) -> None: |
70 | 70 | """ |
71 | | - Scenario: 8:SSPI cease |
| 71 | + Scenario: 8:SSPI cease |
72 | 72 |
|
73 | | - X500-X505-X92-C203 [SSCL30e] [SSUN7] X900-A99-A59-A259-X92-C203 [SSCL30e] [SSUN5] X900-A99-A59-A259-A315-A361-A323-A317-A348-A372-A373-A374-X92-C203 [SSCL30c] [SSUN6] X900 |
| 73 | + X500-X505-X92-C203 [SSCL30e] [SSUN7] X900-A99-A59-A259-X92-C203 [SSCL30e] [SSUN5] X900-A99-A59-A259-A315-A361-A323-A317-A348-A372-A373-A374-X92-C203 [SSCL30c] [SSUN6] X900 |
74 | 74 |
|
75 | | - This scenario tests closure of a Surveillance episode, at various points, as a result of an SSPI cease. Reopening a Surveillance episode from closure on X92 always reopens to X900, which is suitable for reopening after a postpone, but seems less suitable for reopening after the closure occurred later in the episode, as a result of an SSPI cease. |
| 75 | + This scenario tests closure of a Surveillance episode, at various points, as a result of an SSPI cease. Reopening a Surveillance episode from closure on X92 always reopens to X900, which is suitable for reopening after a postpone, but seems less suitable for reopening after the closure occurred later in the episode, as a result of an SSPI cease. |
76 | 76 |
|
77 | | - The cease/uncease rules for Surveillance are old and possibly due for an overhaul – and alas the reasoning behind them has been long since lost in the mists of time. |
| 77 | + The cease/uncease rules for Surveillance are old and possibly due for an overhaul – and alas the reasoning behind them has been long since lost in the mists of time. |
78 | 78 |
|
79 | | - The first cease (before the subject has attended a diagnostic test) closes the episode for death: on uncease the surveillance due date and reason for change are not changed but left as null and "Ceased". Presumably this is to allow user to investigate and possibly reopen the episode. This uncease is done by re-registering the subject with a GP practice. |
| 79 | + The first cease (before the subject has attended a diagnostic test) closes the episode for death: on uncease the surveillance due date and reason for change are not changed but left as null and "Ceased". Presumably this is to allow user to investigate and possibly reopen the episode. This uncease is done by re-registering the subject with a GP practice. |
80 | 80 |
|
81 | | - The second cease (after the subject has attended a diagnostic test, but the episode result is none of Cancer, LNPCP or High-risk findings) closes the episode for embarkation: on uncease the due date is set to the previous surveillance due date (rather than the calculated surveillance due date, which is also a little odd), and the reason set to "Reinstate surveillance". The actual value of the due date is too difficult to check, because the previous surveillance due date field is nullified at the same time. This uncease is done by changing the subject’s deduction code to one of the "not cease" codes. |
| 81 | + The second cease (after the subject has attended a diagnostic test, but the episode result is none of Cancer, LNPCP or High-risk findings) closes the episode for embarkation: on uncease the due date is set to the previous surveillance due date (rather than the calculated surveillance due date, which is also a little odd), and the reason set to "Reinstate surveillance". The actual value of the due date is too difficult to check, because the previous surveillance due date field is nullified at the same time. This uncease is done by changing the subject’s deduction code to one of the "not cease" codes. |
82 | 82 |
|
83 | | - <i>At this point the subject has a diagnostic test with a result and a completed investigation dataset, but no outcome, and there is no Advance Episode option (or even an interrupt) to add one. For the purposes of this scenario, the subject is invited for another test.</i> |
| 83 | + <i>At this point the subject has a diagnostic test with a result and a completed investigation dataset, but no outcome, and there is no Advance Episode option (or even an interrupt) to add one. For the purposes of this scenario, the subject is invited for another test.</i> |
84 | 84 |
|
85 | | - The third cease occurs when the episode has a result of High-risk findings. This is another embarkation cease, and the uncease is done by reopening the episode. Because the reopen also unceases the subject, the recall surveillance type is nullified. Reopening a surveillance episode nullifies the calculated FOBT due date, and the FOBT due date change date and reason for change. |
| 85 | + The third cease occurs when the episode has a result of High-risk findings. This is another embarkation cease, and the uncease is done by reopening the episode. Because the reopen also unceases the subject, the recall surveillance type is nullified. Reopening a surveillance episode nullifies the calculated FOBT due date, and the FOBT due date change date and reason for change. |
86 | 86 |
|
87 | | - <i>Once again, there are only limited options on reopen, and it is impossible to redirect the episode to re-enter the symptomatic result. This means the episode result cannot be “downgraded” at all.</i> |
| 87 | + <i>Once again, there are only limited options on reopen, and it is impossible to redirect the episode to re-enter the symptomatic result. This means the episode result cannot be “downgraded” at all.</i> |
88 | 88 |
|
89 | | - Scenario summary: |
| 89 | + Scenario summary: |
90 | 90 |
|
91 | 91 | > Run surveillance invitations for 1 subject > X500 (3.1) |
92 | 92 | > SSPI update changes subject to in-age at recall |
@@ -119,6 +119,7 @@ def test_scenario_8(page: Page, general_properties: dict) -> None: |
119 | 119 | > Check recall [SSCL30c] |
120 | 120 | > Reopen episode for correction > X900 (3.1) [SSUN6] |
121 | 121 | """ |
| 122 | + |
122 | 123 | # Given I log in to BCSS "England" as user role "Specialist Screening Practitioner" |
123 | 124 | user_role = UserTools.user_login( |
124 | 125 | page, "Specialist Screening Practitioner at BCS009 & BCS001", True |
|
0 commit comments