Point of Care Research: Integrating patient-generated data into electronic health records for clinical trials

Abstract

Integrating patient-generated data into clinical research would improve the reliability of results, especially when longitudinal, chronic, home-based monitoring is needed. To this end, we designed, implemented, and tested a system that allows integrating patient-generated data into electronic case report form (eCRF), using a standards based architecture that ensured the fulfillment of the major requirements for digital data in clinical studies. The system was tested in a clinical investigation for the optimization of deep brain stimulation therapy in patients with Parkinson’s disease that required both the collection of patient-generated data and of clinical and neurophysiological data. The validation showed that the implemented system was able to provide a reliable solution for including the patient as direct digital data source, ensuring reliability, integrity, security, attributability, and auditability of data.

Introduction

Point of Care Research (POC-R) is now gaining increasing attention as a way to enhance the integration between clinical research and clinical practice¹ so that the FDA recently drafted a guidance on the “Use of Electronic Health Record Data in Clinical Investigations” ². Including electronic health records (EHRs) as data source for clinical trials would take advantage of the potentials of combining, aggregating, and analyzing longitudinal patients’ information, thus facilitating the collection of valuable information. It is expected that “EHRs may have the potential to provide clinical investigators and study personnel access to real-time and longitudinal health care data for review and can facilitate post-trial follow-up on patients to assess long-term safety and efficacy of medical products” ².

However, longitudinal clinical trials that require patient’s monitoring in a chronic, home-based condition may benefit of systems able to integrate patient-generated data into EHRs and, in turn, to electronic Case Report Forms (eCRFs). Personal mHealth Apps and the Internet of Things (IoT), at a time when there are more mobile connections than the entire human population, can support patients managing medical conditions, monitor lifestyles, and may even provide medical advice. Such technologies may also be adapted to become a new source of data, directly collected from patients in their ecologic environment, that can be used in clinical trials. To do so, patient-generated data in the chronic, home-based environment needs to be integrated with clinical hospital information systems (HISs) and EHRs.

As previously proposed^3,4, a standards-based architecture could be used, independently from the specific EHR system considered, to allow the direct exchange between mHealth Apps and EHR systems. The standards-based architecture require specific document templates taking into consideration patient’s identification issues, privacy, reliability, and interoperability, and it was successfully proven in a prototype environment⁴.

However, integrating patient-generated data collected while the patient is at home into the streaming of clinical trial data poses some challenges, that reflect the “ALCOA” requirements (A – Attributable, L – Legible, C – Contemporaneous, O – Original, A – Accurate) stated by FDA guidance on electronic data sources in clinical trials:

1. Attributable: each document (and modification or review) has to be attributed to an author;

2. Legible: data should be clearly presented in a human-readable format;

3. Contemporaneous: in addition to the synchronous data recording, any modification should be time-stamped, tracked, motivated, and signed and then synchronized;

4. Original: data should be captured directly and kept safe and de-identified, because the mobile environment is supposed unsafe;

5. Accurate: patient-generated data may pose the problem of reliability, being the patient’s health literacy generally low. Also, data collected from personal medical devices should be considered. Finally, data have to be collected strictly following the clinical protocol, otherwise they cannot be used in the clinical investigation;

Considering these requirements, we designed and implemented a standards-based system that uses

1. a specifically designed web-based platform that integrates EHR features with signal analysis and management⁵;

2. a workflow engine to manage the clinical trial process;

3. a set of mobile apps and wearable devices for patient’s data collection that exchange information using a standards-based document set.

We tested the system in a clinical investigation for the optimization of deep brain stimulation (DBS) therapy in patients with Parkinson’s disease that required both the collection of patient-generated data and of clinical and neurophysiological data.

Methods

System Architecture

The system integrates information from different actors (Figure 1), namely the Patient, the Doctor, and the Researcher. The Patient may be supported by a Caregiver. The architecture has three main components: the Patient System, the Workflow Manager (WFM), and the WebBioBank (WBB).

Figure 1.

System Architecture

Patient System

