TRANSFoRm eHealth solution for quality of life monitoring.

Patient Recorded Outcome Measures (PROMs) are an essential part of quality of life monitoring, clinical trials, improvement studies and other medical tasks. Recently, web and mobile technologies have been explored as means of improving the response rates and quality of data collected. Despite the potential benefit of this approach, there are currently no widely accepted standards for developing or implementing PROMs in CER (Comparative Effectiveness Research). Within the European Union project Transform (Translational Research and Patient Safety in Europe) an eHealth solution for quality of life monitoring has been developed and validated. This paper presents the overall architecture of the system as well as a detailed description of the mobile and web applications.

I. Introduction

The standard method of collecting PROMs (Patient Recorded Outcome Measures) relies on paper forms that are presented to the patient. A more recent approach uses web or mobile software [3][4][6] to assess patient health status and quality of life. Electronic monitoring of PROMs allows the health of patients with chronic disease such as diabetes mellitus and Gastroesophageal reflux disease (GORD) to be monitored closely, without the need to visit a health institution for each report. In addition, those data can be pre-processed automatically by algorithms which are looking for alarm symptoms and signs, and if necessary notify the GP (general practitioner) that the patient needs attention. These features can thus improve the quality of care and the quality of life for patients requiring close monitoring, like elderly people or people suffering from chronic diseases.

Despite the potential benefit of this approach, there are currently no widely accepted standards for developing or implementing PROMs in CER (Comparative Effectiveness Research). From time to time targeted solutions are developed to run a study focused on a specific trial [2].

Digitalising patient data plays a major part in modernizing the Polish health care system. Since 2014 all medical data must be stored in an electronic form in Poland. Furthermore, since the beginning of 2015 the patients in Poland should have access to the application called e-Prescription [7], one of its major functionality is to provide electronic PROMs to the patient.

II. Transform Clinical Trial Management System

TRANSFoRm is an EU funded large scale project within the 7th Framework Programme, which aims to develop and evaluate a Learning Healthcare System for European Primary Care. The project has three main objectives, (1) to facilitate multiple site genotype-phenotype studies, (2) to prototype a diagnostic decision support system linked to Electronic Health Record systems (EHRs), and (3) to enable multi-site, practice-based Randomized Controlled Trials (RCTs) by embedding distributed trial functionality into existing EHR systems. A core output of the project is the specification and demonstration of a ‘functional’ eCRF (electronic Case Report Form), designed to enable the collection of semantically controlled and standardized data from within an EHR system.

The third objective is based on the clinical research question “does continuous PPI (Proton Pump Inhibitors) differ from on demand PPI use regarding symptom severity and quality of life [1]”? To answer that question a multi-centre international RCT including 700 GORD patients randomized to continuous or on demand PPI treatment has been designed [5], EudraCT-number 2014-001314-25.

The functionalities of the TRANSFoRm applications include identifying prevalent and incident cases of GORD, randomizing patients to on-demand or continuous consumption of PPIs, and following these patients using patient mobile or web applications and eCRFs completed by medically qualified personnel at practice visits. The data submitted by the patients using the mobile or web applications are PROMs while the data entered by the clinician using eCRFs are CROMs (Clinician Reported Outcomes Measurement). The task was to build the system which can easily integrate with existing systems i.e. different EHRs and allow to fully conduct multi-centre international randomized controlled trial and at the same time make it as easy as possible for the patients and GPs.

The TRANSFoRm Study System (TSS) is an electronic platform to collect PROMs and transfer data to the EHR systems. The TSS consists of five major parts (Fig. 1):

Fig. 1.

The system architecture for the TRANSFoRm Study System.

Study Server (SS) – manages the connection between mobile and web applications and the external parts outside of the TSS

Study Database (SDB) – stores all of the information about studies, patients, randomization etc. It is used also by the middleware and the Data Node Connector (DNC)

web application – an application placed on the web server that enables filling out PROMs by the patients and CROMs by the GPs

mobile applications – native applications for Android and iOS systems that enable filling out PROMs by the patients

middleware - an Enterprise Service Bus which serves as a connection, authorization and security layer between TRANSFoRm Study System and the rest of the TRANSFoRm infrastructure.

