DICOM中检查时间

CT 的第一张到倒数第二张的时间
0040,0002(ScheduledProcedureStepStartDate)DA:2008-10-27;
0040,0003(ScheduledProcedureStepStartTime)TM:10:41:49;
0040,0004(ScheduledProcedureStepEndDate)DA:2008-10-27;
0040,0005(ScheduledProcedureStepEndTime)TM:11:11:49;
0040,0244(PerformedProcedureStepStartDate)DA:2008-10-27;
0040,0245(PerformedProcedureStepStartTime)TM:10:44:23;

CT 的最后一张
0040,0002(ScheduledProcedureStepStartDate)DA:2008-10-27;
0040,0003(ScheduledProcedureStepStartTime)TM:10:41:49;
0040,0004(ScheduledProcedureStepEndDate)DA:2008-10-27;
0040,0005(ScheduledProcedureStepEndTime)TM:11:11:49;
0040,0244(PerformedProcedureStepStartDate)DA:2008-10-27;
0040,0245(PerformedProcedureStepStartTime)TM:10:44:23;
0040,0250(PerformedProcedureStepEndDate)DA:2008-10-27;
0040,0251(PerformedProcedureStepEndTime)TM:11:03:04;

RisStudyNotify

StudyDateTime: 0008,0020(StudyDate)DA:2008-10-27; + 0008,0030(StudyTime)TM:10:44:23;
ArrivedTime: 图像到达PACS服务器的时间

0008,0020(StudyDate)DA:2008-10-27;
0008,0021(SeriesDate)DA:2008-10-27;
0008,0022(AcquisitionDate)DA:2008-10-27;
0008,0023(Image/ContentDate)DA:2008-10-27;
0008,0030(StudyTime)TM:10:44:23;
0008,0031(SeriesTime)TM:10:44:58;

时间： 2025-01-13 04:18:18

DICOM中检查时间的相关文章

DICOM医学图像处理：AETitle在C-FIND和C-MOVE请求中的设置问题

背景: 最近去医院部署设备,调试PACS系统,遇到了一个奇葩的问题.基本场景是:医院内部网络情况复杂,多个楼层的诊室都安装了看图端,都需要访问顶楼机房的PACS服务器.起初为了调试关闭了防火墙,并确保各楼层的看图端与PACS服务器之间可以ping通,端口也顺利开放.但是具体部署调试过程中发现"有些楼层可正常进行worklist查询和Query/Retrieve查询,而有些楼层只能正常进行worklist查询,Query/Retrieve查询后本地并未获得图像数据":第二天尝试后发现&q

[医疗][Dicom]

对于医疗信息软件来说,Dicom 标准是一个不得不学习的标准.DICOM标准在 PS3.5中定义了27 个基本数据类型,就是所谓的值表现(VR, Value Representations).值表现是用来封装所有可能的临床数据类型的.在 DICOM 中写任何东西都必须符合这 27 个基本数据类型中的一个.每个 VR 都是两个英文字母的缩写.下表列出了这 27 个基本数据类型的定义. DICOM VR (Value Representations)表 VR 含义 允许的字符 数据长度 CS - C

DICOM：基于JMeter+dcm4che2测试PACS服务器性能的解决方案（续篇）

背景: 前一篇博文通过扩展JMeter的java请求,结合dcm4che2现有的工具包dcmsnd.bat实现了简单的测试DICOM服务器C-STORE SCP性能的尝试.由于借用了现有的dcmsnd.bat命令行工具,会有诸多的局限性,比如: 1)必须构造命令行中的参数,才能调用dcmsnd.bat,操作多此一举 2)无法准确跟踪一张图像上传完成后的准确时间 3)既然要模拟海量用户并发,需要准备对应的数量的文件,无法通过自动生成dcm的三级UID来自动生成海量测试文件. 针对上述情况,本篇博文

