Reconciliation-Free IRT

One of the questions most frequently asked by clients during demos of the Veracity Logic IRT (IVR/IWR) system is how best to handle the problem of having to reconcile data between a study’s IRT and EDC platforms.

The answer is twofold, but simple: First, move data between the two systems in only one direction. Second, set up your study so you don’t duplicate data in the two systems.

Electronic integration between the IRT and the EDC systems should be a one-way arrow – ideally, data should be ‘pushed’ from the IRT to the EDC. Not only is this cheaper than requiring a two-way transfer of data (i.e., also ‘pulling’ from the EDC into the IRT, which can double costs), but, depending on the EDC platform being used, it may also be technologically simpler, since EDC APIs to receive data may be more available than APIs to push data.

But there are other more important – and more consistent – reasons to push from the IRT to the EDC.

For one thing, IRT data is typically available significantly earlier than EDC data. This is because many IRT processes require real time recording of data in order to get what the site needs to carry out its visit tasks – for example, to randomize a subject to a treatment group and get a kit number for a drug assignment. By contrast, visit data may languish for many days before site personnel are able to enter it into the EDC system. In terms of availability, it makes sense to push data in near-real-time from the IRT into the EDC rather than the reverse.

In order to avoid reconciliation issues, IRT data should be pushed to the EDC on a ‘read only’ basis, i.e., fields in the EDC system containing data from the IRT cannot be edited by clinical site users. Any updates that need to be done to the IRT data – for example, changes to subject demographic data – should be done only in the IRT, with the data then re-pushed to the EDC.

To further avoid the need to reconcile data, study designs should strive to eliminate any duplication of data collection in the two systems. In the ideal setup, things like basic screening and subject identifiers, stratification data, randomization IDs, visit dates and drug assignments are all collected in or generated by the IRT, then pushed over to EDC on a transactional basis so that they are already in that system when the study team goes in to record the rest of the visit data.

It is not recommended that data like inclusion/exclusion or informed consent information be captured in the IRT; rather the result of the site’s inclusion/exclusion assessment should simply determine whether the subject will be screened (in the IRT) at all. The actual inclusion/exclusion and informed consent information will reside only in the EDC.

There has been some recent movement by clinical teams toward trying to capture more information in the IRT than is practically advisable in order to have the data electronically available sooner. Or at least that is the argument posed.

For example, an IRT system could easily be set up to require that certain visit values normally captured in the eCRF be recorded in the IRT in order for a randomization ID to be granted by the system. This would ‘force’ entry of the visit values earlier. The time consuming and costly business of reconciliation between platforms would, however, argue against also capturing that information in the eCRF. Yet not to do so would result in an uncharacteristically fractured eCRF data record for the patient, and the rich editing power of the EDC could, accordingly, be compromised.

To sum up the reasoning, project teams looking to avoid these kinds of conundrums should carefully consider, during study startup, the potential consequences of each data point requested to reside in the IRT.