Safe Harbor de-identification

The regulatory basis, 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 other two data postures: Limited Data Set under a Data Use Agreement · Business Associate Agreement

The short version

Under the route below, what you send Lumynix is not protected health information. It is not "PHI handled carefully." It is data that HIPAA's Privacy Rule, by its own terms, stops applying to. That removes the Business Associate Agreement, the Data Use Agreement, and the compliance review cycle from your path entirely, not because anyone waived them, but because there is no PHI disclosure to govern.

1.The rule that says so

45 CFR § 164.502(d)(2) Uses and disclosures of de-identified information eCFR · as of 31 August 2026

Health information that meets the standard and implementation specifications for de-identification under § 164.514(a) and (b) is considered not to be individually identifiable health information, i.e., de-identified. The requirements of this subpart do not apply to information that has been de-identified in accordance with the applicable requirements of § 164.514, provided that:
(i) Disclosure of a code or other means of record identification designed to enable coded or otherwise de-identified information to be re-identified constitutes disclosure of protected health information; and
(ii) If de-identified information is re-identified, a covered entity may use or disclose such re-identified information only as permitted or required by this subpart.

Note what (i) requires, because it is the operational point: the code is fine. Disclosing the code together with the means of re-identification is not. That is precisely why the crosswalk stays with you and never reaches us.

2.The eighteen identifiers you remove

45 CFR § 164.514(b) offers two routes to the same destination, and it is worth knowing which one this is before you read the list, because the choice decides how much of the burden lands on you.

45 CFR § 164.514(b) Requirements for de-identification: the two routes eCFR · as of 31 August 2026

A covered entity may determine that health information is not individually identifiable health information only if:
(1) A person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods for rendering information not individually identifiable:
(i) Applying such principles and methods, determines that the risk is very small that the information could be used, alone or in combination with other reasonably available information, by an anticipated recipient to identify an individual who is a subject of the information; and
(ii) Documents the methods and results of the analysis that justify such determination; or

That first route, (b)(1), expert determination, is not what we are asking you to do. It requires a qualified person to reach a statistical judgement that re-identification risk is "very small," and to document the methods and results justifying it. That judgement is defensible, but it is also theirs to defend, on request, later, possibly by someone who was not there. It costs money and it never fully closes.

The route below is (b)(2), Safe Harbor, and it is a checklist. Remove these eighteen categories, hold no actual knowledge that the remainder could identify someone, and the data is de-identified as a matter of the rule's own terms. There is no expert to retain and no judgement call to defend later, which is the entire reason we ask for this route rather than the other one. Whether you complied is a question about the fields you sent, and you can answer it by looking.

Each identifier below links to its own paragraph in the dated rule.

45 CFR § 164.514(b)(2)(i) Requirements for de-identification eCFR · as of 31 August 2026

(A) Names;
(B) All geographic subdivisions smaller than a State, including street address, city, county, precinct, zip code, and their equivalent geocodes, except for the initial three digits of a zip code if, according to the current publicly available data from the Bureau of the Census:
(1) The geographic unit formed by combining all zip codes with the same three initial digits contains more than 20,000 people; and
(2) The initial three digits of a zip code for all such geographic units containing 20,000 or fewer people is changed to 000.
(C) All elements of dates (except year) for dates directly related to an individual, including birth date, admission date, discharge date, date of death; and all ages over 89 and all elements of dates (including year) indicative of such age, except that such ages and elements may be aggregated into a single category of age 90 or older;
(D) Telephone numbers;
(E) Fax numbers;
(F) Electronic mail addresses;
(G) Social security numbers;
(H) Medical record numbers;
(I) Health plan beneficiary numbers;
(J) Account numbers;
(K) Certificate/license numbers;
(L) Vehicle identifiers and serial numbers, including license plate numbers;
(M) Device identifiers and serial numbers;
(N) Web Universal Resource Locators (URLs);
(O) Internet Protocol (IP) address numbers;
(P) Biometric identifiers, including finger and voice prints;
(Q) Full face photographic images and any comparable images; and
(R) Any other unique identifying number, characteristic, or code, except as permitted by paragraph (c) of this section; and

(ii) The covered entity does not have actual knowledge that the information could be used alone or in combination with other information to identify an individual who is a subject of the information.

Two things worth drawing out, both highlighted above. Sex is not on this list. It stays. And (C) is why year of birth is acceptable and a full date is not, and why patients 90 and older need separate handling. (R) is the paragraph that makes a site-generated patient code workable, and its carve-out points directly at the next section.

3.Your patient code is expressly permitted

45 CFR § 164.514(c) Re-identification eCFR · as of 31 August 2026

