Dating is hard, especially if you’re not aware of the relevant conventions and etiquette. The same could be said for collecting date information in your EDC. As technologists enamored with data above all, those of us here at OpenClinica probably aren’t your best source for romantic advice. But if you’re searching for the most efficient way to capture unambiguous and properly formatted date information in your eCRF, prepare to swoon. Here are four tips for working with dates.
Tip #1: Allow for full and partial dates.
Requiring a full date when only a certain month or year are known to a CRC or participant is a major hazard for analysis. If that full date field is required, it’s quite possible that the user will select a placeholder for day of the month–the 1st or 15th, say–when that piece of information is unavailable to her. The value in the database, then, implies a level of specificity that wasn’t intended.
To avoid this pitfall, ensure that the individual entering the date indicates which portions are known and which are unknown (“UNK”). Then, offer the corresponding field for input.
During analysis, your statisticians will need to convert entered partial dates into imputed ones, using clear and consistent rules. So it’s important that your EDC support aggregating full and partial dates into a single item.
Tip #2: Offer a user-friendly UI that boosts accuracy.
Suppose that a participant knows that she took a dose of medication on the first Monday of the month. You don’t want her to leave the ePRO form in search of a calendar to retrieve that date. Similarly, for a CRC who prefers point-and-click wherever possible, you want a UI that works with her style, to encourage prompt entry. The same is true for a CRC who prefers to type.
Human factors like these impact both data quality and speed. That’s why they are a major design consideration for OpenClinica, and ought to be for you, as well. The datepicker shown here is the clear and flexible standard we rely on, supporting point-and-click, typed entry, and convenient scrolling through months, years, and even decades. Make sure your mechanism offers the same virtues.
Tip #3: Let your forms do the math.
Exclusion criteria for some trials require no history of a certain condition for a specified amount of time; for example, no history of melanoma for the last five years. In this case, performing the “date math” mentally may not pose a big challenge. But the situation becomes more complex when, rather than being disqualified, a potential participant is assigned to a particular cohort based on the date of some clinical event (or even multiple events). Error-free calculation then becomes as difficult as it is paramount. A capable form engine is your saving grace in these situations. Your EDC ought support real-time calculations, and respond in a protocol-compliant way based on the results. Use your system’s calculation and logic functions to hide or require certain fields, enforce eligibility rules, makes assignments, and otherwise ensure proper workflows.
The example shown here employs skip logic and date math to assign a cohort based on the date that a CT scan confirmed the absence of melanoma. Three years or more of complete response triggers assignment to cohort A, less than three years to cohort B.
Tip #4: Follow the standards.
The final step when working with dates is to format them in accordance with a recognized standard. CDISC is arguably the most recognizable and robust. Following ISO 8601 standards, CDISC takes YYYY-MM-DD as its date format.
Portion of a CDISC ODM XML 1.3 extract from OpenClinica.
