统一语义数据平台

数据平台一直在进化：从数据中心到数据中台，离散的数据资产得到进一步梳理和整合、按业务封装数据和操作数据的方法，并逐步提供了企业统一的访问、更新、检索、查询等数据服务。

然而市场上不乏听到数据平台的成功案例，却鲜见这些案例得到大规模推广。原因是什么呢？

一. 传统数据平台建设的挑战

传统数据平台的数据模型基于各自厂商的理解，缺乏统一行业数据模型和行业语义。可供参考的国内卫生信息数据元、数据集标准并非完整的行业语义，例如没有业务实体模型和数据元关系定义。传统的数据平台建设通常根据业务域，围绕数据应用需求组织数据。经常看到按业务域划分为CDR（临床数据中心）、ODR（运营数据中心）、RDR（科研数据中心）......  

这造成了几个挑战：

1. 按业务域、而非业务实体来划分数据，虽然方便相应的业务域数据分析，但跨业务域重叠的业务实体数据，例如患者，需要跨数据中心同步。这些同步由于数据模型上的差异，往往非全息拷贝。随着同步次数越多，跨数据中心的数据越失真，造成数据资产多源不统一、数据资产一致性问题和时效性问题。

2. 数据平台产品语义表达上参差不齐，业务用户依赖数据工程师对数据理解和操作，无论是统计分析还是机器学习，海量的实施工作无法满足业务敏捷性要求；

3. 数据平台及数据应用建设依赖单一厂商的能力，而建设成果，包括数据工具、分析指标和应用都无法跨数据平台复用。往往项目都在做低水平重复建设。

4. 数据互操作标准化程度低，数据的同步、迁移困难。在缺乏数据层互操作性的情况下，各类数据中心建设的依然是数据孤岛。

5. 由于数据中心往往忽视互操作建设，数据缺乏流动，进入数据平台后，往往成为死水一潭。

 

二. 如何应对挑战

如何解决这些数据平台建设困境？应该如何建设数据平台？

数据资产不是仅为分析服务的，更重要的是作为生产要素在生产全过程中发挥价值- 这就涉及到数据生成、采集、交换、决策… 在这个全过程链条上的数据互操作能力尤为重要。

HIMSS将互操作定义为4级：基础级、结构级、语义级和组织级，并认为只有到达语义级，才是标准的、才能实现广泛的互操作能力。要达到语义级的互操作，需要进行五位一体的标准化：词汇/术语标准、内容标准、传输标准、隐私和安全标准、标识符标准。

随着我们越来越依赖于机器处理数据、发掘数据背后的知识，对数据资产的开放性和互操作性的要求达到了更高的水平 - 实现机器可以理解的互操作。2016年发表在Scientific Data针对科学数据管理和监管，提出了数据的可发现（Findable）、可访问（Accessible）、可互操作（Interoperable）、可复用（Reusable）的FAIR指导原则。

这些原则的核心是让机器可以理解数据所需的语义层面的要求，尤其是可互操作和可复用两部分提到的语义级要求 - 广泛使用的语言、词汇表、元数据引用、符合相关领域的社区标准...

大家都不约而同地指向了统一行业语义。传统数据中心面临的上述挑战，正是因为缺乏统一的行业语义、缺乏统一的语义级互操作。

那什么是统一语义？

 

三. 统一语义数据平台

圣经记载人类曾经联合起来兴建能通往天堂的高塔 - 巴别塔、也称通天塔。上帝为了阻止人类的计划，让人类说不同的语言。人类相互之间不能沟通，造塔计划因此失败。

统一语言是数据能够互相理解、并利用数据的前提。

语言包含2个层面：

1. 语义：真实世界事物及其关系的表达方法。例如不同电子病历系统对疑似肺癌的记录，可能记录为以下三种之一：

A。问题: 癌症 身体部位:肺 确定程度:疑似

B。问题: 肺癌 确定程度:疑似

C。问题: 疑似肺癌

这三种语义表达不统一。没有统一的语义就像图里的电源插座，每个国家规格都不同，是不可能互联互通的。

2. 语法：语言的结构规则，包括词法和句法。而词法和句法都可能有歧义，就像图中示例的那样。

 

行业数据需要通过统一语义达到互联互通。对数据而言，统一语义不仅在数据模型（语义）、也在数据使用方式（语法）上。不仅数据语义是统一的，操作/互操作数据的方法也是统一的，并且需要能避免词法和句法歧义，才能达到语义级互操作能力！

是不是一定要统一语义？要看数据用途：对于特定的、简单的数据任务，简化的数据模型和数据处理方法可能已经足够，但对于复杂的、跨领域的数据任务，如广泛的自然语言处理、知识图谱构建、大规模机器学习等，统一语义是非常有价值的。

