|
| 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, update/supersede and delete pointers. |
| 6 | + |
| 7 | +[cols="1,3,2,2", options="header"] |
| 8 | +|=== |
| 9 | +| Step | Detailed instructions | Evidence required | Expected outcome |
| 10 | + |
| 11 | +| 1 | Authenticate as a valid organisation with a valid access token | | | |
| 12 | +| 2 | Construct a new DocumentReference for the request body. + |
| 13 | +* Use test patient with NHS number 9876543210 |
| 14 | +* Type should reflect whichever type you plan on using in live, as agreed in IAG. |
| 15 | +* 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. |
| 16 | +* 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. | |
| 17 | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + |
| 18 | +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: + |
| 19 | +* HTTP request body |
| 20 | +* HTTP request URL |
| 21 | +* HTTP verb |
| 22 | +* ODS code of sender |
| 23 | +* NHS number of patient |
| 24 | +* Request date-time |
| 25 | +* Request ID |
| 26 | +* Correlation ID? | |
| 27 | +| 4 | Record the unique .id generated for your newly created pointer. + |
| 28 | +Audit logs should contain details of the response to the request in step 3. + |
| 29 | +Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + |
| 30 | +* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) |
| 31 | +* HTTP response code (201) |
| 32 | +* Response datetime |
| 33 | +* The pointer ID (found in the location header) |
| 34 | +* Correlation ID? | |
| 35 | +|=== |
| 36 | + |
| 37 | +== TC-P02 - Read happy path / success scenario |
| 38 | + |
| 39 | +[cols="1,3,2,2", options="header"] |
| 40 | +|=== |
| 41 | +| Step | Detailed instructions | Evidence required | Expected outcome |
| 42 | + |
| 43 | +| 1 | Authenticate as a valid organisation with a valid access token | | | |
| 44 | +| 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: + |
| 45 | +* HTTP request body |
| 46 | +* HTTP request URL |
| 47 | +* HTTP verb |
| 48 | +* ODS code of sender |
| 49 | +* NHS number of patient |
| 50 | +* Request date-time |
| 51 | +* Request ID |
| 52 | +* Correlation ID? | |
| 53 | +| 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: + |
| 54 | +* HTTP response body (a DocumentReference) |
| 55 | +* HTTP response code (200) |
| 56 | +* Response datetime |
| 57 | +* The pointer ID (found in the location header) |
| 58 | +* Correlation ID? | |
| 59 | +|=== |
| 60 | + |
| 61 | +== TC-P03 - Supersede happy path / success scenario |
| 62 | + |
| 63 | +[cols="1,3,2,2", options="header"] |
| 64 | +|=== |
| 65 | +| Step | Instructions/ Guidance | Evidence required | Expected outcome |
| 66 | + |
| 67 | +| 1 | Authenticate as a valid organisation with a valid access token | | | |
| 68 | +| 2 | Construct a DocumentReference for the request body that will supersede the pointer created in TC01. + |
| 69 | +* Use the same request body as in TC01. NHS number, type and category must match. |
| 70 | +* 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. | |
| 71 | +| 3 | Send as a POST request to the /DocumentReference endpoint, along with headers specified in the API spec. + |
| 72 | +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: + |
| 73 | +* HTTP request body |
| 74 | +* HTTP request URL |
| 75 | +* HTTP verb |
| 76 | +* ODS code of sender |
| 77 | +* NHS number of patient |
| 78 | +* Request date-time |
| 79 | +* Request ID |
| 80 | +* Correlation ID? | |
| 81 | +| 4 | Record the unique .id generated for your newly created pointer. + |
| 82 | +Audit logs should contain details of the response to the request in step 3. + |
| 83 | +Id: ____________________________ | Save an extract or screenshot of the audit logs for this response in the appropriate folder. | Audit logs show: + |
| 84 | +* HTTP response body (an OperationOutcome indicating RESOURCE_CREATED) |
| 85 | +* HTTP response code (201) |
| 86 | +* Response datetime |
| 87 | +* The pointer ID (found in the location header) |
| 88 | +* Correlation ID? | |
| 89 | +|=== |
| 90 | + |
| 91 | +== TC-P04 - Search happy path / success scenario (multiple results) |
| 92 | + |
| 93 | +[cols="1,3,2,2", options="header"] |
| 94 | +|=== |
| 95 | +| Step | Detailed instructions | Evidence required | Expected outcome |
| 96 | + |
| 97 | +| 1 | Authenticate as a valid organisation with a valid access token | | | |
| 98 | +| 2a OR 2b | + |
| 99 | +* Send a GET search request for all pointers using the NHS number. |
| 100 | +* 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: + |
| 101 | +* HTTP request body |
| 102 | +* HTTP request URL |
| 103 | +* HTTP verb |
| 104 | +* ODS code of sender |
| 105 | +* NHS number of patient |
| 106 | +* Request date-time |
| 107 | +* Request ID |
| 108 | +* Correlation ID? | |
| 109 | +| 3 | View the searchset bundle received in the response. + |
| 110 | +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: + |
| 111 | +* HTTP response body (a DocumentReference) |
| 112 | +* HTTP response code (200) |
| 113 | +* Response datetime |
| 114 | +* The pointer ID (found in the location header) |
| 115 | +* Correlation ID? | |
| 116 | +|=== |
| 117 | + |
| 118 | +== Unhappy paths |
| 119 | + |
| 120 | +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. |
| 121 | + |
| 122 | +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. |
| 123 | + |
| 124 | +=== “Create” / “Update” / “Supersede” example error scenarios: |
| 125 | + |
| 126 | +* Message body is not FHIR-compliant (expected response: 400) |
| 127 | +* Message body does not meet the NRL business logic profile (expected response: 400 or 422), e.g. |
| 128 | + ** A mandatory field such as ‘context.practiceSetting’, ‘author’, or ‘category’ is missing. |
| 129 | + ** A mandatory field has an invalid value, e.g. a |
| 130 | + ** 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) |
| 131 | + ** 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’ |
| 132 | +* Missing a mandatory header |
| 133 | +* Marking the ‘type’ of a pointer as one for which your organisation has not been granted permissions. |
| 134 | + |
| 135 | +=== “Read” example error scenarios: |
| 136 | + |
| 137 | +* Missing or incorrect mandatory header |
| 138 | +* The pointer is a type for which your organisation does not have access |
| 139 | +* The pointer was created by a different organisation |
| 140 | + |
| 141 | +=== “Delete” example error scenarios: |
| 142 | + |
| 143 | +* Missing or incorrect mandatory headers |
| 144 | +* The pointer is created by a different organisation |
| 145 | + |
| 146 | +Please indicate which case you have chosen and provide the following: |
| 147 | + |
| 148 | +* Request body |
| 149 | +* Audit logs |
| 150 | +* Response body |
0 commit comments