本文就集成平台在医疗行业实现ETL，尤其是数据抽取的方式和优劣势进行探讨。

  在集成平台建设中，我们大家常常会遇到许多数据整合、同步或者上报等场景，比如：

  如何从HIS、LIS、EMR等临床系统抽取数据到CDR中，实现基于CDR的患者360°视图

  慢病管理服务中，怎么来实现对患者的核心指标数据监测、随访等消息的抽取与汇总

  这些场景会用到数据交换技术之一的ETL方式来实现，同时这种方式许多厂商也会作为集成平台整体架构中数据交换层的核心中间件。在ETL技术应用中，往往会遇到各种数据源（数据库、文件、流媒体等），数据量是少量也可能是海量。数据如何抽取、怎样抽取在ELT中是最多讨论和关心的，本文就集成平台在医疗行业实现ETL，尤其是数据抽取的方式和优劣势进行探讨。

  ETL是Extract (抽取)，Transform (转换) 和Load (加载) 这三个过程的简写, 简单来说ETL的目的是将数据从源数据库搬运至目标数据库。抽取(Extract)就是找出需要搬运的数据并进行抽取；转换(transform)就是调整抽取的源数据格式使它满足搬运目标数据库的标准；加载(Load)则是将数据载入目标数据库。

  1.1视图/快照方式---由于时常会遇到集成平台从医院的第三方系统来进行抽取，为保证数据安全性，通常会以视图/快照的方式生成一个源数据库的本地副本，该副本是只读文件不可以进行编辑修改，但可以读取视图中数据来进行数据抽取，一般会用全量或增量的抽取方式。

  优点：对数据库的侵入性低，无需调整原有数据库的架构，实现上简单容易，实现难度低周期短。

  缺点：实时性较低，需抽取端不停的轮训，增加IO压力，另外对于增量数据的判断需要有特定字段（自增列、时间等）。

  1.2 操作日志---需要源数据库生成数据完毕之后，在外部生成日志。数据抽取时通过检查源系统的执行日志找出数据增删查改的痕迹进行抽取作业，一般会用增量抽取方式。

  1.3 改造成接口---对源系统接口做改造，能让系统在对数据来进行增删改等操作时通过程序接口主动同步发送数据至目标库，发送数据的动作能跟业务修改数据动作脱耦，独立发送，一般会用增量抽取方式

  优点：对原系统没有压力和影响，实时性好，可靠度高，可控性更强，灵活度好。

  集成平台中ETL应根据不同系统灵活切换不同的对接方式，医院原有系统可采用非侵入或侵入性较小的视图或快照方式来进行数据抽取，保证系统的安全运转；新系统可采用改造接口方式，提升数据抽取的效率和可靠性。

  即一批批抽取数据，医院的数据上报场景通常就会采用批量抽取方式。在该场景下，医院会在程序中设置一个数据已加载完毕同时对源数据库压力较小的时间（如每日凌晨2点），时间一到自动发起抽取，一般会用增量或全量抽取方式。

  然而，随着医院数据量的慢慢的变大，单纯在夜间进行批量抽取，时间上已慢慢变得捉襟见肘，甚至会出现医院第二天开始日常工作了前一天的数据仍然没有抽取完毕的窘境。

  通过轮询方式实现的小批量多次抽取，且能轻松实现不间断抽取，用于实时性要求比较高的场景，例如医院新老系统交替时日常业务的数据同步。数据及时性能够最终靠轮询时间的间隔做调整，大幅度的提升了数据同步的实时性，但并未达到完全的实时抽取。

  该方式并非由ETL工具进行数据的搬运而是让源系统在每次进行数据的更新后主动将更新的部分推送给目标数据库。此类数据同步过程并不是由数据抽取的形式达成，但仍可以达成源数据库与目标数据库的数据同步，是实时性最高的一种数据传输方式。不过缺点在于多数医院的老旧系统不支持，有必要进行系统改造才能实现。

  需要根据不同场景需求灵活使用不相同的数据抽取方式，大部分数据建议采用流式抽取，能兼顾数据抽取的实时性和抽取效率，对于小量但实时性要求高的数据则通过消息格式主动推送，达到实时同步。

  在增量数据抽取的过程中，主要的难点就是去判断数据源中哪些数据需要搬运，以下将会分析三种较为常见的处理方法以及其对应的优缺点和局限性。

  3.1 有判定标识或能添加判定标识：即通过判定标识以确认该数据是不是已被抽取

  该方式最易操作且最有效，但局限性较大。需要实施人员有权限对原表进行增删查改。若遇到从第三方系统来进行数据抽取，出于数据安全等因素考虑很多时候只可以通过视图方式抽取，那该方法就不能实现。

  3.2 有时间戳或序号标识：根据最后更新时间或主键序号，确认每次需要搬运的数据

  这种情况下由于增量数据仅关注新出现的时间或序列号，对于已搬运的数据被删除没办法识别，也无法区分数据的插入和更新。因此在这种场景下，需要重起一行描述该数据的删除、插入或更新的操作，以便让ETL工具进行识别或抽取。

  3.3 只有数据没有一点标识：这样的一种情况最常见，而且由于没任何标识作为锚点，无法直接从视图/快照中找出需要搬运的数据。此时的处理方法如下：

  直接全量抽取/全表对比：易于实现，方法简单粗暴，但每次操作的数据量会慢慢的大，对系统性能的压力大。

  CDC（Change Data Capture 变化数据捕获）：通过读取日志文件找出发生明显的变化的数据来进行抽取，市面上的主流数据库（Oracle、SQL Server）都会支持CDC功能，但需要额外购买功能模块---对数据库有侵入性和架构影响（技术上想平衡好性能和数据捕获的准确性要求较高）

  以上是对ETL中的“E”做了较为详细的剖析。当然，除了数据抽取之外，ETL中的“T”也非常关注，不论是实际项目需求还是相互连通测评要求，都需要标准之间的转换处理，数据交换系统能否更好的支撑ETL中的Transform也需要仔细考虑。目前各厂商有自己的数据结构和产品质量标准，国际上有HL7 v2、v3、FHIR等，国内有相互连通2020(HL7 CDA)，引擎对于对于标准的建模、存储、使用以及转换等能力，也慢慢变得被重视。

  因此，引擎不仅需要支持上述行业协议标准，还需要出示模板工具和数据转换工具等功能，帮助医院减少开发成本、降低学习门槛、提高数据转换效率。

  医疗卫生机构仅用ETL已不足以满足各种复杂的数据处理和交换场景，有些复杂场景需要完成一个完整业务，需要对接不同协议和技术的第三方应用，会使用到ESB、API、MQ等其他数据交换技术。因此在考虑集成平台建设时除了具备ETL能力外，还更应思考多种数据交换技术使用的综合能力。

  非税电子发票开票项目服务流程包括：从各院区数据库中抽取开票信息，访问系统API，将开票记录结果返回给对应的数据库。

  在这个场景中，前半段开票信息抽取业务适合通过ETL实现，开票过程中调用接口的动作适合通过APIs实现，而后半段电子发票处理结果的分发和处理业务适合通过ESB实现。在处理这个业务场景时，需要ETL、ESB和APIs根据具体的业务要求协同使用。

  在不久前的HL7新西兰年中会议，特别将一项名为ALEX（Application Layer EXchange）的项目列入专题。ALEX的特别之处在于能基于FHIR API直接对接应用层实现端到端互联。ALEX解决方案涵盖了新西兰 90% 以上的初级医疗数据，允许诊所通过ALEX平台的FHIR API与第三方（包括应用程序、全科医生、患者、保险公司等）安全共享实时医疗数据和记录。该方式既保证了数据同步的安全性和实时性，同时对源系统也不会产生一定的影响，以后我们也会对ALEX项目进行详细的描述，敬请期待。