Awarded to ThoughtWorks Limited

Start date: Friday 27 March 2020
Value: £125,000
Company size: large
The supplier will work for NHS England, as part of the Accelerated Access Collaborative (AAC).

User-Centric Development of an Online Health Innovation Platform for the NHS – Alpha

20 Incomplete applications

17 SME, 3 large

40 Completed applications

31 SME, 9 large

Important dates

Published
Thursday 9 January 2020
Deadline for asking questions
Thursday 16 January 2020 at 11:59pm GMT
Closing date for applications
Thursday 23 January 2020 at 11:59pm GMT

Overview

Summary of the work
A supplier is needed to deliver the required user research; develop and deliver wireframes and a demonstrable prototype for an online support tool solution for health innovators and innovation-focused support organisations. This will include prototypes of the ‘front-end’ and ‘back-end’ functionalities of the solution.
Latest start date
Sunday 1 March 2020
Expected contract length
The project is expected to last for 3 months.
Location
No specific location, eg they can work remotely
Organisation the work is for
The supplier will work for NHS England, as part of the Accelerated Access Collaborative (AAC).
Budget range
The expected cost of developing the alpha prototype is maximum £125,000

About the work

Why the work is being done
A 2018 review into the health innovation landscape highlighted a lack of cohesion and unnecessary complexity, with innovators of new products unclear on how to navigate the innovation pathway, from research through to adoption and spread into the NHS. Finding a solution is a top ministerial priority and one of the six key priorities of the AAC.

An enhanced navigation experience for innovators will make it easier for them to receive the support they need to accelerate product development, facilitating NHS uptake of innovative solutions. This will deliver better patient outcomes and support the growth of the Life Sciences sector.
Problem to be solved
The innovation ecosystem is seen as unnecessarily complex and disjointed, with many innovators and other stakeholders finding it difficult to know who can provide them with guidance and support to navigate the innovation pathway. They are unclear as to when they should be engaging with stakeholders and unsure as to incumbent support systems best placed to meet their needs.

Work is required to effectively map the innovation ecosystem and link existing support systems, such as Health Tech Connect and the AHSN Innovation Exchange, into a solution that would act as the ‘single-front door’ to the innovation ecosystem.
Who the users are and what they need to do
Currently, we anticipate two core groups of users:
1. Innovators developing products for the NHS who will use the solution to:
• Navigate a clearer innovation pathway across Health & Care
• Triage products for suitability, need (including access to data) and spread
• Use a single source for information, tools and support to aid progression
• Connect with relevant health system organisations at the right time

2. Health system organisations who will use the solution to:
• View active innovations, saving time in commissioning and development
• Understand innovators and products in the pipeline
• Connect with the wider ecosystem and those innovators requiring support
Early market engagement
As mentioned above, a 2018 review into the innovation ecosystem identified the lack of clarity faced by innovators when navigating the innovation pathway. To consolidate the findings of this review, focus groups were held in mid-2019 to hear first-hand the problems faced by those looking to navigate the innovation pathway. These focus groups helped shape the early hypothesis for the functionality of the solution. As part of the alpha development, significant further user research is planned.

NHSX’s engagement with innovators has also identified three primary pressure points for innovators: commonality of standards; consistent evaluation frameworks and a clear pathway to procurement. Much of these frustrations are borne out of misalignment and lack of cohesive information across the system.

From the perspective of the health system organisations, significant engagement has taken place with key stakeholders contributing to the current innovation ecosystem. This engagement has focused on receiving feedback on the early hypothesis for the functionality of the solution, as well as collating additional information on stakeholders overlooked who could be an important project partner. Continued engagement is essential for this project due to the importance of the solution bringing existing infrastructure together across the health system.
Any work that’s already been done
From early-stage user research and engagement, the AAC formally agreed in November 2019 that the solution should deliver two main components:
1. An open ‘broadcast’ resource focussing on information provision
2. A ‘marketplace’ resource that facilitates the connection of registered users with existing support structures.

The work below is highly relevant to this project:
● Health Tech Connect
● Customer Relationship Management (CRM) systems operated by AHSNs, some purpose-built
● AHSN Innovation Exchange
● Range of information and tools provided by regulators and others across the innovation pathway.

