Dicom Part 14 Standard

[Lorrine Hatala]

Theinformation in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

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 certify, 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.

This Part of the DICOM Standard specifies a general model for the storage of Medical Imaging information on removable media. The purpose of this Part is to provide a framework allowing the interchange of various types of medical images and related information on a broad range of physical storage media.

a layered model for the storage of medical images and related information on storage media. This model introduces the concept of Media Storage Application Profiles, which specify application specific subsets of the DICOM Standard to which a Media Storage implementation may claim conformance. Such a conformance applies only to the writing, reading and updating of the content of storage media. Specific Application Profiles are not included in this Part but in PS3.11;

a DICOM File Service providing independence from the underlying media format and physical media. The policies specific to the DICOMDIR file used to store the Media Storage Directory Service/Object Pair Class are also addressed.

PS3.6, Data Dictionary, contains a registry 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.11, Media Storage Application Profiles standardizes a number of choices related to a specific clinical need (selection of a Physical Medium and Media Format as well as specific Service/Object Pair Classes). It aims at facilitating the interoperability between implementations that claim conformance to the same Application Profile. PS3.11 is intended to be extended as the clinical needs for Media Storage Interchange evolve;

PS3.12, Media Formats and Physical Media for Data Interchange, defines a number of selected Physical Medium and corresponding Media Formats. These Media Formats and Physical Medium selections are referenced by one or more of the Application Profiles of PS3.11. 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.

PS3.10 lays a foundation for open Media Interchange by standardizing an overall architecture and addressing some of the major barriers to interoperability: the definition of a DICOM File Format, a DICOM File Service and the policies associated with a Media Storage Directory structure.

PS3.3 specifies a general medical imaging Basic Directory Information Object Definition and PS3.4 specifies the corresponding Media Storage Directory SOP Class that is a member of the Media Storage Service Class.

Adherence to the provisions of PS3.10 by implementations reading, writing or updating Storage Media represents a key foundation for open Storage Media Interchange. However, it is only with the selection of standard Physical Media and corresponding Media Formats in PS3.12 and the use of specific Application Profiles in PS3.11 that effective Media Storage Interchange interoperability is achieved. Therefore, claiming conformance to PS3.10 only, is not a valid DICOM Conformance Statement. DICOM Media Storage Conformance shall be made in relation to a PS3.11 Application Profile according to the framework defined by PS3.2.

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/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

A specification that defines a selection of choices at the various layers of the DICOM Media Storage Model that are applicable to a specific need or context in which the media interchange is intended to be performed.

A minimum abstract view of files and operations to be provided by the Media Format Layer. Constraining access to the content of files by the Application Entities through such a DICOM File Service boundary ensures Media Format and Physical Media independence.

A File is an ordered string of zero or more bytes, where the first byte is at the beginning of the file and the last byte at the end of the File. Files are identified by a unique File ID and may by written, read and/or deleted.

An Application Entity that accesses Files, creates additional Files, or deletes existing Files in a File-set. A File-set Updater makes the appropriate alterations to the DICOMDIR file reflecting the additions or deletions.

A piece of material with recording capabilities for streams of bits. Characteristics of a Physical Media include form factor, mechanical characteristics, recording properties and rules for recording and organizing bit streams in accessible structures

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.

Attributes of File Meta Information are assigned a Type that indicates if a specific Attribute is required depending on the Media Storage Services. The following Type designations are derived from the PS3.5 designations but take into account the Media Storage environment:

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;

Type 2C: Such Attributes shall be present with an explicit Value or with a zero-length if unknown, 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 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.

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.

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:

3a8082e126