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!