具有生命体征流媒体基础设施的便携式手术室跟踪应用程序的开发和实现:操作可行性研究

简介

背景

儿科围手术期护理可能是一个繁忙而紧张的工作环境，在这个环境中，由临床医生(麻醉师、外科医生、护士和其他卫生专业人员)组成的多学科团队不断观察和评估患者信息[1-3.］．程序组的效率和患者安全取决于一个运作良好的团队[1，2];然而，数据通常仅限于特定位置，认知工作量可能很高，团队沟通受到可用性和不同优先级的限制[4，5］．即使是经验丰富的团队也面临着物理分离的挑战，需要通过传呼机和电话找到彼此。6］．

为了解决这个问题，我们的临床医生、工程师和计算机科学家团队开发了一个远程便携式手术室跟踪应用程序传送App)，提高麻醉团队成员之间的信息交流和沟通。它旨在将来自手术室(ORs)的生理波形和生命体征的实时馈送与消息、寻呼和提醒功能结合起来。

临床

BC省儿童医院(BCCH)是一个三级儿科医疗中心，每年约有11500名儿童接受手术、牙科手术、内窥镜检查、医学成像和其他干预手术的全身麻醉。在任何工作日，都有大约12-15名麻醉师负责不同的位置，包括核心8个ORs，肿瘤套房，x光，计算机断层扫描(CT)，磁共振成像(MRI)和超声室，以及烧伤治疗室。

他们的工作得到了一个麻醉助理(AAs)小团队的支持。这些是具有呼吸治疗背景的联合卫生专业人员，他们与主治麻醉师合作，确保设备得到维护和随时可用，并在需要时提供额外协助，以优化被麻醉儿童的安全。他们是一种有限的资源，因为在任何时候只有3-4个助理医师可用，而且他们经常忙于帮助启动复杂的手术，如心脏、神经或脊柱手术。每个AA通常支持多个麻醉位置，理想情况下需要能够监测多个患者的状态。他们必须对援助请求作出反应，并在可能的情况下随时了解导致求助的情况。

为了请求AA，麻醉医生依赖于一个数字的、单向的、基于电话的分页系统，从麻醉工作站使用该系统可能很麻烦，不能提供关于AA可用性或消息的紧急性的反馈，不允许双向通信，并且在AA不可用时不允许委派任务。尽管如此，寻呼方法已经很好地建立起来了，因为它是安全可靠的，当我们开始研究时，它仍然在BCCH使用传送项目。它让我们有机会通过双向、安全的沟通和信息来提高团队合作，以提高AAs的态势感知能力。

技术背景

手术室和重症监护室(ICUs)的生理多参数患者监测器从多个传感器和不同格式收集数据。例如，这些包括像心电图(ECG)这样的生理波形，心率和警报(例如，心动过缓[低心率])等数值数据就是从这些波形中推导出来的。大多数or和icu都是多床环境，其中单个患者监控器连接到支持事件记录、集中打印和远程警报监控的中央监控站。这些中心站是固定的，专有接口有限，这对其数据的二次使用造成了障碍。然而，如果这些数据可以在一个安全的移动平台上提供，最好是通过决策支持系统进行增强，那么就存在巨大的机会。

这些从生命体征中收集的数据，涵盖了广泛的设置和程序，对于研究、质量改进(QI)和回顾在正常临床护理中发生的不希望发生的临床事件或结果是有价值的。

在bch，手术室(包括美容后护理病房)和儿科ICU监测多种生命体征参数，并自动捕获并存储在中央工作站服务器中。然而，这些大量的数据通常在2-3天后被丢弃，只有少量的样本以不频繁的间隔(通常是5分钟、15分钟、1小时或4小时)手动或自动转录到患者的医疗记录中。为了克服这一限制，我们在2009年和2011年获得伦理批准，收集和存储来自OR和ICU儿童的所有生命体征数据，用于研究和QI目的。

LambdaNative是一个开源软件框架，设计用于开发医疗应用程序，促进确定性，健壮性和正确的代码[7］．它基于可移植的Gambit Scheme编程语言[8]并为在移动设备上开发图形应用程序以及在嵌入式平台上开发医疗仪器接口提供了灵活的跨平台环境[7］．它已被用于创建各种各样的应用程序，从用于低资源环境下多中心子痫前期试验的移动数据收集工具[9]，到关键任务，嵌入式药物输送作为闭环麻醉系统的一部分[10］．重要的是，我们确定了使用数据代理概念改善医疗设备数据交换的策略[11］．

研究目的

在这篇文章中，我们描述了它的发展传送手机应用采用以用户为中心的设计。我们还概述了提取监控数据、促进数据交换以及确保隐私和安全所需的后端基础设施(vititalnode)。本节包括一些技术细节，可能会对一些读者有所帮助(特别是那些没有麻醉信息管理系统的读者)。

方法

应用程序的主要功能

的目的传送是为了提高麻醉团队成员之间的信息交流，简化沟通。我们将设计重点放在五个关键功能上，所有这些功能都可以在屏幕底部的菜单导航栏(图1)．

概述屏幕

此屏幕提供关于用户订阅的患者监视位置的基本信息。显示的信息包括麻醉阶段指示器和三个生命体征:心率(HR)，氧饱和度(SpO)₂)，以及潮末二氧化碳浓度(etCO .)₂)．消息传递图标显示每个位置的未读通知数量(图1)．次要屏幕显示波形和其他数值，设计类似于患者监控器布局，或30分钟趋势屏幕，可通过选择位置(图1)．监控屏幕允许滑动在屏幕之间快速切换，并具有全屏模式，可以通过将设备方向更改为横屏来实现。这是在开发周期后期作为频繁请求的特性添加的。

消息传递的屏幕

该屏幕提供了个人对个人聊天和系统的结合，通过在手术室中按下病人监视器上的按钮来接收帮助请求。这两种类型的消息位于屏幕的两个独立区域，自动生成的消息(来自OR的帮助请求和来自提醒的通知)位于顶部面板，发送的消息位于底部面板(图1)．

‎ 查看此图

麻醉医师按下患者监控器上的物理快照按钮，发起来自手术室的帮助请求，在4秒窗口内按两次，发起紧急(STAT)呼叫。这些请求将提示显示一个弹出窗口。如果从弹出窗口或系统消息列表中选择，则会显示进一步的信息，包括来源位置、消息紧急性(“请尽快来”或“STAT请求”)，以及包括HR、SpO在内的一系列生命体征₂, etCO₂呼吸频率(RR)和血压(NIBP)。该应用程序允许一个好的或忽略的响应(图1)．如果用户按“忽略”键，或在5分钟内未确认，则告警升级到所有已登录系统的用户。紧急(STAT)消息将发送给所有用户，而不管他们订阅到哪个位置。在请求中提供生命体征可以让接收消息的用户在到达之前获得一些有关情况的信息，以提高对情况的认识[1，12，13］．

对于个人对个人的消息系统，我们支持快速短信，有10个选项，包括“是”、“否”、“您能帮忙吗?”，“在办公室见面”等等，还有一个带有屏幕键盘的常规两人聊天系统。快速文本列表是通过向麻醉助理询问最常用的文本来开发的，而不是通过某种类似于自学的方法。特殊用户(ALL)允许将消息发送给所有用户，但由于没有实现群聊天，响应只会到达发送方。

电话簿屏幕

该屏幕列出了常用的电话分机，如每个手术室，生物医学工程部门和呼机号码，并可以在应用程序中编辑。我们设想在该屏幕上添加互联网协议语音(VoIP)功能，但从未完全实现。

位置订阅界面

此屏幕显示用户订阅了哪些位置，以及从该位置请求信息的其他团队成员。用户可以订阅或取消订阅每个监视位置，订阅可以委托给其他用户(收件人必须接受转移)。最初的设计需要一个可视化的地图，上面有心脏、牙科、神经外科、骨科和其他手术室的图标，允许用户根据他们的物理距离选择位置。后来它被修改为一个简单的列表，因为它使用起来更快，而且分配更频繁地基于案例的复杂性而不是物理上的接近性。

屏幕提示

第五个屏幕允许用户根据时间或麻醉阶段设置提醒(图1)．对于基于时间的提醒，用户可以选择时间(使用滚动轮以小时为单位，以5分钟为单位)、提醒频率(无、15、30、60、90、120和300分钟)和任务(“检查房间”、“绘制ABG”和“会议”)。基于麻醉阶段的提醒，只选择位置、任务和麻醉阶段符号。一种特殊的空房间循环模式允许在房间状态变为空的时候重复提醒，直到一天结束。它是用于高周转清单，如内窥镜，在那里进行频繁的补充，在一天。反复提醒是支持动脉血气(ABG)工作流程的要求功能，在该工作流程中，麻醉医师定期(例如，每2小时)抽取血液样本，然后麻醉助理将其带到护理点分析设备进行处理，然后将结果返回手术室。

vititalnode服务器组件的开发

多参数患者监控器通过专用以太网将实时数据传输到中央工作站。为了克服对专有中央站接口的有限访问，我们直接拦截原始以太网数据包。

我们最初在连接主OR和ICU交换机的以太网电缆的传输线上使用了无源网络抽头，将数据从监视器聚集到中心站。这些连接到一个网口，该网口被设置为监控(混杂)模式，以收集接收到的网络流量。在后来的迭代中，我们桥接了两个网口，因为这种解决方案更容易在更新的100兆全双工网络上实现，该网络自动分配接收或发送线对。完成这项工作的设备被称为“vititalnode”。“我们对数据采取了一种混合方法，存储原始数据，但也会实时分析以进行处理(图2)．

‎ 查看此图

实时数据解析

对网络流量的实时解析包括对Philips和GE或Datex监控通信协议的数据帧进行解码。Datex协议准确地在编程指南中发布，而Philips协议有使用经验分析解码的无文档头数据结构。出于性能考虑，我们选择使用内核级过滤器，将解析限制在我们知道解析器可以分析的类型的包中，并且其中包含对我们的目的有用的数据。

vititalnode应用程序执行了几个任务，包括:1)从所有可用的生命体征(如SpO)中提取关键的生理趋势数据₂， HR，温度)10秒(Datex显示器)或1秒时间分辨率(飞利浦显示器);2)解析告警数据;3)根据供应商和变量，以25 - 500赫兹的分辨率解析相关生理波形数据(如心电图、容积描记仪);4)提取人口信息(很少输入)。

