1 / 35

NHS e-Referral Service - Market engagement workshop Intellect Offices - London

NHS e-Referral Service - Market engagement workshop Intellect Offices - London. 2 nd 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

carnig
Download Presentation

NHS e-Referral Service - Market engagement workshop Intellect Offices - London

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. NHS e-Referral Service -Market engagement workshopIntellect Offices - London 2nd 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

  3. Agenda

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

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

  6. NHS e-RS Vision

  7. NHS e-RS Vision

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

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

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

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

  22. API Business Perspective DRAFT: Please do not distribute

  23. 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 RESTfulservice 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) RESTfulAPI (as opposed to RPC-style transactional API) *See http://www.hl7.org/implement/standards/fhir/ DRAFT: Please do not distribute

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

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

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

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

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

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

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

  31. Breakout Session – 60 Mins DRAFT: Please do not distribute

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

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

More Related