Written and maintained by CASRAI Editorial Board
Last updated
A data quality framework gives you a fixed set of dimensions to check a dataset against, instead of a vague sense that the data “looks fine.” Most data quality frameworks were built for enterprise master data — customer records, product catalogues, transaction logs — where the questions are things like “does this address match the postal database.” Research data raises a related but different set of questions: does this value fall inside a physically plausible range, does every row have the identifiers a downstream analysis needs, does the same subject ID mean the same subject across every file in the dataset. This guide adapts the standard data-quality-dimension framework to that context, and draws the line between data quality and two things it’s routinely confused with: the FAIR Data Principles and repository certification.
Data quality is not the same question as FAIR
FAIR asks whether a dataset can be found and reused — whether it has a persistent identifier, machine-readable metadata, a documented license, an accessible format. Data quality asks whether the values inside the dataset are correct. The two are independent: a dataset can be perfectly FAIR — DOI assigned, rich metadata, open license, deposited in a certified repository — and still contain systematically wrong measurements, duplicate rows, or a codebook that no longer matches the column headers. Conversely, a dataset can be scientifically excellent and still fail FAIR because nobody assigned it an identifier or wrote down what the columns mean. CASRAI’s own research data lifecycle guide treats these as different stages doing different jobs; this guide is about the quality-checking work that FAIR does not itself perform.
Where the framework comes from
The specific dimensions below are not a CASRAI invention. They’re the standard set used across data management practice generally, most formally systematized in DAMA International’s Data Management Body of Knowledge (DMBOK), and in the ISO 8000 family of standards. It’s worth being precise about what ISO 8000 actually is: it’s the international standard for data quality and master data, developed by ISO technical committee TC 184/SC 4 (Industrial data), and its primary use case is exchanging standardized master data — product, material, and counterparty records — between business partners in supply chains, not research datasets. Parts of it (ISO 8000-61, a process reference model for data quality management; ISO 8000-150, roles and responsibilities in data quality management) describe a general management process that transfers reasonably well to a research data context, but nothing in ISO 8000 is written with a research dataset, an instrument reading, or a survey response in mind. Treat it as the closest formal standards-body reference point for the general discipline of data quality management, not as a research-data-specific specification the way the FAIR Principles or the Dublin Core metadata elements are.
The core dimensions, applied to research data
The following six dimensions recur across almost every version of the data-quality-dimension framework in the literature. Each is defined generically first, then translated into what it actually means when the object being checked is a research dataset rather than a customer record.
Accuracy
Does the recorded value reflect the real-world thing it claims to measure? For research data this usually means: is the value inside a physically or biologically plausible range (a body temperature of 45°C, a negative age, a p-value of 1.3), and does it match what an independent measurement or a calibration standard would produce. Accuracy failures in research data are often instrument-drift or transcription errors rather than the address-typo errors a business data-quality check is built to catch.
Completeness
Are all the values a downstream analysis needs actually present, and is missingness itself recorded rather than left ambiguous? A blank cell in a spreadsheet can mean “not collected,” “not applicable,” “collected but lost,” or “refused to answer” — a completeness check for research data has to distinguish these, typically with explicit missing-data codes, not just count blanks.
Consistency
Does the same fact mean the same thing everywhere it appears? The classic research-data consistency failure is an identifier that doesn’t stay stable: the same participant recorded as P-014 in the enrollment file and Participant_14 in the follow-up file, which silently breaks any join between the two without an obvious error message.
Validity
Does the value conform to the format, type, and allowed-value constraints defined for that field — a date that’s actually a date, a categorical variable that only takes values from its defined codebook, a unit that matches what the column header says it is (mmol/L, not mg/dL, in a field labeled mmol/L). Validity is a narrower, mechanical check than accuracy: a value can be valid (a well-formed date) and still be inaccurate (the wrong date).
Timeliness
Is the data current enough, and was it captured close enough to the event it describes, to still be fit for the use it’s being put to? For longitudinal or environmental research data this also covers whether a dataset’s stated collection window is accurate — a mismatch here undermines any analysis that depends on temporal ordering.
Uniqueness
Does each real-world entity appear exactly once, unless the design intends repeated measures? Duplicate participant records, double-counted specimens, or the same instrument reading logged twice after a system retry are the research-data version of the duplicate-customer-record problem enterprise data quality tools were built to catch.
Data quality and repository certification are also different checks
Depositing in a CoreTrustSeal-certified repository is sometimes treated as a proxy for “the data is good.” It isn’t, and CoreTrustSeal doesn’t claim to be: its sixteen requirements assess organizational infrastructure, digital object management, and technology — whether the repository has a sustainability plan, documented preservation actions, and appropriate technical infrastructure — not whether the scientific values inside any particular deposited dataset are accurate. A certified repository is a trustworthy place to keep a dataset; it says nothing about whether that dataset passed the six checks above before it arrived. Quality checking is deliberately upstream of deposit, generally the responsibility of the person carrying out data curation or acting as data steward for the project, not something a repository verifies on intake.
Applying the framework across the data lifecycle
Quality checks are cheapest early and most expensive late — catching a unit-conversion error at data entry costs a corrected keystroke; catching it after publication costs a correction notice. CASRAI’s research data lifecycle guide breaks data management into stages; the practical version of this framework attaches specific checks to specific stages:
- At collection — validity and accuracy checks close to the source: range limits on instrument software, controlled-vocabulary fields in survey tools, calibration logs kept alongside raw output.
- During processing — consistency and uniqueness checks, typically scripted rather than manual: identifier-matching across files, duplicate-detection, cross-field logic checks (a discharge date recorded before an admission date).
- Before deposit or sharing — completeness and timeliness checks against what the Data Management Plan and any funder or journal data policy actually requires: are the missing-data codes documented, does the codebook match the current column headers, is the stated collection window correct.
Running the same six-dimension check at each stage, rather than only once before publication, is what keeps a quality problem from compounding through every downstream analysis that uses the data before anyone notices.
A worked example
Illustrative composite, not a real study or institution. A multi-site clinical dataset combines lab values from three sites. A quality pass finds: one site recording glucose in mg/dL while the shared codebook specifies mmol/L (a validity failure — wrong unit for the declared field, not a wrong value); 40 participant records with a blank “sex” field with no missing-data code distinguishing “not collected” from “declined to answer” (a completeness failure); and 12 participant IDs appearing in both the enrollment and lab files under two different formatting conventions, silently breaking the join (a consistency failure). None of these would be caught by checking the dataset’s FAIR compliance or confirming the repository holding it is CoreTrustSeal-certified — both of those checks can pass cleanly on a dataset with all three problems still in it.
Frequently asked questions
Is a data quality framework the same as the FAIR Principles?
No. FAIR governs findability, accessibility, interoperability, and reusability — largely questions about metadata, identifiers, licensing, and format. A data quality framework governs whether the values inside the dataset are accurate, complete, consistent, valid, timely, and non-duplicated. A dataset can satisfy one framework and fail the other.
Who is responsible for data quality on a research project?
In practice this is usually part of the data steward or data curator role rather than the principal investigator directly, though on smaller projects one person may hold both functions. See CASRAI’s research data governance guide for how accountability is typically structured.
Does ISO 8000 apply to research data specifically?
Not directly. ISO 8000 is the international data quality and master data standard, developed for exchanging standardized business/supply-chain data between organizations. Its general data-quality-management process (ISO 8000-61) is a reasonable structural reference, but no part of it is written for research datasets the way the FAIR Principles or Dublin Core are.
Does depositing in a certified repository guarantee data quality?
No. Repository certification (CoreTrustSeal and similar schemes) assesses the repository’s own organizational and technical trustworthiness as a place to preserve data — not whether the specific values in any dataset it holds are accurate. Quality checking happens upstream of deposit.
For the broader picture of how quality checking fits alongside planning, metadata, and governance, see CASRAI’s research data management pillar.
