NHS e-Referral Service - Market engagement workshop Intellect Offices - London 2 nd October 2013.
-
Upload
holly-pounder -
Category
Documents
-
view
220 -
download
0
Transcript of 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
6
NHS e-RS Vision
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
21DRAFT: Please do not distribute
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
API Business Perspective
23DRAFT: Please do not distribute
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/
24DRAFT: Please do not distribute
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
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
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
API – Typical Development Activities
28DRAFT: Please do not distribute
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
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
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
Breakout Session – 60 Mins
32DRAFT: Please do not distribute
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
33DRAFT: Please do not distribute
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]