主题 4.4 — 联网设备、物联网与临床工程

在医疗与照护领域,联网设备是软件触及患者身体的地方,因此你如何管理输液泵、监护仪、扫描仪与可穿戴设备这支队伍,是一项临床安全、网络安全与公众信任决策,而不是一条设施类的预算条目。

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

一家现代医院运行在直接接触患者、持续与网络对话的机器之上。输液泵以微升为单位计量药物,呼吸机维持人的呼吸,监护仪监视生命体征,影像扫描仪发射电离辐射,楼宇管理系统维持着疫苗冰箱的温度。其中越来越多的设备是联网的:它们把数据推送进记录,从服务器拉取配置,并暴露管理接口。当其中一台表现异常时,这种失效不是一次不便的中断——它可能是一次剂量错误、一次被遗漏的警报,或一张被损坏、改变了诊断的影像。

这就是为什么设备管理坐落在你已经承担的三项职责的交汇处。它是一项临床安全职责,因为一次设备故障或一次糟糕的补丁可能伤害患者(见主题 1.6——临床安全与风险管理)。它是一项网络安全职责,因为联网的临床设备是整片资产中最大、治理最薄弱的攻击面之一(见主题 1.7——信息治理、数据保护与网络安全)。它也是一项监管职责,因为医疗器械是受监管的产品,承担着部分落在你——作为运营者——身上的上市后义务。

利害关系正在扩大,而不是缩小。照护正通过可穿戴设备与远程监测走进家庭,因此"设备资产"如今包括你不拥有、在你不掌控网络上的设备。设备的寿命远比其内部软件更长,因此一台为十五年临床寿命而购买的扫描仪,可能运行着一个五年后就失去安全支持的操作系统。勒索软件团伙已经学到,临床技术是脆弱的、未打补丁的、任务关键的——一种有利可图的组合。把联网设备当作别人的问题来对待,正是机构在一次事故中途才发现没有人拥有它们的原因。

核心概念#

一个医疗器械是任何由其制造商用于医疗目的——诊断、监测、治疗或预防——、且不通过药理学实现其效果的仪器、装置或软件。一个联网医疗器械增加了一个网络接口:它发送或接收数据,或能被远程管理。医疗物联网(IoMT)是更广泛的物联网(IoT)在医疗领域的应用——连接到网络并交换数据的传感器与日常物品的总称。在一个照护环境中,IoMT 涵盖床边监护仪、智能泵、可穿戴设备、家庭传感器,以及把它们缝合在一起的临床级中间件。

临床工程是生物医学工程之内的一个专业领域,负责在一个医疗机构中安全、有效地使用医疗技术。在 NHS,这些团队常被称为医学工程、医学物理,或电子与生物医学工程(EBME)。医疗器械管理是他们的核心学科:维护一份准确的清单、有计划的预防性维护、校准、维修、安全警报、培训,以及在生命周期终结时受控地退役。

运营技术(OT)是监测或控制物理过程与设备的硬件与软件,区别于处理业务数据的传统信息技术(IT)。临床设备与楼宇系统是 OT:它们具有真实世界的物理效果、长生命周期,以及在没有制造商许可的情况下让普通 IT 实践——重启、打补丁、替换——变得有风险或被禁止的约束(正常运行时间、认证、实时行为)。攻击面(attack surface)是攻击者可能进入或影响一个系统的所有点的总和;联网设备极大地扩大了它,因为每一台设备都是你网络上一台小型的、常常未被加固的计算机。

本主题中反复出现两项管控措施。网络分段是把一个网络拆分成隔离区域的实践,这样一个区域的攻破就不会自由扩散到其他区域——这是针对无法打补丁的临床设备最有效的单一缓解措施。资产可见性就是简单地知道你拥有什么:每一台设备、它的位置、固件、所有权、网络行为与支持状态。你无法保护、打补丁,或退役你看不到的东西。

最后是监管框架。在英国,药品和保健产品监管局(MHRA)监管医疗器械,上市后监测——在一款产品上市之后监测其安全性与性能——是制造商与使用并报告这些设备的运营者之间的共同义务。可穿戴技术与远程患者监测把所有这些概念延伸到了建筑物之外,进入了患者的家中与口袋里。

