nhs e-referral service - market engagement workshop intellect offices - london 2 nd october 2013

NHS e-Referral Service -Market engagement workshop

Intellect Offices - London

2nd October 2013

Approach to today

• There are two parts to today’s session with different objectives:

Part A: Provide suppliers with a progress update on NHS e-RS activity

Part B: Update suppliers on proposed approach for NHS e-RS API functionality to enable suppliers to feedback on proposals and guide implementation

• We will operate today under normal Intellect rules which are ‘Chatham House’ rules

• Workshops will need a chair to facilitate and present back findings• Please ask clarification questions as we progress

2

AgendaSession Duration Presenter

Part 1: NHS e-RS Plenary

Approach to the day 13:30 – 13:35 Ben Gildersleve

e-Referral Service Update & Vision 13:35 – 13:55 Ben Gildersleve

Initial Phase Software Development 13:55 – 14:25 Curtis Zack/BJSS

Stakeholder Design Council 14:25 – 14:30 Stephen Miller

Transition Update 14:30 – 14:40 Curtis Zack

Break 14:40 – 14:50

Part 2: API Update and Workshops

Approach to APIs 14:50 – 15:15 Matthew BrownAlek Radjenovic

Workshop breakouts – API Approach 15:15 – 16:15 Suppliers to lead

Supplier feedback to wider group and discussion 16:15 – 16:55 Suppliers to lead

AOB and Close 16:55 – 17:00 Ben Gildersleve

3

NHS e-RS Service Update

• Launched vision at Commissioning Show June 2013• NHS e-RS to succeed Choose and Book and support paperless

referrals and paperless NHS objectives• See www.hscic.gov.uk/ers for detail on the vision• Initial phase s/w development (re-platform) procurement completed,

contract awarded to BJSS in July, completion in 2014• Approvals in progress to support rapid procurement of replacement

services:• Infrastructure and Managed Hosting• The Appointment Line• Software support• Future Development

• NHS e-RS remains a priority for NHS England, Beverley Bryant, HSCIC and DH

4

NHS e-RS Vision (cont)

• Short animated video which describes the vision

5

NHS e-RS Vision

NHS e-RS Vision

9

Introduction: Initial Phase Software Dev

• The presentation will cover:– Project Objectives– BJSS Agile Approach– Architecture Principles– Development Structure

10

Initial Phase – Project Objectives

• Develop a replacement solution for the Choose and Book service:– Functionally broadly equivalent replacement, with the addition of

Any to Any and APIs– Removing the dependencies on Cerner’s Millennium product and

Intellectual Property Rights – Minimal business change to avoid the need to re-train current

users– Enables new and emerging requirements from the NHS e-RS

Roadmap to be met in the future– The replacement approach aspires to be low risk, and minimises

total cost of ownership– Develop a Collaborative working relationship – Agile Delivery Approach– Live before the end of 2014

11

Initial Phase – BJSS Agile Approach

12

Initial Phase – BJSS Agile Approach

13

Initial Phase – Emphasising Collaboration

14

Initial Phase – Architecture Principles

• Develop solution based on Open Source technology products which are well-known, proven, widely used and adequately supported

• Implement loose-coupling and separation of concerns• Adopt open standards where possible• Re-use components where practical• Design and Develop the Solution for:

– Multi-channel consumption– Security– Operational simplicity– Flexible scaling– Resilience

• Adoption of NHS Data Standards as appropriate (e.g. NHS Number)

15

Initial Phase – Development Structure

• Series of Sprints consolidated into 3 Major Releases• Major Release 1 will development basic referral functionality• Major Release 2 will continue the referral workflow including

integration• Major Release 3 will deliver the finishing touches including reporting

and service exposure via API• Testing windows at the end of each major release including

integration, volume and performance, user and partner testing

16

Stakeholder Design Council

• As the vision outlines we want to build a service with users and patients

• To ensure we engage fully with stakeholders we are setting up a Council to bring together in one forum, representatives from a diverse range of backgrounds

• The Council will:• review and assess existing and proposed system functionality• function as the prime source of debate and discussion to agree future functional

requirements of the service

• We also need to develop how we engage with suppliers – to discuss in part B!

17

Transition Update

• Transition workstreams include:– Data migration– Cutover– Assurance approach– Business Change– Service Model and Non functional requirements

• Initial phase development and procurement are key dependencies• Current integration will not change• Assurance activities, including partner testing will be key• As overall strategy and constituent plans are developed, will engage

further

• Question – how to keep suppliers aware, updated on progress and strategy?

18

Transition - Partner Testing

• Project underway to work with suppliers for integrated partner testing

• Testing windows for partners after Major Releases 2 & 3• Early feedback and involvement from partners/suppliers

to input into the project

BREAK – 10 Mins

20DRAFT: Please do not distribute

Part 2: API Session Intro & Purpose

• Update suppliers on proposed approach for NHS e-RS API functionality to enable suppliers to feedback on proposals and guide implementation

• We recognise that suppliers are key to delivering effective solutions for users and patients

• Supporting SRO vision of a ‘Marketplace’ for user facing solutions.• We will describe the proposed approach for implementing APIs to

support supplier integration and ongoing innovation• We would like you to discuss the approach in breakout sessions and

feedback to the wider group on any and all aspects of the proposed approach


