CN115396260A - 智能医学数据网关系统 - Google Patents

智能医学数据网关系统 Download PDF

Info

Publication number
CN115396260A
CN115396260A CN202210836259.4A CN202210836259A CN115396260A CN 115396260 A CN115396260 A CN 115396260A CN 202210836259 A CN202210836259 A CN 202210836259A CN 115396260 A CN115396260 A CN 115396260A
Authority
CN
China
Prior art keywords
data
management
medical
platform
subsystem
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210836259.4A
Other languages
English (en)
Inventor
徐辉
安西平
初乃强
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Singularity Of Life Beijing Technology Co ltd
Original Assignee
Singularity Of Life Beijing Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Singularity Of Life Beijing Technology Co ltd filed Critical Singularity Of Life Beijing Technology Co ltd
Priority to CN202210836259.4A priority Critical patent/CN115396260A/zh
Publication of CN115396260A publication Critical patent/CN115396260A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21—Design, administration or maintenance of databases
    • G06F16/215—Improving data quality; Data cleansing, e.g. de-duplication, removing invalid entries or correcting typographical errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/52—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow
    • G06F21/53—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems during program execution, e.g. stack integrity ; Preventing unwanted data erasure; Buffer overflow by executing in a restricted environment, e.g. sandbox or secure virtual machine
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/12—Protocols specially adapted for proprietary or special-purpose networking environments, e.g. medical networks, sensor networks, networks in vehicles or remote metering networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0618—Block ciphers, i.e. encrypting groups of characters of a plain text message using fixed encryption transformation
    • H04L9/0631—Substitution permutation network [SPN], i.e. cipher composed of a number of stages or rounds each involving linear and nonlinear transformations, e.g. AES algorithms

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Mining & Analysis (AREA)
  • Quality & Reliability (AREA)
  • Medical Informatics (AREA)
  • Health & Medical Sciences (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本申请公开了一种智能医学数据网关系统，包括：数据平台系统以及安全协同设备，其中数据平台系统由一组服务器构成，用于实现数据存储、数据计算以及数据服务的平台；安全协同设备与数据平台系统进行通信连接，用于对数据平台系统进行运行环境部署和管理、隐私计算、安全共享以及授权认证。

Description

智能医学数据网关系统
技术领域
本申请涉及数据网关技术领域，特别是涉及一种智能医学数据网关系统。
背景技术
医学数据是一种具有强隐私保护、安全要求的数字资源，医学数据的要素化需要建立系统化的、可监管、安全可信的基础上。医学数据由于其特殊的战略意义，对数据安全、数据隐私有比较严格的法律红线，不能将数据简单整合；同时又存在法律法规不完善的因素，而出现了一些模糊地带。目前尚没有完备的法律法规、监管制度和体系保障，加快数据治理、数据监管发展迫在眉睫。
为了推动医疗健康行业数据资源利用、数据互联互通和共享，国内各级政府已经开展了多年的工作，也出台了相关的法规、指导意见等一系列政策。主要的模式是在各级政府建设中心化的医疗健康数据平台，要求各医疗机构进行数据上传。这种方案的核心问题就是并没有实现数据的价值化，没有给出数据产权、流通交易、收益分配、安全治理这四个方面的系统化解决方案。
首先，各级卫生健康主管部门建设的医疗数据共享平台是典型的中心化大数据平台模式。卫生管理部门定义统一的数据接口，要求医疗健康服务机构按照接口标准上传数据。这个模式看似非常统一，但是最大的问题在于无法确保通过接口上传到数据质量。医疗机构内部的数据本身很复杂，质量层次不齐，缺乏治理。只是简单的汇聚了数据，就像把多桶原油合成一桶原油，而没有加工成生产要素。
同时，由于全民健康信息平台主要由卫生部门负责建设，数据标准规范、应用、联通都是局限于卫生管理部门，所以很难实现医保、医药等信息共享，没有实现数据的有效流通，又成了大的数据孤岛。
最后，数据对外应用权责不清晰，简单由政府部门收集和管理数据，并不能非常方便的实现数据授权使用，结果是数据即使汇聚了也缺乏应用场景。
发明内容
本公开提供了一种智能医学数据网关系统。
根据本申请的一个方面，提供了一种智能医学数据网关系统，包括：数据平台系统以及安全协同设备，其中
数据平台系统由一组服务器构成，用于实现数据存储、数据计算以及数据服务的平台；
安全协同设备与数据平台系统进行通信连接，用于对数据平台系统进行运行环境部署和管理、隐私计算、安全共享以及授权认证。
可选地，安全协同设备通过防火墙与数据平台系统进行通信连接，并且安全协同设备包括：应用层、DSL层、智能合约层、数据沙箱和区块链层，其中
应用层包括管理配置中心以及应用接口；
DSL层用于实现医学数据应用领域的抽象语言描述；
智能合约在数据沙箱中执行，并且数据沙箱和区块链层用于实现数据的安全协同。
可选地，DSL层采用UQL访问接口语言。
可选地，智能合约层包括监管合约、业务合约、领域类合约、数据分析类合约以及产权信用类合约，通过预先设置的函数进行调用。
可选地，数据平台系统包括：数据采集和治理子系统、数据再生产子系统以及数据服务子系统，其中
数据采集和治理子系统用于从医院信息系统接收医学数据信息，并根据医学数据信息整合新的数据源；
数据再生产子系统用于将数据源进行二次加工，生成医学规则数据；
数据服务子系统用于实现数据引擎。
可选地，数据采集和治理子系统通过CDM进行数据模型的构建，并且数据采集和治理子系统还包括：数据采集模块、数据清洗模块、数据质控模块、数据脱敏模块，用于实现数据的采集以及预处理。
可选地，数据再生产子系统通过时间图谱抽取方法实现数据的二次加工，生成医学规则数据。
可选地，数据服务子系统通过统一的上层开放接口进行数据访问。
可选地，数据平台系统还包括：作业和资源管理子系统以及管理和监控平台，其中
作业和资源管理子系统提供对硬件资源以及用户作业的监控和管理能力；
管理和监控平台提供对系统进行可视化操作的面板。
可选地，管理和监控平台包括用户与权限管理、日志管理以及服务器监控。
从而通过数据平台系统实现医疗数据的共享，通过安全协同设备实现数据平台系统内部数据的安全。通过本发明提供的智能医学数据网关系统的数据平台系统实现数据的共享，并且通过安全协同设备实现数据安全。
根据下文结合附图对本申请的具体实施例的详细描述，本领域技术人员将会更加明了本申请的上述以及其他目的、优点和特征。
附图说明
后文将参照附图以示例性而非限制性的方式详细描述本申请的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。附图中：
图1是根据本申请实施例所述的智能医学数据网关系统的示意图；
图2是图1所示安全协同设备构造示意图；
图3是根据本申请实施例所述的智能合约层的整体框架示意图；
图4是根据本申请实施例所述的监管沙箱实现模式示意图；
图5是根据本申请实施例所述的数据平台系统的主体架构示意图；
图6是根据本申请实施例所述的数据采集与治理子系统的示意图；
图7是根据本申请实施例所述的数据采集服务的功能示意图；
图8是根据本申请实施例所述的数据标准服务示意图；
图9是根据本申请实施例所述的EMPI服务的功能示意图；
图10是根据本申请实施例所述的数据清洗服务的功能示意图；
图11是根据本申请实施例所述的数据质控服务的功能示意图；
图12是根据本申请实施例所述的事件图谱示意图；
图13是根据本申请实施例所述的事件图谱抽取架构图；
图14是根据本申请实施例所述的专病库数据生产流程图；
图15是根据本申请实施例所述的分布式搜索引擎的功能模块示意图；
图16是根据本申请实施例所述的统一API服务的功能示意图。
具体实施方式
需要说明的是，在不冲突的情况下，本公开中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本公开。
为了使本技术领域的人员更好地理解本公开方案，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本公开一部分的实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本公开保护的范围。
需要说明的是，本公开的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的术语在适当情况下可以互换，以便这里描述的本公开的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要注意的是，这里所使用的术语仅是为了描述具体实施方式，而非意图限制根据本申请的示例性实施方式。如在这里所使用的，除非上下文另外明确指出，否则单数形式也意图包括复数形式，此外，还应当理解的是，当在本说明书中使用术语“包含”和/或“包括”时，其指明存在特征、步骤、操作、器件、组件和/或它们的组合。
图1是根据本申请实施例所述的智能医学数据网关系统的示意图，参考图 1所示，智能医学网关系统，包括：数据平台系统以及安全协同设备，其中
数据平台系统由一组服务器构成，用于实现数据存储、数据计算以及数据服务的平台；
安全协同设备与数据平台系统进行通信连接，用于对数据平台系统进行运行环境部署和管理、隐私计算、安全共享以及授权认证。
具体地，智能数据网关的部署结构包括两部分：安全协同设备和数据平台系统。安全协同设备是核心设施，担负着隐私计算、安全共享、授权认证等功能；它是数据访问、节点互联的唯一入口。数据平台系统是一个私有云，由部署于数据拥有方内网的一组服务器构成。在部署时，通过网关设备自动向私有云部署相关系统软件，使其成为内部的数据存储、数据计算、数据服务的平台。通过防火墙实现数据平台系统的数据安全。
从而通过数据平台系统实现医疗数据的共享，通过安全协同设备实现数据平台系统内部数据的安全。通过本发明提供的智能医学数据网关系统的数据平台系统实现数据的共享，并且通过安全协同设备实现数据安全。
可选地，安全协同设备通过防火墙与数据平台系统进行通信连接，并且安全协同设备包括：应用层、DSL层、智能合约层、数据沙箱和区块链层，其中
应用层包括管理配置中心以及应用接口；
DSL层用于实现医学数据应用领域的抽象语言描述；
智能合约在数据沙箱中执行，并且数据沙箱和区块链层用于实现数据的安全协同。
具体地，参考图2所示，应用层、DSL层、智能合约层、数据沙箱和区块链层相当于逻辑分层，上层通过调用下层的接口或者库来实现。其中应用层包括管理配置中心以及应用接口，具体描述如下：
1)管理配置中心：管理、配置、更新运行环境的入口，也是接受第三方发布智能合约的通道。
2)应用接口：可以认为是此数据节点的管理方参与整个网络协同的出口，通过这个接口可以发出数据请求，发布新的合约等。
3)DSL(domain specific Language)：领域描述语言。它是一种针对医学数据应用领域的抽象语言，通过语言的设计能直观描述出医学领域应用数据的各种业务场景，屏蔽了计算机高级语言中的各种编程细节。使得没有计算机编程知识的业务专业人员也可以方便表达出业务场景。
4)智能合约：是一段通过DSL而写在区块链上的代码，一旦某个事件触发合约中的条款，代码即自动执行。合约内容必须是公开透明的，相当于多方共同认同的一个协议。通过这个分层设计可以看出，所有对内网数据的访问，都通过智能合约进行。
5)数据沙箱：是基于可信计算环境(TEE)和密码学技术实现的一个安全可信的隐私计算环境。进入沙箱中的数据可以认为是安全的，TEE技术实现了在硬件上的隔离，即使有木马进程侵入了沙箱，也无法访问到TEE区域内的数据。密码学技术实现了密码级别的隔离。
在数据网关中，智能合约要在数据沙箱中执行，从而保证了数据的安全，以及高效执行。
6)区块链，即区块链的合约运行层、共识层、网络层、数据层和基础设施层。
从而，本发明在区块链、隐私计算、人工智能等技术基础上，将数据互联、系统的数据治理、数据隐私保护、监管、产权确认，集成到一个设备内部。
可选地，DSL层采用UQL访问接口语言。
具体地，数据统一访问接口语言UQL，基于医学数据特点，参考SQL语言，并做了语法扩展，增加了处理时序数据的语法和算子。
可选地，智能合约层包括监管合约、业务合约、领域类合约、数据分析类合约以及产权信用类合约，通过预先设置的函数进行调用。
具体地，参考图3所示，其中合约相当于一个程序。他们是调用关系。业务合约是最终用来实现功能的。领域类合约相当于医学领域内一些通用的场景。业务合约需要调用领域合约。像数据分析、产权信用，就是更加通用的库，适用所有数据要素交易类的场景。所有这些合约都必须通过监管。监管就是医学、数据局所制定的法律法规。它要保证这些交易方所制定的合约是合法的。具体描述如下：
1)监管类合约。由监管部门制定的监管规则，写成合约形式。可以认为它是“合约的合约”，所有业务合约都必须通过监管合约运行通过。
2)业务类合约。指用于实现各种业务场景的智能合约。大致可以分为三类业务智能合约：
第一类，是注册、授权类。包括各个参与方身份注册、权限控制；
第二类，是简单的数据交易类，也就是不涉及多方协作，比如判断、查询、调阅，和基本统计等。如病人摘要、就诊摘要信息。
第三类，复杂类的智能合约。比如需要多机构协作的联合模型训练、统计等。
3)领域类合约。指医疗领域内通过监察或形成规范的常用合约，相当于一个医学领域的know-how库。比如疾病预测模型、医学科研常用的统计指标或统计检验；临床知识图谱。
4)数据分析类合约。指内置的医学领域通用数据分析算法或算子，用于支持上层合约的实现。主要包括统计模型、机器学习模型的联邦训练机制；
5)产权信用类合约。在数据要素交易业务中，必须使用此类合约。包括两大类：
定价类合约：指为数据使用权、或者数据服务的定价方式。现实中存在基于价值的定价、基于成本的定价，或基于竞价的定价方式。
激励类合约：指激励数据产研所有者即患者，以及数据拥有者通常是医院，能够持续的参与数据要素共享。激励建立于基于数据贡献度的激励模型，可参考金融领域，实现利息激励模型和信用激励模型。
此外，图4示出了监管沙箱的实现模式，具体流程如下：
1)由监管部门发布监管合约。
2)每当新的业务合约发布，需要先在数据沙箱的测试环境中通过抽样数据或者仿真数据调试。
3)业务合约和仿真结果需要运行监管合约通过，监管合约通过后正式发布，认为是合法的合约。
在沙箱运行环境内运行业务合约。
可选地，参考图5所示，数据平台系统包括：数据采集和治理子系统、数据再生产子系统以及数据服务子系统，其中
数据采集和治理子系统用于从医院信息系统接收医学数据信息，并根据医学数据信息整合新的数据源；
数据再生产子系统用于将数据源进行二次加工，生成医学规则数据；
数据服务子系统用于实现数据引擎。
具体地，1)数据采集和治理子系统。用于采集医院各个信息系统的数据，转化成统一的数据模型，并且做清洗、质控、脱敏等处理。主要保护点包括：
元数据系统。覆盖所涉及的采集、质控、清洗的规则库，以及术语字典；
数据脱敏、病历解析、数据质控的算法；
2)数据再生产子系统，用于对数据做二次加工处理，对病历文本做深入结构化和归一化，结合医学规则实现按需生产。主要保护点包括：
自然语言理解引擎。通过一系列智能算法将病历转化成“事件图”的形式。
数据再生产技术方案，以及所涉及的医学规则处理引擎。
3)数据服务子系统。主要保护点包括：
数据服务引擎。主要处理UQL请求，即可以做实时交互，也可以定义批处理作业。
开发接口。对应用层开发提供低代码接口，包括UQL模式和API模式；并且提供隐私计算和区块链接口。
从而，本发明提出一种智能医疗数据网关(Intelligent Clinical DataGateWay，以下简称数据网关)。本发明在区块链、隐私计算、人工智能等技术基础上，将数据互联、系统的数据治理、数据隐私保护、监管、产权确认，集成到一个设备内部。并且通过安全互联网连接的一组“智能数据网关”构成的半开放网络。每个数据网关代表一个数据节点。基于智能医疗健康数据网关，不同的数据节点(医疗机构、医保部门、个人居家可穿戴设备、第三方健康服务机构)可以实现快速的数据治理以及安全可信的数据共享协作，从而为健康产业数字化提供一套系统化的解决方案。
进一步地，对医院数据的全方位的操作能力。包括数据数据的集成和治理能力，能够将院内临床数据进行模型转换、清洗、质控，形成统一数据模型；数据按需生产功能，即根据数据需求方所定义的条件，来生成所需的数据结果；全方位数据分析和应用能力，从基本的增删改查浏览，到医学领域的数据挖掘、临床知识推理、疾病预测预警等功能；
多点数据安全协作能力。在隐私计算技术、智能合约以及区块链技术的结合，实现“数据可用不可见”；将协同算法以智能合约方式发布，实现数据的安全协同计算。
“监管沙箱”能力，为监管审计提供入口。监管沙箱是金融行业已经在国际上广泛使用的比较成熟的制度。监管沙箱提供一个受监督的安全测试区，通过设立限制性条件和制定风险管理措施，允许企业在真实的数据环境中测试创新产品、服务和商业模式，有助于减少创新理念进入市场的时间与潜在成本，并降低监管的不确定性。
个人数据产权的确权机制。通过建立于区块链、智能合约和密码学基础上，实现一种个人数据使用授权的机制，来保障数据产权。
为数据交易中的激励和定价，提供一种基础设施的保障。
可选地，数据采集和治理子系统通过CDM进行数据模型的构建，并且数据采集和治理子系统还包括：数据采集模块、数据清洗模块、数据质控模块、数据脱敏模块，用于实现数据的采集以及预处理。
具体地，参考图6所示，示出了数据采集和治理子系统的示意图，从而通过该子系统实现数据的采集以及预处理。进而便于后续数据的规范使用。
其中，参考图7所示，本系统采用数据库同步技术和ETL (Extraction-Transformation-Loading)等技术，对数据进行抽取、同步、汇集，实现针对医院多源异构数据的采集和汇聚，支持与超过150家主流医疗信息化系统厂商无缝集成，支持300多种医疗信息化系统数据源智能映射。整合接入医院生产系统：HIS系统、EMR系统、PACS、RIS系统、检验信息系统、超声信息管理系统、病理系统等临床系统的历史数据的全量采集，且可以即时整合新的数据源。数据采集的具体如下：
采集工具：数据采集工具采用DataX，它是一个异构数据源离线同步工具，致力于实现包括关系型数据库(MySQL、Oracle等)、HDFS、Hive、ODPS、HBase、 FTP等各种异构数据源之间稳定高效的数据同步功能。丰富的数据转换功能：提供了自动groovy函数，让用户自定义转换函数；精准的速度控制:通道(并发)、记录流、字节流三种流控模式，可以随意控制你的作业速度；强劲的同步性能：每一种读插件都有一种或多种切分策略,多线程执行模型可以让DataX 速度随并发成线性增长；健壮的容错机制：线程内部重试与线程级别重试机制。
数据存储与计算
数据存储与计算采用CDH(Cloudera’s Distribution Including ApacheHadoop)大数据处理方案，提供一个可扩展的、灵活的、集成的企业级大数据管理平台，可用来方便地管医院快速增长的多种多样数据，同时提供安全保护以及与硬件、软件方案的集成。支持医疗行业结构化数据，来自传统医疗信息系统，以关系数据库为主；非结构化数据：比如病历中的长文本、医疗影像等；流式数据：比如ICU报警、患者的体征变化等数据的存储。
数据接入方式
数据接入方式支持4种方式，1)表或视图方式：直接读取原始业务系统中已经存在的表或视图，使用SQL进行数据过滤和导入，这种方式也是目前最方便成熟的方式。2)存储过程方式：类似于视图方式，相对工作量有所减少，但鉴于历史数据过于庞大，对原厂的依赖度较大。3)直接读取对象：针对Cache 对象数据库，利用Ensemble内部接口，读取对象进行转换，该方式优点是不需要对业务数据库过多改造，缺点是需要预先知道对象结构和组织方式，进行数据拉取。4)文本导入方式：将对象导出为文本，使用Hadoop批处理进行导入，此种方式的优点是无需原业务系统改造，缺点是需要在Hadoop中编写批处理脚本。
增量数据采集
构建基于CDC(数据变更捕获)、OGG机制、ETL的数据增量采集，既可以实现业务系统的读写分离，又可以实现数据实时备份。增量数据模型构建基于医院的全量数据模型，即创建增量的数据模型与全量的数据模型保持一致，以便于新增数据可快速采集到原有数据平台中。
采集流程可视化
支持对全量、增量(时间戳、自增主键、表达式等方式)任务的一站式配置，极大提高配置效率，降低配置出错率。使用适配和抽取工具将医院HIS、 LIS、RIS/PACS、手术麻醉、病理、心电、重症监护(ICU/CCU)等系统中与临床科研相关的各个数据表导入到医疗数据平台的原始主数据库中。支持多种数据源的灵活配置、支持数据库连通性测试，并且支持对采集目标模型灵活添加时间戳字段，与增量任务形成完整闭环。支持按不同版本发布采集任务，能够在后续创建新任务时适当提高复用性，并支持直接配置定时任务实现手动执行、定时任务等调度策略的多任务场景。
此外，图8示出了数据治理中数据标准服务的功能示意图；参考图8所示，数据标准化目的是将把不同来源的数据统一到一个参考体系下。数据标准定义参照卫计委以及国际标准，建立代码、数据元的分类标准，依据本项目的业务和数据规范要求，制定详细的代码标准和数据元分类标准，为数据的存储、访问、整合提供一致性保障。参考以下国内、国际、行业、指南等标准(包括但不限于)，对采集数据进行标准化处理，并反馈给业务系统：卫健委数据标准、国家相关数据标准、相关术语标准、肿瘤学国际诊治指南、国际性肿瘤数据库结构、HL7CDA文档、药品词典规范等。
病历中一些重要字段(比如诊断、症状、用药等)进行术语化、标准化映射，并给出其对应的医学术语详情，并可显示对应的术语库信息。
自由文本中的同义词或不标准表述进行准确识别，并进行标准化，术语化映射。
实现基于平台内各系统术语数据交换的语义级别的统一，将医院内重要的术语等作为统一的元数据进行维护管理，并提供开放式访问接口和更新通知接口；简化数据交互，降低系统之间的耦合度，建立平台级的术语(字典)标准，以满足系统集成需要，给平台未来各项数据挖掘、科研和历史资料管理提供方便。
其中包括：
术语/字典维护：用于术语/字典的维护功能。包括术语/字典查询、浏览、增加、编辑、删除、修改等功能。
术语/字典审批、启用流程：用于某个术语/字典中的项目增加或者变更后，可以通过此功能审批后进行发布操作。
术语/字典发布、订阅与数据同步：当系统发布更新术语/字典时，通知订阅了该字典的各业务系统，同时提供批量的数据更新同步功能，使得已订阅的业务系统能够更新其本地保存的术语内容。
同时数据元标准也给数据质控提供了邮箱、联系电话、身份证、护照等通用规则字典正则表达式的维护方式，建立统一标准规范，供数据质控直接调用进行数据规范性校验，提高医院数据使用分析质量；
值域标准
通过整合国标：《GB/T 3644-2018数据质量评价指标》，行业标准：《WS 445.1-2014》电子病历基本数据集、《电子病历系统应用水平分级评价体系(2018 版)》，医学标准：内外妇儿教材、临床诊疗指南等标准规范，构建完善的医院信息化标准体系。
值域标准支持构建交叉映射配置，将医院不同业务系统数据映射成标准统一的值，供下游应用；同时值域映射修改会同步进行日志记录，确保数据加工流程的可以溯源；
命名标准
系统中的所有数据都会被划分到某个数据层级中，便于数据在应用过程中合理调用和更高效的数据加工处理、更快速的异常数据问题排查；
支持按不同的业务场景灵活的自定义数据模型层级，如ODS、DWD、CDM、 ADM等；
支持对不同的数据模型层级，灵活设定命名规则；如模型类型-业务域-厂商-自定义命名，方便使用者在业务应用过程中快速识别想要的数据；
命名标准构建发布后，供数据建模调用，形成完整的数据标准体系。
此外，患者主索引(Enterprise Master Patient Index，EMPI)是一个医疗信息化专业用语，简单来说，它是患者基本信息检索目录。医疗机构内很多患者没有形成一个统一的患者ID，因此患者的多系统、多次诊疗信息无法实现数据整合。EMPI主要用途是在一个复杂的医疗体系内，通过唯一的患者标识将多个医疗信息系统有效地关联在一起。以实现医院各个系统之间的互联互通，保证对同一个患者，分布在医院不同系统中的个人信息采集的完整性和准确性。建立患者主索引是实现大型医院内部系统集成，资源共享的必要条件。EMPI服务的功能图9所示。
此外，图10示出了数据清洗的功能示意图，数据清洗是整个医院数据智能网关建设过程中不可缺少的一个环节，其结果质量直接关系到后续所有相关研究的模型效果和最终结论。数据清洗包括对数据的完整性、一致性、合法性、正确性等的清洗，并且按照一定规则转化成统一标准。比如：当数据包含不同量纲的多种变量时，数值间的差别可能很大。归一化将数据按比例缩放，使之落入一个小的特定区间；去除数据的单位限制，将其转化为无量纲的纯数值，便于不同单位或量级的指标能够进行比较和加权。经过清洗后的数据，才可以用于后续的统计分析。
数据清洗对采集汇聚的数据进行清洗加工处理，并做标准化整理。主要包括制定数据清洗流程、清洗流程控制、清洗质量控制、清洗过程管理等。通过规范流程和规则库，基于流程引擎构建统一的、可配置的数据转换、清洗、比对、关联、融合等加工处理过程，对异构异源海量离散的数据资源加工生产，生成易于分析利用的、可共享的数据。
清洗规则配置主要包括字段清洗规则，正则表达式清洗规则，复杂逻辑清洗规则。
数据清洗的任务是过滤那些不符合要求的数据，确认是否过滤掉还是由业务单位修正之后再进行抽取。不符合要求的数据主要是有不完整的数据、错误的数据、重复的数据三大类。
数据清洗要进行一致性检查。一致性检查是根据每个变量的合理取值范围和相互关系，检查数据是否合乎要求，发现超出正常范围、逻辑上不合理或者相互矛盾的数据。
无效值和缺失值的处理
由于调查、编码和录入误差，数据中可能存在一些无效值和缺失值，需要给予适当的处理。常用的处理方法有：估算，整例删除，变量删除和成对删除。
残缺数据
这一类数据主要是一些应该有的信息缺失，对于这一类数据过滤出来，按缺失的内容向客户提交，要求在规定的时间内补全或者选择删除。补全后才写入数据仓库。
错误数据
这一类错误产生的原因是业务系统不够健全，在接收输入后没有进行判断直接写入后台数据库造成的，比如数值数据输成全角数字字符、字符串数据后面有一个回车操作、日期格式不正确、日期越界等。通过数据清洗把格式统一成标准格式。
重复数据
对于这一类数据——特别是维表中会出现这种情况——将重复数据记录的所有字段导出来，让客户确认并整理。
数据清洗是一个反复的过程，不可能在短时间内完成，只有不断的发现问题，解决问题。对于是否过滤，是否修正一般要求客户确认，对于过滤掉的数据，写入Excel文件或者将过滤数据写入数据表，促使他们尽快地修正错误，同时也可以作为将来验证数据的依据。
此外，1)数据脱敏流程
数据脱敏的流程一般分为：敏感数据发现、敏感数据梳理、脱敏方案制定、脱敏任务执行四大步骤，结合数据脱敏算法、数据脱敏规则以及脱敏的环境来达到最佳的数据脱敏效果。
脱敏数据一般采用自动发现为主，结合人工发现和审核，来完成敏感数据的发现和定义，最终形成完善的敏感数据字典。对于医院相对固定的业务数据，可以采用人工甄别，明确指定哪些数据库表的哪些数据列的数据是需要脱敏，这些数据一般数据结构和数据长度不会有变化，大部分为数值型和固定长度的字符。比如：患者姓名、身份证号、联系方式、家庭住址等标识列，针对这些数据可以通过人工指定脱敏规则和不同的数据访问策略，保证敏感信息不被泄漏。自动识别根据人工指定或预定义的敏感数据特征，借助敏感数据信息库和分词系统，自动识别数据库中包含的敏感信息，相对于人工识别可以减少工作量和防止遗漏。在敏感数据发现的基础上，完成敏感数据列、敏感数据关系的调整，以保证数据的关联关系。通过屏蔽、变形、替换、随机、格式保留加密、强加密等数据脱敏算法，针对不同的数据类型进行数据掩码扰乱。
在敏感数据发现的基础上，完成敏感数据列、敏感数据关系的调整，以保证数据的关联关系。通过屏蔽、变形、替换、随机、格式保留加密、强加密等数据脱敏算法，针对不同的数据类型进行数据掩码扰乱。
对于不同的数据脱敏需求，在基础脱敏算法的基础上，可配置专门的脱敏策略。脱敏方案的制定主要依靠脱敏策略和脱敏算法的复用来实现，通过配置和扩展脱密算法以制定最优方案。
按照制定的脱敏方案，确认脱敏范围以及具体脱敏操作后，执行数据脱敏流程。
2)脱敏算法
根据不同数据特征选择不同的脱敏算法，对常见数据如姓名、证件号、住址、电话号码、家庭住址等敏感数据进行脱敏，脱敏算法通常包括屏蔽、变形、替换、随机、格式保留加密(FPE)和强加密算法(如AES)。
3)脱敏规则
一般的脱敏规则分类为可恢复与不可恢复两类。
可恢复类，指脱敏后的数据可以通过一定的方式，可以恢复成原来的敏感数据，此类脱敏规则主要指各类加解密算法规则。
不可恢复类，指脱敏后的数据被脱敏的部分使用任何方式都不能恢复出。一般可分为替换算法和生成算法两大类。替换算法即将需要脱敏的部分使用定义好的字符或字符串替换，生成类算法则更复杂一些，要求脱敏后的数据符合逻辑规则
4)数据脱敏方式
按照数据处理方式的不同，可以将数据脱敏分为静态数据脱敏和动态数据脱敏两大类。
静态数据脱敏指将数据文件进行去敏感、去隐私化的处理同时保证数据之间的关联关系。外发给第三方公司进行开发测试或是数据分析。得到的分析结果后能够将分析出的数据进行回溯。该脱敏方式适用于项目开发单位需要获取完整的数据才能保证数据分析工作的顺利完成，对于数据提供方，又不希望敏感数据泄漏出去，在这种情况下，就需要对数据进行可回溯的脱敏方式，保证发送出去的数据不包含敏感信息，当项目开发单位开发完成后，将分析系统或结果数据回溯成真实的结果数据。这样既保证了开发过程中的数据共享和结果一致性，又保证了真实数据不会在开发过程中泄漏。静态数据的脱敏非常适合数据拥有者在和多个外部开发团队的数据融合和数据共享中使用，保证开发、测试环节不会泄漏数据。
动态数据脱敏指用户在前端应用处调取后台数据库中敏感数据时，进行数据脱敏，再反馈至前台呈现。可在通讯层面上，通过代理部署方式，对业务系统数据库中敏感数据进行透明的、实时的脱敏。通常依据用户的角色、职责和其他IT定义身份特征，动态的对生产数据库返回的数据进行专门的屏蔽、加密、隐藏和审计，可确保不同级别的用户按照其身份特征恰如其分的访问敏感数据，并且不需要对生产数据库中的数据进行任何改变。动态数据脱敏同样支持同义替换、部分遮蔽、混合脱敏、确定性脱敏及可逆脱敏，通常可根据不同用户身份特征，指定对应的数据脱敏算法。
参照HIPAA法案的脱敏方案
HIPAA分为五个部分(Title)，每部分解决医疗保险改革的一个特定问题。该法案解决的第二个问题是简化管理，重点在医疗相关的信息安全问题，HIPAA 建立了一整套用于接收，传送和维护医疗信息，并确保隐私和个人身份信息的安全标准，这部分的核心是对PHI(Protected Health Information)等信息的隐私和安全保护。
为确保患者医疗隐私数据不被泄露，需首先完成患者相关隐私数据的脱敏处理(属静态脱敏方式)。
结合现有字段定义和实际使用情况，并参照HIPAA对PHI定义的18项内容，本发明逐项整理了字段对应分析和相应脱敏建议。具体入表1所示：
表1
Figure BDA0003748428610000121
Figure BDA0003748428610000131
Figure BDA0003748428610000141
Figure BDA0003748428610000151
Figure BDA0003748428610000161
Figure BDA0003748428610000171
此外，图11示出了数据质控模块的功能示意图，为了更好的数据应用，平台对数据采集、数据提取、数据入库等数据处理过程的数据质量要求很高。平台不仅要能支持高质量的数据处理，还需要支持对数据质量进行定量化观测统计与分析，并提供有效的数据质量提升手段。
系统运用大数据技术，结合医学信息规则引擎，建立多维度医疗数据质控体系，进行高度自动化的数据处理与数据提取，可以有效帮助用户解决数据采集进度失控、质量参差不齐、数据不足与错乱、数据标准未履行等问题，确保数据处理过程的完整性，一致性及准确性，提升数据分析利用的准确性和实用性。
系统引入先进的数据采样、测试集训练集构建、人工智能模型优化的系统性方法，做到数据质量的可监测、可分析、可优化。
系统构建数据自动化质控体系，开放数据质检能力，使医疗机构可自定义数据质控规则，支持对数据自动识别及人工核查校正。
提供超强纠错能力，可设置多种临床医学质控规则，自动校准医疗数据。同时辅以人工纸质病案抽样质检，实现治理过程正确、结果正确。使疾病诊疗能够得到最广泛的数据基础支撑，形成高质量大数据。数据质检是一个闭环、不断优化的流程。结合医院的数据治理及监测管理需求，形成对原生数据改进闭环和对数据清洗能力改进闭环，进而保证数据质量的持续改进。实现对数据的分布和动态变更情况的追踪，提升数据质量，接着对数据进行全面的业务化，规范化，形成统一的业务视图，并保障数据在各个使用环节的安全可控。在整个流程中设置数据处理规则，持续监控数据处理情况，及时发现数据质量问题，通过告警的方式通知相关人员及时处理问题。
数据治理平台通过数据质检模块来检验数据的质量问题。要求如下：
有系统化的数据治理流程，包括数据质量控制工具。对数据的完整性、连续性、横向关联、纵向关联等各方面都有相应的数据治理措施。对各个业务系统集成后的数据具备数据完整性自动质控功能。能够提供质控结果示例界面截图，比如展示医嘱和检验检查报告是否匹配。
基于数据质量控制的结果，可以识别业务系统数据质量问题，并对业务系统数据质量改进提出明确的要求和建议方案。
核心字段校验，根据数据模型表中配置的核心字段来校验每个核心字段是否为空；
数据完整性校验，根据数据质控完整性配置表的每一行来分别校验数据的完整性；
数据质控的两个步骤可并行执行，质控结果与记录保存到数据库中。可手动修改“质控结果”列；配置区域不可以修改；该条修改必须填写修改原因、签名。质控指标建表2
表2
Figure BDA0003748428610000181
Figure BDA0003748428610000191
可选地，数据再生产子系统通过事件图谱抽取方法实现数据的二次加工，生成医学研究数据。
具体地，主要基于自研的自然语言理解引擎实现将非结构化的电子病历转成结构化的事件图谱。系统根据医疗行业的特点以及公司业务的需求主要定义了疾病问题类、检查类、治疗类和个人史类四大类事件。其中疾病问题类、检查类与治疗类事件可互相建立关系，个人史类事件属于独立事件而不与其他事件建立关系。此外，为了充分表现医疗过程中的不同细节，系统在每类事件下又分别定义了不同的子事件，每类子事件具有更加明确的医学含义以及详细的属性。整体的事件图谱的结构框架如图12所示。事件之间关系如表3所示：
表3
Figure BDA0003748428610000192
事件图谱抽取：为了从非结构化的病历文本中获取到上述的各类事件以及事件之间关系，系统采用pipline的方式进行分层处理，逐步获取到医疗实体、实体关系以及最终的事件和事件关系。整体的系统框架图如图13所示：各子模块具体说明如下：
1、嵌套实体识别是为了获取不同粒度的医学信息，采用基于SPAN的模型实现，模型主要分为ENCODER和DECODER两个模块。ENCODER模块实现对病历文本的向量化以及特征抽出，主要采用Transform-encode和CNN相结合的结构。在DECODER阶段通过构造N2矩阵并集合一个多分类器同时得到不同粒度的实体。
2、依存关系抽取模块用于获取文本上直接表述的较浅层的医学实体之间的关系，主要参考NLP中依存句法分析任务，采用基于转移的方式来实现。模型中不仅包含基于DNN的分类模块同时也包含了支持实体调度的堆栈和列表。
3、医学关系抽取模块和依存关系抽取模块类似，不过主要用于获取更为抽象的医学关系。模块中的算法主要通过PCNN模型改造而来。
4、事件识别模块是为了发现和获取医疗文本中信息更为具体和丰富的文本片段，从而实现对信息的聚合以及对病历文本重要信息的提取。该模块主要采用专家规则以及基于DNN文本分类的模型来实现。
5、事件属性以及关系抽取，属性和关系抽取则是在事件抽取的基础上进一步实现信息聚合，从而得到最终的事件图谱。此模块中主要采用了规则引擎和抽取式的文档模型来实现。
数据再生产-专病库生产：
通过数据再生产子系统完成事件图谱抽取后，系统对抽取到事件图谱进行进一步的抽取和封装，从而得到医学信息更加集中专病库数据，进而为后端应用提供更加专业化的数据。
系统采用两套模式实现专病库数据的生产，具体数据生产流程如下图14 所示：两条专病库生产流程的起始点都是数据模块1，即专病库的原始数据都来源于非结构化的CDM数据和结构化的CDM数据。专病库生产的终点都是数据模块5，将生产出来的专病库结果数据按照CRF_DATA定义的数据模型存储在 MongoDB数据库中。
第一条专病库生产流程依赖于数据处理模块1将CDM中存储的散表以患者维度聚合成一个个JSON格式的数据并存储在MongoDB库中，之后再通过事件抽取系统以及数据组装系统后得到最终的专病库结果数据。
第二条专病库生产流程同样依赖于数据处理模块1将CDM中散表数据聚合到MongoDB中，之后再将聚合后的数据拆分到不同的散表中，得到结构化数据和非结构化数据。其中结构化数据直接通过通用专病库生产模块得到专病库生产结果；非结果化数据需要经过事件抽取系统转成结构化的事件图谱数据后再经过通用专病库生产模块得到专病库结果。
专病库数据生产流程图中个模块的说明如下：
A.数据存储：
1、通过ETL得到的病历数据，遵循CDM模板存储在关系数据库中；
2、患者详情数据，根据EMPI号将同一个患者的数据聚合在一起，其中同一患者不同就诊的数据相互隔离；
3、算法内部数据模型，主体和CDM一样，只是在每张表中增加了记录标号字段，用来用来区分不同的记录，如一次就诊可能包含多次CT检查报告，那么它们对应的记录标号会依次增加；
4、事件表/事件图谱，存储经过NLP处理后的结构化数据，目前和3存储在同一个关系数据库中；
5、CRF_DATA，专病库结果数据，数据格式遵循各自病种的CRF模板；
B.数据处理：
1、SDB_SERVER，数据聚合，负责将同一患者不同表的数据聚合在一起，构成以患者为维度的JSON格式的数据；
2、SDB_SERVER，特异性专病库生产，负责读取患者数据、调用NLP_SERVER 以及执行包含医学规则的组装逻辑，最终生产出专病库数据；
3、NLP_SERVER，数据结构化服务，执行包含NER、依存分析等一系列操作，负责将非结构化的文本数据转成结构化的数据；
4、CDM数据转存，负责将patient_detail中的数据还原成CDM格式的数据，但在还原的过程中保留表编号信息，拆分后的结构能够支持后续中间层生产的单字段操作；
5、中间层生产，负责从非结构化数据中抽取事件信息，抽取的事件主要包含疾病、手术、症状、检查等；
6、通用专病库生产，根据一定的医学规则，从中间层和CDM算法内部库中生产专病库字段结果。
可选地，数据服务子系统通过统一的上层开放接口进行数据访问。
具体地，数据统一访问接口语言UQL，基于医学数据特点，参考SQL语言，并做了语法扩展，增加了处理时序数据的语法和算子。
UQL主要是面向临床数据的查询场景，词法和语法规则同SQL，但语义上略有差异，主要是体现在，UQL的表不是单纯意义上表，而是一个数据集合，数据行也是一个数据集合，如patients表表示病人维度的数据集合，每条数据指某个病人完整的病历数据，visits表表示就诊维度的数据集合，每条数据值某个病人某次就诊的完整病历数据。本发明提供的UQL的改进函数例如可以包括：计算一组数据统计值的函数、处理时序数据的函数(首次、末次以及n次等)、时间戳函数、输入数据信息统计函数以及输出数据统计值函数等。
示例1
全文模糊查询:男，女
UQL：
SELECT patient_info.PATIENT_SN,patient_info.GENDER,patient_info.ETHNIC
FROM patients
WHERE QUERY('男，女')
示例2
跨就诊查询:诊断为肺癌，诊断时间早于2015年，并且做过右下肺切除或者左下肺切除，患过肺炎，且肺炎患病时间早于2013年的男性患者
UQL：
SELECT patient_info.PATIENT_SN,patient_info.GENDER,patient_info.ETHNIC
FROM patients
WHERE patient_info.GENDER＝'男 'AND{visits.diagnose.DIAGNOSISCONTAIN'肺癌 'AND visits.visit_info.ADMISSION_DATE<'2015-01-01 00:00:00'}AND{visits.operation_info CONTAIN'右下肺切除' OR visits.operation_info CONTAIN'左下肺切除 '}AND{[visits.diagnose.DIAGNOSIS]CONTAIN'肺炎' AND visits.visit_info.ADMISSION_DATE
<'2013-01-0100:00:00'}
此外，图15示出了数据服务子系统的功能模块示意图，分布式搜索引擎采用ElasticSearch，它是一个基于Lucene的搜索服务器，提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。实现亿万级病历中秒级返回搜索结果，支持复杂的查询条件并支持全文检索。查询服务缓存模块采用 Redis集群实现，缓存模块对外提供UQL查询结果的缓存机制，上层业务服务提交查询语句时，若发现缓存中已经有相同的查询，则直接从缓存中获取结果数据，从而减少查询响应时间，提高查询平台并发能力。
此外，参考图16所示，示出了同一API服务的功能示意图，通过统一API 服务的API生成、注册、编排、授权、限流、隔离、监控告警、统计等一系列服务，实现平台内各业务系统之间数据的安全灵活交换，对各项应用和临床研究的协同打通了通道。平台支持对外统一的数据访问接口和模型，平台提供API 接口对外开放，同时也提供二次开发界面，针对不同的使用需求也可以提供定制化的视图。以满足不同第三方系统对系统中数据的调阅使用。
对外后台服务的方式被第三方应用程序调用，支持特定患者的病例检索和数据导出。
对外统一数据服务支持采用脚本或后台服务的方式基于数据平台开放的统一查询语法进行数据查询，定义较为复杂的查询和病例筛选条件，以及查询结果的字段。
API生成：数据源配置，向导模式生成、脚本模式生成
API注册：注册已有的API至数据服务，进行统一管理、发布和对接。页面配置。
API测试：测试已发布的API，在服务管理页面进行测试，需要先发布API。页面配置。
API发布：在数据服务中生成和注册的API，需要发布至API网关才能对外提供服务。数据服务与API网关产品相关连通，支持一键发布API至API网关。
API网关：API网关是API对外开放，或者在自己的应用中调用的最后一道防线，提供权限管理、流量控制、访问控制、计量等服务。通常在数据服务中生成和注册的API，需要发布至API网关才能对外提供服务。数据服务与API 网关相关连通，支持一键发布API至API网关。
API授权：对已发布API进行下线、授权和变更协议等
API调用：直接用API网关控制台提供的多语言调用示例来测试调用，可以自行编辑HTTP(S)请求来调用API
API统计：提供了各类可视化图表及统计数据，包括工作空间下的API总数、总调用次数、总执行时长用量，以及网关状态码、服务错误码、服务资源分配、排行榜单等信息，从全局角度了解API的调用情况。
可选地，数据平台系统还包括：作业和资源管理子系统以及管理和监控平台，其中
作业和资源管理子系统提供对硬件资源以及用户作业的监控和管理能力；
管理和监控平台提供对系统进行可视化操作的面板。
本系统采用Apache DolphinScheduler做为系统的任务调度中心，它是一个分布式去中心化，致力于解决数据处理流程中错综复杂的依赖关系，使调度系统在数据处理流程中开箱即用。
本系统中的数据操作任务集成到统一任务调度平台形成一个分布式去中心化、以扩展的可视化DAG(Directed Acyclic Graph，有向无环图)工作流服务，通过对任务进行定义、依赖编排、定时设置、启动停止等灵活的操作管理，保障数据加工链路的安全；一旦任务发生异常，能第一时间得到有效处理处置，避免对数据应用造成影响。
具备分布式去中心化的特性，具备易扩展的可视化DAG工作流任务调度；
流程定义：通过拖拽任务节点并建立任务节点的关联所形成的可视化DAG；
流程实例：流程实例是流程定义的实例化，可以通过手动启动或定时调度生成,流程定义每运行一次，产生一个流程实例；
任务实例：任务实例是流程定义中任务节点的实例化，标识着具体的任务执行状态；
任务类型：支持有SHELL、SQL、SUB_PROCESS(子流程)、PROCEDURE，同时计划支持动态插件扩展，注意：其中子SUB_PROCESS也是一个单独的流程定义，是可以单独启动执行的；
调度方式：系统支持基于cron表达式的定时调度和手动调度。命令类型支持：启动工作流、从当前节点开始执行、恢复被容错的工作流、恢复暂停流程、从失败节点开始执行、补数、定时、重跑、暂停、停止、恢复等待线程。其中恢复被容错的工作流和恢复等待线程两种命令类型是由调度内部控制使用，外部无法调用；
定时调度：支持cron表达式可视化的生成；
任务依赖：系统不单单支持DAG简单的前驱和后继节点之间的依赖，同时还提供任务依赖节点，支持流程间的自定义任务依赖；
任务优先级：支持流程实例和任务实例的优先级，如果流程实例和任务实例的优先级不设置，则默认是先进先出；
邮件告警：支持SQL任务查询结果邮件发送，流程实例运行结果邮件告警及容错告警通知；
失败策略：对于并行运行的任务，如果有任务失败，提供两种失败策略处理方式，继续是指不管并行运行任务的状态，直到流程失败结束。结束是指一旦发现失败任务，则同时Kill掉正在运行的并行任务，流程失败结束。
进一步地，管理和监控平台包括用户权限管理、日志管理以及服务器监控，其中参考图15所示，用户与权限管理通过对用户账号、角色、菜单、数据权限等配置，实现数据访问使用管控；通过操作日志记录，做到安全审计留痕；通过软硬件资源、任务调度的监控，保障数据处理链路正常稳定进行，确保数据结果准确；数据权限设置：可以对某个用户或者角色设定各种权限。权限包括：患者资料的搜索和查看权限；数据导出的权限；患者隐私资料调阅的权限；指定功能(如查看某个功能视图)的权限；权限的设置可以设定有效期。
1.数据管理平台提供医疗机构账户、用户账户、角色、以及数据资源访问权限的管理。
2.菜单管理随时随地灵活调整数据平台的服务上线，直接配置URL生效，可一个根据用户的使用习惯，灵活配置顺序，方便快捷。
3.用户管理包含用户的增删改查，权限设置和查询。
4.角色管理可以定义和管理不同的角色，并对角色设定相应的权限集合。
5.租户管理支持平台设置外部平台调用接口的有效性鉴权。
日志管理
1.日志管理可以展示所有账号在系统中登录与操作的日志记录，方便管理员查看账号操作情况或查找问题的日志记录。
2.数据管理平台支持各个数据治理和加工服务的调度、监控和日志管理。
3.平台不仅记录用户对于平台内操作日志，同时记录数据变更的记录，全方位管控平台的安全性。
服务器监控
系统集成Cloudera Manager，管理CDH集群，添加、删除节点等操作；监控集群的健康情况，对设置的各种指标和系统运行情况进行全面监控；对集群出现的问题进行诊断，对出现的问题给出建议解决方案；并对hadoop的多组件进行整合。
系统集成Zabbix，通过集成服务器、应用服务器、数据库服务器等系统提供标准化的接口以支持监控和管理功能，并通过多种途径通知管理员快速定位与解决服务器的问题。同时管理员可以通过前端界面很方便地对服务器进行监控管理，具体包括：
监控平台各服务器的CPU负载监控。
监控平台内存使用监控。
监控平台磁盘使用监控。
监控平台网络状况使用监控。
监控平台端口监视。
监控平台日志监视管理。
后台管理平台
具有用户的登录功能；登录方式支持采用单点登录方式进行数据对接。
支持用户的修改密码功能，可在页面上进行对用户的新建、编辑、查询、启用停用、重置密码、删除等操作。
支持用户的退出登录功能。
支持系统配置功能，在页面上可以新增应用系统的基本信息，保存后，自动跳转到编辑页面。
支持科室管理功能，在科室配置中，进行科室的新增、删除、编辑、查询的管理功能。
支持用户管理功能，在页面上可以新增用户的基本信息，修改与保存用户数据。
支持角色管理功能，在页面上设置此用户对应的角色。
支持权限管理功能，在页面上可进行中进行角色权限的配置，包括新增、删除、查询、修改等。
支持日志管理功能，平台上的操作统一提供日志备查。
此外，上层开发接口，对应用层开发提供两种类型低代码开发接口：UQL 模式和API。隐私计算接口：提供和主流隐私计算解决方案的接口，支持联邦训练和可信执行环境；身份认证接口：通过区块链进行授权、身份认证和密钥交换；数据安全访问接口：支持数据加密传输和数据签名、数据水印等安全保护措施。
从而本发明采用与云计算相反的模式，放弃建立“中心化大数据平台”，而是通过智能数据网关建立多点数据网络，将数据留在原地；通过安全协同技术，实现“数据可用不可见”以及“数据不动程序动”；建立安全的多点协作机制以实现对数据的系统化治理，从而为全面的医疗数据资源安全、合规、可监管地利用提供一套基础设施。
除非另外具体说明，否则在这些实施例中阐述的部件和步骤的相对布置、数字表达式和数值不限制本公开的范围。同时，应当明白，为了便于描述，附图中所示出的各个部分的尺寸并不是按照实际的比例关系绘制的。对于相关领域普通技术人员已知的技术、方法和设备可能不作详细讨论，但在适当情况下，所述技术、方法和设备应当被视为授权说明书的一部分。在这里示出和讨论的所有示例中，任何具体值应被解释为仅仅是示例性的，而不是作为限制。因此，示例性实施例的其它示例可以具有不同的值。应注意到：相似的标号和字母在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步讨论。
为了便于描述，在这里可以使用空间相对术语，如“在……之上”、“在……上方”、“在……上表面”、“上面的”等，用来描述如在图中所示的一个器件或特征与其他器件或特征的空间位置关系。应当理解的是，空间相对术语旨在包含除了器件在图中所描述的方位之外的在使用或操作中的不同方位。例如，如果附图中的器件被倒置，则描述为“在其他器件或构造上方”或“在其他器件或构造之上”的器件之后将被定位为“在其他器件或构造下方”或“在其他器件或构造之下”。因而，示例性术语“在……上方”可以包括“在……上方”和“在……下方”两种方位。该器件也可以其他不同方式定位(旋转90度或处于其他方位)，并且对这里所使用的空间相对描述作出相应解释。
在本公开的描述中，需要理解的是，方位词如“前、后、上、下、左、右”、“横向、竖向、垂直、水平”和“顶、底”等所指示的方位或位置关系通常是基于附图所示的方位或位置关系，仅是为了便于描述本公开和简化描述，在未作相反说明的情况下，这些方位词并不指示和暗示所指的装置或元件必须具有特定的方位或者以特定的方位构造和操作，因此不能理解为对本公开保护范围的限制；方位词“内、外”是指相对于各部件本身的轮廓的内外。
以上所述，仅为本申请较佳的具体实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应该以权利要求的保护范围为准。