This paper focuses on the mobile and web applications, their functionality, flexibility and validation process.

III. Mobile And Web Applications

TRANSFoRm Study System mobile and web applications are designed to enable the study participants filling out the PROM questionnaires. The mobile applications are available on Android and iOS platforms. The web application also contains the eCRF where the GP fills out the CROMs. The applications are capable of generating human readable version of any questionnaire provided in the ODM (Operational Data Model) standard. The interface was designed with respect to the Android, iOS and web platforms’ guidelines and best practices. Moreover the applications were built upon the standard system user interface elements, therefore using the application should be comfortable and intuitive to the patients.

A. Requirements and availability

The mobile application available on the Android platform is compatible with the Android system version 4.0 and higher while the mobile application available on the iOS platform requires the iOS system version 7.0 or higher. The mobile devices running other platforms are not able to operate the TRANSFoRm Study System mobile applications, but can still use the web application through their system web browser. The mobile applications are available on platform specific app markets, the Android application at [9] and the iOS application at [10]. The web application is available at [11].

A user account in the TSS is created for patients enrolled to the clinical research study. A unique user name and password for the mobile and web applications are provided to the patient by an email.

Every patient authorized by the TRANSFoRm Study System can perform the following actions within the applications:

log in and log out

see the list of pending questionnaires

see the list of completed questionnaires

fill out pending questionnaires and send them to the TRANSFoRm Study System

close a questionnaire while in the process of filling it out (the current progress will be lost)

In case of any warnings or errors, the mobile and web applications notifies the patient through the system alert boxes (Fig. 2).

Fig. 2.

The example of the alert box in the Android application. The iOS and web applications have almost identical appearance of the alert box.

In order to log in the patient has to provide their credentials. If the patient has lost or forgotten the password, the “Forgot your password?” button might be used, to receive the instruction on how to recover the password. Once the login operation is successful, the patient may access the questionnaires assigned to him.

If the login operation encounters any problem, the patient will be informed with the alert box. The possible errors are: no Internet connection, empty username or password, wrong credentials or other problem in communicating with the TRANSFoRm Study Server

B. Questionnaires list screen

The “Questionnaires” screen (Fig. 3) contains the full list of questionnaires assigned to the patient. In case of the mobile applications the list is divided into pending (area 1) and completed questionnaires (2). In case of web application there are separate lists for the completed and pending questionnaires. The pending questionnaires can be filled out while the completed questionnaires are non-selectable, thus cannot be changed. In order to fill out the questionnaire the patient has to click on the desired questionnaire (3). The questionnaires assigned to the patient is defined by the clinical researchers and allocate to the patient in the TRANSFoRm Study System. If no questionnaire is assigned to the patient, the list is empty and the message “There are no questionnaires to complete” is displayed to the patient.

Fig. 3.

The questionnaires list screen in the Android (on the upper left), iOS (on the upper right) and web (at the bottom) applications.

The “Questionnaire” screen allows the patient to fill out the pending questionnaire. The example of filling out the Reflux Disease Questionnaire is presented in the Fig. 4. The patient should perform the following actions there:

Fig. 4.

The example of filling out the Reflux Disease Questionnaire in the Android application.

Answer to all questions on the first screen by selecting the appropriate answer from the list

Click the Next button

Answer to all questions on the second screen

Click the Send button

If some answers are missing, the alert box pops out and the questions without answers are marked red as in the Fig. 5.

Fig. 5.

The example of missing answers in the web application. Missing answers are marked with red color.

The questionnaire can be closed at any time by the Close button. In such case, the current progress will be lost and the empty questionnaire still will be available as a pending questionnaire.

C. Data safety

A communication between the components is held over a secure SSL connection and the requests are structured in XML format.

Communication with the TRANSFoRm Study System requires a valid session key which is generated every time the patient logs in into the system. For safety reasons, the key is valid for 30 minutes. After that time the first attempt to communicate with the TRANSFoRm Study System will automatically log the patient out from the mobile or web applications and if the patient wish to continue working in the TSS system it is required to log in again.

