医疗器械独立软件研发体系与敏捷项目开发模式的融合实践

随着最近几年很多传统互联网企业开始积极布局医疗市场，国内涌现不少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模型中，敏捷模型也能在医疗器械软件开发中焕发生命力，游刃有余。可以这样讲，法规和标准并不反对企业使用敏捷迭代或某一固定开发模型，只要制造商能对其进行合理的控制以满足相应标准和法规的要求，就是适用的方法。