I. Quantitative vs Qualitative - How to specify quantitative vs qualitative results in a dataset when all else is equal?

Q&A from Nik Pemble:

  • Per my understanding of SDTM IG and Controlled terminology, whatever the test is qualitative or quantitative, it should have the same TESTCD. I notice some sponsors don’t want to follow this rule, they put things like e.g. "HCGQUANT"… but it’s wrong right?
    • Nik-Well for the purposes of collection it is okay to call your tests whatever you want, but in SDTM, the data should be compliant to SDTM controlled terminology which means if you collect in non-compliant terminology, you need to tweak the data more to get compliance which in turn diminishes the traceability.. and still at the end of the data, you have to find a compliant way to represent the data

 

  • If the method, category and specimen are the same, how could we distinguish the tests then other than by the unit (and other than by the LOINC code)? By the --SCAT? Would it be ok to have something like LBSCAT=QUANTITATIVE and QUALITATIVE?
    • Nik-I would not use SCAT for this purpose…SCAT should be used as a subcategory of CAT (akin to a panel of grouping related tests together in LB)…..so LBCAT-CHEMISTRY  tests could have subcategory groupings of ELECTROLYTES, RENAL, LIVER, LIPID etc. I have not found a fool proof way to get a natural key for a test concept without using either the standardized unit in the key……or by "misusing" methodology to indicate it is an assay yielding a specific unit type, or by adding a SUPPLB descriptive variable indicating the "scale" in which the output is reported. There has been some discussion about making a new core LB variable available to determine qualitative vs quantitative, but nothing has materialized yet. There is an effort underway to map CDISC concepts to LOINC…and LOINC has two concepts that are valuable in this regard PROPERTY and SCALE. My hope is that CDISC can adopt something very similar into SDTM and then the qualitative/quantitative issue can be dealt with once and for all. FYI, I have heard that some companies are using TSTDTL to store quantitative vs qualitative, but I have heard that this has been frowned upon and was not seen as an appropriate use of TSTDTL (see below)

 

  • I also noticed this in SDTM IG: MITEST TTF1 example. It looks like --TSTDTL could be an appropriate variable to store this kind of quantitative/qualitative information? To be honest I have never seen this --TSTDTL variable anywhere else than in SDTM IG.
    • Nik-TSTDTL is a relatively new concept. It is being used is MI to differentiate different way of "testing" the same test concept…..as above though, not sure it should be used to differentiate qualitative from quantitative outcomes for the same test concept. Or put another way, in the MI example above, TSTDTL describes the different type of testing of the same concept….if you populate qualitative or quantitative, that is describing the result outcome (not the test)

 

Nik II: Yesterday during the call, I indicated that Janssen at this moment are current "abusing" the METHOD variable to solve this qualitative/quantitative issue, although we are looking to change our dictionary to start to utilize official METHOD CT terminology…..so we are looking at other ways to solve this. However, whatever we decide will also likely not satisfy the OPEN CDISC rule unless we use LBCAT which we really do not want to do, since this is just using a different variable (again for a purpose it was not designed for). Anyway, just to help visualize, here the how the two HBSAB tests look in our dictionary. Greyed columns are Janssen only columns in our dictionary for internal use. Unshaded columns make it to SDTM LB and the orange column is used for conversion

CODE

 

 

LBTESTCD

 

 

LBTEST

 

 

LBDESCR

 

 

LBCAT

 

 

LBSCAT

 

 

LBSPEC

 

 

LBMETHOD

 

 

GRPNAM

 

 

LBORRESU

 

 

CNVU

 

 

CNVCFACT

 

 

LBSTRESU

 

 

SICFACT

 

 

TESTTYPE

 

 

LBCOMMENT

 

 

LCCOMMENT

 

 

3812

 

 

HBSAB

 

 

Hepatitis B Virus Surface Antibody

 

 

Hepatitis B Surface Antibody Quantification by Volume

 

 

IMMUNOLOGY

 

 

 

 

 

 

 

 

ASSAY YIELDING BY VOLUME RESULTS

 

 

CDISC

 

 

IU/L

 

 

mU/mL

 

 

1

 

 

IU/L

 

 

1

 

 

CONTINUOUS

 

 

 

 

 

 

 

 

3812

 

 

HBSAB

 

 

Hepatitis B Virus Surface Antibody

 

 

Hepatitis B Surface Antibody Quantification by Volume

 

 

IMMUNOLOGY

 

 

 

 

 

 

 

 

ASSAY YIELDING BY VOLUME RESULTS

 

 

CDISC

 

 

U/L

 

 

mU/mL

 

 

1

 

 

IU/L

 

 

1

 

 

CONTINUOUS

 

 

 

 

 

 

 

 

3812

 

 

HBSAB

 

 

Hepatitis B Virus Surface Antibody

 

 

Hepatitis B Surface Antibody Quantification by Volume

 

 

IMMUNOLOGY

 

 

 

 

 

 

 

 

