综述：放射肿瘤学中的资源共享和开源软件：从挑战到惠及整个行业的机遇

《Radiotherapy and Oncology》：Resource sharing and open-source software in radiation oncology: From challenges to opportunities for community-wide benefit

　　塞缪尔·英格拉姆|洛伦佐·布鲁阿拉|亚历克西亚·德尔巴雷|马苏德·扎雷皮谢赫|亨德里克·皮尔斯马|阿迪蒂亚·阿普特|罗曼·路德维希|埃里克·罗尔洛夫斯|马尔塞尔·纳赫巴尔|阿里·扎伊拉|克日什托夫·多曼斯基|乔什·柯比|乔治奥·卡特基亚尼|托比亚斯·贝赫|萨穆埃莱·卡维纳托|戈兰·斯塔尼茨|斯蒂娜·科雷曼|尼古拉斯·瓦尔|乔什·梅森|安娜·M·巴拉甘-蒙特罗

英国曼彻斯特的Christie NHS基金会信托

摘要
现代放射治疗工作流程在很大程度上依赖于软件，然而专有解决方案限制了适应性和透明度。许多机构创建了内部工具，导致了重复的工作和可持续性挑战。免费和开源软件（FOSS）提供了透明度、定制化和协作开发的机会，但面临着包括碎片化的工作、监管复杂性以及临床采用障碍等壁垒。这篇愿景论文受到2024年ESTRO物理研讨会的启发，该研讨会讨论了“资源共享：放射治疗中的开源软件与开发”，探讨了这些挑战，并提出了促进放射肿瘤学领域可持续和可发现的开源生态系统的策略。主要建议包括提高互操作性、清晰的许可、风险管理、验证框架以及创建一个用于资源可视化的中央注册系统。采用开源实践可以加速创新、减少冗余并改善患者护理。

引言
现代放射治疗（RT）越来越多地受到软件的影响，无论是作为研究工具还是作为临床工作流程的基本组成部分。然而，在RT社区中，获得灵活、可修改和可共享的软件仍然是一个主要挑战。专有医疗软件的主导地位限制了修改、互操作性和透明验证的机会。因此，为了满足当地临床需求或探索新的应用，许多医学物理学家和研究人员独立开发了内部软件。这些通常在孤立状态下开发的努力经常在各个机构之间重复，并且难以维持。这种冗余不仅浪费了宝贵资源，还减缓了创新速度，最终限制了改善患者护理的潜力。

免费和开源软件（FOSS）提供了一个有吸引力的替代方案，提供了透明度、适应性和协作开发及验证的机会[1]、[2]、[3]。尽管这种方法在医学图像处理和分析等领域已经取得了成功，例如MITK [4]、[5]、ITK/SimpleITK [6]、3D Slicer [7]、MONAI [8]或DIPY [9]等知名库，但2024年ESTRO物理研讨会指出，放射治疗社区仍在积极应对实现同样广泛的开源软件整合的独特障碍。当前的开源RT软件格局是碎片化的，有价值的project分散在不同的平台上，往往缺乏持续的社区支持。较小的开发成果，如AI模型或规划脚本，有时仅在出版物中分享，缺乏再利用、扩展或长期维护所需的支持。临床部门开发的解决方案通常受到法规、机构政策和供应商特定环境的限制。这些挑战反映了更广泛的运营障碍：不一致的标准和接口、有限的文档和可发现性、数据隐私和监管限制，以及缺乏共享和维护的基础设施和激励措施。这些障碍进一步复杂化了研究人员和临床医学物理学家的再利用和协作开发，最终影响了患者受益的创新速度。

尽管医疗组织和专业协会越来越一致地认为需要透明且经过严格验证的软件，但这种缺乏统一生态系统的状况仍然存在。更广泛的医疗政策，如英国的Goldacre Review [10]和NHS服务标准[11]，越来越多地要求采用开源编码实践。同时，专业机构为软件验证和放射肿瘤学中的IT专家整合提供了全面的建议（例如AAPM TG-53/TG-201 [12]、IPEM指南[12]、[13]以及最近的联合声明[12]、[14]）。然而，这些高层次的指南与临床放射治疗社区中开源资源共享的实际日常情况之间仍存在显著差距。

为了应对这些挑战，2024年召开了一场名为“资源共享：放射治疗中的开源与开发”的专门ESTRO物理研讨会，讨论了改进放射治疗中资源共享和开源软件开发的策略。研讨会汇集了软件开发人员、研究人员和临床医生，以确定需求、最佳实践以及走向更可持续、可见和协作软件生态系统的潜在路径。讨论不仅涉及开源代码，还包括相关资源，如基准数据集、规划协议、工作流程和社区基础设施。

