这是一篇开放获取的文章,根据创作共用署名许可(https://creativecommons.org/licenses/by/4.0/)的条款发布,允许在任何媒介上无限制地使用、分发和复制,前提是正确引用最初发表在《医学互联网研究杂志》上的原创作品。必须包括完整的书目信息,//www.mybigtv.com/上的原始出版物的链接,以及此版权和许可信息。
卫生系统最近开始激活面向患者的应用程序编程接口(api),以方便患者访问健康数据和其他交互。
本研究旨在确定卫生系统对面向患者的api的理解、策略、治理和组织基础设施,以及它们的业务驱动因素和障碍,以促进国家学习、政策和采用的进展。
我们对已知的10个卫生系统进行了半结构化访谈,这些卫生系统是卫生技术的领先采用率,已经实施或计划实施面向患者的api。
在这10个卫生系统中,有8个有面向患者的操作api,其组织策略主要受联邦政策、iPhone上健康记录的出现以及道德义务的影响。确定的两个优先用例是启用患者的纵向健康记录和与卫生系统的数字交互。最常被提及的阻碍面向患者api使用增加的主题是安全问题、不成熟的应用程序生态系统(与广泛采用的电子健康记录(EHR)绑定门户相比,目前没有提供更好的功能)、缺乏业务驱动因素、EHR供应商对数据共享的犹豫以及不成熟的技术和标准。
我们的研究结果揭示了卫生系统对实施和使用面向患者的api的理解和方法的异质性。持续的研究、有针对性的政策干预和分享最佳做法似乎是实现国家成功实施的必要条件。
一系列联邦政策努力试图通过改善患者对其电子健康信息(EHI)的访问来创建一个更加以患者为中心、消费者赋权的医疗保健系统[
这些面向患者的api现已开始上线,使患者可以访问他们的EHI,也可以直接通过第三方软件应用程序访问[
我们试图确定和总结早期采用者卫生系统是如何规划和实施面向患者的api的。我们特别想确定他们的理解、他们的总体策略和关键用例,包括相关的组织基础设施、治理、策略和过程,以及策略和其他外部驱动因素如何影响他们的方法。最后,我们的目标是确定在这些早期经验中遇到的障碍,这些障碍可以为政策和实践工作提供信息,并有助于促进广泛采用和有效使用面向患者的api。
我们创建了一个方便的卫生系统样本,已知是卫生技术的早期采用者,包括从事iPhone上面向患者的API试点的卫生系统(苹果新闻稿中包含的卫生系统列表)和其他已知是API技术用户的卫生系统(来自作者的专业网络的列表),然后还通过确保每个人口普查区域(东北部、西部、中西部和南部)至少有一个卫生系统来选择区域差异。尽管api可以被患者、提供者、付款人、第三方应用程序和其他人使用,但我们使用“面向患者的api”来描述用例
我们开发了一份半结构化的访谈指南,涵盖了当前面向患者的API工作和能力、感知的障碍和风险、政策问题、组织治理和经验教训(
我们使用分析矩阵对访谈记录进行了内容分析,从与我们研究领域相关的三个核心主题类别中提取相关陈述:战略与实施、技术问题和障碍与成本。
策略和实现领域内的具体主题类别包括(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的电子病历作为主要电子病历,这些系统的一个子集由于附属、收购和区域合并而在不同的位置使用额外的电子病历。我们采访的领导者涵盖了一系列角色,包括首席信息官、执行副总裁、首席技术官、高级医疗总监和副首席转型官(
样本特征(n=10个组织;13受访者)。
特征 | n值, | |
|
||
|
东北 | 5 |
|
中西部 | 3. |
|
西 | 1 |
|
东南 | 1 |
|
||
|
< 100000 | 4 |
|
100000 - 200000 | 3. |
|
> 200000 | 3. |
|
||
|
< 100亿 | 3. |
|
10 - 20美元 | 3. |
|
> 200亿 | 4 |
|
||
|
史诗 | 7 |
|
欧洲核子研究中心 | 2 |
|
国产 | 1 |
|
||
|
首席信息官 | 4 |
|
执行副总裁一个 | 2 |
|
首席技术官b | 2 |
|
其他(包括执行董事、高级医疗总监、首席数字官、副首席技术官、信息系统副总裁) | 5 |
一个副总裁:副总裁。
bCTO:首席技术官。
我们确定了与组织API战略相关的两个更广泛的主题,其中包括影响卫生系统战略的因素和用例,并鼓励他们采用和使用面向患者的API。
应用程序编程接口策略。
类型 | 组织、n | 描述和示例引用 |
操作的面向患者的api一个具有特定的面向患者的API策略 | 5 |
已定义的策略,以支持面向患者的api和治理机构的技术实现,对面向患者的api进行明确的监督 引用示例:“它(API指导委员会)最初试图在我们的EHR中启动连接到FHIR的提供商应用程序,随着时间的推移,它已经发展到包括一些面向患者的用例。它连接的主要应用程序是Apple Health。“(CIO1) |
操作性的面向患者的API,没有具体的面向患者的API策略 | 3. |
面向患者的API策略(包括相关技术和治理)与整体API策略没有区别 引用示例:“我们认为这是更广泛战略的一部分,即在正确的时间将正确的数据提供给正确的人,相对于将api用于其他目的,我们没有明确的战略。“(CIO2) |
规划面向患者的api | 2 |
面向患者的api已经出现,但还没有制定具体的实施和治理计划。 引用例句:“做这件事没有概念上的保留。我们打算这么做。我们将开放消费者API,并尽快注册到Apple和谷歌生态系统中。“(CTO1) |
一个API:应用程序编程接口。
当被问及是什么形成了他们的战略时,他们确定了三个不同的因素。第一个因素是联邦政策和法规要求面向患者的api,特别是要求患者可以访问并能够通过面向患者的api使用他们的健康数据。正如一位受访者解释的那样:
我想说的是,CMS(医疗保险和医疗补助服务中心)法规是最重要的因素之一,或者更确切地说,我们认为CMS法规将成为一个重要因素。这既包括有意义的使用,也包括围绕互操作性的其他类型的法规[]。我不得不说,法规确实发挥了很大的影响。
第二个因素是苹果公司决定让患者可以通过iPhone上的健康记录下载他们的健康记录数据到他们的苹果智能手机上。在我们的样本中,共有六个组织选择与苹果合作部署这一功能,这需要使用面向患者的api。第三个因素是价值评估或感知道德义务,以部署功能,使患者更好地访问他们的健康数据。正如一位受访者所说:
我们认为,患者应该以一种容易与他们想要与之分享的人分享的格式分享他们的数据。
第一个用例(由六个组织引用)包括使用面向患者的api,使患者能够访问健康信息,以促进纵向健康记录,结合来自多个提供者的信息以及提供者和付款人数据的集成。面向患者的api能够促进这种用例(超越ehr绑定的患者门户),因为它们支持来自多个来源的数据集成。第二个用例(由四个组织引用)包括使用面向患者的api来增强患者对卫生系统的数字体验,包括他们使用远程医疗等便利功能的能力,例如,在虚拟就诊之间传输健康数据,并促进自我调度。对于这些系统,此用例符合消费者日益增长的期望,即医疗保健与旅行、食品服务和金融服务等其他行业一样,提供广泛可用的数据访问和方便的自助服务功能(主要通过移动应用程序)[
当被问及他们组织的主要用例是否会在未来2或3年内发生变化时,大多数受访者认为他们不会。然而,他们确实分享了关于该功能如何演变以提供新价值的具体想法,特别是通过开始实现更好的数据驱动的患者自我管理。例如:
我认为我们将看到更多的分析和情报被推向面向患者的api,用于自我分类管理和升级,而不是今天的服务器端,我们(卫生系统)必须对其进行管理和分类……我认为它将更加主动,而不是被动。
另一个说:
[未来]如果您检查我的数据,并能够将其与生活方式数据和其他信息结合起来,这些信息将为我的信息增加见解和价值,超出我的提供商门户所能做到的范围,那么我将很感兴趣。
在八个具有面向患者的操作api的卫生系统中,我们总结了它们的操作和技术方法以及实施决策的主要特征(
面向患者的应用程序编程接口的现状(在八个具有操作应用程序编程接口的组织中)。
类别及状态 | 组织、n | ||
|
|||
|
读和写 | 4 | |
|
在有限的权限下读 | 3. | |
|
只读 | 1 | |
|
|||
|
白名单:卫生系统管理 | 4 | |
|
白名单:EHRb供应商管理 | 4 | |
|
|||
|
来自电子病历供应商 | 4 | |
|
来自卫生系统 | 2 | |
|
没有可用的文件 | 2 | |
|
|||
|
卫生系统网站上解释了面向患者的api | 2 | |
|
|||
|
系统向患者收取或计划费用以供使用 | 0 | |
|
EHR供应商对面向患者的API使用收取系统费用 | 0 |
一个API:应用程序编程接口。
bEHR:电子健康记录。
c尽管《健康保险携带与责任法案》所涵盖的实体及其业务伙伴不得向患者收取电子费用
第二个API实现决策涉及如何批准第三方应用程序访问API。在应用程序访问API之前,所有八个卫生系统都需要事先批准应用程序或白名单。对于其中四个,卫生系统保持白名单;对于其他四个,由EHR供应商维护。对于第三方应用程序连接到面向患者的API,开发人员需要有关API配置的文档。共有四个卫生系统表示,开发人员可以通过他们的EHR供应商获得该文档,其中两个卫生系统表示,他们将根据开发人员的要求提供该文档,还有两个卫生系统没有为开发人员提供文档。值得注意的是,这些健康系统都没有可供任何开发人员访问的公开API文档。总之,有两个卫生系统指出,他们正在通过面向患者的API积极向患者群体宣传患者数据的可用性,其中一个特别指出,其重点是如何利用面向患者的API功能来帮助“向他们推销体验[而不是底层技术]”(SMD1)。
在面向患者的API的更多技术维度方面,两个医疗系统依赖其EHR供应商来管理API,而六个医疗系统则使用中间件供应商进行API管理。API管理指的是一系列功能,包括API访问控制、API创建和设计、API保护、业务价值报告以及API流量控制、性能和节流[
一些电子病历让这变得很容易,我想说[供应商]就是其中之一。其他的难度更大。我认为这很复杂,因为这取决于他们的内部资源、关注点、结构和能力。
另一位受访者补充说:
你必须有API中间件。[否则],你将无法监控交通流或限制交通流,或识别模式。电子病历供应商永远也搞不清楚这一点。
我们还询问了卫生系统访问令牌的方法,这些令牌可以是持久的(例如,在每次API尝试读取或写入患者数据时不需要登录凭据)或一次性的(即,在使用API的每个会话时都需要登录)。总的来说,受访者对正在使用的令牌类型表示不确定,有两个组织明确表示不确定,其中两个认为他们使用了持久令牌,三个认为他们使用了一次性令牌。
最后,当被问及与面向患者api相关的费用时,没有一个卫生系统正在或计划向患者收取使用面向患者api的费用——考虑到监管机构禁止对使用认证EHR技术中的面向患者api的患者访问其健康信息收取费用,这是合适的。此外,没有一个卫生系统为使用面向患者的api而向其电子病历供应商支付特定的费用。
我们确定了实施和使用面向患者api的六个障碍(
我们有点担心(法规)的精神基本上是,如果任何应用程序敲开你的门,病人真的想这么做,那么你有什么资格去评判……(但)如果我们不能安全地交付它,因为应用程序创建得很糟糕,或者真的做了一些事情,比如把数据泄露给制药公司,怎么办?
卫生系统没有准备好识别和区分值得信任的应用程序供应商和不值得信任的应用程序供应商,随着应用程序生态系统的发展,这应该由谁来承担责任,这也表达了额外的不确定性。在我们的受访者中,一些人建议EHR供应商继续发挥作用,而另一些人则建议成立第三方评级联盟,其中一人建议“创建一个专业知识驱动的团队来策划投资组合将是最有意义的”(CIO2)。经常与安全问题联系在一起的一个因素是卫生系统的财务风险,例如:
当有不好的事情发生时,他们不会去找那些刚起步的小供应商。他们将攻击(医疗系统)。所以这就是为什么我认为我们必须尽可能清楚这个决定意味着什么,以及你的信息会去哪里。你们要为这个决定负责,而我们不用。
受访的一个卫生系统已经采取了措施,试图缓解这一问题,该系统表示:
我们确实有一份这些建议的清单,并为患者的数字健康隐私提供了一种入门……如果我们让(健康数据)可用,人们应该知道如何取消应用程序的授权,如果他们怀疑某个应用程序对他们的数据做了错误的处理,他们应该知道该怎么办。
四个卫生系统指出,使用面向患者的api的应用程序功能不足是一个障碍。卫生系统认为,目前的第三方应用程序生态系统还没有提供一个令人信服的替代方案,以ehr为纽带的门户。例如:
首先,消费者应用程序需要提供一些比供应商移动应用程序更有吸引力的附加价值。
另一位受访者说:
(我们)在门户网站上投入了很多。(我们)担心这可能会吸引一些人离开。
三个卫生系统列举了一个相关的障碍,即缺乏可感知的商业价值或投资的财务回报,其中一人表示:
缺乏外部刺激。它不是一个收入驱动因素。这不是降低成本。
另一个说:
在某种程度上,如果你有10万个不同的应用程序与人们连接,在某种程度上,有人将不得不为此付费。我不知道具体是怎么解决的。
三个卫生系统提到的另一个障碍是他们的电子病历供应商对数据共享持谨慎态度。一位高管说:
许多供应商将数据获取视为他们的一种策略,因此他们不允许您共享数据。
另一个说:
(他们认为)患者会下载恶意软件,窃取他们的患者数据,并利用这些数据做邪恶的事情。
一个系统投诉如下:
我们[电子病历供应商]需要开放你的数据,这样我们就可以在你正在做的事情之外做一些事情,这样其他人就可以做一些事情来补充你正在做的事情。
最后,系统指出,医疗保健中不发达的技术和标准是一个障碍。例如,
他们(FHIR)增加(数据元素)的速度非常缓慢。[我们的EHR]中有4000个数据元素,我认为他们已经通过FHIR[快速医疗互操作性资源]完成了大约150个数据元素。
另一位受访者补充说:
有趣的是,api确实需要你建立一种健壮性和可扩展性,这是你过去从未真正设计过的,因为这一切过去都是由相当有限的医生群体完成的,他们的行为相当容易理解,而不是成千上万的人。可以每六秒更新一次医疗记录…[FHIR]的发展如此之快……一个nd so suddenly you’re engineering a set of apps on shifting sands.
对于可用的技术设置存在一些担忧,例如:
我们没有能力告诉病人这个应用程序能在多长时间内访问他们的数据。这是一个很大的因素。
另一个与不太先进的技术能力相关的具体问题是,在EHR中创建的某些设置可能无法通过面向患者的API传输。例如:
在门户中,你可以加入一些规则,比如在医生公布癌症诊断之前不显示癌症诊断,但我听说在HealthKit API中,所有这些过滤器都没有了,所以你可能会在医生知道之前就在手机上发现你的癌症诊断。
当前/未来实现/使用面向患者的应用程序编程接口的感知障碍。
类别 | 组织、n |
安全或隐私问题 | 5 |
第三方应用程序功能不足 | 4 |
缺乏可感知的投资回报:成本vs商业价值 | 3. |
供应商不愿意在他们的系统之外共享数据 | 3. |
与其他行业相比,医疗保健的技术发展不如其他行业 | 3. |
缺乏应用程序编程接口和语义标准 | 2 |
在这项研究中,我们采访了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)最近公布的常见问题是这方面的一个良好开端[
最后,考虑到我们发现与第三方患者应用程序相比,栓系电子病历门户的相对价值和成本存在持续的不确定性,我们认为电子病历供应商必须面临更大的压力,以扩展可用的api集,甚至是他们认为可能实现竞争产品的功能。这将需要通过标准化api(包括美国互操作性核心数据)更快速地扩展数据集。虽然ONC目前建议在现有的20个数据元素基础上增加3个新的数据元素,但它可以更快地添加其他标准化数据元素,例如已经作为自愿认证的健康信息技术模块存在的数据元素,例如家族史和健康的社会决定因素,并专注于将促进患者驱动的事务交互的api,例如预约安排。加快对USCDI的这些补充将更快地使新的应用程序能够满足目前未满足的需求,反过来推动患者的兴趣和需求,从而导致一个良性循环,增加卫生系统优先考虑进一步实施和使用面向患者的api。
考虑到我们研究了10个早期采用者卫生系统的便利样本,这些系统规划或实施面向患者的api,我们的结果可能在概括性方面受到限制,我们可能没有捕捉到所有重要的主题。我们的样本也倾向于更大的城市卫生系统,这可能无法捕捉到更小的农村医院和卫生系统的经验差异。我们在每个组织采访了一个人(有时是两个人),由组织来选择最合适的受访者。因此,受访者对所涵盖的广泛主题的知识深度各不相同,这意味着某些引用可能反映了受访者的看法。
鉴于最近面向患者的api的可用性,在此主题上的前期工作有限。最近的四项研究评估了原料药的吸收和使用。一项研究调查了12个大型卫生系统中原料药的使用情况,发现吸收率相对较低,但稳步增长[
总之,我们发现,不同的因素推动卫生系统努力追求面向患者的api,包括患者参与和授权给卫生保健带来的好处和机会。然而,我们发现早期采用者卫生系统的方法存在很大的异质性,这些系统正在谨慎地进行,并且对包括长期业务驱动因素在内的多个维度仍然不确定。为了确保实现互操作性和患者数据访问的国家政策目标,需要持续了解面向患者api的使用和障碍,并增加对最佳实践的讨论和共享,可能需要有针对性的持续干预来支持和加强其使用。
“从卫生系统部署面向患者的api的早期洞察”的访谈指南。
结果:实施和使用障碍。
应用程序编程接口
首席信息官
电子健康信息
电子健康记录
国家卫生信息技术协调员办公室
互操作性的美国核心数据
作者要感谢加州大学旧金山分校的Edwin Martin和Victor Galvez在API技术方面提供的专业知识。
AN获得了思科系统公司的研究支持;曾担任Steady Health、Nokia Growth Partners、WebMD和Grand Rounds的顾问;曾获得健康学会和医学研究会的演讲荣誉;他是汰渍保的无偿医疗顾问微软获得了思科系统公司的研究支持。其他作者没有披露任何信息。