Issue: The CDISC lab team received a new term request to add a number of equations for calculating glomerular filtration rates (Cockroft-Gault, MDRD, Schwartz, CKD-EPI, etc.) into the METHOD codelist. The lab team denied the request and told the requester to please put this information into the ANMETH variable, which is currently uncontrolled. The ANMETH variable has been used to as part of lab and other modeling in the past:
- Denied Requests
- Sperm Morphology Assessments: put criterion like WHO Laboratory Manual for the Examination of Human Semen, 5th edition. information into ANMETH
- Scoring Methods in a ?NV dataset here: https://wiki.cdisc.org/x/tIBvAg
- DKD: Glomerular Filtration Rate 2 (They used ANMETH for all the GFR calculation math formula names.)
- CV-Imaging: https://wiki.cdisc.org/display/TACVI/Heart+4 (Used ANMETH for Stroke Volume and Cardiac Output calculations - they put the actual equations in ANMETH because there are no official names for these equations); https://wiki.cdisc.org/display/TACVI/Valves+2 (In this example they used the actual names for the equations because they are commonly known)
- HIV: https://wiki.cdisc.org/x/oxjdAg (the MS dataset, ANMETH is used to house a computer algorithm calculator) - additional uses of ANMETH in TAUGs where the values are computer algorisms, but can't remember the TAUG names at the moment. https://wiki.cdisc.org/x/2VI8Aw (again MS dataset, ANMETH houses the name of an algorithm/criteria published in a paper)
The lab team then got a request from the requester to control the GFR calculations in ANMETH for the lab domain. The team initially agreed that this would be a good idea given that there are a finite number of GFR calculations out there and the calculations are well defined. [2018-11-07: Team agrees that we can control some of these values. Would be easier for reviewers to have a standard name for a formula. We need to consider the inclusion of common, standard formulas only and not necessarily control sponsor-specific formulas] [2018-12-05: After discussion with the lab team; we decide that this needs to go to GGG: Confirm whether these are the appropriate use of ANMETH variable, What is the intended scope of ANMETH (meant to be for summarizing results or for more straightforward calculations to get results themselves ie see C127614, C98735, and C98736). Alternatively, is another variable needed for the purpose of capturing calculation methods and is ANMETH overloaded and/or not scoped correctly?]
https://www.kidney.org/professionals/KDOQI/gfr_calculator
Therefore, the lab team would like GGG input on the following items:
To confirm, is it appropriate to store calculations in the ANMETH variable?
Can values in ANMETH be part of controlled terminology? For this particular use case, the lab team thinks it best to create an LB-specific codelist, otherwise the scope of the codelist could be quite large.
Companies are putting other content into the ANMETH variable. Do we need to be concerned about overloading? (Erin to add examples once received)
Other thoughts:
- ANMETH is not in the LB domain table in SDTMIG3.3. It is only in MS and MO. That being said, it is not in the 'generally not used category' so it should be expected that people are using it.
- ANMETH SDTM3.3 description: Analysis method applied to obtain a summarized result. Analysis method describes the method of secondary processing applied to a complex observation result (e.g. an image or a genetic sequence).
Post-meeting comments from Diane: I was curious how LOINC deals with different formulas. They have method values like “Creatinine-based formula (MDRD)” and “Creatinine-based formula (CKD-EPI)” A similar approach in SDTM might be a variable like “calculation method” that’s used when LBMETHOD = “CALCULATION”. That would seem similar to the approach the sponsors who spoke yesterday use. Whether this information goes into the existing ANMETH or a new variable is a slightly separate question. I think actual formulas should probably be handled in Define, if possible, since they can’t always be represented in a SAS dataset variable value.
Are calculations appropriate for the ANMETH variable in the LB domain?
If calculations are not appropriate for ANMETH, we would need to recommend the use of a NSV (CALMTH) AND a variety of TAUGs would need to be updated.
Discussion/Answer:
Is it possible that there would be an 'analysis method' and a 'calculation method' in the same record? If so, this may mean the variable is overloaded.
Chris C (from the METHOD subteam) reports that they built a mindmap (Erin to email Chris for the link):
Description of ANMETH in SDTM v1.7: Analysis method applied to obtain a summarized result. Analysis method describes the method of secondary processing applied to a complex observation result (e.g., an image or a genetic sequence).
Troy suggests that since ANMETH has already been approved for storing calculations in the LB domain, then perhaps that is the answer...no one on GGG reports heartburn over going forward with this.
GGG approves the use of ANMETH for representing the name of the calculation in the LB domain.
Can/should we control ANMETH variables for those calculations with standard names?
Is this statement true?: "Equations/formulas themselves shouldn't go in there since the SAS dataset might not always be able to support them. The recommendation is that actual formulas should be in the Define files."
GGG says yes.
Discussion/Answer:
GGG agrees: Controlled terminology can be created for named, standard calculations. Calculations without a name would be extensible terminology (with the name decided upon by the sponsor) and not controlled by CDISC. The codelist will be extensible.
The formula/equation would be stored in the define file. It will need to be clarified as to where in Define the formula/equation would be stored.
Statement to be added to SDTM that this variable is not intended to represent the actual calculation string. Also look at variable label; the use of 'analysis' is concerning.
Overview
Content Tools