Test data management for healthcare compliance

What is under control when you manage test data?

The dataset at a stated version, together with a list of every copy of it. An environment is where a dataset is used, and a defensible test result names both. clause 5.7.5 of IEC 62304 lists seven items a software system test record documents, and four of them fix what a rerun would have to reproduce: the version of the software tested, the relevant hardware and software test configurations, the relevant test tools, and the date tested. The clause gives its purpose as supporting the repeatability of tests, and it binds at safety classes A, B and C alike. Nothing in that list is satisfied by an environment name.

Repeatability is the first property to fail when data moves without a name. clause 5.7.4 requires the manufacturer to verify that traceability between software requirements and tests is recorded and that results meet the pass/fail criteria, and a suite rerun next quarter against different rows under the same dataset name still satisfies the form of that record while the result underneath it has changed meaning. Clause 8 of the standard, the software configuration management process, is where the decision belongs: 8.1 Configuration identification, 8.2 Change control, 8.3 Configuration status accounting. Register the dataset as a configuration item or write down that you did not. Which of these clauses bind on your software, and at which safety class, is worked through in IEC 62304 software testing requirements.

Which route produced this dataset?

Every entry in the register names one of three origins, and the third is the one that costs money. Each origin fills the same three cells of a row, so the row can be written without opening another page.

Records that were generated and never belonged to anyone are covered in testing with synthetic PHI data. The row reads: identifier issued at generation, origin "generated", artefact the generator manifest naming the seed, the generator version and the profiles it was built to, classification not electronic protected health information.

Extracts of real records put through 45 CFR 164.514 are covered in PHI de-identification for test environments. The row reads: identifier issued when the extract is cut, origin "de-identified under 164.514" with the method named, artefact the verification result for that method, classification not electronic protected health information from the date on the verification and protected health information before it.

The third origin is a dataset nobody wrote down. Its row reads: identifier issued now, origin "unrecorded", artefact none, classification electronic protected health information. It has to be handled as though it came from production until someone establishes otherwise, and establishing it after the fact means reading rows for identifiers instead of reading a one-line record written on the day the dataset was made. Datasets in this state are usually the oldest ones in the estate, which also makes them the most copied.

Who is allowed to hold a copy?

Whoever your contract reaches, and the definition of that group is wider than a test estate usually assumes. 45 CFR 160.103 defines a business associate by function, and the listed examples include data analysis, processing or administration and quality assurance. Paragraph (3)(iii) brings in a subcontractor that creates, receives, maintains or transmits protected health information on behalf of the business associate, so the chain follows the copies a test estate makes without thinking about them. A fixture repository holding a row set pulled out of a staging database is a holder. A container image with a seeded schema baked into a layer is a holder, and it keeps holding after the layer is superseded, because the layer is still in the registry. A ticket with twenty rows pasted into it to reproduce a defect is a holder, and so is the attachment store behind the tracker. Each of those goes in the holder column under its own name, and each is a party the contract has to reach before a dataset that is still PHI reaches it. Inside the Security Rule the written contract sits at 45 CFR 164.308(b)(3), with its contents set by 164.314(a).

The holder list is therefore the row a lawyer reads first, and it is column five of the register below. We sign a Business Associate Agreement before any engagement that touches PHI, and what else is fixed on our side before any dataset moves is published in our answers on working with protected health information.

Automated holders belong on the same list. 45 CFR 164.312(a)(1) requires technical policies and procedures for electronic information systems that maintain electronic protected health information "to allow access only to those persons or software programs that have been granted access rights as specified in Sec. 164.308(a)(4)". A nightly job that copies a snapshot into a sandbox is such a software program, and it holds the data whether or not a person was watching. Which of these safeguards a test can exercise, and which it cannot, is set out under HIPAA testing requirements for software.

How long does the dataset live?

Two clocks run, and different rules set them. The record of a test has a retention period. The rows the test ran on often have none, and a project that never separates the two keeps everything.

section 164.316(b)(1) requires a written record of any action, activity or assessment that the subpart requires to be documented. 164.316(b)(2)(i) is a required implementation specification and sets the period: retain the documentation for six years from the date of its creation or the date when it last was in effect, whichever is later. 164.316(b)(2)(iii) adds periodic review and update of that documentation in response to environmental or operational changes.

Part 11 imports its period instead of setting one. 11.10(c) asks for "Protection of records to enable their accurate and ready retrieval throughout the records retention period", and 11.1(b) applies the part to records created, modified, maintained, archived, retrieved or transmitted under records requirements set out in other agency regulations. The 2003 scope and application guidance takes enforcement discretion over 11.10(c) and then closes it: "Persons must still comply with all applicable predicate rule requirements for record retention and availability." The same guidance says FDA does not intend to object where a required record is archived to a standard electronic file format such as PDF, XML or SGML, provided the predicate rule requirements are satisfied and the content and meaning are preserved, after which the electronic version may be deleted. Where the record is an audit trail, 21 CFR 11.10(e) requires the audit trail documentation to be retained at least as long as the subject records and to be available for agency review and copying.

Read together, those give a rule you can apply to a dataset in one minute. Export the record into a form that reads without the data. If it reads, the dataset's end date is its own. If it does not, the dataset inherits the record's clock, and the register says so on the row.

How is a dataset refreshed and promoted between environments?

