AAO
Integrating the Healthcare Enterprise

IHE 眼科テクニカルフレームワーク
Year 3: 2008
ボリュームⅡ
総合プロファイル

改正3.3
試験的実装版
発行日：2008年4月18日

Copyright © 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

目次
1 序章……………………………………………………………….....…………........................................5
1.1 テクニカルフレームワークの概要 ....................................……………...................................5
1.2 ボリュームIIの概要..........................................................……………......................................5
1.3 対象読者........................................................................……………........................................6
1.4 規格との関係..................................................................…….......………................................6
1.5 実際のアーキテクチャとの関係 ...............................................…..........................………….7
1.6 コメント...............................................................................................................…………….7
1.7 著作権...........................................................................................................…………….........7
2 表記規則…...........................................................................................................….…..……………8
2.1 汎用IHEトランザクションモデル..................…………......................................................….8
2.2 DICOM 使用上の規則......................................................……………......................................9
2.3 コード体系の利用について…………….……………………………………………………….…11
3 フレームワークの概要....………...........................................................................................……..12
4 IHEトランザクション.............................................................................................……………......13
4.1 撮影実施リストの問い合わせ [EYECARE-1]……….....................................................……13
4.1.1 適用範囲……………………………………………………………………………………….13
4.1.2 ユースケースにおける役割.........……………................................................................13
4.1.3 参照する規格.....................................…………….........................................................144.1.4 相互作用図.......................................……………...........................................................14
4.1.5 患者ID発行者….............................……………..............................................................15
4.2 モダリティ画像／エビデンス保存[EYECARE-2]...............................…………….................16
4.2.1 適用範囲………………………………………………………………………………….……16
4.2.2 ユースケースにおける役割.............……………............................................................16
4.2.3 参照する規格...............................................................................……………...............16
4.2.4 相互作用図................................................................................…………............…......17
4.2.5 眼科画像オプション................................................................………….......................18
4.2.6 エビデンス文書用カプセル化PDFオプション…………………………………………….20
4.2.7 眼科測定値オプション……………………………………………………….……………...22
4.2.8 眼科相対画像位置コードオプション…………………….…………………………………22
4.2.9 立体的位置関係オプション…………………………………….……………………………24
4.3 画像および測定値の検索取得[EYECARE-3] ...............................…………..…………………24
4.3.1 適用範囲………………………………………………………………..……………………..24
4.3.2 ユースケースにおける役割............................................…..........……………….………24
4.3.3 参照する規格................................................……………..…...………………..…………25
4.3.4 相互作用図……………………………………………………………………..……………..25
4.3.5 眼科画像オプション…......................…………..…………………..………………………26
4.3.6 眼科相対画像位置コードオプション…………..………………………………..………..26
4.3.7 立体的位置関係オプション………….………………………………………….…………..27
4.4 エビデンス文書の問い合わせ [EYECARE-4].........…………………………………………….27
4.4.1 適用範囲………………………………….……………………………………………………27
4.4.2 ユースケースにおける役割………………………………………………………………….27

1
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.4.3 参照する規格...............................................……………………………………………….28
4.4.4 相互作用図 ……………………………………………………………………………..…….28
4.4.5 DICOM カプセル化PDF問い合わせ属性…………………………………………………..29
4.5 画像、測定値およびカプセル化文書の問い合わせ[EYECARE-5]..........……….…………….29
4.5.1 適用範囲……………………………………………………………………………………….29
4.5.2 ユースケースにおける役割………………………………………………………………….29
4.5.3 参照する規格………………………………………………………………………………....30
4.5.4 相互作用図………..…………………………………………………………………………..30
4.5.5 患者ID発行者のサポート………………………… ……………………….………………..31
4.6 モダリティ処理手順完了／中止[EYECARE-6]…….……..............………….…............……..31
4.6.1 適用範囲…………………………..…………………………..........…………………………31
4.6.2 ユースケースにおける役割………..………………………………………………………..32
4.6.3 参照する規格…………………………………………………….……………………………32
4.6.4 相互作用図 ……………………………………………………….…………………………..32
4.7 表示可能報告書の保存[EYECARE-7] ..............…………………………………….......……….35
4.7.1 適用範囲……………………………………………………………………………………….35
4.7.2 ユースケースにおける役割…………………….……………………………………………36
4.7.3 参照する規格………..………………………………………………………………………..36
4.7.4 相互作用図…………...……………………………………………………………………….36
4.7.5 DICOMカプセル化文書標準拡張属性………………………………………………………38
4.8 表示可能報告書問い合わせ[EYECARE-8]…………….......................……………….......…...41
4.8.1 適用範囲……………………………………………………………………………………….41
4.8.2 ユースケースにおける役割........................…………....................................................41
4.8.3 参照する規格...........................................................…………...…………………………41
4.8.4 相互作用図……….........................................................................................................42
4.9 表示可能報告書検索取得 [EYECARE-9]……….….............………………………….......…...44
4.9.1 適用範囲…………………………………………………………….…………………………44
4.9.2 ユースケースにおける役割...............………….........................…………………………44
4.9.3 参照する規格.....................………………………………………………………………….44
4.9.4 相互作用図.....................................…………………………………………………..…….45

2
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

はじめに
医療連携のための情報統合化プロジェクト（IHE）は、現代の医療機関を支える情報システムの統合を促進するための構想である。その基本的な目標は、患者の治療において、診断に必要な全ての情報が、医療関係者に対し、正確かつ有効であることである。IHE構想は統合を促進するためのプロセスおよび討議の場である。具体的な臨床的目標を達成するため、確立されたメッセージ規格を実装するための技術的枠組みを定義する。この枠組みを実施するための厳格なテストプロセスを含み、教育セッションを開催し、この枠組みの利点を提示し業界およびユーザによる導入を奨励するために医療専門家の主要ミーティングにて公開する。
IHE構想に使用されているアプローチは新しい統合規格を定義することではなく、必要に応じて構成の選択肢を明確にしながら、統合された形のなかで既存の規格（HL7、DICOM、IETF、その他）の使用をサポートすることである。既存の規格の明確化あるいは拡張が必要な場合は、IHEは関連する標準化団体に意見を照会する。
この構想には様々な医療専門領域や地域から、数多くのスポンサーおよび協力団体が参加している。
北米の主要スポンサーは、the American Academy of Ophthalmology (AAO)、the Healthcare
Information and Management Systems Society (HIMSS) および the Radiological Society of North
America (RSNA)である。IHEカナダも組織された。IHE欧州（IHE-EUR）は大規模な組織連合に支持されており、その連合にはthe European Society of Cardiology (ESC)、European Association ofRadiology (EAR) および European Congress of Radiologists (ECR)、the Coordination Committee of
the Radiological and Electromedical Industries (COCIR)、Deutsche Röntgengesellschaft (DRG)、the
EuroPACS Association、Groupement pour la Modernisation du Système d'Information Hospitalier(GMSIH)、Société Francaise de Radiologie (SFR) および Società Italiana di Radiologia Medica(SIRM)が含まれる。日本では経済産業省（METI）、厚生労働省、およびMEDIS-DCがIHE-Jを支援
し、協力団体としては日本画像医療システム工業会（JIRA）、保健医療福祉情報システム工業会（JAHIS）、日本医学放射線学会（JRS）、日本放射線技術学会（JSRT）、および日本医療情報学会（JAMI）がある。IHEプロセスの拡張には、分野や地域の境界線を超えて、医療専門家を代表する他の組織にも参加を要請している。
多様なドメイン（ITインフラストラクチャー、心臓学、臨床検査、放射線学、眼科等）のIHEテクニ
カルフレームワークは、医療情報共有を促進するため、情報統合実現を目的に、既存規格の実装方
法について定義を行う。テクニカルフレームワークは、公開レビュー期間を経て毎年拡張され、正誤表の確認と修正を通じて定期的に管理されている。これらのテクニカルフレームワークの現行バージョンは、インターネット（www.aao.org、www.rsna.org/IHE、http://www.hIMss.org/IHEまたはwww.ihe.net.）から入手可能である。

3
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

IHEテクニカルフレームワークは、IHEアクタと呼ばれる医療機関の機能要素のサブセットを特定し、調整された、規格ベースのトランザクションを示しながら、アクタの相互作用を規定する。トランザクションについては、段階を追って詳細に記述する。このボリュームIでは、特定の臨床ニーズに対応する「統合プロファイル」と呼ばれる機能単位にまとめられたトランザクションを提示することで、IHEの機能について概観を提供している。ボリュームIIでは、IHEトランザクションについて、詳細な技術的仕様を説明する。

最終版から生じたコメントは下記の場所で提出できる：
http://forums.rsna.orgの”Integrating the Healthcare Enterprise”フォーラムで”IHE Eye Care
Technical Framework version 3.3 Public Comment”サブフォーラムを選択する。

4
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

序章

1
1.1

テクニカルフレームワークの概要

本書（IHE眼科テクニカルフレームワーク：IHE EYECARE-TF）は、眼科における情報統合実現を目的に、既存規格の実装方法について定義を行う。こうした統合により、患者の治療の最適化をサポートする医療情報統合が促進される。
EFECARE-TFは、レビュー期間に正誤表の確認と修正を通じて定期的に見直され、毎年更新される。
本書の最新版はインターネット（www.aao.org）で入手可能である。
EYECARE-TFは、IHE アクタと呼ばれる医療機関の機能要素のサブセットを特定し、調整された、
規格ベースのトランザクションを示しながら、アクタの相互作用を規定する。トランザクションについては、段階を追って詳細に記述する。このボリュームIの最新版では、特定の臨床ニーズに対応
する「統合プロファイル（Integration Profile）」と呼ばれる機能単位にまとめられたトランザクシ
ョンを提示することで、IHEの機能について概観を提供している。ボリュームIIでは、眼科のニーズに対応したIHEトランザクションについて、詳細な技術的仕様を説明する。
EYECARE-TFは、関連する IHE テクニカルフレームワークのセットの一部である。テクニカルフ
レームワーク全体は、次のような分野固有の文書で構成されている。
•

IHE眼科テクニカルフレームワーク•

IHE心臓学テクニカルフレームワーク•

IHEITインフラテクニカルフレームワーク•

IHE放射線テクニカルフレームワーク•

IHE臨床検査テクニカルフレームワーク•

その他

IHE眼科統合プロファイルでは、その他の分野のテクニカルフレームで定義されたトランザクション
を使用、相互参照している。その他のフレームワークの参照に関する表記規則は、ボリュームIの1.6.4
を参照すること。
1.2