这些数据以逗号分隔值(CSV)格式写入磁盘以供以后使用，分离所有可能捕获的潜在变量的5秒或10秒间隔趋势文件。然后，在传感器发送有效数据时写入波形文件，简化数据提取和处理。数据保存在内存中，用于流应用程序中近乎实时的数据访问。vititalnode还存储了在传送应用程序，通过提供者(允许人与人之间的通信)和监视器位置(存储系统生成的消息，这些消息对某个位置的所有订阅者可用)。

该应用程序聚合了30分钟的趋势数据(10秒分辨率)，便于显示。它还应用了一些简单的数据处理，包括麻醉相位指示器。这使用了一个简单的4状态机，基于三个常用传感器(SpO和SpO)的有效值是否存在₂人力资源等₂，使用30秒平均值)。这使我们能够确定病例是否已经开始(麻醉诱导，一个传感器存在)，是否处于病例中间(麻醉维持，三个传感器都存在)，是否接近病例结束(麻醉恢复，一个传感器关闭)，或者是否房间是空的(没有传感器报告有效数据)。为避免在体外循环期间出现问题，etCO值为零₂被认为是有效的，而空状态或错误状态被认为是无效的。

原始数据存储

我们在10分钟内使用原始网络包捕获(PCAP)文件，使用bzip2压缩，有两个原因:1)这些文件有效地使用磁盘空间;2)这种方法允许我们捕获数据解析器中没有实现的数据元素，并从解析器代码中的潜在错误中恢复。

