Spine 2 - Core Supplier Workshop

Supplier Workshop

Presented by HSCIC Spine 2 Programme

Agenda
Morning
Drinks & registration Introduction and Spine 2 Andy Syme Technical Matthew Barrow Test Environments Emma Murphy Test Data Emma Bell Supplier Testing Annie Leach Q&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

Introduction and Spine 2

Andy Syme Transition Manager Spine 2 Programme

Aim

To help suppliers prepare for and participate appropriately in Spine 2 - core testing.

Why Spine 2?
Contract approaching end of life. Drive by the Cabinet Office and Treasury to do things differently. NHS needs are different to those envisaged when Spine contracted.

What is Spine 2?
A complete redesign of the hardware, software and code 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

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 expect for 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 will be more likely you will need to fix.

Integration testing is how we help you ensure Spine to Spine 2 transition is a non event for your users.

* In most cases

Who do we contact in the first case?

Testing Issues* Via the Solution Assurance Helpdesk, or your normal contacts. Candidate technical enhancements Via the STIF Commercial and Transition Planning Issues Me

* Including technical, defects, data and environment

Spine 2 - Core

Matthew Barrow Functional Lead Spine 2 - Core

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

Key Partner - BJSS

Leeds based developers, analysts, testers Experience in high-quality/data-critical delivery One-team (HSCIC internal, contract, BJSS) Agile leadership (BJSS Enterprise Agile) Hardworking but fun http://www.bjss.co.uk

KEY TECHNOLOGIES

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/

Key Technologies - Tornado

Non-blocking Web Server + Fast + Open Source + Huge capacity + Resilient to back-pressure - ??? http://www.tornadoweb.org

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 failure http://redis.io/

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/

Key Technologies - JSON

JavaScript Object Notation used for all data + Flexible + Schema change handled in code not migration + Very Simple - Documentation http://www.json.org/

Key Technologies - Mustache

Logic-less templates for rendering data in a HL7 + Very Simple; learn it in 15 mins + Fast when used with Cystache + Easy to maintain - No logic http://mustache.github.io/
{ "header": "Colors", JSON "items": [ {"name": "red", "first": true, "url": "#Red"}, {"name": "green", "link": true, "url": "#Green"}, {"name": "blue", "link": true, "url": "#Blue"}], "empty": false}

Template <h1>{{header}}</h1> {{#items}} {{#first}}<li><strong>{{name}}</strong></li>{{/first}} {{#link}}<li><a href="{{url}}">{{name}}</a></li>{{/link}} {{/items}} {{#empty}}<p>The list is empty.</p>{{/empty}} Rendered Output
<h1>Colors</h1> <li><strong>red</strong></li> <li><a href="#Green">green</a></li> <li><a href="#Blue">blue</a></li>

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 /
<pattern name="Print both cases"> Schematron <rule context="AAA"> <assert test="BBB">BBB element is missing.</assert> <report test="BBB">BBB element is present.</report> <assert test=DDD">DDD element is missing.</assert> <assert test="@name">AAA misses attr name.</assert> <report test="@name">AAA contains attr name.</report> <report test=count(*)=1">There is 1 element.</report> <report test=count(*)=2>There are 2 elements.</report> </rule> </pattern>

<AAA> <BBB name=all_Bs/> <CCC>Some Cs</CCC> </AAA>

XML

BBB element is present. DDD element is present. AAA misses attr name. There are two elements.

Report

CODE QUALITY

Continuous Integration

Test Coverage

Code Analysis

Progress

KEY CHANGES

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

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, replay etc

Deprecations (unused messages, TES, ERS) Demographics Batch Service Client Warranted environment
Support for Google Chrome and Firefox Mozilla Internet Explorer 7+ (no IE6 support), Java JRE 6 (no 1.4 or 1.5 support)

SELF SERVICE

Self Service
View message status View Spine logs associated with message (including errors) Replay message or resend response Search by message GUID or ASID

Self Service - Home

Self Service GUID Search

Self Service View Status

Self Service View Message

Self Service View Logs

Not a single line of code, artefact or file is shared between Spine 1 & Spine 2 please help us highlight any deviations in test not live!

SA Test Environments & Spine 2 Core

Emma Murphy Test Environments Manager

The SA EMT Path to Live Environments

EMT provide five environments, each has a specific role, a Choose and Book connection and all are available for the NHS and system suppliers to use.

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.

Connecting to Spine 2 Core

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 Spine 2 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.

Path to Live Environments + Spine 2 Core

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 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)

Test Data
Emma Bell Principal Test Data Analyst

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 GP practice. New NHS numbers and demographic details.

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 for processing of supplementary Phase 1 data requests. If you have not received data or heard further communications by 6th May contact the Test Data Team to confirm processing of your requirements.

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 15th June. Data loaded in Phase 1 will not be available in Phase 2 unless specifically requested for load to Core 1.

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

Supplier Testing
Annie Leach Spine Assurance and Integration Test Manager

Assurance Approach
There will be 2 Phases for Integration Test Phase 1 : 13th May 26th July 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

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 and address any issues For ESPs Jill Clarkson and Gerry Monahan will be the contacts who keep 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 practice and 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 CAB suppliers in VNIS 4

Any Questions?

Useful e-mail addresses

Spine 2 Transition Manager : Andy Syme: andrew.syme@hscic.gov.uk ESP : functional.assurance@hscic.gov.uk LSP and NASP Assurance Manager : Andy Byram andrew.byram@hscic.gov.uk Environments Management Team: sa.emt@hscic.gov.uk Test Data: testdata@hscic.gov.uk Other technical and non-technical enquiries : Spine 2 Mailbox: spine2@hscic.gov.uk