显然，对于数据平台这类多用途平台，应该统一数据语义。

 

四. 如何建设行业统一语义数据平台

数据平台建设向统一语义迈进，而统一的行业语义模型，应该针对行业用户友好：直观、完整、语义简单、没有二义性，易于数据探索与使用。

统一语义是指要统一物理数据模型和操作数据的语言吗？是要限定到特定的技术栈吗？

先看一下数据库的结构化查询语言（SQL）：众多的关系型数据库、甚至很多非关系型数据库都支持ANSI SQL语言。SQL定义了自己的语义 - 表、字段、视图、存储过程... 和自己的语法 - 数据定义语言（DDL）、数据操作语言（DML），但它并没有定义任何数据的物理存储方案！也正因如此，任何数据库厂商、任何数据物理存储方案，都可以通过自己的SQL编译器来支持SQL和SQL客户端，从而屏蔽数据库物理层差异，使用相同的SQL语言共同建设SQL生态。这也是SQL生态壮大的原因之一。

SQL的成功告诉我们，统一行业语义是对行业数据的逻辑表达层的要求，它不应对任何数据库技术底层做要求，也就是不应限定任何技术栈。

 

前面提到统一的数据操作/互操作能力是统一语义的一部分，是要用单一的数据操作方法吗？
数据有多种操作方式，每种操作方式都有自己适用的场景，如下：

 

对同一份数据提供多模型的操作能力，会极大提升语义层的操作/互操作的便捷性，是非常重要的统一语义特性。重要的是可以针对同一份语义数据进行多种模型的操作/互操作，而不是建立针对每种模型的多套语义，并进行数据复制。

也就是说统一语义，并不是数据只能有一种操作/互操作方式，而应提供对同一份统一语义数据的多种操作/互操作方式。

 

五. InterSystems统一语义数据平台建设

基于上面的建设思路，InterSystems的医疗信息统一语义平台通过对行业语义的理解和其智能数据编织能力，提供医疗信息数据基座。

5.1 行业语义选择 - FHIR

行业语义应具有开放性、成熟性、准确性、完整性、灵活性、简单性、非二义性、可互操作性、机器可理解，并被广泛接受与认可。纵观医疗信息行业，虽然有不少通用数据模型，但目前最满足上述条件的是HL7 FHIR。它的资源模型覆盖面广，不仅是临床、还包括管理、科研等；不仅包括通用数据模型 - FHIR资源模型，还有对其统一的互操作方法 - FHIR API；按80/20原则设计，允许对资源模型和API进行扩展；资源模型和API简单、并有详细的用例指南；FHIR资源模型、API、扩展都可以被计算机理解；FHIR拥有庞大的用例，并且其触角不断扩展到医疗信息应用的各个层面和各个方向。

另外，更重要的是，FHIR的定位就是行业语义标准 - 逻辑层的标准，任何厂商只需要提供自己的FHIR服务器，就可以利用任何技术栈发布统一的FHIR资源和FHIR API，而屏蔽底层不同类型的数据存储方案、数据模型和数据操作方法。因而它是一个强大的生态标准，所有厂商和用户都可以参与其中。

 

InterSystems的解决方案选择FHIR作为统一语义，在支持FHIR的6种互操作范式的基础上，提供对FHIR资源的SQL投射 - 无需数据拷贝，就可以使用SQL大规模查询FHIR资源，对统计分析、机器学习提供简单易用的数据操作能力。

5.2 利用数据编织技术，无需推倒重来

如果正在规划数据平台，应考虑按统一语义建设。如果已经建设有各类数据中心，并不需要将已有的建设成果推倒重来。InterSystems的解决方案通过数据编织技术，将数据源编织在一起，并建立逻辑上的统一语义层。原有数据中心和其各类应用继续运行，通过统一语义层来支撑新的数据利用和应用创新。

 

InterSystems利用数据编织技术，提供针对所有数据源、数据模型、互操作标准的接入能力和适配器。现有的数据中心被视为数据源，只需接入而无需推倒现有建设成果。

InterSystems的多模型能力，将这些离散的数据源统一转换、表达，将多数据源的数据，以FHIR资源这个统一语义模型，发布多种数据模型的数据服务：包括FHIR JSON模型、FHIR对象模型、FHIR SQL模型，满足多种应用场景对统一语义数据的最佳操作方式。

InterSystems数据引擎，为统一语义层提供高性能、横向可扩展的持久化层，满足不同规模的数据用户所需的性能和弹性。

InterSystems提供FHIR与互联互通、HL7 V2、CDA等通用模型的开箱即用的转换能力和对用户自定义模型的自定义转换能力，提供全方位的统一语义互操作能力。