CORTISONE Deployed Tactical Application Development

Description

Summary of work Background This requirement is for the provision of healthcare application development expertise to deliver outcomes in support of a wider project under Programme Cortisone. The outcome of this project within the programme is the development of an alpha lightweight tactical application platform, suitable for both Android Devices and Windows tablet use. This project will leverage open standards, including OpenEHR to persist information and HL7 FHIR to transmit data as a minimum. All development is to be well documented with potential sharing and reuse in mind. This work will support a project-level make vs. buy analysis for the capabilities required from this application. It is anticipated that the outcomes for this requirement will be delivered by an application development team that could be composed of similar roles described below: - Technical Lead – to lead the development team in the analysis, technical designs and development sprints needed to achieve outcomes. - UI/UX/Service Design Lead – support analysis and develop application UI designs to meet UX goals. - A specified number of full stack software developers to support outcomes. Note: This requirement excludes other elements of the project, which will be delivered by Buyer staff or other subcontracts. These include wider project management, solution architectures, data models, full technical designs and managing stakeholders. Outcomes - Mobilisation: 0-1 weeks from project kick-off: - Mobilise and integrate development team with the wider application project team. - Onboard onto development platform, establish analysis and design information requirements. Analysis and Design: 2 weeks from mobilisation: - UX/UI Design: Deliver a report which (1) assesses the current technical design work and principles of the current proof-of-concept (POC) application, and (2) defines the UX and UI design principles for the new application. - Code Review: Conduct a code review of the POC application and identify any potential re-use opportunities. - Application technical design: with team members, collaborate to develop a specific application technical design including the key reusable design principles and the related underpinning assumptions. - Wireframe and UI Development: In collaboration with other team members, develop an initial new application User Interface wireframe, outlining the underpinning repeatable User Experience (UX) patterns to support feature development at scale. - Continuous Automation, Testing, and Deployment Strategy: Deliver a plan to manage continuous automation, testing and deployment. Iterative Management: - Development: Conduct software development activities as agreed with the Project Manager, utilising the Kotlin development framework, across a series of iterations/sprints. - Iteration/sprint scope will be defined by the project team and is expected to confirm users, workflows (that could include login, review of care records, consultation data capture, clinical templates, data transfers and integration etc) and features to guide dynamic development of the application. - Development will utilise open standards and the project will utilise data persistence via high-performance openEHR compliant database technologies. Development work will utilise Github practices and documentation to support knowledge transfer. This project phase will utilise synthetic patient data only. - Management Outputs: The project will be managed by the Buyer utilising Scaled Agile Framework. The supplier will report on progress against the required outcomes with end-of-iteration/sprint reporting. Project Closedown: - Conduct knowledge transfer and next steps planning activities. Programme Support As part of the wider project, the supplier is required to support the following activities relating to the wider project outcomes: - Iteration/sprint management: Track, manage and report on development capacity and velocity. - Development Platform: Manage the maintenance requirements of the supporting development platform (technical issue resolution, maintenance tickets, technical assurance requirements). - Application Development Roadmaps: Provide input to application development roadmaps, including the identification of clinical integration opportunities. Where the supplied staff will work No specific location (for example they can work remotely) Who the organisation using the products or services is The following users/organisations are the intended users of the future capability: - Frontline Medical Personnel within Strategic Command and Front-Line Commands Why the work is being done This project forms part of the wider Programme CORTISONE - Programme Cortisone - GOV.UK (www.gov.uk/government/publications/programme-cortisone). Programme CORTISONE is a suite of digital medical / healthcare services and products delivered to Defence Medical Services (DMS) by the Defence Digital MedIS delivery team. The aim of Programme CORTISONE is to deliver an integrated ecosystem of medical information services to DMS. Its vision is to deliver ‘a sustainable, integrated, cohesive and enduring information capability that will fully and effectively support the delivery of evidence-based medical and healthcare outputs, to achieve the aim of the Defence Medical Services. The primary role of DMS is to Promote, Protect and Restore the health of the UK armed forces to ensure that they are ready and medically fit to go wherever they are required in the UK and throughout the world. This will enable better patient outcomes and contribute to DMS resource optimisation, with the aim of maximising the number of personnel fit for role for Defence. It will deliver access to, and exploitation of, clinical records across the Firmbase and Deployed operating environments. The term Firmbase refers to all healthcare and associated Med IS undertaken across the UK and permanent locations across the world. Deployed refers to the provision of healthcare on Operations, Exercises and Defence Tasks away from ‘Firmbase’ installations, both on land and at sea. Connectivity on deployments cannot always be relied upon and software solutions must be able to work disconnected for extended periods of time and then safely re-synchronise data to maintain the master patient record. Disconnected applications should be deployable onto a wider range of military CIS infrastructure and should also be configured to allow for data capture in challenging low resource environments and deliver point to point data transfer even when disconnected. This work is required as the legacy electronic patient record system is nearing the end of its in-service life and this experimentation is critical to support the delivery of a new, clinically safe, digitised healthcare software solution for UK Defence. The business problem This specific project relates to the Deployed Information Services. Medical information Services (MEDIS) must be available in all environments where the DMS is delivering healthcare – from the firm base, through fixed bases around the world, to all types of deployments. MedIS should be scalable and capable of functioning disconnected for extended periods with subsequent synchronisation, to meet the variable capability requirements at different locations. Services should also be integrated and cohesive to avoid duplication of effort and wasting valuable clinical time. There should be a single source of truth for each information item. The CORTISONE ecosystem will enable healthcare and information captured in all types of deployed environments from primary care to deployed hospitals, in current and future systems, to be integrated. The CORTISONE ecosystem will connect current and future systems which record and communication healthcare information during Medical Evaluation (MEDEVAC) e.g. patient tracking, clinical records, triage, first responder information and clinical decision support. The people who will use the product or service User type: Healthcare Practitioners – General Practioners, Junior Doctors, Registered Nurses, Paramedics and Medical Assistants Definition: I need to: Deploy overseas at short notice with the ability to utilise clinical software that allows me to review a patient's history, record a consultation, capture pre-determined clinical information in templates, work completely disconnected and transfer this data for safe storage. This software would be accessible to practitioners working in the delivery of primary medical care and pre-hospital emergency care. So that I can: Safely manage the health and wellbeing of the deployed force, on global deployments and ensure that the clinical information is handled correctly in line with clinical safety and security requirements. Work done so far Discovery activities across key user groups and stakeholders in Army, Navy and Air have taken place in order to understand the current state and future state needs, along with the different ways of working and operational needs. In addition, the following clinically led and developed proof of concepts have been undertaken. These activities have helped to inform the approach and requirements, and can be used for onboarding and to help shape the Alpha deliverables: - Pre-Hospital Emergency Care digital voice scribe for concurrent, hands-free documentation - Digitising medical notes in the field using Optical Character Recognition - Novel interface generation - On device terminology server - Medical logistics - International Patient Summary Data transfer via NFC and generative QR code technologies - Use of Power Apps for deployed healthcare management tasks - Remote telemedicine provision Which phase the project is in Alpha Existing team Project Manager – To oversee the successful delivery of the project and associated milestones. Working with teams and suppliers across Defence Digital and Defence Medical Services. Clinical lead(s) – Representing the voice of the user, to describe requirements and information needs in the development of the platform. The primary point of contact for clinical issues and acting as the bridge between healthcare professionals across Army, Navy and Air. Ensuring a clinically led, user centred approach throughout the project. Clinical Safety Officer – Ensuring clinical safety considerations are factored in from the outset of the development of the application, whilst providing clear guidance in the steps and evidence required to align with NHS DCB129 and DCB 160 standards. Enterprise Architect – Defining the architectural strategy for the broader Cortisone Deployed Sub-programme and ensuring architectural cohesion. Solution Architect – Working with the supplier to design and oversee the implementation of the application whilst ensuring alignment to the enterprise architecture Test Lead - Working with the project team to dynamically develop test scripts for agile user testing and provision development reports and feedback. Address where the work will be done The majority of work will be conducted remotely. Occasional face-to-face meetings or workshops may be conducted at one of the following three locations, or other customer locations within the UK as required: Ministry of Defence Corsham Wiltshire SN13 9NR United Kingdom Defence Medical Services Whittington Barracks Lichfield Staffordshire WS14 9PY Ministry of Defence Main Building Whitehall Horse Guards Avenue London SW1A 2HB Working arrangements We expect that the supplier will work remotely for activities relating to this project. The supplier may be required to attend occasional face-to-face meetings at other locations (e.g kick-off meeting, and onboarding/knowledge sharing), which may include Lichfield, Corsham or London plus other locations for user testing. Expenses for any face-to-face meetings will be capped at a reasonable amount for the duration of the contract. All travel and subsistence will require prior approval. Security and vetting requirements Baseline Personnel Security Standard (BPSS) More information about the Security requirements: The supplier must adhere to software engineering security best practices in accordance with industry frameworks/standards. This contract will be subject to DEFCON 658 and has been assessed as "Low" under the cyber risk assessment process, and is subject to DEFSTAN 05-138. More information will be provided under stage 2. This requirement will be subject to a Security Aspects Letter outlining the responsibilities of the supplier. This will be shared during stage 2. Latest start date 14 November 2024 Expected contract length Contract length: 0 years 6 months 0 days Optional extension: 0 years 3 months 0 days Special terms and conditions special term or condition: Standard MOD DEFCONs will apply to the call-off contract. These will be specified in the order form. Budget Indicative maximum: £250000 Indicative minimum: The contract value is not specified by the buyer Contracted out service or supply of resource? Supply of resource: the off-payroll rules may apply Questions and Clarifications 1. (1) In the essential skills and experience section - “OpenEHR compliant Clinical Development Repositories” are referenced - can you clarify the terminology and whether this is actually referencing an OpenEHR clinical data repository (CDR)? (2) Can you provide more details about the current infrastructure that the new application is expected to integrate with, including any specific middleware, databases, or APIs currently in use? (3) Can you provide details on the existing technology stack used to develop the proof of concept application? (4) Is there any flexibility in the budget if additional scope is identified during the project, or will these be handled as separate contract amendments? (1) This is a typo – it should state “Clinical Data Repository”. (2) This information cannot be provided at this stage. The focus at this stage is on developing features in accordance with the identified standards to support an informed make or buy analysis. (3) A series of proof-of-concept applications have been developed for Android using Kotlin in Jetpack Compose. These applications demonstrate different features such as UI functionality (optimising screen space) and technical functionality such as animated QR code for transfer of information. Open-source libraries have been used in development of proof-of-concept applications, such as HAPI FHRI for HL7 FHIR export. Source code and APKs would be shared for experimentation and re-use as appropriate. A core element of this project is that learning should be taken from exiting POC applications and incorporate these learnings onto the new technology stack. (4) The current approved budget for this procurement is £250K. Any additional procurement activity will be procured in compliance with the applicable procurement regulations. Last Updated : <strong>27/09/2024</strong> 2. 1. We believe this Alpha phase intends to test specific hypotheses that have already been identified in your Discovery phase - is that accurate? 2. Can you confirm if there is an incumbent who undertook the Discovery? 3. Can you describe the scope of the POC application - e.g. how many screens it contains, high-level journey? 4. Are there restrictions to non-UK based workers being involved in this? 5. Is there an expected number of iterations/sprints within the iterative management period? 6. Can you confirm the nature of the user journey that was an output of the discovery? 7. Please can you confirm the development platform that would be used? 1. We believe this Alpha phase intends to test specific hypotheses that have already been identified in your Discovery phase - is that accurate? Answer: This phase will focus on the rapid development of features, leveraging both past discovery activities and experimentation, as well as ongoing discovery and experimentation during the development phase. This activity will support a make-or-buy analysis for this capability within the context of the wider programme. 2. Can you confirm if there is an incumbent who undertook the Discovery? Answer: There is no incumbent from a development perspective. 3. Can you describe the scope of the POC application - e.g. how many screens it contains, high-level journey? Answer: The scope of the POC in terms of functionality is not fixed at this stage and we will work closely with the winning supplier to prioritise requirements in a collaborative manner taking a rapid development approach, responding to user needs. This will be based on multiple user journeys and requirements across Pre-Hospital and Primary Care domain within this area – developed from a clinical, operations and patient perspective. The problem that we are exploring focuses on how medical staff at the front line could view, record and transmit existing clinical information about a patient back to the UK, operating in an offline first capacity and in environments with intermittent, in low bandwidth and high latency connectivity situations. 4. Are there restrictions to non-UK based workers being involved in this? Answer: BPSS is required to work on this project. This does not preclude non-UK based workers. Due to the nature of the engagement, we expect a number of face-to-face workshops and meetings. The development approach will be interactive with the other team members, with time-zone critical decision making. 5. Is there an expected number of iterations/sprints within the iterative management period? Answer: There are no expected number of iterations or sprints within the iterative management period. 6. Can you confirm the nature of the user journey that was an output of the discovery? Answer: There are multiple use journeys and requirements across the Pre-Hospital and Primary Care domain. These have been developed from a clinical, operations and patient perspective. 7. Please can you confirm the development platform that would be used? Answer: The target back end / Windows hosting platform is an adapted and locked down version of RedHat OpenShift (with certain aspects turned off for security) or default to Azure. We expect the dev team to build and test locally then use a private repository (GitHub) using their industry best approach. Then the code will be pulled into OpenShift to test the Windows application deployment and locally on an android device for the Android application deployment. For more information about develop platforms please visit the Defence Developer Services (D2S) website: https://d2s.dev.service.mod.gov.uk/ Last Updated : <strong>27/09/2024</strong> 3. 1. The timeframe for the Analysis and Design phase is listed as 2 weeks. Could you confirm the proposed timeframes for the Iterative Management and Project Closeout phases? 2. The total project duration is mentioned as both 6 months and 3 months. Could you clarify the correct length of the project? 3. Can you confirm if this project builds on the work conducted so far, such as user research and the proof of concept (POC), to support a make vs. buy analysis for replacing the current legacy electronic patient record system? 4. Could you provide further details on the activities under ‘Iterative Management: Development’? Specifically, given that a POC has already been developed, is the objective to build a prototype that extends this existing POC? 5. Can you elaborate on the current POC? How extensive is it, and has it been developed in alignment with the outlined frameworks? 1. The timeframe for the Analysis and Design phase is listed as 2 weeks. Could you confirm the proposed timeframes for the Iterative Management and Project Closeout phases? Answer: There is no current fixed timeframe for project closeout. This will depend on the resource cost and capacity of the winning supplier during this phase. The target is to conduct rapid and iterative development of as many features as possible to support a make vs. buy analysis in Q1/Q2 2025. 2. The total project duration is mentioned as both 6 months and 3 months. Could you clarify the correct length of the project? Answer: The current approved budget is £250K. Depending on the supplier proposal, we anticipate this may cover up to 6 months, but the focus is on rapid, iterative development within the current budget. 3. Can you confirm if this project builds on the work conducted so far, such as user research and the proof of concept (POC), to support a make vs. buy analysis for replacing the current legacy electronic patient record system? Answer: The problem that we are exploring focuses on how medical staff at the front line could view, record, and transmit existing clinical information about a patient back to the UK, operating in an offline first capacity and in environments with intermittent, in low bandwidth and high latency connectivity situations. The make vs. buy analysis focuses on delivering an application, or applications, to deliver that capability. 4. Could you provide further details on the activities under ‘Iterative Management: Development’? Specifically, given that a POC has already been developed, is the objective to build a prototype that extends this existing POC? Answer: We anticipate that there will be reuseable elements (subject to refactoring) from the standalone POC applications that could be included in the build activities. We are working on the basis of a new build rather than extending the existing POCs within the Alpha phase, with an emphasis on a vendor and technology neutral data layer through the use of OpenEHR (which is not being use currently). 5. Can you elaborate on the current POC? How extensive is it, and has it been developed in alignment with the outlined frameworks? Answer: The current proof of concept has been developed with a small number of clinical users as part of wider research. It has not been integrated info Defence infrastructure and does not have clinical safety or technical assurance accreditation. It has been developed with HL7 FHIR and Kotlin, but not with OpenEHR at this stage. Last Updated : <strong>27/09/2024</strong>