From 639670f7a46facca500533ccc323c35f50f14559 Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Thu, 1 May 2025 07:17:57 +0100 Subject: [PATCH 1/9] NRL-1329 Add producer test cases --- tests/producer-test-cases-enhanced.asciidoc | 150 ++++++++++++++++++++ tests/producer-test-cases-enhanced.md | 75 ++++++++++ tests/producer-test-cases.md | 75 ++++++++++ 3 files changed, 300 insertions(+) create mode 100644 tests/producer-test-cases-enhanced.asciidoc create mode 100644 tests/producer-test-cases-enhanced.md create mode 100644 tests/producer-test-cases.md diff --git a/tests/producer-test-cases-enhanced.asciidoc b/tests/producer-test-cases-enhanced.asciidoc new file mode 100644 index 000000000..7e9cffa2e --- /dev/null +++ b/tests/producer-test-cases-enhanced.asciidoc @@ -0,0 +1,150 @@ += Producer Guidance + +The test cases in this section are MANDATORY and demonstrate core functionality of the system. + +While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. + +[cols="1,3,2,2", options="header"] +|=== +| Step | Detailed instructions | Evidence required | Expected outcome + +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a new DocumentReference for the request body. + +* Use test patient with NHS number 9876543210 +* Type should reflect whichever type you plan on using in live, as agreed in IAG. +* All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them. +* Do not include a relatesTo section. | Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + +Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + +* HTTP request body +* HTTP request URL +* HTTP verb +* ODS code of sender +* NHS number of patient +* Request date-time +* Request ID +* Correlation ID? | +| 4 | Record the unique .id generated for your newly created pointer. + +Audit logs should contain details of the response to the request in step 3. + +Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + +* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) +* HTTP response code (201) +* Response datetime +* The pointer ID (found in the location header) +* Correlation ID? | +|=== + +== TC-P02 - Read happy path / success scenario + +[cols="1,3,2,2", options="header"] +|=== +| Step | Detailed instructions | Evidence required | Expected outcome + +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + +* HTTP request body +* HTTP request URL +* HTTP verb +* ODS code of sender +* NHS number of patient +* Request date-time +* Request ID +* Correlation ID? | +| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + +* HTTP response body (a DocumentReference) +* HTTP response code (200) +* Response datetime +* The pointer ID (found in the location header) +* Correlation ID? | +|=== + +== TC-P03 - Supersede happy path / success scenario + +[cols="1,3,2,2", options="header"] +|=== +| Step | Instructions/ Guidance | Evidence required | Expected outcome + +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01. + +* Use the same request body as in TC01. NHS number, type and category must match. +* Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response). | Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + +Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + +* HTTP request body +* HTTP request URL +* HTTP verb +* ODS code of sender +* NHS number of patient +* Request date-time +* Request ID +* Correlation ID? | +| 4 | Record the unique .id generated for your newly created pointer. + +Audit logs should contain details of the response to the request in step 3. + +Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + +* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) +* HTTP response code (201) +* Response datetime +* The pointer ID (found in the location header) +* Correlation ID? | +|=== + +== TC-P04 - Search happy path / success scenario (multiple results) + +[cols="1,3,2,2", options="header"] +|=== +| Step | Detailed instructions | Evidence required | Expected outcome + +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2a OR 2b | + +* Send a GET search request for all pointers using the NHS number. +* Send a POST search request for all pointers using the NHS number. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + +* HTTP request body +* HTTP request URL +* HTTP verb +* ODS code of sender +* NHS number of patient +* Request date-time +* Request ID +* Correlation ID? | +| 3 | View the searchset bundle received in the response. + +There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + +* HTTP response body (a DocumentReference) +* HTTP response code (200) +* Response datetime +* The pointer ID (found in the location header) +* Correlation ID? | +|=== + +== Unhappy paths + +Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. + +The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. + +=== “Create” / “Update” / “Supersede” example error scenarios: + +* Message body is not FHIR-compliant (expected response: 400) +* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. + ** A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. + ** A mandatory field has an invalid value, e.g. a + ** The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) + ** The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ +* Missing a mandatory header +* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. + +=== “Read” example error scenarios: + +* Missing or incorrect mandatory header +* The pointer is a type for which your organisation does not have access +* The pointer was created by a different organisation + +=== “Delete” example error scenarios: + +* Missing or incorrect mandatory headers +* The pointer is created by a different organisation + +Please indicate which case you have chosen and provide the following: + +* Request body +* Audit logs +* Response body \ No newline at end of file diff --git a/tests/producer-test-cases-enhanced.md b/tests/producer-test-cases-enhanced.md new file mode 100644 index 000000000..2cc501642 --- /dev/null +++ b/tests/producer-test-cases-enhanced.md @@ -0,0 +1,75 @@ +Producer guidance: + +The test cases in this section are MANDATORY and demonstrate core functionality of the system. + +While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a new DocumentReference for the request body.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: | +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: | + +### **TC-P02 - Read happy path / success scenario** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: | +| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: | + +### **TC-P03 - Supersede happy path / success scenario** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: | +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: | + +### **TC-P04 - Search happy path / success scenario (multiple results)** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2a OR 2b | | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: | +| 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: | + +### **Unhappy paths** + +Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. + +The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. + +**“Create” / “Update” / “Supersede” example error scenarios:** + +* Message body is not FHIR-compliant (expected response: 400) +* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. + + A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. + + A mandatory field has an invalid value, e.g. a + + The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) + + The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ +* Missing a mandatory header +* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. + +**“Read” example error scenarios:** + +* Missing or incorrect mandatory header +* The pointer is a type for which your organisation does not have access +* The pointer was created by a different organisation + +**“Delete” example error scenarios:** + +* Missing or incorrect mandatory headers +* The pointer is created by a different organisation + +Please indicate which case you have chosen and provide the following: + +* Request body +* Audit logs +* Response body diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md new file mode 100644 index 000000000..ffd2551fc --- /dev/null +++ b/tests/producer-test-cases.md @@ -0,0 +1,75 @@ +Producer guidance: + +The test cases in this section are MANDATORY and demonstrate core functionality of the system. + +While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a new DocumentReference for the request body. * Use test patient with NHS number **9876543210** * Type should reflect whichever type you plan on using in live, as agreed in IAG. * All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them. * Do not include a **relatesTo** section. | Please include a **copy of the request body** as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. Audit logs should contain details of the request. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | +| 4 | Record the unique .id generated for your newly created pointer. Audit logs should contain details of the response to the request in step 3. Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an OperationOutcome indicating RESOURCE\_CREATED) * HTTP response code (201) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | + +### **TC-P02 - Read happy path / success scenario** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | +| 4 | View the pointer received in the response. | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an DocumentReference) * HTTP response code (200) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | + +### **TC-P03 - Supersede happy path / success scenario** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01. * Use the same request body as in TC01. NHS number, type and category must match. * Populate the **relatesTo** section with the pointer ID generated in TC01 (found in the location header of the response). | Please include a **copy of the request body** as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. Audit logs should contain details of the request. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | +| 4 | Record the unique .id generated for your newly created pointer. Audit logs should contain details of the response to the request in step 3. Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an OperationOutcome indicating RESOURCE\_CREATED) * HTTP response code (201) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | + +### **TC-P04 - Search happy path / success scenario (multiple results)** + +| | | | | +| --- | --- | --- | --- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2a OR 2b | Send a GET search request for all pointers using the NHS number. Send a POST search request for all pointers using the NHS number. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | +| 3 | View the searchset bundle received in the response. There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an DocumentReference) * HTTP response code (200) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | + +### **Unhappy paths** + +Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. + +The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. + +**“Create” / “Update” / “Supersede” example error scenarios:** + +* Message body is not FHIR-compliant (expected response: 400) +* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. + + A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. + + A mandatory field has an invalid value, e.g. a + + The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) + + The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ +* Missing a mandatory header +* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. + +**“Read” example error scenarios:** + +* Missing or incorrect mandatory header +* The pointer is a type for which your organisation does not have access +* The pointer was created by a different organisation + +**“Delete” example error scenarios:** + +* Missing or incorrect mandatory headers +* The pointer is created by a different organisation + +Please indicate which case you have chosen and provide the following: + +* Request body +* Audit logs +* Response body From 9f90a95691af2f0d08479da02ae26b23be585edc Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Thu, 1 May 2025 09:04:49 +0100 Subject: [PATCH 2/9] NRL-1329 Fix for asciidoc --- tests/producer-test-cases-enhanced.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/producer-test-cases-enhanced.asciidoc b/tests/producer-test-cases-enhanced.asciidoc index 7e9cffa2e..5af1d360a 100644 --- a/tests/producer-test-cases-enhanced.asciidoc +++ b/tests/producer-test-cases-enhanced.asciidoc @@ -9,7 +9,7 @@ While some implementations may not use some interactions, we do require producer | Step | Detailed instructions | Evidence required | Expected outcome | 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a new DocumentReference for the request body. + +| 2 | Construct a new DocumentReference for the request body. * Use test patient with NHS number 9876543210 * Type should reflect whichever type you plan on using in live, as agreed in IAG. * All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them. From 3e5f0b8eebeffe2f5d6f1e8c8b650dde3d540f8f Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 10:31:20 +0100 Subject: [PATCH 3/9] NRL-1329 Remove asciidoc and rename producer test cases --- tests/producer-test-cases-enhanced.asciidoc | 150 -------------------- tests/producer-test-cases-enhanced.md | 75 ---------- tests/producer-test-cases.md | 84 +++++------ 3 files changed, 42 insertions(+), 267 deletions(-) delete mode 100644 tests/producer-test-cases-enhanced.asciidoc delete mode 100644 tests/producer-test-cases-enhanced.md diff --git a/tests/producer-test-cases-enhanced.asciidoc b/tests/producer-test-cases-enhanced.asciidoc deleted file mode 100644 index 5af1d360a..000000000 --- a/tests/producer-test-cases-enhanced.asciidoc +++ /dev/null @@ -1,150 +0,0 @@ -= Producer Guidance - -The test cases in this section are MANDATORY and demonstrate core functionality of the system. - -While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. - -[cols="1,3,2,2", options="header"] -|=== -| Step | Detailed instructions | Evidence required | Expected outcome - -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a new DocumentReference for the request body. -* Use test patient with NHS number 9876543210 -* Type should reflect whichever type you plan on using in live, as agreed in IAG. -* All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them. -* Do not include a relatesTo section. | Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + -Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + -* HTTP request body -* HTTP request URL -* HTTP verb -* ODS code of sender -* NHS number of patient -* Request date-time -* Request ID -* Correlation ID? | -| 4 | Record the unique .id generated for your newly created pointer. + -Audit logs should contain details of the response to the request in step 3. + -Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + -* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) -* HTTP response code (201) -* Response datetime -* The pointer ID (found in the location header) -* Correlation ID? | -|=== - -== TC-P02 - Read happy path / success scenario - -[cols="1,3,2,2", options="header"] -|=== -| Step | Detailed instructions | Evidence required | Expected outcome - -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + -* HTTP request body -* HTTP request URL -* HTTP verb -* ODS code of sender -* NHS number of patient -* Request date-time -* Request ID -* Correlation ID? | -| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + -* HTTP response body (a DocumentReference) -* HTTP response code (200) -* Response datetime -* The pointer ID (found in the location header) -* Correlation ID? | -|=== - -== TC-P03 - Supersede happy path / success scenario - -[cols="1,3,2,2", options="header"] -|=== -| Step | Instructions/ Guidance | Evidence required | Expected outcome - -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01. + -* Use the same request body as in TC01. NHS number, type and category must match. -* Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response). | Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + -Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + -* HTTP request body -* HTTP request URL -* HTTP verb -* ODS code of sender -* NHS number of patient -* Request date-time -* Request ID -* Correlation ID? | -| 4 | Record the unique .id generated for your newly created pointer. + -Audit logs should contain details of the response to the request in step 3. + -Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + -* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) -* HTTP response code (201) -* Response datetime -* The pointer ID (found in the location header) -* Correlation ID? | -|=== - -== TC-P04 - Search happy path / success scenario (multiple results) - -[cols="1,3,2,2", options="header"] -|=== -| Step | Detailed instructions | Evidence required | Expected outcome - -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2a OR 2b | + -* Send a GET search request for all pointers using the NHS number. -* Send a POST search request for all pointers using the NHS number. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show: + -* HTTP request body -* HTTP request URL -* HTTP verb -* ODS code of sender -* NHS number of patient -* Request date-time -* Request ID -* Correlation ID? | -| 3 | View the searchset bundle received in the response. + -There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + -* HTTP response body (a DocumentReference) -* HTTP response code (200) -* Response datetime -* The pointer ID (found in the location header) -* Correlation ID? | -|=== - -== Unhappy paths - -Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. - -The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. - -=== “Create” / “Update” / “Supersede” example error scenarios: - -* Message body is not FHIR-compliant (expected response: 400) -* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. - ** A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. - ** A mandatory field has an invalid value, e.g. a - ** The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) - ** The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ -* Missing a mandatory header -* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. - -=== “Read” example error scenarios: - -* Missing or incorrect mandatory header -* The pointer is a type for which your organisation does not have access -* The pointer was created by a different organisation - -=== “Delete” example error scenarios: - -* Missing or incorrect mandatory headers -* The pointer is created by a different organisation - -Please indicate which case you have chosen and provide the following: - -* Request body -* Audit logs -* Response body \ No newline at end of file diff --git a/tests/producer-test-cases-enhanced.md b/tests/producer-test-cases-enhanced.md deleted file mode 100644 index 2cc501642..000000000 --- a/tests/producer-test-cases-enhanced.md +++ /dev/null @@ -1,75 +0,0 @@ -Producer guidance: - -The test cases in this section are MANDATORY and demonstrate core functionality of the system. - -While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. - -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a new DocumentReference for the request body.
  • Use test patient with NHS number 9876543210
  • Type should reflect whichever type you plan on using in live, as agreed in IAG.
  • All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them.
  • Do not include a relatesTo section.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| - -### **TC-P02 - Read happy path / success scenario** - -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| - -### **TC-P03 - Supersede happy path / success scenario** - -| | | | | -| --- | --- | --- | --- | -| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| - -### **TC-P04 - Search happy path / success scenario (multiple results)** - -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2a OR 2b |
  • Send a GET search request for all pointers using the NHS number.
  • Send a POST search request for all pointers using the NHS number.
| Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| - -### **Unhappy paths** - -Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. - -The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. - -**“Create” / “Update” / “Supersede” example error scenarios:** - -* Message body is not FHIR-compliant (expected response: 400) -* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. - + A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. - + A mandatory field has an invalid value, e.g. a - + The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) - + The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ -* Missing a mandatory header -* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. - -**“Read” example error scenarios:** - -* Missing or incorrect mandatory header -* The pointer is a type for which your organisation does not have access -* The pointer was created by a different organisation - -**“Delete” example error scenarios:** - -* Missing or incorrect mandatory headers -* The pointer is created by a different organisation - -Please indicate which case you have chosen and provide the following: - -* Request body -* Audit logs -* Response body diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index ffd2551fc..cb1a68052 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -4,41 +4,41 @@ The test cases in this section are MANDATORY and demonstrate core functionality While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a new DocumentReference for the request body. * Use test patient with NHS number **9876543210** * Type should reflect whichever type you plan on using in live, as agreed in IAG. * All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them. * Do not include a **relatesTo** section. | Please include a **copy of the request body** as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. Audit logs should contain details of the request. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | -| 4 | Record the unique .id generated for your newly created pointer. Audit logs should contain details of the response to the request in step 3. Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an OperationOutcome indicating RESOURCE\_CREATED) * HTTP response code (201) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | +| | | | | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a new DocumentReference for the request body.
  • Use test patient with NHS number 9876543210
  • Type should reflect whichever type you plan on using in live, as agreed in IAG.
  • All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them.
  • Do not include a relatesTo section.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \***\*\*\*\*\*\*\***\_\_\_\_\***\*\*\*\*\*\*\*** | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| ### **TC-P02 - Read happy path / success scenario** -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | -| 4 | View the pointer received in the response. | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an DocumentReference) * HTTP response code (200) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | +| | | | | +| -------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| ### **TC-P03 - Supersede happy path / success scenario** -| | | | | -| --- | --- | --- | --- | -| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01. * Use the same request body as in TC01. NHS number, type and category must match. * Populate the **relatesTo** section with the pointer ID generated in TC01 (found in the location header of the response). | Please include a **copy of the request body** as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. Audit logs should contain details of the request. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | -| 4 | Record the unique .id generated for your newly created pointer. Audit logs should contain details of the response to the request in step 3. Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an OperationOutcome indicating RESOURCE\_CREATED) * HTTP response code (201) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | +| | | | | +| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \***\*\*\*\*\*\*\***\_\_\_\_\***\*\*\*\*\*\*\*** | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| ### **TC-P04 - Search happy path / success scenario (multiple results)** -| | | | | -| --- | --- | --- | --- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2a OR 2b | Send a GET search request for all pointers using the NHS number. Send a POST search request for all pointers using the NHS number. | Save an extract or screenshot of the **audit logs for this** **request** in the appropriate folder. | Audit logs show: * HTTP request body * HTTP request URL * HTTP verb * ODS code of sender * NHS number of patient * Request date-time * Request ID * Correlation ID? | -| 3 | View the searchset bundle received in the response. There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the **audit logs for this** **response** in the appropriate folder. | Audit logs show: * HTTP response body (an DocumentReference) * HTTP response code (200) * Response datetime * The pointer ID (found in the location header) * Correlation ID? | +| | | | | +| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | +| 1 | Authenticate as a valid organisation with a valid access token | | | +| 2a OR 2b |
  • Send a GET search request for all pointers using the NHS number.
  • Send a POST search request for all pointers using the NHS number.
| Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| ### **Unhappy paths** @@ -48,28 +48,28 @@ The purpose of these tests is to show that your audit logging system properly re **“Create” / “Update” / “Supersede” example error scenarios:** -* Message body is not FHIR-compliant (expected response: 400) -* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. - + A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. - + A mandatory field has an invalid value, e.g. a - + The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) - + The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ -* Missing a mandatory header -* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. +- Message body is not FHIR-compliant (expected response: 400) +- Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. + - A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. + - A mandatory field has an invalid value, e.g. a + - The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) + - The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ +- Missing a mandatory header +- Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. **“Read” example error scenarios:** -* Missing or incorrect mandatory header -* The pointer is a type for which your organisation does not have access -* The pointer was created by a different organisation +- Missing or incorrect mandatory header +- The pointer is a type for which your organisation does not have access +- The pointer was created by a different organisation **“Delete” example error scenarios:** -* Missing or incorrect mandatory headers -* The pointer is created by a different organisation +- Missing or incorrect mandatory headers +- The pointer is created by a different organisation Please indicate which case you have chosen and provide the following: -* Request body -* Audit logs -* Response body +- Request body +- Audit logs +- Response body From 0b066b120dacbb2067a7972b93796a510594f7cc Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:09:33 +0100 Subject: [PATCH 4/9] NRL-1329 Make formatting more human readable, ignore prettier --- .prettierignore | 2 + tests/producer-test-cases.md | 80 +++++++++++++++++++++--------------- 2 files changed, 50 insertions(+), 32 deletions(-) create mode 100644 .prettierignore diff --git a/.prettierignore b/.prettierignore new file mode 100644 index 000000000..24de7b5f4 --- /dev/null +++ b/.prettierignore @@ -0,0 +1,2 @@ +# Ignore producer test cases: +**/producer-test-cases.md diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index cb1a68052..f7e7de267 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -1,50 +1,64 @@ Producer guidance: -The test cases in this section are MANDATORY and demonstrate core functionality of the system. +The test cases in this section are **MANDATORY** and demonstrate core functionality of the system. -While some implementations may not use some interactions, we do require producers to be able to create, update/supersede and delete pointers. +While some implementations may not use some interactions, we do require producers to be able to create, +update/supersede and delete pointers. -| | | | | -| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a new DocumentReference for the request body.
  • Use test patient with NHS number 9876543210
  • Type should reflect whichever type you plan on using in live, as agreed in IAG.
  • All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them.
  • Do not include a relatesTo section.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \***\*\*\*\*\*\*\***\_\_\_\_\***\*\*\*\*\*\*\*** | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +--- + +### **TC-P01 - Create happy path / success scenario** + +|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| +|--------|-------------------------|---------------------|--------------------| +| 1 | Authenticate as a valid organisation with a valid access token. | | | +| 2 | Construct a new DocumentReference for the request body.
  • Use test patient with NHS number 9876543210
  • Type should reflect whichever type you plan on using in live, as agreed in IAG.
  • All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them.
  • Do not include a relatesTo section.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| + +--- ### **TC-P02 - Read happy path / success scenario** -| | | | | -| -------- | ---------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| +|--------|-------------------------|---------------------|--------------------| +| 1 | Authenticate as a valid organisation with a valid access token. | | | +| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| + +--- ### **TC-P03 - Supersede happy path / success scenario** -| | | | | -| -------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | -| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \***\*\*\*\*\*\*\***\_\_\_\_\***\*\*\*\*\*\*\*** | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +|**Step**|**Instructions/ Guidance**|**Evidence required**|**Expected outcome**| +|--------|--------------------------|---------------------|--------------------| +| 1 | Authenticate as a valid organisation with a valid access token. | | | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| + +--- ### **TC-P04 - Search happy path / success scenario (multiple results)** -| | | | | -| -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| **Step** | **Detailed instructions** | **Evidence required** | **Expected outcome** | -| 1 | Authenticate as a valid organisation with a valid access token | | | -| 2a OR 2b |
  • Send a GET search request for all pointers using the NHS number.
  • Send a POST search request for all pointers using the NHS number.
| Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| +|--------|-------------------------|---------------------|--------------------| +| 1 | Authenticate as a valid organisation with a valid access token. | | | +| 2a OR 2b |
  • Send a GET search request for all pointers using the NHS number.
  • Send a POST search request for all pointers using the NHS number.
| Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| + +--- ### **Unhappy paths** -Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. We recognise that if your application is designed to prevent misuse, these could be difficult to recreate using the UI; it may be necessary to make a small temporary change to configuration or send the request in another way. If you cannot complete one of these please reach out to the NRLF team via your organisation’s dedicated Slack channel. +Choose one of the following negative scenarios for each interaction, and provide the evidence suggested. +We recognise that if your application is designed to prevent misuse, these could be difficult to recreate +using the UI; it may be necessary to make a small temporary change to configuration or send the request +in another way. If you cannot complete one of these please reach out to the NRLF team via your +organisation’s dedicated Slack channel. -The purpose of these tests is to show that your audit logging system properly records even failed attempts and error responses, in accordance with SAR requirements. +The purpose of these tests is to show that your audit logging system properly records even failed +attempts and error responses, in accordance with SAR requirements. **“Create” / “Update” / “Supersede” example error scenarios:** @@ -52,8 +66,10 @@ The purpose of these tests is to show that your audit logging system properly re - Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. - A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. - A mandatory field has an invalid value, e.g. a - - The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) - - The display value on a mandatory codeable concept does not match the expected text in the ValueSet (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’ + - The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the + ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) + - The display value on a mandatory codeable concept does not match the expected text in the ValueSet + (e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’) - Missing a mandatory header - Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. From 5c84ad4144b275eaa9a1d72853c5c0a12a981afd Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:11:46 +0100 Subject: [PATCH 5/9] NRL-1329 Make it even more formatted --- tests/producer-test-cases.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index f7e7de267..806bd1dc8 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -9,8 +9,8 @@ update/supersede and delete pointers. ### **TC-P01 - Create happy path / success scenario** -|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| -|--------|-------------------------|---------------------|--------------------| +| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** | +|----------|---------------------------|-----------------------|---------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | | 2 | Construct a new DocumentReference for the request body.
  • Use test patient with NHS number 9876543210
  • Type should reflect whichever type you plan on using in live, as agreed in IAG.
  • All mandatory fields must be populated, and any other fields you plan to use in your live implementation should be populated as you intend to use them.
  • Do not include a relatesTo section.
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | | 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| @@ -20,8 +20,8 @@ update/supersede and delete pointers. ### **TC-P02 - Read happy path / success scenario** -|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| -|--------|-------------------------|---------------------|--------------------| +| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** | +|----------|---------------------------|-----------------------|---------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | | 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| | 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| @@ -30,8 +30,8 @@ update/supersede and delete pointers. ### **TC-P03 - Supersede happy path / success scenario** -|**Step**|**Instructions/ Guidance**|**Evidence required**|**Expected outcome**| -|--------|--------------------------|---------------------|--------------------| +| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | +|----------|----------------------------|-----------------------|----------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | | 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | | 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| @@ -41,8 +41,8 @@ update/supersede and delete pointers. ### **TC-P04 - Search happy path / success scenario (multiple results)** -|**Step**|**Detailed instructions**|**Evidence required**|**Expected outcome**| -|--------|-------------------------|---------------------|--------------------| +| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** | +|----------|---------------------------|-----------------------|---------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | | 2a OR 2b |
  • Send a GET search request for all pointers using the NHS number.
  • Send a POST search request for all pointers using the NHS number.
| Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| | 3 | View the searchset bundle received in the response.
There should be at least TWO DocumentReferences; the one you created (and superseded) in the previous tests, and another one created by NRLF filled with example data. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| From 3445d301c20b8830813a4cfcd4ff2c7e84987c01 Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:27:48 +0100 Subject: [PATCH 6/9] NRL-1329 Fix numbering --- tests/producer-test-cases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index 806bd1dc8..57a36c4f6 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -23,8 +23,8 @@ update/supersede and delete pointers. | **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** | |----------|---------------------------|-----------------------|---------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | -| 3 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 4 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +| 2 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| +| 3 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| --- From 5358c6e127b363fcf992a0990c13f9afdcc19cca Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:34:04 +0100 Subject: [PATCH 7/9] NRL-1329 Remove a few spaces --- tests/producer-test-cases.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index 57a36c4f6..9c4e78ce8 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -24,7 +24,7 @@ update/supersede and delete pointers. |----------|---------------------------|-----------------------|---------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | | 2 | Send a GET request for the pointer created in TC-01 using the ID generated and recorded. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| -| 3 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| +| 3 | View the pointer received in the response. | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (a DocumentReference)
  • HTTP response code (200)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| --- @@ -33,7 +33,7 @@ update/supersede and delete pointers. | **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** | |----------|----------------------------|-----------------------|----------------------| | 1 | Authenticate as a valid organisation with a valid access token. | | | -| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.
  • Use the same request body as in TC01. NHS number, type and category must match.
  • Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).
