http://www.jibing.com.cn

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

随着最近几年很多传统互联网企业开始积极布局医疗市场,国内涌现不少AI医疗公司,也积极参与到医疗器械这个朝阳产业中。


但现实总是机遇和挑战并存,从传统企业直接跨入医疗器械行业,总会带来水土不服的地方。笔者大体总结原因如下:


1.传统行业由于没有医疗器械行业背景,对医疗器械行业标准和法规理解不深刻,运用过去对传统软件开发的经验,来照搬做医疗器械软件开发,可能会在法规和标准的符合性方面存在一些问题;

2.AI是最近几年才开始应用于医疗器械软件,当前业界关于软件开发的指导标准和法规,在面临AI这个新事物时,面临不适用或部分不适用的风险。


简言之,当前没有金标准或成熟标准供大家参照学习。如何在应用AI技术的同时,能确保器械的安全和有效,是整个行业甚至包括监管机构的待解难题。困难再多,企业也要弄潮而上。如何用传统的开发模式来适应医疗行业的新要求,是很多企业的困惑。笔者在阅读动脉网前期的一篇文章《人工智能医疗器械创新合作平台会议在博鳌召开,一文读懂人工智能医疗器械审评审批常见问题》之后,也想以传统敏捷软件开发模式来适应医疗器械独立软件的开发为例,分享些实战经验。



当前国内医疗器械软件开发可以参照的标准和法规有7月12日国家药品监督管理总局发布《医疗器械生产质量管理规范附录独立软件》(下文统一简称为:软件GMP)和IEC62034-2015《医疗器械软件 软件生存周期过程》标准。由于AI医用独立软件管理类别属于Ⅲ类医疗器械,其软件安全等级为Class C,GMP对其产品追溯性和变更控制的要求较高。


产品在立项时就需要定义清楚产品需求,可预见的是需求不能轻易变更,另外对需求的实现及验证要遵循严格的流程要求。但是,这恰恰和软件的迭代和敏捷开发方式有相悖的地方。当然,敏捷开发模型是一种成熟的模型,有其优点:


(1)团队在使用敏捷开发模式的情况下,迭代周期和大家的目标比较统一,敏捷开发模型可以提升团队自主管理能力,信息传递比较及时,每天都会同步信息。

(2)敏捷开发模型里面,产品按照每个迭代去验收,每个迭代工作成果都需要经过演示,如果在演示中意见不同,可以及时暴露并修正,提测频率较高,减少开发和测试的等待时间。敏捷开发模型对项目进度只有零或一百分,着重团队承诺,不强调个人能力,更关注整个团队的绩效,重视对外部承诺和内部承诺等等。

(3)敏捷中的风险管理关注于项目风险如进度、版本质量、人员风险等等。

(4)敏捷中关注迭代过程的持续改进,例如需求评审不充分,沟通信息不同步。


简言之, 敏捷更关注项目的生命周期。而软件GMP的要求更关注于产品生命周期,从产品立项到产品退市,着力于整个产品生命周期的管控。


其次,敏捷模型更适用于软件类产品的开发控制,不太适用于硬件的开发。原因是软件可以快速交付可用的功能,但是硬件的特性决定了功能的实现具有集成性。只是造出一个其中部件,实现不了具体的功能,不能满足定义的功能需求。并且敏捷的需求是渐进明细,不是一开始就能明确下来,有一个迭代完善的过程(见章节3论述)。在人员这一块,敏捷不支持人员兼职或项目并行,必须是串行。


总之,按照GMP的要求,制造商需关注产品的全生命周期,关注于研发过程质量保证,采购质量管理,生产质量控制,销售和售后及上市后的质量跟踪保证等活动。


我们也可以从风险控制角度来看传统敏捷软件开发模式和GMP要求的差异:在敏捷中的风险管理则关注于项目风险如进度,版本质量,人员风险等等,而在GMP中风险管理更多关注产品本身的风险,其风险管理贯穿于软件的整个生命周期。



鉴于大多数软件研发项目采用敏捷开发模型,如何让软件敏捷开发模式能满足软件GMP的要求?笔者认为,可以从YY/T 0664《医疗器械软件 软件生存周期过程》标准中寻求解决之道。那就是深刻理解V模型的项目管理理念,把每个V模型的阶段灵活植入迭代开发的过程,对每个阶段的交付物(各企业可结合自身项目开发流程阶段)进行严格控制,以符合软件GMP的要求。为了便于让多数的读者理解,先简单介绍下V模型。


(1)V模型缩略语及模型:

image.png


image.png


A.需求的垂直分解;

B.需求的水平验证与确认;

C.与风险相关的需求需追溯到源代码;


(2)开发过程中融合规则:

A.产品架构分为三层:系统,子系统,单元模块。

B.设计规范及单元测试:对于各个单元模块可以采用敏捷开发,快速的迭代sprint,对于单元模块对应的单元测试规范及单元测试报告(自测)在软件开发程序变动更新1/3以上或者自我定义,就要启动单元模块对应的设计规范,单元测试规范及单元测试报告等DHF文件的升版和发布。

C.集成测试:对于各个单元模块集成的测试,偏重在功能层面的测试;对于集成测试类型分为三种情况:全部测试、部分测试、缺陷测试;对于每次迭代的测试,测试组负责更新并发布测试规范及测试报告。

D.系统测试:对于系统测试主要集中在产品功能、性能、安全等全面的测试;对于每次迭代的测试,测试组负责更新升版发布测试规范及测试报告。


(3)测试过程中融合规则,示例如下:

image.png



介绍了V模型,读者会问,这和敏捷开发有什么联系?以需求的迭代和详细设计迭代为例说明:


(1)需求的定义,我们当然可以应用敏捷开发(迭代)的思想。

项目开发前期,一般产品经理可以根据客户需求,形成产品的基本需求,我们可以初步称之为市场需求。然后基于此,需求RS向下分解(RS→FS),形成了最初的需求基线(直观为DHF需求文档,最初版本)。在后续项目推进过程中,项目组成员可以参与进来丰富需求。比如,RA(regulatory affair)补充法规和标准的需求,临床专家/医生补充临床需求,服务工程师补充服务需求,研发工程师补充开发需求等等,均可以逐步迭代进来,不断壮大RS需求和FS需求。直至RS→FS完全定义清楚并形成最终的需求基线和最终的版本。


有的企业,在详细设计阶段仍然在进行需求的迭代,笔者认为只要做好相应的变更控制和软件的配置管理(比如:需求基线和软件版本基线控制),也是符合软件GMP和IEC62304要求的。因篇幅所限,笔者不再赘述。


现向大家介绍一种需求的迭代管理模式:


需求的迭代变更管理流程图

 image.png


职责定义:

需求管理团队至少包括以下职能代表:

·系统工程师

·项目经理

·临床专家/医生

·设计质量保证(QA)

·研发工程师

·法规注册工程师(RA)


A.从上图可以看出,需求的迭代变更是变更控制的一种,迭代的过程包括定义需求(制定计划)→利益相关者输入需求→需求追溯关系矩阵建立→需求基线形成→变更(迭代)→需求(制定计划)→…… 循环迭代的过程。

B.在需求迭代过程中,需求管理团队成员需要做好需求的评审,确保正确的需求被吸纳,不明确的需求被适时纠正。


(2)详细设计的迭代控制

当需求定义清楚,项目可以推进入下一阶段,详细设计阶段。笔者简单简绍两种迭代过程:


A.软件功能的迭代

软件工程师可以采用敏捷的开发模式,先实现核心模块的功能,然后逐步的扩展功能,直至把DS中所有的要求实现。工程师可把敏捷的方式运用到极致,只要能做好软件版本的迭代和基线控制(可参考IEC62304-章节8软件的配置管理过程),以满足V模型和软件GMP的要求。比如,FS的需求能完全转化为DS(设计规范)并被追溯,DS能追溯到源代码,反之亦然。


B.修复bug,发布补丁的迭代过程 

解决的过程可以参照如下的流程,如下图:

 

image.png


(3)软件测试的迭代:

IEC62304中能直接体现迭代的思想的实例就是回归测试(IEC62304 –章节5.6),如果软件代码进行了重新编译、软件版本的升级,为了证明原功能仍然正常或未引入新的缺陷,此时进行部分回归或全回归测试就显得非常必要。


综述,只要能真正理解对医疗器械的监管要求——制造商必须确保器械的安全和有效性。在实际开发中,灵活把敏捷开发模式融入V模型中,敏捷模型也能在医疗器械软件开发中焕发生命力,游刃有余。可以这样讲,法规和标准并不反对企业使用敏捷迭代或某一固定开发模型,只要制造商能对其进行合理的控制以满足相应标准和法规的要求,就是适用的方法。


文 |

彭传波(国内知名AI医疗公司质量负责人,微信pengchuanbo52)

程建功(知名外企医疗公司软件质量负责人,微信jekingcheng88)

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。

标签:

相关文章阅读

AI技术公司Concerto HealthAI完成1.5亿美元AI技术公司Concerto HealthAI完成1.5亿美元
人工智能公司Nference完成6000万美元B轮人工智能公司Nference完成6000万美元B轮
性健康首登大雅之堂,可穿戴健康设性健康首登大雅之堂,可穿戴健康设
成立三年,拿下多家一线器械厂商后成立三年,拿下多家一线器械厂商后