首页> 中国专利> 一种以病人为中心的医院一体化方法及系统

一种以病人为中心的医院一体化方法及系统

摘要

本公开提供了一种以病人为中心的医院一体化方法及系统,获取患者的医疗数据,得到多个数据表;遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间和医嘱状态信息字段,得到数据库表结构,根据得到的数据库表结构构建CDR数据库;以CDR数据库为生产库进行医院业务软件模块设计,且业务软件模块运行产生和读取的患者医疗数据均在CDR数据库中;本公开以患者为中心设计数据结构,各业务软件模块共享唯一标识并进行信息关联,数据中心建设完成天然形成患者CDR数据,数据高度共享,消除了信息孤岛。

著录项

  • 公开/公告号CN112635007A

    专利类型发明专利

  • 公开/公告日2021-04-09

    原文格式PDF

  • 申请/专利权人 山东众阳健康科技集团有限公司;

    申请/专利号CN202011519269.2

  • 发明设计人 吴军;赵宁;何晓龙;李涛;

    申请日2020-12-21

  • 分类号G16H10/60(20180101);G06F16/24(20190101);G06F16/22(20190101);

  • 代理机构37221 济南圣达知识产权代理有限公司;

  • 代理人祖之强

  • 地址 250000 山东省济南市高新区新泺大街1166号奥盛大厦一号楼12层

  • 入库时间 2023-06-19 10:32:14

说明书

技术领域

本公开涉及数据处理技术领域,特别涉及一种以病人为中心的医院一体化方法及系统。

背景技术

本部分的陈述仅仅是提供了与本公开相关的背景技术,并不必然构成现有技术。

医院的本质是治病救人,医院的信息化建设也是一个系统性、体系性的事情,不是软件模块的堆积。

但是,发明人发现,很多医院和信息化公司往往是面向管理建设医院信息化,或者面向条线业务、面向科室建设医院信息系统,再试图通过集成模式,即以技术的手段(集成平台)去组装、联通各系统形成患者CDR数据,因各系统本身注重的是功能和满足条线业务、没有考虑医院整体一体化,再加上设计理念不同、技术实现不同等原因,往往行不通,进而给医院带来了一系列的问题,具体如下:

(1)数据是分散的,医院难以形成患者CDR数据,或者只能串联一部分患者数据,存在数据缺失、数据串联不起来,从而难以充分地进行数据利用,难以发挥数据在医院的精细化管理、服务、科研、人工智能和大数据应用等工作中的价值;

(2)集成模式下各系统只能通过接口实现信息交互与共享,各系统之间接口多;且随着政策的变动和需求的不断增长必然会产生新的接口需求,众多接口成本高、调度难。

发明内容

为了解决现有技术的不足,本公开提供了一种以病人为中心的医院一体化方法及系统,以患者为中心设计数据结构,各业务软件模块共享唯一标识并进行信息关联,数据中心建设完成天然形成患者CDR数据;数据高度共享,消除了信息孤岛,并且能够围绕电子病历将患者的基本信息、医嘱、护理记录、病历、检验检查报告、费用等相关信息展现给医师,能更清晰的绘制患者画像,给医师做出良好的治疗方案提供决策依据;同时各业务软件模块中的患者信息被盘活,不止从本次治疗维度还能从时间维度管理居民全生命周期的健康。

为了实现上述目的,本公开采用如下技术方案:

本公开第一方面提供了一种以病人为中心的医院一体化方法。

一种以病人为中心的医院一体化方法,包括以下步骤:

获取患者的医疗数据,得到多个数据表;

遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间和医嘱状态信息字段,得到数据库表结构,根据得到的数据库表结构构建CDR数据库;

以CDR数据库为生产库进行医院业务软件模块设计,且业务软件模块运行产生和读取的患者医疗数据均在CDR数据库中。

作为可能的一些实现方式,CDR数据库,包括:

在CDR数据库为各业务软件模块分配单独的数据库用户,并且分配涉及数据库实例的增删改查权限;

CDR数据库中各表所需要的数据由对应业务软件模块直接采集和存储;

各业务软件模块所需要的数据直接从CDR数据库对应分类实例下的表中查询获取。

作为进一步的限定,非医疗健康数据,在当前CDR数据库基础上扩建对应数据表和分类实例,并分配给各业务软件模块相应的读写权限。

作为进一步的限定,业务软件模块的设计包括患者统一、资源统一、机构和人员统一、字典统一,针对每种统一数据加入唯一标识,且只存储唯一一份,各业务软件模块共同使用同一份统一数据。

