By Eric Andrew Kristof, RN, CAHIMS | Healthcare IT Professional | HIMSS Arkansas Chapter Member
About This Series: The HIMSS Word of the Day is a running blog series drawing from the HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025) — the authoritative reference for healthcare IT professionals and the primary study resource for CAHIMS and CPHIMS certification. Each post paraphrases the term in plain language, grounds it in real-world healthcare IT context, and adds a bedside nursing perspective you won’t find in a textbook.
📖 The Term: Data Use Agreement (DUA)
Source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025)
🔍 Plain-Language Definition
A data use agreement (DUA) is a written contract between a HIPAA covered entity and the person or organization receiving a limited data set. The HIMSS Dictionary describes it as a confidentiality agreement covering health information in a limited data set. In practice, the agreement sets the ground rules for what the recipient may do with the data and what it must never do.
A limited data set is protected health information with the most direct identifiers removed, such as names, street addresses, telephone numbers, email addresses, and medical record numbers. Some detail remains, including dates and geography at the town or city, state, and ZIP code level. That residual detail is why the data are still regulated and why a contract is required before they leave the covered entity.
| Concept | What It Is | Key Point |
|---|---|---|
| Data Use Agreement (DUA) | Contract for sharing a limited data set | Required by the Privacy Rule |
| Limited Data Set | PHI minus listed direct identifiers | Still PHI; allowed only for research, public health, or health care operations |
| De-identified Data | Data meeting the Privacy Rule’s de-identification standard | No longer PHI; no DUA required by HIPAA |
| Business Associate Agreement (BAA) | Contract with a vendor that handles PHI for the covered entity | Different purpose and different required terms |
| Authorization | Individual’s signed permission to use or disclose PHI | Used when no other permission applies |
⚠️ Exam Alert: A DUA is required for a limited data set, not for fully de-identified data and not for a business associate relationship. A limited data set may be used only for research, public health, or health care operations. Do not confuse a DUA with a BAA, which governs a vendor performing services for the covered entity.
🌐 Why It Matters: Real-World Healthcare IT Context
Health data are valuable far beyond the visit that created them. Researchers study outcomes, public health agencies track disease, and quality teams compare performance across facilities. Many of those uses do not need names or account numbers, but they do need dates and locations to be useful. The limited data set is HIPAA’s middle path between identifiable records and fully de-identified data, and the DUA is the safeguard that makes the middle path acceptable.
The rule sits in the Privacy Rule’s de-identification provisions at 45 CFR 164.514(e). A covered entity may use or disclose a limited data set only for research, public health, or health care operations, and only if it obtains satisfactory assurance in the form of a data use agreement. The agreement must establish the permitted uses and disclosures of the data, which must be consistent with those purposes, and it may not authorize the recipient to use or disclose the data in a way the covered entity could not.
The regulation also lists what the agreement must say. It must identify who may use or receive the data, and it must require the recipient to avoid using or further disclosing the data other than as the agreement permits or the law requires. The recipient must use appropriate safeguards to prevent other uses, report to the covered entity any use or disclosure not provided for in the agreement, and make sure that agents and subcontractors who receive the data agree to the same restrictions. The recipient also must not identify the information or contact the individuals.
Responsibility does not end at signing. If a covered entity knows of a pattern of activity or practice by the recipient that amounts to a material breach of the agreement, it must take reasonable steps to cure the breach or end the violation and, if that fails, stop disclosing data to the recipient. A DUA is therefore a living obligation, not a filing-cabinet formality.
Several practical distinctions matter. A DUA is different from a business associate agreement: a business associate performs a function for the covered entity, such as billing or cloud hosting, while a DUA recipient is receiving data for its own research, public health, or operations purpose. A DUA is also different from an authorization, which is permission from the individual. And a limited data set is different from de-identified data, which has met a stricter standard and falls outside the Privacy Rule. Covered entities should also apply the minimum necessary standard when deciding how much data to include in a limited data set.
Informatics teams are often the ones who build the extract. That makes the DUA a technical document as much as a legal one. Analysts need to know which fields the agreement allows, how the file will be transferred, where it may be stored, who may open it, how long it may be kept, and what happens when the project ends. Re-identification, even by accident through linkage with another dataset, is a breach of the agreement and a real privacy risk, which is why guidance on de-identification methods, including NIST’s work on de-identifying government datasets, is worth reading alongside the HIPAA text.
Common DUA problems:
- Treating a DUA as unnecessary because the file has no names
- Sending more fields than the agreement lists
- No record of who at the recipient has access to the file
- Data kept after the project ends because the agreement had no return or destruction term
- Linking the dataset to other data in a way that could re-identify people
- Confusing a DUA with a BAA, so the wrong contract is signed
What supports sound DUA practice:
- A single privacy office intake for every external data request
- A field-level data dictionary attached to the agreement
- Secure transfer and storage requirements written into the contract
- A defined end date with return or destruction steps
- Periodic check-ins with the recipient on compliance
- Clear templates that distinguish DUAs, BAAs, and authorizations
🏥 The Nurse’s Perspective: Clinical, Bedside, & Workflow
Nurses rarely sign a DUA, yet nurse researchers, quality leaders, and informaticists regularly request or receive the data it governs.
At the Bedside
Bedside nurses are not parties to the agreement, but their documentation is the raw material. Complete, accurate, structured entries are what make a limited data set worth sharing in the first place. Nurses who spot a request to send patient data to an outside party, such as a student project or a vendor pilot, route it to the privacy office rather than emailing a spreadsheet.
In Clinical Workflow
Nurse researchers and doctoral students often need dates of care, units, and outcomes for studies. A DUA can make that possible without full identifiers, but the request still goes through the institutional process, including any review board steps that apply. Quality departments share data with registries and collaboratives under similar terms.
Nurse informaticists help translate the legal terms into data requirements. They confirm that the fields requested match the stated purpose, that free-text notes with names are excluded, and that the extract logic is documented for audit.
Managers should know that a DUA limits who may see the data. Passing a file to a colleague outside the named group, even with good intentions, can breach the agreement.
In EHR Implementation (Go-Live Perspective)
An Epic Go-Live generates new reporting needs, and early optimization often involves sharing data with vendors, consultants, or research partners. Reporting analysts check whether a request is covered by an existing agreement before building an extract. At-the-elbow support analysts redirect questions about sending screenshots or reports outside the organization to the privacy and compliance teams.
🎓 CAHIMS / CPHIMS & HIMSS Perspective
CAHIMS Exam Domain Mapping
DUAs appear in privacy, research, and data governance questions:
| CAHIMS Domain | How the DUA Appears |
|---|---|
| Healthcare & Technology Environments | HIPAA Privacy Rule, limited data sets, de-identification |
| Clinical Informatics | Research data requests, quality registries, extract design |
| Healthcare Information & Systems Management | Secure transfer, storage, access control, data retention |
| Management & Leadership | Contracts, compliance oversight, data governance policy |
Key Terms to Know Alongside the DUA
- Limited Data Set — PHI with direct identifiers removed, shareable only under a DUA
- De-identification — removal or statistical treatment of identifiers so data are no longer PHI
- Business Associate Agreement — contract with a vendor that performs services involving PHI
- Authorization — individual’s signed permission for a use or disclosure of PHI
- Minimum Necessary — limiting data to what a purpose requires
- Re-identification — linking data back to a person, prohibited under the agreement
HIMSS Organizational Position
HIMSS supports responsible data sharing and privacy protection through its public policy work, research, and Healthcare Cybersecurity Community. Members can find related resources through the HIMSS Resource Center and Public Policy and Advocacy pages.
🔗 Explore Further: External References
- eCFR — 45 CFR 164.514, Other Requirements Relating to Uses and Disclosures of PHI (Limited Data Set and Data Use Agreement) https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-E/section-164.514
- HHS — Research and the HIPAA Privacy Rule https://www.hhs.gov/hipaa/for-professionals/special-topics/research/index.html
- HHS — Methods for De-identification of PHI https://www.hhs.gov/hipaa/for-professionals/special-topics/de-identification/index.html
- HHS — Minimum Necessary Requirement https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html
- HHS — Sample Business Associate Agreement Provisions https://www.hhs.gov/hipaa/for-professionals/covered-entities/sample-business-associate-agreement-provisions/index.html
- NIST — SP 800-188, De-Identifying Government Datasets: Techniques and Governance https://csrc.nist.gov/pubs/sp/800/188/final
Term source: HIMSS Dictionary of Health Information and Technology Terms, Acronyms, and Organizations, 6th Edition (2025). All definitions in this series are paraphrased for editorial purposes. Readers are encouraged to consult the primary source for exact language.
Eric Andrew Kristof, RN, CAHIMS is a Healthcare IT professional and HIMSS Arkansas Chapter member based in Hot Springs Village, AR, with hands-on Epic Go-Live experience and a diverse healthcare and IT background. He writes at kristof.org at the intersection of clinical care and healthcare technology.
Leave a Reply