Date
Attendees
- Dorina Bratfalean
- Christine Fleeman
- Pawan Gupta
- Laura Hall
- Jordan Li
- Erin Muhlbradt
- Debra O’Neill
- Nik Pemble
- philip pochon
- Anna Pron-Zwick
- Deborah Rittenhouse
- Susan Steen
- Audrey Walker
- Lacey Wallace
- Craig M. Zwickl
- Joyce Hernandez
Goals
- Terminology Rules Discussion
Discussion items
Time | Item | Who | Notes | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Some team members are questioning the need for the two rules in red below. If a majority consensus of the lab terminology team agrees that these rules should not exist then the lab terminology teams decision and comments will be taken to the other terminology teams for a vote. Email comments have been entered below the rules. Please read all of the comments and then vote in the table at the end of the discussion items. If you have any additional comments, please use the comment section below. The next row has all of the current rules for the lab terminology team. There are also rules that apply to all terminology teams. Rules for all codelists_2016-04-20.docx | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Email Comments from 26Dec2016 to 28Dec2016: Erin: I don't agree but will go along with team consensus if I am in the minority. My thinking has changed on this over time; when this rule was added originally I didn't have a strong negative opinion against it. My reasons for dissenting are below, which were briefly discussed on Wednesday's lab team call (for those who were not present): 1. I do agree that two distinct concepts within a single codelist cannot have the same submission value. This would break datasets since the novelty of a submission value ensures that reviewers are filtering or sorting on the exact same concept. The presence of a term in the synonym column that happens to be identical to another submission value does not break anything (at least in my mind). Synonyms are there to help in mapping. If there is a chance that two distinct lab tests can be known by the same abbreviation (e.g. ESR is perfectly valid for both Erythrocyte Sedimentation Rate and Estrogen Receptor), it would actually be a GOOD thing if the synonym was present. If a lab test of ESR was submitted by a local lab, the presence of ESR in two places would force the sponsor to make sure they are assigning the appropriate submission value for the test that was actually done. The removal of synonyms may in fact lead to errors in coding in this instance. 2. The creation of 40 character and 8 character TEST and TESTCD values is onerous. The downstream affect of this rule is that we must now work extra hard to ensure that whatever we assign as a TESTCD is not a valid synonym to something else. Additionally we will lose perfectly good /valid synonyms if we adhere to this rule. 3. When assigning submission values for CDISC terms, some codelists have business rules that disallow the most appropriate term to be used. The LBTEST/CD codelists fall into this category since the 8 and 40 character limits are artificial and force the team to use the name of the analyte as the TEST/CD instead of the more appropriate concept of 'Analyte Measurement'. Submission values are aliases for a concept only; the presence of an artificially constructed TESTCD that happens to be the same as a synonym elsewhere doesn't actually matter from a semantic perspective. I will happily go along with what the majority agrees to however I did want to make my dissent known. I don't believe that this actually 'breaks' anything in terms of terminology usage but this rule does add a burden to the team when assigning TEST and TESTCD values. Audrey: I agree with Erin especially for the following “Synonyms are there to help in mapping. If there is a chance that two distinct lab tests can be known by the same abbreviation (e.g. ESR is perfectly valid for both Erythrocyte Sedimentation Rate and Estrogen Receptor), it would actually be a GOOD thing if the synonym was present. If a lab test of ESR was submitted by a local lab, the presence of ESR in two places would force the sponsor to make sure they are assigning the appropriate submission value for the test that was actually done. The removal of synonyms may in fact lead to errors in coding in this instance.” Deb Rittenhouse: I was not at the meeting where this was discussed. My agreement was from the perspective of a user who may be naive and may select the wrong CD based on the first synonym they find. If the team feels there are reasonable times when more than one CD would have same Synonym, then this would need to be called out and not left for the user to come across by chance. Some users who are selecting the proper code are programmers and not experienced lab professionals. I value your critique. What is missing from all code lists is comments to the user about how to use the values. The definition alone is not enough; it does not provide context. Audrey: We search on synonyms all the time based on synonyms that are in our current glossaries. If the standard synonyms are not included in the synonym list it is very, very hard for the data mappers to do this job especially for labs. I think ESR is a great example where our glossaries have the term ESR and if we were just to see this ESR as a synonym for " Estrogen Receptor" our data mappers would have most likely mapped it to " Estrogen Receptor", but it should really have been mapped to "Erythrocyte Sedimentation Rate". If we were to see two entries for with the same synonym we would definitely ask more questions before mapping. I think limiting the synonyms causes a much greater chance of mapping errors. Joyce: I concur with Deb! Having this documented would result in a more consistent conformance to our standard. There are some of us who would like to automate the terminology process by interrogating the synonym list and selecting the best preferred term (test code, test name submission value) via software and not rely on human intervention. In the interest of automation, the more consistently formatted guidance we can provide in terminology the better. Erin, I agree with your point number 1 assuming that what you mean by "submission value" is the column in the terminology spreadsheet which is used to designate the actual TEST or TEST CODE value and not the result. Point 2 and 3 seem to be stating that the rule to limit test codes and test names to 8 and 40 characters respectively are causing challenges when assigning terminology values. This issue is really the result of the way statistician at both pharma and the FDA pivot their analysis tables so that SDTM rows become actual columns. Having a column of 8 characters is easily manageable when representing it in a report. However, a column name that exceeds 40 characters is not easy to manage in a report. Remember that the reason that our test codes across our SDTM Model is limited to 8 characters is to support analytical reporting that pivots those test codes into column names in a report. This was not done in an arbitrary manner but with this use case in mind. If we wish to revisit this decision, all teams (especially ADaM) must be represented. Nik: As a representative of a large Pharma that implements CDISC standards, we do not use controlled terminology off the shelf. We need to assign categories, and link to specimens and methods to create unique test concepts (define as a unique combination of LBTESTCD, LBCAT, LBSPEC and LBMETHOD). In doing this, we need to create our own sponsor dictionary…which we also use to stored sponsor defined test concepts. We actually manage our own list of synonyms also in our dictionary. We also need to manage unit and unit synonyms, conversion factors, standard units and link all of these to the test concepts. Do you know that labs have found so far, 89 different ways to represent the concept 10^3/uL as a raw unit…which we then theoretically need to represent as submission value 10^9/L (although we still do not comply and keep ORRESU mapped to the 10^3/uL (for traceability reason))….but I digress….one day I will climb down of that hobby horse. I would say that CDISC a responsibility to provide terminology that is as easy to “unambiguously” consume as possible, and for that reason, I tend to agree that the best solution would be to either (1) Allow same synonyms for different tests in the same code list. ESR was one…..some others we have come across internally EGFR, TRAP. (2) Or create some additional documentation describing “ambiguous” terms. Or both With more than 150 trials running concurrently, using a mixture of central and local labs, different DM CROs, internal and external data managers (the vast majority of which have less lab data experience than those on this team), I cannot hand on heart say that on some trials, mistakes are not being made. All we do as an organization, is try to provide training, documentation, programming checks and intelligent design to minimize the ambiguity and risk as much as we can. Bernice (response to Erin's email comments): I do understand your concerns, Erin, but I feel that the rule is necessary to avoid confusion. The end users are notifying me when they find this situation. Once the SAS transport file is changed or not used anymore then we will not have the 8 and 40 character limits. Or we might someday use C-code for the test codes. But for now I think that we should keep this rule. Also, this rule applies to all terminology teams and all of the teams did agree to add it. It also completed public review. If the majority of people on the lab team believe that we should revisit this rule, I will then take it to all of the terminology teams for discussion and another vote. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
VOTING - please answer yes or no in the table below, additional comments can be written in the comments section. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Assume that Erythrocyte Sedimentation Rate and Estrogen Receptor do not yet exist. Possible example where the acronyms are included in the synonym column and the testcd submission value does not equal the synonym. But the testcd submission value does include the ESR as part of the testcd. Any search on ESR in the synonym or submission value column would give you the information that you need. The current lab abbreviations for rate is RT and for receptor is RC.
In this example, the need for the exact same acronym appearing in multiple concepts exists. Also, the testcd submission value does not equal the synonym of a different concept. I think that this scenario would solve everybody's concerns. Do you agree? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
2016-11-16: This topic was discussed again in the lab terminology team meeting. Here are the decisions:
The team agreed that they did not want to follow the existing rule below which is for all controlled terminology teams: 4) Within a codelist, if a term is in use as a CDISC submission value, that same term cannot also be a synonym for a different CDISC terminology concept.
The people who agreed to the above new rule # 3 and to remove #4 are: Erin Muhlbradt, Phil Pochon, Anna Pron-Zwick, Sue Steen, Deb Rittenhouse, and Nik Pemble The people who disagreed to the above new rule # 3 and who wanted to keep rule # 4 are: Deb O'Neill and Bernice Yost This information has been sent to Barrie Nelson for comments.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||