PHI de-identification for test environments

When does a test environment stop holding PHI?

When every record inside it has passed the method, and no other route puts anything else there. 45 CFR 164.502(d)(2) says that health information meeting the standard and implementation specifications for de-identification under 164.514(a) and (b) is considered not to be individually identifiable, and that the requirements of the subpart do not apply to it. The status attaches to the information. A host, a namespace or a virtual private cloud never acquires it.

That distinction decides who answers for the environment. A staging database seeded from a verified extract, and then topped up from a production snapshot on the Friday before a release, holds electronic protected health information from that Friday onward, and so does a defect tracker where a support engineer attached a chart to reproduce a rendering bug. Everyone working in it is holding patient data under somebody's contract from that moment. We sign a Business Associate Agreement before any engagement that touches PHI, and the rest of what a buyer settles before handing an environment to an outside team is set out under how we work with protected health information. Two of the seven questions there are published as unanswered, and one of the two is who builds a test environment and who can reach it. Require an answer to it in writing from whoever you engage, including us.

The technical safeguards at 45 CFR 164.312 apply to whatever system such a record landed on, and the argument that the environment is a test environment answers none of them. HIPAA testing requirements for software sets out which of those safeguards a test can exercise and which it cannot.

Which of the three routes are you taking?

45 CFR 164.514 offers two methods that leave the Privacy Rule and one arrangement that stays inside it. The three produce different data, and they differ in what the rule makes you write down about them.

The three HIPAA de-identification routes in 45 CFR 164.514, compared on what survives in the data, the document required and the result's status.

Route	What survives in the data	What the rule makes you produce	Status of the result
Safe harbor, 164.514(b)(2)	Year, state, and the first three digits of a zip code where the combined area holds more than 20,000 people	Nothing. The method as written names no document	Outside the Privacy Rule under 164.502(d)(2)
Expert determination, 164.514(b)(1)	Whatever the analysis shows carries a very small risk of identification	A written record of the methods and results of the analysis, required by (b)(1)(ii)	Outside the Privacy Rule under 164.502(d)(2)
Limited data set, 164.514(e)	Dates, and geography down to town or city, state and zip code	A data use agreement with the recipient, required by (e)(1)	Still protected health information, for three permitted purposes only

The safe harbor row is the one that catches teams out. 164.514(b)(2)(i) lists eighteen categories of identifier, lettered (A) through (R), and requires them removed for the individual and for relatives, employers and household members alike, so an emergency contact name and an employer field are inside the list even though no column header mentions a patient. Category (R) then reaches "any other unique identifying number, characteristic, or code", which means the list cannot be completed the way a checklist is completed. section 164.514(b)(2)(ii) closes it: the entity must also lack actual knowledge that what remains could be used, alone or in combination with other information, to identify a subject of the information. Removing all eighteen categories is necessary and is not on its own sufficient.

Expert determination is the route with a deliverable attached. 164.514(b)(1) describes a person with appropriate knowledge of and experience with generally accepted statistical and scientific principles and methods, who 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, and who documents the methods and results of the analysis that justify the determination. The rule names no accreditation body and sets no numeric threshold. "Very small" is the whole of the standard, and the written methods-and-results record is the artefact to ask for by name.

Where neither method can produce data your tests can actually run against, the route is to stop starting from real records. Testing with synthetic PHI data covers the data that was never anyone's.

In what order is the environment built?

Each step depends on the one before it, and a step run out of order silently voids the work already done. Steps 1 to 5 run inside the production boundary, on live data, under your existing safeguards. Step 6 is the crossing, and nothing reaches the environment before it.

Steps 1 to 5 touch live records, so they sit inside the Security Rule while they run. section 164.312(a)(1) requires access to be allowed only to persons or software programs granted access rights under 164.308(a)(4), and a de-identification job is a software program under that sentence. Audit controls at 164.312(b) require mechanisms that record and examine activity in systems that contain or use electronic protected health information, and a bulk read of a patient table is exactly such activity. The seeding run's own trace is therefore something the information system activity review at 164.308(a)(1)(ii)(D) will reach later, which is a reason to record the window before the job starts. Documentation of anything the subpart requires documented is retained for six years from creation or last effective date, whichever is later, under 164.316(b)(2)(i).

Step 9 is where long-lived environments fail. A refresh that appends new rows to an environment verified last quarter inherits that verification in the tracker and none of it in the data.

What breaks in the data once the identifiers are gone?

Tests that depended on the removed fields. Safe harbor is written to defeat identification, and several of its categories carry information your product uses as behaviour, so the extract comes back functionally different from the system it was taken from.

Dates. Category (C) removes all elements of dates except the year for dates directly related to an individual, and it names birth date, admission date, discharge date and date of death. Any rule that fires on an interval between two clinical events has no interval left to fire on: a refill reminder, a follow-up queue built from discharge, a duplicate-encounter check that keys on the same day. Age behaves differently. (C) removes all ages over 89 and all date elements indicative of such an age, and permits those to be aggregated into a single category of age 90 or older, which leaves an age below 90 usable as a stored value while an age computed at runtime from a birth date stops working.

