All EDC systems have some form of rules facility. The rules are typically designed to check data. If the check fails, then typically a query is produced.
Web based EDC systems typically run edit checks when a page is submitted.
Prior to the release of web based systems, it was typical to check the data as soon as it was entered - between fields.
With Web 2.0 technologies, it may prove possible to routinely run checks as soon as data is entered - prior to page submit.
So - a question - which approach is best?
2 comments:
Edit Checks are essential to the ROI over paper. They prevent the countless back and forth between CRAs and Sites later discussing data that makes no sense.
The fact that edit checks can be run in real time is enough IMHO. Let me give you an example of 3 types of edit checks and post some more comments if your views differ, or if any of my info needs an addition.
Phase Forward Inform - They run Edit Checks in real time, as in field by field. In the old days, to do this even in a web based environment - you need some sort of applet or cookie or something installed on the local PC for this to work. Now a days, thru version updates - this is done with AJAX web 2.0 technology and is possible with no applets installed. This method makes sense for immediate real time feedback from edit checks, thus always keeping data as clean as possible.
Medidata RAVE - They run edit checks on Page Submit. Data is entered into an eCRF by tabbing through all the fields, and then after the users click submit or SAVE, the edit checks fire. These include Null, Range, and Future Date Auto checks, as well as any user defined edit checks, cross form queries, etc. Nothing fires until you click SAVE, however - this is still immediate feedback.
Oracle RDC - This application runs their edit checks in BATCH. What this means is a coordinator enters data (say it was a busy catch up day - 20 subjects) and no edit checks will fire in real time. The coordinator can;t sleep because she knows in the morning, she is going to wake up to about 50 queries that appear after the edit checks run in batch overnight. This annoys the coordinator who wishes she could just do her job in one sitting!
Not sure how the Mid tier EDC solutions handle Edit Checks. I believe Etrials runs field by field (AJAX), DATATRAK runs Field by field (with Java Applet installed) and Omnicomm runs on page submit. Someone - please comment on this one.
Field by Field feedback is nice, but onPageSave feedback is also nice to compartmentalize your work. Enter data, then fix errors, then move on. You can also move on and come back to those errors later. Both methods have their strong points.
Thank you for your comprehensive input. I will not disagree with your point regarding a need for immedidate feedback for true ROI in EDC. I must admit to being astonished that Oracle RDC still does not offer support for either field or page submit level data checking.
Even with Web 2.0 / Ajax, field based edit checking remains challenging. Unsubmitted data entered so far on a page needs to be taken into consideration with data in the database across pages and visits. Also, on the cancellation of a page update, all activities triggered during the entry process need to be rolled back. This can be difficult to achieve fully if the activity applies to a page outside the scope of the page being updated. Transaction handling and deadlock situations come into play with multi-user access.
What I have seen done, is a subset of the actual edit checking carried out during entry - the basics - but the bulk of processing awaits the data (page) submission.
For EDC tools based on the principle of the centralization of data, the rules need to be applied regardless of the user interface. Lab, IVR and other forms of data feeds need to have edit checks fire even if import bypass the eCRF UI.
The one remaining discussion point is around dynamic page management. Should questions be asked if former responses would negate the need. With HTML systems, the trend was to split the pages to separate the need. It may make more sense, with Web 2.0 to manage this within a page where this makes sense.
Post a Comment