最佳实践#

1. 构建并维护一份权威的设备清单。 你无法管理、保护,或退役你没有清点过的东西。把临床工程的资产数据库与网络发现数据合并,这样清单记录的就不仅仅是品牌、型号与位置,还有固件版本、操作系统、网络行为、数据流、所有权与支持状态。把这份清单当作一个拥有具名负责人的、活的安全系统来对待,持续地对照网络上实际存在的东西进行核对,而不是一年为了审计才刷新一次的电子表格。

2. 把 IT、临床工程与网络安全纳入一个治理论坛。 这些设备落在三个团队之间,它们之间的缝隙恰恰是事故所在之处。建立一个联合医疗器械安全小组,对接入、打补丁、分段与退役拥有明确的决策权,并让它与临床安全职能保持一条常设的联系。临床工程师理解设备与患者风险;安全团队理解网络威胁;没有对方,任何一方都无法安全地行动。

3. 对网络进行分段,默认最小连接性。 大多数临床设备无法按你的时间表被加固或打补丁,因此要转而遏制它们。把设备放置在分段区域中,严格控制流量,只允许设备真正需要的连接,拒绝其余的,这样一次攻破就无法穿越整片资产。分段是让你能够继续运行一台临床上安全、数字上薄弱的设备的管控措施——它买到的时间,是单靠打补丁永远买不到的。

4. 把打补丁当作一项临床安全变更来对待,与制造商共同拥有。 一个受监管设备上的一次补丁,是对一款安全攸关产品的一次变更,应用一次未经验证的更新可能与留下一个漏洞一样危险。追踪制造商的安全公告与 MHRA 现场安全通知,对照制造商的指导验证更新,并通过临床变更控制排定它们的日程,配有后备计划。在一台设备无法打补丁的地方,记录已接受的剩余风险与补偿性管控措施,而不是假装这个缺口不存在。

5. 在购买之前就规划整个生命周期,包括生命终结。 一台设备的临床寿命常规地超过供应商的软件支持期限,造成数年不受支持的、如互联网般暴露的风险。在采购时,要求一份软件物料清单、一份明确的支持与打补丁承诺、设计上的安全特性,以及一个明确的支持终止日期,并依据这个日期、而不是机械寿命日期为替换做预算(见主题 6.3——采购与商务)。退役也是一个受控的步骤:清除患者数据、撤销凭证与网络访问权限,并更新清单,因为一台被遗忘在储藏柜里的监护仪,依然是一条活跃的入侵路径。

6. 安全、有意义地把设备数据接入记录。 联网设备的价值,是在读数准确地、配有正确的患者、单位与时间戳,以及清晰的溯源信息地流入临床记录时实现的。使用公认的互操作性标准与集成中间件,而不是定制的点对点链接,并验证每一次设备读数都能正确地映射到对应患者(见主题 4.3——互操作性与数据标准)。一个被归属到错误患者的生命体征,或一个含糊的单位,是一项打扮成集成便利的临床安全危害。

7. 为家庭、而不是病房设计远程监测与可穿戴设备。 当照护迁移进家庭时,你继承的设备连接着家用宽带、被家人共用、间歇性充电、由不适的人使用。要为连接性缺口、读数突破阈值时的清晰上报升级、数字包容,以及关于收集什么、谁据此采取行动的明确同意而设计(见主题 1.9——数字包容与无障碍,以及主题 3.3——面向患者与市民的数字服务)。对临床问责保持诚实:一条没有人配置资源去关注的家庭读数流,是一种虚假的安心感,而不是一项服务。

8. 演练设备的丢失,并向上报告故障。 假设某一类设备终有一天会不可用——通过勒索软件、一次召回,或一次网络故障——并演练临床后备方案,这样员工在事故中就不必即兴发挥(见主题 3.9——业务连续性与灾难恢复)。与此同时,把设备故障、未遂事件与不良事件通过黄卡计划反馈进 MHRA 的上市后监测,因为你的报告正是系统性设备缺陷在伤害别人之前被捕获的方式。

与团队讨论的问题#

