DICOM PS3.10 2020a - Media Storage and File Format for Media Interchange |
Page 21 |
4 Symbols and Abbreviations
The following symbols and abbreviations are used in this Part of the Standard.
ACC |
American College of Cardiology |
ACR |
American College of Radiology |
ASCII |
American Standard Code for Information Interchange |
AE |
Application Entity |
ANSI |
American National Standards Institute |
CEN/TC/251 |
Comite Europeen de Normalisation - Technical Committee 251 - Medical Informatics |
DICOM |
Digital Imaging and Communications in Medicine |
FSC |
File-set Creator |
FSR |
File-set Reader |
FSU |
File-set Updater |
HL7 |
Health Level 7 |
HTML |
Hypertext Transfer Markup Language |
IEEE |
Institute of Electrical and Electronics Engineers |
ISO |
International Standards Organization |
ID |
Identifier |
IOD |
Information Object Definition |
JIRA |
Japan Medical Imaging and Radiological Systems Industries Association |
MIME |
Multipurpose Internet Mail Extensions |
NEMA |
National Electrical Manufacturers Association |
OSI |
Open Systems Interconnection |
SOP |
Service-Object Pair |
TCP/IP |
Transmission Control Protocol/Internet Protocol |
UID |
Unique Identifier |
VR |
Value Representation |
XML |
Extensible Markup Language |
- Standard -
Page 22 |
DICOM PS3.10 2020a - Media Storage and File Format for Media Interchange |
- Standard -
DICOM PS3.10 2020a - Media Storage and File Format for Media Interchange |
Page 23 |
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.
A Tag is represented as (gggg,eeee), where gggg equates to the Group Number and eeee equates to the Element Number within that Group. Tags are represented in hexadecimal notation as specified in PS3.5.
AttributesofFileMetaInformationareassignedaTypethatindicatesifaspecificAttributeisrequireddependingontheMediaStorage
Services.ThefollowingTypedesignationsarederivedfromthePS3.5designationsbuttakeintoaccounttheMediaStorageenvironment:
•Type 1: Such Attributes shall be present with an explicit Value in files created by File-set Creators and File-set Updaters. They shall be supported by File-set Readers and File-set Updaters;
•Type 1C: Such Attributes shall be present with an explicit Value in Files created by File-set Creators and File-set Updaters if the specified condition is met. They shall be supported by File-set Readers and File-set Updaters;
•Type 2: Such Attributes shall be present with an explicit Value or with a zero-length Value if unknown, in Files created by File-set Creators and File-set Updaters. They shall be supported by File-set Readers and File-set Updaters;
•Type2C:SuchAttributesshallbepresentwithanexplicitValueorwithazero-lengthifunknown,inFilescreatedbyFile-setCreators and File-set Updaters if the specified condition is met. They shall be supported by File-set Readers and File-set Updaters;
•Type 3: Such Attributes may be present with an explicit Value or a zero-length Value in Files created by File-set Creators and File- set Updaters. They may be supported or ignored by File-set Readers and File-set Updaters.
- Standard -
Page 24 |
DICOM PS3.10 2020a - Media Storage and File Format for Media Interchange |
- Standard -
DICOM PS3.10 2020a - Media Storage and File Format for Media Interchange |
Page 25 |
6 DICOM Models for Media Storage
This section defines the DICOM Media Storage Model used by DICOM Application Entities for the purpose of communication through the interchange of removable storage media. Specifically, this Section provides a model to clarify a number of concepts for digital imaging and communications and introduces key terms used throughout the DICOM Standard. This model has been used to partition the DICOM Standard into separate parts related to storage media interchange.
6.1 General DICOM Communication Model
Figure 5-1 in PS3.1 presents the general communication model of the DICOM Standard, which spans both network (on-line) and media interchange (off-line) communication. Application Entities may utilize any of the following transport mechanisms:
a.the DICOM Message Service and Upper Layer Service, which provides independence from specific physical networking commu- nication support and protocols such as TCP/IP,
b.the DICOM Web Service API and HTTP Service, which allows use of common hypertext and associated protocols for transport of DICOM services, or
c.the Basic DICOM File Service, which provides access to Storage Media independently from specific physical media storage formats and file structures.
PS3.10 describes the Basic DICOM File Service, as depicted in Figure 6.1-1.
Medical Images and related information
DICOM Application Entity
Service Class Specifications
Information Objects Definitions |
|
|
Dataset Structure and Encoding - Data Dictionary |
|
|
Media Interchange |
||
|
BOUNDARY: |
|
DICOM Basic File Service |
||
|
Security Layer |
|
|
(Optional) |
|
MEDIUM A |
MEDIUM B |
MEDIUM n |
Physical Medium |
Physical Medium |
Physical Medium |
and |
and |
and |
Medium Format |
Medium Format |
Medium Format |
Media Storage Interchange |
||
Off-Line Communication |
||
Figure 6.1-1. DICOM Communication Model for Media Interchange
- Standard -