主题 1.6 — 临床安全与风险管理

一句话概括: 临床安全是一项有纪律的、有证据支撑的实践,用于找出你的数字技术可能伤害患者的方式,并在这些危害触及任何人之前加以控制——安全从第一张草图起就被设计进去,而不是在上线前才附加上去。

为什么这在医疗与照护领域很重要#

在大多数行业,一个软件缺陷只是个麻烦:一个页面加载失败,一份订单被重复提交,一份报告迟交了。在医疗与照护领域,同一类缺陷可能致命。一个截断小数点的用药字段、一个显示错误患者信息的结果界面、一个悄悄停止标记某种症状的分诊算法、一次悄无声息丢弃过敏记录的集成——每一个都是一个软件错误,也都是一个能够造成严重伤害或死亡的临床危害。这就是为什么临床安全不是叠加在良好工程实践之上的质量点缀;它是一门独立的、受监管的学科,有自己的标准、角色与证据。

其风险是不对称的,且往往不可见。当一个数字系统正常运作时,没有人看到它所防止的伤害;当它失效时,伤害可能是灾难性的、延迟显现的,并在有人察觉到某种模式之前就已经分散影响了成千上万的患者。这种组合——后果严重、可见度低、波及范围广——意味着你不能依赖用户去发现问题,也不能依赖事故来教会你一切。你必须在部署之前主动地推理危害,并在系统上线运行期间持续推理下去。在英国,这种主动的推理不是可选项:NHS 机构及其供应商在合同上与专业上都被期望应用国家级临床风险管理标准,并能够展示他们的工作过程。把这件事做对,与证据(见主题 1.3——循证决策)、与信息治理及网络安全(见主题 1.7——信息治理、数据保护与网络安全)、以及与你在系统上线后如何运营服务(见主题 3.8——服务管理与线上运营)密不可分。

核心概念#

患者安全与风险管理。 患者安全是对照护过程中患者所受伤害的预防、减少、报告与分析。临床风险管理把风险管理这门通用学科——识别、评估、排定优先级并控制风险——应用于一个具体问题:一个健康 IT 系统可能如何导致患者受到伤害。在英格兰规范这一点的两项国家标准是 DCB0129 与 DCB0160(DCB 代表数据协调委员会;这些是根据 2012 年《健康与社会保健法》强制要求的照护信息标准化委员会/SCCI 标准)。DCB0129 对健康 IT 系统的制造商或供应商施加义务;DCB0160 对部署与使用该系统的健康机构施加义务。两者是互补的:一份供应商干净的安全论证,并不能免除一家部署信托机构评估其自身配置、工作流程与情境所引入的危害的职责。

临床安全官(CSO)。 两项标准都要求一位具名的、具备恰当资质与经验的临床安全官——一位注册在案、目前仍在执业、完成了公认临床安全培训的临床医生——来负责临床风险管理活动,并亲自批准安全论证。CSO 这个角色是一项能力要求,而不是一个可以随意指派给谁有空谁来做的职位头衔。CSO 签核意味着危害已被识别并被控制到可接受的水平;这是一项带有专业问责的专业判断。

临床风险管理的成果文件。 三份文件是这门学科的支柱。临床风险管理档案是一个系统所有安全证据的容器。危害日志是一份鲜活的登记册,记录每一个已识别的危害、其成因、后果、风险等级、管控措施与剩余风险。**临床安全论证**是一份结构化的、有证据支撑的论证,说明该系统在其预期用途与预期情境下是可接受地安全的——并附有一份总结该论证以供批准的安全论证报告。这些不是为了文书工作本身而存在的;它们是让安全推理变得明确、可审查、可持久保存的方式。

危害分析:识别、分析、评估、控制。 核心循环是:危害识别(通过工作坊、临床走查、失效模式分析等方式系统性地设想系统可能如何导致伤害)、风险分析(估计伤害的严重程度与发生的可能性)、风险评估(将估计的风险与可接受性标准进行比较)与风险控制(引入措施——设计变更、警报、培训、程序——以降低不可接受的风险,然后重新评估剩余风险)。风险要被降低到合理可行的最低程度(ALARP):你持续控制,直到进一步降低所带来的收益与付出的代价严重不成比例为止。

