One of the functional areas that I have been surprised at the lack of good support for is CTMS features built out of EDC products.
CTMS systems often perform a variety of tasks – Portfolio Management, Site Management, Trial Planning, Monitor Reporting, Study Progress Tracking, the list goes on for a while…
One of the difficulties with using separate EDC and CTMS systems was often the need to either synchronize or interchange the metadata relevant to both systems. Both systems need to be aware of the visit structure, and, potential workflow associated with more complicated visit structures. For example, it might be the case that a study has multiple arms, and, one or more trigger points that determine the branching. In order to predict the CRF’s to be completed from a trial planning perspective the CTMS either needs to recreate the structure – including an appreciation of the trigger points, or, it needs to import the structure from the CTMS. This is all a bit messy.
So, why do EDC vendors not do a better job of leveraging the data and metadata in an EDC database in order to drive at least a % of the needs of a CTMS?
I am open to better ideas here, but to get this started :-
EDC systems try to generalize the definition of studies. Often things like Visit Dates, Visit Numbers, Branching points and subject statuses etc. are all purely data based – often simply fields on a CRF. They have no special meaning that differentiates them from other CRF fields. Vendors could tackle this by offering a form of user definable flags. On the metadata, a spare attribute would be provided that in turn points to an internal metadata codelist. The codelist could be populated by trigger values such as ‘Visit Date’ or ‘Visit Number’ etc. When interfacing, the CTMS system just need to be aware of the special nature of flags, and use them to pick up the one or more fields that are associated with the flags. So, even though 10 different fields are used to hold Visit Dates, provided the ‘Visit Date’ flag is attached, the CTMS knows the find them. Being data based, no special programming required from study to study.
A second issue is the lack of CTMS information defined on an eCRF. EDC systems are generally only geared to capture data through the eCRF medium. When a sponsor approaches either a CRO or Vendor, often, the contents of a CRF page is gospel. The thought of bolting on the capturing of additional fields is considered inappropriate – eek! it could be mistaken for clinical data! – for example – and I have seen it done – a standard could be developed that ensures that for every subject visit, an end of visit form is filled out. The end of visit form would not capture clinical data. It would be used to capture (or derive) study progress information. Visit Date, End of Visit Subject Status and other such information could be captured a validated in one place. With this kind of information, it is somewhat less difficult to either report on status and progress using native EDC reporting tools, or, feed the standard information across to a CTMS.
The third reason I believe for EDC systems not effectively supporting CTMS needs is the whole lack of planning features – yes, when building a deploying a study it is possible to enter no. of expected subjects at a site level – all EDC systems include this, and, in my experience all EDC system rarely use it – but that doesn’t give you the timeline planning – based on a specific recruitment interval, when will I reach my target subject recruitment…. when will the recruited subjects complete LPLV… etc.
So – could EDC systems better leverage the information they have to offer basic CTMS functionality – absolutely. Should they do more – Yes.
The recent Clinpage article vendors offering multiple integrated solutions suggest that the existence of a fully integrated solution will prove to be a key decision influencer over and above the actual feature functionality of individual systems. There is something to be said for that, but (and this is a big but), the systems must be sufficiently well integrated, robust and flexible to actually work in real life. I would venture that many of the purportedly fully integrated product suites are in fact separate products loosely coupled with single-sign-on and a similar UI. I have known (and I will not mention any names) of products that were sold under the same branding, used the same UI, could be accessed through a portal using Single-Sign-on, but that did not share a single application table once utilized – data, and metadata went into entirely separate tables – seamless, yes – a chasm!
With a strong CTMS feature inside an EDC product – does a future exist for standalone CTMS tools – I personally think not. Although more highly functional, their data entry requirements versus the EDC tools that leverage existing metadata and admin data offers a less convincing value proposition. Then again, how many good EDC vendors know how to create a good CTMS?