NHS Booking and Referral Standard

Deploy

Implementing a solution requires good knowledge of the environment being deployed to, allowing a plan to be established to check all conditions are met for success. This section covers deployment, along with the necessary checks to prove functionality, to fully test end-to-end capable environments.

When deploying a solution there are many threads to pull together. The developed solution is one part of this but the local environment it is to be deployed into must also be prepared, as well as confirming workflow and functionality behave as expected. The fundamental steps will include completing BaRS Onboarding, upgrading solutions, configuration and testing.

The overall aim is take a solution and enable it in an environment (INT or Production) to work with other deployed solutions.

Prerequisites

In almost all BaRS Applications, a solution will act as a Sender and Receiver and need to perform all onboarding steps.

Onboarding must occur for each environment independently; the process is similar for each but the steps must be replicated.

Configuration

The core steps to complete technical setup in an environment are:-

• complete onboarding for the desired environment
• install supplier solution in the given Solution Environment (See Testing section)
• perform any configuration steps to enable BaRS (and related workflows) in the solution
• provide service identifier* to be configured in the Endpoint Catalogue (BaRS related component)

*This may be a local value or relate to a directory of service

NOTE - The detail of installing and configuring a solution will differ considerably depending on the supplier and provider(s) involved.

Testing

Testing is a continuous process throughout the development phase and continues right through to business go-live (in the Production environment). There are numerous stages, environments and systems involved and, to ensure there is clarity for suppliers and providers, the BaRS team define the testing stages as outlined below:-

Test Plans

Planning is essential to successful testing where numerous parties are involved. The test needs careful orchestration and for each of the actors involved to know the plan and their roles and resposibilities within it.

Test Plans must be adopted for testing on any live-like environment (INT and Production). However, there are circumstances where ad hoc testing can occur in the Integration (INT) environment, without the need for a full Test Plan (or all actors). For example, when a supplier is initially deploying and configuring their solution (during their later development phases) to test against other suppliers who are already deployed and assured.

The documented steps in the Test Plan must include:-

• prerequiste steps for the test. For example, a particular patient with a certain condition
• test reference and name
• steps to perform test. For example, create local encounter, select a particular service
• expected result
• ability to record success or failure

Tests in the plan MAY cover both expected workflows and error states.

Before engaging in a Test Plan, ensure the follow steps are complete -

• Configuration steps above have been completed
• actors required for the test are informed
• date and time for the testing agreed and scheduled
• test steps are documented (as described above)
• specific test data elements are documented. For example, the patient NHS number to use
• expected results of the test are known and can verified

INT Environment

The Integration (INT) environment is a like-live environment which suppliers can connect into while in development. This can be done without full assurance in place.

The INT environment will be the first place a solution is fully deployed. This environment allows different suppliers to test their solutions together, as they intend to work in the Production environment. INT requires all the same technical elements to be configured as they would be in a Production environment.

Once configured, the solution is ready to interact with other suppliers or Toolkit Workbench (TKW). The BaRS Team can help facilitate the process of engagement with other suppliers for the purposes of testing. Supplier must also demonstrate the full functionality of their solution in INT as part of assurance and evidence compliance with DCB0129 Clinical Risk Management: its Application in the Manufacture of Health IT Systems

Moving to Production

Appropriate planning is required to ensure the successful go live of a solution. There is a staged approach to moving a solution through to Production, which involves testing and decision making by the actors involved, to satisfy the solution is robust enough for patient contacts. Releasing to Production can only happen once assurance is complete and Solution Assurance have issued a Technical Conformance Certificate (TCC). Requests to onboard to Production infrastructure (Connection Agreement) will be rejected prior to this.

Adopting BaRS is likely to require organisational change, which at times may be signifcant (at least at service level), and may need resource from many parties to adopt and implement, including management, clinical and technical teams, as well as system users. A project plan, for implementation and go-live will be required to organise resources accordingly.

In addition to the Configuration steps outlined above, a Clinical Safety Officer (CSO) must be engaged to understand the impact of the BaRS workflow on the service implementing and the organisation at large. It is expected that DCB 0160 Clinical Risk Management: its Application in the Deployment and Use of Health IT Systems will be completed as part of the clinical governance process. This will underpin the Service's Standard Operating Procedures (SOPs) and any training materials required for system users.

A project plan must be drawn up, documenting the steps from the current (as-is) workflow to the new (to-be) one. This will include core phases:-

• changes to workflow
• deployment of solution
• testing phases

Roles and Responsibilities

The actors from the numerous parties must know what is expected of them during a planned test. This ensures the test has the best chance of success and time is not wasted through trial-and-error attempts.

There is a requirement to cover these core roles for any level of planned test. There may be others involved or some individuals may perform multiple roles.

User Acceptance Tests (UAT)

As part of the move to Production, the solution will be deployed to the Provider's testing environment. This must be a replica of the current production environment where the additional BaRS functionality can be trialled to ensure it functions as expected and the system users can be trained to use it. Full functional review of the solution, as well as existing functionalty, should be undertaken during this Provider Testing phase.

All workflows documented in the Test Plan must be tested (and pass) in UAT before arranging upgrades and configuration to the Production environment. If issues with the solution are found at this stage they can be rectified, without having any impact on Production, through either configuration or a new release of the solution. This is the best time to find issues, if they exist, so sufficient resource should be dedicated to ensure thorough testing.

Technical Go Live

Assuming the Provider Testing has been successful, the Technical Go Live can be scheduled. The Technical Go Live testing will take place in the Production environment and will cover all expected functional (happy path) workflows.

Once complete, if all the functional tests have passed, a decision (Go/No Go) to progress to the live environment can be made and a date scheduled.

NOTE - Care must be taken at this stage to limit impact on the live services. The testing must be carried out in live but the service cannot technically go live (and deal with patients) until all functional tests in the Test Plan have been completed successfully.

Business Go Live

On the agreed date of Business go-live (which may be straight after the Technical go live) the system will be enabled, ready for live patient use. If the Business go-live is not on the same day as the Technical go-live, a final end-to-end test run, to verify functionality, should take place before the service is declared fit for live use. The solution then moves from a 'project' into BAU (Business as Usual), supported by all usual processes e.g. Technical Support.

DoS Leads

If the provider operates within Urgent and Emergency Care (UEC), they are likely to have a UEC Directory of Services (DoS) entry. DoS leads must configure Service Providers who wish to use BaRS in the standard way, as the service dictates, but their DoS ID will also need to exist in the BaRS Endpoint Catalogue.

Steps to configure the provider on the BaRS Endpoint Catalogue:-

• note the Service ID on DoS
• Obtain API endpoint details for the service from the Supplier or Provider
• Email bookingandreferralstandard@nhs.net with both pieces of information from above, stating the environment to be configured (INT or Prod). You should include the proposed dates for testing (if known) to allow the urgency of the request to be set

NOTE - CareConnect configuration must be maintained alongside the BaRS configuration. This is so senders who are not yet BaRS compliant can still work with CareConnect and GP Connect.

Incident Management

Once in Production and running as business-as-usual (BAU), should an issue with the solution arise, service providers will be expected to follow their existing support processes with their supplier. After investigation, if the issue is thought to lie with the BaRS API or a third party supplier an incident can be raised with the National Service Desk - ssd.nationalservicedesk@nhs.net - who will involve the BaRS Programme, if required.