ボリュームIIの概要

第2節はIHEのもとでの実装されるトランザクションを定義するための本ボリュームで使われている表記規則を示す。
第3節は分散医療環境の機能要素を定義するため、IHEで使用されるIHEアクタとトランザクションの概念の概要を規定する。
第4節は、トランザクションEYECARE-1からEYECARE-9を詳細に定義し、それぞれのアクタの役
割、使用される標準規約、交換される情報について規定する。

5
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

本ボリュームの本論の後の附属書ではIHEデータモデルとトランザクションの技術的な詳細を明確に規定している。IHEテクニカルフレームワークおよび関連する標準（現行のHL7やDICOM）で使用される専門用語および略語はボリュームIに提示する。
1.3

対象読者

本書の想定される対象読者を以下に示す：•

医療情報システムの統合の技術面に関心のある医師•

IHE活動に関係するベンダの技術担当者•

医療機関のIT部門•

規格の開発に関係する専門家

1.4

規格との関係

IHEテクニカルフレームワークでは、分散医療環境の機能要素（IHEアクタと呼ぶ）を、医療機関におけるアクタ間の相互関係という観点だけから特定する。現時点の開発レベルでは、HL7、DICOM、およびさまざまなウェッブ規格に基づいて調整された一連のトランザクションが定義されている。
IHE構想の範囲が拡大すると共に、他の規格に基づくトランザクションも必要に応じて組み込まれるものがある。

状況によって、IHEは、これらの規格がサポートする特定のオプションも推奨しているが、これらの規格と矛盾する技術的な選択をIHEが推奨することはない。IHEの方針としては、既存の規格に問題があったり、規格を拡張しなければならない場合には、各標準化団体に、それぞれの適合性あるいは各標準化戦略内での解決を依頼することとしている。

したがって、IHE自体は規格ではなく実装するためのフレームワークである。規格が妥当でない場合
はIHEを参照すること。製品が規格に準拠していると宣言するには、個別の規格を直接参照する必要がある。さらに、IHE統合機能を実装したベンダは、IHE統合宣言書を使用して、IHEテクニカルフ
レームワークの仕様に製品が準拠していることを記述しなければならない。IHE統合宣言書の目的は、対応する製品のユーザに、均一の方法で、その製品がサポートするように設計されたIHE機能を伝えることである。IHE統合宣言書を発行するベンダは、その内容に関する全責任を負わなければならな
い。IHEのアクタと統合プロファイルの概念を理解しているユーザは、IHE統合宣言書と他の実装を比較することで、どの程度の統合レベルにあるかを判断することができる。IHEは、実装者に対し、IHEテクニカルフレームワークに従って実装された製品が、IHEの基になっている規格の完全な要件も満たすことを推奨している。またこれにより、その製品は、各規格に準拠して実装されてはいるがIHEテクニカルフレームワークには完全に従っていない他の製品と、統合の下位レベルでは対話可能となるべきである。

6
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

1.5

実際のアーキテクチャとの関係

IHEテクニカルフレームワークで記述されているIHEアクタとトランザクションは、現実の医療情報システム環境を抽象化したものである。従来、各トランザクションは特定の製品カテゴリごと(病院情報システム（HIS）、電子カルテ、業務管理システム、画像管理システムまたは撮影装置など)に実行されるが、IHE テクニカルフレームワークでは、あえてそのような機能やアクタを上記の製品カテゴリと関連させることを避けている。各アクタについて、IHEテクニカルフレームワークでは、統合する情報システムと関連のある機能だけが定義されている。したがって、アクタのIHE定義を、アクタを実装する製品の完全な定義と考えてはならず、また、フレームワーク自体を、医療情報シ
ステムのアーキテクチャを包括的に記述するものとみなしてはならない。
アクタとトランザクションを定義する理由は、医療情報システム環境の機能コンポーネント間の相互作用を定義するための基礎を提供することである。単一の物理的な製品が複数の機能を実装する
ような状況においては、製品と環境の外部機能との間のインターフェイスのみが重要であるとIHE
構想は考える。したがって、IHE構想は、すべてを含む単一の情報システムに基づく統合環境と、協力して同じ目標を実現する複数のシステムに基づく統合環境を比較したときの相対的なメリットに関しては、いかなる立場もとらない。ただし、IHEテクニカルフレームワークの可能性を効果的に示すため、IHEのデモンストレーションでは、IHEテクニカルフレームワークに基づく複数ベンダのシ
ステムの統合が強調されている。
1.6

コメント

AAOは、この文書ならびにIHE構想に関するコメントを歓迎する。コメントは、http://forums.rsna.org/のディスカッションサーバーまで、又は以下の担当者宛メールアドレスまでお送りいただきたい。
Flora Lum, M.D.
Policy Director, Quality of Care and Knowledge Base Development
American Academy of Ophthalmology
e-mail: flum@aao.org
1.7

著作権

Health Level Seven, Inc.は、IHEに対して、HL7規格の表の複製を許可している。本書に掲載されているHL7の表は、Health Level Seven, Inc.が著作権を保有し、無断複写・複製・転載を禁ず。
米国電機工業会 (NEMA)は、DICOM 規格の一部をIHEが使用することを許可している。
これらの文書から引用されている資料については、使用箇所においてその旨を示す。

7
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

表記規則

2

この文書では、以下の表記規則を使用して、フレームワークの概念を表し、IHEテクニカルフレーム
ワークの基になる規格を適用する方法を指定する。
2.1

汎用IHEトランザクションモデル

トランザクションの説明は第4章に示す。各トランザクションの説明においてはアクタとアクタの役
割、それにアクタ間のトランザクションをユースケースとして示している。
汎用IHEトランザクションの説明は下記の要素から成っている。
•

適用範囲：トランザクションの簡単な説明•

ユースケースにおける役割：下記例のような簡単なダイアグラムでのアクタ群およびその役
割の定義文書アクタ

アクタ

トランザクション• 参照する規格：トランザクションに使用される規格（特定の部、章、節を明記）• 相互作用図：アクタとトランザクションに関係する処理を、アクタを四角形で表し、下方向に
時間の流れを示した図による記述。

8
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

アクタ

アクタ

アクタ

メッセージ 1
メッセージ 2

メッセージ 3

IHEテクニカルフレームワークで使用される相互作用図のモデル化は「The Unified Modeling
Language User Guide」(Grady Booch, James Rumbaugh, Ivar Jacobson )(ISBN0-201-57168-4)にならった。なお、図において単なる確認メッセージは簡潔さのために省略している。
• メッセージ定義：トランザクションに含まれるメッセージ、メッセージをトリガするイベン
ト、イベントのセマンティクス、メッセージが受信側に引き起こすアクションの定義。
2.2

DICOM使用上の規則

本書で記載するDICOMトランザクションの一部では特定のタイプ2とタイプ3の属性に対し元々の
DICOMよりも要件を強めている。これについては第4章と附属書で明示的に説明している。
IHEではDICOMタイプ2属性（例えば患者名や患者ID）について、ソース側が有効な値を持たない場
合はlengthを０として送信しなくてはいけないと決めている。言い換えれば、ソース側はデフォル
ト値を与えてはいけないし、受ける側は length 0の値を処理できなくてはならない。
IHEではDICOM問い合わせにおけるSCUとSCPがサポートすべきマッチングキーとリターンキーについても定めている。マッチングキーはSCPがSCUに返すインスタンスの選択に使われるがリター
ンキーは選択には使われず、返すべきデータを定めるだけである。
•

SCU必須マッチングキー
問い合わせSCUが選択基準としてユーザに指定させることが出来なければならないキー。
指定する方法（例えば、値を入力させるか選択させる等）はIHEの範囲外である。

9
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション•

SCP必須マッチングキー：
IHEの必須マッチングキーはあたかもそれがDICOMで要求されているマッチングキーであるかのように処理される。ほとんどの場合IHEで要求されるマッチングキーはそのまま
DICOMで要求されるマッチングキーである。

•

SCU必須リターンキー：
問い合わせSCUが問い合わせSCPに依頼し、問い合わせ応答で受信し、必要ならユーザに見せるキーである。問い合わせSCUのユーザがリターンキーを指定する方法（例えば、デフォルトにするか、チェックボックスにチェックするか等）やリターンキーを見る方法はIHEの範囲外である。

•

SCP必須リターンキー：
IHEが要求するリターンキーのうち、タイプ１、タイプ２のものはDICOMの定義通り処理される。タイプ３のものはDICOMにおけるタイプ２に相当する処理がされる。

フレームワーク内の問い合わせキーの要件表は SCUおよび SCPに対する要件を規定する下記のような凡例を用いる。
R

必須

O

オプション

さらに下記の修飾子も使われる。
R+

DICOMの要求を拡張してIHEの必須としたもの

R*

表示が必須ではない属性

表2.2-1はマッチングキーとリターンキーの定義の例を示す。
表2.2-1 画像問い合わせマッチングキーおよびリターンキー
属性名

タグ(0040,4034)

問い合わせ
マッチングキー
SCU
SCP
R+
R

問い合わせ
リターンキー
SCU
SCP
R+*
R

予約済み実行者シ
ーケンス＞実行者コードシ
ーケンス＞＞コード値＞＞コード体系識
別子＞＞コード意味(0040,4009)

R+

R

R+*

R

(0008,0100)(0008,0102)

R+
R+

R
R

R+*
R+*

R
R

(0008,0104)

-

-

R+

R

＞実行者の名前(0040,4037)

R+

R+

R+

R+

10
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNA

注

問い合わせマッチングキーのSCUまたはSCP
はコード意味の値には使用しない。

IHE 眼科テクニカルフレームワーク、vol.II：トランザクション＞実行者の組織(0040,4036)

O

O

O

R+

参照検査要素シー
ケンス(0008,1111)

O

O

O

O

＞参照SOPクラス
UID＞参照SOPインス
タンスUID
入力情報シーケンス(0008,1150)

O

O

O

R

(0008,1155)

O

O

O

R

(0040,4021)

O

O

R+*

R

2.3

コード体系の利用について

IHEはコード体系や用語集（コード化集合：coded entities）の作成やメンテナン、指定は行わない。
利用可能な場合は HL7とDICOMで決めたコード体系を優先して使わなければいけない。規格で使うべきリソースが明示的に決められていない場合、ライセンスと著作権の問題をクリアしてさえいれ
ば、実装者はどのリソース（独自のもの、若しくはローカルなものを含む）を使ってもよい。

