NHS England GMS Order Management System – Core Broker Alpha Phase

Tender description

Pre-market engagement Three tech UK supplier engagement sessions were held over the last year to gain feedback from suppliers, as part of two-way dialogue and validation of the approach. Work done so far The Discovery Phase of the National Genomics Ordering Management Project was conducted by the Informatics Team within the NHS GMS between June 2022 and August 2023. The Discovery focussed on informing the future possible procurement and/ or development of capabilities for a common national Genomic Ordering Management solution. The research activities were conducted in line with the definition and guidance of a digital service Discovery phase mandated by the Government Digital Service (GDS) Service Manual. All publicly funded digital services are subject to such a Discovery phase before proceeding to the next phase of technical development and design and passing subsequent service assessments. The Discovery has concluded, with key outputs covering the following non-exhaustive list: • a prioritised user requirements backlog and a set of recommendations for consideration. • a baselined Business Requirements Document (BRD) for the Alpha Phase. • a baselined master data set (MDS) of all data related to the end-to-end Order Management process. • a baselined end-to-end process map - the National Genomic Testing Process (NGTP), providing the basis for Order Management requirements. • relevant business rules requirements associated with the NGTP. • A High-Level Design response to the baselined BRD. • A Low-Level Design response to the baselined BRD. • Wireframes representative of the user requirements. • IOPS FHIR Standards. • A draft set of non-functional requirements Which phase the project is in Alpha Existing team The Alpha Phase will require multiple teams from different organisations to work together. At a high-level, resourcing the phase will be as follows: • Informatics & project leadership - supplied by the existing Genomics Informatics Team within the NHS GMS. • Core Broker - engagement a single partner through this opportunity. • Web Portal – we are currently considering a hackathon as part of a pre-market engagement opportunity (to be confirmed), for participation by capable suppliers. • NGIS Integration - engagement through the Genomics Informatics Team with Genomics England (GEL), a key partner of NHS GMS to integrate with an existing downstream system. • EHR & LIMS Integration POC - engagement through the Genomics Informatics Team with at least one (probably multiple) EPR suppliers and at least one (probably multiple) LIMS supplier. Address where the work will be done No specific location, for example they can work remotely or from a supplier’s location. There may well be a requirement for ad hoc face to face meetings, details of the location will be shared with the supplier in a timely manner. Working arrangements The supplier's staff will be expected to be available during the typical working hours of Monday to Friday (9.00am to 5.00pm), in order to maximise collaboration and knowledge sharing. We require the supplier to conduct the usual agile ceremonies and weekly updates/as well as 'show and tell' sessions for stakeholders. Normal, sessions will take place over MS Teams, with key milestone sessions organised ahead of time, being face-to-face in either Leeds or London. Provide more information about your security requirements: Baseline Personnel Security Standard (BPSS) Latest start date 2024-01-16 Enter the expected contract length: 6 months Special terms and conditions NHS England will retain ownership of the Intellectual Property Rights (IPR) created during the contract Special terms and conditions Travel and Expenses will only be paid with prior approval. Special terms and conditions Key supplier staff included at the proposal stage will be expected to work on the contract Are you prepared to show your budget details?: Yes Indicative maximum: 270000 Confirm if you require a contracted out service or supply of resource Contracted out service: the off-payroll rules do not apply Summary of work The Informatics Team within the NHS-E Genomics Unit has concluded a Discovery Phase for a future National Genomics Ordering Management Project. The next stage of the project is an Alpha Technology Phase, to demonstrate if the proposed architectural response will work. The Alpha Technology Phase has numerous workstreams, however this opportunity is specifically focused on the development and documentation of a non-production proof-of-concept of the core application itself (the core broker). The broker is the key backbone to the end-to-end solution and is responsible for receiving and maintaining a central record of all Genomics Test Requests as part of a national solution. The broker will have a defined set of APIs for locally managed Electronic Patient Record (EPR) systems and Laboratory Information Management Systems (LIMS) to integrate to. Where the supplied staff will work No specific location (for example they can work remotely) Who the organisation using the products or services is NHS England Genomic Medicine Service (NHSE GMS). Why the work is being done Currently, there is variation in how genomic test requests are ordered nationally. Whilst some regions have been able to incorporate electronic test requests for a subset of genomic tests, predominantly, requesters rely on paper-based processes. Once received by the lab, the sample along with the details of the test are manually entered into the Laboratory Information Management System (LIMS), creating a potential for transcription errors, additional administrative time, and a duplication in effort. There is also variation in how test requests are stored, with requests stored as paper copies, or as PDFs scanned into LIMS. Whilst some systems provide the capability to capture test details in a structured format within the patient’s Electronic Patient Record (EPR), this capability has not been implemented as part of a standardised national approach. There is also a lack of visibility to the requester when the sample(s) pass through multiple labs (wet labs, Genomic Laboratory Hubs (GLH), Local Genomic Laboratory (LGL), send away for specialist tests etc). When the report is finalised, the requester is sent a copy of the finalised report as a PDF. An additional administrative process is created to maintain an up-to-date electronic patient record, where the report is scanned into the patients EPR and/ or retyped to add as a supplementary pathology report requiring re-authorisation (especially for solid tumour specimens). Please refer to Section 12 within in this document for documentation produced within the Discovery Phase. The expectation is to review and validate the use cases within the Alpha Phase. Whole Genome Sequencing (WGS) test requests remain paper based due to the limitations in clinicians accessing National Genomic Information System (NGIS) and the existing process of managing the Record of Discussion and consent for research given by the patient. This introduces a use of paper in those regions that place test requests electronically as part of an integrated system. Furthermore, the entry of a WGS test request first requires manual input into LIMS and then the same test request is transcribed into the WGS test order management system (TOMS), leading to a duplication in effort and potential delays in processing the sample due to insufficient information. There is also a lack of visibility on the overall progress of the WGS test request. The NHS Genomics Strategy, “Accelerating Genomic Medicine in the NHS”, was published in October 2022 and a supporting internal Genomics Data & Digital Framework has been developed to support delivery of this strategy, including a detailed 3-year roadmap. Priority 3 of the Strategy relates to data and digital commitments including:  • Developing an interoperable informatics and data infrastructure that enables the NHS to use and share genomic data appropriately to improve patient care.  • Putting the NHS at the forefront of using genomic data alongside other health data to drive health improvements for individuals and populations.  • Enabling the NHS to use cutting-edge analytical tools and up to date variant databases to maximise diagnosis, access to precision medicine and efficiency.’  A core component of this strategy is to improve the Genomics Ordering Management process from end-to-end through defining common standards and patterns, digitisation and leveraging interoperability between existing and future systems. The business problem you need to solve The Discovery Phase has provided the following context for its recommendations: • The current ways of manual working using paper are not fit for purpose. • As the service scales there is an increased operational and clinical risk of doing nothing. • Business-as-usual processes need to become more effective to manage current volumes more efficiently. • It would be difficult to scale the service in line with the published strategy. • NHSE commitment to promoting equality and addressing health inequalities would be challenging. • Without improvement, increased workforce frustration will cause higher workforce turnover. • Current paper-processes limit timeliness and accuracy of data in the existing process and increased errors. • Digitisation and standardisation of the end-to-end process will lead to a significant improvement in the availability of operational data for leadership decisions, allowing for improved efficiencies and putting the patient first. • A new approach would be fit for external and internal governance standards. The Discovery Phase recommendations were to proceed with the Alpha Phase, focusing on delivery of a non-production technical proof-of-concept to demonstrate the high-level and low-level architectural design response to the baselined requirements can deliver a viable solution. Working with NHS GMS and numerous integration partners, develop in a non-production capability, using non-production synthetic patient test data, delivering a technical proof of concept (POC) that demonstrates the core broker. The broker facilitates the communication relating to the following capabilities: ● Ability to receive Test Requests & Sample Data from an EHR, LIMS and web portal. ● Ability to route Test Requests to a given lab location, based on defined routing tables, or to the default GLH if no rules exist. ● Ability to process status updates covering tests and samples provided from an EHR, LIMS and web portal, through to and including order completion. ● Ability to support the change in tasks and ownership in the test process. ● Ability to accept modifications and cancellations (including mark in error) of Test Requests ● Ability to accept and store a final report (binary pdf file) ● Ability to have Test Requests closed off. ● Ability for relevant users and systems to receive notifications as regards order modifications or status changes. Noting – Notifications capability to be enhanced post-alpha, for example, a configurable pick list and rules base. The Alpha Phase will focus on when a test has been rejected or is awaiting further information for a requester standpoint and when a report is available. The core broker will deliver: • a modern API framework. • alignment to the Master Data Set (MDS) defined by the Discovery Phase. • standards driven by, FHIR (UK Core R4) with support to HL7 v2 through mapping to FHIR. • alignment to the high-level and low-level target architecture defined by the Discovery Phase. • NHS core services reuse for implementation. First user type: GMS Colleagues Enter more details about this user type: The core broker acting as a central service addresses the challenge faced in the communication of data between multiple organisational boundaries. All organisations in the process will receive relevant updates through their systems polling the central service and communicating their latest status update to the core broker. The actors and transmission flow of the proposed target architecture is: 1. A requester places a test request electronically, within their organisational boundary: o A sample is also then requested to be collected, more than likely at a different organisational location/ boundary to that of the requester. o A variety of non-standardised communication means are employed. e.g. a paper sample linkage form is passed to the patient between organisational boundaries. 2. The Genomic Lab Hub (GLH) (as the next organisational location/ boundary) polls the core broker for new test requests associated to them. 3. The sample collecting organisation is able to update the order, using a test request identifier, adding the sample information. o Once collected, the sample will be sent across to the GLH. Despite sample details being updated electronically, standard procedure is followed and a sample linkage form (paper), is still sent with the sample. 4. Once the test request order has been updated with the sample information, the central service updates the workflow task to the GLH, indicating that the sample has been sent. 5. Once either the order has been updated with sample data, or the physical sample and linkage form has been received by the GLH, the GLH now has both test data and sample data, the minimum data required to process an order. This complete dataset can then be processed at the GLH or forwarded to a remote GLH or external lab via the central service. o The sample is forwarded to the remote GLH or external lab. The physical sample is sent via existing, current-state logistical means. 6. If required, the remote GLH receives the test request and sample data via the central service. 7. The remote GLH processes the request, or forwards on the test request and sample to another external lab in the region, via central service messaging. o The sample is forwarded to the remote GLH also. The physical sample is sent via existing, current-state logistical means. 8. If required, the remote external lab processes the sample and fulfils the order, providing integrated updates to the core broker as necessary. 9. Once a sample has been analysed and interpreted, a final report is generated and loaded to the central service, with the requester and the GLH being notified. All users within this flow are expected to be using their local, integrated EPR or LIMS system, or for non-integrated users, a separate web portal (development of the portal is not within scope of this opportunity).