Data Lifecycle
The corruption of data in the clinical lifecycle
Clinical data is problematic. But too often, we tend to focus on one or two areas as potential sources of error (based on our programming and validation experience, clinical background etc.), but as demonstrated below, every time there is an interface, there is a potential for data corruption. Note that in our example below, a number of additional interfaces have been omitted for brevity, but it should at least demonstrate some of the potential problems with clinical data.
Consider this simple case. A patient comes in to the clinic on Week 7 for their required blood pressure measurement. Beware of the following land mines. (These are taken from actual situations in clinical trials).
If you are interested in learning about more clinical SAS validation tips, then sign up for our quarterly letter, which contains fresh ideas for validating your clinical data and SAS code.

So, can these problems be avoided? Or is clinical data bound to haunt us forever? Fortunately, there is mostly good news. Addressing all the issues above would constitute a volume in itself. However, let us address one technique that is useful as an overall quality assurance check. Essentially, one can estimate some of the problems in data corruption by creating electronic CRFS populated with the patient data and then comparing them against the original CRFs. By taking a good random sample of different types of CRFs (i.e. adverse events, concomitant medications, test article administration) taken at different investigator sites, one can have a rough idea how (and where) data corruption is occurring.
