部署面向患者的应用程序编程接口:卫生系统经验的专题分析

简介

背景

一系列联邦政策努力试图通过改善患者对其电子健康信息(EHI)的访问来创建一个更加以患者为中心、消费者赋权的医疗保健系统[1，2］．以前创建病人控制的健康记录的努力(最著名的是谷歌health和Microsoft HealthVault)从未获得关注，部分原因是缺乏容易获得的数字病人数据[3.］．从那时起，医疗保健系统已将健康数据显著数字化，96%的医院和78%的医生办公室现在使用认证电子健康记录(EHR)技术[4］．一项针对全国消费者的大型调查显示，消费者希望并使用电子方式获取他们的健康信息，包括通过智能手机移动访问和使用健康应用程序[5］．与此同时，现在的法规要求患者及时(在48小时内)获得[6]以电子方式查看、下载和传输他们的健康记录(而不是只能接收纸质副本)。从2019年1月1日开始，随着联邦医疗保险和医疗补助电子病历激励计划(现在称为促进互操作性计划)的第三阶段实施，并得到《21世纪治愈法案》条款的支持，卫生系统必须“不需要特别努力”，通过面向患者的应用程序编程接口(api)向患者提供电子访问其电子病历的权限[1，7］．

这些面向患者的api现已开始上线，使患者可以访问他们的EHI，也可以直接通过第三方软件应用程序访问[8］．这可能是美国医疗保健系统发展的关键时刻，因为成功可能会打破长期孤立的患者数据[9]，从而在互操作性方面取得更好的进展，使患者能够创建自己的纵向健康记录，并通过新兴的第三方应用程序生态系统实现患者参与的潜力。然而，成功并不是必然的结果，卫生系统开始在政策、报销、技术实施、治理、隐私和安全等不确定性和复杂问题中追求面向患者的api [10］．当卫生系统纠结于如何部署面向患者的api的众多决策时，他们冒着在竖井中这样做的风险，而没有组织间学习的好处[11］．这将限制新兴最佳实践的识别和共享，以及遇到的挑战，增加早期失败的可能性，从而阻止下一波采用者。因此，通过面向患者的api获取和分享早期经验，对于为正在进行的政策和实施工作提供信息至关重要，这些政策和实施工作旨在确保这一国家过渡是安全和可靠的，并具有加速患者数据访问、提高护理质量和增加数字化参与患者可用工具的选择的预期影响。

目标

我们试图确定和总结早期采用者卫生系统是如何规划和实施面向患者的api的。我们特别想确定他们的理解、他们的总体策略和关键用例，包括相关的组织基础设施、治理、策略和过程，以及策略和其他外部驱动因素如何影响他们的方法。最后，我们的目标是确定在这些早期经验中遇到的障碍，这些障碍可以为政策和实践工作提供信息，并有助于促进广泛采用和有效使用面向患者的api。

方法

招聘

我们创建了一个方便的卫生系统样本，已知是卫生技术的早期采用者，包括从事iPhone上面向患者的API试点的卫生系统(苹果新闻稿中包含的卫生系统列表)和其他已知是API技术用户的卫生系统(来自作者的专业网络的列表)，然后还通过确保每个人口普查区域(东北部、西部、中西部和南部)至少有一个卫生系统来选择区域差异。尽管api可以被患者、提供者、付款人、第三方应用程序和其他人使用，但我们使用“面向患者的api”来描述用例病人是参与者通过API请求EHI，或指示第三方应用程序代表他们访问信息。在企业对企业API用例中，卫生系统或其他覆盖实体通过API与其他覆盖实体或业务伙伴连接，以交换健康数据。尽管API本身在技术上可能在这两个用例中是相同的，但联邦政策、数据授权工作流以及最终许多特定的用例是不同的，这导致我们分别检查面向患者的API。

访谈指南和数据收集

我们开发了一份半结构化的访谈指南，涵盖了当前面向患者的API工作和能力、感知的障碍和风险、政策问题、组织治理和经验教训(多媒体附件1)．我们通过电子邮件联系了系统的首席信息官(cio)，因为这些领导者通常对主题有最广泛的理解，并邀请他们或具有api主题专业知识的指定人员参加采访。然后，我们提前分享了采访问题，并安排并进行了长达一小时的单独采访。我们纳入了同意参与访谈的前10个卫生系统。我们在2018年9月至12月期间进行了采访(通过电话或视频会议)。所有采访都进行了记录和转录。我们的研究得到了加州大学旧金山分校机构审查委员会(18-25416)的批准。

分析

我们使用分析矩阵对访谈记录进行了内容分析，从与我们研究领域相关的三个核心主题类别中提取相关陈述:战略与实施、技术问题和障碍与成本。

策略和实现领域内的具体主题类别包括(1)整体API策略(包括提供商和面向患者)，(2)面向患者的API用例，(3)实施计划的现状，(4)形成API策略的因素(组织和政策)，以及(5)API读写、应用白名单或黑名单、API对患者和开发者的宣传和营销以及iPhone上的Health Records的参与的具体决策和理由。

技术问题领域内的特定主题类别包括(1)实现面向患者API所需的努力级别，(2)EHR供应商参与和支持的级别，(3)直接使用API或与中间件一起使用API， (4) API管理人员配备，(5)一次性访问令牌与持久访问令牌，(6)监控面向患者API使用的能力，以及(7)技术经验教训。

障碍和成本领域中的特定主题类别包括(1)实现和使用面向患者api的障碍和成本，(2)系统为使用面向患者api评估的费用，以及(3)EHR供应商为使用面向患者api评估的费用。

为了减少偏见，我们在矩阵中给每个受访者自己的行。然后，我们通过四位作者之间的讨论和共识确定了主题类别内和跨主题类别的主题。在某些情况下，我们以更简洁、结构化的方式总结主题，然后报告支持该主题的相关受访者数量。在其他情况下，我们更注重叙述来总结主题。在这两种方法中，我们都使用示例引用来支持主题。在下面的Results部分中，我们根据受访者的组织角色(例如，CIO1、CIO2、CTO1和CTO2)，用每个受访者唯一但匿名的标识符对报价进行编码。

结果

样本特征

受访的卫生系统分布在美国各地，大部分位于东北部或中西部。卫生系统的规模参差不齐，年临床收入从低于100亿美元到超过200亿美元不等。大多数医疗系统都使用Epic systems的电子病历作为主要电子病历，这些系统的一个子集由于附属、收购和区域合并而在不同的位置使用额外的电子病历。我们采访的领导者涵盖了一系列角色，包括首席信息官、执行副总裁、首席技术官、高级医疗总监和副首席转型官(表1)．

面向患者的应用程序编程接口策略

表2描述了受访机构的API策略。在这10个组织中，有8个组织已经启用并运行了面向患者的api，还有2个组织处于规划阶段。在拥有面向患者的操作api的8个组织中，有5个组织为它们的使用制定了具体的策略(包括专门的技术支持和明确的治理)。八个组织中的其他三个已经激活了面向患者的API，但对所有用户都有一个通用的API策略，而不是特定的面向患者的API策略或基础设施。当我们更详细地询问API治理时，七个组织表示API决策是在执行或董事会级别做出的，两个组织表示API决策是由技术团队(低于执行级别)做出的，还有一个组织创建了一个专门的API委员会来制定面向患者和企业对企业API的决策。

我们确定了与组织API战略相关的两个更广泛的主题，其中包括影响卫生系统战略的因素和用例，并鼓励他们采用和使用面向患者的API。

主题1:多种因素形成面向患者的应用程序编程接口策略并促进采用和使用面向患者的应用程序编程接口:联邦政策和法规、iPhone可用性的健康记录和道德义务

当被问及是什么形成了他们的战略时，他们确定了三个不同的因素。第一个因素是联邦政策和法规要求面向患者的api，特别是要求患者可以访问并能够通过面向患者的api使用他们的健康数据。正如一位受访者解释的那样:

我想说的是，CMS(医疗保险和医疗补助服务中心)法规是最重要的因素之一，或者更确切地说，我们认为CMS法规将成为一个重要因素。这既包括有意义的使用，也包括围绕互操作性的其他类型的法规[]。我不得不说，法规确实发挥了很大的影响。
(CTO2)

第二个因素是苹果公司决定让患者可以通过iPhone上的健康记录下载他们的健康记录数据到他们的苹果智能手机上。在我们的样本中，共有六个组织选择与苹果合作部署这一功能，这需要使用面向患者的api。第三个因素是价值评估或感知道德义务，以部署功能，使患者更好地访问他们的健康数据。正如一位受访者所说:

我们认为，患者应该以一种容易与他们想要与之分享的人分享的格式分享他们的数据。
(EVP1)

主题2:两个优先用例正在推动面向患者的应用程序编程接口工作

第一个用例(由六个组织引用)包括使用面向患者的api，使患者能够访问健康信息，以促进纵向健康记录，结合来自多个提供者的信息以及提供者和付款人数据的集成。面向患者的api能够促进这种用例(超越ehr绑定的患者门户)，因为它们支持来自多个来源的数据集成。第二个用例(由四个组织引用)包括使用面向患者的api来增强患者对卫生系统的数字体验，包括他们使用远程医疗等便利功能的能力，例如，在虚拟就诊之间传输健康数据，并促进自我调度。对于这些系统，此用例符合消费者日益增长的期望，即医疗保健与旅行、食品服务和金融服务等其他行业一样，提供广泛可用的数据访问和方便的自助服务功能(主要通过移动应用程序)[12，13］．

当被问及他们组织的主要用例是否会在未来2或3年内发生变化时，大多数受访者认为他们不会。然而，他们确实分享了关于该功能如何演变以提供新价值的具体想法，特别是通过开始实现更好的数据驱动的患者自我管理。例如:

我认为我们将看到更多的分析和情报被推向面向患者的api，用于自我分类管理和升级，而不是今天的服务器端，我们(卫生系统)必须对其进行管理和分类……我认为它将更加主动，而不是被动。
(SMD1)

另一个说:

[未来]如果您检查我的数据，并能够将其与生活方式数据和其他信息结合起来，这些信息将为我的信息增加见解和价值，超出我的提供商门户所能做到的范围，那么我将很感兴趣。
(VP1)

面向患者的应用程序编程接口的操作和技术特征

在八个具有面向患者的操作api的卫生系统中，我们总结了它们的操作和技术方法以及实施决策的主要特征(表3)．api可以允许患者访问数据(读取)或提供数据(写入)。所有这8个卫生系统都在运行中读取api。虽然有7个至少有一些写功能，主要集中在患者的家庭设备数据，但这些写API功能的实现是可变的，其中一些只提供给受邀患者的一个子集，而不是所有患者。在患者是否可以直接将数据写入电子病历或是否需要卫生系统审查和批准才能授权将数据写入电子病历方面也存在差异。

第二个API实现决策涉及如何批准第三方应用程序访问API。在应用程序访问API之前，所有八个卫生系统都需要事先批准应用程序或白名单。对于其中四个，卫生系统保持白名单;对于其他四个，由EHR供应商维护。对于第三方应用程序连接到面向患者的API，开发人员需要有关API配置的文档。共有四个卫生系统表示，开发人员可以通过他们的EHR供应商获得该文档，其中两个卫生系统表示，他们将根据开发人员的要求提供该文档，还有两个卫生系统没有为开发人员提供文档。值得注意的是，这些健康系统都没有可供任何开发人员访问的公开API文档。总之，有两个卫生系统指出，他们正在通过面向患者的API积极向患者群体宣传患者数据的可用性，其中一个特别指出，其重点是如何利用面向患者的API功能来帮助“向他们推销体验[而不是底层技术]”(SMD1)。

在面向患者的API的更多技术维度方面，两个医疗系统依赖其EHR供应商来管理API，而六个医疗系统则使用中间件供应商进行API管理。API管理指的是一系列功能，包括API访问控制、API创建和设计、API保护、业务价值报告以及API流量控制、性能和节流[15］．对EHR供应商而不是中间件的依赖似乎至少部分是由EHR供应商的能力驱动的，无论是真实的还是感知的，以及供应商之间可能的差异。正如一位受访者所说:

一些电子病历让这变得很容易，我想说[供应商]就是其中之一。其他的难度更大。我认为这很复杂，因为这取决于他们的内部资源、关注点、结构和能力。
(CTO2)

另一位受访者补充说:

你必须有API中间件。[否则]，你将无法监控交通流或限制交通流，或识别模式。电子病历供应商永远也搞不清楚这一点。
(CIO3)

我们还询问了卫生系统访问令牌的方法，这些令牌可以是持久的(例如，在每次API尝试读取或写入患者数据时不需要登录凭据)或一次性的(即，在使用API的每个会话时都需要登录)。总的来说，受访者对正在使用的令牌类型表示不确定，有两个组织明确表示不确定，其中两个认为他们使用了持久令牌，三个认为他们使用了一次性令牌。

最后，当被问及与面向患者api相关的费用时，没有一个卫生系统正在或计划向患者收取使用面向患者api的费用——考虑到监管机构禁止对使用认证EHR技术中的面向患者api的患者访问其健康信息收取费用，这是合适的。此外，没有一个卫生系统为使用面向患者的api而向其电子病历供应商支付特定的费用。

当前和未来实现和使用面向患者的应用程序编程接口的感知障碍

我们确定了实施和使用面向患者api的六个障碍(表4，多媒体附件2)．五家卫生系统列举的最常见的问题是，启用面向患者的api带来的安全或隐私问题，例如未经授权的访问或恶意行为者的潜在攻击。例如:

我们有点担心(法规)的精神基本上是，如果任何应用程序敲开你的门，病人真的想这么做，那么你有什么资格去评判……(但)如果我们不能安全地交付它，因为应用程序创建得很糟糕，或者真的做了一些事情，比如把数据泄露给制药公司，怎么办?
(CIO3)

卫生系统没有准备好识别和区分值得信任的应用程序供应商和不值得信任的应用程序供应商，随着应用程序生态系统的发展，这应该由谁来承担责任，这也表达了额外的不确定性。在我们的受访者中，一些人建议EHR供应商继续发挥作用，而另一些人则建议成立第三方评级联盟，其中一人建议“创建一个专业知识驱动的团队来策划投资组合将是最有意义的”(CIO2)。经常与安全问题联系在一起的一个因素是卫生系统的财务风险，例如:

当有不好的事情发生时，他们不会去找那些刚起步的小供应商。他们将攻击(医疗系统)。所以这就是为什么我认为我们必须尽可能清楚这个决定意味着什么，以及你的信息会去哪里。你们要为这个决定负责，而我们不用。
(VP1)

受访的一个卫生系统已经采取了措施，试图缓解这一问题，该系统表示:

我们确实有一份这些建议的清单，并为患者的数字健康隐私提供了一种入门……如果我们让(健康数据)可用，人们应该知道如何取消应用程序的授权，如果他们怀疑某个应用程序对他们的数据做了错误的处理，他们应该知道该怎么办。
(CIO1)

四个卫生系统指出，使用面向患者的api的应用程序功能不足是一个障碍。卫生系统认为，目前的第三方应用程序生态系统还没有提供一个令人信服的替代方案，以ehr为纽带的门户。例如:

首先，消费者应用程序需要提供一些比供应商移动应用程序更有吸引力的附加价值。
(ED1)

另一位受访者说:

(我们)在门户网站上投入了很多。(我们)担心这可能会吸引一些人离开。
(CTO1)

三个卫生系统列举了一个相关的障碍，即缺乏可感知的商业价值或投资的财务回报，其中一人表示:

缺乏外部刺激。它不是一个收入驱动因素。这不是降低成本。
(CTO1)

另一个说:

在某种程度上，如果你有10万个不同的应用程序与人们连接，在某种程度上，有人将不得不为此付费。我不知道具体是怎么解决的。
(CIO1)

三个卫生系统提到的另一个障碍是他们的电子病历供应商对数据共享持谨慎态度。一位高管说:

许多供应商将数据获取视为他们的一种策略，因此他们不允许您共享数据。
(EVP1)

另一个说:

(他们认为)患者会下载恶意软件，窃取他们的患者数据，并利用这些数据做邪恶的事情。
(ED1)

一个系统投诉如下:

我们[电子病历供应商]需要开放你的数据，这样我们就可以在你正在做的事情之外做一些事情，这样其他人就可以做一些事情来补充你正在做的事情。
(CIO2)

最后，系统指出，医疗保健中不发达的技术和标准是一个障碍。例如,

他们(FHIR)增加(数据元素)的速度非常缓慢。[我们的EHR]中有4000个数据元素，我认为他们已经通过FHIR[快速医疗互操作性资源]完成了大约150个数据元素。
(CIO2)

另一位受访者补充说:

有趣的是，api确实需要你建立一种健壮性和可扩展性，这是你过去从未真正设计过的，因为这一切过去都是由相当有限的医生群体完成的，他们的行为相当容易理解，而不是成千上万的人。可以每六秒更新一次医疗记录…[FHIR]的发展如此之快……一个nd so suddenly you’re engineering a set of apps on shifting sands.
(CIO3)

对于可用的技术设置存在一些担忧，例如:

我们没有能力告诉病人这个应用程序能在多长时间内访问他们的数据。这是一个很大的因素。
(VP1)

另一个与不太先进的技术能力相关的具体问题是，在EHR中创建的某些设置可能无法通过面向患者的API传输。例如:

在门户中，你可以加入一些规则，比如在医生公布癌症诊断之前不显示癌症诊断，但我听说在HealthKit API中，所有这些过滤器都没有了，所以你可能会在医生知道之前就在手机上发现你的癌症诊断。
(CIO3)

讨论

主要研究结果

在这项研究中，我们采访了10个领先的卫生系统，了解他们使用面向患者的api的方法，以了解早期经验，并为政策和实践确定见解。我们的研究结果表明，我们有理由对面向患者的api的前景及其对美国医疗保健系统的影响持乐观态度。在使用患者门户方面取得进展的基础上，面向患者的api进一步扩展了技术能力，使我们进一步实现了近20年前在健康保险可携带性和责任法案隐私规则中所记载的希望，该规则赋予患者访问和使用其全部指定的健康记录集的权利。

我们采访的卫生系统都计划增加面向患者api的使用，许多人表示这是“正确的做法”。两个用例作为卫生系统的战略驱动力出现:患者创建汇总纵向健康记录的能力和更好的数字化患者参与。然而，我们也发现在战略以及操作和技术方法上存在很大的异质性。这表明，目前还没有最佳实践来指导卫生系统如何使用面向患者的api，也没有明确的业务模型来推动其实施的共同战略路线图。我们还发现了跨越一系列领域的普遍感知障碍，这表明需要在政策和实践层面进行额外的工作，以确保面向患者的api成功地实现其预期的目的和用例。

我们确定的实现挑战和感知风险导致组织在实现周围谨慎而缓慢地行动，并避免积极地营销新功能。卫生系统通常会提到隐私和安全问题——这是一个值得注意的障碍，因为法规要求卫生系统通过API与患者共享电子健康数据给任何第三方，并以患者要求的任何格式。卫生系统对金融风险有关联的担忧。具体来说，即使患者将数据从系统传输到无关联的第三方应用程序，并且系统对患者随后关于披露和使用的选择不承担法律责任，患者仍然可能选择起诉，并且考虑到卫生系统的“雄厚财力”，仍然可能获得和解。技术主题通常会带来关于策略和实现细节的混乱，例如，访问令牌和应用程序白名单，以及有时相反或分歧的观点，例如是否使用中间件供应商而不是EHR供应商进行API管理。这可能是因为在使用面向患者的api方面还没有足够的纵向经验，无法清晰、自信地理解技术上的细微差别。事实上，一些拥有丰富技术经验的大型卫生系统的首席信息官和其他受访者仍在学习面向患者的api，这是我们工作中的一个重要发现。

卫生系统也对使用面向患者的原料药的市场需求持谨慎态度。尽管他们指出，患者希望使用更方便的工具来管理他们的护理，但我们采访的医疗系统普遍认为，与目前可用的使用面向患者api的第三方应用程序相比，他们的电子病历的绑定门户仍然为患者提供了更大的便利性和价值。从某些卫生系统的角度来看，使用ehr栓系门户的受控集成系统似乎比使用面向患者的api的模块化系统的可能零碎的异构功能更可取。然而，患者是否同意或愿意接受另一种评估，这是一个悬而未决的问题。例如，患者可能想要选择自己的预约安排或成本估算应用程序，或在整个医疗系统中集成他们的数据，这些目前都无法通过绑定门户实现。

基于我们的研究结果，我们认为需要采取更多的行动来刺激卫生系统吸收和有效使用面向患者的api，主要是通过将平衡转向增加卫生系统的好处和减少坏处。首先，考虑到我们发现的一些技术实现最佳实践缺乏清晰度，我们认为在行业内持续的对话和经验分享对于弥合异构技术实现方法至关重要。例如，分享API中间件平台与嵌入式EHR供应商工具在API管理方面的使用经验可能是有价值的，并且可以由诸如卫生服务平台联盟、医疗保健信息管理高管学院、医疗保健信息和管理系统协会、美国医疗信息协会或信息系统医学主任协会等组织促进。其次，我们发现人们经常担心安全、隐私和卫生系统的责任;可能需要开展更广泛的公众意识运动和工具，教育和帮助公众学习如何管理他们的健康数据。一项具体的战略可能包括加强承诺使用国家卫生信息技术协调办公室(ONC)的隐私模型通知，以帮助消费者识别哪些应用程序可能会带来更高的隐私和安全风险。另一个可能有助于说服卫生系统加快进展的策略是增加政策的清晰度，并保护卫生系统免受患者选择的应用程序侵犯数据隐私的影响。美国卫生与公众服务部(Department of Health and Human Services)最近公布的常见问题是这方面的一个良好开端[16］．克服这些担忧的第三个策略将是专家联盟的出现和发展，就应用程序的安全性和有效性提出建议，帮助卫生系统和患者了解哪些应用程序应该使用或避免使用，从而帮助采用。目前尚不清楚ONC、电子病历供应商、食品和药物管理局、医院特定的“数字诊断和治疗委员会”是否会接受这项工作[17]、多方利益相关者联盟，或所有这些的某种组合[18］．

最后，考虑到我们发现与第三方患者应用程序相比，栓系电子病历门户的相对价值和成本存在持续的不确定性，我们认为电子病历供应商必须面临更大的压力，以扩展可用的api集，甚至是他们认为可能实现竞争产品的功能。这将需要通过标准化api(包括美国互操作性核心数据)更快速地扩展数据集。虽然ONC目前建议在现有的20个数据元素基础上增加3个新的数据元素，但它可以更快地添加其他标准化数据元素，例如已经作为自愿认证的健康信息技术模块存在的数据元素，例如家族史和健康的社会决定因素，并专注于将促进患者驱动的事务交互的api，例如预约安排。加快对USCDI的这些补充将更快地使新的应用程序能够满足目前未满足的需求，反过来推动患者的兴趣和需求，从而导致一个良性循环，增加卫生系统优先考虑进一步实施和使用面向患者的api。

限制

考虑到我们研究了10个早期采用者卫生系统的便利样本，这些系统规划或实施面向患者的api，我们的结果可能在概括性方面受到限制，我们可能没有捕捉到所有重要的主题。我们的样本也倾向于更大的城市卫生系统，这可能无法捕捉到更小的农村医院和卫生系统的经验差异。我们在每个组织采访了一个人(有时是两个人)，由组织来选择最合适的受访者。因此，受访者对所涵盖的广泛主题的知识深度各不相同，这意味着某些引用可能反映了受访者的看法。

与之前工作的比较

鉴于最近面向患者的api的可用性，在此主题上的前期工作有限。最近的四项研究评估了原料药的吸收和使用。一项研究调查了12个大型卫生系统中原料药的使用情况，发现吸收率相对较低，但稳步增长[19］．与我们的研究结果相关的是，这项研究发现，与ehr栓系患者入口的使用水平相比，api的使用非常低。第二项研究使用了2017年美国医院协会的数据，发现33%的医院报告患者可以通过EHR api访问他们的EHI [20.］．来自Partners ' Healthcare系统的第三项研究检查了用户的人口统计数据，发现男性患者和年轻患者更有可能使用面向患者的api [21］．最后，加州大学圣地亚哥分校的一项研究调查了开始使用其个人健康记录API功能的前425名患者，在132名调查受访者中，有非常高的比例(75%-96%)指出，他们对这种新的连接和改进的健康信息益处感到满意[22］．这些发现补充了我们的结果，初步结果显示，面向患者的原料药的潜在益处吸收缓慢，但具有显著的热情。

结论

总之，我们发现，不同的因素推动卫生系统努力追求面向患者的api，包括患者参与和授权给卫生保健带来的好处和机会。然而，我们发现早期采用者卫生系统的方法存在很大的异质性，这些系统正在谨慎地进行，并且对包括长期业务驱动因素在内的多个维度仍然不确定。为了确保实现互操作性和患者数据访问的国家政策目标，需要持续了解面向患者api的使用和障碍，并增加对最佳实践的讨论和共享，可能需要有针对性的持续干预来支持和加强其使用。