Data Integrity Matters | Limiting Access to Tools That Could Be Used to Manipulate Data (Part 2)

Heather Longden

Reading Time: 6 minutes

Test or system readiness injections?

Useful tools can be applied to achieve accurate and consistent results, but also, in the wrong hands or if someone has the intent, they might be used to falsify data. How can you tell the difference?

Peak integration decisions may be used by unscrupulous staff to fraudulently manipulate a failing result into a passing specification. I will examine this in a subsequent blog since it’s a very detailed topic.

Failure to follow a sample preparation SOP (Standard Operating Procedure), under-reporting sample weights, or failing to make up solutions to the mark in volumetric flasks could also create deliberately falsified results and these would be significantly harder to investigate than manipulation of the integration parameters in a Chromatography Data System (CDS) designed to meet electronic record regulations.

In an earlier post I wrote on limiting access to tools, I addressed how data integrity controls have evolved and new risks that regulated laboratories with modern tools now face. Let’s take a look at another thorny subject: injections made to determine if your chromatography system is ready to run your samples in a regulated environment.

Procedures are in place to guide the analyst

Experienced scientists also know that chromatographic analysis can be affected by temperature, humidity, and even column history as well as mobile phase preparation, such that one day’s analysis often varies slightly from the previous day’s run. Systems may also simply require time for the mobile and stationary phases to become chemically equilibrated or for the entire separation pathway to become physically equilibrated, especially if the method is susceptible to temperature changes.

Therefore it is essential that procedures are in place to guide the analyst in a series of steps to ensure that the system is ready to begin analyzing samples, without the fear that the system suitability tests would immediately fail.

Can analysts use trial injections or System Readiness checks?

There is a wildfire of concern about the use of Trial Injections in regulated chromatography labs. This often comes from reading regulatory observations, without the significant detail about the SOPs in use. It is not the actual use of System Readiness / Test injections, but auditors and regulators have very valid concerns that unscrupulous staff may use these legitimate activities to mask egregious actions designed to avoid failing or questionable results.

The legitimate use of System Readiness checks can be addressed with some procedural controls:

  • The SOP should describe when and how system readiness injections are performed;
  • It should also be clear exactly what sample will be used for system readiness injections;
  • The data created by those injections should be kept securely.

Technical controls – which simply prevent a user from performing single injections – will have no effect. Any user wishing to “preview” a sample test will simply submit a short sequence; one or two injections or vials, enough to bypass any kind of technical control or mask it from a monitoring view.

Examples of what solution to use for test injections can be found in the FDA Draft Data Integrity Guidance, Question 13. This answer includes: “system suitability tests should include replicate injections of a standard preparation or other standard solutions to determine if requirements for precision are satisfied.. ..If an actual sample is to be used for system suitability testing, it should be a properly characterized secondary standard”

Given these instructions from the agency, plus additional information on appropriate procedures and documentation, it validates that System Readiness Checks ARE permitted by the FDA, contrary to popular myths.

The underlying concern has been well described in FDA and other regulatory observations and is also discussed in the FDA Draft Guidance: “We would consider it a violative practice to use an actual sample in test, prep, or equilibration runs as a means of disguising testing into compliance… .”

As mentioned before, multiple laboratories, when asked about unreported chromatographic sample results that are found in the CDS, (i.e., noted in injection logs or discovered in secret or hard-to-find folders, or even separate PCs or CDS solutions) have tried to excuse those unofficial sample analyses as “test injections”. (See references 1, 2, 3.) This caused a wave of worries about both real test injections designed to test the readiness of the LC or GC system, and even questioned the legitimacy of ANY single injection or injection that was not part of a Sample Set or sequence (even though you are more likely to do unofficial testing in a sequence anyhow).

Are System Readiness injections unofficial sample preliminary tests?

The draft FDA guidance clearly allows for System Readiness or equilibration injections but there is a still a concern: How can you be sure that those injections are not unofficial pretesting of samples?

Realistically, I can think of no fail-safe way to do that. Anecdotal stories abound, indicating that regulators believe that you can “overlay the test injections with real samples and you would see if the test injections were identical to a sample”. However, due to the nature of chromatography, two injections of the exact same solution are rarely identical.

Only if the solutions used for test injections were significantly unlike a sample would this investigation yield any results. It is common that a standard or maybe a synthetic sample mix is used for system readiness checks. Labs might use a vendor’s QC/Check solution, which may be unrelated to the samples of interest. But a test solution so dissimilar to a sample gives you less confidence that the system is actually ready and capable of performing a specific method. The closer your test solution is to the sample, the better they will indicate that a quality separation is possible.

Two other solutions have been suggested:

  • In the realm of bioanalysis, a certain group suggested leveraging a “pooled” sample for system readiness checking, so as not to preview any real sample results. But how to then prove that the injection really was the pooled sample would be extremely difficult.
  • Another suggestion was to use an expired or old sample, but spiked with one unique component that does not exist in a true sample. Ingenious, but a major extra step on the workflow simply to provide evidence of your innocence.

Understanding why certain regulators have concerns about trial injections, test injections, etc., will help you to define a clear procedure detailing exactly how test injections should be carried out, how they should be named, and what solutions should be prepared to perform system readiness checking, as well as any regular or periodic review that this procedure is being followed. Clearly, hiding or deleting these injections would be inviting regulatory curiosity. But equally, the suggestion that these test injections need to form part of the data package is equally onerous and has no scientific basis.

Some laboratories now include system readiness injections at the beginning of every sequence, however, the number of injections and intermediary actions to prepare an HPLC will vary day by day. You may need to simply wait longer for equilibration, or else mobile phases or temperature setting may need to be adjusted, based on the system readiness injection.

In this case, it makes no sense to perform these as part of the sample sequence. It may be more scientific to leave these as single injections but have their use clearly defined, as well as proceduralizing suggested troubleshooting activities (and potentially documenting these) to implement if system readiness injections indicate that the systems is… “not yet ready” to accurately perform your analysis.

 

In my next Data Integrity Matters blog, I will discuss the regulatory concerns about auto-integration, manual reintegration “by method”, and true manual integration as they may all be required actions needed to ensure accurate and reproducible peak integration.


Read more articles in Heather Longden’s blog series, Data Integrity Matters.

References: