Integrating cancer survivors' experiences into UK cancer registries: design and development of the ePOCS system (electronic Patient-reported Outcomes from Cancer Survivors)

Abstract

Background:

Understanding the psychosocial challenges of cancer survivorship, and identifying which patients experience ongoing difficulties, is a key priority. The ePOCS (electronic patient-reported outcomes from cancer survivors) project aims to develop and evaluate a cost-efficient, UK-scalable electronic system for collecting patient-reported outcome measures (PROMs), at regular post-diagnostic timepoints, and linking these with clinical data in cancer registries.

Methods:

A multidisciplinary team developed the system using agile methods. Design entailed process mapping the system's constituent parts, data flows and involved human activities, and undertaking usability testing. Informatics specialists built new technical components, including a web-based questionnaire tool and tracking database, and established component-connecting data flows. Development challenges were overcome, including patient usability and data linkage and security.

Results:

We have developed a system in which PROMs are completed online, using a secure questionnaire administration tool, accessed via a public-facing website, and the responses are linked and stored with clinical registry data. Patient monitoring and communications are semiautomated via a tracker database, and patient correspondence is primarily Email-based. The system is currently honed for clinician-led hospital-based patient recruitment.

Conclusions:

A feasibility test study is underway. Although there are possible challenges to sustaining and scaling up ePOCS, the system has potential to support UK epidemiological PROMs collection and clinical data linkage.

There are currently 2 million cancer survivors in the UK, which is estimated to increase to 4 million by 2030 (Maddams et al, 2009). Some survivors experience ongoing physical and psychosocial difficulties, including problems with fatigue, emotional health and work, yet many survivors report comparable quality of life to their general population peers (Arndt et al, 2005; Helgesson et al, 2007; Short et al, 2008; Hoffman et al, 2009; Harrison et al, 2011). Current understanding of who experiences particular survivorship difficulties and when, however, is limited; research to date has mostly examined a narrow range of outcomes in small-scale, short-term, non-UK studies (Bloom et al, 2007; Foster et al, 2009). A priority of the UK National Cancer Survivorship Initiative (NCSI) is to improve the understanding of survivors' experiences through increased collection of patient-reported outcome measures (PROMs, i.e., questionnaires), across multiple quality-of-life domains for many years post diagnosis. Understanding of survivorship issues is vital to inform service development and interventions, and facilitate targeted provision, with the latter being increasingly important as the number of survivors rises in a difficult financial environment.

Prospective longitudinal PROMs collection is expensive, owing to the high administrative and staff costs of repeated questionnaire administration, and ongoing patient tracking and communication. Moreover, PROMs collection hinges on high rates of sustained patient participation, yet poor accrual and high attrition are common problems in oncology and research generally (Easterbrook and Matthews, 1992; Dilts and Sandler, 2006). There is potential to reduce the cost of PROMs collection, by making many of the involved processes electronic and/or Internet-based. Administering PROMs online eliminates the paper-based costs of printing, distribution, data entry and physical storage, and is therefore estimated to be cheaper than paper administration by over 75% (Greenlaw and Brown-Welty, 2009; Russell et al, 2010). Automating monitoring of patients' questionnaire activity, and preparation of related communications, through use of a tracking database, can greatly reduce staff costs. Similarly, Email communications avoid the expense of postal mail. Online PROMs may also improve patient convenience, and thereby recruitment and retention. Internet questionnaires can be immediately accessed, completed and submitted, 24 h a day, year-round, from numerous web-accessible devices and locations. Studies that have assessed and established psychometric equivalence of electronic and paper PROMs have also reported finding a patient preference in favour of Internet vs paper administration (Handa et al, 2008; Bishop et al, 2010).