医疗器械监管、MHRA与作为医疗器械的软件(SaMD)。 某些数字健康技术是受监管的医疗器械。具有医疗目的——诊断、预防、监测、预测、治疗——的软件,本身就可以是一件医疗器械:即作为医疗器械的软件(SaMD)。在英国,药品和保健产品监管局(MHRA)监管医疗器械,包括 SaMD,而软件生命周期标准 IEC 62304 规定了此类软件必须如何被开发。判断你的技术是否是一件受监管的器械,是一个后果重大的门槛性问题,它与 DCB0129/0160 临床风险管理并列,但相互独立。

数字技术评估标准(DTAC)。 DTAC 是 NHS 与社会保健机构在采购之前用来评估数字产品的国家基准,涵盖临床安全(DCB0129 合规证据)、数据保护、技术安全、互操作性与可用性。它不能替代临床风险管理;它只是检查供应商是否已经做了这项工作。

人因工程与安全文化。 人因工程(工效学)是对人在真实条件下——疲劳、打断、认知负荷、警报疲劳——如何与系统互动的科学研究。大多数数字化伤害并非源于"错误"的代码,而是源于那些让安全的行动变难、让不安全的行动变得容易的设计。安全文化是一种组织层面的承诺,让人们能够无咎地揭示、报告风险并从中学习——这是隐瞒未遂事件的团队与从中挖掘改进机会的团队之间的区别。

事故报告与学习。 在英格兰,**从患者安全事件中学习(LFPSE)**是记录患者安全事件的国家级服务,**患者安全事件响应框架(PSIRF)**规定了 NHS 机构如何应对事故并从中学习——强调基于系统、相称的根本原因分析,而不是追责。运行中的系统会产生新的危害,因此临床安全工作在上线之后仍会持续,通过事故反馈进入危害日志。

最佳实践#

1. 任命一位胜任的临床安全官,并赋予其真正的权力。 为范围内的每一个系统任命一位注册在案、正在执业、接受过公认临床安全培训的临床医生担任 CSO,并确保其签核是一道真正的关卡,而不是在发布前一天才走的过场。CSO 必须能够说"还不行",并且这句话必须被听见——这意味着要保护他们的时间、独立性,以及他们在项目委员会中的地位。一位被交付压力否决的 CSO,是一种治理上的虚构。

2. 尽早开展危害识别工作,并让临床医生在场。 从探索与设计阶段就开始危害工作坊,而不是在上线前才开始,因为最廉价、最有效的管控措施是在任何东西被建成之前所做的设计变更(见主题 3.5——交付生命周期)。请一线临床医生到场,而不仅仅是分析师,因为他们知道工作实际是如何进行的——那些打断、变通做法,以及凌晨三点一个界面被阅读的方式。走查真实的临床场景,不断追问:"这个系统可能如何导致一位患者受到伤害?"

3. 维护一份鲜活的危害日志,而不是一份上线当天的文件。 把危害日志当作一份从探索阶段开启、且在系统运行期间永不关闭的持久登记册来对待。每一个危害都记录其成因、潜在伤害、初始风险等级、所采用的管控措施,以及管控后的剩余风险。当一次事故、一次变更或一次未遂事件揭示出一个新的危害时,它就进入日志,并经过同样的循环被处理——这份日志就是你安全推理的记忆。

4. 让部署机构承担起 DCB0160 的责任,即使供应商是合规的。 供应商的 DCB0129 安全论证涵盖的是产品被构建时的状态;它无法涵盖你如何配置它、你在它周围包裹了哪些工作流程,或是你的哪些人群在使用它。为本地危害——与你其他系统的集成、你的数据质量、你的临床路径——运行你自己的 DCB0160 评估,并维护你自己的危害日志。假设供应商的保证涵盖了你的情境,是一条常见而危险的捷径。

5. 让风险控制与风险相称,并优先选择设计而非警告。 按强度对管控措施排序:把危害设计出去(约束条件、默认值、强制功能)胜过屏幕上的警报,警报又胜过培训手册里的一行文字。把最重的保证工作留给后果最严重的危害,对真正的低风险变更采用更轻、更快的流程——相称性正是让安全能够跟上交付节奏的关键。把风险降低到 ALARP,并记录为什么剩余风险是可接受的。