这篇愿景论文就是基于该倡议提出的，概述了改进资源共享的动机、挑战以及在不同时期的研究和临床RT环境中开发和实施开源软件时推荐的改进措施和行动。

在这篇手稿中，软件指的是用于放射治疗工作流程的计算工具，包括独立应用程序、库/工具包以及扩展现有平台的脚本或插件。这些工具可以用于研究或临床目的，并可以使用开源或专有编程环境进行实现。另一方面，“免费”指的是无需成本即可使用的软件，而“开源”（或libre）指的是源代码可访问、可修改并在适当许可下可重新分发的软件。这些概念相关但不同，因为软件可能免费但不一定是开源的。

放射治疗中的开源软件和资源共享实践现状及挑战：调查结果
在研讨会前进行的一项调查（补充材料）分发给了ESTRO物理邮件列表。在收到的103个回复中，80%的人在临床环境中工作，40%在研究领域，5%在工业领域（可以针对所有问题选择多个回复）。71%的受访者使用过开源代码，42%的人开发过开源代码，20%的人两者都没有。当被问及是否曾经使用过开源代码时，88%的人在研究中使用过，55%的人在临床中使用过，而73%的受访者开发、贡献或分享过开源代码或资源。GitHub是迄今为止最常用的代码共享平台。寻找资源的主要方法包括互联网搜索、GitHub、网络交流、会议摘要和期刊出版物。当被问及哪些放射治疗研究或临床应用特别受益于资源共享时，答案涵盖了放射治疗路径的所有方面，包括患者数据库、数据工具、规划和管理脚本，以及AI工具、患者特定质量保证（PSQA）和在线自适应工作流程的工具和模型。受访者还被问及他们认为资源共享的主要障碍是什么，答案总结在表1中。研究背景下的主要障碍是需要改进（例如整理、记录）或进一步测试代码后再分享，其次是时间不足；而临床背景下的主要障碍是担心如果出现问题要承担责任，其次是知识产权或许可问题。

表1. 调查问题“放射治疗中资源共享的主要障碍是什么？”的回答百分比，显示了研究人员和临床使用中选择每个选项的受访者比例。

障碍 研究 临床
缺乏明显的平台 44% 47%
时间不足 48% 42%
知识产权或许可问题 45% 50%
机构或雇主政策 38% 42%
需要改进（即整理、记录）或进一步测试代码 55% 42%
不愿对代码负责 37% 64%
支持代码或回答问题的时间不足 26% 23%
与期刊出版物相比缺乏学术认可 40% 16%

尽管受访者样本有限，但结果表明，即使在临床环境中，开源代码的使用和开发也相当普遍，医学物理学家也面临着相同的开源采用障碍（即文档、缺乏可持续维护的时间、许可等）。

在研讨会上，讨论了开源软件和商业解决方案的优缺点，并在表2中进行了总结。

表2. 商业软件与开源软件的比较

| 特征 | 商业软件 | 开源软件 |
|-----------------|---------------------------|----------------------|
| 成本 | 初始购买成本高且持续许可费用 | 免费或最低成本；可能需要更多投资用于本地支持或定制 |
| 透明度 | “黑箱”实现，算法可见性有限 | 完全透明，源代码可供审查和修改 |
| 监管批准 | 通常需要监管批准（FDA、UKCA、EMA CE标志） | 常常缺乏正式的监管批准，需要本地验证和质量管理 |
| 支持 | 专业支持与服务水平协议 | 基于社区的支持；可能提供有偿支持选项 |
| 文档 | 面向用户的全面文档，专业开发 | 质量参差不齐；取决于社区贡献 |
| 更新和维护 | 供应商定期提供更新 | 社区驱动的更新；可能频繁但结构较差 |
| 定制 | 限于供应商批准的选项 | 无限定制潜力 |
| 集成 | 为特定工作流程优化；可能互操作性有限 | 可变集成能力：较新的平台如PortPy具有商业系统兼容性 |
| 验证 | 由制造商验证 | 需要在临床实施前进行本地验证 |
| 创新速度 | 由商业优先级驱动的较慢开发周期 | 通过协作开发实现快速创新 |
| 示例 | Eclipse、RayStation、Monacomat | Rad、OpenTPS、PortPy、RDS、CERR |

培训和教育 | 供应商提供的培训计划 | 自主学习；社区资源 |
| 法律责任 | 供应商承担部分责任 | 机构承担全部责任 |
| 数据所有权 | 数据使用和导出可能受到限制 | 完整的数据所有权和控制 |
| 研究灵活性 | 为研究目的的修改能力有限 | 非常适合具有完全修改自由的研究 |

