Development

Analysis

During this stage, suppliers will conduct any initial engagement, analysis etc.. required to get development underway. The TKW Simulators (Provider Simulator and Consumer Simulator) are useful tools for this stage.

The solution can be tested at any stage of development using these tools and the TKW Simulators will provide useful validation reports to highlight points of failure or oversight. These is more about testing during development maturity under the Testing section of this Deployment Toolkit.

Development Complete

Once Development is complete, the suplier can move onto Integration Testing.

Integration Testing

Integration testing can be a challenging step. It involves gaining access to the SPINE Integration Environment (INT). There are a series of pre-requestites and steps to complete before you can begin integration testing which equate to Technical Accreditation.

Pre-Requisites

Below are the prerequisites that need to be established before it is possible to connect to the INT environment:

• You must have HSCN connectivity
• You must have started the on-boarding (SCAL) process with the NHS Digital Solutions Assurance team

Getting connected

Once you have the above pre-requisites you will need to get connected to the INT environment. This requires a series of steps (see Appendix1 for associated URL bindings):

1. Register or modify your FQDN with the NHS’ DNS service
   • You will find the DNS request form here.
   • You need to know what your URL is
2. Register or modify your messaging product with Spine
   • Use the MPV registration request form for this
3. Request new certificates and/or create or modify endpoints
   • Use the Combined endpoint and service registration request form for this

Configure your environment to connect to SSP:

Click to see step-by-step guide to generating certificate request

The process for generating a CSR and Private Key

Prerequisite

• OpenSSL installed

Steps

1. Open a command prompt (CMD)
2. Navigate to the folder you want the CSR to go into (e.g. C:\Users\johnsmith\Desktop)
3. C:\Users\johnsmith\Desktop>openssl req -out .csr -new -newkey rsa:2048 -nodes -keyout .key

Click to see step-by-step guide to installing certificate

Steps

1. Install the cert you have been given to local cert store and bind you your site e.g. – xxx.thirdparty.nhs.uk etc
2. Configure your firewall to make outbound connections to: https://proxy.int.spine2.ncrs.nhs.uk/[provider service root url]/[fhir request]
   • See here for more information
3. Configure your firewall to receive connection inbound from msg-out.int.spine2.ncrs.nhs.uk
   • See here for more information
4. Root CA and Sub CA installed in cert store and added to bindings for local site in SSL/TLS
   • as described here
   • Note: contrary to the information in that link, PLEASE ENSURE YOU PUT BOTH CERTIFICATES IN (SHA1 + SHA2) (See documentation for more information)
5. Configure and check Certificate revocation (CRL checks) for both old (SHA1) and new (SHA2) root certs. Note: They use different revocation methods
   • New method (SHA2) needs the following:
     • The SubCA/RootCA will point to this URL: “http://crl.nhs.uk/int/1c/crlc2.crl”. This location will download a CRL file locally and will add CRL checks in.
     • Local TLS should be configured to go check this file.
     • It is on the INTERNET so please configure firewall outbound rules to be able to go to this URL over the internet.
   • Old method (SHA1) needs the following: Note: The CDP is a relative request to an LDAP query, this is not live and not accessible.
     • So the process required is to download the file and load it locally into the CRL cache and then configure the service to not check for a new file
     • The CRL files can be downloaded from here: “http://checkit/public/pki/crls.php”.
       • This location is on HSCN.
       • This file is updated every day. However it is large, and so it is acceptable to have a batch process which updates it on a longer schedule. (we recommend once per week)
       • For your clients you will obviously need this to be a batch process to download and install. Note – you need to find the correct CRL file for the right SSP integration or live environment
   • If you are using IIS:-
     • There is a way of setting IIS CRL to default to the cached file and use that even if the downloaded CRL expiry date is in the past.
     • If CertCheckMode is set to 2, certificate revocation verification will be done based on the cached CRL on the IIS server. IIS will not try to connect to the remote server to download the CRL even if it has expired and in which case CRL verification will fail (see; MSDN Article).

End-to-End test

Once set up on the Integration Environment it is possible to perform like-live tests, including making requests to spine components - SDS, SSP - and interacting with other supplier solutions.

The end-to-end tests can be characterised in either an informal, ad hoc, approach where suppliers may contact each other to arrange tests, or more formal Test Plans can be followed. If a formal test is required the Booking Team will take the lead, requesting systems to be configured, arrange a meeting time and guide users through a step-by-step test plan. The formal approach would be required for a supplier to demonstrate their solution (part of the assurance process) or gather evidence for their SCAL submission.

Assure

Assurance is a vital step in developing a Booking solution for either Provider or Consumer functionality. You will engage with the Solutions Assurance Team, via the Booking Team, who will provide the SCAL (Supplier Conformance Assessment List) document for completion. This is a self-assurance process but there is a requirement to demonstrate the end-to-end functionality and provide documented evidence of how the solution meets the Standard.

The TKW Simulator can provide supporting evidence documents required by the SCAL.

Technical Conformance Certificate

A Technical Conformance Certificate confirms NHS Digital are satisfied the solution meets the published Standard. The supplier is subsequently able to progress to live testing with a service providers in the Production environment.

Provider Testing

The first live Production test a supplier will undertake will be a controlled test, following a pre-determined Test Plan. The test will involve all actors (Service Provider, Supplier(s), DoS Leads etc) and aim to prove end-to-end functionality of the supplier solution with components - DoS, SDS & SSP, along with other existing supplier soltions.

In the unlikely event of an issue being raised at this point, it provides time for resolution prior to business go-live, whether it be in the developed solution itself or setup and configuration.

Live Install

The Live install of a Provider, to support the Provider Test, can only be performed once the Technical Conformance Certificate has been issued and Connection Agreement confirmed.

It is expected the supplier will dedicate project management resource to arranging the Live install of their customer; the Provider. The Live install will take place as part of the preparations for the end-to-end Provider Test which includes ensuring the following steps are complete:

• Connectivity to HSCN
• Establish Connection Agreement
• Register FQDN
• Register Product with the Spine - Manufacturer Product Version Registration
• Request & install certificates
• Assignment of ASID(s)
• Assign interactions (SDS/SSP) to ASID
• Ensure Firewalls are open for connections
• Upgrade & configuration of Provider system with supplier solution
• Configure DoS

Technical Live

At this point, assuming the Provider Testing has been successful, the solution is now technically ready to go live. The supplier, service provider and supporting leads e.g. DoS lead, Commisioners etc. can agree a date to start using the solution in Production.

Business Live

On the agreed date of go-live, the system will be ‘switched on’, an end-to-end test run to verify functionality and the service declared live. The solution moves from a project into BAU (Business as Usual), supported by all usual processes e.g. Technical Support.

Depending on the supplier’s adopted methodolgy, the solution may be monitored and enhanced to support more complex workflows or functional additions. This is a typcial process within the SDLC (Software Development LifeCycle).

Appendices

Click to expand appendices

Appendix1 – Message Sets/Bindings to request against your endpoint

Consumer

• CareConnect Consumer Slot v1
• CareConnect Consumer Booking v1
• CareConnect Consumer Appointment Search v1
• CareConnect Consumer Appointment Update v1
• CareConnect Registry v1
• CareConnect Booking Consumer v1

Provider

• CareConnect Provider Slot v1
• CareConnect Provider Booking v1
• CareConnect Provider Appointment v1
• CareConnect Registry v1
• CareConnect Booking Provider v1