Research on DICOM query/Information Retrieval Model and implementation of Relational Database

1 Introduction
With the development of hospital digitalization and informatization in China, more and more hospitals need to efficiently and automatically manage and share the generated medical images. The use of the medical image management and archiving system (PACS) can meet this need, and the dicom3.0 standard is the basis for designing and implementing the PACS system. DICOM query/retrieval service class (query/retrieve service class) is a DICOM service class that must be implemented in the PACS system. It must (or can) be used in many components of PACS) use DICOM query/retrieve services, such as image archiving servers, offline storage servers, and Image Browsing workstations.
DICOM query/retrieve service class (SOP class) the service object pair class (SOP class) is a DIMSE-C Service Group (DIMSE-C Service Group) that obtains information model (querylretrieve Information Model) and operates on it by DICOM query L) the fully understanding and reasonable implementation of DICOM query/retrieve information model ensures the high efficiency and low redundancy of medical image information data storage, and improves the speed of data query and image acquisition. This article describes DICOM query/retriev. Based on the service class, the query/retrieve information model is analyzed, and the information model is implemented using Relational Database Service (RDS) ms SQL Server2000, finally, the offis DCMTK is used to verify the feasibility and correctness of Using relational database to implement the querylretrieve information model.

 

 

2 DICOM query/retrieve service class
The DICOM query/retrieve service class is an important DICOM service, DICOM query/retrieve service. DICOM query/retrieve service object pair class is implemented by two peer DICOM applications (peer dicom aes), one serves as the service class provider ), one is a service class user ). SCP maintains and manages a group of stored composite object SOP instances, which are organized according to the DICOM query/retrieve information model. A group of DIMSE-C (DICOM message service element-composite) services can operate on the query/Retrieve Information Model to query and obtain the storage compound object instances. The entity-1 link model 1 defined by the DICOM query/retrieve service class is shown in.
The DICOM query/retrieve service is initiated by SCU. The basic implementation process is as follows:
(1) first establish the DICOM Association (association) between SCP and SCU through negotiation (negotiate ). During negotiation, SCU must specify the query/retrieve information model and Message Service Group used by the request (determined by the SOP class UID ).
(2) SCP accepts (accept) or rejects (refuse) the request based on its support for the Service requested by SCU. If the request is accepted, the connection is established.
(3) After the association is established, SCP processes the request identifier in the form of DICOM data set sent by SCU ). Request identifier contains key attributes, query retrieval level (query/retrieve level, Tag:,), and character set, tag: 0008, 0005 ).
(4) SCP matches the compliant storage compound SOP instances in the query/retrieve information model according to the key attributes. Each time a sop instance is matched, a response identifier (Response identifier) is constructed to send to SCU (if it is a retrieve service, a storageservice is also initiated) and the response status is pending.
(5) After the entire query is matched, SCP sends the overall response status to SCU: Success, refused, or (6) When SCP matches the query/retrieve information model, SCU can send C-CANCEL requests that require SCP to stop the query/retrieve service. After receiving the C-CANCE request, SCP stops matching the query/retrieve information model, initiates the C-STORE service, and responds to the SCU to the query/retrieve service status: cancel.
3 DICOM standard query/Retrieve Information Model
DICOM standard query/retriev. The information model is an organizational form of medical image information. The information model consists of 0-n dicom entities, each of which is represented by multiple DICOM attributes. Query/retriev. The DICOM attributes in the information model are the same as those in the DICOM information object definition (IOD). Each attribute has its attribute description, tag, and value type (VR ). In the query/retrieve information model, the DICOM data set composed of all attributes of each object determines a unique DICOM composite object instance ). The query/retrieve information model is maintained and managed by the SCP of the SOP class. Each object corresponds to a DICOM composite object instance that the SCP can operate on.
3.1 type of attributes in the query/Retrieve Information Model
DICOM query/retriev. Attributes of an entity in an information model are divided into three types: unique key attribute, required key attribute, and optional key attribute ).
Unique keyword attribute: Unique keyword (unique key) for short ). In querylretriev. Each level of the information model has an attribute defined as a unique keyword. Each unique keyword determines an object at a given level, two entities at each level cannot have the same unique keyword.
Required keyword attribute: requiredkey ). At each level of the query/retrieve information model, a set of attributes are defined as required keywords. It is called a mandatory keyword because SCP in the C-FIND service must support a matching requirement for a required keyword, that is, the query/retriev maintained by SCP. The entity in the Information Model must have a required keyword attribute. In the C-find service, SCP must match the required keyword attribute contained in request identifie, and return the matching result in response identifie. For two DICOM entities at a given level, they can have the same essential keyword attribute.
The request identifier of the C-FIND service can contain the required keyword, And the requestidentifier of the C-move, C-get service cannot contain the required keyword.
Optional keyword attribute: Optional keyword (optional key) for short ). At each level of the query/retrieve information model, a set of attributes are defined as the primary key word. In the C-FIND service, SCP can handle the following three Optional keywords:
(1) The DICOM entity of the query/retrieve information model does not have the optional keyword attribute.
(2) The DICOM entity of the information model has the optional keyword attribute, but SCP does not match the optional keyword. The required optional keyword is not returned in response identifie.
(3) process the Optional keywords in a way that processes the required keywords.
The request identifier of the C-FIND service can contain Optional keywords, And the requestidentifier of the C-MOVE, C-get service cannot contain Optional keywords.
Table 1 lists the attributes and types defined by the patient Root query/retrieve information model patient level.

 

 

 

