PROMETRIKA was the first Medidata CRO partner accredited in the Medidata Patient Cloud® platform. As early adopters, we experienced the growing pains of using the Patient Cloud, when we used it as an ePRO solution with Rave. A recent project with a third-party vendor, a leader in the ePRO field, provides a case study for contrasting our experience with the Patient Cloud to that of integrating other ePRO systems with Rave.
The Other ePRO Solution
Forms in other ePRO products are built outside of the Rave EDC; getting the ePRO and EDC pieces to be a cohesive data source requires integration in a secondary process. What are the pain points of integrating other ePRO solutions with Rave?
The standard operating procedures of the third-party vendor stipulated that the ePRO specifications be final before their release to the EDC vendor. By the time the vendor released the specifications after several weeks of internal review, they were ready to go with their build. That left us, the EDC builder, no time to provide feedback regarding the specifications – just time to match our EDC forms to their ePRO forms.
This led to the problem of data format compatibility. Because the third-party’s ePRO specifications were final, the data managers and SDTM programmers could not assess whether the vendor’s data format was SDTM compliant. If the data structure is not sound, making the data come out as needed on the back end requires a lot of extraneous programming.
A second challenge was the integration timeline. The third-party vendor’s timeline for go live did not include integration of ePRO data with the EDC. Technically, data integration does not need to be complete before either the ePRO or the EDC system goes live. However, if your screens go live and, during the integration process, you find an error in mapping or another error, you have to go back and retool the EDC system.
Another challenge with the third-party vendor was the mapping of variable names between the ePRO and EDC systems. Any work with external data requires extensive mapping – a labor-intensive manual process that must be checked by user acceptance testing (UAT) because it is not automated. This could be daunting in terms of resources if the ePRO data has hundreds of data points that must be mapped.
Another challenge with the third-party ePRO solution was that, although the vendor shared the ePRO specifications, they did not share the xml integration specifications for Rave Web Services (RWS). It was difficult to determine how the ePRO data were coming in. In particular, their ePRO solution would create a new patient profile in Rave if one did not already exist. PROMETRIKA’s randomization module also created new patient profiles in Rave. With two systems competing to create new patient profiles, ultimately, the whole system crashed, and a manual process was needed for resolution. Because the ePRO system was external to our EDC group, there wasn’t a lot of custom programming that could be done to control the workflow, whether creating patient records or making sure forms were completed within a timeframe.
Patient Cloud
In contrast to a third-party ePRO system, Patient Cloud forms are built within Rave itself, along with the other eCRFs, and pushed out to the Patient Cloud platform.
Use of the Patient Cloud does not present issues with data format compatibility. When the ePRO forms are designed in Rave along with the eCRF forms, the review cycle includes biostatisticians and SDTM programmers in a continuous process. Because the review is not a secondary process, the biostatisticians and programmers get a comprehensive view of what the final data structure is going to look like.
In the Patient Cloud, issues with the integration timeline are almost a moot point. Because the ePRO forms are developed along with the EDC, one system does not go live without the other. It’s nice to know that you don’t have to be concerned with integration – it is already built into the system.
Using the Patient Cloud for ePRO eliminates the worry about integration mapping because the ePRO forms are built to the same specifications as the eCRF forms and are included in the existing dataset. In saving time and resources, the Patient Cloud product demonstrates a stark contrast with integrating another ePRO system with EDC.
As PROMETRIKA was going through the process of implementing the Patient Cloud, one pain point was that customized workflow had to be dictated by custom function programming. Custom function programming is a niche skill that not all database programmers have, and that is expensive to obtain by outsourcing. But this experience of working with another ePRO vendor, with the customization option simply not available, gave us a newfound appreciation for custom function programming: it is cumbersome, but necessary. It prevents data issues going forward. At PROMETRIKA, having custom function programmers in house allows programming around the workflows.
ePRO Wish List
We have leveraged our experience of integrating an ePRO solution that was not the Patient Cloud to come up with an ePRO vendor wish list.
First, the vendor must utilize an agile software development paradigm. Review of specifications should be iterative and flexible. If changes have to be made, they are made real time, to avoid the costly process of fixing errors later.
The vendor must also have extensive experience with collaborative EDC integration. It’s not so much that vendors don’t have EDC integration expertise, but that they treat data integration as a secondary process. They see it as the EDC vendor’s problem – it is about prioritization more than about expertise. Our experience with data integration shows it is best practice for integration to occur before either the ePRO or EDC system goes live to ensure that the two systems can talk to one another.
The vendor should make xml specifications available for review. Laboratory data vendors do this – why not ePRO vendors? The workflow error we experienced could have been avoided altogether if the xml specifications had been made available. We would have seen the ePRO vendor’s xml code calling for a new subject profile to be created if one did not already exist in Rave.
Ideally the ePRO vendor should have custom programming expertise to adapt the system to every sponsor’s need – from a tiny phase 1 to a large phase 3 trial. The system should be flexible enough to accommodate time and visit windows – even when a form is called up outside the protocol-defined visit windows.
We have learned from experience that it is also very useful if the ePRO vendor has device and instrument (questionnaires administered to patients) services and provides devices and technical support. The importance of instrument services are often overlooked. Instruments must be licensed and validated. Lack of licensure and/or validation can be the downfall of an eventual regulatory submission.
Compatibility is inherent in using a solution from a single-source vendor. Using the Patient Cloud as an ePRO solution with Rave EDC eliminates data incompatibility and allows better control of workflow through custom function programming.