To be most informative, PROMs must be linked and analysed with patients' diagnostic and treatment information; this is important to identify clinical predictors of survivorship difficulties and enable risk stratification. However, clinical data linkage can be logistically and ethically complex, because of issues such as data completeness and security, and also time consuming and costly (Bohensky et al, 2010). A review by Lipscomb et al (2007) highlighted failure to link PROMs with clinical data as a common problem in cancer survey research, and urged the establishment of ‘data systems that incorporate not only traditional clinical and epidemiological parameters, but patient-reported outcomes’ (p 292). The UK has a comprehensive network of cancer registries that collate, link and store clinical information on all cancer patients to produce incidence and survival statistics; the network comprises eight regional English registries and three national registries in each of Scotland, Wales and Northern Ireland. English data are collated by the National Cancer Intelligence Network (NCIN) in the National Cancer Data Repository (NCDR), which is centrally linked with other data sets including Hospital Episode Statistics (HES). Data linking through the registries would be logistically efficient and enable PROMs to be linked with a standard clinical data set. Registry linkage would also capitalise on costly work already undertaken to collate and validate patients' clinical data, and, as registries work to the highest standards of data protection and security, would ensure compliance with all relevant ethical, NHS and legal mandates. By means of the NCDR, registry linkage also affords potential for linking (English) PROMs to other data such as HES.

We aim to facilitate epidemiological measurement of UK survivors' experiences by developing a technical system for regularly collecting PROMs and linking to clinical information: the electronic Patient-reported Outcomes from Cancer Survivors (ePOCS) system. Specifically, we aim to develop a system in which PROMs are completed online and stored with clinical data in the registries/NCDR, and in which patient tracking is electronically automated and communication is Email-based. As the Internet and registry network both provide enduring UK-wide coverage, such a system is potentially sustainable and UK scalable. Recent years have seen rapid growth in the use of electronic PROMs and analyses of linked data sets (Gwaltney et al, 2008; Snyder et al, 2009; Bohensky et al, 2010). In The Netherlands, the PROFILES Group (Patient Reported Outcomes Following Initial treatment and Long-term Evaluation of Survivorship) have very recently set up a ‘web-based registry’ to facilitate cancer PROMs collection, and which links to clinical data in a regional cancer registry (van de Poll-Franse et al, 2011). In the UK, however, there is currently no system for regularly collecting cancer PROMs and linking to registry data.

Patients must be recruited for PROMs-based research (i.e., identified eligible and provide consent). Any PROMs collection system must be able to receive information of newly recruited patients, and must be developed, therefore, with a view to the context(s) of recruitment. It is not permissible to contact patients directly via UK cancer registries. Research suggests that patient recruitment rates are generally higher in secondary and tertiary hospitals than primary care general practitioner practices (Hunt et al, 2001; Hetherton et al, 2004; Hummers-Pradier et al, 2008). We anticipate that recruitment will be more effective and sustainable if undertaken by clinical teams than by non-NHS research personnel. Therefore, we decided to develop (and test) ePOCS within a context of hospital-based recruitment led by research nurses (RNs).

This article describes the technical development of the ePOCS system, which entailed designing and building new constituent technical components, and establishing and adjusting component-connecting data flows. The system is currently being tested in a feasibility study with non-metastatic breast, colorectal and prostate cancer patients in two Yorkshire NHS Trusts, and using the Northern and Yorkshire Cancer Registry and Information Service (NYCRIS). Feasibility evaluation will be the subject of future papers (e.g., patient participation rates, reliability of the informatics, running costs). In this paper, we aim to (1) delineate the methods and processes involved in designing and building the system; (2) describe the developed system in terms of its technical components, data flows and involved human activities; and (3) discuss the challenges of development, and those potentially involved in sustaining and scaling up the system.

Materials and methods

Overview of system development

ePOCS seeks to provide a technical platform for collecting PROMs online, at repeated post-diagnostic timepoints, for linking these with clinical data in cancer registries, and for electronically managing associated patient tracking and communications. System development required building three technical components: (1) a web-based software tool into which any questionnaire can be programmed, and completed online by large groups of patients at specific post-diagnostic timepoints (QTool); (2) a public-facing Internet website that can provide quick and easy access to the QTool; and (3) an electronic database that can track patients' PROMs completion progress and automatically generate necessary related communications such as reminder notices (the Tracker). Development also required building data flows between the components and making minor adjustments to existing data flows incorporated into the system. Broadly speaking, for most components and data flows, development was a multi-stage process that involved determining specifications, building/modifying and usability testing.