DICOM医学图像处理：DICOM存储操作之 “多幅JPG图像数据存入DCM文件”

背景: 续上篇,继续介绍如何将多幅JPG图像数据存入DCM文件.即将有损压缩数据直接写入DCM文件,存储为Multi-frame形式. 多幅JPG图像数据存入DCM文件: 为了避免引起歧义,这里着重说明一下.本博文的描述的场景是:假设我们手中有多张JPG文件,想把JPG文件写入DCM文件,即单个DCM文件包含多幅图像信息的Multi-Frame形式.该问题之前与CSDN博友y317215133y也讨论过,当时我在OFFIS论坛中找到了一个帖子直接给了y317215133y答复.今天重新梳理了一下

DICOM医学图像处理：DCMTK的wiki资料学习之PACS调试

背景: 前段时间着重从dcmtk和fo-dicom(mDCM)源码角度进行剖析,期望加深对DICOM协议的理解.知其然,知其所以然.如果"所以然"很不好懂,那我们还是先多多"知其然"吧.搞清楚原理的目的不也是为了更好的运用于实践么?所以理论和实践应该彼此交错进行,理论搞不动了就搞搞应用,应用久了就钻研钻研理论. 以前上DCMTK官网仅仅是浏览关于开源库中各个类的设计模式.依赖关系.最近在打开DCMTK官网的wiki时,才发现OFFIS对DCMTK的介绍是如此的详细.

DICOM医学图像处理：fo-dicom网络传输之 C-Echo and C-Store

背景: 上一篇博文对DICOM中的网络传输进行了介绍.主要參照DCMTK Wiki中的英文原文.通过对照DCMTK与fo-dicom两个开源库对DICOM标准的详细实现,对理解DICOM标准有一个更直观的认识.此篇博文是对上一篇博文的补充.由于专栏前面的演示样例大多是利用DCMTK工具包来进行的,此次借着分析fo-dicom源代码结构的机会,參照fo-dicom的README.md,给出C-ECHO 和C-STORE服务的详细实现.在实现的同一时候给出DICOM3.0标准中的相关介绍,帮助我们理

DICOM：dcm4che工具包怎样压缩dcm文件探讨（续篇）

背景 前段时间博文DICOM:dcm4che工具包怎样压缩dcm文件探讨(前篇)提到了一个问题:"利用dcm4che工具包中的dcm2dcm来进行dcm文件的压缩和加压缩.即改变dcm文件里的Transfer Syntax,比如由1.2.840.10008.1.2(Implicit VR Little Endian)变成1.2.840.10008.1.2.4.70(JPEG LossLess,Non-Hierarchical,First_order Prediction Process 14).

DICOM医学图像处理：DICOM网络传输

背景: 专栏取名为DICOM医学图像处理原因是:博主是从医学图像处理算法研究时开始接触DICOM协议的.当初认识有局限性,认为DICOM只是一个简单的文件格式约定,简而言之,我当时认为DICOM协议就是扩展名为DCM文件的格式说明.其实不然,随着对医疗行业的深入,对DICOM协议也有了更全面的认识.而今才发现DCM文件只是DICOM协议一部分中的一小节,仅仅是整个协议中的一个数据结构,而DICOM协议更多的是关于医疗行业各种服务及相关流程的约定,因此其实DICOM协议中最主要的是信息流,是对医院

DICOM：DICOM3.0网络通信协议

转载:http://blog.csdn.net/zssureqh/article/details/41016091 背景: 专栏取名为DICOM医学图像处理原因是:博主是从医学图像处理算法研究时开始接触DICOM协议的.当初认识有局限性,认为DICOM只是一个简单的文件格式约定,简而言之,我当时认为DICOM协议就是扩展名为DCM文件的格式说明.其实不然,随着对医疗行业的深入,对DICOM协议也有了更全面的认识.而今才发现DCM文件只是DICOM协议一部分中的一小节,仅仅是整个协议中的一个数据结