随着最近几年很多传统互联网企业开始积极布局医疗市场，国内涌现不少ai+医疗公司，也积极参与到医疗器械这个朝阳产业中。
但现实总是机遇和挑战并存，从传统企业直接跨入医疗器械行业，总会带来水土不服的地方。笔者大体总结原因如下：
1.传统行业由于没有医疗器械行业背景，对医疗器械行业标准和法规理解不深刻，运用过去对传统软件开发的经验，来照搬做医疗器械软件开发，可能会在法规和标准的符合性方面存在一些问题；
2.ai是最近几年才开始应用于医疗器械软件，当前业界关于软件开发的指导标准和法规，在面临ai这个新事物时，面临不适用或部分不适用的风险。
简言之，当前没有金标准或成熟标准供大家参照学习。如何在应用ai技术的同时，能确保器械的安全和有效，是整个行业甚至包括监管机构的待解难题。困难再多，企业也要弄潮而上。如何用传统的开发模式来适应医疗行业的新要求，是很多企业的困惑。笔者在阅读动脉网前期的一篇文章《人工智能医疗器械创新合作平台会议在博鳌召开，一文读懂人工智能医疗器械审评审批常见问题》之后，也想以传统敏捷软件开发模式来适应医疗器械独立软件的开发为例，分享些实战经验。
一、ai医疗行业gmp现状
当前国内医疗器械软件开发可以参照的标准和法规有7月12日国家药品监督管理总局发布《医疗器械生产质量管理规范附录独立软件》(下文统一简称为：软件gmp)和iec62034-2015《医疗器械软件 软件生存周期过程》标准。由于ai医用独立软件管理类别属于ⅲ类医疗器械，其软件安全等级为class c，gmp对其产品追溯性和变更控制的要求较高。
产品在立项时就需要定义清楚产品需求，可预见的是需求不能轻易变更，另外对需求的实现及验证要遵循严格的流程要求。但是，这恰恰和软件的迭代和敏捷开发方式有相悖的地方。当然，敏捷开发模型是一种成熟的模型，有其优点：
（1）团队在使用敏捷开发模式的情况下，迭代周期和大家的目标比较统一，敏捷开发模型可以提升团队自主管理能力，信息传递比较及时，每天都会同步信息。
（2）敏捷开发模型里面，产品按照每个迭代去验收，每个迭代工作成果都需要经过演示，如果在演示中意见不同，可以及时暴露并修正，提测频率较高，减少开发和测试的等待时间。敏捷开发模型对项目进度只有零或一百分，着重团队承诺，不强调个人能力，更关注整个团队的绩效，重视对外部承诺和内部承诺等等。
（3）敏捷中的风险管理关注于项目风险如进度、版本质量、人员风险等等。
（4）敏捷中关注迭代过程的持续改进，例如需求评审不充分，沟通信息不同步。
简言之, 敏捷更关注项目的生命周期。而软件gmp的要求更关注于产品生命周期，从产品立项到产品退市，着力于整个产品生命周期的管控。
其次,敏捷模型更适用于软件类产品的开发控制，不太适用于硬件的开发。原因是软件可以快速交付可用的功能，但是硬件的特性决定了功能的实现具有集成性。只是造出一个其中部件，实现不了具体的功能，不能满足定义的功能需求。并且敏捷的需求是渐进明细，不是一开始就能明确下来，有一个迭代完善的过程（见章节3论述）。在人员这一块，敏捷不支持人员兼职或项目并行，必须是串行。
总之，按照gmp的要求，制造商需关注产品的全生命周期，关注于研发过程质量保证，采购质量管理，生产质量控制，销售和售后及上市后的质量跟踪保证等活动。
我们也可以从风险控制角度来看传统敏捷软件开发模式和gmp要求的差异：在敏捷中的风险管理则关注于项目风险如进度，版本质量，人员风险等等，而在gmp中风险管理更多关注产品本身的风险，其风险管理贯穿于软件的整个生命周期。
二、ai医疗行业gmp实践策略
鉴于大多数软件研发项目采用敏捷开发模型，如何让软件敏捷开发模式能满足软件gmp的要求？笔者认为，可以从yy/t 0664《医疗器械软件 软件生存周期过程》标准中寻求解决之道。那就是深刻理解v模型的项目管理理念，把每个v模型的阶段灵活植入迭代开发的过程，对每个阶段的交付物（各企业可结合自身项目开发流程阶段）进行严格控制，以符合软件gmp的要求。为了便于让多数的读者理解，先简单介绍下v模型。
（1）v模型缩略语及模型：
a.需求的垂直分解；
b.需求的水平验证与确认；
c.与风险相关的需求需追溯到源代码；
（2）开发过程中融合规则：
a.产品架构分为三层：系统，子系统，单元模块。
b.设计规范及单元测试：对于各个单元模块可以采用敏捷开发，快速的迭代sprint，对于单元模块对应的单元测试规范及单元测试报告（自测）在软件开发程序变动更新1/3以上或者自我定义，就要启动单元模块对应的设计规范，单元测试规范及单元测试报告等dhf文件的升版和发布。
c.集成测试：对于各个单元模块集成的测试，偏重在功能层面的测试；对于集成测试类型分为三种情况：全部测试、部分测试、缺陷测试；对于每次迭代的测试，测试组负责更新并发布测试规范及测试报告。
d.系统测试：对于系统测试主要集中在产品功能、性能、安全等全面的测试；对于每次迭代的测试，测试组负责更新升版发布测试规范及测试报告。
（3）测试过程中融合规则，示例如下：
三、ai医疗行业gmp实践解惑
介绍了v模型，读者会问，这和敏捷开发有什么联系？以需求的迭代和详细设计迭代为例说明：
（1）需求的定义，我们当然可以应用敏捷开发（迭代）的思想。
项目开发前期，一般产品经理可以根据客户需求，形成产品的基本需求，我们可以初步称之为市场需求。然后基于此，需求rs向下分解（rs→fs），形成了最初的需求基线(直观为dhf需求文档，最初版本)。在后续项目推进过程中，项目组成员可以参与进来丰富需求。比如，ra（regulatory affair）补充法规和标准的需求，临床专家/医生补充临床需求，服务工程师补充服务需求，研发工程师补充开发需求等等，均可以逐步迭代进来，不断壮大rs需求和fs需求。直至rs→fs完全定义清楚并形成最终的需求基线和最终的版本。
有的企业，在详细设计阶段仍然在进行需求的迭代，笔者认为只要做好相应的变更控制和软件的配置管理（比如：需求基线和软件版本基线控制），也是符合软件gmp和iec62304要求的。因篇幅所限，笔者不再赘述。
现向大家介绍一种需求的迭代管理模式：
需求的迭代变更管理流程图
职责定义：
需求管理团队至少包括以下职能代表：
系统工程师
项目经理
临床专家/医生
设计质量保证（qa）
研发工程师
法规注册工程师（ra）
a.从上图可以看出，需求的迭代变更是变更控制的一种，迭代的过程包括定义需求（制定计划）→利益相关者输入需求→需求追溯关系矩阵建立→需求基线形成→变更（迭代）→需求（制定计划）→…… 循环迭代的过程。
b.在需求迭代过程中，需求管理团队成员需要做好需求的评审，确保正确的需求被吸纳，不明确的需求被适时纠正。
（2）详细设计的迭代控制
当需求定义清楚，项目可以推进入下一阶段，详细设计阶段。笔者简单简绍两种迭代过程：
a.软件功能的迭代
软件工程师可以采用敏捷的开发模式，先实现核心模块的功能，然后逐步的扩展功能，直至把ds中所有的要求实现。工程师可把敏捷的方式运用到极致，只要能做好软件版本的迭代和基线控制（可参考iec62304-章节8软件的配置管理过程），以满足v模型和软件gmp的要求。比如，fs的需求能完全转化为ds（设计规范）并被追溯，ds能追溯到源代码，反之亦然。
b.修复bug，发布补丁的迭代过程
解决的过程可以参照如下的流程，如下图：
（3）软件测试的迭代：
iec62304中能直接体现迭代的思想的实例就是回归测试（iec62304 –章节5.6），如果软件代码进行了重新编译、软件版本的升级，为了证明原功能仍然正常或未引入新的缺陷，此时进行部分回归或全回归测试就显得非常必要。
综述，只要能真正理解对医疗器械的监管要求——制造商必须确保器械的安全和有效性。在实际开发中，灵活把敏捷开发模式融入v模型中，敏捷模型也能在医疗器械软件开发中焕发生命力，游刃有余。可以这样讲，法规和标准并不反对企业使用敏捷迭代或某一固定开发模型，只要制造商能对其进行合理的控制以满足相应标准和法规的要求，就是适用的方法。
