8 Structure of application profile

Application Profiles specific to various clinical areas are defined in the annexes to this part. Each Annex defines an Application Profile Class related to a single area of medical practice, e.g., cardiology, or to a single functional context, e.g., image transfer to a printer system. Several specific Application Profiles may be defined in each Application Profile class, and an identification scheme is established to label each specific Application Profile.

An example of an Application Profile structure is provided in below. The section identifier "X" should be replaced by the identifier of the annex.

Class and Profile Identification - Section X.1

Section X.1 of the Application Profile defines the class and specific Application Profiles in that class.

This section assigns an identifier to each Application Profile of the form ttt-x...x-y...y, where “ttt” indicates the type of Application Profile, "x...x" is an abbreviation of a significant term for the clinical context and "y...y" is a significant term for a distinguishing feature of the specific Application Profile. The “ttt” type term shall be one of STD, AUG, or PRI, indicating whether the Application Profile is a Standard, Augmented, or Private Application Profile respectively (see PS 3.2). Identifiers shall be written such that they may be encoded with LO (Long String) Value Representation (see PS 3.5).

Note: Conformance Statements may use the earlier prefix of APL, which is equivalent to STD. This use is deprecated and may be retired in future versions of the standard.


Section X.2 of the Application Profile shall describe the clinical need for the interchange of medical images and related information on storage media, and its context of application. This section shall not require any specific functionality of the Application Entities exchanging information using media interchange beyond their capabilities in the roles of File-set Creator, File-set Reader, and File-set Updater.

NOTE : This Section does not, for example, place any graphical presentation or performance requirements on workstations that read DICOM interchange media. Such requirements are beyond the scope of a DICOM Media Storage Application Profile. The requirements that fall within the scope of an Application Profile are the specific functional storage media interchange capabilities associated with the defined roles.

Roles and Service Class Options Section X.2.1

Section X.2.1 describes the Service Class Options used and the contextual application of the roles of File-set Creator, File-set Reader, and File-set Updater.

General Class Profile - Section X.3

Section X.3 defines characteristics of the Application Profile Class that are constant across all specific Application Profiles in the class.

SOP Classes and Transfer Syntaxes - Section X.3.1

Section X.3.1 lists the SOP Classes and Transfer Syntaxes common to all specific Application Profiles in the class, if any. This section specifies which SOP Classes are mandatory and optional for the roles of FSC, FSR, and FSU, including any required groupings or SOP options.

Physical Media And Media Formats - Section X.3.2

Section X.3.2 defines the physical media and corresponding media formats common to all specific Application Profiles in the class, if any.

This section also specifies any file service functionality beyond the DICOM File Service required by the clinical application to be supplied by the Media Format Layer.

Directory Information in DICOMDIR - Section X.3.3

Section X.3.3 specifies the type of Directory Records that shall be supported and any additional associated keys. It also defines any extensions to or specializations of the Basic Directory Information Object Definition, if any.

Other Parameters - Section X.3.4

Section X.3.4 is optional; if present, it should define any other parameters common to all specific Application Profiles in the class, which may need to be specified in order to ensure interoperable media interchange.

Specific Application Profiles - Section X.4 and following

Sections X.4.and following, each define the unique characteristics of a specific Application Profile. If there are any Application Profile specific changes to IODs, Transfer Syntax, DICOMDIR, or other general class requirements, they should be described for each Application Profile that specifies such changes.

SECURITY Parameters - Section X.3.5

Section X.3.5 is optional; if absent, the Application Profile is unsecure and the Secure DICOM File Format shall not be used for any DICOM File in the File-set.

If present, this section defines the Media Storage Security Profile to be used for encapsulating all DICOM Files in the File-set, including the DICOM Directory. If this section is present, the Application Profile is called Secure Media Storage Application Profile .