多学科开发团队成员在以用户为中心的远程医疗产品和服务设计中的经验:定性研究

简介

慢性病患者和老年人的数量在增加，而护理专业人员的数量却在减少[1］．在不久的将来，由这些变化造成的护理需求和供应之间的差距将给病人、护理专业人员和卫生保健系统带来负担[2，3.］．远程医疗产品和服务有可能通过支持自我管理、远程监测健康状况和提供干预措施来减轻这一负担[4-6］．适当采用远程照护技术，可改善慢性病患者和长者的生活质素，使他们能尽可能长时间独立生活，从而有助他们的生活。[7，8］．

不幸的是，以往的研究表明，远程护理并不总是发挥其潜力，因为所开发的远程护理产品和服务不符合最终用户的需求和偏好，或者因为它们不符合应该实施的环境[9-12］．让终端用户参与远程护理产品和服务的开发，可确保考虑到人力和非技术问题，从而提高正在开发的技术的可用性和可接受性[13-15］．

在远程护理产品和服务的开发过程中，以用户为中心的设计(UCD)的理论框架已被用作指导方针[16-22］．这些框架考虑了UCD的重要关键原则，例如，开发过程应该是迭代和增量的，最终用户应该从早期开发阶段开始积极参与，设计选项应该以最终用户能够理解的语言向最终用户解释，开发的服务和产品应该在现实生活中进行评估，开发过程应该由有效的多学科团队执行[23］．以往的研究表明，在UCD过程中会出现各种障碍和挑战，这些障碍和挑战会影响多学科利益相关者之间的合作。这些障碍的例子包括来自不同背景的团队成员之间的沟通，期望的管理，以及用户参与的资源的可用性[14，24，25］．

了解具有不同背景的多学科开发团队成员如何体验UCD过程可能有助于深入了解在远程护理产品和服务开发过程中不同成员认为至关重要的因素。此外，这可能会揭示他们如何处理遇到的障碍和挑战。因此，本研究的主要目的是探讨多学科开发团队的成员如何体验远程医疗产品和服务的UCD过程。第二个目标是确定他们所经历的障碍和促进因素的异同。

方法

设计与参与者

这项定性研究是与马斯特里赫特大学和/或祖伊德应用科学大学发起的四个(补贴)研发(R&D)项目同时进行的。这些项目被选中是因为它们开发了各种远程护理产品和服务，以支持不同用户群体的自我管理:糖尿病或慢性阻塞性肺病患者[26-28]、癌痛病人、体弱长者或居家长者[29］．项目选择的一个先决条件是最终用户被认为是开发团队的正式成员。多媒体附件1提供有关这四个项目的信息。这些项目的主要调查人员具有卫生科学背景。

在这项研究中，四个开发团队的“核心成员”从一开始就参与了整个开发过程，他们被邀请参加半结构化访谈。每个开发团队的主要研究员在与他们的团队协商后确定了核心成员，并询问他们是否愿意通过电子邮件收到本研究的邀请。四个研发项目共确定了25名核心成员:3名老年人、2名老年人的专业顾问(专门协助老年人参与研究项目)、2名慢性病患者、1名老年科医生、2名护士、5名软件/技术工程师、4名研发公司或工程团队的经理以及6名研发项目的研究员/主要研究员。所有这些潜在参与者都通过电子邮件收到了来自研究人员(JV)的邀请函，解释了这项定性研究的目的和细节。所有被邀请的人都接受了邀请。

程序

在被邀请者同意参加后，面试被安排在参与者方便的时间和地点。结果，13次访谈在大学进行，9次在参与者的工作场所进行，3次通过Skype/电话进行。本研究的6名参与者是四个研发项目之一(JV, RV, LMJH, SvdW, YPM, LdW)的研究人员或主要研究员，由一位经验丰富的外部采访者采访，他没有参与上述任何研发项目。JV、RV、LMJH、SvdW和YPM采访了本研究的其余19名参与者。所有参与者都接受了一名研究人员的采访，该研究人员与参与者没有参与同一个研发项目。项目1、3和4的开发团队成员的访谈是在最终产品已经开发出来时进行的。与项目2开发团队成员的访谈在原型阶段进行。研究人员用数字录音设备记录了采访过程，时间在35到65分钟之间。访谈的平均时长为46分钟。

所有的半结构化访谈都基于以下主题列表:参与者在项目中的角色，项目的目标，开发过程中的经验，开发过程中的改进点，以及项目对参与者的意义。该主题列表是在研究开始前建立的，在研究过程中没有更改。面试官使用反思性倾听技巧来鼓励参与者详细阐述他们的观点。通过在面试过程中向参与者反映面试官认为参与者所说的话，参与者的陈述得到了验证和/或澄清。通过保持开放的姿态，并在采访开始时强调答案没有对错，参与者被鼓励分享自己的个人观点和想法。所有参与者的回答都是保密的。为了保证匿名性，本文使用以下术语来指代从某些参与者群体中获得的数据:

• “最终用户”是指从老年人、老年人的顾问或慢性病患者(n=7)处获得的数据。
• “专业最终用户”是指从老年医生或护士处获得的数据(n=3)。
• “工程师”是指从软件/技术工程师(n=5)处获得的数据。
• “经理”是指从技术项目负责人或研发公司所有者(n=4)处获得的数据。
• “研究员”指从研发项目的研究员或主要研究员(n=6)处获得的数据。

数据分析

所有访谈完成后，由两名研究人员(JV/RV)或一名研究助理逐字记录。之后，JV将笔录与录音进行了比对。所有转录本均使用NVivo version 9.0进行编码。访谈的现场记录也包括在分析中，如果它们是可用的。两名研究人员(JV和RV)开始使用传统的内容分析方法分析数据。他们独立编写了六份采访记录，采访对象是来自不同开发团队、具有不同背景的成员。在初始编码后，两位研究人员进行了一致性检查，经过讨论，他们对编码方案的主题和子主题达成了一致。JV使用这个编码方案来分析剩下的访谈。如果对其余访谈的数据是否符合编码方案有疑问，JV咨询了RV。主题和子主题是根据剩余的访谈数据进行细化或扩展的，如果有必要，还会添加新的(子)主题。 Once all transcripts were analyzed, the content of the themes and subthemes of the coding scheme were discussed with the research group that included all co-authors of this paper. Consensus was reached on themes that were related to different phases of the development process and subthemes that related to barriers and facilitators participants experienced during these phases. After completing the data analyses, findings related to themes and subthemes were reported back to all participants for a member check.

结果

主题

从与UCD过程的不同阶段相关的分析中出现的主要主题是(1)创建开发团队，(2)关于责任和角色的期望，(3)将用户需求转换为技术需求，(4)技术挑战，(5)评估，和(6)定价。参加者在这些不同阶段的经验现述于下。表1而且2提供开发团队成员分别报告了哪些经验丰富的障碍和促进因素的概述，以深入了解差异和相似之处。

创建开发团队

由于开发团队的成员有不同的背景，在关于项目、UCD流程、远程护理产品和服务、技术的预期最终用户以及在卫生保健环境中进行研究的方式的知识方面也存在差异。此外，开发团队的不同成员似乎说着“不同的语言”(使用不同的术语):

我们有研究人员，我们有医生，我们有技术人员，这是一个非常不同的世界。因为我们说的不是同一种语言……有时候我们在想一些事情，而研究人员却理解了另一些事情……我们讲技术，她(研究人员)与老年人交谈，她与其他世界交谈。这就是为什么它如此困难。
[P20，男性，工程师]

参与者报告说，克服这些差异有时很困难。大多数参与者都提到，这些差异的一个好处是，团队成员可以真正地相互补充，从而产生积极的“团队精神”:

他们(技术工程师)对药物一无所知，然后你会想;我对电脑一窍不通。所以在一起很有趣，就好像你们说着不同的语言，但仍然必须一起想出一个解决方案。
[P23，女性，专业终端用户]

患者和护理专业人员从一开始就参与并被认可为开发团队的成员，这对多学科合作产生了积极的影响。根据最终用户的说法，当经理或主管主张所有成员的输入应该被平等对待时，这就促进了共同创造和UCD。此外，最终用户表示，当研究人员向他们报告他们的建议哪些部分得到了遵守，哪些部分没有得到遵守时，他们很感激。根据一些人的说法，这种反馈比实际听从他们的建议更重要，因为这让他们感觉自己是团队的一员。

我确实有一种感觉，我们提出的东西，他们(研究人员)做了一些事情。有时他们(研究人员)只是说:“听着，我们没有选择这个，或者我们确实选择了这个。”我认为这很重要反馈也很重要例如，当你提出某件事之后，你什么都听不到。那么你就不知道是否有人对它做了什么，或者它是否被认真对待了。在这个过程中也很难在一起。
[P9，女性，最终用户]

最后，在多学科团队中工作的组织方面在大多数项目中都是一个挑战。由于大多数成员有不同的日程安排，通常很难组织整个团队的会议。根据大多数人的意见，分会议是一个令人满意的解决办法。老年人代表、护理专业人员和工程师表示，他们很欣赏研究人员上门或在工作场所提供额外信息/解释或最新情况的灵活态度。

关于责任和角色的隐性期望

参与者表示，在项目期间，他们发现了开发团队成员之间关于责任和角色的期望的差异。开发团队成员之间期望不同的问题示例包括谁是项目经理，不同团队成员的任务是什么，以及谁交付正在开发的服务的内容。参与者似乎同意，在项目开始时清晰地表达和交流期望将有助于确保整个开发团队在同一页上，这可能会优化多学科协作。然而，一些参与者表示，表达这些期望可能很困难，因为它们通常是隐含的:

事实上，你以开放的心态开始这个项目，在这个过程中你创造了期望。因为我们的工作方式是:迭代设计。我们每一次都更进一步。所以，在项目开始的时候，你实际上不知道你会在哪里结束。你慢慢地工作到最后。所以，在开始之前，你实际上没有非常详细的期望。
[P15，男性，工程师]

在项目开始时，我希望有更多的愿景，更多的策略，对这个(项目的概念)有更清晰的认识。这让我很失望。符合患者群体的标准是在这个过程中形成的。我本想充分利用大学里的知识。但这令人失望。
[P16，男性，经理]

我认为我们在提供内容(为远程医疗产品和服务)方面发挥了很大的作用……当然，你必须在一定程度上开发干预。但是这个细节，不，我没想到我会这么做。我本来还想再买一份公司的股票，事后想来很失望。
[P2，女性，研究员]

将用户需求转化为技术需求

参与者体验到，收集用户需求并与开发团队讨论哪些需求值得优先考虑所花费的时间比预期的要长。其中一个原因是，在一个由不同背景的成员组成的团队中达成共识是相当具有挑战性的。

该过程中另一个耗时的部分是将用户需求转换为工程师开发第一个原型所需的非常详细的技术需求。在翻译过程中，来自工程师的帮助似乎至关重要，因为大多数研究人员没有技术背景，也不熟悉用于描述技术需求的技术语言:

在概念阶段，一切似乎都是可能的。但当你必须在最后的反馈信息之前指定事情时，这是非常困难的。想清楚这些事情需要很多时间。
[P5，女性，研究人员]

研究人员或多或少被迫扮演一种角色，他们必须以技术的方式思考。他们不习惯，这不是他们的工作。这就产生了一种紧张感。因为他们被迫思考以前没有想过的(技术)问题。
[P18，男性，工程师]

最后，作为UCD过程迭代性质的结果，在项目期间所确定的用户需求不断发展。开发团队的成员一致认为这些迭代是必要的，以确保开发的产品和服务满足最终用户的需求(以最好的可能方式)。特别是工程师和经理指出，他们试图尽可能灵活地将新的和额外的需求合并到新的原型中，因为他们认识到迭代的重要性。然而，在某一时刻，这种灵活性就会终止，因为必须满足最后期限，并且在这些期限之后人员将被部署到其他项目中:

从目标群体中获得反馈是件好事，但保持控制是很重要的…我感觉为了响应目标群体的反馈，有太多的变化…在某个时候，我们冻结了规格并开始工作。
[P18，男性，工程师]

我们有很多前前后后的变化。对于终端用户来说，一个相对简单的更改(例如将条从一个地方更改到另一个地方)可能会花费大量时间，或者需要对软件程序的运行方式进行重大更改。
[P19，男性，经理]

技术挑战

概述

开发团队所面临的技术挑战与不同技术或平台的集成、现实环境中技术的健壮性以及商业市场上的快速发展有关。

不同技术或平台的集成

项目期间开发的远程遥控产品和服务都需要集成各种技术组件(例如，传感器与移动设备上的应用程序和在线数据库的集成)。技术和软件工程师，以及在较小程度上的其他参与者，经历了这些组件的集成通常比预期的困难，原因有几个。首先，工程师体验到组件有时有自己的“语言”和规范(例如，硬件与软件)，这使得集成更加复杂。其次，对整个系统的输入，以及对护理中已开发技术的集成的输入，由开发团队的不同成员提供。所有团队成员都认识到，将这些方面的投入整合到产品和服务中可能是一个真正的挑战，因为它们并不总是匹配的。第三，在某些情况下，不同的组件不会同时完成。这可能会严重延误项目的进度。

每个公司都开发了自己的部分(技术)……我们开发了一些很好的东西，但后来它不适合。然后其他公司开发了一些好东西，我们的系统无法处理。然后研究人员提供了一个新的内容部分，然后我们想:我们可以把它放在哪里?有时候这很难处理。我们最终解决了这个问题，但我认为在某些方面可以更有效地运行。
[P17，男性，工程师]

Telecare产品在现实环境中的稳健性

研究人员经历过，通常没有足够的时间和预算来开发远程医疗产品，因为资助机构认为这项技术已经存在。由于考虑到保健环境，这些项目的技术开发似乎更具挑战性，而现有的现成远程护理产品往往不是这样。因此，当项目转移到大型试验或评估研究时，技术有时不够“成熟”，这导致了关于稳健性的问题。开发团队的所有成员都同意，健壮性是在实践中采用远程医疗产品和服务的绝对先决条件。研究人员表示，在转向现实生活环境之前，花足够的时间进行实验室可用性测试和试点研究，可能会防止大型试验中的稳健性问题:

资助研究的机构通常认为这些技术已经存在。但是，几乎没有时间进行技术开发。但我们从经验中知道，这是非常困难和耗时的。我们不应该过快地跳到大型评估研究，而是在开始大型工作之前先进行试点和可用性评估。这一点经常被低估。
[P6，男性，研究员]

商业市场的发展

许多与会者认为，商业市场为研发项目开发的产品制定了标准;用户对远程护理产品和服务的需求往往受到市场上现有产品的影响。根据开发团队成员的说法，要跟上商业市场发展的快速步伐几乎是不可能的。开发团队选择创造新产品而不是购买现成产品的原因是，新开发的产品可以适应医疗保健环境和最终用户的需求。

评价

概述

在所有项目中，开发的设备都在实验室和现实生活中进行了测试。下面将介绍在这两种情况下与设备评估相关的问题。

实验室评估

开发团队的成员首先对开发的产品进行了广泛的测试。测试产品的研究人员表示，这不仅对识别bug和错误很重要，而且还能更好地了解产品最终用户的预期体验。然而，研究人员和工程师表示，最终他们识别错误的能力下降了，因为他们无意识地创造了自己的“变通办法”:

一旦你自己真正使用了它(技术)，那么可以说，你真的与它建立了联系。然后你会对改进变得更加警觉
[P2，女性，研究员]

现实生活中的评估

与会者认为，招募愿意评估所开发产品和服务的患者和专业人员是项目规划的真正瓶颈。根据参与者的说法，这一问题的一个可能的解释是，通常护理专业人员必须在日常活动之外执行此类研发项目的活动(例如，为需求提供输入或招募患者)，这导致工作量增加。在一些项目中，专业人员招募参与者没有得到补偿。另一个问题是在同一时间有太多不同的(远程)研究项目在一个领域。针对这些问题，在研发项目期间采用的可能的解决方案是补偿护理专业人员，通过开发团队成员的正式网络招募参与者，或与参与评估研究的专业人员组织会议，以提高他们的意识并建立对项目的承诺:

在研究中，耐心是非常重要的，尤其是当你的研究涉及到病人的时候。你会遇到障碍，在某种意义上就像跨栏一样。
[P24，男性，专业终端用户]

说服那些不得不在工作之余做这件事的人。他们是医生，这是最重要的……是的，我认为人们每次都受到新事物的轰炸:另一种技术会很好。这让事情变得相当困难。
[P14，男性，经理]

稳定物价

一旦开发的远程遥控产品和服务的效果经过评估，资助的研发项目将终止。所有开发团队的成员都强调了扩大和确定已开发的远程医疗产品和服务的重要性:

这是问题之一;未来这种情况将会更大规模地发生。为此，你确实需要一个商业模式。只是为了做项目而做项目，在资金结束后做其他事情是没有意义的。
[P22，男性，经理]

来自研发公司的经理和一些技术工程师表示，在项目期间没有多少时间或预算来专注于开发适当的商业模式，这太糟糕了。事实上，不同的公司和组织经常涉及到一个远程护理产品和/或服务的交付，这是这种商业模式发展中的一个重要问题，因此大多数管理人员都关心:

首先，你必须开始考虑谁将成为所有者，谁将从中赚钱……无论如何，你必须想出一种模式，既能覆盖成本，又能留下一些额外的东西，因为我们不是那种不断投资不赚钱的东西的企业家。所以我确实看到了可能性，但还没有明确定义。
[P14，男性，经理]

老年人、慢性病患者、护理专业人员和研究人员也表示，他们对开发的产品和服务的升级换代有担忧。他们关注的问题集中在由谁来支付和销售产品/服务，这些产品/服务的成本应该是多少，以及当远程护理产品和服务在实践中实施时，患者和专业人员的角色和责任将如何变化:

我担心这在经济上是不可行的。因为理疗不包括在基本医疗保险中，所以你的目标人群很小。
[P7，男性，最终用户]

我认为我们仍然需要考虑这一点，就何时回复或不回复(在远程医疗产品发出某种信号后)达成协议，就如何与患者沟通(使用新的远程医疗服务)达成更好的协议。
[P25，男性，专业终端用户]

讨论

主要成果及与以往研究的比较

目前的研究提供了深入了解多学科开发团队成员如何体验远程医疗产品和服务的UCD过程。根据四个多学科开发团队的不同成员，我们经历了几种影响UCD过程的障碍和促进因素。发现的大多数障碍与之前的研究一致[14，24，25］．其中一些因素是由来自不同背景的参与者报告的，而另一些因素似乎更具体地适用于在UCD过程中拥有相似背景或角色的一组参与者。此外，这项研究还提供了对开发团队成员如何尝试处理他们遇到的障碍以及他们采取哪些行动来促进开发过程的洞察。

所有参与者都经历过，背景的差异会导致多学科开发团队成员之间的语言差距，从而对开发过程产生负面影响。其他认识到这一障碍的研究人员和设计师建议使用人物角色、场景、模型或原型来减少语言差距[13，21，30.，31］．这些技术也在本研究的重点研发项目中使用。此外，这项研究表明，开发团队成员之间的差距可以通过强调团队成员可以通过他们的差异相互补充的方式来弥合，通过明确主张团队成员输入平等的主要研究人员，以及通过从一开始就在整个开发过程中向(专业的)最终用户提供关于他们输入的反馈。

不同背景的与会者都认识到，管理对职责和角色的期望是远程医疗产品和服务UCD的关键因素。Gasson之前的研究表明，管理关于工作角色和任务的期望是任何UCD过程中的关键问题[32］．目前的研究结果显示，尽管开发团队的所有成员都阅读并同意使用相同的项目计划和UCD方法，但期望仍然存在差异。Goodman-Dean等人解释说，尽管对UCD过程的基本性质一致，但团队成员的方法之间仍然存在差异[33］．在开发过程的开始明确地表达详细的期望可能会防止项目后期的延迟。然而，当前研究的参与者认识到这可能很难做到。以前的研究强调项目管理应该识别和分配职责、任务和角色[16，32，34］．项目经理应该以这种方式促进UCD过程，而不是过度规定或官僚主义，因为这可能阻碍设计过程的创造性[34］．

这项研究的结果证实，时间和预算相关的问题似乎在UCD过程的不同阶段发挥了重要作用。在以前的研究中报告的主要时间限制因素是，无论使用哪种方法，以迭代的方式与用户一起工作都会花费太多的时间[13，14，34，35］．Shah等人的文献综述表明，缺乏可用的最终用户是UCD过程中的一个障碍[14］．目前的研究结果并不完全符合这一点，因为招募用户参与开发团队，并在迭代UCD过程中测试原型，与招募纵向研究参与者相比，似乎障碍较小。对此的一个可能的解释是，对于之前的UCD活动，参与者是通过终端用户和作为开发团队一部分的专业终端用户的(非正式的)网络招募的。通过这种方式，(专业)最终用户从早期阶段就开始参与，促进了项目的进展。以前进行的其他研究并没有指出哪些因素被认为太费时。目前的研究深入了解了多学科开发团队不同成员所经历的与时间相关的障碍的原因。研究人员和工程师是参与者中最常报告与时间有关的障碍以及他们如何努力解决这些障碍的群体。

所有管理者报告的一个关键因素是建立良好的商业模式。这项研究的结果表明，预算应该分配给业务用例的开发，相关的涉众应该在早期阶段讨论业务建模问题。以往的研究强调，商业模式开发应与电子卫生技术的UCD并行，因为它有助于此类技术的发展[16，36］．

优势与局限

本研究包括的四个研发项目的范围，从与社区老年人的护理和福祉相关的一般服务，到为患有癌症(治疗)疼痛的重病患者提供的特定服务。所包含项目的多样性增加了研究结果的普遍性。此外，我们还采访了多学科开发团队的所有核心成员，以便将所有观点纳入我们的分析中。这是研究设计的一个优势，因为以前旨在识别UCD过程障碍的研究往往只关注设计师或开发人员的角度[13，33，36］．包括来自不同背景的参与者创建了数据资源的三角测量，这增加了研究结果的可信度。此外，成员检查显示，参与者同意所确定的有经验的障碍和促进者。

在解释本研究的结果时，应考虑到研究设计的一些局限性。首先，在访谈中，参与者反映了1-2年前开始的发展过程，这可能会造成一定程度的记忆偏差。然而，在开发过程的后期阶段反思开发过程也可能比在开发过程的中间阶段采访参与者有好处。在后一种情况下，参与者的回答可能会受到采访时项目所处阶段的影响。其次，参与者被要求批判性地反思他们所参与的开发过程，因此他们必须反思自己的行为和团队成员的行为，这可能是一个敏感的话题。为了限制这种敏感性，一位不属于参与者开发团队的研究人员进行了访谈。但是，不能保证所有障碍和促进因素都已向采访者报告。第三，这篇论文的作者在这项研究中扮演了双重角色，因为他们采访的参与者不是研究人员，但他们也是开发团队的核心成员(因此他们自己也接受了采访)。远程遥控产品和服务UCD研究人员的参与和经验可能会影响数据收集和/或分析。为了将这些影响降到最低，我们让研究人员只采访与他们参与不同研发项目的参与者，制定了一份访谈主题清单，供所有访谈人员在整个研究过程中使用，并与2名研究人员一起制定了编码方案。 Finally, data from the interviews with the researchers and from the interviews with other team members were treated as equal in the analyses. This is not necessarily a limitation, but it might be considered a notable feature of the study design. The main reason for this novel and somewhat unusual approach was that the researchers themselves had experienced and influenced the development process just as much as other members of the development team. Not interviewing the researchers could have resulted in missing barriers and facilitators that they themselves experienced.

结论

在远程医疗产品和服务UCD期间，多学科开发团队成员所经历的障碍和促进因素之间似乎存在许多相似之处。然而，不同背景的团队成员之间的经验也存在差异。深入了解这些相似点和不同点可以提高来自不同背景的团队成员之间的理解，这可以优化远程医疗产品和服务开发过程中的协作。