3.2 hierarchical structure of query/Retrieve Information Model
The DICOM Standard defines three DICOM standard query/retrieve information models: Patient Root query/retrieve information model, study Root query/retrieve information model and patient/study only query/retriev. Information Model. Entities in each information model are organized in a hierarchical manner. For each information model entity, DICOM standards divide it into several levels for operations, the relationship between entities at each level is represented by the entity-relation model, the DICOM Standard specifies the unique keywords, mandatory keywords, and Optional keywords of each level of the object (for example, the attributes and types of the patient level of the patient Root query/Retrieve Information Model in Table 1 ). When the query/retrieve service is implemented, the query/retrieve Level Attribute (tag; 0008,0052) in the request identifier specifies the level of the requested query/retrieve information model.
Patient Root query/Retrieve Information Model: divided into four levels: patient level, study level, Series level and composite object instance ixvel. As shown in figure 2.
Study Root query/retriev. Information Model: There are three levels: study level, Series level, and composite objectinstance level. Entity contact 1 model 3 is shown.
 

 

 

 

 

Patient/study only query/Retrieve Information Model: There are two levels: patient level and study level. Object contact model 4.

 

 

 

4 Implementation of DICOM query/Retrieve Information Model
DICOM query/retrieve information model can be implemented in any way, such as the file system and database management system, as needed. Through the previous analysis, we can see that the DICOM query/retrieve information model is more suitable for using relational databases. This makes it easy to use the DICOM object contact model to realize the relationship between entities at different levels; effectively organize data to reduce data storage redundancy. Construct SQL statements according to query requirements to improve query speed. In addition, multiple SCP nodes can share the same query/retrieve information model. The following is the implementation of the DICOM query/Retrieve Information Model Using ms SQL Server2000.
4.1 database table structure
According to the hierarchical data organization features of DICOM query/retrieve information model, four tables, patientinfo, studylnfo, seriesinfo, and instanceinfo, are designed in the database, which correspond to the patient level of the information model respectively, study level, seriallevel, and composite object instance level. The primary key of each table is the unique keyword (unique key) at the corresponding level of the information model, and the table contains the required keyword (required key) at the current level ). Use the primary key of the upper-level table as the foreign key of the lower-level table to realize the object-1 link of the query/retrieve information model. The specific table structure is shown in tables 2, 3, 4, and 5:
 

 

 

 

 

 

 