telePORT客户端组件的开发

采用以用户为中心的设计过程[14］．最初，三位助理助理在两个白班期间被跟踪，以确定他们的信息需求、沟通和提醒策略以及任务计划方法。结合半结构化访谈，这些数据被用来创建一个修改的工作域分析[15，16]，它建立了领域的层次模型，并允许对应用程序需求进行规范。接下来，我们对手机app进行了参与式设计[17-19，我们经常寻求对设计功能的反馈，最初使用PowerPoint开发的模型(微软，西雅图，华盛顿州)，后来使用iPod touch上展示的部分工作原型(苹果，库比蒂诺，加利福尼亚州;图1)．

我们使用LambdaNative［7]以快速开发一款可在小型移动平板电脑或智能手机上运行的移动应用程序，例如第四代iPod touch，其有效屏幕分辨率为480x320像素。最初的开发是在Linux机器上进行的，iOS构建过程只在Mac上执行，因此突出了跨平台功能的一个优势LambdaNative环境。原型组件实现后，AAs和研究团队成员进行了快速的可用性测试，然后根据获得的反馈进行了修改。该应用程序使用苹果开发者配置文件部署在iPod touch上。修改后的版本(没有持续的后台处理和连接)可在苹果应用商店[20.］．

评估方法

在获得英属哥伦比亚大学儿童和妇女健康中心英属哥伦比亚研究伦理委员会(H11-01785)的批准和书面知情同意后，我们使用混合方法建立了AAs的基线工作量:我们使用步进计数器来获得旅行距离的代理，以及收到的页面数和这些请求的紧迫性的每日日志。我们原本打算重复这些之后传送应用程序的实现，但数据是高度可变的，数据收集并不总是全面的，因为用户认为它太繁琐，所以我们决定不这样做。

评价的使用传送应用程序，我们使用了AAs通过电子邮件或口头信息提供的正式和非正式反馈，并量化了使用模式VitalNode基于数据的记录。以CSV格式记录用户登录、注销、断开连接(客户端连接丢失超过60秒)、导航屏幕、消息发送方和接收方以及系统生成的页面的时间戳数据VitalNode服务器。使用R (R Foundation for Statistical Computing, Vienna, Austria)对数据进行解析，并绘制图进行分析。我们使用电池使用量作为设备使用量的替代品(将其从充电站中移除使用)，并定量地探索消息频率和页面数量。Cytoscape(系统生物学研究所，西雅图，华盛顿州)被用于通过创建应用程序屏幕日志序列的双向图来绘制导航流。

结果

基线步骤和寻呼机跟踪

从2011年10月到12月，总共完成了27份数据表(估计有10-15%的轮班工作)。中位数(四分位范围[IQR])步数为每班6426 (IQR 5163-8910)，或每小时627 (IQR 451-784)。在此期间，aa报告了34页，每班的中位数为0 (IQR 0-2.5)，每个原因包括12/34例(36%)的设备原因，14/34例(41%)的临床原因，8/34例(24%)的行政原因。

电池和系统使用情况

的早期版本传送在6-7小时内耗尽了iPod touch(第四代，iOS 5.1，屏幕关闭)，这不足以用于临床使用。Code经过优化，降低了中央处理单元(CPU)的使用率，实现了平均每小时9.04%的电池耗电量，这使得两次充电之间的电池寿命为11小时。

在评估期间，传送仅由麻醉医师使用(而不是由麻醉师或麻醉师负责)。2013年1月7日至2013年12月9日这337天的数据被用来分析使用情况，因为这段时间正好是使用高峰，并且是连续可用的。电池消耗(作为应用程序使用的替代品)显示，使用模式与预期使用重叠，主要是在工作日或时间段，从7小时开始，高峰使用时间在9小时到17小时之间，一直持续到19小时左右(图3)．

虽然在评估期间使用情况变化很大，每天使用的设备中位数(IQR[范围])为1.45(1.0-2.0[0.01-3.7])，但在观察期结束时，使用情况持续下降(每天使用-0.3%)。这种下降部分归因于用户报告的网络通信问题，但也可能表明工作流集成问题。

‎ 查看此图

通信流程和系统导航

手术室共记录327条信息(约每天1条)和1528条求助请求(约每天4.5条)。消息传递模式分析发现，沟通流程以一个AA (AA5)为中心，他不是团队领导(图4)．请求帮助的分布显示，OR7(脊柱外科)的数量超过了其他位置，但OR1也有一个明显的模式，即在周二和周五达到峰值(通常是神经外科)。时间分布并没有显示出任何令人惊讶的模式，除了在中午新病例开始时消息数量达到峰值(图5)．

最常用的功能是消息(30%)、概述(20%)、页面或警报(19%)和波形(14%)。集成聊天屏幕很少被使用(2%)，这表明比起自由文本交流，他们更喜欢使用10种快速文本。由于导航栏允许在五个主要功能之间进行即时导航，只有子屏幕导航显示定向导航模式的迹象(例如，从提醒设置转到提醒设置)。

‎ 查看此图

‎ 查看此图

讨论

主要发现

我们开发了传送改善麻醉团队成员之间信息交换和沟通的应用程序，包括消息传递，帮助请求(分页)和提醒功能。此外,传送提供来自手术室的实时波形和生命体征。遵循以用户为中心的设计原则，开发了应用程序的用户界面，传送在11个月的时间里，bch的助理工程师们用它来支持他们正常的日常活动。手术室中来自麻醉医师的帮助请求(约4.5次/天)多于团队成员之间的信息(约1次/天)，但被动手术室监测也被频繁使用(占屏幕访问的34%)。无线连接的间歇性中断导致使用量稳步下降(-0.3% /天)，该项目最终停止。底层服务器基础设施已被证明非常有价值，并继续为研究和QI目的自动收集OR和ICU数据。

团队沟通和态势感知

利用传送在寻呼(请求帮助)功能上比在aa之间交换信息时更高，这表明麻醉师喜欢请求额外人手的简单方式。数据还表明被动OR监测很常见。这可能增加了AAs的情景感知能力，从而避免了对分页功能的额外使用。

人们担心在手术室使用智能手机可能会传播感染，分散麻醉团队成员的注意力，以及干扰医疗设备[21];然而，它们可以改善团队沟通，并提供重要的学习工具。21］．重症护理领域的应用程序正在出现。22]，包括提供实时生命体征监测、警报通知和提醒的护士观察应用程序等工具[23]，以及一个与病人的电子健康记录同步的微博消息平台，并为制定和分享护理计划提供一个论坛[24］．

在围手术期，VigiVU应用程序(范德堡大学)[25]为麻醉护理提供者提供生命体征偏离、患者位置变化的通知，便于团队沟通，并提供每个手术室的高质量视频视图。这个系统是由一个更大的团队开发和实现的，比传送．让其他研究人员从我们的经验中学习并继续发展传送和vititalnode供其他机构使用，它们的源代码已在LNhealth Github存储库中免费提供(在伯克利软件分发许可证下)[26］．也许是最大的成就传送开发过程是将生命体征实时传输到其他设备，用于临床研究和QI项目中的数据收集。vititalnode，类似于密歇根大学正在使用的系统[27]，促进了我们机构在一系列研究和质量改进研究中使用生命体征数据[28-31］．

实现问题:连接和电池寿命

主要的可行性挑战是医院的无线区域网络反复出现问题。这导致了使用量的下降，并最终终止了该项目。在测试时，信号强度被认为是足够的，即使是在巨大的混凝土墙存在的情况下，但失去连接的问题(或者，具体地说，无法从动态主机配置协议[DCHP]服务器重新获得互联网协议[IP]地址)无法通过医院网络克服。我们调试该问题的能力有限，而且我们无法确保在所有接入点上启用便于切换的网络功能(例如电气和电子工程师学会802.11k和802.11r)。这也可能是我们使用的移动设备(iPod Touch)的限制。如果我们使用带有数据计划的蜂窝网络设备，我们可能会使用苹果推送通知，这已被证明是一种特别可靠的消息交换模式，甚至比常规的寻呼网络更好[32］．

VigiVU的开发者也注意到了类似的限制，他们需要继续使用传统的寻呼机，因为在某些无线接入点之间切换时，连接性会短暂地受到影响。虽然无缝交接已有所改善，但机构仍须致力提升及维持无线网络基础设施[27］．

在设计阶段，曾有人担心iPod Touch电池的电量不足以支撑整个轮班的使用。事实证明，这个问题比我们担心的要小，电池每小时消耗大约9%，足以维持一个典型的轮班。VigiVU应用也有类似的发现，在11个小时的工作结束后(从充满电算起)，电池的待机时间约为25%。25］．

移动应用程序和决策支持系统

的传送应用程序直接从手术室患者监测系统中提取数据，但在一些机构中，可以使用从麻醉信息管理系统(AIMS)中提取的数据，该系统提供了接近实时的临床决策支持(CDS)。例如，智能麻醉管理器的使用(SAM，华盛顿大学，西雅图，美国)[33]表明β受体阻滞剂和葡萄糖管理方案的依从性改善[33，34]，减少血压监测的差距[33，35]以及低血压的持续时间和频率[36]，甚至建议削减一些成本是可行的[33］．在其他病例中，术中CDS对抗生素管理和临床记录显示出类似的好处[37］．然而，流程度量的改进，如协议遵从性，并不一定转化为改善的结果[34，38］．此外，开发这样的系统提出了许多挑战，包括需要证明结果改善，对患者安全的影响，符合监管要求[39]，而采用相对简单的方法，可能更容易取得某些改善事后报告(29，40］．

限制

同时评价传送App由于一个无法克服的技术问题而被终止，在对此或类似计划进行任何进一步工作之前，应该注意到该研究的几个缺点。应用程序的总结性评估应该包括某些维度，我们不能在这里报告。对包括麻醉师在内的所有相关利益相关者进行结构化的实施前和实施后调查，可能就应用程序的好处和流程改进提供了有用的意见。基于机管局对关键事件的反应时间，也可能建立一个可量化的措施来衡量机管局的态势感知。这应该包括提供有意义的援助的时间以及到达，因此需要一个仔细的和商定的定义。

我们没有获得应用程序发送消息(求助电话)的原因记录，包括任何虚假警报的发生，这将为应用程序的效用提供另一种有用的衡量标准。最后，虽然在我们机构的患者安全和学习系统中没有记录与使用应用程序相关的不良事件，但我们也没有实施任何措施来跟踪应用程序的警惕性或导致的临床错误。要推进这一项目，需要明确定义现有护理模式的潜在影响点，并在实施后进行评估。

未来的工作

应用程序等传送和VigiVU有可能加强与电子麻醉记录的集成，并支持决策支持工具、调度系统和仪表板，以改善围手术期数据流和团队沟通，并提供双向数据馈送。它应该是可以修改的传送使用使用蜂窝数据的苹果推送通知来实现更好的连接，并使其在苹果商店中可用，因此麻醉团队的所有成员都可以使用(安全)自带设备的模式。

的传送该应用程序是为一小群麻醉医师设计的，支持更多的麻醉医师，但它也有潜力作为一个便携式工具，为单个麻醉医师监控多个手术室或程序套件，可能支持学员或其他护理提供者。在这两种情况下，该工具功能的一个重要补充将是通过确认已收到消息来实现闭环通信。

下一步，我们的研究小组已与儿科重症监护临床医生密切合作，开发和评估初步的低保真VitalPAD原型，这是一款旨在提高ICU临床决策、沟通和患者安全效率的应用程序[41］．该应用程序最终将把来自多个监测和治疗设备的信息整合到一个移动应用程序中，其中包括ICU的地图概述，显示临床医生分配、患者状态和呼吸支持，以及显示患者生命体征、ABG结果照片记录、团队沟通和提醒的功能。

的传送App和其他研究团队的相关项目展示了创新、临床相关、实时应用的潜力。研究团体将从生命体征流的开放协议中受益匪浅，这将使新的智能应用程序能够快速开发并部署在医院环境中，为医疗保健专业人员、研究人员和患者带来直接利益。为物联网开发的协议可能提供一种已经得到强大社区支持的解决方案[11］．

结论

我们演示了麻醉团队的日常活动可以通过一个移动应用程序来支持，该应用程序集成了从手术室监视器实时收集的数据，用于麻醉医生发送帮助请求，以及团队通信功能。我们克服了重大的技术挑战，受益于以用户为中心的设计，并能够与我们机构的aa演示可行性。我们站点的本地无线网络问题阻碍了全面实施，但收集和存储OR数据的vititalnode服务器基础设施继续受益于正在进行的研究和QI计划。