医疗设备软件开发--模型驱动
在当今的互连世界,医疗设备理所当然地容纳了更多具有智能功能的创新性能。这些新型性能通常采用软件进行设计;因此,用于实现这些新功能的软件日益复杂。同时,FDA及其它管理机构也逐步对医疗设备制造商施加压力,以确保产品安全和有关医疗设备报告信息的准确性。
本文引用地址://m.amcfsurvey.com/article/199779.htm市场上面临产品复杂性增加、上市压力、产品安全和监管,对于医疗设备公司来说应对这些挑战成为良好的商业常识。本文探究一种开发医疗设备软件的模型驱动方法。
设备制造商正处于软件开发的转折点,几种工具可能会帮助他们改良生产率和质量。一种模型驱动的开发流程集成了产品开发的多样阶段,从需求分析到系统设计、实现、文档制作和测试。此工作流程有助于使复杂的需求和架构能图形化地以图表形式表示,因此减少了复杂性,并且还能帮助股东之间就需求和设计进行交流。图表具有语义并且互连,有助于实现直接从设计要求到设计的可追踪性。更进一步的是,该软件实现可由模型直接生成,提供了从设计要求到设计到实现的追踪检查。
交付设备软件
在医疗设备市场,交付创新技术的推动力非常现实,智能设备无处不在。在这一领域,是软件提供了使高技术世界成为可能的功能。医疗设备的软件被用于执行以往可能以硬件实现的功能:例如,诊断设备上的物理旋钮和按钮经常被触摸屏显示所替代,或者医疗图像如X光和MRI逐渐以数字格式而不是物理胶片交付。
医疗市场竞争残酷,而且产品在竞争到来之前上市至关重要。完成上市销售前的活动(如510(k)流程)和随后的药品生产和质量管理(GMP)对设备引入市场并占领强劲市场份额必不可少。但是,在速度和病人安全之间必须取得平衡以避免耗费大的产品召回。策略之一是为上市前活动重复使用现有的大量的等效编程代码,尤其是当与软件协同工作进行生命攸关的手术时。实现成功软件的关键路径是通过理解;在一些情况下,软件可能已老化,编程人员也早已不在公司,即为什么有效复用取决于文档可理解。
文档!文档!文档!
能发挥其知识产权(IP)效用的组织——并能复用——在工程设计新型医疗设备软件时已领先一步。对于复用,没有什么比药品文档编制更为重要,它还具有其它的效用。对于维护项目信息,一个设计历史文件(DHF)被用于储存项目成果。FDA通过需要一个DHF的质量系统监控(QSR)——21 联邦管理代码(CFR) Part 820.30来管理面向美国市场开发的产品。该DHF包含有关的信息,从多种源,包括诸如需求、系统规范、风险管理和其它正式文档在内的项目。也可能包括笔记、草图或其它零碎信息。具备一个DHF背后的基本原理是提供可追踪性和文档,以显示设备被用于特定目的,其设计实现了所有要求。然而,如何实现在某种程度上实属偶然:一些公司使用源代码打印清单以证明全部实现设计要求。当然,用源代码作为沟通方法仅在读者能读懂代码的条件下有效。非技术股东可能缺乏所需读懂源代码的技能,从而产生了潜在的危险的沟通真空。
可视软件开发
模型驱动开发(MDD)为软件交付创建了一种可视化开发环境。MDD的基础是源于对象管理组织的统一建模语言(UML)。MDD环境使复杂的设计输入可视化,促进了各种各样股东之间的沟通。开发团队能用比源代码更易使股东理解的格式表述设计要求、架构、结构、设计和行为。UML定义了几种不同的图表来获得系统或应用的机构、架构和行为。与UML类似的是,系统建模语言(SysML)基于UML,但是是为系统工程设计需求而量身定做。
UML图表内的信息被存储在一个模型储存库内,这极大地扩展了图表原仅作为插图之用的作用(见图1)。一张图表上的信息变化被模型储存库所反映,并传送给其它图表以反映同样的信息。例如,假定设计中有一级名为“Pump”,同一级出现在两个不同的图表内。在一张图中把“Pump”名改为“InfusionPump”将会在另一张图中自动变化过来。
图1:以状态图形式描述的设备操作模式。
追踪设计要求到模型元件
对医疗设备的要求通常以文本文件而规定,或存在于用作设计输入的需求管理工具内。尽管文本能交流大量需要完成的细节,它也会易受误解。更为重要的是,没有滤波器或流程来防止有冲突的设计要求在最开始就被记录下来。通过把需求拆分为产品内每个元件更进一步的细节要求,执行需求分析能帮助解决冲突。建模能通过文本需求以图表的形式可视化来辅助这一过程,并且提供到设计和实现的可追踪性。
追踪需求到模型元件的第一步是将文本需求与建模环境相关起来。模型内的一个需求元件储存需求,并保持除其它相关信息如需求ID、优先级、安全完整性级别及风险等之外的描述需求的文本。对能储存的数据类型没有限制。需求和模型之间保持同步化,从而任何一方的更改都能反映到另一方。从需求到满足这些需求的模型元件的可追踪性能在模型内表述出来。凭借这些信息,能生成需求覆盖报告或进行设计改变的影响分析。例如,能生成一个UML资料,定义了故障树分析图表。模型内还能进行安全性和风险分析。图2展示了故障如何被追踪到与故障相关的设计要求。可进行更进一步的模型信息分析来说明覆盖鸿沟。
图2:关系追踪需求到满足设计要求的模型元件。
助听器原理相关文章:助听器原理
评论