Version 3 (modified by stels, 8 years ago) (diff)


tblLAB_RES - Resistance testing

abstract for this table
it is somewhat unclear to me which paragraph from the .doc is mapped to which specific article -> double-check.

Note: This table is tightly linked to tblLAB_RES_LVL_1, tblLAB_RES_LVL_2 and tblLAB_RES_LVL_3.

Resistance should be reported at lowest level of interpretation possible – so if the nucleotide sequence is available this should be reported rather than the list of mutations or resistance scores. However, the resistance test results should be captured if they have been part of the physician’s treatment decisions for the patient.

These four tables are designed to capture several possible formats the clinics and cohorts might have recorded resistance test data in. Once this data is gathered it should like all other tables be quality assessed. For the full nucleotide sequences a short guide on “Sequence Quality Control” can be found here:

fix the following link

Core fields

Note: Fields marked bold form the unique identifier for a record of the table.

  • PATIENT: Code to identify patient (Cohort Patient ID)
  • SAMP_ID: The assigned sample ID
  • SAMPLE_D: Date of the actual sample taken (NOT the test date)
  • SEQ_DT: Date and time when the sequencing was performed
  • LAB: Name of laboratory where the test was performed
  • LIBRARY: Library/algorithm used to identify resistance mutations
  • REFSEQ: Name/identifier of reference HIV strain used to find mutations
  • KIT: Vendor and version/name of the kit used for the test
  • SOFTWARE: Software and version used to determine resistance
  • TESTTYPE: Type of test
  • SUBTYPE: Subtype of HIV-RNA

Additional fields

As shown with the core fields, the SAMP_ID is the link between the 3 levels of data and the test background information table. The sample identifier, however, must be unique for the format to work. This might not always be the case. If needed SAMPLE_D could be used as an additional part of the key, or just SAMPLE_D along with the PATIENT key1.

Some prior assessment of the assigned sample identifiers has to be done in order to avoid duplicates.

In a running database the duplicate issues are easily resolved by adding a unique auto-generated key as the identifier between 3 levels of data and the test background information table SAMP_ID.

Along with the SAMP_ID it might be necessary to store the ID assigned to the sample at both the testing laboratory but also the centres laboratory in order to track the sample. Each of these could also be used as the SAMP_ID value.

1: However this raises the issue about several aliquots from the same day will look like duplicates in the tables.

  • SAMP_LAB: The assigned sample ID at the lab where the resistance test is preformed.
  • SAMP_INT: The assigned sample ID from the centre.