6. 为人因因素而设计,尊重警报疲劳。 假设用户是忙碌的、会被打断的、依赖模式识别的,并这样设计:让安全的行动成为容易的、默认的行动。警惕警报过载:一个触发过于频繁的警报会被忽视,因此每一个额外的警告都必须证明自己值得存在的位置,否则就会削弱那些真正重要的警报的效果。在现实条件下进行可用性测试,是一项临床安全活动,而不仅仅是设计上的点缀。

7. 刻意确定你的监管地位。 及早追问你的软件是否符合医疗器械或 SaMD 的定义,如果是,就从一开始就纳入 MHRA 的要求与 IEC 62304,而不是等到后期才发现这项义务。分类错误在两个方向上都代价高昂——一件未注册的器械是一次法律与安全上的失败,而把一个简单工具过度分类则会浪费稀缺的保证能力。有疑问时,寻求监管方面的建议,并记录推理过程。

8. 把 DTAC 当作底线,而不是终点线。 把数字技术评估标准当作任何被采购的数字产品的最低准入检查,确认临床安全、数据保护、安全性、互操作性与可用性已被处理。通过 DTAC 意味着供应商已经做了这项工作;它并不意味着该产品在你的情境下是安全的,因此要将其与你自己的 DCB0160 评估及线上监测配对使用。

9. 把线上事故的经验反馈闭环到危害日志中。 把你的事故报告——LFPSE 提交、PSIRF 调查、本地未遂事件报告——重新接入临床风险管理,使真实世界的伤害与未遂事件更新你的危害与管控措施。一份上线后从未被重新审视的安全论证会腐坏,因为运行中的系统、集成与临床实践都在漂移(见主题 3.8——服务管理与线上运营)。学习是基于系统、意识到责任分散的,而不是去寻找一个人来惩罚。

10. 建立一种公正、鼓励报告的安全文化。 让报告未遂事件、以及在安全理由上挑战一次发布,变得安全且理所当然,因为你从未听说过的危害,是你无法控制的危害。领导者要通过以好奇心与改进、而不是追责来回应坏消息,并把 CSO 的谨慎当作有价值而不是碍事的东西,来树立这种基调。文化是本主题其他每一项实践所依赖的基质。

与团队讨论的问题#

1. 在我们当前的项目组合中,我们在哪些地方依赖供应商的安全保证,来覆盖实际上应当由我们自己承担的风险? 这个问题探究的是 DCB0129/DCB0160 的划分,而团队常常把这条界线模糊化。供应商的 DCB0129 安全论证针对的是制造出来的产品本身,但当你配置它、把它连接到你的其他系统、在它周围包裹本地工作流程,并将其指向你特定的患者群体的那一刻,你就引入了供应商从未评估过、也不可能评估过的危害。诚实的张力在于,运行你自己的 DCB0160 评估要花费稀缺的临床与分析时间,而把供应商干净的保证与通过 DTAC 当作已经足够,是很有诱惑力的。梳理一次正在进行或即将到来的部署,具体地问:我们为它指定的具名 CSO 是谁,我们有自己的危害日志吗,哪些危害纯粹源于我们的本地情境而不是产品本身?一个好的答案会指出本地评估薄弱的具体系统,把产品危害与部署危害区分开来,并承诺承担起后者,而不是假设它们已被覆盖。

2. 我们的临床安全流程有多相称——我们是否在把低风险变更埋在文书工作里,而高后果的变更却凭借声势蒙混过关? 本主题主张保证工作应当与临床风险成正比:对后果最严重的危害给予最深入的审查,对真正低风险的地方采用更轻、更快的流程。这个问题检验的是你的机构是否真正在校准,还是套用同一个生硬的设置。两个失败方向都是真实且代价高昂的——一个一律沉重的流程会训练团队把临床安全视为一种官僚税,并想办法绕开它,而一个一律轻描淡写的流程会让一项用药剂量计算的变更以与一个帮助页面变更同样的力度获得通过。更微妙的危险在于,决定审查力度的是声势,而不是风险:一个受到高管关注的旗舰项目可能获得一种不可避免的光环,让 CSO 不敢说"还不行"。审视两三项风险明显不同的近期变更,问所投入的精力是否与潜在伤害相匹配,是否有人感到能够放慢那个高调的项目。一个诚实的答案会承认流程在哪个方向上被校准错了,并把相称性当作一种站得住脚的、明确的判断,而不是一种反射动作。

