6 DICOM information model

The DICOM Information Model defines the structure and organization of the information related to the communication of medical images. Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.

[pic]

Figure 6-1 MAJOR STRUCTURES OF DICOM INFORMATION MODEL

6.1 Information object definition

An Information Object Definition (IOD) is an object-oriented abstract data model used to specify information about Real-World Objects. An IOD provides communicating Application Entities with a common view of the information to be exchanged.

An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real-World Objects which share the same properties. An IOD used to generally represent a single class of Real-World Objects is called a Normalized Information Object. An IOD which includes information about related Real-World Objects is called a Composite Information Object.

6.1.1 COMPOSITE IOD

A Composite IOD is an Information Object Definition which represents parts of several entities included in the DICOM Model of the Real-World. This Model is introduced in Section 7. Such an IOD includes Attributes which are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

These related Real-World Objects provide a complete context for the exchanged information. When an instance of a Composite IOD is communicated, this entire context is exchanged between Application Entities. Relationships between Composite IOD Instances shall be conveyed in this contextual information.

The Composite IODs are specified in Annex A.

6.1.2 NORMALIZED IOD

A Normalized IOD is an Information Object Definition which generally represents a single entity in the DICOM Model of the Real-World.

When an instance of a Normalized IOD is communicated, the context for that instance is not actually exchanged. Instead, the context is provided through the use of pointers to related Normalized IOD Instances.

The Normalized IODs are specified in Annex B.

6.2 Attributes

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules which represent a higher level of semantics documented in the Module Specifications found in Annex C.

Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in PS 3.5. For specific Data Elements, the Value Representation and Value Multiplicity are specified in the Data Dictionary in PS 3.6.

When multiple modules containing the same Attributes(s) are included in an IOD, the Attribute shall be encoded only once into a Data Element.

6.3 On-line communication and media storage services

For on-line communication the DIMSE Services allow a DICOM Application Entity to invoke an operation or notification across a network or a point-to-point interface. DIMSE Services are defined in PS 3.7.

For media storage interchange, Media Storage Services allow a DICOM Application Entity to invoke media storage related operations.

Note: These Media Storage Services are discussed in PS 3.10.

6.3.1 DIMSE-C SERVICES

DIMSE-C Services are services applicable only to a Composite IOD, except for C-FIND which may apply to both normalized and composite instances. DIMSE-C Services provide only operation services.

6.3.2 DIMSE-N SERVICES

DIMSE-N Services are services applicable only to a Normalized IOD. DIMSE-N Services provide both operation and notification services.

6.4 DIMSE SERVICE GROUP

A DIMSE Service Group specifies one or more operations/notifications defined in PS 3.7 which are applicable to an IOD.

DIMSE Service Groups are defined in PS 3.4 in the specification of a Service-Object Pair Class.

6.5 SERVICE-OBJECT PAIR (SOP) CLASS

A Service-Object Pair (SOP) Class is defined by the union of an IOD and a DIMSE Service Group. The SOP Class definition contains the rules and semantics which may restrict the use of the services in the DIMSE Service Group and/or the Attributes of the IOD.

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction. This negotiation is performed at association establishment time as described in PS 3.7. An extended negotiation allows Application Entities to further agree on specific options within a SOP Class.

Note: The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the Managed Object Class. Readers familiar with object oriented terminology will recognize the SOP Class operations (and notifications) as comprising the methods of an object class.

6.5.1 NORMALIZED AND COMPOSITE SOP CLASSES

DICOM defines two types of SOP Classes, Normalized and Composite. Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services. Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services.

Note: SOP Class Specifications play a central role for defining DICOM conformance requirements. It allows DICOM Application Entities to select a well-defined application level subset of the DICOM V3.0 Standard to which they may claim conformance. See PS 3.2.

6.6 Association negotiation

Association establishment is the first phase of communication between peer DICOM compliant Application Entities. The Application Entities shall use association establishment to negotiate which SOP Classes can be exchanged and how this data will be encoded.

Association Negotiation is defined in PS 3.7.

6.7 SERVICE CLASS SPECIFICATION

A Service Class Specification defines a group of one or more SOP Classes related to a specific function which is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules which allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to SOP Classes as either a Service Class User (SCU) or Service Class Provider (SCP).

Service Class Specifications are defined in PS 3.4.

Note: Such interaction between peer Application Entities work on a 'client/server model'. The SCU acts as the 'client', while the SCP acts as the 'server'. The SCU/SCP roles are determined during association establishment.