1.传统行业由于没有医疗器械行业背景，对医疗器械行业标准和法规理解不深刻，运用过去对传统软件开发的经验，来照搬做医疗器械软件开发，可能会在法规和标准的符合性方面存在一些问题；
2.AI是最近几年才开始应用于医疗器械软件，当前业界关于软件开发的指导标准和法规，在面临AI这个新事物时，面临不适用或部分不适用的风险。
一、AI医疗行业GMP现状
当前国内医疗器械软件开发可以参照的标准和法规有7月12日国家药品监督管理总局发布《医疗器械生产质量管理规范附录独立软件》(下文统一简称为：软件GMP)和IEC62034-2015《医疗器械软件软件生存周期过程》标准。由于AI医用独立软件管理类别属于Ⅲ类医疗器械，其软件安全等级为ClassC，GMP对其产品追溯性和变更控制的要求较高。
产品在立项时就需要定义清楚产品需求，可预见的是需求不能轻易变更，另外对需求的实现及验证要遵循严格的流程要求。但是，这恰恰和软件的迭代和敏捷开发方式有相悖的地方。当然，敏捷开发模型是一种成熟的模型，有其优点：
（1）团队在使用敏捷开发模式的情况下，迭代周期和大家的目标比较统一，敏捷开发模型可以提升团队自主管理能力，信息传递比较及时，每天都会同步信息。
其次,敏捷模型更适用于软件类产品的开发控制，不太适用于硬件的开发。原因是软件可以快速交付可用的功能，但是硬件的特性决定了功能的实现具有集成性。只是造出一个其中部件，实现不了具体的功能，不能满足定义的功能需求。并且敏捷的需求是渐进明细，不是一开始就能明确下来，有一个迭代完善的过程（见章节3论述）。在人员这一块，敏捷不支持人员兼职或项目并行，必须是串行。
二、AI医疗行业GMP实践策略
鉴于大多数软件研发项目采用敏捷开发模型，如何让软件敏捷开发模式能满足软件GMP的要求？笔者认为，可以从YY/T0664《医疗器械软件软件生存周期过程》标准中寻求解决之道。那就是深刻理解V模型的项目管理理念，把每个V模型的阶段灵活植入迭代开发的过程，对每个阶段的交付物（各企业可结合自身项目开发流程阶段）进行严格控制，以符合软件GMP的要求。为了便于让多数的读者理解，先简单介绍下V模型。
（1）V模型缩略语及模型：
A.需求的垂直分解；
B.需求的水平验证与确认；
（2）开发过程中融合规则：
A.产品架构分为三层：系统，子系统，单元模块。
B.设计规范及单元测试：对于各个单元模块可以采用敏捷开发，快速的迭代sprint，对于单元模块对应的单元测试规范及单元测试报告（自测）在软件开发程序变动更新1/3以上或者自我定义，就要启动单元模块对应的设计规范，单元测试规范及单元测试报告等DHF文件的升版和发布。
C.集成测试：对于各个单元模块集成的测试，偏重在功能层面的测试；对于集成测试类型分为三种情况：全部测试、部分测试、缺陷测试；对于每次迭代的测试，测试组负责更新并发布测试规范及测试报告。
D.系统测试：对于系统测试主要集中在产品功能、性能、安全等全面的测试；对于每次迭代的测试，测试组负责更新升版发布测试规范及测试报告。
（3）测试过程中融合规则，示例如下：
三、AI医疗行业GMP实践解惑
介绍了V模型，读者会问，这和敏捷开发有什么联系？以需求的迭代和详细设计迭代为例说明：
（1）需求的定义，我们当然可以应用敏捷开发（迭代）的思想。
项目开发前期，一般产品经理可以根据客户需求，形成产品的基本需求，我们可以初步称之为市场需求。然后基于此，需求RS向下分解（RS→FS），形成了最初的需求基线(直观为DHF需求文档，最初版本)。在后续项目推进过程中，项目组成员可以参与进来丰富需求。比如，RA（regulatoryaffair）补充法规和标准的需求，临床专家/医生补充临床需求，服务工程师补充服务需求，研发工程师补充开发需求等等，均可以逐步迭代进来，不断壮大RS需求和FS需求。直至RS→FS完全定义清楚并形成最终的需求基线和最终的版本。
有的企业，在详细设计阶段仍然在进行需求的迭代，笔者认为只要做好相应的变更控制和软件的配置管理（比如：需求基线和软件版本基线控制），也是符合软件GMP和IEC62304要求的。因篇幅所限，笔者不再赘述。
现向大家介绍一种需求的迭代管理模式：
需求的迭代变更管理流程图
职责定义：
需求管理团队至少包括以下职能代表：
系统工程师
项目经理
临床专家/医生
设计质量保证（QA）
研发工程师
法规注册工程师（RA）
B.在需求迭代过程中，需求管理团队成员需要做好需求的评审，确保正确的需求被吸纳，不明确的需求被适时纠正。
（2）详细设计的迭代控制
当需求定义清楚，项目可以推进入下一阶段，详细设计阶段。笔者简单简绍两种迭代过程：
A.软件功能的迭代
软件工程师可以采用敏捷的开发模式，先实现核心模块的功能，然后逐步的扩展功能，直至把DS中所有的要求实现。工程师可把敏捷的方式运用到极致，只要能做好软件版本的迭代和基线控制（可参考IEC62304-章节8软件的配置管理过程），以满足V模型和软件GMP的要求。比如，FS的需求能完全转化为DS（设计规范）并被追溯，DS能追溯到源代码，反之亦然。
B.修复bug，发布补丁的迭代过程
解决的过程可以参照如下的流程，如下图：
（3）软件测试的迭代：
IEC62304中能直接体现迭代的思想的实例就是回归测试（IEC62304–章节5.6），如果软件代码进行了重新编译、软件版本的升级，为了证明原功能仍然正常或未引入新的缺陷，此时进行部分回归或全回归测试就显得非常必要。
综述，只要能真正理解对医疗器械的监管要求——制造商必须确保器械的安全和有效性。在实际开发中，灵活把敏捷开发模式融入V模型中，敏捷模型也能在医疗器械软件开发中焕发生命力，游刃有余。可以这样讲，法规和标准并不反对企业使用敏捷迭代或某一固定开发模型，只要制造商能对其进行合理的控制以满足相应标准和法规的要求，就是适用的方法。