动机和好处
通过医疗保健和放射肿瘤学中的开源软件和脚本进行资源共享，为研究和临床实践提供了变革性的好处[15]、[16]。开源解决方案通过汇集专家知识和资源来促进机构、研究人员和临床医生之间的合作，从而进行扎实的研究并加速发现[17]。在某些情况下，这些工具通过消除前期许可费用而显著节省了成本。然而，机构必须仔细权衡这些节省的成本与内部“总拥有成本”；如果没有专门的商业支持，运行和维护开源工具需要组织积极分配资金用于专门的内部人员、IT基础设施和本地验证工作（如表2所总结的）[18]。开源软件固有的透明度增加了针对特定临床工作流程的定制灵活性，并可以通过社区驱动的错误识别和纠正提供更高的稳定性[19]。公共问题跟踪明确了工具的功能和限制，减少了重复工作[20]。互操作性是一个关键优势，因为开源工具打破了不同医疗系统和设备之间的隔阂。它们通过原生支持供应商中立的标准（如DICOM和FHIR）实现了这一点，提供了对底层数据结构的透明访问，并提供了开放的应用程序编程接口（API），使机构能够在不兼容的商业系统之间建立自定义桥梁。这支持了协调护理和多机构研究合作所需的无缝数据共享。此外，开源能够促进快速的创新，拥有活跃的用户和开发者社区，可以迅速共同创建解决方案。一些与医学物理社区相关的例子包括MONAI[8]、MatRad[21]、OpenTPS[22]、CERR[23]、3DSlicer[7]、PortPy[24]、[25]、Pylimac[26]等。这种协作方法在COVID-19等危机期间特别有价值，因为“即插即用”的开源技术使得解决方案能够快速跨地理和知识边界部署[28]。

人工智能（AI）时代中的开源
广义上讲，人工智能（AI）是指旨在自动化或增强临床任务的机器学习和深度学习算法，在放射治疗中显示出显著的优势，特别是在轮廓勾画和规划方面，通过节省时间、减少观察者间变异性（IOV）以及提高质量和指南遵守性。基于开源nnU-Net框架构建了大量用于分割的AI模型[29]，为开发建立了标准化基线。例如，已经向社区发布了高质量的开源 pelvic MRI 分割模型，展示了开源合作如何产生强大的临床工具[30]。此外，用于头部和颈部器官[31]以及淋巴结分割[32]的AI模型显示出减少的轮廓变异性，而国家级别的乳腺分割模型进一步提高了一致性和准确性[33]。最近，专家训练的AI模型被提出作为传播放射治疗轮廓勾画指南的范式转变，例如在EPTN共识图谱中用于CT和MR基础的神经肿瘤学轮廓勾画，其中模型直接与专家共识定义相关联[34]、[35]。AI驱动的规划模型同样产生了更一致和改进的治疗计划[36]、[37]。虽然这些研究大多是在单个机构或国家内进行的，但公开分享这些模型并将其代码开源将为全球范围内的更一致和改进的临床实践带来社区范围内的好处。此外，与许多商业工具相比，开源AI提供了更大的控制力和透明度，这在针对小患者群体或罕见疾病时尤为重要，因为商业兴趣可能有限。开源AI还允许动态适应并通过社区审查建立信任。

尽管开源AI在医疗保健中具有诸多好处，但它也面临着独特的挑战，特别是与数据共享和隐私相关的问题。用于训练AI模型的敏感患者数据需要严格的保护，由于监管、伦理和隐私限制，跨机构共享变得复杂[38]。这个问题在低收入和中等收入国家（LMICs）中更加严重，因为基础设施障碍进一步限制了AI开发的有效数据共享[39]。与人工智能相关的数据集的颗粒度和敏感性，通常包括生物特征和成像数据，引发的隐私问题超出了传统医疗记录交换的范畴。已训练模型的权重与训练数据本身的开放共享仍然是一个有争议的话题，这影响了研究的可重复性和社区验证，同时也需要仔细的治理措施来保护患者的隐私[40]。国家和国际学术联盟正在努力开发“基础模型”。例如，丹麦的AIM@CANCER项目[41]利用超级计算能力在安全的国家级数据上生成了强大的基础模型。这些通用模型将能够支持各种临床任务。基础模型也可以使用本地数据进行构建或微调，从而在不暴露底层数据的情况下确保对特定患者群体的高效率[42]。重要的是，这种本地优化还允许机构根据其特定的临床实践（例如，机构轮廓指导原则和计划技术）和独特的硬件设置（例如，特定的成像设备和协议）来调整模型。最后，将这些开源创新转化为常规实践需要一个框架，以便无缝集成到临床工作流程中。像RadDeploy[43]这样的开源工具正是为此目的而开发的，它允许内部开发的软件和AI模型直接高效地部署到放疗工作流程中。