作为进一步的限定,业务软件模块存储数据使用统一格式,对于加密的数据,采用同一加密算法。

作为可能的一些实现方式,业务软件模块的功能以患者为中心进行数据组织,并且以医生使用的电子病历系统为核心进行数据的展现。

作为进一步的限定,创建各微服务,每个微服务只负责一个关联查询功能,以患者ID和医嘱ID为索引关联起本业务的信息;

以时间为主线串联组合各微服务,形成时间维度的业务分类;

以医生关心视角在电子病历系统中展示由上一步业务分类组合而成的患者全面临床信息。

本公开第二方面提供了一种以病人为中心的医院一体化系统。

一种以病人为中心的医院一体化系统,包括CDR数据库和至少一个与CDR数据库数据交互的业务软件模块,业务软件模块以CDR数据库为生产库设计,且业务软件模块运行产生和读取的患者医疗数据均在CDR数据库中;

其中,CDR数据库的构建,包括以下步骤:

获取患者的临床医疗信息数据,得到多个数据表,遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间和医嘱状态信息字段,得到数据库表结构,根据得到的数据库表结构构建CDR数据库。

作为可能的一些实现方式,CDR数据库,包括:

在CDR数据库为各业务软件模块分配单独的数据库用户,并且分配涉及数据库实例的增删改查权限;

CDR数据库中各表所需要的数据由对应业务软件模块直接采集和存储;

各业务软件模块所需要的数据直接从CDR数据库对应分类实例下的表中查询获取。

作为进一步的限定,非医疗健康数据,在当前CDR数据库基础上扩建对应数据表和分类实例,并分配给各业务软件模块相应的读写权限。

作为进一步的限定,业务软件模块的设计包括患者统一、资源统一、机构和人员统一、字典统一,针对每种统一数据加入唯一标识,且只存储唯一一份,各业务软件模块共同使用同一份统一数据。

作为进一步的限定,业务软件模块存储数据使用统一格式,对于加密的数据,采用同一加密算法。

作为可能的一些实现方式,业务软件模块的功能以患者为中心进行数据组织,并且以医生使用的电子病历系统为核心进行数据的展现。

作为进一步的限定,创建各微服务,每个微服务只负责一个关联查询功能,以患者ID和医嘱ID为索引关联起本业务的信息;

以时间为主线串联组合各微服务,形成时间维度的业务分类;

以医生关心视角在电子病历系统中展示由上一步业务分类组合而成的患者全面临床信息。

与现有技术相比,本公开的有益效果是:

1、本公开提供的方法或系统,从全院一体化软件系统建设的角度出发,以患者的就诊流程为业务主线,串联起全院业务,进行全院的信息化系统的统筹规划;各业务系统不再各自为战,不再是功能多而不精,而是其功能设计和需求根据医院的整体管理通盘考虑,以一个相互紧密结合的形式不断积累,整体提升全院信息化水平。

2、本公开提供的方法或系统,以患者为中心设计数据结构,各业务软件模块共享唯一标识并进行信息关联,数据中心建设完成天然形成患者CDR数据;数据高度共享,消除了信息孤岛,并且能够围绕电子病历将患者的基本信息、医嘱、护理记录、病历、检验检查报告、费用等相关信息展现给医师,能更清晰的绘制患者画像,给医师做出良好的治疗方案提供决策依据;同时各业务软件模块中的患者信息被盘活,不止从本次治疗维度还能从时间维度管理居民全生命周期的健康。

3、本公开提供的方法或系统,数据存储合理,减少了非必要接口的量,为医院节省巨额的接口费,各业务软件模块之间就已经实现了无缝对接,数据标准统一,数据传输环节少,传输损耗也少。也可以充分发挥虚拟化和超融合的价值,大幅度降低硬件投入。

本公开附加方面的优点将在下面的描述中部分给出,部分将从下面的描述中变得明显,或通过本公开的实践了解到。

附图说明

构成本公开的一部分的说明书附图用来提供对本公开的进一步理解,本公开的示意性实施例及其说明用于解释本公开,并不构成对本公开的不当限定。

图1为本公开实施例1提供的一种以病人为中心的医院一体化方法的流程示意图。

图2为本公开实施例1提供的CDR数据库构建方法示意图。

图3为本公开实施例1提供的数据表与业务的对应关系示意图。

图4为本公开实施例1提供的数据库表结构示意图。

图5为本公开实施例1提供的业务软件模块的设计方法示意图。

