Feasibility of a Learning Health System
Research type
Research Study
Full title
Demonstrating the feasibility of a Learning Health System for cancer diagnosis in primary care
IRAS ID
252487
Contact name
Brendan Delaney
Contact email
Sponsor organisation
Imperial College London
Clinicaltrials.gov Identifier
N/A, N/A
Duration of Study in the UK
0 years, 11 months, 31 days
Research summary
Research Summary
Early diagnosis research is one of the strategic priorities for Cancer Research UK (CRUK), where survival is clearly linked to stage at diagnosis for many common cancers. The most significant causes of diagnostic delays are sub-optimal decision-making by general practitioners (GPs) and lack of diagnostic evidence on predictive symptoms and signs. Risk Assessment Tools (RATs) provide estimates of diagnostic probabilities per individual, and so can be used to create a Decision Support System (DSS) to help with diagnosis in the consultation room at real time.
This study is part of a wider project that aims to work closely with GPs and patients to determine the requirements of a DSS for cancer diagnosis in UK primary care. In doing so, the project will develop a data collection tool, known as the DSS Data Collection Only Module (DSS-DCOM), and deploy it in practices to collect ‘episode of care’ data, with the goal to demonstrate that the data collection is scalable to large volumes of data required for a future programme.
The study described here addresses the final goal of the project, to demonstrate the feasibility of coding to scale to 3 million episodes of care over 4 years. To achieve this goal, we will recruit 40 GP practices and will train GPs on how to use the DSS-DCOM for assisted coding and data capture during the consultation, without decision support. Data collected via the DSS-DCOM will be extracted, cleaned and passed for analysis to estimate the proportion of eligible consultations conducted using the DSS-DCOM and explore the range of Reasons for Encounter (RfE) and the population characteristics of patients. Finally, we will explore formats and analyses necessary for formative feedback to practices on data quality.Summary of results
This was a feasibility study of using a prototype computerised decision support system (DSS) as a ‘plug in’ at the beginning of a GP consultation. The tool used the patient’s ‘reason for encounter’ and past history to trigger a list of potential diagnoses and assist the GP in collecting additional information to help identify the correct diagnosis. Previous simulation studies had shown that providing this initial list could improve accuracy of diagnosis by GPs. The data collected were then saved into the GP record and allocated a unique code that would enable us to gather the entered data from routine extracts of GP consultation coded data in NW London and the RCGP network of research practices.The objectives of the pilot were to:
1. Establish the ability of EHR systems to integrate the DSS and gather data from it.
2. Establish the willingness of practices to deploy the tool 3. Establish the potential for gathering data from the tool 4. Establish the likely numbers of patients for whom the tool might be used.Results
1. Integration of the DSS tool was attempted with two GP systems, EMIS and TPP SystmOne. For TPP we used a within-system ‘trigger button’ set up in SystmOne and GPs were asked to click it when relevant. This opened the DSS and allowed the GP to start using it. On closing the DSS any text and coded data would be written back into the TPP system using the Application Programming Interface (API). We found developing software for the API much harder than anticipated as there were a number of problems with the write back functionality. These took over a year to resolve, and included having to ensure that the versions of codes (SNOMED code set) being written back included only those in the current NHS GP version (any unexpected codes stopped the write back). In addition it proved impossible using the API to automatically include the unique ID code, GPs were asked to type it in manually. Out of the 34 practices that we recruited, only 17 installed the DSS system, and we have patients with CPMS codes from only 9 of those, the rest do not have a single patient with either the CPMS or SNOMED code. Those 9 practices recruited a total of 92 patients.
2. Several hundred practices were approached about the research project, but only 34 agreed to take part and only 17 installed the DSS. Reasons for not taking part were primarily that the practice was using other systems (such as Ardens) that monitor all coding entering a GP record, to ensure that codes are in accordance with GP payments and targets. Practices did not want another system to enter ‘unchecked’ codes. In addition, although the DSS was designed to be installed without requiring ‘adminsitration’ rights, in many practices there were insufficient IT skilled staff to carry out this task.
3. The combination of these factors at all points in the process meant that we did not have sufficient numbers of patients to establish whether we were recruiting the type of patients we expected.
4. The DSS tool, as deployed as part of this research is not a feasible solution to the problem of GP diagnostic error on account of a combination of operational and technical issues.Recommendations
Further attempts to influence GP diagnosis should follow the following approach
1. Operation of data gathering and generation of differential diagnosis should occur before involvement of the GP and before any access to GP systems 2. A full technical appraisal of the requirements of write-back and system integration with an experienced NHS IT partner and industry should take place to design a system that has better ‘work arounds’ for integration problems (for example using robotic processes) 3. Future software should have a commercial sponsor and be on GP choices as attempting to do this from academia is too challenging.
4. Using ‘Research codes’ to identify patients records is challenging as they are not entered automatically and GPs miss entering them manually. Alternative automatic methods of identification need to be identified.
5. GP versions of code lists should be managed as part of the business of a commercial parter.
6. Installation should take place by local NHS IT service partners under standard commercial practices.Conclusion.
Navigating software installation in the NHS has become increasingly complex and is no longer within the capacity of a research organisation.REC name
London - Bromley Research Ethics Committee
REC reference
18/LO/2240
Date of REC Opinion
25 Jan 2019
REC opinion
Further Information Favourable Opinion