3. 当我们的某个数字系统差一点出问题时,接下来实际上发生了什么?一线临床医生会说提出这件事是安全的吗? 这个问题审视的是安全文化与事故学习闭环,这正是既定承诺与现实相遇的地方。临床安全依赖于听到未遂事件的消息,但人们只有在感觉报告是安全的、值得的,并且看到它带来改变而不是追责时,才会去报告。张力在于,在交付与声誉压力之下,本能是把一次未遂事件解释过去、迅速了结、继续前进——尤其是如果充分披露它会延误一次发布或让一位高级赞助人难堪。PSIRF 那种基于系统、意识到责任分散的方法之所以存在,正是因为寻找一个人来追责会抑制你所需要的报告,并错过真正的、系统性的成因。把讨论建立在一个具体的近期未遂事件或事故上:它被记录了吗,它进入危害日志了吗,是否进行了相称的调查,是否有什么真正发生了改变?一个好的答案会坦率承认报告是否真的感觉安全,把真正的学习与文书工作式的结案区分开来,并说出领导者将采取的具体行为,好让下一个发现危害的人敢于发声。

4. 我们是否诚实地确定过我们的哪些产品是受监管的医疗器械——谁对这个决定负责? 监管地位是一个后果极大的门槛性问题,而由于回答它可能带来不便,它很容易被搁置不答。能够诊断、预测、监测或治疗的软件,本身可能就是作为医疗器械的软件,这会引入 MHRA 的义务与 IEC 62304 生命周期标准——这与 DCB0129/0160 临床风险管理是分开的、额外附加的。这里的张力是双向的:分类不足会让你出货一件未注册的器械,这是一种可能在规模上灾难性地暴露出来的法律与安全失败;而把一个简单的行政工具过度分类,则会烧掉你在别处需要的稀缺保证能力。危险在于,分类的责任落在了各个角色之间的缝隙里——临床医生以为工程师决定了,工程师以为监管或商务团队决定了,而实际上没有人真正把推理过程写下来。具体地审视你项目组合中最接近这条界线的产品——任何带有分诊规则、风险评分或警报算法的东西——并追问是谁做出了器械判定、依据是什么,以及这个判定是否被记录并随功能变化而重新审视。一个诚实的答案会说出处于边界地带的产品,为每一个产品指出一个有记录、站得住脚的理由,并坦率承认这个决定在哪些地方实际上从未真正被做出过。

5. 我们是在把危害设计出去,还是在悄悄积累临床医生已经学会忽视的警报与警告? 本主题按强度对管控措施排序——把危害设计出去胜过屏幕上的警报,警报又胜过培训手册里的一行文字——然而警报是阻力最小的路径,因为增加一条警告既快又让人感觉负责任,而重新设计一个工作流程既慢又有争议。随着时间推移,这种偏向会积累成警报疲劳:警告触发得太多,以至于临床医生学会了对所有警告进行模式匹配式地忽略,包括那个真正重要的警告,于是每一个新警报实际上都可能降低安全性。真正的张力在于,每一个不必要的警报背后都有一位在某次事故后出于善意添加它的赞助人,这使得即使警告正在损害系统,把它移除在政治上也很困难。人因工程是这里的学科——设计出让安全的行动成为一个忙碌、被打断、在凌晨三点读屏幕的用户的容易、默认选择的方式——而在现实条件下进行可用性测试,是一项临床安全活动,而不是设计上的点缀。审视一个你的团队实际使用的系统,追问一位临床医生在一次典型任务中会遇到多少警报,其中有多少真正改变了行为,以及在哪些地方一个强制功能或一个更好的默认值本可以完全取代一个警告。一个好的答案会抵制再添加一个警报的冲动,把警报负荷本身当作一个可衡量的危害来对待,并愿意移除那些不再值得占据位置的警告。