Claims (10)

1.一种智能医学数据网关系统，其特征在于，包括：数据平台系统以及安全协同设备，其中
所述数据平台系统由一组服务器构成，用于实现数据存储、数据计算以及数据服务的平台；
所述安全协同设备与所述数据平台系统进行通信连接，用于对所述数据平台系统进行运行环境部署和管理、隐私计算、安全共享以及授权认证。
2.根据权利要求1所述的智能医学数据网关系统，其特征在于，所述安全协同设备通过防火墙与所述数据平台系统进行通信连接，并且所述安全协同设备包括：应用层、DSL层、智能合约层、数据沙箱和区块链层，其中
所述应用层包括管理配置中心以及应用接口；
所述DSL层用于实现医学数据应用领域的抽象语言描述；
所述智能合约在所述数据沙箱中执行，并且所述数据沙箱和区块链层用于实现数据的安全协同。
3.根据权利要求2所述的智能医学数据网关系统，其特征在于，所述DSL层采用UQL访问接口语言。
4.根据权利要求2所述的智能医学数据网关系统，其特征在于，所述智能合约层包括监管合约、业务合约、领域类合约、数据分析类合约以及产权信用类合约，通过预先设置的函数进行调用。
5.根据权利要求1所述的智能医学数据网关系统，其特征在于，所述数据平台系统包括：数据采集和治理子系统、数据再生产子系统以及数据服务子系统，其中
所述数据采集和治理子系统用于从医院信息系统接收医学数据信息，并根据所述医学数据信息整合新的数据源；
所述数据再生产子系统用于将所述数据源进行二次加工，生成医学规则数据；
所述数据服务子系统用于实现数据引擎。
6.根据权利要求5所述的智能医学数据网关系统，其特征在于，所述数据采集和治理子系统通过CDM进行数据模型的构建，并且所述数据采集和治理子系统还包括：数据采集模块、数据清洗模块、数据质控模块、数据脱敏模块，用于实现数据的采集以及预处理。
7.根据权利要求5所述的智能医学数据网关系统，其特征在于，所述数据再生产子系统通过时间图谱抽取方法实现数据的二次加工，生成医学规则数据。
8.根据权利要求5所述的智能医学数据网关系统，其特征在于，所述数据服务子系统通过统一的上层开放接口进行数据访问。
9.根据权利要求1所述的智能医学数据网关系统，其特征在于，所述数据平台系统还包括：作业和资源管理子系统以及管理和监控平台，其中
所述作业和资源管理子系统提供对硬件资源以及用户作业的监控和管理能力；
所述管理和监控平台提供对系统进行可视化操作的面板。
10.根据权利要求9所述的智能医学数据网关系统，其特征在于，所述管理和监控平台包括用户与权限管理、日志管理以及服务器监控。
CN202210836259.4A 2022-07-15 2022-07-15 智能医学数据网关系统 Pending CN115396260A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210836259.4A CN115396260A (zh) 2022-07-15 2022-07-15 智能医学数据网关系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210836259.4A CN115396260A (zh) 2022-07-15 2022-07-15 智能医学数据网关系统