A covered entity may assign a code or other means of record identification to allow information de-identified under this section to be re-identified by the covered entity, provided that:
(1) Derivation. The code or other means of record identification is not derived from or related to information about the individual and is not otherwise capable of being translated so as to identify the individual; and
(2) Security. The covered entity does not use or disclose the code or other means of record identification for any other purpose, and does not disclose the mechanism for re-identification.

This is the provision that makes the arrangement work rather than a workaround of it. Category (R) above carries the explicit carve-out "except as permitted by paragraph (c)." A site-generated code, not derived from the record, with the mapping held only by you, is the shape this provision describes.

4.The steps

Steps 1 through 5 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. A standard export. No connector, no integration, no vendor software inside your stack.

Keep only these

Medications · diagnoses · sex · year of birth · clinical notes and observations, scrubbed.

Reduce the dates

Date of birth becomes the year alone. Send it in whatever shape your export already produces. 1975-00-00, 00/00/1975 and 1975-01-01 all import correctly and are all read as year only. You should not have to reformat anything to suit us. If your export emits the year in some other shape, tell us and we will accept that too That is our work, not yours. Where a month and day are required to carry the field, we substitute a fixed placeholder; a constant month and day convey nothing about the person.
Any patient aged 90 or over: set the year to the current year minus 90, so that every patient 90 and older carries the same year and becomes indistinguishable. This is the aggregation that (C) requires, and it is recalculated each time you send.
Every other date related to the individual, meaning admission, discharge, service and death, year only, same rule.

Remove the identifiers in section 2

Our recommendation: do not send notes or observations in the first phase

Send medications, diagnoses, coded observations, year of birth, sex, and the code. Leave narrative notes out.

Free-text notes are where de-identification actually goes wrong. Structured fields are straightforward: coded diagnoses, coded labs, medication lists. Narrative notes routinely carry patient and relative names, referring-provider names, facility names, "seen 3/14," phone numbers, and record numbers retyped inline by a person. No scrubber catches all of that reliably.

Leaving them out makes the de-identification mechanically true rather than dependent on how well a scrubber performed, and it is a far easier thing for your own reviewers to sign off on. Notes can be added in a later phase, deliberately, with a validation step.

We would rather start narrower and be certain than start wide and be approximately right.

Assign your code and keep the map

One code per patient, not derived from and not derivable from anything you are sending. Not the record number, not initials, not a date, not a hash of any of them. You create and hold the mapping. It never leaves your systems.

Send

The code and the fields. Nothing else.

5.What this removes from your path

Not required	Why
Business Associate Agreement	We are not handling PHI on your behalf, because what you send is not PHI
Data Use Agreement	A DUA governs a Limited Data Set, which may retain full dates and geography. Safe Harbor is stricter and sits outside that regime
A PHI compliance review cycle	There is no PHI disclosure to review

6.Where your data lives

What you send us

Five fields and a code. Nothing else.

Medications	As exported from your system.
Diagnoses	As exported from your system.
Sex	Not one of the eighteen identifiers HIPAA requires you to remove. It stays.
Year of birth	No month, no day, so an age we compute is accurate to within a year, and each import reports how many birth dates in that file were year-only. Any patient aged 90 or over: the year is set to the current year minus 90, so every patient 90 and older carries the same year and becomes indistinguishable.
Notes & observations	With identifiers removed before they leave your systems. We recommend leaving these out of the first phase. See step 4.
Your patient code	Generated by you. Only you can resolve it back to a person.

What we never receive

No names. Not the patient's, not a relative's, not a provider's.
No dates of birth, no admission, discharge or service dates.
No medical record numbers, account numbers, addresses, phone numbers or email addresses.
No crosswalk. The map from your code back to your record stays on your systems. We never receive it, never ask for it, and cannot reconstruct it.

An attacker who took everything we hold would have medications and diagnoses attached to codes that mean nothing without the map on your side.

How we handle your code

Your code is an opaque token to us. We compare it as written, ignoring only letter case and extra spaces, and never parse it, infer from it, or attempt to reverse it. Our software preserves its punctuation precisely because its meaning is unknown to us. The platform is built to run on records that have no name attached; that is a first-class case in the system, not a workaround.

Where it lives

The first is a property of the software and is true wherever it runs. The rest describe how we stand up a site, which is the honest way to put them. 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, which is the drill in section 8. Backups are stored in Amazon S3, which holds ciphertext it cannot read. Before a site goes live we run that drill against its own records and hand over the signed record of it.
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 screening model never sees your patient code. It receives the clinical picture only.
The platform makes three external calls, and none of them carries readable patient data: ClinicalTrials.gov, by public trial registry number, to retrieve protocol details; Amazon Cognito, for staff sign-in only; and Amazon S3, which receives the encrypted backups and holds ciphertext it cannot read.

What comes back to you