1. 联网设备队列在其整个生命周期中实际上由谁拥有——今天 IT、临床工程与网络安全之间的缺口在哪里? 这一点之所以重要,是因为无人拥有的设备正是那些不被打补丁、不被监测、不被绘制,直到一次事故逼出这个问题的设备。在大多数机构中,临床工程拥有资产记录,IT 拥有网络,安全拥有威胁,而没有人把设备当作一个联网的、受监管的、面向患者的整体来拥有。讨论接缝在哪里:谁决定一台设备可以加入网络,谁验证一次补丁,谁签核退役,以及当一台设备既是一件安全攸关的仪器、又是一台脆弱的计算机时谁来负责。考虑你的治理论坛是否拥有真实的决策权与预算,还是一个把一切都上报升级、却什么都解决不了的清谈馆。一个好的、诚实的答案会为生命周期的每一个阶段说出负责任的负责人,承认今天答案是"没有人"的地方,并承诺关闭具体的缝隙,而不是重申协作很重要。

2. 我们实际上能看到多少联网资产?我们对这个数字有多大信心? 你无法对你没有清点过的设备进行分段、打补丁,或退役,然而大多数机构在一次事故期间才发现,他们的清单大大低估了现实——影子设备、供应商安装的设备、储藏室里被遗忘的设备,以及没有人编目的家庭设备。讨论你的清单是如何被构建与核对的:它是一份静态的电子表格,还是持续地与网络发现在网络上看到的东西相匹配?探究你团队信心的诚实程度——一个看起来精确、却没有核对流程的数字,比一句承认的"我们不完全知道"更危险,因为它滋生虚假的安心感。考虑最困难的类别:楼宇管理系统、第三方托管设备,以及患者家中的设备。一个好的答案会陈述一个现实的覆盖率数字,描述差异是如何被发现并关闭的,并把这份清单当作一个拥有具名负责人的安全攸关系统、而不是一份合规成果文件来对待。

3. 当一类这样的设备不可用、不安全或被攻破时,临床上会发生什么——我们曾经演练过吗? 联网设备是按类别、而不是逐台失效的:一次勒索软件事件、一个固件缺陷、一次召回,或一次网络中断,能够同时拖垮一整类泵或监护仪。讨论哪些设备类别如果丢失会造成最大的伤害,手动或替代的临床后备方案是什么,以及一线员工是否真正知道它、还是会在压力下即兴发挥。揭示可用性与安全性之间的取舍:保持一台脆弱设备在临床上继续运行的压力,与留下一个已知漏洞的风险之间,以及谁有权做出这个决定。考虑你是否能够侦测到一台微妙地表现异常的被攻破设备——一台报告看似合理、实则虚假读数的监护仪,比一台直接黑屏的监护仪更难被发现。一个好的答案会识别出伤害最大的类别,确认每一类都存在一份经过演练、配有资源的后备方案,并对依然存在的侦测盲点保持坦率。

4. 我们是在为一台设备的软件寿命采购与预算,还是只为它的机械寿命? 一台扫描仪可能拥有十五年的临床寿命,而其内部的操作系统在五年后就失去安全支持,因此今天做出的一项采购决策,除非有人为此规划,否则会悄悄让你承诺接受长达十年的无法打补丁的风险。讨论你的采购流程是否把软件物料清单、一份明确的打补丁承诺、设计上的安全特性,以及一个明确的支持终止日期当作合同条款来对待,还是当作在价格压力下会消失的锦上添花。探究谁掌握着替换预算,依据的是哪个日期——机械故障点,还是几年前就到来的软件支持终止点。考虑资产中已经存在的尴尬案例:在任何人问出这些问题之前购买的设备,如今已过支持期多年,却看不到任何替换资金。揭示想要最新能力的临床团队、想让资产物尽其用到物理寿命尽头的财务部门,以及看到日益增长负债的安全部门之间的张力。一个诚实的答案会把购买决策与全生命周期成本联系起来,说出谁拥有替换预算,并承认资产中哪些地方已经承载着未获资助的软件过时风险。

