spine 2 nhs workshop

7/30/2019 SPINE 2 NHS Workshop

1/53

Spine 2 - Core SupplierWorkshopSupplier Workshop

1

Presented by

HSCIC Spine 2 Programme


2/53

Agenda

MorningDrinks & registrationIntroduction and Spine 2 Andy SymeTechnical Matthew BarrowTest Environments Emma MurphyTest Data Emma Bell

Supplier Testing Annie LeachQ&A

Afternoon 1:00 1:45 Breakout Group #1

1:45 2:00 Drinks 2:00 - 2:45 Breakout Group #2 2:45 3:00 Close


3/53

Introduction and Spine 2

Andy Syme

Transition ManagerSpine 2 Programme


4/53

Aim

To help suppliers prepare for and

participate appropriately inSpine 2 - core testing.


5/53

Why Spine 2?

Contract approaching end of l ife.

Drive by the Cabinet Office and Treasury to do things

differently. NHS needs are different to those envisaged when

Spine contracted.


6/53

What is Spine 2?

A complete redesign of the hardware, software andcode to deliver the equivalent functionality to Spine

Release 1 PDS, PSIS, TMS, (TES) Alert Viewer UI, EPS, DSA, DBS,

SCR, SCRa/CSA, ACS, Gazetteer, LRS, Audit & Reporting

Release 2

EPS Prescription Tracker, DTS , NN4B, CP-IS, BNA, &SCRa 1-Click

Release 3

New functionality

Our intent is that If it worked and

was used on Spine it will work on Spine 2


7/53

Key Messages?

You need to test your systems

Spine is complex and has evolved over the years.

You need to ensure that everything works as you expectfor your customers.

We can help ensure everything works as before

In Phase 1 we will code a deviation or a deprecation so it

will*.

In Phase 2 it wil l be more likely you wil l need to f ix.

Integration testing is how we help you ensure Spine

to Spine 2 transition is a non event for your users.

* In most cases


8/53

Who do we contact in the first case?

Testing Issues* Via the Solution AssuranceHelpdesk, or your normal contacts.

Candidate technical enhancements Via the STIF Commercial and Transition Planning Issues Me

* Including technical, defects, data and environment


9/53

Spine 2 - Core

Matthew Barrow

Functional LeadSpine 2 - Core


10/53

Key Principles

Agility

NoSQL

Enterprise open source software Commodity hardware

Automation

Plan for failure Stability Not Speed

Self Service

Small team of highly-skilled resource Reduce inventory

Platform for future change

(more) Agility


11/53

Key Partner - BJ SS

Leeds based developers, analysts, testers

Experience in high-quality/data-criticaldelivery

One-team (HSCIC internal, contract, BJ SS) Agile leadership (BJ SS Enterprise Agile)

Hardworking but fun

http://www.bjss.co.uk


12/53

KEY TECHNOLOGIES


13/53

Key Technologies - RIAK

No-SQL document store

+ Fast+ Open Source

+ Reliable

+ Horizontally Scalable+ Tunable relationship between Consistency,

Availability and Partition tolerance

- Not atomic- Very hard to run un-indexed cross-store queries

http://basho.com/riak/


14/53

Key Technologies - Tornado

Non-blocking Web Server

+ Fast

+ Open Source

+ Huge capacity+ Resilient to back-pressure

- ???http://www.tornadoweb.org


15/53

Key Technologies - Redis

In-memory key-value store

+ Extremely Fast

+ Open Source

+ Very Simple- Capacity limited by memory capacity

- Data needs to be reloaded on failurehttp://redis.io/


16/53

Key Technologies - Splunk

Real-time indexing and reporting

+ Extremely Fast+ Huge capacity+ Logs available

immediately+ Very Flexible- Dependant on

Source Data

http://www.splunk.com/


17/53

Key Technologies - J SON

J avaScript Object Notation used for all data

+ Flexible

+ Schema change handled in code not

migration+ Very Simple

- Documentation

http://www.json.org/


18/53

Key Technologies - Mustache