NHS e-RS API Approach

• Feedback from previous Intellect session (Aug 2012) was clear regarding integration with NHS e-RS– suppliers requested richer API to interact with CAB (NHS e-RS); and

– far simpler compliance mechanism

• This feedback has heavily influenced high-level NHS e-RS API approach– separate future NHS e-RS UI from underlying data through set of internal

application services

– our proposal: internal services will be:• wrapped with appropriate authentication and authorisation security mechanism;

and• re-presented to external systems as NHS e-RS API

Note: in theory, every action available in NHS e-RS professional application will be available to external systems


API Business Perspective


API Technical Perspective

• NHS e-RS API will be aligned with emerging HL7 FHIR specification* where possible

– FHIR built upon well defined resources• few relevant: Patient, Organization, …

• many missing: Service, Referral, … – will be defined by HSCIC and submitted into FHIR specification

– FHIR defines RESTful service interface to interact with resources• e.g. http://e-rs.nhs.uk/appointmentRequest/@12345

– Representation of resources in JSON• XML as possible addition

• NHS e-RS will continue to support existing HL7 V3 messages– But not via API - via Spine messaging only

• We need supplier feedback on: – Serialisation format: JSON, XML, or both– Familiarity with (or, appetite to adopt) RESTful API (as opposed to RPC-style

transactional API)

*See http://www.hl7.org/implement/standards/fhir/


API Security – External System Registration

• Two-stage registration mechanism– (Authority-issued) digital certificate for new API-based software successfully

completing development– subsequent authorisation/registration of the certificate by an organisational user


API Security – Authentication and Authorisation

• TLS Mutual Authentication used to identify external system for all API calls

– (Authority-issued) client digital certificate for new API-based software successfully completing development

• Session initiation checks client certificate and user/org details and issues time-limited session user token if org registration checks pass

– Token + client certificate presented on all subsequent API calls

– Individual APIs implement relevant business-level access and legitimate relationship controls


NHS e-RS API Development Ecosystem

• Support materials are required to help suppliers throughout the development lifecycle

– Different materials will support suppliers during different phases– Feedback & suggestions are sought from suppliers as to what materials would be

of most help during the development lifecycle

• Technical documentation– API architecture, API reference, development guide, code samples

• Online support– FAQ, Blogs, Wiki, Tutorials, Forums, Bugs

• Test environments– API sandpit, integration testing

• (possible) Deployment Tool


API – Typical Development Activities


API Assurance

• Supplier feedback from previous Intellect session was for “far simpler compliance mechanism”

• Focus has to be on delivering products users want, and will use.• Current prescriptive compliance is partial response to some early

Choose and Book-related development• not well received by users (e.g. hard coded metadata, poor response times,

displaced appointments)

• However, electronic referrals process now much better understood by supplier market

• Balance needs to be reached between allowing supplier flexibility to develop a product as they see fit, and meaning of any “compliance” statement provided by the Authority

• Please comment and feedback


API Assurance contd.

• ‘Technical Compliance’ (digital certificate)– issued to technically sound API-based solutions (by the Authority)

– flexibility vs. assurance effort trade-off

– need supplier feedback and suggestions on detail:• Performance

• Functional correctness of calls

• Usability & Error Handling

• Avoiding unintended usage patterns

• Managing deprecation & withdrawal of API versions

• Deployment in production environments– Clinical Safety & Information Governance would reside with care provider


We need feedback & suggestions on

• API Serialisation format: JSON, XML, or both• API Design Pattern: RESTful or RPC-style transactional (e.g. XML-

RPC or SOAP)• Proposed API Authentication and Authorisation model• Useful Development Ecosystem support materials• A “compliance” mechanism which delivers products users want and

will use• Do you have an appetite to consume APIs? What is good and bad

about the approach

• Please identify a representative in your group to feedback key messages at the end of the breakout session


Breakout Session – 60 Mins


API Design Pattern (Architectural Style)

REST RPC-style Transactional Other

Serialisation Format

JSON XML Other

The proposed e-RS API Authentication and Authorisation model

Development Ecosystem support materials

“Compliance" Mechanism which delivers products users want and will use

Feedback Session – 40 Mins


Next Steps & AOB

• Optional supplier feedback pro-forma for completion after today’s event, within 2 weeks

• Opportunity to request separate 1-2-1 session – please contact Phil Nixon

• Further engagement…

Thank you for your attendance and input!

34

Contacts

Name: Role: e-mail: Tel:

Ben Gildersleve Programme Head [email protected] 07917 277822

Dr Stephen Miller National Medical Director [email protected] 07973 613467

Matthew Brown Senior Solutions Architect [email protected] 07920 783041

Curtis Zack Programme Manager, Development and Transition

[email protected] 07960 718610

Phil Nixon Programme Manager, Strategy and Controls

[email protected] 07920 246535

35

Follow us on Twitter @nhsereferral

For more information on NHS e-Referral Service see www.hscic.gov.uk/ers

For additional queries, please contact us on [email protected]

nhs e-referral service - market engagement workshop intellect offices - london 2 nd october 2013

Documents

nhs ers activity

nhs ers roadmap

nhs ers plenary approach

nhs ers service update

nhs ers api functionality

nhs ers vision patients

nhs number

nhs england