KRAD7804 - Electronic Care Plan App Re-Build (Xamarin to cross platform single codebase)

Description

Summary of work Sanctuary requires the re-build of an in-house custom developed Electronic Care Planning, known as kradle, iOS app which is in active use in approx. 100 Residential and Nursing Care Homes. It requires rebuilding due to Xamarin.iOS becoming an unsupported platform in 2024. The app is to be rebuilt maintaining the existing user interface (UI) design, only allowing for changes driven by the technology move. The app must be re-built in a cross-platform framework such as Flutter. Business outcome success will be realised by the move to a current and future-proofed platform with minimal (preferred zero) downtime and familiarity of UI that requires no additional training. Where the supplied staff will work West Midlands Where the supplied staff will work No specific location (for example they can work remotely) Why the work is being done kradle holds, maintains, and manages care plans that are required for the health and wellbeing of residents and regulated by the Care Quality Commission. The application which needs to be re-built consumes a hosted API which is based on a framework that is soon to come "End of Support" by Microsoft in May 2024 (Xamarin.iOS). The App is currently used across one hundred Care Homes and across five thousand Staff. Therefore, we need the App how it currently functions, to be rebuilt onto a framework that will continue to be supported and preferably gives us interoperability across multiple platforms. The business problem Care staff within Sanctuary Care homes must be able to read and update real-time care plans through the continued use of "Electronic Care Planning" beyond May 2024. It must not require re-training of end users which requires maintaining a look and feel like the current in-use App. It ensures longevity and device independence requiring it to be built on a modern cross-platform framework and must be able to be installed and concurrently used on multiple device platforms (e.g., Android and iOS). The people who will use the product or service User type: Care giving staff Definition: Any Care Staff that are "on-shift" within the Sanctuary Care homes would typically the app to record the delivery of Care at "Point of Care" for Sanctuary Care's residents. This would mainly be "Care Assistants" however, this could also be agency, nurses, team leads, home managers, etc. Any pre-market engagement done Limited engagements have been held with suppliers to enable Sanctuary to validate approach, timescales, and budget. Challenges have been made to offline capabilities, web app or progressive web app, review and redesign of user interface and redevelopment of API and database. The app will remain with offline capabilities however this will remain in review dependant on the ability to drastically improve its current technical design. The API layer will not change unless it impacts the critical path, and the user interface will not be re-designed. Any materials made available in pre-market discussions have been made available. Work done so far The App already exists in Xamarin and is in a production, as such we don’t need the R&D of app improvements, UX or KPI approach to how the app is used, it is a "known" state and business process. We already have the requirements and specification of how the app should and will work. Which phase the project is in Discovery Existing team Software Development Team, the team pre-exists and maintains the product as it is today across the entire stack, (Database, API, and Frontend). The skillset is full stack but with an emphasis on .NET/C#. Supported by internal product teams and extra technology capabilities. Address where the work will be done A mixture of Sanctuary House, Chamber Court, Castle St, Worcester WR1 3ZQ and remote. Working arrangements Work will involve the close on-boarding and discovery phase to stand up any supplier sufficiently with the knowledge of how the app works and the specifics of the back end and its frameworks or gotcha's. The development team can work remotely but also visit suppliers for milestone examples. Supplier should be prepared for some face to face at Sanctuary's headquarters. Each "Screen" developed of the app should go through a review and a "show and tell". Transition back to the Sanctuary development team should be planned and proposals of approach are sought through this process. Everyday expenses are to be included in the supplier cost, any special circumstance expenses must be pre-approved by Sanctuary and will be subject to the Sanctuary expenses policy. Security and vetting requirements No security clearance needed Latest start date 5 February 2024 Expected contract length Contract length: 2 years 0 months 0 days Optional extension: 1 years 0 months 0 days Budget Indicative maximum: £350000 Indicative minimum: £90000 Further information: The budget is expected to allow for headroom to enable the procurement of additional services. These services enhance the delivery but are not core to the delivery and therefore are to be counted as extra to the core delivery. These services will fall outside of the agreed services that are required to replicate the products style, usability, and functionality. The detailed definition of core service will be defined in collaboration between the customer and supplier. The additional services will enhance the overall product and not impact the analysis, development, testing, transition and hypercare of the product. The delivery team should be scaled appropriately to release the product in line with the deprecated timelines of Xamerin.ios. Contracted out service or supply of resource? Contracted out service: the off-payroll rules do not apply Terms and acronyms Term or acronym: Cross Platform App Definition: a single source code to deploy across multiple platforms e.g. iOS and Android Term or acronym: Flutter Definition: Platform Development language by Google Term or acronym: ReactNative Definition: Cross Platform Development language by Facebook Questions and Clarifications 1. Hi, you have specified a minimum budget of £90,000 and a maximum budget of £350,000. How much of the maximum budget would be allocated to the engineering of the replacement app, versus for example support costs for the new app? Would you expect the engineering of the app to last for the full 24 months duration listed in the Statement of Requirements, or just for a portion of the time? We require the rebuilt app to be deployed by the deprecation of support date of Xamerin.ios or within 90 days post that date. The contract has the extended timeline to 24 months in order to enable the ability to approach any key developments that may be required to be added to the app but can not be achieved during strict deployment window. The proposal should factor the resources required to meet this timeline, to provide hypercare and to transition to the internal development team. It is understood that developments required but unknown at this stage may require agreed variations to the statement of work. Last Updated : <strong>05/12/2023</strong> 2. 1. Do you have a design system in place for the app / website?  2. Will the app development team be all external developers (i.e. the supplier) or do you intend to augment the project team with Sanctuary Housing's internal developers? 3. Is it intended that the project be delivered before the end of life date for Xamarin (1/5/24)?  4.What will the project team look like from Sanctuary Housing? Who will have the ultimate sign off throughout the stages of the project? 5. What do you envisage as additional services outside of the core delivery? i.e. support services? 1. Not strictly, we use common design elements on the website that adhere to the same spacing/colouring principles, but as this is about building a like for like app, there shouldn't be a design system constraint. 2. Ultimately an external development team, there will be a lead at Sanctuary who will be engaged and updated via milestones. 3. We require the app to be released either before the deprecation of support date for Xamerin.ios or with 90 days post that date. 4. We have a technical lead and project management; this is internally and aimed at a "stakeholder" level. The sign off will ultimately be the technical lead at Sanctuary alongside stakeholders in Care who will sign off UAT. 5. The options of support services, design services and full stack development services. Last Updated : <strong>05/12/2023</strong> 3. Would you be open to having a team based partly in the uk, partly near-shore for this project? Yes, we are happy with that however we do ask that when required resources are available within core UK working hours and that data is not removed from sovereign locations without prior assessment and agreement. Last Updated : <strong>05/12/2023</strong> 4. 1. We would be looking to convert the existing code from Xamarin to Microsoft MAUI (Multi-Platform App UI) and not use ReactNative or Flutter, both of which would require a total rewrite. However, MAUI is not mentioned as an example in the ITT so we want to be sure that MAUI is an acceptable approach? 2. In our experience offline work is usually carried out using a local on device SQLite database. Is SQLite used for this system or is it just using a memory cache for offline working? 3. Is Kradle currently deployed to users through the app store, or via other means such as Microsoft Intune? 4. Would it be possible to get a copy of the source code for the Xamarin app as this would enable us to do a more accurate, and likely lower, estimate for the conversion to MAUI? 1. The framework was not previously built on Xamarin Forms where MAUI is a direct line upgrade, but actually as a native app in Xamarin.iOS Therefore it will ultimately need a large re-write. As such, in terms of market trends, we have leant towards the market leading stack which is Futter/ReactNative. 2. It's actually memory cache, there no persisted state such as SQLite, though it was considered early doors, 3. Correct, it's not via the app store at all, but via code signed. IPA's that are distributed via Intune and Mobile Iron, (soon to be entirely by InTune) 4. No, we will not be sharing the source code at this stage. Last Updated : <strong>05/12/2023</strong> 5. Does the budget include an expected support period, if so what is the support period and what is the SLA? (e.g. Service desk hours, response times, etc) Yes, the budget does include hypercare for which the SLA would be agreed with the successful party and dependent on issue type. Last Updated : <strong>05/12/2023</strong> 6. The template for the response document only includes 1 box each for ‘essential skills’ & ‘nice-to-have skills’ - Can we assume that it is 750 characters per question? The procurement team have advised that the Buyers Guide states "Suppliers are requested to provide an individual response against each of your questions. Each response should not exceed 750 characters in length (the equivalent of about 150 words). You have the discretion to exclude any supplier who exceeds this limit, or to evaluate only the first 750 characters of their response". Last Updated : <strong>05/12/2023</strong> 7. Does the current app use any third party components/can we get a list of any with a brief summary of what context they’re used? Not really appliable, no 3rd party apps/frameworks to be considered here other than it's a standard Xamarin.iOS MVVM project, we've not included many other libraries in the app. Last Updated : <strong>05/12/2023</strong> 8. You mention Flutter & ReactNative - have you considered .net MAUI as an alternative cross platform technology for the rebuild? The framework was not previously built on Xamarin Forms where MAUI is a direct line upgrade, but actually as a native app in Xamarin.iOS Therefore it will ultimately need a large re-write. As such, in terms of market trends, we have leant towards the market leading stack which is Futter/ReactNative. Last Updated : <strong>05/12/2023</strong> 9. For Q7, can you clarify whether you mean things such as setting up release pipelines, creating testing infrastructure and tooling, or something else? Yes, setup of general development infrastructure, to compile/build a product in frameworks such as Flutter/ReactNative with the typical development components such as release/pipeline/testing/code and references etc. Last Updated : <strong>05/12/2023</strong> 10. Are you looking for the rebuild to be completed fully by a supplier team and then handed over, or do you envisage the in house team working with the supplier to deliver the project? Ultimately looking for a supplier team to fully build and handover with some technical lead involvements such as milestone reviews etc. Last Updated : <strong>05/12/2023</strong> 11. Will support of the app be done in house following the completion of the rebuild? If so, will the capabilities of the current in house team influence technology choices for the rebuild? Support will be done in-house following the completion and handover of the app. The team is currently the technical authority for the app, so yes the team would influence technologies/frameworks and libraries alike. Last Updated : <strong>05/12/2023</strong> 12. Can you clarify how you anticipate the 2-yearr contract to be split, e.g. how long do you anticipate the build phase for this to be? Does the stated budget include the 1-year potential extension? Th expectation is that the app rebuild is completed by, or within 90 days after, the end of support of Xamarin.iOS. The 2 years is to allow for any additional work that is identified as requiring to be carried out within the rebuild. The 1 year is in addition and relates directly to the post initial rebuild work. Last Updated : <strong>05/12/2023</strong> 13. How have you approached estimating the rebuild to date?  This has been identified through the pre-market engagements carried out. Last Updated : <strong>05/12/2023</strong> 14. Is 'stage 1' the response needed by 11th December? Yes Last Updated : <strong>05/12/2023</strong> 15. Is 'stage 2' the response then needed by 3rd January? Will there be any other questions outside of what's been published already to answer as part of stage 2? The exact format of stage 2 presentations will be shared with companies successful in stage 1. Bidders should expect it to include, but not be exclusive to, approach, architecture and recommendations, test management, hypercare, additional services and cost breakdown (core and optional). Last Updated : <strong>05/12/2023</strong> 16. Can you provide the templates for the stage 2 response now, so that we can ensure we're able to provide the right information in the right format ahead of time? Specifically: a) Does each section have the same 750-character limit as per stage 1? b) Does the cost proposal have to be in a certain format?  The exact format of stage 2 presentations will be shared with companies successful in stage 1. Bidders should expect it to include, but not be exclusive to, approach, architecture and recommendations, test management, hypercare, additional services and cost breakdown (core and optional). Last Updated : <strong>05/12/2023</strong> 17. Are the 'additional assessment methods' on p.9 of attachment 1 an exhaustive list of the information also required as part of stage 2? If not, what else will be required outside of these things, the cost proposal, and answers to the stated questions?  We expect it to be likely that clarification discussions post presentation are likely to be required. If this is required, they will follow a template format for all engagements. Last Updated : <strong>05/12/2023</strong> 18. Can we reference sections in the cost proposal for stage 2 answers, or will we have to provide separate answers with a character limit as per stage 1?  Yes, you can reference other sections in your presentation. Last Updated : <strong>05/12/2023</strong> 19. Do you know the specific business requirements for caching or offline use of Kradle?  It is listed as a requirement by the operational team for business continuity. Last Updated : <strong>05/12/2023</strong> 20. Will we have the chance to talk directly to the Sanctuary team as part of stage 2 to ask any further clarification questions?  Successful stage 1 candidates will be provided an opportunity for further clarification immediately post announcement of proceeding to stage 2. Last Updated : <strong>05/12/2023</strong> 21. Thanks for sharing the API, it gives us an idea of the endpoint and core features for each objects. Can you confirm your internal team is responsible for maintaining it? Yes, this is maintained by the internal team. Last Updated : <strong>05/12/2023</strong> 22. Can you confirm we should exclude any backend changes and assume the API will remain identical? Yes, but we will be open to recommendations for improvements post rebuild. Last Updated : <strong>05/12/2023</strong> 23. Would the team supporting the API be available during the rebuild to answer any question or troubleshoot issues? Yes, the internal team will be available. Last Updated : <strong>05/12/2023</strong> 24. Who owns and controls access to the App Stores? It is deployed through InTune. Last Updated : <strong>05/12/2023</strong> 25. In terms of release and launch plan, are you expecting a direct switchover for all users by overwriting the existing app on the stores, or a gradual approach, releasing a new codebase and asking the users to download the "new" app?  We use InTune as an MDM rather than the app store, so we will likely push the app out as we see fit to devices. If the app is working cross-platform successfully from go live, we may simply push out as a large upgrade to all devices. Last Updated : <strong>05/12/2023</strong> 26. Is question 6 (regarding internal BAU teams), referring to technical / support BAU teams, or internal end users of the application’ It will be regarding technical/support teams internally. Last Updated : <strong>05/12/2023</strong> 27. Please could you clarify how the expected budget aligns to the delivery milestones e.g Xamarin deprecation. Are you provide more detail around how the budget will be allocated across the requirements? We are looking for the supplier to propose the cost model dependant on their approach. Last Updated : <strong>05/12/2023</strong> 28. In the "Additional Information on Budget" box within the Statement of Requirements you mention the requirement for "additional services" as part of this contract. Are you able to give any examples?  Should you believe that there are services that would be beneficial to the delivery of the rebuild but not critical to the app's replication then these should be presented as additional services. An example of this may be user experience design. Last Updated : <strong>05/12/2023</strong> 29. Is the response limited to 750 characters for all 5 essential questions or is the limit of 750 characters per question? The procurement team have advised that the Buyers Guide states "Suppliers are requested to provide an individual response against each of your questions. Each response should not exceed 750 characters in length (the equivalent of about 150 words). You have the discretion to exclude any supplier who exceeds this limit, or to evaluate only the first 750 characters of their response". Last Updated : <strong>05/12/2023</strong> 30. How is the app currently made available for download to the devices? It is delivered via InTune as an enterprise managed app. Last Updated : <strong>05/12/2023</strong> 31. Can a user install the app on a personal device? No, it is only available on company devices. Last Updated : <strong>05/12/2023</strong> 32. Do you have multiple devices in the a single care home having access to the app? Yes, on-duty Care staff have access to a device on an individual basis. Last Updated : <strong>05/12/2023</strong> 33. Where is the 6 digit pin stored? is it different for each user? is it in effect a way to perform 2FA? Different for each user, it is a local "session" pin, not related to MSAL at all, it effectively allows each user logged-in to set a pin for the period of their shift or until they have logged out/timed out. Last Updated : <strong>05/12/2023</strong> 34. Is the API being polled by the app to check connectivity status? Yes, we poll the API against a /status api endpoint, this effectively checks that the API is online and connecting into the Database. There is caching function behind the API endpoint, but it effectively polls every 5 seconds or so. Last Updated : <strong>05/12/2023</strong> 35. How many screens does the app currently has? circa 15 Last Updated : <strong>05/12/2023</strong> 36. Is there anyway for multiple staff users to modify the record for a single resident? As a RESTful API, there is no distinction/restriction on the CRUD operation here, though we restrict the "App" to doing chart entries (POST), as such, the chart entries can be "posted" multiple times in parallel, they aren't technically doing an update on a record. Last Updated : <strong>05/12/2023</strong> 37. We assume that there is no work required on the API side and current API will be reused by the new App? even if there is we have expert capability to provide assistance for API development as well. This is a correct assumption, but we will be open to recommendations for improvements post rebuild. Last Updated : <strong>05/12/2023</strong> 38. It appears you are looking for a maximum 750 character response to the first 5 requirements combined and a maximum 750 character response to the second 4 requirements combined. Is this correct or is this a max 750 character response for each requirement? The procurement team have advised that the Buyers Guide states "Suppliers are requested to provide an individual response against each of your questions. Each response should not exceed 750 characters in length (the equivalent of about 150 words). You have the discretion to exclude any supplier who exceeds this limit, or to evaluate only the first 750 characters of their response". Last Updated : <strong>05/12/2023</strong> 39. Would a MAUI tech stack be a suitable proposal for the rebuild? The framework was not previously built on Xamarin Forms where MAUI is a direct line upgrade, but actually as a native app in Xamarin.iOS Therefore it will ultimately need a large re-write. As such, in terms of market trends, we have leant towards the market leading stack which is Futter/ReactNative. Last Updated : <strong>05/12/2023</strong>