Geography. Category (B) removes every geographic subdivision smaller than a state, and keeps the first three digits of a zip code only where all zip codes sharing those three digits cover more than 20,000 people according to current publicly available Census data. Where the combined area holds 20,000 or fewer, the three digits are changed to 000. Address validation, service-area eligibility and nearest-facility routing have nothing left to work on, and the 000 bucket is a value distribution that no production system ever produced.

Join keys. Categories (H), (I) and (J) take medical record numbers, health plan beneficiary numbers and account numbers. In most estates one of those is the join across systems, so removing it separates a lab result from the encounter it belongs to and an eligibility response from the claim that triggered it. A replacement key is permitted under 164.514(c), and it has to be generated independently of the patient, because (c)(1) forbids a code derived from or related to information about the individual. That constraint is the one that turns a de-identified extract into a piece of engineering: the key map is built once, kept outside the environment, and never shipped with it. The same problem appears whole in healthcare data migration testing, where the point of the exercise is that the joins survive.

Device serials. Category (M) removes device identifiers and serial numbers. Where a reading reaches the platform carrying the serial of the thing that produced it, that field is the patient association, and pairing, unpairing and misattribution tests lose their subject with it. Remote patient monitoring software testing covers what that class of product does with the association.

Network values. Categories (N) and (O) remove web URLs and IP addresses. Webhook targets, callback registrations and the source addresses recorded inside access history all fall under them, which changes what an access log looks like in the environment where you test it. Audit trail testing is the work that has to account for the difference.

Images and voice. Categories (P) and (Q) remove biometric identifiers, including finger and voice prints, and full face photographic images and any comparable images. A portal avatar, a stored consent recording and a wound photograph are each covered by one of the two.

Write the losses down as they are found. Each one is a test that has to move to another data source or be marked as unexecutable in this environment, and a suite that silently passes because the input can no longer trigger the rule is worse than a suite that fails.

What does the finished exercise leave behind?

Six records. They are the evidence that the environment is what the contract says it is, and they are what a customer's security questionnaire asks for a year later.

• The method record. States which of the three routes applies. States who chose it and on what date.
• The identifier-to-field map. One row per identifier category, per store. Empty rows are kept and marked, because a category nobody mapped and a category that does not occur look identical once the row is deleted.
• The verification result. One result per category, per store, against the extract that was actually loaded.
• The actual-knowledge statement. Records the check under 164.514(b)(2)(ii) and names who made it. Required only on the safe harbor route.
• The expert's methods-and-results document. Required by 164.514(b)(1)(ii) on the expert determination route, and produced by the expert.
• The seeding log. One entry per run: method, date, source build, operator, and the destination environment.

Keep the identifier-to-field map under the same change control as the schema. A column added to a patient table after the map was written is a column outside the map, and the next refresh carries it. Wider practice on holding these records across several environments and several releases belongs to test data management for healthcare software.

Where does the scrub miss?

In the places that are not columns. A de-identification job written against a schema handles a schema, and identifiers do not confine themselves to one.

Free text is the first. Clinical notes, ticket bodies, reason-for-visit fields and the comment box on a referral form carry names, employers and phone numbers that no column-level rule sees. Category (R) reaches them, and 164.514(b)(2)(ii) means a residual name inside a note is enough to defeat the whole extract.

Encoded objects are the second, and imaging is where it bites hardest. The identifiers in a DICOM instance are data elements inside the object, next to the pixels: (0010,0010) Patient's Name and (0010,0020) Patient ID are registered elements in PS3.6 Table 6-1, and a database scrub over the study table never opens the file that holds them. PS3.15 Annex E defines the Attribute Confidentiality Profiles for exactly this, and states that an implementation claiming conformance to the Basic Application Level Confidentiality Profile as a de-identifier shall protect or retain all instances of the attributes listed in Table E.1-1, whether contained in the top level Data Set or embedded in an Item of a Sequence of Items. Nested sequences are named in that sentence, and a scrub that walks only the top level Data Set satisfies half of it. Annex E then declines to call its own table sufficient: identifying information may sit in Private Attributes, new Standard Attributes, Retired Standard Attributes and attributes used in Standard Extended SOP Classes. What a conformance claim over that profile does and does not commit a vendor to is covered under DICOM conformance testing requirements.

Backups are the third. A snapshot taken before the transformation, restored afterwards to recover a lost fixture, returns the environment to where it started, and nothing in the tracker records that it happened.

The replacement key is the fourth. A team that needs stable identities across refreshes reaches for a hash of the medical record number, because it is reproducible and it looks opaque. 164.514(c)(1) rules it out on its face: the code may not be derived from or related to information about the individual. The defect survives review because the field looks random.

Production support is the fifth, and it appears after go-live, when the environments have been signed off and nobody is watching them. A reproduction case built from a real patient record is a disclosure into a system that was scoped on the assumption it would never hold one. We do not need production PHI to test. Environments run on synthetic and de-identified data, and the way that holds over time is that the inlets stay closed rather than that the first extract was good.

The Privacy Rule text on this page was read on 2 September 2026 against the CFR annual edition of title 45 revised as of 1 October 2024 and against the eCFR compilation current as of 31 August 2026, which are identical for every section quoted here. The Security Rule sections were read on the same date against the eCFR compilation current as of 31 August 2026. The DICOM material comes from release 2026c of PS3.6 and PS3.15, read on 2 September 2026.