CN116010941A - 一种基于沙箱的多中心医学队列构建系统及方法 - Google Patents
一种基于沙箱的多中心医学队列构建系统及方法 Download PDFInfo
- Publication number
- CN116010941A CN116010941A CN202310313579.6A CN202310313579A CN116010941A CN 116010941 A CN116010941 A CN 116010941A CN 202310313579 A CN202310313579 A CN 202310313579A CN 116010941 A CN116010941 A CN 116010941A
- Authority
- CN
- China
- Prior art keywords
- sandbox
- request
- user
- end processor
- module
- 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
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种基于沙箱的多中心医学队列构建系统及方法,该系统包括中心机与若干前置机;中心机用于接收用户请求、执行管理控制等,部署在云端;前置机部署在医疗机构内部,与医疗机构的医疗信息系统连接,用于进行用户请求解析、查询、计算等。本发明利用沙箱对不同的用户进行隔离,提高安全性;医疗隐私数据的队列统计、计算等完全在沙箱内部进行,防止数据泄露;对沙箱可使用的资源进行限制,合理规划不同任务的运行资源,避免硬件资源被某个用户的单一任务消耗殆尽而影响到其他用户的其他任务。
Description
技术领域
本发明属于医疗信息技术领域,尤其涉及一种基于沙箱的多中心医学队列构建系统及方法。
背景技术
队列研究是一种在医学研究中常用的研究方法,其基本原理是在一个特定人群中选择所需的研究对象,根据某个时期是否暴露于某个待研究的危险因素,或其不同的暴露水平而将研究对象分成不同的组,如暴露组和非暴露组,高剂量暴露组和低剂量暴露组等,随访观察一段时间,检查并登记各组人群待研究的预期结局的发生情况,比较各组结局的发生率,从而评价和检验危险因素与结局的关系。研究者在筛选研究人群时,需要根据研究因素或者研究目的制定一些特定的人群筛选规则,同时需要结合医疗数据的结构或者内容,转化成可执行的筛选方案。
随着国内医疗信息化水平的提高,各家医疗机构中心建立起了自己的医院信息系统、电子病历系统、影像采集与传输系统等,有的医院还建立起了临床数据中心,医疗信息的电子化为医院管理、病人服务及临床科研都提供了很大的便利。基于统一标准化的医疗数据,已经有医院开始建立了自己的医学队列研究系统,队列研究系统可以基于单中心或者多中心,基于多中心的队列研究系统,可以将队列研究方案很方便地复制并应用于多个医院中去,为多中心的医学研究提供了很大的便利。
沙箱是一种虚拟的系统程序,沙箱技术创造了一个独立的作业环境,在其内部运行的程序不会对硬盘产生永久性的影响,相当于一个隔离的程序运行环境,可以提高数据访问的安全性。另外,结合操作系统对沙箱环境的限制,可以对单个沙箱赋予独立的资源环境,保证沙箱与沙箱之间做到资源上的隔离。
现有的基于多中心的医学队列系统在构建医学队列时,会设置一个中心机,用来收集用户请求,然后会在不同的医院内部设置前置机,前置机通过连接院内的医疗数据库,把各自医院的数据转化成符合OMOP(observational medical outcomes partnership)cdm(common data model)标准术语体系的数据,前置机的应用服务器执行校验、查询、计算、存储等操作,中心机与前置机通过专网连接,将队列构建的请求分发到前置机,前置机执行参数校验、解析、数据库查询、模型计算等操作后,将结果返回给中心机。现有的方案可以保证数据在医院内部流转,不会流出医院,但是也有明显的缺点,比如1、不同的用户请求在前置机上混合操作,缺乏隔离性,安全性较低;2、前置机直接接触到了医疗隐私数据,安全性较差;3、由于前置机的CPU、内存、网络等硬件资源为各进程共享使用,不同的用户请求各自运行时,会争抢CPU、内存以及数据库连接等资源,长任务可能会抢占过多的资源,导致短任务长时间得不到响应等。
发明内容
本发明的目的在于针对现有技术的不足,提供一种基于沙箱的多中心医学队列构建系统及方法。
本发明的目的是通过以下技术方案实现的:
根据本说明书的第一方面,提供一种基于沙箱的多中心医学队列构建系统,该系统包括中心机,以及与所述中心机连接的若干部署在医疗机构内部的前置机;
所述中心机用于设置用户的优先级及权限编码,接收用户请求,构造出符合用户医学队列构建需求的JSON字符串,通过路由规则发送给对应的前置机;
所述前置机用于对接收的用户请求进行校验,校验通过后将请求划分到以用户标识为索引的缓冲池中,每个缓冲池具有对应的沙箱;每隔设定时间从缓冲池挑选出一个请求进行执行;根据条件因子与沙箱分类的关系建立决策树模型,将请求进行分解,根据决策树模型得到请求对应的沙箱分类,确定执行请求的沙箱;将请求拆分为若干中间业务过程,在沙箱中按顺序执行。
进一步地,所述中心机包括以下模块:
权限控制模块:用于对不同用户设置不同的优先级及权限编码,所述权限编码用于控制不同用户在前置机上能够执行的数据类型和操作类型;
业务请求构造模块:根据用户请求中的业务参数,结合优先级、权限编码以及加密机制,构造出用户请求对应的JSON字符串;
路由模块:中心机为每个前置机分配前置机id,请求需要进行路由选择时,根据用户标识找到前置机id,根据前置机id查询网络参数构造路由地址;
业务请求发送模块:用于将业务请求构造模块构造的请求根据路由模块得到的路由地址发送给用户对应的前置机。
进一步地,所述业务请求构造模块具体为:
将用户请求中的业务参数转化成结构化数据并存储在中心机数据库中;
取出业务参数的结构化数据,将结构化数据转化成JSON字符串,向JSON字符串中添加用户标识、请求id、优先级和权限编码,形成新的JSON字符串并对新的JSON字符串通过MD5加密算法得到消息摘要,将消息摘要添加到新的JSON字符串中,形成请求对应的JSON字符串。
进一步地,所述前置机中包含校验模块,用于对接收的请求进行校验,具体为:
将对JSON字符串求MD5值得到消息摘要与JSON字符串中的消息摘要进行比对,如果不一致,则上报中心机请求异常并丢弃该请求;
进行权限校验,提取JSON字符串中的权限编码,得到各数据类型的可操作权限,将可操作权限与前置机本地服务器的已配置权限进行比对,如果可操作权限高于本地服务器的权限,则上报中心机请求异常并丢弃该请求,否则校验通过。
进一步地,所述前置机中包含请求缓冲模块,用于将请求划分到缓冲池中,具体为:
前置机预设缓冲池的最大数量N,以及每个缓冲池最多缓存的请求数量M;
新请求到达时,根据用户标识进行索引,确认待划分的缓冲池,
如果该用户没有对应的缓冲池,则判断缓冲池的数量是否超过N个,如果超过N个则拒绝请求并上报给中心机告警,否则创建新的缓冲池,并将该请求放入新的缓冲池的末尾;在新创建缓冲池时,同时创建对应的沙箱;
如果该用户已有对应的缓冲池,则判断该缓冲池中的请求数量是否超过M个,如果超过M个则拒绝请求并上报给中心机告警,否则将该请求放入该缓冲池的末尾。
进一步地,所述前置机中包含请求调度模块,用于从缓冲池挑选待执行请求,具体为:
统计过去一段时间内前置机服务器上运行的所有沙箱的CPU利用率、内存使用量和磁盘使用量,如果某沙箱的CPU利用率、内存使用量和磁盘使用量均小于预设百分比阈值,则标记该沙箱为可用沙箱,否则标记该沙箱为过载沙箱;
将可用沙箱对应的用户组成候选用户集合{User1,User2,...},对应的优先级数值集合为{p1,p2,...},计算出候选用户的优先级数值总和P;随机生成一个整数R,整数范围为1到P;设sum=0,i=1,若 sum<=R<=sum+pi,则Useri为可挑选的用户,否则sum=sum+pi ,i=i+1;从可挑选的用户对应的缓冲池中取出第一个请求进行执行。
进一步地,所述前置机中包含沙箱调度模块,用于确定执行请求的沙箱,具体为:
根据条件因子与沙箱分类的关系建立决策树模型,所述条件因子包括数据表大小、概念个数、单个概念的最大统计数和时间窗;所述沙箱的分类对应于沙箱能够分配的硬件资源;
将请求进行分解,根据决策树模型得到请求对应的沙箱分类;
查询用户标识与沙箱id映射表,如果能查到该用户对应的当前沙箱,且所需分配沙箱的等级小于等于当前沙箱的等级,则将该请求分配到当前沙箱中去执行计算;否则按照所需分配沙箱的等级新建沙箱,将该请求分配到新建沙箱中去执行计算,并更新用户标识与沙箱id映射表,将原沙箱标记为可销毁沙箱;
新建沙箱时,根据决策树模型的沙箱分类结果,对沙箱所能利用的硬件资源进行限制。
进一步地,所述前置机中包含沙箱执行模块,用于在沙箱内部进行请求的计算,包括:
将请求的业务参数中的纳入规则和结局规则的多个并列条件按顺序拆分,得到若干中间业务过程,对每个业务过程按顺序编号,赋予不同的步骤id;
按照中间业务过程的顺序依次执行数据库查询或者计算;
每个中间业务过程的结果均保存到中间结果文件中;
查找该请求对应的元数据文件,如果元数据文件不存在,则新生成一个元数据文件,用于记录当前已执行步骤的标志信息,如果元数据文件已经存在,则在已生成好的元数据文件中,追加记录当前的中间业务过程已完成。
进一步地,所述前置机中包含沙箱管理模块,具体为:
在设定时间对沙箱进行检查及记录,如果第一次检查时,某沙箱没有请求在运行,则该沙箱标记为空闲;第二次检查时,如果已标记为空闲的沙箱,还是没有请求在运行,则标记为可销毁;第三次检查时,如果已标记为可销毁的沙箱,仍然没有请求在运行,则直接销毁该沙箱;
记录每个沙箱自新建以来的利用效率,如果每一次请求所需沙箱的等级和实际运行任务时的沙箱等级不匹配的比例超过阈值,则将该沙箱标记为可销毁沙箱;在下一次检查时,如果该沙箱没有请求在运行,则直接销毁该沙箱,同时新建一个低一级的沙箱替换掉原沙箱。
根据本说明书的第二方面,提供一种基于沙箱的多中心医学队列构建方法,该方法包括:
部署一个中心机和与该中心机通过专网连接的若干前置机,各前置机部署在在医疗机构内部,与医疗机构的医疗信息系统连接;
中心机对不同用户设置不同的优先级及权限编码;
中心机接收用户的队列构建请求,构造出符合用户医学队列构建需求的JSON字符串,通过路由规则发送给对应的前置机;
前置机对接收的中心机发送的用户请求进行校验,校验通过后将请求划分到以用户标识为索引的缓冲池中,每个缓冲池具有对应的沙箱;
前置机每隔设定时间从缓冲池挑选出一个请求进行执行;
前置机根据条件因子与沙箱分类的关系建立决策树模型,将请求进行分解,根据决策树模型得到请求对应的沙箱分类,确定执行请求的沙箱;
前置机将请求拆分为若干中间业务过程,在沙箱中按顺序执行。
本发明的有益效果是:1、利用沙箱对不同的用户进行隔离,提高安全性;2、医疗隐私数据的队列统计、计算等完全在沙箱内部进行,防止数据泄露;3、对沙箱可使用的资源进行限制,合理规划不同任务的运行资源,避免硬件资源被某个用户的单一任务消耗殆尽而影响到其他用户的其他任务。
附图说明
图1为一示例性实施例示出的基于沙箱的多中心医学队列构建系统部署图;
图2为一示例性实施例示出的基于沙箱的多中心医学队列构建系统结构图;
图3为一示例性实施例示出的某时刻的缓冲池示意图;
图4为一示例性实施例示出的某时刻的缓冲池请求队列示意图;
图5为一示例性实施例示出的决策树模型结构图。
具体实施方式
为使本发明的上述目的、特征和优点能够更加明显易懂,下面结合附图对本发明的具体实施方式做详细的说明。
在下面的描述中阐述了很多具体细节以便于充分理解本发明,但是本发明还可以采用其它不同于在此描述的其它方式来实施,本领域技术人员可以在不违背本发明内涵的情况下做类似推广,因此本发明不受下面公开的具体实施例的限制。
本发明提供一种基于沙箱的多中心医学队列构建系统,该系统的部署图如图1所示,包括中心机和前置机,中心机用来接收用户请求、执行管理控制等,部署在云端,系统中只部署一个中心机,中心机包含若干功能模块;前置机与中心机通过专网连接,可以接收来自中心机的请求,前置机部署在医疗机构内部,与医疗机构的医疗信息系统连接,可以访问到医疗机构的数据库,前置机也包含若干功能模块,用来进行用户请求解析、查询、计算等。一个中心机可以与多个前置机进行连接,一个用户的请求可以进行路由选择到某个前置机上进行运算。用户的业务请求即队列构建请求。
如图2所示,中心机包含有权限控制模块、业务请求构造模块、路由模块和业务请求发送模块;前置机包含有校验模块、请求缓冲模块、请求调度模块、沙箱调度模块、沙箱执行模块、沙箱管理模块和报警模块。在以下实施例中,详细说明中心机和前置机中各功能模块的实现过程。
一、中心机上各功能模块具体如下:
1、权限控制模块
中心机的权限控制模块,通过规则配置,对不同的用户设置不同的优先级,优先级较高的用户的请求,在前置机上有可能优先执行,优先级较低的用户的请求,则在前置机上更有可能延后执行,优先级数值越大,代表优先级越高。
同时针对不同的用户设置不同的权限编码,用于控制不同的用户在前置机上可以执行的数据类型和操作类型,包括{诊断数据:可读可写;手术数据:可读可写;用药数据:可读可写;医学检查数据:可读可写;患者信息数据:可读可写;医学概念数据:可读可写;就诊数据:可读可写}。
用户权限表部分举例如下:
表1 用户权限表结构
2、业务请求构造模块
用户通过系统UI界面上的选择框输入业务请求的业务参数,首先将业务参数转化成关系型数据库的结构化数据并存储在中心机的数据库中,然后,业务请求构造模块取出业务参数的结构化数据,使用通用的JSON库将结构化数据转化成JSON字符串,然后,向JSON字符串中添加用户标识、请求id、优先级、权限编码,形成新的JSON字符串并对新的JSON字符串通过MD5加密算法得到消息摘要,将消息摘要添加到新的JSON字符串中,形成业务请求对应的JSON字符串。其中,用户标识可以是用户的id,请求id可以是当前的时间戳,优先级由管理员进行配置,权限编码为用户可执行的数据类型和操作类型。
3、路由模块
中心机与前置机通过专网连接,前置机服务器在启动时,向中心机发送消息,将自己的服务器名、IP、端口等网络参数传给中心机,中心机在数据库中记录下这些网络参数,并为每一个前置机分配一个前置机id。中心机上的每一个非管理员用户,都对应于一个前置机id,用户与前置机id的映射关系由管理员配置。当业务请求需要进行路由选择的时候,首先根据用户标识找到对应的前置机id,然后根据前置机id查出对应的网络参数,从而构造出正确的路由地址。
4、业务请求发送模块
中心机的业务请求根据路由模块得到的路由地址,将业务请求构造模块构造的请求通过HTTPS接口的方式发送给用户对应的前置机。
二、前置机上各功能模块具体如下:
1、校验模块
前置机收到中心机的业务请求后,校验模块首先对业务请求进行检查。首先,对JSON字符串求MD5值,得到消息摘要,将这个消息摘要与JSON字符串中的消息摘要进行比对,如果不一致,则上报中心机请求异常并丢弃这个业务请求;然后,进行权限的校验,提取出JSON字符串中的权限编码,得到各个数据类型的可操作权限,将这个可操作权限与前置机本地服务器的已配置权限进行比对,如果可操作权限高于本地服务器的权限,比如请求中的可操作权限为{“诊断数据”:“可读可写”},但本地服务器的权限为“诊断数据”仅可读,则认为请求中的可操作权限高于本地服务器的权限,则上报中心机请求异常并丢弃这个业务请求;否则进行下一步,将请求交给请求缓冲模块,由请求缓冲模块放置入缓冲池中。
2、请求缓冲模块
前置机上预设缓冲池的最大数量记为N,每个缓冲池以用户标识为索引,每个缓冲池预设最多缓存的请求数量记为M。新的请求到达时,先根据用户标识进行索引,确认划分到哪个缓冲池,如果该用户没有对应的缓冲池,先判断缓冲池的数量是否超过N个,如果超过N个,则拒绝请求并上报给中心机告警;如果没有超过N个,则创建一个新的缓冲池,并将该请求放入这个新的缓冲池的末尾;如果该用户已有对应的缓冲池,则判断该缓冲池中的请求数量是否超过M个,如果该缓冲池中的请求数量已经超过M个,则拒绝请求并上报给中心机告警,如果请求数量没有超过M个,则将该请求放入该缓冲池的末尾。
在新创建缓冲池时,同时创建对应的沙箱,沙箱执行的某请求由请求调度模块决定,沙箱的大小由沙箱调度模块决定。
例如某一时刻前置机上的缓冲池如图3所示,预设N=4,M=5,若此时中心机向这个前置机发送用户1的请求,则因为用户1缓冲池中的请求数量已达到预设值,前置机直接向中心机机告警;若此时中心机向这个前置机发送用户2的请求,因为用户2的缓冲池中的请求数量未达到预设值,则用户2的请求可以直接放入缓冲池的末尾;若此时中心机向这个前置机发送用户5的请求,因为用户5尚未建立对应的缓冲池,且缓冲池的数量已经达到预设值,因此不能为用户5建立缓冲池,前置机向中心机告警并丢弃请求,记录下丢弃数量。
3、请求调度模块
请求调度模块每隔预设的固定间隔时间(例如10分钟),从请求缓冲池挑选出一个请求。
首先,请求调度模块统计过去一段时间内(例如5分钟)前置机服务器上运行的所有沙箱的CPU利用率、内存使用量、磁盘使用量,如果某沙箱的CPU利用率、内存使用量、磁盘使用量均小于预设的百分比阈值,则标记该沙箱为可用沙箱,否则标记该沙箱为过载沙箱。
然后,将可用沙箱对应的用户组成候选用户集合{User1,User2,...},对应的优先级数值集合为{p1,p2,...},计算出候选用户的优先级数值总和P。随机生成一个整数R,整数范围为1到P。设sum=0,i=1,若 sum<=R<=sum+pi,则Useri为可挑选的用户,否则sum=sum+pi ,i=i+1。
最后,从可挑选的用户对应的缓冲池中取出第一个请求,交给沙箱调度模块进行调度。
4、沙箱调度模块
沙箱调度模块事先根据数据表大小、概念个数、单个概念的最大统计数、时间窗等条件因子与沙箱分类的关系,建立决策树模型,输出结果为沙箱的分类,分别有特大、大、中、小,沙箱的分类对应于沙箱能够分配的硬件资源,特大沙箱可以分配的硬件资源相对最多,小沙箱可以分配的硬件资源相对最少。条件因子还可以包含年龄范围等。
具体地,数据表大小是指数据库存储的表行数;概念个数是指业务请求中纳入规则和结局规则中涉及到的医学概念个数;单个概念的最大统计数是指纳入规则和结局规则中涉及到的多个医学概念中,某个医学概念在数据表中对应的最多的记录个数;时间窗是指纳入规则中的时间范围,比如确诊日期范围、用药日期范围等;年龄范围是指纳入规则中的患者年龄范围。
沙箱调度模块事先对前置机数据库中的各个表进行统计,得到各个表的大小、每张表中单个概念的统计数。
沙箱调度模块对业务参数的JSON字符串进行解析,分解成纳入规则+时间窗+结局规则等,从纳入规则、结局规则中解析出需要查询的数据表类型、概念id。从上述的统计表中得到纳入规则和结局规则中对应的数据表大小、每个概念在对应数据表中的统计数,计算出纳入规则和结局规则中的概念个数、单个概念的最大统计数等数值,运用事先建立好的决策树模型进行决策分类,得到该请求对应的沙箱分类。
沙箱调度模块查询用户标识与沙箱id(沙箱id可以是沙箱进程号或者是沙箱名称)的映射表,得到该用户对应的当前沙箱,如果能查到当前沙箱,且所需分配沙箱的等级小于等于当前沙箱的等级,则将该请求分配到当前沙箱中去执行计算;否则,按照所需分配沙箱的等级新建一个沙箱,将该请求分配到新的沙箱中去执行计算,并更新用户标识与沙箱id的映射表,将原沙箱标记为可销毁沙箱,若原沙箱没有请求正在运行,则直接销毁原沙箱,若原沙箱还有请求在运行,则等请求运行完后销毁原沙箱。
新建沙箱时,根据决策树模型的沙箱分类结果,使用Linux操作系统中的cgroups技术对沙箱所能利用的硬件资源进行限制,划分额定的CPU时间、内存、磁盘等硬件资源给该沙箱。
5、沙箱执行模块
沙箱执行模块负责在沙箱内部进行请求的计算。一个沙箱可以同时运行多个请求,但需满足沙箱的硬件资源条件。
第一步,将请求的业务参数分解成纳入规则、时间窗、结局规则、研究时间范围、暴露因素,其中,纳入规则中可以包含多个一级检索条件,结局规则中可以包含多个二级检索条件,一级检索条件与二级检索条件都包含有检索类型、检索字段、检索条件等检索因子。将纳入规则和结局规则的多个并列条件按顺序进行拆分,得到若干个中间业务过程,对每个业务过程按照顺序从1开始依次编号,赋予不同的步骤id;优先地,拆分顺序如下:纳入规则、时间窗、结局规则、研究时间范围、暴露因素。具体为:
①从纳入规则中提取出多个一级检索条件,其中每个一级检索条件包含检索类型、检索字段、检索条件等检索因子,对每个一级检索条件都转化为一条数据库查询的SQL。一级检索条件转化成SQL的具体方法为:以一级检索条件 {“检索类型”:“诊断”,“检索字段”:“诊断概念id”,“检索条件”:“0000123”}举例,首先,初始化SQL语句“select * fromTABLE_NAME where FIELD=‘CONDITION’”;然后,按照中心机与前置机事先约定好的检索类型与数据库表的映射字典,用检索类型的值去替换掉SQL中待填充的值,比如检索类型与数据库表的映射字典为{“诊断”:“condition_occurrence”,“用药”:“drug_exposure”,“患者”:“person”,“手术”:“operation”},则根据映射字典,用一级检索条件中的{“检索类型”:“诊断”}对应的表名“condition_occurrence”替换掉SQL语句中的TABLE_NAME,得到新的SQL:“select * from condition_occurrence where FIELD=‘CONDITION’”;接下来,按照中心机与前置机事先约定好的检索字段与数据库表的映射字典,用检索字段的值去替换掉SQL中待填充的值,比如检索字段与数据库表的映射字典为{“诊断概念id”:“condition_concept_id”,“用药概念id”:“drug_concept_id”,“诊断年龄”:“age”,},用一级检索条件中的{“检索字段”:“诊断概念id”}对应的字段名“condition_concept_id”替换掉SQL语句中的FIELD,得到新的SQL:“select * from condition_occurrence where condition_concept_id=‘CONDITION’”;最后,将一级检索条件中的{“检索条件”:“0000123”}中的值“0000123”代替掉SQL中的CONDITION,得到最后的SQL:“select * from condition_occurrence where condition_concept_id=“0000123”。
②从时间窗中提取出起始时间和结束时间。
③从结局规则中提取出多个二级检索条件,其中每个二级检索条件与一级检索条件一样,也包含检索类型、检索字段、检索条件等检索因子,对每一个二级检索条件都转化为一条数据库查询的SQL,具体的转化方法与一级检索条件的转化方法相同。二级检索条件的转化过程与一级检索条件的转化过程,可以使用相同的映射字典。
④从研究时间范围提取出起始时间和结束时间。
⑤提取出暴露因素。
⑥从纳入规则、结局规则中转化的多条SQL语句即构成一系列的中间业务过程,每一条SQL语句即为一个中间业务过程,时间窗的起始时间和结束时间对应一个中间业务过程,表示对纳入规则的结果按照时间进行过滤,研究时间范围的起始时间和结束时间也对应一个中间业务过程,表示对结局规则的结果按照时间进行过滤,暴露因素对应一个中间业务过程,表示按照暴露因素进行过滤,按照纳入规则、时间窗、结局规则、研究时间范围、暴露因素的顺序,将从中提取转化出来的各个中间业务过程依次排列,并在中间插入适当的中间计算过程以减少后面步骤的查询数量或者计算数量,比如在纳入规则的多条SQL语句之后紧接着插入一个求交集的中间业务过程等。对所有的中间业务过程从1开始依次编号。
第二步,按照中间业务过程的顺序依次执行数据库查询或者计算。
第三步,每个中间业务过程的结果都保存到中间结果文件中,中间结果文件以“用户标识+请求id +步骤id+当前时间戳”命名。
第四步,查找该请求对应的元数据文件,元数据文件与中间结果文件分别放在不同的目录下,元数据文件以“用户标识+请求id”为文件名,如果元数据文件不存在,则新生成一个元数据文件,用于记录当前已执行步骤的标志信息,比如在元数据文件中记录“步骤1已完成”,标志步骤1已完成查询或者计算且步骤1的结果已经保存到中间结果文件中;如果元数据文件已经存在,则在已生成好的元数据文件中,追加记录当前的中间业务过程已完成,比如在元数据文件中记录“步骤2已完成”,标志步骤2已完成查询或者计算且步骤2的结果已经保存到中间结果文件中。元数据文件的记录可以方便异常处理模块重复利用已有的数据,由于有些请求的执行过程较复杂,中间有可能会因为网络、磁盘等原因而导致请求未能顺利执行完,如果出现中途报错的情况,则将该请求标记为异常请求,交给异常处理模块。如果业务过程顺利执行完,则将结果回传到中心机,用户可以在中心机上查看到最后的结果统计。
6、异常处理模块
异常处理模块每次处理异常请求时,执行如下过程:
第一步,将请求的业务参数分解成纳入规则、研究时间范围、时间窗、结局规则,将纳入规则和结局规则的多个并列条件按顺序进行拆分,得到若干个中间业务过程,对每个业务过程按照顺序从1开始依次编号,赋予不同的步骤id,保证得到的中间业务过程以及顺序编号与沙箱执行模块中第一步得到的中间业务过程以及顺序编号完全一样;拆分规则相同。
第二步,在元数据文件所在的目录下查询该请求对应的元数据文件,元数据文件以“用户表示+请求id”为文件名,找到标志信息的最后一行,比如最后一行为“步骤4已完成”,则表示该步骤4已完成,且步骤4后面步骤的执行过程出现异常。
第三步,扫描该请求已有的中间结果文件,如果异常步骤之前的所有中间结果文件都存在,则直接从异常的步骤开始,重新计算;如果其中有中间结果文件丢失,则清空元数据文件,从头开始计算。
举例假设,第一步得到中间业务过程为{步骤1、步骤2、步骤3、步骤4、步骤5、步骤6},第二步通过查询元数据文件,发现步骤4已完成,则表示步骤5在执行过程中出现异常,第三步扫描中间结果文件,查看步骤1~步骤4 的中间结果文件是否都存在,如果都存在,则按照沙箱执行模块的方法,继续执行步骤5和步骤6,并将步骤5和步骤6的结果保存在中间结果文件中,并更新元数据文件。如果步骤1~步骤4的中间结果文件有任何一个缺失,则直接清空元数据文件,并从步骤1开始重新执行,并生成中间结果文件,再更新元数据文件。异常处理模块处理请求时,如果再次发生异常,则直接清空对应的元数据文件和中间结果文件,并上报给中心机告警。
7、沙箱管理模块
沙箱管理模块每隔固定的时间会进行检查,记录下每个沙箱的CPU利用率、内存使用率、磁盘使用率、磁盘IO、正在运行的请求数等指标,如果第一次检查时,某沙箱没有请求在运行,则该沙箱标记为空闲;第二次检查时,如果已标记为空闲的沙箱,还是没有请求在运行,则标记为可销毁;第三次检查时,如果已标记为可销毁的沙箱,仍然没有请求在运行,则直接销毁该沙箱,并找到用户标识<-->沙箱id映射表的对应项,将该对应项删除。如果检查时,沙箱有请求在运行,则直接将沙箱标记为正常。
同时,沙箱管理模块会记录下每个沙箱自新建以来的利用效率,比如每一次队列构建请求所需沙箱的等级和实际运行任务时的沙箱等级,如果不匹配的比例超过一定的阈值,则将该沙箱标记为可销毁沙箱。沙箱管理模块在下一次检查时,如果该沙箱没有请求在运行,则直接销毁该沙箱,同时新建一个低一级的沙箱,同时更新用户标识<-->沙箱id映射表,用低一级的沙箱id代替原沙箱id。
8、报警模块
请求缓冲池中丢弃的业务请求数量超过阈值时,报警模块会向中心机发送报警消息,提示丢弃请求过多,管理员根据提示检查前置机硬件资源或者请求的合理性。
以下描述一种基于沙箱的多中心医学队列构建系统的示例性实施过程,假设用户A想要构建一个多中心医学队列,要求如下:
确诊时间在2010-01-01到2011-01-01之间,诊断年龄在20-60岁之间,服用过格列美脲的2型糖尿病患者,分成吸烟组与不吸烟组,分别统计两个组中在十年内做过胃切除术的患者。
一、中心机
1、权限控制模块通过读取权限表,得到用户A的权限编码为{诊断数据:可读可写;手术数据:可读可写;用药数据:可读可写;医学检查数据:可读可写;患者信息数据:可读;医学概念数据:可读;就诊数据:可读},优先级为3。
2、业务请求构造模块,将UI请求的业务参数,保存到关系型数据库中,再把这些参数转化成纳入规则、时间窗、暴露因素、结局规则、研究时间范围等,上述队列的参数可以转化成如下形式:
表2 请求参数分解表
以上参数再转化成JSON格式的字符串,并添加用户标识、请求id、优先级、数据权限编码、消息摘要等数据,得到完整的业务请求参数,其中中间涉及到的医学概念,需要通过查找医学概念数据表进行转化,比如通过查找医学概念数据表,得到“2型糖尿病”的概念id为“0000123”、“格列美脲”的概念id为“0000258”、“胃切除术”的概念id为“0000369”,通过查找用户表,得到用户A的用户标识为“00000A”。得到完整的业务请求参数如下:
表3 用户请求对应的JSON字符串
3、路由模块,首先根据用户标识找到对应的前置机id,然后根据前置机id查出对应的网络参数,从而构造出正确的路由地址。
4、业务请求发送模块,中心机的业务请求根据路由模块得到的路由地址,将业务请求构造模块构造的请求通过HTTPS接口的方式发送给用户对应的前置机。
二、前置机
1、校验模块
前置机收到中心机的请求后,校验模块首先对业务请求进行检查。首先,
对JSON字符串求MD5值,得到消息摘要,将这个消息摘要与JSON字符串中的消息摘要进行比对,如果不一致,则上报中心机请求异常并丢弃这个业务请求;然后,进行权限的校验,提取出JSON字符串中的权限编码,得到各个数据类型的可操作权限,将这个可操作权限与前置机本地服务器的已配置权限进行比对,如果可操作权限高于本地服务器的权限,则上报中心机请求异常并丢弃这个业务请求;否则进行下一步,将请求交给请求缓冲模块,由请求缓冲模块放置入缓冲池中。
2、请求缓冲模块
假设前置机上的缓冲池如图4所示,预设缓冲池最大数量N为4,每个缓冲池最多缓存的请求数量M为5,此时中心机向这个前置机发送用户A的请求,此时只有3个缓冲池,又因为用户A尚未建立对应的缓冲池,于是创建一个新的缓冲池,并把该请求放入这个新的缓冲池的末尾,这个新的缓冲池以用户A的标识作为索引。同时,为用户A的缓冲池创建一个对应的沙箱,沙箱执行的某请求由请求调度模块决定,沙箱的大小由沙箱调度模块决定。
3、请求调度模块
请求调度模块每隔预设的固定间隔时间(例如10分钟),从请求缓冲池挑选出一个请求。
首先,请求调度模块统计过去一段时间内(例如5分钟)前置机服务器上运行的所有沙箱的CPU利用率、内存使用量、磁盘使用量,如果某沙箱的CPU利用率、内存使用量、磁盘使用量均小于预设的百分比阈值,则标记该沙箱为可用沙箱,否则标记该沙箱为过载沙箱。
然后,将可用沙箱对应的用户组成候选用户集合{User1,User2,...},对应的优先级数值集合为{p1,p2,...},计算出候选用户的优先级数值总和P。随机生成一个整数R,整数范围为1到P。设sum=0,i=1,若 sum<=R<=sum+pi,则Useri为可挑选的用户,否则sum=sum+pi ,i=i+1。
最后,从可挑选的用户对应的缓冲池中取出第一个请求,交给沙箱调度模块进行调度。
比如,用户A请求调度的时候,前置机上存在4个缓冲池,对应用户A、用户B、用户C、用户D,每个用户的沙箱的过去5分钟内硬件使用量及优先级如下表所示,其中预设CPU利用率阈值90%,内存使用量阈值 80%,磁盘使用量阈值80%;
表4 某时刻各沙箱的硬件资源利用统计表
其中,用户C的内存使用量超过预设的使用量阈值,因此对应的沙箱3被标记为过载沙箱,其余的沙箱被标记为可用沙箱。可用沙箱对应的用户组成候选用户集合{用户A,用户B,用户D},对应的优先级数值集合为{3,1,1},计算优先级数值总和为5。随机生成一个整数,范围为1-5。假设生成的整数小于等于3,则用户A为可挑选的用户;假设生成的整数等于4,则用户B即为可挑选的用户;假设生成的整数等于5,则用户D即为可挑选的用户。本实施例中,生成的整数为2,则用户A为可挑选的用户。最后,从用户A对应的缓冲池中取出第一个请求,交给沙箱调度模块进行调度。
4、沙箱调度模块
沙箱调度模块事先根据数据表大小、概念个数、单个概念的最大统计数、时间窗等条件因子与沙箱分类的关系,建立决策树模型,输出结果为沙箱的分类,分别有特大、大、中、小,沙箱的分类对应于沙箱能够分配的硬件资源,特大沙箱可以分配的硬件资源相对最多,小沙箱可以分配的硬件资源相对最少。条件因子还可以包含年龄范围等。
前置机建立好的决策树模型部分如图5所示。在图5的示例中,以“最大数据表大小”节点为根节点,根据根节点的值分成四个分支,分别为“>1亿”、“>5000万”、“>1000万”、“<1000万”;在“最大数据表大小”<1000万的分支中,以“概念个数”节点的值分成三个分支,分别为“<5”、“<10”、“>=10”;在“概念个数”<5的分支中,以“单个概念的最大统计数”节点的值分成四个分支,分别为“>30万”、“>=10万”、“>=1万”、“<1万”;在“单个概念的最大统计数”>=10万的分支中,以“时间窗”节点的值分成四个分支,分别为“>=1年”、“>6个月”、“>1个月”、“<1个月”;在“时间窗”>=1年的分支中,以“年龄范围”的值最后分成四个分类,分别是“年龄范围”无限制为“中”、“年龄范围”>20岁为“中”、“年龄范围”>10岁为“中”、“年龄范围”<10岁为“小”。
根据前置机的硬件资源情况以及实际使用需求,对每种沙箱能分配的硬件资源可以做如下配置:
表5 各沙箱分类的可分配硬件资源配置表
沙箱调度模块事先对前置机数据库中的各个表进行统计,得到各个表的大小、每张表中单个概念的统计数,比如如下的统计:
表6 各个表的数据量统计表
表7 各个概念的数据量统计表
沙箱调度模块将业务参数分解成纳入规则、暴露因素、研究时间范围、时间窗、结局规则等,用户A的请求可以分解成如表2所示的形式。
前置机根据以上规则,解析出请求需要查找的数据表为{诊断表、用药表、手术表},各个数据表的记录数量分别为{1000000、2000000、500000},其中用药表的记录数量最多,因此,最大数据表大小即为2000000,需要查找的概念为{“2型糖尿病”、“格列美脲”、“胃切除术”},共3个概念,对应的概念id分别为{“00001”、“00002”、“00003”},各个概念对应的记录数量分别为{100000、50000、3000},3个概念中统计数最多的为“2型糖尿病”,概念id为“00001”,因此,单个概念的最大统计就是“2型糖尿病”的统计数,即100000。
根据以上查找出来的数据,进入决策树模型分析,得到最后输出的结果为“中”。因此该请求所需分配沙箱的等级为中型沙箱,其中的硬件资源为{CPU时间:3%;内存:1GB;磁盘:20GB }。
沙箱调度模块查询用户标识与沙箱id的映射表,得到该用户对应的当前沙箱,如果能查到当前沙箱,且所需分配沙箱的等级小于等于当前沙箱的等级,则将该请求分配到当前沙箱中去执行计算;否则,按照所需沙箱的等级新建一个新的沙箱,将该请求分配到新的沙箱中去执行计算,并更新用户标识与沙箱id的映射表,将原沙箱标记为可销毁沙箱,若原沙箱没有请求正在运行,则直接销毁原沙箱,若原沙箱还有请求在运行,则等请求运行完后销毁原沙箱。
用户A的请求为第一次到达前置机,因此用户标识与沙箱id的映射表查不到用户A对应的沙箱,因此需要新建一个中型沙箱来运行该请求。新建沙箱时,使用Linux操作系统中的cgroups技术对沙箱所能利用的硬件资源进行限制,划分额定的CPU时间、内存、磁盘等硬件资源给该沙箱。
5、沙箱执行模块
沙箱执行模块负责在沙箱内部进行请求的计算。
第一步,将请求的业务参数分解成纳入规则、研究时间范围、时间窗、结局规则、暴露因素等,从纳入规则和结局规则中提取出涉及到的概念id,将纳入规则和结局规则的多个并列条件按顺序进行拆分,得到若干个中间业务过程,对每个业务过程按照顺序从1开始依次编号,赋予不同的步骤id;第二步,按照中间业务过程的顺序依次执行数据库查询或者计算;第三步,每个中间业务过程的结果都保存到中间结果文件中,中间结果文件以“用户标识+请求id+步骤id+当前时间戳”为文件名;第四步,查找该请求对应的元数据文件,元数据文件与中间结果文件分别放置在不同的目录下,元数据文件以“用户标识+请求id”为文件名,如果元数据文件不存在,则新生成一个元数据文件,用于记录当前已执行步骤的标志信息,比如在元数据文件中记录“步骤1已完成”,标志步骤1已完成查询或者计算且步骤1的结果已经保存到中间结果文件中;如果元数据文件已经存在,则在已生成好的元数据文件中,追加记录当前的中间业务过程已完成,比如在元数据文件中记录“步骤2已完成”,标志步骤2已完成查询或者计算且步骤2的结果已经保存到中间结果文件中。元数据文件的记录可以方便异常处理模块重复利用已有的数据,由于有些请求的执行过程较复杂,中间有可能会因为网络、磁盘等原因而导致请求未能顺利执行完,如果出现中途报错的情况,则将该请求标记为异常请求,交给异常处理模块。如果业务过程顺利执行完,则将结果回传到中心机,用户可以在中心机上查看到最后的结果统计。
6、异常处理模块
异常处理模块每次处理异常请求时,第一步,将请求的业务参数分解成纳入规则、研究时间范围、时间窗、结局规则,将纳入规则和结局规则的多个并列条件按顺序进行拆分,得到若干个中间业务过程,对每个业务过程按照顺序从1开始依次编号,赋予不同的步骤id,保证得到的中间业务过程以及顺序编号与沙箱执行模块中第一步得到的中间业务过程以及顺序编号完全一样。第二步,在元数据文件所在的目录下查询该请求对应的元数据文件,元数据文件以“用户表示+请求id”为文件名,找到标志信息的最后一行,比如最后一行为“步骤4已完成”,则表示该步骤4已完成,且步骤4后面步骤的执行过程出现异常。第三步,扫描该请求已有的中间结果文件,如果异常步骤之前的所有中间结果文件都存在,则直接从异常的步骤开始,重新计算;如果其中有中间结果文件丢失,则清空元数据文件,从头开始计算。举例假设,第一步得到中间业务过程为{步骤1、步骤2、步骤3、步骤4、步骤5、步骤6},第二步通过查询元数据文件,发现步骤4已完成,则表示步骤5在执行过程中出现异常,第三步扫描中间结果文件,查看步骤1~步骤4 的中间结果文件是否都存在,如果都存在,则按照沙箱执行模块的方法,继续执行步骤5和步骤6,并将步骤5和步骤6的结果保存在中间结果文件中,并更新元数据文件。如果步骤1~步骤4的中间结果文件有任何一个缺失,则直接清空元数据文件,并从步骤1开始重新执行,并生成中间结果文件,再更新元数据文件。异常处理模块处理请求时,如果再次发生异常,则直接清空对应的元数据文件和中间结果文件,并上报给中心机告警。
7、沙箱管理模块
沙箱管理模块每隔固定的时间会进行检查,记录下每个沙箱的CPU利用率、内存使用率、磁盘使用率、磁盘IO、正在运行的请求数等指标,如果第一次检查时,某沙箱没有请求在运行,则该沙箱标记为空闲;第二次检查时,如果已标记为空闲的沙箱,还是没有请求在运行,则标记为可销毁;第三次检查时,如果已标记为可销毁的沙箱,仍然没有请求在运行,则直接销毁该沙箱,并找到用户标识<-->沙箱id映射表的对应项,将该对应项删除。如果检查时,沙箱有请求在运行,则直接将沙箱标记为正常。
同时,沙箱管理模块会记录下每个沙箱自新建以来的利用效率,比如每一次队列构建请求所需沙箱的等级和实际运行任务时的沙箱等级,如果不匹配的比例超过一定的阈值,则将该沙箱标记为可销毁沙箱。沙箱管理模块在下一次检查时,如果该沙箱没有请求在运行,则直接销毁该沙箱,同时新建一个低一级的沙箱,同时更新用户标识<-->沙箱id映射表,用低一级的沙箱id代替原沙箱id。
8、报警模块
请求缓冲池中丢弃的业务请求数量超过阈值时,报警模块会向中心机发送报警消息,提示丢弃请求过多,管理员根据提示检查前置机硬件资源或者请求的合理性。
本发明实施例还提供一种基于沙箱的多中心医学队列构建方法,该方法包括以下步骤:
部署一个中心机和与该中心机通过专网连接的若干前置机,各前置机部署在在医疗机构内部,与医疗机构的医疗信息系统连接;
中心机对不同用户设置不同的优先级及权限编码;
中心机接收用户的队列构建请求,构造出符合用户医学队列构建需求的JSON字符串,通过路由规则发送给对应的前置机;
前置机对接收的中心机发送的用户请求进行校验,校验通过后将请求划分到以用户标识为索引的缓冲池中,每个缓冲池具有对应的沙箱;
前置机每隔设定时间从缓冲池挑选出一个请求进行执行;
前置机根据条件因子与沙箱分类的关系建立决策树模型,将请求进行分解,根据决策树模型得到请求对应的沙箱分类,确定执行请求的沙箱;
前置机将请求拆分为若干中间业务过程,在沙箱中按顺序执行。
具体实现流程可参照前述基于沙箱的多中心医学队列构建系统中的各功能模块。
以上所述仅是本发明的优选实施方式,虽然本发明已以较佳实施例披露如上,然而并非用以限定本发明。任何熟悉本领域的技术人员,在不脱离本发明技术方案范围情况下,都可利用上述揭示的方法和技术内容对本发明技术方案做出许多可能的变动和修饰,或修改为等同变化的等效实施例。因此,凡是未脱离本发明技术方案的内容,依据本发明的技术实质对以上实施例所做的任何的简单修改、等同变化及修饰,均仍属于本发明技术方案保护的范围内。
Claims (10)
1.一种基于沙箱的多中心医学队列构建系统,其特征在于,该系统包括中心机,以及与所述中心机连接的若干部署在医疗机构内部的前置机;
所述中心机用于设置用户的优先级及权限编码,接收用户请求,构造出符合用户医学队列构建需求的JSON字符串,通过路由规则发送给对应的前置机;
所述前置机用于对接收的用户请求进行校验,校验通过后将请求划分到以用户标识为索引的缓冲池中,每个缓冲池具有对应的沙箱;每隔设定时间从缓冲池挑选出一个请求进行执行;根据条件因子与沙箱分类的关系建立决策树模型,将请求进行分解,根据决策树模型得到请求对应的沙箱分类,确定执行请求的沙箱;将请求拆分为若干中间业务过程,在沙箱中按顺序执行。
2.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述中心机包括以下模块:
权限控制模块:用于对不同用户设置不同的优先级及权限编码,所述权限编码用于控制不同用户在前置机上能够执行的数据类型和操作类型;
业务请求构造模块:根据用户请求中的业务参数,结合优先级、权限编码以及加密机制,构造出用户请求对应的JSON字符串;
路由模块:中心机为每个前置机分配前置机id,请求需要进行路由选择时,根据用户标识找到前置机id,根据前置机id查询网络参数构造路由地址;
业务请求发送模块:用于将业务请求构造模块构造的请求根据路由模块得到的路由地址发送给用户对应的前置机。
3.根据权利要求2所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述业务请求构造模块具体为:
将用户请求中的业务参数转化成结构化数据并存储在中心机数据库中;
取出业务参数的结构化数据,将结构化数据转化成JSON字符串,向JSON字符串中添加用户标识、请求id、优先级和权限编码,形成新的JSON字符串并对新的JSON字符串通过MD5加密算法得到消息摘要,将消息摘要添加到新的JSON字符串中,形成请求对应的JSON字符串。
4.根据权利要求3所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含校验模块,用于对接收的请求进行校验,具体为:
将对JSON字符串求MD5值得到消息摘要与JSON字符串中的消息摘要进行比对,如果不一致,则上报中心机请求异常并丢弃该请求;
进行权限校验,提取JSON字符串中的权限编码,得到各数据类型的可操作权限,将可操作权限与前置机本地服务器的已配置权限进行比对,如果可操作权限高于本地服务器的权限,则上报中心机请求异常并丢弃该请求,否则校验通过。
5.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含请求缓冲模块,用于将请求划分到缓冲池中,具体为:
前置机预设缓冲池的最大数量N,以及每个缓冲池最多缓存的请求数量M;
新请求到达时,根据用户标识进行索引,确认待划分的缓冲池,
如果该用户没有对应的缓冲池,则判断缓冲池的数量是否超过N个,如果超过N个则拒绝请求并上报给中心机告警,否则创建新的缓冲池,并将该请求放入新的缓冲池的末尾;在新创建缓冲池时,同时创建对应的沙箱;
如果该用户已有对应的缓冲池,则判断该缓冲池中的请求数量是否超过M个,如果超过M个则拒绝请求并上报给中心机告警,否则将该请求放入该缓冲池的末尾。
6.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含请求调度模块,用于从缓冲池挑选待执行请求,具体为:
统计过去一段时间内前置机服务器上运行的所有沙箱的CPU利用率、内存使用量和磁盘使用量,如果某沙箱的CPU利用率、内存使用量和磁盘使用量均小于预设百分比阈值,则标记该沙箱为可用沙箱,否则标记该沙箱为过载沙箱;
将可用沙箱对应的用户组成候选用户集合{User1,User2,...},对应的优先级数值集合为{p1,p2,...},计算出候选用户的优先级数值总和P;随机生成一个整数R,整数范围为1到P;设sum=0,i=1,若 sum<=R<=sum+pi,则Useri为可挑选的用户,否则sum=sum+pi ,i=i+1;从可挑选的用户对应的缓冲池中取出第一个请求进行执行。
7.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含沙箱调度模块,用于确定执行请求的沙箱,具体为:
根据条件因子与沙箱分类的关系建立决策树模型,所述条件因子包括数据表大小、概念个数、单个概念的最大统计数和时间窗;所述沙箱的分类对应于沙箱能够分配的硬件资源;
将请求进行分解,根据决策树模型得到请求对应的沙箱分类;
查询用户标识与沙箱id映射表,如果能查到该用户对应的当前沙箱,且所需分配沙箱的等级小于等于当前沙箱的等级,则将该请求分配到当前沙箱中去执行计算;否则按照所需分配沙箱的等级新建沙箱,将该请求分配到新建沙箱中去执行计算,并更新用户标识与沙箱id映射表,将原沙箱标记为可销毁沙箱;
新建沙箱时,根据决策树模型的沙箱分类结果,对沙箱所能利用的硬件资源进行限制。
8.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含沙箱执行模块,用于在沙箱内部进行请求的计算,包括:
将请求的业务参数中的纳入规则和结局规则的多个并列条件按顺序拆分,得到若干中间业务过程,对每个业务过程按顺序编号,赋予不同的步骤id;
按照中间业务过程的顺序依次执行数据库查询或者计算;
每个中间业务过程的结果均保存到中间结果文件中;
查找该请求对应的元数据文件,如果元数据文件不存在,则新生成一个元数据文件,用于记录当前已执行步骤的标志信息,如果元数据文件已经存在,则在已生成好的元数据文件中,追加记录当前的中间业务过程已完成。
9.根据权利要求1所述的基于沙箱的多中心医学队列构建系统,其特征在于,所述前置机中包含沙箱管理模块,具体为:
在设定时间对沙箱进行检查及记录,如果第一次检查时,某沙箱没有请求在运行,则该沙箱标记为空闲;第二次检查时,如果已标记为空闲的沙箱,还是没有请求在运行,则标记为可销毁;第三次检查时,如果已标记为可销毁的沙箱,仍然没有请求在运行,则直接销毁该沙箱;
记录每个沙箱自新建以来的利用效率,如果每一次请求所需沙箱的等级和实际运行任务时的沙箱等级不匹配的比例超过阈值,则将该沙箱标记为可销毁沙箱;在下一次检查时,如果该沙箱没有请求在运行,则直接销毁该沙箱,同时新建一个低一级的沙箱替换掉原沙箱。
10.一种基于沙箱的多中心医学队列构建方法,其特征在于,该方法包括:
部署一个中心机和与该中心机通过专网连接的若干前置机,各前置机部署在在医疗机构内部,与医疗机构的医疗信息系统连接;
中心机对不同用户设置不同的优先级及权限编码;
中心机接收用户的队列构建请求,构造出符合用户医学队列构建需求的JSON字符串,通过路由规则发送给对应的前置机;
前置机对接收的中心机发送的用户请求进行校验,校验通过后将请求划分到以用户标识为索引的缓冲池中,每个缓冲池具有对应的沙箱;
前置机每隔设定时间从缓冲池挑选出一个请求进行执行;
前置机根据条件因子与沙箱分类的关系建立决策树模型,将请求进行分解,根据决策树模型得到请求对应的沙箱分类,确定执行请求的沙箱;
前置机将请求拆分为若干中间业务过程,在沙箱中按顺序执行。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310313579.6A CN116010941B (zh) | 2023-03-28 | 2023-03-28 | 一种基于沙箱的多中心医学队列构建系统及方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202310313579.6A CN116010941B (zh) | 2023-03-28 | 2023-03-28 | 一种基于沙箱的多中心医学队列构建系统及方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN116010941A true CN116010941A (zh) | 2023-04-25 |
CN116010941B CN116010941B (zh) | 2023-06-30 |
Family
ID=86025293
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202310313579.6A Active CN116010941B (zh) | 2023-03-28 | 2023-03-28 | 一种基于沙箱的多中心医学队列构建系统及方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN116010941B (zh) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116991563A (zh) * | 2023-09-28 | 2023-11-03 | 之江实验室 | 一种支持快速构建沙箱的队列生成方法及装置 |
Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103678505A (zh) * | 2013-11-20 | 2014-03-26 | 北京奇虎科技有限公司 | 一种在浏览器中运行应用程序的方法、装置和浏览器 |
CN106127368A (zh) * | 2016-06-14 | 2016-11-16 | 成都镜杰科技有限责任公司 | 用于企业资源管理系统的数据存储方法 |
CN110348203A (zh) * | 2018-04-02 | 2019-10-18 | 蓝盾信息安全技术有限公司 | 一种队列式沙箱文件处理方法 |
CN112507330A (zh) * | 2020-11-04 | 2021-03-16 | 北京航空航天大学 | 一种基于分布式沙箱的恶意软件检测系统 |
CN113297566A (zh) * | 2020-05-15 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 沙箱实现方法、装置、设备和存储介质 |
US11341029B1 (en) * | 2021-01-14 | 2022-05-24 | Datorama Technologies Ltd. | Virtual sandbox environment of cloud computing resources |
-
2023
- 2023-03-28 CN CN202310313579.6A patent/CN116010941B/zh active Active
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103678505A (zh) * | 2013-11-20 | 2014-03-26 | 北京奇虎科技有限公司 | 一种在浏览器中运行应用程序的方法、装置和浏览器 |
CN106127368A (zh) * | 2016-06-14 | 2016-11-16 | 成都镜杰科技有限责任公司 | 用于企业资源管理系统的数据存储方法 |
CN110348203A (zh) * | 2018-04-02 | 2019-10-18 | 蓝盾信息安全技术有限公司 | 一种队列式沙箱文件处理方法 |
CN113297566A (zh) * | 2020-05-15 | 2021-08-24 | 阿里巴巴集团控股有限公司 | 沙箱实现方法、装置、设备和存储介质 |
CN112507330A (zh) * | 2020-11-04 | 2021-03-16 | 北京航空航天大学 | 一种基于分布式沙箱的恶意软件检测系统 |
US11341029B1 (en) * | 2021-01-14 | 2022-05-24 | Datorama Technologies Ltd. | Virtual sandbox environment of cloud computing resources |
Non-Patent Citations (2)
Title |
---|
WANRONG OUYANG: "RusBox: Towards Efficient and Adaptive Sandboxing for Rust", 《IEEE》 * |
范炜玮;赵东升;王松俊;: "基于云计算的区域医疗信息共享平台的设计与实现", 军事医学, no. 04 * |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN116991563A (zh) * | 2023-09-28 | 2023-11-03 | 之江实验室 | 一种支持快速构建沙箱的队列生成方法及装置 |
CN116991563B (zh) * | 2023-09-28 | 2023-12-22 | 之江实验室 | 一种支持快速构建沙箱的队列生成方法及装置 |
Also Published As
Publication number | Publication date |
---|---|
CN116010941B (zh) | 2023-06-30 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US10025904B2 (en) | Systems and methods for managing a master patient index including duplicate record detection | |
CN101939742B (zh) | 在日志数据中搜索关联事件 | |
CA2393860C (en) | Anonymously linking a plurality of data records | |
CA2564307C (en) | Data record matching algorithms for longitudinal patient level databases | |
CN113643821B (zh) | 一种多中心知识图谱联合决策支持方法与系统 | |
CN111190881A (zh) | 一种数据治理方法和系统 | |
US10572461B2 (en) | Systems and methods for managing a master patient index including duplicate record detection | |
CN116010941B (zh) | 一种基于沙箱的多中心医学队列构建系统及方法 | |
US11798690B2 (en) | Method of using medical data related to patients suffering a given disease | |
US11321366B2 (en) | Systems and methods for machine learning models for entity resolution | |
Benitez et al. | Beyond safe harbor: automatic discovery of health information de-identification policy alternatives | |
CN115292353B (zh) | 数据查询方法、装置、计算机设备和存储介质 | |
CN113283677B (zh) | 指标数据处理方法、装置、设备及存储介质 | |
CN114692204A (zh) | 数据查询方法、装置、设备及存储介质 | |
CN114783557A (zh) | 肿瘤患者数据的处理方法和装置、存储介质及处理器 | |
US20050125257A1 (en) | System and method for creating data links between diagnostic information and prescription infornation records | |
Salloway et al. | A de-identification tool for users in medical operations and public health | |
Khan et al. | Secured technique for healthcare record linkage | |
CN112631998B (zh) | 文件夹显示方法及相关设备 | |
Abel et al. | How fair were COVID-19 restriction decisions? A data-driven investigation of England using the dominance-based rough sets approach | |
CN117349349A (zh) | 异构数据集成方法、终端设备及计算机可读存储介质 | |
CN112069248A (zh) | 一种对数据进行治理和核查的可视化配置方法和平台 | |
CN116386797A (zh) | 一种医学检验数据的跨平台流转系统与方法 | |
AU2012200281A1 (en) | "Data record matching algorithms for longitudinal patient level databases" |
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 |