终于把某个项目交掉了,但过段时间后,就会来很多comments,然后programmer就对着这些要求来改自己的程序以及相关的文件,这里说一点点TFLs comments。
1 某张table或listing中header改变,或者某一行的label改变,但值是不变的。比如一段语句中首字母大写呀,把start date/day变成date/day of start,连接符前后要加空格等等,反正花样多多,人家说怎么改,就怎么改。其实大部分时候,这种更新是有依据有意义和有必要的。它能让这些TFLs更标准化,更好理解,更符合这个study(protocol, CRF..),这在程序里只需要做一些wording工作就行。所以,熟悉和了解一些general的comments是很必要的。
2 对于增加某行或某列,那就要再写code。如果这个新加的变量更合适放在ADaM中的话,那这一段程序可以放在ADaM中写。另外,对于ADaM data set,因为是要求ready to analysis,窃以为,把在TFLs中的programming放到ADaM中更好些,具体原因如下:
a, 除了一些ADaM model要求的基础变量之外,ADaM数据集是可以按user-defined的要求生成一些变量的,包括命名,computation rules。当然了,也要follow ADaM IG里面的general standard。
b, ADaM数据集本来是为TFLs服务的,它的生成是为了更方便的出TFLs。试想,现在要连接start date, start day, end date, end day, duration形成一个变量在listing输出,也就是说把5个变量合成一个,再者,这个信息在3个listing中都要出现。如果都在listing中programming的话,那是不是要把这段程序写3遍。更多时候,要按某种format科学合理的呈现data,那这程序还挺长的,这不就增加了工作量嘛。如果在以后要对这列进行算法更新,这就挺麻烦的,而放在ADaM中,则只用update一次,而且也好找好改。
c. Listing到底要不要写完整的程序qc且不论。如果original and validation都在TFLs中programming的话,因为用的变量属性不一样,程序中的处理也不一样,这就增加compare的时间了。这一个变量的qc,放在ADaM中处理,完了之后,TFLs用相同的变量,也就省事得多。
所以,我觉得经的经过SDTM标准化数据之后,ADaM是个很重要的步骤,做得好了,承上启下,对整个study的高效,快速,准确的完成意义重大。个人意见而已,仅供学习讨论。
3 下面是data display方面。比如像CM这种经常date不是很清楚的,那在listing中如何呈现呢?。首先,listing中呈现的都是"raw data"。在ADaM中,像--STDTC,--ENDTC,--DTC,这都是直接从SDTM中拿过来的,而SDTM也是从raw data里拿的。那在listing应该display这样的变量。如果是2013-06,或者2000,这种日期时间数据不完整的,这就是"raw data"。而ASTDT是经过某种rule算出来的,更多的是分析所用。如果某一条CM的记录只有start date,没有end date,因而也没有duration,那要像上面要求怎么连呢?有的要求不管后面有没有数据,也要用类似"/"来标注,以说明这个记录没有end date,比如2013-06/,也有表示成2013-06,把后面放空。再比如像某列要显示yes or no,如果是yes,再在后面写原因。可以显示成Yes/Reasons 或者No,如果结果为yes但原因缺失,仍然显示成"Yes/"。我个人prefer后者,好像看起来有点多余,但却很清晰地表达了某个信息。
4 有些title/footnote,analysis population 需要更新。在title中,可能需要加入选定的语句来更加明确地表达出这个表的内容。footnote可能需要加入更详细一点的footnote来解释TFLs中用到的省略词语,比如severe AE中,1 = Results in Death,Baseline is defined the last non-missing record before first dose. Study day is defined as the day relative to the first dose等等。表中的[a], [b]...要和下面的footnote一一对应。同一个footnote可能存在很多个TFLs中。比如listing中要出现的subject/age/sex/race,在footnote中就要说明这里面的值代表什么意思,比如F = Female, W = White之类。
5 针对某些table的update,也许改动比较大了。比如开始给出的shell里面,只要summarize某个SOC/PT之下的subjects and percent,而实际上一般都是SOC一个汇总,下面每一条PT也汇总,如果这个PT下面再有Severe Grade或者Relationship to study drug之类的分组,如果可以的话,可以在程序里一层一层地把它都求出来,要哪些内容再输出哪些内容。因为有些draft mock-up没有finalized,后面可以需要加入更多的内容,还不如刚开始写程序的时候,就考虑得深远一点。
6 像某个table后面,一般都有某个listing与之对应,这样可以便于cross check。比如在table中算得的年龄最小值为18,而在后面的listing中,从一条条的patient看过去,年龄都是大于20的。那这就前后矛盾了。前面的disposition表显示safety population(如果这个flag是定义为服用过试验用药的人)只有10个人,但其他表的header中的大N总和并不等于10,这就有问题。原因可能是这个人dose date不为空,但arm=not assigned,也就是data中,这个人有用药记录,但没有给他assignment treatment。像这种data issue,有的时候是data本身的issue,另外就是程序中可能出现了错误。
哆嗦了这么多,不知道听烦了没有,这并不是一个系统性的总结,只是想到哪里就说到哪里。如果有时间,我想以后再专门就自己想到的一些general rules写出来,这样比较有完整和系统些,也好和大家参与讨论。
|