DICOM文件处理方法、装置、计算机设备和存储介质与流程

dicom文件处理方法、装置、计算机设备和存储介质
技术领域
1.本技术涉及医学文件处理技术领域，特别是涉及一种dicom文件处理方法、装置、计算机设备和存储介质。


背景技术：

2.在相关的医疗信息系统中，针对dicom(digital imaging and communications in medicine，医学数字图像与通讯)协议的支持，不管是c 、c#或java的底层实现，都没有保证完全支持大文件的接收和发送。在相关技术中，在接收或者发送支持dicom协议的医学影像文件时，均需要将dicom文件完整读入内存或者全部生成医学影像的本地缓存文件，才可以实现接收或者发送。不同医疗影像设备生成的dicom文件大小也不同，很多dicom文件的大小会超过500m以上，有些dicom文件会非常大甚至达到数g以上。
3.由于dicom文件通常较大，若每次处理均将dicom文件完整读入内存，则随着dicom文件的数量增多以及对dicom文件的处理频次增多，从而会导致内存耗费急剧增大，医疗信息系统响应变慢。即使是读入至本地缓存，则也会增加消耗i/o读写资源，而导致性能变差。为了提升响应速度，则需要提高硬件资源，则又会带来较高的成本。


技术实现要素：

4.基于此，有必要针对上述技术问题，提供一种能够提高响应速度的dicom文件处理方法、装置、计算机设备和存储介质。
5.一种dicom文件处理方法，该方法包括：
6.接收对端发送的请求，确定请求的服务类型；
7.获取第一处理流；
8.解析第一处理流中的头部数据；
9.将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
10.在其中一个实施例中，服务类型为存储服务；相应地，第一处理流为对端发送的网络流，第二处理流为本地的文件流。
11.在其中一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，对第二处理流进行处理之前，还包括：
12.确定未解析的医学影像数据的实际长度；
13.若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
14.在其中一个实施例中，服务类型为转发服务；相应地，第一处理流为对端发送的网络流，第二处理流为对外转发的网络流。
15.在其中一个实施例中，对第二处理流进行处理之前，还包括：
16.若本地已存储与未解析的医学影像数据相同的数据内容，则将本地已存储的医学
影像数据写入至第二处理流，若本地未存储与未解析的医学影像数据相同的数据内容，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
17.在其中一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，从第一处理流中获取未解析的医学影像数据，包括：
18.确定未解析的医学影像数据的实际长度；
19.若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据。
20.在其中一个实施例中，对第二处理流进行处理，包括：
21.根据列存储数据库指令，对外发送第二处理流。
22.一种dicom文件处理装置，该装置包括：
23.接收模块，用于接收对端发送的请求，确定请求的服务类型；
24.第一获取模块，用于获取第一处理流；
25.解析模块，用于解析第一处理流中的头部数据；
26.第一写入模块，用于将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据；
27.处理模块，用于对第二处理流进行处理。
28.一种计算机设备，包括存储器和处理器，存储器存储有计算机程序，处理器执行计算机程序时实现以下步骤：
29.接收对端发送的请求，确定请求的服务类型；
30.获取第一处理流；
31.解析第一处理流中的头部数据；
32.将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
33.一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
34.接收对端发送的请求，确定请求的服务类型；
35.获取第一处理流；
36.解析第一处理流中的头部数据；
37.将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
38.上述dicom文件处理方法、装置、计算机设备和存储介质，通过接收对端发送的请求，确定请求的服务类型。获取第一处理流，解析第一处理流中的头部数据。将已解析的头部数据写入至第二处理流，并对第二处理流进行处理。由于只需将第一处理流中非医学影像数据的部分数据，也即头部数据解析至内存，而医学影像数据则不需要解析至内存，而是可以直接写入待处理的第二处理流中，从而在对dicom文件的处理过程中，可以避免将全部数据解析至内存，进而可以维持内存稳定地使用，提高内存的使用性能。另外，通过该方法可以使得在对dicom文件进行处理时，不受dicom文件大小的限制，也不需要为大体积的dicom文件额外提高硬件配置，从而拓展了应用范围以及节省了硬件开支。
附图说明
39.图1为一个实施例中dicom文件处理方法的流程示意图；
40.图2为另一个实施例中dicom文件处理方法的流程示意图；
41.图3为又一个实施例中dicom文件处理方法的流程示意图；
42.图4为再一个实施例中dicom文件处理方法的流程示意图；
43.图5为一个实施例中dicom文件处理装置的结构框图；
44.图6为一个实施例中计算机设备的内部结构图。
具体实施方式
45.为了使本技术的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本技术进行进一步详细说明。应当理解，此处描述的具体实施例仅仅用以解释本技术，并不用于限定本技术。
46.可以理解，本技术所使用的术语“第一”、“第二”等可在本文中用于描述各种专业名词，但除非特别说明，这些专业名词不受这些术语限制。这些术语仅用于将一个专业名词与另一个专业名词区分。举例来说，在不脱离本技术的范围的情况下，第三预设阈值与第四预设阈值可以相同可以不同。
47.dicom协议是医学图像和相关信息的国际标准，它定义了质量能满足临床需要的可用于数据交换的医学图像格式。在相关技术中，不管是c 、c#、java的底层实现，都没有保证完全支持大文件的接收和发送。其中，针对归档的dicom文件，一般c
‑
store scp(service class provider，服务提供方)，也即支持dicom协议的接收文件的服务端会将接受的网络流全部解析到内存中，再将内存中的数据写入磁盘或者是外发的网络流中，由此服务端的内存使用率会随着dicom文件大小激增，导致最终服务端崩溃。针对发送的dicom文件，一般c
‑
store scu(service class user，请求服务方)，也即支持dicom协议的发送文件的客户端会将dicom文件全部读入内存，再写入到网络流，由此客户端的内存使用率也会随着dicom文件大小激增，导致客户端无法正常发送dicom文件。
48.无论上述哪种情形，随着dicom文件越来越大，要保证系统正常运行，均需要不断地提高硬件资源，从而会提高硬件成本。另外，将数据全部解析到内存中，解析了很多用不到的数据，从而会导致数据存储及后续数据处理时整体性能低下。因此，现急需一种解决上述技术问题的文件传输方法。
49.针对上述相关技术中存在的问题，本发明实施例提供了一种dicom文件处理方法，该方法可以应用于服务器中。要说明的是，本技术各实施例中提及的“多个”等的数量均指代“至少两个”的数量，比如，“多个”指“至少两个”。
50.结合上述说明，在一个实施例中，参见图1，提供了一种dicom文件处理方法。以该方法应用于服务器，且执行主体为服务器为例进行说明，该方法包括如下步骤：
51.101、接收对端发送的请求，确定请求的服务类型；
52.102、获取第一处理流；
53.103、解析第一处理流中的头部数据；
54.104、将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
55.在上述步骤101中，对端可以指的是客户端，请求可以由客户端以处理流的形式发送至服务器端。其中，该处理流中可以包括数据集与基于dicom协议格式规范所生成的命令集，数据集即为第一处理流。服务器端根据命令集，可以获知对端请求的服务类型，以提供相应的处理，如后续的解析处理。服务类型可以根据实际需求分为多种，可以为查询服务、存储服务、获取服务、发送服务或删除服务等，本发明实施例对此不作具体限定。
56.在步骤101之前，客户端与服务器端可以先建立网络连接。本发明实施例不与对端建立网络连接的方式作具体限定，包括但不限于：接收对端发送的网络连接建立请求；根据网络连接建立请求，确定对端请求的服务类型；判断本地是否支持服务类型，若支持，则向对端返回确定消息，并与对端建立网络连接。需要说明的是，若服务器端本地不支持对端请求的服务类型，则会向对端返回拒绝消息，从而不会与对端建立网络通信连接。其中，服务器端可以通过预先配置不同的运行环境，以支持不同的服务类型。
57.在上述步骤102中，第一处理流可以由对端发送的，也即可以是由客户端发送的，第一处理流中包含医学影像数据。在上述步骤103中，可以基于dicom协议格式规范，解析第一处理流中的头部数据。其中，头部数据与未解析的医学影像数据在第一处理流中是基于结尾标识所区分的，从而可以基于结尾标识解析第一处理流中的头部数据。具体地，可以将(7fe0,0010)作为结尾标识，将结尾标识以前的数据作为头部数据，而将结尾标识以后的数据作为医学影像数据。实际实施过程中，可以从第一处理流起始位置开始解析，直至解析至结尾标识处，解析出的头部数据可以存储至内存中。另外，头部数据通常为12个字节，主要是包括文件元信息，也即文件元tag。文件元tag里定义了传输语法，同时可以记录dicom文件中医学影像数据的长度。
58.在上述步骤104中，第二处理流的类型、对第二处理流的处理方式与请求的服务类型相对应。将上述步骤103中解析得到的头部数据由内存写入第二处理流。与此同时，为使得第二处理流中包含第一处理流中未解析的医学影像数据，还可以将未解析的医学影像数据写入至第二处理流。至于第二处理流中未解析的医学影像数据的数据来源，可以来源于第一处理流，也可以来源于本地，本发明实施例对此不作具体限定。
59.本发明实施例提供的方法，通过接收对端发送的请求，确定请求的服务类型。获取第一处理流，解析第一处理流中的头部数据。将已解析的头部数据写入至第二处理流，并对第二处理流进行处理。由于只需将第一处理流中非医学影像数据的部分数据，也即头部数据解析至内存，而医学影像数据则不需要解析至内存，而是可以直接写入待处理的第二处理流中，从而在对dicom文件的处理过程中，可以避免将全部数据解析至内存，进而可以维持内存稳定地使用，提高内存的使用性能。另外，通过该方法可以使得在对dicom文件进行处理时，不受dicom文件大小的限制，也不需要为大体积的dicom文件额外提高硬件配置，从而拓展了应用范围以及节省了硬件开支。
60.结合上述实施例的内容，在一个实施例中，服务类型为存储服务；相应地，第一处理流为对端发送的网络流，第二处理流为本地的文件流。
61.存储服务对应的应用场景主要是客户端向服务器端发送dicom文件，而由服务器端接收并保存dicom文件。具体地，可以由支持dicom协议的客户端通过c
‑
store发送向服务器端发送dicom文件。此时，第一处理流指的是由客户端向服务器发送的网络流。网络流可以具体指的是socket网络流，本发明实施例不对网络流对应使用的传输协议作具体限定。
第二处理流为本地的文件流，通过本地的文件流可以实现dicom文件的本地落盘。
62.为了便于理解，结合上述实施例的内容，结合图2，现对存储服务的实现过程进行解释说明：
63.(1)客户端向服务器端发送网络连接建立请求a
‑
ssociate
‑
rq，由于通过该请求所请求的服务类型可能会有很多种，只有服务器端能够支持的服务类型，服务器端才会选择性地返回确定消息a
‑
ssociate
‑
ac。此时，服务器端与客户端之间会建立网络连接。若客户端所请求的服务类型服务器端并不支持，则服务器端会返回拒绝消息a
‑
ssociate
‑
rj。
64.(2)客户端接收到服务器端返回的a
‑
ssociate
‑
ac，即表明客户端与服务器端已建立网络连接。此时，客户端可以向服务器端发送处理流p
‑
data
‑
tf(rq)，p
‑
data
‑
tf(rq)中携带有命令集及数据集。p
‑
data
‑
tf(rq)可以具体为socket网络流，服务器端可以通过socket端口监听，以接收socket网络流。需要说明的是，socket网络流可以是一段段的数据组合而成，也即一个个segment，每一个segment可以有最大长度限制。socket网络流中可以先是先命令集部分，后是数据集部分。其中，第一段segment可以是命令集与部分数据集，后续接收的segment可以均为数据集。
65.还需要说明的是，客户端在向服务器端发送处理流p
‑
data
‑
tf(rq)，可以根据列存储数据库指令发送，列存储数据库可以具体为c
‑
store，本发明实施例对此不作具体限定。其中，c
‑
store是一个为了快速查询而设计的关系型数据库，为了达到更快的查询性能，c
‑
store按列存储数据，同一个表中的不同列可能被存储在不同的且可能有重叠的projection中。其中，projection指的是数据存储列的集合。
66.(3)服务器端在接收到p
‑
data
‑
tf(rq)后，服务器端可以先对其中的命令集进行解析，确定客户端所请求的服务类型，从而使用特定服务对p
‑
data
‑
tf中后续接入的数据集，也即第一处理流进行处理。在相关技术中，处理方式即为将接收到的所有数据集全部写入内存，导致对内存资源消耗过大。或者，将数据直接写入到本地缓存中，后续使用再从缓存中取出来，导致i/o(input/ouput，输入输出)操作急剧增加，降低系统处理性能。
67.而在本技术中为了避免上述两种情形，主要是基于dicom标准对dicom文件格式的规定，分析dicom文件的数据集中各个数据元素其组成部分的特性，从而针对描述影像部分信息的医学影像数据去内存化和去缓存处理，也即绕过内存及缓存，而是直接与真实的目的地建立管道连接，从而实现快速高效地处理医学图像影像数据。
68.(4)服务器端获取p
‑
data
‑
tf(rq)中的数据集，也即socket网络流中的数据部分(第一处理流)，解析第一处理流中的头部数据。需要说明的是，在本发明实施例中服务器端实际上提供的是存储服务。实际实施过程中，服务器端可以对获取到的网络数据进行监控，也即可以对socket网络流，以动态获取所需要的数据。例如，在获取命令集及第一处理流，均可以采用上述动态获取的方式。由于获取网络数据实际上也是i/o操作，从而可以利用阻塞i/o机制及非阻塞i/o机制获取网络数据，也可以利用同步i/o机制和异步i/o机制获取网络数据。
69.上述阻塞i/o和非阻塞i/o这两个概念是程序级别的，主要用于描述程序请求操作系统i/o操作后，如果i/o资源没有准备好，则程序该如何处理的问题。具体地，如果i/o资源没有准备好，阻塞i/o机制会等待，而非阻塞i/o机制会继续执行，也即会使用线程一直轮询，直至存在i/o资源准备好。
70.上述同步i/o和异步i/o这两个概念是操作系统级别的，主要描述的是操作系统在收到程序请求i/o操作后，如果i/o资源没有准备好，该如何响应程序的问题。具体地，如果i/o资源没有准备好，同步i/o直至i/o资源准备好之前会不响应。而异步i/o会返回一个标记，用于标记后续i/o资源准备好的事件触发后，该事件的返回目标。通过上述不同的i/o机制，服务器端可以一段段地解析第一处理流。具体地，只对第一处理流中的头部数据进行解析，头部数据通常为12个字节，且不会超过16kb。由此，可以通过上述实施例提及的结尾标识从第一处理流中截出头部数据，并对解析出的头部数据进行记录保存。
71.(5)服务器端将已解析的头部数据写入至第二处理流，也即写入至服务器端本地的文件流中。同时，还可将第一处理流中未解析的医学影像数据也写入至第二处理流中。最后，通过第二处理流可以使得dicom文件在本地落盘。至此，服务器端提供的存储服务结束。需要说明的是，在此之后，服务器端可以选择性地向客户端返回p
‑
data
‑
tf(rsp)，以表示存储服务结束以作为回复响应。客户端在接收到p
‑
data
‑
tf(rsp)，可以向服务器端发送释放网络连接请求a
‑
release
‑
rq。服务器端在接收到a
‑
release
‑
rq后，可以向终端返回a
‑
release
‑
rp，以表示确定释放与客户端之间的网络连接。
72.上述内容为服务类型为存储服务时的具体过程，其简要过程还可参考如下图3，具体包括：
73.(1)接收c
‑
store scp接收socket网络流；
74.(2)解析socket网络流中的命令集；
75.(3)以结尾标识为分界点解析socket网络流中的数据集；
76.(4)记录头部数据12个字节信息；
77.(5)将解析的头部数据及socket网络流中未解析的医学影像数据写入之至第二处理流。
78.本发明实施例提供的方法，由于不用将接收到的所有数据集全部写入内存，从而可以避免对内存资源消耗过大。与此同时，由于不用将接收到的所有数据集全部写入本地缓存，后续再从本地缓存取出，从而可以避免i/o操作急剧增加而降低系统处理性能。
79.结合上述实施例的内容，在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，对第二处理流进行处理之前，还包括：确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
80.由上述实施例的内容可知，第一处理流中头部数据与医学影像数据主要是以结尾标识进行区分。在本发明实施例中，可以从结尾标识处开始统计，直至第一处理流中医学影像数据的结束位，从而可以确定未解析的医学影像数据的实际长度。其中，医学影像数据在第一处理流中的结束位，可以为预设的结束标识，如预设的字符或者预设固定的字节位，本发明实施例对此不作具体限定。
81.在服务类型为存储服务的情况下，未解析的医学影像数据的数据来源为第一处理流，从而需要从第一处理流中获取未解析的医学影像数据。因此，在上述过程中，可以先将记录长度与实际长度比对，若两者不一致，则无法从第一处理流中获取未解析的医学影像数据。此时，可以向客户端返回重发消息，以使得客户端重新发送第一处理流。若两者一致，则可从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二
处理流，而不用经过内存或本地缓存。
82.本发明实施例提供的方法，通过确定未解析的医学影像数据的实际长度，若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。由于医学影像数据的实际长度与记录长度是否一致的判断结果，可以用于指示医学影像数据是否出错，从而通过上述判断过程，可以避免向第二处理流中写入错误的医学影像数据，进而保证后续本地落盘时的数据准确性。
83.结合上述实施例的内容，在一个实施例中，服务类型为转发服务；相应地，第一处理流为对端发送的网络流，第二处理流为对外转发的网络流。
84.转发服务对应的应用场景主要是客户端向服务器端发送dicom文件，服务器端接收到后再转发至其它客户端或者其它服务器端。具体地，可以由支持dicom协议的客户端通过c
‑
store发送向服务器端发送dicom文件。此时，第一处理流指的是由客户端向服务器发送的网络流。网络流也可以具体指的是socket网络流，本发明实施例不对网络流对应使用的传输协议作具体限定。第二处理流为服务器端对外转发的网络流，通过对外转发的网络流，可以将dicom文件转发至其它客户端或者服务器端。
85.本发明实施例提供的方法，由于不用将接收到的所有数据集全部写入内存，从而可以避免对内存资源消耗过大。与此同时，由于不用将接收到的所有数据集全部写入本地缓存，后续再从本地缓存取出，从而可以避免i/o操作急剧增加而降低系统处理性能。
86.结合上述实施例的内容，在一个实施例中，对第二处理流进行处理之前，还包括：若本地已存储与未解析的医学影像数据相同的数据内容，则将本地已存储的医学影像数据写入至第二处理流，若本地未存储与未解析的医学影像数据相同的数据内容，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
87.由上述实施例可知，本发明实施例中的服务类型为转发服务，也即由客户端将dicom文件发送至某一服务器端，该服务器端再将dicom文件转发至其它客户端或者服务器端。其中，客户端将dicom文件发送至某一服务器端后，该服务器端可以预先没有存储该dicom文件，也可能已存储该dicom文件。因此，针对不同的情形，在本发明实施例中存在不同的处理过程。在判断本地是否存储与未解析的医学影像数据相同的数据内容时，可以根据已解析的头部数据进行判断。具体地，已解析的头部数据存储有用于与医学影像数据唯一对应的标识数据，比如tag数据，包括图像宽、高、数据传输格式、病人姓名、病人生日、病历医院、病历科室、病情的描述等等数据。对于某一医学影像数据，若需要判断本地是否已存储该医学影像数据，则查找本地是否已存储该医学影像数据tag数据。若已存储，则表明本地已存储该医学影像数据。若未存储，则表明本地未存储该医学影像数据。
88.为了便于理解，结合上述实施例的内容，结合图2，现对转发服务的实现过程进行解释说明：
89.(1)客户端向服务器端发送网络连接建立请求a
‑
ssociate
‑
rq，由于通过该请求所请求的服务类型可能会有很多种，只有服务器端能够支持的服务类型，服务器端才会选择性地返回确定消息a
‑
ssociate
‑
ac。此时，服务器端与客户端之间会建立网络连接。若客户端所请求的服务类型服务器端并不支持，则服务器端会返回拒绝消息a
‑
ssociate
‑
rj。
90.(2)客户端接收到服务器端返回的a
‑
ssociate
‑
ac，即表明客户端与服务器端已建立网络连接。此时，客户端可以向服务器端发送处理流p
‑
data
‑
tf(rq)，p
‑
data
‑
tf(rq)中携
带有命令集及数据集。p
‑
data
‑
tf(rq)可以具体为socket网络流，服务器端可以通过socket端口监听，以接收socket网络流。需要说明的是，socket网络流可以是一段段的数据组合而成，也即一个个segment，每一个segment可以有最大长度限制。socket网络流中可以先是先命令集部分，后是数据集部分。其中，第一段segment可以实命令集与部分数据集，后续接收的segment可以均为数据集。
91.还需要说明的是，客户端在向服务器端发送处理流p
‑
data
‑
tf(rq)，可以根据c
‑
store指令发送，本发明实施例对此不作具体限定。其中，c
‑
store是一个为了快速查询而设计的关系型数据库，为了达到更快的查询性能，c
‑
store按列存储数据，同一个表中的不同列可能被存储在不同的且可能有重叠的projection中。
92.(3)服务器端在接收到p
‑
data
‑
tf(rq)后，服务器端可以先对其中的命令集进行解析，确定客户端所请求的服务类型，从而使用特定服务对p
‑
data
‑
tf中后续接入的数据集，也即第一处理流进行处理。在相关技术中，处理方式即为将接收到的所有数据集全部写入内存，导致对内存资源消耗过大。或者，将数据直接写入到本地缓存中，后续使用再从缓存中取出来，导致i/o操作急剧增加，降低系统处理性能。
93.而在本技术中为了避免上述两种情形，主要是基于dicom标准对dicom文件格式的规定，分析dicom文件的数据集中各个数据元素其组成部分的特性，从而针对描述影像部分信息的医学影像数据去内存化和去缓存处理，也即绕过内存及缓存，而是直接与真实的目的地建立管道连接，从而实现快速高效地处理医学图像影像数据。
94.(4)p
‑
data
‑
tf(rq)中的数据集，也即socket网络流中的数据部分为第一处理流。由于第一处理流中未解析的医学影像数据服务器端可能已存储，也可能未存储。由此，服务器端可以根据已解析的头部数据，确定本地是否存储内容与未解析的医学影像数据相同的医学影像数据。
95.医学影像数据可以通过校验码进行校验，而每一医学影像数据可以对应唯一的校验码。基于此，本发明实施例不对根据已解析的头部数据，确定本地是否存储内容与未解析的医学影像数据相同的医学影像数据的方式作具体限定，包括但不限于：获取未解析的医学影像数据对应的校验码；将该校验码与本地已存储的医学影像数据对应的校验码进行比对；若存在相同的校验码，则确定本地已存储与未解析的医学影像数据相同的医学影像数据，若不存在相同的校验码，则确定本地未存储与未解析的医学影像数据相同的医学影像数据。
96.(5)若上述服务器端确定本地已存储与未解析的医学影像数据相同的医学影像数据，则将已解析的头部数据写入至第二处理流，也即写入对外转发的网络流中，同时将本地已存储与未解析的医学影像数据相同的医学影像数据写入至第二处理流。若上述服务器端确定本地未存储与未解析的医学影像数据相同的医学影像数据，则将已解析的头部数据写入至第二处理流，也即写入对外转发的网络流中，同时将第一处理流中未解析的医学影像数据写入至第二处理流。在此之后，可以通过第二处理流实现dicom文件的对外转发。
97.至此，服务器端提供的存储服务结束。需要说明的是，在此之后，服务器端可以选择性地向客户端返回p
‑
data
‑
tf(rsp)，以表示存储服务结束以作为回复响应。客户端在接收到p
‑
data
‑
tf(rsp)，可以向服务器端发送释放网络连接请求a
‑
release
‑
rq。服务器端在接收到a
‑
release
‑
rq后，可以向终端返回a
‑
release
‑
rp，以表示确定释放与客户端之间的
网络连接。
98.还需要说明的是，上述过程只是表示客户端与服务器端之间的数据传输结束。而服务器端是需要将dicom文件转发至其它客户端或者其它服务器端的，由此，服务器端还需要与目的地端建立网络连接，具体过程可参考客户端与服务器端之间的数据传输过程，此处不再赘述。
99.上述内容为服务类型为转发服务时的具体过程，以服务器端本地已存储与未解析的医学影像数据相同的医学影像数据为例，其简要过程还可参考如下图4，具体包括：
100.(1)建立dicom文件流；需要说明的是，由于服务器端本地已存储与未解析的医学影像数据相同的医学影像数据，从而为了将其写入至第二处理流，需要先建立该医学影像数据的dicom文件流；
101.(2)解析dicom文件流的文件元信息；需要说明的是，由于不再是网络流，从而文件元不再存在于头部数据中。
102.(3)将解析的文件元信息及dicom文件流中未解析的医学影像数据写入至第二处理流；需要说明的是，第二处理流可以为对外发送的socket网络流。
103.(4)将第二处理流外发。
104.本发明实施例提供的方法，由于不用将接收到的所有数据集全部写入内存，从而可以避免对内存资源消耗过大。与此同时，由于不用将接收到的所有数据集全部写入本地缓存，后续再从本地缓存取出，从而可以避免i/o操作急剧增加而降低系统处理性能。另外，由于可以根据作为转发中转的服务器端是否存储有待转发的医学影像数据，选择将医学影像数据写入至第二处理流时的数据来源，从而可以提高转发数据时的容错率。
105.结合上述实施例的内容，在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，从第一处理流中获取未解析的医学影像数据，包括：确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据。
106.由上述实施例的内容可知，第一处理流中头部数据与医学影像数据主要是以结尾标识进行区分。在本发明实施例中，可以从结尾标识处开始统计，直至第一处理流中医学影像数据的结束位，从而可以确定未解析的医学影像数据的实际长度。其中，医学影像数据在第一处理流中的结束位，可以为预设的结束标识，如预设的字符或者预设固定的字节位，本发明实施例对此不作具体限定。
107.在服务类型为转发服务的情况下，未解析的医学影像数据的数据来源为第一处理流或者本地的文件流。在数据来源未第一处理流时，需要从第一处理流中获取未解析的医学影像数据。因此，在上述过程中，可以先将记录长度与实际长度比对，若两者不一致，则无法从第一处理流中获取未解析的医学影像数据。此时，可以向客户端返回重发消息，以使得客户端重新发送第一处理流。若两者一致，则可从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流，而不用经过内存或本地缓存。
108.本发明实施例提供的方法，通过确定未解析的医学影像数据的实际长度，若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。由于医学影像数据的实际长度与记录长度是否一致的判断结果，可以用于指示医学影像数据是否出错，从而通过上述判断过程，可以避免向第二处理流
中写入错误的医学影像数据，进而保证后续对第二处理流进行处理时的数据准确性。
109.结合上述实施例的内容，在一个实施例中，关于对第二处理流进行处理的方式，本发明实施例对此不作具体限定，包括但不限于：根据列存储数据库指令，对外发送第二处理流。
110.其中，列存储数据库可以为c
‑
store。另外，上述存储服务与转发服务均可以在不同客户端与服务器端之间并发执行，从而在本发明实施例中，可以持续提高c
‑
store指令的并发量，进而可以在dicom协议下快速传输dicom文件。与此同时，结合上述实施例中的过程，由客户端及服务器端组成的整个服务系统可以达到更高的吞吐量。
111.本发明实施例提供的方法，由于采用的是c
‑
store数据库存储dicom文件，而c
‑
store数据库列的长度都是固定的，从而在数据库实现上不用考虑内存对齐，以避免数据跨越边界，造成处理一次数据需要两次访问内存的情况，从而可将数据元素编码成最有效的形式，而不用受dicom文件大小的限制。
112.应该理解的是，虽然图1至图4的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图1至图4中的至少一部分步骤可以包括多个步骤或者多个阶段，这些步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤中的步骤或者阶段的至少一部分轮流或者交替地执行。
113.需要说明的是，上述阐述的技术方案在实际实施过程中可以作为独立实施例来实施，也可以彼此之间进行组合并作为组合实施例实施。另外，在对上述本发明实施例内容进行阐述时，仅基于方便阐述的思路，按照相应顺序对不同实施例进行阐述，如按照数据流流向的顺序，而并非是对不同实施例之间的执行顺序进行限定。相应地，在实际实施过程中，若需要实施本发明提供的多个实施例，则不一定需要按照本发明阐述实施例时所提供的执行顺序，而是可以根据需求安排不同实施例之间的执行顺序。
114.结合上述实施例的内容，在一个实施例中，如图5所示，提供了一种dicom文件处理装置，包括：接收模块501、获取模块502、解析模块503、第一写入模块504及处理模块505，其中：
115.接收模块501，用于接收对端发送的请求，确定请求的服务类型；
116.第一获取模块502，用于获取第一处理流；
117.解析模块503，用于解析第一处理流中的头部数据；
118.第一写入模块504，用于将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据；
119.处理模块505，用于对第二处理流进行处理。
120.在一个实施例中，服务类型为存储服务；相应地，第一处理流为对端发送的网络流，第二处理流为本地的文件流。
121.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，该装置还包括：
122.第一确定模块，用于确定未解析的医学影像数据的实际长度；
123.第二写入模块，用于当记录长度与实际长度一致时，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
124.在一个实施例中，服务类型为转发服务；相应地，第一处理流为对端发送的网络流，第二处理流为对外转发的网络流。
125.在一个实施例中，该装置还包括：
126.第三写入模块，用于当本地已存储与未解析的医学影像数据相同的数据内容时，则将本地已存储的医学影像数据写入至第二处理流，若本地未存储与未解析的医学影像数据相同的数据内容，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
127.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，第二获取模块，用于确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据。
128.在一个实施例中，处理模块505，用于根据列存储数据库指令，对外发送第二处理流。
129.本发明实施例提供的装置，通过接收对端发送的请求，确定请求的服务类型。获取第一处理流，解析第一处理流中的头部数据。将已解析的头部数据写入至第二处理流，并对第二处理流进行处理。由于只需将第一处理流中非医学影像数据的部分数据，也即头部数据解析至内存，而医学影像数据则不需要解析至内存，而是可以直接写入待处理的第二处理流中，从而在对dicom文件的处理过程中，可以避免将全部数据解析至内存，进而可以维持内存稳定地使用，提高内存的使用性能。另外，通过该方法可以使得在对dicom文件进行处理时，不受dicom文件大小的限制，也不需要为大体积的dicom文件额外提高硬件配置，从而拓展了应用范围以及节省了硬件开支。
130.关于dicom文件处理装置的具体限定可以参见上文中对于dicom文件处理方法的限定，在此不再赘述。上述dicom文件处理装置中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。
131.在一个实施例中，提供了一种计算机设备，该计算机设备可以是服务器，其内部结构图可以如图6所示。该计算机设备包括通过系统总线连接的处理器、存储器和网络接口。其中，该计算机设备的处理器用于提供计算和控制能力。该计算机设备的存储器包括非易失性存储介质、内存储器。该非易失性存储介质存储有操作系统、计算机程序和数据库。该内存储器为非易失性存储介质中的操作系统和计算机程序的运行提供环境。该计算机设备的数据库用于存储预设阈值。该计算机设备的网络接口用于与外部的终端通过网络连接通信。该计算机程序被处理器执行时以实现一种dicom文件处理方法。
132.本领域技术人员可以理解，图6中示出的结构，仅仅是与本技术方案相关的部分结构的框图，并不构成对本技术方案所应用于其上的计算机设备的限定，具体的计算机设备可以包括比图中所示更多或更少的部件，或者组合某些部件，或者具有不同的部件布置。
133.在一个实施例中，提供了一种计算机设备，包括存储器和处理器，存储器中存储有计算机程序，该处理器执行计算机程序时实现以下步骤：
134.接收对端发送的请求，确定请求的服务类型；
135.获取第一处理流；
136.解析第一处理流中的头部数据；
137.将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
138.在一个实施例中，处理器在执行计算机程序时，服务类型为存储服务；相应地，第一处理流为对端发送的网络流，第二处理流为本地的文件流。
139.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，处理器执行计算机程序时还实现以下步骤：确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
140.在一个实施例中，处理器在执行计算机程序时，服务类型为转发服务；相应地，第一处理流为对端发送的网络流，第二处理流为对外转发的网络流。
141.在一个实施例中，处理器执行计算机程序时还实现以下步骤：若本地已存储与未解析的医学影像数据相同的数据内容，则将本地已存储的医学影像数据写入至第二处理流，若本地未存储与未解析的医学影像数据相同的数据内容，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
142.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，处理器执行计算机程序时还实现以下步骤：确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据。
143.在一个实施例中，处理器执行计算机程序时还实现以下步骤：根据列存储数据库指令，对外发送第二处理流。
144.在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：
145.接收对端发送的请求，确定请求的服务类型；
146.获取第一处理流；
147.解析第一处理流中的头部数据；
148.将已解析的头部数据写入至第二处理流，第二处理流中包含第一处理流中未解析的医学影像数据，并对第二处理流进行处理。
149.在一个实施例中，计算机程序被处理器执行时，服务类型为存储服务；相应地，第一处理流为对端发送的网络流，第二处理流为本地的文件流。
150.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，计算机程序被处理器执行时还实现以下步骤：确定未解析的医学影像数据的实际长度；若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
151.在一个实施例中，计算机程序被处理器执行时，服务类型为转发服务；相应地，第一处理流为对端发送的网络流，第二处理流为对外转发的网络流。
152.在一个实施例中，计算机程序被处理器执行时还实现以下步骤：
153.若本地已存储与未解析的医学影像数据相同的数据内容，则将本地已存储的医学
影像数据写入至第二处理流，若本地未存储与未解析的医学影像数据相同的数据内容，则从第一处理流中获取未解析的医学影像数据，并将未解析的医学影像数据写入至第二处理流。
154.在一个实施例中，头部数据包括未解析的医学影像数据的记录长度；相应地，计算机程序被处理器执行时还实现以下步骤：
155.确定未解析的医学影像数据的实际长度；
156.若记录长度与实际长度一致，则从第一处理流中获取未解析的医学影像数据。
157.在一个实施例中，计算机程序被处理器执行时还实现以下步骤：根据列存储数据库指令，对外发送第二处理流。
158.本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本技术所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和易失性存储器中的至少一种。非易失性存储器可包括只读存储器(read
‑
only memory，rom)、磁带、软盘、闪存或光存储器等。易失性存储器可包括随机存取存储器(random access memory，ram)或外部高速缓冲存储器。作为说明而非局限，ram可以是多种形式，比如静态随机存取存储器(static random access memory，sram)或动态随机存取存储器(dynamic random access memory，dram)等。
159.以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。
160.以上所述实施例仅表达了本技术的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本技术构思的前提下，还可以做出若干变形和改进，这些都属于本技术的保护范围。因此，本技术专利的保护范围应以所附权利要求为准。