What DUO is for
Repositories and data stewards can annotate data with use permissions or restrictions. Researchers can describe intended use. Systems can then support consistent discovery and preliminary matching across datasets and requests.
Terms and identifiers should be taken from the current ontology release and repository implementation. Local shorthand should not be allowed to silently change the meaning of a code.
Read the permission before the abbreviation
The official DUO repository distinguishes broad research permissions from narrower disease-specific use and additional conditions. GRU is general research use; HMB limits the scope to health, medical or biomedical research; DS requires the specified disease context. These labels help discovery, but an acronym alone is not a complete authorization record. Resolve the identifier against a pinned ontology release and retain any disease annotation and modifiers.
Do not infer that a request is allowed because its label resembles the dataset label. A reviewer still needs the actual research question, the applicable source terms and any narrower committee conditions. A missing disease annotation or ambiguous source clause is an unresolved input, not a permissive default.
Worked example: a disease-scoped dataset request
This is a synthetic review example, not a real participant dataset, committee ruling or output from the planned Audarel product. Dataset EXAMPLE-042 is annotated for disease-specific research. Its confirmed source terms limit use to the named study disease; the requested project proposes an unrelated disease. The reviewer records a purpose mismatch and holds the request for committee review. A later amended request needs its own review; editing a label does not erase the earlier finding.
| Record | Example value | Review consequence |
|---|---|---|
| Source authority | Agreement EXAMPLE-042, version 2, purpose exhibit | Keep the clause citation and reviewer confirmation |
| Ontology | Pinned DUO release and resolved disease-specific permission | Keep the resolved identifier and disease annotation together |
| Requested use | Research on a different disease | Record the mismatch rather than approving on a broad research label |
| Other conditions | Named users, approved environment and retention date | Review separately; a purpose match would not satisfy these conditions |
| Decision | Held for the authorized committee; unresolved purpose scope | Preserve reviewer, time, evidence and any subsequent decision |
A minimum handoff for a data access committee
Give the committee one versioned packet rather than an isolated ontology code: the dataset identifier, governing consent or agreement, source citation, resolved DUO terms and release, disease scope where applicable, proposed project purpose, named users, requested data and the outstanding findings. Separate a preliminary machine match from the committee's final authority to grant access.
Record the reason when a request cannot be evaluated. An absent source agreement, unresolved term or changed project purpose should remain visible in the review history. If the source terms change, re-review affected requests against the new version while retaining the earlier record. This is an operating example; the repository's policy and authorized reviewers determine the real decision.
Evaluate the proposed purpose
Capture the release's proposed DUO codes and compare them with the data-use terms confirmed for the governing agreement. Treat mismatches as explainable findings that identify expected and proposed values. Route the result to the authorized committee or steward.
Combine DUO with Library Cards
Institutional assertions and dataset purpose restrictions answer different review questions. Keep evidence about named users separate from the dataset terms. Audarel is in development; its planned review workflow connects these inputs without treating an institutional assertion as permission to override a dataset restriction.
Keep the human decision visible
Ontology matching can reduce administrative work, but context and exceptions still require governance judgment. Record the reviewer or committee, comments, quorum, time, agreement version, proposed codes, and final release decision.
Keep decisions human and evidence explicit.
Practical guidance that connects policy documents to observable release controls.
Confirm requirements against current source material.
Requirements and vendor capabilities change. Confirm the current source and your approved QC plan before changing a production process.