Limited Data Set under a Data Use Agreement
The rule, what the agreement must say, the steps, and what happens to the record after it reaches us.
For clinical research sites evaluating Total Patient Recruitment (TPR). Statutory text quoted verbatim from the Electronic Code of Federal Regulations, current as of 31 August 2026. Every citation on this page links to that exact dated version of the rule, not to a moving target.
The short version
A limited data set is still protected health information. Removing the sixteen direct identifiers in section 2 does not take the data outside HIPAA, the way Safe Harbor de-identification does. What permits you to disclose it is a Data Use Agreement between your site and Lumynix, and the rule sets out exactly what that agreement must contain.
What you get in return is the data Safe Harbor makes you strip. Full dates may stay, and so may town or city, State and ZIP code. For pre-screening, the date that matters is the date of birth: TPR computes eligibility age from the full date rather than from a year.
1.The rule that permits it
Standard: Limited data set. A covered entity may use or disclose a limited data set that meets the requirements of paragraphs (e)(2) and (e)(3) of this section, if the covered entity enters into a data use agreement with the limited data set recipient, in accordance with paragraph (e)(4) of this section.
The agreement is the condition. The next paragraph of the rule limits what a limited data set may be used for at all.
(i) A covered entity may use or disclose a limited data set under paragraph (e)(1) of this section only for the purposes of research, public health, or health care operations.
(ii) A covered entity may use protected health information to create a limited data set that meets the requirements of paragraph (e)(2) of this section, or disclose protected health information only to a business associate for such purpose, whether or not the limited data set is to be used by the covered entity.
Paragraph (i) is a determination for your site to make, not us. A limited data set may be disclosed only for research, public health or health care operations. Whether pre-screening your own patients for a trial falls under one of those, and which one, is a question for your site and its counsel. We don't answer it for you, and nothing on this page should be read as answering it.
Paragraph (ii) describes a business associate creating the limited data set for you. TPR does not do that. It has no step that removes identifiers from what you send, so under this posture the limited data set is created on your systems, before anything reaches us. If you would rather send full records, that is the Business Associate Agreement posture.
2.The sixteen identifiers you remove
Sixteen, not eighteen. The list is shorter than Safe Harbor's because a limited data set is allowed to keep some of what Safe Harbor removes. Each identifier below links to its own paragraph in the dated rule.
A limited data set is protected health information that excludes the following direct identifiers of the individual or of relatives, employers, or household members of the individual:
- (i) Names;
- (ii) Postal address information, other than town or city, State, and zip code;
- (iii) Telephone numbers;
- (iv) Fax numbers;
- (v) Electronic mail addresses;
- (vi) Social security numbers;
- (vii) Medical record numbers;
- (viii) Health plan beneficiary numbers;
- (ix) Account numbers;
- (x) Certificate/license numbers;
- (xi) Vehicle identifiers and serial numbers, including license plate numbers;
- (xii) Device identifiers and serial numbers;
- (xiii) Web Universal Resource Locators (URLs);
- (xiv) Internet Protocol (IP) address numbers;
- (xv) Biometric identifiers, including finger and voice prints; and
- (xvi) Full face photographic images and any comparable images.
What is missing from this list matters as much as what is on it. Dates are not on it, so a full date of birth may stay, and so may other dates in the record. Paragraph (ii) removes postal address information other than town or city, State and ZIP code, so those three may stay. And the list reaches past the patient: the identifiers of relatives, employers and household members come out too.
Medical record numbers are (vii). That rules out the number most sites would reach for to link a patient's rows together. Step 4 in section 5 covers what to use instead.
3.What the data use agreement must contain
(i) Agreement required. A covered entity may use or disclose a limited data set under paragraph (e)(1) of this section only if the covered entity obtains satisfactory assurance, in the form of a data use agreement that meets the requirements of this section, that the limited data set recipient will only use or disclose the protected health information for limited purposes.
A data use agreement between the covered entity and the limited data set recipient must:
- (A) Establish the permitted uses and disclosures of such information by the limited data set recipient, consistent with paragraph (e)(3) of this section. The data use agreement may not authorize the limited data set recipient to use or further disclose the information in a manner that would violate the requirements of this subpart, if done by the covered entity;
- (B) Establish who is permitted to use or receive the limited data set; and
- (C) Provide that the limited data set recipient will:
- (1) Not use or further disclose the information other than as permitted by the data use agreement or as otherwise required by law;
- (2) Use appropriate safeguards to prevent use or disclosure of the information other than as provided for by the data use agreement;
- (3) Report to the covered entity any use or disclosure of the information not provided for by its data use agreement of which it becomes aware;
- (4) Ensure that any agents to whom it provides the limited data set agree to the same restrictions and conditions that apply to the limited data set recipient with respect to such information; and
- (5) Not identify the information or contact the individuals.
Two of these bear directly on how TPR works.
(A) ties the agreement back to section 1. The permitted uses it sets out must be consistent with the purposes in paragraph (e)(3), which is why the purpose your site settles on is written into the agreement itself.
(C)(5): we do not identify the information or contact the individuals. TPR returns pre-screening results to your site, keyed to the code you assigned. We never receive the map from that code back to your records. TPR has no means of contacting a patient: it sends no email and no text messages, and patients have no accounts in it. Any contact with a patient is made by your site, through your own channels.
4.Who you are disclosing to
A vendor that does work on your behalf is usually a business associate, and a business associate usually needs a Business Associate Agreement. The rule has a provision for the case where what the vendor receives is a limited data set:
A covered entity may comply with this paragraph and § 164.314(a)(1) if the covered entity discloses only a limited data set to a business associate for the business associate to carry out a health care operations function and the covered entity has a data use agreement with the business associate that complies with §§ 164.514(e)(4) and 164.314(a)(1), if applicable.
Read the condition: for the business associate to carry out a health care operations function. Where that is what we are doing for you, this provision lets the data use agreement stand in for the business associate contract. Where your site treats pre-screening as research rather than health care operations, the provision as written does not reach it, and whether a vendor in our position needs a business associate agreement as well is for your counsel to settle.
We would rather point you at the condition than tell you it is met. If your site wants both, we will sign a business associate agreement alongside the data use agreement.
5.The steps
Sign the data use agreement
Before the first file is sent. Section 3 sets out what it must contain.
Steps 2 through 4 happen entirely inside your network, on your systems. We are not present for any of them.
Export from your source system
Your EMR, your CTMS, or both, as a CSV file. No connector, no integration, no vendor software inside your stack.
Remove the sixteen identifiers in section 2
Names, street address, telephone and fax numbers, email addresses, medical record and account numbers, and the rest of the list. TPR does not check this for you. Nothing in its importer rejects a name or a phone number if one arrives, so the removal is yours, and section 6 explains why it has to happen before you send.
Give each patient a code, and keep the map
One code per patient. TPR uses it to link a patient's diagnoses, medications and observations together, and with no names in a limited data set, it is required on every row. Not the medical record number and not an account number: both are on the list. You hold the map from code to patient, and it stays on your systems.
Send
The code and the fields in section 6. Nothing else.
6.What you send, and what TPR does with it
What TPR accepts
| Your patient code | Required on every row. It is how TPR links a patient's records together. |
| Date of birth | Required. Kept in full, as you send it. TPR computes eligibility age from it. There is no field for an age in place of a date, so a roster that carries ages instead of dates of birth will not import. |
| Sex | Required. Male, female, other or unknown. |
| Diagnoses | A code, with an optional description, clinical status and onset date. |
| Medications | The medication, with an optional code, start and end dates, and dosage text. |
| Observations | A code, with an optional description, status, value and unit, and effective date. |
| Town or city, State, ZIP | Accepted, but the screening model never receives them, so they add nothing to pre-screening. |
What TPR does not take. Admission, discharge and service dates, dates of death, county, procedures and allergies have no place in TPR's importer, and notes are not imported from a file. A limited data set may carry them. TPR has nowhere to put them.
What you send is what we hold
TPR keeps the file you upload exactly as you sent it, including any column its importer ignores, and that file is included in the backups described in section 8. A column left in by mistake is not discarded on arrival. It is held. Check the file before you send it.
What the screening model receives
- From the patient record, the date of birth and sex only, and only when a protocol's criteria need them. The date of birth arrives in full.
- From the clinical record, diagnoses, medications and observations with their dates as you sent them, and any notes your staff have typed into TPR when a screening run includes notes.
- It never receives your patient code, and never your town or city, State or ZIP code.
One other model call sees your rows. When an administrator asks TPR to propose a column mapping for a new export layout, it sends the column headers and up to twenty sample rows to a model on our own hardware. Under this posture, those rows are your limited data set.
How TPR handles your code
Before matching, TPR trims the spaces around your code, collapses repeated spaces inside it and
ignores letter case, so ab-123 and AB-123 are the same patient. Its
punctuation is kept as you sent it. We never receive the map from your code back to your
records.
What comes back to you
- A ranked pre-screening result keyed to your code, with the chart evidence behind each judgement.
- The platform recommends; your investigator decides. It never enrolls anyone.
7.Compared with Safe Harbor
| This adds | Why |
|---|---|
| A Data Use Agreement | § 164.514(e)(4)(i) requires one before a limited data set is disclosed. |
| Your Privacy Rule obligations | The data is still protected health information, so they continue. Among them, the minimum necessary standard applies to what you send. |
| A permitted purpose | Research, public health or health care operations, settled by your site. See section 1. |
| This removes | Why |
|---|---|
| Year-only dates | Dates may stay in full, and TPR keeps them in full. An age near an eligibility boundary is computed from the date of birth rather than the year. |
| The 90-and-over grouping | That aggregation is a Safe Harbor requirement. A limited data set has no equivalent, and TPR does not apply one to the records you send. |
| Town or city, State, ZIP | No longer have to be removed, though TPR does not use them for screening. |
One thing it does not add: an entry in your accounting of disclosures. Disclosures made as part of a limited data set are among the exceptions listed in § 164.528(a)(1)(viii).
8.Where your data lives
The first is a property of the software and is true wherever it runs. The rest describe how we stand up a site. They are facts about a deployment, and a deployment is something we provision rather than something the software guarantees on its own.
- Your own database. One physically separate database file per site. Reaching another site's data would mean opening a different file, not forgetting a filter.
- The database sits on hardware Lumynix owns and operates, not a third-party cloud tenancy.
- The model that reads your records runs on a different physical machine from the one that stores your database, reachable only over our private internal network.
- Your backups. Every backup is encrypted, and encryption is not optional. A backup is verified by reading every row back rather than by checking that a file opens. Backups are stored in Amazon S3, which holds ciphertext it cannot read.
- Records are retained, and nothing on our side deletes them. A defined retention schedule, agreed with you, is part of go-live rather than something we apply by default.
What runs on it
- All AI runs on our own hardware. There is no third-party AI service in the path, and no part of a patient record is ever sent to one.
- Outside our own hardware, TPR reaches three services. ClinicalTrials.gov, by public trial registry number, to retrieve protocol details; the request carries no patient data. Amazon Cognito, for staff sign-in, which holds no patient data. And Amazon S3, which stores the encrypted backups above. There is no outside error-tracking, analytics or logging service.
9.What this does not touch
Your IRB obligations are between you and your IRB, and nothing here changes them. A data use agreement settles how a limited data set may be disclosed. It says nothing about whether a given activity is human-subjects research, or what your IRB requires of recruitment and pre-screening procedures. Those turn on facts about the study, not about us. Your own institutional policies and your sponsors' contractual obligations likewise stand.
The permitted purpose is yours to determine. Section 1 explains why, and section 4 explains what turns on it.
And the removal is yours. The steps in section 5 run on your systems, and we are not present for them, which means we cannot verify that they were performed correctly, and we do not claim to.
We would rather say all of this plainly than imply a clearance we are not in a position to give.
10.About these citations
Every statutory passage on this page is quoted verbatim and links to the 31 August 2026 version of the rule on the Electronic Code of Federal Regulations,
using eCFR's point-in-time addresses (/on/2026-08-31/). Those links do not drift. If the rule is amended next month, these links keep
returning the text quoted here, and the difference will be visible to you rather than silently
absorbed. A link to the "current" version could not give you that, and neither could a PDF.
One limit worth stating, since it is the sort of thing you would otherwise find yourself. The eCFR is an editorial compilation maintained jointly by the Office of the Federal Register and the Government Publishing Office. It is updated daily and it is what we quote, but by its own reader-aid pages it is not yet the officially sanctioned legal edition of the CFR. The edition that carries that status is the annual print codification published by GPO at govinfo.gov, revised each 1 October for Title 45. For a filing, a submission, or anything where the official edition is what counts, cite that annual edition. For reading the rule as it stood on a given day, eCFR's dated URL is the more precise instrument, which is why it is the one on this page.