Some organisations plan to link their work into our solution’s development.
Existing team
The ‘Innovation Portal’ is a project lead and managed by the AAC which reports into the AAC Steering Group (chaired by the AAC CEO) and from there into the AAC Board (chaired by Lord Darzi).

The project has an operational working group including team members from many of the organisations which make up the AAC, including NHS England, Office for Life Sciences, NHSX, the AHSNs and NICE. Close connections have been established with the assurance teams within the Government Digital Service (GDS) to ensure that necessary approval is received when progressing through the project lifecycle.
Current phase
Alpha

Work setup

Address where the work will take place
The working group are based across the UK, including in London, Manchester, Newcastle and Leeds. Key governance meetings for the AAC occur in London, typically in Skipton House (Elephant & Castle). Whilst there will be a need to hold regular catch ups to understand how development of the alpha prototype is progressing, there is no expectation that this work needs to take place in London. However, the supplier must be willing to travel to London to hold regular face-to-face catch ups.
Working arrangements
The working group meet on a weekly basis, alongside a more extensive monthly meeting, where other key stakeholders get together to drive forward areas of work identified as a priority.

The supplier will work closely with this team. The team’s focus will be on the development of materials, logic processes and tools relevant to the solution, while guiding the solution’s design and build.

The supplier would be expected to join the weekly and monthly meetings and work closely with colleagues from NHSX to ensure that the Technology Code of Practise is adhered to when developing the alpha prototype.
Security clearance
BPSS is desirable (not essential) as this is the security clearance necessary to enable the supplier to be unescorted in 1 Victoria Street, 39 Victoria Street and Skipton House, the main work areas in London.

Additional information

Additional terms and conditions
N/A at this stage

Skills and experience

Buyers will use the essential and nice-to-have skills and experience to help them evaluate suppliers’ technical competence.

Essential skills and experience
  • Demonstrate (with specific skills and experience) where you have delivered user-centric web-design supported by conducting user research.
  • Demonstrate experience working within health and a demonstrated understanding of the challenges faced by innovators navigating the innovation pathway
  • Demonstrate (with specific skills and experience) experience with management of information governance / intellectual property in complex settings.
  • Demonstrate (with specific skills and experience) of where you have used the Government Service Manual and Technology Code of Practice, delivering APIs to Government Standards - https://www.gov.uk/guidance/gds-api-technical-and-data-standards.
Nice-to-have skills and experience
Demonstrate experience working with, and/or an understanding of the health innovation ecosystem, including the key players within this ecosystem (AHSNs, NICE, government, NHS England etc).

How suppliers will be evaluated

All suppliers will be asked to provide a written proposal.

How many suppliers to evaluate
4
Proposal criteria
  • Clarity of approach and how the approach or solution meets user needs
  • How risks and dependencies have been identified and offered approaches to manage them
  • Team structure, including skills, experience and relevance of individuals
  • Experience of the method of working from previous projects, including a flexible approach demonstrating agile practices
  • Timescales to deliver the project
Cultural fit criteria
  • Demonstrate how you work as a team with our organisation and other stakeholders.
  • Demonstrate how you are transparent and collaborative when making decisions.
Payment approach
Capped time and materials
Additional assessment methods
  • Case study
  • Presentation
Evaluation weighting

Technical competence

70%

Cultural fit

10%

Price

20%

Questions asked by suppliers

