可以将“敏捷”应用于医疗保健IT团队吗？

敏捷能否在医疗保健IT等领域受聘，该领域的病人护理很大程度上取决于系统的质量和及时交付？

是的，敏捷开发绝对在医疗保健IT开发中发挥作用。没有一个人，不是最终用户，不是患者，当然还有开发团队，如果开发过程做得不好，就会得到很好的服务。考虑一下敏捷宣言背后的一些原则（我的评论从维基百科无耻地撕掉了清单）：

• 通过快速交付有用的软件使客户满意。这什么时候不是目标？
• 即使在开发后期，也欢迎不断变化的需求。医疗保健IT集成到一个领域，尽管它绝对被技术所淹没，但并不是特别关注IT。旨在立即“正确解决”问题的系统潜力很小。
• 工作软件经常交付（数周而不是数月）。作为某些此类产品的最终用户，我会喜欢的。快速而有效的变更非常宝贵，这使医疗保健IT从“我们需要做的事情”转变为“改变了我工作方式的事情”。
• 工作软件是进度的主要衡量标准。在大多数应用中都有意义，因此实际上没有理由不涉及HIT。
• 可持续发展，能够保持稳定的步伐。您会在整个医疗保健中看到这一点，从感染监测到HIT到设施。医疗保健不是一个兴衰周期，而是持续不断的敲打。
• 商界人士与开发人员之间的紧密日常合作。大多数HIT都不是开发人员工具。这是开发人员制作的工具。与客户的联系是并且应该是关键。如果系统可以运行并集成到客户端工作流中，那么采用该系统也容易得多，而不需要进行附加，打补丁等工作。
• 面对面的交谈是最好的交流方式（同位）。从我与临床医生的互动中，亲自完成事情（最好是用纸垫）比其他任何方式都容易。
• 项目是建立在有动力的人周围的，这些人应该受到信任。这会使您的生活变得更好-是的，应该采用;）
• 持续关注技术卓越和良好的设计。这又是“每个人都应该这样做，所以当然应该这样做”的事情之一。但是，请考虑HIT系统的复杂性以及日复一日地最终使用它们的多种方式。一个伪劣的系统不会削减它。
• 简单性。它应该开箱即用。它应该一直以预期的方式运转良好。人是白痴。医护人员就是人。因此...你知道其余的。简单性有帮助。
• 自组织团队。对于HIT来说，这可能只是一点点延伸。老实说，我不确定在这种情况下的自我组织是好还是不好。
• 定期适应变化的环境。HIT是一个活跃的，成长中的行业，具有复杂且不断变化的监管负担。能够适应似乎是一个不错的主意。

关于在FDA监管环境中使用敏捷医疗设备软件开发的讨论已经进行了一段时间，并且与该问题有关。原因如下：

1. 从本质上讲，Waterfall与迭代开发的优缺点是相同的，任何Health IT项目都需要考虑到。
2. 用于医疗器械软件开发的FDA强制性质量体系（请参见软件验证通用原则；行业和FDA工作人员最终指南）是行业的金标准。应该注意的是，这些法规没有规定任何特定的开发方法。无论如何，如果所有人都遵循这些最佳实践，则将大大改善Health IT软件的质量。
3. 目前，大多数Heath IT软件开发均未按照这些FDA法规标准进行操作。随着医疗设备互操作性的障碍不断下降，特别是对于移动平台，这种情况可能会改变-请参阅FDA解决移动医疗应用问题。
4. 另外，如果您要开发商业性的Health IT软件，则必须问自己是否要创建医疗设备数据系统（MDDS）：我的产品是MDDS吗？

简短的回答是“是”。更长但更准确的答案是“如果您认真对待”。

有几个主题需要牢记，我想将其分为与（a）患者安全和产品质量以及（b）行业法规有关的关注点。

在安全和质量方面，请记住，制作安全软件很困难。一些具有一定领域知识的优秀程序员可以开发出非常有用的非常安全的软件。如果它们是本地临床环境中部署的一部分，并且能够在软件的部署和使用过程中保持对事件的响应和调整，则该软件可能会提供价值，可以挽救或改善生命，而只有很少的与使用错误相关的伤害或死亡。或软件错误。但是，该软件将要求程序员始终在其中，以响应，随着软件用途的发展而不断发展。这不是一个可扩展的过程，当程序员死亡或感到无聊时，系统很容易很快变得非常危险。为了改善这些结果并制作安全的软件，在开发软件时，需要采取重要的开发过程步骤。可以在医疗设备软件开发的国际标准ISO / IEC 62304中找到对它们的很好的“即开即用”介绍。主要概念是在各个阶段的安全风险管理-在用例分析和故事开发期间，要求说明，系统和体系结构设计，实现，单元和集成测试。敏捷不会使任何工作消失或减轻难度，但是通过专注于价值创造并消除不会创造价值的工作（例如不需要的功能或过多的验证测试/修复周期），敏捷开发可以允许团队将这项工作集成到开发中，从而可以同时开发更安全的软件。敏捷团队通常使用的迭代式开发实践非常适合完成安全风险管理工作，它在项目的整个生命周期中都在发展，而不是事后才想到。并且在软件运行之后，需要单独或汇总考虑来自用户的反馈以及任何可能导致伤害的事件，以确保软件的安全使用。如果敏捷能够提供快速，安全的过程来合并更改而又不破坏系统的其他部分，则可以为您提供帮助-这又需要开发软件时创建的良好体系结构和易于理解的设计交互。在项目的整个生命周期中不断发展，而不是事后才想到。并且在软件运行之后，需要单独或汇总考虑来自用户的反馈以及任何可能导致伤害的事件，以确保软件的安全使用。如果敏捷能够提供快速，安全的过程来合并更改而又不破坏系统的其他部分，则可以为您提供帮助-这又需要开发软件时创建的良好体系结构和易于理解的设计交互。在项目的整个生命周期中不断发展，而不是事后才想到。并且在软件运行之后，需要单独或汇总考虑来自用户的反馈以及任何可能导致伤害的事件，以确保软件的安全使用。如果敏捷能够提供快速，安全的过程来合并更改而又不破坏系统的其他部分，则可以为您提供帮助-这又需要开发软件时创建的良好体系结构和易于理解的设计交互。

