建模数据之旅为肾移植服务的数字化转型提供信息:观察研究

介绍

数据旅程建模是一种新兴的方法，旨在帮助理解作为数字化转型一部分的数据移动的社会技术挑战和边界[1，2]。它已成功地用于识别医疗保健系统内信息技术(It)项目的风险和成本，例如英国国家医疗服务体系(NHS) [3.]。具体来说，数据旅程建模提供了与临床服务相关的数据实体、IT系统、手工流程和组织的高级概述。它是一种交叉协作的方法，连接健康信息学家和临床领域专家，目的是产生与临床服务相关的It基础设施的概念性概述。这允许从以数据为中心的角度更好地理解服务是如何交付的，并有助于提供有意义的解决方案。因此，数据旅程建模已被证明可以识别提高运营效率、数据管理和患者安全的机会，以及其他潜在的好处[3.]。本研究的目的是将数据旅程建模应用于计划进行数字化转型的肾脏移植这一特定临床用例。

肾移植是一项区域性、多组织的临床服务[4]。它在大型大学医院(移植中心)提供，这些医院接收来自邻近肾脏转诊单位的患者。这种轮辐模式可以覆盖广泛的地理区域，类似于其他专业服务，如癌症、遗传学和血管服务。移植患者的旅程是复杂的，需要捕获大量的异质临床数据。涉及多个临床团队，患者自然跨越组织界限，从肾功能下降到肾功能衰竭，最终到肾移植。在病人就诊过程中的数据采集需要细致的管理，以防止延误和瓶颈[5]。然而，跨组织管理大容量、复杂的临床数据既耗时又容易出错，还会产生巨大的管理成本。2014年英国移植优先倡议认识到了这一点，并指出“技术和行政支持的低效使用”是及时移植的主要障碍之一[6]。的美国移植杂志进一步强调全院电子病历(epr)缺乏整合对肾脏移植护理的影响[7]。

由于上述原因，移植是一个临床领域，将受益于数字解决方案，以改善数据的管理和流动。医疗信息技术已被证明成功地实现了这些预期的好处;然而，新的干预措施往往因不被采用和失败而受到损害。［8]。缺乏对变革的技术和组织背景的理解是限制成功的关键因素之一[9，10]。由于缺乏对干预措施的社会方面的考虑，存在进一步的障碍，这些干预措施依赖于人力投入，因此受到抵制变革和未能与最终用户分享所感知到的利益的影响[11]。在开发新的干预措施时，往往没有将最终用户包括在需求收集过程中，因此，解决方案无法实现其预期的利益[1，12]。为了成功地克服这些挑战，数据旅程建模被确定为一种方法，用于理解当前的IT基础设施，并让领域专家参与开发潜在的解决方案。

移植转诊过程是整个移植患者旅程中不可分割的一部分。它依赖于从移植中心的各种内部和外部来源获取数据，最后将患者登记在国家器官等待名单上。本研究旨在从数据之旅的角度来理解这一过程。具体目标是:(1)绘制数据管理过程，包括IT支持在区域移植网络中的作用;(2)根据已建立的框架确定挑战并对其进行分类;(3)使用结果发现建议潜在的解决方案。

方法

概述

我们采用迭代和增量的方法，根据临床和管理领域专家的输入构建数据旅程模型。我们使用建模过程来识别数据管理的潜在挑战，并与没有参与原始建模的领域专家一起验证模型的最终版本。

上下文

我们研究的背景是曼彻斯特大学NHS基金会信托的移植中心(曼彻斯特，英国)。它是英国最大的肾脏移植中心[13]，接收来自另外两个区域肾脏转诊单位(皇家索尔福德NHS基金会信托基金和兰开夏教学医院NHS基金会信托基金)的患者。移植中心每年在全国移植等候名单上登记约300名新患者。病人还接受当地全科医生的治疗，通过以社区为基础的医疗服务来维持长期健康。