1. Was the discovery phase completed internally or by an external incumbent supplier?
The discovery phase was completed internally.
2. Is the budget for this opportunity inclusive or exclusive of VAT?
The budget is exclusive of VAT
3. Is there an incumbent supplier in place?
No. However, a partnership organisation has worked with a supplier with work that is pertinent to this project. Outputs will be shared with the successful supplier.
4. Our question is in relation to the final bullet point of the 'Essential skills and experience' table. We are experienced in working to the GDS standards, having delivered multiple digital products in this manner. We have extensive experience of performing complex systems integrations, for major banks and public sector organisations alike. We also have experience of delivering APIs to government standards, though we have never done this for public sector organisations or the government. Please can you give us your view as to what extent this is likely to count against us in the scoring?
Each of the criteria set out in the DOS case counts towards scoring for the assessment. However, demonstration of relevant skills and experiences will be still be considered if they meet best practice/conform to government standards.
5. Do you require, research, design and development resources from the supplier?
Yes
6. Do you have any resources in those areas in your working group or elsewhere?
No
7. Does the working group have experience of working in an agile way based on the Government Digital Service Standard?
Some do; most of the group does not
8. Can you share your findings from Discovery and the user needs that are in scope for the alpha phase?
Full details will be shared with the appointed supplier. A summary will also be shared with short-listed suppliers.
9. Regarding requirement 4 – Demonstrate (with specific skills and experience) of where you have used the Government Service Manual and Technology Code of Practice, delivering APIs to Government Standards. Would you consider evidence that demonstrates ability to integrate APIs within a health context but not directly to the code above? As a note this requirement prohibits capable suppliers from ever developing the evidence as only previously experience suppliers can meet the criteria. Seems exclusionary.
Each of the criteria set out in the DOS case will count towards scoring for the assessment. However, demonstration of relevant skills and experiences will be still be considered if they meet best practice/conform to government standards.
10. Please can you provide some more detail / qualification on what you mean exactly by a "front-end" and a "back-end" prototype? Clearly this is about the different functionalities that deliver both parts of the solution, but how functional do the prototypes need to be? Perhaps you could use an example to highlight how comprehensive the prototype needs to be in each case?
The front-end will primarily be an information provision website which will not require a log-in to access. This will host a significant range of information which the working group has begun to collate already which is relevant to users of the service (e.g. information on funding opportunities, evidence requirements etc.).

The back-end will be an infrastructure that connects innovators accessing the system with existing support organisations, envisaged as a nationally connected CRM with log-in functionality, allowing innovators to be seamlessly transferred across multiple organisations for support, and for data to be captured on the flow of innovations throughout the system.
11. Is there an incumbent supplier working on this project?
No. However, a partnership organisation has worked with a supplier with work that is pertinent to this project. Outputs will be shared with the successful supplier.
12. We are new to the CCS Roster, so do not have GDS specific experience. Is the team happy to consider examples where the supplier has followed design systems similar to that of GDS in the commercial sector?
Each of the criteria set out in the DOS case counts towards scoring for the assessment. However, demonstration of relevant skills and experiences will be still be considered if they meet best practice/conform to government standards.
13. Research expectations: in the ‘Summary of the Work’ section, it states that the ‘Supplier is needed to do deliver the required user research…’, and in section ‘Who are users and what do they need to do’, it states ‘As part of the alpha development, significant further user research is planned.’ How do these two research elements differ and who will be carrying out the ‘significant further user research section’?
These do not differ. We expect the supplier to support the working group in carrying out extensive user research.
14. Access to existing research: we are assuming this will be made available to the successful supplier at the outset of the project. This includes such references as the ‘2018 review into the innovation echo system’ and any further research thereafter.
Yes, all relevant information will be shared with the successful supplier
15. Given the project is now at ‘Alpha’ stage we are assuming it has successfully passed the GDS Discovery gate. Will the winning supplier be able to see the comments made by the Discovery gate review team at the start of Alpha to help with planning and identification of further potential research activities, where appropriate?
Yes, all relevant information will be shared with the successful supplier
16. Can you provide further clarification around what is mean by ‘front-end’ and ‘back-end; functionalities of the solution? Is this a proxy for pre- and post-login states for example?
The front-end will primarily be an information provision website which will not require a log-in to access. This will host a significant range of information which the working group has begun to collate already which is relevant to users of the service (e.g. information on funding opportunities, evidence requirements etc.).

