PS3．10−2001翻訳 医療におけるデジタル画像と通信（DICOM） 巻10

PS 3.10-2001 翻訳原稿
ＰＳ３．１０−２００１翻訳
医療におけるデジタル画像と通信（ＤＩＣＯＭ）
巻１０：媒体相互交換のための媒体保存とファイルフォーマット
PS 3.10-2001
Digital Imaging and Communications in Medicine (DICOM)
Part 10: Media Storage and File Format for Media Interchange
Published by
National Electrical Manufacturers Association
1300 N. 17th Street
Rosslyn, Virginia 22209 USA
© Copyright 2001 by the National Electrical Manufacturers Association. All rights including translation into
other languages, reserved under the Universal Copyright Convention, the Berne Convention or the Protection of
Literary and Artistic Works, and the International and Pan American Copyright Conventions.
2002/09/12
PS 3.10-2001 翻訳原稿
解説
この文書は，DICOM Committee が作成し，NEMA が発行した下記の規格を検討用として翻訳したもの
である。
PS 3.10-2001
Digital Imaging and Communications in Medicine (DICOM)
Part 10: Media Storage and File Format for Media Interchange
File name: 01_10pu.pdf
追加部分翻訳
繁村
翻訳登録：
2002.9.12
ファイル名
P10j0016.doc
直
ＤＩＣＯＭ規格 PS 3.10-2001 は PS 3.10-2000 に下記の Supplement による追加を行ったものである。
Supplement 51 Media Security
ＤＩＣＯＭ規格 PS 3.10-2000 はＤＩＣＯＭ規格 PS 3.10-1999 と同一で，変更はない。
ＤＩＣＯＭ規格 PS 3.10-1999 はＤＩＣＯＭ規格 PS 3.10-1998 に CP114 による修正と下記の
Supplement に基づく削除を行ったものである。Supplement と翻訳者名を記す（敬称略）。
Supplement 39: Add Stored Print Media Storage, Retire Normalized Print Media Storage 岩田
ii
2002/09/12
PS 3.10-2001 翻訳原稿
目次
頁
目次 .................................................................................................................................................................... iii
まえがき .............................................................................................................................................................. 1
１ 適用範囲と適用分野..................................................................................................................................... 3
２ 参照規格....................................................................................................................................................... 4
２．１ 引用規格 ........................................................................................................................................... 4
３ 定義 .............................................................................................................................................................. 5
３．１ 参照モデル定義................................................................................................................................. 5
注：定義は「データが無許可の方法で変更されなかった，あるいは破壊されなかったという特性」である。
３．２ サービス規約定義 ............................................................................................................................. 5
３．３ プレゼンテーションサービス定義 .................................................................................................... 5
３．４ ＤＩＣＯＭ序文と概説定義 ............................................................................................................... 5
３．５ ＤＩＣＯＭ情報オブジェクト定義 .................................................................................................... 6
３．６ ＤＩＣＯＭデータ構造および符号化定義 ......................................................................................... 6
３．７ ＤＩＣＯＭメッセージ交換定義........................................................................................................ 6
３．８ ＤＩＣＯＭ媒体保存およびファイルフォーマット定義 .................................................................... 6
４ 記号と略語 ................................................................................................................................................... 8
５ 規約 .............................................................................................................................................................. 9
６ 媒体保存のためのＤＩＣＯＭモデル............................................................................................................ 9
６．１ 一般ＤＩＣＯＭ通信モデル ............................................................................................................... 9
６．２ ＤＩＣＯＭ媒体保存モデル ............................................................................................................. 11
６．２．１ 物理媒体層........................................................................................................................... 11
６．２．２ 媒体フォーマット層 ............................................................................................................ 12
６．２．３ ＤＩＣＯＭデータフォーマット層 ....................................................................................... 12
６．２．３．１ ＤＩＣＯＭ ＳＯＰクラス ........................................................................................ 12
６．２．３．２ ＤＩＣＯＭファイルフォーマットの概念................................................................. 13
６．２．３．３ ＤＩＣＯＭ医用情報ディレクトリ............................................................................ 13
６．２．４ ＤＩＣＯＭ媒体保存応用プロファイル................................................................................ 13
６．２．５ 媒体保存およびＤＩＣＯＭ規格構造 ................................................................................... 14
７ ＤＩＣＯＭファイルフォーマット ............................................................................................................. 16
７．１ ＤＩＣＯＭファイルメタ情報 ......................................................................................................... 16
７．２ データ集合のカプセル化 ................................................................................................................ 18
７．３ ファイル管理情報のサポート ......................................................................................................... 19
７．４ セキュアＤＩＣＯＭファイルフォーマット .................................................................................... 19
８ ＤＩＣＯＭファイルサービス..................................................................................................................... 19
８．１ ファイル集合 .................................................................................................................................. 20
８．２ ファイルＩＤ .................................................................................................................................. 21
８．３ ファイル管理の役割とサービス...................................................................................................... 22
８．４ ファイル内容のアクセス ................................................................................................................ 23
８．５ 文字集合 ......................................................................................................................................... 24
８．６ 予約済みＤＩＣＯＭＤＩＲファイルＩＤ ....................................................................................... 24
９ 適合性要求 ................................................................................................................................................. 25
付属書Ａ（情報） ＤＩＣＯＭＤＩＲファイル内容の例 ..................................................................................... 26
Ａ．１ 単純なディレクトリ内容の例 ......................................................................................................... 26
Ａ．２ 複数参照ファイルをもつＤＩＣＯＭＤＩＲファイル内容の例 ....................................................... 28
付属書Ｂ（情報） 属性タグおよびＵＩＤの索引................................................................................................ 29
iii
2002/09/12
PS 3.10-2001 翻訳原稿
まえがき
ＡＣＲ（American College of Radiology）とＮＥＭＡ（National Electrical Manufacturers Association）は医
療におけるデジタル画像と通信のための規格を開発するために合同委員会を組織した。このＤＩＣＯ
Ｍ規格はＮＥＭＡの手続きにしたがって開発された。ＡＣＣ（American College of Cardiology）はデジ
タル媒体保存規格の定義に特別な関心をもち，この標準化活動に参加することを決めた。
この規格は，欧州のＣＥＮ ＴＣ２５１，および日本のＪＩＲＡを含む他の標準化組織との連絡のもと
に，また米国のＩＥＥＥ，ＨＬ７，およびＡＮＳＩを含む他の組織の論評をうけて開発された。
ＤＩＣＯＭ規格は下記の文書の中で確立された指針を使用して，複数の巻の文書として構成される。
-
ISO/IEC Directives, 1989 Part 3 - Drafting and Presentation of International Standards
この文書は，次の巻で構成されるＤＩＣＯＭ規格の一つの巻である：
ＰＳ３．１：序文と概論
ＰＳ３．２：適合性
ＰＳ３．３：情報オブジェクト定義
ＰＳ３．４：サービスクラス仕様
ＰＳ３．５：データ構造と符号化
ＰＳ３．６：データ辞書
ＰＳ３．７：メッセージ交換
ＰＳ３．８：メッセージ交換のためのネットワーク通信サポート
ＰＳ３．９：メッセージ交換のための二点間通信サポート
ＰＳ３．１０：媒体相互交換のための媒体保存とファイルフォーマット
ＰＳ３．１１：媒体保存応用プロファイル
ＰＳ３．１２：媒体相互交換のための媒体フォーマットと物理媒体
ＰＳ３．１３：プリント管理二点間通信サポート
ＰＳ３．１４：グレースケール標準表示関数
ＰＳ３．１５：セキュリティプロファイル
ＰＳ３．１６：内容マッピング資源
これらの巻は，独立しているが，しかし関連した文書である。ＰＳ３．４，ＰＳ３．７，ＰＳ３．８
およびＰＳ３．９は，二点間およびネットワークインタフェースを横切ったデジタル画像データの通
信に焦点を合わせる。ＤＩＣＯＭ規格のＰＳ３．１０は，ファイルの中の，または取り外し可能な保
存媒体上の医用画像の開放型媒体相互交換に取り組んでいる。それらは，過去および現在の関係する
努力を考慮に入れている：
ａ． 磁気テープのためのＡＣＲ−ＮＥＭＡ規格（ＰＳ１）は，９トラック磁気テープ上に，ＡＣＲ
−ＮＥＭＡ Ｖ２．０規格によってフォーマットされた一つ以上のデータ集合を保存するため
の包括的な方法を定義した。
1
2002/09/12
PS 3.10-2001 翻訳原稿
ｂ． ＩＳ＆Ｃ（Image Save and Carry）と呼ばれる日本の努力は，ＩＳ＆Ｃ特有の媒体編成フォーマ
ットをもつ 130 mm または 5-1/4 インチ光磁気ディスク上に画像を保存するために，ＡＣＲ−
ＮＥＭＡ Ｖ２．０準拠フォーマットを同様に使用している。
ｃ． スイスのジュネーブ大学によって始められたヨーロッパの努力は，物理媒体およびそのファイ
ル編成フォーマットに関係なく，フォルダとしてグループ化される一つ以上の画像をファイル
の中に保存するために，ＡＣＲ−ＮＥＭＡ Ｖ２．０に準拠したフォーマット，ＰＡＰＹＲＵ
Ｓを定義した。新しいＰＡＰＹＲＵＳ Ｖ３．０は，ＤＩＣＯＭ規格のこの巻と互換性のある
べきことが意図されている。
ネットワーク通信および媒体相互交換の双方は，共通の特性の多くを共用するので， ＤＩＣＯＭの既
存の巻の多くの巻が利用される：
ＰＳ３．３：情報オブジェクト定義
ＰＳ３．５：データ構造と符号化
ＰＳ３．６：データ辞書
ＰＳ３．１０は，ＤＩＣＯＭ規格の二つの他の巻のための基礎を用意する。
ＰＳ３．１１：媒体保存応用プロファイル
ＰＳ３．１２：媒体相互交換のための媒体フォーマットと物理媒体
これらの巻は，物理媒体に関係した技術および臨床的要求が発達するに従って，拡張される必要があ
ることがある。ＰＳ３．１１およびＰＳ３．１２は，開放型媒体相互交換のための完全な解を提供す
るために，ＤＩＣＯＭのために必要である。特に，媒体相互交換の分野でのＤＩＣＯＭへの適合性は，
ＤＩＣＯＭ規格のＰＳ３．２によって定義され，そしてＰＳ３．１１によって定義される応用プロフ
ァイルに基づいている。
2
2002/09/12
PS 3.10-2001 翻訳原稿
１
適用範囲と適用分野
ＤＩＣＯＭ規格のこの巻は，取り外し可能媒体上の医用画像情報の保存のための一般的なモデルを明
記する。この巻の目的は，広い範囲の物理保存媒体の上に種々のタイプの医用画像と関連情報の相互
交換を許す枠組みを提供することである。
この巻は下記について明記する：
ａ． 医用画像と関連情報の保存のための保存媒体上の階層モデル。このモデルは，媒体保存実装が
適合性を主張することがあるＤＩＣＯＭ規格の応用特有のサブセットを明記する，媒体保存応
用プロファイルの概念を導入する。そのような適合性は，保存媒体の内容の書き込み，読み出
し，そして更新にのみ適用される。特定の応用プロファイルはこの巻の中に含まれないで，Ｄ
ＩＣＯＭ規格のＰＳ３．１１の中に含まれる；
ｂ． 情報オブジェクト定義のカプセル化をサポートするＤＩＣＯＭファイルフォーマット；
ｃ． 暗号エンベロープの中でＤＩＣＯＭファイルフォーマットのカプセル化をサポートするセキ
ュアＤＩＣＯＭファイルフォーマット；
ｄ． 下にある媒体フォーマットおよび物理媒体からの独立を提供するＤＩＣＯＭファイルサービ
ス。媒体保存ディレクトリサービスオブジェクト対クラスを保存するために使用するＤＩＣＯ
ＭＤＩＲファイルに特有の方針が，同様に取り扱われる。
この巻は，ＤＩＣＯＭ規格の他の巻に下記のことで関連する：
−
ＰＳ３．２，適合性は，媒体保存に関するＤＩＣＯＭ適合性を達成するために合致する必要条
件を明記する；
−
ＰＳ３．３，情報オブジェクト定義は，この巻と共に使用されることがある多くの情報オブジ
ェクト定義（例えば種々のタイプの画像）を明記する；
−
ＰＳ３．４，媒体保存サービスクラスを定義するためにこの巻に基礎を置いている；
−
ＰＳ３．５，データ構造と符号化は，この巻の中で明記されるファイルの中にカプセル化され
るデータ集合を構築するために必要な符号化規則に取り組む。
−
ＰＳ３．６，データ辞書は，ＰＳ３．３の中で定義される情報オブジェクトの属性に関係した
全てのデータ要素のタグによる登録を含む。この索引は各データ要素についての値表現および
値複数度を含む。
−
ＰＳ３．１１，媒体保存応用プロファイルは，特定の臨床ニーズに関係した多くの選択を標準
化する（特定のサービスオブジェクト対クラスと同様に，物理媒体および媒体フォーマットの
選択）。それは，同じ応用プロファイルへの適合を主張する実装の間の相互運用性を容易にす
ることを目指している。ＰＳ３．１１は，媒体相互交換についての臨床ニーズが発展するに従
って拡張されることを意図している。
−
ＰＳ３．１２，媒体交換のための媒体フォーマットおよび物理媒体は，多くの選択された物理
媒体と対応する媒体フォーマットを定義する。これらの媒体フォーマットおよび物理媒体の選
択は，ＰＳ３．１１の応用プロファイルの一つ以上によって参照される。ＰＳ３．１２は，物
理媒体に関係する技術が発展するに従って拡張されることを意図している。
−
ＰＳ３．１５，セキュリティプロファイルは，セキュアＤＩＣＯＭ媒体保存応用プロファイル
3
2002/09/12
PS 3.10-2001 翻訳原稿
による使用のための多くのプロファイルを定義する。媒体保存セキュリティプロファイルは，
セキュア媒体保存応用プロファイルの中で個々の安全なＤＩＣＯＭファイルのために使用さ
れる暗号技術を明記する。
ＰＳ３．１０は，全体のアーキテクチャを標準化することおよび相互運用性への主な障害の幾つか，
ＤＩＣＯＭファイルフォーマットの定義，ＤＩＣＯＭファイルサービス，および媒体保存ディレクト
リ構造に関連する方針，に取り組むことによって，開放型媒体相互交換のための基礎を築く。
注： ＰＳ３．３は一般医用画像基本ディレクトリ情報オブジェクト定義を明記する，そしてＰＳ３．４は媒体
保存サービスクラスの一員である対応する媒体保存ディレクトリＳＯＰクラスを明記する。
保存媒体を読み出し，書き込み，あるいは更新する実装によるＤＩＣＯＭ ＰＳ３．１０の規約の固守
は，開放型媒体相互交換のための主要な基礎を表している。しかしながら，効果的な媒体保存相互交
換相互運用性が達成されるのは，ＰＳ３．１２の中の標準物理媒体および対応する媒体フォーマット
の選択，およびＰＳ３．１１の中の特定応用プロファイルの使用によってのみである。従って，ＤＩ
ＣＯＭ ＰＳ３．１０のみへの適合性を主張することは，有効なＤＩＣＯＭ適合性宣言ではない。ＤＩ
ＣＯＭ媒体保存適合性は，ＰＳ３．２によって定義される枠組みに従って，ＰＳ３．１１応用プロフ
ァイルに関係して作られる。
２
参照規格
２．１
引用規格
下記の規格は，この本文で参照することで，この規格の規定を構成する規定を含んでいる。発行の時
点では表示された版が有効であった。全ての規格は改訂の対象であり，この規格に準拠することに合
意する団体は，下記に示す規格の最新の版の適用の可能性を調査することが推奨される。
ISO/IEC Directives, 1989 Part 3 - Drafting and presentation of International Standards.
ISO 7498-1, Information Processing Systems - Open Systems Interconnection - Basic Reference Model.
ISO 7498-2, Information processing systems - Open Systems Interconnection - Basic reference Model - Part 2:
Security ArchitectureISO/TR 8509, Information Processing Systems - Open Systems Interconnection - Service
Conventions
ISO 8822, Information Processing Systems - Open Systems Interconnection - Connection-Oriented Presentation
Service Definition
ISO 8859, Information Processing - 8-bit single-byte coded graphic character sets - Part 1: Latin Alphabet No. 1
NEMA PS 3.1 - Introduction and Overview
NEMA PS 3.2 - Conformance
NEMA PS 3.3 - Information Object Definitions
NEMA PS 3.4 - Service Class Specifications
NEMA PS 3.5 - Data Structures and Encoding
NEMA PS 3.6 - Data Dictionary
NEMA PS 3.7 - Message Exchange
NEMA PS 3.8 - Network Communication Support for Message Exchange
4
2002/09/12
PS 3.10-2001 翻訳原稿
NEMA PS 3.11 - Media Storage Application Profiles.
NEMA PS 3.12 - Media Formats and Physical Media for Media Interchange
RFC-2630, Cryptographic Message Syntax, June 1999
３
定義
この規格の目的のために下記の定義が適用される。
３．１
参照モデル定義
規格のこの巻は ISO 7498-1 の中で開発された概念に基づき，その中で定義される下記の用語を使用す
る：
ａ． 応用エンティティ [Application Entity]
ｂ． 応用プロセス [Application Process]
ｃ． サービスまたは層サービス [Service or Layer Service]
ｄ． 転送構文 [Transfer Syntax]
規格のこの巻は ISO7498-2 の中で定義された次の用語を使用する：
ａ．データ機密性 Data Confidentiality
注：定義は，「情報が，無許可の個人，エンティティ，あるいは処理に，利用可能にならない，あるいは開示
されない特性」である
ｂ．データ発信元認証 Data Origin Authentication
注：定義は「受信データの発信元が主張されたとおりである認証」である。
ｃ．データ完全性 Data Integrity
注：定義は「データが無許可の方法で変更されなかった，あるいは破壊されなかったという特性」で
ある。３．２ サービス規約定義
規格のこの巻は ISO/TR 8509 の中で定義される下記の用語を使用する：
ａ． サービス提供者 [Service Provider]
ｂ． サービス利用者 [Service User]
３．３
プレゼンテーションサービス定義
規格のこの巻は ISO 8822 の中で定義される下記の用語を使用する：
ａ． 抽象構文 [Abstract Syntax]
ｂ． 抽象構文名 [Abstract Syntax Name]
３．４
ＤＩＣＯＭ序文と概説定義
規格のこの巻は，ＰＳ３．１の中で定義される下記の用語を使用する：
5
2002/09/12
PS 3.10-2001 翻訳原稿
−
３．５
属性 [Attribute]
ＤＩＣＯＭ情報オブジェクト定義
規格のこの巻は，ＰＳ３．３の中で定義される下記の用語を使用する：
ａ． 情報オブジェクト定義 [Information Object Definition]
３．６
ＤＩＣＯＭデータ構造および符号化定義
規格のこの巻は，ＰＳ３．５の中で定義される下記の用語を使用する：
ａ．データ要素 [Data Element]
ｂ．データ集合 [Data Set]
ｃ．データ要素タイプ [Data Element Type]
ｄ．値 [Value]
ｅ．値複数度 [Value Multiplicity]
ｆ．値表現 [Value Representation]
３．７
ＤＩＣＯＭメッセージ交換定義
規格のこの巻は，ＰＳ３．７の中で定義される下記の用語を使用する：
ａ．サービス−オブジェクト対（ＳＯＰ）クラス [Service-Object Pair (SOP) Class ]
ｂ．サービス−オブジェクト対（ＳＯＰ）インスタンス [Service-Object Pair (SOP) Instance]
ｃ．実装クラスＵＩＤ [Implementation Class UID]
３．８
ＤＩＣＯＭ媒体保存およびファイルフォーマット定義
規格のこの巻は，以下の用語を使用する。
応用プロファイル [Application Profile] ：
媒体保存応用プロファイルは，媒体相互交換が実行されることが意図されている特定のニーズまたは
コンテキストに適用可能であるＤＩＣＯＭ媒体保存モデルの種々の層での選択の選択を定義する。
ＤＩＣＯＭファイルサービス [DICOM File Service] ：
ＤＩＣＯＭファイルサービスは，媒体フォーマット層によって提供されるべきファイルの最小の抽象
的概念を明記する。そのようなＤＩＣＯＭファイルサービス境界によって，応用エンティティによる
ファイルの内容へのアクセスを強制することは，媒体フォーマットおよび物理媒体の独立を保証する。
ＤＩＣＯＭファイル [DICOM File] ：
ＤＩＣＯＭファイルは，ＤＩＣＯＭ規格のこの巻の必要条件に従ってフォーマットされる内容をもつ
ファイルである。特にそのようなファイルは，ファイルメタ情報および適切にフォーマットされたデ
ータ集合を含む。
ＤＩＣＯＭＤＩＲファイル [DICOMDIR File] ：
ファイル集合内で，媒体保存ディレクトリＳＯＰクラスを含む唯一のそして必須のＤＩＣＯＭファイ
6
2002/09/12
PS 3.10-2001 翻訳原稿
ル。このファイルは，単一構成要素ファイルＩＤ，ＤＩＣＯＭＤＩＲを与えられる。
ファイル [File] ：
ファイルは，零以上のバイトの順序づけられる列である，ここで最初のバイトはファイルの始まりに
あり，そして最後のバイトはファイルの終わりにある。ファイルは固有のファイルＩＤによって識別
される，そして書き込み，読み出し，そして／または削除されることがある。
ファイルＩＤ [File ID] ：
ファイルは，それらが属しているファイル集合のコンテキスト内で唯一であるファイルＩＤによって
識別される。順序づけられるファイルＩＤ構成要素の集合（最大８個まで）は，ファイルＩＤを形成
する。
ファイルＩＤ構成要素 [File ID Component] ：
定義された文字集合の１から８文字の列
ファイルメタ情報 [File Meta Information] ：
ファイルメタ情報は，カプセル化されたデータ集合を識別する情報を含む。それは，あらゆるＤＩＣ
ＯＭファイルの始まりにある必須のヘッダである。
ファイル集合 [File-set] ：
ファイル集合は，その内でファイルＩＤが固有である共通命名空間を共有するＤＩＣＯＭファイル（お
よび，あるいは非ＤＩＣＯＭファイル）の集積である。
ファイル集合クリエータ [File-set Creator] ：
ＤＩＣＯＭＤＩＲファイル（節８．６を参照）および零以上のＤＩＣＯＭファイルを生成する応用エ
ンティティ。
ファイル集合リーダー [File-set Reader] ：
ファイル集合の中の一つ以上のファイルにアクセスする応用エンティティ。
ファイル集合アップデータ [File-set Updater] ：
ファイル集合の中でファイルにアクセスする，追加ファイルを生成する，または既存のファイルを削
除する応用エンティティ。ファイル集合アップデータは，追加または削除を反映するＤＩＣＯＭＤＩ
Ｒファイルへの適切な変更を行う。
ＤＩＣＯＭファイルフォーマット [DICOM File Format] ：
ＤＩＣＯＭファイルフォーマットは，ＤＩＣＯＭ情報オブジェクトに関係するＳＯＰインスタンスを
表現するデータ集合をファイルの中にカプセル化する手段を提供する。
媒体フォーマット [Media Format] ：
物理媒体によって定義されるビットの流れを，データファイル構造および関連するファイルディレク
トリの中に組織化するデータ構造および関連する方針。
媒体保存モデル [Media Storage Model] ：
ＤＩＣＯＭ媒体保存モデルは，媒体相互交換を通して相互運用性を達成するために，異なる層で使用
されるデータ構造に関係する。
7
2002/09/12
PS 3.10-2001 翻訳原稿
物理媒体 [Physical Media] ：
ビットの流れに対して記録能力をもつ一枚の材料。物理媒体の特性は，外形因子，機械特性，記録特
性，そしてアクセス可能な構造の中で，ビットの流れを記録しそして組織化するための規則を含む。
セキュアＤＩＣＯＭファイル Secure DICOM File：
RFC 2630 の中で明記された暗号メッセージ構文でカプセル化されたＤＩＣＯＭファイル。
セキュアファイル集合 Secure File-set：
すべてのＤＩＣＯＭファイルがセキュアＤＩＣＯＭファイルであるファイル集合。
セキュア媒体保存応用プロファイル Secure Media Storage Application Profile：
セキュアファイル集合を必要とするＤＩＣＯＭ媒体保存応用プロファイル。
４
記号と略語
下記の記号と略語は，この規格のこの巻の中で使用される。
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
Comité Européen 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
Healthcare Level 7
IEEE
Institute of Electrical and Electronics Engineers
ISO
International Standards Organization
ID
Identifier
IOD
Information Object Definition
JIRA
Japan Industries Association of Radiation Apparatus
NEMA
National Electrical Manufacturers Association
OSI
Open Systems Interconnection
SOP
Service-Object Pair
TCP/IP
Transmission Control Protocol/Internet Protocol
8
2002/09/12
PS 3.10-2001 翻訳原稿
UID
Unique Identifier
VR
Value Representation
５
規約
この文書の節３の中で既に定義されている用語は，読者の理解を助けるために，この文書の中で大文
字で書かれている，そしてその意味で解釈される。
タグは， (gggg，eeee) として表される。ここで， gggg はグループ番号に等しく， eeee はそのグル
ープ内での要素番号に等しい。タグは，ＤＩＣＯＭ規格のＰＳ３.５の中で明記されるように，１６進
数表記で表現される。
ファイルメタ情報の属性は，特定の属性が，媒体保存操作に依存して必要である場合を示すタイプを
割り当てられる。以下のタイプ指示は，ＰＳ３.５の指示から引き出されるが，しかし媒体保存環境を
考慮に入れている：
６
−
タイプ１：このような属性は，ファイル集合クリエータおよびファイル集合アップデータによ
って生成されるファイルの中に，明示的な値をもって存在する。それらは，ファイル集合リー
ダーおよびファイル集合アップデータによってサポートされる。
−
タイプ１Ｃ：このような属性は，明記される条件に合致する場合，ファイル集合クリエータお
よびファイル集合アップデータによって生成されるファイルの中に，明示的な値をもつて存在
する。それらは，ファイル集合リーダーおよびファイル集合アップデータによってサポートさ
れる。
−
タイプ２：このような属性は，ファイル集合クリエータおよびファイル集合アップデータによ
って生成されるファイルの中に，明示的な値もってまたは不明な場合は長さ零の値をもって存
在する。それらは，ファイル集合リーダーおよびファイル集合アップデータによってサポート
される。
−
タイプ２Ｃ：このような属性は，指定された条件に合致する場合は，ファイル集合クリエータ
およびファイル集合アップデータによって生成されるファイルの中に，明示的な値をもって，
または不明な場合は零の長さをもって存在する。それらは，ファイル集合リーダーおよびファ
イル集合アップデータによってサポートされる。
−
タイプ３：このような属性は，ファイル集合クリエータおよびファイル集合アップデータによ
って生成されるファイルの中に，明示的な値または零の長さの値をもって存在することがある。
それらは，ファイル集合リーダーおよびファイル集合アップデータによってサポートされるこ
とがある。
媒体保存のためのＤＩＣＯＭモデル
この節は，取外し可能な保存媒体の相互交換による通信の目的のためにＤＩＣＯＭ応用エンティティ
によって使用されるＤＩＣＯＭ媒体保存モデルを定義する。特に，この節はデジタル画像と通信のた
めの多くの概念を明らかにするモデルを提供する，そしてＤＩＣＯＭ規格を通して使用される重要な
用語を紹介する。このモデルはＤＩＣＯＭ規格を保存媒体交換に関係した個々の巻に分割するために
使用される。
６．１
一般ＤＩＣＯＭ通信モデル
9
2002/09/12
PS 3.10-2001 翻訳原稿
図６．１−１はネットワーク，２点間および媒体相互交換通信にわたるＤＩＣＯＭの一般通信モデル
を表す。ＤＩＣＯＭ応用エンティティは，次の境界の何れか一つを使用する：
−
ＯＳＩ上位層サービス，これは特定の物理ネットワークおよび２点間通信サポートからの独立
を提供する。
−
ＤＩＣＯＭファイルサービス，これは特定の物理媒体保存フォーマットおよびファイル構造か
ら独立している保存媒体へのアクセスを提供する。
医用画像応用
ＤＩＣＯＭ応用エンティティ
ＯＳＩ上位層サービス境界
５０ピン
ＴＣＰ／ＩＰ
ＤＩＣＯＭファイルサービス境界
ＯＳＩ
ネットワークおよび２点間通信
媒体 Ａ
媒体 Ｂ
媒体 Ｃ
媒体
フォーマット
と
物理
フォーマット
媒体
フォーマット
と
物理
フォーマット
媒体
フォーマット
と
物理
フォーマット
媒体交換
図６．１−１ 一般ＤＩＣＯＭ通信モデル
10
2002/09/12
PS 3.10-2001 翻訳原稿
６．２
ＤＩＣＯＭ媒体保存モデル
ＤＩＣＯＭ媒体保存モデルは，図６．２−１によって示される，そして先に節６．１の中で導入され
た一般ＤＩＣＯＭ通信モデルを拡張する。
ＤＩＣＯＭ媒体保存モデルは，取外し可能保存媒体によるデータ相互交換に直接関係する局面に焦点
を合わせる。それは媒体相互交換による相互運用性を達成するために異なる層で使用されるデータ構
造および関連する規則に関係する。このモデルの中で確認されるサービスは，機能層間の単純な境界
である。
注： これらの境界での応用プログラミングインタフェースを明記することは，この規格の範囲外である。
ＤＩＣＯＭ媒体保存モデルは，次の節の中で記述される三つの層を含む。
応用サービス境界
ＤＩＣＯＭ情報オブジェクトと
媒体サービスクラスに依存する
応用エンティティ
サービスオブジェクト対
基本ディレ
クトリ
ＤＩＣＯＭデータフォーマット層
ＤＩＣＯＭファイルフォーマット
ＤＩＣＯＭファイルサービス境界
媒体フォーマットと物理媒体の
独立を保証する
媒体フォーマット
媒体フォーマット層
例 物理媒体特有のことがある
ファイルシステムのデータ構造
物理媒体アクセスサービス境界
物理媒体特有
物理媒体
保管媒体仕様
例 ＣＤ−Ｒ，９０ｍｍＭＯＤ，１３０ｍｍＭＯＤ等
物理媒体フォーマット層
応用特有情報オブジェクト（画像，結果，など）
この巻の中で注力される包括的要素（特定物理媒体と情報オブジェクトから独立）
下位層のデータ構造にアクセスを提供する抽象サービス
図６．２−１ ＤＩＣＯＭ媒体保存モデル
６．２．１ 物理媒体層
物理媒体特性が物理媒体層で定義される。そのような特性は物理保存媒体外形因子，寸法，機械特性
および記録特性を含む。この層はまた，記録されたビットの構成および組織化を定義する。
注： １．パーソナルコンピュータ環境の中での物理媒体層の例は３．５インチ両面高密度フロッピーディスク
11
2002/09/12
PS 3.10-2001 翻訳原稿
である。
２．与えられた応用に対する一つ以上の特定物理媒体の仕様はＤＩＣＯＭ規格のこの巻の範囲外である。
ＤＩＣＯＭ規格のＰＳ３．１２とその付属書はいくつかの物理媒体選択を明記する。ＰＳ３．１１は特定
の医用画像応用の必要条件に依存する特定物理媒体を選択する多くの応用プロファイルを定義する。
６．２．２ 媒体フォーマット層
媒体フォーマット層において，物理媒体のビット流れが，特定構造の中に組織化される。データファ
イル構造および関連するディレクトリ構造は，物理媒体空間の効率的アクセスおよび管理を可能にす
るために定義される。
注： この層は，与えられたオペレーティングシステム環境にしばしば特有のものである。３．５インチフロッ
ピーディスクに関連したそのような媒体フォーマット層定義の例として，オペレーティングシステムによ
って使用される種々のパーソナルコンピュータファイルシステムのデータ構造がある。ＤＩＣＯＭ規格の
ＰＳ３．１２およびその付属書が，いくつかの媒体フォーマットの選択を明記する。
ＤＩＣＯＭ規格によってサポートされる媒体フォーマットは，この巻の節８の中で明記されるＤＩＣ
ＯＭファイルサービスによって明記される最小必要条件をサポートするために選択される。そのよう
なＤＩＣＯＭファイルサービスによるファイル内容への制約的アクセスは，ＤＩＣＯＭデータフォー
マット層が媒体フォーマットおよび物理媒体の選択から独立していることを保証する。
６．２．３ ＤＩＣＯＭデータフォーマット層
ＤＩＣＯＭデータフォーマット層は，仕様の四つの要素を含む：
ａ． ＤＩＣＯＭ媒体保存ＳＯＰクラスおよび関連する情報オブジェクト定義；
ｂ． ＤＩＣＯＭファイルフォーマット；
ｃ． セキュアＤＩＣＯＭファイルフォーマット；
ｄ． ＤＩＣＯＭ媒体保存ディレクトリＳＯＰクラス；
ｅ． ＤＩＣＯＭ媒体保存応用プロファイル。
ｆ． 媒体保存のためのＤＩＣＯＭセキュアプロファイル。
６．２．３．１
ＤＩＣＯＭ ＳＯＰクラス
ＤＩＣＯＭ ＳＯＰクラスおよび関連する情報オブジェクト定義（ＩＯＤ）は，データフォーマット層
において特定の医用画像情報を伝達するために使用される。媒体保存のために使用されるＳＯＰクラ
スおよびＩＯＤは，ＤＩＣＯＭ規格のＰＳ３．３およびＰＳ３．４の中で確立された枠組みに従う。
そのようなＩＯＤの例は，モダリティ画像，患者情報，結果などである。
媒体保存操作に関連したＤＩＣＯＭ ＩＯＤの使用は，多くの媒体保存サービスオブジェクト対クラス
またはＳＯＰクラスを形成する。媒体保存操作（例えば，読み出し，書き込み，消去，など）は，Ｄ
ＩＣＯＭファイルサービスを通して実行される。結果として生じるＤＩＣＯＭファイルの内容は，以
下に明記するＤＩＣＯＭファイルフォーマットに従ってフォーマットされる。
注： １．媒体保存コンテキストの中のＳＯＰクラスの概念は，ネットワークに関係した操作（ＤＩＭＳＥ操作）
のためにＰＳ３．３およびＰＳ３．４の中で導入されたＳＯＰクラスの概念に等しい。
２．複合および正規化ＩＯＤおよびＳＯＰクラスの双方が，媒体保存コンテキストの中で使用されること
がある。
12
2002/09/12
PS 3.10-2001 翻訳原稿
ＤＩＣＯＭ規格のＰＳ３．４は，媒体保存のために使用されることがある多くのＳＯＰクラスを定義
する。これらのＳＯＰクラスは，ＤＩＣＯＭ ＰＳ３．３の付属書の中で見いだされることがあるＤＩ
ＣＯＭ標準ＩＯＤに基づいている。
ＳＯＰクラスに関連したデータを表現するデータ集合の構造と符号化は，ＤＩＣＯＭ規格のＰＳ３．
５に従う。そのようなデータ集合を符号化するために使用されることがある転送構文の仕様は，同様
にＰＳ３．５の中で定義される。
６．２．３．２
ＤＩＣＯＭファイルフォーマットの概念
ファイルの中のＤＩＣＯＭデータ集合のカプセル化は，この巻の節７の仕様に従う。これらのカプセ
ル化規則は，如何なるＤＩＣＯＭデータ集合もファイルの中に含むことが可能なＤＩＣＯＭファイル
フォーマットを定義する。ファイルは，ファイルＩＤによって識別される。意味は，これらのファイ
ルＩＤからも，またはそれらの構造からも推論されない。
注： ＤＩＣＯＭファイルのクリエータとして動作する医用画像応用はファイルＩＤを生成するために意味情
報を使用することがあるが，しかしＤＩＣＯＭファイルのリーダーはファイルＩＤの見かけの意味内容に
頼ってはいけない。
データ集合のカプセル化は，この巻の節８の中で明記されるＤＩＣＯＭファイルサービスに基づく。
注： 特定の媒体フォーマットが，ＤＩＣＯＭファイルサービスの中で明記されるものよりも多くのファイルサ
ービスを提供することが許される。そのようなサービスは局所または実装の内部にあることがある。それ
らの使用法は，ＤＩＣＯＭ規格の適用範囲外である。しかしながら，そのようなサービスが，媒体フォー
マット層のファイル構造の中に，または情報オブジェクトのデータ集合符号化の中に反映される場合には，
相互運用性を阻害する方法（例えば，ＤＩＣＯＭファイルサービスの中で明記されるものよりも長いファ
イルＩＤ）でのそのようなサービスの拡張は行うべきではない。
セキュアＤＩＣＯＭファイルへのＤＩＣＯＭファイルのカプセル化は，この巻の節７．４の仕様に従
う。これらのカプセル化規則は，保護のないＤＩＣＯＭファイルをセキュアエンベロープ内のペイロ
ードとしてカプセルに入れることによって，セキュアＤＩＣＯＭファイルを生成するための機構を定
義する。
６．２．３．３
ＤＩＣＯＭ医用情報ディレクトリ
ＤＩＣＯＭ画像および画像関連ＳＯＰクラス（例えば，結果，患者）に加えて，媒体保存に適合させ
た他のＳＯＰクラスが，医用情報に基づく参照（またはディレクトリ）を提供する，従って医用画像
情報へのアクセスを促進するために使用されることがある。そのようなＳＯＰクラスは，ＤＩＣＯＭ
規格のＰＳ３．４の中で定義される媒体保存ディレクトリＳＯＰクラスである。このＳＯＰクラスの
インスタンスは，ＤＩＣＯＭＤＩＲのファイルＩＤをもつファイルの中で伝達される。
６．２．４ ＤＩＣＯＭ媒体保存応用プロファイル
媒体保存応用プロファイルは，媒体相互交換が実行されることが意図される特定の要求またはコンテ
キストに適用可能であるＤＩＣＯＭ媒体保存モデルの種々の層での選択の選択を定義する。そのよう
な選択は，同一の媒体保存応用プロファイルに適合する実装間で相互運用性を保証するために，媒体
保存応用プロファイルとして公式に明記される。それは，使用者が異なる実装の相互運用性を評価す
ることを可能にする適合性宣言を容易にする。
媒体保存応用プロファイルは下記を含む：
13
2002/09/12
PS 3.10-2001 翻訳原稿
ａ． 応用プロファイル（例えば心臓検査，超音波検査，アンジオグラフィ）によって取り扱われる
ニーズの記述およびその応用のコンテキスト；
ｂ． データフォーマット層における，多くの特定のＩＯＤおよび関連するＳＯＰクラスの選択。標
準ＤＩＣＯＭ ＳＯＰクラスに対して，これは，ＤＩＣＯＭ規格ＰＳ３．４への参照によって
行われる。これらのＳＯＰクラスは，他のＤＩＣＯＭ ＳＯＰクラスのように，固有の登録済
みＵＩＤを割り当てられる。各ＳＯＰクラスに対して，それのサポートがこのプロファイルの
コンテキスト内で必要とされるかまたはオプションであるかが述べられる；
ｃ． 特定媒体フォーマット定義の選択。これは，選択された物理媒体，特定の関連する媒体フォー
マットおよび媒体フォーマット（またはファイルシステム）サービスのＤＩＣＯＭファイルサ
ービスへの写像を明記しているＤＩＣＯＭ規格ＰＳ３．１２への参照によってなされる；
ｄ． 適切な転送構文の選択；
ｅ． 特定のセキュリティプロファイルの選択。これは，ＤＩＣＯＭファイル集合のＤＩＣＯＭファ
イルをセキュアＤＩＣＯＭファイルの中にカプセル化するために使用される暗号アルゴリズ
ムを明記するＤＩＣＯＭ規格のＰＳ３．１５への参照によって行われる。媒体保存応用プロフ
ァイルがセキュリティプロファイルを選択しない場合，応用プロファイルはセキュアでない，
そして，セキュアＤＩＣＯＭファイルフォーマットはその応用プロファイルと共に使用されな
い；
ｆ
特定の制限（例えば，必要な場合は最大ファイルサイズ，存在する場合はオプションのサポー
ト）のような相互運用性を容易にする他の選択。
媒体保存応用プロファイルの完全な定義および構造は，ＰＳ３．１１によって明記される。異なった
ニーズに対応する多くの標準応用プロファイルが，ＰＳ３．１１の中に含まれる。
６．２．５ 媒体保存およびＤＩＣＯＭ規格構造
図６．２−２は，節６．２の中で導入したＤＩＣＯＭ媒体保存モデルによって識別される機能領域お
よび媒体保存に関係するＤＩＣＯＭ規格の種々の巻の間の関係の概要を提供する。ＤＩＣＯＭ規格の
多くの巻は，ネットワーク通信および媒体交換の間で共通である。
14
2002/09/12
PS 3.10-2001 翻訳原稿
一般
ネットワークおよび
二点間通信
媒体保存相互交換
巻２
巻４
巻１
序文と概説
適合性
サービスクラス仕様
巻１１
媒体保存
応用プロ
ファイル
巻３ 情報オブジェクト定義
（画像，検査，など）
巻６
巻５
データ辞書
データ構造と符号化
巻７
巻８
巻９
巻１０ 保存
巻１５
媒体とファイ セキュリティ
ルフォーマッ プロファイル
ト（規格のこの
巻が扱う）
巻１２
媒体Ｘ
媒体フォーマット
と物理媒体
媒体Ｙ
媒体Ｚ
ＤＩＣＯＭの最初の９巻
媒体保存相互交換をサポートする巻
ＤＩＣＯＭ規格のこの巻
図６．２−２ 媒体保存およびＤＩＣＯＭの巻
15
2002/09/12
PS 3.10-2001 翻訳原稿
７
ＤＩＣＯＭファイルフォーマット
ＤＩＣＯＭファイルフォーマットは，ＤＩＣＯＭ ＩＯＤに関係したＳＯＰインスタンスを表現するデ
ータ集合をファイルの中にカプセル化する手段を提供する。図７−１の中で示すように，データ集合
のバイトの流れは，ＤＩＣＯＭファイルメタ情報の後のファイルの中に置かれる。各ファイルは単一
のＳＯＰインスタンスを含む。
ＤＩＣＯＭ
ＳＯＰインスタンス
ＤＩＣＯＭ
ＳＯＰインスタンス
ＤＩＣＯＭ巻５符号化
ＤＩＣＯＭ
ファイルメ
タ情報
ＤＩＣＯＭデータ集合
一つのＳＯＰインスタンスを含むファイル
・・・
DICOM
SOP ｲﾝｽﾀﾝｽ
ＤＩＣＯＭ巻５符号化
ＤＩＣＯＭ
ファイルメ
タ情報
ＤＩＣＯＭデータ集合
一つのＳＯＰインスタンスを含むファイル
・・
ファイル
ＤＩＣＯＭフォーマットファイルを含むファイル集合
図７−１
７．１
ファイル集合およびファイルフォーマット
ＤＩＣＯＭファイルメタ情報
ファイルメタ情報は，カプセル化されたデータ集合を識別する情報を含む。このヘッダは，表７．１
−１の中に示す１２８バイトのファイルプリアンブル（前文），これに続く４バイトのＤＩＣＯＭプ
リフィックス（前置子），それに続くファイルメタ要素から構成される。このヘッダはすべてのＤＩ
ＣＯＭファイルの中に存在する。
ファイルプリアンブルは，応用プロファイルまたは特定の実装によって定義されるように使用するこ
とが可能である。ＤＩＣＯＭ規格のこの巻は，この固定サイズのプリアンブルについて如何なる構造
も要求しない。それは，タグおよび長さをもつＤＩＣＯＭデータ要素として構築されることを要求さ
れない。それは，多くの一般に使われるコンピュータ画像ファイルフォーマットとの互換性を提供す
ることによって，ＤＩＣＯＭファイルの中の画像および他のデータへのアクセスを容易にすることが
意図されている。ファイルプリアンブルが情報を含んでいても含んでいなくても，ＤＩＣＯＭファイ
ルの内容が，この巻の必要条件に適合する，そしてデータ集合は，ファイルメタ情報の中で明記され
たＳＯＰクラスに適合する。
注： １．ファイルプリアンブルが応用プロファイルまたは特定の実装によって使用されない場合は，全ての１
２８バイトは 00H に設定される。これは，全ての１２８バイトが上記で明記されるように設定されてい
ない時は，プリアンブルが使用されていることを認識することを容易にすることを意図している。
２．ファイルプリアンブルは，例えば，マルチメディア応用がＤＩＣＯＭデータ集合の中に保存されてい
る画像にランダムにアクセスすることを可能にする情報を含むことがある。同一のファイルが，プリアン
ブルを使用するマルチメディア応用によって，そしてプリアンブルを無視するＤＩＣＯＭ応用によって，
二つの方法で利用されることが可能である。
16
2002/09/12
PS 3.10-2001 翻訳原稿
４バイトのＤＩＣＯＭプリフィックスは，ISO 8859 G0 文字集合の大文字として符号化される文字列
“DICM” を含む。この４バイトプリフィックスは，タグおよび長さをもつＤＩＣＯＭデータ要素とし
て構築されない。
プリアンブルおよびプリフィックスは，表７．１−１の中で定義されるタグおよび長さをもつＤＩＣ
ＯＭメタ要素の集合によって後続される。
表７．１−１ ＤＩＣＯＭファイルメタ情報
属性名
タグ
タイプ
属性記述
ファイルプリアンブ タグなし，長さ １
ル
領域なし
応用プロファイルまたは実装特定の用途のために使
用できる固定１２８バイト領域。応用プロファイルま
たは特定の実装によって使用されない場合は，全ての
バイトは 00H に設定される。
ファイル集合リーダーまたはアップデータはこのフ
ァイルがＤＩＣＯＭファイルであるか否かを決める
ためにこのプリアンブルの内容を信頼しない
ＤＩＣＯＭプリフィ タグなし，長さ １
ックス
領域なし
文字列 “DICM” を含む４バイト。このプリフィック
スはこのファイルがＤＩＣＯＭファイルか否かを認
識するために使用されることを意図している。
グループ長さ
(0002,0000)
１
このファイルメタ要素（値領域の終わり）に続くグル
ープ２ファイルメタ情報の最後のファイルメタ要素
まで，そしてそれを含むバイトの数
ファイルメタ情報版 (0002,0001)
１
これは各ビットがこのファイルメタ情報ヘッダの版
を識別する２バイト領域である。版１の中では最初の
バイト値は 00H であり，そして二番目のバイト値は
01H である。
この属性が 1 に設定された二番目のバイトのビット
0 （lsb 下位ビット）を持つ場合に，メタ情報をもつ
ファイルを読む実装は，ＰＳ３．１０のこの版の中で
明記されるようにファイルメタ情報を解釈するであ
ろう。他の全てのビットは検査されない。
注： 各ビットが版を識別するビット領域は，複数の旧版の
サポートの明示的な指示を可能にする。版１リーダー
によって読むことができるファイルメタ情報の将来
の版は，1 に設定された二番目のバイトのビット 0
を持つであろう。
媒体保存ＳＯＰクラ (0002,0002)
スＵＩＤ
１
データ集合に関係するＳＯＰクラスを唯一に識別す
る。媒体保存のために許されるＳＯＰクラスＵＩＤは
ＤＩＣＯＭ規格ＰＳ３．４の媒体保存応用プロファイ
ルの中で明記される。
媒体保存ＳＯＰイン (0002,0003)
スタンスＵＩＤ
1
ファイルの中に置かれ，そしてファイルメタ情報に後
続するデータ集合に関係するＳＯＰインスタンスを
唯一に識別する。
17
2002/09/12
PS 3.10-2001 翻訳原稿
転送構文ＵＩＤ
(0002,0010)
1
後続するデータ集合の符号化に使用される転送構文
を唯一に識別する。この転送構文はファイルメタ情報
に適用されない。
注： ファイルメタ要素値の解釈を容易にするために明示
的値表現符号化をサポートするＤＩＣＯＭ転送構文
の一つを使用することが推奨される（ＤＩＣＯＭ規格
ＰＳ３．５を参照）
実装クラスＵＩＤ
(0002,0012)
1
このファイルおよびその内容を書いた実装を唯一に
識別する。相互交換問題の場合にはファイルを最後に
書いた実装のタイプの曖昧でない識別を提供する。Ｄ
ＩＣＯＭ規格のＰＳ３．７（アソシエーション折衝）
によって定義されるものと同じ方針に従う。
実装版名
(0002,0013)
3
節８．５の中で確認される文字集合の１６文字までを
使用して，実装クラスＵＩＤ（0002,0012）に対する版
を識別する。ＤＩＣＯＭ規格のＰＳ３．７（アソシエ
ーション折衝）によって定義されるものと同じ方針に
従う。
発生元応用エンティ (0002,0016)
ティ名称
3
このファイルの内容を書いた（または最後にそれを更
新した）ＡＥのＤＩＣＯＭ応用エンティティ（ＡＥ）
名称。使用される場合は，それは媒体相互交換問題の
場合にエラーの発生元の追跡を可能にする。ＡＥ名称
に関係する方針はＤＩＣＯＭ規格のＰＳ３．８の中で
定義されるものと同じである。
私的情報生成者ＵＩ (0002,0100)
Ｄ
3
私的情報 (0002,0102) の生成者のＵＩＤ
私的情報
1C
ファイルメタ情報の中に置かれた私的情報を含む。生
成者は (0002,0100) の中で識別される。私的情報生成
者ＵＩＤ (0002,0100) がある場合は必要。
(0002,0102)
１２８バイトプリアンブルおよび４バイトプリフィックスを除いて，ファイルメタ情報は，ＤＩＣＯ
Ｍ ＰＳ３．５の中で定義される明示的ＶＲリトルエンディアン転送構文（UID = 1.2.840.10008.1.2.1）
を使用して符号化される。各ファイルメタ要素の値は，それらの対応する値表現によってＰＳ３．５
の中で指定されるとおり偶数長にすることが必要なときは，埋められる。この規格の将来の版との互
換性のために，表７．１−１の中で定義されていないタグ (0002,xxxx) は無視される。
全てのタグ (0002,xxxx) の値が，この規格およびＤＩＣＯＭの今後の版によって使用されるために予
約されている。タグ (0001,xxxx), (0003,xxxx), (0005,xxxx), および (0007,xxxx) をもつ要素は媒体交換
のためには使用されない。
７．２
データ集合のカプセル化
各ファイルは，単一のＳＯＰクラス（そして対応するＩＯＤ）に関係する単一のＳＯＰインスタンス
を表現する単一のデータ集合を含む。
注： 特定ＩＯＤは複数フレームを含むことを定義されることがあるので，ファイルは単一の２Ｄ画像フレーム
より多くを含むことがある。
18
2002/09/12
PS 3.10-2001 翻訳原稿
データ集合を符号化するために使用される転送構文は，ＤＩＣＯＭファイルメタ情報の転送構文ＵＩ
Ｄによって識別されるものである。
注： ＤＩＣＯＭデータ集合は，その全体の長さを含まない。ＤＩＣＯＭファイルサービス（節８．４を参照）
によって提供されるファイル指示の終わりが，データ集合の終りの唯一の指示である。
ファイルが書かれるときにデータ集合のパディングが望まれる場合は，データ集合の最後のデータ要
素はデータ要素 (FFFC,FFFC) であることがある。このデータ集合末尾パディングデータ要素
(FFFC,FFFC) の値は，重要性を持たず，そしてこのデータ集合を読む全てのＤＩＣＯＭ実装によって
無視される。ファイル集合リーダーまたはアップデータは，メタ情報に後続しているデータ集合の中
で，またはシーケンスの中で入れ子になったデータ集合の中で，このデータ集合末尾パディング
(FFFC,FFFC) を処理することが可能である（ＤＩＣＯＭ規格ＰＳ３．５を参照）。
７．３
ファイル管理情報のサポート
ＤＩＣＯＭファイルフォーマットは，媒体フォーマット層に関係した機能の重複を避けるためにファ
イル管理情報を含まない。与えられたＤＩＣＯＭ応用プロファイルのために必要な場合は，以下の情
報が媒体フォーマット層によって提供されるべきである：
−
ファイル内容の所有者の識別；
−
ファイルアクセスの統計（例えば，生成の日付および時刻）；
−
応用ファイルアクセス制御；
−
物理媒体アクセス制御（例えば，書込み禁止）。
７．４
セキュアＤＩＣＯＭファイルフォーマット
セキュアＤＩＣＯＭファイルは，RFC 2630 の中で定義される暗号メッセージ構文によりカプセルに入
れられた単一ＤＩＣＯＭファイルを含む。カプセル化のために使用された暗号アルゴリズムに依存し
て，セキュアＤＩＣＯＭファイルは次のセキュリティ特性の一つ以上を提供することができる：
−
データ機密性（暗号の手段による）
−
データ発信元認証（証明書とデジタル署名の手段による）
−
データの完全性（デジタル署名の手段による）
さらに，セキュアＤＩＣＯＭファイルは，キー輸送，キーの合意あるいは対称キー・暗号キー技術に
よって意図した受信者に暗号キーおよび証明書を伝える可能性を提供する。
８
ＤＩＣＯＭファイルサービス
ＤＩＣＯＭファイルサービスは，データフォーマット層の中で，サービス利用者の見地からファイル
の抽象的な概念を明記する。そのようなＤＩＣＯＭファイルサービスを通して，応用エンティティに
よるファイルの内容へのアクセスを制限することは，特定の媒体フォーマットおよび物理媒体の選択
からデータフォーマット層機能の独立を保証する。
注：このＤＩＣＯＭファイルサービス定義は，それが単に境界の仕様であるとの意味における抽象概念である。
その焦点は，媒体フォーマット層のデータ構造へのアクセスに直接関係した見地に制限される（データ構
造自身の仕様ではない）。ＤＩＣＯＭファイルサービスは，読み出し，書き込み，消去などのような多く
の抽象的プリミティブの手段によって記述されることがあるけれども，それは応用プログラミングインタ
19
2002/09/12
PS 3.10-2001 翻訳原稿
ーフェース（ＡＰＩ）の定義であることを意図していない。
媒体保存のために明記されたＤＩＣＯＭファイルサービスは，一般に利用できる媒体フォーマット（ま
たはファイルシステム）の広い範囲によってサポートされるために充分に簡単であるが，しかしファ
イルを効果的に管理しそしてそれらの内容へアクセスするためのキー機能を提供するために充分に充
実している基本サービスを提供する。以降の節は，ＤＩＣＯＭ媒体保存モデルに適合するために，物
理媒体および関連した媒体フォーマットによって満たされる最小限の必須必要条件を明記する。
注： 特定の媒体フォーマットが，ＤＩＣＯＭファイルサービスの中で明記されるものよりも多くのファイルサ
ービスを提供することは許される。そのようなサービスは多分実装の内側にある（すなわちそれは保存媒
体上のデータ構造を通して見ることはできない）。それらの使用法はＤＩＣＯＭ規格の範囲外である。し
かしながら，そのようなサービスが，媒体フォーマット層のファイル構造の中でまたは情報オブジェクト
を符号化するデータ集合の中で反映される場合は，相互運用性を阻害する方法の中のそのようなサービス
の拡張は行うべきでない（例えば，ＤＩＣＯＭファイルサービスの中で明記されるよりも長いファイルＩ
Ｄ）。
８．１
ファイル集合
ＤＩＣＯＭファイルサービスは，ファイル集合の中に一つ以上のファイルを生成しそしてアクセスす
る能力を提供する。ファイル集合は，ファイルＩＤ（節８．２を見よ）がその内で唯一である共通命
名空間を共有するファイルの集積である。ファイル集合内のファイルの順序には意味がつけられてい
ない。
注： １．ＤＩＣＯＭファイルサービスは，ファイル集合内のファイルが同時にアクセス可能なことを必要とし
ない（例えば，テープのような順次アクセス媒体がサポートされる）。
２．ＤＩＣＯＭファイルサービスは，複数「ボリューム／物理媒体」を横切ってファイル集合またはファ
イルを分配する概念を明示的には含まない。しかしながら，そのような特性の媒体フォーマット層による
透過的サポートは，除外されない。
（ファイル集合に対応する）ファイルＩＤ命名空間は，媒体フォーマット定義構造の適切な特性と関
係づけられる。この写像は，各媒体フォーマット仕様に対してＰＳ３．１２の中で明記される（これ
は，特定媒体フォーマットサービスとこのＰＳ３．１０の中で定義されるＤＩＣＯＭファイルサービ
ス間の関係の仕様に不可欠である）。
注:
そのような関係の例は，ファイルＩＤ命名空間を，取り外し可能媒体上のパーソナルコンピュータ媒体フ
ォーマットにおけるボリュームまたはワークステーションファイルシステムにおけるパーティションに
写像することである。他の例は，ファイルＩＤ命名空間を，ディレクトリとそのサブディレクトリのツリ
ーに写像することである。この場合，同じ物理媒体上に複数ファイル集合（ディレクトリあたり一つ）を
サポートする可能性を提供できる。各ファイル集合は，それ自身のＤＩＣＯＭＤＩＲファイルを持つ。相
互運用性を保証するため，ＰＳ３．１２は，ディレクトリとファイル集合のフィルＩＤ命名空間との間の
写像規則を明記する（ＤＩＣＯＭＤＩＲファイルを明白に位置付ける規則を含めて）。
ファイルＩＤ DICOMDIR をもつ一つのファイルが，各ファイル集合の中に含まれる。
各ファイル集合は，ＤＩＣＯＭ規格ＰＳ３．５の中で明記されるＵＩＤ登録規則に従って登録される
ファイル集合ＵＩＤによって唯一に識別される。ファイルがファイル集合に加えられるかまたは除去
されるとき，ファイル集合ＵＩＤは，変化しない。
ファイル集合は，単純な（しかしおそらくは地球的には唯一でない）人間の読むことができる参照を
提供するファイル集合ＩＤによって同様に識別されることがある。ファイル集合ＩＤは，ＩＳＯ ８８
５９（節８．５参照）のＧ０レパートリのサブセットからの零から１６文字の列である。ファイル集
20
2002/09/12
PS 3.10-2001 翻訳原稿
合ＩＤは，媒体フォーマット層で適切な識別子と結合されるか写像されることがある。
注： １．前の注の中で最初に使用されたパーソナルコンピュータ媒体フォーマットの例に続いて，ファイル集
合ＩＤは，ボリュームラベルと同一であると定義されることがある。
２．非ＤＩＣＯＭファイル（ＤＩＣＯＭ規格のこの巻の必要条件に従ってフォーマットされていない内容
をもつファイル）が，ファイル集合の中に存在することがある。そのようなファイルは，表７．１−１の
中で明記されたＤＩＣＯＭファイルメタ情報を含んではならない，そしてＤＩＣＯＭ媒体保存ディレクト
リ（節８．６参照）によってＤＩＣＯＭ形式のファイルとして参照されることはない。
ファイル集合記述子ファイル（“readme”ファイル）は，同様にファイル集合に付属されることがある。
基本ディレクトリＩＯＤの詳細な仕様については，ＰＳ３．３を参照。
８．２
ファイルＩＤ
ファイルは，ファイル集合のコンテキスト内で唯一であるファイルＩＤによって識別される。ファイ
ルＩＤは，ファイルＩＤ構成要素の順序づけられたシーケンスである。ファイルＩＤは１から８構成
要素を含むことがある。各構成要素は，ＩＳＯ ８８５９のＧ０文字集合のサブセット（節８．５を参
照）からの１から８文字の列である。
ファイルＩＤに対するそのような構造（構成要素のシーケンス）は，ＤＩＣＯＭファイルサービスが
階層的モードの中でのファイル選択を組織化することを可能にする。ファイルＩＤ構成要素の構造お
よびその内容の使用に対する規定は，ＤＩＣＯＭ規格によって定義されていない（予約済みファイル
ＩＤ ＤＩＣＯＭＤＩＲを除く。節８．６を参照）。さらに，そのようなファイルＩＤの構造および内
容によって意味は伝達されない。これは，ファイルＩＤがファイル集合の中のファイルに割り当てら
れるときに，生成するＤＩＣＯＭ応用エンティティは，それが望むようにファイルＩＤを構築するこ
とを選ぶことがあることを暗示する。既存のファイルを読み出すまたは新しいファイルを生成する他
のＡＥは，発生元のクリエータがそのような構造に関連させていることがある意味を知ることを必要
とされない。
注： １．ＤＩＣＯＭファイルＩＤは，一般に使用される「ファイル名」と連結された「パス名」の概念に等し
い。４構成要素を持つ有効なＤＩＣＯＭファイルＩＤの例は，バックスラッシュによって分離されて示さ
れる SUBDIR1¥SUBDIR2¥SUBDIR3¥ABCDEFGH である。
２．ＤＩＣＯＭ保存媒体モデルの中で明記されるように，これらのファイルの中に保存されるＤＩＣＯＭ
情報オブジェクトに関係するような意味はファイルＩＤの内容および構造に付けられていない。使用され
る場合は，階層構造は，ファイル集合のファイルを組織化しそしてその選択を容易にする手段を単に提供
する
３．ＤＩＣＯＭファイルサービスは，ファイルＩＤの構成要素の間の「区切り記号」を指定しない。これ
は，各媒体フォーマット層によって特定方法において取り扱われることがある値表現の問題である。ＤＩ
ＣＯＭ ＩＯＤの中では，ファイルＩＤ構成要素は，一般に複数値として扱われ，「バックスラッシュ」
によって分離される。媒体フォーマット層がこの区切り記号を使うことは必要条件ではない。
21
2002/09/12
PS 3.10-2001 翻訳原稿
８．３
ファイル管理の役割とサービス
ＤＩＣＯＭ応用エンティティが，保存媒体の相互交換によって情報の交換に関与するとき，それらは
ＤＩＣＯＭファイルサービスを通して多くの媒体保存操作を実行する：
ａ． Ｍ−ＷＲＩＴＥ，ファイル集合内に新しいファイルを生成する，そしてそれらにファイルＩＤ
を割り当てる；
ｂ． Ｍ−ＲＥＡＤ，それらのファイルＩＤに基づいて既存のファイルを読む；
ｃ． Ｍ−ＤＥＬＥＴＥ，それらのファイルＩＤに基づいて既存のファイルを削除する；
ｄ． Ｍ−ＩＮＱＵＩＲＥ ＦＩＬＥ−ＳＥＴ，ファイル集合内に新しいファイルを生成するために，
可能な空き容量を問い合わせる；
ｅ． Ｍ−ＩＮＱＵＩＲＥ ＦＩＬＥ，ファイル集合内のファイルに対して，ファイル生成の（また
は適用可能な場合は，最後に更新した）日付，時刻を問い合わせる。
ＤＩＣＯＭ応用エンティティは，次の三つの役割の一つ以上をとることがある：
ａ． ファイル集合クリエータ（ＦＳＣ）。そのような応用エンティティは，ＤＩＣＯＭＤＩＲファ
イル（節８．６参照）および零以上のＤＩＣＯＭファイルを生成するために，Ｍ−ＷＲＩＴＥ
操作の手段によってこの役割を実行する。
ｂ． ファイル集合リーダー（ＦＳＲ）。そのような応用エンティティは，ファイル集合の中の一つ
以上のファイルにアクセスするために，Ｍ−ＲＥＡＤ操作の手段によってこの役割を実行する。
ファイル集合リーダーは，ファイル集合の（ＤＩＲＭＤＩＲファイルを含む）ファイルの何れ
も修正しない。
ｃ． ファイル集合アップデータ（ＦＳＵ）。そのような応用エンティティは，Ｍ−ＲＥＡＤ，Ｍ−
ＷＲＩＴＥ，およびＭ−ＤＥＬＥＴＥ操作の手段によってこの役割を実行する。それは，ＤＩ
ＣＯＭＤＩＲファイルを除き，ファイル集合の中の何れかのＤＩＣＯＭファイルの内容を読む
が，しかし修正しない。それは，Ｍ−ＷＲＩＴＥの手段によって追加ファイルを生成する，あ
るいはＭ−ＤＥＬＥＴＥの手段によってファイル集合の中で既存のファイルを削除すること
がある。
注： ファイル集合アップデータ（ＦＳＵ）は，ファイル集合クリエータ（ＦＳＣ）およびファイル集合リーダ
ー（ＦＳＲ）に相当する機能を含むことがあるが，ＦＳＵの役割をサポートする実装は，ＦＳＣまたはＦ
ＳＲの役割を同様にサポートすることを要求されない。
ＤＩＣＯＭ適合性宣言における役割の概念の使用は，ＤＩＣＯＭ媒体保存をサポートする実装の能力
のより正確な表現に帰着するであろう。適合する実装は，下記の選択の一つをサポートする：
ａ． ファイル集合クリエータ
ｂ． ファイル集合リーダー
ｃ． ファイル集合クリエータおよびファイル集合リーダー
ｄ． ファイル集合アップデータ
ｅ． ファイル集合アップデータおよびファイル集合クリエータ
ｆ． ファイル集合アップデータおよびファイル集合リーダー
22
2002/09/12
PS 3.10-2001 翻訳原稿
ｇ． ファイル集合アップデータ，ファイル集合クリエータおよびファイル集合リーダー
ＤＩＣＯＭ応用エンティティによってサポートされる役割に基づいて，ＤＩＣＯＭファイルサービス
は表８．３−１の中で定義される媒体操作をサポートする。
表８．３−１ 媒体操作および役割
媒体操作
役割
M-WRITE
M-READ
M-DELETE
M-INQUIRE
FILE-SET
M-INQUIRE
FILE
FSC
必須
必要ない
必要ない
必須
必要ない
FSR
必要ない
必須
必要ない
必要ない
必須
FSC+FSR
必須
必須
必要ない
必須
必須
FSU
必須
必須
必須
必須
必須
FSU+FSC
必須
必須
必須
必須
必須
FSU+FSR
必須
必須
必須
必須
必須
FSU+FSC+FSR
必須
必須
必須
必須
必須
注： １．媒体の準備は，ＤＩＣＯＭ規格のこの巻の範囲外である。しかしながらファイル集合クリエータによ
って実行されることが仮定される。
２．ＤＩＣＯＭファイルサービスは，ファイル更新能力（例えば，追加）が選択された全ての媒体フォー
マット定義によってサポートされることは要求されない。そのようなＤＩＣＯＭＤＩＲファイルへのファ
イル更新能力のサポートがないものは，ディレクトリ情報の一貫性を保つために，消去しそして新ファイ
ルを生成しなけらばならないことが単に結論される。
３．ファイルの内容が，ＦＳＵによって更新されるか，あるいは変更される必要がある場合は，Ｍ−ＤＥ
ＬＥＴＥ操作にＭ−ＷＲＩＴＥ操作が後続することが，ＤＩＣＯＭ規格のこの巻によって考慮される。Ｆ
ＳＵは，正確にあたかもＦＳＵが新しいファイルを生成しているかのように，ファイルの内部的一貫性，
およびＰＳ３．１０と保存した特定ＳＯＰクラスへのその適合性を保証することに責任を持つ。特にＦＳ
Ｕの実装がファイル内容を更新する必要があるが，しかしファイルプリアンブルの内容を認識することお
よび完全に処理することができない場合には（節７．１参照），プリアンブルの最初の４バイトを “DICM”
に，後続の１２４バイトを 00H に設定することを考慮してもよい。これは，ファイルプリアンブルの内
容とファイル内容の残りとの間で，非一貫性を導入することを避ける。この状況の例は，ファイルプリア
ンブルの中の TIFF IFD 0 オフセットが，ＤＩＣＯＭデータ集合の中に埋めこまれている更なる TIFF IFD
を指す時，および更新操作がこの埋めこまれた TIFF IFD の位置を変える時に起こることがある。
８．４
ファイル内容のアクセス
ＤＩＣＯＭファイルサービスは，ファイル集合の何れのファイルの内容にアクセスする能力を提供す
る。ファイル内容は，零以上のバイトの順序づけられた列である，ここで最初のバイトはファイルの
始まりにあり，そして最後のバイトはファイルの終りにある。
注： バイトの順序づけられた列としてのファイル内容の定義は，ＤＩＣＯＭファイルサービスレベルで提供さ
れる概念に関係している。それは特定媒体上のデータのバイトの物理的順序に対応しないことがある。
ＤＩＣＯＭファイルサービスは，最後のバイトを越えた読み取りアクセスが検出されるそしてＤＩＣ
ＯＭファイルサービス利用者に報告されるであろうことを，ファイルサービスの利用者に保証するこ
とによって，ファイルの終わりの区切りを管理する。この区切り機能は媒体フォーマット層によって
実行される。
23
2002/09/12
PS 3.10-2001 翻訳原稿
ＤＩＣＯＭファイルサービスは，下記に対する能力を提供する：
−
ファイルの内容の零以上のバイトを読むためにＭ−ＲＥＡＤを実行するＦＳＲまたはＦＳＵ；
−
ファイルの内容を作る一つ以上のバイトを書くためにＭ−ＷＲＩＴＥを実行するＦＳＣまた
はＦＳＵ。
注： ＤＩＣＯＭファイルサービスは，ファイルの内容の選択読み取りアクセスまたは書き込みアクセス（例え
ば，シークまたは追加）についての特定の能力を必要としない。しかしながら，それはそのような特性を
サポートする特定媒体フォーマット定義を制限するものではない。
８．５
文字集合
ファイルＩＤおよびファイル集合ＩＤは，ＩＳＯ ８８５９のＧ０文字集合のサブセットからの文字で
作られる文字列である。以下の文字がこのサブセットを構成する：
A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z （大文字）
1, 2, 3, 4, 5, 6, 7, 8, 9, 0 および _（下線）
注： １．これは，SPACE が含まれていないことを除いて，制御列に対して定義される文字集合である（値表
現ＣＳ，ＤＩＣＯＭ規格ＰＳ３．５を参照）。
２．この文字集合は，ファイルＩＤおよびファイル集合ＩＤの中の文字を，ＰＳ３．１２の中で定義され
たファイルシステムの中で予約された文字及び区切り記号と衝突しないものに制限するために選択され
た。ＰＳ３．１２の中で定義される構成要素区切り記号または他の必要とされる境界は，ファイルＩＤま
たはファイル集合ＩＤの部分ではない。
８．６
予約済みＤＩＣＯＭＤＩＲファイルＩＤ
ファイルＩＤ，ＤＩＣＯＭＤＩＲを持つ単一のファイルは，全てのファイル集合の一員として存在す
る。このファイルＩＤは，単一構成要素でつくられる（ファイルＩＤ構造については節８．２を参照）。
それは全ファイル集合についての一般情報を含むＤＩＣＯＭ媒体保存ディレクトリを含む（基本ディ
レクトリＩＯＤの詳細仕様についてはＰＳ３．３を参照）。この一般情報は，常に存在するが，しか
し任意選択としてディレクトリ内容は，それが必要でない環境においては空にしておかれることがあ
る。ＤＩＣＯＭＤＩＲファイルがファイル集合の中に存在しない場合は，ファイル集合はＤＩＣＯＭ
規格のＰＳ３．１０に適合しない。ＤＩＣＯＭＤＩＲは，それが属するファイル集合の外部のファイ
ルを参照しない。
注： １．ＤＩＣＯＭＤＩＲファイルの内容の二例が，付属書Ａの中で見いだせるであろう。
２．ファイル集合の原点を，特定媒体フォーマットの中の特定ディレクトリノードに写像することを選ぶ
場合は， ＤＩＣＯＭＤＩＲファイルＩＤを含んでファイルＩＤは，このディレクトリノードパス名と関
係する。
ＤＩＣＯＭＤＩＲファイルは，媒体保存ディレクトリＳＯＰクラスを符号化するために明示的ＶＲリ
トルエンディアン転送構文（UID = 1.2.840.10008.1.2.1）を使用する。ＤＩＣＯＭＤＩＲファイルは，こ
の規格の節７の中で明記されるＤＩＣＯＭファイルフォーマットに従う。特に：
ａ． ファイルメタ情報の中のＳＯＰクラスＵＩＤ（ＤＩＣＯＭＤＩＲファイルのヘッダ）は，この
規格のＰＳ３．４の中で媒体保存ディレクトリＳＯＰクラスのために明記される値を持つ。
ｂ． ファイルメタ情報（ＤＩＣＯＭＤＩＲファイルのヘッダ）の中のＳＯＰインスタンスＵＩＤは，
ファイル集合ＵＩＤ値を含む。ファイル集合ＵＩＤは，零以上のＤＩＣＯＭファイルをもつフ
24
2002/09/12
PS 3.10-2001 翻訳原稿
ァイル集合を生成する応用エンティティ（ＦＳＣ役割，節８．３を参照）によって割り当てら
れる。このファイル集合ＵＩＤ値は，ファイル集合の内容を読み出すまたは更新する他のどの
応用エンティティによっても変更されない。
注： １．この方針は，ファイル集合が，ファイルがその内で生成されるまたは読み出されることがある「コン
テナ」の抽象概念であることを反映する。ファイル集合ＵＩＤは，「コンテナ」に関係しており，その内
容にではない。ＤＩＣＯＭファイルサービスの中のファイル集合は，選択された媒体フォーマットのサポ
ート機能（例えばボリュームまたはパーティション）に写像されることが意図される。
２．この規格は，ファイル集合の重複コピーをつくることを阻止しない（即ち，同一のファイル集合ＵＩ
Ｄをもつファイル集合）。しかしながら，ファイル集合の管理された定義域内では，定義域特有の方針が，
そのような重複ファイル集合の生成を阻止するために使用されることがある。
９
適合性要求
ＤＩＣＯＭ規格ＰＳ３．１０の実装は下記の通りである：
ａ） ＰＳ３．２の中で定義された枠組みに従って，ＰＳ３．１１応用プロファイルに基づいた適合
性宣言を持つ；
ｂ） この巻の節７の中で明記されるＤＩＣＯＭファイルフォーマットの必要条件に合致する；
ｃ） 節８．３の中で識別される一つ以上の役割の中で，この巻の節８の中で明記されるＤＩＣＯＭ
ファイルサービスをサポートする；
ｄ） サポートする役割に従って表８．３−１の中で定義される媒体操作を実行する；
ｅ） この規格のＰＳ３．４における媒体保存ディレクトリＳＯＰクラスの中で明記される内容をも
つＤＩＣＯＭＤＩＲファイルをサポートする。
25
2002/09/12
PS 3.10-2001 翻訳原稿
付属書Ａ（情報）
ＤＩＣＯＭＤＩＲファイル内容の例
この付属書は，基本ディレクトリ情報オブジェクトのためにＰＳ３．３の中で導入された例の選択さ
れた局面に基づくファイル内容の例を提供する。これは規格としての付属書ではない。それは単なる
例であり，ＤＩＣＯＭＤＩＲファイルの中に保存されるＤＩＣＯＭディレクトリの構成を読者がより
よく理解することを助けることを単に意図している。
Ａ．１
単純なディレクトリ内容の例
表Ａ．１−１は，単純化された方法で，単純なＤＩＣＯＭＤＩＲファイル（即ち，複数参照ファイル
をもたない）の内容を示す。要素の値は，かぎ括弧の間に書かれる（例えば，[1.840.10008.34.7.6]）。
バイトオフセットは，中括弧の間に書かれるシンボル値によって示される（例えば，{1493}）。
図Ａ．１−１ ディレクトリ内容の例
メタ情報
128バイト
4 バイト
0002,0000
0002,0001
0002,0002
ファイルプリアンブル [全てのバイトを 00H にセットする]
ＤＩＣＯＭプリフィックス {DICOM}
グループ長さ
ファイルメタ情報版 [0001]
ＳＯＰクラスＵＩＤ [1.2.840.10008.1.3.10]
0002,0010
ＳＯＰインスタンスＵＩＤ [1.840.23856.36.45.3]
転送構文ＵＩＤ [1.840.10008.1.1]
0002,0012
実装クラスＵＩＤ [1.840.23856.34.90.3]
・・・
・・・
0002,0003
ファイル集 0004,1130
ファイル集合ＩＤ [EXAMPLE]
合識別
一般ディレ 0004,1200
クトリ情報 0004,1202
ルートディレクトリエンティティの最初のレコードのオフセット {1236}
ルートディレクトリエンティティの最後のレコードのオフセット {6F18}
0004,1212
ファイル集合一貫性フラグ [0000H]
・・・
0004,1220
・・
ディレクトリレコードシーケンス
このデータ要素値は以下の項目シーケンスを含む。
{1236}
項目タグ
FFFE,E000
項目データ要素（以下のデータ要素を含む）
患者Ｂ
0004,1400
ディレクトリエンティティの次ディレクトリレコードのオフセット{1493}
レコード使用中フラグ [FFFFH]
ディレクト 0004,1410
リレコード 0004,1420
・・・
ディレクトリレコードタイプ [PATIENT]
0004,1500
参照ファイルＩＤ [DIR¥THRE¥KC48]
ファイルの参照ＳＯＰクラスＵＩＤ [1.840.10008.3.1.2.1.1]
0004,1510
0004,1511
0004,1512
選択キー
参照下位ディレクトリエンティティのオフセット（例には示されていない)
・・・
0004,1430
ファイルの参照ＳＯＰインスタンスＵＩＤ [1.840.23856.3.9879]
ファイルの参照転送構文ＵＩＤ [1.840.10008.1.2.2]
0010,0020
患者名 [Patient B]
患者ＩＤ [550-31-8623]
・・・
・・・
0010,0010
項目区切り FFFE,E00D 項目が無定義長のときのみ，項目区切りタグが存在する。
タグ
{1493}
項目タグ
FFFE,E000
項目データ要素（以下のデータ要素を含む）
26
2002/09/12
PS 3.10-2001 翻訳原稿
患者Ａ
0004,1400
ディレクト 0004,1410
リレコード 0004,1420
・・・
参照下位ディレクトリエンティティのオフセット {1829}
・・・
0004,1430
・・・
ディレクトリレコードタイプ [PATIENT]
0004,1500
参照ファイルＩＤ [DIR¥TDRE¥GC48]
ファイルの参照ＳＯＰクラスＵＩＤ [1.840.10008.3.1.2.1.1]
0004,1510
0004,1511
0004,1512
選択キー
ディレクトリエンティティの次ディレクトリレコードのオフセット{6F18}
レコード使用中フラグ [FFFFH]
ファイルの参照ＳＯＰインスタンスＵＩＤ [1.840.23856.3.9789]
ファイルの参照転送構文ＵＩＤ [1.840.10008.1.2.2]
0010,0020
患者名 [Patient A]
患者ＩＤ [535-71-7321]
・・・
・・・
0010,0010
項目区切り FFFE,E00D 項目が無定義長のときのみ，項目区切りタグが存在する。
タグ
{1829}
項目タグ
FFFE,E000
項目データ要素（以下のデータ要素を含む）
検査１
0004,1400
ディレクトリエンティティの次ディレクトリレコードのオフセット（例には
ディレクト
リレコード 0004,1410
0004,1420
選択キー
示されていない）
レコード使用中フラグ [FFFFH]
参照下位ディレクトリエンティティのオフセット {2299}
・・・
0004,1430
・・・
ディレクトリレコードタイプ [STUDY]
0020,000D
0020,0010
検査インスタンスＵＩＤ [1.840.4656.23.4568745]
検査ＩＤ [srt78UJ]
・・・
・・・
項目区切り FFFE,E00D 項目が無定義長のとき，項目区切りタグが存在する。
タグ
{2299}
項目タグ
FFFE,E000
項目データ要素（以下のデータ要素を含む）
シリーズ１ 0004,1400
ディレクトリエンティティの次ディレクトリレコードのオフセット（例には
ディレクト
示されていない）
レコード使用中フラグ [FFFFH]
リレコード 0004,1410
0004,1420
選択キー
参照下位ディレクトリエンティティのオフセット {2681}
・・・
0004,1430
・・・
ディレクトリレコードタイプ [SERIES]
0008,0060
0020,0011
モダリティ [NM]
シリーズ番号 [2]
・・・
・・・
項目区切り FFFE,E00D 項目が無定義長のとき，項目区切りタグが存在する。
タグ
{2681}
項目タグ
FFFE,E000
項目データ要素（下記のデータ要素を含む）
画像１
0004,1400
ディレクトリエンティティの次ディレクトリレコードのオフセット{3419}
レコード使用中フラグ [FFFFH]
ディレクト 0004,1410
リレコード 0004,1420
・・・
ディレクトリレコードタイプ [IMAGE]
0004,1500
参照ファイルＩＤ [DIR¥TDRI¥3856G3]
ファイルの参照ＳＯＰクラスＵＩＤ [1.840.10008.5.1.4.1.1.5]
0004,1510
0004,1511
0004,1512
選択キー
参照下位ディレクトリエンティティのオフセット [00000000H]
・・・
0004,1430
ファイルの参照ＳＯＰインスタンスＵＩＤ [1.840.34.56.78999654.234]
ファイルの参照転送構文ＵＩＤ [1.840.10008.1.2.2]
0020,0013
画像ＳＯＰインスタンスＵＩＤ [1.840.34.56.78999654.234]
画像番号 [1]
・・・
・・・
0008,0018
27
2002/09/12
PS 3.10-2001 翻訳原稿
項目区切り FFFE,E00D 項目が無定義長のとき，項目区切りタグが存在する。
タグ
{3419}
項目タグ
FFFE,E000
項目データ要素（下記のデータ要素を含む）
画像２
0004,1400
ディレクトリエンティティの次ディレクトリレコードのオフセット（例には
ディレクト
リレコード 0004,1410
0004,1420
参照下位ディレクトリエンティティのオフセット [00000000H]
・・・
0004,1430
・・・
ディレクトリレコードタイプ [IMAGE]
0004,1500
参照ファイルＩＤ [DIR¥TDRI¥3856G7]
ファイルの参照ＳＯＰクラスＵＩＤ [1.840.10008.5.1.4.1.1.5]
0004,1510
0004,1511
0004,1512
選択キー
示されていない）
レコード使用中フラグ [FFFFH]
ファイルの参照ＳＯＰインスタンスＵＩＤ [1.840.34.56.78999654.235]
ファイルの参照転送構文ＵＩＤ [1.840.10008.1.2.2]
0020,0013
画像ＳＯＰインスタンスＵＩＤ [1.840.34.56.78999654.235]
画像番号 [2]
・・・
・・・
0008,0018
項目区切タ FFFE,E00D 項目が無定義長のとき，項目区切りタグが存在する。
グ
・
・
{6F18}
項目タグ
FFFE,E000
項目データ要素（次のデータ要素を含む）
患者Ｃ
0004,1400
ディレクト
ディレクトリエンティティの次ディレクトリレコードのオフセット
{00000000H}
リレコード 0004,1410
0004,1430
レコード 使用中フラグ [FFFFH]
ディレクトリレコードタイプ [PATIENT]
選択キー
・・・
・・・
0010,0010
0010,0020
患者名 [Patient C]
患者ＩＤ [523-61-8765]
・・・
・・・
項目区切り FFFE,E00D 項目が無定義長のとき，項目区切りタグが存在する。
タグ
シーケンス FFFE,E0DD ディレクトリレコードシーケンス (0004,1220) が無定義長のときだけ，ディレクトリレコードシーケ
区切りタグ
Ａ．２
ンスデータ要素の値の終わりを区切るために使われる
複数参照ファイルをもつＤＩＣＯＭＤＩＲファイル内容の例
この節はＤＩＣＯＭにおいて以前は定義されていた。これは現在退役した。節ＰＳ３．３−１９９８
を参照。
28
2002/09/12
PS 3.10-2001 翻訳原稿
付属書Ｂ（情報）
(0002,0000)
(0002,0001)
(0002,0002)
(0002,0003)
(0002,0010)
(0002,0012)
(0002,0013)
(0002,0016)
(0002,0100)
(0002,0102)
(FFFC,FFFC)
1.2.840.10008.1.2.1
属性タグおよびＵＩＤの索引
17, 26
17, 26
17, 26
17, 26
18, 26
18, 26
18
18
18
18
19
18, 24
29
2002/09/12