Dealing with mid-study changes (data model)
Whether you’re working on a big pharma clinical trial or a multi-site research study, changes will pop-up while the study is running. I have yet to find someone who enjoys changing electronic case report forms (CRFs), subject numbering schemes, or modifying user permissions in the middle of a study, but change requests will come and how you react to these changes defines the robustness of your design. It’s frustrating, and I’ve found that they are unfortunately a fact of life.
One of my favorite authors, David Allen, writes that how we react to change differentiates us from other people. Those who react quickly can respond efficiently, and then just as quickly move on. I view mid-study changes the same way. Because they will happen (and sometimes frequently!), it’s necessary to design a system that will make this process as painless as possible. For this post, I’ll focus on how a mid-study change to a CRF can be done quickly from the perspective of the data model.
The most common mid-study changes I’ve come across for a CRF are adding/removing items in a dropdown, adding/removing/modifying fields, changing the type of a field, and adding/removing/modifying what some call skip patterns or verification rules. Keep in mind, the data model must support these changes. The most difficult thing to satisfy without proper design is for the old data to be accessible. It’s messy and data conversion could be needed. Providing you’re not using some sort of star schema for your database, adding/removing/modifying columns in an existing database is something I like to avoid. Using a traditional relational database, I don’t see a clear way of avoid this.
One solution (the one I normally use) is to create a data table for the CRF where nothing is ever removed. Columns are permanent. The disadvantage of this approach is storage. For example, if a mid-study change requires removing a column, our approach means we do not remove it. Future records saved in this table would ignore this column which means there’s empty space in the table.
The advantage of this approach is that you never lose data. A permanent record always exists for the CRF and you only need to find ways to manipulate it. While we’re on the topic of manipulating the data, another advantage is all the CRF data is in one place! Yet another advantage is that you can re-use a lot of the older CRF. Normally, mid-study changes don’t require major protocol revisions, so you save time not having to re-code the unchanged portions of the CRF. If you utilize a persistence layer like Hibernate (which you should!), you’ll be able to leverage your existing code and only add methods or properties when needed.
In order to make all this possible, you will need to add an extra column to your data table that represents the revision/version/whatever you want to call it. This will make it possible to correctly display the right “view” on this model.
Although this will be the subject of another post, with the data model in place, we can then focus on how to retrieve and manipulate the data so that it displays properly in a CRF regardless of whether the CRF was saved before or after the mid-study change.
To receive updates on new articles, subscribe to CRF Design today!