Publications (1)

Publication Number Publication Date
CN115396260A true CN115396260A (zh) 2022-11-25

Family

ID=84116753

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210836259.4A Pending CN115396260A (zh) 2022-07-15 2022-07-15 智能医学数据网关系统

Country Status (1)

Country Link
CN (1) CN115396260A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117389529A (zh) * 2023-12-12 2024-01-12 神州医疗科技股份有限公司 基于pacs系统的ai接口调用方法及系统
CN117727410A (zh) * 2023-12-14 2024-03-19 广东省疾病预防控制中心 一种基于人工智能nlp技术的医疗数据处理方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109410110A (zh) * 2018-10-22 2019-03-01 上海市疾病预防控制中心 区域卫生信息平台中实现公共卫生数据交互控制的系统
CN109670340A (zh) * 2018-12-29 2019-04-23 湖南网数科技有限公司 一种医疗数据的安全可信交换共享方法和系统
US20210065179A1 (en) * 2019-08-30 2021-03-04 Salesforce.Com, Inc. Payments platform, method and system having external and internal operating modes for ingesting payment transaction data from payment gateway services at a cloud computing platform

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109410110A (zh) * 2018-10-22 2019-03-01 上海市疾病预防控制中心 区域卫生信息平台中实现公共卫生数据交互控制的系统
CN109670340A (zh) * 2018-12-29 2019-04-23 湖南网数科技有限公司 一种医疗数据的安全可信交换共享方法和系统
US20210065179A1 (en) * 2019-08-30 2021-03-04 Salesforce.Com, Inc. Payments platform, method and system having external and internal operating modes for ingesting payment transaction data from payment gateway services at a cloud computing platform

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117389529A (zh) * 2023-12-12 2024-01-12 神州医疗科技股份有限公司 基于pacs系统的ai接口调用方法及系统
CN117727410A (zh) * 2023-12-14 2024-03-19 广东省疾病预防控制中心 一种基于人工智能nlp技术的医疗数据处理方法及系统

