CN113239096B - 一种提升dicom影像云归档入库速度的方法 - Google Patents

一种提升dicom影像云归档入库速度的方法 Download PDF

Info

Publication number
CN113239096B
CN113239096B CN202110746523.0A CN202110746523A CN113239096B CN 113239096 B CN113239096 B CN 113239096B CN 202110746523 A CN202110746523 A CN 202110746523A CN 113239096 B CN113239096 B CN 113239096B
Authority
CN
China
Prior art keywords
data
warehousing
redis database
index information
information
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
Application number
CN202110746523.0A
Other languages
English (en)
Other versions
CN113239096A (zh
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.)
Zhejiang Keyi Intelligent Medical Technology Co ltd
Original Assignee
Zhejiang Keyi Intelligent Medical Technology 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 Zhejiang Keyi Intelligent Medical Technology Co ltd filed Critical Zhejiang Keyi Intelligent Medical Technology Co ltd
Priority to CN202110746523.0A priority Critical patent/CN113239096B/zh
Publication of CN113239096A publication Critical patent/CN113239096A/zh
Application granted granted Critical
Publication of CN113239096B publication Critical patent/CN113239096B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

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
    • 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
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2471—Distributed queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/27—Replication, distribution or synchronisation of data between databases or within a distributed database system; Distributed database system architectures therefor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Health & Medical Sciences (AREA)
  • Probability & Statistics with Applications (AREA)
  • Epidemiology (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Fuzzy Systems (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Nuclear Medicine, Radiotherapy & Molecular Imaging (AREA)
  • Radiology & Medical Imaging (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Medical Informatics (AREA)
  • Primary Health Care (AREA)
  • Public Health (AREA)
  • Computing Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Medical Treatment And Welfare Office Work (AREA)

Abstract

本发明公开了一种提升DICOM影像云归档入库速度的方法。为了克服现有技术因影像云数据量巨大、并发量高、峰值明显带来的归档存储难度大、速度慢的问题；本发明包括以下步骤：S1：解析DICOM文件，获取病人信息ID、检查信息UID、序列信息UID、图像信息UID和租户ID数据组成一条入库数据；S2：将解析获取的数据缓存至Redis数据库中；多线程地从Redis数据库中进行索引并读取数据；S3：数据归档入库；建立包括病人、检查、序列和实例的四级数据表库；将从Redis数据库中读取的有效数据，根据设置的单次入库数量限制将数据批量入库，完成将DICOM文件上传至影响云平台。提升DICOM影像云归档入库速度并且减少并发冲突，提高归档效率。

Description

一种提升DICOM影像云归档入库速度的方法
技术领域
本发明涉及一种医学影像归档领域，尤其涉及一种提升DICOM影像云归档入库速度的方法。
背景技术
图像存储与传输***(Picture Archiving and Communication System, PACS)是专门为医学影像检查图像管理而设计的包括图像存储、传输、显示、处理信息化***。医学检查图像存储格式采用DICOM3.0(Digital Imaging and Communications inMedicine：医疗数字成像和通信)标准。
DICOM(Digital Imaging and Communications in Medicine)即医学数字成像和通信，是医学图像和相关信息的国际标准(ISO 12052)。它定义了质量能满足临床需要的可用于数据交换的医学图像格式。
全院级PACS***涵盖整个医院的影像信息，并联动放射、超声、核医学、内镜、病理等多个影像科室，响应其对医疗影像数据的需求。
影像云是将单个医院或多个医院的全院PACS中的影像数据上传归档到云平台上，实现各医疗影像检查数据跨院、跨区域互联互通，医生或患者通过移动设备即可调阅报告及DICOM影像，对实现远程影像诊断、会诊服务以及医学影像信息共享、实行检查检验结果互认，提高医疗服务效率，减少患者来回跑医院时间具有重要意义。
随着医疗信息化程度的加深，医院医疗数据的存储量也随之攀升，影像云数据量巨大、并发量高、峰值明显，为影像数据的存储和归档，带来了巨大的挑战。
例如，一种在中国专利文献上公开的“一种基于分布式计算技术的医疗影像云归档平台”，其公告号CN111739613A，包括：DICOM服务集群，响应影像归档请求和影像调阅请求；影像归档服务器，根据影像归档请求对影像文件进行解析并分别构建影像文件对应的患者索引信息、检查索引信息、序列索引信息和文件索引信息；将患者索引信息和检查索引信息导入第一数据库，将序列索引信息和文件索引信息导入第二数据库，将影像文件导入第三数据库；影像调阅服务器，根据影像调阅请求由第一数据库中获取患者索引信息和检查索引信息，由第二数据库中获取序列索引信息和文件索引信息，进而由第三数据库中获取影像文件。该方案无法解决因影像云数据量巨大、并发量高、峰值明显带来的归档存储难度大、速度慢的问题。
发明内容
本发明主要解决现有技术因影像云数据量巨大、并发量高、峰值明显带来的归档存储难度大、速度慢的问题；提供一种提升DICOM影像云归档入库速度的方法，使用分布式高速缓存，数据库批量入库的特性,将单条入库的数据转换成批量入库,提升数据入库的效率。
本发明的上述技术问题主要是通过下述技术方案得以解决的：
本发明包括以下步骤：
S1：解析DICOM文件，获取病人信息ID、检查信息UID、序列信息UID、图像信息UID和租户ID数据组成一条入库数据；
S2：将解析获取的数据缓存至Redis数据库中；多线程地从Redis数据库中进行索引并读取数据；根据索引信息，经过ACK处理后，将Redis数据库中已处理的数据删除；
S3：数据归档入库；建立包括病人、检查、序列和实例的四级数据表库；将从Redis数据库中读取的有效数据，根据设置的单次入库数量限制将数据批量入库，完成将DICOM文件上传至影响云平台。
DICOM文件解析速度较慢，本方案只需进行少量必要数据的解析，减少重复解析，提高归档入库速度。若每条数据单独直接入库，数据量较大时，持续入库速度较慢。Redis是用C语言开发的一个开源的高性能基于内存运行的键值对NoSQL数据库。通过先将数据缓存至Redis中，再读取一定数量的数据进行批量入库，可以极大提高入库速度。使用分布式高速缓存，数据库批量入库的特性,将单条入库的数据转换成批量入库,提升数据入库的效率。
作为优选，所述的步骤S2包括以下步骤：
S201：数据清洗去重；Redis数据库以Set数据结构分别储存每条数据的病人信息ID、检查信息ID和序列信息ID；
S202：数据写入；将每条入库数据生成唯一标志Key，写入Redis数据库；将每条数据对应的位置索引写入到Redis数据库中的链表list中；
S203：多线程数据读取；根据数据索引信息从Redis数据库中读取对应的数据；将数据索引信息从链表list中删除，并根据数据索引信息从Redis数据库中删除对应的数据；
S204：定时ACK处理；在数据读取过程中将数据索引信息和数据缓存到本地，根据本地定时判断数据处理是否超时的结果，删除彻底删除Redis数据库中数据。
通过先将数据缓存至Redis数据库中，再读取一定数量的数据进行批量入库，可以极大提高入库速度。
作为优选，每条入库数据生成唯一标志Key的过程为：
拼接租户ID和图像信息UID的字符串，经过HASH256运算后的值为唯一标志Key。
每个DICOM文件的图像信息UID（SOPInstanceUID）都是唯一的，每次缓存的时候，单个DICOM文件解析出来的数据是一个操作单位。根据租户ID(医院编码)+SOPInstanceUID生成唯一标志。
作为优选，所述的多线程数据读取过程包括：
(1)从Redis数据库的链表list中读取数据索引信息；
(2)根据读取到的数据索引信息,从Redis数据库中读取对应的数据；
(3)将已经读取到的数据索引信息以及数据处理的时限，放入表示“处理中”的hash表中；
(4)将数据索引信息从链表list中删除；
(5)数据处理成功后，将数据索引信息从表示“处理中”的hash表中移除；
(6)根据数据索引信息，将Redis数据库中的已处理数据删除。
应用可以在多个机器上部署,单个应用下也可以启动多个线程去处理Redis中的数据,进行数据入库，提高入库效率。
作为优选，所述的定时ACK处理过程包括：
(1)在从Redis数据库中读取数据索引信息以及数据的同时，将数据索引信息以及数据缓存到本地内存中；
(2)后台定时线程从本地内存中读取该数据，根据预存的数据处理的时限判定数据处理是否超时；
当数据处理判断为超时的时候，则将数据索引信息从表示“处理中”hash表内重新存入链表list中，同时删除本地内存中的缓存数据；
当数据处理为未超时的时候，则循环轮询本地内存中数据处理是否超时。
由于从Redis取走数据后,可能应用机器发生宕机，或者程序关闭，该部分数据就会丢失。因此需要有个ACK的过程,来避免数据丢失，只有在ACK之后,数据才会真正的从Redis中删除。
作为优选，宕机或者应用重启之后,会先从Redis数据库中的表示“处理中”hash表内加载数据至本地缓存。
避免宕机或重启后数据丢失。
作为优选，所述的步骤S3包括以下步骤：
S301：建立数据表库，数据表库包括病人、检查、序列和实例四级；
病人表以病人信息ID作为唯一标志；
检查表以检查信息UID作为唯一标志；
序列表以序列信息UID作为唯一标志；
实例表以图像信息UID作为唯一标志；
S302：根据单表的字段数，将数据库参数除以单表字段数的结果取整，计算获得每表入库的数据量上限值；
Figure DEST_PATH_IMAGE002
其中，
Figure DEST_PATH_IMAGE004
为计算得到的单张表入库的数据量上限值；
Figure DEST_PATH_IMAGE006
为数据库参数；
Figure DEST_PATH_IMAGE008
为单表字段数；
S303：数据归档入库；将从Reids数据库中读取到的数据剔除为空的项后，使用Redis数据库的InsertOrUpdate方法写入数据库；
S304：完成DICOM文件的影像云平台上传。
根据单表的字段数,计算出每张表入库数据最恰当的数据量,每次入库***不超过该数量值的数据。避免影响入库速度。
本发明的有益效果是：
1. 只需进行少量必要数据的解析，减少重复解析，提高归档入库速度。
2. 先将数据缓存至Redis中，再读取一定数量的数据进行批量入库，极大提高入库速度。
3.使用分布式高速缓存，数据库批量入库的特性，将单条入库的数据转换成批量入库，提升数据入库的效率。
4.采用 ACK的过程，避免宕机或重启后数据丢失。
附图说明
图1是本发明的一种影像云归档存储方法流程示意图。
图2是本发明的一种步骤S2的流程示意图。
具体实施方式
下面通过实施例，并结合附图，对本发明的技术方案作进一步具体的说明。
实施例：
本实施例的一种提升DICOM影像云归档入库速度的方法，如图1所示，包括以下步骤：
S1：解析DICOM文件，获取病人信息ID、检查信息UID、序列信息UID、图像信息UID和租户ID数据组成一条入库数据。
对输入的DICOM文件进行解析，获取其中的病人信息ID（Patient ID）、检查信息UID（Study Instance UID）、序列信息UID（Series Instance UID）、图像信息UID（SOPInstance UID），并加上多租户下的租户ID，组成一条入库数据，作为DICOM文件的索引信息。
DICOM文件解析速度较慢，只需此步骤进行少量必要数据的解析，减少重复解析，提高归档入库速度。
每个DICOM文件,内部保存了一系列的Tag值, 这些Tag值以类似树状结构的形式进行存储。可以通过DICOM标准协议从DICOM文件中将相关节点的Tag 值读取出来，DICOMTag里面的值长度在标准下通常长度是不超过64的,尤其是作为唯一键的几个UID。
病人信息ID (Patient ID)为每个检查中的病人标志。在同一个检查下面,会生成多个影像文件(DICOM文件),但是DICOM中的Patient ID这个节点的Tag值都应该是相同的。通常在一家医院中,每个检查的Patient ID都应该是唯一的。如: 874597。
检查UID (Study Instance UID)为每个检查的唯一标志符号,在同一家医院下Study Instance UID应该保持唯一性。一个检查下有多个DICOM图像，它 们的StudyInstance UID都是相同的。
如: 1.2.392.200036.9116.2.6.1.48.1215544645.1119340078.95700。
序列UID(Series Instance UID)为每个检查下面会有一个或者多个“序列(Series)”，每个序列都拥有一个唯一的序列号。序列号通常都保持唯一性。如: 1.2.392.200036.9116.2.6.1.48.1215544645.1119341130.544939。
图像UID(SOP Instance UID)为每个检查下面会有一个或者多个序列，每个序列下面会有一个或者多个图像(图像就是所说的DICOM文件)。通常情况下，每个图像都有一个唯一的标志(SOP Instance UID)。
如: 1.2.392.200036.9116.2.6.1.48.1215544645.1119341186.386533。
S2：将解析获取的数据缓存至Redis数据库中；多线程地从Redis数据库中进行索引并读取数据；根据索引信息，经过ACK处理后，将Redis数据库中已处理的数据删除。
若每条数据单独直接入库，数据量较大时，持续入库速度较慢。Redis数据库是用C语言开发的一个开源的高性能基于内存运行的键值对NoSQL数据库。通过先将数据缓存至Redis数据库中，再读取一定数量的数据进行批量入库，可以极大提高入库速度。
如图2所示，步骤S2具体包括以下步骤：
S201：数据清洗去重；Redis数据库以Set数据结构分别储存每条数据的病人信息ID、检查信息ID和序列信息ID。
（1）创建Set分别用来存储每条数据的Patient ID、Study Instance UID、SeriesInstance UID。
Set是Redis的一种数据结构，其特性为：每次***数据时，若数据不在Set中，则将数据***Set；若数据已存在Set中，则不会将数据***Set。实现数据去重，减少内存开销。
（2）将每条数据的Patient ID***Patient ID Set。若Set中已存在，则将数据中的Patient ID设为空。
（3）将每条数据的Study Instance UID***Study Instance UID Set。若Set中已存在，则将数据中的Study Instance UID设为空。
（4）将每条数据的Series Instance UID***Series Instance UID Set。若Set中已存在，则将数据中的Series Instance UID设为空。
S202：数据写入；将每条入库数据生成唯一标志Key，写入Redis数据库；将每条数据对应的位置索引写入到Redis数据库中的链表list中。
（1）写入数据，将每条数据生成唯一标志作为Key，写入Redis数据库中。
（2）写入数据索引，将每条数据位置索引写入到Redis数据库中的链表（list）中。
（3）对上述步骤（1）与步骤（2）使用Redis数据库的事务进行一致性保证。
每条入库数据生成唯一标志Key的过程为：
拼接租户ID和图像信息UID的字符串，经过HASH256运算后的值为唯一标志Key。
S203：多线程数据读取；根据数据索引信息从Redis数据库中读取对应的数据；将数据索引信息从链表list中删除，并根据数据索引信息从Redis数据库中删除对应的数据。
多线程数据读取过程包括：
(1)从Redis数据库的链表list中读取数据索引信息。
(2)根据读取到的数据索引信息,从Redis数据库中读取对应的数据。
(3)将已经读取到的数据索引信息以及数据处理的时限，放入表示“处理中”的hash表中。
(4)将数据索引信息从链表list中删除。
(5)数据处理成功后，将数据索引信息从表示“处理中”的hash表中移除。
(6)根据数据索引信息，将Redis数据库中的已处理数据删除。
S204：定时ACK处理；在数据读取过程中将数据索引信息和数据缓存到本地，根据本地定时判断数据处理是否超时的结果，删除彻底删除Redis数据库中数据。
由于从Redis数据库取走数据后,可能应用机器发生宕机，或者程序关闭，该部分数据就会丢失。因此需要有个ACK的过程,来避免数据丢失，只有在ACK之后,数据才会真正的从Redis数据库中删除。
定时ACK处理过程包括：
(1)在从Redis数据库中读取数据索引信息以及数据的同时，将数据索引信息以及数据缓存到本地内存中。
(2)后台定时线程从本地内存中读取该数据，根据预存的数据处理的时限判定数据处理是否超时。
当数据处理判断为超时的时候，则将数据索引信息从表示“处理中”hash表内重新存入链表list中，同时删除本地内存中的缓存数据；
当数据处理为未超时的时候，则循环轮询本地内存中数据处理是否超时。
当处理超时的时候，则从Redis数据库的“处理中”hash表内重新存入数据索引list中，同时删除本地缓存数据。在本地缓存进行超时的判断,能大幅度的提高读写性能。如果直接从Redis数据库中读取，一个是存在多线程上的并发问题，必须要使用Redis锁；另一个是每次从Redis数据库中读写数据远远比读写本地内存数据要慢。
宕机或者应用重启之后,会先从Redis数据库中的表示“处理中”hash表内加载数据至本地缓存。
S3：数据归档入库；建立包括病人、检查、序列和实例的四级数据表库；将从Redis数据库中读取的有效数据，根据设置的单次入库数量限制将数据批量入库，完成将DICOM文件上传至影响云平台。
S301：建立数据表库，数据表库包括病人、检查、序列和实例四级；
由于DICOM标准协议，作为图像调阅端，调阅的时候通常以检查（Study）为单位，根据检查（UID）StudyInstanceUID或者访问号（AccessionNo）进行调阅。因此，数据库表分为四级进行创建，包括：病人（Patient），检查（Study），序列（Series），实例（Instance）。表之间使用各自级别的UID作为唯一标志。
病人表以病人信息ID作为唯一标志；
检查表以检查信息UID作为唯一标志；
序列表以序列信息UID作为唯一标志；
实例表以图像信息UID作为唯一标志。
病人（Patient），检查（Study），序列（Series）和实例（Instance）对应的DICOM中的几种数据关系。Patient 与 Study 1:1的关系, Study与Series 1*N的关系, Series与Instance(图像) 1*N的关系。
创建这种表结构的依据,一个是DICOM协议中定义的相互之间的关系。第二种是在DICOM应用中一些功能，比如 QR功能，就是 SCU 从 SCP端按照查询条件查询功能，QR功能在DICOM标准协议中有定义，支持 Patient级别，Study级别，Series级别，Image级别，Worklist级别。因此为了QR等功能的方便查询，按照三级关系进行建表。
S302：根据单表的字段数，将数据库参数除以单表字段数的结果取整，计算获得每表入库的数据量上限值；
Figure DEST_PATH_IMAGE002A
其中，
Figure 334439DEST_PATH_IMAGE004
为计算得到的单张表入库的数据量上限值；
Figure 907371DEST_PATH_IMAGE006
为数据库参数；
Figure 952688DEST_PATH_IMAGE008
为单表字段数。
当入库的数据较多的时候,由于各个数据库的参数数量的限制,容易出现参数量超限制。会导致必须开启事物来保证一次入库数据的一致性，从而影响入库速度。因此，根据单表的字段数,计算出每张表入库数据最恰当的数据量,每次入库***不超过该数量值的数据。
S303：数据归档入库；将从Reids数据库中读取到的数据剔除为空的项后，使用Redis数据库的InsertOrUpdate方法写入数据库。
避免在入库的时候,需要进行的重复数据的查询,提升数据的入库速度。
S304：完成DICOM文件的影像云平台上传。
本实施例的方案只需进行少量必要数据的解析，减少重复解析，提高归档入库速度。先将数据缓存至Redis中，再读取一定数量的数据进行批量入库，极大提高入库速度。使用分布式高速缓存，数据库批量入库的特性，将单条入库的数据转换成批量入库，提升数据入库的效率。
应理解，实施例仅用于说明本发明而不用于限制本发明的范围。此外应理解，在阅读了本发明讲授的内容之后，本领域技术人员可以对本发明作各种改动或修改，这些等价形式同样落于本申请所附权利要求书所限定的范围。

Claims (3)

1.一种提升DICOM影像云归档入库速度的方法，其特征在于，包括以下步骤：
S1：解析DICOM文件，获取病人信息ID、检查信息UID、序列信息UID、图像信息UID和租户ID数据组成一条入库数据；
S2：将解析获取的数据缓存至Redis数据库中；多线程地从Redis数据库中进行索引并读取数据；根据索引信息，经过ACK处理后，将Redis数据库中已处理的数据删除；
S3：数据归档入库；建立包括病人、检查、序列和实例的四级数据表库；将从Redis数据库中读取的有效数据，根据设置的单次入库数量限制将数据批量入库，完成将DICOM文件上传至影像云平台；
所述的步骤S2包括以下步骤：
S201：数据清洗去重；Redis数据库以Set数据结构分别储存每条数据的病人信息ID、检查信息ID和序列信息ID；
S202：数据写入；将每条入库数据生成唯一标志Key，写入Redis数据库；将每条数据对应的位置索引写入到Redis数据库中的链表list中；
S203：多线程数据读取；根据数据索引信息从Redis数据库中读取对应的数据；将数据索引信息从链表list中删除，并根据数据索引信息从Redis数据库中删除对应的数据；
S204：定时ACK处理；在数据读取过程中将数据索引信息和数据缓存到本地，根据本地定时判断数据处理是否超时的结果，彻底删除Redis数据库中数据；
所述的多线程数据读取过程包括：
(1)从Redis数据库的链表list中读取数据索引信息；
(2)根据读取到的数据索引信息,从Redis数据库中读取对应的数据；
(3)将已经读取到的数据索引信息以及数据处理的时限，放入表示“处理中”的hash表中；
(4)将数据索引信息从链表list中删除；
(5)数据处理成功后，将数据索引信息从表示“处理中”的hash表中移除；
(6)根据数据索引信息，将Redis数据库中的已处理数据删除；
所述的定时ACK处理过程包括：
(1)在从Redis数据库中读取数据索引信息以及数据的同时，将数据索引信息以及数据缓存到本地内存中；
(2)后台定时线程从本地内存中读取该数据，根据预存的数据处理的时限判定数据处理是否超时；
当数据处理判断为超时的时候，则将数据索引信息从表示“处理中”hash表内重新存入链表list中，同时删除本地内存中的缓存数据；
当数据处理为未超时的时候，则循环轮询本地内存中数据处理是否超时。
2.根据权利要求1所述的一种提升DICOM影像云归档入库速度的方法，其特征在于，每条入库数据生成唯一标志Key的过程为：
拼接租户ID和图像信息UID的字符串，经过HASH256运算后的值为唯一标志Key。
3.根据权利要求1所述的一种提升DICOM影像云归档入库速度的方法，其特征在于，宕机或者应用重启之后,会先从Redis数据库中的表示“处理中”hash表内加载数据至本地缓存。
CN202110746523.0A 2021-07-02 2021-07-02 一种提升dicom影像云归档入库速度的方法 Active CN113239096B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110746523.0A CN113239096B (zh) 2021-07-02 2021-07-02 一种提升dicom影像云归档入库速度的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110746523.0A CN113239096B (zh) 2021-07-02 2021-07-02 一种提升dicom影像云归档入库速度的方法

Publications (2)

Publication Number Publication Date
CN113239096A CN113239096A (zh) 2021-08-10
CN113239096B true CN113239096B (zh) 2022-06-24

Family

ID=77141235

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110746523.0A Active CN113239096B (zh) 2021-07-02 2021-07-02 一种提升dicom影像云归档入库速度的方法

Country Status (1)

Country Link
CN (1) CN113239096B (zh)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116627919A (zh) * 2023-06-14 2023-08-22 富士胶片（中国）投资有限公司 一种医学影像显示方法、***及电子设备、存储介质

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101340268B (zh) * 2008-08-18 2011-06-29 杭州华三通信技术有限公司 节点间通信确认机制的实现方法和实现***
US20140142984A1 (en) * 2012-11-21 2014-05-22 Datcard Systems, Inc. Cloud based viewing, transfer and storage of medical data
CN104113566B (zh) * 2013-04-18 2019-05-21 蓝网科技股份有限公司 一种医疗影像的云存储的实现方法
CN109299079A (zh) * 2018-09-11 2019-02-01 南京朝焱智能科技有限公司 一种高速数据库设计方法

Also Published As

Publication number Publication date
CN113239096A (zh) 2021-08-10

Similar Documents

Publication Publication Date Title
US11610653B2 (en) Systems and methods for improved optical character recognition of health records
US20090313194A1 (en) Methods and apparatus for automated image classification
CN110990390B (zh) 数据协同处理方法、装置、计算机设备和存储介质
US20140149132A1 (en) Adaptive medical documentation and document management
US20160203264A1 (en) Systems, methods, and computer program products for processing medical images to address privacy concerns
CN106933859B (zh) 一种医疗数据的迁移方法和装置
CN109857736A (zh) 医院异构***的数据编码统一化方法及***、设备、介质
CN109448811B (zh) 处方审核改进方法、装置、电子设备及存储介质
US11361020B2 (en) Systems and methods for storing and selectively retrieving de-identified medical images from a database
EP4170670A1 (en) Medical data processing method and system
CN115497631A (zh) 一种临床科研大数据分析***
EP2359273A1 (en) Data communication in a picture archiving and communications system network
CN113239096B (zh) 一种提升dicom影像云归档入库速度的方法
US20180046779A1 (en) Caching technology for clinical data sources
CN114625829A (zh) 文本信息提取方法、装置、介质及电子设备
CN111190902A (zh) 一种医疗数据的结构化方法、装置、设备及存储介质
CN112669943B (zh) 一种文件目录中dicom文件的解析方法
CN111279424A (zh) 用于优化图像采集工作流的设备、***和方法
CN115579094A (zh) 一种多模态医疗数据湖构建方法及***
WO2014114761A1 (en) Data management system
Kosvyra et al. Data Quality Check in Cancer Imaging Research: Deploying and Evaluating the DIQCT Tool
Houser et al. The Temple University Hospital Digital Pathology Corpus
CN113053479A (zh) 医学数据处理方法、装置、介质及电子设备
GB2573512A (en) Database and associated method
CN117038002B (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
GR01 Patent grant
GR01 Patent grant