Verifying Slack requests in Python

If you’re building a Slack app in Python, you’ll need to verify that the inbound callbacks you’re receiving are genuine.

This page in the Slack API docs explains the process in pseudocode: Verifying requests from Slack

Below is a Python function, based on that pseudocode, which will simply return True if the request is valid, and False if not. This has been tested using a Flask request object, but should be easily adaptable to any other web framework.

I’ve declared the secrets in code here for ease of the example, but you shouldn’t do this in real life. You should put your secrets somewhere outside of the code (e.g. environment variables) and read them from config when needed.

import hmac
import hashlib
import time
def verify_request(request):
    SIGNING_SECRET = "your_slack_signing_secret"
    # Convert your signing secret to bytes
    slack_signing_secret = bytes(SIGNING_SECRET, "utf-8")
    request_body = request.get_data().decode()
    slack_request_timestamp = request.headers["X-Slack-Request-Timestamp"]
    slack_signature = request.headers["X-Slack-Signature"]
    # Check that the request is no more than 60 seconds old
    if (int(time.time()) - int(slack_request_timestamp)) > 60:
        print("Verification failed. Request is out of date.")
        return False
    # Create a basestring by concatenating the version, the request  
      timestamp, and the request body
    basestring = f"v0:{slack_request_timestamp}:{request_body}".encode("utf-8")
    # Hash the basestring using your signing secret, take the hex digest, and prefix with the version number
    my_signature = (
        "v0=" +, basestring, hashlib.sha256).hexdigest()
    # Compare the resulting signature with the signature on the request to verify the request
    if hmac.compare_digest(my_signature, slack_signature):
        return True
        print("Verification failed. Signature invalid.")
        return False

This could also be implemented as a Python decorator (if I get a chance I’ll update this post with an example of that too).

Notes from GDS Tech Talks – Interoperability and Open Standards – 2020-02-03

These notes are just an attempt to capture some of the key points from the talks. I haven’t supplemented with anything personal so everything here should be considered my (potentially incorrect) interpretation of the speakers’ content.


“What’s new in open standards / open web” by Daniel Appelquist (@torgo), Samsung Internet & W3C

Daniel has kindly shared the link to his slides here:

Talk from Daniel Appelquist (@torgo). Dan does a number of things in open standards space; he works at Samsung Internet (android web browser with a strong focus on user privacy), and he is a member of the W3C Technical Architecture Group (TAG).

The TAG ( ponders deep questions about the design of the web, publishes findings, and helps coordinate cross-technology architecture developments.

Some of the new things coming along are:

  • Connections between the web and your device e.g. WebNFC, Web bluetooth, Web USB, Serial API, Context API(?)
  • SMS Reeceive API, Contats API, Clipboard Access API, File System APIs…

New features that make the web able to develop a richer experience:

  • Service Worker, Manifest File, Push Notifications
  • Badging API (to enable an icon on desktop / home screen to show some richer information e.g a number that is programmatically set)
  • Web Assembley
  • WebGL
  • WebXR (bringing augmented / virtual reality use cases to the web)
  • Web payment

New layout capabilities:

  • CSS Grid
  • “Houdini” APIs (the next step in extending style, enabling you to script style within the Javascript layer. “Houdini” in quotes as it’s the name of the ‘project / team’ not necessarily the official name of the APIs)

New comms capabilities:

  • WebRTC, WebSockets, Streams, Web Transport

Enhancements to Web Security:

  • Feature policy, Signed Exchanges & Packaging

Progressive Web Apps
Intended to be inherently multi-device, multi-os, multi-browser. Grew out of a movement to make sure web apps on your phone are available offline, and to have more features that people expect from applications themselves.

What makes the web ‘open’?

  • BUilt on open standards
  • Based on user needs
  • Transparent and open processs
  • Fair access
  • Royalty Free
  • Compatible with open source
  • Multiple implementations

What makes a standard open?

  • Collaborating between all interested partiens, not just individual suppliers -transparent and published decision-making process that is review by subject matter experts

Wide Review

  • The open tandarsds proces itself – call for reviews, public comemnt period….
  • Github issues in the repo where the standard is being work on
  • Discussions in browser-specific or engine-specific mailing lists (e.g. Chromium)
  • Review by vertical groups in W3C (Accessibility, Internationalisation, Privacy)
  • Review in standards groups outside W3C
  • TAG review
  • People talking on the internet

Ethical Web
How do we build things that are not only subject to strong technical and business review, but are also ethical?

Rules that we se for ourselves, encoding certain lmoral values into rules that guide conduct. e.g. The Hippocratic Oath (“Do no harm”).

Lots of examples of Tech Ethics out there:

ACM Ethics

Google AI Ethics

Mozilla Manifesto

  • should enable civil discourse, human dignity, individual expression

“The web already encodes ethics.”
e.g. Accessibility (A11Y)

  • WCAG
  • ARIA
  • Silver
    UPcoming – AOM)

