计算机化系统验证CSV相关问题

kujind

计算机化系统验证中风险评估，可以进行需求风险评估，或者进行功能风险评估，那么作为GAMP 5   1，3，4，5 分类来讲，哪些是进行需求风险评估（针对URS），哪些是进行功能风险评估（针对FS），这个大家有啥建议或参考吗？另外，作为计算机化系统风险评估来讲，是不是一定要等出具了功能规范FS，才能进行风险评估呢？

kujind

可以参见GAMP 5中描述

小新地球

已确定该系统为GXP关键系统后需要进行验证，针对验证需要做RA，针对csv风险评估分为两部分：1、初步风险评估2、功能性风险评估。初步风险评估包括初始urs、GXP评估和分类、供应商评估（看需求）；功能性风险评估包括先确认关键部件/系统再对其进行风险评估，确认验证的范围

kujind

小新地球 发表于 2022-7-27 14:10
已确定该系统为GXP关键系统后需要进行验证，针对验证需要做RA，针对csv风险评估分为两部分：1、初步风险评 ...

这块的话，你的意思是，所有关键的计算机化系统都是进行功能风险评估吗，那就是要先完成FS再进行FRA吗？不需要根据具体的GAMP 5系统分类吗

wudizzx

最好是有FS，再进行FRA。因为FS是说明“系统如何实现你需求”的文档，实现方式可能不在一开始的需求里，那么在FS中列明后，可能会带来新的风险。

至于GAMP5分类，当个参考就行了。如果本身需求里就把系统要如何实现需求的部分和具体参数写明白，在需求文档出来后做一次风险也够啊。

kujind

wudizzx 发表于 2022-7-27 14:39
最好是有FS，再进行FRA。因为FS是说明“系统如何实现你需求”的文档，实现方式可能不在一开始的需求里，那 ...

如果不管GAMP5分类，就是3.4.5类计算机化系统都是要列出FS功能规范？，还是说更为细化的，只有4.5类，可配置或定制化软件系统才需要定义这个FS？ 如果这个系统本身比较简单，是不可配置的软件，那我针对URS进行了风险评估，那还需要在RA之前出具FS吗？

wudizzx

看你想怎么规定了，对于4类可配置和5类开发类系统，FS里的内容是必要的，GAMP 5也是那么建议的。

当然你在自己SOP里写这是可选的，也是可以的。或者说，评估为3类的系统也要写出FS，SOP里规定好了，就按这个执行。

关键是，FS的作用是什么，以及为什么说要基于FS做功能性风险评估，这个我记得在FS的那个章节里应该是有说明的。

kujind

wudizzx 发表于 2022-7-27 15:09
看你想怎么规定了，对于4类可配置和5类开发类系统，FS里的内容是必要的，GAMP 5也是那么建议的。

当然你 ...

4，5类软件，有FS进行FRA，这个情况下，先起草FS再进行FRA，没有问题，但是如果3类软件呢，sop中定义可以不需要FS，但是具体验证项目VP中定义了交付物需要起草FS，这个时候我也仅仅针对URS进行的RA，这个情况下，需要等FS起草完毕后，再进行RA吗，RA与FS还有必然的联系吗

wudizzx

kujind 发表于 2022-7-27 16:29
4，5类软件，有FS进行FRA，这个情况下，先起草FS再进行FRA，没有问题，但是如果3类软件呢，sop中定义可以 ...

那这个问题就变成了：为什么VP里要规定死了一定要有FS。至少VP里你们可以根据软件类型去规定【必要】的交付物。有些软件就算是3类，使用也可能是很复杂，需要有FS来支持的（虽然我一时半会想不到好的实际例子。。）

kujind

wudizzx 发表于 2022-7-27 17:30
那这个问题就变成了：为什么VP里要规定死了一定要有FS。至少VP里你们可以根据软件类型去规定【必要】的交 ...

是的，有些3类系统，也定义了需要FS，这种情况下，是不是意味着，需要对FS进行FRA，还是说可以只针对URS进行RA，此时FS与RA之间有必然联系吗，简言之,如果我的风险评估不是针对的FS（针对URS），是否还需要在FS起草定稿后才能进行RA，RA与FS是否有依赖关系

wudizzx

kujind 发表于 2022-7-28 09:35
是的，有些3类系统，也定义了需要FS，这种情况下，是不是意味着，需要对FS进行FRA，还是说可以只针对URS ...

