如何准确理解FHIR能力？医疗IT行业的数据交换和共享难题如何破？

最在第一期“极客聊吧”中，InterSystems销售工程师们聊了聊这些话题：为什么有些医院和某些商保之间可以直接结算，有些又不能？医院和保险之间的结算难在哪儿？在InterSystems 2021全球线上峰会中提到的医保结算案例对国内实践有哪些借鉴意义？FHIR又能起到什么关键作用？医疗数据实现互联互通的关键是什么？以下是文字版。

点击查看视频。

#从商保结算谈起#

菁伟 (@Jingwei Wang ) )：大家好，我是InterSystems的销售工程师王菁伟，这是我的同事祝麟和刘皆良(Jeff)。今天我们一块来聊聊HIT行业里的数据交互那点事。去医院就诊的话，我们会发现有些医院可以和某些商业保险直接结算，有的医院或者某些保险产品又不能。为什么直结这个流程没有全面开通呢？

祝麟 ( @Nicky Zhu ) )：我们虽然平时看病都基本实现了医保直连， 但实际上背后医院的信息科和供应商付出了大量的努力，比如供应商就需要要适应各地医保结算流程和政策的差异，这个过程的数字化还是有很大难度的，也没法一蹴而就。

Jeff ( @Jeff Liu ) )：到商保这一侧，可以观察到很多商保产品的直结清单是逐年递增。那么保险公司的产品是一家一家和医院对接的，难度恐怕更大。

菁伟 (@Jingwei Wang ) )：医院和保险之间的结算过程到底为什么落地困难呢？

祝麟 ( @Nicky Zhu ) )：原因很多，既有政策层面的，也有技术层面的。比如医院和院外机构间通信的安全性保障就是问题，如果没有安全的公共平台进行数据交换，哪家医院也不能独立承担数据流出医院的安全风险，这在政策的制定和技术的实现方面都有挑战。

Jeff ( @Jeff Liu ) )：医院和保险之间的接口也是问题，不同的医院会采用不同厂家提供的系统，不同保险公司采用的数据接口肯定也不一样，是个典型的多对多集成的问题，工作量会比较大，实施周期也很长。

#借鉴国际成功案例#

菁伟 (@Jingwei Wang ) )：去年InterSystems的全球峰会上HealthShare的分论坛里是不是就谈到了医保结算的场景？这个案例对实现直接结算有没有借鉴意义呢？

祝麟 ( @Nicky Zhu ) )：是的。本身医保结算这个事是个全球性的挑战。除了我们国家以外，即使是商保比较发达的欧美国家，在打通流程方面也是处于进行中的状态。这次峰会上HealthShare发布解决方案，实现了CMS，也就是美国医保局所定义的医疗服务提供方和支付方的交互规范。这个方案覆盖的正是医疗机构、支付方以及患者三者之间结算和信息交互流程。

菁伟 (@Jingwei Wang ) )：也就是说满足了政策要求？

Jeff ( @Jeff Liu ) )：也包含技术要求。CMS定义的交互流程和数据模型是以FHIR为载体的。

祝麟 ( @Nicky Zhu ) )：是的。CMS定义的交互规约既包含流程规范，也包含接口和数据规范，目前是以FHIR R4规定的，所以必须以FHIR API的形式实现。

#如何准确理解FHIR能力#

菁伟 (@Jingwei Wang ) )：那么，现在有没有实际的案例使用FHIR来完成业务功能呢？

Jeff ( @Jeff Liu ) )：有的。我们在国际上已经看到不少基于FHIR的业务出现。比如我们和UC Davis Health以及Centene合作进行了医保预授权的自动化项目，就是基于FHIR的。在这个项目里，UC Davis Health的角色是医疗机构，Centene是保险的支付方，采用HealthShare作为平台来支撑不同角色间的实时交互。

