闲话DICOM

最近在准备一场有关DICOM应用的讲座，整理了一下思路。想了几个问题，发现挺有
意思的，想与大家共同分享。
接触过DICOM，应该了解普通DICOM 文件包含的四级属性，病人，检查，序列，影像。每一
级别需要具有能够唯一标识这个等级属性的键值，类似关系数据库中的主键。
病人对应的为Patient id, 检查 study instance UID, 序列 Series Instanceuid,
影像 SOP Instance UID.

Patient
问题
为何病人级没有一个Patient instance UID?? 只定义一个patient id，而且可以为
空。ID 不是 GUID, 只是局部唯一。
这样在不同的医院，不同的信息系统中对应同一个Patient 可能会出现不同
的patient id, 给区域信息系统整合带来麻烦，需要进行映射等处理。
在中国城市，有常住人口，流动人口， 常住有社保卡，可实现唯一Patient ID.
流动人口，各医院的住院卡，无法保证数据(Patient ID) 的一致性。
国外虽然信息化技术先进，但对病人信息一致性也无法绝对保证。
信息是为了诊断，医生病人关注的是检查，对病人信息，通过姓名等信息可以关联确定。
Patient level, 有姓名，出生日期，还有年龄，性别等信息。
两个问题，
出生日期，年龄都是不是必须的属性，可选的，如果显示病人信息，同一病人，在不同年份的检查，如何显示年龄？ 显示dicom 文件中的年龄，还是根据出生日期计算？
在调用不同的检查时，如何显示年龄？检查时期的年龄还是调用时间的病人实际年龄？
这可能要看具体的设计，Patient-Study-Series-Image 还是没有Patient表，
Study-Series-Image.
病人性别， M\F\O (男\女\其他)，还可以为空) 为什么这样定义？
Patient 一定是指人吗？ 如果给宠物狗做个检查,Patient 可以为一只狗吗？DICOM有定义，patient 既可以为人，也可以为动物。 我觉得这时候性别有4种枚举值也就可以理解。
性别只有在某些性别作为重用参考信息时才有意义。

Study
谈完patient，说说study,
Accession number, Study Description, Study id, studydate 都是这一级别的重要属性。
accession number如果在有IS的情况下，作为检查登记号不能为空，用以标识一个检查；否则置空。
Study ID 与IS 无关，由用户或设备生成，这也是他存在的意义。

Series
Modality, Bodypartexaminated, Patient Position, View Position, Series number, Series time这些为什么重要? 对医生来说, 图像质量,和挂片顺序(协议)非常重要，这些都是挂片条件！

Image
Image Number, image time(content time)

同样，挂片条件！

DICOM 文件如何编码？

DICOM 定义一些数据类型---- VR (PN,CS,AE,LT,ST,LO,IS,DS,OB,OW,SQ ...),
编码方式---传输语义(Transfer Syntax)， ImplicitLittleEndian,ExplicitLittleEndian, ExplicitBigEndian,Encapsulated tranfer syntax
什么玩艺-- SOP class (CR? CT? .....)
当然还有一些细节－－character set , VM ...

数据类型
DICOM中的数据类型基本囊括我们常用的类型，字符串类型就有很多细分
PN-- patient name, 64字节长，可由最多3种姓名比如日文罗马名=汉字名=假名，每个姓名部分又最多可由5部分组成，够复杂了。不过这是因为各地区，文化有自己的称呼习惯。
CS- code string, 由大写的A-Z, 数字0-9, 下划线，空格组成，比如Modality type 就是CS类型，一般用于表示一些特定的枚举值。
DA- date, 日期，yyyymmdd 中间没有任何符号，但一些老标准中允许有符号比如yyyy-mm-dd,这在一些老设备中会出现，我们也要多留意。
类型太多，具体可参见DICOM3-5,数据字典。
因为DICOM要兼顾各个地区语言，所以定义了Character set (0x0008,0x0005)来处理不同地区的编码. 比如中国大陆的GB18030，台湾的utf-8，日本的ISO 2002 IR 87 等等。
定义某些数据类型比如SH,LO,PN 等可采用特定编码。同时允许采用多种混合编码方式，方便用户录入，理解。
为囊括各种影像设备，为每种设备定义特定的属性，同时抽取一些共同的属性，在DICOM3-3(IOD)种，1000多页洋洋洒洒。为照顾各大厂商私密，DICOM还有一个类型UN-unkown就是不知道，你爱放啥就放啥。一些已奇数为group值的tag 都有厂商把握。

传输语义
DICOM为利用各种已有的图像压缩技术和计算机平台，定义大量的传输语义，implictlittleendian,explicitlittleedian, explicitbigendian, JPEG Loseless, JPEG Lossy, RLE, JPEG2K, MPEG2, MPEG4.
最近几年为应用一些新的IT，支持一些影像以外的应用 还陆续添加了JPIP, Encapsulated PDF,Deflated 等传输语义

IOD
DICOM3-3 Information Object definition， IOD 由多个特定的模块(Module)组成，一些是必须有的,有些是可选的。比如一般的image IOD中,General Patient, General Study,General series, Image, Pixel 都是必须的，有些比如 Overlay Plane 则是可选的。
每个module中的一些属性，对于属性又分为4个级别，1, 2,2C,3.
对于 type 1, 属性必须存在，而且属性值不能为空，
对于type 2, 属性必须存在，
但可以为空。
2C, C即为conditional,在某些条件下必须要存在。
Type 3, 属性可有可无，如果有也可以为空。
我们在做设备研发时一定要注意。Type 1, type 2 必须要有。对于一些重要的Type 3,最好要有。对于Type 2最好能分配一个合理的值。比如General series中定义的series number, 它是type 2的属性，很多设备生成的影像中，这个值为空，这也是符合标准的。
如果一个检查有多个序列，对于同一检查的多个序列，它会依据series number, image number 来挂片，这样给医院整个工作流带来麻烦。
特定的影像IOD,一般都会有特定的level 2的属性 (general series 2C). 比如intra oral 中的image level的positioner type, image laterality.

国内的很多的应用是基于一些免费的或第三方的开发库，一些库都有自己的缺陷或对DICOM标准自己的理解，有时并不正确。所以我们在应用时一定要注意，type 1, type 2最好都要有值。一个常见的例子，patient id 就是type 2 的patient level 的属性，可以为空，但是对于general worklist,它有是patient level 的unique key. 很多系统在设计是，不允许它为空。此时会很尴尬。