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
Agenda
Session
Duration
Presenter
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 1: NHS e-RS Plenary
Part 2: API Update and Workshops
Approach to APIs
14:50 – 15:15
Matthew Brown
Alek 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
Follow-up
Appointments
• Patients able to choose and book their own follow-up
appointments electronically along with alert/reminder
advising them when to book..
Self Referrals
• 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.
NHS e-RS Vision
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.
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
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 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
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. XMLRPC 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
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
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
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
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]
35