Development of a Prostate Cancer Patient PSA History Calculator To Support Patient Follow-Up Scheduling Decisions

Abstract

The primary goal of this Health Informatics (HI) work-term was to develop a software application which can be used by the Radiation Oncology Department of the QEII to predict the probability that a patient’s prostate specific antigen (PSA) levels may rise by an estimated amount over a specified period of time. The data for these calculations was from a database maintained by this department containing about 2000 patient histories in MS Access. This application was created by the author under the guidance of Dr Rob Rutledge between mid July 2009 and the end of December 2009. All software development expertise, tools, planning, and host platform were supplied by the author to meet the requirements of this department. The work was composed of 6 phases: 1) Topic Familiarization and Research: Receive introductory clinical familiarizations from Dr Rutledge, and learn primary objective (a workable application) and secondary (long term plan) requirements. Search library sources for related publications. Meet department staff. Review format/content of patient charts. Meet Ron Dewar of Cancer Care Nova Scotia. Review epidemiology projects done using ‘R’. Receive raw data files from Dr Wilke. 2) Data Exploration and Refinement: Prioritize data fields. Identify records belonging to Dr Wilke and correlate secondary file data to primary file. Review OPIS data from CCNS. Produce initial PSA behavior graphs. Experiment with regression analysis methods. Develop data clipping methods. Propose 3D nearest neighbor CBR approach. View data using WEKA. 3) Algorithm Trials and Demonstrations: Develop overlapping patient plots separated by risk levels, add start window filtering and end window filtering, then calculate percentage of PSA failures per grouping. Apply iterative processing of previous calculation to produce a probability graph over time. Rework to meet user expectations (month time scale, unique PSA failure plots, etc) 4) User Application Integration and Testing: Search for appropriate GUI application tools which can interface to ‘R’ routines, are supported by CDHA network PCs, can be applied quickly, and are zero cost. Develop PSA History Calculator GUI, integrate to ‘R’ routines and graphing output devices. Add patient charting feature and exact count displays. Test multiple use cases, debug errors encountered, compile delivery version. 5) Product Documentation and Delivery: Write a comprehensive user guide to explain tool use and dataset updating. Print and deliver hardcopy with all software products on CD. 6) Planning Future Improvements: Write technical proposal for delivery to BC hospital authority for request to use their 6000 patient dataset to augment our existing 300 patient set. The resultant prototype created allows a user to select a patient risk level, their time of Radiation Therapy (RT), the present date, their present PSA level, a future follow-up appointment date, and an estimated future PSA level on that date. It will calculate the probability that they will exceed that future estimated level on that future date based upon approximately 300 eligible patient histories from the original dataset. It allows the user to see a composite plot of previous patients who were similar to the selected case and how many of those cases exceed the anticipated PSA growth. It also allows the user to see the probability that the entered case will exceed the future estimated level as a function of time between the present date and the date of the future follow-up appointment. As an additional feature it will specify which previous case histories did exceed the entered parameters to allow gathering of further details by comparing the chart of the present patient against the chart of those specific previous patients if desired. All computations and history plotting was performed using the statistical script language called ‘R’, and the program integration and graphical user interface (GUI) was constructed using a language called ‘C++’. Health care practitioners are not computer experts, nor should they ever need to be. Healthcare practitioners have some strong preconceptions about software and computer systems in general that will evolve gradually with time, patience, and experience. Health Informatics solution developers need to be equally open to change, new ideas, and unique ways of looking at problems, because only by combining our skills and knowledge effectively with one another can we achieve the best results. Solutions must “fit” the needs of the practitioners who know their subject matter best, and their patients as well. Nobody wants a “solution” that makes their goals harder to achieve. A significant limitation of this tool is that it has only about 300 source cases to draw on to make decisions. The result is that it can give significant results in some of the most common case scenarios, but when a case scenario diverges from the typical path of progression, the results quickly become statistically insignificant because there are only a handful (or fewer) previous cases that have been similar. We have proposed to solve this by seeking significantly larger patient data history sets from other sources with similar treatment practices to those of CDHA. The first of these is a set of 6000 patient histories from a hospital in British Columbia. Acquisition of this data will allow for creation of a greatly enhanced source case dataset and logically should lead to improved result significance and accuracy.