6. 随着我们运行中的系统、集成与临床路径随时间漂移,我们如何知道我们的安全论证是否依然站得住脚? 临床安全不会在上线时就结束;运行中的系统会产生新的危害,一个系统周围的世界也在不断变动——一次上游集成改变了它的数据,一条临床路径被重新设计,一位供应商发布了一次更新,一个新的患者群体开始使用这个工具。一份两年前被批准的安全论证,描述的是一个可能已不复存在的系统与情境,因此问题在于你的危害日志是一份鲜活的登记册,还是一份被签署一次、此后就被搁置腐坏的文件(见主题 3.8——服务管理与线上运营)。张力在于,在上线后维护安全推理,与新的交付工作争抢同样稀缺的 CSO 与临床时间,而漂移是渐进且不可见的,很少能引起关注,直到某件事情失效为止。具体的切入点包括:配置或集成发生变化时重新触发危害评估的变更控制、对后果最严重的危害的定期审查,以及能够真正察觉某项管控措施正在悄悄失效的监测。挑一个已经上线一年以上的系统,追问它的危害上一次是什么时候被审查的,自批准以来其底层发生了什么变化,以及如果一项关键管控措施失效了谁会注意到。一个诚实的答案会把真正持续进行安全管理的系统,与依靠一份陈旧安全论证得过且过的系统区分开来,并承诺一个与真实变化挂钩、而不仅仅是依日历进行的、相称的审查节奏。

实践中:一个医疗与照护案例#

一个整合照护系统(ICS)正在部署一款共享的电子转诊工具,让全科医生能够直接把患者转诊到社区服务,并内置了一套分诊规则,将紧急病例导向一条更快的队列。一种由交付驱动的方式会直接采用供应商的 DCB0129 安全论证,通过 DTAC,并为了赶上董事会承诺的日期而直接上线。

相反,该项目任命了一位受过临床安全培训、正在执业的全科医生担任临床安全官,并在设计一开始就开启了一份临床风险管理档案与危害日志。与全科医生、社区护士与行政人员一起开展的早期危害工作坊,揭示出若干供应商产品层面的论证从未触及的危害——它们全都源于本地部署。最严重的一个是:分诊规则是依据 ICS 自己的服务定义来配置的,一个映射错误可能把一个紧急的皮肤癌转诊导向一条要等上数周的常规皮肤科队列。这个危害被评为高严重程度、可能发生。

在运用风险控制循环时,团队优先选择设计而非警告。他们加入了一个强制功能,使一个紧急临床标记不能被路由逻辑悄悄覆盖,一份由临床医生每日审查的核对报告,以及——在层级中最靠下的——一份培训说明。剩余风险被重新评级并判定为可接受且符合 ALARP;CSO 记录了理由。由于这个工具只做路由、本身不进行诊断,团队评估它未达到 SaMD 门槛,记录了这一推理并归档。人因工程测试发现了另一个问题:一个过于敏感的"重复转诊"警报触发得如此频繁,以至于全科医生已经开始忽视它,于是它被重新设计,只在真正的重复情况下才触发。

上线时,DCB0160 安全论证由 CSO 批准,而不是由项目总监批准。三周后,一份 LFPSE 报告与一位接待员标记的未遂事件揭示出一个新的危害——一个自由文本字段被用来夹带路由逻辑从未看到的紧急信息。在 PSIRF 框架下,一次相称的、基于系统的审查随即展开,该危害进入日志,一项设计变更被排期,一项临时管控措施在同一周内被下达。这份安全论证是一份鲜活的论证,记录清楚地显示了每一个危害是如何被推理的——这正是一位检查员、一位验尸官,或两年后一位新的 CSO 所需要的东西。

行业视角#

每个人都负有同等的控制临床风险的责任,但机制、激励与压力因机构而异。

初创企业#