Similar Documents

Publication Publication Date Title
Subrahmanya et al. The role of data science in healthcare advancements: applications, benefits, and future prospects
Madhuri et al. Challenges and issues of data analytics in emerging scenarios for big data, cloud and image mining
US12080404B2 (en) Methods, systems and computer program products for retrospective data mining
CN117238458B (zh) 基于云计算的重症护理跨机构协同平台系统
CA2637574C (en) Platform for interoperable healthcare data exchange
CN110415831A (zh) 一种医疗大数据云服务分析平台
KR102583800B1 (ko) 다중 이종 기록 시스템(SORs) 간의 블록체인-기반 의미적 상호운용성을 제공하는 컴퓨팅 시스템 및 관련방법
Faroukhi et al. An adaptable big data value chain framework for end-to-end big data monetization
WO2011009211A1 (en) System, method and computer program for multi-dimensional temporal data mining
CN115396260A (zh) 智能医学数据网关系统
CN113722301A (zh) 基于教育信息的大数据处理方法、装置及系统、存储介质
Rao et al. Survey on electronic health record management using amalgamation of artificial intelligence and blockchain technologies
Varshney et al. Big data analytics and data mining for healthcare informatics (HCI)
Rodríguez et al. SOA-enabled compliance management: instrumenting, assessing, and analyzing service-based business processes
CN116910023A (zh) 一种数据治理系统
Chen [Retracted] Optimization of Clinical Nursing Management System Based on Data Mining
Kumar et al. Analysis of Business Intelligence in Healthcare Using Machine Learning
EP4127972A1 (en) Methods, systems and computer program products for retrospective data mining
Murphy et al. Information Technology Systems
Chavali et al. Clinical Trials in the Realm of Health Informatics
Aydemir et al. A hybrid process mining approach for business processes in financial organizations
Samra et al. Design of a clinical database to support research purposes: Challenges and solutions
CN109102866A (zh) 一种诊疗数据智能合约方法及装置
Subhani Continuous process auditing (CPA): An audit rule ontology approach to compliance and operational audits
Esiefarienrhe et al. Healthcare information System for tuberculosis and the creation of event log for process mining

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication

Application publication date: 20221125

RJ01 Rejection of invention patent application after publication