MIPS的一个主要目标是增加提供者之间的信息共享,消除所谓的数据竖井。这一目标的核心是执行快速卫生保健互操作性资源(FHIR)。FHIR允许一个电子病历直接查询和从另一个电子病历提取信息,其基础是可以可靠地抽象成医疗图表资源.所有可交换内容都被定义为Resource,它充当共享的容器,并由可重用数据类型、一组公共元数据和最重要的资源定义人类可读的部分.不少于28种不同的编码库包括SNOMED、LOINC、CPT、NDC、RXNORM、ICD-10等。
计费、编码和政府授权要求使用这些多个重叠的代码集。这就产生了一篮子不相同的代码,没有一个代码可以直接相互映射。将文档强制放到不同的编码系统中通常会导致与真正意图之间微妙但重要的偏差。
FHIR假设所有的笔记都是及时的、准确的、完整的,并且不同的子专业临床数据可以成功地合并成易于阅读的格式。任何执业的临床医生都会告诉你这种情况不会发生。
有剪切和粘贴提供程序、拖延文档记录程序、非常专门的提供程序、过度文档记录程序和文档记录程序。
想象一下,尝试合并来自精神科医生、整形外科医生、急诊科(ED)肿瘤科医生和心脏病科医生的图表数据。这些不同的供应商提供的药物清单相同的可能性有多大?任何在现实世界中行医并看过真实图表的人都知道,急诊科通常太忙了,无法得到一份完整的药物清单,非专科医生将不熟悉不断扩大的肿瘤药物的宿主,而且精神科医生、整形外科医生和肿瘤科医生也不太可能有类似的问题清单。
然而,如果目标是获得可搜索的、离散的数据,而不局限于任何特定的EHR竖井,那么每一个这些图表都需要合并来自这些不同专业图表的信息。这不可避免地导致了排行榜的膨胀。
此外,由于每个提供者都控制他们的图表,这肯定会导致不一致。
问题清单会是一样的吗?药物清单会统一更新吗?如果没有主海图,FHIR不可能产生紧凑易读的海图。但是谁拥有主图呢?是家庭医生吗?如果病人没有保险怎么办?没有家庭医生吗?如果患者的保险公司更改了他们的提供者名单怎么办?
FHIR实现的另一个缺点是假设编码模板结果集可以作为一种用户友好的临床交流形式。在FHIR范式中,“资源”被视为临床数据的容器,每个资源严重依赖于四个主要的代码集(SNOMED、LOINC、ICD-10、CPT)和一大堆较小的代码。这些代码,就其本质而言,既限制了临床目的,又巧妙地修改了临床目的。
最近,关于临床医生的倦怠和对现有的电子病历的不满的报道铺天盖地。这种挫折感很大程度上是基于这样一个事实:所有的电子病历在一个或另一个级别上使用相同的代码集,这些代码集被设计用来优化计费和数据检索,但对临床提供者来说完全不是用户友好的。
我们强迫医生记录编码集,应该是另一种情况。
基于上述讨论,再加上实际上有数百个电子病历和24个批准临床专业在美国,临床数据似乎不太可能像目前设想的那样跨越多个平台和多个专科进行合并。
解决方案是什么?
首先,FHIR的设计是为了共享和组织数据;它不应该被赋予作为临床工具的任务。
如果我的病人是由整形外科医师治疗骨折的手臂,我希望看到的结果历史,x射线,程序,考试计划每个分配到自己的头和相关代码和元数据可能至少需要一两页的单词并显示——或者我宁愿得到短信“12/16/2019——典型FOOSH损伤、简单的桡骨下端骨折,好的对齐后减数——在两周内复核——塞缪尔·琼斯博士”?
无论Dr. Jones EHR中存在什么离散数据,也没有理由试图将其复制到多个其他图表中,更新应该是简短、简单和简明的文本信息,具有临床直观和信息性。
那么,我们如何聚合和使用所有电子病历生成的数据呢?
基于时间、专业偏差、数以百万计的提供者如何绘制图表的内在不一致、缺乏指定的“主图表”以及不同的电子病历的绝对数量,每个电子病历似乎不太可能与其他所有相关的电子病历数据源合并。最简单的解决方案是只有一个病人记录。在某种程度上,医疗保险已经做到了这一点。而不是试图合并到多个不同的ehr,以使它们都一致和同步(这是永远不可能完成的),每次访问将自动上传FHIR文档到单个主图表。这解决了多个问题:
1.与尝试与许多不同的电子病历(每个电子病历都有自己的小功能)通信不同,每个电子病历将与一个单一的标准化存储库通信。
2.上传将是自动的,从而确保完整的记录。
3.FHIR将包含它真正设计的功能:充当数据整合器。
4.最重要的是,这解决了“竖井”问题。主记录将存在于任何EHR或提供者网络之外。更换医疗机构或搬到另一个州不会对患者的医疗记录产生影响。
未能认识到并对这些问题做出反应将会导致更多的临床医生的沮丧,糟糕的采用,最糟糕的是,不一致和过度冗长的图表到处传播。
解决方案很简单:分享25年前运行良好的简洁文本摘要,如果能够自动发送,效果会更好,从而使临床服务提供者摆脱使用无休止且往往设计糟糕的代码集进行沟通的束缚。
图片来源:Shutterstock.com