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.
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!
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.
“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).
“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.
“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.
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.
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 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.
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.
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!
Once all development is complete, you submit your completed requirements cataloge along with all necessary test evidence that is required.
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.
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
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).
I only realised in hindsight that I attended a number of tech events, meetups, training, hackathons etc. during 2017.
To attempt to be a bit more organised, and in case it’s of interest to others, I’m going to keep a live list of my planned events for 2018 here. Give me a shout if you’re interested in any of them and would like to know more!
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.
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!
It is the third definition we’re interested in here:
3. theplanforcontinuinghealthcare of a patientfollowingdischargefrom a givenhealthcarefacility.
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.