11
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

3

フレームワークの概要

IHEテクニカルフレームワークは、アクタがトランザクションを介して相互に作用するという考えに基づいている。
アクタは情報システムまたは情報システムのコンポーネントで、その医療機関における運用に関係する情報を生成、管理、操作する。
トランザクションはアクタ間の相互作用で、規格に基づいたメッセージを介して必要な情報を伝達するものである。
アクタとトランザクションの仕様は「統合プロファイル」で定義する（EYECARE-TF 1参照）。

12
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4

IHEトランザクション

本章では各IHEトランザクションの詳細を定義する。すなわち、使用する規格、転送する情報、どのトランザクションが必須またはオプションであるかについて定義する。
撮影実施リストの問い合わせ［EYECARE-1］

4.1

本トランザクションは、撮影実施リストの問い合わせ［RAD-5］（RAD-2:4.5参照）に、いくつかの特徴を追加したものである。
注-1：放射線TFでは、撮影装置がワークリスト問い合わせ選択肢から少なくとも1つ（患者および／または広範囲問い合わせ）をサポートすることを要請している。眼科では、両方のオプションのサポー
トを要求している。EYECARE-TF1:3.2を参照。

4.1.1

適用範囲

本トランザクションはスキャンまたは撮影時に撮影装置で実行される。患者が予約済み検査手続きに来院した時、当該検査手続きを実行するユーザは、主要な情報要素を調べて、検査手続き、オーダされた検査手続きの妥当性、委託医師が入力したコメントを関連付けなければならない。撮影装
置でユーザはDICOMモダリティワークリストを使用して、部門システムスケジューラ／オーダ受付
から予約済み処理手順を問い合わせる。リストを撮影装置にダウンロードし、ユーザは撮影装置のコンソール画面でその情報を検証する。モダリティ／エビデンス画像保存トランザクションでは、生成したオブジェクトのヘッダにこの情報を含める（RAD-TF2：4.8およびRAD-TF2：附属書A参照）
4.1.2

ユースケースにおける役割

部門システムスケジ
ューラ／オーダ受付

撮影装置

撮影実施リストの問い合わせ

アクタ：撮影装置
役割：部門システムスケジューラ／オーダ受付からのデータを要求および受信する。データ検証およびデータ不一致の是正機能がある。
アクタ：部門システムスケジューラ／オーダ受付
役割：撮影装置からモダリティワークリスト（MWL）要求を受信し、問い合わせを実行し、返信する。

13
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.1.3

参照する規格DICOM 2007 PS 3.4：モダリティワークリストSOPクラス
4.1.4

相互作用図
撮影装置

部門システムスケジューラ／
オーダ受付

予約済み MWL 問い合わせ
予約済み MWL 受信

4.1.4.1

予約済みMWLメッセージ問い合わせ

これは部門システムスケジューラ／オーダ受付に送られるワークリスト問い合わせメッセージである
4.1.4.1.1

トリガイベント患者が検査手続きのため撮影装置に到着する。
4.1.4.1.2

メッセージのセマンティクス

撮影装置は、DICOM モダリティワークリストSOPクラスのC-FIND要求を使用して、部門システム
スケジューラ／オーダ受付(DSS/Oder Filler)からワークリストを問い合わせする。撮影装置はSCU（サービスクラスユーザ）、DSS／オーダ受付はSCP（サービスクラスプロバイダ）となる。問い
合わせタイプはRAD-TF 2：4.5に指定および定義する。
4.1.4.1.3

想定される動作想定される動作はRAD-TF 2：4.5に定義する。本セクションでは、眼科のユースケースに対する詳しい説明を提示する。
眼科写真および／またはトモグラフィー画像を生成できる撮影機器には様々なものがある。例えば、眼底カメラおよび細隙灯生体顕微鏡はいずれも眼科写真を撮影できる。モダリティワークリストを実行するとき、医療機関によっては各機器の予定プロトコルを個別に要求することもある（眼底カ
メラ用リストと細隙灯生体顕微鏡用リストを別々に参照するなど）、このユースケースは、MWL問
い合わせでモダリティ属性を使用することでほぼ解決されるが、各機器のモダリティがOPである眼科ユースケースでは、この方法は使用できない。このユースケースは、DSS／OFが予約済みステー
ションAE名称属性を管理することで解決される。

14
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

予約済みステーションAE名称属性は、MWL問い合わせを要求している実際の機器がどれかを識別するために使用される。医療機関が各機器の予定を個別に求める場合、予約済みAE名称を使用し、機器の識別を行う。しかし、このような例はあまり一般的ではない。より一般的な例では、医療機関
は機器のタイプに基づく予約を希望する。このシナリオに対しては、DSS／OFは各類似機器のタイプごとにAE名称の表を作成することで解決策を提示する。したがって、眼底カメラおよび細隙灯生体顕微鏡の撮影装置がMWL問い合わせに予約済みステーションAE名称を使用する時、それぞれの予約済み検査手続きリストを受信することになる。これは、予約済みステーションAE名称属性をDSS／OFがどのように管理するかを示した一例に過ぎない。医療機関のニーズに基づきその他の管理が必要となることもある。
4.1.5

患者ID発行者

ADT／患者登録アクタは、患者IDの割当権限者（発行者）に関する情報をオーダ実施アクタに送信する。これについては［RAD-1］（RAD-TF 2：4.1参照）に定義する。ただし、［RAD-5］（RAD-TF
2：4.5参照）は、MWL問い合わせ中の撮影装置による要請である場合、DICOM「患者ID発行者」属
性がオーダ実施アクタによって入力されていることを要求していない。この拡張を行うにはこの属性をサポートする必要がある。ユースケースの説明についてはEYECARE-TF 1：3.3.1を参照。
このEYECARE-1の拡張については、以下の表により定義されるように、［RAD-5］（RAD-TF 2：
4.5）の表4.5-3を拡張する。
表4.1.5-1
属性

モダリティワークリストのリターンキーおよびマッチングキー
タグ

問い合わせ

問い合わせリマッチングキー

ターンキー

SCU

SCP

SCU

SCP

患者ID
患者IDの発行者(0010,021)

O

O

O

R+

注：撮影装置による問い合わせ中の患者ID発行者の要求は必須ではない。この属性を求める場
合は、オーダ実施は有効な値を返信することを要求される。

15
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.2

モダリティ画像／エビデンス保存［EYECARE-2］

本トランザクションは、モダリティ画像保存［RAD-8］（RAD-TF 2：4.8参照）に、以降の項で定義するサポートSOPクラスのリストを追加したものである。
4.2.1

適用範囲

モダリティ画像／エビデンス保存トランザクションでは、撮影装置は作成した画像／エビデンス文書を画像保管装置に送信する。生成した画像のヘッダに、モダリティワークリストトランザクショ
ン（RAD-TF 2：4.5参照）で提供された情報を含めること。
4.2.2

ユースケースにおける役割

撮影装置

画像保管装置モダリティ画像保存

アクタ：撮影装置
役割：画像／エビデンス文書データを画像保管装置に送信する。
アクタ：画像保管装置
役割：撮影装置から送信された画像／エビデンス文書を受信し、保存する。
4.2.3

参照する規格DICOM 2007 PS 3.4：保存サービスクラス

16
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.2.4

相互作用図
撮影装置

画像保管装置C-STORE（画像／エビデンス保存）

4.2.4.1

画像／エビデンス保存

4.2.4.1.1

トリガイベント

撮影装置は、画像／エビデンス文書がまとめて利用可能になると、1つ以上のDICOMアソシエーシ
ョン内で画像／エビデンス文書を画像保管装置に連続送信できる。
4.2.4.1.1.1

検査UIDおよびシリーズUID

検査UID作成の詳細およびタイミングについては、IHEで明示的に定義する。放射線通常運用ワーク
フローおよび患者情報整合性確保プロファイルでは、検査インスタンスUIDなどの検査情報およびIDをオーダ実施が作成する方法、並びにモダリティワークリストを介してモダリティにより利用可能にする方法について説明している。モダリティまたはワークステーションによってこうした項目を作成することは一般的に制限されており、PPSがまだ予約されていない場合（RAD-TF 2：附属書Aの表A1-2）あるいは異なる予約済み検査手続きに属する複数のSPSが単一PPSを満たす場合（RAD-TF 2：附属書Aの表A1-5）など、特別に言及された例外的ケースでのみ許可される。
シリーズUIDの作成は、多くのDICOM規則に準拠していなければならない。
複数の実施処理手順を同じシリーズに関連付けることは認められない。逆にいえば、1つのシリーズに異なる実施処理手順の成果を含むことはできない。したがって、処理手順の修正はできないため、
画像／エビデンス文書を完了した処理手順のシリーズに加えることは認められない。
ただし、1つのシリーズで複数の予約済み処理手順を実行することは可能である。
処理手順の完了後の画像／エビデンス文書の追加は、新規シリーズ作成のトリガとなる。

17
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

1つのシリーズに異なる機器の成果を含めることはできない（1つのシリーズの関連枠は1つでなければならないため）。異なる機器での画像／エビデンス文書の作成は、新規シリーズ作成のトリガとなる。
1つのシリーズの全画像は同じ関連枠を共有している必要がある。したがって、一般的には、異なる
体位画像の作成は新規シリーズのトリガとなる。ただし、関連枠が存在しない場合（シリーズレベルで）、この要件は回避される。
異なる機器で再構成した画像／エビデンス文書は、異なるシリーズに含める必要がある。
整合性を保つため、IHEでは画像の抽出や再構成を実施したのが撮影装置であっても、エビデンス生
成であっても、実施された抽出または再構成画像を元画像とは異なるシリーズに保存することを規定している。
注：再構成または抽出された眼科画像例としては、モザイク、パノラマ、二次元／三次元化、画像の重ね合わせ、組み合わせ、画像統計地図、補間画像などがある。
4.2.4.1.2

メッセージのセマンティクス

撮影装置はDICOMのC-STOREメッセージを使用して、画像／エビデンス文書を送信する。撮影装
置はDICOM保存SCUとなり、画像保管装置がDICOM保存SCPとなる。ユーザは、患者情報および予約済み処理手順／依頼済み処理手順で利用可能な情報を検証する。画像／エビデンス文書のオブ
ジェクトヘッダに一定の情報を記録することが要件である。DICOM画像／エビデンス文書インスタ
ンスのマッピングの詳細はRAD-TF 2の附属書Aに指定する。事実上、この附属書はIHEテクニカル
フレームワーク用のDICOM属性の定義を強化するものである。
4.2.4.1.3

