CN114822744A - 医疗就诊数据共享方法、系统、计算设备及存储介质 - Google Patents

医疗就诊数据共享方法、系统、计算设备及存储介质 Download PDF

Info

Publication number
CN114822744A
CN114822744A CN202210502325.4A CN202210502325A CN114822744A CN 114822744 A CN114822744 A CN 114822744A CN 202210502325 A CN202210502325 A CN 202210502325A CN 114822744 A CN114822744 A CN 114822744A
Authority
CN
China
Prior art keywords
target patient
client
file
medical treatment
medical
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
Application number
CN202210502325.4A
Other languages
English (en)
Inventor
吕威
王凌青
李春宝
刘鑫
李季
安庆梁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China United Network Communications Group Co Ltd
Unicom Digital Technology Co Ltd
China Unicom Heilongjiang Industrial Internet Co Ltd
Original Assignee
China United Network Communications Group Co Ltd
Unicom Digital Technology Co Ltd
China Unicom Heilongjiang Industrial Internet Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by China United Network Communications Group Co Ltd, Unicom Digital Technology Co Ltd, China Unicom Heilongjiang Industrial Internet Co Ltd filed Critical China United Network Communications Group Co Ltd
Priority to CN202210502325.4A priority Critical patent/CN114822744A/zh
Publication of CN114822744A publication Critical patent/CN114822744A/zh
Pending legal-status Critical Current

Links

Images

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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/17—Details of further file system functions
    • G06F16/176—Support for shared access to files; File sharing support
    • 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
    • G16H30/00—ICT specially adapted for the handling or processing of medical images
    • G16H30/20—ICT specially adapted for the handling or processing of medical images for handling medical images, e.g. DICOM, HL7 or PACS
    • 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
    • G16H40/63—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 for local operation
    • 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
    • G16H40/67—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 for remote operation