ASSAY YIELDING BY VOLUME RESULTS

 

 

CDISC

 

 

mIU/mL

 

 

mU/mL

 

 

1

 

 

IU/L

 

 

1

 

 

CONTINUOUS

 

 

 

 

 

 

 

 

3812

 

 

HBSAB

 

 

Hepatitis B Virus Surface Antibody

 

 

Hepatitis B Surface Antibody Quantification by Volume

 

 

IMMUNOLOGY

 

 

 

 

 

 

 

 

ASSAY YIELDING BY VOLUME RESULTS

 

 

CDISC

 

 

mU/mL

 

 

mU/mL

 

 

1

 

 

IU/L

 

 

1

 

 

CONTINUOUS

 

 

 

 

 

 

 

 

3174

 

 

HBSAB

 

 

Hepatitis B Virus Surface Antibody

 

 

Hepatitis B Surface Antibody

 

 

IMMUNOLOGY

 

 

 

 

 

 

 

 

 

 

 

CDISC

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

DISCRETE

 

 

 

 

 

 

 

 

 

Sue's comments:

Below is the note I sent to Craig asking for help to work with the vendor who was demanding that I use a different method for the Hepatitis B Virus Surface Antibody Assays (Quant and Qual) to satisfy the requirements of the OpenCDISC rule.  Our Vendor Lab Corp provided the same methodology for both the Quant and Qual assays, so my suggestion to meeting the OpenCDISC rule was to use the CAT variable rather than the METHOD to distinguish these two tests.  Currently we do not have a clear way to denote the difference between two assays, quant/qual or std/high- or ultra-sensitive, when the same specimen type and methodology is used. Discussion around solutions to meeting the rule ensued at the meeting today and we are interested in determining how sponsor Pharma is currently satisfying the rule as well as providing guidance if possible for the CDISC preferred method to satisfy the rule. Any help on how to proceed with this vendor?  They are not open to my suggestion to use CAT – category to distinguish qualitative from quantitative measurements which would satisfy the OpenCDISC rule (SD0007, FDAC084): Standard Units (--STRESU) must be consistent for all records with same Short Name of Measurement, Test or Examination (--TESTCD), Category (--CAT), Specimen Type (--SPEC) and Method of Test or Examination (–METHOD). Have you been likewise bullied by others to co-opt the organizational efforts of the control terminology group to satisfy their algorithmic programs (Pinnacle 21 Validator) or their certain interpretation of the OpenCDISC requirements? Vendor is unhappy with the mapping provided for our BMS two tests for detection of Hepatitis B surface antibody, Qualitative and Quantitative.  Both currently show the same control terminology for:

LBTEST: HBSAB           

LBTESTCD: Hepatitis B Virus Surface Antibody

METHOD: CHEMILUMINESCENT IMMUNOASSAY

SPECIMEN: SERUM

They would like me to create extensible methodology to denote the difference between the two assays.  I’ve suggested using CAT – category since this is not a controlled variable, but they are not happy with that suggestion.

 

Craig's comments:

I’m glad this came up during our lab meeting.  I’ve been wrestling with a response, which, at best, would only be a personal opinion.  Although there is not a consensus yet, I think this kind of information is part of the test.  Consequently, it could become part of the test name, could go into the test detail variable, or could go into a non-standard variable until a variable is created for it (e.g. a ‘test mode’).  There is also an argument for considering it to be a method qualifier where it could go into something like ‘assay mode’, or it could be a method category or subcategory.  I don’t think these will prove to be the best solutions though, because they violate the definitions of category and subcategory (i.e. it would violate the hierarchical nature of category > subcategory > method by allowing a one-to-many relationship in the reverse direction of the hierarchy). I also lean toward not using the test category because it ‘eats’ the category variable, which I think is more important for other kinds of information (e.g. hematology, clinical chemistry, urinalysis, differential, tumor characteristics, etc.). At the moment, I think it might be most useful to consider it to be a test detail in order to avoid needing to create additional controlled terminology for test name for each test that can be qualitative, semi-quantitative, quantitative, confirmatory, etc.  There might be a good reason not to use test detail, that I’m failing to understand or appreciate.  Ultimately, I think this info may need to go into an as yet to be defined permissible variable.  Maybe we can get this in front of the Method team to think about too.

Thanks Nik.  The table is helpful and further illustrates why we might want to stay away from using LBCAT to solve the qualitative/quantitative issue.  I like your shaded TESTTYPE information.  Do you know whether it makes its way into the define.xml file at the test level?

Nik Response:

To answer that question…..No, testtype is just a Janssen variable we use in our dictionary only, to manage (determine) the type of outcome we expect from a test concept….it never makes it into SDTM or define.xml. Most continuous measures have a unit (but some do not), discrete tests by definition have no unit in our dictionary. Specific concepts that do have units (are continuous) and usually have numeric results, can occasionally within a trial, take a character value (such as TNTC)…but that is rare.

 

 

 

 

  • No labels