保存した画像またはエビデンス文書に含める患者IDの発行者情報

EYECARE-1は、撮影装置がDICOMモダリティワークリストを使用して患者ID発行者属性を問い合わせる機能について定義している。使用については4.1を参照。本項では、ワークリスト問い合わせから得られた場合に、この属性を画像やエビデンス文書に含める要件について定義する。撮影装置
アクタが、ワークリスト問い合わせトランザクションを介して患者ID発行者属性（0010,00210）の有効値を取得した場合、撮影装置はこの属性を、この患者に関連して作成した全画像および／またはエビデンス文書に含めなければならない。
4.2.5

眼科画像オプション

EYECARE画像オプションをサポートする撮影装置は、表4.2.5-1および4.2.5-3に定義するSOPクラスの少なくとも1つをサポートしていなければならない。
画像写真作成のEYECARE画像オプションをサポートする撮影装置は、眼科8ビット写真または眼科
16ビット写真画像保存をサポートできなければならない。

18
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

眼科トモグラフィー画像作成のEYECARE画像オプションをサポートする撮影装置は、眼科トモグ
ラフィー画像保存をサポートできなければならない。
表4.2.5-1に指定するEYECARE画像オプションをサポートする撮影装置は、JPEGベースライン（処理1）： 非可逆JPEG 8ビット画像圧縮用デフォルト転送構文およびJPEG可逆、非階層、一時予測（処理14［選択値1］）；可逆 JPEG 画像圧縮用デフォルト転送構文のネゴシエーションおよび提供が可能でなければならない（表4.2.5-2参照）。圧縮の使用については医療機関で決定する。したがって、撮影装置は圧縮ネゴシエーションをオフにする必要もある（医療機関の選択に基づき）。
注：圧縮については発展的テクノロジーであると予測しているため、転送構文のサポート要件については将来修正する可能性がある。

EYECARE画像オプションをサポートする画像保管装置は、表4.2.5-1および4.2.5-3にあげたSOPク
ラスをすべてサポートしなければならない。
EYECARE画像オプションをサポートする画像保管装置は、以下の2つの圧縮転送構文のネゴシエー
ションおよび提供が可能でなければならない。
1)

JPEGベースライン（処理1）： 非可逆JPEG 8ビット画像圧縮用デフォルト転送構文

2)

JPEG可逆、非階層、一時予測（処理14［選択値1］）；可逆 JPEG 画像圧縮用デフォ
ルト転送構文表4.2.5-1

眼科保存SOPクラス

SOPクラスUID

SOPクラス名称

1.2.840.10008.5.1.4.1.1.6.1

超音波画像保存1.2.840.10008.5.1.4.1.1.3.1

超音波マルチフレーム画像保存

1.2.840.10008.5.1.4.1.1.77.1.5.1

眼科8ビット写真保存

1.2.840.10008.5.1.4.1.1.77.1.5.2

眼科16ビット写真保存

1.2.840.10008.5.1.4.1.1.88.33

立体的位置関係保存表4.2.5-2

眼科圧縮転送構文

SOPクラスUID

SOPクラス名称

1.2.840.10008.1.2.4.50

JPEGベースライン（処理1）：非可逆JPEG 8ビット
画像圧縮用デフォルト転送構文

1.2.840.10008.1.2.4.70

JPEG可逆、非階層、一時予測（処理14［選択値1］）；
可逆JPEG画像圧縮用デフォルト転送構文

19
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

表4.2.5-3

眼科保存SOPクラス

SOPクラスUID

SOPクラス名称

1.2.840.10008.5.1.4.1.1.77.1.5.4

4.2.5.1

眼科トモグラフィー画像保存

眼科の放射線検査

眼科医師は、頻繁に眼や眼周囲の放射線検査をオーダする。多くの場合、必要とされるのは放射線医による検査結果の解釈だけである。しかし、眼窩や副鼻腔の疾患や外傷が疑われるときなどは、眼科医は放射線医の報告書と個人的な画像検査評価の両方を考慮する。よくある例として、眼窩のCTスキャンで眼窩底の構造を調べる場合、外科的修復が必要となることがある。他の例としては、
眼窩MRIで腫瘍の有無を調べる場合がある。眼の周囲の外傷がある場合、顔面骨の単純X線写真を撮ることもある。こうした場合、眼科医は撮影画像の自身の評価が診断価値を高めることになり、ORのこの機能を用いて、外科的介入を誘導することもある。
画像表示アクタまたは画像保管装置アクタは、表4.2.5.1-1で定義される放射線SOPクラスをサポートすることを推奨している。

表4.2-5.1-1

放射線検査SOPクラス

SOPクラスUID

SOPクラス名称

1.2.840.10008.5.1.4.1.1.1

コンピューテッドラジオグラフィ画像保存

1.2.840.10008.5.1.4.1.1.1.1

デジタルX線画像保存-表示用

1.2.840.10008.5.1.4.1.1.2

CT画像保存1.2.840.10008.5.1.4.1.1.4

MR画像保存1.2.840.10008.5.1.4.1.1.12.1

X線血管造影画像保存

1.2.840.10008.5.1.4.1.1.7

二次取得画像保存

4.2.6

エビデンス文書用カプセル化PDFオプション

抽出画像、組み合わせデータ、測定値、プロット、グラフ、その他の診断情報などのスタンドアロ
ンの画像に加えて、若しくはその代わりにエビデンス文書を生成する撮影装置は多い。
カプセル化PDFオプションをサポートする撮影装置は、表4.2.6-1で定義するSOPクラスをサポートしなければならない。

20
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

2008年に、DICOMでは、レンズ測定計、自動屈折計、角膜測定器、自覚的屈折矯正検査等の測定値を作成する多くの機器を定義した。したがって、これらの機器は4.2.8で定義した眼科測定値オプシ
ョンをサポートすることが要求される。カプセル化PDFオプションをサポートする画像保管装置は、
表4.2.6-1で定義するSOPクラスをサポートしなければならない。
表4.2.6-1

エビデンス文書用眼科SOPクラス

SOPクラスUID
1.2.840.10008.5.1.4.1.1.104.1

4.2.6.1
4.2.6.1.1

SOPクラス名称
カプセル化PDF保存

エビデンス文書用のカプセル化PDFオプションの属性
コンセプト名コードシーケンス

コンセプト名コードシーケンスは、標準化されたコード化タイトルを提供するために用いる属性である。カプセル化PDFオプションをサポートする報告書作成は、臨床要件または選択された業界規格に基づき、この属性を構成することができなければならない。
注：この要件により、ユーザおよび実装者は異なる種類のカプセル化文書を識別できる。

4.2.6.2

PDFバージョン要件

DICOM規格は、カプセル化PDFを用いる際に特定PDFバージョンの使用を規定していない。この結果、ファイル作成ソフトウェアにより異なるPDFバージョンが使用されたときに報告書の表示の不整合が生じうる。臨床上問題になりかねないエラーとしては、空白、ページの落丁、図表の漏れや位置の間違い、フォーマットの重要な変更などがよくみられる。
PDFファイルで生じるその他の問題として、ピクセルデータだけを使用するとファイルが大きくな
りすぎるという問題がある。このことにより、ネットワーク通信スピードが非常に遅くなるなどの許容できない臨床上の問題が起こる。ピクセルデータのPDFファイルは、文書の一部のみを表示することしかできず、拡大、縮小などの表示ができないという問題等もある。PDFを検索可能なテキストファイルとして情報を保存すれば、ファイル用量はかなり小さくなり、問題の大部分は解決できる。検索可能なテキストファイルを使用することで、医師が特定の情報を素早くみつけることができるなどの重大な利点も提供する。
こうした問題に対応するために、規格に基づくISO PDFが開発されている。撮影装置アクタとエビデンス生成アクタは、電子文書の長期保存用のフォーマットPDF/A；ISO/DIS19005-1 PDF/Aをサポートしなければならない。

21
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

DICOMカプセル化PDFオブジェクトのPDFコンテンツは、PDF/A-1a（PDF/A Part 1レベルA適合）に準拠していなければならない。これは、文書の外観を、コンピュータプラットフォームにかかわらず長期間にわたり再現可能とし、文書を携帯機器（PDAなど）や米リハビリテーション法第508条に準じたその他の機器で自然な順序で表示可能とすることを目的とした要件である。
画像表示アクタはPDF／A規格に準拠したDICOMカプセル化PDF文書を表示するためにPDF／Aリ
ーダ要件に準拠する必要がある。これは、文書の正確なレンダリングを目的とした要件である。
4.2.7

眼科測定値オプション

レンズ測定計、自動屈折計、角膜測定器、自覚的屈折矯正検査等の眼科測定値情報を作成する多くの撮影装置がある。本オプションにより、こうした機器のサポートが可能となる。
眼科測定値オプションをサポートする撮影装置は、表4.2.7-1に定義するSOPクラスを少なくとも1つサポートしなければならない。
眼科測定値オプションをサポートする画像保管装置は、表4.2.7-2に定義するSOPクラスを全てサポートしなければならない。

表4.2.7-1

眼科測定値保存SOPクラス

SOPクラスUID

4.2.8

SOPクラス名称

1.2.840.10008.5.1.4.1.1.78.1

レンズ測定値

1.2.840.10008.5.1.4.1.1.78.2

自動屈折計測定値

1.2.840.10008.5.1.4.1.1.78.3

角膜測定値

1.2.840.10008.5.1.4.1.1.78.4

自覚的屈折矯正検査測定値

1.2.840.10008.5.1.4.1.1.78.5

視力測定値

1.2.840.10008.5.1.4.1.1.78.6

レンズ処方報告書

眼科相対画像位置コードオプション

医師が眼底写真を読み取る場合、網膜のどの位置なのか、あるいは右目か左目かについて判断が難しいことがある。側性（右目か左目か）はDICOM写真画像SOPクラスの必須属性であり、それがなければ画像表示ベンダは情報表示ができない。しかし、DICOM属性の相対画像位置コードシーケン
スは、オプション属性であり、眼科画像に付随していないことが多い。
相対画像位置コードオプションをサポートする撮影装置は、表4.2.8-1および4.2.8-2の要件をサポートしなければならない。