每次转诊包括几次医院访问、医学检查和临床评估。多个卫生保健专业人员在不同阶段参与的途径。路径上的数据捕获是在一个称为“清单表单”的Microsoft Word文档上进行的。列表表单的各个部分由临床团队成员在多个临床时间点填充患者数据。捕获的数据包括常规医疗保健数据，如病史、测试结果和检查结果。需要一份完整而准确的名单表来评估患者是否适合移植，并允许在全国等待名单上登记。表格填妥后，若认为病人适合移植，表格便会送交移植化验室登记(图1）.

‎ 查看此图

数据旅程建模

数据旅程建模有3个步骤，总结为图2。其目的是建立哪些IT系统包含与移植相关的数据，哪些组织参与提供服务，哪些个人提供直接护理或管理(即，哪些个人是参与者)，并了解参与者与系统之间的相互作用。这将提供IT基础设施的全面概述，提取和存储数据的过程，以及作为转诊途径的一部分的数据旅程。然后，我们使用与数据旅程建模一起开发的既定框架来分析结果，以帮助描述我们的发现并得出有意义的结论[1]。最后，我们评估了模型的最终版本，并与最初没有参与开发方法的领域专家一起评估了建模过程中的发现。

‎ 查看此图

文档评审

我们回顾了当地关于移植中心的已故供体、活体供体和移植受体途径的书面协议。我们提取了通常期望在清单表单上捕获的所有数据实体，并交叉引用了存储这些项目的IT系统。我们确定了参与提供服务的其他医疗保健组织，并划定了它们的边界。最后，我们确定了哪些参与者在移植中心的转诊途径中发挥了作用。有了这些信息，我们设计了数据旅程模型的基线迭代，该模型演示了技术和组织基础设施，但仍然缺少参与者和数据旅程。我们使用Lucidchart软件(Lucid software, Inc .)，一个基于网络的图表和视觉设计应用程序，来绘制我们的模型迭代。

领域专家访谈

我们进行了非正式访谈，并与在移植中心工作的领域专家举行了小组会议，以收集进一步开发模型所需的信息。我们将领域专家定义为参与直接患者护理或移植相关数据后台管理的临床或管理团队的任何成员。我们确保这涵盖了通过文档审查和模型的基线迭代确定的所有必要的参与者。我们采访了4名移植协调员、2名肾病学家、2名外科医生、1名移植评估护士、2名秘书和1名实验室管理员。领域专家访谈提供了用于提取和存储数据的过程的信息，以及IT系统之间和跨组织边界的数据旅程。会议持续了15至60分钟;我们保留了这些会议的书面记录，以提高准确性和记忆力。

迭代建模

我们遵循敏捷启发的方法来开发基于增量方法的模型。敏捷是一种适应性项目方法，它依赖于与干系人的持续协作，根据反馈和重复的审查周期来改变输出[14，15]。它已被证明可以成功地完成医疗保健项目的目标，并且非常适合于依赖于领域专家的嵌入反馈来迭代最终版本的模型的开发[16]。

我们对各个参与者在其工作中处理关键数据实体以及捕获和存储数据或将数据从一个系统移动到另一个系统的过程进行了建模。与数据旅程建模师和领域专家共举行了5次迭代会议，以创建用于分析的最终模型。

分析与外部评价

我们使用LOAD框架来分析数据旅程模型的最终版本，并对我们的发现进行分类。LOAD代表“场景、组织、参与者和数据”，每个代表作为临床服务一部分的IT维度(图3) [1]。使用LOAD框架确保我们全面地分析了模型和相关的数据旅程，使我们能够识别技术障碍，例如缺乏系统互操作性，以及社会挑战，例如手动解决方法。

然后，我们通过与没有直接参与模型开发的领域专家进行半结构化访谈，从外部评估最终模型。受访对象包括2名移植协调员、1名移植外科医生和1名肾内科医生。我们向他们展示了这个模型，并询问他们是否准确地反映了移植中心的临床工作流程和数据管理过程。我们促使他们考虑LOAD框架的要素，并思考花费在数据管理上的时间如何影响服务的交付和患者体验。会议通常持续30分钟，并以研究笔记的形式记录下来。

‎ 查看此图

结果

数据旅程模型的基线迭代

在文献回顾的基础上，我们建立了模型的基本要素。有四个组织提供了与提供服务相关的患者数据:1个移植中心，2个转诊中心和1个全科诊所。在移植中心内，我们确定了6个保存移植转诊途径相关数据的IT系统(表1）.移植中心的组织边界之外还有几个外部IT系统，其中包含相关数据。这些系统是全科诊所的系统，包含病史和药物数据，其他信托机构的系统包含当地病史和结果。由于我们没有详细地映射其他组织的IT系统，我们将它们表示为单个IT系统，尽管每个组织可能使用多个系统。最后，一旦临床路径上的数据收集完成，数据将通过一个名为“器官捐赠和移植在线”(由NHS血液和移植部门内部开发)的网络系统传输，将患者登记在全国等待名单上。

我们确定了在管理临床数据中起作用的4个角色:临床医生、移植协调员、秘书和管理员。“临床医生”一词指的是多个专家，包括肾病学家、外科医生和移植评估护士。然而，由于他们的角色从数据的角度来看是相似的，为了我们模型的目的，我们将他们表示为“移植临床医生”。图4演示文档审查的输出和数据旅程模型的第一次迭代。

‎ 查看此图

最终数据旅程模型

基线模型和领域专家的访谈迭代地告知参与者交互和数据旅程，这些被添加到模型中以创建最终版本。这些组织被重新安排，将移植中心放在模型的中心，其他组织围绕着它。移植中心内的IT系统之间或跨组织边界的系统之间没有直接的数据传输。很明显，共享驱动器是数据管理的中心焦点。这是一个内部解决方案，因为需要集中捕获和查看临床数据;现有的制度无法满足这一需要。为了完成工作流，至少需要12个独立的参与者与IT系统进行交互。参与者与IT系统的交互次数最少:临床医生，5次交互;协调员，3次互动;秘书，2次互动; and administrators, 2 interactions. The final data journey model is shown in图5。

‎ 查看此图

负载分析

最终的数据旅程模型和来自领域专家的外部评估反馈使我们能够基于LOAD维度分析结果。

景观

从数据的角度来看，整体景观显示了移植转诊途径的复杂性。资讯科技系统不是为移植服务的需要而开发的，也没有随着需求的变化而更新。缺乏跨组织边界的互操作性引发了数据治理问题，并且不清楚组织之间的数据共享是否是正式协议的结果。没有IT系统提供移植数据的统一视图，这导致了以Microsoft Word文档和共享驱动器形式的变通解决方案。这导致了这样一种局面，即人类参与者，而不是IT系统，形成了数据移动的中心焦点。

组织

关键数据主要存储在移植中心的组织边界内。患者数据，如不在中心进行的调查结果，存储在转诊单位和一般做法的外部。外部组织的IT系统没有直接的数据传输到移植中心;这些数据通常通过邮寄、电子邮件或传真的方式传递给移植协调员。然后，他们手动扫描纸质数据，并将其与其他电子数据一起保存到共享驱动器中。我们发现，三分之二的患者通过该途径来自外部转诊单位。这意味着，对于大多数登记在等待名单上的患者来说，移植中心没有最新的临床数据。所有受访者都表示，这对临床工作流程构成了重大挑战。从转诊单位获取数据花费了时间，由于需要反复请求，经常出现延误。另一个社会挑战是缺乏问责制，临床工作人员不清楚谁负责更新和准确的数据:移植中心还是转诊单位。

演员

数据之旅完全依赖于参与者与IT系统的交互和数据的手动转录。关键数据存储在多个IT系统中，这导致了效率的降低，因为临床医生必须多次登录才能查看和提取数据。只有两个参与者组能够与共享驱动相互作用，这意味着在他们缺席的情况下，患者将无法沿着列表路径前进。领域专家报告说，这给整个数据旅程造成了瓶颈，并导致患者延误。由于在多个应用程序之间切换以访问和转录数据是不现实的，参与者报告使用启发式解决方案，例如使用两台设备(例如笔记本电脑和台式机)。然而，从采访中可以看出，演员在数字能力方面存在差异，他们报告了与系统互动的一系列经验。

数据

我们发现清单表单总共包含247个需要填充的数据字段。所有需要的数据都存储在移植中心的5个IT系统和全科医生或转诊中心的系统中。在IT系统之间或从系统到移植共享驱动器之间没有数据传输。为了将数据移动到共享驱动器，临床医生必须访问不同的系统，并将临床数据转录(即键入)到相关字段中，并将表单保存在指定的共享文件夹中。文件名保存为患者的姓和名。填充表单所需的所有数据都是电子格式的。数据直接转录，不需要任何临床专业知识进行转化或操作。领域专家访谈显示，转录错误和不完整的数据字段是患者风险和列表路径延迟的来源。目前也没有办法确认数据的准确性或强制完成数据。受访者进一步表示，他们对耗时的任务感到沮丧，这减少了与患者相处的时间。

风险缓解策略

上述调查结果表明，具有商定的数据共享和治理合同的区域解决方案将有助于减轻当前分散格局的风险。需要建立一个具有移植中心和转诊单位可访问的用户界面的中央临床数据存储库。考虑到移植转诊途径中涉及的多学科参与者的范围，用户界面必须具有适应性和易于操作，以降低采用的障碍。从技术上讲，这样的解决方案将受益于基于web和使用云存储提供跨组织边界的安全性和安全访问。互操作性和开放数据标准将支持跨IT系统的数据集成。至关重要的是，通过本研究的结果提供的对需求和要求的深刻理解，应该推动解决方案的开发，以实现预期的利益。这也适用于其他临床领域的医疗IT项目，证明了这种方法的价值。

讨论

主要研究结果

本研究应用数据旅程模型对肾移植转诊路径进行评估，成功识别出数据、IT系统、参与者和组织，以及它们之间的关系。这提供了对数据环境的概述，并突出了数据管理的复杂性以及数据流的缺乏。我们发现临床工作人员必须进行繁琐的手工流程来总结和可视化来自多个IT系统的数据。在缺乏有意义的解决方案来满足临床工作流程的需求和要求的情况下，已经创建了变通方案。缺乏互操作性和对相关数据的集中访问增加了完成移植转诊所需的工作量和时间，这可能会延迟患者在移植名单上的登记。

与其他研究的关系

这是首次将数据旅程建模应用于移植服务。以往的研究从临床管理的角度强调了肾移植的复杂性。这些建议采用资讯科技解决方案，例如业务流程管理技术，以降低管理成本[17]。我们的研究建立了对人工流程管理数据的依赖，这可能会产生管理成本。当前的数据环境严格服务于文档流程，不提供任何流程支持。整个欧盟的经验表明，当代IT系统和EPR系统必须提供数据捕获之外的功能，以更好地支持临床服务的需求[18]。

这项研究发现，移植过程中的数据旅程自然地跨越了专业和组织的界限。然而，由于缺乏互操作性，因此依赖于参与者交互来共享数据。在其他临床领域，跨组织边界访问数据仍然是一个重大挑战[19]。芬兰国家EPR系统的引入促进了数字途径在肾病学和移植领域的实施[20.]。然而，人口异质和地理差异较大的国家在协调分散的卫生保健数据方面面临挑战[21]。本研究中进行的数据旅程建模证实，互操作性仍然是有意义的数字化转型的关键障碍之一。

对实践和未来概念的启示

数据旅程建模显示，在转诊过程中，临床医生不需要转换或操作任何数据来完成表格，因此IT挑战是总结和查看相关信息的格式，允许无缝和增强临床决策。在英国，全科医生认识到早期定制的临床数据查看的价值，初级保健IT系统对临床医生的使用更加直观[22]。然而，在医院环境中，存在一个悖论，即由于依赖用户交互来查看数据，IT系统通常会减少与患者的接触[23，24]。Zeng等人的早期研究[25评估了以概念为导向的临床数据观点与传统的按时间顺序呈现的数据，例如在当前的epr中。他们证明，在临床环境中可视化数据，如疾病或器官系统，减少了信息过载，提高了数据检索的准确性。根据本研究确定的数据领域，对于肾移植，这将包括提供相关人口统计数据的单屏摘要，以及医疗和社会历史，以及与透析和既往手术相关的详细信息。这将允许临床医生在遇到问题时关注患者，并将以前没有记录在任何IT系统中的相关临床细节添加到患者记录中，例如残余尿量、运动耐受性或检查结果[26]。

这项研究的结果强调了移植特定解决方案的技术要求，该解决方案具有跨相关组织的区域性集成数据存储，并具有满足临床工作流程需求的应用程序处理接口(图6）.医疗保健IT的独立数据和应用层可能有助于克服当前的互操作性障碍，并使开发特定于服务的模块化解决方案成为可能[27]。集中的临床数据存储库可以促进模型-视图-控制器软件开发的应用，使各个临床领域有机会设计适合其上下文的视图[28]。跨系统的语义互操作性允许数据容易地交换、分析和解释，并且是有意义的数字转换的先决条件。相比之下，存储在孤立数据库中的数字数据不仅减缓了医学进步，而且限制了诸如实时分析和研究数据重用等技术创新。［19，26]。诸如快速医疗保健互操作性资源协议和OpenEHR原型等解决方案可能会解决未来的这些挑战，但在广泛采用之前仍需要进行开发[29，30.]。

‎ 查看此图

医疗保健信息和管理系统协会根据能力、互操作性和治理定义了个体医疗保健提供者的数字成熟度[31]。然而，由于移植服务的多中心性质，我们发现数字成熟度受到构成提供服务一部分的最不成熟组织的限制。因此，即使移植中心拥有先进和统一的EPR系统，但患者是由其他组织转诊的，无法共享数据，这意味着临床过程无法得到充分支持。因此，应使用互操作性框架评估任何新解决方案的潜在影响[32]。此外，获取定量数据，如加入移植等待名单所需的时间，可以提供影响的衡量标准。

在整个医疗保健领域，临床数据仍然受到组织边界的限制，新的EPR采购没有积极考虑区域工作流或数据共享，从而加强了供应商锁定[33]。为此，英国国民健康服务体系启动了“当地健康和护理记录范例”项目，该项目的任务是在一个地区内增加初级、二级和社会护理的临床信息共享[34，35]。移植可能是这种互操作性倡议的一个极好的用例，可以向临床医生、政策制定者以及至关重要的患者展示价值。关联数据将为了解卫生系统提供基础，这些系统能够直观地了解其人口需求，并为及时干预提供信息，以改善长期卫生和社会保健结果。［36，37]。

本研究的局限性

还有许多其他模型可用于评估医疗IT基础设施。数据旅程模型和LOAD框架是根据英国卫生保健环境开发的，并被选为最适合使用的工具[38]。然而，它们尚未在其他临床领域得到广泛应用，可能是因为它们在建模过程中严重依赖领域专家提供输入。在我们的案例中，这项研究是由一位临床研究员领导的，他能够帮助弥合临床和学术利益相关者之间的差距。最后，这项研究只关注了一个地区移植中心。这使得我们的发现在多大程度上可以转化为其他地区的未知，需要进一步的调查。

结论

必须充分了解复杂的临床护理途径，以便将有意义的解决方案作为数字化转型计划的一部分提出。数据旅程建模成功地为肾移植中的健康信息技术提供了有价值的社会技术因素。它强调了互操作性的缺乏如何导致与多个系统进行耗时的人工交互，以总结移植转诊数据。数据跨越多个组织边界，所有数据的移动都依赖于参与者的交互，即使没有数据被转换或操作。未来的解决方案必须考虑区域互操作性、满足临床需求的定制系统，以及将临床工作人员从管理负担中解放出来的自动化流程。