4.2 SQL statement Construction
When designing the table structure of a database, the characteristics of hierarchical data organization in the query/retrieve information model are taken into account, and the need to reduce data redundancy is also taken into account. The same attributes are only saved in one table, for example, patient information is only stored in the patientinfo table. Implement query/retriev. When using the query/Retrieve Information Model (patient root, study root or patientlstudy only) and the required level ), obtain query conditions from request identifier to construct an SQL statement. The following uses the study Root query/Retrieve Information Model of the query service (C-FIND) as an example to illustrate how to construct an SQL statement.
The study Root query/retrieve information model has three query levels: study level, Series level, and composite object instance level. There are two types of study level queries. One is a query that contains the patient attribute in the request identifier, and the other is a query that does not contain the patient attribute. Because all patient attributes are saved in the patientinfo table, you need to connect the patientinfo table and studyinfo table to query requests that contain the patientinfo attribute. For example, the data set of request identifier is: (0008, 0052) CS
[Study] # queryretrievelevel
(0010,0010) PN [Mary] # patientsname
() Lo [] # patientid
(0002,000 d) UI [] # studyinstanceuid
(0008,0020) DA [] # studydata
The SQL statement used to query the database is:
Select plpatientid, patientname, studyinstanceuid, studydata
From patientinfo as pi join studyinfo as Si On plpatientid = slpatientid
Where patientname = 'Mary'
For queries that do not contain the patient attribute in the request identifier, you only need to query the words in the studyinfo table. For example, the data set of request identifie is:
(0008,0052) CS [Study] # queryretrievelevel
(0020,0010) Lo [001] # studyid
(0002,000 d) UI [] # studyinstanceuid
(0008,0020) DA [] # studydata
The SQL statement used to query the database is:
Select studyid, studyinstanceuid, studydata
From studyinfo
Where studyid = '001'
If the query level is Series level or composite object instance level, the attributes of request identifier are only included in the seriesinfo table or the instanceinfo table, therefore, the method for constructing SQL statements is the same as that of study level.
For the retrieve service (C-MOVE, C-GET), regardless of the level, query the instanceinfo table to obtain the storage location of the composite object instance, and then perform corresponding operations on it.
5 query/Retrieve Information Model Implementation Verification
DCMTK (DICOM tools kit) is a DICOM application software development kit developed by the offis Institute offis of Oldenburg, Germany. It is a famous open source DICOM software development kit. DCMTK's query/retrieve information model is implemented by the file system, which limits its data capacity and query efficiency. We use the SQL Server 2000 implementation of the query/Retrieve Information Model to replace its original "File System query/retrieval model". In Windows2003 serve: The system uses its command line program dcmqrscp. ex. Serves as the DICOM archive service and tool. We use Japanese bitstron for image acquisition. The bs dicom gateway developed by the company converts common images (BMP, JPEG, etc.) to DICOM images and sends them to the archiving server for storage (second capture image storage service ). The image workstation software used is efilm workstation V2.1 of merge emed and PACS plus DICOM viewer of medical standard in South Korea.
After testing, we use the DICOM query/Retrieve Information Model Implemented by SQL Server2000 to correctly implement the DICOM query/retrieve services at various levels of patient root, study root, and patient/study only, in addition, the large amount of DICOM image information stored on the archiving server can also achieve high query efficiency.
6 Summary
The characteristics of Medical Image Data determine that the DICOM archive server of the PACS system needs to store massive amounts of medical image data information, and at the same time ensure the reliability of data storage and query speed, therefore, deep understanding and reasonable implementation of DICOM query/retrieve information models are particularly important. The use of relational database management systems (such as ms SQL Server, Oracle, etc.) to achieve DICOM query/retrieve information model is a good choice, which can realize the rational organization of medical imaging data information, reduces data storage redundancy and storage space occupation. In the case of large data volumes, you can create indexes to ensure fast query speed; in addition, the data backup function provided by the database management system can be used to ensure the reliability of data storage.