Development team

A university-based research group led and oversaw development day to day, and worked collaboratively on specific technical tasks with informatics specialists from the NHS, NYCRIS, NCIN and an e-health software company (X-Lab Ltd; with a university-employed director). Collectively, the team included expertise in psychosocial oncology research, electronic PROMs, clinical oncology, nursing, data management, cancer registration, health informatics and multimedia production. Four cancer survivors participated in the wider project steering group.

Key development challenges

Receiving information about incoming patients

As previously discussed, we decided to develop ePOCS within a context of hospital-based recruitment by clinical teams. A key challenge was designing the system with capacity to efficiently receive notice and information about newly consented patients (e.g., contact details), from multiple recruiting teams in different hospitals.

Patient usability

Most cancer survivors are older (>65 years), with associated lower levels of computer literacy (Maddams et al, 2009; Wagner et al, 2010). Consequently, an important challenge was designing the website and QTool to be sufficiently simple and user-friendly for those with limited information technology (IT) skills.

Data linkage

ePOCS aims to collect PROMs online and link them to clinical data in the registries. A key challenge was ensuring the system's ability to identify, track and link the involved data without error.

Data security

The system will handle sensitive patient-identifiable data. An imperative, therefore, was developing the constituent data stores and flows to ensure whole-system security.

Key development methodologies

Process mapping

Throughout development, the research group met regularly to process map the system. Using Microsoft (MS) Visio, the envisaged and emerging system was iteratively mapped in terms of its constituent parts, data flows and involved human activities. Process mapping was undertaken to help the development team achieve a clear and shared understanding of the system, determine technical specifications and identify and solve design challenges. Process mapping is increasingly used in health care to help delineate, design and safety-assess complex systems, including clinical processes and trial procedures (Whitman et al, 1999; Rosen et al, 2009).

Agile methods

The system was generally developed using agile methods, which are characterised by emphasis on the fluid and evolving nature of IT development, continuous communication between users and developers, and regular user-review of incremental versions of products throughout development (Dybå and Dingsøyr, 2008). This meant the research group worked collaboratively with the informatics specialists, rather than simply commissioning IT tasks, and that the ‘specification-build-test’ stages of development proceeded in repeated iterative cycles, rather than separate linear phases. Agile methods have been successfully used in the development of several previous health-related informatics systems (Kane et al, 2006; Narasimhadevara et al, 2008).

Stages in system development

Determining system specifications

Initial specifications were generated by the research group through discussion and brainstorming, and were guided by the need to develop a system that is user-friendly, secure and potentially UK scalable. As an example, early QTool specifications included ability to display PROMs with varied response formats, cross-browser compatibility and different, password-secured functionalities for administrator-users and patient-users. Following agile methodology, most specifications were refined and augmented during development, informed by process mapping, feedback from the informatics specialists and usability testing.

Building technical components and data flows

QTool was designed and built by X-Lab using jQuery and MS ASP.NET and SQL Server. The website was constructed by a university-employed multimedia specialist, through Adobe Dreamweaver, using HTML, CSS, PHP and JavaScript. The Tracker was built by a NYCRIS and NCIN-employed database manager; the database tier was built using MS SQL Server, the front-end application tier was created using MS Access and the two tiers connect using open database connectivity (ODBC). To establish data flows, the IT specialists building the different components exchanged data structure specifications and data definition scripts, and worked collaboratively to harmonise the components' architectures. Adjustments to existing data flows were made, after obtaining permissions, by the locally responsible IT teams in liaison with the ePOCS IT specialists. System development also involved setting up a system-specific NHS email account, for use by the administrator team for ePOCS-related patient correspondence.

Usability testing

