Example scenario
Services on the DoS are profiled with a range of data that is used to determine the ranking for services. There are also additional data items that are used for other purposes, for example interoperability. Examples of these data items are as follows:
- Geographical information such as address and search etc..
- Demographic profile of patients the service is available for
- The comissioning footprint of the service, for example
- GP Practices that patients have to be registered to in order to use the service
- The clinical needs that the service will meet, for example:
- symptoms
- timeframes
- Referal endpoint information, for example:
- URLs
- Document format
The key aspect for direct booking is how a specific service will relate to a CareConnect Schedule resource on a particular system.
Please note that in the example below, many irrelevent details are simplified or skipped. Also the technical details of the API messaging interactions are omitted. This is explained in detail here.
For this example, consider a UTC provider called “UTC Service Ltd.”. This provider has been comissioned in a comissioning area to deliver Urgent Treatment Centre services. UTC Service Ltd. operates this service from within the Accident and Emergency department at the Hospital.
UTC Service Ltd. deliver their services from a single IT Platform, known as “Another ED System (ANEDS)”.
| Provider Name | Provider ODS Code | IT System |
|---|---|---|
| UTC Service Ltd. | AB1234 | ANEDS |
The UTC offers three different clinics. Each of the three clinics has its own appointment diary represented as a schedule in ANEDS. Clinic 1 is a GP diary, Clinic 2 offers GP and Nurse appointments and Clinic 3 has just a Nurse diary:
The important thing here is how the DoS services link through the the appointment schedule. The below table describes the location configuration on the IT system. Note that each provider system instance has a unique identifier, this ID is what is known as an accredited system identifier (ASID) and is created when an endpoint is configured on the Spine Directory Service (SDS):
| ID | Location Name | ODS Code | Schedule | Appointment Type | ASID |
|---|---|---|---|---|---|
| 1 | Clinic 1 | AB1234 | 1 | GP | ASID:109876543210 |
| 1 | Clinic 1 | AB1234 | 2 | Nurse | ASID:109876543210 |
| 2 | Clinic 2 | AB1234 | 3 | Nurse | ASID:109876543210 |
| 3 | Clinic 3 | AB1234 | 4 | Nurse | ASID:109876543210 |
The table below shows key information about the associated DoS services and the ASID defined against each service:
| Service Type | DoS ID | Service Name | Service ODS Code | ASID |
|---|---|---|---|---|
| UTC | 123456 | The UTC - GP Clinic | AB1234 | ASID:109876543210 |
| UTC | 654321 | The UTC - Nurse Clinic 1 | 654321 | ASID:109876543210 |
| UTC | 123457 | The UTC - Nurse Clinic 2 | 123457 | ASID:109876543210 |
| UTC | 123458 | The UTC - Nurse Clinic 3 | 123458 | ASID:109876543210 |
From this information we can see that each DoS service has a 1:1 relationship with appointment schedules through the DoS service ID. This identifier needs to be specified on the appointment provider system and gets set against the corresponding service on the DoS. As can be seen this means that each location (and even each appointment type) has its own DoS service. Since ODS code is not relevent to the booking process here it means that the location and slot ambiguity caused by the brittle relationship between ODS code, the service, its locations and schedules is removed.
The following digram illustrates with a typical return from the DoS, the relationship of DoS services to appointment schedules.
Once all the above is understood we can walk through a typical booking scenario using this example service.
Booking scenario walk-through
- A patient dials 111 on their phone and gets through to their local 111 service.
- The health advisor takes them through an NHS Pathways assessment and they get referred to the Clinical Assessment Service (CAS) to speak to a clinician.
- The clinician assesses the patient and determines that the patient requires an urgent appointment with a GP.
- The 111 IT system searches the DoS with the details of the patient and the assessment
- The DoS returns a ranked list of services. The top service is the service named “The UTC - GP Clinic”
- This service is selected and information on the referral and booking endpoints is returned including the ASID
- Next the 111 system will use the ASID to retreive the correct booking API endpoint from the endpoint registry. In this scenario, since the target system is all the same, the returned URL’s will all be the same. However since the DoS Service ID gets included in the query parameters, ANEDS can filter the slots returned appropriately.
- A request will be made by the 111 system to the appointment provider IT system to retreive all available and appropriate slots from the GP Diary at “UTC - Clinic 1”