Skip to content

Commit 99f791d

Browse files
Merge branch 'develop' into feature/made14-NRL-1375-codebuild-deploys
2 parents 1f1f802 + f3e6d1b commit 99f791d

File tree

2 files changed

+93
-0
lines changed

2 files changed

+93
-0
lines changed

.prettierignore

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,2 @@
1+
# Ignore producer test cases:
2+
**/producer-test-cases.md

tests/producer-test-cases.md

Lines changed: 91 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,91 @@
1+
# Producer guidance:
2+
3+
The test cases in this section are **MANDATORY** and demonstrate core functionality of the system.
4+
5+
While some implementations may not use some interactions, we do require producers to be able to create,
6+
update/supersede and delete pointers.
7+
8+
---
9+
10+
### **TC-P01 - Create happy path / success scenario**
11+
12+
| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** |
13+
|----------|---------------------------|-----------------------|---------------------|
14+
| 1 | Authenticate as a valid organisation with a valid access token. | | |
15+
| 2 | Construct a new DocumentReference for the request body.<br> <ul> <li>Use test patient with NHS number 9876543210</li> <li>Type should reflect whichever type you plan on using in live, as agreed in IAG.</li> <li>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.</li> <li>Do not include a relatesTo section.</li> </ul> | 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. |
16+
| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.<br> 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:<br> <ul> <li>HTTP request body</li> <li>HTTP request URL</li> <li>HTTP verb</li> <li>ODS code of sender</li> <li>NHS number of patient</li> <li>Request date-time</li> <li>Request ID</li> <li>Correlation ID?</li> </ul> |
17+
| 4 | Record the unique .id generated for your newly created pointer.<br> Audit logs should contain details of the response to the request in step 3.<br> Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:<br> <ul> <li>HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)</li> <li>HTTP response code (201)</li> <li>Response datetime</li> <li>The pointer ID (found in the location header)</li> <li>Correlation ID?</li> </ul> |
18+
19+
---
20+
21+
### **TC-P02 - Read happy path / success scenario**
22+
23+
| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** |
24+
|----------|---------------------------|-----------------------|---------------------|
25+
| 1 | Authenticate as a valid organisation with a valid access token. | | |
26+
| 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:<br> <ul> <li>HTTP request body</li> <li>HTTP request URL</li> <li>HTTP verb</li> <li>ODS code of sender</li> <li>NHS number of patient</li> <li>Request date-time</li> <li>Request ID</li> <li>Correlation ID?</li> </ul> |
27+
| 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:<br> <ul> <li>HTTP response body (a DocumentReference)</li> <li>HTTP response code (200)</li> <li>Response datetime</li> <li>The pointer ID (found in the location header)</li> <li>Correlation ID?</li> </ul> |
28+
29+
---
30+
31+
### **TC-P03 - Supersede happy path / success scenario**
32+
33+
| **Step** | **Instructions/ Guidance** | **Evidence required** | **Expected outcome** |
34+
|----------|----------------------------|-----------------------|----------------------|
35+
| 1 | Authenticate as a valid organisation with a valid access token. | | |
36+
| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01.<br> <ul> <li>Use the same request body as in TC01. NHS number, type and category must match.</li> <li>Populate the relatesTo section with the pointer ID generated in TC01 (found in the location header of the response).</li> </ul> | 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. |
37+
| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec.<br> 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:<br> <ul> <li>HTTP request body</li> <li>HTTP request URL</li> <li>HTTP verb</li> <li>ODS code of sender</li> <li>NHS number of patient</li> <li>Request date-time</li> <li>Request ID</li> <li>Correlation ID?</li> </ul> |
38+
| 4 | Record the unique .id generated for your newly created pointer.<br> Audit logs should contain details of the response to the request in step 3.<br> Id: \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show:<br> <ul> <li>HTTP response body (an OperationOutcome indicating RESOURCE_CREATED)</li> <li>HTTP response code (201)</li> <li>Response datetime</li> <li>The pointer ID (found in the location header)</li> <li>Correlation ID?</li> </ul> |
39+
40+
---
41+
42+
### **TC-P04 - Search happy path / success scenario (multiple results)**
43+
44+
| **Step** | **Detailed instructions** | **Evidence required** |**Expected outcome** |
45+
|----------|---------------------------|-----------------------|---------------------|
46+
| 1 | Authenticate as a valid organisation with a valid access token. | | |
47+
| 2a OR 2b | <ul> <li>Send a GET search request for all pointers using the NHS number.</li> <li>Send a POST search request for all pointers using the NHS number.</li> </ul> | Save an extract or screenshot of the audit logs for this request in the appropriate folder. | Audit logs show:<br> <ul> <li>HTTP request body</li> <li>HTTP request URL</li> <li>HTTP verb</li> <li>ODS code of sender</li> <li>NHS number of patient</li> <li>Request date-time</li> <li>Request ID</li> <li>Correlation ID?</li> </ul> |
48+
| 3 | View the searchset bundle received in the response.<br> 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:<br> <ul> <li>HTTP response body (a DocumentReference)</li> <li>HTTP response code (200)</li> <li>Response datetime</li> <li>The pointer ID (found in the location header)</li> <li>Correlation ID?</li> </ul> |
49+
50+
---
51+
52+
### **Unhappy paths**
53+
54+
Choose one of the following negative scenarios for each interaction, and provide the evidence suggested.
55+
We recognise that if your application is designed to prevent misuse, these could be difficult to recreate
56+
using the UI; it may be necessary to make a small temporary change to configuration or send the request
57+
in another way. If you cannot complete one of these please reach out to the NRLF team via your
58+
organisation’s dedicated Slack channel.
59+
60+
The purpose of these tests is to show that your audit logging system properly records even failed
61+
attempts and error responses, in accordance with SAR requirements.
62+
63+
**“Create” / “Update” / “Supersede” example error scenarios:**
64+
65+
- Message body is not FHIR-compliant (expected response: 400)
66+
- Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g.
67+
- A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing.
68+
- 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)
69+
- The category does not match the type (e.g. a Mental Health Crisis Plan is submitted in the
70+
‘Observations’ category instead of ‘Care plan’) or uses the wrong system (i.e. not SNOMED)
71+
- The display value on a mandatory codeable concept does not match the expected text in the ValueSet
72+
(e.g. SNOMED code 736253002, but display is ‘Radiology report’ instead of ‘Mental health crisis plan’)
73+
- Missing a mandatory header
74+
- Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions.
75+
76+
**“Read” example error scenarios:**
77+
78+
- Missing or incorrect mandatory header
79+
- The pointer is a type for which your organisation does not have access
80+
- The pointer was created by a different organisation
81+
82+
**“Delete” example error scenarios:**
83+
84+
- Missing or incorrect mandatory headers
85+
- The pointer is created by a different organisation
86+
87+
Please indicate which case you have chosen and provide the following:
88+
89+
- Request body
90+
- Audit logs
91+
- Response body

0 commit comments

Comments
 (0)