谈谈临床研究文件的撰写、审核与批准流程

　　研究文件撰写是项目中的日常工作之一，来自SOP和实践的要求，导致文件的种类和数量越来越多，参与的职能部门和人员也越来越多。虽然大多数公司都有GDP（Good Document Practice），也有文件审核批准的SOP/WI，但和其他高大上的文件一样，这些文件对实践的指导作用有限。

　　有鉴于此，秉承一贯的务实作风，本文将从实际操作的层面分享研究文件、审核与批准流程。争取让所有的研究文件撰写过程都条理清晰、逻辑有序，做到有成功之喜悦，无案牍之劳形。但也同时说明，如果公司有类似的指南（大概率不会到细致到这个程度），还是以公司指南为主。

　　研究文件的撰写首先要分清RACI，具体如下：

　　理清了责任，还要认清楚人。撰写人通常比较容易确定，部门分工职责描述说的很清楚。弄清其他几个ACI也不是太难的问题，可以根据经验、可以参考SOP、可以询问批准人（模板中的签字人）、也可以根据文件内容来确定，如果实在不知道，那就在发出初稿的时候尽量缩小范围，不要抄送太多人。

　　认识到上面这个程度还不够，知人知面更要知心。RACI里面，R就不用说了，A也好不到哪里去，干活的和承担责任的，deliverable就是找你们二位要。C通常是术业有专攻的人，和你想的一样，专业越强脾气越大，C虽然不承担责任，但却要在局部贡献主要意见，这是一个悖论。I是听报告的，无论在哪个公司，听报告的是什么角色，自己体会。

　　R（撰写人）在撰写初稿时的注意事项：

　　1、确定整体时限，并根据估计可能修改的轮次分解一个时间表，何时有初稿，何时需要反馈...；
　　2、确定使用的SOP和模板；
　　3、完成相应的培训再动手，不仅是为了走流程，必须了解相应的背景和内容；
　　4、获得相应的支持文件或材料，正式的和/或非正式的；
　　5、了解可能的需求和要求：内容需求、时间要求、特殊要求…；
　　6、撰写时，除技术性文字外，还要注意字体、格式、语句通顺、用词准确、缩写的统一…；
　　7、撰写完成后草稿命名为0.1版，注明版本日期。

　　好的开始是成功的一半，初稿写好了，再检查一遍，务必保证版面整洁统一，思想端正不端正不容易看出来，态度的端正程度如皓月当空。

　　R（撰写人）在发出初稿时的注意事项：

　　1、发邮件时直接发送（to）所有的A和C，抄送（cc）所有的I；
　　2、明确需要回复的时间，注意留出一些余量（除非必要，不使用收条或者后续跟进功能）；
　　3、告知接收人可以转发给其他有必要作为A/C的人，下次你将直接发送给他们；
　　4、明确告知接收人，不要更改文件的版本号和日期；
　　5、明确告知接收人，在修订模式下修改（可以在发出时将修订点击为选中状态），除了简单的文字修改或者可以自证的修改（例如说明原理的专业性很强的修改），尽量添加批注说明修改原因。

　　A（批准人）/C（咨询人）在给出文件修改意见时需要注意的事项：

　　1、按时限回复，不要成为限制文件定稿的瓶颈；
　　2、在修订模式下来加入修改；
　　3、以批注的形式说明修改的理由或原因，批注要言简意赅，体现专业性的同时也要考虑其他人的理解能力，简单的文字修改或者可以自证的修改，不需要加批注；
　　4、修改完成后，在文件名加一个姓名缩写的后缀，作为识别符，日期可有可无，除非你想改两次；
　　5、不要更改版本号和日期；
　　6、在添加批注时，注意框中显示的是不是本人的名字，通常是电脑或word的注册名，如果不一致，要修改一下或在批注时加上姓名。

　　R（撰写人）在根据反馈意见更新文件时的注意事项：

　　1、收到所有的反馈后再开始更新，将所有的反馈合并到一个文件中，合并修订方法参见文末的图，“在看”的上方，顺手点一下在看更好；
　　2、检查所有的修改和批注，不要删除任何批注；
　　3、接受认为合理的修改，并在批注上回复“已接受”，并点击批注下方的解决，关闭该问题；
　　4、对于不能接受的修改，不要选择“拒绝”，在批注下方回复不能接受的理由，可将批注内容和回复摘到邮件正文，用于组织会议讨论或加快修改进度；
　　5、修改完成后，生成一份只有未解决问题的更新稿（包括修改建议内容和批注及回复）；
　　6、撰写人可以将此稿定为0.2版，并注明版本日期；
　　7、如果文件中需要修改的内容很多，涉及的人员很多，时间也不紧急，可以考虑发出0.2版继续征求意见，重复上述1-6的动作，直至定稿。
　　8、如果文件需要修改的内容不多或时间紧迫，建议召集一个会议，一次性讨论所有问题，并在会议上定稿。

　　文件定稿之后没有什么特殊，签字生效，注意按GDP要求，签名必须有日期。

　　上述关于“研究文件的撰写、审核与批准流程”的内容就介绍完了，但在实践过程中仍然收到或者听到各种各样关于文件的咨询和抱怨，特别是关于文件审核过程中的RACI，因此，有必要对此部分进行补充，请结合前文中的RACI部分：

　　1、通常来说，文件的开发是一项team work的工作，除文件的owner外，还需要有最终责任人（签字放行文件的人）和不同职能部门的参与；
　　2、文件的大部分内容都会来自模板或根据模板指导来开发，Owner和责任人会负责大部分内容的开发，因此，确定的SOP，选择模板很重要；
　　3、职能部门是否参与取决于：1）模板要求；2）项目中确实有交界性的工作需要职能部门来支持，有必要邀请参与文件的开发；
　　4、所有参与文件开发的人员都需要了解自己在RACI中属于哪一方，避免由于定位不清导致的喧宾夺主；
　　5、文件的Owner和责任人应在发出文件审核请求时，应至少明确相应职能需要审核的内容与反馈时间，必要时拆分相关内容发送；同时在收到反馈时，对所有的comments都进行审核，确认是否可以接受；
　　6、职能部门在收到待审核文件时，除按日期回复外，无论发件人是否提醒，应仅审核与角色有关的内容（即与所在职能有关的部分），不应公开对其他职能负责的内容提出意见或做出修订，无论是否为出于好意，自觉更加专业或者文本具有明显错误等任何理由。
　　7、对于确实无法压抑需要反馈的情形，应以非公开的点对点沟通为主，避免增加团队的沟通负担。
　　8、任何沟通都要注意方式方法，申办者至大上级领导至大也要有document才行。

　　举个例子：从事临床运营多年的人员转型做DM，遇到临床监查计划的协作审核请求，无论如何技痒难耐，也不应对与DM无关的内容公开发表意见。
　　作者：CT-PM&CO工作组