What makes database design “smart”?
What makes a database design “smart”, and when should a sponsor begin thinking about data collection and analysis? To learn more, we spoke with PharPoint Research programmer Michelle M.
Balancing the goals of data capture and data analysis
When it comes to smart database design, achieving the perfect balance between data capture and data analysis can be tough.
The goal of data collection is to provide complete, high-quality data. Here, we want to consider how database design can ease some of the burden of data entry and monitoring. This can be done by being flexible while also reducing entry errors, allowing for easier entry through intuitive design, and by increasing collection efficiency.
The goal for data analysis is to receive complete high-quality data that is most conducive to the review process. This is best done by maintaining the ability to link data together, by ensuring data quality and consistency, by handling missing or questionable data, and by conforming output to expected standards.
The challenge we face in database design is meeting the needs of both the database end users and the data consumers.
Utilizing an intelligent approach to CDASH
Designing the database to meet data collection needs up front while reducing the efforts to meet SDTM compliance downstream can be achieved with proper planning and use of CDASH.
However, there are potential issues, even when following the CDASH model, that must be addressed during database design.
“By taking an intelligent approach to CDASH,” PharPoint Principal Database Programmer Michelle Morcos explains, “you can not only make data entry more efficient, but you can also reduce the number of custom edit checks and manual reviews.”
“This is done by building the database to allow for things like enforcement of numeric precision, correct units of measurement, range checks, and more.”
Keeping SDTM compliance and data analysis in mind
Smart database design begins with SDTM compliance and data analysis in mind. This should be considered during form design, but it’s never too early to begin thinking about it. Ideally, this would start at protocol development where the CDISC Protocol Representation Model (PRM) could be utilized.
For instance, why not use CDISC controlled terminology right from the start, eliminating the need to map the data on the backend?
Beginning with the end in mind is a great way to work when feasible. However, SDTM can still be implemented after all data is collected as part of the submission preparation process. So while it’s best to start early, it’s never too late.
