CN120811775B - 医疗管理系统及其数据访问方法 - Google Patents
医疗管理系统及其数据访问方法Info
- Publication number
- CN120811775B CN120811775B CN202511281998.1A CN202511281998A CN120811775B CN 120811775 B CN120811775 B CN 120811775B CN 202511281998 A CN202511281998 A CN 202511281998A CN 120811775 B CN120811775 B CN 120811775B
- Authority
- CN
- China
- Prior art keywords
- data
- service
- layer
- access
- target
- 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.)
- Active
Links
Landscapes
- Medical Treatment And Welfare Office Work (AREA)
- Storage Device Security (AREA)
Abstract
本申请提供了一种医疗管理系统及其数据访问方法,涉及医疗技术领域。该方法包括:在访问层生成业务访问请求,将业务访问请求发送至服务层;在服务层根据业务访问请求调用与目标业务对应的目标业务模块,并将业务访问请求转发至业务应用层;在业务应用层构建数据访问请求,并将数据访问请求发送至数据层;在数据层基于数据访问请求获取与目标业务对应的目标业务数据,并对目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的目标业务数据返回访问层;在访问层对加密后的目标业务数据进行解密处理,并将解密后的目标业务数据在访问平台上展示,从而解决了相关技术中存在的在不同接入环境之间难以实现安全、可控、实时数据访问的问题。
Description
技术领域
本申请涉及医疗技术领域,具体而言,本申请涉及一种医疗管理系统及其数据访问方法。
背景技术
随着医疗信息化水平的不断提升,医疗管理系统逐渐呈现出多层架构、分布式部署和跨机构协作的趋势,能够支持不同医疗机构、不同接入环境之间的数据交互。然而,现有的数据访问方式在跨环境访问场景中仍存在较多不足。
具体地,出于业务数据安全与合规性的考虑,医疗管理系统通常需要对访问路径、访问权限进行严格控制,这在一定程度上增加了数据访问的复杂度,使得用户在非本地接入环境下难以及时获取所需业务数据。
基于此,在不同接入环境之间难以实现安全、可控、实时数据访问成为了亟需解决的问题。
发明内容
本申请各实施例提供了一种医疗管理系统及其数据访问方法、装置、计算机设备、存储介质及计算机程序产品,可以解决相关技术中存在的在不同接入环境之间难以实现安全、可控、实时数据访问的问题。所述技术方案如下:
根据本申请的一个方面,一种医疗管理系统的数据访问方法,所述系统包括访问层、服务层、业务应用层及数据层;其中,所述数据层部署于第一网络环境,所述访问层部署于与所述第一网络环境相互隔离的第二网络环境;所述方法包括:在所述访问层为用户提供访问平台,并基于所述用户在所述访问平台的业务访问操作,生成业务访问请求,将所述业务访问请求发送至所述服务层;所述业务访问请求用于指示所述用户请求访问的目标业务;在所述服务层根据所述业务访问请求调用与所述目标业务对应的目标业务模块,并根据所述目标业务模块将所述业务访问请求转发至所述业务应用层;在所述业务应用层根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相应的数据访问请求,并将所述数据访问请求发送至所述数据层;所述数据访问请求用于向所述数据层请求获取与所述目标业务模块相对应的目标业务数据;在所述数据层基于所述数据访问请求获取与所述目标业务对应的目标业务数据,并对所述目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的所述目标业务数据返回所述访问层;其中,所述双单向隔离交换技术用于在所述第一网络环境与所述第二网络环境之间实现业务数据的单向安全传输;在所述访问层对所述加密后的所述目标业务数据进行解密处理,并将解密后的所述目标业务数据在所述访问平台上展示,使得所述用户在所述访问平台查看所述目标业务数据。
根据本申请的一个方面,一种医疗管理系统的数据访问装置,所述系统包括访问层、服务层、业务应用层及数据层;其中,所述数据层部署于第一网络环境,所述访问层部署于与所述第一网络环境相互隔离的第二网络环境;所述装置包括:业务访问模块,用于在所述访问层为用户提供访问平台,并基于所述用户在所述访问平台的业务访问操作,生成业务访问请求,将所述业务访问请求发送至所述服务层;所述业务访问请求用于指示所述用户请求访问的目标业务;业务调用模块,用于在所述服务层根据所述业务访问请求调用与所述目标业务对应的目标业务模块,并根据所述目标业务模块将所述业务访问请求转发至所述业务应用层;数据访问模块,用于在所述业务应用层根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相应的数据访问请求,并将所述数据访问请求发送至所述数据层;所述数据访问请求用于向所述数据层请求获取与所述目标业务模块相对应的目标业务数据;数据获取模块,在所述数据层基于所述数据访问获取与所述目标业务对应的目标业务数据,并对所述目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的所述目标业务数据返回至所述访问层;其中,所述双单向隔离交换技术用于在所述第一网络环境与所述第二网络环境之间实现业务数据的单向安全传输;数据展示模块,用于在所述访问层对所述加密后的所述目标业务数据进行解密处理,并将解密后的所述目标业务数据在所述访问平台上展示,使得所述用户在所述访问平台查看所述目标业务数据。
根据本申请的一个方面,一种医疗管理系统,所述系统包括访问层、服务层、业务应用层及数据层;所述访问层,用于为用户提供访问平台,并基于所述用户在所述访问平台的业务访问操作,生成业务访问请求,将所述业务访问请求发送至所述服务层;接收所述数据层发送的加密后的目标业务数据,对所述加密后的所述目标业务数据进行解密处理,并将解密后的所述目标业务数据在所述访问平台上展示,使得所述用户在所述访问平台查看所述目标业务数据;所述业务访问请求用于指示所述用户请求访问的目标业务;所述服务层,用于根据所述业务访问请求调用对应的目标业务模块,并根据所述目标业务模块将所述业务访问请求转发至所述业务应用层;所述业务应用层,用于根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相对应的数据访问请求,并将所述数据访问请求发送至所述数据层;所述数据访问请求用于向所述数据层请求获取与所述目标业务模块相对应的目标业务数据;所述数据层,用于接收所述数据访问请求,基于所述数据访问请求获取与所述目标业务对应的目标业务数据,并对所述目标业务数据进行加密处理,通过双单向隔离交换技术将所述加密后的所述目标业务数据返回至所述访问层;其中,所述数据层部署于第一网络环境,所述访问层部署于与所述第一网络环境相互隔离的第二网络环境;所述双单向隔离交换技术用于在所述第一网络环境与所述第二网络环境之间实现业务数据的单向安全传输。
根据本申请的一个方面,一种计算机设备,包括至少一个处理器以及至少一个存储器,其中,所述存储器上存储有计算机程序,所述计算机程序被所述处理器执行时实现如上所述的医疗管理系统的数据访问方法。
根据本申请的一个方面,一种存储介质,其上存储有计算机程序,所述计算机程序被一个或多个处理器执行时实现如上所述的医疗管理系统的数据访问方法。
根据本申请的一个方面,一种计算机程序产品,包括计算机程序,所述计算机程序被一个或多个处理器执行时实现如上所述的医疗管理系统的数据访问方法。
本申请提供的技术方案带来的有益效果是:
在上述技术方案中,实现了在医疗管理系统中跨不同网络环境对目标业务数据的安全访问与展示,在访问层、服务层、业务应用层和数据层之间构建了完整的业务访问链路,确保用户在外部网络环境中发起的业务访问请求能够在经过认证、路由和数据生成后,安全地传输至内部网络环境的数据层进行处理,并将加密后的目标业务数据单向回传至访问层进行解密和展示,从而能够有效地解决相关技术中存在的在不同接入环境之间难以实现安全、可控、实时数据访问的问题。
附图说明
为了更清楚地说明本申请实施例中的技术方案,下面将对本申请实施例描述中所需要使用的附图作简单地介绍。显而易见地,下面描述中的附图仅仅是本申请的一些实施例,对于本领域技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他的附图。
图1是根据本申请所涉及的医疗管理系统的结构框图;
图2是根据一示例性实施例示出的一种医疗管理系统的系统框图;
图3是根据一示例性实施例示出的一种医疗管理系统的数据访问方法的流程图;
图4是图3对应实施例中步骤310在一个实施例的流程图;
图5是图3对应实施例中步骤350在一个实施例的流程图;
图6是图5对应实施例中步骤351在一个实施例的流程图;
图7是图6对应实施例所涉及的双单向隔离交换技术的具体实现示意图;
图8是图3对应实施例中医疗管理系统的数据访问方法在一个实施例的流程图;
图9至图10是一应用场景中一种医疗管理系统的数据访问方法的具体实现示意图;
图11是根据一示例性实施例示出的一种医疗管理系统的数据访问装置的结构框图。
具体实施方式
下面详细描述本申请的实施例,所述实施例的示例在附图中示出,其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的,仅用于解释本申请,而不能解释为对本申请的限制。
本技术领域技术人员可以理解,除非特意声明,这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是,本公开的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件,但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解,当我们称元件被“连接”或“耦接”到另一元件时,它可以直接连接或耦接到其他元件,或者也可以存在中间元件。此外,这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
如前所述,现有的数据访问方式在跨网络环境下仍存在较多不足。
一方面,为保障敏感业务数据的安全,发明人想到,能够将医疗管理系统的不同功能模块部署在相互隔离的网络环境中。然而,这种隔离在一定程度上提升了数据安全性,但也增加了跨网络访问的复杂度,用户往往无法直接、便捷地从外部环境访问所需的业务数据。
另一方面,发明人发现,现有医疗管理系统在安全访问控制方面缺乏统一机制,不同业务模块之间的访问入口和认证流程相互独立,导致用户需要多次登录、重复认证,增加了操作负担,同时也可能因认证标准不一致而产生安全隐患。
此外,在高并发访问场景下,由于缺乏跨层级的资源动态调度能力,当某一系统层出现资源消耗过高的情况时,可能引发访问延迟、请求阻塞等问题,影响整体运行效率与稳定性。
由上可知,相关技术中仍存在在不同接入环境之间难以实现安全、可控、实时数据访问的缺陷。
为此,本申请提供的医疗管理系统的数据访问方法,能够有效地提升医疗管理系统的数据访问的安全性,相应地,该医疗管理系统的数据访问方法适用于医疗管理系统的数据访问装置,该医疗管理系统的数据访问装置可部署于电子设备,该电子设备可以是配置冯诺依曼体系结构的计算机设备,例如,该计算机设备包括台式电脑、笔记本电脑、服务器等。
为使本申请的目的、技术方案和优点更加清楚,下面将结合附图对本申请实施方式作进一步地详细描述。
请参阅图1,图1为一种医疗管理系统的结构框图,如图1所示,该医疗管理系统100包括访问层110、服务层130、业务应用层150及数据层170。其中,数据层170部署于第一网络环境,访问层110部署于与第一网络环境相互隔离的第二网络环境。
访问层110,用于为用户提供访问平台,并基于用户在访问平台的业务访问操作,生成业务访问请求,将业务访问请求发送至服务层;业务访问请求用于指示用户请求访问的目标业务;接收数据层发送的加密后的目标业务数据,对加密后的目标业务数据进行解密处理,并将解密后的目标业务数据在访问平台上展示,使得用户在访问平台查看目标业务数据。其中,访问层110可通过用户终端上安装的移动应用(APP)、微信公众号、支付宝生活号等多种方式为用户提供访问平台。
服务层130,用于根据业务访问请求调用对应的目标业务模块,并根据目标业务模块将业务访问请求转发至业务应用层。
业务应用层150,用于根据业务访问请求所指示的目标业务,构建与目标业务模块相对应的数据访问请求,并将数据访问请求发送至数据层;数据访问请求用于向数据层请求获取与目标业务模块相对应的目标业务数据。
数据层170,用于接收数据访问请求,基于数据访问请求获取与目标业务对应的目标业务数据,并对目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的目标业务数据返回至访问层。
其中,数据层部署于第一网络环境,访问层部署于与第一网络环境相互隔离的第二网络环境;双单向隔离交换技术用于在第一网络环境与第二网络环境之间实现业务数据的单向安全传输。
在一个可能的实现方式,医疗管理系统还可以包括基础层,基础层用于获取访问层、服务层、业务应用层及数据层的资源使用信息;基于资源使用信息,为数据层分配或调整为访问层、服务层、业务应用层与数据层之间的数据传输分配资源;若检测到访问层、服务层、业务应用层或数据层的资源使用超过设定阈值,则重新通过对访问层、服务层、业务应用层和/或数据层进行资源分配。
在一个可能的实现方式,图2示出了一种医疗管理系统的系统框图,如图2所示,该系统按照功能逻辑自上而下依次包括访问层、服务层、业务应用层、数据层以及基础层,各层之间通过信息安全机制和数据标准规范进行交互。
访问层:用于面向终端用户(如医生、患者、第三方医疗服务机构等)提供统一的访问入口,可通过移动应用(APP)、微信公众号、支付宝生活号等多种方式接入。访问层负责承载业务访问模块,能够为用户提供访问平台,并基于用户在访问平台的业务访问操作生成业务访问请求,并将该请求发送至服务层。
服务层:用于对来自访问层的业务访问请求进行接收与处理,提供统一账户、统一认证、统一登录和统一服务等功能。服务层承载业务调用模块,该模块可根据业务访问请求调用对应的目标业务模块,并将请求转发至业务应用层,实现访问控制与业务逻辑调度。
业务应用层:包括多种面向医疗业务的功能应用模块,例如预约挂号、在线咨询、影像检查、报告查询、健康档案、医保结算等。业务应用层承载数据访问模块,能够根据业务访问请求生成数据访问请求,并将该数据访问请求发送至数据层,以便获取对应的业务数据。
数据层:负责业务数据的存储、管理与处理,包括数据采集、数据控制、数据存储、数据分析、数据挖掘等功能。数据层承载数据获取模块,该模块可基于数据访问请求查找对应的目标业务数据,并对目标业务数据进行加密处理,然后通过双单向隔离交换技术将加密数据传输至访问层,实现业务数据在不同接入环境间的单向安全传输。
在一个可能的实现方式,数据层包括数据采集模块,可以用于采集超声设备输出的实时视频信号,并保障视频信号在传输过程中的低时延、高可靠及高安全性。
具体而言,数据采集模块通过HDMI接口采集超声机的实时画面,利用内置采集芯片执行信号均衡、抖动抑制,并通过DMA直接内存访问方式将视频帧送入硬编码单元;采用Slice硬编码方式将单帧视频划分为多个独立 Slice,在网络条件不佳时仅重传丢失部分,缩短恢复时间并减少错误传播。
采集后的视频流通过通途视频传输协议进行传输,该协议基于内存语义优化和零拷贝传输技术,结合RDMA将数据直接写入网络缓冲区,降低CPU占用并减少延迟;传输过程中集成TLS加密握手并支持国密SM1、SM2、SM3、SM4、SM6算法,实现视频流加密与完整性校验。
数据展示模块:可以部署于访问层,用于对接收到的加密业务数据进行解密处理,并在访问平台上进行展示,使用户能够在访问平台查看所需的目标业务数据。
基础层:为上述各层提供云计算资源、网络资源、存储资源及管理功能,并对资源使用情况进行监控和动态调度,以保证系统在高并发或负载变化情况下的稳定运行。
在一个可能的实现方式,基础层可部署于云端或混合云环境中,基于应用层与物理层解耦的架构设计,通过应用接口抽象层、插件式调度策略引擎、调度策略配置层及资源实时感知层,实现对系统内各类异构算力资源(包括CPU、GPU、DPU、FPGA、高速存储节点等)的按需分配与动态调度。
其中,应用接口抽象层用于屏蔽底层硬件架构差异,为访问层、服务层、业务应用层及数据层提供统一的资源请求与交互接口,使得各层业务模块无需关心底层算力的具体部署细节,仅需以业务友好的方式描述其算力需求(如实时性要求、并发访问量、带宽需求、算法类型等)。
插件式调度策略引擎可以根据业务模块的实时性、吞吐量及算法类型需求,匹配最优的异构算力资源组合,并支持在不同业务场景下动态更换调度策略。例如,在超声视频实时分析场景中,可优先分配具备视频编解码硬件加速的DPU与GPU节点;在批量数据分析场景中,可优先分配高存储吞吐的NVME-oF节点。
调度策略配置层可以提供对插件式调度策略的管理与配置能力,允许系统管理员根据目标业务场景配置不同阶段的算力分配规则与优先级,例如限制单任务最大资源占用比例、优化特定资源(如GPU)的利用率、或为关键业务保留冗余算力池。
资源实时感知层可以实时收集分布式算力节点的健康状态、带宽利用率、硬件拓扑结构及运行负载情况,并将感知结果反馈给调度策略引擎,以实现资源分配的动态优化。例如,当检测到某节点负载过高或硬件故障时,可自动将任务迁移至其他健康节点,从而保障业务的连续性与稳定性。
在一个可能的实现方式中,基础层还可接入第三方安全平台,提供国密SM1、SM4、SM2、SM3、SM6等密码算法的密钥、令牌及证书管理能力,用于保障跨层数据传输及访问控制的安全性。
请参阅图3,本申请实施例提供了一种医疗管理系统的数据访问方法,该方法适用于图1所示出的医疗管理系统。
在下述方法实施例中,为了便于描述,以该方法各步骤的执行主体为医疗管理系统为例进行说明,但是并非对此构成具体限定。
如图3所示,该方法可以包括以下步骤:
步骤310,在访问层为用户提供访问平台,并基于用户在访问平台的业务访问操作,生成业务访问请求,将业务访问请求发送至服务层。
其中,业务访问请求用于指示用户请求访问的目标业务。
首先说明的是,本实施例的数据访问方法适用于医疗管理系统,该医疗管理系统包括访问层、服务层、业务应用层及数据层;其中,数据层部署于第一网络环境,访问层部署于与第一网络环境相互隔离的第二网络环境。
具体而言,访问层可通过部署于第二网络环境的访问服务器、门户系统或客户端应用,为用户提供统一的访问入口,即访问平台。访问平台可以为基于Web的门户页面,也可以为安装在用户终端(如智能手机、平板电脑、个人电脑等)上的客户端应用程序,用于接收用户的业务操作指令。
在本实施例中,第一网络环境可以为部署有医疗管理系统数据层的内部安全网络环境,通常为医疗机构内部的信息专网、医院局域网、或通过专线接入的卫生健康行业内网。第一网络环境与互联网物理隔离,用于存储和处理涉及患者隐私信息、诊疗数据、电子病历等敏感数据。
可以理解,第一网络环境是承载医院核心业务系统和敏感数据的内部网络,可以具有以下特征:与互联网隔离,仅通过安全接入点或隔离设备与外部网络进行有限数据交换;内部设备之间通过高速局域网(LAN)互联,确保数据传输低延迟与高可靠性;网络拓扑可采用多层结构(核心层、汇聚层、接入层),并部署多级防护策略。
第二网络环境可以为部署有医疗管理系统访问层的外部网络环境,通常为可通过互联网接入的公共网络环境,例如医院对公众开放的互联网访问平台、患者服务网站、移动应用平台等。该网络环境用于为终端用户(如医生、患者、第三方医疗服务机构等)提供业务访问入口,以便发起业务访问请求并查看返回的数据。
可以理解,与第一网络环境相对,第二网络环境主要承载对外开放的医疗服务访问层。
进一步地,第一网络环境与第二网络环境之间可以通过双单向隔离交换技术实现数据的单向安全传输,防止第一网络环境被外部直接访问或入侵。
在用户通过访问平台执行业务访问操作时,访问层可采集与该业务访问操作相关的操作参数,例如:目标医院标识、业务数据类型、用户身份认证信息等,并基于上述操作参数构造业务访问请求。业务访问请求可以包含用户操作所指向的业务对象信息,还可包括后续访问控制和数据调度所需的上下文信息。
在一个可能的实现方式,业务访问请求包括目标医院标识和业务数据类型,目标医院标识用于指示需要访问的目标医院的数据层,业务数据类型用于指示需要访问的具体业务数据类别;用户身份认证信息可用于在后续的服务层或业务应用层解析得到目标成员信息,从而确保数据访问的合法性与准确性。
在生成业务访问请求后,访问层将该请求发送至服务层。为保证跨网络环境的安全传输,访问层与服务层之间可通过加密通信通道(例如TLS/SSL)进行数据交互,并可在传输过程中附加访问令牌或会话密钥,以实现对业务访问请求来源和完整性的验证。
在一个可能的实现方式,如图4所示,步骤310还可以包括以下步骤:
步骤311,通过5G双域专网在通信网元中建立公共通信域与安全通信域。
其中,安全通信域与数据层所在的第一网络环境连通,公共通信域与访问层所在的第二网络环境连通。
具体而言,通信网元可以为支持5G专网功能的核心网设备,例如5G核心网的用户面功能节点或多接入边缘计算节点。
在本实施例中,通信网元可在同一硬件平台或虚拟化平台上划分两个相互隔离的逻辑域:
安全通信域:与数据层所在的第一网络环境连通,用于承载涉及敏感业务数据的安全访问通道。
公共通信域:与访问层所在的第二网络环境连通,用于承载外部互联网资源访问等非敏感数据流量。
那么,通过5G双域专网的网络切片或多接入技术,可在物理链路上同时建立两类通信域,实现对不同业务流量的分域管理与隔离传输,从而保证医疗数据访问的安全性与业务处理的高效性。
在一个可能的实现方式,医院内部设备主要部署于第一网络环境内,该网络环境通常为医院的内部信息专网或通过专线接入的行业内网,与公共互联网物理隔离,具备较高的安全防护等级。医院内部设备包括但不限于:服务器类设备(例如,医疗管理系统数据服务器)、网络与安全设备和终端类设备(仅限院内使用的终端,例如,医生工作站、护士站终端、医技科室查询终端等等)。
步骤313,在通信网元中基于用户身份认证规则,在公共通信域和安全通信域下对访问层对应的用户终端进行双域身份认证。
其中,访问层对应的用户终端可以是指部署有访问平台客户端,并用于发起业务访问请求、接收业务处理结果的用户侧设备,该用户终端可以通过接入5G网络(专网或公网)与访问层建立通信关系。
在本实施例中,双域身份认证是指通信网元对访问层对应的用户终端在公共通信域和安全通信域中的访问权限进行分别验证。认证过程可包括以下操作:
在公共通信域中,对用户终端的网络接入身份进行认证,例如基于SIM卡/USIM卡的5G接入认证。
在安全通信域中,对用户终端的业务访问身份进行二次认证,例如基于用户身份认证信息、数字证书、令牌(Token)等方式进行访问权限校验。
在一个可能的实现方式中,双域身份认证包括对公共通信域与安全通信域分别进行接入鉴权与业务授权,确保终端接入两个域的身份一致性与权限合法性;该过程可采用基于用户身份认证信息的双向鉴权机制,以防止未授权终端越权访问第一网络环境内部的敏感业务系统。
通过双域身份认证,可确保用户终端不仅具有网络接入权限,还具备访问敏感业务数据的业务授权,从而实现对医疗数据访问的多层防护。
步骤315,在身份认证通过的情况下,若业务访问请求指向第一网络环境中的目标业务数据,将业务访问请求通过安全通信域转发至数据层。
具体而言,通信网元在识别业务访问请求的访问目标后,若目标为部署于第一网络环境的数据层,则选择安全通信域作为传输路径,并通过该安全通信域将请求定向路由至目标数据层所在的内部网络地址。
此时,通信网元可根据业务访问请求中所携带的目标医院标识与业务数据类型,将该业务访问请求至对应的第一网络环境数据层地址,实现从外网环境到内网业务系统的安全访问。
为确保传输安全性,可在安全通信域内启用端到端加密与访问控制策略,从而避免业务请求在传输过程中被截获或篡改。
步骤317,若业务访问请求指向外部互联网资源,将业务访问请求通过公共通信域转发至外部服务器。
在本实施例中,外部互联网资源可以是第三方医院平台、公共健康信息平台或外部云服务接口等。
通信网元在判断业务访问请求的目标地址属于互联网范围后,将该请求通过公共通信域转发至相应的外部服务器,从而与外部系统进行数据交互。由于公共通信域与第一网络环境物理隔离,因此外部请求无法直接访问内部数据层,有效防止了内部网络的暴露风险。
那么,此方式可在同一终端会话中实现对内网业务系统与互联网资源的灵活访问,且二者的访问路径与权限体系完全隔离,从而保证了第一网络环境的安全性与互联网访问的便利性。
通过上述过程,通过5G双域专网,在通信网元中实现数据访问的智能分流,使得用户在外网环境下,通过访问层所在的终端无需更换SIM卡或更换电话号码,即可安全、快速、便捷地接入卫生健康行业专网,从而在第二网络环境下直接访问第一网络环境内部的应用与数据服务。
补充说明的是,访问层可以部署用户信息验证模块,用于在用户访问平台之前对其身份合法性进行校验,以防止未经授权的终端或用户访问医疗管理系统。
在一个可能的实现方式,在访问层接收到用户发起的访问平台登录请求后,对用户信息进行验证;具体地,访问层接收用户在访问平台输入的登录凭证信息,登录凭证信息可以包括用户身份认证信息(如用户名、密码)、动态验证码、生物特征信息(如指纹、面部识别数据),访问层可以将用户身份认证信息发送至认证服务组件进行校验。认证服务组件可以本地部署于访问层,也可以调用服务层或外部身份认证中心的接口实现;那么,在身份认证通过的情况下,访问层可为该用户生成访问令牌(Token)和会话密钥,并将访问令牌与用户类型(如医生、患者、管理人员、第三方医疗服务机构用户等)绑定,用于后续业务访问请求的权限校验与调用控制;当然,若身份认证未通过,则拒绝用户登录请求,并在访问平台返回相应的提示信息,提示用户检查登录凭证或重新申请访问权限。
在另一个可能的实现方式,访问层还可以在验证用户信息的同时,结合用户终端设备信息(如设备唯一标识码、IP地址、地理位置信息等)进行安全策略判断,以识别潜在的越权访问或异常登录行为,从而进一步提升系统的安全性。
步骤330,在服务层根据业务访问请求调用与目标业务对应的目标业务模块,并根据目标业务模块将业务访问请求转发至业务应用层。
具体而言,服务层可部署于独立的应用服务器或云计算环境中,作为访问层与业务应用层之间的业务处理枢纽。服务层接收到访问层发送的业务访问请求后,首先对该业务访问请求进行解析,以提取其中包含的关键参数,例如:目标医院标识、业务数据类型、用户身份认证信息等。
在一个可能的实现方式中,服务层可以维护多个不同的目标业务模块,每个目标业务模块对应一种或多种业务处理逻辑。例如,电子病历查询模块、检验报告获取模块、影像资料调阅模块、预约挂号模块等。当业务访问请求解析完成后,服务层可根据业务数据类型、目标医院标识及系统内部的模块映射规则,确定需要调用的目标业务模块。
除此之外,目标业务模块还可以结合用户类型进行调用策略的确定,例如,对于医生用户,目标业务模块可以包括电子病历查询模块、检验报告获取模块、影像资料调阅模块、处方开具模块等;对于患者用户,目标业务模块可以包括预约挂号模块、检验结果查看模块、费用清单查询模块、在线缴费模块等。
补充说明的是,目标业务模块可以在访问平台的用户界面上进行动态加载和展示,使得用户在访问平台界面中直接访问与其角色及权限相匹配的业务功能。
那么,展示的目标业务模块不仅可供用户查看,还可进一步响应用户的操作指令(例如点击、查询、修改、下载等),将这些操作作为更新后的业务访问请求再次传递至服务层,由服务层继续进行处理或转发至业务应用层。
通过这种方式,服务层不仅实现了目标业务模块的调用与转发功能,还能根据用户类型和操作上下文动态调整访问平台展示的业务功能,从而提高系统的交互性与个性化服务能力。
那么,在调用所述目标业务模块后,服务层可基于该目标业务模块所关联的业务应用层接口地址、通信协议及数据格式,将所述业务访问请求转化为与目标业务模块相匹配的数据请求格式,并将其转发至业务应用层中对应的业务处理单元。业务应用层接收到该请求后,即可按照预定业务逻辑对请求进行处理。
例如,当所述目标业务模块为电子病历查看模块时,服务层可将业务访问请求按照电子病历接口的标准参数格式封装,并将其转发至业务应用层中负责病历数据查询的服务进程;当目标业务模块为检验报告查询模块时,则将业务访问请求转发至业务应用层中负责检验报告检索的功能单元。
需要说明的是,目标业务模块与用户的用户类型密切相关,即使多个用户请求访问相同的目标业务(例如“在线咨询”服务),由于其身份属性不同,系统所调用的目标业务模块也可能有所差异,从而影响后续业务处理流程与数据展现形式。
在一个可能的实现方式,上述方法还包括:根据所述业务访问请求确定所述用户的用户类型;基于所述用户类型,根据所述业务访问请求所指示的所述目标业务,调用对应的目标业务模块。
其中,用户类型可以是指基于用户在医疗管理系统中所承担角色或权限所进行的分类标识,用于区分不同用户在业务流程中的操作权限、数据访问范围及交互内容差异。
在一个可能的实现方式,用户类型包括医生、患者、护士、专家远程会诊人员等等,在此不作具体限定。
举例来说,若用户为患者身份,系统可调用患者专用的在线咨询模块,提供包括咨询发起、图文问诊、历史记录查看等功能;若用户为医生身份,则可调用医生侧的在线问诊模块,支持查看患者队列、响应咨询请求、填写病历等业务流程。
关于用户类型的识别,业务访问请求中可以包含用户标识(如用户ID、账户名等),系统可基于上述信息查询用户的注册资料或授权信息,以确定其对应的用户类型;例如,若用户信息中包含“role=doctor”字段,可识别为医生。
此外,当用户通过特定访问平台、渠道或路径进入系统时,可据此推断用户类型,例如,来自医院HIS系统内网的访问,默认视为医生或护士等医疗人员,来自移动App的外部访问,默认视为患者或家属,在此不作限定。
通过上述过程,用户类型的识别可用于指导系统在调用目标业务模块时作出差异化决策,以实现精准访问控制和个性化交互。
步骤350,在业务应用层根据业务访问请求所指示的目标业务,构建与目标业务模块相应的数据访问请求,并将数据访问请求发送至数据层。
其中,数据访问请求用于向数据层请求获取与目标业务模块相对应的目标业务数据。
应当理解,在业务访问请求完成目标业务模块调用之后,系统会基于所选定的目标业务模块生成对应的数据访问请求,用于向数据层请求获取与该目标业务模块相关的目标业务数据。该数据访问请求可以包含业务数据类型、目标成员信息等,数据访问请求可以支撑数据层完成目标业务数据的精确提取、语义关联与结构化处理,并将处理后的目标业务数据返回至访问层供最终展示使用。
具体而言,业务应用层部署在医疗管理系统的业务逻辑处理环境中,通常由多个面向不同业务领域的应用服务组成,例如电子病历服务、影像诊断服务、检验报告服务、药品管理服务等。
在接收到服务层转发的业务访问请求后,业务应用层可基于该业务访问请求所包含的目标医院标识、业务数据类型、用户身份认证信息等参数,解析出所需访问的业务数据范围与访问条件。
在一个可能的实现方式,业务访问请求包括目标医院标识和业务数据类型;如图5所示,步骤350包括:
步骤351,若目标医院标识所指示的目标医院不是当前访问平台对应的医院,则基于业务访问请求解析得到目标成员信息。
可以理解,若目标医院标识所指示的目标医院不是当前访问平台对应的医院,则需要对业务访问请求进行跨院处理,即基于业务访问请求解析得到目标成员信息。
在一个可能的实现方式,如图6所示,步骤351还可以包括以下步骤:
步骤3511,基于业务访问请求获取访问凭证,并在医院互联的情况下将访问凭证发送至目标医院标识所指示的目标医院对应的目标访问平台。
其中,访问凭证用于在不同医院平台之间建立安全的访问会话,访问凭证可以是授权码,在此不作限定。
具体地,业务应用层在接收到跨院访问的业务访问请求后,首先会基于业务访问请求解析出目标医院标识,并确认该标识指向的目标医院并非当前访问平台对应的医院。此时,需要构建跨院访问的安全通道。
为此,业务应用层可以从业务访问请求中提取用于跨院访问授权的基础参数(如用户身份认证信息)并生成访问凭证。
上述访问凭证可以采用单次有效的随机字符串形式,并通过加密算法(如AES或RSA)结合数字签名技术进行封装,以确保访问凭证在传输过程中的机密性与防篡改性。
随后,在医院互联的条件下(例如基于国家卫生健康行业专网或区域医疗数据交换平台),业务应用层将生成的访问凭证发送至目标医院标识对应的目标访问平台,用于发起跨院会话初始化请求。
步骤3513,通过与目标访问平台的一个或多个应用编程接口交互,基于访问凭证,获取用户在目标访问平台的目标用户信息,并根据目标用户信息确定用户在目标访问平台中的目标成员信息。
在一个可能的实现方式,可以在目标访问平台通过第一应用编程接口,基于访问凭证获取TOKEN令牌;在目标访问平台通过第二应用编程接口,基于TOKEN令牌获取用户的目标用户信息;在目标访问平台通过第三应用编程接口,基于目标用户信息获取对应得到目标成员信息。
具体地,目标访问平台在接收到访问凭证后,可以通过第一应用编程接口(API1)对访问凭证进行验证。
在一个可能的实现方式,验证过程可以包括:检查访问凭证的数字签名是否匹配目标医院的公钥;检查访问凭证的有效期是否在设定时间窗口内(例如60秒或5分钟内有效);验证访问凭证的来源是否在可信访问平台白名单中。
那么,在验证通过后,目标访问平台会为本次跨院访问生成一个具有时效性和唯一性的TOKEN令牌。该TOKEN令牌通常为不可预测的随机值,并可绑定访问用户的身份信息、授权范围、可访问的业务数据类型等内容。TOKEN令牌的生成可以依托定制的医院内部令牌机制,并存储于目标医院的会话管理模块中。
在TOKEN令牌生成后,业务应用层会通过第二应用编程接口(API2),基于该令牌向目标访问平台发起目标用户信息获取请求。
目标访问平台在接收到目标用户信息获取请求后,会根据TOKEN令牌解析出与之绑定的用户标识,并在目标医院的用户管理系统中查询该用户的注册信息、权限等级、角色类型(如医生、护士、患者、第三方服务人员等)等。
目标用户信息的返回可以采用加密数据包形式,且可附带数据签名,以防止中间人攻击或数据篡改。
具体地,目标成员信息包括用户在目标医院的就诊卡号,除此之外,目标成员信息还可以包括用户在病历号、门诊或住院登记信息等等,在此不作限定。
需要说明的是,目标用户信息可以是指与用户在目标医院相关的基础身份信息和账户信息,可以用于后续在目标医院业务系统中确认用户身份,以及获取更具体的成员信息,例如,用户姓名、身份证号、手机号等等;目标成员信息可以是指用户在目标医院内部业务系统中对应的业务身份标识信息,是直接用于查询医疗业务数据的关键标识,可以作为数据访问请求中的检索条件,用于定位目标医院数据库中与该用户相关的业务数据,例如,工号(医生或护士)、就诊卡号、病案号、住院号、电子病历唯一标识等等。
步骤353,基于业务访问请求所指示的业务数据类型和目标成员信息生成数据访问请求。
那么,在业务应用层获取到目标成员信息后,可进一步结合业务访问请求中所指示的业务数据类型,生成用于访问目标医院数据层的数据访问请求。
具体而言,业务数据类型可以用于指示所需访问的数据类别,例如门诊就诊记录、住院病历、检验检查结果、影像数据、处方信息等;目标成员信息可以唯一标识用户在目标医院的主体,例如工号(医生或护士)、就诊卡号、患者唯一编码等。
在生成数据访问请求时,业务应用层还可将业务数据类型与目标成员信息进行绑定,并添加必要的访问控制参数,例如访问时间戳、用户身份认证信息、会话令牌等,以便在数据层进行访问权限校验和数据调度。
步骤355,基于目标医院标识确定目标医院的数据层访问地址,并基于数据层访问地址,将数据访问请求发送至目标医院的数据层。
具体地,可以基于业务访问请求中包含的目标医院标识,在医院互联的地址映射表或目录服务中查找对应的目标医院数据层访问地址,例如该数据层的安全接入网关地址、专线IP地址、或虚拟专用网络(VPN)入口地址。
在确定了访问地址后,业务应用层可将数据访问请求通过安全传输通道发送至目标医院数据层。安全传输通道可以采用5G双域专网、VPN专线、或支持国密算法的TLS/SSL加密链路,以确保数据访问请求在传输过程中不被窃听、篡改或重放。
步骤370,在数据层基于数据访问请求获取与所述目标业务对应的目标业务数据,并对目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的目标业务数据返回至访问层。
其中,双单向隔离交换技术用于在第一网络环境与第二网络环境之间实现业务数据的单向安全传输。
在一个可能的实现方式,步骤370还可以包括以下步骤:基于数据访问请求的目标成员信息,在目标医院的数据层中查找目标成员信息对应的目标数据库;基于数据访问请求所指示的业务数据类型,在目标数据库中查找得到目标业务数据。
具体地,在数据层接收到数据访问请求后,首先基于数据访问请求中包含的目标成员信息,在目标医院数据层中查找与该目标成员信息对应的目标数据库。
例如,当目标成员信息为患者在目标医院的就诊卡号时,数据层可在患者信息索引表中定位到对应的患者档案数据库或其逻辑分区。
接着,数据层可进一步基于数据访问请求中所指示的业务数据类型,在目标数据库内检索相应的数据记录。例如,当业务数据类型为“检验结果”时,系统可在该患者的检验数据表中查找符合访问条件的记录;当业务数据类型为“影像资料”时,可定位至影像存储系统(PACS)并提取相应的影像文件及其结构化报告。
在获取到目标业务数据后,数据层会对其进行加密处理,以防止在跨网络传输过程中被未授权访问或篡改。加密方式可以支持国密算法(SM1、SM4对称加密,SM2非对称加密,SM3、SM6哈希算法),所使用的加密密钥、令牌可由系统的基础层生成,也可以通过基础层接入第三方安全平台来获取。
加密完成后,数据层通过双单向隔离交换技术将加密后的目标业务数据发送至访问层。
在一个可能的实现方式,通过双单向隔离交换技术包括前置机、后置机及单向光闸;其中,前置机部署于数据层所在的第一网络环境,用于接收经加密处理的目标业务数据,并将目标业务数据传输至单向光闸;单向光闸设置于第一网络环境与访问层所在的第二网络环境之间,单向光闸仅允许目标业务数据按照预定方向从前置机传输至后置机;后置机部署于访问层所在的第二网络环境,用于接收经单向光闸传输的目标业务数据,并将目标业务数据传输至访问层。
图7示出了一种双单向隔离交换技术的具体实现示意图,如图8所示,双单向隔离交换技术包括分别部署于不同网络环境的前置机与后置机,以及位于两者之间的单向光闸设备;移动专网一侧的隔离交换系统作为前置机部署,连接第一网络环境(如医院的数据层所在的内部安全网络);办公专网一侧的隔离交换系统作为后置机部署,连接第二网络环境(如访问层所在的对外办公网络、互联网接入环境);两套光闸设备(图中标注为“光闸(进)”)分别实现不同方向的单向传输通道,确保数据只能按照预定方向流动,防止反向访问或数据回流。
那么,数据层便可以将加密处理后的目标业务数据交付给移动专网一侧的前置机,通过光闸单向传输至办公专网一侧的后置机,再由后置机将上述目标业务数据转交至访问层,最终在访问平台上展示给用户。
通过上述双单向隔离交换技术,可以保证了内网数据只出不进,即使在跨专网传输敏感医疗数据的情况下,也能有效防止外部网络对第一网络环境的直接入侵,实现医疗管理系统在不同专网间的安全互联。
在一个可能的实现方式,上述方法还可以包括:对目标业务数据进行语义级数据解析处理,得到与用户上下文信息相关联的目标业务数据子集,并将目标业务数据子集返回访问层。
具体地,所述用户上下文信息可包括但不限于:用户的用户类型(如医生、患者、管理人员等)、访问时间、终端类型、业务数据类型等信息。数据层可基于上述用户上下文信息,通过结构化抽取、语义理解与特征匹配等技术,对目标业务数据进行语义级数据解析处理,筛选出与当前用户访问目的最相关的子集数据,作为目标业务数据子集返回访问层。
例如,在用户请求访问某位患者的影像资料时,若用户为主诊医生且访问目的为“术后复查”,则系统可仅提取该患者术后7日内的影像报告与手术记录;而当用户为患者本人且访问目的是“健康咨询”,则系统可优先呈现基础影像结果与解释性说明文档。
通过该方式,系统能够在数据层实现个性化的数据下发,提高数据响应效率,减少冗余传输内容,同时增强终端展示的精准性与安全性。
步骤390,在访问层对加密后的目标业务数据进行解密处理,并将解密后的目标业务数据在访问平台上展示,使得用户在访问平台查看目标业务数据。
具体而言,访问层在接收到通过双单向隔离交换技术传输的、经数据层加密处理的目标业务数据后,可以调用本地的解密模块或接入基础层提供的解密服务,对所述目标业务数据进行解密处理。
在一个可能的实现方式中,所述解密过程可基于与加密过程相匹配的密码算法执行,例如国密SM1、SM4对称加密算法、SM2非对称加密算法、SM3、SM6哈希算法等。解密所需的密钥、令牌可由基础层集中生成和管理,也可以由基础层通过安全接口接入第三方安全平台来提供。
解密完成后,访问层将得到的明文目标业务数据通过访问平台进行展示。访问平台可根据业务数据类型,以列表、图表、电子病历视图、检查报告视图等不同方式呈现,确保用户能够直观、准确地查看数据内容。
在一个可能的实现方式中,访问层还可以对展示的数据执行权限控制和审计记录,例如根据用户身份认证信息与访问令牌验证用户是否有权限查看特定数据,并记录每次数据访问的时间、来源IP、操作类型等信息,以满足医疗数据安全和合规性要求。
通过上述过程,实现了在医疗管理系统中跨不同网络环境对目标业务数据的安全访问与展示,在访问层、服务层、业务应用层和数据层之间构建了完整的业务访问链路,确保用户在外部网络环境中发起的业务访问请求能够在经过认证、路由和数据生成后,安全地传输至内部网络环境的数据层进行处理,并将加密后的目标业务数据单向回传至访问层进行解密和展示。
上述过程通过双单向隔离交换技术和加解密机制,实现了第一网络环境与第二网络环境之间的物理隔离和单向安全传输,防止内部数据泄露或被非法访问;同时,通过访问层对数据的解密与展示,使用户能够在保证数据安全与合规的前提下,高效、便捷地获取所需的业务信息,从而提升医疗数据的可用性与访问安全性。
请参阅图8,在一示例性实施例中,上述医疗管理系统还包括基础层。相应地,上述方法还可以包括以下步骤:
步骤410,通过基础层获取访问层、服务层、业务应用层及数据层的资源使用信息。
在本实施例中,基础层作为医疗管理系统的底层支撑平台,可统一监控各个系统层级的运行负载和资源占用情况。资源使用信息可以包括但不限于 CPU 占用率、内存使用量、网络带宽占用情况、存储空间使用量以及加密/解密处理资源消耗等。资源使用信息可通过在各层部署的监控代理模块周期性上报至基础层,或通过集中化的资源管理接口实时采集。
步骤430,在基础层基于资源使用信息,为数据层分配或调整为访问层、服务层、业务应用层与数据层之间的数据传输分配资源。
具体而言,基础层可结合当前访问请求的数量、数据传输量、业务处理类型等因素,对数据层的计算资源、存储资源和网络资源进行优化分配。例如,在访问量突增时,基础层可以临时为数据层增加计算节点或带宽配额,以确保业务访问链路的稳定性与低延迟;在访问量下降时,则可将多余资源释放,以提高整体资源利用率。
步骤450,若检测到访问层、服务层、业务应用层或数据层的资源使用超过设定阈值,则重新通过基础层对访问层、服务层、业务应用层和/或数据层进行资源分配。
具体地,基础层可预先配置多个阈值策略,例如针对CPU占用率的80%警戒值、网络带宽的峰值限制等。当检测到某一层的资源使用超过设定阈值时,基础层可触发资源再分配流程,将空闲或低负载节点的资源动态调度至高负载层;在必要时还可触发负载均衡机制,将部分业务请求迁移至其他可用节点,从而避免单点过载导致的系统性能下降。
在一个可能的实现方式中,基础层除了用于采集访问层、服务层、业务应用层及数据层的资源使用信息,并进行动态资源分配外,还可为系统提供统一的安全支撑能力。
具体而言,基础层可生成或管理数据加密所涉及的密钥、访问令牌等安全凭证。所述密钥、访问令牌可支持国密SM系列密码算法,包括但不限于SM1、SM4对称加密算法,SM2非对称加密算法,SM3哈希算法,以及SM6等新一代密码算法。
进一步地,在实际部署中,基础层既可以本地部署密钥管理模块,由其直接生成和分发所述密钥、令牌,也可以通过安全接口与第三方安全平台对接,由第三方安全平台生成并管理密钥、令牌。
通过上述方式,可确保业务访问请求、数据访问请求及目标业务数据在跨网络环境传输和处理过程中的机密性、完整性与可追溯性。
在上述实施例的作用下,通过在基础层统一采集各系统层级的资源使用信息,并基于实时监测结果进行资源的动态分配与调整,实现了访问层、服务层、业务应用层与数据层之间的数据传输资源的按需分配和负载均衡。当任一层资源使用超过设定阈值时,能够及时触发资源再分配,避免单点过载,保障系统在高并发和复杂业务场景下的稳定性与响应速度,从而提高医疗管理系统的整体运行效率与可靠性。
图9至图10是一应用场景中一种医疗管理系统的数据访问方法的具体实现示意图,该应用场景适用于图1所示出的医疗管理系统。
现结合图9和图10对该应用场景进行说明,用户通过部署有安全访问应用的移动终端(如安全手机、安全平板电脑等)接入医疗管理系统的访问平台。用户终端首先通过5G专用网络建立与访问层的安全连接,该连接通过运营商提供的5G双域专网实现。
具体地,用户终端通过接入5G专用基站,连接至第二用户面功能网元(UPF)。第二UPF可部署于公网接入区域,用于承载来自互联网或公共5G网络的业务访问请求;第一UPF则部署于专网接入区域(5G双域专网),用于承载来自医疗专网用户的业务访问请求。系统可基于业务策略和用户身份认证信息,智能选择第一UPF或第二UPF进行数据接入,实现访问路径的动态切换与分流,从而在不同网络环境下均可稳定、安全地访问目标业务数据。
需要说明的是,第一UPF可作为访问第一网络环境的接入点之一,其承载的业务流量最终被引入至第一网络环境中的数据层等核心资源;第二UPF可作为访问第二网络环境的接入点之一,其承载的业务流量被引入至第二网络环境中的访问层等核心资源。
当用户在访问平台上发起业务访问操作(例如调取患者影像资料、查看检验报告),访问层基于该操作生成业务访问请求,并将其发送至服务层。服务层根据业务访问请求调用与用户类型相匹配的目标业务模块(如PACS影像系统访问模块、LIS检验系统访问模块),并将业务访问请求转发至业务应用层。
业务应用层根据业务访问请求生成数据访问请求,并基于目标医院标识及业务数据类型,确定需要访问的目标医院数据层。在用户需要访问非本院数据时,系统可通过授权码、TOKEN令牌等机制跨院获取目标成员信息(如用户在目标医院的就诊卡号),并将该目标成员信息与业务数据类型封装到数据访问请求中。
那么,数据访问请求可以通过安全隔离区的双单向隔离交换技术(包括前置机、单向光闸、后置机)安全传输至目标医院的数据层。数据层在接收数据访问请求后,从对应的目标数据库中查找所需的目标业务数据(如超声视频流、检验报告数据),并使用基础层提供的加密机制(支持国密SM1、SM4、SM2、SM3、SM6密码算法)进行加密。
在涉及大规模超声影像的场景中,数据层内部署的数据采集模块可通过HDMI采集超声设备实时画面,采用Slice硬编码进行低时延视频编码,并通过通途视频传输协议高效传输至数据中心,那么,云端处理模块可与基础层协同工作,利用分布式算力节点及DPU硬件加速对数据进行实时处理和AI分析。
进一步地,加密后的目标业务数据通过单向光闸传输至访问层所在网络环境,在访问层完成解密后在访问平台展示给用户,从而实现用户在外网环境下安全、快速地访问医疗机构内部业务数据。
在本应用场景中,通过在访问层引入基于业务策略和用户身份认证信息的接入路径动态选择机制,实现第一UPF与第二UPF之间的智能切换与业务分流,使系统能够在不同网络环境下均保持业务访问的稳定性与安全性;配合跨院访问的目标成员信息获取机制,保障了用户在多医疗机构间的数据访问一致性与业务处理连续性;结合双单向隔离交换技术与基础层加密机制,确保了业务数据在跨网络传输过程中的机密性与完整性;在涉及大规模超声影像等高带宽业务时,利用Slice硬编码与通途视频传输协议实现低时延视频采集与高效传输,进一步结合云端分布式算力节点与DPU硬件加速的AI处理能力,实现了对大数据量医疗影像的实时处理与智能分析,从而提升了系统的整体访问效率、数据安全性和跨机构业务协同能力。
应该理解的是,虽然附图的流程图中的各个步骤按照箭头的指示依次显示,但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明,这些步骤的执行并没有严格的顺序限制,其可以以其他的顺序执行。而且,附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段,这些子步骤或者阶段并不必然是在同一时刻执行完成,而是可以在不同的时刻执行,其执行顺序也不必然是依次进行,而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
下述为本申请装置实施例,可以用于执行本申请所涉及的医疗管理系统的数据访问方法。对于本申请装置实施例中未披露的细节,请参照本申请所涉及的医疗管理系统的数据访问方法的方法实施例。
请参阅图11,本申请实施例中提供了一种医疗管理系统的数据访问装置900,可以部署于医疗管理系统,该系统包括访问层、服务层、业务应用层及数据层。其中,数据层部署于第一网络环境,访问层部署于与第一网络环境相互隔离的第二网络环境。
该装置900包括但不限于:业务访问模块910、业务调用模块930、数据访问模块950、数据获取模块970以及数据展示模块990。
其中,业务访问模块910,用于在访问层为用户提供访问平台,并基于用户在访问平台的业务访问操作,生成业务访问请求,将业务访问请求发送至服务层;业务访问请求用于指示用户请求访问的目标业务;
业务调用模块930,用于在服务层根据业务访问请求调用与目标业务对应的目标业务模块,并根据目标业务模块将业务访问请求转发至业务应用层;
数据访问模块950,用于在业务应用层根据业务访问请求所指示的目标业务,构建与目标业务模块相应的数据访问请求,并将数据访问请求发送至数据层;数据访问请求用于向数据层请求获取与目标业务模块相对应的目标业务数据;
数据获取模块970,在数据层基于数据访问获取与目标业务对应的目标业务数据,并对目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的目标业务数据返回至访问层;其中,双单向隔离交换技术用于在第一网络环境与第二网络环境之间实现业务数据的单向安全传输;
数据展示模块990,用于在访问层对加密后的目标业务数据进行解密处理,并将解密后的目标业务数据在访问平台上展示,使得用户在访问平台查看目标业务数据。
需要说明的是,上述实施例所提供的医疗管理系统的数据访问装置在进行医疗管理系统的数据访问时,仅以上述各功能模块的划分进行举例说明,实际应用中,可以根据需要而将上述功能分配由不同的功能模块完成,即医疗管理系统的数据访问装置的内部结构将划分为不同的功能模块,以完成以上描述的全部或者部分功能。
另外,上述实施例所提供的医疗管理系统的数据访问装置与医疗管理系统的数据访问方法的实施例属于同一构思,其中各个模块执行操作的具体方式已经在方法实施例中进行了详细描述,此处不再赘述。
与相关技术相比,本方案实现了在医疗管理系统中跨不同网络环境对目标业务数据的安全访问与展示,在访问层、服务层、业务应用层和数据层之间构建了完整的业务访问链路,确保用户在外部网络环境中发起的业务访问请求能够在经过认证、路由和数据生成后,安全地传输至内部网络环境的数据层进行处理,并将加密后的目标业务数据单向回传至访问层进行解密和展示。
上述过程通过双单向隔离交换技术和加解密机制,实现了第一网络环境与第二网络环境之间的物理隔离和单向安全传输,防止内部数据泄露或被非法访问;同时,通过访问层对数据的解密与展示,使用户能够在保证数据安全与合规的前提下,高效、便捷地获取所需的业务信息,从而提升医疗数据的可用性与访问安全性。
以上所述仅是本申请的部分实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本申请原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也应视为本申请的保护范围。
Claims (9)
1.一种医疗管理系统的数据访问方法,其特征在于,所述系统包括访问层、服务层、业务应用层、数据层及基础层;其中,所述数据层部署于第一网络环境,所述访问层部署于与所述第一网络环境相互隔离的第二网络环境;所述方法包括:
在所述访问层为用户提供访问平台,并基于所述用户在所述访问平台的业务访问操作,生成业务访问请求,将所述业务访问请求发送至所述服务层;所述业务访问请求用于指示所述用户请求访问的目标业务;
在所述服务层根据所述业务访问请求调用与所述目标业务对应的目标业务模块,并根据所述目标业务模块将所述业务访问请求转发至所述业务应用层;
在所述业务应用层根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相应的数据访问请求,并将所述数据访问请求发送至所述数据层;所述数据访问请求用于向所述数据层请求获取与所述目标业务模块相对应的目标业务数据;
在所述数据层基于所述数据访问请求获取与所述目标业务对应的目标业务数据,并对所述目标业务数据进行加密处理,通过双单向隔离交换技术将加密后的所述目标业务数据返回所述访问层;其中,所述双单向隔离交换技术用于在所述第一网络环境与所述第二网络环境之间实现业务数据的单向安全传输;
在所述访问层对所述加密后的所述目标业务数据进行解密处理,并将解密后的所述目标业务数据在所述访问平台上展示,使得所述用户在所述访问平台查看所述目标业务数据;
在所述基础层获取所述访问层、所述服务层、所述业务应用层及所述数据层的资源使用信息,并基于所述资源使用信息,为所述数据层分配或调整所述访问层、所述服务层、所述业务应用层与所述数据层之间的数据传输分配资源,若检测到所述访问层、所述服务层、所述业务应用层或所述数据层的资源使用超过设定阈值,则重新通过所述基础层对所述访问层、所述服务层、所述业务应用层和/或所述数据层进行资源分配。
2.如权利要求1所述的方法,其特征在于,所述在所述服务层根据所述业务访问请求调用与所述目标业务对应的目标业务模块,包括:
根据所述业务访问请求确定所述用户的用户类型;
基于所述用户类型,根据所述业务访问请求所指示的所述目标业务,调用对应的目标业务模块。
3.如权利要求1所述的方法,其特征在于,所述业务访问请求包括目标医院标识和业务数据类型;
所述在所述业务应用层根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相应的数据访问请求,并将所述数据访问请求发送至所述数据层,包括:
若所述目标医院标识所指示的目标医院不是当前访问平台对应的医院,则基于所述业务访问请求解析得到目标成员信息;
基于所述业务访问请求所指示的业务数据类型和所述目标成员信息生成数据访问请求;
基于所述目标医院标识确定目标医院的数据层访问地址,并基于所述数据层访问地址,将所述数据访问请求发送至所述目标医院的数据层。
4.如权利要求3所述的方法,其特征在于,所述基于所述业务访问请求解析得到目标成员信息,包括:
基于所述业务访问请求获取访问凭证,并在医院互联的情况下将所述访问凭证发送至所述目标医院标识所指示的目标医院对应的目标访问平台;
通过与目标访问平台的一个或多个应用编程接口交互,基于所述访问凭证,获取所述用户在所述目标访问平台的目标用户信息,并根据所述目标用户信息确定所述用户在目标访问平台中的目标成员信息。
5.如权利要求3所述的方法,其特征在于,所述在所述数据层基于所述数据访问请求获取与所述目标业务对应的目标业务数据,包括:
基于所述数据访问请求的所述目标成员信息,在所述目标医院的数据层中查找所述目标成员信息对应的目标数据库;
基于所述数据访问请求所指示的业务数据类型,在所述目标数据库中查找得到所述目标业务数据。
6.如权利要求1所述的方法,其特征在于,所述在所述数据层基于所述数据访问请求获取与所述目标业务对应的目标业务数据之后,所述方法还包括:
对所述目标业务数据进行语义级数据解析处理,得到与所述用户上下文信息相关联的目标业务数据子集,并将所述目标业务数据子集返回所述访问层。
7.如权利要求1所述的方法,其特征在于,所述双单向隔离交换技术包括前置机、后置机及单向光闸;
所述通过双单向隔离交换技术将加密后的所述目标业务数据返回所述访问层,包括:
将所述前置机部署于所述数据层所在的第一网络环境,用于接收经加密处理的目标业务数据,并将所述目标业务数据传输至所述单向光闸;
将所述单向光闸设置于所述第一网络环境与所述访问层所在的第二网络环境之间,所述单向光闸仅允许所述目标业务数据按照预定方向从所述前置机传输至所述后置机;
将所述后置机部署于所述访问层所在的第二网络环境,用于接收经所述单向光闸传输的所述目标业务数据,并将所述目标业务数据传输至所述访问层。
8.如权利要求1所述的方法,其特征在于,所述将所述业务访问请求发送至所述服务层,包括:
通过5G双域专网在通信网元中建立公共通信域与安全通信域,所述安全通信域与所述数据层所在的第一网络环境连通,所述公共通信域与所述访问层所在的第二网络环境连通;
在所述通信网元中基于用户身份认证规则,在所述公共通信域和所述安全通信域下对所述访问层对应的用户终端进行双域身份认证;
在所述身份认证通过的情况下,若所述业务访问请求指向所述第一网络环境中的目标业务数据,将所述业务访问请求通过所述安全通信域转发至所述数据层;
若所述业务访问请求指向外部互联网资源,将所述业务访问请求通过所述公共通信域转发至外部服务器。
9.一种医疗管理系统,其特征在于,所述系统包括访问层、服务层、业务应用层、数据层及基础层;
所述访问层,用于为用户提供访问平台,并基于所述用户在所述访问平台的业务访问操作,生成业务访问请求,将所述业务访问请求发送至所述服务层;接收所述数据层发送的加密后的目标业务数据,对所述加密后的所述目标业务数据进行解密处理,并将解密后的所述目标业务数据在所述访问平台上展示,使得所述用户在所述访问平台查看所述目标业务数据;所述业务访问请求用于指示所述用户请求访问的目标业务;
所述服务层,用于根据所述业务访问请求调用对应的目标业务模块,并根据所述目标业务模块将所述业务访问请求转发至所述业务应用层;
所述业务应用层,用于根据所述业务访问请求所指示的所述目标业务,构建与所述目标业务模块相对应的数据访问请求,并将所述数据访问请求发送至所述数据层;所述数据访问请求用于向所述数据层请求获取与所述目标业务模块相对应的目标业务数据;
所述数据层,用于接收所述数据访问请求,基于所述数据访问请求获取与所述目标业务对应的目标业务数据,并对所述目标业务数据进行加密处理,通过双单向隔离交换技术将所述加密后的所述目标业务数据返回至所述访问层;
所述基础层,用于获取所述访问层、所述服务层、所述业务应用层及所述数据层的资源使用信息,并基于所述资源使用信息,为所述数据层分配或调整所述访问层、所述服务层、所述业务应用层与所述数据层之间的数据传输分配资源,若检测到所述访问层、所述服务层、所述业务应用层或所述数据层的资源使用超过设定阈值,则重新通过所述基础层对所述访问层、所述服务层、所述业务应用层和/或所述数据层进行资源分配;
其中,所述数据层部署于第一网络环境,所述访问层部署于与所述第一网络环境相互隔离的第二网络环境;所述双单向隔离交换技术用于在所述第一网络环境与所述第二网络环境之间实现业务数据的单向安全传输。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202511281998.1A CN120811775B (zh) | 2025-09-09 | 2025-09-09 | 医疗管理系统及其数据访问方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202511281998.1A CN120811775B (zh) | 2025-09-09 | 2025-09-09 | 医疗管理系统及其数据访问方法 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN120811775A CN120811775A (zh) | 2025-10-17 |
| CN120811775B true CN120811775B (zh) | 2025-11-21 |
Family
ID=97314341
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202511281998.1A Active CN120811775B (zh) | 2025-09-09 | 2025-09-09 | 医疗管理系统及其数据访问方法 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN120811775B (zh) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110912940A (zh) * | 2019-12-25 | 2020-03-24 | 普世(南京)智能科技有限公司 | 一种基于双单向交换设备的隔离网络透明业务访问方法及系统 |
| CN112650732A (zh) * | 2020-12-22 | 2021-04-13 | 平安普惠企业管理有限公司 | 一种业务处理方法、装置、设备及存储介质 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114297290A (zh) * | 2021-12-08 | 2022-04-08 | 国网安徽省电力有限公司信息通信分公司 | 一种电力营销数据共享应用平台 |
| CN116980438A (zh) * | 2022-04-22 | 2023-10-31 | 武汉联影智融医疗科技有限公司 | 远程医疗监护系统和方法 |
| CN117807070A (zh) * | 2023-12-25 | 2024-04-02 | 中广核智能科技(深圳)有限责任公司 | 基于大数据的设备标牌管理系统 |
-
2025
- 2025-09-09 CN CN202511281998.1A patent/CN120811775B/zh active Active
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110912940A (zh) * | 2019-12-25 | 2020-03-24 | 普世(南京)智能科技有限公司 | 一种基于双单向交换设备的隔离网络透明业务访问方法及系统 |
| CN112650732A (zh) * | 2020-12-22 | 2021-04-13 | 平安普惠企业管理有限公司 | 一种业务处理方法、装置、设备及存储介质 |
Also Published As
| Publication number | Publication date |
|---|---|
| CN120811775A (zh) | 2025-10-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US12132835B2 (en) | Encrypted file storage | |
| US20230010452A1 (en) | Zero-Knowledge Environment Based Networking Engine | |
| US8438622B2 (en) | Methods and apparatus for authorizing access to data | |
| US9614855B2 (en) | System and method for implementing a secure web application entitlement service | |
| CN103795702A (zh) | 用于数据的发送控制 | |
| US20150271146A1 (en) | Methods and systems for the secure exchange of information | |
| US11537733B2 (en) | Database access control service in networks | |
| CN108173836A (zh) | 朝向内容消费者迁移经过认证的内容 | |
| KR20180080183A (ko) | 생체인식 프로토콜 표준을 위한 시스템 및 방법 | |
| US20220019682A1 (en) | Securely processing shareable data utilizing a vault proxy | |
| CN117097540A (zh) | 一种基于智能网联的校园身份验证安全管理方法 | |
| CN115460228B (zh) | 一种医疗数据的访问控制方法及系统 | |
| US12327030B2 (en) | Bridging authorization standard for cloud storage | |
| Reis et al. | Private data sharing in a secure cloud-based application for acute stroke care | |
| CN120811775B (zh) | 医疗管理系统及其数据访问方法 | |
| Sharghi et al. | Federated service-based authentication provisioning for distributed diagnostic imaging systems | |
| Taechoyotin et al. | Health link: scalable health information exchange platform in Thailand | |
| CN115801843A (zh) | 一种基于云技术的医疗服务平台和方法 | |
| Akilandeswari et al. | A review of literature on cloud brokerage services | |
| US20250278514A1 (en) | Systems and methods for data access management | |
| Balamurugan et al. | Layered storage architecture for health system using cloud | |
| García et al. | Web-based service for remote execution: NGI network design application | |
| CN120642297A (zh) | 用于隐藏动态客户端注册的注册规则的安全系统 | |
| Priya et al. | Protecting Healthcare Database by Access Control Method on Cloud Computing Technique-A Survey. | |
| Chadwick et al. | Using the internet to access confidential patient |
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 |