PKB offers an Appointment Management capability in our UI, allowing a patient to securely message a team in the PKB organisation to say they wish to Cancel or Amend an appointment. This message then has to be read and acted upon by someone at the organisation.

These secure messages and the associated appointment information can be extracted via API, enabling the organisation to have more control over how requests are handled. For example, organisations can:

• Route requests to specific individuals or teams

• Create their own dashboards to handle the requests

• Build their own reports to monitor the volume of requests per specialty over time

1. PKB organisation enables Appointment Management capability.

2. The organisation sends appointments into PKB patient records (via HL7 or FHIR).

3. Patients send secure messages to request to amend/cancel appointments.

4. A clinician at the organisation “Grants Access” to enable the required data to be extracted.

5. The organisation uses PKB’s APIs to:

   1. extract the secure message requests

   2. extract the appointment details

6. The organisation displays the extracted information to the appropriate appointment management team.

7. The appointment management team actions the patient requests within their own appointment system.

8. The organisation sends the updated appointment information to PKB (via HL7 or FHIR).

This workflow uses a combination of custom REST APIs and our Aggregated FHIR API.

1. A clinician who has access to the cancel / rebook messages sent by patients grants access to their PKB record.

   1. Access is granted to the credentials that PKB provides to the organisation for use with the PKB APIs.

2. The resulting authorization code is exchanged for an access and refresh token pair.  

   1. Tokens will be managed and maintained by the customer to ensure the authorization is only done once.  

   2. A corrective workflow is required to obtain a new authorization code in the event a session breaks / expires.

Here is an example of a patient using this process, with links out to the key parts of our wiki.  The clinician follows the same steps, only the scope is changed to CLINICIAN.

1. Using a valid access token, retrieve the user’s messages in PKB, specifying which messages to return by supplying a specific timestamp as a parameter.

2. Within the response, there are a few key elements to be aware of:

   1. The “subject” has the type of request (change or cancel) and the date, time, and appointment’s subject (from the HL7 feed) of the appointment.  You’ll need this to match to the appointment information from the aggregated endpoint.

   2. The “content” has the note that the patient added when making the request to change or cancel. 

   3. The “patientId” is the PKB id of the patient.  You’ll need this to obtain the patient’s national identifier.

1. Using a valid access token, and the PKB patientId from the message, get the national identifier for the patient.

2. Call /json/v1/users/{userId}

1. Obtain an access token for the Aggregated FHIR endpoint.  Instructions here.

2. Search the Aggregated endpoint for the patient’s appointment.  

   1. You must include the patient’s NHS number (or PKB public id) in the search.

   2. We support FHIR search parameters so you can use any other supported search parameter that would be helpful to identify the appointment.

   3. If you use the “status” search parameter with a value of “pending” that will bring back only the appointments that have been requested to be changed/cancelled.

3. Your appointment id from the HL7 message is stored within the Appointment resource in the “identifier” element, with the system of: “http://fhir.patientsknowbest.com/id/external-identifier”

Using the information obtained above (appointment id and message content), the team at the trust amends the appointment.  The resulting change flows into PKB via the existing appointment feed.