Logic-less templates for

rendering data in a HL7+ Very Simple; learn it in 15mins

+ Fast when used with

Cystache+ Easy to maintain- No logic

http://mustache.github.io/

{"header": "Colors","items": [

{"name": "red", "first": true, "url": "#Red"},{"name": "green", "link": true, "url": "#Green"},

{"name": "blue", "link": true, "url": "#Blue"}],"empty": false}

{{header}}{{#items}}{{#first}}{{name}}{{/first}}{{#link}}{{name}}{{/link}}{{/items}}{{#empty}}

The list is empty.
{{/empty}}
Colorsredgreen

blue

J SON

Template

RenderedOutput


19/53

Key Technologies - Schematron

Easy way to write XSLT for

validation/extraction+ Much easier than XSLT+ Compiled at run-time+ Easy to maintain

- Reduced features- Two-stage conversion

http://www.schematron.com/

BBB element is missing.BBB element is present.There is 1 element.There are 2 elements.

Some Cs

BBB element is present.DDD element is present.AAA misses attr name.

There are two elements.

Schematron

XML

Report


20/53

CODE QUALITY


21/53

Continuous Integration


22/53

Test Coverage


23/53

Code Analysis


24/53

Progress


25/53

KEY CHANGES


26/53

Key Changes

Validation Increased inbound validation to enforce specifications and data quality Consider PDS Update scenarios, only return changed data

Future dates No support for future business dated demographics in Spine 2 - rejection Migration approach not yet agreed

Object IDs in PDS Option to provide them as part of the addition Backwards compatibility maintained

EPS Future dated prescriptions supported Handling of out-of-order messages (cancellations, dispense, claim) Positive Acknowledgements Backwards Compatible by Service

UI Session Persistence Supported in SCRa and DSA, across browser and machine, not role

Summary Care Record Application Permission to View


27/53

Key Changes - continued

Reduced dataset in PDS 2007-A (MIM6.3.01), though MIM7.2.02 interactions are supported

DSA Complete re-design, performs the same functions Error reporting

Effort to maintain the response codes, but provide better display detail

Record / replay

Ability to capture all messages into all environments for analysis, replayetc

Deprecations (unused messages, TES, ERS) Demographics Batch Service Client Warranted environment

Support for Google Chrome and Firefox Mozilla Internet Explorer 7+ (no IE6 support), J ava J RE 6 (no 1.4 or 1.5

support)


28/53

SELF SERVICE


29/53

Self Service

View message status

View Spine logs associated with message(including errors)

Replay message or resend response Search by message GUID or ASID


30/53

Self Service - Home


31/53

Self Service GUID Search


32/53

Self Service View Status


33/53

Self Service View Message


34/53

Self Service View Logs


35/53

Not a single line of code, artefact or fileis shared between Spine 1 & Spine 2

please help us highlight any deviationsin test not live!


36/53

SA Test Environments & Spine 2Core

Emma MurphyTest Environments Manager

Th SA EMT P th t Li E i t


37/53

The SA EMT Path to Live Environments

EMT provide five environments, each has aspecific role, a Choose and Book connection and

all are available for the NHS and systemsuppliers to use.


38/53


39/53

Connecting a Spine 2 Core test environment

A Spine 2 Core test environment will:

connect to an existing Spine test environment.

use the existing environment for smartcard authentication.

use the SDS in the existing environment for Spine Directory Services data.use the certificates and CAs of the existing Spine environment.

use a Choose and Book messaging connection redirected to Spine 2 Core.


40/53

Connecting to Spine 2 Core


41/53

Connecting to Spine 2 Core

The new Spine 2 Core Test Environments will be named for their usage e.g.Integration, Training, Development etc.

Users of an existing Spine test environment can connect to an attached Spine2 Core environment e.g. Integration by:

Adding the new Spine 2 Core IP addresses to local firewall rules. Changing the Spine messaging URLs

o add entries to the host file to redirect existing URLs or

o reconfigure local message handler with the Spine 2 Core IP addresses

Using new Spine 2 Core URLs to access some web based applications, for

example DSA.


42/53

Path to Live Environments + Spine 2 Core

SA EMT O i


43/53

SA EMT Operations

EMT will provide the operational management of the new Spine 2 core boxes.

This includes: Managing changes e.g. code deployments

Integration support e.g. end point connection issues.

Environment monitoring.

SA T t E i t Ti li


44/53

SA Test Environments Timeline

13th May 2013 NIS1 + Integration (core 2) + VF1 (CAB)

Late May 2013 VNIS1 + Deployment (core 2) + VE1 (CAB)

Autumn 2013 VNIS3 + Development (core 2) Autumn 2013 TSpine + Training (core 2)

Autumn 2013 VNIS4 + Production (core 2)


45/53

Test Data

Emma BellPrincipal Test Data Analyst

Ph 1 T ti D t B ild


46/53

Phase 1 Testing Data Builds

Core 1 data unchanged.

SDS data shared between Core 1 and Core 2 (users,

organisations, smartcards etc unchanged). Standard PDS and EPS packs mix of demographics and

scenarios.

ESPs (NIS1) Compliance team provided list of suppliers

and pack types. Non- ESPs (NIS1 and VNIS1) packs allocated based on

previous allocation. 1 x standard pack allocated to each GPpractice.

New NHS numbers and demographic details.

Phase 1 Testing Timelines


47/53

Phase 1 Testing Timelines

VNIS1 data build soon after NIS1.

Reference packs issued prior to start of testing.

Possible large demand peaks allow 4 weeks forprocessing of supplementary Phase 1 data requests.

If you have not received data or heard further

communications by 6th May contact the Test DataTeam to confirm processing of your requirements.

Phase 2 Testing


48/53

Phase 2 Testing

SDS data (users, organisations, smartcards etc unchanged).

Data migrated from NIS1 Core 1 PDS, EPS and SCR(snapshot date TBC).

Requests for additional data to be migrated required by 15thJ une.

Data loaded in Phase 1 will not be available in Phase 2 unlessspecifically requested for load to Core 1.

If in doubt

Email: [email protected]

Mobile: Emma Bell @ 07834 418 301 Website (form downloads): http://nww.hscic.gov.uk/nic/testdata


49/53

Supplier Testing

Annie LeachSpine Assurance and Integration TestManager

Assurance Approach


50/53

Assurance Approach

There will be 2 Phases for Integration Test

Phase 1 : 13th May 26thJ uly

Phase 2 : 5th August 13th September Phase 1 is critical to the success of Phase 2 as it is the first stage to

identify issues and correct them

Phase 2 is for a more formal regression test to ensure that the build

is defect free and that your systems will continue to work from day1 There will be no additional supplier test list workshops as in the past

Youll need to assess how your system interacts with the Spine and identify any potential risk

areas

plan testing around those risk areas use Phase 1 to explore the risk areas

determine the versions of your software to be tested

TestPhase Management


51/53

Test Phase Management

For LSPs and NASPs Andy Byram is the test execution manager,he will keep in touch with your test team to check progress andaddress any issues

For ESPs J ill Clarkson and Gerry Monahan will be the contacts whokeep in touch with your test teams

Each phase will be tracked in terms of planned and actual progress,with Suppliers being contacted from w/c 22nd April.

Defects should be raised via the SA help desk as is current practiceand all communications about defects should go via this route

Defect and progress calls to be set up as required

All suppliers are required to sign off at the end of each phase (no

test evidence required)

There will be provisioned production support capabilities for CABsuppliers in VNIS 4


52/53

Any Questions?

Useful e-mail addresses


53/53

Useful e-mail addresses

Spine 2 Transition Manager : Andy Syme:[email protected]

ESP : [email protected] LSP and NASP Assurance Manager : Andy Byram

[email protected]

Environments Management Team: [email protected]

Test Data: [email protected]

Other technical and non-technical enquiries : Spine 2 Mailbox:[email protected]

spine 2 nhs workshop

Documents