图6为本公开实施例1提供的患者全面临床信息示意图。

具体实施方式

下面结合附图与实施例对本公开作进一步说明。

应该指出,以下详细说明都是示例性的,旨在对本公开提供进一步的说明。除非另有指明,本文使用的所有技术和科学术语具有与本公开所属技术领域的普通技术人员通常理解的相同含义。

需要注意的是,这里所使用的术语仅是为了描述具体实施方式,而非意图限制根据本公开的示例性实施方式。如在这里所使用的,除非上下文另外明确指出,否则单数形式也意图包括复数形式,此外,还应当理解的是,当在本说明书中使用术语“包含”和/或“包括”时,其指明存在特征、步骤、操作、器件、组件和/或它们的组合。

在本公开中,术语如“上”、“下”、“左”、“右”、“前”、“后”、“竖直”、“

在不冲突的情况下,本公开中的实施例及实施例中的特征可以相互组合。

实施例1:

本公开实施例1提供了一种以病人为中心的医院一体化方法,包括以下步骤:

获取患者的医疗数据,得到多个数据表;

遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间和医嘱状态信息字段,得到数据库表结构,根据得到的数据库表结构构建CDR数据库;

以CDR数据库为生产库进行医院业务软件模块设计,且业务软件模块运行产生和读取的患者医疗数据均在CDR数据库中。

进一步的,业务软件模块的功能以患者为中心进行数据组织,并且以医生使用的电子病历系统为核心进行数据的展现。

如图1所示,具体的包括以下步骤:

S1:以病人为中心,串联各科室业务,按以时间为主线可串联、以医嘱为轴可闭环为原则,进行患者CDR数据库模型的设计。

S2:以CDR数据库为生产库进行医院业务软件模块统一规划和开发,保证业务软件模块运行产生和读取的患者医疗健康数据是在CDR数据库中,做到全面系统的病人信息采集和存储。业务软件模块产生或需要的非医疗健康数据,可在CDR数据库基础上进行扩建数据库表。

S3:业务软件模块的功能开发,统筹以患者为中心进行数据组织,以医生使用的电子病历系统为核心进行数据全面展现。其余系统模块根据各自领域业务的实际需要组织相应数据进行展现。

如图2所示,S1的具体实施步骤如下:

S1.1:依据《电子病历临床文档基础模板数据集标准》,结合实际医院业务,串联各科室,按以时间为主线可串联、以医嘱为轴可闭环为原则,穷举患者所受服务相关内容,设计数据表、表字段。

数据表包含但不局限于以下各举例表:患者信息表,门诊挂号表、门诊医嘱表、门诊病历表、入院登记表、入院记录表、住院医嘱表、病程记录表、手术记录表、会诊记录表、检验申请单、检验报告表、检查申请单、影像报告表等等,如图3所示;

每个表中根据实际业务所需信息和软件开发设计设置每个表的字段。以上各表可以分类到以下各实例分类中存储:基础信息类、配置类、事件日志类、临床诊疗类、医技类、治疗类、监控和上报类、统计分析类等,实例分类包括但不局限于以上分类实例。

例如门诊医嘱表包含的字段有:门诊主医嘱ID、医院ID、对应的挂号ID、医嘱主编号、医嘱排序序号、就诊卡ID、开单医生编号、开单科室编号、开单时间、签名医生所在科室、签名医生编号、签名时间、执行科室编号、执行人员编号、执行时间、医嘱状态、医嘱属性、医嘱项目ID、医嘱项目名称、项目单价、数量、数量单位、合计金额、规格、剂量、剂量单位、服用天数、草药付数、用法的系统id、频率的系统id、处方类别的系统id、指定类型、费别类型ID、费别个人负担比例、停用标志、如果停用说明该遗嘱不收费、备注、医嘱执行速度、医嘱执行速度描述即时间录入的数值和单位的组合中间以空格隔开、皮试结果、停止时间、停止医生、停止医生科室、处方编号、草药用法ID等等,门诊医嘱表放在临床诊疗实例下;各表字段包含但不局限于以上举例字段,其他表以此类推。

S1.2:遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间、医嘱状态信息字段。

如图4所示,例如门诊医嘱表加入患者ID,就可以根据患者ID查询该患者所有的医嘱记录、医嘱状态。检验申请单表加入患者ID、医嘱ID、医嘱时间、状态,就可以通过患者ID查其所有的检验申请单记录,通过医嘱ID查询当前该检验医嘱的执行情况、持续时长等等。

