Trainee information system - Delivery partner for Alpha development using Low/No Code platform

Description

Summary of the work At HEE's National School of Healthcare Science we need to modernise the way that we manage the extensive data we keep about trainees on our programmes. We are looking for a delivery partner to develop an Alpha to determine the viability of developing a system via a low/no code platform. Expected Contract Length 2-3 months in the first instance Latest start date Monday 3 October 2022 Budget Range Up to £75,000 Why the Work is Being Done At HEE's National School of Healthcare Science (NSHCS) we need to modernise the way that we manage the extensive amount of data that we need to keep about healthcare science trainees on our training programmes. Data about trainees' assessments and progression on programmes, and data about trainees in difficulty, needs to be managed in a much more streamlined and efficient manner than it currently is. We have conducted an extensive Discovery that has produced detailed findings about user needs and a range of valuable outputs to inform the next stage of the work. Our Discovery recommended that we work with a delivery partner to develop a proof of concept to determine the viability of developing a trainee information system via a low code / no code development platform. We are looking for a delivery partner to work with us to develop a proof of concept through to the end of the Alpha stage, in the first instance. Problem to Be Solved The NSHCS manages many different aspects of the education and training of over 2000 active trainees on various NHS healthcare science training programmes. Some key trainee information is maintained on a database developed in-house several years ago, and yet other critical trainee information, particularly 'case' information about trainees in difficulty, is maintained very manually outside of this system. This set up is no longer viable or efficient. Some of our highest priority user needs include: As member of school staff I need: - to view and maintain all evidence about a trainee in one location so that the School can make important decisions with robust data that is not fragmented and/or duplicated across multiple places - to search for trainees by specific attributes (e.g. trainee status, location, specialism, programme) so that I can instantly access all trainees relevant to my particular enquiry - to access high-level summaries about the trainee data collected so that I can get an instant overview of the information available (e.g. quick stats) - to update the assessment and progression review data of a trainee so that their training performance is accurately recorded by the School. Who Are the Users The initial and principal users of the system are members of NSHCS staff. Some will need to maintain and update data (data processors); others will simply need to locate and view data (data seekers). Some core user needs are listed above. Most of these are of this nature: As a 'data processor' I need to update information about a trainee and their progress So that the School has accurate information about trainees in one location in order to advise and support trainees to complete their training programme. As a 'data seeker' I need to locate key, up-to-date information about a trainee or a group of trainees in one location So that the School can make appropriate decisions about trainees in order to advise and support them to complete their training programme. For the Alpha we are proritising the needs of School staff. The roadmap for the service within the Beta stages includes development to bring in 'trainee self-service' to meet such needs as: As a trainee I need to submit personal data requested by the School (e.g. name, contact details, demographic information) So that the School has an accurate record of myself as one of their trainees Work Already Done A comprehensive Discovery has been conducted to understand users’ needs Discovery outputs include: - A substantial report summarising the work and its findings, including case studies of organisations with similar needs, technology recommendations, recommendations about valuable Alpha experiments - A backlog of validated and prioritised user needs - A set of proto-personas - A future service blueprint - A set of (tested and iterated) concept prototypes - A matrix of technology options - A full set of interview transcripts and research notes covering all discovery activities The Discovery report can be found at: https://nshcs.hee.nhs.uk/publications/discovery-report-nshcs-trainee-data-management-system-discovery/ Existing Team - Within the NSHCS Digital team we will have a nominated Product Manager as initial point of contact, continuous collaborator and translator of user needs - Two additional members of the School's Digital Team will support the Product Manager, participate in all key meetings, co-ordinate and conduct testing - We will have good access to our principal users - NSHCS staff members - who will engage in comprehensive testing and provision of feedback Current Phase Alpha Skills & Experience • Demonstrate expertise in managing the complete Alpha process, including building and user testing prototypes. • Demonstrate ability to successfully run complex digital projects through their life cycle including Alpha, Beta, Live and Retirement. • Demonstrate excellent information architecture skills. • Understand and be committed to helping the project meet the NHS Service Standard. • Understand and be committed to the confidentiality, data protection, and data and system security standards in use within government and the NHS. • Provide evidence of expertise in accessibility, specifically WCAG compliance • Demonstrate experience of rapid application development using low/no code platforms • Provide evidence of capabilities to engage with users via quantitative and qualitative user research and testing throughout the development process, including running user research workshops. • Demonstrate robust risk management processes. • Demonstrate robust financial management processes. Nice to Haves • Demonstrate experience of health sector digital service provision • Demonstrate experience of education and training sector digital service provision Work Location We expect that much of the work will be done remotely. The NSHCS Digital Team are based in Birmingham, where we have very central offices beside New Street station and this would be our preferred location for any necessary face-to-face activity. Our principal users, NSHCS staff, are overwhelmingly based in and around Birmingham and can easily participate in live user testing and feedback sessions in the Birmingham office, if required. Working Arrangments We want the supplier to take a flexible approach rather than working for set times in a set office. We expect that the majority of the work will be done remotely, although we will want to build up a relationship in person in the beginning. We will want the team to work on dedicated, pre-planned and pre-approved activities with planned outcomes. We expect to participate fully with the supplier in sprint and review meetings. No. of Suppliers to Evaluate 4 Proposal Criteria • Understanding of the brief • Proposed solution • Approach and methodology • How the supplier will ensure that they meet user needs • Estimated timeframes for the work • How the supplier has identified risks and dependencies and offered approaches to manage them • Proposed team structure • Value for money Cultural Fit Criteria • Work as a team with HEE and other suppliers. We will seek evidence for an inclusive approach and a willingness to co-operate/collaborate, with practical mechanisms suggested to achieve this. • Be transparent/collaborative when making decisions. Cover the decision-making process, set out the role of the key team members and the mechanisms by which the processes will be adopted. • Take responsibility for their work. We would expect the supplier’s proposal to show evidence of process for setting quality standards for their own work. • Share knowledge and experience with other team members and HEE. Proposal should show how information and knowledge is captured, shared and interpreted, in terms of day-to-day activity and longer-term reporting. • Work with clients with low technical expertise. Supplier should explain how they bridge gaps between technical expertise of their team and the knowledge of the HEE team and stakeholders. • Demonstrate ability to facilitate both parties to learn from each other, and how full implications of any specialised technical discussions can be clarified to key team members including Service Owner. Payment Approach Fixed price Assessment Method Presentation Evaluation Weighting Technical competence 60% Cultural fit 20% Price 20% Questions from Suppliers 1. Is the maximum budget of £75,000 including or excluding VAT? The maximum budget of £75,000 is exclusive of VAT. 2. Can you please clarify with wording of the 2nd Nice to Have criteria? The 2nd nice-to-have criteria, as published is:'Demonstrate experience of education and training sector digital service provision.'To clarify: we are interested to know whether potential suppliers have experience of developing digital services for use in an educational context, particularly by learners, educators or education programme managers 3. Does the budget include licence costs? Yes, we anticipate that the budget will cover licence costs. 4. Do you have a low-code software platform in mind already? No. We would expect potential suppliers to propose an appropriate platform. In doing so we will want to be very clear about exportability of code, ownership of IP and how to avoid platform lock-in. We would anticipate that potential suppliers should make a powerful case for the platform they propose. 5. Please can you clarify what you mean by ‘robust financial management processes’ and the reason for the question? It’s quite a broad topic and we want to specifically answer your concerns. We simply want to know what you will have in place to ensure that costs are being looked at, looked after and reported so that there are no surprises at key points in the project and that we are receiving value for money. We appreciate that this is a broad topic and we don't have a list of sub-headings for you. We will be happy to receive a brief summary of how you will manage the budget. 6. Could you please provide us access to the artefacts delivered in the Discovery phase which are listed in Annex 2 section of the report? Apologies, but we are not able to share these right now. We will happily share them with the 4 shortlisted applicants that we progress to the next stage of this process. 7. Could you please explain what you define as excellent information architecture skills? We are looking for a thoughtfulness and care from applicants about how information is presented, structured and navigated on the front-end so that it can be navigated, worked with and manipulated smoothly by users. And we are definitely looking for an attentiveness to how data should be organised in the back end so that the data model is sustainable and extensible into the future. 8. Will records require files / images to be uploaded as well as just data (e.g. certificates, test transcripts, images, attachments)? (Affects platform / data costs) Yes. We anticipate that the part of the system via which we manage cases of trainees in difficulty will require files to be uploaded, so that all of the information about the 'case' is held in one place. 9. How many students are active at any one time? The HEE website says 160,000 and the discovery report says around 4000 (Section 2.2.2) Currently, approximately 2000 trainees are active at any one time. We have records about approximately 4000 healthcare science trainees on account of having approximately 2000 alumni of our training programmes. We have some important decisions ahead of us about whether the system we build should hold alumni data after trainees complete their training programme. 10. Could you please provide clarity on the anticipated number of users and any variance in roles and usage needs? We were not able to establish from the Discovery outputs. Users: inside the National School we would have approximately 20 editors of data (data processors) and 30 readers of data (data seekers). Beyond Alpha we intend to develop the system so that trainees can view some of their key data (e.g. assessment outcomes) and update a small amount of key data (e.g contact details). At any one tiem we anticipate there being approximately 2000 active trainees on training programmes. 11. IN your answer to Q4 you indicate that you’re expecting a supplier to advocate for a specific low/no-code solution – but one of the major objectives of an Alpha phase is to determine what the right technology solution is, and that should (in this case) entail proof-of-concept work with a number of candidate solutions, not just one, so that a recommendation can be made in terms of how to proceed to Beta. Can you confirm this is what you’re expecting? We will be open to a supplier conducting proof-of-concept work with a number of candidate solutions in order to produce a recommendation about how to proceed to Beta. This might even be proof of concepts in 'competing' low/no code platforms. If you look at the Discovery report we have published, you will see that it recommended Alpha experiments in low/no code and with a CRM-based solution. 12. Based on the learnings from Discovery (which you’ve clarified you’re not able to share yet) could you please indicate the broad types of solution you’d consider to be candidate low code / no code platforms at this stage? We have published the learnings from Discovery. They can be found at:https://nshcs.hee.nhs.uk/publications/discovery-report-nshcs-trainee-data-management-system-discovery/Rather than indicate the broad types of solution that we would consider to be candidate low/no code platforms, we would prefer applicants to persuade us about their choices and preferences and strengths in this area. As we indicate in the tender information, we need to be convinced that the platforms provide us with good exportability and ownership and onwards extensibility of the code developed and with good measures that mean we are not locked in to a specific platform. 13. Can you confirm this project will be available across multiple devices or will there be limitations? The majority of admin and editor users of the system will use it on laptops and desktops but we would also expect the system to perform well and enable some useful views of information on mobile devices. 14. Will it be created for specific device types? For example: desktops and phones The majority of admin and editor users of the system will use it on laptops and desktops but we would also expect the system to perform well and enable some useful views of information on mobile devices.