| Please include a copy of the request body as it was sent in. | Request body is a valid FHIR R4 DocumentReference that adheres to the additional constraints detailed in the API specification, as well as any other constraints mentioned in the compliance checklist. | | 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.
Audit logs should contain details of the request. | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:
  • HTTP request body
  • HTTP request URL
  • HTTP verb
  • ODS code of sender
  • NHS number of patient
  • Request date-time
  • Request ID
  • Correlation ID?
| | 4 | Record the unique .id generated for your newly created pointer.
Audit logs should contain details of the response to the request in step 3.
Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:
  • HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)
  • HTTP response code (201)
  • Response datetime
  • The pointer ID (found in the location header)
  • Correlation ID?
| From 34cef1eb0e9d6671e4cdda8e055995e6d2a79d4e Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:52:46 +0100 Subject: [PATCH 8/9] NRL-1329 Add example of invalid mandatory field --- tests/producer-test-cases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index 9c4e78ce8..e19da1bc6 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -65,7 +65,7 @@ attempts and error responses, in accordance with SAR requirements. - Message body is not FHIR-compliant (expected response: 400) - Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. - A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. - - A mandatory field has an invalid value, e.g. a + - A mandatory field has an invalid value, e.g. an ’author’ with an invalid system identifier (i.e. not https://fhir.nhs.uk/Id/ods-organization-code) - The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the ‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED) - The display value on a mandatory codeable concept does not match the expected text in the ValueSet From de9621ed2cae02011477a942a9a2c0049ca95271 Mon Sep 17 00:00:00 2001 From: "Axel Garcia K." Date: Tue, 13 May 2025 11:58:31 +0100 Subject: [PATCH 9/9] NRL-1329 Add header --- tests/producer-test-cases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/producer-test-cases.md b/tests/producer-test-cases.md index e19da1bc6..75e9faeb7 100644 --- a/tests/producer-test-cases.md +++ b/tests/producer-test-cases.md @@ -1,4 +1,4 @@ -Producer guidance: +# Producer guidance: The test cases in this section are **MANDATORY** and demonstrate core functionality of the system.