一家数字医疗初创企业常常把临床安全当作一道采购关卡来遇到:一位 NHS 买家索要 DTAC 与一份 DCB0129 安全论证,于是一阵手忙脚乱随之而来。胜出的做法是从第一个冲刺阶段起就把临床风险管理构建进去——一份与待办事项并行的危害日志、一位触手可及的临床安全官(通常是合同雇用而非全职员工,但真正胜任且被赋权)——因为在一个已完成的产品上事后补装一份安全论证,既缓慢、昂贵,又缺乏说服力。创始人还必须及早诚实地面对 SaMD 问题,因为在规模扩张过程中才发现产品是一件未注册的医疗器械,是一种生死攸关的法律与安全风险。做得好的话,成熟的临床安全成果文件会成为缩短 NHS 销售周期的商业资产。

小型企业#

一家成熟的小型服务提供者——一家全科诊所、一家社区药房、一家养老院、一家居家照护机构、一家单一场所的诊所,或是一家已过预收入阶段的小型健康科技供应商——在部署与配置数字系统时,承担着与大型信托机构同样的 DCB0160 职责,却没有任何余力去履行它。这里通常没有专职的 CSO 或安全分析师,因此现实的路径是以合同方式聘请一位胜任的、正在执业的临床医生,并保持一份精简但真实的危害日志,而不是假装这项职责不适用。最尖锐的本地危害通常是配置与工作流程方面的——共享记录是如何设置的,紧急标记是如何处理的,一位兼职行政人员的变通做法如何变成一个路由风险——这些恰恰是供应商的 DCB0129 论证从未涵盖的危害。相称性在这里是小型提供者的朋友:把你仅有的一点保证时间集中在后果最严重的危害上,在选择产品时把 DTAC 与供应商的安全论证当作底线,并依靠诸如 ICS 临床安全支持这样的共享资源,而不是试图独自搭建整套机制。

大型企业#

一家 NHS 信托机构或 ICS 承担双重问责:它在 DCB0160 之下部署他人的系统,又常常在 DCB0129 之下构建或大量配置自己的系统。典型的失败是机构性的——一个上线日期具有政治分量的旗舰电子病历项目,使得 CSO 的谨慎被悄悄当作一种障碍。纠正之道是结构性的:赋予 CSO 独立性与真正的否决权,在整个资产范围内维护一份鲜活的危害日志,而不是一架上线当天文件的搁板,并把 LFPSE 与 PSIRF 的学习作为一项常设流程重新接入临床风险管理。在企业规模上,最大的危害是集成与配置方面的危害,没有任何供应商保证能够覆盖它们,因此本地所有权不容商量。

政府机构#

一个国家机构——NHS England、MHRA、DHSC、NICE——设定了其他人必须达到的标准,因此它的工作方式塑造了整个系统:DCB0129/0160、DTAC 与 SaMD 监管,都是人群规模安全的工具。这里的决策会吸引监管、议会与公众的审视,一个携带潜在危害的、全国强制推行的系统,会在有人察觉到这种模式之前,就把这种伤害分散到数百万人身上。这里的职责是在已发布的标准中把相称性明确化,对剩余风险保持透明,并让监管框架跟上技术——尤其是 AI——的超车速度(见主题 8.4——人工智能与新兴技术治理)。在这个规模上,独特的风险是系统性的:在薄弱的安全证据基础上在整个资产范围内强制推行一项技术,会在全国各地同时固化一种危害。

常见失败模式#

• 安全在末尾才被附加上去。 在上线前一周才产出一份安全论证以满足关卡要求。解药:从探索阶段起就开启危害日志;把最大的危害设计出去。
• 把供应商保证误认为本地安全。 把一份 DCB0129 论证与通过 DTAC 当作涵盖了你的部署。解药:拥有你自己的 DCB0160 评估与本地危害日志。
• CSO 沦为橡皮图章。 一位没有时间、独立性或权力说"还不行"的临床安全官。解药:保护这个角色,让签核成为一道真正的关卡。
• 僵死的危害日志。 一份写过一次、上线后再也没被重新审视的文件。解药:让它保持鲜活;把事故与变更反馈进去。
• 警报过载。 警告太多,以至于临床医生把所有警告都忽视了,包括那个至关重要的警告。解药:人因工程设计;每一个警报都必须证明自己值得存在。
• 追责文化。 因为未遂事件而惩罚个人,导致报告枯竭。解药:一种公正的、基于系统的、与 PSIRF 一致的文化。
• 错失的监管门槛。 在没有意识到 SaMD 是一件受监管器械的情况下就出货。解药:及早评估并记录医疗器械地位。

