Business Associate Agreement
The rule, what the agreement must say, and what happens to each identifier 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
Under this posture you may send identifiable records, and Lumynix handles them as your business associate. Names, medical record numbers and contact details can travel with the clinical data, and nothing has to be stripped on your side first.
The rule permits that disclosure on one condition: a written agreement that gives you satisfactory assurance we will safeguard the information. Lumynix signs a Business Associate Agreement where a site's data posture requires one, and this is the posture that does. The rest of this page sets out what that agreement must contain and what TPR actually does with each identifier you send.
1.The rule that permits it
Business associate: (1) Except as provided in paragraph (4) of this definition, business associate means, with respect to a covered entity, a person who:
(i) On behalf of such covered entity or of an organized health care arrangement (as defined in this section) in which the covered entity participates, but other than in the capacity of a member of the workforce of such covered entity or arrangement, creates, receives, maintains, or transmits protected health information for a function or activity regulated by this subchapter, including claims processing or administration, data analysis, processing or administration, utilization review, quality assurance, patient safety activities listed at 42 CFR 3.20, billing, benefit management, practice management, and repricing; or
Receiving and maintaining records on your behalf is exactly what TPR does under this posture. You send the records, TPR stores them and screens them, and that makes Lumynix your business associate. The disclosure itself is governed here:
Standard: Disclosures to business associates. (i) A covered entity may disclose protected health information to a business associate and may allow a business associate to create, receive, maintain, or transmit protected health information on its behalf, if the covered entity obtains satisfactory assurance that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
(ii) A business associate may disclose protected health information to a business associate that is a subcontractor and may allow the subcontractor to create, receive, maintain, or transmit protected health information on its behalf, if the business associate obtains satisfactory assurances, in accordance with § 164.504(e)(1)(i), that the subcontractor will appropriately safeguard the information.
(2) Implementation specification: Documentation. The satisfactory assurances required by paragraph (e)(1) of this section must be documented through a written contract or other written agreement or arrangement with the business associate that meets the applicable requirements of § 164.504(e).
Satisfactory assurance, documented in writing. That is what the agreement is. Paragraph (2) sends you to § 164.504(e) for what it must say, which is the next section.
2.What the agreement must contain
A contract between the covered entity and a business associate must:
- (i) Establish the permitted and required uses and disclosures of protected health information by the business associate. The contract may not authorize the business associate to use or further disclose the information in a manner that would violate the requirements of this subpart, if done by the covered entity, except that:
- (A) The contract may permit the business associate to use and disclose protected health information for the proper management and administration of the business associate, as provided in paragraph (e)(4) of this section; and
- (B) The contract may permit the business associate to provide data aggregation services relating to the health care operations of the covered entity.
- (ii) Provide that the business associate will:
- (A) Not use or further disclose the information other than as permitted or required by the contract or as required by law;
- (B) Use appropriate safeguards and comply, where applicable, with subpart C of this part with respect to electronic protected health information, to prevent use or disclosure of the information other than as provided for by its contract;
- (C) Report to the covered entity any use or disclosure of the information not provided for by its contract of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410;
- (D) In accordance with § 164.502(e)(1)(ii), ensure that any subcontractors that create, receive, maintain, or transmit protected health information on behalf of the business associate agree to the same restrictions and conditions that apply to the business associate with respect to such information;
- (E) Make available protected health information in accordance with § 164.524;
- (F) Make available protected health information for amendment and incorporate any amendments to protected health information in accordance with § 164.526;
- (G) Make available the information required to provide an accounting of disclosures in accordance with § 164.528;
- (H) To the extent the business associate is to carry out a covered entity's obligation under this subpart, comply with the requirements of this subpart that apply to the covered entity in the performance of such obligation.
- (I) Make its internal practices, books, and records relating to the use and disclosure of protected health information received from, or created or received by the business associate on behalf of, the covered entity available to the Secretary for purposes of determining the covered entity's compliance with this subpart; and
- (J) At termination of the contract, if feasible, return or destroy all protected health information received from, or created or received by the business associate on behalf of, the covered entity that the business associate still maintains in any form and retain no copies of such information or, if such return or destruction is not feasible, extend the protections of the contract to the information and limit further uses and disclosures to those purposes that make the return or destruction of the information infeasible.
- (iii) Authorize termination of the contract by the covered entity, if the covered entity determines that the business associate has violated a material term of the contract.
Three of these are worth reading against the rest of this page.
- (ii)(B) brings in subpart C, the Security Rule, for electronic records. That is section 3.
- (ii)(C) has the agreement commit us to report to you any use or disclosure it does not provide for, including breaches of unsecured protected health information under § 164.410.
- (ii)(D) extends the same restrictions to anyone we pass the information to. That is section 4.
3.The Security Rule's part
Records sent as files are electronic, so the Security Rule has its own version of the same requirement.
Business associate contracts and other arrangements. A covered entity may permit a business associate to create, receive, maintain, or transmit electronic protected health information on the covered entity's behalf only if the covered entity obtains satisfactory assurances, in accordance with § 164.314(a), that the business associate will appropriately safeguard the information. A covered entity is not required to obtain such satisfactory assurances from a business associate that is a subcontractor.
Business associate contracts. The contract must provide that the business associate will—
- (A) Comply with the applicable requirements of this subpart;
- (B) In accordance with § 164.308(b)(2), ensure that any subcontractors that create, receive, maintain, or transmit electronic protected health information on behalf of the business associate agree to comply with the applicable requirements of this subpart by entering into a contract or other arrangement that complies with this section; and
- (C) Report to the covered entity any security incident of which it becomes aware, including breaches of unsecured protected health information as required by § 164.410.
(A) is a promise the agreement makes, and (C) is a duty to tell you. What TPR does today is in section 8, written as facts about a deployment you can check, not as a compliance status.
4.Subcontractors
(3) Business associate includes:
(iii) A subcontractor that creates, receives, maintains, or transmits protected health information on behalf of the business associate.
So it matters who else touches your records. The model that reads them runs on our own hardware, so it is not one. Outside our own hardware, TPR reaches three services, and this is what each one holds:
| Service | What it holds |
|---|---|
| ClinicalTrials.gov | Nothing of yours. TPR asks it for protocol details by public trial registry number. |
| Amazon Cognito | Staff sign-in. No patient data. |
| Amazon S3 | Your backups. Every backup is encrypted, and encryption is not optional. Backups are stored in Amazon S3, which holds ciphertext it cannot read. Under this posture, that ciphertext is your identifiable records. Our off-site backup provider is covered by a business associate agreement with Lumynix. |
There is no outside error-tracking, analytics or logging service. If your review needs the arrangements behind any of these, ask us.
5.The steps
Sign the agreement
Before any protected health information is sent. Section 2 sets out what it must contain.
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.
Send what pre-screening needs
The minimum necessary standard applies to what you disclose to a business associate, so send the fields in section 6 and leave out what TPR has no use for. In particular, leave out social security numbers. TPR has no field for one, and as section 6 explains, a column TPR does not read is still held.
Send, and read the results
Results come back to your staff, with the chart evidence behind each judgement. The platform recommends; your investigator decides. It never enrolls anyone.
6.What you send, and what TPR does with each identifier
What TPR accepts
| Name | First and last. Shown to your staff. Never sent to the screening model. |
| Record number | One per patient: your medical record number, or a code of your own. It links a patient's records together. Each row needs a name, this number, or both. Never sent to the screening model. |
| Date of birth | Required. Kept in full, as you send it. TPR computes eligibility age from it. |
| Sex | Required. Male, female, other or unknown. |
| Address | Street, town or city, State, ZIP code and country. There is no county field. |
| Phone and email | One of each, and the email address is checked for format. Stored and shown to your staff. TPR never uses either to contact anyone. |
| Insurance | Free text. |
| Clinical records | Diagnoses with onset dates, medications with start and end dates, and observations with their values and effective dates. |
What TPR has no field for. Social security numbers, a second phone number, email address or street address, county, admission, discharge and service dates, dates of death, procedures and allergies. Notes are not imported from a file.
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 with no field in TPR is not discarded on arrival. It is held. That is why step 3 asks you to leave out what TPR has no use for.
Who sees each identifier
- Your staff. TPR labels each patient by name, or by record number when there is no name. The patient list shows name, record number, site and date of birth, and searches by name. Printed pre-screening logs carry the patient's name, date of birth and record number.
- The screening model never receives a name, a record number, a phone number, an email address, any part of an address, or insurance. From the patient record it receives the date of birth and sex only, and only when a protocol's criteria need them. The date of birth arrives in full.
- One caution about notes. Notes your staff type into TPR reach the screening model when a run includes notes, and a typed note can carry a name or a number. What goes into a note is up to the person writing it.
- 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 can include names and record numbers.
No contact with your patients
TPR does not contact your patients. It sends no email and no text messages, and patients have no accounts in it. A stored phone number or email address is there for your staff to see and edit.
How TPR matches a record number
Before matching, TPR trims the spaces around a record number, collapses repeated spaces inside
it and ignores letter case, so mrn-123 and MRN-123 are the same
patient. Its punctuation is kept as you sent it.
7.Compared with Safe Harbor
| This adds | Why |
|---|---|
| A Business Associate Agreement | § 164.502(e)(2) requires the assurance to be documented in writing. |
| Your Privacy Rule obligations | The data is protected health information, so they continue. Among them, the minimum necessary standard applies to what you send. |
| Breach reporting to you | The agreement must provide that we report breaches of unsecured protected health information, as (e)(2)(ii)(C) sets out. |
| This removes | Why |
|---|---|
| The scrub on your side | There are no identifiers to remove before you send. Names, record numbers and contact details may stay. |
| Year-only dates | Dates may stay in full, and TPR keeps them in full. The 90-and-over grouping goes with them. |
| A separate patient code | Your medical record number can link a patient's records. You keep no map. |
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.
- The outside services TPR reaches, and what each one holds, are in section 4.
9.What this does not touch
Your IRB obligations are between you and your IRB, and nothing here changes them. A business associate agreement settles how we may handle the records you send. 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.
Running TPR on your own premises is not an exemption. Records would stop travelling to our hardware, but whether we are your business associate turns on whether we create, receive, maintain or transmit protected health information on your behalf. An on-premises deployment carries a BAA scoped to your data posture, the same as a hosted one.
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.