Interactions with the DoS

Introduction

The Urgent Care Directory of Services (known as the “DoS”) is the primary service discovery and information tool available to the NHS. Although this standard does support booking workflows that do not need to use the DoS it is envisaged that it will provide the service discovery element in the majority of booking workflows that use this standard.

Therefore it is important to understand how the DoS will interact with these booking workflows. At a very high level there are four key elements in the booking sequence. These are:

• Service discovery
• End point discovery
• Slot discovery
• Booking a slot

Understanding how these steps interact with each other is essential, especially when booking into more complex services. For exmaple the way the profiling of the DoS service is tied to the schedules on a provider system. In order to understand these interactions better we shall walk through an example.

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 servie will meet, for example:
  • symptoms
  • timeframes
• Referal endpoint information, for example:
  • URL’s
  • Document format

The aspect of that is key for direct booking is how a specific service will relate to a CareConect Schedule resource on a particular system.

Please note that in the example below, many irrelevent details are simplefied or skipped. Also the technical details of the API messaging interactions are omitted. This is explained in detail here.

For this example, consider a GP Federataion provider called “GP Federations Ltd.”. This provider has been comissioned by the GP Practices in a comissioning area to deliver the extended access GP services on behalf of these GP Practices. GP Federations Ltd. operates this service from three different locations, these are consulting rooms in three of the GP Practices they are covering.

GP Federation Ltd. deliver their services from a single IT Platform, known as “Another GP System (ANGPS)”.

Each of the three locations has its own appointment diary represented as a schedule in ANGPS. Location 1 has two diaries, a GP diary like the other two and a Nurse diary also:

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 schedule has a unique HealthcareServicesID:

The table below shows key information about the associated DoS services and the HealthcareServicesID defined against each service, Note that each service has its own unique HealthcareServiceID:

From this information we can see that each DoS service has a 1:1 relationship with appointment schedules through the HealthcareServiceID. This identifier needs to be specificied on the appointment provider system and 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 locational and slot ambiguity caused by the brittle relationship between ODS code, the service, its locations and schedules is removed.

The following digram illustrates 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-though

1. a patient dials 111 on their phone and gets through to their local 111 service.
2. The health advisor takes them through an NHS Pathways assessment and they get referred to the Clinical Assessment Service (CAS) in the 111 to speak to a clinician.
3. The clinician assesses them and determines that they require an urgent appointment with a GP.
4. The 111 IT system searches the DoS with the details of the patient and the assessment
5. The DoS returns a ranked list of services. The top service is the service named “GP Hub - Main location GP”
6. This service is selected and information on the referral and booking endpoints is returned including the HealthcareServiceID
7. Next the 111 system will use the HealthcareServiceID to retreive the correct booking API endpoint from the endpoint registry
8. 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 “GP Hub - Main location GP”

Key Requirements

For the three key actors in this process there are the following key requirments:

• The appointment consumer (111 system in the example above):
  • MUST be able to retreive the HealthcareServiceID from the DoS endpoint details
  • MUST ensure that the booking functionality invoked is compliant with the national standards when a booking endpoint (HealthcareServiceID) is returned by the DoS GetServiceDetailsByID API call
  • MUST ensure that if no booking endpoint is returned by the GetServiceDetailsByID API call that any proprietary booking mechanisms are then tried and still work
• The DoS:
  • MUST be able to store the HealthcareServiceID
  • MUST return a booking endpoint (HealthcareServiceID) in response to a GetServiceDetailsByID API call
• The appointment provider (GP Federation system in the example above):
  • MUST allow association of a booking diary with a HealthcareServiceID
  • MUST ensure that two different diaries cannot be associated with the same HealthcareServiceID UNLESS there is a clear use case for slots from multiple schedules to be returned in one schedule bundle and therefore be considered by a booking consumer as one diary.