The normative definition of the schema can be found in Section H.1.3. This section gives additional informative descriptions of the objects and information defined in that schema and makes normative statements regarding DICOM system behavior.
The Application Configuration Data Model has the following component objects:
Device – The description of the device
Network AE – The description of the network application entity
Network Connection – The description of the network interface
Transfer Capability – The description of the SOP classes and syntaxes supported by a Network AE.
Figure H.1-1Application Configuration Data Model
In addition there are a number of other objects used in the LDAP schema (see section H.1.2 and Figure H. 1-2) :
DICOM Configuration Root – The root of DICOM Configuration Hierarchy
DICOM Devices Root – The root of the DICOM Devices Hierarchy
DICOM Unique AE-Title Registry Root – The root of the Unique DICOM AE-Title Registry
DICOM Unique AE Title – A unique AE Title within the AE Title Registry
LDAP permits extensions to schema to support local needs (i.e. an object may implement a single structural and multiple auxiliary LDAP classes). DICOM does not mandate client support for such extensions. Servers may support such extensions for local purposes. DICOM Clients may accept or ignore extensions and shall not consider their presence an error.
The “device” is set of components organized to perform a task rather than a specific physical instance. For simple devices there may be one physical device corresponding to the Data Model device. But for complex equipment there may be many physical parts to one “device”.
The “device” is the collection of physical entities that supports a collection of Application Entities. It is uniquely associated with these entities and vice versa. It is also uniquely associated with the network connections and vice versa. In a simple workstation with one CPU, power connection, and network connection the “device” is the workstation.
An example of a complex device is a server built from a network of multiple computers that have multiple network connections and independent power connections. This would be one device with one application entity and multiple network connections. Servers like this are designed so that individual component computers can be replaced without disturbing operations. The Application Configuration Data Model does not describe any of this internal structure. It describes the network connections and the network visible Application Entities. These complex devices are usually designed for very high availability, but in the unusual event of a system shutdown the “device” corresponds to all the parts that get shut down.
Table H.1-2 Attributes of Device Object
|Device Name||1||A unique name (within the scope of the LDAP database) for this device. It is restricted to legal LDAP names, and not constrained by DICOM AE Title limitations.|
|Description||0..1||Unconstrained text description of the device.|
|Manufacturer||0..1||Should be the same as the value of Manufacturer (0008,0070) in SOP instances created by this device.|
|Manufacturer Model Name||0..1||Should be the same as the value of Manufacturer Model Name (0008,1090) in SOP instances created by this device.|
|Software Version||0..N||Should be the same as the values of Software Versions (0018,1020) in SOP instances created by this device.|
|Station Name||0..1||Should be the same as the value of Station Name (0008,1010) in SOP instances created by this device.|
|Device Serial Number||0..1||Should be the same as the value of Device Serial Number (0018,1000) in SOP instances created by this device.|
|Primary Device Type||0..N||Represents the kind of device and is most applicable for acquisition modalities. Types should be selected from the list of code values (0008,0100) for Context ID 30 in PS3.16 when applicable.|
|Institution Name||0..N||Should be the same as the value of Institution Name (0008,0080) in SOP Instances created by this device.|
|Institution Address||0..N||Should be the same as the value of Institution Address (0008,0081) attribute in SOP Instances created by this device.|
|Institutional Department Name||0..N||Should be the same as the value of Institutional Department Name (0008,1040) in SOP Instances created by this device.|
|Issuer of Patient ID||0..1||Default value for the Issuer of Patient ID (0010,0021) for SOP Instances created by this device. May be overridden by the values received in a worklist or other source.|
|Related Device Reference||0..N||The DNs of related device descriptions outside the DICOM Configuration hierarchy. Can be used to link the DICOM Device object to additional LDAP objects instantiated from other schema and used for separate administrative purposes.|
|Authorized Node Certificate Reference||0..N||The DNs for the certificates of nodes that are authorized to connect to this device. The DNs need not be within the DICOM configuration hierarchy.|
|This Node Certificate Reference||0..N||The DNs of the public certificate(s) for this node. The DNs need not be within the DICOM configuration hierarchy.|
|Vendor Device Data||0..N||Device specific vendor configuration information|
|Installed||1||Boolean to indicate whether this device is presently installed on the network. (This is useful for pre-configuration, mobile vans, and similar situations.)|
The “Authorized Node Certificate Reference” is intended to allow the LDAP server to provide the list of certificates for nodes that are authorized to communicate with this device. These should be the public certificates only. This list need not be complete. Other network peers may be authorized by other mechanisms.
The “This Node Certificate Reference” is intended to allow the LDAP server to provide the certificate(s) for this node. These may also be handled independently of LDAP.
Note: A device may have multiple Primary Device Type entries. It may be a multifunctional device, e.g. combined PET and CT. It may be a cascaded device, e.g. image capture and ultrasound.
Table H.1-3 Child Objects of Device Object
|Network Application Entity||1..N||The application entities available on this device (see Section H.1.1.2)|
|Network Connection||1..N||The network connections for this device (see Section H.1.1.3)|
A Network AE is an application entity that provides services on a network. A Network AE will have the same functional capability regardless of the particular network connection used. If there are functional differences based on selected network connection, then these are separate Network AEs. If there are functional differences based on other internal structures, then these are separate Network AEs.
Table H.1-4 Attributes of Network AE Object
|AE Title||1||Unique AE title for this Network AE|
|Description||0..1||Unconstrained text description of the application entity.|
|Vendor Data||0..N||AE specific vendor configuration information|
|Application Cluster||0..N||Locally defined names for a subset of related applications. E.g. “neuroradiology”.|
|Preferred Called AE Title||0..N||AE Title(s) that are preferred for initiating associations.|
|Preferred Calling AE Title||0..N||AE Title(s) that are preferred for accepting associations.|
|Association Acceptor||1||A Boolean value. True if the Network AE can accept associations, false otherwise.|
|Association Initiator||1||A Boolean value. True if the Network AE can accept associations, false otherwise.|
|Network Connection Reference||1..N||The DNs of the Network Connection objects for this AE|
|Supported Character Set||0..N||The Character Set(s) supported by the Network AE for data sets it receives. The value shall be selected from the Defined Terms for Specific Character Set (0008,0005) in PS3.3. If no values are present, this implies that the Network AE supports only the default character repertoire (ISO IR 6).|
|Installed||0..1||A Boolean value. True if the AE is installed on network. If not present, information about the installed status of the AE is inherited from the device|
The “Application Cluster” concept provides the mechanism to define local clusters of systems. The use cases for Configuration Management require a “domain” capability for DICOM applications that would be independent of the network topology and administrative domains that are used by DNS and other TCP level protocols. The Application Cluster is multi-valued to permit multiple clustering concepts for different purposes. It is expected to be used as part of a query to limit the scope of the query.
The “Preferred Called AE Title” concept is intended to allow a site administrator to define a limited default set of AEs that are preferred for use as communication partners when initiating associations. This capability is particularly useful for large centrally administered sites to simplify the configuration possibilities and restrict the number of configured AEs for specific workflow scenarios. For example, the set of AEs might contain the AE Titles of assigned Printer, Archive, RIS and QA Workstations so that the client device could adapt its configuration preferences accordingly. The “Preferred Called AE Title” concept does not prohibit association initiation to unlisted AEs. Associations to unlisted AEs can be initiated if necessary.
The “Preferred Calling AE Title” concept is intended to allow a site administrator to define a default set of AEs that are preferred when accepting assocations. The “Preferred Calling AE Title” concept does not prohibit accepting associations from unlisted AEs.
The “Network Connection Reference” is a link to a separate Network Connection object. The referenced Network Connection object is a sibling the AE object (i.e., both are children of the same Device object).
Table H.1-5 Child Objects of Network AE Object
|Transfer Capability||1..N||The Transfer Capabilities for this Network AE. See Section H.1.4|
The “network connection” describes one TCP port on one network device. This can be used for a TCP connection over which a DICOM association can be negotiated with one or more Network AEs. It specifies the hostname and TCP port number. A network connection may support multiple Network AEs. The Network AE selection takes place during association negotiation based on the called and calling AE-titles.
Table H.1-6 Attributes of Network Connection Object
|Common Name||0..1||An arbitrary name for the Network Connections object. Can be a meaningful name or any unique sequence of characters. Can be used as the RDN. Note: The “cn” attribute type is a basic LDAP defined type and is a synonym for Common Name.|
|Hostname||1||This is the DNS name for this particular connection. This is used to obtain the current IP address for connections. Hostname must be sufficiently qualified to be unambiguous for any client DNS user.|
|Port||0..1||The TCP port that the AE is listening on. (This may be missing for a network connection that only initiates associations.)|
|TLS CipherSuite||0..N||The TLS CipherSuites that are supported on this particular connection. TLS CipherSuites shall be described using an RFC-2246 string representation (e.g. “TLS_RSA_WITH_RC4_128_SHA”)|
|Installed||0..1||A Boolean value. True if the Network Connection is installed on the network. If not present, information about the installed status of the Network Connection is inherited from the device.|
Inclusion of a TLS CipherSuite in a Network Connection capable of accepting associations implies that the TLS protocol must be used to successfully establish an association on the Network Connection.
A single Network AE may be available on multiple network connections. This is often done at servers for availability or performance reasons. For example, at a hospital where each floor is networked to a single hub per floor, the major servers may have direct connections to each of the hubs. This provides better performance and reliability. If the server does not change behavior based on the particular physical network connection, then it can be described as having Network AEs that are available on all of these multiple network connections. A Network AE may also be visible on multiple TCP ports on the same network hardware port, with each TCP port represented as a separate network connection. This would allow, e.g. a TLS-secured DICOM port and a classical un-secured DICOM port to be supported by the same AE.
Each Network AE object has one or more Transfer Capabilities. Each transfer capability specifies the SOP class that the Network AE can support, the mode that it can utilize (SCP or SCU), and the Transfer Syntax(es) that it can utilize. A Network AE that supports the same SOP class in both SCP and SCU modes will have two Transfer Capabilities objects for that SOP class.
Table H.1-7 Attributes of Transfer Capability Object
|Common Name||0..1||An arbitrary name for the Transfer Capability object. Can be a meaningful name or any unqiue sequence of characters. Can be used as the RDN.|
|SOP Class||1||SOP Class UID|
|Role||1||Either “SCU” or “SCP”|
|Transfer Syntax||1..N||The transfer syntax(es) that may be requested as an SCU or that are offered as an SCP.|
This structural object class represents the root of the DICOM Configuration Hierarchy. Only a single object of this type should exist within an organizational domain. Clients can search for an object of this class to locate the root of the DICOM Configuration Hierarchy.
Table H.1-8 Attributes of the DICOM Configuration Root Object
|Common Name||1||The Name for the Configuration Root. Should be used as the RDN. The name shall be “DICOM Configuration”.|
|Description||0..1||Unconstrained text description.|
Table H.1-9 Child Objects of DICOM Configuration Root Object
|Devices Root||1||The root of the DICOM Devices Hierarchy|
|Unique AE Titles Registry Root||1||The root of the Unique AE Titles Registry|
This structural object class represents the root of the DICOM Devices Hierarchy. Only a single object of this type should exist as a child of DICOM Configuration Root. Clients can search for an object of this class to locate the root of the DICOM Devices Hierarchy.
Table H.1-10 Attributes of the Devices Root Object
|Common Name||1||The Name for the Devices Root. Should be used as the RDN. The name shall be “Devices”.|
|Description||0..1||Unconstrained text description.|
Table H.1-11 Child Objects of Devices Root Object
|Device||0..N||The individual devices installed within this organizational domain.|
This structural object class represents the root of the Unique AE-Titles Registry Hierarchy. Only a single object of this type should exist as a child of the DICOM Configuration Root. Clients can search for an object of this class to locate the root of the Unique AE Titles Registry.
Table H.1-12 Attributes of the Unique AE Titles Registry Root Object
|Common Name||1||The Name for the Unique AE Titles Registry Root. Should be used as the RDN. The name shall be “Unique AE Titles Registry”.|
|Description||0..1||Unconstrained text description.|
Table H.1-13 Child Objects of Unique AE Titles Registry Root Object
|Unique AE Title||0..N||The unique AE Titles installed within this organizational domain (see Section H.1.8)|
This structural object class represents a Unique Application Entity Title. Objects of this type should only exist as children of the Unique AE-Titles Registry Root. The sole purpose of this object class is to enable allocation of unique AE Titles. All operational information associated with an AE Title is maintained within a separate Network AE object.
Table H.1-14 Attributes of the Unique AE Title Object
|AE Title||1||The Unique AE Titles.|