Lynch syndrome (LS) is a hereditary cancer syndrome responsible for 3% of all endometrial cancer and 5% in those aged under 70 years. It is unclear whether universal testing for LS in endometrial cancer patients would be cost-effective. The Manchester approach to identifying LS in endometrial cancer patients uses immunohistochemistry (IHC) to detect mismatch repair (MMR) deficiency, incorporates testing for MLH1
promoter hypermethylation, and incorporates genetic testing for pathogenic MMR variants. We aimed to assess the cost-effectiveness of the Manchester approach on the basis of primary research data from clinical practice in Manchester. The Proportion of Endometrial Tumours Associated with Lynch Syndrome (PETALS) study informed estimates of diagnostic performances for a number of different strategies. A recent microcosting study was adapted and was used to estimate diagnostic costs. A Markov model was used to predict long-term costs and health outcomes (measured in quality-adjusted life years, QALYs) for individuals and their relatives. Bootstrapping and probabilistic sensitivity analysis were used to estimate the uncertainty in cost-effectiveness. The Manchester approach dominated other reflex testing strategies when considering diagnostic costs and Lynch syndrome cases identified. When considering long-term costs and QALYs the Manchester approach was the optimal strategy, costing £5459 per QALY gained (compared to thresholds of £20,000 to £30,000 per QALY commonly used in the National Health Service (NHS)). Cost-effectiveness is not an argument for restricting testing to younger patients or those with a strong family history. Universal testing for Lynch syndrome in endometrial cancer patients is expected to be cost-effective in the U.K. (NHS), and the Manchester approach is expected to be the optimal testing strategy.
This is an open access article distributed under the Creative Commons Attribution License
which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited