Материал: part03

In combination with the definition of the Context Group as Extensible or Non-extensible in PS3.16, the conventions in Table 5.6-1​ apply.​

Table 5.6-1. Conventions for Specification of Context Groups​

AlternativeCodesforthesameConcept(i.e.,withthesamemeaning)​ Groups.​

may be used instead of the Codes in the Context Group, since this​ can be construed as not using the Baseline Context Group.​

Codes not in the Context Group may be used as an extension when​ their meaning is within the scope of that Context Group.​

I.e., any Code may be used if its meaning is applicable to the context​ of invocation.​

See also Section 7.2.3 “Extension of Context Groups” in PS3.16.​

- Standard -​

6 DICOM Information Model​

TheDICOMInformationModeldefinesthestructureandorganizationoftheinformationrelatedtothecommunicationofmedicalimages.​ Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.​

Service Class

Specification

1 specifies related

n

SOP Class(es)

1

defined as

DIMSE Services

or Media Storage Attributes Services

Figure 6-1. Major Structures of DICOM Information Model​

6.1 Information Object Definition​

AnInformationObjectDefinition(IOD)isanobject-orientedabstractdatamodelusedtospecifyinformationaboutReal-WorldObjects.​ 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 that 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 that 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 that 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 that 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 that 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.​

- Standard -​

6.2 Attributes​

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules that​ 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​ PS3.5. For specific Data Elements, the Value Representation and Value Multiplicity are specified in the Data Dictionary in PS3.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​

Foron-linecommunicationtheDIMSEServicesallowaDICOMApplicationEntitytoinvokeanoperationornotificationacrossanetwork​ or a point-to-point interface. DIMSE Services are defined in PS3.7.​

Formediastorageinterchange,MediaStorageServicesallowaDICOMApplicationEntitytoinvokemediastoragerelatedoperations.​

Note​

These Media Storage Services are discussed in PS3.10.​

6.3.1 DIMSE-C Services​

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

6.3.2 DIMSE-N Services​

DIMSE-NServicesareservicesapplicableonlytoaNormalizedIOD.DIMSE-NServicesprovidebothoperationandnotificationservices.​

6.4 DIMSE Service Group​

A DIMSE Service Group specifies one or more operations/notifications defined in PS3.7 that are applicable to an IOD.​

DIMSE Service Groups are defined in PS3.4 in the specification of a Service-Object Pair Class.​

6.5 Service-Object Pair Class (SOP Class)​

The SOP Class definitions in PS3.4 contain the rules and semantics that may restrict the use of the services in the DIMSE Service​ Group and/or the Attributes of the IOD. PS3.10 and PS3.18 contain the rules and semantics that may restrict the attributes of the IOD​ or the use of the services in the Media Storage Services and the Web Services respectively.​

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction for​ SOP Classes based on DIMSE Services. This negotiation is performed at association establishment time as described in PS3.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. For DIMSE Services, Normalized SOP Classes are defined​ as the union of a Normalized IOD and a set of DIMSE-N Services, while Composite SOP Classes are defined as the union of a​ Composite IOD and a set of DIMSE-C Services. Media Storage Services only support Composite IODs and Web Services supports​ both Normalized and Composite SOP Classes.​

- Standard -​

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 PS3.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 PS3.7.​

6.7 Service Class Specification​

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

Service Class Specifications are defined in PS3.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.​

- Standard -​

- Standard -​