为了更广泛和可持续地共享和使用开源软件（FOSS），需要关注以下方面：

**监管概述**
管理医疗设备（包括软件）的法规不断演变，以应对技术进步和新出现的挑战。以下总结反映了当前的监管环境，但机构和开发者应定期咨询官方监管机构和指导文件，以确保符合最新要求。开源软件也不免除监管合规性，除非仅用于非临床研究目的。当用于临床环境时，开源软件必须满足与专有解决方案相似的监管要求，但可能不需要正式批准（例如CE标志认证）。在欧盟，开发者应审查《医疗器械法规》（MDR 2017/745），该法规将某些健康相关软件归类为医疗器械，并规定了严格的合规性评估程序（例如文件编制、质量管理、监控）。此外，最近实施的《欧盟人工智能法案》为AI系统（包括开源模型）引入了基于风险的义务，特别是当它们用于医疗或安全关键领域时。在美国，食品药品监督管理局（FDA）将软件作为医疗器械进行监管，开源工具必须遵守FDA关于软件验证的指导。在英国，脱欧后的法规通过《2002年医疗器械法规》（经修订）与MDR保持一致，由MHRA监督。使用开源软件的开发商和机构应评估其工具是否属于这些法规的适用范围，并实施适当的质量管理系统、文件编制和风险缓解策略，以确保合规性。

**指导文件**
有指导文件可用于支持医疗机构内部开发软件作为医疗器械（SaMD）的开发和使用。例如，英国的医学物理与工程研究所（IPEM）提供了关于医疗环境中软件生产和共享的最佳实践建议，强调了针对内部开发的风险管理、验证和监管考虑[44]。同样，其他人也提出了质量管理、临床评估和持续上市后监测的内部SaMD的框架，使机构实践符合不断变化的监管期望[45]。这些指南通过明确本地开发者如何安全地将SaMD集成到临床工作流程中，促进了合规性，同时鼓励创新，前提是维护严格的内部程序。机构应密切遵循这些和其他区域性的监管指导文件，以确保其内部SaMD符合患者安全要求并主动适应监管变化。

**提高开源软件在临床中的采用率**
成功将FOSS转化为临床环境需要一个结构良好的生态系统。图1展示了支持这一过程所需的层次结构、治理机制和工作流程，强调了创新责任、质量保证和持续风险管理如何在关键利益相关者之间分配。开源软件在临床环境中的采用面临独特的挑战，需要深思熟虑的策略来克服这些挑战。如前所述，尽管开源解决方案具有潜在的优势，但由于对可靠性、支持和监管合规性的担忧，医疗机构往往犹豫不决。然而，需要消除一个常见的误解：购买商业软件系统并不免除医疗机构与该软件相关的操作风险。无论系统是商业购买的还是内部开发的，安全合规使用的责任仍在于医疗机构本身，它们必须进行自己的风险评估、持续监控和集成检查。解决这些问题需要综合考虑技术和组织因素的多方面方法。Moran等人[2]描述的内部临床软件的结构化、团队合作开发和实施周期就是一个示例。以下是一系列建议，旨在提高FOSS在临床中的采用率：
- **集成和互操作性**对于开源软件在临床中的采用至关重要。能够与商业系统接口的解决方案（例如通过在商业系统中通过脚本运行软件或自动的DICOM导入/导出）具有重要优势，因为它们使医疗机构能够在保持与现有基础设施兼容性的同时利用开源创新。这种桥接方法允许逐步采用，而不会扰乱现有的临床工作流程。模块化的软件设计通过分离不同过程的计算算法，消除了在复杂系统中修改和扩展模型的复杂性，从而进一步增强了这一能力。这种基于组件的架构允许用户选择特定工具，而不是采用整个生态系统，使实施更加灵活并针对具体的临床需求。
- **清晰的许可**对于医疗机构的采用至关重要，因为许多排除了商业用途的开源许可也无意中排除了医院使用。Web工具可以帮助导航预先制作的许可（例如choosealicense.com），在编写自定义许可时也需特别小心。从法律角度来看，医院通常被视为通过患者护理产生收入的业务，即使它们是非营利机构，因此它们对软件的使用通常被视为商业用途。调查显示，知识产权和许可问题是主要障碍之一（表1）。虽然Web工具（如choosealicense.com）有助于导航预先制作的许可，但开发者必须尽早与其机构的技术转移或法律部门合作，以使FOSS目标与当地知识产权政策保持一致。为了帮助开发者和机构应对这些复杂性，表3总结了开源软件许可的关键考虑因素和实际缓解策略。