祝麟 ( @Nicky Zhu ) )：UC Davis Health的医生在Epic的电子病历系统里下达医嘱，系统把患者和医嘱信息按自定义接口发到HealthShare；HealthShare将请求转为FHIR标准再通过FHIR接口与Centene的系统交互，检查这些医嘱能不能被Centene的保险产品覆盖，再把结果通过HealthShare转回到医生那儿。这样就可以在下达医嘱时实时地通过预授权的检验，杜绝医保拒付的情况。先不说杜绝拒付问题能节省的开支，光是将预授权自动化这一项，和人工处理相比，就能把每一单预授权的处理成本从3.68美金降到0.04美金，那每处理一百万次预授权就能省下几百万美金了。

菁伟 (@Jingwei Wang ) )：那么，假设我们有一个集成平台，通过平台实现FHIR API接口，不同的系统通过FHIR API与集成平台对接，是不是就能解决数据交互问题呢？

祝麟 ( @Nicky Zhu ) )：这是个非常好的问题。FHIR在设计之初就声明采用了剃刀原理，它大概只能覆盖80%常见的交互需求。因此，对于差异化的需求或者是新技术引入的新的数据交互需求，FHIR要借助除了API之外的额外机制来解决这个问题。在医疗行业，我们现在经常遇到医疗文档共享或者跨机构流程这样的业务场景，除了API。Jeff，你认为平台这个层面还需要什么样的一些能力来支撑这些场景呢？

Jeff ( @Jeff Liu ) )：Profile。针对患者健康档案共享和支付方之间的数据交换两个不同的场景，需要分别遵循USCore profile和PDex Profile的规约。也就是说在可预见的未来，对于一家医院或者一个区域级的数据交换中心来说，需要能够支持不同的Profile以应对不同的场景。

菁伟 (@Jingwei Wang ) )：这些不同的Profile之间有什么差别吗？

Jeff ( @Jeff Liu ) )：首先我们需要明白Profile立意于使用FHIR支持差异化的用例或场景。因此，一个合法的Profile就只覆盖这个场景所需要使用的模型而不会涉及到其他用例的内容。

US Core和PDex 这两个Profile首先在定位上不太一样。US Core面向患者就诊过程的信息交换，对就诊中的涉及例如治疗计划、体征和检验结果这样的临床信息进行了定义；而PDex是面向医保结算的用例，就会包含报销范围，支付方的组织机构信息这样一些和医保报销相关的信息，由CPCDS这个数据集定义。当然PDex也会引用US Core中定义的内容，比如患者的身份、病史、体征、检验结果，在PDex里这些临床信息是直接引用US Core里的定义的。

祝麟 ( @Nicky Zhu ) )：没错，正如同我们在医院信息互联互通标准化成熟度测评过程中可以体会到文档交换和服务调用是面向不同用例的交互手段，两者的信息构造有差异。那么使用FHIR进行交互时，面对不同的应用场景时完全可能需要套用不同的Profile，甚至是借助Profile套用特定的术语。因此，Profile之间会有很多差异。

如果FHIR在中国落地，可以想象到，由于医疗技术上我们包含中医，医疗福利上我们有医保和商保，还有很多其他差异，我们也需要有中国自己定义的多个Profile去投入使用。

因此，对FHIR的支持不能仅仅体现在支持HL7官网发布的协议结构上。支持多Profile，能够根据地区、应用场景的不同导入并套用Profile对于医疗行业的集成引擎、数据平台这样的产品是一项至关重要的FHIR能力。

Jeff ( @Jeff Liu ) )：除了遵循协议之外，还有数据架构。在HealthShare的解决方案里包含了一个整合好的数据存储。

祝麟 ( @Nicky Zhu ) )：是的，有一份在各业务系统之上，经过整合与泛化统一存储的数据能够极大简化应用标准协议的成本。大家可以想象一下，对于使用FHIR来说，在多Profile模式下运行的一个体系，如果没有一份整合的数据，那么每次要支持一个新的Profile，特别是和上一次应用的Profile所需的资源不一样，术语可能也不一样的时候，实施方需要再一次挨个把和各个业务系统的映射再做一遍，这个代价和周期可想而知。