The Patient System consists of both hardware and software to ensure the provision and use at home of the information necessary for the proper implementation of the clinical trial. The hardware is composed of a Wearable Device (WD) and a Mobile Device (MD), while software refers to the mHealth app for the Patient and the Caregiver. The MD collects all the information attained by the WD (in our specific application, it consists of accelerometer acquisition) and the self-reported data (Patient Diary), and communicates them to the WFM via an external gateway. The main components of this device are a large touchscreen (>3.7”) for better filling out the Patient Diary, a storage system (larger than that made available by the WD) to temporary store collected data before sending it to the WFM, a Bluetooth transceiver to communicate with and receive acquired data from the WD, and a long-life battery (at least 8h).

The connection from the Patient System to the WFM is implemented by the exchange of XML-based CDA-2 structured documents optimized for the anonymous communication with mobile applications⁴, so that no identification data is sent through unsecure connections, or retained into unsafe environments.

The WFM communicates with the Patient System by exposing services that manage reminders and notifications to the mobile application.

Workflow Manager

The WFM is a system that provides the interoperability and electronic exchange of information between the Patient System and the WBB. This system offers to the Researcher the ability to model the patient protocol as a graphical flowchart in a workflow editor and to the Doctor the ability to associate each Patient to the specific protocol and execute such process in a workflow engine.

A proprietary workflow composer is used for viewing and creating patient protocols. Key components of each protocol definition are participants (i.e., patients, caregivers, doctors, researchers and inspectors), activities (e.g., data acquisition, filling patient diary, drug administration, …), transitions (e.g., end data acquisition and send the CDA-2 document), schedules (e.g., filling the patient diary each 30 minutes), and variables.

For patient protocol execution, the WFM extends the Mirth Connect health care integration engine⁶. Mirth Connect is an open source HL7 interface engine is rich in features as well, including filtering, validation, transformations and routing of documents through different kinds of information system.

Users with different privileges and roles will gain access to the WFM according to their job function and to the clinical center they belong to, according to each specific research protocol. User access is managed and tracked in the WBB and synchronized with the WFM access control.

WebBioBank

WBB (www.webbiobank.com) is a web-based platform that integrates clinical data collection with signal management and processing⁵. The system is based on the wHospital framework⁷ that is a commercial EHR system used in several healthcare institutions and Regional implementations. WBB includes dedicated functionalities to support multicenter clinical studies and an adjunctive module for biosignal storage, management, and analysis⁵. The system is accessed through a standard web browser, allowing users to perform various tasks for data management in an anonymous mode according to shared protocols, thus guaranteeing real time interaction between researchers and clinicians in different research centers. Clinicians can add patient’s clinical information using shared clinical forms specific for the clinical study, whereas researchers develop and use shared advanced algorithms for signal processing that can be combined in analysis chains, ensuring that the data processing and analysis are the same in all of the centers involved in the research study. To extend its use to clinical trials, WBB provides data de-identification, ensuring patient’s privacy also when involved in multi-center studies. To enable anonymous data collection, on the web-based platform, only unique patients’ IDs (IDBAC) are saved and records do not include identifying demographic information. The unique IDBAC ensures attributability of records to patients. Patients demographics are visible only to the users belonging to the clinical center (operative unit, OU) in charge of the patient. Each OU can therefore use WBB as an EHR. WBB implements a Role-Based Access Control ensuring that only authorized users, with pre-defined roles, will gain access according to their job function in the clinical center during each specific research protocol. Also, the system keeps track of logins and failed login attempts. Since WBB integrates the functionalities of traditional EHRs with those of research support systems, it implements a “research” EHR (rEHR)⁵.

Structured documents templates

Data reliability, integrity, and attributability was achieved by exchanging standard CDA-2 documents. The CDA-2 template used is a modified version of the Personal Helathcare Monitoring Report (PHMR) CDA2 template (CDAR2_IG_PHMRPTS_R1.1_DSTU_2010OCT) adapted to fulfill the requirements of the mHealth App/EHR data exchange as already described in ⁴. We will refer to this template as mobile PHMR (mPHMR) The major changes introduced in mPHMR regard the possibility to recognize the patient as data author (and not only as <recording target>), and the use of de-identified patient’s information, to ensure security. In this implementation, the experimental session ID is also reported in the header, to identify the precise location of the data collected within the clinical study protocol. The <Custodian> is the OU in charge of the patient. The mobile app and device are described as equipment and participate to the data collection as data source. The body of the document is composed by four mandatory sections: Results (LOINC 30954-2), Medical Equipment (LOINC 46264-8), Medications (LOINC 10160-0), and Purpose (LOINC 48764-5)⁴.

