WARNING
This guidance is under active development by NHS England and content may be added or updated on a regular basis.Scenario - Request Access and Create a Relationship
Actors
| Name | Type | Description |
|---|---|---|
| Client Application | System | The application the Proxy uses to create the request |
| NHS England Proxy Service | System | NHS England National Proxy Service |
| NHS England Proxy Repository | System | NHS England National Proxy Data Repository |
| Primary Care | System | General Practice System |
Use Case(s)
Request Access and Create a Relationship Workflow
The sequence diagram below is a high level view of the actual process which focuses on the interactions exchanged between the actors.
Send Proxy Access Request
The Client Application creates a FHIR QuestionnaireResponse which matches the FHIR Questionnaire definition Proxy Access Request.
This request is then submitted to the national proxy service via FHIR RESTful API
POST https://proxyservice.example.nhs.uk/FHIR/R4/QuestionnaireReponse
Event Payload Example
Request Consent Verification
Once the proxy request has been processed, the patient's GP can be asked to verify the relationship and proxy access request. In the FHIR Task the status is requested, asking for consent in the code element.A reference to the original request is supplied in the focus element, this can be used to retrieve the original request (the FHIR QuestionnaireResponse).
The request starts a series of interactions following a conversation pattern where the national proxy service and primary care exchange FHIR Task resources. Normally at each exchange, the status of the Task changes to reflect the current status of the workflow, see also FHIR Task State Machine.
FHIR RESTful API is used in the examples below, other event notification methods may be used instead.
POST https://primarycare.example.nhs.uk/FHIR/R4/Task
Event Payload Example
Accept Consent Verification
On receiving the request, the GP system should respond back to the national proxy service with either an accepted or rejected. In the example below, the status has been changed to accepted. For a rejected example see Task Consent Verification Rejected where the status is now rejected and a note has been added to indicate the rejection reason (e.g. patient not registered).
PUT https://proxyservice.example.nhs.uk/FHIR/R4/Task?identifier={identifier}
Event Payload Example
Complete Consent Verification
After the request has been accepted, the request should be actioned. Once actioned the decision should be sent back to the National Proxy with a status of completed. The decision is sent in the output element.
PUT https://proxyservice.example.nhs.uk/FHIR/R4/Task?identifier={identifier}
Event Payload Example
Inform Proxy of Decision
This has not been defined and so is an example of a notification which is a copy of the completed Task resource.
PUT https://clientapplication.example.nhs.uk/FHIR/R4/Task?identifier={identifier}
Event Payload Example
Reject Consent Verification
This is not a rejection of the proxy request but a rejection of the workflow task to Verify the Consent.
This may result in action being taken by the National Proxy Service which may result in the request being corrected and re-requested or sent to another GP Surgery.
PUT https://proxyservice.example.nhs.uk/FHIR/R4/Task?identifier={identifier}