菁伟 (@Jingwei Wang ) )：梳理和整合数据存储的话，这样一套方案就不是单纯的集成平台方案了。

祝麟 ( @Nicky Zhu ) )：没错，这是因为采用集成平台，和采用集成加数据整合的医院信息平台，要解决的问题是不一样的。

当单纯应用集成平台整合流程时，要解决是打破烟囱的问题，但还谈不上整合数据与数据利用。对于这样的场景，即使点对点地两两集成，也能解决问题，坦率说除非每个应用系统都能支持某个标准协议通信，否则采不采用协议进行集成并不关键。但如果要上线统一患者档案这样的业务，就需要整合和泛化数据并进行存储，如何利用这份数据就是协议可以发挥作用的地方了。

Jeff ( @Jeff Liu ) )：日本群马大学医学部附属医院就用我们的产品作为信息平台使用。应用InterSystems IRIS作为信息交换引擎从HIS、检验这样的系统里通过实时和批量数据同步接口获取数据，转换为FHIR并存储在InterSystems IRIS的FHIR存储库里。这个FHIR存储库所承担的就是临床数据中心的角色。它们的科研系统REDCap则通过FHIR对这个存储库进行查询并获得患者档案。现在这个项目也还在扩展，通过和Apple的技术融合实现患者端对自己的临床档案的访问。

祝麟 ( @Nicky Zhu ) )：是的，FHIR API本身就能支持数据利用和数据共享。院里要做科研的话也可以通过FHIR API查询符合条件的患者集合，比如查2021年11月到12月间就诊的低密度脂蛋白低于100的II型糖尿病患者，这是个典型的数据利用问题。如果不借助一份整合好的数据，只凭借单纯的集成平台，那就需要把这样的请求解析并分解到不同的业务系统，再把结果整合起来，才能获得结果。实施难度大，业务压力大不说，效率还没有保障。直接从支持FHIR的存储库里获取数据要高效得多。

Jeff ( @Jeff Liu ) )：使用FHIR资源仓库还有一大好处是，FHIR资源仓库并不意味着中心化的存储，而是由一系列物理上分布的资源仓库组成。这些离散的仓库各自保存特定的数据，通过资源间的相互引用形成逻辑上的统一。由于这种引用本质上松耦合，因此能够形成一个逻辑上整合的数据中心。也因为物理离散而逻辑统一，FHIR存储库非常适合用在微服务架构中。当然无论如何，物理上分布的数据也仍然需要通过FHIR统一逻辑概念和语意，以便在异构的系统间和组织机构间进行共享。

因此在应用FHIR相关的技术方面，FHIR接口是个基本的合规要求，多Profile的支持和FHIR存储库则更加关键，这是两个会直接影响FHIR是否能落地的重要特性。

#小谈互联互通#

菁伟 (@Jingwei Wang ) )：标准接口和整合数据存储，这个概念听着很耳熟。

Jeff ( @Jeff Liu ) )：当然。一是互联互通的推荐架构里，是包含临床数据中心的，也是对整合应用数据提出了要求。另外，InterSystems在介绍方案时，通常也是把集成平台、数据中心看作是一个解决方案中的两个组成部分来看的。

祝麟 ( @Nicky Zhu ) )：没错，随着互联互通这项工作的逐渐推广，相信各家医院和区域数据中心都会收到越来越多数据开放和应用的需求。基于FHIR的数据交换和数据利用会经历越来越多的讨论，我们也会见到大量的交互场景通过FHIR实现的案例，以及基于FHIR特性的智能应用的出现。

菁伟 (@Jingwei Wang ) )：感谢两位工程师与大家分享FHIR的案例和FHIR协议落地时所需要的平台能力。FHIR除了资源和接口的定义之外，还有许多特性能够帮助医疗机构打通数据流程。作为一个面向互操作性的协议，相信未来我们还会见到更多通过FHIR支撑的业务场景。