Internationalization (I18N)

  • Make it possibe to use Web Tech with different languages

Privacy & Security

  • A workshop called out that “Pervasive Monitoring is a Threat to the Web” – resulted in a call to move the web to HTTPS
  • W3C Privacy & Security Questionnaire – could we adopt this for health?

Last year, Dan and Hadley Beeman worked on W3C TAG Ethical Web Principles.

Some bits from that:

“The Web Should Not Cause Harm to Society.”

There are lots of examples of this already:
– Filter bubbles
– Clik-bait
– Fake news
– Addictive behaviours

The web must support health community and debate.


  • Harassment
  • Algorithms that prioritise “engagement”
  • Content warnings

“The web should prioritise the needs of marginalised over the comfort of the priviledged”

The web is for all people.

The web must enable freedom of expression…
– …as long as it doesn’t contravene human rights
– Passive monitoring and surveillance can have a chilling effect
– Freedom of expression does not mean free speech everywhere
– Hate speech, harassment, or abuse may reasonably be denied a platform.

The web must make it possible for peple to verify the information teh see: e.g.

  • Credible web activity
  • Extensions that verify information or verify sources (Dan uses “News Guard”
  • Data journalism

Web must enhance individuals’ control and power:
Consider harmful use cases such as:

  • Stalkerware
  • IoT used by abusive partners

The web must be an environmentally sustainable platform:

The web is transparent:

  • “View source”
  • Transparency enables:
    • learning
    • research & audit
    • extensions

The web is multi-browser, multi-os, and multi-devices:

Multiple implementations help to keep the web open
People should be able to render web content as they want.

How do we apply these principles in real life?

  1. Start with web ( “A responsive website is usually the best way to build a service that will work on whatever device or browser they choose to use.
  2. Respect peoples’ privacy
    • Do you really need that info?
    • Consider GDPR
    • Don’t collect gender information unless you really need it.
  3. Use permissions-requiring features, & especially notifications, sparingly.
  4. Use the URL
  5. Test in multiple browsers
  6. Design for marginalised groups and communities
    • Tools for reporting harassment.
    • Features that discourage negative behaviours
    • Features that encourage good behaviours:
      • Content warnings
      • Text descriptions
  7. Respect humans and their choices
    • Let people delete their accounts
    • Dont fingerprint people (or their browsers)
  8. Get involved in web standards
  9. Join a discussion on a new technology / standard proposal

“Intro to OpenAPI” by Lorna Mitchel (@lornajane), Nexmo

APIs are the enginer of modern software development. API descriptions power up our API workflows.

Spec-first API Design

Who writes API specs?

<some missed notes>

Having tech writers on the team makes a massive difference. Tech writers have to be incredibly sharp and concise.

Should I write API descriptions for my existing APIs?

Yes – retrofitting can be painful, but helps highlight places where you’re making mistakes you shouldn’t be in your existing APIs.

API Description Languages

There are some proprietary API description languages e.g. API Blueprint (from Apiary) and RAML from Mulesoft.

OpenAPI ( is an open standard (formerly known as “Swagger”).

<Lorna did a walkthrough of an OpenAPI specification example which I didn’t attempt to note>

API descriptions are not just important for understanding your APIs, they are going to enable your users to discover your APIs.

OpenAPI allows you to define components once, and refer back to them from multiple endpoints within the API specification.

How do you edit OpenAPI specs

They are just text-based specs, so you can use your text editor. Lorna uses Atom with a plugin (possibly still called “Swagger”).

Stoplight Studio is a free-to-use IDE for working with OpenAPI specs. There is a desktop and web-based version.

Spectral Linting tool lets you lint your OpenAPI specs using pre-defined rules

What can you do now?

Generate Documentation – use your OpenAPI spec as the source for your API reference documentation

  • There are a choice of tools you can use to do this
  • The content and presentation of your documentation is completely separate
  • The OpenAPI spec has support for examples which is great for enhancing your documentation

Redoc is a documentation-generator that builds from OpenAPI specs

Postman ( lets you import the OpenAPI spec into a Collection, with requests already set up for you to easily create requests to support debugging etc.

Prism lets you turn an OpenAPI spec into an API server

(The OpenAPI spec has recently had Webhooks support added – will be in the 3.1 release. Lorna expects Prism to support this pretty quickly.)

Code Generation – OpenAPI Generator – lets you take an OpenAPI specification and generate lightweight API wrapper client code in your chosen language. It’s a quick way to create sample client code for your APIs.

Finding OpenAPI Tools – a community listing of OpenAPI tools – you can submit contributions and additions.

What lessons has OpenAPI learned from WSDL and SOAP?

  • The ability to quickstart developers – SOAP provides the WSDL that developers could just feed into their dev stack and automate lots of the work. OpenAPI is building on this concept, but adding lots of new stuff.

Why haven’t you mentioned Swagger?

Swagger is more than one thing. It is a tradename for the toolset from which the OpenAPI was specification emerged. Formerly, the specification standard was called ‘Swagger’ – this was then renamed to OpenAPI 2.0.

Swagger ( still provide tools for working with APIs, and their tools support the OpenAPI specification.

Does OpenAPI handle GraphQL?

Not really – OpenAPI is really REST-ish. If you’re working with GraphQL, then you’re best off using the tools that are provided for that.

OpenAPI isn’t necessarily aiming to converge with GraphQL world, as it’s not a great fit in terms of paradigm.

Does OpenAPI make recommendations on where the descriptions should be hosted?

There are no official recommendations on where you should host the descriptions (as in which path to host the documentation on). Lorna feels like OpenAPI probably wouldn’t recommend hosting your descriptions on the API paths themselves.

“API First for the humans and the machines” by Kin Lane (@kinlane), Postman

Going to talk a bit more about the governance around API development.

It’s important to set the stage when talking about APIs – Kin focuses on web APIs (as opposed to browser APIs, hardware APIs etc.)

The latest wave of web APIs was set into motion by eCommerce giants like Amazon, Ebay etc.

Following that, startups began seeing APIs being more than just about ecommerce, but about social interactions.

In 2006, a big step was when Amazon realised you could deliver infrastructure using APIs.

Why are we doing web APIs?

Originally, the commerce giants had data that they needed to make available to people on the web. APIs were being used to publish and syndicate content to websites. APIs allowed you to publish the data to websites, mobile applications directly fro the data source.

We also saw the creation of widgets, allowing people to take that data and make it available embedded within other websites.

Data needed sharing to trusted partners, e.g. sharing water utility data across the US.

With mobile phones taking hold, people realised APIs could be used to drive sensors, and other data sources connecting everyday items to the internet.

API Development Lifecycles

An API lifecycle can take an average of 3-12 months to deliver each version of an API, using a code-first approach. It can take that long to put something out there, get feedback from the people who will use it, and then iterate on it.

The introduction of tools like Apiary (Kin largely credits them with being first) allowed people to design, refine, document, and iterate their API designs without writing any code. Processes that would take years could take months or even days.

Postman is an API platform, with the majority of usage being using it as an HTTP client. it has evolved along the way, with much more functionality being added to it. Today you can use it to actually design your API.

<Kin gave a walkthrough of designing an API using Postman>

Demonstrated creating a new API Path in Postman, and then added a JSON example to the request. You can then create a Mock API, which gives you a published Mock API URL, which returns the example JSON response you added. The response could be something other than JSON: it could be YAML, or CSV etc.

As Lorna demonstrated with Stoplight, Postman can create documentation for sharing with users. As Lorna also demonstrated, you can import OpenAPI specifications into Postman. A new feature also lets you add two-way sync with the git repository containing your OpenAPI specification.

This integration gives a lot of flexibility around how users can work with your APIs. You can either build entirely within Postman, or plug into an existing API dev lifecycle – potentially allowing different members of your team to use different tools e.g. you could be using Postman, whilst others are using Stoplight tools.

Letting developers build against your mock APIs

Having Mock APIs let’s people start to design the things that are going to interact with those APIs. e.g. mocking your mobile apps, your display widgets

The advantage of getting people doing this very quickly is that you start getting feedback on the API design, and you can feed this back into your API design really quickly.

It allows your API users to help define the API tests that are used to validate each API response. Having users involved in the design, allows you to create API contracts by applying API tests that everyone contributes to.

Deploying your API

Once your API is ready it can be deployed using a gateway or other approach. There are some services which can take an OpenAPI specification and set up your management layer – although almost all require you to wire up the endpoints to the data layer behind.

API Management

  • All APIs should have a management layer.
  • All should have security, rate limits, analytics. API management is what will protect you if there are issues. There are many API management options out there now.


All APIs should be clearly documented.


  • Monitor from different regions around the world.
    • Your monitors can have issues, you need to build in monitoring resilience.


  • Make sure API tests are avaialble to be run manually against the API.
  • API tests should also be available to be run as part of a CI/CD pipeline (automated tests)


Ensure security – You should use OWASP, and associated tools, to make sure you are covering common security guidelines and avoiding common security vulnerabilites.


You need to make sure that there is a strategy for APIs to have owners and support avaialble.


Every API should be announced. There should internal and external communications around every API release. All developers should have to step up and be part of that communications strategy. They need to be able to communicate the value and detail of the API releases.


“Leveraging all of the outputs from API operations to ensure all APIs are observable and seen by stakeholders.”


Establishing governance of design, mocks, docs, tests, and all other parts of the API life cycle.

How do you define what API design should look like?

Make all teams move to an API-first strategy. It forces team to be having conversations early on.

You should have a documented approach to how you govern your APIs.

“Governance wraps up the full life cycle, and allows teams to understand how they should be building and operating APIs.”


Mainstream companies are getting more organised about how they deliver APIs, establishing common approaches to delivering APIs across their teams.

Working with government

APIs can be an answer to departments hoarding data for ‘power’. They also affect the politics though. For example, gov departments might be paid to hold the ‘authoritative list’ of something, so unsurprisingly there are multiple ‘authoritative lists’.

APIs can tackle the data silos, and enable better cooperation between gov departments.

API Advocacy

The most important tools we have are evangelism and advocacy for API-first approaches. It’s important to tell stories of what’s going on, and to help developers (and others) understands the human effects and benefits of APIs. It’s important to be able to articulate the human aspect of APIs – not just the technical. We need the conversations to focus on the real-life stories.


Continued storytelling is important to keep API approaches alive, to educate new champions and advocates, to keep up the momentum. Stories are all that matter – communicating the impact we make on our environment, our children, our veterans etc.

The Zen of Interoperability

I was having a discussion with a colleague this week about architectural options for some specific interoperability use cases we are tackling.

The conversation touched on implementation choice – how much flexibility should there be in how to approach specific interoperability use cases within the NHS?

I’ve thought about this quite a bit, and struggled with the complexity that “many ways to do the same thing” can introduce. I naturally found myself quoting PEP 20 — The Zen of Python |


There should be one — and preferably only one — obvious way to do it.

Could this be a reasonable principle for us to take with NHS interoperability?

I wonder if there is a place for “The Zen of NHS Interoperability” – to define some guiding principles for all of us working hard to make interoperability useful for the NHS.

Here is a slightly tongue-in-cheek attempt at a “Zen of NHS Interoperability” 🙂

The Zen of Interoperability

Elegant is better than messy.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Open is better than controlled.
But controlled is better than proprietary.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you designed it.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Clear Standards are one honking great idea -- let's have more of those!

Appointment booking in Urgent Care


This is a collection of my thoughts about the challenge of improving appointment booking within the urgent and emergency care sector. It has a fairly technical focus and may well lack context for people not so familiar with the field.

I also want to explicitly acknowledge that this post does not examine user needs in detail as it was originally intended to support technical consideration – it doesn’t replace or negate the need for properly understanding the needs of users both professional (within the NHS) and public (users of the NHS).

Some background

Out of hours care has always had the concept of appointment booking for patients that need contact with a clinician from an out of hours service – this could be a face-to-face appointment at a local out of hours centre, or an appointment for a telephone consultation with a clinician (although this tended to happen less).

Prior to the introduction of NHS 111, out of hours care was generally provided locally (i.e. a patient would contact an out of hours service local to their area), and so booking of appointments was handled internally within the same organisation or with local arrangements between specific nearby services.  In the majority of cases the transactions would all happen within the same IT system.

NHS Direct was a service that operated at national scale, but they did not offer appointments for patients; you would either receive a callback from a nurse, or NHS Direct would pass your details through to your local out of hours service which would then make contact with you.

With the introduction of NHS 111 in 2013, urgent care in England moved to a ‘national service delivered locally’ model. This model made use of national telephony infrastructure to route telephone calls to 111 through to different call centres around the country. In the vast majority of cases, 95% of 111 calls would be routed to a NHS 111 call centre close to the location of the caller using either an approximation of the landline location, or an approximation of a mobile phone using mobile mast triangulation.

Call demand on NHS 111 is incredibly ‘peaky’ – you can see this from the openly available monthly datasets that are published by NHS England. Particularly busy times for urgent & emergency care are long weekends (e.g. bank holidays), Easter, and Christmas / New Year – this is a well understood demand pattern in the NHS.

The challenging aspect of these few ‘super peaks’, however, is that they are several order of magnitudes larger that the regular weekly peaks (which general happen on Saturday mornings around 09:00 to 11:00). In terms of managing and planning for demand, this poses an immense challenge for services for whom simply ‘getting all of your staff in’ isn’t guaranteed to cover it.

An advantage of the national telephony approach is that it allows NHS 111 to distribute incoming calls flexibly across the country – this provides significant contingency for a range of situations (be it a particularly high demand in a particular region, or maybe a significant incident inhibiting the ability of a particular region to handle the local demand).

How does this relate to appointment booking though?

One impact of moving to the national service model is that it introduced a separation between the services handling telephone calls, and the services providing the appointment-based care to patients; in most situations this means separate IT systems are used too.

NHS 111 has been making good use of nationally-standard interoperability since its inception – this allows services to provide safe clinical handover of a patient between services (i.e. an NHS 111 service handing a patient over to an out of hours service so that they can provide further clinical care), however to this date there is no national standard defined for appointment transactions.

The supplier market responded to the gap by building appointment booking interoperability solutions for their customers which augmented the existing nationally-defined clinical handover interoperability – these solutions fill an important gap and several years on these solutions are used fairly widely both within the urgent care sector (e.g. between NHS 111 call centres and other urgent care services) and more recently between urgent care and general practice (GP surgeries).

Existing capabilities

The existing proprietary solutions are already becoming more widely deployed, and will continue to be deployed more and more as the urgent care system moves towards its aspiration of facilitating appointment booking into services for all patients (see the Next Steps on the Five Year Forward View or my precis of the urgent care specific elements of the FYFV). Given the relatively short timescale of the FYFV aspirations, and the fact that we don’t yet have a broad enough, nationally-defined standard for appointment booking interoperability using proprietary solutions in the short term remains a valid option.

There are some limitations to the existing proprietary solutions, and there is a common list of issues and gaps that service providers have started to identify. Some of the limitations are with the implementations themselves often relating to them being specific to individual IT systems (this is understandable in where solutions have been driven by the competitive market and have grown organically), other issues are related to the fact that there is some coordination needed across different services and regions which cannot realistically be provided by market-led proprietary point solutions.

Implementation of proprietary solutions could also increase the implementation cost in the long-run as it generally involves licensing on usage which attracts a cost to the users. There is also a coordination overhead that comes with the rollout of any proprietary point solutions. Having said that, the ROI is still considered to be favourable for investing in these existing capabilities in order to move interoperability between services on from where it is now.

Existing interfaces generally provide the ability to query slots of a destination service, pick an empty slot for a patient, and book an appointment into that slot. In some cases it is possible to change or cancel that appointment whilst still within the initial booking journey. Some systems have integrated the appointment booking transaction into the wider urgent care workflow, linking the appointment directly to the clinical handover (using the CDA documents that are sent between services). The official Integrated Urgent Care CDA messages have a section that allows systems to embed appointment reference details for the purpose of linking up with appointments within their system. There is a mixture of business rules applied by the various systems involved that guide how appointments can / can’t be booked, and what data items are required to do so. Some suppliers have attempted to build on top of existing proprietary solutions to avoid further divergence but this does mean building on top of existing limitations as well.

The biggest gaps are currently:

a) a lack of clearly defined appointment booking workflow that can be applied consistently across all services

b) a lack of an appointment repository / index that allows services to easily find out if and where a patient already has an appointment booked

c) a lack of business rules around how appointment booking should be handled when happening across regional borders (introduces financial, political, and accountability challenges)

So what comes next?

System suppliers and service providers alike have asked for standardisation of the appointment booking specification for urgent care and emergency care (note specification covers both an API specification and the associated business processes that support it).

There are a number of benefits from standardising the specification:

  • it will reduce the implementation cost for both system suppliers and service providers through use of configuration over installation, and less variability related to the IT systems in use;
  • it will introduce consistency of workflow across services and therefore ultimately improve consistency of experience for the users of the services (i.e. patients)

What about the existing systems like eRS and GP Connect?

System suppliers have been very clear that in order to realise the benefits of standardising the interoperability for appointment booking it is important that we don’t simply introduce YAAS (yet another appointments system). In particular alignment with the existing GP Connect work is preferred.

The key is in the user needs and the fact that nothing exists currently to meet all of the user needs in urgent and emergency care.

A drastic over-simplification of the use cases in urgent and emergency care appointment booking is:

  1. An urgent / emergency care service booking an appointment into general practice (a patient’s GP surgery)
  2. An urgent / emergency care service booking an appointment into another urgent / emergency care service

GP Connect is currently focused on enabling the first of these: booking an appointment into general practice (and specifically only the IT system suppliers that are part of the national GPSoC framework) – it therefore could help to meet some of our user needs in urgent and emergency care, but not all of them.

The e-Referrals Service (eRS) (formerly known as Choose and Book) currently targets a different set of needs: primarily referral from primary care into elective care* services (e.g. your GP referring you to a specialist in a hospital). The sort of workflows that support eRS use cases are quite different to what we need in urgent and emergency care with a key example being the respective definitions of an urgent appointment: in elective care this means 2 weeks, in urgent & emergency care this might mean within 1 hour.

In both cases there are IT systems in urgent and emergency care that do not already have integration with either GP Connect or eRS. This does not mean that neither can be of use, but it does mean that neither can provide what is needed in the current form.

Some specifics

The following notes were made whilst summarising some key characteristics of appointment booking in urgent & emergency care – they are highly likely missing context and are not exhaustive…

Appointment types (e.g. routine, urgent, 1 slot 1 patient, 1 slot many patients, not date/time bound, etc.)

Urgent care appointments are generally specific time-based slots i.e. come to x place at 20:30. In most cases a single patient will be booked into a single as would happen at a GP surgery, but busier or higher acuity services may utilise group slots i.e. come to x place at 16:00 and you will be seen around that time – this helps manage high demand and the general challenge of keeping to specific appointment times in dynamic services such as healthcare.

The urgency of an appointment tends to be denoted by the ‘disposition’ – a term which represents the concept of a timeframe within which the patient needs to be seen (e.g. must be seen within 6 hours) combined with the general type of care the patient requires (e.g. see a clinician, see a dentist, see a pharmacist). When a disposition is derived for a patient the ‘timer is started’ with regards to the timeframe.

As mentioned above, there will be variety in the types of appointment patients require e.g. it might be with a mental health specialist, with a nurse, they might need a clinician who specifically can prescribe medication, they might need to see an emergency dentist.

There is a mixed model of how this is provided: some service providers will supply several types of appointment, whereas other specialist providers might only supply one type (e.g. an emergency dental provider might only supply emergency dental appointments).

Slot management (publishing, synchronisation, ownership, etc.)

All existing models within urgent care use real-time slot queries to get availability of appointments. At the busiest periods even this can result in appointments becoming unavailable between the initial search and confirming it with the patient – this is not unlike the high-demand ticket-booking scenario. Demand on services can fluctuate rapidly, and services maintain the ultimate control over the appointments they are making available; it is not unheard of for a service to remove some availability when they see an influx of patients to prevent running over-capacity.

Ultimately the services providing the slots have ownership over what they do and don’t make available – there are some political complications if the service providers are contracted to provide a certain number of appointments for instance, but this is a separate detail.

Services will sometimes make slots available for certain types of patient, and have to manage their slot allocation carefully so as to avoid using all slots within the first hour of opening – they have an obligation to continue to provide a service during the out of hours period and so they have to apply demand predictions and spread their slot availability out. This can be done by restricting certain slots for patients with certain clinical urgency, and spreading these through the schedule (e.g. reserve a % of slots every hour that can only be booked into for patients with a urgency of < 1 hour). Another method of controlling demand is to use the disposition timeframe to filter the time range for appointments e.g. if a patient needs to be seen within 6 hours, don’t show slots sooner than 2 hours away. Obviously some serious thought has to be put into how this is all filtered and as to how they make sure they are providing an acceptable service for patients.

Who can do what? (professionals and patients)

Patients do not currently have any access to their own appointment information in urgent care, and there is no existing facility for patients to book appointments directly without first speaking to a member of staff within a service such as NHS 111.

The permission to book appointments does not tend to be restricted at an individual user level – at this point in time it is more about inter-organisational agreements i.e. can X NHS 111 call centre appointments into Y urgent treatment centre.

Generally if someone is able to deal with a patient on the phone, they will be able to take the patient through the full journey including booking them an appointment at another service. On a technical level, API authentication tends to happen at the organisational level with the authentication and authorisation of individual users remaining the responsibility of the respective systems – it is rare that Jackie Jones from Townsville NHS 111 call centre is specifically given authorised to book an appointment into Townsville Urgent Treatment Centre.

Slot mapping/semantics (e.g. slot = service, or slot = care role, or slot = name clinician, etc.)

This varies depending on the scheduling models that systems implement, and to a certain extent does it matter? Ultimately, though, slots are made available by services, and may be restricted by the type of care provided and restricted by certain patient criteria i.e. only patients who have received a certain disposition can book this slot.

There is no significant precedence of slots being at named clinician level within urgent care as staff are much more ephemeral than in other services, and encounters with urgent care by definition are not the start of an ongoing long-term relationship between the patient and service.

Managing appointments (booking, cancelling, rescheduling, recording attendance, etc.)

Proprietary solutions currently provide Book and limited Cancel / Reschedule functionality.

Cancel / Reschedule is limited because this can only really be done during the initial call with the patient i.e. if the patient changes their mind before the telephone call is completed.

None of the existing proprietary solutions support Cancel / Reschedule after the initial call has completed, and this is one of the big workflow challenges for us: how do we identify that an appointment has previously been booked for a patient if they are to call back to NHS 111 at some point after their original call. In particular considering the notes above regarding distribution of telephone calls nationally there is no guarantee that a patient will speak to the same call centre, let alone same operator, if they call back to NHS 111.

Any national approach will need to provide interoperability and operational workflows that support these missing bits.

Access to the booking system(s)

Patients do not currently have access to the appointment booking systems in urgent care.

Existing proprietary interoperability is all system-to-system  – there are no publicly-available or open APIs for third-parties to easily consume.

Monitoring/Analytics/Reporting (e.g. DNAs, unused slots, etc.)

All handled locally by system, nothing centralised at the moment. Being able to look at how appointments are utilised across the urgent care system would be a good thing to tackle, providing it isn’t at the expense of the patient experience and operational workflows.

From a data perspective, it should be possible to get decent activity information about appointment booking without requiring patient-identifiable data – this will need looking at in more detail.


* Elective care is pre-arranged, non-emergency care, including scheduled operations. It is provided by medical specialists in a hospital or another care setting. You will usually be referred by your GP.