成熟度模型#

检查清单#

• 为每个系统指定了一位胜任的、正在执业的、受过培训的临床安全官,拥有说"还不行"的时间与权力。
• 范围内的每个系统都存在一份临床风险管理档案、一份鲜活的危害日志与一份临床安全论证。
• 危害识别始于探索阶段,并有一线临床医生在场。
• 部署机构已经运行了自己的 DCB0160 评估,而不仅仅是接受供应商的 DCB0129 论证。
• 风险控制优先选择设计消除,其次是警报,再次是培训,剩余风险被降低到 ALARP 并有理由说明。
• 医疗器械/SaMD 地位已被评估并记录,相关的 MHRA/IEC 62304 义务已在适用之处被纳入。
• DTAC 已作为底线完成,并与本地临床风险管理配对。
• 已在现实条件下完成人因与可用性测试;警报负荷受到控制。
• 线上事故(LFPSE)与 PSIRF 学习作为一项常设流程被反馈进危害日志。
• 报告未遂事件以及以安全为由挑战一次发布,是明显安全且理所当然的。

关键来源#

• NHS England ——DCB0129:临床风险管理:在健康 IT 系统制造中的应用。
• NHS England ——DCB0160:临床风险管理:在健康 IT 系统部署与使用中的应用。
• NHS England ——临床安全官培训 与临床风险管理指导。
• NHS England ——数字技术评估标准(DTAC)。
• MHRA ——作为医疗器械的软件与人工智能(AI) 指导。
• IEC ——IEC 62304:医疗器械软件——软件生命周期流程。
• ISO ——ISO 14971:医疗器械风险管理的应用。
• NHS England ——从患者安全事件中学习(LFPSE) 服务。
• NHS England ——患者安全事件响应框架(PSIRF)。
• 世界卫生组织 ——2021–2030 年全球患者安全行动计划。

参考文献#

1. Patient safety — Wikipedia — https://en.wikipedia.org/wiki/Patient_safety
2. Risk management — Wikipedia — https://en.wikipedia.org/wiki/Risk_management
3. Hazard analysis — Wikipedia — https://en.wikipedia.org/wiki/Hazard_analysis
4. Safety case — Wikipedia — https://en.wikipedia.org/wiki/Safety_case
5. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
6. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
7. Ergonomics (human factors) — Wikipedia — https://en.wikipedia.org/wiki/Ergonomics
8. Safety culture — Wikipedia — https://en.wikipedia.org/wiki/Safety_culture
9. As low as reasonably practicable (ALARP) — Wikipedia — https://en.wikipedia.org/wiki/As_low_as_reasonably_practicable
10. Root-cause analysis — Wikipedia — https://en.wikipedia.org/wiki/Root-cause_analysis
11. IEC 62304 — Wikipedia — https://en.wikipedia.org/wiki/IEC_62304
12. DCB0129: Clinical Risk Management in the Manufacture of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
13. DCB0160: Clinical Risk Management in the Deployment and Use of Health IT Systems — NHS England — https://digital.nhs.uk/services/clinical-safety/clinical-risk-management-standards
14. Digital Technology Assessment Criteria (DTAC) — NHS England — https://www.nhs.uk/digital-technology-assessment-criteria-dtac/
15. Software and Artificial Intelligence (AI) as a Medical Device — MHRA, GOV.UK — https://www.gov.uk/government/publications/software-and-artificial-intelligence-ai-as-a-medical-device
16. IEC 62304: Medical device software — software life cycle processes — International Electrotechnical Commission — https://www.iso.org/standard/38421.html
17. ISO 14971: Application of risk management to medical devices — International Organization for Standardization — https://www.iso.org/standard/72704.html
18. Learn from Patient Safety Events (LFPSE) service — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/learning-from-patient-safety-events/
19. Patient Safety Incident Response Framework (PSIRF) — NHS England — https://www.england.nhs.uk/patient-safety/patient-safety-insight/incident-response-framework/
20. Global Patient Safety Action Plan 2021–2030 — World Health Organization — https://www.who.int/teams/integrated-health-services/patient-safety/policy/global-patient-safety-action-plan