5. 对于正走进患者家中的设备,实际上是谁在关注这些读数——我们是否为使用它们的人而设计? 远程监测与可穿戴设备把设备资产转移到家用宽带上,被家人共用,间歇性充电,由不适的人操作,因此关于连接性、控制与支持的病房假设不再成立。讨论是否有一个具名的、配有资源的临床团队对据家庭读数采取行动负责,还是数据流入一个没有人有资金去关注的仪表盘——一种打扮成服务的虚假安心感。揭示数字包容方面的张力:一个家庭监测项目可能悄悄排斥那些没有可靠宽带、没有合适设备,或没有信心使用一台设备的人,加剧它本应缩小的不平等(见主题 1.9——数字包容与无障碍)。考虑同意与问责的清晰度——患者与照护者需要知道收集了什么、谁能看到,以及一次读数突破阈值时会发生什么。权衡快速扩展这些项目的拉力与让它们变得安全、公平的职责。一个好的答案会确认谁在关注并上报升级,对包容性风险保持坦率,并把家庭设备当作一项受治理的临床服务、而不是一条便利的数据源来对待。

6. 当一条设备读数抵达临床记录时,我们确信它是正确的值、正确的单位、正确的患者吗? 联网设备的临床价值,只有在其数据准确地落地记录时才能实现,然而每一次集成也是一次把一项生命体征归属到错误患者、或丢失一个数字背后单位与溯源信息的新机会。讨论设备数据是否通过带有明确患者匹配检查的、经过验证的互操作性标准与集成中间件流动,还是通过没有人完全理解的定制点对点链接(见主题 4.3——互操作性与数据标准)。探究那些看起来像便利、实则是安全隐患的失效模式:一个含糊的单位、一次时间错位的读数、一个被写入床边仍处于登录状态的上一位患者的值。考虑鉴于一个看似合理却错误的数字远比一个明显的缺口更危险,你要如何才能侦测到这样一个错误。揭示连接一台新设备的速度与让其数据可信的保证工作之间的取舍。一个诚实的答案会描述患者匹配与单位完整性是如何被端到端验证的,说出谁拥有这项保证,并把一次归属错误的读数当作它本来就是的那种临床安全事故、而不是一种集成上的麻烦来对待。

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

Meadowfield NHS 基金会信托机构运营着一家中等规模的急症医院,并日益运营着一个在家中监测患者的虚拟病房。在一家同行信托机构遭受了一次通过未受管理的临床设备扩散的勒索软件事件之后,Meadowfield 的董事会提出了一个简单的问题:我们有多少联网设备,谁拥有它们?诚实的答案是没有人能说清。临床工程的数据库列出了大约 6000 项资产;网络团队的被动发现工具看到接近 9000 个表现得像设备的东西。这个差距就是问题所在。

该信托机构组建了一个由临床工程主管与首席信息安全官共同主持的联合医疗器械安全小组,临床安全官列席参加。他们的第一项交付成果是一份核对过的清单:他们合并了两个数据源,追查了差异,发现了普通网络上的输液泵、一台运行着一个比支持期晚三个版本的操作系统的 CT 扫描仪,以及一组 IT 从未编目过的药房冰箱楼宇管理控制器。每一项发现都以临床风险等级、而不是纯技术等级被记录下来。

他们今年无法替换那台扫描仪,因此他们遏制它:把它移入一个严格分段的区域,只允许通往其影像存档与供应商支持网关的流量,已接受的剩余风险被记录并通过临床治理签核。这些泵被纳入一个对照制造商公告验证过的、受管理的打补丁周期,并通过变更控制排定日程。对于虚拟病房,该小组坚持要求家庭监测设备通过经过验证的、带有患者匹配检查的集成中间件报告进记录,并且一个具名的临床团队获得资源来关注并上报升级这些读数——而不是一个没有人拥有的仪表盘。

六个月后,一位供应商发布了一份关于一个监护仪固件缺陷的现场安全通知。因为清单现在是准确的、经过核对的,Meadowfield 在一小时内识别出了每一台受影响的设备,通过变更控制应用了经过验证的修复,并通过黄卡计划向 MHRA 报告了自己相关的未遂事件。这项工作并不光鲜——一份清单、一个论坛、一个分段项目——但它把一项不可见的、无人拥有的风险,变成了一项被管理的风险。

行业视角#

初创企业#