既然你们规定3类也要写FS，我不清楚你们具体会往里面写什么。。。这个问题你可以这么想：在没有FS的前提下，仅对URS的内容去作风险评估，会不会有遗漏的内容？以及在获得FS内容后再进行风险评估，会不会有产生新的风险。

风险评估本质是在系统正式运行前通过识别、控制的方式来减少/消除风险。它和文件本身没有强逻辑关联。我们说要在URS后进行general的评估，是因为这时候具体的实施细节没有定，只能去作整体评估；而有FS后，明确了具体的实现方式，我们有了更详细的描述，有了具体的功能描述，有了准确详细的业务流程，那么这可能带来新的风险，需要进一步评估。也会有种情况，FS中的内容也可以用来解决URS阶段所发现的风险。

回到3类，如果其FS本身能提供进一步的信息，并可能会带来新的风险，那么建议对此进行风险评估，反之则不用。当然，考虑到RA文档的编写和审核这种流程性质的事情，你等到FS出来后再统一作RA也不是不可以嘛，只要后面的验证活动能够去充分证明所识别的风险是能被消除/降低的。

kujind

wudizzx 发表于 2022-7-28 10:25
既然你们规定3类也要写FS，我不清楚你们具体会往里面写什么。。。这个问题你可以这么想：在没有FS的前提 ...

学习了

kujind

wudizzx 发表于 2022-7-28 10:25
既然你们规定3类也要写FS，我不清楚你们具体会往里面写什么。。。这个问题你可以这么想：在没有FS的前提 ...

不好意思，想追问一下，FS之后做这个RA，这个逻辑是通的，那么CS/DS呢，是放在RA之前还是可以放在RA之后呢？

wudizzx

kujind 发表于 2022-8-9 13:36
不好意思，想追问一下，FS之后做这个RA，这个逻辑是通的，那么CS/DS呢，是放在RA之前还是可以放在RA之后 ...

先明确下定义和用途，两个都是specification，字面理解是用于指导系统后续的开发（Design）和配置（Configuration)。
CS是configuration Spec，是把关键的、和需求相关的系统配置项记录在此文件中，测试前要基于这份文件去做实际的配置，然后测试确认其配置是准确的、且能满足需求的；
DS是Design Spec，又不是5类要开发。。。做那么多干啥。。我碰到过的一个DS做法是比对了FS和UR，确认所有的UR都有对应的FS条目描述。

这两个Spec过程中的风险，我的理解是应该在RA过程中就涵盖了。需求是通过开发coding实现，还是通过系统本身的配置config实现，在FS阶段应该要说清楚了。

但是有个概念，RA这个东西不是就通过这1~2次的文件去完成的，它也是贯穿整个系统生命周期。说UR和FS后做RA，只不过是两个最关键、相对最容易发现、控制风险的时间点，把它通过纸质文档记录下。不要刻意纠结啥阶段要有RA，每个阶段都可以有RA。

有段时间没温习GAMP了。。可能有些理解是错的，仅供参考。论坛里第二版也出来了，可以以里面的概念为主，我还没来得及看。。。

kujind

wudizzx 发表于 2022-8-10 16:02
先明确下定义和用途，两个都是specification，字面理解是用于指导系统后续的开发（Design）和配置（Confi ...

是的，有句话非常赞同，ra是贯穿整个生命周期的，但是从验证流程角度来讲，逻辑角度来讲，非要有个文件交付顺序的话，那fs是需要在ra之前的，至于ds或者cs，可以在ra之前也可以在ra之后

kujind

wudizzx 发表于 2022-8-10 16:02
先明确下定义和用途，两个都是specification，字面理解是用于指导系统后续的开发（Design）和配置（Confi ...

你好，请问有图片中的这些资料吗或者哪里可以找到这些中文或者中英文版的资料，谢谢。

wudizzx

这个论坛里有部分的ISPE的指南，或者你在博普智库里搜搜。

shengyan766

学习了！GAMP5分类是验证的指导啊

kujind

wudizzx 发表于 2022-8-10 16:02
先明确下定义和用途，两个都是specification，字面理解是用于指导系统后续的开发（Design）和配置（Confi ...

基于这个概念，FS之后进行FRA，那后面FS如果进行升版呢，FRA是不是也要跟着进行升版，或者这样理解，如果此时FS升版，里面涉及的主要功能并没有发生重大变化，所对应的风险并没有发生改变，此时是不是FRA就不需要进行升版？