Digital Imaging and Communications in Medicine (DICOM)

9.5 Application Context 191
application (such as particular DICOM software running on the associationrequesting
AE). The association-responding AE can even abort the entire association
if it finds the context unsupported.
For this purpose, NEMA (keeper of the DICOM standard) is also responsible
for issuing unique Application Context names to various DICOM implementations
and manufacturers (following UID encoding guidelines, see 5.5.8).
In this way, various Application Contexts uniquely correspond to the DICOM
capabilities of their respective applications, acting as conformance statement
references.
Moreover, you can define your own private (unregistered with NEMA) Application
Context and use it in your application. For example, if, during the
negotiation process, your application receives an association request with an
Application Context equal to yours, it will immediately know that an association
is requested by another instance of the same software. In this case, you
can enable advanced or proprietary data transfer protocols, which only your
software supports, and you will know for sure that they will work.
Practically, however, DICOM offers a default Application Context name
(1.2.840.10008.3.1.1.1) that many applications borrow. It would be impractical
for any program to maintain a list of various Application Context names from
other DICOM manufacturers and use them to negotiate additional DICOM
capabilities during the association establishment process. Besides, all DICOM
parameters needed for association (such as Abstract and Transfer Syntaxes)
are explicitly included in association messages and can be used to capture any
perceivable variety of communication options without the use of Application
Context.
Fig. 57 Application Context item, from PS3.8, and its most typical example