Throughout development, the research group comprehensively tested the website, and both the administrator and patient functions of QTool; numerous PROMs were programmed in and completed through the patient interface using dummy logins. Later in development, a convenience sample of seven cancer survivors tested the website and QTool; patients were asked to complete five PROMs and provide feedback on the system, taking into account how it looked, how well it worked and its ease of use. To obtain an ecologically valid test, patients had a range of computer literacy (not all owned a home computer), and completed the testing unsupervised from a community location of their choice. Key findings from the usability testing are summarised in Figure 1.

Figure 1.

Key issues highlighted and resolved through system usability testing.

Results

Overview of the ePOCS system components and data flows

A graphical overview of the developed system is shown in Figure 2. Patients' complete PROMs online using QTool, and the responses are imported into the NCDR. Patient monitoring and communication are semi-automated through the Tracker; the database tier is stored on the regional cancer registry server, and receives nightly data feeds from the registry and QTool; the application tier is used by the ePOCS administrator team to prepare and send necessary communications. Correspondence is wholly electronic for patients able and willing to provide an Email address. Key QTool and Tracker functionalities are summarised in Figure 3. ePOCS is currently honed for RN-led recruitment, from hospitals using an electronic patient record (EPR). As diagrammed in Figure 2, the system entails three major data flows.

Figure 2.

ePOCS: a graphical representation of the developed system.

Figure 3.

Key functionalities of the QTool and Tracker system components.

PROMs completion status information from QTool → Tracker

Anonymous (ID only) data on patients' QTool login activity (date and time) and PROMs completion status (submitted or incomplete), are imported from QTool into the Tracker's database on a scheduled nightly basis.

PROMs data from QTool → NCDR

PROMs responses are imported and stored in a queryable database on the NCDR server.

Information about new patients from recruiting teams → Tracker

In the Yorkshire-based feasibility study, the Tracker receives information about new patients from the recruiting hospitals' EPR, via the regional cancer registry. Recruiting RNs manually register consented patients on the EPR; this research-related information is exported nightly to the registry along with patients' clinical information. Through a daily scheduled query, timed to run after the EPR → registry feed, ePOCS ‘tagged’ patients are filtered from the larger registry data set into the Tracker's database.

Overcoming development challenges

Receiving information about incoming patients

For clinician-led recruitment in Yorkshire, where ePOCS is being developed and tested, we decided the most efficient means of supplying the system with information about new patients would be to link it to the recruiting teams' local EPR. In many Yorkshire hospitals, the EPR is patient pathway manager (PPM). Patient pathway manager exports clinical data to the regional registry to assist with registration and, in addition to medical data, contains a research/trials database, in which studies are listed, consented patients ‘tagged’ as such, and associated study events recorded (e.g., date consented; Newsham et al, 2011). To enable ePOCS to receive information via PPM, local hospital IT adjusted the PPM → registry data export to include research information, and to run more frequently (i.e., nightly).

Patient usability

Features were included in the patient interfaces to increase usability for older adults and/or those with limited IT skills. Aesthetically, for instance, all website and QTool webpages have large-size text and navigation buttons, and follow a simple uniform template using a limited number of colours. Functionally, for example, QTool presents PROMs one question per screen, to avoid patients needing to scroll down webpages, and saves PROMs responses entirely automatically, to avoid patients having to remember and manually save. Usability was also enhanced through deliberate non-inclusion of interactive features such as moving elements, popups and downloadable documents. Patient testing led to the addition of further user-friendly features, which are briefly described in Figure 1.

Data linkage