22
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

表4.2.8-1

相対画像位置コード拡張属性およびコード

属性名

タグ

タイプ

相対画像位置コードシーケンス(0022,001D)

IC-割り当てられた画像コードレビューレコ
メンデーションを有する画像は必須>コードシーケンスマクロ

表8.8.1を含む

コンテキストID 4207の値の一覧

DICOM2007 PS 3.3：情報オブジェクト定義で定義されたコードシーケンスマクロ

眼科分野では、多くの画像位置コードを利用する。DICOM CID-4207は、このコードを特定するが、医師は他の撮影プロトコルに従い、DICOM CID 4207で定義された以外の画像位置コードを利用したいと考えるかもしれない。したがって撮影装置アクタは、表4.2.8-2に定義した追加コード（DICOM
CID 4207で定義された以外）をサポートし、医療機関の選択あるいは定義した体系のサポートを設定可能にする必要がある。
4.2.8-2

相対位置拡張コード

コード体系識別子(0008,0102)

コード値(0008,0100)

コード意味(0008,0104)

99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE
99IHEEYECARE

330001330002330003330004330005330006330007330008330009330010330011330012330013330014330015330016330017330018

黄斑中央部
乳頭中央部
中間周辺上部
中央周辺上側部
中央周辺側部
中央周辺下側部
中央周辺下部
中央周辺下内側部
中央周辺内側部
中央周辺上内側部
周辺上部
周辺上側部
周辺側部
周辺下側部
周辺下部
周辺下内側部
周辺内側部
周辺上内側部

99IHEEYECARE

330019病変中央部

23
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.2.9

立体的位置関係オプション

視神経円板等の立体写真では、2つの眼科画像間の立体的位置関係の判断が求められる。DICOMでは、左右画像を参照して、異なる立体的位置関係オブジェクトの保存メカニズムを提供している。
立体的位置関係オプションをサポートする撮影装置、画像保管装置、画像表示アクタは、表4.2.9-1に定義するDICOMのSOPクラスをサポートしなければならない。
撮影装置アクタに関しては、最適表示のために画像の左右、水平変位、垂直変位、左画像に対する右の回転を判断するためのユーザインプットが必要となることがある。撮影装置アクタは、ユーザ
インプットなしに自動的に立体的位置関係を保存することができる。機器が分離角度を把握している場合、DICOM属性のステレオ基線角度（0022,0010）を伝える必要がある。
撮影装置アクタは、少なくとも、単一フレーム画像または複数フレーム画像の各フレーム間の立体的位置関係判断機能をサポートする。すなわち、複数フレーム画像の複数フレーム間の立体的位置
関係判断機能をサポートしてよい。

表4.2.9-1

立体的位置関係SOPクラス

SOPクラスUID

SOPクラス名称

1.2.840.10008.5.1.4.1.1.77.1.5.3

4.3

立体的位置関係保存

画像および測定値の検索取得［EYECARE-3］

本トランザクションは、画像取得トランザクション［EAD-16］（RAD-TF 2：4.16参照）と同一であるが、屈折測定値の取得を含む。
4.3.1

適用範囲

画像表示が取得を依頼した後に、依頼済みDICOM画像および／または測定値が閲覧できるように画像保管装置から画像表示に転送される。
4.3.2

ユースケースにおける役割

画像表示

画像保管装置

画像取得

24
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

アクタ：画像保管装置
役割：画像表示アクタに依頼済み画像を送る
アクタ：画像表示
役割：画像保管装置アクタから送られた依頼済み画像を受信する
4.3.3

参照する規格DICOM 2007 PS 3.4：保存サービスクラス
DICOM 2007 PS 3.4：問い合わせ／検索取得サービスクラス
4.3.4

相互作用図
画像保管装置

画像表示

画像取得(C-MOVE)
画像保存(C-STORE)

画像の閲覧

4.3.4.1

画像の取得

検索取得（検査ルート MOVE と任意の患者ルートMOVE）SOPクラスをサポートする。画像保管装置はSCUとしてDICOM画像保存SOPクラスをサポートする。詳細についてはDICOM PS 3.4（附属書C）を参照のこと。
4.3.4.1.1

トリガイベント

画像表示で画像および／または測定値が閲覧用に選択される
4.3.4.1.2

メッセージのセマンティクス

メッセージのセマンティクスは、DICOM問い合わせ／検索取得SOPクラスとDICOM画像および測定値保存SOPクラスにより定義される。
DICOM検査ルート問い合わせ／検索取得情報モデルまたはDICOM患者ルート問い合わせ／検索取
得情報モデルからのC-MOVE要求－MOVE SOPクラスは画像表示から画像保管装置に送られる。

25
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.3.4.1.3

想定される動作

画像保管装置アクタはC-MOVE要求を受信し、画像表示とDICOM通信でアソシエーションを確立し、
C-STORE要求（適切なDICOM画像および／または測定値保存SOPクラス）を使用して要求された画像を転送する。画像表示は、表4.2.5-1、4.2.5-3、4.2.7-1で定義するSOPクラスの少なくとも1つをサポートすることが想定されている。検索取得SOPクラスのサポートは表示のサポートを意味す
る。
4.3.5

眼科画像オプション

眼科画像オプションをサポートする画像表示アクタは、表4.2.5-1、4.2.5-3、4.2.8-1で定義するSOPクラスの少なくとも1つをサポートする。例えば、CT、MR、X線等の放射線のような他の専門分野
でも眼科画像を取得できる。IHE EYE CAREではこうした可能性を一覧表示していないものの、こうした画像を表示できる画像表示アクタを推奨している。画像表示アクタがサポートする保存SOP
クラスはもれなく、DICOM適合性宣言書で文書化すること。
注：例をあげると、眼の異物のX線、眼窩血管病変のX線血管造影、眼窩のMR画像などがある。

EYE CARE画像オプションをサポートする画像表示アクタは、JPEGベースライン（処理1）： 非可逆JPEG 8ビット画像圧縮用デフォルト転送構文およびJPEG可逆、非階層、一時予測（処理14［選択値1］）；可逆 JPEG 画像圧縮用デフォルト転送構文のネゴシエーションおよび提供が可能でなければならない（表4.2.5-2参照）
画像表示アクタがDICOMカプセル化PDF検索取得SOPクラスをサポートする場合は、電子文書の長期保存用のフォーマットPDF/A；ISO/DIS19005-1 PDF/Aをサポートしなければならない。
画像表示アクタは PDF／A規格に準拠したDICOMカプセル化PDF文書を表示するためにPDF／Aリ
ーダ要件に準拠する必要がある。これは、文書の正確なレンダリングを目的とした要件である。
4.3.6

眼科相対画像位置コードオプション

医師が眼底写真を読み取る場合、網膜のどの位置なのか、あるいは右目か左目かについて判断が難しいことがある。側性（右目か左目か）はDICOM写真画像SOPクラスの必須属性であり、それがなければ画像表示ベンダは情報表示ができない。しかし、DICOM属性の相対画像位置コードシーケン
スは、オプション属性であり、眼科画像に付随していないことが多い。
相対画像位置コードオプションをサポートする撮影装置は、表4.2.8-1および4.2.8-2の要件をサポートしなければならない。
相対画像位置オプションに準拠する画像表示アクタは、DOP画像に含まれるDICOM相対画像位置コ
ードシーケンス属性（0022,001D）の明示的および／若しくは暗示的表示機能をサポートする。

26
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

明示的表示では、画像表示アクタは、OP画像の相対画像位置コードの意味（該当する場合）を表示できる。暗示的表示の場合、画像表示アクタは、ユーザに相対画像位置を明白に伝える方法で、相対画像位置コード機能として複数画像の表示レイアウトを調整できる。
4.3.7

立体的位置関係オプション

視神経円板等の立体写真では、2つの眼科画像間の立体的位置関係の判断が求められる。DICOMでは、左右画像を参照して、異なる立体的位置関係オブジェクトの保存メカニズムを提供している。
立体的位置関係オプションをサポートする画像保管装置、画像表示アクタは、表4.2.9-1に定義する
DICOMのSOPクラスをサポートしなければならない。
立体的位置関係オプションをサポートする画像表示アクタは、DICOM立体的位置関係オブジェクト
によって参照される画像ペア表示表に定義されるSOPクラスをサポートする。左画像に対する右画
像の表示の最適化には、水平変位、垂直変位、および／または左に対する右画像の回転を反映する。
このオプションに準拠する画像表示アクタは、単一フレーム画像または複数フレーム画像の各フレ
ーム間の立体的位置関係判断機能をサポートする。立体フレームの複数ペアの表示は、1回につき立体位置関係の画像ペア1組の表示に制限される。

4.4

エビデンス文書の問い合わせ［EYECARE-4］

本トランザクションは画像問い合わせ［RAD-45］（RAD-TF 3：4.45参照）に、DICOMカプセル化
PDF文書の問い合わせ機能を追加したものである。
4.4.1

適用範囲

本項では、画像表示が画像保管装置からエビデンス文書のインスタンスを問い合わせするためのト
ランザクションシーケンスを説明する。
4.4.2

ユースケースにおける役割

画像保管装置

画像表示

エビデンス
問い合わせ

27
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

アクタ：画像表示
役割：エビデンス文書オブジェクトを問い合わせる（一般的に画像の検索のため）
アクタ：画像保管装置
役割：画像表示によるエビデンス文書オブジェクトの問い合わせに応答する
4.4.3

参照する規格DICOM 2007 PS 3.4：問い合わせ／検索取得サービスクラス
4.4.4

相互作用図
画像表示

画像保管装置エビデンス文書問い合わせ(C-FIND)
問い合わせに対する応答 (C-FIND)

4.4.4.1

エビデンス文書問い合わせ

問い合わせ（検査ルート－FINDおよび任意の患者ルート－FIND）SOPクラスはサポートされる。
詳細については DICOM PS 3.4（附属書C）：問い合わせ／検索取得サービスクラスを参照のこと。
4.4.4.1.1

トリガイベント

画像表示はエビデンス文書に関する情報を取得する必要がある
4.4.4.1.2

メッセージのセマンティクス