**临床采用开源软件的建议：**
- **集成和互操作性**对于开源软件在临床中的采用至关重要。能够与商业系统接口的解决方案（例如通过在商业系统中通过脚本运行软件或自动DICOM导入/导出）具有显著优势，因为它们允许医疗服务提供者利用开源创新，同时保持与现有基础设施的兼容性。
- **清晰的许可**对于医疗机构的采用至关重要，因为许多排除商业用途的开源许可也会无意中排除医院使用。Web工具可以帮助导航预先制作的许可（例如choosealicense.com），在编写自定义许可时需格外小心。从法律角度来看，医院通常被视为通过患者护理产生收入的业务，即使它们是非营利机构，因此它们对软件的使用通常被归类为商业用途。调查显示，知识产权和许可问题是主要障碍之一（表1）。
- **路线图设计**除了许可之外，明确的开发路线图提供了关于项目愿景和方向的必要清晰度。这些路线图有助于贡献者和用户理解项目的目标，帮助优先处理任务，并通过提供开发计划的透明度来建立信任。
- **风险分析**记录的失效模式和效应分析（FMEA）、危险测试和风险分析证据（例如TG100、ISO14971和DCB0129）对临床团队采用解决方案很有用[46]，并且可以与商业解决方案相比，但应强调采用实体需要进行实施风险管理。
- **预期用途和用户**建立正式的预期用途声明，并建立机制来展示谁在使用代码，例如合作列表，以及他们如何实施代码，这有助于建立潜在采纳者的信任。临床用户报告的最大障碍是不愿对代码负责（表1）。虽然无法完全消除绝对责任，但有时可以通过明确界定预期用途界限（例如仅用于研究目的）并将临床验证责任明确转移给采纳机构来缓解这种恐惧，详见第3.3节。
- **版本控制**清晰的版本控制区分了重大和次要更改，有助于临床用户理解更新的含义并相应地进行规划。
- **结构和文档**一般来说，遵循开发最佳实践可以大大提高开源软件的采用便利性和可信度。像CLEAR检查表[47]这样的资源提供了可操作的步骤，以确保发布的软件达到基准标准。此外，像ESTRO工作组（GitHub仓库）创建的这种模板这样的标准模板可以帮助项目领导者构建新工具并支持他们创建高质量软件。此外，越来越多的标准化标准可以帮助改善开源模型的采用[48][49]。这两种方法共同降低了分享和采用代码的障碍，促进了更高质量和更易于实施。调查显示（表1），“清理代码”的需求是研究人员面临的主要障碍。从项目开始就使用标准化资源（如CLEAR检查表或社区提供的模板）可以显著提高代码在分享时的准备程度。
- **AI辅助开发**AI辅助编码工具的迅速出现可能通过降低技术障碍、改进文档以及促进代码生成和维护来加速开源软件的开发。然而，依赖AI生成的代码引入了新的障碍，社区必须谨慎处理。其中最主要的是围绕AI生成片段的版权和许可的法律不确定性，以及将微妙的漏洞或“幻觉”引入安全关键临床软件的风险。因此，虽然AI可以加速开发，但它不能替代严格的人类监督、同行评审和自动化测试的需求。
- **安全性**在医疗环境中，安全性和合规性整合包括数据加密、访问控制和适当的隔离都是相关的。试点项目和分阶段实施策略允许控制逐步采用，尽量减少干扰。如果可能的话，直接比较开源工具和专有工具会很有帮助。应有一份处理常见漏洞和暴露（CVEs）的文件化方法。
- **监管合规性**最终，合规性是实施FOSS的团队的责任。然而，有几个特征可以帮助FOSS的采用：
- 明确的软件范围、要求和变更的可追溯性。
- 软件材料清单（SBOM，所有底层软件组件和依赖性的完整清单）。
- 用于发布管理和常见漏洞和暴露（CVEs，公开披露的网络安全漏洞）的程序化文档。
- 软件审计日志记录的机制（跟踪系统事件和用户操作，用于安全、调试和可追溯性）。
- **调试**调试确认开源软件功能正确并且在研究和临床使用中都是安全的。关键步骤包括定义预期用途、根据要求测试核心功能，并记录所有结果。对于临床环境，团队可以选择使用标准化协议，如安装资格（IQ）、操作资格（OQ）和性能资格（PQ），以确保在现实世界环境中的可靠性。保持验证记录的最新状态有助于审核和持续质量控制，帮助采纳者在不同的医疗环境中保持合规性和信任。
- **挑战**算法挑战对于透明比较和可复制的软件开发至关重要。特别是深度学习挑战已成为通过共享数据集、预定义的评估指标和公共排行榜进行强有力基准测试的工具。在放射肿瘤学领域，此类竞赛已经推进了包括分割[50]、[51]、[52]、合成CT生成[53]、治疗计划[55]、肿瘤追踪[56]和可变形图像配准[57]等任务。这些在Grand Challenge或CodaBench（前身为CodaLab）等平台上举办的倡议通常会产生经过策划的开源数据集和评估流程，为社区提供有价值的基准。虽然到目前为止这些挑战主要与深度学习相关，但类似的框架也可以扩展到其他类型的算法，提供结构和化的机制来评估和验证软件，以便在更广泛的临床采用之前进行评估。生态系统在三个领域运作：创新与发展负责生成核心算法和自由/开源软件（FOSS）输出；治理与质量保证作为关键的监管门户，管理员和风险评估人员通过它执行质量管理体系（QMS）；临床部署则代表医疗机构的本地验证和最终使用。经济模型通过双向资金支持（拨款和支持合同）得以维持，而持续的风险管理则通过从临床到开发者和验证者的直接反馈循环来维持。

