CN109471866A - 增量医疗数据更新方法及系统 - Google Patents
增量医疗数据更新方法及系统 Download PDFInfo
- Publication number
- CN109471866A CN109471866A CN201811334183.5A CN201811334183A CN109471866A CN 109471866 A CN109471866 A CN 109471866A CN 201811334183 A CN201811334183 A CN 201811334183A CN 109471866 A CN109471866 A CN 109471866A
- Authority
- CN
- China
- Prior art keywords
- data
- patient
- database
- index
- written
- 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.)
- Granted
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Medical Treatment And Welfare Office Work (AREA)
Abstract
本发明涉及医疗数据处理技术领域,提供一种增量医疗数据更新方法及系统,增量医疗数据更新方法包括:将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。本发明通过病人内全量,病人间增量的方式,来平衡整个处理流程的性能和逻辑复杂度,综合增量更新和全量更新的思路,在严格控制时间的情况下,完成增量数据更新,在实现T+1的数据更新的情况下,同时也使服务器的压力减少到可承受范围。此外,通过将数据存储在键‑值存储系统中,大大提高了数据查询速度和并发处理能力。
Description
技术领域
本发明涉及医疗数据处理技术领域,具体涉及一种增量医疗数据更新方法及系统。
背景技术
医疗数据主要包含患者的基本信息,病历,医嘱,护理文书,检验报告,检查报告等,这些数据反映患者的临床诊断,诊疗过程,以及相应的治疗措施和结果。随着信息技术的发展,越来越多的医疗数据由手工录入改为电子化管理。保存在各个医疗信息系统中的数据逻辑上是分表存储的,比如有患者基本信息表,病历表,医嘱表等等。患者基本信息表中的主键ID唯一标识一个病人,其他表中的主键ID唯一标识一次就诊,因此,一个病人的所有历史数据呈树状结构,一个病人对应多次就诊,一次就诊对应此次就诊下的多个医疗记录。
完整数据处理流程,以下简称为全量ETL过程,包含一系列数据处理步骤,如清洗,合并,转换,统计,写库等,通常需要病人的完整历史数据才能进行。比如,当需要统计一个病人过去所有的急诊次数时,需要一个病人的历史完整的就诊数据才可进行计算。但是基于数据实时性的要求,整个信息处理流程要求数据具有T+1的时效性,T+1的含义是当天产生的数据,需要在当天+1天(明天)体现在最终的处理结果中。
工程上比较常见的处理方式有两种:第一种是每次数据更新都使用全量的数据,优点是处理逻辑简单,编程容易,缺点是处理时间长,对服务器的压力大,并且在数据量到达一个阈值后无法在规定的T+1天内进行完整的数据处理。
另一种是每次数据更新都只用增量数据,也就是发生变更的数据,此种方案的优点是性能高,对服务器压力小,缺点是逻辑复杂,编程困难,且在某些情况下,无法仅仅通过增量数据产生逻辑自洽的最终数据处理结果。
因此,需要一种新的医疗数据更新方法。
在所述背景技术部分公开的上述信息仅用于加强对本发明的背景的理解,因此它可以包括不构成对本领域普通技术人员已知的现有技术的信息。
发明内容
本发明的目的在于提供一种增量医疗数据更新方法,进而解决医疗数据ETL处理过程中数据增量更新问题,实现在限定的时间内,对增量数据进行完整、正确的处理。
本发明的其他特性和优点将通过下面的详细描述变得显然,或部分地通过本发明的实践而习得。
根据本发明的第一方面,公开一种增量医疗数据更新方法,包括:
将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;
将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及
对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。
根据本发明的一示例实施方式,其中数据存储在键-值存储系统中;以及在键-值存储系统中,其中键是病人ID,值是该病人当前时间的所有数据。
根据本发明的一示例实施方式,其中单个病人的所有数据存储为一个单独的JSON存储格式。
根据本发明的一示例实施方式,其中数据处理为包括清洗,合并,转换和统计的完整数据处理流程。
根据本发明的一示例实施方式,其中对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中包括:
对增量数据进行数据处理以得到最终需要写入数据库或者索引的新数据;
删除数据库或者索引中所有发生数据变更的病人的数据;以及
将新数据写入数据库或者索引。
根据本发明的一示例实施方式,其中对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中还包括:记录所有发生数据变更的病人的ID。
根据本发明的一示例实施方式,所述方法还包括:当数据更新失败时,进行数据回滚流程,其中数据回滚流程包括:
删除数据库或者索引中所有发生数据变更的病人的ID;以及
将所有发生数据变更的病人在数据更新前的数据写入数据库或者索引。
根据本发明的第二方面,提供一种增量医疗数据更新系统,其特征在于,所述系统包括:
全量数据模块,用于将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;
增量数据模块,用于将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及
数据处理及写入模块,用于对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。
根据本发明的第三方面,提供一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现上述任意一项所述的方法步骤。
根据本发明的第四方面,提供一种电子设备,其特征在于,包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现上述任意一项的方法步骤。
根据本发明的一些示例实施方式,通过病人内全量,病人间增量的方式,来平衡整个处理流程的性能和逻辑复杂度,综合增量更新和全量更新(半全量半增量)的思路,在严格控制时间的情况下,完成增量数据更新,在实现T+1的数据更新的情况下,同时也使服务器的压力减少到可承受范围。
根据本发明的另一些示例实施方式,通过将数据存储在键-值存储系统中,大大提高了数据查询速度和并发处理能力。
应当理解的是,以上的一般描述和后文的细节描述仅是示例性的,并不能限制本发明。
附图说明
通过参照附图详细描述其示例实施例,本发明的上述和其它目标、特征及优点将变得更加显而易见。
图1示出根据本发明一示例实施方式的增量医疗数据更新方法的流程图。
图2示出根据本发明另一示例实施方式的增量医疗数据更新方法的流程图。
图3示出根据本发明一示例性实施方式的增量医疗数据更新系统的框图。
图4示出根据本发明一示例实施方式的电子设备。
具体示例实施方式
现在将参考附图更全面地描述示例实施方式。然而,示例实施方式能够以多种形式实施,且不应被理解为限于在此阐述的范例;相反,提供这些示例实施方式使得本发明的描述将更加全面和完整,并将示例实施方式的构思全面地传达给本领域的技术人员。附图仅为本发明的示意性图解,并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分,因而将省略对它们的重复描述。
此外,所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多示例实施方式中。在下面的描述中,提供许多具体细节从而给出对本发明的示例实施方式的充分理解。然而,本领域技术人员将意识到,可以实践本发明的技术方案而省略所述特定细节中的一个或更多,或者可以采用其它的方法、组元、步骤等。在其它情况下,不详细示出或描述公知结构、方法、实现或者操作以避免喧宾夺主而使得本发明的各方面变得模糊。
附图中所示的一些方框图是功能实体,不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体,或在一个或多个硬件模块或集成电路中实现这些功能实体,或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
本发明的目的在于提供一种增量医疗数据更新方法及系统,增量医疗数据更新方法包括:将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。本发明设计了一种增量医疗数据更新方法,通过病人内全量,病人间增量的方式,来平衡整个处理流程的性能和逻辑复杂度,综合增量更新和全量更新(半全量半增量)的思路,在严格控制时间的情况下,完成增量数据更新,在实现T+1的数据更新的情况下,同时也使服务器的压力减少到可承受范围。此外,通过将数据存储在键-值存储系统中,大大提高了数据查询速度和并发处理能力。
下面结合图1-4对本发明的增量医疗数据更新方法及系统进行详细说明,其中,图1示出根据本发明一示例实施方式的增量医疗数据更新方法的流程图;图2示出根据本发明另一示例实施方式的增量医疗数据更新方法的流程图;图3示出根据本发明一示例性实施方式的增量医疗数据更新系统的框图;图4示出根据本发明一示例实施方式的电子设备。
首先结合图1对本发明一示例实施方式的一增量医疗数据更新方法进行具体说明,图1示出根据本发明一示例实施方式的增量医疗数据更新方法的流程图。
在医学数据处理场景下,数据处理有一个最重要的特征,就是数据处理的粒度基本是在病人维度,也就是说,聚合,统计,分组等常见的操作,只会在一个病人内进行,病人间数据的相关性较弱。
医院按照大小不同,核心病种不同,数据量有很大的区别,大型三甲医院历史病人数在百万级,每日变更病人在千级到万级。小型专科医院或二甲医院历史病人数在几十万级,每日变更病人数在百级,全量处理和增量处理数据量差距在100倍以上。
在全量处理流程下,读取全部病人的全量数据作为数据输入,进行并行处理,算出最终每个病人需要写入数据库或者索引的字段(上述说过,所有计算在病人内部完成,不需要病人间信息互相操作),最后对每个病人的处理完成的字段进行写入。此处需要说明,数据库和索引都支持按照一个病人维度进行数据的删除和增加。
根据试验,平均一个病人的完整处理需要0.02秒,若某一医院全量病人为300万,则处理数据所用时间为20小时,不能达到T+1的数据更新要求。
因此,本发明针对T+1的数据处理要求以及增量处理方式和全量处理方式的优缺点,结合医学数据的特质,综合上述两种技术方案,以病人内全量,病人间增量的方式,来平衡整个处理流程的性能和逻辑复杂度。在采取此种数据更新方案的情况下,假设平均每日变更病人数为5000,则数据处理时间在10分钟内(系统启动,准备需要一些时间),可以达到T+1的数据更新,也对服务器的压力减少到可承受范围。下面结合图1进行具体说明。
如图1所示,在S101,将发生数据变更的病人的所有历史数据作为该病人的新的全量数据。具体处理方式是,每次更新数据,如果病人A有任何数据变更,则取此病人所有历史数据作为此病人的新的全量数据。
根据本发明的一示例实施方式,其中数据存储在键-值存储系统(Key-Value存储系统,简称KV存储系统)中。KV存储是一种分布式非关系型存储系统,可以直接通过key(键)查询到相应的value(值),或者通过key去更新value,并且在极快的速度内完成,而且查询速度和整个KV存储已经存储了多少对KV无关,常见的KV存储有Mongodb,Hbase等。KV存储能在上万并发连接下,轻松地完成高速查询;而MySQL等关系型存储系统,在几百个并发连接下,就基本上崩溃了。因此通过将数据存储在键-值存储系统中,大大提高了数据查询速度和并发处理能力。
根据本发明的一示例实施方式,在键-值存储系统中,其中键是病人ID,用于在医院内标识唯一的病人/患者,值是该病人当前时间的所有数据。
根据本发明的一示例实施方式,其中单个病人的所有数据存储为一个单独的JSON存储格式,例如可以表示为PP。也就是说,可以用PP表示一种病人维度所有数据的存储格式,具体存储格式为一个大json,如{“patient”:[{}],”visit”:[{},{}],”labexam”:[{},{}],”exam”:[{}],”order”:[{},{}]},这其中patient指病人基本信息,visit指就诊,labexam指检验,exam指检查,order指医嘱,[]含义为多个元素,其中每个元素又为一个json,所以PP就是一种最外层的key(键),是活动记录名称,每个key的value是所有这个类型的活动记录的集合的存储一个病人所有活动记录的格式。
在S102,将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据。具体处理方式是,每次更新数据,如果病人A有任何数据变更,则取此病人所有历史数据作为此病人的新的全量数据,在T+1场景下,每日新增/变更的病人数量在千级(以大型三甲医院为例,但本发明不限于此),所以可以把这些病人的全量数据,作为此次更新的增量数据。
在S103,对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。具体处理方式是,上游给出所有数据有变化的病人/患者的PP(此次更新的增量数据),首先对此部分患者的数据(此次更新的增量数据)进行数据处理以计算出最终需要写入数据库或者索引的字段(数据),记录此批病人/患者的病人/患者ID列表以备做为后续异常处理和备份之用(记录病人/患者ID列表的步骤是可选的步骤而不是必须的步骤),然后删除数据库和/或索引中此批病人/患者的数据,最后用新生成的数据重写索引和/或数据库,此时确定增量数据更新完毕,可以用此批数据的PP更新这批病人/患者的旧PP。
根据本发明的一示例实施方式,其中数据处理为完整数据处理流程。
根据本发明的一示例实施方式,其中完整数据处理流程包括清洗,合并,转换和统计。
图2示出根据本公开另一示例实施方式的增量医疗数据更新方法的流程图,其中,S201-S203与S101-S103相同,在此不再赘述,下面仅对S204进行说明:
在S204,当数据更新失败时,进行数据回滚流程。
根据本发明的一示例实施方式,其中数据回滚流程包括:删除数据库或者索引中所有发生数据变更的病人的ID;以及将所有发生数据变更的病人在数据更新前的数据写入数据库或者索引。
具体来说,出现更新失败的回滚流程是,若新生成的数据在写数据库或者索引过程出现失败,则首先删除库中此批病人/患者的ID,之后用此批用户旧的PP重新写库,保证任何时候库都为合法状态。此次增量更新不成功,但是数据依然可用。
下述为本发明系统实施方式,可以用于执行本发明方法实施方式。对于本发明系统实施方式中未披露的细节,请参照本发明方法实施方式。
图3示出根据本发明一示例性实施方式的增量医疗数据更新系统的框图。
如图3所示,增量医疗数据更新系统300可包括全量数据模块301、增量数据模块302和数据处理及写入模块303。
其中,全量数据模块301用于将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;增量数据模块302用于将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;数据处理及写入模块303用于对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。
需要说明的是,上述增量医疗数据更新系统中各模块的具体细节已经在对应的增量医疗数据更新方法中进行了详细描述,因此此处不再赘述。
应当注意,尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元,但是这种划分并非强制性的。实际上,根据本发明的实施方式,上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之,上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
此外,尽管在附图中以特定顺序描述了本发明中方法的各个步骤,但是,这并非要求或者暗示必须按照该特定顺序来执行这些步骤,或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的,可以省略某些步骤,将多个步骤合并为一个步骤执行,以及/或者将一个步骤分解为多个步骤执行等。
通过以上的实施方式的描述,本领域的技术人员易于理解,这里描述的示例实施方式可以通过软件实现,也可以通过软件结合必要的硬件的方式来实现。因此,根据本发明实施方式的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中或网络上,包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本发明实施方式的方法。
作为另一方面,本发明还提供了一种计算机可读介质,该计算机可读介质可以是上述实施方式中描述的系统中所包含的;也可以是单独存在,而未装配入该系统中。上述计算机可读介质承载有一个或者多个程序,当上述一个或者多个程序被一个该系统执行时,使得该系统可以实现上述任一示例实施方式所述的方法步骤。
图4示出根据本发明一示例实施方式的电子设备。
如图4所示,电子设备400可包括:一个或多个处理器410;存储器420。另外,根据一实施方式,电子设备还可包括发射器及接收器。
处理器410可调用存储器420中存储的指令控制相关操作,如控制发射器和接收器进行信号收发等。根据一实施方式,存储器420存储用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器410执行时,使得所述一个或多个处理器410实现上述任一示例实施方式所述的方法步骤。处理器410可调用存储器420中存储的指令控制相关操作。易于理解,存储器420还可存储用于处理器410控制根据本发明实施方式的其他操作的指令,这里不再赘述。
通过以上的详细描述,本领域的技术人员易于理解,根据本发明实施例的方法具有以下的优点中的一个或多个。
根据本发明的一些示例实施方式,通过病人内全量,病人间增量的方式,来平衡整个处理流程的性能和逻辑复杂度,综合增量更新和全量更新(半全量半增量)的思路,在严格控制时间的情况下,完成增量数据更新,在实现T+1的数据更新的情况下,同时也使服务器的压力减少到可承受范围。
根据本发明的另一些示例实施方式,通过将数据存储在键-值存储系统中,大大提高了数据查询速度和并发处理能力。
本领域技术人员在考虑说明书及实践这里公开的发明后,将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化,这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的,本发明的真正范围和精神由下面的权利要求指出。
应当理解的是,本发明并不局限于上面已经描述并在附图中示出的精确结构,并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。
Claims (10)
1.一种增量医疗数据更新方法,包括:
将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;
将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及
对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。
2.根据权利要求1所述的方法,其特征在于,其中数据存储在键-值存储系统中;以及在键-值存储系统中,其中键是病人ID,值是该病人当前时间的所有数据。
3.根据权利要求2所述的方法,其特征在于,其中单个病人的所有数据存储为一个单独的JSON存储格式。
4.根据权利要求1所述的方法,其特征在于,其中数据处理为包括清洗,合并,转换和统计的完整数据处理流程。
5.根据权利要求1所述的方法,其特征在于,其中对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中包括:
对增量数据进行数据处理以得到最终需要写入数据库或者索引的新数据;
删除数据库或者索引中所有发生数据变更的病人的数据;以及
将新数据写入数据库或者索引。
6.根据权利要求5所述的方法,其特征在于,其中对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中还包括:记录所有发生数据变更的病人的ID。
7.根据权利要求1或6所述的方法,其特征在于,还包括:当数据更新失败时,进行数据回滚流程,其中数据回滚流程包括:
删除数据库或者索引中所有发生数据变更的病人的ID;以及
将所有发生数据变更的病人在数据更新前的数据写入数据库或者索引。
8.一种增量医疗数据更新系统,其特征在于,所述系统包括:
全量数据模块,用于将发生数据变更的病人的所有历史数据作为该病人的新的全量数据;
增量数据模块,用于将所有发生数据变更的病人的新的全量数据作为此次更新的增量数据;以及
数据处理及写入模块,用于对增量数据进行数据处理以得到最终需要写入数据库或者索引的数据并写入数据库或者索引中。
9.一种计算机可读存储介质,其上存储有计算机程序,其特征在于,该程序被处理器执行时实现权利要求1-7任一项所述的方法步骤。
10.一种电子设备,其特征在于,包括:
一个或多个处理器;
存储装置,用于存储一个或多个程序,当所述一个或多个程序被所述一个或多个处理器执行时,使得所述一个或多个处理器实现如权利要求1-7中任一项所述的方法步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811334183.5A CN109471866B (zh) | 2018-11-09 | 2018-11-09 | 增量医疗数据更新方法及系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201811334183.5A CN109471866B (zh) | 2018-11-09 | 2018-11-09 | 增量医疗数据更新方法及系统 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN109471866A true CN109471866A (zh) | 2019-03-15 |
CN109471866B CN109471866B (zh) | 2021-10-22 |
Family
ID=65672125
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201811334183.5A Active CN109471866B (zh) | 2018-11-09 | 2018-11-09 | 增量医疗数据更新方法及系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN109471866B (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110209636A (zh) * | 2019-06-11 | 2019-09-06 | 全国公民身份证号码查询服务中心 | 一种数据维护方法、装置、系统及存储介质 |
CN111028931A (zh) * | 2019-12-11 | 2020-04-17 | 医渡云(北京)技术有限公司 | 医疗数据处理方法及装置、电子设备、存储介质 |
CN111198893A (zh) * | 2019-12-31 | 2020-05-26 | 南京医睿科技有限公司 | 一种数据更新方法、装置、可读介质及电子设备 |
CN111767284A (zh) * | 2020-06-23 | 2020-10-13 | Oppo(重庆)智能科技有限公司 | 数据处理方法、装置、存储介质和服务器 |
CN113488184A (zh) * | 2021-07-07 | 2021-10-08 | 天津开心生活科技有限公司 | 录入数据的方法及装置、计算机可读存储介质和电子设备 |
CN116959656A (zh) * | 2023-08-18 | 2023-10-27 | 成都医星科技有限公司 | 基于es的医疗主索引抽取合并方法及系统 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN104834700A (zh) * | 2015-04-27 | 2015-08-12 | 南京邮电大学 | 一种基于轨迹变更的移动数据增量捕获方法 |
CN107977396A (zh) * | 2014-11-12 | 2018-05-01 | 华为技术有限公司 | 一种KeyValue数据库的数据表的更新方法与表数据更新装置 |
Family Cites Families (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN102339315B (zh) * | 2011-09-30 | 2014-11-19 | 亿赞普(北京)科技有限公司 | 一种广告数据的索引更新方法和系统 |
CN103796041A (zh) * | 2013-11-01 | 2014-05-14 | 中兴通讯股份有限公司 | 一种iptv系统的更新方法及装置 |
CN104090889B (zh) * | 2013-12-12 | 2016-01-13 | 深圳市腾讯计算机系统有限公司 | 数据处理方法及系统 |
CN108322492B (zh) * | 2017-01-16 | 2021-09-17 | 医渡云(北京)技术有限公司 | 医疗数据同步方法及装置 |
-
2018
- 2018-11-09 CN CN201811334183.5A patent/CN109471866B/zh active Active
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107977396A (zh) * | 2014-11-12 | 2018-05-01 | 华为技术有限公司 | 一种KeyValue数据库的数据表的更新方法与表数据更新装置 |
CN104834700A (zh) * | 2015-04-27 | 2015-08-12 | 南京邮电大学 | 一种基于轨迹变更的移动数据增量捕获方法 |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110209636A (zh) * | 2019-06-11 | 2019-09-06 | 全国公民身份证号码查询服务中心 | 一种数据维护方法、装置、系统及存储介质 |
CN111028931A (zh) * | 2019-12-11 | 2020-04-17 | 医渡云(北京)技术有限公司 | 医疗数据处理方法及装置、电子设备、存储介质 |
CN111028931B (zh) * | 2019-12-11 | 2023-08-22 | 医渡云(北京)技术有限公司 | 医疗数据处理方法及装置、电子设备、存储介质 |
CN111198893A (zh) * | 2019-12-31 | 2020-05-26 | 南京医睿科技有限公司 | 一种数据更新方法、装置、可读介质及电子设备 |
CN111198893B (zh) * | 2019-12-31 | 2023-05-02 | 医渡云(北京)技术有限公司 | 一种数据更新方法、装置、可读介质及电子设备 |
CN111767284A (zh) * | 2020-06-23 | 2020-10-13 | Oppo(重庆)智能科技有限公司 | 数据处理方法、装置、存储介质和服务器 |
CN111767284B (zh) * | 2020-06-23 | 2023-11-21 | Oppo(重庆)智能科技有限公司 | 数据处理方法、装置、存储介质和服务器 |
CN113488184A (zh) * | 2021-07-07 | 2021-10-08 | 天津开心生活科技有限公司 | 录入数据的方法及装置、计算机可读存储介质和电子设备 |
CN113488184B (zh) * | 2021-07-07 | 2023-09-22 | 天津开心生活科技有限公司 | 录入数据的方法及装置、计算机可读存储介质和电子设备 |
CN116959656A (zh) * | 2023-08-18 | 2023-10-27 | 成都医星科技有限公司 | 基于es的医疗主索引抽取合并方法及系统 |
CN116959656B (zh) * | 2023-08-18 | 2024-04-23 | 成都医星科技有限公司 | 基于es的医疗主索引抽取合并方法及系统 |
Also Published As
Publication number | Publication date |
---|---|
CN109471866B (zh) | 2021-10-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN109471866A (zh) | 增量医疗数据更新方法及系统 | |
US10878064B2 (en) | Clinical data management system | |
CN103914526B (zh) | 一种用于sap erp系统与oracle erp系统的接口方法和装置 | |
US10108917B2 (en) | Metadata-driven audit reporting system | |
CN108573006A (zh) | 跨机房数据同步系统、方法及装置、电子设备 | |
US11276495B2 (en) | Systems and methods for predicting multiple health care outcomes | |
US20130311483A1 (en) | Method and system for accurate medical-code translation | |
US20230018975A1 (en) | Monolith database to distributed database transformation | |
CN106933859B (zh) | 一种医疗数据的迁移方法和装置 | |
CN109299200A (zh) | 将数据模型转换为数据库的方法、装置及设备 | |
US10055545B2 (en) | System and method for master data management | |
US10657115B2 (en) | Methods and apparatuses for improved data modeling using a relational database management system | |
JP2011258122A (ja) | データ転送装置及びデータ転送方法及びデータ転送プログラム及びデータ連携システム | |
CN106648840A (zh) | 事务之间的时序确定方法和装置 | |
CN114218193A (zh) | 数据迁移方法、装置、计算机设备和可读存储介质 | |
CN109800069A (zh) | 一种实现数据治理的方法及装置 | |
US11768996B2 (en) | Rapid reconciliation of errors and bottlenecks in data-driven workflows | |
CN110637293A (zh) | 数据分析系统中搜索查询的验证 | |
Kalvit | Application of an innovative MBSE (SysML-1D) co-simulation in healthcare | |
US20230153731A1 (en) | Data Validation and Master Network Techniques | |
CN114860819A (zh) | 商业智能系统的构建方法、装置、设备和存储介质 | |
WO2014114761A1 (en) | Data management system | |
Sharma et al. | CONSENSUS: a Shiny application of dementia evaluation and reporting for the KU ADC longitudinal Clinical Cohort database | |
CN113223677A (zh) | 针对患者的医生匹配方法及装置 | |
Duggal et al. | Forecasting disease trajectories in critical illness: comparison of probabilistic dynamic systems to static models to predict patient status in the intensive care unit |
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 | ||
GR01 | Patent grant | ||
GR01 | Patent grant |