A ranked pre-screening result keyed to your code, with the chart evidence behind each judgement.
Pre-screening only. The platform recommends; your investigator decides. It never enrolls anyone.

What you can always do

Download your complete database at any time, in one request. Administrator-gated and recorded. Your data is yours and it is portable.
Corrections do not erase what came before. A clinical correction is recorded as a retraction and remains restorable, and when two of your source systems disagree about a fact, the value that loses is kept and marked superseded rather than overwritten. Every import, export and download is attributed and audited, with a server-generated timestamp the caller cannot set.

7.What happens to the record after it reaches us

Sections 1 through 5 answer the HIPAA question completely. This section answers the one an FDA-regulated site asks second.

21 CFR Part 11 is the FDA's rule for electronic records. Its scope, in its own words:

21 CFR § 11.1(b) Scope eCFR · as of 31 August 2026

This part applies to records in electronic form that are created, modified, maintained, archived, retrieved, or transmitted, under any records requirements set forth in agency regulations. This part also applies to electronic records submitted to the agency under requirements of the Federal Food, Drug, and Cosmetic Act and the Public Health Service Act, even if such records are not specifically identified in agency regulations. However, this part does not apply to paper records that are, or have been, transmitted by electronic means.

Part 11 attaches to the records you are required to keep, your case histories and your source documentation, and those never leave your systems. A pre-screening ranking, keyed to a code you generated, for a person who is not yet a subject, is not that record. Your Part 11 obligations are yours and nothing in this arrangement changes them.

Where its controls bear on what we do hold, we meet them. Most of the rule does not reach us for a simple reason: the platform has no electronic signatures, which places the whole of Subpart C outside its scope, along with §§ 11.50 and 11.70 and § 11.10(j). Section 11.30 governs open systems and this is a closed one. What remains is § 11.10, and against it:

Access is limited to authorized individuals, and only people authorized to write are given accounts at all. (d, g)
Audit trails are computer generated and server time stamped. The timestamp is set by our server at the moment of the event, and the caller has no way to supply it or override it. Deletion of audit records is blocked in production. No application code path deletes an audit record, and the one shared helper that can, our own test tooling, refuses to run when NODE_ENV is production. (e)
A record change never obscures what came before. When two of your source systems disagree about a clinical fact, the value that loses is kept and marked superseded rather than overwritten, and the conflict stays visible. A clinical correction is recorded as a retraction and remains restorable. (e)
You can obtain a complete copy of your records at any time, in one request, administrator gated, and the download itself recorded. (b)
Change control over system documentation is maintained in version control. (k)(2)
Operational sequencing is enforced and tested. The rule qualifies this one with the words "as appropriate" and does not compel it for a system of this kind. We do it anyway: protocol activation, protocol lifecycle, extraction, patient lifecycle and questionnaire archiving each move through states the software enforces, with integration tests covering the transitions. Device checks, also qualified, do not apply here. (f, h)

21 CFR § 11.10(e) Controls for closed systems eCFR · as of 31 August 2026

Use of secure, computer-generated, time-stamped audit trails to independently record the date and time of operator entries and actions that create, modify, or delete electronic records. Record changes shall not obscure previously recorded information. Such audit trail documentation shall be retained for a period at least as long as that required for the subject electronic records and shall be available for agency review and copying.

System validation under § 11.10(a). We maintain a documented validation package for the platform: a validation plan, a written requirements specification, and a traceability matrix that maps every requirement either to the test that proves it or to the plain fact that no test does. Installation and operational qualification are executed and recorded against a named build. Your instance is qualified on installation before it carries your records, and the performance qualification runs on your own data, in your own instance, before go-live. You receive that signed record. The package states its own limits, including the requirements we do not yet meet, and we will send it to you or to your sponsor on request.

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.

8.Before your site goes live

Stage one, the system. We back up a test instance, destroy it, restore it, and confirm the restored records match. Signed and dated internally, before any customer data exists.

Stage two, your instance. After your records are ingested and before you go live, we run the same drill on your own data. We back it up, restore it to an isolated location, confirm the restored records match, and then destroy the working copy. You receive the signed, dated record of that verification. Your system is not green lighted until it passes.

We would rather hand you evidence than an assurance.

9.What this does not touch

Your IRB obligations are between you and your IRB, and nothing here changes them. HIPAA's Privacy Rule ceasing to apply to de-identified data 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.

And the scrub is yours. The steps in section 4 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. Our platform is built to operate on records that arrive already de-identified. That division is the point of the arrangement, not a gap in it.

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 and each 1 April for Title 21. 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.

We have deliberately not published section-level deep links into govinfo. Its per-section identifiers are not derivable from a citation and have to be looked up per document; a plausible-looking link that lands in the wrong place would be worse than the sentence above.