Validation case study

Our first target for system validation is the telemonitoring of patients with DBS implant in order to obtain information on therapy optimization. Since our patients face a fragile stabilization period immediately after electrode placement, we decided to make the first system testing in a controlled environment, to keep the risks for patients as low as possible.

We hence used the implemented system to support a clinical trial ongoing at the Fondazione IRCCS Ca’ Granda Ospedale Maggiore Policlinico of Milan (Italy) on patients with Parkinson’s Disease implanted with DBS electrodes. The specific research aimed to test a newly developed CE-marked external prototype for closed-loop adaptive DBS (aDBS). The aDBS device automatically adapts stimulation parameters moment-by-moment to the patient’s clinical state, thus providing optimal stimulation parameters⁸. This external prototype we tested implements an aDBS approach based on the analysis of local neuronal activity (local field potentials, LFPs) captured from the DBS electrodes while stimulation is switched on⁸. In particular, the prototype adapts DBS parameters according using modulations of the LFP beta band (13-35 Hz). In this research study, aDBS was tested in freely moving PD patients for 8 consecutive hours, by continuously monitoring beta band modulations and by assessing aDBS ability to respond to changes in patient’s state (Figure 2). The data collection system we implemented was used to support the research in two ways: (1) collecting clinical data generated by the expert neurologist who assessed the patient during the 8-hours period; (2) collecting patient-generated data in an ecologic but controlled environment, while the patient was left alone doing his/her normal activities in his/her room with the aDBS prototype on.

Figure 2.

8-hours experimental protocol

The experimental protocol is depicted in Figure 2. The study was approved by the institutional review board and by the Italian Ministry of Health, and conformed with the Declaration of Helsinki. We enrolled 4 PD patients who underwent surgery for DBS electrode implant having externalized leads for a week to connect a wearable device for aDBS testing. Two perioperative sessions lasting from 7 to 8 hours were conducted the day 5 and 6 after surgery while the patient was doing his/her normal activities. In the first session, the beta band power was continuously recorded while the patient took its post-operative daily medication dose. In the second session, we added aDBS treatment to beta band power monitoring and daily medication. A neurologist assessed the clinical state and fluctuations at 5 time points (Figure 2) through the motor Unified Parkinson’s Disease Rating Scale part III (UPDRSIII) and the Unified Dyskinesia Rating Scale (UDysRS). During the entire duration of the experimental session, the patient filled in a diary (every 30 minutes) and wore a bracelet to assess his/her bradykinesia state.

Patient’s wearable device and mobile application

Patient’s generated data in the implemented system were of two kinds, the first one being a personal diary, collecting the patient’s state every 30 minutes, with scheduled alerts; the second one being accelerometer data acquired by a commercially available wearable device.

The device used was a Pebble Time smart-watch. It includes a three-axis accelerometer and a Bluetooth connection with a mobile device (Android Phone). A dedicated app was developed to both acquire and store data, and to provide a clinical diary to be filled in by the patient at predefined times. The patient has a personal ID and password to access to the app (enforced by an initial login screen). The mobile phone app implements an algorithm that finds the Bradykinesia Acceleration Scores (BAS) using the accelerometric values of the smart bracelet. The BAS algorithm was adapted from the patent of Griffiths & Horne⁹.

System testing

The system Validation test consisted into two experiments: the first one checked the functionalities of the WBB system and its integration with the WFM, and the second one verified the ability of the app to collect patient-generated data in an accurate and secure way. Tables 1 and 2 (columns 1 and 2) detail the test protocols of the two experiments and their expected results. Errors are detected when the test result differs from the expected result.

Table 1.

Validation tests for the WBB and WFM systems. The ALCOA cell line (column “Results”) represents the verification of requirements fulfillment with the results obtained by the tested action (green = achieved).

Table 2.

Validation tests for the Patient System. The ALCOA cell line (column “Results”) represents the verification of requirements fulfillment with the results obtained by the tested action (green = achieved).

Results

System implementation

The system was fully implemented to be used in the validation case study. WBB was configured in terms of users, roles, and forms to support the 8-hours research study in the hospital-based ecologic but controlled environment. WBB fulfills the requirements for clinical study data collection: patients are de-identified to ensure security; the clinical forms are developed by the researcher (usually the principal investigator), filled in and signed by the author, reviewed by the principal investigator, and changes/modifications are tracked, time-stamped, and signed whenever they occur, thus guaranteeing integrity, attributability, and reliability. The definition of the “inspector” user role allowed auditability. Figure 3A shows the snapshots of the main rEHR forms created to collect data from PD patients undergoing the experiment.

Figure 3.

System implementation for the validation case study. A) Snapshot of the WBB form for UPDRS III. B) Patient assessment and patient diary. C) Accelerometer exemplary data. D) Correlation between UPDRS III score and bradykinesia accelerometer score (BAS). Note that the system was implemented in Italian.

Two web services were developed to support the communication and integration between the WBB and the WFM. The first one (wHvpc) is devoted to the integration of user roles and patients’ IDs: it allows the verification of the privacy criteria for doctors/researchers who access the WFM to create or assign the patient’s protocol and, once the doctor accesses to assign the study protocol, allows the exchange of patient’s ID and contact information from WBB to WFM. Then, when the protocol has been assigned and the patient is registered in WFM, the WFM deletes contact information and keeps only the patient’s ID. In this way, the synchronization between the two systems is guaranteed thus allowing attributability and integrity, and patient’s contact information do not reside on WFM, thus allowing security and privacy. The second one (wHcda) is devoted to the exchange of CDA-2 standard documents between the WFM and the WBB. Once the WFM receives patient-generated data from the mobile application, it creates and encrypts the CDA-2 document according to the mPHMR template, and sends it to the WBB using the wHcda web service. Data reliability is therefore ensured by the use of standard documents that are accepted by the WBB platform and processed as clinical documents.

On the patient side, the WFM provides the functionalities for patient’s registration and protocol fulfillment. The WFM stores the patient data into the correct rEHR on the WBB by calling the wHcda service passing the identification numbers of the user (uID), the patient (IDBAC), and the custodian (ID OU). The patient data inside the database are anonymous for all users, and only the patient’s doctor can re-identify them by means of a local registry. Deidentification is guaranteed also by the WFM registration process that does not require patient’s demographic information, but uses the contact information retrieved at the time of assignment that are then deleted when the patient is successfully registered. Thanks to the definition of the patient’s protocol, the WFM is able to send the activity program to the patient’s mobile app, and to provide remainders and alerts when a task is due (e.g., when the patient has to fill-in the diary). Also, in the case WFM does not receive the patient-generated data on time, according to the protocol, it sends new requests, and then notifies the WBB of the deviation from the protocol, sending a specific CDA-2 with the indication of the deviation using the wHcda web service.

Patient-generated data collection for the case study, including a patient’s diary to be filled in and a wearable bracelet for bradykinesia evaluation (Figure 3B), is shown in the sequence diagrams in Figure 4. The algorithm in the mobile app generates a BAS value every 4 minutes of data. BAS is lower when the patient is bradykinetic (Figure 3C). Bracelet data are preprocessed in the mobile app to retrieve the bradykinesia score (Figure 3C). The forms for the patient’s diary consists of a multiple-choice mutually exclusive list that asks the perceived motor status through 4 different answers: “OFF: Bradykinesia and rigidity”, “ST: Transition”, “ON: normal mobility”, and “ON: disabling dyskinesia”.

Figure 4.

Sequence diagram of Patient-generated data collection. A) Accelerometric data acquisition. B) Diary generation