**安全的共享方式**

如前所述，为医疗机构开发的软件通常符合英国、欧盟和美国的医疗设备定义，需要遵守相关法规（见“法规概述”部分）。在这三个地区，控制临床设备或影响临床决策的软件必须符合医疗设备法规。在英国和欧盟，内部使用可以免除全面符合性评估[58] [59]，但任何外部分发都需要监管批准和标记。健康机构豁免（HIE）在这些司法管辖区是一致的，具体标准和程序指导合规性。共享旨在用于研究目的但被临床团队采用的软件显然将责任置于临床机构。然而，由于欧盟和英国的MDR等法规的限制，共享由医疗机构为临床目的创建和使用的软件变得复杂。

一种共享软件的方式是仅共享那些不是作为临床软件设计的组件，而是作为研究或教育工具提出的。这一区分非常重要，因为它显著改变了监管要求。然而，这需要关于软件预期用途的明确沟通，并明确声明在没有接受机构适当验证和文件支持的情况下，该软件不应用于临床决策。即便如此，这可能仍不足以完全免除开源软件的机构责任[60]，建议直接与当地指定的监管机构进行讨论。

为非医疗设备软件共享开发专门设计的许可附加条款可以为社区提供更大的信心。这些附加条款应包含明确的语言，说明软件仅用于研究、教育或开发目的，而不是作为认证的医疗设备。它们应明确指出，任何临床应用都需要接受机构自行进行验证，并对其使用负责，尽可能由当地指定的监管机构指导。另一种更为彻底的方法是将临床应用版本和开源版本完全分开；有多种架构方法可以实现这一点，这有助于更清楚地区分用于临床的软件和用于非临床的软件，详见表4。

**表4. 可能具有临床可行性的软件共享方式**

| 共享方式 | 临床版本外观 | 开源版本外观 | 优点 | 缺点 |
|---------|-----------|------------------|-------|---------|
| 仅构建模块 | 临床软件使用共享文档或抽象接口实现（无直接开源代码） | 支持知识传递；通过避免代码共享减少机构责任；促进互操作性 | 缺乏可立即采用的 ??代码；实施质量不稳定；开发合规系统需要更多工作 |
| 仅许可证 | 经过本地治理的开源代码库的闭源副本，用于临床用途 | 开源代码库，仅许可用于研究/教育 | 简单；代码副本最少；确保每个人都使用相同的代码库；可以有单独的验证过程 | 许可限制可能限制采用；定制临床的灵活性较低；可能不足以免除机构责任 |
| 仅分叉 | 具有特定临床功能的独立临床软件分叉 | 公开的开源仓库，由社区驱动功能 | 维持开放开发；版本清晰；临床分叉可以独立进化 | 代码分歧；维护成本较高；可能重复工作 |
| 独立开源核心+商业扩展 | 基于稳定的开源核心构建的临床软件，加上专有的临床代码 | 平衡开放性和专有控制；临床代码可以严格管理 | 集成管理复杂；版本兼容性挑战 |
| Git子模块 | 临床软件包含作为受控Git子模块的开源核心 | 独立维护的开源核心 | 明确的依赖管理；便于重用稳定代码 | 仓库管理复杂；潜在的集成问题 |
| 插件架构 | 临床功能作为插件实现 | 核心软件保持完全开源 | 模块化、灵活的定制；易于单独开发临床功能 | 依赖管理复杂；插件兼容性问题 |

