DICOM查询/获取信息模型的研究及关系数据库实现
1 引言
随着我国医院数字化、信息化建设的发展，越来越多的医院需要对生成的医学影像进行高效的、自动化的管理和共享。使用医学图像管理与归档系统（PACS）可以满足这种需要，而DICOM3．0标准是设计和实现PACS系统的基础。DICOM查询/获取服务类（Query/Retrieve Service Class），是PACS系统中所必须实现的一个DICOM服务类，在PACS的许多组件中都必须要（或可以）使用DICOM Query/Retrieve服务，如影像归档服务器、离线存储服务器、影像浏览工作站等。
DICOM Query/Retrieve服务类的服务对象对类（SOP Class）由DICOM查询l获取信息模型（QuerylRetrieve Information Model）和对其进行操作的DIMSE-C服务组（DIMSE-C Service Group）组成，对DICOM Query/Retrieve信息模型的充分理解和合理的实现，可以保证医学影像信息数据存储的高效性和低冗余度，提高数据查询和影像获取的速度。本文在介绍DICOM Query/Retriev。服务类的基础上，重点分析了Query/Retrieve信息模型，并使用关系数据库MS SQL Server2000实现了此信息模型，最后利用OFFIS的DCMTK验证了使用关系数据库实现QuerylRetrieve信息模型的可行性和正确性。
2 DICOM Query/Retrieve服务类
DICOM Query/Retrieve服务类实现了一种重要DICOM服务，DICOM Query/Retrieve服务。DICOM Query/Retrieve服务对象对类（Service Object Pair Class）由两个对等的DICOM应用实现（peer DICOM AEs），一个充当服务类提供者的角色（Service Class Provider），一个是服务类使用者（Service Class User）。SCP维护和管理一组存储复合对象SOP实例（Stored Composite Object SOP Instance）信息，这些信息按照DICOM Query/Retrieve信息模型进行组织。一组DIMSE -C（DICOM Message Service Element-Composite）服务可以对Query/Retrieve信息模型进行操作，实现对存储复合对象实例的查询和获取。DICOM Query/Retrieve服务类定义的实体一联系模型如图1所示。
DICOM Query/Retrieve服务由SCU发起，基本实现过程如下：
（1）首先通过协商（Negotiate）建立SCP与SCU的DICOM关联（Association）。在进行协商时SCU要指定所请求使用的Query/Retrieve信息模型和消息服务组（由SOP Class UID确定）。
（2）SCP根据它对SCU所请求的服务的支持情况对此次请求（Request）进行接受（Accept）或拒绝（Refuse），若接受请求则关联建立。
（3）在关联建立后，SCP处理SCU发送的DICOM数据集（DICOM Data Set）形式的请求标示符（Request Identifier）。Request Identifier中包含要求匹配的关键字属性（Key Attributes），查询获取层次（Query/Retrieve Level，tag为：0008，0052），及所使用的字符集（Character Set，tag为：0008，0005）。
（4） SCP按照查询关键字属性（Key Attributes），在Query/Retrieve信息模型中匹配符合要求的存储复合SOP实例。每匹配一条SOP实例，构造一个回应标示符（Response Identifier）向SCU发送（如果是Retrieve服务，还要发起一个StorageService），并且向SCU发送回应状态：pending。
（5）在整个查询匹配完成后，SCP向SCU发送总的回应状态：Success，Refused或（6）在SCP匹配Query/Retrieve信息模型的过程中，SCU可以发送C-CANCEL请求，要求SCP停止此次Query/Retrieve服务。SCP收到C-CANCE请求后因停止对Query/Retrieve信息模型的匹配，及发起C-STORE服务，并向SCU回应此次Query/Retrieve服务的状态：CANCEL。
3 DICOM标准Query/Retrieve信息模型
DICOM标准Query/Retriev。信息模型，是一种医学影像信息的组织形式，信息模型由0-n个DICOM实体（Entity）组成，每个实体由多个DICOM属性（Attribute）来表示。Query/Retriev。信息模型中的DICOM属性与DICOM信息对象定义（IOD）中的属性相同，每个属性都有它的属性描述，标签（tag）和值类型（VR）。在Query/Retrieve信息模型，每个实体的所有属性组成的DICOM数据集（DICOM Data Set）可以确定一个唯一的DICOM复合对象实例（Composite Object Instance）。Query/Retrieve信息模型由SOP Class的SCP维护和管理，每个实体对应一个SCP可操作的DICOM复合对象实例。
3．1 Query/Retrieve信息模型中属性的类型
DICOM Query/Retriev。信息模型中实体的属性被分为三种类型：唯一关键字属性（Unique Key Attribute）、必须关键字属性（Required Key Attribute）和可选关键字属性（Optional Key Attribute）。
唯一关键字属性：简称唯一关键字（Unique Key）。在QuerylRetriev。信息模型的每个级别（Level）上都有一个属性被定义为唯一关键字，每一个唯一关键字确定一个给定级别上的实体，每个级别上的两个实体不能具有相同的唯一关键字。
必须关键字属性：简称必须关键字（RequiredKey）。Query/Retrieve信息模型的每一个级别上有一组属性被定义为必须关键字。之所以被称为必须关键字，是因为在C-FIND服务中SCP必须支持对必须关键字的匹配要求，也就是说SCP所维护的Query/Retriev。信息模型中的实体必须具有有必须关键字属性，在C -FIND服务中对于Request Identifie：中包含的必须关键字属性，SCP要实现对其在信息模型中进行匹配，而且在Response Identifie：中将匹配结果返回。对于给定级别的两个DICOM实体可以有相同的必须关键字属性。
C-FIND服务的Request Identifier中可以包含必须关键字，C -MOVE，C -GET服务的RequestIdentifier中不能包含必须关键字。
可选关键字属性：简称可选关键字（Optional Key）。Query/Retrieve信息模型的每一个级别上有一组属性被定义为哥选关键字。在C-FIND服务中，SCP对可选关键字可进行如下三种处理：
（1）Query/Retrieve信息模型的DICOM实体中不具有可选关键字属性。
（2）信息模型的DICOM实体中具有可选关键字属性，但SCP不实现对可选关键字的匹配，在Response Identifie：中不返回所要求的可选关键字。
（3）以处理必须关键字的方式处理可选关键字。
C-FIND服务的Request Identifier中可以包含可选关键字，C-MOVE，C -GET服务的RequestIdentifier中不能包含可选关键字。
表1为Patient Root Query/Retrieve信息模型Patient Level所定义的属性及类型。
3．2 Query/Retrieve信息模型的分层结构
DICOM标准中定义了三种DICOM标准Query/Retrieve信息模型：Patient Root Query/Retrieve信息模型，Study Root Query/Retrieve信息模型和Patient/Study Only Query/Retriev。信息模型。每种信息模型中的实体都按照分层的形式进行了组织，即对于每种信息模型中实体，DICOM标准将其分为几个级别（Level）来进行操作，各个级别的实体的关系由实体一联系模型（Entity -Relation Model）来表示，DICOM标准规定了每个级别中的实体所具有的唯一关键字、必须关键字和可选关键字（如：表1为Patient Root Query/Retrieve信息模型Patient Level的属性和类型）。在实现Query/Retrieve服务时，Request Identifier中的Query/Retrieve Level属性（tag；0008，0052）指明了所请求的Query/Retrieve信息模型的级别。
Patient Root Query/Retrieve信息模型：分为四个级别，Patient Level，Study Level，Series Level和Composite Object Instance Ixvel。其实体一联系模型如图2所示。
Study Root Query/Retriev。信息模型：分为三个级别，Study Level，Series Level和Composite ObjectInstance Level。实体联系一模型如图3所示。
Patient/Study Only Query/Retrieve信息模型：分为两个级别，Patient Level和Study Level。实体联系模型如图4所示。
4 DICOM Query/Retrieve信息模型的实现
DICOM Query/Retrieve信息模型可以根据需要使用文件系统、数据库管理系统等任何方式来实现。通过前面的分析，我们可以看出DICOM Query/ Retrieve信息模型更适合于使用关系数据库来实现，这样可以方便的利用DICOM实体联系模型，实现各级别的实体之间的关系；有效的组织数据，减少数据存储的冗余度；根据查询要求合理的构造SQL语句，提高查询速度；而且还可实现多个SCP共享同一个Query/Retrieve信息模型。下面就是我们使用MS SQL Server2000对DICOM Query/Retrieve信息模型的实现。
4．1 数据库表结构
根据DICOM Query/Retrieve信息模型分层组织数据的特点，我们在数据库中设计了4张表，PatientInfo，Studylnfo，SeriesInfo和InstanceInfo，分别对应信息模型的Patient Level，Study Level，SerialLevel和Composite Object Instance Level。每个表的主键为信息模型相应级别上的唯一关键字（Unique Key），且表中包含本级别的必须关键字（Required Key）。使用上层级别表的主键作为下层级别表的外键来实现Query/Retrieve信息模型的实体一联系关系。具体的表结构如表2，3，4，5所示：
4．2 SQL语句的构造
在设计数据库的表结构时，既考虑了Query/Retrieve信息模型分层组织数据的特点，又考虑了减少数据冗余度的需要，相同的属性只在一个表中保存，如Patient的信息只在PatientInfo表中存放。在实现Query/Retriev。服务时，需要根据使用的Query/Retrieve信息模型的类型（Patient Root，Study Root或者PatientlStudy only）以及所要求的级别（Level），从Request Identifier中取得查询条件，来构造SQL语句。下面以使用Study Root Query/Retrieve信息模型的查询服务（C-FIND）为例来说明如何构造SQL语句。
Study Root Query/Retrieve信息模型有3个查询级别Study Level，Series Level和Composite Object Instance Level。对于Study Level的查询有两种情况，一种是Request Identifier中包含Patient的属性的查询，一种是不包含Patient的属性的查询。由于所有Patient的属性都保存在PatientInfo表中，所以对于Request Identifier中包含Patient属性的情况，需要连接PatientInfo表和StudyInfo表进行查询。例如，Request Identifier的数据集为：（0008，0052）CS
[STUDY] # QueryRetrieveLevel
（0010，0010）PN [Mary] # PatientsName
（0010，0020）LO[] # PatientID
（0002，000D）UI[] # StudyInstanceUID
（0008，0020）DA[] #StudyData
查询数据库的SQL语句为：
SELECT PLPatientID，PatientName，StudyInstanceUID，StudyData
FROM PatientInfo AS PI JOIN StudyInfo AS SI ON PLPatientID=SLPatientID
WHERE PatientName='Mary'
对于Request Identifier中不包含Patient属性的查询则只需在StudyInfo表中词查询。例如，Request Identifie：的数据集为：
（0008，0052）CS [STUDY] # QueryRetrieveLevel
（0020，0010）LO [001] # StudyID
（0002，000D）UI[] # StudyInstanceUID
（0008，0020）DA[] #StudyData
查询数据库的SQL语句为：
SELECT StudyID，StudyInstanceUID，StudyData
FROM StudyInfo
WHERE StudyID=‘001’
若查询级别为Series Level或Composite Object Instance Level，则Request Identifier中的属性都只包含在SeriesInfo表或InstanceInfo表中，因此构造SQL语句的方法与Study Level的第二种情况相同。
对于Retrieve服务（C-MOVE，C-GET）由于总是要对复合对象实例（Composite Object Instance）进行操作，因此无论那个级别，都通过查询InstanceInfo表来获得复合对象实例的存储位置，然后对其进行相应的操作。
5 Query/Retrieve信息模型实现的验证
DCMTK（DICOM Tools Kit）是由德国奥登勃格（Oldenburg）的OFFIS研究院（Institute OFFIS）开发的一款DICOM应用软件开发包，是一个比较有名的开源DICOM软件开发包。DCMTK的Query/Retrieve信息模型使用文件系统来实现，这样限制了它的数据容量和查询效率。我们使用Query/Retrieve信息模型的SQL Server 2000实现替换了它原来的“文件系统查询/获取模型”，在Windows2003 Serve：系统下使用它的命令行程序dcmqrscp．ex。作为DICOM归档服务、器。在影像的获取方面我们使用日本BitStron。公司开发的BS DICOM Gateway将普通图像（bmp，jpeg等）转换为DICOM图像，送归档服务器保存（Second Capture Image Storage Service ）。使用的影像工作站软件为美国Merge eMed公司的efilm Workstation v2．1和韩国Medical Standard公司的PACS PLUS DICOM Viewer。
经过测试，我们使用SQL Server2000实现的DICOM Query/Retrieve信息模型，可以正确的实现Patient Root，Study Root和Patient/Study Only的各个级别的DICOM Query/Retrieve服务，而且在归档服务器保存的DICOM影像信息数据量较大时，也可以获得较高的查询效率。
6 小结
医学影像数据自身的特点决定了PACS系统的DICOM归档服务器需要保存海量的医学影像数据信息，同时要保证数据保存的可靠性和查询的速度，因此对于DICOM Query/Retrieve信息模型的深刻理解和合理的实现就显的尤为重要。使用关系数据库管理系统（如，MS SQL Server，Oracle等）来实现DICOM Query/Retrieve信息模型是一个不错的选择，这样可以实现医学影像数据信息的合理组织，减少数据保存的冗余度，减少对存储空间的占用；在大数据量的情况下，可通过建立索引等方式保证较快的查询速度；另外也可以利用数据库管理系统提供的数据备份的功能，来保证数据存放的可靠性。
