What is ITK?

The acronym ‘ITK’ gets used a lot within the healthcare technology world.

It stands for Interoperability Toolkit, and the official NHS Digital page about ITK can be found at (https://digital.nhs.uk/interoperability-toolkit)

What is ITK?

The Interoperability Toolkit (ITK) is a set of common specifications, frameworks and implementation guides that support interoperability.

It is essentially an umbrella term / brand name.

What isn’t ITK?

ITK is not a specific specification or standard. It is not a ‘badge’ that is issued to system suppliers.

A system with ‘ITK interfaces’ or ‘ITK support’ does not necessarily have the ability to talk to other systems with ‘ITK interfaces’ – it depends completely on which of the ITK specifications or standards the system provider has implemented.

When system providers have developed their product to support ITK specifications and standards, they can go through an accreditation process to have this formally tested and recognised by NHS Digital.

If a system provider tells you that the system supports ‘ITK’ you should ask for precise detail on which elements of ITK they support.

What is ITK accreditation?

Also known as ‘ITK conformance’, a system provider being issued with ITK accreditation means that they have implemented against at least one of the specifications within the ITK collection.

An ITK Conformance certificate is issued to a system provider upon completion of the accreditation process – it means that NHS Digital are satisified that the system meets the requirements in the specification you have chosen to support.

Note: You do not require ITK accreditation in order to start development – it is issued right at the end of the development process.

NHS Digital maintains an online catalogue of suppliers who have been formally accredited as ‘ITK Conformant’ – if the supplier is not in this list, it means they have not been issued with an ITK accreditation by the NHS Digital ITK team.

You will notice that the catalogue specifically lists the Catalogue category and System type against which a system provider has been issued accreditation.

As a purchaser / user of systems this is the most important part of the cataloge – it will tell you exactly which capability a system provider can support.

For example, a supplier listed under the Catalogue category of “Hospital Admission, Discharge and Transfers” can’t necessarily communicate with a system under the category of “NHS 111”.

The cataloge also lists the System Version ID against which an accreditation has been issued. This means that in order for you to make use of the ITK functionality, your system will need to be on that minimum version; it is often the case that all versions after the one listed will continue to support the functionality but you should always ask your the system provider about this.

What is the process for ITK accreditation / conformance?

The ITK team at NHS Digital will guide you through the process, and so you should enage with that team as early in the process as possible. You need to know which of the ITK specifications you would like to develop against, as the requirements can vary significantly, and the exact process may involve different teams and additional business requirements.

You can find more details about initiating contact with the ITK team here: (https://developer.nhs.uk/testcentre/itk-accreditation/)

A a system provider, an overview of the process is:

  1. You identify the ITK specifications against which they would like to develop your software.
  2. You make contact with ITK Accreditation team at NHS Digital to initiate the process.
  3. You download the relevant technical specifications to support the specific technical capability you are building against.

    Most specifications can be found on the TRUD (Terminology and Reference data Update Distribution) portal – you will have to sign up for an account, but this is free.

    You will also need to download the development support tools that are provided to help you with the process.

    You should ask the ITK team for guidance on which specifications and tools you need to use if in doubt.

  4. Once accepted into the process, the ITK team will issue you with a tailored “requirements catalogue” – it will list all of the documented functional and non-functional requirements you need to meet. It will also detail any tests you need to complete as part of the process.

  5. As you develop your product, you should complete the requirements catalogue and try and use the specified tests as a guide for your development. Many leave the compliance parts to the end, and this is guarranteed to be more painful for you!

  6. Once all development is complete, you submit your completed requirements cataloge along with all necessary test evidence that is required.

  7. When the ITK team are satisfed with your submission, they will confirm conformance and issue you with a certificate. This is the point at which you will be added to the online ITK Accreditiation Catalogue.

The NHS, Public Cloud, and N3

This week, NHS Digital have released new guidance around the hosting and off-shoring of NHS and Social Care data.

The guidance on “off-shoring and the use of public cloud” clarifies a couple of important factors:

  • NHS and Social Care data is to be treated as OFFICIAL data which is the lowest of the Governement Security Classifications [(there are only three classifications: OFFICIAL, SECRET, and TOP SECRET). The significance of this is that it means we don’t need to buy NHS-specific hosting any more – OFFICIAL means good enterprise security and compliance with recognised data security standards.
  • Data can be hosted within the UK – European Economic Area (EEA), a country deemed adequate by the European Commission, or in the US where covered by Privacy Shield. This is a significant change from the previous restriction which required data to be kept in England for NHS England remit services, for instance.

All of this is strongly predicated on the fact that appropriate controls, risk assessments, and security measures are applied regardless of where data is processed and stored – the novel part is that this guidance acknowledges that acceptable levels of security can be achieved within the off-shore areas mentioned above.

For the avoidance of doubt, this new guidance does not mean that it is automatically safe to store NHS and Social Care personal data within these wider regions – the same level of design and scrutiny needs to be applied in line with the necessary security principles.

N3 / HSCN applications in public cloud

The above guidance is a massive step forward, and it hopefully signals a new focus from NHS Digital on fulfilling its purpose as a foundation for technology within the NHS, and on remaining a technologically-relevant organisation within the such a fast-paced industry.

The guidance alone isn’t quite enough, though. For many, the knowledge needed to design a public cloud infrastructure with the ability to communicate within the N3 / HSCN networks is a mere myth.

Black Pear, a health software supplier with a focus on interoperability are one of the few who have actually achieved this and Dunmail Hodkinson, CTO, shared some of his top tips on the OpenHealthHub community forum. He kindly agreed that I could collect them together here for easy reference.

The below information is shared in the hope that it will at least help you get started with designing your use of public cloud, and we are grateful to Dunmail and Black Pear for sharing this openly.

It should go without saying that this is by no means an exhaustive set of guidance and that you are completely responsible for your own implementations.

Designing the infrastructure

The design used by Black Pear is relatively simple:

  • AWS DirectConnect (https://aws.amazon.com/directconnect/) is used to securely route traffic from N3/HSCN to the Gateway VPC on AWS. (The Gateway VPC is then effectively a little bubble of N3 running on AWS)

  • Host proxy servers for both inbound and outbound traffic in the Gateway VPC. Choose your favourite software! (Black Pear runs Ubuntu + haproxy/nginx/squid/postfix).

  • Create a second VPC on AWS – this is the Private VPC and must not be routable from the internet

  • The Private VPC is used to host your application servers

  • Finally, VPC peering (https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html) is configured to route traffic between the Gateway VPC and Private VPCs.

  • Supporting guidance

    AWS have published a helpful set of guidance describing Cloud architectures for UK-OFFICIAL workloads:
    (https://aws.amazon.com/quickstart/architecture/accelerator-uk-official).

    This includes a candidate architecture that can quickly be adapted to NHS requirements. You can try these out on any AWS account…

    N3 Connectivity

    Black Pear uses Redcentric to provide N3 connectivity for their production services on AWS (http://www.redcentricplc.com/services/networks/hscn-connectivity/hscn-public-cloud-connectivity/).

    This is straightforward, but there are some pre-requisites for connecting to N3:

    • Design documentation (the Logical Connection Architecture) is used to show that the connection will be safe, secure and comply with NHS requirements.
  • The Information Governance Toolkit (https://www.igt.hscic.gov.uk/) is used to show that your organisation has a robust information governance framework in place.

  • Once the agreement and necessary documentation was in place, the actual setup of the connection took less than a day.

    Some top tips…

    • Start the IGToolkit and Logical Connection Architecture early. You can then make design decisions that make it easy to meet the requirements.
  • Use the Infrastructure as Code practice, for example AWS CloudFormation (https://aws.amazon.com/cloudformation/). Use this to build and deploy a development environment that matches the production environment exactly – including network configuration, firewall rules and virtual machine images.

  • Remember that not all AWS services run in all regions (e.g. Kinesis Firehose) and some must be internet connected (e.g. ApiGateway). Check that you’ll be able to use the service when you deploy to production.

  • Ensure you establish contact with the NHS Digital DNS team and help them understand what you are doing – you may need their help to configure some non-standard DNS records (e.g. a CNAME record on N3 DNS servers that points to a CNAME record on internet DNS servers that points to the CNAME record of a private load balancer on AWS DNS servers, that finally resolves to A records describing IP addresses in the Gateway VPC).

  • Links

    Black Pear is a provider of healthcare interoperable clinical applications.

    Redcentric is a managed services provider.

    NHS Digital – NHS and social care data: off-shoring and the use of public cloud services

    Information Governance Tool Kit

    Government Security Classifications

    AWS Guidance on UK-OFFICIAL workloads

    NHS Hack Day – What is a pitch, and who should do one?

    This is a shadow copy of the blog post published on (NHSHackDay.com): (http://nhshackday.com/blog/posts/2018/01/17/everything-you-ever-wanted-to-know-about-pitching)

    If you’re new to NHS Hack Day (and even if you’re not), the thought of pitching your idea to an entire room of people is quite daunting.

    So who should pitch at NHS Hack Day? And what even is a pitch anyway…?

    Let’s cover the what and who bits first.


    What is a pitch?

    A pitch is a short opportunity for a person to share a project idea to tempt others to work on it with them.

    At the start of NHS Hack Day, anyone with a problem or project they think might be interesting to other attendees can speak for up to 60 seconds to explain it to the rest of the group.

    Based on these short pitches, other attendees decide what they’d like to spend time on on during the weekend.

    The pitches are short, and so it is not possible to use slides or to show demos on the projector. This is almost always a good thing — you can focus on making your explanation as clear to as many people as possible.

    If you really need to show something (seriously, you probably don’t), you could hold up a sheet of flipchart paper (we’ll have lots of this) — but try not to over-complicate or over-think it 🙂


    Who should pitch?

    Short answer: Anyone.

    Longer answer: This is an opportunity for anyone with an idea that they’d like to explore, or a problem they have in their day-to-day work, to tell a room full of smart and motivated people about it, with the aim of coming up with a joint solution, or even ‘just’ some more information about the problem.

    The weekend will be a great opportunity for you to learn about what other people in your sector are doing, and how they’re addressing the problems they face; but of course this will work best if everyone buys in.


    I’m still not sure

    Ok, so now you know why you are totally someone who should pitch at NHS Hack Day, but you’re still not sure?

    Here are some common concerns about pitching:

    1. I’m not very good at presenting to audiences

    Firstly, you are probably a whole load better at it than you think you are.

    Secondly, the NHS Hack Day community does not attract polished speakers with years of presentation experience. It attracts people just like you and I, who have the same apprehensions.

    The quick-fire pitching style is actually fun. It’s so different to a formal presentation that people won’t even think about the sort of things you’re worried about.

    And if you’re still not sure: talk to an organiser or hang back down the queue a bit, watch some other people pitch first, and then see how you feel. Every hack event we’ve held has had at least one last minute idea pitched where someone gets inspired by the other pitches.

    Lastly, no one will even notice if you decide not to go ahead. 🙂

    If you think that talking through your pitch with someone might help, do get in touch with our team of volunteers on the event Slack, on Twitter, or at hello@openhealthcare.org.uk and we’ll be happy to try and help you.

    2. My idea is not developed enough to be interesting or useful

    This is just not A Thing!

    The best ideas for an NHS Hack Day are those ones that have plenty of room to be developed. That’s why we’re at NHS Hack Day in the first place, right?

    People come to NHS Hack Day for a number of reasons: to work on an idea or problem they have, to get stuck in helping other people develop their ideas, or just to learn about what’s happening and to meet people.

    In any case, what you have to offer is valuable to the community – we promise.

    Your pitch might be as simple as describing a problem that you’ve encountered, and there will be people in the audience for whom that is enough for them to get problem-solving with you.

    You might have a clear idea, but feel like you haven’t developed the ‘how’ enough yet — that’s great! Tell the audience this, and ask them to help you work out the ‘how’. Again, this will be a really interesting proposition for some people.

    Be careful here not to pitch a solution rather than a problem, see Tip 5 in our first blog (http://nhshackday.com/blog/posts/2017/11/15/top-10-tips-for-awesome-pitches) for more info on this!

    There is no idea too small or too early to pitch – you’ll get a feel for this as soon as you see what other people are pitching.

    3. My idea isn’t interesting enough, or the other ideas will be more interesting

    “Interesting” is a personal thing. You really can’t guess what will or won’t be interesting to other people in our community.

    NHS Hack Day often ends up with only some of the original pitches actually being worked on; this is entirely normal, and is a result of the self-organising that happens at these events.

    It is possible that your pitch won’t make it all the way to the end of the weekend, but this is not a reflection of quality, interest, value, or you. You might even decide that you’d rather work on someone else’s idea (this happens ALL the time).


    Go on, give pitching a go

    Don’t be shy: do consider having a go at pitching. Your friends at NHS Hack Day are the best people you could do this with for sure.


    And lastly, as always, if you have any questions about anything in this post (or indeed about anything else), do get in touch with our team of volunteers on the event Slack, on Twitter, or at hello@openhealthcare.org.uk and we’ll be happy to help.

    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 | Python.org.

    Specifically:

    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!

    What are ‘dispositions’ in Urgent Care?

    The majority of the content in this post was provided by a colleague.

    In Urgent & Emergency Care, dispositions play a key part in helping us to categorise patients and ensure they get the right response for their clinical need.

    ‘Dispositions’ are defined here: http://medical-dictionary.thefreedictionary.com/disposition.

    It is the third definition we’re interested in here:

    3. the plan for continuing health care of a patient following discharge from a given health care facility.

    My version of this, with the added context of how we use dispositions in NHS urgent & emergency care is:

    A disposition packages the perceived clinical need of a patient in the form of a skill set and a time frame.

    e.g. “Speak to a clinician | within 2 hours”

    We allocate dispositions using information / input data from the patient and our clinical expertise, and are there to help consistently communicate a point-in-time assessment of a patient’s clinical need in terms of what needs to happen next; they are really only ever recommendations.

    Although dispositions are essentially recommendations, some scenarios may have pre-defined dispositions that are considered appropriate.

    For example – specific clinical conditions might require a disposition that denotes a response by an ambulance, or Key Performance Indicators (KPIs) such as National Quality Requirements (NQRs) might define a maximum amount of time within which a patient should receive a call back from a General Practitioner (GP).

    The decision-making process taken to reach a recommended disposition (skillset and timeframe) will vary between entities too. Different organisations, regions, even clinical IT systems may use different reasoning dependent on specific external factors.

    For example – a local region may have recently experienced a high number of clinical incidents with unwell children, and therefore decide that all children are seen by a specialist paediatric service, regardless of their presenting features.

    E.g. Disposition of “See paediatric specialist | within 2 hours”

    This is still a disposition representing a clinical recommendation – i.e. the recommendation that a child be seen within 2 hours by a paediatric specialist – however the decision on which disposition is appropriate was affected by different factors.

    In all situations disposition are based on a combination of expert opinion, relevant evidence, and situational factors and therefore they are always subject to change and re-evaluation.

    How are dispositions used?

    Once a perceived skillset and timeframe have been “packaged” into a disposition, the response to the patient’s identified need will, and can, vary depending on the availability of services locally, the risk appetite of the responsible organisations or individuals, and the prioritisation within services that are available.

    How does this relate to prioritisation?

    Prioritisation is the next step and can only ever be relative.

    A “package” of information has led to the disposition but other factors will decide which of the patients assigned a similar disposition require priority.

    More external factors come into play here, such as the age of the patient, their specific condition, and any co-morbidities they may have.

    Again, it is ultimately a matter of expert opinion as to which factors have the greatest weighting when deciding priority (although as we do more with data this is likely to be come more evidence-based and less dependent on pure expert opinion).

    All the time expert opinion is a significant part of the decision-making process there will be conflict between different expert perspectives and belief systems.

    NHS Hack Day 17 – Manchester

    A short blog post about NHS Hack Day and why it’s worth attending.

    "NHS Public Data" team

    I have just spent the weekend at NHS Hack Day in Manchester, hosted by the Co-op in their new tech hub The Federation.

    I wrote this blog post with the primary intention of sharing with my colleagues in NHS Digital to hopefully encourage some more people to get involved – but I don’t think there’s anything here that doesn’t apply to everyone.

    It was a brilliant weekend, and there was a super mixture of people there – plenty of healthcare professionals, IT professionals, some senior management types (CIOs / CCIOs), general “techies” (professional, aspiring, and amateur), researchers, and a lawyer.

    "Mobi-Alert" team

    What’s NHS Hack Day like?

    For those who aren’t familiar with NHS Hack Day, it goes something like this:

    The event runs 9-5 Sat and Sun

    Lunch is provided on both days and hot drinks are available throughout.

    Saturday morning is spent using coffee to recover from the work week, chatting with people, and pitching ideas.

    Pitches are 2 minutes each and you can pitch anything from a solid idea to an open-ended question (this time we even had someone who wanted to create a sci-fi story about healthcare in the year 2100).

    Most people are nervous

    Some people only decide to pitch an idea whilst watching the other pitches – the team that won last weekend only decided to pitch after getting confidence from the other pitches.

    After pitching everyone has some time to go and talk to the pitchers, explore the ideas, and gradually teams are formed around the projects. Sometimes ideas are merged together, sometimes they’re split off into smaller projects.

    The rest of Saturday, and most of Sunday is spent working on projects 

    Different people work in different ways; some teams like to stick the headphones on and just chip away at a problem and others will spend a lot of time working through problems interactively. 

    Sometimes people start building software etc. in the first hour, sometimes people don’t build at all.

    On Sunday afternoon teams decide if they would like to present their project to everyone else – and if so submit their projects

    This is completely optional, but it feels good and is encouraged – the community is friendly and rarely does a team not present something.

    "Trendy" team

    At about 15:30 everyone gets together and watches presentations

    Each team gets 3 minutes to present their work, and 2 minutes to answer questions.

    I’m always amazed at what people have managed to prepare – last weekend we had a Fresh Prince rap from one team, and a promotional video from another…

    I had several conversations with people where they were not sure where they were expected to be in terms of progress at various points through the event. Superbly, there is no right answer.

    The presentations are one of the most enjoyable bits for me – and last weekend had me smiling throughout every single presentation. There were so many great ideas, and every team had something interesting to show.

    Teams will present anything from some paper mockups and a bit of narrative through to a fully working product with audience participation – it is dependent on the type of project, the team, and how good people are at getting up on Sundays mornings.

    IMG_0030

    After presentations, there is a short period of evaluation where either a panel of invited judges, or the community, will vote for the top three projects – and those teams are given some prizes

    We tried a new approach to voting this time where the community was given 3 votes each to vote for the three projects they were most excited by. We trusted the community to not vote for themselves, and to only vote three times – this simply doesn’t need policing.

    People then help put the borrowed space back to how it was found, and head home feeling enthused 🙂 

    The last 30 mins is spent clearing up, saying goodbye, exchanging contact details, plotting world domination, and just generally wrapping up an enjoyable weekend.

    170716-DSCF2913.JPG

    Why should I care?

    If you’re thinking “well I’m sure you all had fun, but does this matter to me?”, here are a few of my thoughts:

    There is absolutely no ‘right skill set’

    In fact I shouldn’t need to explain that diversity always wins and this certainly includes diversity of skills.  The best outputs come from the teams with the most diversity, and there is no buzz quite like building something with a diverse team of techies, healthcare professionals, artists, and users.

    On our team, we were all learners in one way or another so a large amount of our time was spent pairing, learning, explaining, and discovering – this is just as rewarding as having something shiny to present the end of it.

    This type of event is unconstrained thinking at its absolute best

    As an embittered and tiring NHS technology person, I go to these events to recharge my batteries. This kind of community is not subject to the organisational, political, and learned behavioural constraints that many of us are.

    It’s incredibly rare that a pitch is binned because “we’ll never get it through the <insert your favourite bureaucratic restriction here> process” – people are there to busk and solve problems. The concept of a political mandate, or a 4:1 return on investment simply isn’t important here.

    The ideas and outputs from these events are a map for the future

    Maps are so useful – we are all pretty convinced of the benefit of roadmaps, and visions, and Google maps.

    The ideas at these events give us a clue about what is around the corner for NHS technology. Many people at these events are recently qualified healthcare professionals, or are maybe only involved with NHS technology as users and see this as an opportunity to have a voice.

    The things they want, and expect, are clues – to what we should be thinking about, to where we should be going, and to where we’re falling short.

    It helps prove that the centre can engage, listen and help

    Do not read subtext into this – I am not saying “NHS England / NHS Digital never engage with the community”.

    But it should not raise eyebrows at these events when one says that they work for NHS Digital, or NHS England – people are, but shouldn’t be, pleasantly surprised.

    Last weekend I think I counted the number of attendees from NHS England / NHS Digital on one hand – I’d love to see this go onto two hands.

    People are enthused to see us there, and actually we can be really helpful as guides, navigators, and mentors. It encourages innovators just to know that we’ve considered it of value to take time to be there.

    It’s not just about AI and mobile apps – people solve fundamental problems too

    One of my favourite projects from last week: FastPass. A team of seasoned IT support professionals who were determined to sort out the drag of password resets – both for support staff and users. They built a working system for self-service password resets and they intend to take it forward within their local NHS trust.

    My team tackled the challenge of collecting timely feedback from users of NHS services at a scale that would produce enough data to be significant.

    Real problems, not flashy, that could genuinely make stuff better.

    IMG_0025

    In conclusion

    Next time there’s an NHS Hack Day near you, try and get along – if only for one day.

    If you don’t like it then fair enough.

    But you might do, and you might find it leads to you bringing a better, more energised self back into work the following Monday – and that can only be a good thing for your own organisation, and the NHS.

    Visit http://nhshackday.com/ for more information, or follow @NHSHackDay on Twitter.

    If you are interested, and would like to ask some questions feel free to drop me an email at matt@stibbsy.co.uk or @mattstibbs on Twitter – I’d be really happy to tell you more.

    Appointment booking in Urgent Care

    Introduction

    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.