以前有给DM写信的想法，主要是想DM在设计库的时候，就严格按照一些标准来设计字段以及对应的值，这样对我们SP编程来说也相对友好一些。
我一直认为DM和SP是好朋友，从我一开始写的一篇文章就这样认为，双方合作密切，交流甚多（可能是因为以前要帮DM写DVP的缘故）
随着做的项目越来越多，也见识到各种各样因为DM库设计的不合理导致我们SP徒增工作量的，所以就想写一篇文章，讲讲DM在设计库的时候，如何处理能对我们友好一些。虽然你们不一定会改，但是我就是要讲，哈哈。
1：我见过的最离谱的一个就是CRF上的页面和你们发给我们的数据集不对应，比如说你们在CRF上的页面是用“DM”代表人口统计学信息，但是你们发给我们的数据集的名称却是，比如说FM，完全不对应。我不知道你们是用什么系统生成库的，但是第一见到还是大吃一惊，然后无奈接受。
2：第二个令我们大多数SP头痛的一个，就是你们设计的CRF的值，尤其是AE不良事件页面的，不知道哪里来的那么不标准的值，比如不良事件页面的“转归”。
首先我需要让你们明白：就是我们SP递交给监管机构的数据中，比如这个转归，它对应的值只能是下面这几个，并且不可拓展，也就是我们不能再给转归多添加其他的值。
你们有时候值用不标准的，但是条数是一样的（也就是下面的这6条），没关系，我们自己在程序里进行匹配，将你们设计的值转换成标准的值，但是有时候你们设计的值，不仅不是标准的值，关键是条数都不一样，比如什么“恶化”；“缓解”；“稳定”什么的，我都不知道你们是从哪里得到的这些值，关键是我看方案上都没有提到这些。
所以如果你们能一开始就按照这些值设计的话，我们就不用做那么多重复的工作了。
而且如果你们有采用CDASH标准的话，我看上面提到转归的值有采用ICH E2B这个指导原则推荐的值
于是我打开了那个ICH E2B一看，发现值也只是那几个啊，并没有那些乱七八糟的值
好在目前不可拓展的字段就下面这些，主要还是不良事件和人口统计学方面的信息。如果这些字段你们在设计值的时候都能用上面的这些值，那我们SP一定会对你们DM感激涕零的!
3：另一个常见的问题就是既往合并用药页面记录既往病史的编号、不良事件页面记录既往病史和用药编号 这种类型的，有一次我很欣喜的发现你们DM直接给我们把编号对应的既往病史具体XXXX都写出来，而不是只有一个数字，我当时还在窃喜你们给我们省了不少事情，因为我们出listing的时候，需要把具体的既往病史或者用药信息写出来的，而不是仅仅展示一个编号，要不然的话评审的人也不知道这个编号对应什么东西。
但是后来我才发现你们给我们挖了一个大坑了，比如说不良事件页面，你们记录了一个既往用药编号，这个编号假设是2，然后后面紧跟着360感冒胶囊，可是你们没有指定输入值的时候，这个2和360之间要以什么区分开，比如空格或者横杠，直接"2360感冒胶囊"，我们展示的时候其实只要展示这个既往用药是“360感冒胶囊”就可以了,但是这个"2360感冒胶囊"我们怎么拆分啊？
你们说删掉第一个数字就可以了，但是如果有十几个既往用药，编号变成了“13360感冒胶囊”，那我们SP只能跪下求你们不要这样做了，我们自己去既往合并用药页面去拼该受试者的用药信息就好了。
所以如果你们想这样做的话，要么只留一个编号（如果有多个编号的话，一定要指定分隔符，空格或者其他分隔符，否则的话，2 39，你们想说的是编号2,3，9共3个用药信息，我们只会当做2,39共两个用药信息）；如果你们想把具体的用药信息XXXX也写上去，也请加上分隔符（这时候不建议用空格了，要是药品名称里面也有空格就该死了）
4：说到用药信息，在收集既往合并用药信息的时候，你们最好收集上单位，因为在我们SP这边，进行数据验证的时候，给药信息需要对应的单位。而且如果可以的话，单位在录入的时候，格式能有一定限制，不要像下面这样“3 mg/6 片”，“1/3片”，这样我们真的不好处理，要么你就用3mg；要么你就填6片，不要两种单位混合在一起。
但是我感觉这些字段在设计的时候，可能就是以自由文本的形式，所以对这个也不抱多大希望，希望将来的时候，可以在CRC录入的时候，如果单位合并填写，能给个错误提示。
然后也得到了一些读者朋友的反馈，这些就偏项目管理层面了：
5：到了之前共同确定的更新日期了，还需要反复push才会更新数据，这个就是没按照timeline走了，我们在跟申办方确定timeline的时候，就是根据你们DM发送给我们正式数据的那一天算timeline的，如果你们延迟的话，我们SP这边也需要相应地作出调整，所以大家一起遵守timeline，大家都好。
但是跟一些DM读者聊天的时候，得知其实你们能起到的作用也主要是催、催、催，你们也改变不了数据。中心录入数据慢，不负责也会导致这个问题，所以也是为难你们了。
6：反馈的dataissue，很早之前就反馈过了，但是新数据还是有，DM态度很好，但是SP心情很不好，哈哈。这个真是骂也骂不了，如果以前反馈过dataissue的话，解决了的话，最好再看下新的数据有没有一样的问题，我就遇到过同样的问题，新数据，发生在不同的受试者身上。
7：数据收集的质量很差，基本上得sp来qc，提了也不一定改，会觉得反正sp要进行标准化处理，原始数据很乱也没关系。跟上条差不多，数据差可能是CRC录入不认真，其实对你们DM核查起来头疼，对我们SP来说更头疼，按理说清理数据主要是DM的职责的。比如最离谱的是死亡日期在DM和DS里能差一个月，这里的DM和DS是我们SP创建的两个数据集，对应的就是你们死亡页面和研究结束页面的死亡日期不一致，那就要批评你们核查不认真哦。所以大家都负责一些吧。
8：DBD建库的时候细致一点，最后面把“其他，请描述”堆在一起真的很糟心；还有把之前遗漏的变量随手插在一组变量中间的…这个我没太看懂，“其他，请描述”不知道她是不是指的是好几个这样的字段聚在一起，这样我们就真的分不清哪个对应哪个了。但是我目前做过的所有项目还没有这样的情况。
9：还有一个很糟心的就是实验室检查的单位，比如L和I不分，✖️写的X或者x。做项目，每次花比较多的时间就是在跟DM确认单位这些了。但是也跟DM聊过，说这是中心实验室那边录入的，DM这边也只能进行确认和核查。我不知道DM那边能不能每次新数据来了，能看到同一个检测项对应多少种单位，如果可以的话，提前跟医学或者中心确认标准单位是哪个，并提供相应的转换系数。
为什么需要标准单位，我在这里提一下，因为我们SP出table的时候，一般只会对一个检测项采用同一个单位进行总结分析，不会说一个白细胞计数用×10^9/L,又用×10^9/mL，我们只会采用一个单位的，所以说如果这方面能注意一下的话，我代表我们SP对你们DM表示诚挚的感谢！
最后，还是那句话，DM和SP是好朋友，有什么问题可以来和SP一起交流交流，而且我们有SAS在手，可能会解决你们的好多问题。
网友评论