Benefits of form versioning
Picture a fully developed CRF. The form layout is pristine, the validation rules are working exactly the way you want them to, and the field data maps directly to your database tables.
What more can you ask for?
Unfortunately, forms hardly ever stay the same throughout the course of a clinical trial or a research study. Forms frequently need to adapt to new data points that were unforeseen during the protocol definition phase. So how can we handle this?
We could go ahead and naively make the new changes, but what happens if the change asks for a field to be deleted? Even if we just hide the field and keep the previous underlying data, how can we display the data that was captured now that the field is missing from the form?
One solution for this is form versioning. The ability to load alternate versions of a form is a frequently overlooked feature when designing a system to handle CRFs for a clinical trial, forms for a research study, or generally any forms that tend to change.
Form versioning allows us to:
- Retrieve and display data even if the field is no longer part of the current version of the form.
- A dropdown list’s items can be added, removed, or changed and we’ll always be able to retrieve exactly what items were present before changes were made.
- Keep the validation rules (edit checks) specific to a specific version of the form.
- Tell customers that mid-study changes are a breeze because the form versioning technology keeps mid-study changes isolated from existing data.
Next time you’re designing a system that stores CRFs or basically stores form data, it may pay to integrate form versioning into your system. It definitely saved me a lot of time. Although I can’t say mid-study changes are my favorite thing in the world, I can say that form versioning makes mid-study changes a whole lot easier.
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Dealing with mid-study changes (data model)
- OpenClinica takes open-source community by storm
- Quick and dirty “dirty checking” for Windows form, C#
- Portrait vs Landscape, CRF Design for a Tablet PC
- Using TZEdit on Windows SP, SP2, SP3 for Daylight Saving Time (DST)
Portrait vs Landscape, CRF Design for a Tablet PC
HP Tablet PC (convertible)
How do you systematically make use of the varied Tablet PC screen resolution dimensions using C#?
Designing a CRF specifically for a Tablet PC can be a challenging experience, but it can also be one of the most rewarding.
The Tablet PC is very similar to a traditional desktop computer or a laptop. As I write this entry, most Tablet PCs are running some variant of Windows. Whether it’s Windows XP Tablet PC Edition or Vista (which has built-in support for Tablet PC specific functionality), you’re basically dealing with a Windows machine and you can pretty much treat it as such… almost.
Maybe it’s not so much the variety. One of my biggest obstacles was that the dimensions change. They don’t change just once in a while (like when the resolution changes when you connect your laptop to a TV), they can change many times during a single session!
For example, convertible Tablet PCs (like the one in the image above) provide the ability to change from portrait to landscape and back again all in seconds. In addition, most Tablet PCs come in screen dimensions that are either wider or taller depending on whether it’s in slate mode or the more traditional notebook mode. Taking advantage of a taller or wider screen is going to be the topic of a future post, but let’s say you have a layout for making use of the added height or width, how do you know when to use which?
The first step is determining whether the screen dimensions are in portrait (slate) mode or landscape (notebook) mode. Here are two straight-forward methods for determining which mode the Tablet PC is using:
public bool IsPortrait()
{
return Screen.PrimaryScreen.Bounds.Height >
Screen.PrimaryScreen.Bounds.Width;
}
public bool IsLandscape()
{
return !this.IsPortrait();
}
We can setup a thread that calls one of these methods at specified intervals (polling solution), or we can leverage the .NET event architecture so that our application responds to dimension changes. Leveraging the event architecture is intuitively more efficient and more reliable, so add this to your Form_Load() method:
Microsoft.Win32.SystemEvents.DisplaySettingsChanged +=
new EventHandler(SystemEvents_DisplaySettingsChanged);
Now, define the event handler:
void SystemEvents_DisplaySettingsChanged(
object sender, EventArgs e)
{
if (ScreenProperties.IsPortrait())
// do portrait handling
else
// do landscape handling
}
And just like that, your form is now responding to screen resolution dimension changes!
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- 5 Common Mistakes for Tablet PC Development
- Quick and dirty “dirty checking” for Windows form, C#
- Benefits of form versioning
- Future of notebooks, Dell Latitude XT Tablet PC
- Why does an abstract class need to implement interface methods?
Quick and dirty “dirty checking” for Windows form, C#
While designing a CRF, little short-cuts can save you lots and lots of time. This time-saver is straight-forward code-wise and should fit right into your C# code without much modification.
During CRF design time, I often have CRFs that have dozens and dozens of input controls (radio buttons, dropdowns, listboxes, textboxes…). I’d like to add OnChange handlers to all of these input controls so that I know when a change has been made. Basically, what it comes down to is I want to know when the form is dirty, but I don’t want to add all the handlers by hand. Fortunately, I didn’t have to and neither do you!
The code below is a recursive function which traverses the Control tree. Whenever it locates a control that can be classified as an input control, it attaches an event handler.
void AddOnChangeHandlerToInputControls(Control ctrl)
{
foreach (Control subctrl in ctrl.Controls)
{
if (subctrl is TextBox)
((TextBox)subctrl).TextChanged +=
new EventHandler(InputControls_OnChange);
else if(subctrl is CheckBox)
((CheckBox)subctrl).CheckedChanged +=
new EventHandler(InputControls_OnChange);
else if(subctrl is RadioButton)
((RadioButton)subctrl).CheckedChanged +=
new EventHandler(InputControls_OnChange);
else if(subctrl is ListBox)
((ListBox)subctrl).SelectedIndexChanged +=
new EventHandler(InputControls_OnChange);
else if(subctrl is ComboBox)
((ComboBox)subctrl).SelectedIndexChanged +=
new EventHandler(InputControls_OnChange);
else
{
if (subctrl.Controls.Count > 0)
this.AddOnChangeHandlerToInputControls(subctrl);
}
}
}
Keep in mind the recursion is necessary, because the Controls property field only lists a control’s immediate children. Those immediate children may have children of their own. That’s right… exactly like a family tree! The use of recursion creates an elegant way to traverse the control’s control tree.
I’ve only picked up on the simplest input controls. It should be straight-forward to extend this for other controls like a DateTimePicker or a CheckedListBox (although the CheckedListBox is a little tricky because it uses a different type of event handler).
void InputControls_OnChange(object sender, ItemCheckEventArgs e)
{
// Do something to indicate the form is dirty like:
// this.formIsDirty = true;
}
All the event handler does is set a flag which indicates the form is dirty. How you process the dirty flag is up to you, and there you have it! Hopefully, you’ve saved a few hours of manually adding event handlers!
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Portrait vs Landscape, CRF Design for a Tablet PC
- Benefits of form versioning
- Remap keys, map caps lock to control button
- Top 10 differences between Java and C#
- Dealing with mid-study changes (data model)
OpenClinica takes open-source community by storm
Over 100 clinical research institutions adopted OpenClinica, an open-source EDC platform?
At first glance, OpenClinica looks likes a very polished product. Based on the demo application, the web pages are snappy, and the user-interface seems pretty clean and friendly. Of course it was a demo study, so it’s not clear how the application will fair under the heavy load of a phase III or phase IV clinical trial. This definitely seems like something worth investigating, and I’ll be giving it a much closer look very soon.
OpenClinica is a web-based EDC (electronic data capture) vendor. EDC usually refers to electronic data capture solutions for clinical trials. What makes OpenClinica unique is it’s open source! Back in April 2007, the OpenClinica community had 1,300 members. In April 2008, it had over 3,500!
On March 9th, 2005, Akaza Research released OpenClinica Beta Software and Portal. Akaza Research is a Massachusetts-based biomedical informatics firm. A little over 9 months later, on December 23, 2005, Akaza released OpenClinica 1.0. On November 15, 2006, OpenClinica 2.0 was released. Now, OpenClinica 2.5 is in beta and appears to be nearing release.
Their website indicates their features include protocol configuration, CRF design, data extraction, clinical data management, and support for HIPAA, 21 CRF Part 11 and GCP (all significant regulatory guidelines/requirements).
Enough with the feature list, let’s hear about the technology! It seems they are about as open-source as it comes. Developed using the J2EE framework, uses PostreSQL 8.x (among many other databases supported), and it runs on Linux (as well Windows Server). Although it was developed to run on Apache Tomcat 5.x, they say any Servlet/JSP container that implements the Servlet 2.x and JavaServer Pages 2.x specifications will do.
Definitely worth a look!
To receive updates on new articles, subscribe to CRF Design today!
Similar Posts:
- Benefits of form versioning
- Dealing with mid-study changes (data model)
- 5 Common Mistakes for Tablet PC Development
- PHR Showdown!
- Free iPHR Market Report from Chilmark
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!