CN110517738A - 一种基于医院内网环境的房颤单病种随访数据库系统 - Google Patents
一种基于医院内网环境的房颤单病种随访数据库系统 Download PDFInfo
- Publication number
- CN110517738A CN110517738A CN201910361838.6A CN201910361838A CN110517738A CN 110517738 A CN110517738 A CN 110517738A CN 201910361838 A CN201910361838 A CN 201910361838A CN 110517738 A CN110517738 A CN 110517738A
- Authority
- CN
- China
- Prior art keywords
- data
- atrial fibrillation
- patient
- hospital
- single diseases
- 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
Links
- 206010003658 Atrial Fibrillation Diseases 0.000 title claims abstract description 109
- 208000037265 diseases, disorders, signs and symptoms Diseases 0.000 title claims abstract description 74
- 201000010099 disease Diseases 0.000 title claims abstract description 71
- 238000004140 cleaning Methods 0.000 claims abstract description 51
- 238000003908 quality control method Methods 0.000 claims abstract description 33
- 238000004458 analytical method Methods 0.000 claims abstract description 26
- 238000011160 research Methods 0.000 claims abstract description 7
- 238000003745 diagnosis Methods 0.000 claims description 32
- 238000000034 method Methods 0.000 claims description 22
- 238000003860 storage Methods 0.000 claims description 16
- 239000003814 drug Substances 0.000 claims description 13
- 229940079593 drug Drugs 0.000 claims description 12
- 230000008569 process Effects 0.000 claims description 11
- 239000003146 anticoagulant agent Substances 0.000 claims description 8
- 229940127219 anticoagulant drug Drugs 0.000 claims description 8
- 238000012545 processing Methods 0.000 claims description 8
- 238000013461 design Methods 0.000 claims description 7
- 238000009826 distribution Methods 0.000 claims description 7
- 238000002604 ultrasonography Methods 0.000 claims description 5
- 238000013079 data visualisation Methods 0.000 claims description 4
- 230000001360 synchronised effect Effects 0.000 claims description 4
- 101100048435 Caenorhabditis elegans unc-18 gene Proteins 0.000 claims description 3
- 230000003068 static effect Effects 0.000 claims description 3
- 230000009471 action Effects 0.000 claims description 2
- 230000010354 integration Effects 0.000 abstract description 3
- 230000000007 visual effect Effects 0.000 abstract 1
- 238000007726 management method Methods 0.000 description 27
- 238000010586 diagram Methods 0.000 description 14
- 230000006870 function Effects 0.000 description 11
- 238000007405 data analysis Methods 0.000 description 7
- 238000005516 engineering process Methods 0.000 description 7
- 238000007619 statistical method Methods 0.000 description 7
- 238000004590 computer program Methods 0.000 description 6
- 241001269238 Data Species 0.000 description 5
- 230000004048 modification Effects 0.000 description 5
- 238000012986 modification Methods 0.000 description 5
- 238000012216 screening Methods 0.000 description 4
- 238000001356 surgical procedure Methods 0.000 description 4
- 235000005187 Taraxacum officinale ssp. officinale Nutrition 0.000 description 3
- 230000006399 behavior Effects 0.000 description 3
- 230000000694 effects Effects 0.000 description 3
- 230000036541 health Effects 0.000 description 3
- 238000007689 inspection Methods 0.000 description 3
- 239000010410 layer Substances 0.000 description 3
- 239000000203 mixture Substances 0.000 description 3
- 241000208340 Araliaceae Species 0.000 description 2
- 235000005035 Panax pseudoginseng ssp. pseudoginseng Nutrition 0.000 description 2
- 235000003140 Panax quinquefolius Nutrition 0.000 description 2
- 241000245665 Taraxacum Species 0.000 description 2
- 230000009286 beneficial effect Effects 0.000 description 2
- 230000008859 change Effects 0.000 description 2
- 238000010276 construction Methods 0.000 description 2
- 239000000284 extract Substances 0.000 description 2
- 235000008434 ginseng Nutrition 0.000 description 2
- 238000012423 maintenance Methods 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 206010058046 Post procedural complication Diseases 0.000 description 1
- 208000035965 Postoperative Complications Diseases 0.000 description 1
- 240000001949 Taraxacum officinale Species 0.000 description 1
- 230000002411 adverse Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000004888 barrier function Effects 0.000 description 1
- 230000008901 benefit Effects 0.000 description 1
- 210000004556 brain Anatomy 0.000 description 1
- 238000006243 chemical reaction Methods 0.000 description 1
- 238000013497 data interchange Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000005611 electricity Effects 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 230000008676 import Effects 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 238000009440 infrastructure construction Methods 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 239000011229 interlayer Substances 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 238000005457 optimization Methods 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
- 238000004088 simulation Methods 0.000 description 1
- 239000000344 soap Substances 0.000 description 1
- 238000013179 statistical model Methods 0.000 description 1
- 230000009466 transformation Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H10/00—ICT specially adapted for the handling or processing of patient-related medical or healthcare data
- G16H10/60—ICT specially adapted for the handling or processing of patient-related medical or healthcare data for patient-specific data, e.g. for electronic patient records
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H40/00—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices
- G16H40/60—ICT specially adapted for the management or administration of healthcare resources or facilities; ICT specially adapted for the management or operation of medical equipment or devices for the operation of medical equipment or devices
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
- G16H50/70—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for mining of medical data, e.g. analysing previous cases of other patients
-
- G—PHYSICS
- G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
- G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
- G16H70/00—ICT specially adapted for the handling or processing of medical references
- G16H70/60—ICT specially adapted for the handling or processing of medical references relating to pathologies
Landscapes
- Engineering & Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Medical Informatics (AREA)
- Public Health (AREA)
- General Health & Medical Sciences (AREA)
- Primary Health Care (AREA)
- Epidemiology (AREA)
- Biomedical Technology (AREA)
- Data Mining & Analysis (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Databases & Information Systems (AREA)
- Pathology (AREA)
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Abstract
本发明公开了一种基于医院内网环境的房颤单病种随访数据库系统,包括数据采集及清洗模块,用于对房颤单病种数据进行自动识别、采集和清洗;质量控制模块,用于对清洗后的数据进行质量控制分类,并以可视化方式生成对应的统计图表;多维分析模块,用于通过患者的识别号,将患者对应的各房颤单病种数据关联起来;并根据用户的查询操作向用户展示相应患者对应的房颤单病种数据;VPN硬件模块,用于实现多端口联动,使用户能够远程链接到医院网络,借助网络访问医院数据库服务器。本发明将病人散落在各数据系统和端口中的数据集成到一个数据库系统;并可通过多种端口进行随访、科研和管理,从而为医院建立真正安全的房颤单病种随访数据库系统。
Description
技术领域
本发明涉及医疗技术领域,尤其涉及一种基于医院内网环境的房颤单病种随访数据库系统。
背景技术
目前现有技术有三种方案解决房颤单病种随访数据需求。
第一种为医生通过传统的excel软件全手动录入患者的诊疗数据和随访数据:该解决方案需要操作人员花费大量时间手动收集病人数据并且录入到excel中,具有数据获取难度大、使用成本高、存储不方便、分析困难、数据丢失风险高、数据维度低、数据缺陷率高、修改困难、维护困难、清洗困难、不可溯源、难以进行不同端口的协同操作和隐私数据保护困难等问题,是目前完成病人数据录入和存储的最简陋的方式,缺点甚多。
第二种为医生委托医院工程师从传统的医院数据库以检索方式跨门诊系统、住院系统、急诊系统、HIS系统、电子病历、检验系统、影像系统、处方系统、医嘱系统、手术系统等各个院内系统数据库调用各诊疗数据集成为10余份文档,每份文档内只有所有病人的来自于某个系统的诊疗数据,交给医生。该种方式比传统手工录入方便,但是对医生而言非常难以将某个病人的数据横跨10余份文件汇总起来综合管理,并且极难进行随访整理和数据清洗,有事不能完全打开,更多情况下数据具有复杂的代码,对于医务工作者而言具有很大处理难度,回溯数据时发现所需要的数据并不能被该种方式有效解决。因此数据具有使用成本高、汇总分析困难、监测病人难度极大、不具有时效性、数据丢失风险高、获取数据壁垒高、数据修改困难、难以跟不同端口协作共同管理和隐私数据容易泄露保护困难等。
第三种为基于互联网的各类随访平台,该种平台通过在互联网云服务器上部署一套公网服务,然后让医务工作人员自备外网电脑,再使用这台外网电脑录入病人的病史资料、随访资料。该套随访平台比第一种和第二种方案要方便一些,主要是实现了医生之间的协同管理,不同医生可以共同管理和编辑同一个病人的资料,并且病人资料可以制作相应的模板,加上患者端的功能以后可以与患者之间形成互动。但是,临床医生没有足够的时间录入每个病人的上千条诊疗数据,并且数据采集困难,很多医院内部的诊疗数据没有办法获取,病人数据也无法保护,增加病人遭受电信网络诈骗、医药广告推销的风险,存在极大的安全问题。总体来看,通过此方式数据采集效率低、采集成本高、安全系数极低,具有高风险高成本的特征,因此医院不愿接受。
综上所述,现有技术的主要问题聚焦在以下几类:
首先是数据层面:
一是数据采集困难,现有技术或使用人工录入为主、或通过医院现有信息化系统采集到大量对房颤单病种管理分析无效的数据,这些数据提取方式依赖于大量人力成本、时间成本投入,并且采集效率低,采集效果差。
二是数据清洗困难,现有数据基本以人工清洗为主,主要原因是现有技术方案不是针对房颤这一单病种疾病的,大多数也没有设定病人的标准数据字段,字段之间的关系是割裂的、互相独立的,导致获得的数据大多都是非结构化的无效数据,所以对数据进行结构化、随访化、单病种化的处理需要依赖大量的时间投入。
三是数据质量控制困难,现有技术基本是没有办法解决数据质量控制这一问题的,医疗数据质量控制的本质是医疗质量控制,但是没有通过数据技术挖掘出来数据的完整度、缺陷率、数据冗余程度、具体的临床质量控制的指标等,这一工作现有技术的基础是采集和清洗到位,再进行人工质量控制,因此也极度依赖医生高质量的投入大量的时间和人力成本。
四是数据统计分析困难,现有技术主要是通过人工的方式在前面工作的基础之上使用spss或者传统的excel方式进行统计分析,具有大量的人力因素,医生不是计算机专业人员,医生面对的数据可能是具有复杂的代码或者冗余信息的,甚至有时医生大量的时间和人力成本投入以后还是难以解决数据的统计分析问题。
其次是协同工作和医患互动层面:
一是多端口共同管理,现有的协同技术或是使用医院门诊、急诊、住院系统的院内管理方案,或是使用外网WEB、APP的院外管理方案。
现有院内管理技术的弱点是协同管理困难、数据互通困难,没有集成在一起,在门诊系统只能管理当日就诊的患者,在住院系统只能管理住院中的患者,在急诊系统亦然,无法回溯、难以协作管理。
现有院外管理技术的弱点是没有办法实现院内外协作管理,医生在院内大多数时间还是在面对院内系统,医院的网络基础设施建设也相对落后,很多院内就诊数据给与医生应有提示也没办法做到根据数据实现病人管理的自动化和私人订制。
最后是安全层面。
该问题主要是病人数据存储在哪里,现有的技术解决方案或是存储在HIS数据库中,或是导出存储成为excel中,或是存储在外网云服务器内。
这三种方式各有利弊,存储在HIS数据库中最安全,但会导致医生提取使用困难,也难以维护;
导出成excel会导致数据随时可能意外泄露,虽然使用方便,但清洗和维护比较困难;
存储在外网云服务器内,虽然使用方便,但是会导致数据意外泄漏,所以基本也是不可取的。
本发明的目的就是要解决传统技术无法解决的以上各方面数据问题、多端口协作问题、数据安全问题。使用新的技术架构、全新的功能设计、全新的产品技术方案、安全方案等,建设基于医院内网环境的房颤单病种随访数据库系统,在不改变医院院内数据库的基础上,解决房颤病人数据结构化自动提取录入的困难,并且实现医生的协作管理、自主管理、自主分析等,解决这一房颤单病种管理的痛中之痛。
发明内容
针对上述现有技术中存在的问题,本发明提供一种基于医院内网环境的房颤单病种随访数据库系统,所述基于医院内网环境的房颤单病种随访数据库系统包括:
数据采集及清洗模块,通过设计专用的视图结构,从医院各系统数据库视图和有关的数据端口中自动识别并采集房颤单病种数据,并对采集到的数据进行清洗,然后按照预设存储分类格式将清洗后的数据进行存储;
质量控制模块,对经过所述数据采集及清洗模块处理后的数据进行质量控制分类,再分别计算各自的预设统计数据并对统计结果进行分析,然后将分析结果采用数据可视化的方式生成对应的统计图表;
多维分析模块,用于对经过所述数据采集及清洗模块处理的数据进行表关联并选择所有表;通过患者的识别号,将患者对应的各房颤单病种数据关联起来,保证每一个患者每一次的就诊信息都采用预设的标准格式记录下来;并根据用户的查询操作向用户展示相应患者对应的房颤单病种数据;
VPN硬件模块,用于实现多端口联动,使用户能够远程链接到医院网络,借助网络访问医院数据库服务器。
进一步地,所述数据采集及清洗模块对房颤单病种数据进行自动识别,采集和清洗的过程包括:
从医院各系统数据库视图和有关的数据端口中进行查询;
当患者病情资料的诊断中出现预设关键字时,获得该患者的识别码;
通过该患者的识别码关联到该患者的基本信息、病史、用药、心电图、超声以及房颤患者相关的评分;
对获得的数据通过预设结构化进行结构化,然后按照预设存储分类格式将结构化后的数据进行存储分类。
可选地,所述预设关键字包括:“房颤”、“心房颤动”、“心房纤颤”中的一种或多种的组合;所述患者的识别码包括:身份证号、就诊卡号、病人ID中的一种或多种的组合。
进一步地,数据采集及清洗模块的数据源为第三方数据库和集成平台;
当所述数据采集及清洗模块的数据源为第三方数据库时,所述数据采集及清洗模块的采集器根据单病种的名称或icd编码从诊断表中匹配出所有属于该病种的患者的院内id,然后从各个业务系统中定期采集属于这个id的所有信息;采集完成后,采集器会将所获得的数据统一转换为JSON数据结构;
当所述数据采集及清洗模块的数据源为集成平台时,所述数据采集及清洗模块根据每一接口形式分别封装相应接口,形成多个患者id->JSON的标准接口,所述采集器的调度模块将多个患者的JSON数据汇总成列表,获得与视图的情况相同的返回结果。
进一步地,所述数据采集及清洗模块还包括数据转换器;
所述数据转换器用于,确定需要同步的数据所在的时间范围,对相应时间范围内的数据进行同步;确定新订阅的患者id,将其历史数据导入数据库中;通过各种透视操作将数据库中源数据字段与新字段建立一一对应的关系。
进一步地,所述质量控制模块按照门诊、住院、急诊、全院对经过所述数据采集及清洗模块处理后的数据进行质量控制分类;所述预设统计数据包括总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计和合并疾病。
进一步地,所述质量控制模块具体用于:
对经过所述数据采集及清洗模块处理后的数据,查询出所有业务表相关的患者识别号pi、就诊识别号pv及相应的时间,并生成一个中间表dates;
以中间表dates为基础对其它表进行left join操作,并把所有结果通过union操作列在一起,统一为一个大表。
进一步地,所述多维分析模块基于MySQL数据库设计,其具体用于:
通过患者的就诊卡号、身份证号或者门诊号作为患者的唯一识别号,将患者的基本信息、病史、用药以及就诊记录关联起来,保证每一个患者每一次的就诊信息都可以用预设的标准格式记录下来;
当用户需要按患者进行查询研究的时候,首先将各个表进行缩并,确保各个表里的患者都是唯一的,然后通过逐级left join将所有表连接起来形成医生需要的一张大表。
可选地,所述VPN硬件模块包括电脑、转换器和双WLAN口路由器;
其中,所述双WLAN口路由器的WLAN口与医院内网端口链接,所述电脑设置为所述内网端口的IP地址;所述双WLAN口路由器的LAN2口接入所述转换器,通过所述转换器接入到所述电脑;所述电脑配置有无线网卡,远程使用无线网络访问院内的房颤服务器。
进一步地,所述VPN硬件模块组装方式如下:
向院内IT部门报备申请内网网线接口,获取该内网端口IP地址,将使用的电脑设置为该静态IP地址;
使用内网接入双WLAN口路由器中,链接WLAN接口,同时将双WLAN口接入转换器,使用转换器接入到电脑上;使用电脑配置无线网卡,远程使用无线网络访问院内房颤服务器。
本发明的技术方案相比于现有技术具有如下有益效果:
针对现有技术在对数据进行处理时,存在的采集和清洗困难问题,本发明通过根据诊断含有“房颤”、“心房纤颤”、“心房颤动”获取病人唯一识别码,并根据病人识别码进一步获取病人视图里基本信息、诊断、用药、病史、B超、病历、手术信息等其他的患者数据,通过本发明的房颤专病随访数据库标准化的格式要求,将数据进行自动清洗、自动结构化并最终分类存储;从而实现了对数据的自动采集和清洗;
针对现有技术在对数据进行处理时,存在的质量控制困难问题,本发明通过将病人资料按照门诊、住院、急诊、全院等进行质量控制分类,再分别计算各自的总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计、合并疾病以及这些指标的趋势,然后这些分析结果采取数据可视化的方式生成对应的统计图表;从而便于使用数据透视统一处理及质量控制。
针对现有技术在对数据进行处理时,存在的统计分析困难问题,本发明通过设计一个基于常见的MySQL数据库的房颤多维大数据分析模块,将清洗后的数据进行表关联并选择所有表,同时字段围绕房颤这一单病种优化。使得用户操作时,不需要进行表关联和选择表,就可以采用本发明的多维分析模块做几乎类似数据库的多维查询分析工作。
而针对现有技术存在多端口协同管理困难和数据安全问题,本发明通过设计多端口联动的VPN硬件模块,实现了将数据库系统等其他房颤相关的多个端口布置在医院内网服务器中。从而使得医生可以在各个不同的端口管理同样的病人,不同的端口也都可以各自获取病人数据,然后各端口可以共同管理每一个端口里获得的病人数据、而且数据之间通过医院的专门VPN进行管理,通过专门的服务器架构保证协作顺畅;在保障数据安全的同时能够更加有效的利用数据。
附图说明
图1为本发明实施例提供的基于医院内网环境的房颤单病种随访数据库系统的组成示意图;
图2为本发明实施例提供的数据采集及清洗的原理示意图;
图3为本发明实施例提供的进行质量控制操作的原理示意图;
图4a至图4f为本发明实施例提供的示例性的统计图表的示意图;
图5为本发明实施例提供的多维分析模块的工作原理示意图;
图6为本发明实施例提供的进行多维查询分析工作的示意图;
图7为本发明实施例提供的筛选条件输入界面示意图;
图8为本发明实施例提供的系统接入智能硬件的示意图;
图9为本发明实施例提供的多端口联动的VPN硬件模块的组成示意图;
图10和图11为多端口联动示意图。
具体实施方式
为使本发明实施例的目的、技术方案和优点更加清楚,下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例是本发明的一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例,都属于本发明保护的范围。
请参阅图1至图11,本实施例提供一种基于医院内网环境的房颤单病种随访数据库系统,实现对房颤病人相关数据的自动抓取并且自动将抓取的数据清洗成结构化的房颤单病种随访数据,然后将清洗后的房颤单病种随访数据在医院内网服务器网络环境中进行存储,从而将所有在医院门急诊和住院中就诊过的房颤病人的诊疗信息通过信息化技术进行多端口的集成,将病人散落在医院门诊系统、住院系统、急诊系统、HIS系统、电子病历、检验系统、影像系统、处方系统、医嘱系统、手术系统以及患者自己的可穿戴设备等十余个端口中的数据集成进入统一的基于医院内网环境的房颤单病种随访数据库系统;然后通过PC客户端进行随访、科研和管理,并且也可以通过移动端App和微信服务号等多个端口参与管理,从而为医院建立真正安全的房颤单病种随访数据库系统。
在此房颤单病种随访数据库的基础上完成信息化的房颤病人筛查、录入房颤病人随访数据、记录患者手术详细资料、进行多维数据查询、对房颤病人规范诊疗情况进行详细的质量控制、群发短信给患者、下载房颤病人资料、监测病人病情、管理房颤患者就诊、建设房颤大数据监控中心、管理院内房颤患者流和进行更多的统计分析等。
为实现上述功效,本实施例在医院内网环境中的医院信息系统权限下,设置一套服务器,名称为房颤单病种随访系统服务器,简称房颤服务器;并开发一套专门的房颤单病种数据库随访管理系统,简称房颤系统。通过获取医院的各大信息系统的接口或者视图,让房颤管理系统对接这些视图,自动实现数据抓取,并能够在数据抓取的基础上实现数据分析,并进一步根据数据实现医院的病人管理和辅助医生科研。
基于上述,本实施例的系统设计有自动识别、自动抓取、自动清洗、自动质量控制、医用数据库统计分析等功能,采用移动端APP、微信服务号和院内PC客户端等多端口跨平台协作的方式、纯内网数据库等功能和架构,解决现有技术未解决的问题。帮助医生高效收集房颤患者临床数据,同时协助医生对房颤患者进行专病管理,从而帮助医生提高效率,减轻数据录入和管理专病患者的负担;进一步地,整个系统由医院内网WEB、移动端APP、微信服务号等多个医患端口构成,打通了数据孤岛,并接入了智能硬件,如图8所示;从而极大地方便了临床工作,其系统组成如图1所示。
具体地,本实施例的系统所实现的主要功能如下:
数据抓取,包括患者信息、病史、用药、检验信息、心超、心电图、医嘱、其他房颤数据要点等;
数据记录,包括评分、门诊随访、手术记录、课题资料、外院数据记录、其他房颤随访要点等;
医疗质量控制,包括抗凝率、评分率、不良事件、手术并发症、患者流、其他房颤质控要点等。
数据分析,内置房颤数据库、可直接完成许多高级数据分析、一键式导出结果等。
基于上述,本实施例的系统主要包括以下功能模块:
数据采集及清洗模块,用于针对房颤单病种的数据进行采集和清洗操作;
针对现有技术在对数据进行处理时,所存在的采集和清洗困难问题,本实施例的数据采集及清洗模块通过设计专门的视图结构,从医院各系统数据库视图和有关的数据端口中,根据病人病情资料的“诊断”中出现“房颤”、“心房颤动”、“心房纤颤”等条件,获得病人的身份证号、就诊卡号、patient ID等病人识别码,再通过这类识别码关联到患者的基本信息、病史、用药、心电图、超声以及房颤患者相关的评分,将院内原本分割的数据重新整合对应,将患者的数据清洗出来,实现每一个房颤患者每一次的清晰就诊数据都可以完整无缺。此处也可以不通过最终确诊诊断,而是通过诊断标准来模拟诊断,获取病人识别码,当然结果不如通过最终确诊诊断准确。
房颤患者主要为门诊、住院、急诊,我们获取了门诊以及住院的房颤患者的基本信息、诊断、就诊记录、处方、病史以及住院房颤病人的手术相关信息,分别计算各自的总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计、合并疾病以及这些指标的趋势等进行分析,使用本发明的房颤病人数据结构化方法将病人病情资料进行结构化,再按照本发明设计的专门的房颤单病种随访数据库存储分类格式,将住院患者与门诊患者数据按照房颤单病种随访结构进行存储分类;如图2所示。
该数据采集及清洗模块进行数据采集及清洗的过程具体如下:
1、数据抽取(Extraction)
患者属于某个单病种的数据分布在院内各个业务系统内,针对医院的具体情况,所获得的数据源一般有两类:第三方数据库和集成平台。
对于数据库,数据采集及清洗模块的采集器会根据单病种的常用名称或icd编码从诊断表中匹配出所有属于该病种的患者的院内id,然后从各个业务系统中定期采集属于这个id的所有信息。采集完成后,采集器会将所获得的数据统一转换为JSON数据结构。
对于集成平台,常见的接口形式有http接口,soap接口,socket接口,MQ接口等,接口的入参和出参的常见形式有JSON,xml,hl7,集成平台定义的特种二进制结构等。对此,数据采集及清洗模块会根据每一种特定情况封装相应接口,形成多个患者id->JSON的标准接口,器采集器的调度模块会将多个患者的JSON数据汇总成列表,获得与视图的情况相同的返回结果。
在这个阶段最重要的有:
患者id在各业务模块的统一性,如果不统一则难以获取全部相关数据。
每个业务模块必须返回时间字段,这样才能对数据增量同步。
各个重要字段必须有索引,否则同步时间无法控制。
2、数据转换(Transformation)
高质量的数据库涉及到维度、访问速度、数据量、实时度等各方面的优化。Aftitadb标准数据库是我们在实践中总结出来的一个对医学科研来说维度已经相当齐全的数据库,为了将已经同步的数据注入到这个标准的数据库中。本实施例还需要一个自动数据转换器。相关步骤如下:
确定需要同步的数据所在的时间范围,只同步相应时间范围内的数据,降低各业务系统的读取压力。
确定新订阅的患者id。单病种数据库只关注与该病种相关的患者,如果该患者最近才诊断出该疾病,则之前并未被纳入数据库,因此需要将其历史数据导入数据中。
数据库的字段和表结构都需要调整,因此需要通过各种透视操作将源数据字段与新字段建立一一对应的关系。
质量控制模块,用于对获得的高质量房颤单病种随访数据进行一系列质量控制操作;
针对现有技术在对数据进行处理时,存在的质量控制困难问题,在通过对数据进行采集和清洗后,本实施例还进一步通过质量控制模块对获得的高质量的房颤单病种随访数据进行一系列质量控制操作,并在此基础上建设房颤多维分析工具:
这一系列的质量控制操作包括以下过程:
首先将按照门诊、住院、急诊、全院等进行质量控制分类,再分别计算各自的总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计、合并疾病以及这些指标的趋势等进行分析,再将这些分析结果采取数据可视化的方式生成对应的统计图表;如图3所示。
在标准数据库aftitadb的基础上查询出所有业务表相关的患者识别号pi,就诊识别号pv及相应的时间,并生成一个中间表dates,以此表为基础对其它表进行left join操作,并把所有结果通过union操作列在一起,则可以将分散在各个业务系统中的表统一为一个大表,我们称为患者综合行为表。这个表包含了患者在院的所有信息,比如何时入院,合适诊断,何时做了一个检查,何时接受了一次b超检查,何时收到了一个用药医嘱等。在此基础上我们可以进行统一的数据分析,而不用再分别关联各个表,便于使用数据透视统一处理。
本实施例所实现的统计模式有按科室统计、按门诊住院统计、按年龄性别统计、按抗凝率、cv、并发症等统计以及按时间统计等,如图4a至4f所示。当然可理解的是,也可计算别的类似指标,本实施例对此不作具体限定。
多维分析模块,用于对获得的房颤单病种随访数据进行多维大数据分析;
针对现有技术在对数据进行处理时,存在的统计分析困难问题,在该多维分析模块中,本实施例生产了一个基于常见的MySQL数据库的房颤多维大数据分析系统,这一分析系统的特点是已经将清洗后的数据进行了表关联并已经选择了所有表,该分析系统通过患者的就诊卡号、身份证号或者门诊号作为唯一识别号,将患者的基本信息、病史、用药、就诊记录以及其他就诊信息关联起来,保证每一个患者每一次的就诊信息都可以用标准化的格式记录下来,同时数据是完完全全围绕房颤这一单病种展开的;如图5所示。
内网房颤管理系统通过aftitadb数据库和院内接口间的ETL平台实现了数据层和应用层间的分离。其中aftitadb作为应用层的关键数据源,其实体包括:aftita_patients,保存了患者的基本信息;aftita_diagnosis,保存了所有诊断及科室信息;aftita_drugs,保存了用药的信息;aftita_surgery,保存了手术的信息,包括手术名称、手术经过、详细的手术报告等。Aftita_examination,保存了检验信息;aftita_inhos,保存了当前住院的患者。其它的表也类似,来自于其它院内业务系统。所有的表都是通过jzkh和mzh两个外键进行多对多关联的,其中jzkh是“就诊卡号”的缩写,广义上指患者的唯一识别号,多次就诊的时候是不变的,而mzh是“门诊号”的缩写,广义上指患者某次就诊的识别号,如某次门诊,某次急诊或某次住院。
当需要按患者进行查询研究的时候,应用层会首先将各个表通过sql语句:selectgroup_concat(distinct name)from table group by jzkh等形式进行缩并,确保各个表里的患者都是唯一的,然后通过逐级left join将所有表连接起来形成医生需要的一张大表。这张大表可以用于“数据库”模块里进行患者筛选,也可以直接导出为excel文件。此外,为了提高查询性能,系统每天晚上会自动运行一次预缓存功能,将大表先建好,并添加索引,便于之后使用。
通过上述多维分析模块可以做几乎类似数据库的多维查询分析工作;而且由于本实施例已将患者的所有就诊信息都进行关联并且进行标准化的数据清洗,因此用户操作时,不需要进行表关联和选择表,就可以采用本实施例的多维分析模块做几乎类似数据库的多维查询分析工作,能够使用最快的查询方式帮助医院解决数据难分析的问题,并且完全房颤单病种化;如图6所示;用户在查询时,可以根据自身需求输入筛选条件,如图7所示。
此外,本实施例的系统还部署有多端口联动的VPN硬件模块,通过VPN硬件远程链接到医院网络,借助网络访问数据库服务器,保证远程可操作系统安装、部署、更新、检查等功能,从而最快的提高全国单病种软件安装效率。其硬件组成如图9所示;包括电脑、转换器和双WLAN口路由器;
其中,该双WLAN口路由器的WLAN口与医院内网端口链接,该电脑设置为该内网端口的IP地址。此外,该双WLAN口路由器的LAN2口接入转换器,通过该转换器接入到上述电脑;该电脑配置有无线网卡,远程使用无线网络访问院内的房颤服务器;可选地,上述电脑可选用windows电脑,该转换器可选用dataOS蒲公英2.0转换器。
该多端口联动的VPN硬件模块组装方式如下:
1、向院内IT部门报备申请内网网线接口,获取该内网端口IP地址,将使用的电脑设置为该静态IP地址。
2、使用内网接入双WLAN口路由器中,链接WLAN接口,同时将双WLAN口接入dataOS蒲公英,使用蒲公英接入到电脑上。
3、使用电脑配置无线网卡,远程使用无线网络访问院内房颤服务器。
当然可理解的是,也可以使用医院自带的前置服务器方案,实现与上述多端口联动VPN类似的效果,本实施例并不对实现VPN的方式作具体限定。
通过本实施例的VPN硬件模块,一方面针对现有技术存在的多端口协同管理困难,院内各电脑无法协同管理,院内外管理割裂等问题;本实施例通过设计专门的功能和设备端口,将本发明的所有功能集成到一站式的房颤系统中进行管理。并设计开发了PC客户端、移动端APP、电脑WEB、移动端网页、微信公众号等进行一站式的协作管理。好处在于,医生可以在各个不同的端口管理同样的病人,不同的端口也都可以各自获取病人,然后各端口可以共同管理每一个端口里获得的病人数据、而且数据之间通过医院的专门VPN进行管理,通过专门的服务器架构保证协作顺畅;如图10和图11所示。
另一方面,针对现有技术存在的严重的数据安全问题,本实施例的技术方案通过设计专门的VPN和服务器架构,依托于一套院内IT部门的纯内网的服务器,将病人资料导入到该服务器中,整套技术框架的核心也全部搭载在这套服务器上,保障数据安全的同时能够更加有效的利用数据,并且可以让数据影响患者管理。
综上可知,本实施例的技术方案相比于现有技术具有如下有益效果:
针对现有技术在对数据进行处理时,存在的采集和清洗困难问题,本实施例通过根据诊断含有“房颤”、“心房纤颤”、“心房颤动”获取病人唯一识别码,并根据病人识别码进一步获取病人视图里基本信息、诊断、用药、病史、B超、病历、手术信息等其他的患者数据,通过本发明的房颤专病随访数据库标标准化的格式要求,将数据进行自动清洗、自动结构化并最终分类存储;从而实现了对数据的自动采集和清洗;
针对现有技术在对数据进行处理时,存在的质量控制困难问题,本实施例通过将病人资料按照门诊、住院、急诊、全院等进行质量控制分类,再分别计算各自的总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计、合并疾病以及这些指标的趋势,然后这些分析结果采取数据可视化的方式生成对应的统计图表;从而便于使用数据透视统一处理及质量控制。
针对现有技术在对数据进行处理时,存在的统计分析困难问题,本实施例通过设计一个基于常见的MySQL数据库的房颤多维大数据分析模块,将清洗后的数据进行表关联并选择所有表,同时字段围绕房颤这一单病种优化。使得用户操作时,不需要进行表关联和选择表,就可以采用本实施例的多维分析模块做几乎类似数据库的多维查询分析工作。
而针对现有技术存在多端口协同管理困难和数据安全问题,本实施例通过设计多端口联动的VPN硬件模块,实现了将数据库系统等其他房颤相关的多个端口布置在医院内网服务器中。从而使得医生可以在各个不同的端口管理同样的病人,不同的端口也都可以各自获取病人,然后各端口可以共同管理每一个端口里获得的病人数据、而且数据之间通过医院的专门VPN进行管理,通过专门的服务器架构保证协作顺畅;并且在保障数据安全的同时能够更加有效的利用数据。
此外,需要说明的是,本领域内的技术人员应明白,本发明技术方案可提供为方法、装置、或计算机程序产品。因此,本发明实施例可采用完全硬件实施例、完全软件实施例、或软件和硬件相结合的实施例的形式。而且,本发明实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
而且本发明实施例是参照根据本发明实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
当然可以理解的是,尽管已描述了本发明实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本发明实施例范围的所有变更和修改。
还需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上仅为本发明优选实施例而已,并不用于限制本发明,对于本领域技术人员来说,本发明可以有各种更改和变化。凡在本发明的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本发明的保护范围之内。
Claims (10)
1.一种基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述基于医院内网环境的房颤单病种随访数据库系统包括:
数据采集及清洗模块,通过设计专用的视图结构,从医院各系统数据库视图和有关的数据端口中自动识别并采集房颤单病种数据,并对采集到的数据进行清洗,然后按照预设存储分类格式将清洗后的数据进行存储;
质量控制模块,对经过所述数据采集及清洗模块处理后的数据进行质量控制分类,再分别计算各自的预设统计数据并对统计结果进行分析,然后将分析结果采用数据可视化的方式生成对应的统计图表;
多维分析模块,用于对经过所述数据采集及清洗模块处理的数据进行表关联并选择所有表;通过患者的识别号,将患者对应的各房颤单病种数据关联起来,保证每一个患者每一次的就诊信息都采用预设的标准格式记录下来;并根据用户的查询操作向用户展示相应患者对应的房颤单病种数据;
VPN硬件模块,用于实现多端口联动,使用户能够远程链接到医院网络,借助网络访问医院数据库服务器。
2.如权利要求1所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述数据采集及清洗模块对房颤单病种数据进行自动识别,采集和清洗的过程包括:
从医院各系统数据库视图和有关的数据端口中进行查询;
当患者病情资料的诊断中出现预设关键字时,获得该患者的识别码;
通过该患者的识别码关联到该患者的基本信息、病史、用药、心电图、超声以及房颤患者相关的评分;
对获得的数据通过预设结构化方式进行结构化,然后按照预设存储分类格式将结构化后的数据进行存储分类。
3.如权利要求2所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述预设关键字包括:“房颤”、“心房颤动”、“心房纤颤”中的一种或多种的组合;所述患者的识别码包括:身份证号、就诊卡号、病人ID中的一种或多种的组合。
4.如权利要求2所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,数据采集及清洗模块的数据源为第三方数据库和集成平台;
当所述数据采集及清洗模块的数据源为第三方数据库时,所述数据采集及清洗模块的采集器根据单病种的名称或icd编码从诊断表中匹配出所有属于该病种的患者的院内id,然后从各个业务系统中定期采集属于这个id的所有信息;采集完成后,采集器会将所获得的数据统一转换为JSON数据结构;
当所述数据采集及清洗模块的数据源为集成平台时,所述数据采集及清洗模块根据每一接口形式分别封装相应接口,形成多个患者id->JSON的标准接口,所述采集器的调度模块将多个患者的JSON数据汇总成列表,获得与视图的情况相同的返回结果。
5.如权利要求4所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述数据采集及清洗模块还包括数据转换器;
所述数据转换器用于,确定需要同步的数据所在的时间范围,对相应时间范围内的数据进行同步;确定新订阅的患者id,将其历史数据导入数据库中;通过各种透视操作将数据库中源数据字段与新字段建立一一对应的关系。
6.如权利要求1所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述质量控制模块按照门诊、住院、急诊、全院对经过所述数据采集及清洗模块处理后的数据进行质量控制分类;所述预设统计数据包括总人数、总人次数、科室分布、抗凝率、男女年龄横断面统计和合并疾病。
7.如权利要求6所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述质量控制模块具体用于:
对经过所述数据采集及清洗模块处理后的数据,查询出所有业务表相关的患者识别号pi、就诊识别号pv及相应的时间,并生成一个中间表dates;
以中间表dates为基础对其它表进行left join操作,并把所有结果通过union操作列在一起,统一为一个大表。
8.如权利要求1所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述多维分析模块基于MySQL数据库设计,其具体用于:
通过患者的就诊卡号、身份证号或者门诊号作为患者的唯一识别号,将患者的基本信息、病史、用药以及就诊记录关联起来,保证每一个患者每一次的就诊信息都可以用预设的标准格式记录下来;
当用户需要按患者进行查询研究的时候,首先将各个表进行缩并,确保各个表里的患者都是唯一的,然后通过逐级left join将所有表连接起来形成医生需要的一张大表。
9.如权利要求1所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述VPN硬件模块包括电脑、转换器和双WLAN口路由器;
其中,所述双WLAN口路由器的WLAN口与医院内网端口链接,所述电脑设置为所述内网端口的IP地址;所述双WLAN口路由器的LAN2口接入所述转换器,通过所述转换器接入到所述电脑;所述电脑配置有无线网卡,远程使用无线网络访问院内的房颤服务器。
10.如权利要求9所述的基于医院内网环境的房颤单病种随访数据库系统,其特征在于,所述VPN硬件模块组装方式如下:
向院内IT部门报备申请内网网线接口,获取该内网端口IP地址,将使用的电脑设置为该静态IP地址;
使用内网接入双WLAN口路由器中,链接WLAN接口,同时将双WLAN口接入转换器,使用转换器接入到电脑上;使用电脑配置无线网卡,远程使用无线网络访问院内房颤服务器。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910361838.6A CN110517738A (zh) | 2019-04-30 | 2019-04-30 | 一种基于医院内网环境的房颤单病种随访数据库系统 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201910361838.6A CN110517738A (zh) | 2019-04-30 | 2019-04-30 | 一种基于医院内网环境的房颤单病种随访数据库系统 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN110517738A true CN110517738A (zh) | 2019-11-29 |
Family
ID=68622526
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201910361838.6A Pending CN110517738A (zh) | 2019-04-30 | 2019-04-30 | 一种基于医院内网环境的房颤单病种随访数据库系统 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN110517738A (zh) |
Cited By (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111292841A (zh) * | 2020-01-21 | 2020-06-16 | 广西海数信息技术有限公司 | 一种基于精准计价的智慧就诊系统及就诊方法 |
CN112149183A (zh) * | 2020-10-19 | 2020-12-29 | 关涛 | 一种通过数据云功能实现数据“物理”切割系统 |
CN112289394A (zh) * | 2020-08-12 | 2021-01-29 | 上海柯林布瑞信息技术有限公司 | 病种库病例订阅方法及装置、存储介质、终端 |
CN112786195A (zh) * | 2021-02-01 | 2021-05-11 | 深圳市贝斯曼精密仪器有限公司 | 数据信息化导引医疗措施平台商业模式及其预测分析方法 |
Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107066816A (zh) * | 2017-03-22 | 2017-08-18 | 袁洪 | 基于临床数据的就医指导方法、装置及服务器 |
CN107169270A (zh) * | 2017-04-24 | 2017-09-15 | 江苏省苏北人民医院 | 一种慢性心血管病远程分级随访精准管理系统 |
-
2019
- 2019-04-30 CN CN201910361838.6A patent/CN110517738A/zh active Pending
Patent Citations (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107066816A (zh) * | 2017-03-22 | 2017-08-18 | 袁洪 | 基于临床数据的就医指导方法、装置及服务器 |
CN107169270A (zh) * | 2017-04-24 | 2017-09-15 | 江苏省苏北人民医院 | 一种慢性心血管病远程分级随访精准管理系统 |
Non-Patent Citations (5)
Title |
---|
小天哥: "解毒 | 距离不再成问题?蒲公英VPN组网路由器上手玩", 《HTTPS://MP.WEIXIN.QQ.COM/S/IIO-KEENVUUMPLR4SUYW0G》 * |
小天哥: "解毒 | 距离不再成问题?蒲公英VPN组网路由器上手玩", 《HTTPS://MP.WEIXIN.QQ.COM/S/IIO-KEENVUUMPLR4SUYW0G》, 15 November 2017 (2017-11-15), pages 1 - 24 * |
胡方方: "卵巢癌大数据库的建立及其病例特点", 《中国优秀硕士学位论文全文数据库 医药卫生科技辑》 * |
胡方方: "卵巢癌大数据库的建立及其病例特点", 《中国优秀硕士学位论文全文数据库 医药卫生科技辑》, no. 03, 15 March 2019 (2019-03-15), pages 1 - 31 * |
高宇等: "基于单病种数据库的临床科研系统的设计与研发", 《中国肿瘤》, pages 678 * |
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111292841A (zh) * | 2020-01-21 | 2020-06-16 | 广西海数信息技术有限公司 | 一种基于精准计价的智慧就诊系统及就诊方法 |
CN111292841B (zh) * | 2020-01-21 | 2023-07-07 | 广西海数信息技术有限公司 | 一种基于精准计价的智慧就诊系统及就诊方法 |
CN112289394A (zh) * | 2020-08-12 | 2021-01-29 | 上海柯林布瑞信息技术有限公司 | 病种库病例订阅方法及装置、存储介质、终端 |
CN112289394B (zh) * | 2020-08-12 | 2024-07-26 | 上海柯林布瑞信息技术有限公司 | 病种库病例订阅方法及装置、存储介质、终端 |
CN112149183A (zh) * | 2020-10-19 | 2020-12-29 | 关涛 | 一种通过数据云功能实现数据“物理”切割系统 |
CN112149183B (zh) * | 2020-10-19 | 2024-03-29 | 关涛 | 一种通过数据云功能实现数据“物理”切割系统 |
CN112786195A (zh) * | 2021-02-01 | 2021-05-11 | 深圳市贝斯曼精密仪器有限公司 | 数据信息化导引医疗措施平台商业模式及其预测分析方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN110517738A (zh) | 一种基于医院内网环境的房颤单病种随访数据库系统 | |
CN110415831B (zh) | 一种医疗大数据云服务分析平台 | |
CN107945086A (zh) | 一种应用于智慧城市的大数据资源管理系统 | |
CN103455886B (zh) | 基于工作流的诊疗决策支持系统 | |
CN103778346A (zh) | 医疗信息处理方法和装置 | |
CN110766332A (zh) | 一种区域卫生全面质量指标监测系统 | |
CN110070929A (zh) | 一种针对房颤单病种数据的采集和清洗方法 | |
CN105723366A (zh) | 用于准备用于搜索数据库的系统的方法以及用于执行向所连接的数据源的查询的系统和方法 | |
CN111383762A (zh) | 一种全民健康数据监管平台 | |
CN112057038A (zh) | 一种基于云平台的大数据智能健康监护系统 | |
CN115458140A (zh) | 基于医疗大数据的互联网医院智慧运营系统 | |
CN114649074A (zh) | 一种病历数据处理方法、平台和装置 | |
CN115359921B (zh) | 一种基于数据分析的医疗信息存储共享系统 | |
CN112786128A (zh) | 一种电子病历书写质量检查系统和方法 | |
WO2016175649A1 (en) | Tele-health and tele-medical facilitation system and method thereof | |
Wang et al. | Notice of Retraction: Internet of things technology applied in medical information | |
CN108538385A (zh) | 一种医学检验危急值警报系统 | |
CN110750596A (zh) | 一种医疗机构实现信息共享的流程设计方法 | |
Happe et al. | A visual approach of care pathways from the French nationwide SNDS database–from population to individual records: the e PEPS toolbox | |
CN114117053A (zh) | 病种分类模型训练方法、装置、存储介质及电子装置 | |
CN103617474A (zh) | 一种基于动态选路算法的临床路径变异管理的系统和方法 | |
CN111402975A (zh) | 一种基于智慧云平台的院外药学监护系统及方法 | |
KR101295613B1 (ko) | 다수의 진료 수행 프로세스의 임상의사결정지원시스템 구현 방법 | |
Hu | Research on monitoring system of daily statistical indexes through big data | |
CN112151134B (zh) | 一种基于大数据模型的临床研究数据管理平台及方法 |
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 | ||
RJ01 | Rejection of invention patent application after publication |
Application publication date: 20191129 |