Draft data management#28
Conversation
|
No spelling errors! 🎉 |
|
No broken url errors! 🎉 |
|
Re-rendered previews from the latest commit:
* note not all html features will be properly displayed in the "quick preview" but it will give you a rough idea. Updated at 2026-06-22 with changes from the latest commit d2acfb0 |
|
@carriewright11 this is a draft of chapter 5 (with the updates we discussed in our last meeting). It is mostly complete, but is missing a conclusion and images. I can add these to the pull request but first wanted to make sure that this all looks good, because it is my first contribution to this course or any of the ITCR courses. I can brainstorm where to add images/what images to add but am open to any ideas that you or @kweav have, if you had anything in mind. |
| - Data Cleaning and Processing: Ensuring data consistency, accuracy, and completeness by detecting and rectifying errors, missing values, and inconsistencies. | ||
| - Data Analysis: Using statistical and analytical tools to generate insights from the data that can inform clinical decisions and study outcomes. | ||
| - Data Sharing and Reporting: Providing access to data for collaborators, regulators, or stakeholders in a secure and controlled manner and generating reports that summarize findings. | ||
|
|
There was a problem hiding this comment.
Possible figure showing how these activities relate (e.g., data is collected and then stored. Data may be checked and then shared and then analysis (with more checking) and then more sharing (of reports)) sort of thing
| #### Open source options | ||
|
|
||
| Open-source tools provide a cost-effective and flexible alternative to proprietary software for handling clinical data. These tools are often developed and maintained by vibrant communities and can be customized to fit specific research needs. | ||
|
|
There was a problem hiding this comment.
Possible figure here that open source software doesn't mean data won't be protected (but still have to do work to make sure data is protected)
There was a problem hiding this comment.
May be better later in the section (looks like line 74)
|
|
||
| - **Data Quality**: Refers to the accuracy, completeness, consistency, and reliability of data. High-quality data is essential for producing valid and reliable research outcomes. It involves processes such as data validation, error checking, and quality control measures. | ||
| - **Data Handling**: Encompasses the broader scope of managing the data lifecycle, from collection and storage to processing, analysis, and sharing. While data quality is a component of data handling, the latter also involves aspects like data security, access management, and regulatory compliance. | ||
|
|
There was a problem hiding this comment.
possible figure here showing that data quality is just a part of data handling
| - **Scalability**: The tool should be able to handle the volume of data expected in the study and scale as the study progresses. | ||
| - **User-Friendliness**: A user-friendly interface can reduce the learning curve for researchers and data managers, improving efficiency and reducing errors. | ||
| - **Regulatory Compliance**: The tool should comply with relevant data privacy and security regulations to protect patient data. | ||
| - **Support and Documentation**: Adequate support, including user manuals, tutorials, and customer service, is essential for troubleshooting and maximizing the tool's potential. |
There was a problem hiding this comment.
Add a note about institutional support / access as well possibly? Institutional suppport for REDCap is an example.
| - **User-Friendliness**: A user-friendly interface can reduce the learning curve for researchers and data managers, improving efficiency and reducing errors. | ||
| - **Regulatory Compliance**: The tool should comply with relevant data privacy and security regulations to protect patient data. | ||
| - **Support and Documentation**: Adequate support, including user manuals, tutorials, and customer service, is essential for troubleshooting and maximizing the tool's potential. | ||
|
|
There was a problem hiding this comment.
In line with seeking recommendations which is said at the end of this section, I wonder about adding a point about it being a mainstream/commonly used tool. Like probably don't pick something that isn't commonly used in the field.
|
|
||
| Examples of popular open-source data handling tools include: | ||
|
|
||
| - **REDCap**: A secure, web-based application for building and managing online surveys and databases, widely used in clinical research for data collection and management. |
There was a problem hiding this comment.
Add a note that it has robust capability for data quality checks, can produce basic reports (stats & visualizations), but is not capable of advanced statistical modeling or more sophisticated analyses
|
|
||
| When moving between multiple data handling tools, it is important to consider interoperability. As an example, REDCap and R play very nicely together via API tokens, but this may not be true of all electronic data capture systems or databases. The sharing, integration and redistribution of data between systems - whether internally or externally - needs to be carefully planned, tested and documented. | ||
|
|
||
| ### Testing data handling tools |
There was a problem hiding this comment.
I think for this section we might want to provide a few examples of this. Really communicate that simulating can mean writing a script that uses statistical / probabilistic modeling frameworks to create a dataset and you add some noise (such as removing data or putting in a few errors). And once you've simulated that data, you put it through the rest of the handling pipeline (storing, transferring between tools, running the proposed analysis on it). But it can also mean inputting data (like data collection) where you go through a case report form and answer the questions a few dozen times and then continue with the data handling pipeline.
|
|
||
| - **Creating Realistic Dummy Data**: Dummy data should mimic the real data in terms of format, structure, and complexity. It should include various scenarios (e.g., missing data, outliers, data entry errors) to test the system's error-handling capabilities. | ||
| - **Simulating the Full Data Handling Workflow**: The process should involve every stage of data handling, from data collection and entry to storage, cleaning, analysis, and reporting. This comprehensive simulation helps identify potential issues early, such as data loss, security vulnerabilities, or errors in data processing algorithms. | ||
| - **Refining and Optimizing Data Handling Methods**: Based on the findings from dummy data tests, researchers can refine their data handling protocols, adjust tools and settings, and optimize workflows to ensure smooth operations when real data is introduced. |
There was a problem hiding this comment.
Do we want to mention that they may want to refine their survey instruments / case report forms based on these tests as well? That was a huge focus of the redcap course at Hopkins that every case report form should be tested and often the case report form itself gets refined (e.g., a question is rephrased or moved or marked as required or .,,,, ) not just settings or proposed analysis steps
Co-authored-by: Kate Isaac <41767733+kweav@users.noreply.github.com>
…ical_Data_Management into draft_data_management
…o newer or less common tools
…can do basic repots but not advanced statistical modeling or analyses
| - **Access Control and Encryption**: Tools should support robust access controls, ensuring that only authorized users have access to the data. Encryption should be used for both data at rest and data in transit to prevent unauthorized access. | ||
| - **Compliance and Auditing**: Tools should facilitate compliance with regulatory standards and provide auditing capabilities to track data access and usage. | ||
|
|
||
| When selecting data handling tools, it is crucial to prioritize those that offer comprehensive privacy features to safeguard sensitive information and maintain public trust in clinical research. |
There was a problem hiding this comment.
I think this sentence may fit better before the bulleted list? Feels like the bulleted list needs some sort of transition sentence before it
|
Overall readability score: 51.25 (🔴 -1.23)
View detailed metrics🟢 - Shows an increase in readability
Averages:
View metric targets
|
2 participants
Purpose/implementation Section
Chapter 5: clinical data management
What changes are being implemented in this Pull Request?
This pull request adds a draft of chapter 5: clinical data management.
What was your approach?
I transferred the content for this chapter from the Google Drive, editing and re-ordering as needed to make it fit into the framework of the course.
What GitHub issue does your pull request address?
No current issues.
Tell potential reviewers what kind of feedback you are soliciting.
I would like to get feedback on the overall structure of this chapter, as this is my first addition to this course. I would also appreciate any ideas of where to add images.
New Content Checklist
New content/chapter is in an Rmd file with this kind of format and headers.
New content/chapter contains Learning Objectives and are in the correct format.
Bookdown successfully re-renders and any new content files have been added to the _bookdown.yml.
Spell check runs successfully in Github actions style-n-check).
Any newly necessary packages that are needed have been added to the Dockerfile and image.
Images are in the correct format for rendering.
Every new image has alt text and is in a Google Slide.
Each slide is described in the notes of the slide so learners relying on a screen reader can access the content. See https://lastcallmedia.com/blog/accessible-comics for more guidance on this.
The color palette choices of the slide are contrasted in a way that is friendly to those with color vision deficiencies.
You can check this using Color Oracle.