The back-end will be an infrastructure that connects innovators accessing the system with existing support organisations, envisaged as a nationally connected CRM with log-in functionality, allowing innovators to be seamlessly transferred across multiple organisations for support, and for data to be captured on the flow of innovations throughout the system.
17. Output fidelity for prototype: given this is a prototype our working assuming would be that this doesn’t need to be given full visual design treatment and is not built in code. Can you confirm this is the case/advise otherwise?
We do not expect a prototype to be fully coded at this stage. However, we do expect well developed visuals which accurately demonstrate the functionality that will be provided to end users.
18. Will the prototype need to be constructed to adhere to NHS design framework component guidelines or is there flex in this respect?
The prototype will not be expected to adhere to the NHS design framework component guidelines. However, we expect the design to adhere to GDS standards.
19. Will the prototype need to be built for a single device view e.g. desktop or will cross-device designs be required for this stage i.e. desktop, tablet, mobile?
We expect the prototype to be built for multi-device, with a mobile-first approach.
20. Will the NHS team be able to support and help provide stakeholder user contacts for potential recruitment for research and prototype user testing?
Yes
21. Will ‘subject matter experts’ be available to answer questions as they arise which the team may have outside of the defined weekly catch-ups etc. to support with ongoing project activities etc.? And, would this be subject to any formal SLA, for example?
Yes, subject matter experts will available but this would not be formalised within an SLA.
22. In the ‘Any work that’s already been done’ section, bullet 4 references the fact that there’s a ‘Range of information and tools provided by regulators and others across the innovation pathway’ as being relevant and therefore information we would logically wish to refer to if successful. Can you give a sense of the size/types of information this body of reference material may contain?
The envisaged content will encompass large quantities of content from sources across the innovation ecosystem, including: copy, publications, videos, infographics, embedded content, signposting to other services and more.
23. In the user section you talk about 2 core user groups. Do you have any user personas for these groups for us to refer to, or is this something you might be looking for as part of this alpha project delivery?
We do not have defined user personas. It is up to the discretion of the successful supplier on whether to create user personas to support user research.
24. Whilst the title of the project and majority of references to it in the brief refer to ‘Innovation Platform’, the words ‘Innovation Portal’ is also used (‘Opportunity attribute name’), is this something different or are they one and the same?
They are one and the same
25. In the ‘Early Market Engagement’ section, the anticipated solution is identified as comprising of 2 main components, one of these being a ‘marketplace’ resource for registered users. Is the means by which users will be registered already defined or will we need to define the registration and sign-up experience as part of this overall prototyping activity?
This needs to be defined as part of the prototyping activity
26. API design/delivery: under essential skills it states ‘experience of delivering APIs to Government Standards’. Will this phase of work include the design of a working API?
Yes, this work will include the design of new working APIs.
27. Can you please outline your timeline for the additional assessment, following shortlisting?
Supplier presentations are scheduled for 6th February at NHSE London Location
28. Can you please describe what roles you expect the AAC and the operational working group will provide for this project?
Project management, weekly working groups, development and curation of content, briefing, advice, steers, stakeholder engagement access etc.
29. Do you have in mind any particular technology choices at this point? Or do you expect this will be established throughout the alpha?
No technology preferences exist. However, we expect the design to adhere to GDS standards.
30. Have any technical decisions been made around development stack and hosting?
No technical decisions have been made, but we expect developers to adhere to GDS standards and use open source technology, including open source code and outputs.
31. Are the 2 intended audience streams internal to the NHS / external innovation partners or a mix of both?
They are a mix of both.
32. Can we assume that we can meet with one or two end users?
As part of user research it is assumed that many end users will need to be involved.
33. Is there an existing map of the innovation ecosystem?
There's a good understanding of the key stakeholders in the innovation ecosystem. However, further work needs to be done to understand the roles & responsibilities of each organisation in relevance to the others.
34. Do you have a preference with regards to tech to be developed in?
No technical decisions have been made, but we expect developers to adhere to GDS standards and to use open source technologies, including open source code and outputs.
35. Do you have a considered view on the breakdown of effort between research and development? Do you foresee the research extending beyond the initial phase of development?
Preliminary research into the requirements of the Portal has been undertaken. However, there is a requirement for further detailed research into how the system will be used to inform ongoing design and development.
36. Are you expecting the supplier to source the research candidates or would these be provided?
While we are happy to provide support, we would consider this to be part of the role of the supplier
37. Is there a preferred research methodology? Guerrilla / lab / focus groups
We will expect the supplier to consider a mixed-methodology approach, using the most appropriate methodologies for conducting research on specific user groups and specific proposed functionality of the service.
38. Are you able to share the output of previous research?
Yes, all relevant information will be shared with the successful supplier
39. What resources are in place internally within the NHS to own this product?
There is a small working group comprised of c.7 members of organisations who are core to the project (NHSE, OLS, NHSx, AHSNs etc.)
40. Are travel expenses to London reimbursable?
No