一家发布可穿戴设备或家庭监测设备的数字医疗初创企业,站在监管界线的制造商一侧,它的工作方式必须从第一天起就反映这一点。要以设计上的安全来构建:经过签名的固件、一条空中更新路径、一份软件物料清单,以及一份为已在外部使用的设备打补丁的计划——在一轮融资之后再事后补装安全性要困难得多。要理解你承担着不会因为团队规模小而缩水的上市后监测职责与 MHRA 义务,一家医院客户会在让你的设备靠近其网络之前评估你的安全态势。你的竞争优势不仅仅是这台设备,还有你将在其整个临床寿命期间支持并保护它这一可信的、有文档记录的承诺。

小型企业#

一家成熟的小型提供者——一家全科诊所、一家社区药房、一家养老院,或一家单一场所的诊所——运营着一支规模不大、却真实存在的联网设备队列:血压计、心电图仪、疫苗冰箱传感器、肺功能仪,以及日益增多的患者可穿戴设备,全部处于一个没有专职 IT 团队关注的网络上。同样的 MHRA、网络安全与临床安全职责适用,如同大型信托机构一样,但没有临床工程部门,常常也完全没有内部 IT,因此要从简单地知道自己拥有什么开始:一份简短、诚实的清单,记录品牌、固件与支持状态,胜过一个你无法维护的精心系统。大力依靠你的供应商与托管服务伙伴——坚持要求维护合同、打补丁责任与支持终止日期被写下来,因为你正依靠他们来获得你无法配置人手去处理的能力。把购买的时刻当作你的主要管控点,因为替换一台过时的设备对你而言往往比原地加固它更现实。把伤害最大的项目——一个装着冷链疫苗的冰箱、一台临床医生信任的监护仪——保持在扁平的办公室网络之外,即使完全的分段超出了你的能力范围。

大型企业#

一家大型 NHS 信托机构或医院集团,在一片庞大、长期存在的资产上管理着来自数十家供应商的数千台设备,它的挑战是协调与规模。现实的目标是一份核对过的清单、有纪律的分段,以及一个横跨临床工程、IT 与安全、拥有真正权力的联合治理论坛——而不是让供应商的约束条件变得不可能的、处处完美的打补丁。把设备安全嵌入采购之中,让支持承诺、设计上的安全特性,以及支持终止日期成为合同条款,并让替换预算与软件寿命对齐,而不是机械寿命(见主题 4.0——技术架构、云与遗留系统)。在这个规模上,最大的收获来自少数几项在整片资产范围内一致执行的管控措施,而不是在单台设备上的英雄主义。

政府机构#

一个国家或区域机构——NHS England、一个权力下放的卫生部门、MHRA——塑造着每一位运营者所处的环境。它制定设备安全标准与采购框架,运行国家级威胁情报与告警,使一个在某家信托机构发现的漏洞能够保护所有人,并监管设备及其上市后监测。它的杠杆,是通过标准与采购力量让设计上的安全与生命周期支持成为市场默认,这样单个信托机构就不必各自从一个弱势地位谈判安全性。政府还承担着公平职责:确保家庭监测与可穿戴设备项目不会加剧数字鸿沟,确保安全报告向上流动,使系统性设备缺陷能够在全国范围内被捕获,而不是被每家信托机构各自重新发现(见主题 9.1——与地方及中央政府合作)。

常见失败模式#

• 说谎的清单。 一份一年前最后核对过的整洁电子表格给人虚假的信心;真正伤害你的设备正是它从未列出的那些。持续地对照网络发现进行核对。
• 处于团队之间无人区的设备。 当 IT 说这是临床工程的设备、临床工程说这是 IT 的网络时,没有人为它打补丁、分段或监测。指定端到端的所有权。
• 打补丁的瘫痪或鲁莽。 两个极端都伤害患者——从不更新会留下已知漏洞,应用未经验证的更新可能破坏一台安全攸关的设备。让补丁通过联合临床变更控制。
• 为机械寿命购买,却忘记了软件寿命。 一台支持期只有五年操作系统上的十五年扫描仪,变成一项无法打补丁的负债。依据软件支持终止日期为替换做预算。
• 扁平网络。 普通网络上的联网设备让一次攻破能够触及一切。默认进行分段。
• 无人关注的家庭监测。 一条没有临床医生获得资源去据以行动的可穿戴设备读数流,是一种虚假的安心感与一项治理风险,而不是一项服务。
• 名不副实的退役。 一台已退役的设备仍在网络上,带着旧凭证与患者数据,是一条活跃的攻击路径。清除、撤销、断开连接,并更新清单。

