Didn’t we say that you can use the same Edit Checks for both data collection from paper CRFs and for Electronic Data Collection (EDC) ? Eh yes, technically speaking, you can use the same Edit Checks. However, there are certain areas which require a different approach in Edit Check specifications.
The basic difference being that in a paper based study, all Edit Checks will (usually) be triggered within the walls of the Data Management center. So, ideally they are being handled by experienced and trained people. And even if they have a problem, there is always a collaegue around the corner who can help. So as long the Queries which are raised as a result of Edit Checks are clear, you are fine. And perhaps just as important, Edit Checks are being handled by people who’s sole task it is to handle study data (in whatever format or role)
Which is a different story than in an Electronic Data Capture study where Edit Checks are being triggered at sometimes far and remote sites, and handled by people with different levels of computer and study knowledge, and with no help around the corner. And compared to the example above, site personnel often have other things to do than do handle clinical study data. Unless of course, this is handled by a dedicated study nurse.
So a first question you need to ask yourself is: “Do we want to fire all Edit Checks directly at Data Entry at the site?”. Phrased this way, the answer is probably ‘No’. So then the next question is, when and where and by whom do we want to trigger which Edit Check ?
- The question regarding when needs to be answered in terms of things like Field exit or Plate Exit and also in terms of at which validation level.
- The where question relates to the specific item or plate at which to attach the Edit Check.
- Whom relates to the person, or more specifically the user role which should/should not trigger a query
Where questions like these might be more trivial in a paper Form based study, they gain a lot of importance in an EDC study. I have explained in an earlier blog that we use a phased approach at Thorin towards Querying illegal data values. So we have separate Edit Checks to query for a missing value, an illegal value or an inconsistency between two different variables. This distinction is also very helpful in deciding which Edit Check to trigger and when.
There can hardly be any argument that, in an EDC study, the best moment to trigger an Edit Check regarding a missing value or a variable being illegal is when the person doing the first data Entry is leaving the field. So we are talking a Field_Exit Edit Check, linked to that variable, which is triggered from first level Data Entry onwards. In a paper form study, people doing first level data entry are probably not that happy with Edit Checks popping up every time an item is missing or illegal. So if you have a hybrid study, combining paper Forms with EDC, you will need to build in something into your Edit Checks, which takes the role into account. Luckily, there is function available in the Edit Check programming language to help you with this. So you probably want to include something like:
if ( dfrole() !="SITE" && dflevel() <= 2 ) return;
This example of a missing or illegal item is one end of the spectrum, then there is the other of the line, which are Edit Checks involving multiple items from multiple Plates. Let’s take an example of a check that “Date of Signature on End of Study Form should be within 7 days of the last available visit.”. First of all, you need to post yourself the question whether you want to pose this question directly during first level Data Entry. Chances are slim that the investigator will be able to solve this right away (unless it is a clear typo). So either you add Queries like these later on the workflow, or at least you should include Wayne’s idea of including a line like: “there is a problem, do you want to fix it now or later ?”.
And then another thing you need to consider is the timing of Events. In the above example, it will be clear that the Edit Check only makes sense when it is triggered from the End of Study page. But how confident are you about the order in which the site will perform Data Entry. Can it be that they first enter data from End of Study, and then later on they supply data for earlier visits. If scenario’s like this don’t sound like nonsense, you have to seriously consider if you want to have to have an Edit Checks triggered on EOS from level 1 onwards. As it might trigger a non-relevant Query.
And let’s take another example, a simple within-a-plate Edit Check verifying that Date of Vital Signs should be the same as Date of Visit (both are on the same plate). It goes without saying, that this Edit Check should be triggered from Field Exit of the last Field involved, which is Date of Vital Signs. But do you leave the cursor at Date of Vital Signs or do you want the cursor to jump back, by using dfmoveto() to the first Field involved (Date of Visit) ? Personally I feel that jumping back to the first Field involved makes the most sense. Main thing is that you have consequent behavior, whatever you do, do it everywhere.
As a last word of advice, put as much of functionality like this into functions (or #include statements). The major advantage of such an approach is that whenever you want to update your policy in any of the above issues, you only need to update the function itself and not 100+ different Edit Checks.
