2 nd October 2013

• 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

Session
Part 1: NHS e-RS Plenary
Approach to the day e-Referral Service Update & Vision
Initial Phase Software Development
Stakeholder Design Council
Transition Update
Break
Part 2: API Update and Workshops
Approach to APIs
Workshop breakouts – API Approach
Supplier feedback to wider group and discussion
AOB and Close
Duration Presenter
13:30 – 13:35 Ben Gildersleve
13:35 – 13:55 Ben Gildersleve
13:55 – 14:25 Curtis Zack/BJSS
14:25 – 14:30 Stephen Miller
14:30 – 14:40 Curtis Zack
14:40 – 14:50
14:50 – 15:15 Matthew Brown
Alek Radjenovic
15:15 – 16:15 Suppliers to lead
16:15 – 16:55 Suppliers to lead
16:55 – 17:00 Ben Gildersleve
3

• 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

• Short animated video which describes the vision
5

6

Follow-up
Appointments
Self Referrals
• Patients able to choose and book their own follow-up appointments electronically along with alert/reminder advising them when to book..
• Commissioning organisations able to determine services that are appropriate to accept self referrals from patients.
Patients able to refer themselves into services.
Reporting
Electronic
Communication
• A rich reporting function that provides easy access to referral and booking data in meaningful formats.
• Use of modern technology - mobile phone Apps, e-mails, text reminders etc, to support different ways of communicating appointment-related information to patients and system alerts to professional users.

Integration and
Usability
• A more intuitive system with a modern look and feel that will support the seamless transfer of referral information from GP clinical systems into provider systems.
Referral
Management
Support
• Enhanced Advice and Guidance functionality and Clinical
Request Templates supporting clinical decisions.
Commissioners driven Referral Assessment Services.
Any to Any
• Consultants able to make tertiary and onward referrals and commissioners being able to assign referrer rights to groups of clinicians and practitioners.
Linked
Appointments
• Ability to link appointments in a care pathway to ensure all take place in a pre-determined order.

9

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

• 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

12

13

14

• 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

• 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

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

• 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

DRAFT: Please do not distribute 20

• 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
DRAFT: Please do not distribute 21

• 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
DRAFT: Please do not distribute 22

DRAFT: Please do not distribute 23

• 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/
DRAFT: Please do not distribute 24

• 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
DRAFT: Please do not distribute 25

• 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
DRAFT: Please do not distribute 26

• 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
DRAFT: Please do not distribute 27

DRAFT: Please do not distribute 28

• 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
DRAFT: Please do not distribute 29

• ‘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
DRAFT: Please do not distribute 30

• 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
DRAFT: Please do not distribute 31

API Design Pattern (Architectural Style)
REST RPC-style Transactional Other
Serialisation Format
XML Other JSON
The proposed e-RS API Authentication and Authorisation model
Development Ecosystem support materials
“Compliance" Mechanism which delivers products users want and will use
DRAFT: Please do not distribute 32

DRAFT: Please do not distribute 33

• 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…
34

Name:
Ben Gildersleve
Dr Stephen Miller
Matthew Brown
Curtis Zack
Phil Nixon
Role:
Programme Head
National Medical Director e-mail: ben.gildersleve@hscic.gov.uk
stephen.miller@nhs.net
Tel:
07917 277822
07973 613467
Senior Solutions Architect matthew.brown1@hscic.gov.uk
07920 783041
07960 718610 Programme Manager, Development and
Transition
Programme Manager, Strategy and
Controls curtis.zack@hscic.gov.uk
phil.nixon@hscic.gov.uk
07920 246535
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 nhs.ers@hscic.gov.uk
35