成熟度模型#

检查清单#

• 存在一份权威的设备清单,持续对照网络发现进行核对,有具名负责人。
• IT、临床工程与网络安全的一个联合论坛对接入、打补丁、分段与退役拥有真实的决策权。
• 联网设备处于只允许其真正需要流量的分段网络区域中。
• 受监管设备的补丁与固件更新经过验证,并通过临床变更控制发布,配有后备计划。
• 采购合同要求一份软件物料清单、设计上的安全特性,以及一个明确的支持终止日期。
• 替换预算与软件支持寿命、而不仅仅是机械寿命对齐。
• 退役会清除患者数据、撤销凭证与网络访问权限,并更新清单。
• 设备数据通过带有患者匹配与单位检查的经过验证的集成抵达临床记录。
• 家庭监测与可穿戴设备项目拥有配置了资源的临床上报升级机制、明确的同意,以及设计上的包容性。
• 每一类高伤害设备丢失时的临床后备方案被记录并演练。
• 设备故障、未遂事件与不良事件通过黄卡计划向 MHRA 报告。

关键来源#

• MHRA ——《医疗器械:面向制造商、运营者与用户的指导》,以及针对不良事件与现场安全通知的黄卡报告计划。
• NHS England / NHS Digital ——《数据安全与保护工具包》与面向医疗与照护机构的网络/设备安全指导。
• NCSC(国家网络安全中心)——关于运营技术、网络分段与保护联网设备安全的指导。
• NHS England / IEC 标准 ——临床工程与医疗器械管理良好实践(包括 IEC 80001,用于纳入医疗器械的 IT 网络的风险管理)。
• NICE ——《数字健康技术证据标准框架》与关于远程监测及可穿戴设备的指导。
• 英国医学与工程物理研究所(IPEM)——临床与生物医学工程的专业指导。

参考文献#

1. Medical device — Wikipedia — https://en.wikipedia.org/wiki/Medical_device
2. Internet of things — Wikipedia — https://en.wikipedia.org/wiki/Internet_of_things
3. Clinical engineering — Wikipedia — https://en.wikipedia.org/wiki/Clinical_engineering
4. Biomedical engineering — Wikipedia — https://en.wikipedia.org/wiki/Biomedical_engineering
5. Operational technology — Wikipedia — https://en.wikipedia.org/wiki/Operational_technology
6. Network segmentation — Wikipedia — https://en.wikipedia.org/wiki/Network_segmentation
7. Attack surface — Wikipedia — https://en.wikipedia.org/wiki/Attack_surface
8. Medicines and Healthcare products Regulatory Agency — Wikipedia — https://en.wikipedia.org/wiki/Medicines_and_Healthcare_products_Regulatory_Agency
9. Postmarketing surveillance — Wikipedia — https://en.wikipedia.org/wiki/Postmarketing_surveillance
10. Wearable technology — Wikipedia — https://en.wikipedia.org/wiki/Wearable_technology
11. Remote patient monitoring — Wikipedia — https://en.wikipedia.org/wiki/Remote_patient_monitoring
12. Infusion pump — Wikipedia — https://en.wikipedia.org/wiki/Infusion_pump
13. Medicines and Healthcare products Regulatory Agency — Medical devices: guidance and Yellow Card reporting — GOV.UK — https://www.gov.uk/government/organisations/medicines-and-healthcare-products-regulatory-agency
14. National Cyber Security Centre — Guidance on operational technology and device security — NCSC — https://www.ncsc.gov.uk/
15. NHS England — Data Security and Protection Toolkit — NHS England — https://www.dsptoolkit.nhs.uk/
16. National Institute for Health and Care Excellence — Evidence Standards Framework for Digital Health Technologies — NICE — https://www.nice.org.uk/about/what-we-do/our-programmes/evidence-standards-framework-for-digital-health-technologies
17. Institute of Physics and Engineering in Medicine — Clinical and biomedical engineering guidance — IPEM — https://www.ipem.ac.uk/