This week, NHS Digital have released new guidance around the hosting and off-shoring of NHS and Social Care data. This blog post pulls out some of the important points, and details how people have approached this already.
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:
- Create a VPC on AWS (https://aws.amazon.com/vpc/) – this will be the Gateway VPC
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.
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…
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).