メッセージのセマンティクスはDICOM問い合わせ／検索取得SOPクラスにより定義される。
DICOM検査ルート問い合わせ／検索取得情報モデル－FIND SOPクラスまたはDICOM患者ルート
問い合わせ／検索取得情報モデル－FIND SOPクラスからのC-FIND要求は画像表示から画像保管装置に送られる。
画像表示は検索基準として1つまたは複数のマッチングキーを使い、選択したレベル（患者および検査／シリーズ／インスタンス）で、画像保管装置からマッチングエントリーのリストを取得する。
DICOM規格で定義された必須固有キーに加えて、IHEテクニカルフレームワークは問い合わせSCU
およびSCPがサポートするマッチングキーおよびリターンキーを定義している。キーの定義はRADTF-2：4.14.4.1.2およびRAD TF-2：4.14-1を参照すること。キー使用の表記法は、RAD TF-2：2.2

28
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクションに定義する。画像表示（SCU）および画像保管装置（SCP）に対する追加的なエビデンス文書イン
スタンス固有キーをRAD TF-3：4.44-1に定義する。
4.4.5

DICOMカプセル化PDF問い合わせ属性

RAD-44は、エビデンス生成（およびその他のアクタ）が画像保管装置からエビデンス文書情報を問い合わせする機能を定義している。このトランザクションは、DICOMカプセル化PDF問い合わせ属性のサポートに文書タイトル表示を加えただけのRAD-44の簡単な拡張である。
エビデンス生成および画像は、表4.4.5-1で定義する要件を追加して、RAD-44が定義するトランザク
ションをサポートしなければならない。
表4.4.5-1

DICOMカプセル化PDFサポートのための追加的問い合わせマッチングキー
およびリターンキー

属性名

タグ

問い合わせマッチングキー
SCU

問い合わせリターンキー

SCP

SCU

SCP

カプセル化文書インスタンス固有レベル
文書タイトル注：

4.5(0042,0010)

O

O

R+

R+

眼科エビデンス文書プロファイルをサポートしているワークステーションや撮影装置は、1回の問い合わせで画像およびエビデンス文書の両方の情報を得ることができる（2回の問い合わせは必要ない）。
同様に、情報を検索取得するときにも、1回の検索取得で画像とエビデンス文書の両方を得ることができる。

画像、測定値およびカプセル化文書の問い合わせ[EYECARE-5]

本トランザクションは、画像問い合わせ［RAD-14］（RAD-TF 2：4.14参照）に、画像保管装置の患者ID発行者属性サポート要件を追加したものである。
4.5.1

適用範囲

画像表示は閲覧用に、画像保管装置で検査、シリーズ、画像インスタンスを問い合わせする。
4.5.2

ユースケースにおける役割
画像表示

画像保管装置

画像問い合わせ29
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

アクタ：画像保管装置
役割：検査、シリーズ、画像の問い合わせに応答する
アクタ：画像表示
役割：検査、シリーズ、画像の問い合わせを行う

4.5.3参照する規格
DICOM 2007 PS 3.4：問い合わせ／検索取得サービスクラス

4.5.4

相互作用図
画像保管装置

画像表示

画像問い合わせ(C-FIND)

応答(C-FIND)

4.5.4.1

画像、測定値、カプセル化文書の問い合わせ

問い合わせ（検査ルート－FINDおよび任意の患者ルート－FIND）SOPクラスをサポートする。詳細なセマンティクスの説明についてはDICOM 2007 PS 3.4を参照すること。
4.5.4.1.1

トリガイベント

画像表示ユーザが特定画像の閲覧を希望
4.5.4.1.2

メッセージのセマンティクス

メッセージのセマンティクスはDICOM問い合わせ／検索取得SOPクラスで定義する。
DICOM検査ルート問い合わせ／検索取得情報モデル－FIND SOPクラスまたはオプションの
DICOM患者ルート問い合わせ／検索取得情報モデル－FIND SOPクラスからのC-FIND要求は画像30
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

表示から画像保管装置に送られる。階層的検索手法をサポートする。
画像表示は検索基準として1つまたは複数のマッチングキーを使い、選択したレベル（患者および検査／シリーズ／インスタンス）で、画像保管装置からマッチングエントリーのリストを取得する。
画像表示は、エントリリストに基づいて、関連エントリを選択し、検索取得できる。
画像表示（SCU）および画像保管装置（SCP）がサポートすべきマッチングキーおよびリターンキーは［RAD-14］（RAD-TF 2：4.14参照）の表で定義する。この表は、問い合わせSCU（画像表示）
および問い合わせSCP（画像保管装置）の両者について規定しており、マッチングキー（問い合わ
せ要求においてマッチング基準として用いられるキー）およびリターンキー（問い合わせ応答の中で返信される属性を要求するために用いられるキー）は必須（R）またはオプション（O）で表示さ
れる。
4.5.5

患者ID発行者のサポート

RAD-14は画像表示アクタが画像保管装置から画像を問い合わせる機能を定義している。このトランザクションは、RAD14に患者ID発行者属性のサポートを追加した単純な拡張である。
画像表示および画像保管装置は、表4.5.5-1で定義する要件を追加して、RAD-14で定義されたトランザクションをサポートしなければならない。
表4.5.5-1
属性名

画像問い合わせのマッチングキーとリターンキー

タグ

問い合わせ

問い合わせ

マッチングキー

リターンキー

SCU

SCU

SCP

注

SCP

検査レベル
患者ID発行者(0010,0020)

O

O

O

R+

注1を参照

注：画像表示は問い合わせで患者IDの発行者を要求する必要はないが、この属性を要求する場合、オーダ実施
は有効値で応答する必要がある（存在する場合）。

4.6

モダリティ処理手順完了／中止[EYECARE-6]

本トランザクションはモダリティ処理手順完了［RAD-7］（RAD-TF 2：4.7参照）に、撮影装置がMPPSメッセージの中で実施済みプロトコルコードシーケンス属性を伝える要件を追加したものである。部門システムスケジューラ／オーダ受付、画像管理、進捗管理および撮影装置アクタは、
EYECARE-6トランザクションを使用する。
4.6.1

適用範囲

本トランザクションには、撮影装置から進捗管理へのメッセージが含まれる。その後、進捗管理は、
メッセージをDSS／オーダ受付および画像管理に対し、実施処理手順の完了を知らせるメッセージを発行する。この時点では、請求のための情報は発行しないが、コードを割り当ててもよい。画像31
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

管理は同じ検査の画像を同一箇所に配置するための情報を必要とすることがある。モダリティ処理
手順完了メッセージは、画像セットが全て揃ったこと、若しくは検索取得可能であることを必ずしも意味しない。
4.6.2

ユースケースにおける役割

進捗管理

画像管理
部門システムスケジ
ューラ／オーダ受付

撮影装置

モダリティ処理手
順完了

アクタ：部門システムスケジューラ／オーダ受付
役割：PPS管理から出されたPPS情報を受信する
アクタ：画像管理
役割：PPS管理から出されたPPS情報を受信する
アクタ：撮影装置
役割：進捗管理に特定の実施処理手順が完了したことを知らせる
アクタ：進捗管理
役割：撮影装置からの実施処理手順情報を受信し、その情報を部門システムスケジューラ／オーダ
受付および画像管理に転送する

4.6.3

参照する規格DICOM 2007 PS 3.4：モダリティ実施処理手順SOP ClassDICOM 2007 PS 3.16：DCMRコンテキストグループ（規範）

4.6.4

相互作用図

32
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

進捗管理／画像管理部門システムスケジュー
ラ／オーダ受付

撮影装置

撮影装置

進捗管理／
部門システムスケジューラ／
オーダ受付

画像管理

注：上の図は、モダリティ実施処理手順SOPクラスに対するメッセージのシーケンスを示す。撮影装置は保存
クラスおよび保存委託クラスも実装する。PPSメッセージと保存／保存委託メッセージのタイミングの関係性は指定されていない。つまり、PPSメッセージは保存依頼の前でも後でも生じうる。

4.6.4.1 モダリティ処理手順完了／中止 [EYECARE-6]
RAD-7はモダリティ処理手順完了／中止をサポートするための要件およびオプションを定義している。本トランザクションは、撮影装置がMPPSメッセージで実施済みプロトコルコードシーケンスを伝える追加的要件を加えたRAD-17の単純な拡張である。
部門システムスケジューラ／オーダ受付、画像管理、進捗管理および撮影装置アクタは、以下の拡張を加えたRAD-7（RAD-TF 2：4.7参照）をサポートする必要がある。

33
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.6.4.2

実施済みプロトコルコードシーケンス

モダリティプロトコルコード表を、撮影装置アクタで設定する。この表は、画像管理及び部門シス
テムスケジューラ／オーダ受付アクタと同期させなければならない。
モダリティ
プロトコルコード表
コード プロトコル説明OD 黄斑

実施済みプロトコル名実施済みプロトコルコード

視神経 OD

オペレータは提案されたプロト
コルを受信し、表からプロトコルを選択する。

部門システムスケジューラ／オーダ受付からMWLを取得すると、撮影装置は予約済みプロトコルコ
ードシーケンス属性および予約済み処理手順説明属性を表示するよう要求される（この要求はRAD-5の一部および［EYECARE-1］）。
モダリティのオペレータはこの要求に対し、予約済みプロトコルコードシーケンス属性で提案されたプロトコルの承認／選択、若しくはモダリティプロトコルコード表の選択肢リストで定義された別のプロトコルの選択のいずれかを行う。オペレータ撮影プロトコルの属性（プロトコルコードのタイプ）を手動ではなく、モダリティプロトコルコード表のリストを用いて入力する。こうすることで、モダリティでのオペレータの作業が容易になり、画像部門で使用するプロトコル管理の改善が可能となる。撮影装置アクタは、プロトコル名に加えて実施済みプロトコルコードシーケンス属
性のプロトコルコード値を提供する。この機能は、検査会計統合プロファイル内の部門システムス
ケジューラ／オーダ受付の役割を補助する。
この機能は特定の撮影プロトコルコード体系を定義しない。関連するアクタである部門システムス
ケジューラ／オーダ受付、撮影装置、画像管理／画像保管装置は、医療機関が選択または定義したコード体系のサポートが設定可能でなければならない。
4.6.4.3

トリガイベント

オペレータが撮影装置コンソールでの処理手順を完了。
4.6.4.4

メッセージのセマンティクス

撮影装置は、モダリティ実施処理手順SOPクラス（N-SETサービス）を使用して、進捗管理に特定の実施処理手順が完了または中止したことを知らせる。撮影装置はMPPS N-SETサービスを用いて、実施処理手順情報の中間アップデートを送ってもよい。

34
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

