## 4 Discussion
### Fast Results vs. Thorough Analysis  
There are different approaches to targeting DQA. One important use case is to get a quick insight into a dataset with little programming skills and without using much formal information about data properties and requirements. Packages such as DataExplorer[41] follow this approach, and are a viable option to obtain informative insights. Accessibility is also supported with GUIs, but this may impair reproducible workflows if the selected options or pre-processing steps, such as filtering data, are not recorded. However, one package (ExPanDaR[47]) aims at reconciling a GUI with reproducibility by providing an interactive notebook.  
In this first use case, simplicity usually comes at the expense of having no or few options to explicitly check the requirements on the targeted dataset. Without an explicit definition of permissible values, reference distributions, or expected associations, a package may only use generic algorithms to numerically or graphically describe data properties. The person inspecting the results must then decide whether the finding truly reflects a DQ problem. This way, judgements on DQ findings are informal, based on implicit assumptions, and therefore, they are prone to error [6]. However, a lack of metadata usage may reflect that only limited related information is available in the data dictionaries underlying most observational studies [24].  
A second use case is to obtain a highly focused insight on rule violations in a dataset. However, the additional information required to perform the checks in this approach commonly conflicts with ease of use. For example, while validate[18] and errorlocate[46] allow for calculating many indicators, the user must explicitly write the so-called \"rules\" (equivalent to metadata) to evaluate each indicator for the corresponding variable. Similar packages are testdat[60] and sanityTracker[55]. Moreover, for some packages, the user must understand their particular grammar. An example is pointblank[54]. In this package, the user needs to be familiar with specific conventions to perform the assessments: the indicators are stored in an \"agent\" that needs to be \"interrogated\" to perform the evaluation. Despite the detailed documentation provided with pointblank, understanding the grammar is time-intensive for any user. The main advantages of these packages are the transparency and reproducibility of their assessments, as well as the possibility of extending the range of checks with user-defined requirements. Moreover, these features allow integrating DQA into automated workflows, which is impossible with packages from the first use case. A disadvantage is the low interoperability of check rules, as the syntax may need to be tailored to fit individual package requirements.  
From the previous considerations, it is clear that meaningful metadata in a machine-readable format is a key to comprehensive DQ reports [24]. Therefore, a third use case reconciles ease-of-use with setting up extensive rules. One possibility of achieving this is by separating the metadata setup from formal programming, an approach followed by dataquieR[42] and DQAstats[45; 67]. Both packages can use metadata for DQ in a basic spreadsheet format, which lowers the technical barriers to adding and modifying content. Subsequently, basic code suffices to conduct extensive reports. However, agreeing on common data formats for storing metadata remains an open issue. For this reason, it is advisable to take into account existing standards in the health sciences, such as HL7 FHIR and CDISC-ODM[68], as well as common data dictionary formats, for example REDCap[69].