By issuing a new identifier and moving the old one out of reach, in that order. A refresh is a new configuration item, not an update to an existing one, and treating it as an update is what silently voids the results that came before it.

IEC 62304 clause 5.7.5 requires a system test record to document the version of the software tested and the relevant hardware and software test configurations, and it names repeatability of tests as the reason. A result recorded against dataset MDM-014 is repeatable only while MDM-014 still holds the rows it held on the day. So a refresh takes the next identifier, MDM-015, and the register keeps both rows open until every test record naming MDM-014 has reached its own end date.

Promotion between environments follows the classification column, not the convenience of the copy. A dataset marked as electronic protected health information does not move into an environment whose holders are not on its holder list, and adding a holder is the contract question above, not a deployment step. A dataset marked as not protected health information moves freely, and the artefact that proves the classification travels with it, because the environment it lands in is where somebody will next ask what the rows are.

Three things get written down at each promotion, and each answers a question somebody asks later. The identifier and the environment, so a failing suite can be traced to the rows it ran on. The pinned upstream versions the dataset was built against, because a code set or a schema that moved between environments turns a data defect into a false product defect. The date, because the retention clock on the dependent records starts from the record, and a record with no date against a dataset with no date settles nothing.

A dataset that is refreshed by overwriting the environment it lives in leaves no trace of either state. What the register shows afterwards is a row whose contents were true at some point, which is the same position as an unrecorded origin, and it is reached from the other direction.

In what order is a dataset retired?

Steps 5 and 6 are the two the rule makes required. 45 CFR 164.310(d)(1), Device and media controls, carries four implementation specifications: Disposal at (d)(2)(i) and Media re-use at (d)(2)(ii) are both marked Required, while Accountability at (d)(2)(iii) and Data backup and storage at (d)(2)(iv) are Addressable. Addressable never means optional. 164.306(d) requires the entity to assess whether the specification is reasonable and appropriate, implement it if it is, and otherwise record why it was not implemented along with the equivalent alternative measure adopted, the written record being called for at 164.306(d)(3)(ii)(B)(1). Accountability is the specification that produces a record of the movements of hardware and electronic media, so a project that declines it and writes no equivalent has step 4 with nothing to work from.

What does the register have to show?

One row per dataset, eight columns, held under the same change control as the schema it was drawn against.

The eight columns a healthcare test data register holds for each dataset, with what each column settles.

Column	What it settles
Dataset identifier	Which rows a given test result was produced against
Origin and method	Whether the dataset was generated, de-identified under 45 CFR 164.514, or of unrecorded origin, and the artefact that proves it
Classification	Whether the dataset is handled as electronic protected health information today
Pinned versions	Which upstream releases and schema versions the dataset was built against
Holder list	Every party and every system holding a copy, automated holders included
Dependent records	Which test records cite this identifier and when each may be destroyed
Retirement date and trigger	The end date, and the event that starts the clock
Closure entry	Date, operator, copies destroyed and the method used on each

The dependent records column is the one that repays the effort. Without it, retirement is blocked by an unanswerable question about what a deletion would break, and the default answer to an unanswerable question is to keep the data.

Where does test data governance fail?

The dataset that outlived its project. No owner is named, so nobody has authority to destroy it, and the safest available reading gets applied to it forever. Retention decisions belong to a named person, and the register is where the name goes.

The suite that seeds itself. A run that builds its own rows creates an unregistered dataset every time it executes. FDA's computer software assurance guidance of 3 February 2026 recommends digital records "such as system logs, audit trails, and other data generated and maintained by the system" as the least-burdensome form of objective evidence, which works only where the run's own log records the seed and the inputs it used. That guidance covers software used as part of production or the quality management system and expressly excludes device software functions, so it reaches the estate around the product. Keeping a generated dataset identifiable inside an automated pipeline is the subject of test automation in a validated environment.

The backup that survives the deletion. Data backup and storage at 45 CFR 164.310(d)(2)(iv) is addressable and is usually implemented, which means a retirement that reaches the live copies and not the backup generations restores the dataset on the next incident. Name the generations in step 4 or the register records a destruction that did not happen.

The shared dataset with two writers. A performance suite and a manual tester working the same rows produce a dataset that neither of them can describe by lunchtime, and every failure after that is a debate about who mutated what. One writer per dataset copy, and a fresh copy for the second writer.

The media that changed hands. Media re-use at 164.310(d)(2)(ii) is a required implementation specification, and a workstation reassigned between projects is the commonest re-use event in a test estate. It rarely appears in a retirement plan because it is a facilities event on the day it happens.

What does this work produce?

An index of every dataset in the estate, a route and an artefact behind each one, and an end date on each row that somebody has authority to act on. We do not need production PHI to test. Environments run on synthetic and de-identified data, and governance is what keeps that statement true on the twentieth environment rather than the first. The record side of the work, and the form the artefacts take for an auditor, is described under validation documentation.

The Security Rule text on this page was read on 2 September 2026 against the eCFR compilation of title 45 current as of 31 August 2026, and the business associate definition at 160.103 against the same compilation. The Part 11 text and the 2003 scope and application guidance are read in the eCFR title 21 issue of 31 August 2026 and in that guidance. The IEC 62304 clause numbers, titles and record contents are read in Edition 1.1. The computer software assurance material is read in the FDA guidance issued on 3 February 2026.