1. NHS e-Referral Service - Market engagement workshop Intellect Offices - London 2 nd October 2013

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

3. Agenda SessionDurationPresenter Part 1: NHS e-RS Plenary Approach to the day13:30 – 13:35Ben Gildersleve e-Referral Service Update & Vision13:35 – 13:55Ben Gildersleve Initial Phase Software Development13:55 – 14:25Curtis Zack/BJSS Stakeholder Design Council14:25 – 14:30Stephen Miller Transition Update14:30 – 14:40Curtis Zack Break14:40 – 14:50 Part 2: API Update and Workshops Approach to APIs14:50 – 15:15Matthew Brown Alek Radjenovic Workshop breakouts – API Approach15:15 – 16:15Suppliers to lead Supplier feedback to wider group and discussion16:15 – 16:55Suppliers to lead AOB and Close16:55 – 17:00Ben Gildersleve 3

4. 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 visionwww.hscic.gov.uk/ers 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

5. NHS e-RS Vision (cont) Short animated video which describes the vision 5

6. 6

7. NHS e-RS Vision Patients able to choose and book their own follow-up appointments electronically along with alert/reminder advising them when to book.. Follow-up Appointments Commissioning organisations able to determine services that are appropriate to accept self referrals from patients. Patients able to refer themselves into services. Self Referrals A rich reporting function that provides easy access to referral and booking data in meaningful formats. Reporting 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. Electronic Communication

8. NHS e-RS Vision 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. Integration and Usability Enhanced Advice and Guidance functionality and Clinical Request Templates supporting clinical decisions. Commissioners driven Referral Assessment Services. Referral Management Support Consultants able to make tertiary and onward referrals and commissioners being able to assign referrer rights to groups of clinicians and practitioners. Any to Any Ability to link appointments in a care pathway to ensure all take place in a pre-determined order. Linked Appointments

9. NHS e-RS Vision 9

10. Introduction: Initial Phase Software Dev The presentation will cover: –Project Objectives –BJSS Agile Approach –Architecture Principles –Development Structure 10

11. 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

12. Initial Phase – BJSS Agile Approach 12

13. Initial Phase – BJSS Agile Approach 13

14. Initial Phase – Emphasising Collaboration 14

15. 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

16. 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

17. 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

18. 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

19. 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

20. BREAK – 10 Mins 20DRAFT: Please do not distribute

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

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

23. API Business Perspective 23DRAFT: Please do not distribute

24. 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/@12345http://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/ http://www.hl7.org/implement/standards/fhir/ 24DRAFT: Please do not distribute

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

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

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

28. API – Typical Development Activities 28DRAFT: Please do not distribute

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

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

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

32. Breakout Session – 60 Mins 32DRAFT: Please do not distribute API Design Pattern (Architectural Style) RESTRPC-style TransactionalOther Serialisation Format JSONXMLOther The proposed e-RS API Authentication and Authorisation model Development Ecosystem support materials “Compliance" Mechanism which delivers products users want and will use

33. Feedback Session – 40 Mins 33DRAFT: Please do not distribute

34. 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

35. Contacts Name:Role:e-mail:Tel: Ben GildersleveProgramme Headben.gildersleve@hscic.gov.uk07917 277822 Dr Stephen MillerNational Medical Directorstephen.miller@nhs.net07973 613467 Matthew BrownSenior Solutions Architectmatthew.brown1@hscic.gov.uk07920 783041 Curtis ZackProgramme Manager, Development and Transition curtis.zack@hscic.gov.uk07960 718610 Phil NixonProgramme Manager, Strategy and Controls phil.nixon@hscic.gov.uk07920 246535 35 Follow us on Twitter @nhsereferral For more information on NHS e-Referral Service see www.hscic.gov.uk/erswww.hscic.gov.uk/ers For additional queries, please contact us on nhs.ers@hscic.gov.uk