The diary and the accelerometer data is stored internally in a SQLite DBMS. When the device is synchronized with the WFM, a mPHMR document is generated with the all the BAS data compressed and encoded in MIME format in an observation of the CDA-2 document (content-type: application/x-compressed, Content-Transfer-Encoding: BASE64) and all the diary data on another plain text observation of the same document. If the mPHMR document is correctly stored and approved by the WFM, a positive feedback is sent back to the mobile device and the internal database is erased for security reason. This feedback and the other remainders are sent through a web-service exposed by the WFM. The use of standard CDA-2 documents between the App and the WFM ensures data integrity, attributability, and safety (in the CDA-2 the author is the patient, identified only by his/her ID). Also, the mobile app does not retrieve any clinical data, but deletes them when the WFM correctly receives the CDA-2 and validates the data.

System validation

In our experiment, we enrolled 4 patients, 2 doctors, and 1 researcher (the principal investigator). Also, a user with role “inspector” was created to test the audit functionalities. On WBB, the researcher created 7 forms, one for patient’s disease history, one for DBS surgery details (target position, electrodes implanted, intraoperative monitoring results), one for the details of the experimental setting (levodopa equivalent dose administered to the patient, neurophysiologic parameters retrieved to set the aDBS device), one for each clinical assessment including the UPDRSIII and the UDysRS scale, and one for the visualization of patient-generated data. The results of the planned validation testing are reported in Tables 1 and 2 (column 3).

All the expected 128 diary recordings were received by the system. Of them, 105 were filled-in whereas 23 arrived with null values. The major reason was one poor compliant patient who lacked compiling the diary several times. There were no errors in the data transmission. A total of 40 hours of accelerometer data were recorded. The accelerometer data loss was due to a poor connection between the wearable device and the mobile app. Despite this, as shown in Figure 3D, there was a significant correlation (-0.582, p<0.009) between clinical assessments and patient-generated data, thus suggesting that the measures obtained by the wearable device are reliable for assessment purposes, even though data are incomplete.

Conclusion

We designed, implemented, and tested in a real clinical research study a system that allows integrating patient-generated data regarding clinical trial into rEHRs, using a standards based architecture that ensured the fulfillment of the major requirements².

Health information exchange between mHealth Apps (Patient Reported Outcomes, PRO), clinical research studies, and EHR systems is a recent challenge from the technological and regulatory point of view. Many example bi-directional health information exchange between mHealth Apps and EHR systems are available but they all differ from the architecture described in the present work, because they were all developed for the hospital environment and for the use by healthcare professionals^10,11. Other solutions provide the integration between clinical research studies and PRO without EHR support^12,13. Our web based solution provides the integration of all the three elements: PRO, EHR and clinical trials.

Moreover, the presented system architecture could be used in different healthcare domains. For instance, a similar architecture, still in a prototype stage, was developed to support longitudinal studies in nutrigenomics¹⁴, including the management of behavioral and nutritional habits of patients with cardiovascular risk that was guaranteed by the integration of the patient reported meals, his/her EHR, and food dictionary.

It has been proposed that interoperability issues in health IT can be addressed by using web services^15,16. Our architecture, in agreement with this hypothesis, implements specific web services to ensure interoperability among the different systems (WebBioBank, Workflow manager, and mHealth App) and to enable the communication among patients/caregiver, researchers and doctors by using standards such as PHMR template compliant with RIM (CDA2) and dictionaries.

Considering that DBS patients after surgery for electrode implant face a fragile stabilization period, we expected poor compliance and increased risk. For this reason, we decided to make the first assessment of the mHealth App in a controlled hospital environment. However, the system requires, in the next future, a more focused testing procedure with the patients in their home environment to further verify usability and robustness in longitudinal studies.

The loss of data during the evaluation stage was mainly caused by the low available data storage memory in the bracelet, thus requiring a continuous connection with the mobile phone to transfer data and free the memory. This study shows how the capability of a device to collect data autonomously is critical during the daily living of these fragile patients who are not used to keep the mobile phone close to them but tend to wander off outside its range. This capability will be a major requirement for future implementations of the proposed architecture.

The validation showed that the implemented system and architecture were able to provide a reliable solution for including the patient as direct digital data source, ensuring ALCOA requirements for data generated either by the patient him/herself of by personal wearable device.