**提高可见性的平台**

除了上述关于操作性（如文档、许可、法规等）的实际障碍之外，改善资源共享的关键之一是提高现有倡议和开发软件的可见性。目前，寻求FOSS的用户往往依赖优秀但非正式维护的社区列表，例如GitHub上的‘awesome-medphys’仓库[61]，来发现可用资源。为了在这些社区努力的基础上进一步标准化发现性，ESTRO研讨会后成立的工作组提议开发一个集中式、用户友好的注册系统，以提高RT（放射治疗）软件工具和数据的可见性和可访问性。该平台将作为参考中心，链接到已建立的仓库（如GitHub、供应商网站（例如Varian或RaySearch）、针对特定主题的商业解决方案仓库（例如DLinRT.eu）或数据平台（如TCIA和cancerdata.org），以及更广泛的科学注册系统（如Papers with Code或机构支持的研究软件目录）。该注册系统将鼓励社区内的协作、验证和重用，提供丰富的元数据、持久标识符（例如DOI）和用户友好的提交模板。自动化、轻量级管理和质量指标（例如隐私声明、许可合规性和代码注释）将促进最佳实践，而不会设置出版障碍。理想的平台还将整合社区驱动的反馈工具，例如资源评分机制，使用户能够随时间评估相关性和质量。这个平台的开发目前是该工作组的持续努力。

这一倡议强烈强调开源和自由软件原则，支持允许重用、适应甚至商业部署的FOSS许可模型，前提是满足监管要求。在这方面，将鼓励开发者为现有FOSS项目做出贡献（例如通过拉取请求），而不是重复工作，从而培养可持续的创新生态系统。该平台将强制披露许可，并根据ISO 16290:2013标准促进工具技术成熟度（TRL）的透明跟踪。软件元数据标签可以帮助社区区分早期研究工具（TRL 4-6）和临床验证的原型（TRL 7–8），但临床部署（TRL 9）将要求机构负责监管合规性，例如之前讨论的欧盟MDR、美国FDA或英国MHRA法规。额外的功能，如与开源数据集的可选基准测试和专门的社区论坛，将进一步支持RT软件开发的可重复性和协作进展。

最终，共享信息与共享软件或数据集同样重要。以集中和可访问的方式编目正在进行的研究工作、商业工具和评估挑战，为社区增添了巨大价值。例如，最近的DLinRT.eu倡议提供了放射治疗领域深度学习解决方案的全面概述，主要关注商业解决方案，但也包括学术倡议（如SynthRAD [54]、StructSeg [51]等）。这使社区能够轻松比较产品并跟踪该领域的进展。将这些倡议整合和引用到注册系统中，将有助于维护与RT社区相关的资源和发展的动态、最新景观。

**讨论**

ESTRO关于开源放射治疗软件的研讨会讨论和后续分析突显了放射肿瘤学软件的一个核心矛盾。一方面， Clearly存在对适应性强的透明数字工具的需求，以支持研究、创新和临床工作流程。另一方面，目前对专有系统和孤立机构开发的依赖造成了信息壁垒，减缓了创新并限制了可重复性。开源模式提供了一个有吸引力的前进路径，但其广泛采用需要解决特定的文化、监管和运营障碍。

一个关键见解是，成功的资源共享必须超越软件代码，包括文档、临床协议、基准数据集和工作流程。ESTRO研讨会上展示的案例研究表明，即使是少量的共享，如脚本库或AI分割模型，也可以通过减少重复并提供基准标准来带来社区利益。未来，社区将从结构化的方法中受益，以促进信任、确保临床安全和管理责任风险。这涉及许可证的清晰性、仔细的风险分析以及反映商业解决方案已有做法的透明验证策略。继续需要发布清晰的成功案例，以帮助更广泛的社区了解如何在临床中实施FOSS。这应该通过新的文章类型来支持，例如《Green Journal》中的“如何”系列文章。具体来说，目前缺乏关于不同医疗机构如何正式监督、支持和负责物理师使用和开发软件的全面数据，以及这些过程在不同司法管辖区的差异。未来的工作必须系统地收集机构案例研究，以绘制这些多样化的治理策略。此外，科学期刊可以通过越来越多地鼓励或在出版物中强制共享代码来推动文化变革，例如通过特别问题和专用文章类型。为了直接解决我们在调查中发现的学术认可缺乏问题，还应利用专门的同行评审软件期刊，如《Journal of Open-Source Software》（JOSS）或SoftwareX，为代码库提供正式的可引用认可，除了现有的但非同行评审的可引用软件服务（如Zendo）。

