1.简介
医疗保健通常被视为采取预防性或必要的医疗程序来改善一个人的健康状况。此类程序通常通过由医院和专业人员（如全科医生、护士、医生等）组成的医疗系统提供，这些人员在多学科环境中工作，承担着复杂的决策责任。
随着2000年代中期先进健康信息技术（HIT）和电子健康记录（EHR）的出现[1]，医院开始以电子方式管理和共享患者信息，而不是通过纸质记录。这导致越来越多的手写移动技术和设备被使用，这些技术和设备能够与EHR系统同步，从而允许医生从远程位置访问患者记录，并支持他们执行护理程序。因此，医生访问患者时同时与多个移动设备进行交互是很常见的。 尽管EHR系统和移动技术有利于改善护理程序的交付[2,三,4,5]，也有迹象表明，它们的使用可能会对以患者为中心产生负面影响[6]. 这通常会导致医生在探视患者时付出更大的体力和认知努力，使他们更容易犯医疗错误[7]失去与患者的融洽关系[8,9]. 然而，正如[10]，通过EHR系统进行多任务和信息传输已成为医疗环境的必要方面，这是无法完全避免的。 虽然到目前为止，实现一种技术解决方案是可取的，该解决方案支持医生通过移动设备制定护理程序，使用移动设备需要有限的物理/认知努力，并确保通过EHR系统的信息流的连续性，大多数现有的解决方案只关注上述需求的一个方面或它们的部分组合[11]. 一方面，人机交互（HCI）社区已经调查了多模式界面有可能减少用户管理复杂活动（如临床活动）的认知努力。例如，在[12]，作者表示“随着任务难度和通信复杂性的增加，负载增加，多模式界面用户通过转向多模式通信，自发地响应自己认知负载的动态变化”. 此外，Pieh等人最近的研究[13]已经表明，与单一的医疗模式相比，多模式医疗模式能够提供最有效的结果。 另一方面，业务流程管理（BPM）社区已经研究了如何组织结构良好的临床活动医疗保健流程并通过使用专用的过程感知信息系统（PAIS）自动执行。PAIS能够解释这些过程，并通过调用（必要时）外部工具和应用程序，向医生和医务人员（例如护士、全科医生）提供相关信息、文档和待制定的临床任务[14]. 尽管如此，由预定义规则列表驱动的当前BPM解决方案已被证明仅适用于管理较低级别的管理流程，例如预约，但在核心护理流程方面进展甚微[15]. 基于上述内容，本文介绍了意大利项目TESTMED（TESTMED是一个为期24个月的意大利项目，代表“meTodi e t Ecniche per la geSTione dei processi nella MEdicina D'urgenza公司“，英语：”应急医疗过程管理的方法与技术“），其目的是设计和开发一种临床PAIS，称为TESTMED系统，该系统研究触摸和声音界面，作为一种潜在的解决方案，以减少医生在患者就诊期间与（临床）移动设备交互的认知负荷，以及一种用于自动化特定类别护理程序的过程软件方法，称为临床指南（客户团体）。CG是以“最佳实践”的形式提出的关于如何诊断和治疗特定医疗条件的建议。它们基于可用的最佳研究和实践经验[16,17,18,19]. 该项目的目标不是自动化临床决策，而是支持医生制定CG，向他们提供相关的临床信息（如某些药物的影响等），以降低决策风险。该系统利用BPM中关于如何组织CG以及如何支持其全部或部分执行的概念。此外，该系统支持与核心临床移动设备进行语音和多点触摸交互。这使得医生可以在不同的交互模式之间切换，在患者就诊期间选择最合适（且分心程度较低）的模式。
TESTMED系统是通过以用户为中心的设计（UCD）方法设计的[20]并在罗马（意大利）主要医院Policlinico Umberto i的DEA急诊室进行评估。其目标是证明，采用提供多模式用户界面的移动设备，再加上以流程为导向执行临床任务，是支持医生执行CG的一个有价值的解决方案。 本文扩展了我们以前的工作[21,22]通过包括许多以前被忽视的新元素，在几个方向上。具体来说： 引言部分被改写和扩展；
提供了一个精炼的背景部分，描述了不同视角下医疗过程的特征；
临床指南的描述更加详细和完整；
描述相关作品的章节已被大幅扩展，新的贡献描述了声音界面的最新技术；
提出了一个改进的用户评估部分，讨论了评估系统有效性和可用性的完整实验流程，并测量了收集结果的统计显著性；
论文的所有其他部分都经过了编辑和完善，以更全面地介绍材料。
论文的其余部分组织如下：第2节提供了有关医疗流程和CG的相关背景知识，并介绍了一个具体的CG，该CG将用于解释TESTMED系统的基本方法。第3节描述了用于处理CG制定的一般方法，而第4节介绍了系统的体系结构，介绍了系统软件组件的技术细节。然后，第5节介绍了用户对系统的评估结果和一些性能测试。最后，第6节讨论相关工作并第7节通过跟踪未来的工作，对本文进行了总结。 2.背景
2.1. 医疗保健流程
在医院的背景下，医生和医务人员的工作包括制定若干组织和临床任务，这些任务在为患者定制的护理路径中组织。此外，不同的组织单位参与患者的护理路径。例如，对于在心脏科治疗的患者，需要在实验室进行常规血液检测，并在放射科进行胸部RX。这意味着不同科室的医生必须探视患者，撰写医疗报告并分享临床结果，即所有临床任务必须按一定顺序执行，并且需要不同组织单位之间的合作才能正确完成这些任务[11]. 根据上述内容，可以确定几个医疗保健流程具有不断增长的复杂性和持续时间。例如，有短期的组织程序，如患者接受或长期运行的治疗程序，如物理治疗。根据[23]，医疗流程可分为两个抽象组：选择性护理和非选择性护理. 为了进一步了解医疗流程的复杂性，可以将其分为六个宏观步骤[27]，根据其展现的结构化程度和可预测性进行组织[28].图1显示了这样的分类。 六个宏步骤包括：
管理步骤，如患者登记和病人出院以及实验室测试和患者转移等组织活动通常是结构化和重复性的。任何潜在的异常行为都是有限的，可以从一开始就预见到。因此，它们是采用传统流程管理方法制定的很好的候选者[11]. 相反，医疗过程中的所有其他诊断和治疗步骤可以被视为知识密集型活动因为它们依赖于医学知识和证据、特定患者和病例数据以及医生的经验和专业知识。此外，在其颁布过程中可能会出现许多不易预见的复杂情况。因此，它们通常导致松散结构或非结构化流程[29]. 总之，整个医疗保健过程，即使是从过于简单化的角度来看图1，反映了可预测和不可预测元素的组合，使其通过传统的过程软件信息系统（PAIS）实现完全自动化极为复杂，这往往会过度限制医生和医务人员的行动范围[28]. 虽然很明显，BPM社区提供的过程驱动技术与医学信息学领域建议的方法驱动解决方案之间存在差距，但这在不久的将来不太可能解决[11]在本文中，我们讨论了如何有效地使用过程软件方法来支持管理一类特定的护理程序，称为临床指南. 2.2. 临床指南
去年，医学界对调查和发展循证医学越来越感兴趣临床指南（客户团体）。CG基于可用的最佳医学研究证据，并以推荐的护理路径的形式表示，以支持特定医疗条件下患者护理的正确决策[17,18,30,31]. 通常，CG不强制执行强制性要求，而是用作评估临床实践的参考框架。 如所示图2CG的定义是获取特定领域的知识，需要补充其他“知识层”，包括医生的基本医学知识（BMK）、特定场所的知识和患者相关信息（如病史和当前状况）以获得适用于特定患者的具体护理路径。护理路径建议了管理患者状况所需的临床活动及其顺序和时间安排。根据[14]护理路径和患者相关信息的结合可以定义个人护理路径，从而形成实际的患者治疗过程。 在患者护理管理中采用CG和护理路径的一个优势在于其结构化和以流程为导向的观点，这与导致松散结构或非结构化工作程序的传统临床决策不同。医学信息学界的研究文献深入研究了CG和护理路径管理模型、语言和系统的定义，重点关注所谓的“计算机可解释临床指南”（CIG）。工作[28]介绍了最近的一项调查，对现有的CIG管理框架进行了分类，这些框架可以分为基于规则（例如，Arden Syntax）、基于逻辑（例如，PROforma）、基于网络（例如，EON）和基于工作流（例如，GUIDE）。大多数可用的形式都允许将CG表示为任务网络，其中活动和决策通过调度和时间约束关联，通常以刚性流程图式结构进行。这使得使用PAIS和面向过程的方法自动制定CG成为医学界的一个相关且及时的挑战[11,28,32]. 在本文中，我们通过介绍TESTMED项目的主要发现来应对这一挑战，该项目的目的是实现一个能够解释CG并通过移动技术和多模式用户界面协调医生和医务人员执行CG的临床PAIS。
2.3. 案例研究：胸痛
为了更好地理解TESTMED项目的整体情况，在本节中，我们详细介绍了为胸痛患者制定的标准CG。胸痛是指颈部和上腹部之间身体前部任何地方都能感觉到的疼痛或不适。它可能是心脏病发作的迹象，但也可能是其他疾病的症状。胸痛被认为是急诊室入院的最常见原因之一（占所有就诊的5%），如果诊断失败和不当解雇，死亡率很高（2-4%）[33]. 当胸痛患者到达急诊室时，通常会有医生来探望他/她，医生会调查患者病史和风险因素。此外，a胸痛评分通过计算，医生可以将患者分为心脏事件的低风险和高风险亚群。 图3显示DEA采用的胸痛评分。分数来自四个临床特征：（ii）这个本地化疼痛；（ii）这个性格疼痛；（iii）这个辐射痛苦和（iv）相关症状部分评分与每个特征相关，这些值的总和产生预测心绞痛概率的最终评分。胸痛评分低于4分表示冠状动脉疾病的低风险概率，而评分大于或等于4分可被归类为冠状动脉风险的中高概率，即需要入院进行临床观察。不同的比率值对应患者遵循的不同临床治疗。 3.制定TESTMED临床指南
TESTMED项目解决的主要挑战是缩小BPM社区提供的全自动化解决方案与在医疗环境中应用传统流程管理方法的明显困难之间的差距。为了实现这一愿景，该项目的主要成果是开发了一个临床PAIS，称为TESTMED系统，能够解释和执行CG，并通过多模式用户界面向医生和医务人员演示CG。
TESTMED系统被认为是在患有某种疾病的患者（可接受CG）要求就诊时使用的。医生配备了一台运行TESTMED系统的平板电脑（支持触摸和语音交互）。因此，医生能够选择、实例化和执行特定的CG。
例如，在胸痛的情况下，医生开始填写一份调查，以确定患者病情的严重程度，该严重程度通过胸痛评分表示（参见第2.3节). 在安装TESTMED系统的平板电脑的图形用户界面（GUI）上向医生展示调查结果（请参阅图4a） 。交互可以通过利用平板电脑的触摸功能来执行，也可以通过语音合成和识别集成来执行。中GUI右上角带有麦克风的灰色图标图4只有当互动从触摸转变为声音时，才会显示a。这是一种视觉反馈，表明声音交互工作正常。 语音交互要求医生戴上耳机（耳机的使用既保证了在像医院病房这样的嘈杂环境中进行更高质量的语音交互，又保证了受访患者的隐私），并配有与平板电脑相连的麦克风；他/她可以听与调查相关的问题，并从演讲中选择一个合成的可能答案进行口头回答。每个答案都与一个特定的特征相关联，并提供一个关联的比率。
一旦调查完成，TESTMED系统将制定专门的治疗方法，包括一系列临床治疗和对患者的分析。治疗的结构是护理途径例如，当胸痛评分大于4时，建议的护理路径如所示图5。为了便于阅读，我们在业务流程建模标记法（BPMN是标准ISO/IEC 19510:2013，参见。https://www.iso.org/standard/62652.html，以建模业务流程）。读者应该注意到，BPMN并不是用于在TESTMED系统中具体表示和编码CG的符号（为此，我们使用了PROforma语言[34]，如中所述第4节)，但这里使用它来显示（以综合的方式）护理路径通常是什么样子的。 护理途径图5首先，包括对患者进行常规血液分析，四小时后必须再次进行。一旦分析结果就绪，医生就会对其进行评估，以决定患者是否应该住院。具体来说，如果结果不好，护理途径图5提供了对患者进行进一步测试的说明（在本例中，是血液动力学咨询和冠状动脉插管），并根据获得的结果，启动了与患者住院有关的进一步程序。另一方面，如果分析结果良好，则在8-12小时后，患者将（再次）接受一些常规血液分析，根据中的护理路径，这些结果将推动对患者执行下一个临床步骤图5. 各种临床任务的执行发生在治疗的不同时刻。此外，医生和医务人员之间的合作对于为每位患者制定适当的医疗措施至关重要。医务人员的组成部分（即护士和全科医生）配备了基于Android的移动设备，并被告知护理途径的进展以及为支持医生而必须制定的临床任务（例如，对患者进行血液分析等）。图6显示了提供给医务人员的GUI的两个屏幕截图，这两个屏幕仅允许触觉交互。 TESTMED系统能够正确安排临床任务，将其分配给（可用的）医生或医务人员，并通过记录分析结果和医生的决定来跟踪护理路径的状态。提醒和通知提醒医生和医务人员，如果有新的数据（例如，一些分析的结果已经准备好进行分析，请参阅图4b） 可供某些患者使用。如果是这种情况，医生可以决定可视化有关分析结果和护理路径执行状态的进一步详细信息，或者只接受通知。值得注意的是，医生可以随时中止护理路径的制定。 4.TESTMED系统的体系结构
TESTMED系统基于三个主要的体系结构组件：图形用户界面，一个后端引擎、和任务处理服务器.图7显示了系统架构的总体视图。 该系统采用多模式用户界面实现。一方面，医生与GUI交互（参见图4)这是专门为在大型移动设备（例如平板电脑）上执行而设计的，并允许触觉或声音交互。特别是，声音交互使医生能够在临床场景中灵活工作，在这些场景中，他们的视觉和触觉注意力（即眼睛和手）主要忙于患者的就诊。另一方面，提供给医务人员的GUI被认为是在小型移动设备（例如智能手机）上可视化的，并且只提供触觉交互（请参阅图6). 这个后端引擎其服务提供了在运行时中断、激活、执行和监控医生和医务人员之间的CG和相关数据的能力。在TESTMED中，使用各种编程语言的集合来定义每个CG。首先，形式语言[34]用于将每个CG建模为一组临床活动、数据项以及它们之间的控制流。然后，从生成的PROforma模型开始，用XML语言半自动构建配置文件，以定义允许多模式交互功能和启用不同系统组件集成的所有必要设置。因此，CG最终将表示为引导bean，将部署到系统中并准备执行。 CG的执行是通过数据、事件集和临床活动的精确路由来完成的，所有这些都遵循定义明确的流程软件和基于内容的方法，在这种方法中，以事件和数据驱动的方式安排活动并发送消息。后端引擎管理和控制所有临床活动、相关数据和相应部分（包括参与者、服务和应用程序）之间生成的事件的路由过程。因此，它保证了所有参与单位和服务之间的成功互动。此外，任何与引擎通信以完成任何定义活动的软件模块都可以视为需要时调用的外部服务。
基本上，服务被认为是对先前存在的遗留系统的包装，例如医院中使用的电子病历（EMR）系统。
路由引擎的性能取决于一个主要调度单元，该调度单元处理需要时间约束的活动的完成（例如，应及时设计和执行的检查和分析实验测试），并与EMR系统进行通信，以便（i）搜索和查询医疗和管理患者信息，（ii）根据相关医疗程序组织和计划检查、实验室测试、药品收据等，以及（iii）获得有关事件和实验室测试结果的通知，以便将其转发给指定的医生。这种与EMR系统的互操作性工作是通过使用Health Level 7（HL7）标准协议来实现的（HL7是一套用于在医院信息系统之间传输临床和管理数据的国际标准）。http://www.hl7.org/). HL7消息包的分析、处理和创建由特定的HL7处理单元组织和控制。 值得注意的是，在执行CG时，所有进行的活动都应该存储和注册，以便跟踪和检索与医疗案例及其决策场景相关的所有事件、活动和数据。此注册信息可能用于：（i）创建医疗和分析报告；（ii）记录分配给每个患者的建议和遵循的护理计划，以便将来用作法律参考；（iii）提供一个数据库平台，用于维护所有患者的所有病历和所选治疗方案，在对所有收集的数据进行进一步分析后，可以利用该数据库平台引入一个更好和改进的文档化CG版本；和（iv）为法医分析提供宝贵支持[35]. 最后，a任务处理服务器负责通过HL7和RESTful消息与后端和现有遗留系统进行通信。该服务器的重要作用是通知医务人员何时需要在特定CG的上下文中执行临床活动。另一方面，如前所述，为医务人员提供了一个专用的前端Android应用程序，该应用程序使用RESTful服务与任务处理服务器进行交互。
因此，CG的所有逻辑都是通过PROforma模型和各种基于XML的配置文件进行编码的。这些文件描述了用户界面提供的数据、要交换的队列和消息（JMS和HL7）、不同交互的路由和调度等（尤其是，所有这些文件指示Apache Camel框架制定的路由和中介规则。）所有这些文件都绑定在一个引导bean-一个压缩的档案，然后由系统分解，用于指示不同的组件。对于系统部署和制定的每个新指南，系统工程师应根据描述护理路径的BPMN流程（作为图5胸痛）。因此，与许多中间件技术和过程软件工具类似，TESTMED系统是通用的（部署新CG时不应编写新代码），但需要系统工程师进行技术配置，他们根据要实施的特定护理路径的要求，设计和部署guidelinebean。 5.用户评估
TESTMED系统被认为用于医院病房，以支持医生执行CG。在这种情况下，医务人员和医生必须协同工作，为患者开展适当的临床活动。因此，提供令人满意的移动交互至关重要，因为它允许：
支持医生走访患者的流动性；
通过支持即时和移动访问，促进信息流的连续性；
在执行CG和执行临床决策的同时加快医生的工作。
普华永道警察健康研究所（HRI）的一项调查也证实了后一点[36]报告称，56%的医生（在一个大样本中）能够通过使用移动技术改进和加快决策。 尽管移动设备和应用程序的使用可能会大大增强医生和医务人员的协作和协调能力，但仍有一些关键挑战需要解决。其中，最相关的挑战之一是实现一个GUI，该GUI能够以简洁易懂的方式表示临床活动的描述，同时不会分散医生探视患者的注意力[37]. 为了实现这个目标，我们利用以用户为中心的设计（UCD）方法[20]，将最终用户置于任何设计和开发活动的中心。为此，我们最初开发了两个系统模型（分别在项目的第4个月和第9个月）。与真实医生一起对每个模型进行了各种可用性研究（包括大声思考技术、焦点小组等），每个用户研究的结果都用于逐步改进系统GUI的设计。应用UCD方法的一个主要效果是在第二个模型中引入了声音界面，以及在第一个模型中单独出现的基本触摸界面。这是因为用户对第一个模型的反馈表明医生在探视患者时需要双手自由。这就是为什么我们引入了与GUI进行语音交互的可能性。 基于上述可用性研究的结果，我们分别在项目的第12个月和第18个月迭代生成了两个系统的工作原型。我们采用成熟的评估方法对其进行评估，包括目标用户（即真正的医生）。下一节将讨论对工作原型进行的用户评估的结果和发现。
5.1. 第一次用户研究的评估设置和结果
这两个开发的工作原型已经在胸痛患者身上进行了测试（参见。第2.3节)因此，已在系统上对相关CG进行建模、配置和部署，以执行测试。 最初的用户研究是在罗马的Policlinico Umberto I医院在急诊和住院部（DEA）的帮助下进行的。在图8，医生使用TESTMED系统在患者模拟器上执行CG。在这个实验中，五名研究生和两名医生参与了这项研究。给参与者一个本应反映胸痛症状的真实患者的患者模拟器，要求参与者根据相关CG使用TESTMED系统探视患者（参见图8). 用户测试完成后，向参与者提供了一份问卷，目的是收集他们的背景信息，并收集关于他们如何感知与系统交互的数据。具体来说，问卷由11个陈述组成，涵盖GUI的易用性、多模式交互的质量等方面。答案通过5点利克特量表进行评估，范围为1-强烈反对到5-强烈同意，以反映参与者如何同意/不同意定义的陈述：
- 第一季度
我在使用移动设备方面有很好的经验。
- 第2季度
与系统的交互不需要任何特殊的学习能力。
- 第3季度
我认为与触摸界面的交互非常令人满意。
- 第4季度
我认为与人声界面的交互非常令人满意。
- 问题5
我认为通过触摸界面或声音界面与系统交互的能力非常有用。
- 问题6
非专业用户可以使用该系统来使用移动设备。
- 问题7
该系统允许持续监控临床活动的状态。
- 问题8
该系统正确地驱动临床医生执行临床活动。
- 问题9
医生可以在任何时候访问与特定临床活动相关的数据和信息。
- 问题10
该系统对误差具有鲁棒性。
- 问题11
我认为，该系统的使用可以促进医生在执行其活动时的工作。
表1总结了第一次用户研究的结果。从这些结果中，我们可以推断参与者对我们的系统的总体态度是积极的。结果表明，参与者认为该系统在制定CG方面是有效的，因为它能够具体协调医生执行CG中包括的临床活动（参见Q8的结果）。此外，该系统允许医生持续监控每个临床活动的状态（参见Q7的结果），并轻松访问与正在执行的特定活动相关的信息（参见Q9的结果）。参与者还对系统在错误处理（参见Q10的结果）、可学习性（参见Q2的结果）和非专业用户的易用性（参见问题6的结果）方面的表现表现出相当满意。 从负面来看，与人声界面的互动被认为是非常不令人满意的（参见第4季度的结果），而使用触摸界面的满意度很高（参见第3季度的结果。）。尽管如此，参与者同意，涉及触摸和声音界面的多模式交互可能有助于促进医生的工作（参见问题5的结果）。值得注意的是，调查问卷还允许参与者以自由文本的形式添加反馈和评论。使用此功能，七分之五的参与者明确要求我们为系统开发改进的语音交互，使医生能够在需要时动态切换交互模式（从语音到触摸，或反之亦然）。
GUI的响应性是在第一个工作原型范围内研究的另一个方面。在这个方向上，进行了进一步的测试，以计算医生执行与部署到系统中的CG相关的调查的单个步骤所需的时间（另请参阅第2.3节). 具体来说，我们假设医生从一个场景经过时完成了调查中的一个步骤（在TESTMED中，如中所述第4节，MT4j被用来构建系统的GUI框架，称为场景，通过回答调查中的相应问题，可以处理GUI到下一个GUI的（多）触控输入事件。我们监控了医生完成CG调查相关场景所需的时间，直到完成为止。 我们进行了两次测试：首先，使用触摸界面，然后使用声音界面。收集的结果摘要如所示图9，其中每个场景过渡都显示在x个-轴，生成新场景并在屏幕上显示所需的相应时间在年-轴。在我们的案例研究中，重点是胸痛CG，在生成最终胸痛评分之前，我们需要三个场景转换。 测试使用的是ACER Iconia Tab W500（ACER Inc.，中国台湾西直人），具有1 Ghz AMD CPU和2 Ghz RAM，运行Windows 7操作系统（美国华盛顿州雷蒙德市微软雷蒙德）。分析显示，在只使用触摸界面的情况下，完成场景转换的平均时间为400毫秒，而仅使用人声界面时需要6-700毫秒。使用语音接口导致延迟的原因是系统接触ASR引擎所需的（额外）时间（通常约为200–250毫秒）。尽管如此，从用户的角度来看，这种延迟对系统的整体响应性影响很小，因为执行场景转换的时间不超过700 ms通常被认为是用户可以接受的[38]. 5.2. 第二次用户研究的评估设置和结果
利用第一次用户研究的结果和发现来完善第一个原型的薄弱环节，以便实现系统的（更）健壮的第二个工作原型。如果与第一个原型相比，第二个原型提供了更详细的GUI设计，以及对语音界面背后的交互原则的重新定义。例如，在第一个原型中，系统的声音特征在CG的设定过程中始终处于活动状态。这导致了许多“误报”，即系统错误地将医生在患者就诊期间发出的一些单词识别为正确的语音命令（从而激活不需要的功能）。在第二个原型中，为了防止错误触发，我们决定只在医生发出特定（和可定制）的关键语音指令后激活语音界面。
利用第二个工作原型，我们使用第一个用户研究中使用的相同胸痛CG进行了第二个用户研究。此外，第二次用户研究在罗马的Policlinico Umberto I DEA进行。七名用户（与第一次用户研究中的用户不同）参与了第二次用户研究，其中包括六名医学研究生和一名医生。与第一次用户研究一样，参与者参加了患者模拟器，并被要求使用系统的第二个原型来制定CG（参见图8). 他们还完成了第一次用户研究中使用的相同问卷，以评估系统的有效性。第二次用户研究的结果如所示表2. 从结果分析中可以明显看出，第一次用户研究中获得的关于系统工作的良好感觉已被第二次用户研究的结果所证实。如果我们提到图10我们可以注意到，与第一次用户研究相比，第二次用户研究中参与者对所有语句的评分都有所提高。此外，研究结果突出表明，第二个原型的设计取得了相当大的进展，特别是因为我们在开发过程中严格遵循了构建多模式GUI的传统设计准则[10]. 一个关键方面是与人声界面的交互（参见第4节陈述），这在第一次用户研究中表现得相当不理想，平均评分为2.7。相反，第二个工作原型中使用的改进的声音界面得到了研究参与者的认可，平均评分为4。为了证实人声界面的改善不是巧合的结果，我们利用2个样本分析了第一和第二次用户研究中收集的Q4语句的评级t吨-测试。此统计检验用于比较两个总体平均值之间的平均差异是否真的具有统计显著性，或者是否是由于随机机会造成的。2个样本的结果t吨-测试总结如下图11。通过查看p值来确定结果的统计显著性，该值给出了随机获得收集结果的概率。如果第页-值假定值为0.05或更小，可以得出结论，收集的数据不是偶然发生的，我们的数据就是这样(第页-值为0.0265099）。这让我们可以得出结论，声音界面的改进并不是巧合的结果。 最后，我们还进行了传统的系统可用性量表（SUS）问卷调查，以精确测量第二个工作原型的可用性。SUS是测试后数据收集中使用最广泛的方法之一（43%的测试后数据属于SUS类型[39]). 它由一份10项问卷组成。任何问题都用5分的李克特量表进行评估，范围从1到5不等。完成后，将为问卷分配总分。这样的分数可以与研究文献中的几个基准进行比较，以确定被评估GUI的可用性水平。在我们的测试中，我们使用了[39]和所示图12。根据第二次用户研究的七名参与者完成的SUS分析，医生和医务人员使用的GUI的最终平均评分分别为77.5和78.4，这对应于[39]. 这意味着TESTMED的GUI平均具有良好的可用性，即使还有改进的余地。 6.相关工作
6.1. 面向流程的医疗保健系统
尽管在许多最近的工业项目中使用PAIS以及在各种现实场景中采用快速增长的面向过程的方法取得了巨大成就[40,41,42]，BPM技术仍面临着在医疗应用中广泛采用的几个挑战[14,28]. 这主要是由于PAIS对流程定义强加的刚性结构限制了处理和管理医疗流程的灵活性，而这些流程在制定过程中经常受到许多变化和例外的影响[43]. 为了解决这个问题，BPM技术的发展应该能够增强对医疗流程的灵活管理，而相反，最近的研究尝试更侧重于在现有PAIS之上改进其自动化[11]. 在这个方向上[44]确定了可以通过在医疗应用程序中使用流程管理技术来增强的不同灵活性需求。这项工作的重点是妇科肿瘤学过程的诊断步骤及其在四种不同PAIS中的可能实现。然而，工作[44]主要面向分析结构良好的医疗保健流程的灵活性需求。 工作[45]使用BPMN符号研究程序化手术干预的病理过程建模。设计的模型不仅包括手术干预期间，还包括干预前后的准备/随访阶段所需的所有临床活动。请注意，在[45]没有讨论过程制定的支持系统。同样，工作[46]定义了BPMN中的几个临床过程，涵盖了患者从入院到出院的所有治疗步骤。 有关BPMN在建模医疗流程方面的潜在作用的更广泛调查，请参阅[47]，其中讨论了医疗流程的多学科性质及其在传统PAIS中执行的互操作性要求等挑战。在[14,48]作者再次考虑将互操作性需求以及服务协调和应用程序集成作为基本资产，以实现制定医疗流程所需的支持。特别是，他们注意到医疗应用程序中使用的当前信息系统由几个独立的（临床）科室系统组成，导致了许多集成问题。尽管使用HL7标准缓解了此类集成问题[14,48]作者主张，目前仍缺乏一个共同认可的解决方案，以确保不同临床系统之间的适当整合。 在[23]作者研究了流程挖掘技术的使用如何利用事件日志数据中包含的知识来增强EHR应用程序的功能，同时解决与医疗流程管理的成本和效率相关的各种问题。根据[49]，过程挖掘可分为三大分支：（i）进程发现[50,51,52],（ii）一致性检查[53,54,55,56,57]和（iii）过程增强[58,59,60]. 具体来说，在[23]作者认为，加强医疗过程与理解这些过程的“本质”直接相关。这可以通过确定整个医疗程序中发生的情况（即流程发现），并分析它们是否与预期的治疗方案存在不一致或偏差（即合规性检查）来实现。最后，可以使用流程增强技术检测并修复效率低下、瓶颈和其他问题。 考虑到利用web服务的面向服务的体系结构，已经提出了一些系统，通过将服务编排规范定义为BPEL流程来解决制定医疗保健流程的问题。例如，在[61]，作者介绍了一种在BPEL中创建web服务规范的创新方法，该方法利用半自动化模型驱动方法，重点关注管理工作流，包括医疗测试计划和跟踪患者从入院到出院的状态。同样，面向服务的集成、web服务、，和工艺技术也在[62]作为在组织间紧急情况下自动化医疗流程的一种手段。在[63]，讨论[62]扩展到移动技术和基于云的架构。 在[64]服务流管理系统是一种管理整个医疗流程的工具，尤其是当多个组织单位参与护理交付活动时。该系统提供了一个三级体系结构，其中上层负责协调下层可用的服务，并处理整个医疗流程，该流程被建模为服务流。最后，在[65]，作者提出了一种通过面向服务的体系结构支持医疗流程的方法。该方法侧重于将无菌处理部门中执行的操作组织为医疗流程，并确定实现支持此类流程的系统所需的架构需求。建议的架构是原型，并在卫生工作区进行评估。 如果与上述主要为管理明确定义的医疗流程提供特别解决方案的工作相比，TESTMED的目标是实现一个通用的临床PAIS，能够解释PROFORMA语言中编码的CG，并通过移动技术和多模式用户界面在医生和医务人员之间协调执行。
6.2. 医疗保健领域的移动和多模式交互
移动和多模式用户交互在许多现实环境中都有很长的成功历史，包括应急管理[66,67,68]智能协作环境[69,70,71,72]、文化遗产[73,74]当然还有医疗保健[37]. 如果使用得当，这类技术不仅有助于改善患者护理服务，而且有助于推动医院大规模采用移动临床设备。 在这个方向，在[75]，Flood等人提出了一种方法，该方法允许医疗移动应用程序的设计者和开发人员尽早评估其应用程序的已实现原型，特别是如果它们的使用可能会对最终用户产生高度的认知努力。提出的方法包括中断应用程序开发过程和在需要时修改用户界面设计。尽管此方法旨在减轻使用移动应用程序时感知到的认知努力，但它并没有引入任何新的设计技术来解决移动多模式交互问题。相反，在[76]Jourde等人通过为多模式协作医疗系统设计用户界面提出规范，承认了与临床移动设备提供多模式交互的重要性。另一个有趣的方法是[77]它由一个智能移动设备和一个支持移动交互的软件系统组成，移动交互处理审计任务，并使急诊室的医务人员能够建立无缝的临床交接程序。最后，GuideView系统[78,79]这表明宇航员在太空探索任务中，尤其是在无法获得地球专业医疗援助的情况下，需要为自己提供医疗服务时，充分的移动交互非常重要。值得注意的是，上述工作都不是为了改进CG建模或执行。 总结并确认第1节，TESTMED系统旨在提供以下要求：通过支持移动访问信息来确保信息流的连续性，在执行CG的同时赋予医生权力，并改进和维持有效的移动多模式交互设计，以减轻医务人员和医生的身体和认知负荷。最近的工作，包括上述工作，主要针对的是一个单一的要求或他们的部分组合。 6.3. 语音接口
在过去几年中，计算机的输入和输出接口一直在发展，以便在不同任务期间通过计算机进行交互和协作时，为人类提供更好的用户体验。这一进化的驱动因素之一是提供利用人类所有感官的界面，特别强调视觉、语言和触觉交互，这些交互被认为是人类和计算机之间最真实的对话。由于智能移动设备最近的成熟度和广泛可用性，它们变得更小、更便携、更强大，因此除了传统接口之外，对更有效接口的需求变得更加迫切。因此，最近有相当多的研究工作讨论了所谓多模态交互的当前局限性和可能的机会。所涉及的技术包括触觉设备，如数码笔、指纹扫描仪和3D手势，以及高级语音和视觉接口，如语音命令和面部识别。特别是，这些技术必须结合起来，以便为目标用户提供最适合其需求的交互。
语音界面代表了一种广泛使用的交互模型，证明了其在各种场景中的有用性，例如家庭自动化、汽车驾驶和制造过程。在早期专利中[80]，作者开发了一个电话系统环境下的交互式语音应用程序，其中与用户（即呼叫者）的交互式对话任务可以定义为对话模块的形式，用户输入以口头命令的形式提供。与单独使用触摸界面相比，智能移动设备的显示屏相对较小，语音输入将支持更轻松、更快和更高效的任务执行，也可以采用同样的方法。该方法的示例如所示[81]作者建议使用语音控制界面来克服阅读大量文本（例如选择菜单）和使用小触摸键盘键入响应的任务。中介绍的工作[82]考虑到危机管理的情况，并建议在这种环境下提供包括语音交互在内的多模态界面将非常有价值，从而在更短的时间内解决问题，同时确保团队成员之间更好的协作。另一方面，作者[83]分析了现有自动语音识别（ASR）技术的性能，并指出了语音成为真正普及的用户界面所需的级别。基于神经网络的新的、非常精确的识别技术的使用最终使得基于语音的接口的使用无处不在。 最近，市场上推出了许多商业语音界面原型。这在许多移动操作系统中很容易注意到，在这些系统中，语音界面（作为自然语言用户界面）被提供作为智能个人助理和知识导航器。这些系统包括Siri、Google Assistant和Cortana。这些程序听取用户的声音输入，将其解释为口头命令，并使用文本到语音对用户作出响应，从而模拟人与人之间的声音交互。不幸的是，在开发系统时，这些系统不可用，因此我们使用了文本到语音（TTS）引擎和Microsoft自动语音识别（ASR），如中所述第4节. 在健康支持系统的背景下，语音接口已被应用于多个应用程序中。中的作者[84]建议在检测到独居老人跌倒后使用音频输入。这里，该系统在移动设备上实现，并使用加速计识别可疑坠落。此时，用户可以通过语音寻求即时帮助，因为在这种危急情况下，使用键盘打字可能是不切实际的。同样，遵循远程医疗的方向，作者[85]研究了在远程监控的情况下，声音作为获取患者情绪的一种手段的使用，在这种情况下，需要更高水平的技能、专业精神和能力来进行现场访问。在此，作者指出，由于患者自身难以准确表达自己的情绪状态，因此使用声音检测患者的情绪可能更加准确，因此强调开发这种多模式智能有效界面的重要性。在精神病理学领域也进行了类似的工作[86]其中，主要抑郁症病例的临床诊断是使用面部表情和声音分析来帮助自动检测抑郁症，抑郁症的评估通常基于经典报告（例如，临床访谈和问卷调查）。 中的作者[87]讨论了机器人在医疗机构（如医院）中的应用，并建议将声音交互应用于在医疗中心周围移动的机器人，以便在此类环境中更好、高效地执行任务。 在他们呈现连续口语和连续手势的多模态整合的工作中[88]在他们的原型中包含了一个医学信息学示例，其中用户（本例中为患者）可以使用语音和手势在他们所在区域的地图上搜索可用的医疗服务提供者。此原型中的多模态输入被转换为查询，该查询在所选区域中所有医疗保健提供者（例如医生）的数据库上执行，并检索可直接显示在地图上的返回结果。为了建立一个保健品智能家居，作为一个智能空间，帮助老年人和有特殊需求的用户进行日常生活活动，作者于[89]他认为，语音接口可能会有所帮助，因为它们不需要佩戴或在空间上靠近任何设备。 在外科干预导航协助的背景下，作者[90]开发了一个原型，该原型将虚拟现实与多模式接口（包括声音输入）和一个专家系统结合使用，该专家系统有助于推断上下文，以便为外科医生提供支持，无论是在过程模拟中还是在现实干预中，都是出于培训和临床目的。 我们的工作可以定位在这一研究背景下，引入移动应用程序，支持执行所需的相关临床指南，同时提供与声音界面的多模式交互，可以为患者和临床医生带来显著益处。当使用这些IT系统的临床医生以免提模式使用语音输入时，这些好处很容易被注意到，这反过来又允许在这种环境下更轻松、更快地执行医疗任务，并帮助医务人员在对患者进行身体检查时提高整体临床表现。
7.结论
在本文中，我们介绍了TESTMED项目的主要成果，该项目旨在通过部署在移动设备上的高级GUI与系统进行触摸和语音交互，实现在医院病房CG制定过程中支持医生的临床PAIS。TESTMED系统是通过UCD方法设计的[20]并在罗马（意大利）主要医院Policlinico Umberto I的DEA急诊室进行评估。这使我们能够证明，采用提供多模式GUI的移动设备，再加上以流程为导向执行临床任务，是支持医生执行CG的一个有价值的解决方案。 作为未来的工作，我们将授权该系统支持更多的CG，如晕厥和血脂异常，使其在更多临床环境中可用。此外，我们计划实现一种精确的方法，解释如何将CG建模为形式过程。最后，我们计划对该系统进行更长时间的测试，只为医生提供单一的交互方式（仅限于触摸或声音）。这将使我们了解语音交互功能是否比使用GUI的传统触摸功能使系统更加可用和有效。