To ensure the highest possible security and data privacy no data at all are stored on the patients device, which is the reason why answers cannot be saved and the questionnaire has to be completed at one time point. The completed questionnaires are immediately sent to the TRANSFoRm Study System and stored in the TRANSFoRm Study Database.

D. Data model for storing results

All of the PROMs that were created for the GORD Study are based on the CDISC ODM (Operational Data Model) XML-based standard. It is one of the components taken from the CDISC Data Exchange structure. ODM is a vendor and platform independent format for exchanging and archiving clinical study data. The model includes clinical data along with its associated metadata, administrative data, reference data and audit information. All the information that needs to be shared among different software systems during the study setup, operation, analysis, submission or for long-term retention as part of an archive is included in the model.

In the GORD Study a single PROM contains several questionnaires, e.g. the Short-Form 12 (SF12) PROM contains: GERD (Gastroesophageal reflux disease) Impact Scale, RDQ (Strengths & Difficulties Questionnaires) and SRH (Self-rated health) questionnaires. Questions and answers in the ODM questionnaires are coded based on annotations chosen by the study designer.

When a patient completes a questionnaire a new segment called Clinical Data (CD) is created and inserted inside the ODM structure. CD is a part of the ODM specification. All of the answers are coded using specific phrases formulated by the study designer. For example answer “Yes” for English which is “Tak” for Polish in the CD section will be saved as “CL.YN.1”. This is very convenient because TRANSFoRm GORD Study is multilingual.

E. Generalisability

The mobile and web applications were designed to be as flexible as possible in terms of supporting different types of questionnaires and multiple language versions at the same time. The applications are able to generate a human readable version of any questionnaire as long as it is compatible with the ODM standard. The applications are equipped with build in logic to parse and display ODM-structured files. Therefore, providing the new type of questionnaire to the patients requires only creating the proper XML document.

Furthermore, the mobile and web applications are able to properly switch the language of the questionnaire depending on the language selected on the patients device or in the patients browser. The only requirement is that the appropriate translation is available in the ODM file describing the questionnaire. Currently, the TRANSFoRm study includes four languages: English, Dutch, Polish and Greek. Adding another language is a simple process, it requires translating the questionnaire into a new language and embedding the translation into the ODM file. An example of translating the “Self rated health” question into Dutch and Polish is presented in Fig. 6.

Fig. 6.

The example of translating a single question in the ODM format.

F. Designing questionnaires

The study designer selected the questionnaires included in the GORD study. There were no technical restrictions to enable all necessary types of questions and answers to be included. Since ODM is an extended XML model it needs to be stored as the XML file.

In the scope of one study all of the data gathered are consistent. TSS provides the same questionnaires for every country and practice participating in that study. When someone creates a new study then it would be necessary to take all of the questionnaires from another already created study to ensure consistency.

TRANSFoRm GORD study questionnaires can be exported and freely imported to a different study and they can be modified by the study designer. Knowledge about the CDISC ODM structure is required when someone wants to tamper with these questionnaires. Documentation for the ODM standard is available, but unfortunately currently there is no dedicated software for WYSIWYG creation or modification and it needs to be done manually.

G. Data analysis

A dedicated service that allows analysis of data gathered during the study has been created. It is called TRANSFoRm Researchers Workbench (TRW). This tool aggregates all of the data from one instance of the SDB (Study Database). One study database can store information from different studies, countries, practices, diseases, etc. How much information can be saved is only related to the storage space available to the SDB. TRW presents data on a few layers:

Study level – shows all of the available studies and all of the completed ones (Fig. 7). It displays information about how many patients are participating in that study

Fig. 7.

TRANSFoRm Researchers Workbench – study level.

Country level – displays information about countries in which a particular study is run (Fig. 8). Additionally information about study count is displayed. It is possible to start one study many times in one country or practice. When it comes to running a few studies in one practice it is necessary to specify different time periods in the SDB (not stacking time periods)

Fig. 8.

TRANSFoRm Researchers Workbench – country level.

Practice level – presents the information about practices which are participating in a selected study (Fig. 9). It shows study start date, end date and if the study is active or not. A researcher can check how many questionnaires of each type are filled out as well.

Fig. 9.

TRANSFoRm Researchers Workbench – practice level.