Landscapes

  • Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Primary Health Care (AREA)
  • Biomedical Technology (AREA)
  • Public Health (AREA)
  • Epidemiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • General Business, Economics & Management (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Radiology & Medical Imaging (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本申请提供一种医疗就诊数据共享方法、系统、计算设备及存储介质。该方法包括：响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成医疗就诊数据的共享请求；所述医疗就诊数据包括：目标患者的影像图像；在共享请求审批通过之后、且到达目标时间时，从存储地址读取医疗就诊数据，并向第一客户端和第二客户端分发包括医疗就诊数据的数据流。通过采用本申请提供的方法，任一客户端可以通过将其所属的医疗机构产生并存储在医疗就诊数据共享系统上的医疗就诊数据，共享至其他客户端，实现医疗就诊数据的共享。

Description

医疗就诊数据共享方法、系统、计算设备及存储介质
技术领域
本申请涉及通信技术，尤其涉及一种医疗就诊数据共享方法、系统、计算设备及存储介质。
背景技术
医疗机构采用影像诊疗设备对患者身体进行检查，生成患者的医学数字成像和通信(Digital Imaging and Communications in Medicine，DICOM)影像图像。该DICOM影像图像用于辅助医生确认患者的身体情况。
目前，各医疗机构的DICOM影像图像相互独立，无法共享。
发明内容
本申请提供一种医疗就诊数据共享方法、系统、计算设备及存储介质，用以解决医疗就诊数据无法共享的问题。
第一方面，本申请提供一种医疗就诊数据共享方法，该方法包括：
响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成所述医疗就诊数据的共享请求；所述医疗就诊数据包括：所述目标患者的影像图像；
在所述共享请求审批通过之后、且到达所述目标时间时，从所述存储地址读取所述医疗就诊数据，并向所述第一客户端和所述第二客户端分发包括所述医疗就诊数据的数据流。
可选地，所述响应于用户通过第一客户端的操作，获取目标患者的基本信息，包括：
响应于用户通过第一客户端输入的所述目标患者的标识，从第一数据库查询所述目标患者的基本信息；所述第一数据库中存储有至少一个患者的文档，所述文档包括：患者的基本信息，以及，患者的至少一个医疗就诊数据在文件子系统上的存储地址；
响应于在所述第一数据库中查询到所述目标患者的文档，则从所述目标患者的文档中获取所述目标患者的基本信息；
响应于在所述第一数据库中未查询到所述目标患者的文档，输出提示信息，所述提示信息用于表征所述第一数据库中无所述目标患者的文档；
响应于用户通过所述第一客户端输入的所述目标患者的基本信息，获取所述目标患者的基本信息，并在所述第一数据库中构建所述目标患者的文档。
可选地，所述响应于用户通过第一客户端的操作，获取所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，包括：
响应于用户通过第一客户端针对医疗就诊数据的添加操作，获取已存储在文件子系统中的所述目标患者的医疗就诊数据在所述文件子系统的存储地址；
和/或，响应于用户通过第一客户端针对医疗就诊数据的本地上传操作，将医疗就诊数据存储至文件子系统，并获取医疗就诊数据在文件子系统的存储地址。
可选地，所述响应于用户第一客户端针对医疗就诊数据的上传操作，将医疗就诊数据存储至文件子系统，包括：
针对影像图像，从文件传输设备获取所述第一客户端推送的原始影像文件；
检测所述原始影像文件的格式是否为预设格式；
响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；
将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
可选地，所述方法还包括：
通过前置机，从所述目标患者就诊的医疗机构的本地数据库获取原始影像文件；
检测所述原始影像文件的格式是否为预设格式；
响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；
将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
可选地，所述解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像，包括：
响应于所述原始影像文件为压缩文件，则对所述原始影像文件进行解压缩；
对解压缩后的原始影像文件进行解析，得到所述目标患者的基本信息、以及，影像图像。
可选地，所述方法还包括：
本地同步存储所述目标患者的影像图像和所述原始影像文件。
可选地，所述方法还包括：
根据当前触发的原始影像文件的上传数量，调整用于执行上传操作的线程池的大小。
可选地，所述方法还包括：
接收用户通过第三客户端触发的传输服务的启动请求，从第一数据库获取各传输服务的服务状态；一个所述传输服务用于从一个医疗机构的本地数据库获取原始影像文件；
输出各传输服务的服务状态。
可选地，所述方法还包括：
根据所述共享请求对应的审批关联关系，向审批关联关系所表征的至少一个客户端，逐级触发审批流程，直至所述共享请求审批通过。
第二方面，本申请提供一种医疗就诊数据共享系统，该系统包括：
获取模块，用于响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成所述医疗就诊数据的共享请求；所述医疗就诊数据包括：所述目标患者的影像图像；
读取模块，用于在所述共享请求审批通过之后、且到达所述目标时间时，从所述存储地址读取所述医疗就诊数据；
分发模块，用于向所述第一客户端和所述第二客户端分发包括所述医疗就诊数据的数据流。
第三方面，本申请提供一种计算设备，包括：处理器，以及与所述处理器通信连接的存储器；
所述存储器存储计算机执行指令；
所述处理器执行所述存储器存储的计算机执行指令，以实现如第一方面任一项所述的方法。
第四方面，本申请提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如第一方面任一项所述的医疗就诊数据共享方法。
本申请提供的医疗就诊数据共享方法、系统、计算设备及存储介质，任一客户端可以通过将其所属的医疗机构产生并存储在医疗就诊数据共享系统上的医疗就诊数据，共享至其他客户端，实现医疗就诊数据的共享。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。
图1为本申请实施例提供的一种医疗就诊数据共享系统的结构示意图；
图2为本申请实施例提供的医疗就诊数据共享系统存储医疗就诊数据的应用架构示意图；
图3为本申请实施例提供的一种医疗就诊数据共享系统的应用场景示意图；
图4为本申请实施例提供的另一种医疗就诊数据共享系统的应用场景示意图；
图5为部署有医疗就诊数据共享系统的计算设备的硬件结构示意图；
图6为本申请实施例提供的一种医疗就诊数据共享方法的流程示意图；
图7为本申请实施例提供的一种可能的用户通过第一客户端发起会诊请求的界面示意图；
图8为本申请实施例提供的一种可能的用户通过第一客户端获取患者基本信息的界面示意图；
图9为本申请实施例提供的一种可能的用户通过第一客户端添加医疗就诊数据的界面示意图；
图10为本申请实施例提供的一种可能的医疗机构之间单向关联的界面示意图；
图11为本申请实施例提供的一种可能的会诊会议开始的界面示意图；
图12为本申请实施例提供的一种获取目标患者的基本信息的方法的流程示意图；
图13为本申请实施例提供的一种获取原始影像文件的方法的流程示意图；
图14为本申请实施例提供的一种可能的DICOM服务状态的界面示意图；
图15为本申请实施例提供的一种可能的DICOM服务状态页面中服务参数的界面示意图；
图16为本申请实施例提供的另一种获取原始影像文件的方法的流程示意图；
图17为本申请实施例提供的一种可能的影像预览界面的示意图；
图18为本申请实施例提供的一种医疗就诊数据共享系统的结构示意图。
通过上述附图，已示出本申请明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本申请构思的范围，而是通过参考特定实施例为本领域技术人员说明本申请的概念。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
目前，各医疗机构的DICOM影像图像存储在医疗机构的本地数据库，数据相互独立，无法共享。因此，现有技术不支持如下操作：
1、单点影像数据多点会诊。例如，以上级医院和下级医院为例，由于各医院的DICOM影像图像相互独立，因此，上级医院无法对下级医院针对DICOM影像图像的诊疗做出指导意见，导致，下级医院的诊疗水平提升缓慢，患者难以享受到更高水平的影像诊断和会诊服务。
2、不支持交互式影像教学。例如，在线式影像教学。
3、医生也无法随时随地查看DICOM影像图像。
有鉴于此，本申请提供了一种利用医疗就诊数据共享系统实现医疗就诊数据共享的方法，这样，用户可以通过利用医疗就诊数据共享系统实现医疗就诊数据共享。
其中，医疗就诊数据可以包括患者就诊过程中产生的就诊数据，例如：影像文件、检查记录单等。影像文件例如可以是DICOM文件或者其它格式的影像文件。例如，计算机体层摄影(Computed Tomography，CT)影像文件等。
本申请提供的医疗就诊数据共享方法可以用于任一需要共享医疗就诊数据的场景。例如，远程会诊的场景、交互式影像教学的场景等。
图1为本申请实施例提供的一种医疗就诊数据共享系统的结构示意图。如图1所示，该医疗就诊数据共享系统包括：至少一个文件子系统、至少一个第一数据库，以及，服务器。服务器分别与文件子系统和第一数据库连接。图1是以一个文件子系统和一个第一数据库为例的示意图。
其中，文件子系统用于存储医疗就诊数据。该文件子系统例如可以是轻量级分布式文件系统(Fast Distributed File System，FastDFS)。
第一数据库用于记录文件子系统上存储的医疗就诊数据的查询索引，以及其他所需存储的数据。其他所需存储的数据例如可以包括医疗机构的信息、医疗机构的各客户端的标识、共享请求的审批关联关系、患者的检查数据等中一项或多项。其中，患者的检查数据例如可以是除影像图像之外的检查数据。
查询索引可以采用“患者的文档”的格式存储于第一数据库中。其中，患者的文档可以包括：患者的基本信息，以及，患者的至少一个医疗就诊数据在文件子系统上的存储地址。第一数据库例如可以是mongo数据库。
可选地，第一数据库可以采用复制集(Replica Set)部署，即，第一数据库可以包括一个主数据库和两个从数据库。通过这种部署方式，可以确保存储在第一数据库上的数据的安全。
服务器，用于为用户提供医疗就诊数据共享服务的人机交互操作。
图2为本申请实施例提供的医疗就诊数据共享系统存储医疗就诊数据的应用架构示意图，如图2所示，该系统存储医疗就诊数据可以采用如下两种方式：
第一种方式：主动从医疗机构的本地数据库中提取医疗就诊数据进行存储。在该实现方式下，各医疗机构可以将所需存储至该系统的就诊数据预先存储至其本地数据库即可。
作为一种可能的实现方式，服务器可以通过控制前置机主动从医疗机构的本地数据库中提取医疗就诊数据，然后服务器将该医疗就诊数据存储至服务器本地以及第一数据库和/或文件子系统。其中，前置机用于实现服务器与医疗机构的本地数据库的交互。该前置机例如可以是基于移动通信网络实现数据采集的前置机，其中，该移动通信网络例如可以是第五代移动通信技术(5th-Generation Mobile Communication Technology，5G)移动通信网络。
第二种方式：医疗机构利用终端设备上安装的该系统的客户端，主动上传医疗就诊数据进行存储。该客户端可以是安装在终端设备上的手机软件(application，app)，或者是全球广域网(World Wide Web，web)客户端。
作为一种可能的实现方式，医疗机构利用终端设备上安装的该系统的客户端主动上传医疗就诊数据至文件传输设备，服务器可以从该文件传输设备获取该医疗就诊数据，然后服务器将该医疗就诊数据存储至服务器本地以及第一数据库和/或文件子系统。其中，文件传输设备用于临时存储医疗机构利用终端设备上安装的该系统的客户端主动上传的医疗就诊数据，同时实现医疗机构的终端设备与服务器的交互。该文件传输设备例如可以是文件传输协议(File Transfer Protocol，FTP)服务器。
应理解，前置机和/或文件传输设备可以属于本申请所提供的医疗就诊数据共享系统，也可以属于医疗机构，也可以是独立于医疗就诊数据共享系统、以及，医疗机构之外的单独的设备。一种可能的实现方式，上述前置机和/或文件传输设备的功能也可以由服务器实现，在该实现方式下，无需再额外设置前置机和/或文件传输设备。
图3为本申请实施例提供的一种医疗就诊数据共享系统的应用场景示意图，如图3所示，在一种实施例中，医疗就诊数据共享系统可全部部署在云环境中。云环境是云计算模式下利用基础资源向用户提供云服务的实体。云环境包括云数据中心和云服务平台，所述云数据中心包括云服务提供商拥有的大量基础资源(包括计算资源、存储资源和网络资源)，云数据中心包括的计算资源可以是大量的计算设备(例如服务器)。例如，以云数据中心包括的计算资源是运行有虚拟机的服务器为例，医疗就诊数据共享系统可以独立地部署在云数据中心中的服务器或虚拟机上，医疗就诊数据共享系统也可以分布式地部署在云数据中心中的多台服务器上、或者分布式地部署在云数据中心中的多台虚拟机上、再或者分布式地部署在云数据中心中的服务器和虚拟机上。
如图3所示，医疗就诊数据共享系统例如可以由云服务提供商在云服务平台抽象成一种医疗就诊数据共享服务提供给用户。用户在使用医疗就诊数据共享服务时，可以通过应用程序接口(application program interface，API)或者图形用户界面(GraphicalUser Interface，GUI)与医疗就诊数据共享系统交互，实现医疗就诊数据的共享。
图4为本申请实施例提供的另一种医疗就诊数据共享系统的应用场景示意图，本申请实施例提供的医疗就诊数据共享系统的部署较为灵活，如图4所示，在另一种实施例中，本申请实施例提供的医疗就诊数据共享系统还可以分布式地部署在不同的环境中。本申请提供的医疗就诊数据共享系统可以在逻辑上分成多个部分，每个部分具有不同的功能。医疗就诊数据共享系统中的各部分可以分别部署在终端计算设备(位于用户侧)、边缘环境和云环境中的任意两个或三个中。位于用户侧的终端计算设备例如可以包括下述至少一种：终端服务器、智能手机、笔记本电脑、平板电脑、个人台式电脑。边缘环境为包括距离终端计算设备较近的边缘计算设备集合的环境，边缘计算设备包括：边缘服务器、拥有计算力的边缘小站等。部署在不同环境或设备的医疗就诊数据共享系统的各个部分协同实现为用户提供医疗就诊数据共享的功能。应理解，本申请实施例不对医疗就诊数据共享系统的哪些部分部署具体部署在什么环境进行限制性的划分，实际应用时可根据终端计算设备的计算能力、边缘环境和云环境的资源占有情况或具体应用需求进行适应性的部署。图4是以医疗就诊数据共享系统分别部署在边缘环境和云环境为例的应用场景示意图。
医疗就诊数据共享系统也可以单独部署在任意环境中的一个计算设备上(例如：至少一个文件子系统、至少一个第一数据库，以及，服务器全部部署在边缘环境的一个边缘服务器上)。图5为部署有医疗就诊数据共享系统的计算设备的硬件结构示意图，图5所示的计算设备包括存储器、处理器、通信接口。存储器、处理器、通信接口之间彼此通信连接。例如，存储器、处理器、通信接口之间可以采用网络连接的方式，实现通信连接。或者，上述计算设备还可以包括总线。存储器、处理器、通信接口通过总线实现彼此之间的通信连接。图5是以存储器、处理器、通信接口通过总线实现彼此之间的通信连接的计算设备。
存储器可以是只读存储器(Read Only Memory，ROM)，静态存储设备，动态存储设备或者随机存取存储器(Random Access Memory，RAM)。存储器可以存储程序，当存储器中存储的程序被处理器执行时，处理器和通信接口用于执行医疗就诊数据共享系统为用户提供医疗就诊数据的方法。存储器还可以存储医疗就诊数据。
处理器可以采用通用的中央处理器(Central Processing Unit，CPU)，微处理器，应用专用集成电路(Application Specific Integrated Circuit，ASIC)，图形处理器(graphics processing unit，GPU)或者一个或多个集成电路。
处理器还可以是一种集成电路芯片，具有信号的处理能力。在实现过程中，本申请的医疗就诊数据共享系统的功能可以通过处理器中的硬件的集成逻辑电路或者软件形式的指令完成。上述的处理器还可以是通用处理器、数字信号处理器(digital signalprocessing，DSP)、专用集成电路(ASIC)、现成可编程门阵列(field programmable gatearray，FPGA)或者其他可编程逻辑器件、分立门或者晶体管逻辑器件、分立硬件组件，可以实现或者执行本申请下文实施例中的公开的各方法、步骤及逻辑框图。通用处理器可以是微处理器或者该处理器也可以是任何常规的处理器等。结合本申请下文实施例所公开的方法的步骤可以直接体现为硬件译码处理器执行完成，或者用译码处理器中的硬件及软件模块组合执行完成。软件模块可以位于随机存储器，闪存、只读存储器，可编程只读存储器或者电可擦写可编程存储器、寄存器等本领域成熟的存储介质中。该存储介质位于存储器，处理器读取存储器中的信息，结合其硬件完成本申请实施例的医疗就诊数据共享系统的功能。
通信接口使用例如但不限于收发器一类的收发模块，来实现计算设备与其他设备或通信网络之间的通信。例如，可以通过通信接口获取数据集。
当上述计算设备包括总线时，总线可包括在计算设备各个部件(例如，存储器、处理器、通信接口)之间传送信息的通路。
下面以具体地实施例对本申请的技术方案以及本申请的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本申请的实施例进行描述。
图6为本申请实施例提供的一种医疗就诊数据共享方法的流程示意图。该方法可以由医疗就诊数据共享系统执行，如图6所示，该方法包括：
S101、响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成医疗就诊数据的共享请求；医疗就诊数据包括：目标患者的影像图像。
第一客户端可以实现发起共享请求，即，第一客户端为该医疗就诊数据的分享端，第二客户端为该医疗就诊数据的被分享端。被分享的医疗就诊数据存储于该医疗就诊数据共享系统。该第二客户端与第一客户端可以是同一医疗机构的客户端，也可以是隶属不同医疗机构的客户端。
目标患者的基本信息可以包括：目标患者的标识，该标识例如可以是目标患者的身份标识、电话号码、或者，在该系统上注册的标识。可选地，该基本信息例如还可以包括下述至少一项：姓名、年龄、性别等。
请求共享的目标时间，即请求允许向第二客户端共享医疗就诊数据的时间；此处所说的目标时间可以是共享开始的时间起点，也可以是指某一具体的时间段。当指代具体的时间段时，说明该医疗就诊数据在该时间段可以共享给第二客户端。
上述目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、目标患者待共享的医疗就诊数据在文件子系统的存储地址，可以是用户通过第一客户端所显示的用户界面手动输入的，也可以是部分手动输入，部分通过用户界面上的选择控件实现的。
一种可能的实现方式，以数据共享为发起会诊为例，图7为本申请实施例提供的一种可能的用户通过第一客户端发起会诊请求的界面示意图。如图7所示，用户可以通过第一客户端所示“会诊申请单”界面输入请求共享的目标时间，然后通过该界面点击添加参会人员控件，服务器从第一数据库中获取待共享的第二客户端的标识列表。该待共享的第二客户端的标识列表显示在第一客户端的“会诊申请单”界面。用户通过第一客户端界面所示该标识列表点击该标识，完成第二客户端的标识的添加。
添加完成后，用户通过第一客户端所示“会诊申请单”界面点击下一页控件，界面跳转至“会诊患者资料”界面。
图8为本申请实施例提供的一种可能的用户通过第一客户端获取患者基本信息的界面示意图。如图8所示，用户可以通过第一客户端所示“会诊患者资料”界面点击查询控件，服务器从第一数据库获取目标患者的基本信息，目标患者的基本信息显示在第一客户端的“会诊患者资料”界面。
获取目标患者的基本信息后，用户通过第一客户端所示“会诊患者资料”界面点击下一页控件，界面跳转至添加医疗就诊数据的界面。
图9为本申请实施例提供的一种可能的用户通过第一客户端添加医疗就诊数据的界面示意图。如图9所示，用户可以通过第一客户端所示界面点击添加影像文件控件和/或添加附件控件，服务器从第一数据库获取目标患者的影像图像的标识列表，该标识列表显示在第一客户端所示添加医疗就诊数据的界面。用户通过该界面选择待共享的影像图像的标识，服务器根据该影像图像的标识获取目标患者待共享的影像图像在文件子系统的存储地址。
上述操作完成后，用户可以通过第一客户端所示添加医疗就诊数据的界面点击保存控件，生成会诊请求，即，生成医疗就诊数据的共享请求。
S102、在共享请求审批通过之后、且到达目标时间时，从目标患者待共享的医疗就诊数据在文件子系统的存储地址读取该医疗就诊数据，并向第一客户端和第二客户端分发包括该医疗就诊数据的数据流。
用户通过第一客户端的操作生成医疗就诊数据的共享请求后，服务器根据共享请求对应的审批关联关系，向审批关联关系所表征的至少一个客户端，逐级触发审批流程，直至共享请求审批通过。
上述审批关联关系可以是基于医疗机构的审批关联关系。例如，审批关联关系可以是医疗机构B负责审批医疗机构A的共享请求。示例性的，医疗机构B的客户端C负责审批医疗机构A的所有客户端的共享请求。即，当医疗机构A的某一客户端发起共享请求后，服务器可以将该共享请求推送至客户端C进行审批处理。
上述审批关联关系可以是设置在第一数据库中的，也可以是用户通过第一客户端触发共享请求时，选择或者输入的。
以设置在第一数据库中为例，例如，用户通过客户端输入至少一个医疗机构的信息，例如可以包括医疗机构名称、等级、地址等基本信息。然后，服务器可以采用工作流(flow)引擎，建立医疗机构之间的单向审批关联关系，并将该审批关联关系存储至第一数据库中。图10为本申请实施例提供的一种可能的医疗机构之间单向审批关联的界面示意图，如图10所示，医疗就诊数据共享系统通过单向关联医疗机构，可以保证审批流程贯通。
在该共享请求审批通过后、且到达目标时间时，服务器可以从文件子系统中获取该医疗就诊数据，向第一客户端和第二客户端分发包括医疗就诊数据的数据流，以将医疗就诊数据分享给第二客户端，实现数据共享。
一种可能的实现方式，以数据共享为发起会诊为例，会诊请求审批通过之后，参加会议的用户通过第二客户端的界面根据会诊请求的目标时间进入会议。服务器与声网(Agora)服务器连接，服务器自动调用agora声网提供的会议服务地址，使用agora声网提供的会议服务实现数据共享。图11为本申请实施例提供的一种可能的会诊会议开始的界面示意图，如图11所示，参加会议的用户通过该会议界面可以查看会诊信息，其中包括目标患者的基本信息和影像图像。在会诊人员列表显示所有参加会议的用户，参加会议的用户可以通过该会议界面点击屏幕共享控件实现影像图像的共享，还可以通过该会议界面的图像浏览和图像工具实现对影像图像的浏览和编辑。参加会议的用户可以实时在该会议界面提供的会诊报告中记录重要信息，所有参加会议的用户可以通过该会议界面查看会诊报告，同时agora声网服务器会自动实时进行会议信息记录，通过该会议界面实时显示信息记录。
如图11所示，采用agora声网提供数据共享服务，会诊会议功能实现可以包括下述至少一种：
1、采用agora声网一站式解决方案，集实时音视频、屏幕共享、文档共享、互动白板(即会诊报告)、实时消息、录制留存等功能的一站式智慧医疗解决方案，满足医疗诊断需求。
2、基于声网Agora音视频编解码算法和优异弱网对抗能力，支持1080逐行扫描(Progressive scanning，P)60画面每秒传输帧数(Frame Per Second，FPS)超清视频，48千赫兹(kHz)全频带音频编码，患者患处、手术细节清晰呈现。其中，弱网是指网络比较弱，通常称为网络信号差、网速慢，网络会出现延迟、中断、抖动、超时等情况。
3、agora声网在进行医疗就诊数据传输过程中，经过多重鉴权控制、传输加密、异地容灾等安全机制，更提供实时运维监控服务。其中，鉴权控制是指对用户的身份权利的真实性进行鉴别；异地容灾是指在不同的地域，构建一套或者多套相同的医疗就诊数据共享系统或者第一数据库，起到灾难后立刻接管的作用。agora声网的安全机制保证了agora声网在进行医疗就诊数据传输过程的安全性和保密性，同时对医疗就诊数据共享系统及第一数据库起到了安全性、业务连续性等方面的作用。
会诊会议结束后，会诊报告及会议录屏视频存储在服务器本地以及文件子系统中，方便用户随时调阅。
本申请实施例提供的医疗就诊数据共享方法，任一客户端可以将其所属的医疗机构产生并存储在医疗就诊数据共享系统上的医疗就诊数据，共享至其他客户端。该第二客户端与第一客户端可以是同一医疗机构的客户端，也可以是隶属不同医疗机构的客户端。通过上述方法，可以实现医疗就诊数据的共享。
下面对步骤S101中如何获取目标患者的基本信息进行说明。图12为本申请实施例提供的一种获取目标患者的基本信息的方法的流程示意图。该方法可以由服务器执行，如图12所示，该方法包括：
S201、响应于用户通过第一客户端输入的目标患者的标识，从第一数据库查询目标患者的基本信息。
如前所述，查询索引可以采用“患者的文档”的格式存储于第一数据库中。其中，患者的文档可以包括：患者的基本信息，以及，患者的至少一个医疗就诊数据在文件子系统上的存储地址。
因此，本实施例中，继续参照如图8所示界面，用户可以通过第一客户端所示“会诊患者资料”界面点击查询控件。用户可以通过该界面输入目标患者的标识，服务器可以根据目标患者的标识，从第一数据库查询目标患者的文档，以此判断是否存在目标患者的基本信息。
若在第一数据库中查询到目标患者的文档，说明该系统中存储有目标患者的基本信息，则执行步骤S202；若在第一数据库中未查询到目标患者的文档，说明该系统中未存储有目标患者的基本信息，则执行步骤S203。
S202、响应于在第一数据库中查询到目标患者的文档，则从该目标患者的文档中获取目标患者的基本信息。
如图8所示，若该系统中存储有目标患者的基本信息，服务器从第一数据库获取该目标患者的基本信息，第一客户端所示“会诊患者资料”界面显示目标患者的基本信息。
S203、响应于在第一数据库中未查询到目标患者的文档，输出提示信息，该提示信息用于表征第一数据库中无该目标患者的文档。执行步骤S204。
服务器可以通过第一客户端输出该提示信息，例如在第一客户端的界面上显示该提示信息。
S204、响应于用户通过第一客户端输入的目标患者的基本信息，获取目标患者的基本信息，并在第一数据库中构建目标患者的文档。
如图8所示，用户可以通过第一客户端所示“会诊患者资料”界面点击添加控件，服务器在第一数据库中构建目标患者的文档，用户通过第一客户端所示“会诊患者资料”界面输入目标患者的基本信息。服务器将目标患者的基本信息存储在第一数据库中。
下面对步骤S101中如何获取目标患者待共享的医疗就诊数据在文件子系统的存储地址进行说明，具体可以包括如下两种情况：
第一种情况：响应于用户通过第一客户端针对医疗就诊数据的添加操作，获取已存储在文件子系统中的目标患者的医疗就诊数据在文件子系统的存储地址。即，预先在文件子系统中存储有医疗就诊数据的影像图像。
图13为本申请实施例提供的一种获取原始影像文件的方法的流程示意图。该方法可以由服务器执行，如图13所示，该方法包括：
S301、通过前置机，从目标患者就诊的医疗机构的本地数据库获取原始影像文件。
例如，服务器接收用户通过第三客户端触发的传输服务的启动请求，从第一数据库获取各传输服务的服务状态；一个传输服务用于从一个医疗机构的本地数据库获取原始影像文件。然后服务器输出各传输服务的服务状态。
其中，传输服务用于表征服务器从一个医疗机构的本地数据库获取原始影像文件的服务，例如传输服务可以是DICOM服务。传输服务的服务状态可以包括：启动，停用。
以传输服务为DICOM服务为例，图14为本申请实施例提供的一种可能的DICOM服务状态的界面示意图，如图14所示，用户可以通过第三客户端上显示的DICOM服务界面控制DICOM服务的启动与停用。其中，该用户例如可以是系统运维人员。
可能地，用户可以通过第三客户端显示的DICOM服务界面点击启动控件，服务器从第一数据库获取DICOM服务的启动服务状态，利用浏览器技术进行动态回显界面展示；同时，服务器自动注册一个DICOM服务进程，即表征DICOM服务正在运行。用户也可以通过第三客户端显示的DICOM服务界面点击停用控件，服务器从第一数据库获取DICOM服务的停用服务状态，利用浏览器技术进行动态回显界面展示；同时，服务器自动注销该DICOM服务进程，即表征DICOM服务停止运行。其中，浏览器技术例如可以是异步JavaScript和可扩展标记语言(Extensible Markup Language，XML)(Asynchronous Javascript And XML，Ajax)技术。
如图14所示，通过利用浏览器技术，第三客户端显示的DICOM服务界面的右上角可以动态的显示DICOM服务的状态。例如，当DICOM服务启动时，第三客户端上显示的DICOM服务界面的右上角显示“启用”字样，同时该字样后的三个按钮中的第一个按钮亮起；当DICOM服务停用时，第三客户端上显示的DICOM服务界面的右上角显示“停用”字样，同时该字样后的三个按钮中的第二个按钮亮起。
服务器通过利用浏览器技术，可以快速地回应用户的操作，不需要重新刷新整个界面。
图15为本申请实施例提供的一种可能的DICOM服务状态界面中服务参数的界面示意图，如图15所示，用户可以通过第三客户端显示的DICOM服务界面进行服务参数的设置。例如，用户可以通过第三客户端显示的DICOM服务界面点击新增或删除控件，实现对客户端的网际互连协议(Internet Protocol，IP)地址、端口号、数据库名称、存储路径等服务参数的增加和删除。同时，用户还可以通过该界面查看待处理文件(即待存储至医疗就诊数据共享系统的影像文件)的数量和影像数据日志等信息。其中，影像数据日志用于记录医疗就诊数据共享系统从获取影像图像到存储影像图像的过程。
传输服务启动后，服务器可以利用程序脚本，控制前置机从目标患者就诊的医疗机构的本地数据库统计当前待处理文件的数量并下载原始影像文件。该程序脚本例如可以是shell脚本。
S302、从医疗机构的本地数据库获取到原始影像文件之后，检测该原始影像文件的格式是否为预设格式。服务器响应于原始影像文件的格式是预设格式，则执行步骤S303；服务器响应于原始影像文件的格式不是预设格式，则输出提示信息，该提示信息表征原始影像文件的格式不是预设格式，该原始影像文件无法上传至文件子系统。
本申请实施例以原始影像文件为DICOM文件为例，对服务器如何检测文件格式是否为预设格式进行说明：
DICOM文件的内容包括：128字节的导言部分、四个字节组成的“dicm”字符串，以及，若干数据元素依次排列直至文件结束。服务器检测文件格式时，由于导言部分没有实际信息，因此跳过导言部分，判断128字节后4个字符是否为dicm。若4个字符为dicm，则表明原始影像文件为DICOM文件；若4个字符不是dicm，则表明原始影像文件为非DICOM文件。
对于服务器如何检测其他影像文件的格式是否为预设格式，则依照其他影像文件的格式进行检测，在此不再赘述。
S303、解析该原始影像文件，得到目标患者的基本信息、以及，影像图像。
可选地，服务器响应于原始影像文件为压缩文件，则对该原始影像文件进行解压缩；对解压缩后的原始影像文件进行解析，得到目标患者的基本信息、以及，影像图像。服务器响应于原始影像文件为未压缩文件，则直接对该原始影像文件进行解析。
本申请实施例以原始影像文件为DICOM文件为例，对服务器如何解析原始影像文件进行说明：
DICOM文件可以为压缩文件，也可以为未压缩文件。若DICOM文件为压缩文件，则先应用DICOM解压缩协议对DICOM文件进行解压缩，再对解压缩后的DICOM文件进行解析；若DICOM文件为未压缩文件，则直接对DICOM文件进行解析。例如可以采用dcm4che标准解析DICOM文件。其中，dcm4che是指基于java语言开发的工具包，可以实现DICOM文件的解析。DICOM文件解析完成后，服务器取出目标患者的基本信息以及影像图像。
对于服务器如何解析其他格式的影像文件，则依照其他格式的影像文件的解析方法进行解析，在此不再赘述。
S304、将目标患者的基本信息、影像图像、原始影像文件存储至文件子系统，并将存储地址更新至目标患者的文档中。
服务器取出目标患者的基本信息后，根据目标患者的标识从第一数据库查询该目标患者的基本信息。若服务器在第一数据库中未查询到该目标患者的基本信息，则服务器将目标患者的基本信息存储至第一数据库中；若服务器在第一数据库中查询到该目标患者的基本信息，则服务器将原始影像文件和解析后生成的影像图像存储至文件子系统中，并将存储地址存储在第一数据库中的目标患者的文档中。
由于医疗机构的本地数据库存储的原始影像文件只能由医疗机构的用户使用，因此服务器需要通过前置机与医疗机构的本地数据库建立交互，以此实现原始影像文件的获取。
在该情况下，继续参照如图9所示界面，用户可以通过第一客户端所示界面点击添加检查数据控件，服务器从第一数据库查询目标患者的检查数据。可能地，检查数据可以包括：目标患者的检查基本信息(例如可以包括检查项目、检查时间、检查部位、检查设备等)、影像图像，以及，附件等。其中，附件例如可以包括：检查记录单、相关单据或其它图片等。
若在第一数据库查询到目标患者的检查基本信息，服务器从第一数据库获取该目标患者的检查基本信息列表，该目标患者的检查基本信息列表显示在第一客户端所示界面。用户通过该界面选择待共享的检查基本信息，该界面显示待共享目标患者的检查基本信息。
若在第一数据库未查询到目标患者的检查基本信息，服务器输出提示信息，该提示信息用于表征第一数据库中无该目标患者的检查基本信息，第一客户端所示界面显示该提示信息。然后用户通过第一客户端所示界面点击添加检查数据控件，输入目标患者的检查基本信息，服务器将该目标患者的检查基本信息存储至第一数据库。
然后，用户可以通过第一客户端所示界面点击添加影像文件控件，服务器从第一数据库获取目标患者的影像图像的标识列表，该标识列表显示在第一客户端所示界面。用户通过该界面选择待共享的影像图像的标识，第一客户端所示界面显示该影像图像的标识，服务器根据该影像图像的标识获取目标患者待共享的影像图像在文件子系统的存储地址。
可选地，如图9所示，用户还可以通过第一客户端所示界面点击添加附件控件，主动上传待共享的附件。服务器通过采用多部件文件(MultipartFile)接口从文件传输设备获取该附件，并将该附件存储至文件子系统。
第二种情况：响应于用户通过第一客户端针对医疗就诊数据的本地上传操作，将医疗就诊数据存储至文件子系统，并获取医疗就诊数据在文件子系统的存储地址。即，在触发数据共享时，上传影像图像。
图16为本申请实施例提供的另一种获取原始影像文件的方法的流程示意图。该方法可以由服务器执行，如图16所示，该方法包括：
S401、针对影像图像，从文件传输设备获取第一客户端推送的原始影像文件。
例如，如图8所示，用户可以通过第一客户端所示“会诊患者资料”界面点击上传控件，主动上传原始影像文件。该原始影像文件临时存储在文件传输设备。服务器利用程序脚本从文件传输设备下载该原始影像文件。
S402、从文件传输设备获取到原始影像文件之后，检测该原始影像文件的格式是否为预设格式。服务器响应于该原始影像文件的格式是预设格式，则执行步骤S403；服务器响应于该原始影像文件的格式不是预设格式，则输出提示信息，该提示信息表征原始影像文件的格式不是预设格式，该原始影像文件无法上传至文件子系统。
S403、解析该原始影像文件，得到目标患者的基本信息、以及，影像图像。
S404、将目标患者的基本信息、影像图像、原始影像文件存储至文件子系统，并将存储地址更新至目标患者的文档中。
对于上述步骤S402、S403和S404中所涉及的如何检测原始影像文件格式、如何解析原始影像文件以及如何存储的方法，可以参照第一种情况中步骤S302、S303和S304对于各方法的描述，在此不再赘述。
由于医疗机构的本地数据库存储的原始影像文件只能由医疗机构的用户使用，且医疗机构不想进行数据共享，因此服务器需要通过文件传输设备与医疗机构的用户的终端设备建立交互，以此实现原始影像文件的获取。
第三种情况：医疗就诊数据既包括预先在文件子系统中存储有医疗就诊数据的影像图像，以及，在触发数据共享时，上传影像图像。
对于第三种情况所涉及的步骤及方法，可以参照第一种情况和第二种情况中各步骤及方法的描述，在此不再赘述。
对于上述医疗就诊数据的存储方式，可选地，目标患者的影像图像和原始影像文件可以只存储在文件子系统，也可以在本地同步存储目标患者的影像图像和原始影像文件。本申请对此不做限定。
用户通过第一客户端添加影像文件，和/或，附件后，可以通过点击对应的预览控件实现预览。图17为本申请实施例提供的一种可能的影像预览界面的示意图，如图17所示，在该影像预览界面上可以显示对应的影像预览图像，以及，该影像对应的目标患者的基本信息、检查基本信息等。
上述图7-图11、图14、图15以及图17仅是示例性的提供了一种可能的界面，本申请对于具体的界面的设计不做具体限定，能实现上述功能即可。
对于上述获取医疗就诊数据并存储至文件子系统的方式，若当前触发的原始影像文件的上传数量较多，服务器根据当前触发的原始影像文件的上传数量，调整用于执行上传操作的线程池的大小。其中线程是服务器能够进行运算调度的最小单位。它被包含在进程之中，是进程中的实际运作单位。一个进程中可以并发多个线程，每条线程并行传输来自不同客户端的原始影像文件。而线程池就是线程的集合。
线程池在服务器启动时即创建大量空闲的线程。当服务器从医疗机构的本地数据库或终端设备获取原始影像文件时，线程池就会启动一条线程将存储在医疗机构的本地数据库或终端设备的原始影像文件传输至服务器，传输完成后，该线程再次返回线程池中成为空闲状态，等待下一次传输存储在医疗机构的本地数据库或终端设备的原始影像文件。
服务器支持多用户同时上传原始影像文件，文件子系统会依据原始影像文件类型(例如文件格式、文件内容等)对多个原始影像文件进行分类及分别存储。服务器可以根据当前触发的原始影像文件的上传数量，调整用于执行上传操作的线程池的大小。这样可以确保客户端连接时间最短，传输时间最快，避免阻塞。
需说明，在上述实施例中，用户通过第一客户端的操作，服务器可以通过端口转发界面地址实现界面跳转。该端口例如可以是反向代理全球广域网(World Wide Web，web)服务器(engine x，nginx)端口。
图18为本申请实施例提供的一种医疗就诊数据共享系统的结构示意图。应理解，图18仅是示例性地展示了医疗就诊数据共享系统的一种结构化示意图，本申请并不限定对医疗就诊数据共享系统中的模块的划分。如图18所示，医疗就诊数据共享系统包括获取模块11、读取模块12和分发模块13。可选地，该系统还可以包括下述至少一个模块：存储模块14、调整模块15、服务处理模块16、审批模块17。
下面简要地描述医疗就诊数据共享系统中的各个模块的功能：
获取模块11，用于响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成所述医疗就诊数据的共享请求；所述医疗就诊数据包括：所述目标患者的影像图像；
读取模块12，用于在所述共享请求审批通过之后、且到达所述目标时间时，从所述存储地址读取所述医疗就诊数据；
分发模块13，用于向所述第一客户端和所述第二客户端分发包括所述医疗就诊数据的数据流。
一种可能的实现方式，所述获取模块11，具体用于响应于用户通过第一客户端输入的所述目标患者的标识，从第一数据库查询所述目标患者的基本信息；响应于在所述第一数据库中查询到所述目标患者的文档，则从所述目标患者的文档中获取所述目标患者的基本信息；响应于在所述第一数据库中未查询到所述目标患者的文档，输出提示信息；响应于用户通过所述第一客户端输入的所述目标患者的基本信息，获取所述目标患者的基本信息，并在所述第一数据库中构建所述目标患者的文档。
其中，所述第一数据库中存储有至少一个患者的文档，所述文档包括：患者的基本信息，以及，患者的至少一个医疗就诊数据在文件子系统上的存储地址；所述提示信息用于表征所述第一数据库中无所述目标患者的文档。
一种可能的实现方式，所述获取模块11，具体用于响应于用户通过第一客户端针对医疗就诊数据的添加操作，获取已存储在文件子系统中的所述目标患者的医疗就诊数据在所述文件子系统的存储地址；和/或，响应于用户通过第一客户端针对医疗就诊数据的本地上传操作，将医疗就诊数据存储至文件子系统，并获取医疗就诊数据在文件子系统的存储地址。
例如，所述获取模块11，具体用于针对影像图像，从文件传输设备获取所述第一客户端推送的原始影像文件；检测所述原始影像文件的格式是否为预设格式；响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
示例性的，所述获取模块11，具体用于响应于所述原始影像文件为压缩文件，则对所述原始影像文件进行解压缩；对解压缩后的原始影像文件进行解析，得到所述目标患者的基本信息、以及，影像图像。
在该实现方式下，一种可能的实现方式，存储模块14，用于本地同步存储所述目标患者的影像图像和所述原始影像文件。
一种可能的实现方式，所述获取模块11，还用于通过前置机，从所述目标患者就诊的医疗机构的本地数据库获取原始影像文件；检测所述原始影像文件的格式是否为预设格式；响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
示例性的，所述获取模块11，具体用于响应于所述原始影像文件为压缩文件，则对所述原始影像文件进行解压缩；对解压缩后的原始影像文件进行解析，得到所述目标患者的基本信息、以及，影像图像。
在该实现方式下，一种可能的实现方式，存储模块14，用于本地同步存储所述目标患者的影像图像和所述原始影像文件。
一种可能的实现方式，调整模块15，用于根据当前触发的原始影像文件的上传数量，调整用于执行上传操作的线程池的大小。
一种可能的实现方式，服务处理模块16，用于接收用户通过第三客户端触发的传输服务的启动请求，从第一数据库获取各传输服务的服务状态；输出各传输服务的服务状态；一个所述传输服务用于从一个医疗机构的本地数据库获取原始影像文件。
一种可能的实现方式，审批模块17，用于根据所述共享请求对应的审批关联关系，向审批关联关系所表征的至少一个客户端，逐级触发审批流程，直至所述共享请求审批通过。
由于上述各模块的功能，本申请实施例提供的医疗就诊数据共享系统可向用户提供医疗就诊数据共享的业务。
需要说明的是，上述图18所示的医疗就诊数据共享系统的各模块的划分仅是一种示意，本申请对各模块的划分，以及，各模块的命名并不进行限定。
本申请还提供一种如图5所示的计算设备，计算设备中的处理器读取存储器存储的程序和数据集合以执行前述医疗就诊数据共享系统执行的医疗就诊数据共享方法。
本申请还提供了一种计算机可读存储介质，该计算机可读存储介质可以包括：U盘、移动硬盘、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random AccessMemory)、磁盘或者光盘等各种可以存储程序代码的介质，具体的，该计算机可读存储介质中存储有程序指令，程序指令用于上述实施例中的方法。
本申请还提供一种程序产品，该程序产品包括执行指令，该执行指令存储在可读存储介质中。计算设备的至少一个处理器可以从可读存储介质读取该执行指令，至少一个处理器执行该执行指令使得电子设备实施上述的各种实施方式提供的医疗就诊数据共享方法。
本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求书指出。
应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求书来限制。

Claims (13)

1.一种医疗就诊数据共享方法，其特征在于，所述方法包括：
响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成所述医疗就诊数据的共享请求；所述医疗就诊数据包括：所述目标患者的影像图像；
在所述共享请求审批通过之后、且到达所述目标时间时，从所述存储地址读取所述医疗就诊数据，并向所述第一客户端和所述第二客户端分发包括所述医疗就诊数据的数据流。
2.根据权利要求1所述的方法，其特征在于，所述响应于用户通过第一客户端的操作，获取目标患者的基本信息，包括：
响应于用户通过第一客户端输入的所述目标患者的标识，从第一数据库查询所述目标患者的基本信息；所述第一数据库中存储有至少一个患者的文档，所述文档包括：患者的基本信息，以及，患者的至少一个医疗就诊数据在文件子系统上的存储地址；
响应于在所述第一数据库中查询到所述目标患者的文档，则从所述目标患者的文档中获取所述目标患者的基本信息；
响应于在所述第一数据库中未查询到所述目标患者的文档，输出提示信息，所述提示信息用于表征所述第一数据库中无所述目标患者的文档；
响应于用户通过所述第一客户端输入的所述目标患者的基本信息，获取所述目标患者的基本信息，并在所述第一数据库中构建所述目标患者的文档。
3.根据权利要求2所述的方法，其特征在于，所述响应于用户通过第一客户端的操作，获取所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，包括：
响应于用户通过第一客户端针对医疗就诊数据的添加操作，获取已存储在文件子系统中的所述目标患者的医疗就诊数据在所述文件子系统的存储地址；
和/或，响应于用户通过第一客户端针对医疗就诊数据的本地上传操作，将医疗就诊数据存储至文件子系统，并获取医疗就诊数据在文件子系统的存储地址。
4.根据权利要求3所述的方法，其特征在于，所述响应于用户第一客户端针对医疗就诊数据的上传操作，将医疗就诊数据存储至文件子系统，包括：
针对影像图像，从文件传输设备获取所述第一客户端推送的原始影像文件；
检测所述原始影像文件的格式是否为预设格式；
响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；
将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
5.根据权利要求3所述的方法，其特征在于，所述方法还包括：
通过前置机，从所述目标患者就诊的医疗机构的本地数据库获取原始影像文件；
检测所述原始影像文件的格式是否为预设格式；
响应于所述原始影像文件为预设格式，则解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像；
将所述目标患者的基本信息、影像图像、所述原始影像文件存储至文件子系统，并将存储地址更新至所述目标患者的文档中。
6.根据权利要求4或5所述的方法，其特征在于，所述解析所述原始影像文件，得到所述目标患者的基本信息、以及，影像图像，包括：
响应于所述原始影像文件为压缩文件，则对所述原始影像文件进行解压缩；
对解压缩后的原始影像文件进行解析，得到所述目标患者的基本信息、以及，影像图像。
7.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：
本地同步存储所述目标患者的影像图像和所述原始影像文件。
8.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：
根据当前触发的原始影像文件的上传数量，调整用于执行上传操作的线程池的大小。
9.根据权利要求5所述的方法，其特征在于，所述方法还包括：
接收用户通过第三客户端触发的传输服务的启动请求，从第一数据库获取各传输服务的服务状态；一个所述传输服务用于从一个医疗机构的本地数据库获取原始影像文件；
输出各传输服务的服务状态。
10.根据权利要求1-5任一项所述的方法，其特征在于，所述方法还包括：
根据所述共享请求对应的审批关联关系，向审批关联关系所表征的至少一个客户端，逐级触发审批流程，直至所述共享请求审批通过。
11.一种医疗就诊数据共享系统，其特征在于，所述系统包括：
获取模块，用于响应于用户通过第一客户端的操作，获取目标患者的基本信息、请求共享的目标时间、待共享的第二客户端的标识、所述目标患者待共享的医疗就诊数据在文件子系统的存储地址，以生成所述医疗就诊数据的共享请求；所述医疗就诊数据包括：所述目标患者的影像图像；
读取模块，用于在所述共享请求审批通过之后、且到达所述目标时间时，从所述存储地址读取所述医疗就诊数据；
分发模块，用于向所述第一客户端和所述第二客户端分发包括所述医疗就诊数据的数据流。
12.一种计算设备，其特征在于，包括：处理器，以及与所述处理器通信连接的存储器；
所述存储器存储计算机执行指令；
所述处理器执行所述存储器存储的计算机执行指令，以实现如权利要求1至10中任一项所述的方法。
13.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机执行指令，所述计算机执行指令被处理器执行时用于实现如权利要求1至10任一项所述的医疗就诊数据共享方法。
CN202210502325.4A 2022-05-10 2022-05-10 医疗就诊数据共享方法、系统、计算设备及存储介质 Pending CN114822744A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210502325.4A CN114822744A (zh) 2022-05-10 2022-05-10 医疗就诊数据共享方法、系统、计算设备及存储介质

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210502325.4A CN114822744A (zh) 2022-05-10 2022-05-10 医疗就诊数据共享方法、系统、计算设备及存储介质

Publications (1)

Publication Number Publication Date
CN114822744A true CN114822744A (zh) 2022-07-29

Family

ID=82513165

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210502325.4A Pending CN114822744A (zh) 2022-05-10 2022-05-10 医疗就诊数据共享方法、系统、计算设备及存储介质

Country Status (1)

Country Link
CN (1) CN114822744A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115394392A (zh) * 2022-08-31 2022-11-25 西安交通大学 一种医疗数据的共享系统及方法
CN115442332A (zh) * 2022-08-30 2022-12-06 潍柴动力股份有限公司 一种资源共享的方法及装置、电子设备、存储介质
CN115662581A (zh) * 2022-12-28 2023-01-31 神州医疗科技股份有限公司 一种医学影像互动系统、应用及方法

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115442332A (zh) * 2022-08-30 2022-12-06 潍柴动力股份有限公司 一种资源共享的方法及装置、电子设备、存储介质
CN115442332B (zh) * 2022-08-30 2023-06-23 潍柴动力股份有限公司 一种资源共享的方法及装置、电子设备、存储介质
CN115394392A (zh) * 2022-08-31 2022-11-25 西安交通大学 一种医疗数据的共享系统及方法
CN115394392B (zh) * 2022-08-31 2023-06-20 西安交通大学 一种医疗数据的共享系统及方法
CN115662581A (zh) * 2022-12-28 2023-01-31 神州医疗科技股份有限公司 一种医学影像互动系统、应用及方法

Similar Documents

Publication Publication Date Title
CN114822744A (zh) 医疗就诊数据共享方法、系统、计算设备及存储介质
US9954915B2 (en) Remote cine viewing of medical images on a zero-client application
US20170103047A1 (en) Mechanisms to Compose, Execute, Save, and Retrieve Hyperlink Pipelines in Web Browsers
US8788699B2 (en) Information processing apparatus and document data producing method
US20100268694A1 (en) System and method for sharing web applications
CN111901674A (zh) 一种视频播放控制及装置
WO2018107719A1 (zh) 数据分享方法、装置、终端设备和服务器
US20190371023A1 (en) Method and apparatus for generating multimedia content, and device therefor
CN112382372B (zh) 一种基于网络页面查看dicom文件的系统、方法及设备
WO2020233168A1 (zh) 图片类评论数据的网络存储方法、装置、电子设备及介质
JP6355341B2 (ja) 情報処理端末、情報処理端末の制御方法およびプログラム
US20190146645A1 (en) Replaying event-based sessions between a user device and an agent device
US20210360053A1 (en) File storage and retrieval
US20150149586A1 (en) Information processing apparatus, information processing method, and information processing system
JP2017527872A (ja) クラウドストリーミングサービス提供方法、そのための装置及びシステム、並びにそのためのクラウドストリーミング用スクリプトコードを記録したコンピュータ読み取り可能な記録媒体
CN105630948B (zh) 网络页面显示方法和装置
US9942287B2 (en) Information processing system, terminal device, and method
US20110179115A1 (en) Sharing of Documents with Semantic Adaptation Across Mobile Devices
CN114817794A (zh) 网页内容控制方法、装置、设备及介质
KR100625656B1 (ko) 자원공유 시스템 및 방법
US20190146807A1 (en) Establishing an event-based session between a user device and an agent device
CN114827753B (zh) 视频索引信息的生成方法、装置及计算机设备
CN111090485B (zh) 面向多集群的帮助数据处理方法及装置、介质和设备
JP2017212644A (ja) 通信装置、システム、情報処理方法及びプログラム
Di Nitto et al. Adaptation of web contents and services to terminals capabilities: The@ Terminals approach

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