几个主题被认为对维持进步尤为重要：
- **社区治理和可见性**：如果没有共同努力组织和维护集体项目，所进行的工作将保持分散状态。正如工作组所提议的，中央注册系统或元数据中心可以提供一个统一的框架。
- **指南和模板**：识别项目特性有助于创建高质量的FOSS，供社区采用。工具如CLEAR [47]、PROBAST [62]、TRIPOD [63] 促进最佳实践。
- **临床集成**：采用取决于与现有系统的互操作性、模块化架构以及研究和临床版本之间的明确区分。这些策略允许逐步集成，而不扰乱临床工作流程。
- **监管和安全**：开源软件在临床应用时仍需遵守监管要求。实用框架，如内部SaMD指南，可以帮助机构在享受FOSS灵活性的同时遵守监管要求。
- **保持动力**：除了正式出版物外，还需要定期研讨会、网络研讨会和在ESTRO和ICCR等会议上举办的专门会议，以维持对话、分享最佳实践并促进新的协作。

ESTRO关于开源放射治疗软件的研讨会展示了协调行动的意愿和可行性。专业协会在通过召集社区、支持标准和将资源共享纳入更广泛的专业发展框架方面发挥着至关重要的作用。此外，为了减轻个别机构面临的高昂监管合规负担，这些协会应考虑建立司法顾问委员会。这些小组可以提供模板化文档、标准化的风险评估表格和FOSS实施的同行指导。大学和培训项目也应将开源实践直接纳入医学物理课程中。此外，公共卫生系统和资助机构必须发展，以明确激励和财政支持这些共享资源的长期维护。随着时间的推移，通过认可、引用或资助机制来协调激励措施也将很重要。

**结论**

总之，资源共享和开源软件不仅代表了技术机会，也代表了放射肿瘤学的文化转变。通过将开源、协作的实践嵌入社区的基础设施中，该领域可以加速创新、促进公平的访问，并最终改善全球患者的护理。

**资金来源**

LB感谢EURATOM PIANOFORTE拨款协议101,061,037（DOSELIA），PID2022-140503OB-I00（由西班牙MICIU/AEI提供，https://doi.org/10.13039/501100011033）、ERDF/EU拨款以及GVA拨款CIPROM/2021/64的支持。MZ和AA感谢MSK Cancer Center的支持拨款/核心拨款（来自NIH，P30CA008748）。AB是FNRS – UCLouvain的研究助理。

**CRediT作者贡献声明**

- Samuel Ingram：写作 – 审稿与编辑，撰写原始草稿，资源整理，概念化。
- Lorenzo Brualla：写作 – 审稿与编辑，撰写原始草稿，资源整理，概念化。
- Alexia Delbaere：写作 – 审稿与编辑，撰写原始草稿，资源整理，概念化。
- Masoud Zarepisheh：写作 – 审稿与编辑，资源整理。亨德里克·皮尔斯马（Hendrik Piersma）：写作——审阅与编辑；写作——初稿撰写；资源支持
阿迪亚·阿普特（Aditya Apte）：写作——审阅与编辑
罗曼·路德维希（Roman Ludwig）：写作——审阅与编辑
埃里克·罗洛夫斯（Erik Roelofs）：写作——审阅与编辑；概念规划
马塞尔·纳赫巴尔（Marcel Nachbar）：写作——审阅与编辑
阿里·扎伊拉（Ali Zaila）：写作——审阅与编辑
克日什托夫·多马尼夫斯基（Krzysztof Domański）：写作——审阅与编辑
乔什·柯比（Josh Kirby）：写作——审阅与编辑
乔治奥·卡尔泰基尼（Giorgio Cartechini）：写作——审阅与编辑
托比亚斯·贝彻（Tobias Becher）：写作——审阅与编辑
萨穆埃莱·卡维纳托（Samuele Cavinato）：写作——审阅与编辑
戈兰·斯塔尼奇（Goran Stanic）：写作——审阅与编辑；资源支持
斯汀·科雷曼（Stine Korreman）：写作——审阅与编辑；资源支持
尼古拉斯·瓦尔（Niklas Wahl）：写作——审阅与编辑；项目管理工作；概念规划
乔什·梅森（Josh Mason）：写作——审阅与编辑；写作——初稿撰写；资源支持；项目管理工作；数据整理；概念规划
安娜·M·巴拉甘-蒙特罗（Ana M. Barragán-Montero）：写作——审阅与编辑；写作——初稿撰写；监督工作；项目管理工作；数据整理；概念规划