Patient level – the researcher can see here, when exactly a particular questionnaire was filled out by a patient (Fig. 10). All of the Patient IDs are encrypted. Researcher cannot see patient name.

Fig. 10.

TRANSFoRm Researchers Workbench – patient level.

There are two additional ways for analysing the data gathered by web and mobile applications:

Using an SQL query a researcher can extract specific data from the SDB

Selected data from the SDB can be flagged and they can be accessed through patients account using web application. It is possible only to see answers made by patients. It is not possible in any way to modify data using this method.

H. Technical challenges

There were a lot of challenges during design, development and integration phases of the mobile and web applications. The most important of them were:

Study database design – a complex structure had to be created to satisfy the needs of running multiple multilingual studies at one time. Database structure has to be able to store many studies, practices, patient data, time tables and logs. This was resolved during a design period of one year. TSS developers had frequent scheduled meetings with the GORD study designers, general practitioners, researchers and people who have experience with creating commercial medical systems,

Communication with the DNC – Data Node Connector is a Transform System component which mediates between a vendor’s EHR system and Transform Study System. The DNC is installed locally on the GP computer and on the one hand pools the data (exclusion criteria, randomisation results, forms etc.) from TSS, prepopulate the forms with the data extracted from EHR and presents them on the GP’s screen, and on the other hand saves all forms filled out by the GP in both the EHR and the TSS. Additionally the DNC encrypts all patient data, so nothing stored in the TSS can be used to directly identify the patient. It was necessary to create web services that could be used to communicate between the DNC and the TSS. Not only type of web services had to be specified but also order in which they would be invoked. Few scenarios were created to accommodate these processes. This was related to the design and integration stage of developing the TSS. This lasted for over two years. Frequent meetings with DNC designers and EHR vendors solved this issue,

Creating a system to display questionnaires to patients – in early stages of the project it was decided that all questionnaires need to be store in the CDISC ODM structure. TSS developers had to devise a way to extract, convert and store data represented in the ODM format. Not only data would have to be displayed on a web page but also on various mobile devices. Additional communication and data formats had to be created. All of this had to be an universal design that could be handled by turning into a web page and applications for Android and iOS operating systems.

IV. GCP Validation

The applications will be tested in three steps. First, the applications have been GCP (Good Clinical Practice) certified. Second, the application has been tested by test patients. Third, the applications are evaluated in a randomized controlled trial comparing the full TRANSFoRm system with manual patient recruitment, a web based and paper based PROM collection. Entire validation from obvious reasons was conducted together with entire TSS platform.

Government rules, regulations and guidance documents contain specific requirements for computerized systems. One of the most important certifications for medical software is the GCP. It was vital for the TSS to be GCP certified. Two studies were conducted to satisfy the GCP validation requirements. First, the TRANSFoRm software was installed in three selected practices in Poland and 10 patients at these practices were recruited to test the application to fill out the PROMs. Second, data for 10 simulated test patients were inserted into the mobile and web application to test the system.

Overall, the patient’s experiences using the PROM application was positive, with 6 out of 10 patients preferring the application over completing the questionnaire on paper.

V. Discussion And Future Work

The TSS software was designed as a generic solution to support embedding of clinical trial functionality into Electronic Health Record systems and providing electronic data collection capabilities. The only requirement is that study is designed with accordance to the CDISC (Clinical Data Interchange Standards Consortium) SDM (Study Design Model) standard [8]. If this condition is fulfilled and the SDM standard is used then all of the ODM questionnaires can be used to display questionnaires on the mobile and web devices to the patient.

Furthermore, these applications are not limited to clinical trials. With few changes to the software it is possible to use the applications for any type of patient surveys. The ODM standard is flexible and can allow that.

With the TRANSFoRm tools GCP certified and validated, the effectiveness of the system to identify, include and follow patients is evaluated in a randomized controlled study comparing the TRANSFoRm system with a web based system not integrated with the eHR and PROMs completed on paper. The evaluation study gives a head to head comparison between the two methods while also answering the clinical research question. The study is running in Poland, the Netherlands, the United Kingdom and Greece. As part of the evaluation study, feedback from the patients using the TSS applications will be gathered and used for future improvements of the applications.