First there was Electronic Data Capture, “EDC.” This was the initial step of storing data from clinical trials electronically, focused on patient CRF data. EDC rapidly became more than EDC, as integrated edit checks replaced the need for a separate data management cleaning step. Clinical Trial Management Systems (CTMS) focused more on the business aspects of a clinical trial, including site management, inventory control, and financial tracking.
The separation of EDC from key CTMS functions missed the opportunity to integrate the patient information into the CTMS. For example, site and study-level inventories could be automatically adjusted and invoices generated based on the patient EDC visit information. In addition, many software systems had a set of disparate “modules” that were not well integrated for functions such as randomization (often through IVRS), lab data collection, document management, notifications, query generation and reconciliation, and even adverse event management. Integration between these was often cumbersome at best.
Savvy EDC developers quickly realized that a single, “eClinical” approach to data collection and trial management, where the modules were designed as part of the same software system, yielded the most synergy between the data. Site management could reflect the real-time entry of patient data; randomization could be just another edit check calculation; IVRS could be more elegantly implemented as IWRS. This was a challenge to legacy software systems, where different modules were designed and implemented by different organizations, using different architectures and software languages. Creating interfaces between modules led to cumbersome user interfaces, non-intuitive navigation, and inflexible work-flow that might not represent the real-world work flow of the organization conducting the trial.
EDC companies that designed their software to encompass patient, site, user, and study level information from inception had a much easier foray into eClinical. However, while electronic patient CRFs were, by necessity, designed with the flexibility to configure the data for each study, the other components were and still are typically fixed and non-configurable. Sponsors and CROs using these systems have to modify their operations to fit the work flow inherent in the eClinical software tool.
A more flexible, configurable, and novel approach, beyond most current eClinical applications, is to view the site, user and study-level data collection in the same way as patient data collection. Configurable site forms with edit checks can reflect the sponsor or CRO method of collecting data for sites, while having all the patient data available. Invoices can be tailored not only to the sponsor’s typical pricing paradigm, but modified for each study. Inventory/Accountability forms can be configured for patients (dispensing and return) and sites (shipped to and returned from), with a study-level form showing the rollup. Viewed in the same way as patient forms, these other components can be configured to grant and limit access by role.
In addition to configurable site and study forms, eClinical systems can use the information in a much more dynamic way. For example, site and study information can be used to populate patient drop-downs so that these do not need to be hard-coded, but rather under the control of the managers of the study. Standard events, documents, and other data items can be entered at the site or study level, and used to populate a list of items on a patient CRF. Cross-form edit checks can relate to patient, site, study, and user forms.
There’s no limit to the flexibility, configurability, or interrelationship of these eClinical implementations when viewed more abstractly. Just as some studies have many more unique and complex patient CRFs than others, studies could have more CTMS-like functionality than others, as appropriate to the study. Studies requiring document management could have components in the patient CRFs (e.g., for uploading source docs, CT scans), site forms (e.g., uploading their regulatory documents), and study-level forms as binders to complete the trial master file. Study forms can even define the standard patient, site, and user documents to be uploaded, which are then used to populate the individual patient, site, and user document forms.
Prelude Dynamics has made this leap with their visionary, Vision software system. Much more than EDC, Vision takes eClinical to the next logical step, with completely configurable and cohesive site, user and study management.
As we used to say in my DoD days, sky’s the limit.