第二个问题是监管。在理想的情况下，安全法规将适用于可能具有足够危险性的所有产品，并且供应商一旦开始越界，便可以通过做一些简单的事情来遵守这些法规。实际上，全球法规在这个行业中是复杂且瞬息万变的，这意味着您有一天可以开发一款小型iPhone应用程序，以显示一些医疗数据，而第二天您将符合ISO和FDA关于“质量管理”的标准。系统”或QMS。对于过去没有正式的QMS的公司来说，这可能是令人恐惧的。敏捷可能会加剧这种情况，因为您可能会从产品概念入手，并通过不断的发展不经意间进入规范的预期用途（例如向用户显示临床诊断数据）。2011年10月；对于任何打算销售类别名称中具有“健康”，“医疗”，“保健”的产品的公司，我的建议是，他们应该制定一个计划，使所制造的产品在全球范围内受到一个或多个医疗设备监管机构的监管。敏捷在这里再次可以提供帮助，因为敏捷实践通常会产生（或容易产生）合规的输出，从而满足监管客户的上市前清关提交（如FDA 510k），认证（如ISO 13485）和上市后运营的要求。测试优先开发适合医疗软件。持续集成，自动化的单元测试和SCRUM sprint元数据可以提供完整的客观证据，证明风险管理和适当的验证不仅是事后的想法，而且可以融入开发过程。在大多数情况下，我认为敏捷可能比“瀑布”产生更多的假象，也许形式不同。但是，将输出转换为令人满意的调节器是一个相对较小的问题。

因此，总而言之...是的，弗吉尼亚州具有医疗IT（以及其他医疗设备）软件开发的敏捷性。像所有敏捷一样，它需要奉献的过程，业务支持和勇气。

是的，敏捷开发的前提之一就是客户的参与。这对于医疗保健IT系统和流程至关重要。如果有客户代表参与，医疗保健IT部门将做出更好的决策，并提供有关决策将如何影响患者护理的信息。

我认为这是有可能的，但是行业需要巨大的范式转变。我在医疗保健开发人员的第二年，信任和自我组织并没有明显的表现。正式采用敏捷技术将极大地受益于医疗保健，因为无论如何它通常都是混乱的，迭代开发被称为“颠覆性”，并且需求的变更日新月异，因为大型的前期设计始终无法正常工作。

我明白你的问题。敏捷开发的一个很好的例子是为某人建立一个网站。通常，客户并不确切知道他/她想要什么，因此与客户之间存在很多互动。

医疗保健IT似乎是计算机科学中一个非常预先定义的领域。有了严格的标准（DICOM，HL7），似乎只有一种方法可以实现它们，但也有很多偏好和决策能力。

我认为，无论您要生产什么产品，都无法提前确定所有要求，因此敏捷的软件开发方法非常有效。

如前所述，答案是肯定的。

将敏捷应用于受监管或高风险区域时，必须在每次迭代中定义“完成”，以便包括合规性和其他风险缓解策略。例如，这可能需要QA文档，需求可追溯性，安全审核和其他操作才能在每次迭代中完成。

例如，对于将敏捷方法应用于FDA监管环境，存在良好的技术和实践。

简短的回答：是的。有一个关于高保证环境中敏捷的好博客，其中提供了一些技巧。

但是，需要做出一些折衷。考虑一下敏捷宣言：

个人与流程和工具之间的互动

工作软件超过全面的文档

客户合作而非合同谈判

响应计划变更

监管机构对左侧的重视程度与敏捷团队一样，但与典型的敏捷团队相比，监管机构需要更多地强调右侧。例如，FDA要求您验证您的过程和工具，要求相当全面的设计和测试文档，并且绝对需要进行大量规划。

另一方面，许多敏捷原则非常适合医疗保健领域，包括：

• TDD和结对编程-提高质量
• 紧密的客户反馈环-尽早进行验证非常有用
• 迭代计划-监管机构都在进行计划

一些学科本质上已经是敏捷的。例如，护理依赖于“评估，评估，计划，干预”周期，该周期取决于诊断/预后的多次迭代，以逐步实现最终结果。

然而，试图建议以这种方式提供的医疗保健服务特别适合于敏捷软件开发的基本单实例应用朝着用于所述服务交付的软件工具或系统的应用，将是致命的混淆。

AAMI正在积极编写一份技术信息报告，标题为：
AAMI TIR SW1，有关在医疗设备软件开发中使用敏捷实践的指南。

我听说它可能会在2012年出版。

它讨论了敏捷宣言（请参阅EpiGrads答案）的原理与医疗器械软件相关的法规要求，典型流程和其他产品实用性的一致性。