To ensure that data are securely tracked and linked through the system, all constituent components recognise patients using a common unique anonymous six-character ID. As Figure 2 illustrates, this ID must be assigned to patients at recruitment and is thereon the unifying thread through the system's data stores and flows. The ID links with patients' unique cancer registry number, which, as mandated by data protection and information governance regulations, cannot be disseminated or used outside registries. To maintain security and avoid errors (e.g., ID duplication and miswriting), all potentially usable IDs (and corresponding QTool passwords) should be generated and entered into QTool (to allow user authentication) by the ePOCS administrator team before data collection. In the feasibility study, recruiting RNs are given an allocation of IDs on stickers (e.g., #1–150) to assign to patients and attach to paperwork; one ID sticker also contains the associated QTool password, and this is given to patients (on a postcard with printed logon instructions).

Data security

Security features were incorporated into the system to ensure data protection. All data-storing components are password-secured and housed on firewall-protected servers, and all patient-identifiable data are stored within the NHS systems and firewalls. All data flows are encrypted using secure socket layers (e.g., PROMs completed in a web browser → QTool) or SQL Server database transfer system (e.g., QTool → Tracker). To safeguard security and integrity of NHS data and IT systems, patient information is exported from the EPR to the Tracker via the cancer registry (rather than directly), and PROMs data are imported from QTool by the registry (rather than exported by QTool).

Activities involved in running and using the system

Administrator activities

Before data collection starts

Administrators enter the required PROMs into QTool and specify, for each, for which patients each measure is available (e.g., colorectal cancer), from when (e.g., 9 months post diagnosis) and for how long (e.g., 4 weeks). Administrators also generate a list of IDs and passwords, enter them into QTool and provide them to those obtaining patients' consent (in the feasibility study, RNs).

When new patients join

Administrators enter each patient's Email address into the Tracker, and their diagnosis date into QTool, so that PROMs are accessible to complete at the correct post-diagnostic timepoints (in the feasibility study, RNs enquire whether patients are happy to receive E-communications, and if so take down an Email address and send it to the administrators).

During data collection

Administrators use the Tracker daily to monitor patients' PROMs activity and prepare related communications. The Tracker's application interface contains clickable buttons representing all communication types (invitations to complete PROMs, reminder notices, thank you acknowledgements), by delivery mode (Email or letter), at all data collection timepoints; these buttons highlight red when a particular communication type is due. To prepare due communications, administrators click the red-highlighted buttons; the required communications are automatically populated with the relevant patients' details and generated, as appropriate, as ready-to-send Emails or ready-to-print letters. Administrators confirm whether the communications were sent (or not) by clicking on a corresponding red-highlighted ‘activity log’ button.

Patient activities

Patients receive an immediately functional ID and password (in the feasibility study, on a postcard with logon instructions from recruiting RNs). To complete PROMs, patients access the ePOCS website (www.epocs.leeds.ac.uk), and from this the QTool login page, where they enter their ID and password. The QTool homepage contains generic instructions on completing PROMs and lists all current measures for completion. Patients click on the listed PROMs and move through the questions by clicking a ‘Next Page’, and finally ‘Submit’ button. Patients can return to a partially completed PROMs, and continue where they left off, within 24 h; after 24 h, measures are automatically re-administered from the start. Submitted PROMs cannot be accessed or reviewed. When all PROMs for a given timepoint have been submitted, or the completion time-window has expired, the QTool homepage features a message indicating this. Patients receive reminder notices if they have not completed all PROMs, and an acknowledgement thanking them when they have. At new data collection timepoints, patients receive invitations to login again and complete further PROMs.

Discussion

This article has described the rationale and methodology underlying development of the ePOCS system. In ePOCS, we have designed and built a technical platform for collecting PROMs electronically via the Internet, at repeated post-diagnostic timepoints, for linking these with clinical registry data in the NCDR, and for electronically managing associated patient monitoring and communications.

Early indicators of patient participation

A feasibility study of the system is currently underway in two Yorkshire NHS Trusts in conjunction with the NYCRIS regional registry, and within a context of hospital-based clinician-led recruitment; patients are being asked to complete PROMs at three timepoints (⩽6, 9 and 15 months post diagnosis). In the feasibility study to date (November 2010 to August 2011), over 550 patients have joined the ePOCS system (≈60% consent rate), most have provided an Email address for communications (>80%) and ≈75% have fully completed PROMs at the first timepoint (80 questions total); the proportion of missing responses is <1% (i.e., patients' responded ‘prefer not to reply’), and <2% of patients have withdrawn consent. Few patients have contacted the administrator team for help (<10%); moreover, many queries have concerned the same easily rectifiable issue (misreading zeros and letter Os in ID/password). Thus far, the most common reasons offered for not joining ePOCS are a lack of interest in and/or access to the Internet.

System accessibility for patients

Although not all patients are Internet users, ePOCS is a future-focused system, and the ‘digital divide’ is a time-limited problem. The number of UK Internet-enabled households and individuals is increasing year-on-year; in 2010, 73% of households had Internet access, compared with 57% in 2006, and 73% of adults used the Internet at least weekly, relative to 51% in 2006 (ONS, 2010). Furthermore, the government is currently funding a ‘Race Online 2012’ campaign to improve digital literacy in the UK, particularly among older and unemployed people. At present, for patients who are not independent Internet users, our ongoing feasibility study has highlighted that relatives are often able and willing to provide assistance, and that some hospitals have charitably funded volunteer-supervised patient computer facilities. Internet-enabled computers are also accessible, at no or minimal cost, in public libraries, community centres and high-street cafes, and low-cost government-funded IT training courses are provided across the UK. However, for the short-term future, it is perhaps inevitable that PROMs will need to be administered simultaneously online and via paper; The Netherlands PROFILES registry, although a web-based facility for electronic PROMs, currently offers paper versions at patients' request (van de Poll-Franse et al, 2011).

Challenges to sustaining and scaling up the system

Maintaining technical harmonisation

A technical challenge for ongoing running of the system is maintaining harmonisation of the constituent components, so that the data flows continue to function. Changes to components are likely to necessitate immediate corresponding adjustments to (some of the) other components. However, subject to sufficient funding and good collaborative working relationships with IT specialists, such adjustments should be simple and quick to execute. Similarly, as IT in general advances, aspects of the system's components may need to be adapted in order to remain current, efficient and maximally user-friendly. However, this is inevitably the case, not only for ePOCS, but any IT-based system.

Devising local solutions for supplying ePOCS with information about new patients

A challenge in rolling out ePOCS beyond Yorkshire will be finding local solutions for feeding the system with information about incoming patients. In the Yorkshire-based test sites, ePOCS receives this information through linkage with the local EPR (PPM). Although the use and sophistication of EPRs are continually increasing, not all hospitals currently have an EPR, or an EPR with the research-related functionality of PPM. However, the role of PPM within the ePOCS system could be performed by an alternative purpose-built database. Such a database could be built similarly to the Tracker component and comprise a database tier, housed on an NHS-firewalled server, and an ODBC-connecting application tier, accessible to authenticated users on any computer via a virtual private network. Recruiters could record new patients on this database, and relevant clinical information to allow patients' identification could be inputted manually or imported from an EPR. Information from this database could be added to an existing EPR → registry data flow and, as in the Yorkshire set-up, filtered into the Tracker via the regional registry. The information could also be fed directly into the Tracker; as this has a defined input specification, such a data flow could be readily established. As an alternative to a purpose-built database, where there is a local EPR, it may be possible to enhance its functionality to be similar to PPM. The best means of supplying the system with information about new patients, however, depends on the context of patient recruitment. In the feasibility study, patients are being recruited in secondary care; in the future, however, others using the system may choose to recruit patients in primary care or, if UK governance regulations were to change, directly via cancer registries.

Maintaining effective patient recruitment and communication procedures

Another challenge to system sustainment and scale-up is keeping recruitment and communications sufficiently personalised to motivate patients' initial and continued participation. In the feasibility study, patients are mostly recruited face to face by RNs during routine outpatient appointments, often after introduction to ePOCS by a familiar doctor or specialist nurse. These recruitment procedures may not be cost feasible on a larger scale; however, less-personalised and labour-intensive procedures may yield lower rates of consent and/or PROMs completion. In the feasibility study, patients whom it is not possible to see face to face are sent a letter (signed by their consultant); it will be important to analyse whether patient participation rates differ as a function of recruitment approach. It will also be important to compare ePOCS consent rates with those for the new Netherlands PROFILES registry (van de Poll-Franse et al, 2011). PROFILES recruits entirely via letters (from patients' former physician), and also approaches patients later in the cancer pathway, post registration, using registry records; to collect PROMs over as much of the cancer continuum as possible, in the feasibility study, we are approaching patients ⩽6 months post diagnosis, using hospital records. Recruitment to ePOCS is evidently distinct from the system itself, and devising effective recruitment procedures that are viable at scale is not an ePOCS specific, but a universal challenge.

Currently, ePOCS patient communications are automatically generated, but not sent; this allows administrators to omit a communication(s) on a patients' request. For instance, a patient may ask for reminders to cease while they are in hospital or on holiday. Although it is possible to accommodate such requests in the feasibility study, if ePOCS were scaled up, tailoring communications would become more difficult. It would not necessarily be unworkable, however; of the 1000 plus communications due in the feasibility study thus far, only a small minority (<2%) have not been sent following patient request. Furthermore, the Tracker could be reprogrammed to automatically send prepared communications (by Email) unless there was administrator intervention/override. Time savings from such additional automation may help allow for tailoring communications even at scale.

Using the system: applications and implications

ePOCS is a technical platform that could be used by different groups for different purposes. The system could be used by university research groups, independently but simultaneously, to facilitate and support different PROMs-based survivorship cohort studies. Alternatively, the system could be used in a national government initiative to realise the NCSI goal of increased cancer PROMs collection. Who uses ePOCS, and for what purpose, has implications for the associated ethical and recruitment processes. For our feasibility study, we obtained medical ethical approval, and patients provide written consent (including for PROMs linkage to clinical data), which is stored locally (by our research group, with a copy filed in patients' medical notes). If university groups use ePOCS to support survivorship cohort studies, they would similarly need to obtain ethical approval for each study, and collect and store all patients' fully informed written consent. However, a government-led initiative may not require ethics approval, and may also be granted permission to recruit patients without obtaining written consent, or, as is being done in The Netherlands PROFILES registry (van de Poll-Franse et al, 2011), by obtaining and storing consent electronically (i.e., via the ePOCS system). The accessibility and dissemination of ePOCS-collected data will be dependent on the aims and decisions of those using the system. University groups using the system to support individual research studies may wish to retain the data entirely for their own analysis and dissemination. In contrast, if ePOCS is used as part of a government-led UK-wide PROMs collection initiative, the resultant data set is likely to be a national resource, freely available on request for hypothesis-driven analysis.

Potential future system improvements and extensions

Our ongoing feasibility study has already highlighted potential system improvement modifications. For instance, the Tracker's operation speed could be greatly increased, and QTool could be enhanced by inclusion of a quicker means of entering large lists of pre-generated IDs/passwords, and by addition of reporting functionality. ePOCS has generally been built flexibly, however, and the constituent components can be readily modified and extended. QTool, in particular, has been built to be easily augmented with further functionality; a QTool-version2 is already underway, which includes a means of entering thousands of IDs/passwords simultaneously, as well as reporting functionality. QTool-version2 is also being built with extra features such as capability for EPR linkage, and question-dependency based on responses to items in a different PROM. In the near future, subject to funding, we aim to link QTool with interactive voice recognition software, which would allow PROMs to be completed orally by telephone, as well as online, thus enabling participation by patients who are not Internet enabled and/or high literate.

Concluding comments

The NCSI prioritises increased and improved measurement of UK cancer survivors' experiences. We have designed and built an electronic system in which PROMs are completed on the Internet using a secure, flexible questionnaire administration tool, the response data are stored in the cancer registries/NCDR, patient monitoring and communications are semiautomated via a tracker database, and patient correspondence is primarily Email based. A feasibility study of the system is currently underway, and the results of this will be the subject of future papers; early indicators, however, are thus far promising with regard to patient participation and proof-of-concept concerning the underpinning informatics infrastructure. ePOCS has the potential to provide an affordable UK-scalable technical platform to facilitate and support epidemiological PROMs collection and clinical data linkage.