Removing Phantom Samples.

So you’ve imported your AGS data into your software, and everything seemed to go okay. But then you notice you suddenly have more samples listed in your database than you took on-site.

This problem is often caused by your AGS data file having phantom samples.

What is a phantom sample?

AGS data needs to reference samples with the combination of four fields: sample top, sample type, sample reference number and location ID or using a single field for Sample ID.

If the sample information has been incorrectly entered into the laboratory system then a “new” sample is created in the AGS file.  The sample may be very similar to the sample you know about, but it may have a missing reference or a slightly different depth. 

In terms of the computer world, this is a different sample because the four fields, when combined, produce a unique reference and not a sample it already knows about.  Hence, the software will see it as a new sample and import it, then assign the test results to this new phantom sample.

This a nightmare scenario. You have a list of correct samples and a list of incorrect samples that have all the test results referenced to them. If you get into this position, you must somehow relink the test results to the correct samples.

Side note for laboratories.  If your client requests AGS, then ensure that you request AGS from them containing all their sample references.  This means you won’t have to type them into your own system and you won’t produce phantom samples to make your AGS data valid.  Check out our full advice for laboratories producing AGS data

The AGS toolkit has a specific workflow for helping eliminate phantom samples before you import the data into your software solution.  The steps below ensure you never import phantom samples into your database.

  1. Step 1: Export AGS data from your current project and include only the sample referencing and the location ID information.  This generates a tiny file that can be passed to your laboratory without passing any project confidential information from the other data tables
  • Step 2: Replace the SAMP table in the file provided by the laboratory by using the replace table command. 
  • Step 3: Check the resulting AGS file.  You may find it has errors to do with sample orphans. If so, select any one of the error messages and select Orphan Repair from the Ribbon and run the orphan repair routine on each of the tables that have error messages associated to them.

Top tip.  By highlighting by clicking on the error message and selecting orphan repair, the table that requires repairing will be automatically selected and the list of orphans in that table will be displayed at the top of the screen.

  • Step 4: Once you have repaired all of the orphans, use the Export command and create a new AGS file. Make sure you give it a different name so you don’t overwrite the original.  If this file still has errors, the program will report these errors to you and offer to replace your error summary with your new list of errors.  Hopefully they will be less than they were the first go.
  • Step 5: Repeat steps three and four and use any of the other repair tools required to remove the other errors.

The resulting AGS file will have your own sample references attached to the laboratory testing data and can now be safely imported into your database without the worry of adding phantom samples.

Please note, if you are using OpenGround, it may combine all five sample references as the unique reference, it is therefore essential to remove the sample ID from the file if your laboratory has added it and you are not using it within your sample table.  You can do this by using the Remove Sample ID feature.