CMS最终规则在Perficient的互操作性团队中引发了一些有趣的对话和问题解决。这是第一次付款人或健康保险公司不得不对这类规则做出反应。他们处理数据的方式和所有数据的位置使得这与你必须遵循的如果你是一家医院不同。这意味着，虽然对基本规则的理解保持不变，但您考虑的解决方案实际上是完全不同的。
的问
今年早些时候，CMS / ONC发布了他们备受期待的“最后的规则，该法案要求与联邦政府相关计划有任何关系的纳税人必须做到以下几点:
- 病人存取API:提供一个基于fhir的API，让患者通过第三方应用程序访问他们的索赔和信息
- 提供者目录API:通过公开的基于fhirr的API提供提供者目录信息
- Payer-to-Payer转移:允许会员或患者要求将其记录转移给其他支付人
符合关键标准的支付方必须提供这些功能，并且必须遵循FHIR、SmartIG和OpenID等开放标准。
所面临的挑战
虽然许多支付方已经拥有可用的数据和集成平台，但大多数支付方还没有将这些数据公开。此外，许多数据驻留在一系列系统中。这些系统也有重叠的数据。这就是问题所在。重叠数据意味着您必须找到它，转换它，并重复删除该数据。实时呼叫是可能的，但你拥有的副本越多，数据重叠越高，那么你需要做的就越多。
换句话说，仅仅创建一个FHIR API并不能满足您的需求。
你还可以享用:医疗保健PowerByte:互操作性——使数据成为战略性业务资产
确定解决方案
我们团队早期的争论主要是什么类型的体系结构能够满足CMS最终规则所要求的标准。不幸的是，没有一种架构方法适用于每个支付方。这使得具有FHIR支持的集成平台和FHIR服务器类型的解决方案可以混合使用。它们甚至可以共存，这取决于您的平台和数据源生态系统。
为了做出决定，你需要考虑以下几点:
- 你的病人/成员信息在哪里?它是否在多个位置用于索赔、眼科检查数据、临床数据等?
- 您的提供者信息位于何处?它是否可以通过API轻松访问?
- 在各种数据源中是否有大量重叠的数据?
- 您是否很难从数据源中提取数据并将其映射到正确的成员?
- 您是否已经拥有(或即将拥有)集成和API管理平台?(注意:两者都可能需要。)
关于可能的解决方案的一些想法
如上所述，不是每个人都有相同的解决方案。
更大的组织结构和更多的数据源促使您使用更复杂的解决方案集。我将解决方案分为以下几类:
- 对于那些数据源很少(主要是索赔数据)的公司，可以考虑使用集成和API管理供应商来提供提供商和患者数据，并提供基于fhirr的资源。
- 对于更复杂的情况，您可以考虑FHIR服务器或FHIR“解决方案”。这可能需要与企业集成和API管理平台配合使用。这种方法意味着:
- 你把所有的数据集中到一个中心位置
- 您可以对其执行数据转换和重复数据删除，以便正确定义患者数据
- 这些数据不是实时的;从本质上讲，会有一些延迟
- 规范化的数据可以被API前面的任何东西安全地调用
- 如果您的提供者数据很容易访问并且已经集中，那么混合选项可以工作
- API平台调用提供者数据并启用FHIR API
- 集中式患者数据平台，用于更复杂的患者数据场景
成功的故事:为医疗保健消费者及其医疗生态系统提供可互操作的数据
底线是每个组织都有各种各样的选择。在创建最终架构时，您总是必须考虑系统和数据。
记住FHIR是标准，而不是解决方案．大部分繁重的工作都发生在实际的FHIR调用之后。
对近期或长期的集成和互操作性目标有疑问。我们的专家能帮上忙。联系我们开始吧。