检验报告表加入患者ID、医嘱ID、医嘱时间、状态、申请单ID,可以通过患者ID查询其所有的检验报告列表,通过医嘱ID可查询该医嘱对应的检验报告的详情、结果、状态,通过申请单ID查该检验事件对应的检验报告。加入唯一标识包含但不局限于以上举例方法,其他表以此类推。

S1.3:根据设计的数据库表结构,通过技术工具转换为实际的物理库,例如使用PowerDesigner工具,将数据模型转换成Oracle、MySQL、SQL SERVER或PostgreSQL等物理数据库,该步包含但不局限于以上举例使用的工具和数据库。

如图5所示,S2的具体实施步骤如下:

S2.1:在CDR数据库为各业务软件模块分配单独的数据库用户,并且分配涉及数据库实例的增删改查权限。CDR数据库中各表所需要的数据由对应业务软件模块直接采集和存储。各业务软件模块所需要的数据直接从CDR数据库对应分类实例下的表中查询获取。

S2.2:非医疗健康数据,例如用户、角色、权限、菜单等等,在当前CDR数据库基础上扩建对应数据表和分类实例。并分配给各业务软件模块相应的读写权限。

S2.3:各业务软件模块规划和开发要患者统一,资源统一,机构、人员统一,字典统一。针对每种统一数据加入唯一标识,且只存储唯一一份。各业务软件模块共同使用同一份统一数据。所述统一数据包括但不限于以下内容:人员(医生)、用户、权限、药品、材料、设备、号源、诊断编码字典、医嘱字典等等。

S2.4:各业务软件模块存储数据使用公开统一格式,以保证其他模块能够共享使用。对于涉及加密的数据,如密码,采用同一加密算法。

S3:的具体实施步骤如下:

S3.1:创建各微服务,每个微服务只负责一个关联查询功能,即以患者ID和医嘱ID为索引关联起本业务的信息。各微服务包含但不限于以下查询:患者基本信息、医嘱记录、医嘱执行记录、医嘱结果记录、检验申请记录、检验结果记录、检查申请记录、检查结果记录、门诊病历记录、入院记录、出院记录、病程记录、心电图记录等等。

S3.2:以时间为主线串联组合各微服务,形成时间维度的业务分类。各业务分类包含但不限于以下分类:基础信息、医嘱、现有及历史病历、出入院记录、检验、检查、心电、病理、护理记录、体温单、手术记录、输血、会诊、上报等等。

S3.3:以医生关心视角在电子病历系统中展示由上一步业务分类组合而成的患者全面临床信息,患者全面临床信息中各业务分类的组合方式包含但不限于如图6所示的方式。

S3.4:其余业务软件模块根据各自领域业务的实际需要组织相应数据进行展现。

实施例2:

本公开实施例2提供了一种以病人为中心的医院一体化系统。

一种以病人为中心的医院一体化系统,包括CDR数据库和至少一个与CDR数据库数据交互的业务软件模块,业务软件模块以CDR数据库为生产库设计,且业务软件模块运行产生和读取的患者医疗数据均在CDR数据库中;

其中,CDR数据库的构建,包括以下步骤:

获取患者的临床医疗信息数据,得到多个数据表,遍历每个数据表,根据以患者为中心的关联关系,加入患者唯一标识、医嘱唯一标识、医嘱时间、医疗事件唯一标识、医疗事件时间和医嘱状态信息字段,得到数据库表结构,根据得到的数据库表结构构建CDR数据库;所述系统具有天然形成临床数据中心、数据集中、数据高度共享等优点。

一体化系统是指全院所有信息化系统视为一体,统为一个系统,数据共享;

业务软件模块是指在全院一体化系统体系下,原各科室的业务系统不再以独立的业务系统存在,而是作为一体化系统下的一个模块,与其他业务软件模块相互配合,最终搭建成全院一体化系统。

具体的一体化系统的设计方法和工作方法与实施例1提供的相同,这里不再赘述。

以上所述仅为本公开的优选实施例而已,并不用于限制本公开,对于本领域的技术人员来说,本公开可以有各种更改和变化。凡在本公开的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本公开的保护范围之内。

去获取专利,查看全文>

相似文献

  • 专利
  • 中文文献
  • 外文文献
获取专利

客服邮箱:kefu@zhangqiaokeyan.com

京公网安备:11010802029741号 ICP备案号:京ICP备15016152号-6 六维联合信息科技 (北京) 有限公司©版权所有
  • 客服微信

  • 服务号