NHS Digital consults the public on data and tech

NHS Digital has published two public consultations on digital, data, and technology – I’ve summarised and linked to them in this blog post.

Recently, NHS Digital has published two public consultations that are of broad public interest and deserving of comprehensive feedback. They are looking to define principles and standards for the use of NHS technology and data.

It’s positive that these things are out there for public input but sometimes they don’t get the breadth of audience, and depth of attention, that they need.

There is a strong argument for just getting high-level principles out there with some authority, especially if they are broad enough that everyone can get behind them; the Secretary of State Matt Hancock has done this recently with a policy paper:

“The future of healthcare: our vision for digital, data and technology in health and care”


The policy paper has received strong support from across the system, but to make these principles work for us we need to start “baking them in” to the way the the NHS works – at that point a bit more attention is required.

I’ve summarised and linked to them below in the hope that you will take a bit of time to take part.

Continue reading “NHS Digital consults the public on data and tech”

DoS Hack 2018

A couple of weeks ago, we brought together several NHS Digital internal product teams in Exeter to spend two days hacking on projects related to Directory of Services and service information products.

I feel strongly that not all hackathons have to be developer-centric. We made a point of bringing a range of people and skillsets together for this and it’s an opportunity for people to play whatever role they want to – you do not have to do your day job!

We brought together teams who either work directly on DoS products, or who have some dependency on DoS products. This included teams such as NHS 111 Online who have had to work closely with the DoS teams over the last year to develop their product.

The primary aim of the hackathon was to bring disparate, but related teams together to counter the silo effect that we can sometimes experience working in a big organisation across multiple locations. Allowing people to put names to faces, and make new connections inevitably streamlines the way we work together. It was also an opportunity for people to break away from their daily work routine and ‘backlog’. It was not a requirement that the end result involved production-ready software or ideas supported by a business case!

The Projects

It was great to see over 20 different pitches made at the beginning of the two days with some people making more than one. By the end of the first morning, teams had self-organised around 8 projects:

“Capacity Grids Reinvented” – The team took our existing Capacity Management product and imagined what a modern, mobile-first version might look like. The team had people doing development, design, and analysis and created a collection of prototypes demonstrating a user experience much more aligned with the needs of capacity management users.

Photo of the "Capacity Management" team sitting around their project table working on their laptops.
The “Capacity Management” team worked on some prototypes for a new user interface

“Alexa, ask Health Info…” – A hackathon favourite – the team combined a number of pitched ideas to use Amazon Alexa to answer questions about health issues (using health content from the NHS.UK API) and then provide service recommendations (using information from the DoS API).

Photo of the "Ask Health Info" team standing around their project table
The “Ask Health Info” team prototyped their conversational UI with post-its and their voices

“Alternative triage products searching the DoS” – Related to work going on in the Clinical Triage Platform (CTP) programme, this team looked at how multiple triage products might search the DoS using their triage output. This is a semantics and information modelling challenge as much as it is technical.

“Elasticating the DoS…” – With Elasticsearch being another popular hackathon tool of choice, this team combined several pitches related to using Elasticsearch (or similar indexing technology) to experiment with optimising searches for service information – both in terms of speed and flexibility.

Photo of the Elasticsearch team standing in a circle around some paper designs laid out on the floor.
Surely everyone does collaborative design on the floor?

“Postcode microservice” – This team worked up a simple prototype looking at splitting commonly-used postcode reference data out into a discrete service so that it could be used across multiple teams without uncessary duplication.

“Change request microservice” – This team prototyped a “Change Request Service” for the DoS, experimenting with JSON Patch syntax to present some simple request and approval workflow via an API to allow consumers to request a change to their service information.

“Faker” – As is the story with so many startups these days, this team began looking at the potential of using Machine Learning to optimise the search algorithms in the DoS but quickly pivoted to focus on using the Faker tool to generate synthetic service information in bulk. The potential here being not just simple testing, but the opportunity to generate on-demand service data to reflect different commissioning scenarios within the NHS.

“Geofencing (I’m a person not a crow)” – This team decided to tackle the long-standing issue of the DoS using “direct line” distance searching. They prototyped an end-to-end search using Isochrones to define polygons to bound searches, which can then be easily passed into most geospatial-aware database queries.

How did it go?

At the end of the second afternoon each team gave a 10 minute show and tell about their projects. We managed to get some of the NHS Digital DDC Exeter Senior Management Team along for this bit – and I’m glad we did.

Although, as I’ve mentioned, the idea was not to produce “deployable solutions” I was chuffed to see just how much the teams had achieved in just a day and a half. I certainly left the event trying to work out how I could shoehorn the ideas into our product roadmaps, and I am confident that we have turbo-charged some of the work we will need to do in due-course.

It was great to bring lots of different skillsets together and almost everyone felt like they could contribute, but there is always more that can be done to make sure the day is as inclusive for every attendee as possible. It just emphasises that you really do have to put in the prior effort to structure any kind of collaborative / interactive event like hackdays or workshops if you want it to really ‘work’.

Thank you to everyone who contributed to making it a valuable two days – I’m certainly hoping we can do it again, and maybe with a broader attendance.

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:

    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.


    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.