Part 11
Part 11
11
DICOM PS3.11 2019c - Media Storage Application
Profiles
Page 2
A DICOM® publication
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 3
Table of Contents
Notice and Disclaimer ........................................................................................................................................... 11
Foreword ............................................................................................................................................................ 13
1. Scope and Field of Application ............................................................................................................................. 15
2. Normative References ....................................................................................................................................... 17
3. Definitions ....................................................................................................................................................... 19
4. Symbols and Abbreviations ................................................................................................................................. 23
5. Conventions ..................................................................................................................................................... 25
6. Purpose of An Application Profile ......................................................................................................................... 27
7. Conformance Requirements ................................................................................................................................ 29
8. Structure of Application Profile ............................................................................................................................. 31
X.1. Class and Profile Identification ...................................................................................................................... 31
X.2. Clinical Context .......................................................................................................................................... 31
X.2.1. Roles and Service Class Options ................................................................................................................ 31
X.3. General Class Profile .................................................................................................................................. 31
X.3.1. SOP Classes and Transfer Syntaxes ........................................................................................................... 31
X.3.2. Physical Media and Media Formats ............................................................................................................. 31
X.3.3. Directory Information in DICOMDIR ............................................................................................................. 32
X.3.4. Other Parameters .................................................................................................................................... 32
X.4. Specific Application Profiles .......................................................................................................................... 32
X.3.5. Security Parameters ................................................................................................................................. 32
A. Basic Cardiac X-Ray Angiographic Application Profile (Normative) .............................................................................. 33
A.1. Class and Profile Identification ...................................................................................................................... 33
A.2. Clinical Context .......................................................................................................................................... 33
A.2.1. Roles and Service Class Options ............................................................................................................ 33
A.2.1.1. File Set Creator ............................................................................................................................ 34
A.2.1.2. File Set Reader ............................................................................................................................. 34
A.2.1.3. File Set Updater ............................................................................................................................ 34
A.3. STD-XABC-CD Basic Cardiac Profile ............................................................................................................. 34
A.3.1. SOP Classes and Transfer Syntaxes ....................................................................................................... 34
A.3.2. Physical Media and Media Formats ......................................................................................................... 35
A.3.3. Directory Information in DICOMDIR ......................................................................................................... 35
A.3.3.1. Additional Keys ............................................................................................................................. 35
A.3.3.2. Icon Images ................................................................................................................................. 36
A.3.4. Other Parameters ................................................................................................................................ 36
A.3.4.1. Image Attribute Values ................................................................................................................... 36
A.3.4.1.1. Attribute Value Precedence ...................................................................................................... 36
B. 1024 X-Ray Angiographic Application Profile (Normative) ......................................................................................... 37
B.1. Class and Profile Identification ...................................................................................................................... 37
B.2. Clinical Context .......................................................................................................................................... 37
B.2.1. Roles and Service Class Options ............................................................................................................ 37
B.2.1.1. File Set Creator ............................................................................................................................ 37
B.2.1.2. File Set Reader ............................................................................................................................. 38
B.2.1.3. File Set Updater ............................................................................................................................ 38
B.3. STD-XA1K Application Profile Class Requirements ........................................................................................... 38
B.3.1. SOP Classes and Transfer Syntaxes ....................................................................................................... 38
B.3.2. Physical Media and Media Formats ......................................................................................................... 39
B.3.3. Directory Information in DICOMDIR ......................................................................................................... 39
B.3.3.1. Additional Keys ............................................................................................................................. 39
B.3.3.2. Icon Images ................................................................................................................................. 40
B.3.4. Other Parameters ................................................................................................................................ 40
B.3.4.1. Image Attribute Values ................................................................................................................... 41
B.3.4.2. Multi-frame JPEG Format ............................................................................................................... 41
B.3.4.3. Attribute Value Precedence ............................................................................................................. 41
C. Ultrasound Application Profile (Normative) ............................................................................................................. 43
C.1. Class and Profile Identification ...................................................................................................................... 43
C.2. Clinical Context ......................................................................................................................................... 43
C.2.1. Roles ................................................................................................................................................ 44
- Standard -
Page 4 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 5
- Standard -
Page 6 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 7
List of Figures
6-1. Relationship Between an Application Profile and Parts of DICOM ............................................................................. 27
A.2-1. Basic Cardiac X-Ray Angiographic Clinical Context ............................................................................................ 33
C.2-1. Ultrasound Clinical Context ........................................................................................................................... 44
K.2-1. Dental Clinical Context ................................................................................................................................. 79
- Standard -
Page 8 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 9
List of Tables
A.1-1. Basic Cardiac XA Profile ............................................................................................................................... 33
A.3-1. STD-XABC-CD SOP Classes and Transfer Syntaxes .......................................................................................... 34
A.3-2. STD-XABC-CD Additional DICOMDIR Keys ...................................................................................................... 35
A.3-3. STD-XABC-CD- Required Image Attribute Values .............................................................................................. 36
B.1-1. 1024 X-Ray Angiographic Profiles ................................................................................................................... 37
B.3-1. STD-XA1K SOP Classes and Transfer Syntaxes ............................................................................................... 38
B.3-2. STD-XA1K Additional DICOMDIR Keys ............................................................................................................ 40
B.3-3. STD-XA1K Required XA Image Attribute Values ................................................................................................ 41
B.3-4. STD-XA1K Required SC Image Attribute Values ................................................................................................ 41
C.1-1. Ultrasound Application Profile identifiers ........................................................................................................... 43
C.3-1. Ultrasound SOP Classes and Transfer Syntaxes ............................................................................................... 45
C.3-2. Defined Photometric Interpretation and Transfer Syntax Pairs .............................................................................. 45
C.3-3. Media Classes ............................................................................................................................................ 46
D.1-1. STD-GEN Profile ......................................................................................................................................... 47
D.3-1. STD-GEN SOP Classes and Transfer Syntaxes ................................................................................................ 49
D.3-2. STD-GEN Additional DICOMDIR Keys ............................................................................................................. 50
E.1-1. STD-CTMR Profiles ..................................................................................................................................... 51
E.3-1. STD-CTMR SOP Classes and Transfer Syntaxes .............................................................................................. 52
E.3-2. STD-CTMR Additional DICOMDIR Keys ........................................................................................................... 54
E.3-3. STD-CTMR Required Image Attribute Values for CT Images ................................................................................ 55
E.3-4. STD-CTMR Required Image Attribute Values for MR Images ............................................................................... 55
E.3-5. STD-CTMR Required Image Attribute Values for Grayscale SC Images .................................................................. 55
E.3-6. STD-CTMR Required Image Attribute Values for Color SC Images ........................................................................ 56
G.1-1. STD-GEN-MIME Profile ................................................................................................................................ 59
G.3-1. STD-GEN-MIME SOP Classes and Transfer Syntaxes ....................................................................................... 60
H.1-1. STD-GEN-DVD and STD-GEN-SEC-DVD Profiles ............................................................................................. 63
H.3-1. STD-GEN-DVD and STD-GEN-SEC-DVD SOP Classes and Transfer Syntaxes ...................................................... 65
H.3-2. STD-GEN-DVD and STD-GEN-SEC-DVD Additional DICOMDIR Keys ................................................................... 66
I.1-1. STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML Profiles ................................................................... 69
I.3-1. STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML SOP Classes and Transfer Syntaxes ............................ 70
I.3-2. STD-DVD-MPEG2-MPML and STD-DVD-SEC-MPEG2-MPML Additional DICOMDIR Keys ......................................... 71
J.1-1. STD-GEN-USB, STD-GEN-SEC-USB STD-GEN-MMC, STD-GEN-SEC-MMC, STD-GEN-CF, STD-GEN-SEC-CF, STD-
GEN-SD and STD-GEN-SEC-SD Profiles .................................................................................................................. 73
J.3-1. STD-GEN-USB, STD-GEN-SEC-USB, STD-GEN-MMC, STD-GEN-SEC-MMC, STD-GEN-CF, STD-GEN-SEC-CF, STD-
GEN-SD and STD-GEN-SEC-SD SOP Classes and Transfer Syntaxes ........................................................................... 76
K.1-1. Dental Application Profile identifiers ................................................................................................................. 79
K.3-1. Dental Abstract and Transfer Syntaxes ............................................................................................................ 80
K.3-3. STD-DEN-CD - Required Image Attribute Values ............................................................................................... 81
K.3-4. STD-DEN-CD - Required Image Attribute Types ................................................................................................ 81
L.1-1. STD-x-ZIP-MAIL Application Profiles ................................................................................................................ 83
L.3-1. STD-GEN-ZIP-MAIL and STD-GEN-SEC-ZIP-MAIL SOP Classes and Transfer Syntaxes .......................................... 84
L.3-2. STD-DTL-SEC-ZIP-MAIL Abstract and Transfer Syntaxes .................................................................................... 85
L.4-1. STD-DTL-ZIP-MAIL - Required Image Attribute Values ........................................................................................ 86
L.4-2. STD-DTL-ZIP-MAIL - Required Image Attribute Types ......................................................................................... 86
M.1-1. STD-GEN-BD and STD-GEN-SEC-BD Profiles ................................................................................................. 87
M.3-1. STD-GEN-BD and STD-GEN-SEC-BD SOP Classes and Transfer Syntaxes .......................................................... 89
N.1-1. STD-GEN-BD-MPEG4-LV42 and STD-GEN-SEC-BD-MPEG4-LV42 Profiles ........................................................... 93
N.3-1. STD-GEN-BD-MPEG4-LV42 and STD-GEN-SEC-BD-MPEG4-LV42 SOP Classes and Transfer Syntaxes .................... 95
- Standard -
Page 10 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 11
NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary
consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have
an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness
in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy
or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.
NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect,
consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document.
NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information
published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes
or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by
virtue of this standard or guide.
In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf
of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using
this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional
in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by
this publication may be available from other sources, which the user may wish to consult for additional views or information not covered
by this publication.
NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not cer-
tify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance
with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the
certifier or maker of the statement.
- Standard -
Page 12 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 13
Foreword
This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.
The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].
DICOM® is the registered trademark of the National Electrical Manufacturers Association for its standards publications relating to di-
gital communications of medical information, all rights reserved.
HL7® and CDA® are the registered trademarks of Health Level Seven International, all rights reserved.
SNOMED®, SNOMED Clinical Terms®, SNOMED CT® are the registered trademarks of the International Health Terminology
Standards Development Organisation (IHTSDO), all rights reserved.
LOINC® is the registered trademark of Regenstrief Institute, Inc, all rights reserved.
- Standard -
Page 14 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 15
• PS3.2, Conformance, specifies the general rules for assuring interoperability, which are applied for media interchange through the
Application Profiles of this Part
• PS3.3, Information Object Definitions, specifies a number of Information Object Definitions (e.g., various types of images) that may
be used in conjunction with this Part. It also defines a medical Directory structure to facilitate access to the objects stored on media
• PS3.4, Service Class Specifications, specifies the Media Storage Service Class upon which Application Profiles are built
• PS3.5, Data Structure and Encoding, addresses the encoding rules necessary to construct a Data Set that is encapsulated in a file
as specified in PS3.10
• PS3.6, Data Dictionary, contains an index by Tag of all Data Elements related to the Attributes of Information Objects defined in
PS3.3. This index includes the Value Representation and Value Multiplicity for each Data Element
• PS3.10, Media Storage and File Formats for Media Interchange, standardizes the overall open Storage Media architecture used
by this Part, including the definition of a generic File Format, a Basic File Service and a Directory concept
• PS3.12, Media Formats and Physical Media, defines a number of standard Physical Media and corresponding Media Formats.
These Media Formats and Physical Media selections are referenced by one or more of the Application Profiles of this Part. PS3.12
is intended to be extended as the technologies related to Physical Medium evolve
• PS3.15, Security Profiles defines a number of profiles for use with Secure DICOM Media Storage Application Profiles. The Media
Storage Security Profiles specify the cryptographic techniques to be used for each Secure DICOM File in a Secure Media Storage
Application Profile.
- Standard -
Page 16 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 17
2 Normative References
The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. At the time of
publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard
are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.
[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/
members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .
[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
[ISO 7498-2] ISO. 1989. Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2: Security
Architecture.
- Standard -
Page 18 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 19
3 Definitions
For the purposes of this Standard the following definitions apply.
Note
The definition is "the property that information is not made available or disclosed to
unauthorized individuals, entities or processes."
Note
The definition is "the corroboration that the source of data received is as claimed."
Note
The definition is "the property that data has not been altered or destroyed in an
unauthorized manner."
Note
The definition is "the generation, storage, distribution, deletion, archiving and application
of keys in accordance with a security policy."
Attribute Attribute.
Service Object Pair Class (SOP Service-Object Pair Class (SOP Class).
Class)
- Standard -
Page 20 DICOM PS3.11 2019c - Media Storage Application Profiles
File File.
File-set File-set.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 21
Application Profile Class A group of related Application Profiles defined in a single Annex to PS3.11.
- Standard -
Page 22 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 23
CEN TC 251 Comite Europeen de Normalisation - Technical Committee 251 - Medical Informatics
ID Identifier
- Standard -
Page 24 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 25
5 Conventions
Words are capitalized in this document to help the reader understand that these words have been previously defined in Section 3 of
this document and are to be interpreted with that meaning.
- Standard -
Page 26 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 27
Media interchange applications claim conformance to one or more Media Storage Application Profiles. Two implementations that
conform to identical Application Profiles and support complementary File-set roles (e.g., an FSC interchanging media with an FSR)
are able to exchange SOP Instances (pieces of DICOM information) on recorded media within the context of those Application Profiles.
a. which SOP Classes and options must be supported, including any required extensions, specializations, or privatizations
b. for each SOP Class, which Transfer Syntaxes may be used
e. which roles an application may take: File-set Creator, File-set Reader, and/or File-set Updater
f. which physical media and corresponding media formats must be supported
g. whether or not the DICOM Files in the File-set shall be Secure DICOM Files
h. which Media Storage Security Profile must be used for the creation of Secure DICOM Files
The result of making the necessary choices means that the Application Profile can be thought of as a vertical path through the various
parts of DICOM that begins with choices of information to be exchanged and ends at the physical medium. Figure 6-1 shows the re-
lationship between the concepts used in an Application Profile and the parts of DICOM.
PS3.3
PS3.4
PS3.5
Data Structure and
Transfer Syntax Semantics
PS3.10
Media Storage and File
File Format, Directory Format for Data Interchange
PS3.12
Media Formats and Physical
Medium Format, Physical Medium Media for Data Interchange
PS3.15
Security
Security Profile Profiles
- Standard -
Page 28 DICOM PS3.11 2019c - Media Storage Application Profiles
a. The name of the Application Profile, or the list of Application Profiles grouped in a related class
c. The definition of the Media Storage Service Class with the device Roles for the Application Profile and associated options
d. Informative section describing the operational requirements of the Application Profile
e. Specification of the SOP Classes and associated IODs supported and the Transfer Syntaxes to be used
g. If the Directory Information Module is used, the description of the minimum subset of the Information Model required
h. Other parameters that need to be specified to ensure interoperable media interchange
i. Security parameters that select the cryptographic techniques to be used with Secure Media Storage Application Profiles
The structure of DICOM and the design of the Application Profile mechanism is such that extension to additional SOP Classes and
new exchange media is straightforward.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 29
7 Conformance Requirements
Implementations may claim conformance to one or more PS3.11 Application Profiles in a Conformance Statement as outlined in
PS3.2.
Note
Additional specific conformance requirements for an Application Profile may be listed in the Application Profile definition.
- Standard -
Page 30 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 31
An example of an Application Profile structure is provided in below. The section identifier "X" should be replaced by the identifier of
the annex.
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 PS3.2). Identifiers shall be written such that they may be
encoded with LO (Long String) Value Representation (see PS3.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 editions of the Standard.
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 capab-
ilities associated with the defined roles.
- Standard -
Page 32 DICOM PS3.11 2019c - Media Storage Application Profiles
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.
If present, this section defines the Media Storage Security Profile to be used for encapsulating allDICOM Files in the File-set, including
the DICOM Directory. If this section is present, the Application Profile is called Secure Media Storage Application Profile.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 33
The identifier for this class shall be STD-XABC. This annex is concerned only with cardiac angiography.
The specific Application Profile in this class is shown in the Table A.1-1.
Note
This table contains only a single Application Profile. It is expected that additional Application Profiles may be added to PS3.11.
The Application Entity shall support one or more of the roles of File-set Creator, File-set Reader, and File-set Updater, defined in
PS3.10.
- Standard -
Page 34 DICOM PS3.11 2019c - Media Storage Application Profiles
FSC shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information can
be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disk).
Note
A multiple volume (a logical volume that can cross multiple physical media) is not supported by this Application Profile Class.
If a set of Files, e.g., a Study, cannot be written entirely on one CD-R, the FSC will create multiple independent DICOM File-
sets such that each File-set can reside on a single CD-R media controlled by its individual DICOMDIR file. The user of the
FSC can opt to use written labels on the discs to indicate that there is more than one disc for this set of files (e.g., a study).
FSU shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information can
be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disk).
Note
If the disc has not been closed out, the File-set Updater shall be able to update information assuming there is enough space
on the disc to write a new DICOMDIR file, the information, and the fundamental CD-R control structures. CD-R control
structures are the structures that are inherent to the CD-R standards, see PS3.12.
SOP Classes and corresponding Transfer Syntaxes supported by this Application Profile are specified in the Table A.3-1.
1.2.840.10008.1.2.1
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 35
Information Object SOP Class UID Transfer Syntax and UID FSC FSR FSU
Definition Requirement Requirement Requirement
X-Ray Angiographic 1.2.840.10008.5.1.4.1.1.12.1 JPEG Lossless Process 14 Mandatory Mandatory Optional
Image (selection value 1)
1.2.840.10008.1.2.4.70
Note
1. This application profile does not allow the use of the X-Ray Angiographic Bi-Plane Image Object. Biplane acquisitions
must therefore be transferred as two single plane SOP instances. A future Application Profile that permits X-Ray An-
giographic Bi-Plane Image Object transfer is under development.
2. This Application Profile includes only the XA Image SOP Instances. It does not include Standalone Curve, Modality
LUT, VOI LUT, or Overlay SOP Instances.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
Sequence
Image Type (0008,0008) IMAGE 1
Calibration Image (0050,0004) IMAGE 2
Referenced Image Sequence (0008,1140) IMAGE 1C Required if the SOP Instance
referenced by the Directory
Record has an Image Type
(0008,0008) of BIPLANE A or
BIPLANE B. May be present
otherwise.
- Standard -
Page 36 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
1. This icon size is larger than that recommended in PS3.10 because the 64x64 icon would not be clinically useful for
identifying and selecting X-Ray angiographic images.
2. For multi-frame images, it is recommended that the icon image be derived from the frame identified in the Representative
Frame Number attribute (0028,6010), if defined for the image SOP Instance. If the Representative Frame Number is
not present, a frame approximately one-third of the way through the multi-frame image should be selected. The process
to reduce a 512x512 image to a 128x128 image is beyond the scope of this Standard.
When creating or updating a File-set, Rows or Columns shall not exceed a value of 512. When reading a File-set, an FSR or FSU
shall accept a value of at least 512 for Rows or Columns.
Note
The retired Detached Patient Management SOP Class was previously suggested to allow patient identification and demo-
graphic information to be updated without changing the composite Image IOD files. This usage is now retired.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 37
The specific Application Profiles in this class are shown in the Table B.1-1.
Additionally, images derived from or related to primary digital X-Ray cine runs, such as quantitative analysis images, reference images,
multi-modality images and screen capture images, may be interchanged via this Profile.
The operational use of the media interchange is potentially both intra-institutional and inter-institutional.
Note
An FSC conforming to the Basic 512 Cardiac Angiographic Profile and General Purpose CD-R Profile supporting the SC
Image Media Storage SOP Class could, if the restrictions in this profile were observed, create images that were readable
by an FSR supporting the profile. Conversely, SC Images written by an FSC conforming to this profile, would be readable
by an FSR conforming to the Basic 512 Cardiac Angiographic Profile and the General Purpose CD-R Profile supporting the
SC Image Media Storage SOP Class.
The Application Entity shall support one or more of the roles of File-set Creator, File-set Reader, and File-set Updater, defined in
PS3.10.
- Standard -
Page 38 DICOM PS3.11 2019c - Media Storage Application Profiles
An FSC shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc). An
FSC may allow packet-writing if supported by the media and file system specified in the profile.
Note
A multiple volume (a logical volume that can cross multiple physical media) is not supported by this Application Profile Class.
If a set of Files, e.g., a Study, cannot be written entirely on one piece of media, the FSC will create multiple independent
DICOM File-sets such that each File-set can reside on a single piece of media controlled by its individual DICOMDIR file.
The user of the FSC can opt to use written labels on the discs to reflect that there is more than one disc for this set of files
(e.g., a Study).
An FSU shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc).
Note
If the disc has not been finalized, the File-set Updater will be able to update information assuming there is enough space on
the disc to write a new DICOMDIR file, the information, and the fundamental volume control structures. Volume control
structures are the structures that are inherent to the standards of the physical volume; see PS3.12
SOP Classes and corresponding Transfer Syntaxes supported by this Application Profile are specified in Table B.3-1.
1.2.840.10008.1.2.1
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 39
Information Object SOP Class UID Transfer Syntax and UID FSC FSR FSU
Definition Requirement Requirement Requirement
(see Note 1)
X-Ray Angiographic 1.2.840.10008.5.1.4.1.1.12.1 JPEG Lossless Process 14 Mandatory Mandatory Optional
Image (selection value 1)
1.2.840.10008.1.2.4.70
X-Ray Angiographic 1.2.840.10008.5.1.4.1.1.12.1 JPEG Lossy, Baseline Optional for Mandatory for Undefined for
Image Sequential with Huffman DVD; DVD; DVD;
Coding (Process 1) Disallowed for Disallowed for Disallowed for
CD CD CD
1.2.840.10008.1.2.4.50
X-Ray Angiographic 1.2.840.10008.5.1.4.1.1.12.1 JPEG Extended (Process 2 & Optional for Mandatory for Undefined for
Image 4): DVD; DVD; DVD;
Disallowed for Disallowed for Disallowed for
Default Transfer Syntax for CD CD CD
Lossy JPEG 12 Bit Image
Compression (Process 4 only)
1.2.840.10008.1.2.4.51
Secondary Capture 1.2.840.10008.5.1.4.1.1.7 Explicit VR Little Endian Optional Mandatory Optional
Image Storage Uncompressed
1.2.840.10008.1.2.1
Grayscale Softcopy 1.2.840.10008.5.1.4.1.1.11.1 Explicit VR Little Endian Optional Optional Optional
Presentation State Uncompressed
Storage
1.2.840.10008.1.2.1
Note
2. The Standalone Overlay, Standalone Curve and Detached Patient management SOP Classes were formerly defined
in these profiles, but have been retired. The Grayscale Softcopy Presentation State Storage SOP Class has been added
as the preferred mechanism for conveying annotations.
The 1024 X-Ray Angiographic Application DVD profile STD-XA1K-DVD requires any of the 120 mm DVD media other than DVD-RAM
as defined in PS3.12.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
- Standard -
Page 40 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
1. It is recommended that the Icon Images be encoding using VR OB encoding. The use of OW, allowed by the STD-
XABC-CD Basic Cardiac profile defined in Annex A, is deprecated, and may be retired in future editions of the Standard.
2. This icon size is larger than that recommended in PS3.10 because the 64x64 icon would not be clinically useful for
identifying and selecting X-Ray angiographic images.
3. For multi-frame images, it is recommended that the icon image be derived from the frame identified in the Representative
Frame Number attribute (0028,6010), if defined for the image SOP Instance. If the Representative Frame Number is
not present, a frame approximately one-third of the way through the multi-frame image should be selected. The process
to reduce any image to a 128x128 image is beyond the scope of this Standard.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 41
Note
1. An FSC or FSU, when creating or updating a File-set, Rows or Columns will not exceed a value of 1024. When reading
a File-set, an FSR or FSU will accept all values of up to 1024 for Rows or Columns.
2. Photometric Interpretation, Pixel Representation, High Bit, Bits Allocated and Samples per Pixel are defined in the XA
IOD.
The attributes listed in Table B.3-4 used within the Secondary Capture Image files have the specified values.
Note
1. An FSC or FSU, when creating or updating a File-set, Rows or Columns will not exceed a value of 1024. When reading
a File-set, an FSR or FSU will accept all values of up to 1024 for Rows or Columns.
2. It is recommend that Referenced Image Sequence (0008,1140) be present if the SC Image is significantly related to XA
images and frames stored on the same media, and if present, it should contain references to those images and frames.
Overlay Group 60XX shall not be present in Secondary Capture Images, and Standalone Overlays shall not be referenced by or to
Secondary Capture Images used in this profile.
- Standard -
Page 42 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 43
The prefix for this class of application profiles is identified with the STD-US identifier.
Note
Conformance Statements may use the earlier prefix of APL that is equivalent to STD. This use is deprecated and may be
retired in future editions of the Standard.
The midsection is broken down into three subclasses that describe the clinical use of the data. These subclasses are: Image Display
(ID identifier), Spatial Calibration (SC identifier), and Combined Calibration (CC identifier). All three subclasses can be applied to
either single frames (SF) images or single and multi-frames (MF) images. The SC subclass enhances the ID class by adding the re-
quirement for region specific spatial calibration data with each IOD. The CC subclass enhances the SC subclass by requiring region
specific pixel component calibration.
The suffix, xxxx, is used to describe the actual media choice used for the conformance claim. Any of the above mentioned classes
can be stored onto one of eight pieces of media described in the Table C.3-3.
The ID Application Profile Classes are intended to be used for the transfer of ultrasound images for display purposes.
The SC Application Profile Classes are intended to be used for the transfer of ultrasound images with spatial calibration data for
quantitative purposes (see Section C.4).
The CC Application Profile Classes are intended to be used for the transfer of ultrasound images with spatial and pixel component
calibration data for more advanced quantitative purposes (see Section C.5).
- Standard -
Page 44 DICOM PS3.11 2019c - Media Storage Application Profiles
C.2.1 Roles
An FSC shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc) or
to allow packet-writing, if supported by the media and file system specified in the profile.
An FSU shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc) or
to allow packet-writing, if supported by the media and file system specified in the profile.
The FSU role is not defined for the STD-US-xx-xx-DVD profiles (i.e., for DVD media that is not DVD-RAM).
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 45
the three possible transfer Syntaxes to create an IOD. In the role of FS-Reader an application shall support all transfer Syntaxes
defined for the STD-US application profile.
In the role of FS-Updater or FS-Creator the application can choose any of the supported Photometric Interpretations described in
PS3.3 US Image Module to create an IOD. In the role of FS-Reader, an application shall support all Photometric Interpretations described
in PS3.3 US Image Module.
Table C.3-2 describes restrictions on the use of various Transfer Syntaxes with the supported Photometric Interpretations for both
single and multi-frame images.
- Standard -
Page 46 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
Media Classes FLOP, MOD128, MOD230, MOD540, MOD640, MOD650, MOD12 AND MOD23 were previously defined
but have been retired. See PS3.11 2004.
C.3.3 DICOMDIR
The Directory shall include Directory Records of PATIENT, STUDY, SERIES, IMAGE corresponding to the information object files in
the File Set. All DICOM files in the File Set incorporating SOP Instances (Information Objects) defined for the specific Application
Profile shall be referenced by Directory Records. At the image level each file contains a single ultrasound image object or a single
ultrasound multi-frame image object as defined in PS3.3 of the Standard.
Note
For all media selected in this Application Profile Class, STD-US, the following applies as defined in PS3.12.
All implementations should include the DICOM Media Storage Directory in the DICOMDIR file. There should only be one DICOMDIR
file on a single media. The DICOMDIR file should be found in the root directory of the media. For the case of double-sided MOD
media, there shall be a DICOMDIR on each side of the media.
On a single media the patient ID key at the patient level shall be unique for each patient directory record.
File Component IDs should be created using a random number filename to minimize File Component ID collisions as described
in PS3.12. The FS-Updater should check the existence of a Component ID prior to creating that ID. Should an ID collision
occur, the FS-Updater should try another ID.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 47
A detailed list of the Media Storage SOP Classes that may be supported is defined in PS3.4.
The identifier for this General Purpose Image Exchange profile class shall be STD-GEN.
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
This Application Profile facilitates the creation of a multi-modality medium for image interchange, useful for clinical, patient record,
teaching and research applications, within and between institutions.
This profile is intended only for general purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context. The latter may support compression Transfer Syntaxes, limitations on the form and
content of SOP Class instances, and specific media choices that preclude the use of the General Purpose Interchange Profile.
- Standard -
Page 48 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
The creation of a CD, DVD-RAM or BD is considerably more complex than the reading thereof. Therefore the clinical context
for this Application profile is likely to be asymmetric, with a sophisticated File Set Creator and relatively simple File Set
Readers.
The Application Entity shall support one or more of the roles of File Set Creator (FSC), File Set Reader (FSR), and File Set Updater
(FSU), defined in PS3.10.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-GEN Application Profile.
FSC shall offer the ability to either finalize the physical volume at the completion of the most recent write session (no additional inform-
ation can be subsequently added to the volume) or to allow multi-session (additional information may be subsequently added to the
volume) or to allow packet-writing, if supported by the media and file system specified in the profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media), the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using the defined Transfer Syntax.
File Set Updaters shall be able to generate one or more of the SOP Instances defined for this Application Profile, for which a Conform-
ance Statement is made, and to read and update the DICOMDIR file.
FSU shall offer the ability to either finalize the physical volume at the completion of the most recent write session (no additional inform-
ation can be subsequently added to the volume) or to allow multi-session (additional information may be subsequently added to the
volume) or to allow packet-writing. if supported by the media and file system specified in the profile.
Note
If the volume has not been finalized, the File Set Updater will be able to update information assuming there is enough space
on the volume to write a new DICOMDIR file, the information, and the fundamental volume control structures. Volume control
structures are the structures that are inherent to the standards of the physical volume, see PS3.12.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 49
1.2.840.10008.1.2.1
Composite Image & See PS3.4 Explicit VR Little Endian Defined in Defined in Optional
Stand-alone Storage Uncompressed Conformance Conformance
Statement Statement
1.2.840.10008.1.2.1
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table D.3-1. The
supported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
The STD-GEN-DVD-RAM and STD-GEN-SEC-DVD-RAM application profiles require the 120 mm DVD-RAM medium, as defined in
PS3.12.
The STD-GEN-BD and STD-GEN-SEC-BD application profiles require any of the 120 mm BD media, as defined in PS3.12.
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Table D.3-2 specifies the additional associated keys. At each directory record level other additional data elements can be added, but
it is not required that File Set Readers be able to use them as keys. Refer to the Basic Directory IOD in PS3.3.
- Standard -
Page 50 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
The requirements with respect to the mandatory DICOMDIR keys in PS3.3 imply that either these attributes are present in
the Image IOD, or they are in some other way supplied by the File-set Creator. These attributes are (0010,0020) Patient ID,
(0008,0020) Study Date, (0008,0030) Study Time, (0020,0010) Study ID, (0020,0011) Series Number, and (0020,0013) In-
stance Number.
Note
The retired Detached Patient Management SOP Class was previously suggested to allow patient identification and demo-
graphic information to be updated without changing the composite Image IOD files. This usage is now retired.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure Integrity or carry the same originators' signatures.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 51
Note
Media Profiles STD-CTMR-MOD650, STD-CTMR-MOD12 and STD-CTMR-MOD23 were previously defined but have been
retired. See PS3.11 2004.
Typical interchanges would be between acquisition devices, archives and workstations, within and between institutions.
The Application Entity shall support one or more of the roles of File-set Creator, File-set Reader, and File-set Updater, defined in
PS3.10.
An FSC shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc) or
to allow packet-writing, if supported by the media and file system specified in the profile.
- Standard -
Page 52 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
A multiple volume (a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume, the FSC will create multiple inde-
pendent DICOM File-sets such that each File-set can reside on a single physical volume controlled by its individual
DICOMDIR file. The user of the FSC can opt to use written labels on the physical volumes to indicate that there is more than
one physical volume for this set of files (e.g., a study).
An FSU shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc) or
to allow packet-writing if supported by the media and file system specified in the profile.
Note
If the volume has not been finalized, the File Set Updater will be able to update information assuming there is enough space
on the volume to write a new DICOMDIR file, the information, and the fundamental volume control structures. Volume control
structures are the structures that are inherent to the standards of the physical volume, see PS3.12.
SOP Classes and corresponding Transfer Syntaxes supported by these Application Profiles are specified in the Table E.3-1.
1.2.840.10008.1.2.1
CT Image 1.2.840.10008.5.1.4.1.1.2 JPEG Lossless Process 14 Optional Mandatory Optional
(selection value 1)
1.2.840.10008.1.2.4.70
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 53
Information Object SOP Class UID Transfer Syntax and UID FSC FSR FSU
Definition Requirement Requirement Requirement
(see Note 1)
CT Image 1.2.840.10008.5.1.4.1.1.2 Explicit VR Little Endian Optional Mandatory Optional
Uncompressed
1.2.840.10008.1.2.1
MR Image 1.2.840.10008.5.1.4.1.1.4 JPEG Lossless Process 14 Optional Mandatory Optional
(selection value 1)
1.2.840.10008.1.2.4.70
MR Image 1.2.840.10008.5.1.4.1.1.4 Explicit VR Little Endian Optional Mandatory Optional
Uncompressed
1.2.840.10008.1.2.1
SC Image 1.2.840.10008.5.1.4.1.1.7 JPEG Lossless Process 14 Optional Mandatory Optional
(grayscale) (selection value 1)
1.2.840.10008.1.2.4.70
SC Image 1.2.840.10008.5.1.4.1.1.7 Explicit VR Little Endian Optional Mandatory Optional
(grayscale) Uncompressed
1.2.840.10008.1.2.1
SC Image(palette 1.2.840.10008.5.1.4.1.1.7 JPEG Lossless Process 14 Optional Optional Optional
color) (selection value 1)
1.2.840.10008.1.2.4.70
SC Image(palette 1.2.840.10008.5.1.4.1.1.7 Explicit VR Little Endian Optional Optional Optional
color) Uncompressed
1.2.840.10008.1.2.1
Grayscale Softcopy 1.2.840.10008.5.1.4.1.1.11.1 Explicit VR Little Endian Optional Optional Optional
Presentation State Uncompressed
1.2.840.10008.1.2.1
X-Ray Radiation 1.2.840.10008.5.1.4.1.1.88.67 Explicit VR Little Endian Optional Optional Optional
Dose SR Uncompressed
1.2.840.10008.1.2.1
Note
2. The Detached Patient management SOP Class was formerly defined in these profiles, but has been retired.
The STD-CTMR-CD application profile requires the 120 mm CD-R physical medium with the ISO 9660 Media Format, as defined in
PS3.12.
The STD-CTMR-DVD-RAM application profile requires the 120 mm DVD-RAM medium, as defined in PS3.12.
The STD-CTMR-DVD application profile requires any of the 120 mm DVD media other than DVD-RAM, as defined in PS3.12.
- Standard -
Page 54 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
Note
The Frame of Reference module is specified in PS3.3 as mandatory for the CT and MR composite information objects, but
not for Secondary Capture objects.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 55
Note
1. The Basic Directory Information Object definition in PS3.3 defines the following attributes as Type 1 or 2: for PATIENT
directory records: (0010,0010) Patient's Name; for STUDY directory records: (0008,0050) Accession Number, (0008,0020)
Study Date, (0008,1030) Study Description; for SERIES directory records: (0008,0060) Modality. Hence these are not
redefined here.
2. The Basic Directory Information Object definition in PS3.3 allows for the optional inclusion of Icon Images at the IMAGE
or SERIES level. These remain optional for this profile, and the choice of whether or not to include Icon Images for every
image or series, or in a more selective manner, is left up to the implementer. E.3.3.3 describes restrictions that apply
to Icon Images that are included in this profile.
Note
The definition of the MR Composite Image Object in PS3.3 does not restrict (0028,0101) Bits Stored or (0028,0102) High
Bit.
Table E.3-5. STD-CTMR Required Image Attribute Values for Grayscale SC Images
Attribute Tag Value
Samples Per Pixel (0028,0002) 1
Photometric Interpretation (0028,0004) MONOCHROME2
Bits Allocated (0028,0100) 8 or 16
Bits Stored (0028,0101) Bits Allocated (0028,0100)
High Bit (0028,0102) Bits Stored (0028,0101) - 1
- Standard -
Page 56 DICOM PS3.11 2019c - Media Storage Application Profiles
Table E.3-6. STD-CTMR Required Image Attribute Values for Color SC Images
Attribute Tag Value
Samples Per Pixel (0028,0002) 1
Photometric Interpretation (0028,0004) PALETTE COLOR
Bits Allocated (0028,0100) 8
Bits Stored (0028,0101) 8
High Bit (0028,0102) 7
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 57
- Standard -
Page 58 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 59
Note
This Media Storage Application Profile Class is not intended to replace the more robust DICOM Storage Service Class.
Objects from multiple modalities may be included on the same e-mail. A detailed list of the Media Storage SOP Classes that may be
supported is defined in PS3.4.
The identifier for this General Purpose MIME Interchange profile shall be STD-GEN-MIME.
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
This profile is intended only for general purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context.
Note
The present Application Profile does not include any specific mechanism regarding privacy. However it is highly recommended
to use secure mechanisms (e.g., S/MIME) when using STD-GEN-MIME Application Profile over networks that are not otherwise
secured.
The Application Entity shall support one or two of the roles of File Set Creator (FSC) and File Set Reader (FSR), defined in PS3.10.
Because the exchange of e-mail does not involve storage, the role of File Set Updater (FSU) is not specified.
- Standard -
Page 60 DICOM PS3.11 2019c - Media Storage Application Profiles
File Set Creators may be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes included in the File Set.
The Application Entity acting as a File Set Creator generates a File Set under the STD-GEN-MIME Application Profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple media) is not supported by this class of Application profile.
Because MIME is a virtual medium and since e-mail mechanisms include some way of fragmenting MIME parts to be sent
through limited size e-mail, there are no needs for multiple volume.
File Set Readers may be able to read the DICOMDIR directory file and shall be able to read all the SOP Instance files defined for this
Application Profile, using the Transfer Syntaxes specified in the Conformance Statement.
1.2.840.10008.1.2.1
Composite Image & See PS3.4 Defined in Conformance Defined in Defined in
Stand-alone Storage Statement Conformance Conformance
Statement Statement
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table G.3-1. The
supported Storage SOP Class(es) and Transfers Syntax(es) shall be listed in the Conformance Statement using a table of the same
form.
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
1. DICOMDIRs with no directory information are not allowed by this Application Profile.
2. In the DICOMDIR each object may be referenced by a referenced file ID (e.g., 000/000) that contains multiple values
corresponding to a path for physical system, since the MIME organization is flat. There is no requirement that this path
will be used by the receiving application to create file hierarchy.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 61
There may only be one DICOMDIR file per File Set. The Patient ID at the patient level shall be unique for each patient directory record
in one File Set.
- Standard -
Page 62 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 63
A detailed list of the Media Storage SOP Classes that may be supported is defined in PS3.4.
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
This Application Profile Class facilitates the creation of a multi-modality medium for image interchange, useful for clinical, patient record,
teaching and research applications, within and between institutions.
This profile is intended only for general purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context.
Note
The creation of a DVD is considerably more complex than the reading thereof. Therefore the clinical context for this Applic-
ation profile is likely to be asymmetric, with a sophisticated File Set Creator and relatively simple File Set Readers.
- Standard -
Page 64 DICOM PS3.11 2019c - Media Storage Application Profiles
The Application Entity shall support one or more of the roles of File Set Creator (FSC) or File Set Reader (FSR), defined in PS3.10.
The File Set Updater (FSU) role is not defined.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-GEN-DVD or STD-GEN-SEC-DVD Application Profile.
FSC shall offer the ability to either finalize the physical volume at the completion of the most recent write session (no additional inform-
ation can be subsequently added to the volume) or to allow multi-session (additional information may be subsequently added to the
volume). An FSC may allow packet-writing, if supported by the media and file system specified in the profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media), the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using all the defined Transfer Syntaxes for the Profile.
Note
All Transfer Syntaxes defined in the profile must be supported by the FSR. It is not permissible to only support one or other
of the uncompressed or the compressed Transfer Syntaxes.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 65
Table H.3-1. STD-GEN-DVD and STD-GEN-SEC-DVD SOP Classes and Transfer Syntaxes
Information Object SOP Class UID Transfer Syntax and UID FSC Requirement FSR Requirement
Definition
Basic Directory 1.2.840.10008.1.3.10 Explicit VR Little Endian Mandatory Mandatory
Uncompressed
1.2.840.10008.1.2.1
Composite IODs for which a See PS3.4 Explicit VR Little Endian Defined in Mandatory for all SOP
Media Storage SOP Class Uncompressed Conformance Classes defined in
is defined in PS3.4 Statement Conformance Statement
1.2.840.10008.1.2.1
Composite IODs for which a See PS3.4 JPEG Lossless Process 14 Defined in Mandatory for -JPEG profiles
Media Storage SOP Class (selection value 1) Conformance for all SOP Classes defined
is defined in PS3.4 Statement in Conformance Statement
1.2.840.10008.1.2.4.70
Composite IODs for which a See PS3.4 JPEG Lossy, Baseline Defined in Mandatory for -JPEG profiles
Media Storage SOP Class Sequential with Huffman Conformance for all SOP Classes defined
is defined in PS3.4 Coding (Process 1) Statement in Conformance Statement
1.2.840.10008.1.2.4.50
Composite IODs for which a See PS3.4 JPEG Extended (Process 2 & Defined in Mandatory for -JPEG profiles
Media Storage SOP Class 4): Conformance for all SOP Classes defined
is defined in PS3.4 Statement in Conformance Statement
Default Transfer Syntax for
Lossy JPEG 12 Bit Image
Compression (Process 4 only)
1.2.840.10008.1.2.4.51
Composite IODs for which a See PS3.4 JPEG 2000 Image Defined in Mandatory for -J2K profiles
Media Storage SOP Class Compression (Lossless Only) Conformance for all SOP Classes defined
is defined in PS3.4 Statement in Conformance Statement
1.2.840.10008.1.2.4.90
Composite IODs for which a See PS3.4 JPEG 2000 Image Defined in Mandatory for -J2K profiles
Media Storage SOP Class Compression Conformance for all SOP Classes defined
is defined in PS3.4 Statement in Conformance Statement
1.2.840.10008.1.2.4.91
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table H.3-1. The
supported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
- Standard -
Page 66 DICOM PS3.11 2019c - Media Storage Application Profiles
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Table H.3-2 specifies the additional associated keys. At each directory record level other additional data elements can be added, but
it is not required that File Set Readers be able to use them as keys. Refer to the Basic Directory IOD in PS3.3.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 67
Note
The requirements with respect to the mandatory DICOMDIR keys in PS3.3 imply that either these attributes are present in
the Image IOD, or they are in some other way supplied by the File-set Creator. These attributes are (0010,0020) Patient ID,
(0008,0020) Study Date, (0008,0030) Study Time, (0020,0010) Study ID, (0020,0011) Series Number, and (0020,0013) In-
stance Number.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure Integrity or carry the same originators' signatures.
- Standard -
Page 68 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 69
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
The Application Entity shall support one or more of the roles of File Set Creator (FSC) or File Set Reader (FSR), defined in PS3.10.
The File Set Updater (FSU) role is not defined.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-DVD-MPEG2-MPML or STD-DVD-SEC-MPEG2-MPML Application Profile.
FSC shall offer the ability to either finalize the physical volume at the completion of the most recent write session (no additional inform-
ation can be subsequently added to the volume) or to allow multi-session (additional information may be subsequently added to the
volume). An FSC may allow packet-writing, if supported by the media and file system specified in the profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media), the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
- Standard -
Page 70 DICOM PS3.11 2019c - Media Storage Application Profiles
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using all the defined Transfer Syntaxes for the Profile.
1.2.840.10008.1.2.1
Multi-frame Composite IODs See PS3.4 MPEG2 MP@ML Image Defined in Mandatory for all SOP
for which a Media Storage Compression Conformance Classes defined in
SOP Class is defined in Statement Conformance Statement
PS3.4 1.2.840.10008.1.2.4.100
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table I.3-1. The sup-
ported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 71
Table I.3-2 specifies the additional associated keys. At each directory record level other additional data elements can be added, but
it is not required that File Set Readers be able to use them as keys. Refer to the Basic Directory IOD in PS3.3.
Note
The requirements with respect to the mandatory DICOMDIR keys in PS3.3 imply that either these attributes are present in
the Image IOD, or they are in some other way supplied by the File-set Creator. These attributes are (0010,0020) Patient ID,
(0008,0020) Study Date, (0008,0030) Study Time, (0020,0010) Study ID, (0020,0011) Series Number, and (0020,0013) In-
stance Number.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure Integrity or carry the same originators' signatures.
This profile does not require this, nor specify which approach to take. Specifically, this profile does not require that a DVD Video file
and folder structure be present, though it is recommended.
- Standard -
Page 72 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 73
A detailed list of the Media Storage SOP Classes that may be supported is defined in PS3.4.
- Standard -
Page 74 DICOM PS3.11 2019c - Media Storage Application Profiles
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
This Application Profile Class facilitates the creation of a multi-modality medium for image interchange, useful for clinical, patient record,
teaching and research applications, within and between institutions.
This profile is intended only for general-purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 75
The Application Entity shall support one or more of the roles of File Set Creator (FSC) or File Set Reader (FSR), or File Set Updater
(FSU) defined in PS3.10.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-GEN-USB, STD-GEN-SEC-USB STD-GEN-MMC, STD-GEN-SEC-MMC, STD-GEN-CF, STD-GEN-SEC-CF, STD-GEN-SD
or STD-GEN-SEC-SD Application Profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media), the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using all the defined Transfer Syntaxes for the Profile.
Note
All Transfer Syntaxes defined in the profile must be supported by the FSR. It is not permissible to only support one or other
of the uncompressed or the compressed Transfer Syntaxes.
File Set Updaters shall be able to generate one or more of the SOP Instances defined for this Application Profile, for which a Conform-
ance Statement is made, and to read and update the DICOMDIR file.
- Standard -
Page 76 DICOM PS3.11 2019c - Media Storage Application Profiles
1.2.840.10008.1.2.1
Composite IODs for See PS3.4 Explicit VR Little Endian Defined in Mandatory for all SOP Defined in
which a Media Storage Uncompressed Conformance Classes defined in Conformance
SOP Class is defined in Statement Conformance Statement Statement
PS3.4 1.2.840.10008.1.2.1
Composite IODs for See PS3.4 JPEG Lossless Process Defined in Mandatory for JPEG Defined in
which a Media Storage 14 (selection value 1) Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 1.2.840.10008.1.2.4.70 Conformance Statement
Composite IODs for See PS3.4 JPEG Lossy, Baseline Defined in Mandatory for JPEG Defined in
which a Media Storage Sequential with Huffman Conformance profiles for all SOP Conformance
SOP Class is defined in Coding (Process 1) Statement Classes defined in Statement
PS3.4 Conformance Statement
1.2.840.10008.1.2.4.50
Composite IODs for See PS3.4 JPEG Extended (Process Defined in Mandatory for JPEG Defined in
which a Media Storage 2 & 4): Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 Default Transfer Syntax Conformance Statement
for Lossy JPEG 12 Bit
Image Compression
(Process 4 only)
1.2.840.10008.1.2.4.51
Composite IODs for See PS3.4 JPEG 2000 Image Defined in Mandatory for J2K Defined in
which a Media Storage Compression (Lossless Conformance profiles for all SOP Conformance
SOP Class is defined in Only) Statement Classes defined in Statement
PS3.4 Conformance Statement
1.2.840.10008.1.2.4.90
Composite IODs for See PS3.4 JPEG 2000 Image Defined in Mandatory for J2K Defined in
which a Media Storage Compression Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 1.2.840.10008.1.2.4.91 Conformance Statement
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table J.3-1. The
supported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
The STD-GEN-CF-JPEG, STD- GEN-SEC-CF-JPEG, STD-GEN-CF-J2K and STD-GEN-SEC-CF-J2K application profiles require
any of the CompactFlash Removable Devices, as defined in PS3.12.
The STD-GEN-SD-JPEG, STD-GEN-SEC-SD-JPEG, STD-GEN-SD-J2K and STD-GEN-SEC-SD-J2K application profiles require any
of the Secure Digital Card Removable Devices, as defined in PS3.12.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 77
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Table H.3-2 specifies the additional associated keys that shall also be applicable to the profiles defined in this Annex. At each directory
record level other additional data elements can be added, but it is not required that File Set Readers be able to use them as keys.
Refer to the Basic Directory IOD in PS3.3.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure Integrity or carry the same originators' signatures.
- Standard -
Page 78 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 79
Hospital or Physician
Removable Media
Removable Media
K.2.1 Roles
- Standard -
Page 80 DICOM PS3.11 2019c - Media Storage Application Profiles
An FSC shall offer the ability to either finalize the disc at the completion of the most recent write session (no additional information
can be subsequently added to the disc) or to allow multi-session (additional information may be subsequently added to the disc).
Note
A multiple volume (a logical volume that can cross multiple physical media) is not supported by this Application Profile Class.
If a set of Files, e.g., a Study, cannot be written entirely on one CD-R, the FSC will create multiple independent DICOM File-
sets such that each File-set can reside on a single CD-R media controlled by its individual DICOMDIR file. The user of the
FSC can opt to use written labels on the discs to indicate that there is more than one disc for this set of files (e.g., a study).
1.2.840.10008.1.2.1
Digital Intra-oral X-Ray Image 1.2.840.10008.5.1.4.1.1.1.3 Explicit VR Little Endian Optional Mandatory
Storage - For Presentation Uncompressed
1.2.840.10008.1.2.1
Digital X-Ray Image Storage 1.2.840.10008.5.1.4.1.1.1.1 Explicit VR Little Endian Optional Mandatory
- For Presentation Uncompressed
1.2.840.10008.1.2.1
Basic Structured Display 1.2.840.10008.5.1.4.1.1.131 Explicit VR Little Endian Optional Optional
Storage Uncompressed
1.2.840.10008.1.2.1
Grayscale Softcopy 1.2.840.10008.5.1.4.1.1.11.1 Explicit VR Little Endian Optional Optional
Presentation State Uncompressed
1.2.840.10008.1.2.1
Note
The Digital X-Ray Image Storage and Digital Intra-oral X-Ray Image Storage For Presentation SOP Classes can also be
used for scanned film.
A File Set Creator (FSC) shall support at least one of the specified image storage SOP Classes.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 81
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Note
These Type 3 attributes of the General Equipment and DX Detector Module are specialized in order to encourage FSCs to
include values for them, recognizing that there are situations in which values may be unknown.
- Standard -
Page 82 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 83
Two Application Profiles support all defined Media Storage SOP Classes. These are intended to be used for the interchange of
Composite SOP Instances via email for general purpose applications. Objects from multiple modalities may be included on the same
email. The email may also include non-DICOM objects. One of these general profiles supports encryption of the email.
The other application profile is specialized for dental applications and adds mandatory requirements for dental images to the general
secure email profile.
The STD-GEN-ZIP-MAIL and STD-GEN-SEC-ZIP-MAIL profiles are intended for general purpose applications. They are not intended
as a replacement for specific Application Profiles that may be defined for a particular clinical context. The STD-DTL-SEC-ZIP-MAIL
profile is intended for the clinical context of the exchange of dental radiographs.
Note
It is possible to use email transport without using the encrypted secure profile. This would make sense for mailing DICOM
objects that do not need protection.
L.2.1 Roles
- Standard -
Page 84 DICOM PS3.11 2019c - Media Storage Application Profiles
Table L.3-1. STD-GEN-ZIP-MAIL and STD-GEN-SEC-ZIP-MAIL SOP Classes and Transfer Syntaxes
Information Object SOP Class UID Transfer Syntax and UID FSC Requirement FSR Requirement
Definition
Basic Directory 1.2.840.10008.1.3.10 Explicit VR Little Endian Mandatory Mandatory
Uncompressed
1.2.840.10008.1.2.1
Composite Image & See PS3.4 Defined in Conformance Defined in Defined in
Stand-alone Storage Statement Conformance Conformance
Statement Statement
Equipment claiming conformance to these Application Profiles shall list the subset of Media Storage SOP Classes and Transfer
Syntaxes that it supports in its Conformance Statement.
Note
An additional content type, file extension and file name may be defined by the Standard in the future to accommodate a
DICOM specific zip file.
Note
DICOMDIRs with no directory information are not allowed by these Application Profiles.
There may only be one DICOMDIR file per File Set. The Patient ID at the patient level shall be unique for each patient directory record
in one File Set.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 85
1.2.840.10008.1.2.1
Digital Intra-oral X-Ray Image 1.2.840.10008.5.1.4.1.1.1.3 Explicit VR Little Endian Optional Mandatory
Storage - For Presentation Uncompressed
1.2.840.10008.1.2.1
Digital X-Ray Image Storage 1.2.840.10008.5.1.4.1.1.1.1 Explicit VR Little Endian Optional Mandatory
- For Presentation Uncompressed
1.2.840.10008.1.2.1
Note
An additional content type, file extension and file name may be defined by the Standard in the future to accommodate a
DICOM specific zip file.
- Standard -
Page 86 DICOM PS3.11 2019c - Media Storage Application Profiles
Note
DICOMDIRs with no directory information are not allowed by these Application Profiles.
There may only be one DICOMDIR file per File Set. The Patient ID at the patient level shall be unique for each patient directory record
in one File Set.
The Attributes listed in Table L.4-2 shall have their Types specialized.
Note
These Type 3 attributes of the General Equipment and DX Detector Module are specialized in order to encourage FSCs to
include values for them, recognizing that there are situations in which values may be unknown.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 87
A detailed list of the Media Storage SOP Classes that may be supported is defined in PS3.4.
- Standard -
Page 88 DICOM PS3.11 2019c - Media Storage Application Profiles
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
This Application Profile Class facilitates the creation of a multi-modality medium for image interchange, useful for clinical, patient record,
teaching and research applications, within and between institutions.
This profile is intended only for general-purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context.
Note
1. The creation of a BD is considerably more complex than the reading thereof. Therefore the clinical context for this Ap-
plication profile is likely to be asymmetric, with a sophisticated File Set Creator and relatively simple File Set Readers.
2. Each BD Rewritable/Recordable contains a unique ID, which can be read by a BD drive. This ID can be used for referring
to a BD, for example in a database.
The Application Entity shall support one or more of the roles of File Set Creator (FSC) or File Set Reader (FSR), or File Set Updater
(FSU) defined in PS3.10.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-GEN-BD or STD-GEN-SEC-BD Application Profile.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 89
An FSC shall offer the ability to finalize the physical volume at the completion of the most recent write session (no additional information
can be subsequently added to the volume), if supported by the media and file system specified in the profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media), the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using all the defined Transfer Syntaxes for the Profile.
Note
All Transfer Syntaxes defined in the profile must be supported by the FSR. It is not permissible to only support one or other
of the uncompressed or the compressed Transfer Syntaxes.
File Set Updaters shall be able to generate one or more of the SOP Instances defined for this Application Profile, for which a Conform-
ance Statement is made, and to read and update the DICOMDIR file.
An FSU shall offer the ability to finalize the physical volume at the completion of the most recent write session (no additional information
can be subsequently added to the volume), if supported by the media and file system specified in the profile.
Note
If the volume has not been finalized, the File Set Updater will be able to update information assuming there is enough space
on the volume to write a new DICOMDIR file, the information, and the fundamental volume control structures. Volume control
structures are the structures that are inherent to the standards of the physical volume, see PS3.12.
Table M.3-1. STD-GEN-BD and STD-GEN-SEC-BD SOP Classes and Transfer Syntaxes
Information Object SOP Class UID Transfer Syntax and FSC FSR Requirement FSU
Definition UID Requirement Requirement
Basic Directory 1.2.840.10008.1.3.10 Explicit VR Little Endian Mandatory Mandatory Mandatory
Uncompressed
1.2.840.10008.1.2.1
- Standard -
Page 90 DICOM PS3.11 2019c - Media Storage Application Profiles
Information Object SOP Class UID Transfer Syntax and FSC FSR Requirement FSU
Definition UID Requirement Requirement
Composite IODs for See PS3.4 Explicit VR Little Endian Defined in Mandatory for all SOP Defined in
which a Media Storage Uncompressed Conformance Classes defined in Conformance
SOP Class is defined in Statement Conformance Statement
PS3.4 1.2.840.10008.1.2.1 Statement
Composite IODs for See PS3.4 JPEG Lossless Process Defined in Mandatory for JPEG Defined in
which a Media Storage 14 (selection value 1) Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 1.2.840.10008.1.2.4.70 Conformance
Statement
Composite IODs for See PS3.4 JPEG Lossy, Baseline Defined in Mandatory for JPEG Defined in
which a Media Storage Sequential with Huffman Conformance profiles for all SOP Conformance
SOP Class is defined in Coding (Process 1) Statement Classes defined in Statement
PS3.4 Conformance
1.2.840.10008.1.2.4.50 Statement
Composite IODs for See PS3.4 JPEG Extended (Process Defined in Mandatory for JPEG Defined in
which a Media Storage 2 & 4): Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 Default Transfer Syntax Conformance
for Lossy JPEG 12 Bit Statement
Image Compression
(Process 4 only)
1.2.840.10008.1.2.4.51
Composite IODs for See PS3.4 JPEG 2000 Image Defined in Mandatory for J2K Defined in
which a Media Storage Compression (Lossless Conformance profiles for all SOP Conformance
SOP Class is defined in Only) Statement Classes defined in Statement
PS3.4 Conformance
1.2.840.10008.1.2.4.90 Statement
Composite IODs for See PS3.4 JPEG 2000 Image Defined in Mandatory for J2K Defined in
which a Media Storage Compression Conformance profiles for all SOP Conformance
SOP Class is defined in Statement Classes defined in Statement
PS3.4 1.2.840.10008.1.2.4.91 Conformance
Statement
Multi-frame Composite See PS3.4 MPEG2 Main Profile @ Defined in Mandatory for all SOP Defined in
IODs for which a Media Main Level Conformance Classes defined in Conformance
Storage SOP Class is Statement Conformance Statement
defined in PS3.4 1.2.840.10008.1.2.4.100 Statement
Multi-frame Composite See PS3.4 MPEG2 Main Profile @ Defined in Mandatory for all SOP Defined in
IODs for which a Media High Level Conformance Classes defined in Conformance
Storage SOP Class is Statement Conformance Statement
defined in PS3.4 1.2.840.10008.1.2.4.101 Statement
Multi-frame Composite See PS3.4 MPEG-4 AVC/H.264 Defined in Mandatory for all SOP Defined in
IODs for which a Media High Profile / Level 4.1 Conformance Classes defined in Conformance
Storage SOP Class is Statement Conformance Statement
defined in PS3.4 1.2.840.10008.1.2.4.102 Statement
Multi-frame Composite See PS3.4 MPEG-4 AVC/H.264 Defined in Mandatory for all SOP Defined in
IODs for which a Media BD-compatible High Conformance Classes defined in Conformance
Storage SOP Class is Profile / Level 4.1 Statement Conformance Statement
defined in PS3.4 Statement
1.2.840.10008.1.2.4.103
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table M.3-1. The
supported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 91
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Table H.3-2 specifies the additional associated keys that shall also be applicable to the profiles defined in this Annex. At each directory
record level other additional data elements can be added, but it is not required that File Set Readers be able to use them as keys.
Refer to the Basic Directory IOD in PS3.3.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure integrity or carry the same originators' signatures.
- Standard -
Page 92 DICOM PS3.11 2019c - Media Storage Application Profiles
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 93
A detailed list of the Media Storage SOP Classes that may be supported is defined in PS3.4.
Equipment claiming conformance to this Application Profile shall list the subset of Media Storage SOP Classes that it supports in its
Conformance Statement.
Note
Since it is not required to support all Media Storage Classes the user should carefully consider the subset of supported
Media Storage SOP Classes in the Conformance Statements of such equipment to establish effective object interchange.
- Standard -
Page 94 DICOM PS3.11 2019c - Media Storage Application Profiles
This Application Profile Class facilitates the creation of a multi-modality medium for image interchange, useful for clinical, patient record,
teaching and research applications, within and between institutions.
This profile is intended only for general-purpose applications. It is not intended as a replacement for specific Application Profiles that
may be defined for a particular clinical context.
Note
1. The creation of a BD is considerably more complex than the reading thereof. Therefore the clinical context for this Ap-
plication profile is likely to be asymmetric, with a sophisticated File Set Creator and relatively simple File Set Readers.
2. Each BD Rewritable/Recordable contains a unique ID, which can be read by a BD drive. This ID can be used for referring
to a BD, for example in a database.
The Application Entity shall support one or more of the roles of File Set Creator (FSC) or File Set Reader (FSR) , or File Set Updater
(FSU) defined in PS3.10.
File Set Creators shall be able to generate the Basic Directory SOP Class in the DICOMDIR file with all the subsidiary Directory Records
related to the Image SOP Classes stored in the File Set. The Application Entity acting as a File Set Creator generates a File Set under
a STD-GEN-BD-MPEG4-LV42 or STD-GEN-SEC-BD-MPEG4-LV42 Application Profile.
An FSC shall offer the ability to finalize the physical volume at the completion of the most recent write session (no additional information
can be subsequently added to the volume) , if supported by the media and file system specified in the profile.
Note
A multiple volume (i.e., a logical volume that can cross multiple physical media) is not supported by this class of Application
profile. If a set of Files, e.g., a Study, cannot be written entirely on one physical volume (side of one piece of media) , the
FSC will create multiple independent DICOM File Sets such that each File Set can reside on a single physical volume (side
of a single piece of media) controlled by its individual DICOMDIR file. The user of the FSC can opt to use written labels on
the physical volumes to indicate that there is more than one physical volume for this set of files (e.g., a study).
File Set Readers shall be able to read the DICOMDIR directory file and all the SOP Instance files defined for this Application Profile,
for which a Conformance Statement is made, using all the defined Transfer Syntaxes for the Profile.
Note
All Transfer Syntaxes defined in the profile must be supported by the FSR. It is not permissible to only support one or other
of the uncompressed or the compressed Transfer Syntaxes.
- Standard -
DICOM PS3.11 2019c - Media Storage Application Profiles Page 95
File Set Updaters shall be able to generate one or more of the SOP Instances defined for this Application Profile, for which a Conform-
ance Statement is made, and to read and update the DICOMDIR file.
An FSU shall offer the ability to finalize the physical volume at the completion of the most recent write session (no additional information
can be subsequently added to the volume) , if supported by the media and file system specified in the profile.
Note
If the volume has not been finalized, the File Set Updater will be able to update information assuming there is enough space
on the volume to write a new DICOMDIR file, the information, and the fundamental volume control structures. Volume control
structures are the structures that are inherent to the standards of the physical volume, see PS3.12.
1.2.840.10008.1.2.1
Multi-frame Composite See PS3.4 MPEG-4 AVC/H.264 High Defined in Mandatory for all Defined in
IODs for which a Media Profile / Level 4.2 For 2D Conformance SOP Classes defined Conformance
Storage SOP Class is Video Statement in Conformance Statement
defined in PS3.4 Statement
1.2.840.10008.1.2.4.104
Multi-frame Composite See PS3.4 MPEG-4 AVC/H.264 High Defined in Mandatory for all Defined in
IODs for which a Media Profile / Level 4.2 For 3D Conformance SOP Classes defined Conformance
Storage SOP Class is Video Statement in Conformance Statement
defined in PS3.4 Statement
1.2.840.10008.1.2.4.105
Multi-frame Composite See PS3.4 MPEG-4 AVC/H.264 Defined in Mandatory for all Defined in
IODs for which a Media Stereo High Profile / Level Conformance SOP Classes defined Conformance
Storage SOP Class is 4.2 Statement in Conformance Statement
defined in PS3.4 Statement
1.2.840.10008.1.2.4.106
The SOP Classes and corresponding Transfer Syntax supported by this Application Profile are specified in the Table N.3-1. The
supported Storage SOP Class(es) shall be listed in the Conformance Statement using a table of the same form.
- Standard -
Page 96 DICOM PS3.11 2019c - Media Storage Application Profiles
All DICOM files in the File Set incorporating SOP Instances defined for the specific Application Profile shall be referenced by Directory
Records.
Note
DICOMDIRs with no directory information are not allowed by this Application Profile.
All implementations shall include the DICOM Media Storage Directory in the DICOMDIR file. There shall only be one DICOMDIR file
per File Set. The DICOMDIR file shall be in the root directory of the medium. The Patient ID at the patient level shall be unique for
each patient directory record in one File Set.
Table H.3-2 specifies the additional associated keys that shall also be applicable to the profiles defined in this Annex. At each directory
record level other additional data elements can be added, but it is not required that File Set Readers be able to use them as keys.
Refer to the Basic Directory IOD in PS3.3.
Note
These Application Profiles do not place any consistency restrictions on the use of the Basic DICOM Media Security Profile
with different DICOM Files of one File-set. For example, readers should not assume that all Files in the File-set can be decoded
by the same set of recipients. Readers should also not assume that all secure Files use the same approach (hash key or
digital signature) to ensure integrity or carry the same originators' signatures.
- Standard -