Appointments

Patients Know Best (PKB) supports appointments being sent into PKB through a wide-range of services, such as:

  • HL7 integration with Patient Administration System or Trust-Integration Engine
  • e-letters from a hybrid mail solution - instead of posting an appointment letter to a patient it can automatically come into the patient's PKB record. In the near future this will also support reminders and 'read receipts'. In practice, when this is used with a solution like Synertec it can identify if an appointment sent electronically has been read and if, within a defined time period, has not been opened a physical letter can be sent as a 'back up'
  • Integration with appointment booking services, such as swiftQueue, which can manage the appointment inventory and booking rules needed at a granular level

PKB is the only solution that can act as the hub of a centralised appointment system and is a scalable and future proof solution.

More information about booking appointments and inventory management:

Centralised booking:

A centralised appointments management system for patients needs to cover primary care, hospital, community, mental health, social care and out of hours. Covering GP appointments only addresses a small percentage of the need. This is because each of the end systems have their own booking inventory, i.e. EMIS or TPP handle GP appointments, the PAS at the hospital has a different inventory, the same for each of the other providers.


Sending the appointment from all providers to a central record to display and remind patients of appointments is currently only achievable via PKB, as all other patient-facing solutions only deal with one silo of information.


Changing and amending an appointments is incredibly difficult when you move beyond primary care - each GP has the same time slot and same rules, whereas in a hospital each clinic and each professional may have different time slots, days where they are working in alternate locations seeing different issues with different rules. It gets very complicated very quickly, then to write that back to systems that are not capable of having data written to them (no two-way APIs) is challenging. This is why no supplier in the market is able to do centralised booking across multiple providers and why it has not been addressed nationally. To give concrete examples, Evergreen can do GP but not hospital, DrDoctor are able to do hospital but not GP etc.


Furthermore, once you look into some of these other solutions you find that they are able to send a few choices for an appointment but when you need to change, amend or cancel, you invariably end up speaking to someone on the phone.


Integrating with appointment booking solutions:

PKB already has, or is working on, integrations from a number of different booking system suppliers. For example, swiftQueue has an integration in place and PKB is scoping the DrDoctor system. As PKB supports single-sign on with patient context then this is a ready-now implementation.


More about GP appointment booking:

The GP appointment booking service was originally scoped during the IM1 programme in response to the last GPSoc contract 3 years ago. These were bespoke APIs to each of the four different GP provider systems, meaning four different unique integrations with GP system suppliers that did not - at that time - have any APIs. Further, these APIs are local client-side interactions, meaning they have to be locally installed and configured and updated whenever an update to each system is made. This is not practical to deploy or support at scale.


Despite this, PKB were in the IM1 programme and at the 'front of the queue' but it took over 2 years before the main system suppliers were ready to integrate - at this time NHS Digital then announced GPConnect programme and that they were "unsure" whether IM1 would continue or not, but they were sure they would not support it from a technical perspective once GPConnect was live. We took the decision not continue down the IM1 programme due to all the points raised above and that our developers would be better spent working with appointment booking companies, like swiftQueue. This decision was mirrored by all the main suppliers such as Orion, Intersystems, Graphnet, Cerner, leaving only the bespoke GP systems, such as Evergreen (formerly Paers), Blackpear and Apollo to continue on the IM1 programme.


It is our intention to scope the GPConnect programme once it has been deployed beyond test environments and once GP IT Future programme has been implemented, to see how it can be supported.


Choosing a solution that is only able to address primary care is not scalable or future-proof as you need a booking system for primary care, another for each of the other health and care providers, meaning a patient has multiple websites and logins. Solutions like Evergreen are unable to take data from multiple sources or have a professionals dashboard to interact with patients online (please see attached comparison chart).


The solution:

Phase 1: Immediately available

  1. Send your appointments to a centralised patient-owned record, e.g. PKB
  2. If a change, amendment or cancellation is required the patient goes to the secure messaging in PKB and sends a request to either a) a centralised Appointments Booking team in each organisation setup in PKB, or b) to the specific team that is offering them an appointment

Phase 2:

  1. PKB has each of the booking systems of each of provider integrate to PKB, see example here of swiftQueue here (an appointments booking service)
  2. Continue to work with NHS Digital on the GPConnect programme (see here) and liaise with them over a centralised booking service.


PKB is the only solution that can act as the hub of a centralised booking system and be a scalable and future proof solution. If NHS Digital have a centralised booking service in the long-term then PKB will ensure we work with them to incorporate this as a feature. Currently, the set-up listed above allows each provider to choose the relevant booking service provider, whether that be DrDoctor, swiftQueue or other.