最終N-SETのMPPSステータスは「完了」あるいは「中止」のいずれかである。進捗管理は部門システムスケジューラ／オーダ受付および画像管理に対応するN-SETを送信する。
N-SETが「中止」ステータスとともに発行されるときに、画像が生成、送信される場合、1つ以上のインスタンスシリーズが参照される。こうしたインスタンスは保存および保存委託される。
その他の情報に加えて、撮影装置は、SOPインスタンスを生成するために用いるプロトコルに関する情報を受信者に送信する。この問題の詳細に関しては、RAD-TF 2：4.6.4.1.2.4のプロトコル取扱の項を参照すること。
注：DICOMは、N-SETにより属性をセットできる時、最新N-SETにより提供された値は、以前のN-CREATE
またはN-SETによりセットされた値を無効にすると規定している。

4.6.4.4.1

想定される動作画像管理および部門システムスケジューラ／オーダ受付は実施処理手順の完了または中止に関する情報を受領し、その情報を依頼済み手続きおよび予約済み処理手順と関連付ける。画像管理および部門システムスケジューラはMPPSステータス「進行中」のついたN-SET中間メッセージに関する動作をする必要はない。
全予約済み処理手順に関連する実施処理手順が全て完了（若しくは適切に中止）したときに、依頼済み手続きは完了したとみなされる。依頼済み手続きに完了走査ステータスが割り当てられた後であっても、追加的な新規（未予約）実施処理手順はいつでも実行してよい。この問題の詳細については、RAD-TF 2：4.6.4.1.2.3の予約済みおよび実施処理手順の関係に関する項を参照すること。
4.7

表示可能報告書の保存[EYECARE-7]

本セクションは、IHEテクニカルフレームワークのEYECARE-7トランザクションに対応する。
EYECARE-7トランザクションは、報告書作成アクタおよび報告書保管アクタにより使用される。
4.7.1

適用範囲

報告書保存トランザクションでは、報告書作成アクタがDICOMカプセル化文書オブジェクトを報告
書保管に送信する。

35
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.7.2

ユースケースにおける役割

報告書作成

報告書保管

アクタ：報告書作成
役割：報告書保管にDICOMカプセル化文書報告書の草案または最終版を送信する
アクタ：報告書保管
役割：DICOMカプセル化文書報告書の草案または最終版を受信し、保存する
4.7.3

参照する規格DICOM 2007 PS 3.4：保存SOP Class
4.7.4

相互作用図
レポート
保管

報告書作成

報告書を作成する
報告書保存（C-STORE）

4.7.4.1

報告書の作成上記相互作用図での「報告書の作成」イベントに関連するトランザクション
4.7.4.1.1

トリガイベント

報告書作成のユーザがDICOMカプセル化文書を用いた臨床報告書の作成を希望する

36
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

起動のセマンティクス

4.7.4.1.2

これは報告書作成でのローカルな起動であり、報告書作成で報告書データを取得し、かつDICOMカ
プセル化文書オブジェクトを生成するのに使用される方法は、IHEテクニカルフレームワークの範囲外である。報告書作成は、4.7.5で定義されるDICOMカプセル化文書に準拠する報告書を作成しなければならない。
想定される動作

4.7.4.1.3

報告書保管で保存できるDICOMカプセル化文書オブジェクトの生成
4.7.4.1.3.1

検査識別および同一文書シーケンス

報告書が属する検査を識別するため、検査インスタンスUIDが要求される。画像および／または測定値の検査インスタンスUIDは作成されたカプセル化文書の検査インスタンスUIDと同じものを使用することが推奨される。報告書作成が複数検査に関する単一報告書を作成する場合、異なるSOP
インスタンスUIDの報告書のコピーを作成し、同一文書シーケンス属性（0040,A525）を各報告書に使用する。各報告書の同一文書シーケンス属性（0040,A525）は他の検査の同一報告書を参照する。
実際の報告書内容は（同一文書シーケンス属性を除き）各報告書インスタンスで同一である。
同一文書シーケンスアイテムの検索取得AEタイトル属性（0008,0054）は送信しないこと。
4.7.4.2

報告書の提出本トランザクションは上記の相互作用図の報告書作成および報告書保管の間の“DICOM-STORE”
イベントに関連する。
4.7.4.2.1

トリガイベント

報告書のオーサリングが完了し、報告書作成が新規DICOMカプセル化文書作成すると、報告書作成
はDICOMカプセル化文書を報告書保管に送信する。
4.7.4.2.2

メッセージのセマンティクス

報告書作成はDICOMのC-STOREメッセージを使用して、DICOMカプセル化文書の報告書を送信する。DICOMカプセル化文書インスタンスには、表4.7.5-1に示す追加属性を含めること。報告書保管はレベル2（フル）保存をサポートする。すなわち、報告書保管はDICOMタイプ1、2および3とプラ
イベート属性を保存する。

37
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.7.4.2.3

想定される動作

報告書保管は受信したDICOMカプセル化文書オブジェクトを保存する。この時点で、報告書作成は報告書オブジェクトに対する全責任を放棄し、新たなSOPインスタンスUIDを有する新規オブジェ
クトを作成する以外の方法で、報告書オブジェクトの変更をすることはできない。報告書保管は当該インスタンスを問い合わせおよび検索取得に利用できる状態にしなければならない。
4.7.5

DICOMカプセル化文書標準拡張属性

報告書作成および報告書保管は、表4.7.5-1に定義するDICOMのSOPクラスおよび表4.7.5-2に定義する標準拡張属性をサポートする。

表4.7.5-1

カプセル化文書のSOPクラス

SOPクラスUID

SOPクラス名

1.2.840.10008.5.1.4.1.1.104.1

表4.7.5-2

カプセル化PDF保存

DICOMカプセル化文書標準拡張属性

属性名

タグ

タイプ

属性の説明

検証フラグ

(0040,A493)

1

この文書が検証されたか否かを示す
値の一覧：
UNVERIFIED = 未検証
VERIFIED = 文書内容に責任を有する検証者名（0040,A075）により検証済み
注：この仕様のカプセル化文書の「現行の最終版」とは、最新の検証日時（0040,A030）、完了フラグ（040,A491）のCOMPLETEおよび検証フラグ（040,A493）のVERIFIEDを有するバージョンである。
注：カプセル化IOD定義ではタイプ3のみであるが、眼科ではこの属性をタイプ1フィールドにしている。

文書内容作成日(0008,0023)

1

文書内容の作成を開始した日付
注：カプセル化IOD定義ではタイプ2のみであるが、眼科ではこの属性をタイプ1フィールドにしている。

文書内容作成時間(0008,0033)

1

文書内容の作成を開始した時間
注：カプセル化IOD定義ではタイプ2のみであるが、眼科ではこの属性をタイプ1フィールドにしている。

38
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

完了フラグ(0040,A491)

1

完了フラグ説明(0040,A492)

3

検証者シーケンス(0040,A073)

1C

このタイプの文書を検証する権限を有し、この文書の内容に責任を負う人物。このシーケンスには1つまたは複数項目が含まれる。
検証フラグ（0040,A493)）VERIFIEDである場合に要求
される。

検証者名

(0040,A075)

1>検証者IDコード
シーケンス(0040,A088)2

検証組織（0040,A027）によりこのタイプの文書の検証権限を与えられ、文書の内容に責任を負う人物。
検証者のコード化ID。
このシーケンスには項目を含まない、若しくは1つの項目を含む。
ベースラインコンテキスト ID は定義されていない>>コードシーケンスマクロ表8.8-1（DICOM標準パート3）>検証組織(0040,A027) 1>検証日時(0040,A030)

1

適合宣言書で規定された方法で外的に定義された基準に基づき推定されたこの文書の完了程度
注：こうした基準が、現地法やユーザの決定に適応できるようにすることが望ましい。
値の一覧：
PARTIAL =部分的に完了した内容
COMPLETE = 完了した内容
完了フラグで送った値の説明 (0040,A491).

検証者名（0040,A075）が現行の解釈措置に関する説明責任を負う組織
検証者名（0040,A075）による検証の日時>SOPインスタンスリファレンスマクロの表C17-3（DICOM標準パート3）を含む
当該依頼済み手続 (0040,A375) 3
当該依頼済み手続きを実行するために生成された文書まきエビデンスシー
たはコンテンツツリーに参照される文書から成り、生成
ケンス
者が認識している合成SOPインスタンスのフルセット。
このシーケンスには1つ以上の項目が含まれる。
> SOPインスタンスリファレンスマクロの表C17-3を含む
関連するその他の (0040,A385) 3
文書の生成者により関連エビデンスとみなされるその他
エビデンスシーケの合成SOPインスタンス。このエビデンスは当該文書がンス生成される原因となった依頼済み手続き以外の依頼済み
手続きを実行するために作成されたものでなければならない。このシーケンスには1つ以上の項目が含まれる。
同一文書シーケン
ス(0040,A525)

1C

異なるSOP UIDで保存されている当該文書のコピー。このシーケンスには1つ以上の項目が含まれる。1つ以上の試験で異なるSOPインスタンスUIDの同文書が保存される場合に要求される。

39
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション> SOPインスタンスリファレンスマクロの表 C17-3（DICOM規格パート3）を含む

4.7.5.1

カプセル化文書拡張属性

4.7.5.2

コンセプト名コードシーケンス

コンセプト名コードシーケンスは、文書の標準コード化タイトルを提供するために用いられる属性である。本トランザクションのために、報告書作成は臨床要件または選択された業界規格に基づき、この属性の設定が可能であることを求められる。
注：この要求により、ユーザおよび実装者は異なるタイプのカプセル化文書を識別できる。

4.7.5.3

ソースインスタンスシーケンス

ソースインスタンスシーケンスは、抽出されたカプセル化文書を参照するために用いる属性である。
この属性はSOPインスタンスと呼ばれ（事前報告書または暫定報告書）、その内容の全体または一部がカプセル化文書に含まれる。この文書改訂手続きは明示的には説明されていないが、この属性を使用することで当該文書の前版に遡ることが可能となる。
4.7.5.4

PDFバーション要件

DICOM規格は、カプセル化PDFを用いる際に特定PDFバージョンの使用を規定していない。この結果、ファイル作成ソフトウェアにより異なるPDFバージョンが使用されたときに報告書の表示の不整合が生じうる。臨床上問題になりかねないエラーとしては、空白、ページの落丁、図表の漏れや位置の間違い、フォーマットの重要な変更などがよくみられる。
PDFファイルで生じるその他の問題として、ピクセルデータだけを使用するとファイルが大きくな
りすぎるという問題がある。このことにより、ネットワーク通信スピードが非常に遅くなるなどの許容できない臨床上の問題が起こる。ピクセルデータのPDFファイルは、文書の一部のみを表示することしかできず、拡大、縮小などの表示ができないという問題等もある。PDFを検索可能なテキストファイルとして情報を保存すれば、ファイル用量はかなり小さくなり、問題の大部分は解決できる。検索可能なテキストファイルを使用することで、医師が特定の情報を素早くみつけることができるなどの重大な利点も提供する。
こうした問題に対応するために、規格に基づくISO PDFが開発されている。報告書作成アクタは、
PDF/A；ISO/DIS19005-1、文書管理－電子文書の長期保存用のフォーマット－パート1：PDFの使用（PDF/A）をサポートしなければならない。
DICOMカプセル化PDFオブジェクトのPDFコンテンツはPDF/A-1a（PDF/A Part 1規格へのレベルA適合）に準拠していなければならない。これは、文書の外観を、コンピュータプラットフォームにかかわらず長期間にわたり再現可能とし、文書を携帯機器（PDAなど）や米国リハビリテーション
法第508条に準じたその他の機器で自然な順序で表示可能とすることを目的とした要件である。

40
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.8

表示可能報告書問い合わせ［EYECARE-8]

本項は、IHEテクニカルフレームワークのEYECARE-8トランザクションに対応する。EYECARE-2
トランザクションは報告書閲覧アクタおよび報告書保管アクタにより使用される。
4.8.1

適用範囲

表示可能報告書問い合わせトランザクションでは、報告書閲覧が報告書保管からDICOMカプセル化
文書の草案あるいは最終版を問い合わせる。
4.8.2

ユースケースにおける役割
報告書閲覧

報告書保管

報告書
問い合わせ

アクタ：報告書保管
役割：DICOMカプセル化文書の問い合わせに応答する
アクタ：報告書閲覧
役割：報告書保管からDICOMカプセル化文書を問い合わせし、選択可能な状態にする。
4.8.3

参照する規格DICOM 2007 PS 3.4：問い合わせ／検索取得サービスクラス

41
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.8.4

相互作用図
報告書閲覧

報告書保管

報告書問い合わせ(C-FIND)
応答問い合わせ(C-FIND)

報告書管理

報告書閲覧

報告書問い合わせ(C-FIND)

応答問い合わせ(C-FIND)

4.8.4.1

表示可能報告書問い合わせ本トランザクションは上記相互作用図の問い合わせに関連する。問い合わせ（検査ルート－FINDおよび任意の患者ルート－FIND）SOPクラスをサポートする。詳細なセマンティクスの説明は、DICOM 2007 PS 3.4問い合わせ／検索取得サービスクラスを参照する。
4.8.4.1.1

トリガイベント

報告書閲覧のユーザが選択した報告書の閲覧を希望
4.8.4.1.2

メッセージのセマンティクス

メッセージのセマンティクスはDICOM問い合わせ／検索取得SOPクラスで定義する。

42
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

DICOM検査ルート問い合わせ／検索取得情報モデル－FIND SOPクラスまたはDICOM患者ルート
問い合わせ／検索取得情報モデル－FIND SOPクラスからのC-FIND要求は、画像表示から画像保管装置に送られる。
報告書閲覧は検索基準として1つ以上のマッチングキーを使い、選択したレベル（患者および検査／
シリーズ／インスタンス）で、報告書保管からマッチングエントリーのリストを取得する。
DICOM規格で定義された必須固有キーに加えて、IHEテクニカルフレームワークは問い合わせSCU
およびSCPがサポートするマッチングキーおよびリターンキーを定義している。キーは[RAD-14]（RAD TF-2：表4.14-1参照）で定義する。但し、報告書閲覧および報告書保管はPPS開始日付とPPS
開始時間をサポートする必要はない。キー使用の表記法は、RAD TF-2：2.2に定義する。報告書閲
覧（SCU）および報告書保管（SCP）に対する追加的な文書インスタンス固有キーを表4.8-1で定義する
表4.8-1 文書インスタンス固有問い合わせマッチングキーおよびリターンキー
属性名

SRインスタンス固有レベル
文書タイトル
完了フラグ
検証フラグ
文書内容日付
文書内容時間
検証者シーケンス> 検証組織> 検証日時> 証者名> 検証者ID
コードシーケンス>> コード値>> コード体系識別子>> コード体系バージョン>> コード意味
コンセプト名
コードシーケンス> コード値> コード体系識別子> コード体系バージョン> コード意味
4.8.4.1.3想定される動作

タグ

問い合わせ
マッチングキー
SCU
SCP

問い合わせ
リターンキー
SCU
SCP(0042,0010)(0040,A491)(0040,A493)(0008,0023)(0008,0033)(0040,A073)(0040,A027)(0040,A030)(0040,A075)(0040,A088)

O
R+
R+
O
O

O
R+
R+
O
O

R+
R+
R+
R+
R+

R+
R+
R+
R+
R+

O
R+
R+

O
R+
R+

R+
R+
R+

R+
R+
R+

(0008,0100)(0008,0102)

O
O

O
O

O
O

R+
R+

(0008,0103)(0008,0104)(0040,A043)

O
O

O
O

O
O

R+
R+

(0008,0100)

R+

R+

R+

R+

(0008,0102)(0008,0103)(0008,0104)

R+
O
O

R+
O
O

R+
O
R+

R+
R+
R+

報告書保管はC-FIND要求を受け取り、提供されたキーのマッチングを行い、C-FIND応答を介して報告書閲覧にマッチング記録を返信する。

43
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.9

表示可能報告書検索取得 [EYECARE-9]

本項はIHEテクニカルフレームワークのEYECARE-9トランザクションに対応する。EYECARE-9ト
ランザクションは報告書閲覧アクタおよび報告書保管アクタにより使用される。
4.9.1

適用範囲

表示可能報告書検索取得トランザクションでは、要求されたDICOMカプセル化文書を報告書保管から報告書閲覧に閲覧用に転送する。
4.9.2

ユースケースにおける役割

報告書閲覧

報告書保管

報告書
検索取得

アクタ：報告書保管
役割：要求されたDICOMカプセル化文書を報告書閲覧に送る。
アクタ：報告書閲覧
役割：DICOMカプセル化文書を報告書保管から検索取得し、閲覧できるようにする。
4.9.3

参照する規格DICOM 2007 PS 3.4：問い合わせ／検索取得サービスクラス
DICOM 2007 PS 3.4：保存SOPクラス

44
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

4.9.4

相互作用図
報告書閲覧

報告書保管

表示可能報告書検索取得（C-MOVE）

報告書保存（C-STORE）

レポーをト閲覧する

4.9.4.1

報告書検索取得

本トランザクションは上の相互作用図の検索取得に関連する。検索取得（検査ルート－MOVEと任意の患者ルート－MOVE）SOPクラスをサポートする。報告書閲覧は、SCPとしてDICOMカプセル
化文書保存SOPクラスをサポートする。報告書保管は、SCUとしてDICOMカプセル化文書保存SOP
クラスをサポートする。詳細なセマンティクスの説明については DICOM PS 3.4（附属書C）を参照のこと。
4.9.4.1.1

トリガイベント

報告書閲覧のユーザは特定報告書を閲覧用に選択する。
4.9.4.1.2

メッセージのセマンティクス

メッセージのセマンティクスは、DICOM問い合わせ／検索取得SOPクラスおよびDICOMカプセル
化保存SOPクラスで定義する。

45
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

DICOM検査ルート問い合わせ／検索取得情報モデル－MOVE SOPクラスまたはDICOM 患者ルート問い合わせ／検索取得情報モデル－MOVE SOPクラスからのC-MOVE要求は、報告書閲覧から報告書保管に送られる。
4.9.4.1.3

想定される動作

報告書保管アクタはC-MOVE要求を受信し、報告書閲覧とDICOM通信でアソシエーションを確立し、適切なDICOMカプセル化文書保存SOPクラスを使用して要求された報告書を転送する。
報告書保管はこの問い合わせに応答し、報告書作成から受け取ったDICOMインスタンスから情報を送信する。
報告書保管および報告書閲覧は、表4.7.5-1で定義するSOPクラスをサポートしていなければならな
い。
4.9.4.2

報告書の閲覧

本トランザクションは、上の相互作用図の「報告書の閲覧」に関連する。
4.9.4.2.1

PDFバージョン要件

DICOM規格は、カプセル化PDFを用いる際に特定PDFバージョンの使用を規定していない。この結果、ファイル作成ソフトウェアにより異なるPDFバージョンが使用されたときに報告書の表示の不整合が生じうる。臨床上問題になりかねないエラーとしては、空白、ページの落丁、図表の漏れや位置の間違い、フォーマットの重要な変更などがよくみられる。
4.9.4.3

トリガイベント

報告書閲覧が報告書保管から報告書を受信する。
4.9.4.4

起動セマンティクス

これは報告書閲覧でのローカルな起動であり、報告書閲覧が報告書データを解釈および表示するために用いられる方法はIHEテクニカルフレームワークの範囲外である。
4.9.4.5

想定される動作報告書閲覧はDICOMカプセル化文書をユーザに提示する。
4.9.4.6

PDFバージョン要件

DICOM規格は、カプセル化PDFを用いる際に特定PDFバージョンの使用を規定していない。この結果、ファイル作成ソフトウェアにより異なるPDFバージョンが使用されたときに報告書の表示の不46
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNAIHE 眼科テクニカルフレームワーク、vol.II：トランザクション

整合が生じうる。臨床上問題になりかねないエラーとしては、空白、ページの落丁、図表の漏れや位置の間違い、フォーマットの重要な変更などがよくみられる。
こうした問題に対応するために、規格に基づくISO PDFが開発されている。報告書閲覧アクタは、
PDF/A；ISO/DIS19005-1、文書管理－電子文書ファイルの長期保存用のフォーマット－パート1：
PDFの使用（PDF/A）をサポートしなければならない。
報告書表示アクタは PDF／A規格に準拠したDICOMカプセル化PDF文書を表示するためにPDF／A
閲覧要件に準拠しなければならない。これは、文書の目に見える形の正確なレンダリングを確実にすることを目的とした要件である。

47
試験的実装版 Year 3 著作権所有© 2008: AAO, HIMSS, RSNA