IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
Copyright © 2012: IHE International, Inc.

医療機関情報統合 （IHE）
Integrating the Healthcare Enterprise （IHE）

IHE放射線テクニカルフレームワーク
IHE Radiology Technical Framework

第三巻
トランザクション（続）Volume 3（IHE RAD TF-3）
Transactions （continued）

改訂第 11 版確定本
2012 年 7 月 24 日_______________________________________________________________________________________________________________________________________________

1
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
目次

前書き ............................................................................................................................................ 4
1.1 テクニカルフレームワークの概観 ............................................................................................. 4
1.2 第三巻の概要 ........................................................................................................................... 5
4 IHE トランザクション ........................................................................................................................ 5
4.32 拠点認証 （Authenticate node） －廃止 .............................................................................. 54.33 時刻維持 （Maintain Time） －廃止 .................................................................................... 5
4.34 監査事例記録 （Record Audit Event） .................................................................................. 5
4.35 通知済課金情報 （Charge Posted） ....................................................................................... 5
4.36 会計口座管理 （Account Management） ................................................................................ 94.37 後処理業務一覧問い合わせ（Query Post-Processing Worklist） ........................................ 15
4.38 業務項目取得要求 （Workitem claimed） ........................................................................ 17
4.39 作業項目検査段階進行中 （Workitem Performed Procedure Step in Progress） ............. 19
4.40 作業項目検査段階完了（Workitem Performed Procedure Step Completed） ...................... 21
4.41 作業項目完了済（Workitem Completed） ............................................................................. 23
4.42 の実行済作業状態更新（Performed Work Status Update） .................................................. 24
4.43 エビデンス書類保存完了（Evidence Document Stored） ..................................................... 26
4.44 エビデンス書類（ED）問合せ ............................................................................................... 28
4.45 エビデンス書類（ED）の取得（Query Evidence Documents）............................................... 29
4.46 レポート作業一覧問合せ （Query Reporitng Worklist） ...................................................... 31
4.47 媒体上画像情報配布（Distribute Imaging Information on Media） .................................... 34
4.48 予約通知（Appointment Notification） ................................................................................. 44
4.50 インスタンス保存 （Store Instances） ..................................................................................... 51
4.51 送出選択保存 （Store Export Selection） ............................................................................ 51
4.52 ティーチングファイル追加情報保存（Store Additional Teaching File Information） ........... 57
4.53 インスタンスの送出 （Export Instances） .............................................................................. 58
4.54 画像書類セットの提供と登録（Provide and Register Imaging Document Set－廃止 ......... 59
4.55 WADO 取得（WADO Retrieve） ........................................................................................ 59
4.59 取込み検査段階進行（Import Procedure Step In Progress） ............................................... 62
4.60 取込み検査段階完了・中止（Import Procedure Step Completed/Discontinued） ............... 65
4.61 取込みオブジェクト保存済み （Imported Objects Stored） ................................................. 69
4.62 線量情報の保存 （Store Dose Information） .................................................................... 72
4.63 線量情報提出 （Submit Dose Information） ....................................................................... 75
4.64 線量情報問合せ （Query Dose Information） ..................................................................... 79
4.65 線量情報取得 （Retrive Dose Information） ....................................................................... 82
4.66 意図して、一時的に空白です ........................................................................................... 84
4.67 意図して、一時的に空白です ........................................................................................... 84
4.68 画像書類セット提供と登録 Provide and Register Imaging Document Set – MTOM/XOP........................................................................................................................................................ 84
4.69 画像書類セット取得（Retrieve Imaging Document Set） ...................................................... 931_______________________________________________________________________________________________________________________________________________

2
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 A: 廃止 .................................................................................................................................. 103
付録 B: 廃止 ................................................................................................................................. 103
付録 C: 後処理業務流れでの汎用業務リスト、SPS, PPS および結果 Composite IOD 属性の整合.......................................................................................................................................................... 103
付録 D: レポート業務流れでの汎用業務リスト、SPS, PPS および結果 Composite IOD 属性の整合...................................................................................................................................................... 104
付録 E: DICOM 媒体交換－不可欠な DICOM 互換性のコツ .................................................... 105
付録 F: 作成された媒体内容物の実例 ........................................................................................ 107
付録 G: DICOM, WADO と web service 取得サービスの設定 ..................................................... 108
付録: H ティーチングファイル構造化レポート目録のひな形例 ................................................... 110
付録 I: 識別子削除、識別子再付与、偽名化、識別子保持と臨床試験属性（情報的内容） ..... 111
用語表.............................................................................................................................................. 113_______________________________________________________________________________________________________________________________________________

3
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
1

前書き

健康情報技術（HIT）システムの相互運用性と電子診療録（EHR）の効率的運用を実現するため、医療機
関情報統合（IHE）は標準規格の利用推進を主導しています。IHEは医療者の自主的委員会、健康情報技術（HIT）専門家、複数の臨床・業務領域の利害関係者が、標準規格に依拠した相互運用性の解決法の共通理解を得られる様、公開討論の場を提供しています。IHEは制作した機器実装手引き（IHEプロファイ
ル）を出版し、最初は一般から意見をあつめ、次いでHIT制作者や情報システム開発者の試験実装に役立
たせています。
IHEは、IHEプロファイルの実装を開発者が試すため、定期的試験であるコネクタソンを実施しています。
委員会が試験に成功し、実際の診療の場に導入できると判定すると、IHEテクニカルフレームワーク（TF）に組み込まれます。この書類はその一つの巻です。テクニカルフレームワークはHITシステムの開発者と使用者が利用できる特別な資源で、これを用いれば標準に準拠した、実証済みの相互運用性が確保され、EHRの利便性の高い安全な利用が実現できます。
システム購入者は、該当するIHEプロファイルに適合すべきことを要求仕様書で指定できます。製作者は、
IHEプロファイルを実装した製品に対して、適合性宣言（IHE統合書類）をIHE製品登録（http://productregistry.ihe.net）に掲載できます。
この書類および他のIHE書類はhttp://www.ihe.net/Technical_Framework/index.cfm/ から入手できます。
この書類への意見はhttp://www.ihe.net/radiology/radiologycomments.cfm まで申し出てください。
IHEの各領域委員会はテクニカルフレームワーク（TF）の開発と出版に責任を持っています。本書類はIHE放射線委員会により出版されています。この領域の動作、委員一覧や参加方法については、
http://wiki.ihe.net/index.php?title=Domainsに掲載しています。
IHEの組織、後援、会員組織については、www.ihe.netを参照してください。

1.1 テクニカルフレームワークの概観
本書類、すなわち、IHE テクニカルフレームワークは、定められている標準規格の実装法を定義し、医療情報共有を振興し、相互運用性を実現させて、最適な医療をもたします。本書類は毎年拡張され、一般への公開期間と閲覧をへて、誤りの発見と訂正をおこない、常に維持管理されています。最新版は第 11 版
で 、 IHE ト ラ ン ザ ク シ ョ ン を 規 定 し 2012 年 10 月 に 実 装 さ れ た も の で す 。 書 類 の 最 新 版 は 常 に
http://www.ihe.net/Technical_Framework にて取得可能です。
IHEテクニカルフレームワークは、医療期間の機能単位の構成要素であるIHEアクタ（アクタ）をさだめ、標準規格準拠の連携したトランザクションを定めています。本書類はトランザクションの本体を常に深化させています。
第一巻は IHE 機能の高所からの概観で、統合プロファイルと呼ばれます。機能単位として組織化されたトランザクション群を示して、特定の臨床的要望を処理する能力を明らかにします。 第二巻は、 IHE トランザ
クション RAD-1 から RAD-31 の詳細な技術的解説で、IHE の最初の 3 年間（1999 - 2001）で定めたものです。第三巻は IHE トランザクション RAD-32 から RAD-69 の詳細な技術的解説で、2002 年から 2007
年までの作業で定めたものです。2005 年には、IHE 基本保安が ITI-査察追跡と認証（ATNA）プロファイ
ルの放射線査察追跡オプションに置き換えられたため、第三巻で定めたトランザクション RAD-32, RAD-33,_______________________________________________________________________________________________________________________________________________

4
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
RAD-34 が廃止されました。

1.2 第三巻の概要
この巻の本体は第二巻第４節の続きです。RAD-32 から 69 までのトランザクションを詳細にさだめ、個々のアクタの役割、使用される標準、交換される情報、および、一部のトランザクションではオプションが特定されます。IHE のもとで実装された標準に準拠したトランザクションの凡例と、IHE アクタとトランザクションの構想の外観については、テクニカルフレームワーク第二巻を参照してください。本文に続く付録は、IHE
データモデルとトランザクションの技術的詳細を明らかにします。本巻の最後には用語一覧と、IHE テクニ
カルフレームワークで使用される、略語一覧があります。略語には関連する標準規格（HL7、DICOM、
IETF、W3C、ISO/CITI など）由来のものもあります。

4

IHE トランザクション

この節は、おのおののトランザクションの定義の詳細の続きで、使用する標準、送られる情報、トランザクショ
ンが必要、あるいは、オプションとなる条件を特定します。RAD-1 から RAD-31 トランザクションは、IHE 放射線技術枠組 第二巻、第 4 節を参照してください。

4.32 拠点認証（Authenticate node）－廃止

このトランザクションは、ＩＴＩ監査追跡と拠点認証プロファイルの一部です、認証済拠点におなじで、これに置き換えられました。（ITI-TF-2a: 3.1）

4.33 時刻維持 （Maintain Time）－廃止

このトランザクションは、ＩＴＩ一貫時刻プロファイルの一部です、時刻維持 （Maintain Time） におなじで、これに置き換えられました。（ITI-TF-2a: 3.1）

4.34 監査事例記録 （Record Audit Event）
このトランザクションは、ＩＴＩ監査追跡と拠点認証プロファイル（ITI-TF-2a: 3.20）と RAD TF-3: 5.1 に記載の放射線監査追跡オプションに置き換えられました。

4.35 通知済課金情報 （Charge Posted）
この節は IHE テクニカルフレームワークの RAD-35 トランザクションに該当します。RAD-35 トランザクション
は部門システム予定・オーダ実施役（DSS/OF）と会計処理役（Charge Processor）に使用されます。

4.35.1 範囲
通知済課金情報 （Charge Posted）トランザクションは、部門システム予定・オーダ実施役（DSS/OF）と会計処理役の間の通信文を規定します。HL7 会計トランザクション（HL7 Fianancial Transaction）通信文は請求を行うのに必要な検査情報を含んでいます。
部門システム予定・オーダ実施役（DSS/OF）は、会計処理役（Charge Processor）が使用する検査情報を提供します。会計処理役（Charge Processor）は、検査に関連する実際の処理料金がトランザクションに含まれると期待することも、期待しないこともあります。ある状況では、部門システム予定・オーダ実施役（DSS/OF）
が、検査の必要な詳細を適切な料金に対応させる最良の能力を持つことがあります。他の状況では、会計処理役がこの機能をはたします。いずれの場合も、会計処理役は部門システム予定・オーダ実施役（DSS/OF）が提供した料金を、書き換えることができます。

_______________________________________________________________________________________________________________________________________________

5
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
必要なデータが完全に揃っていることを確認する方法と手段は会計処理役（Charge Processor）の責任であり、IHE の範囲外です。
注； IHE は即時会計通知トランザクションを規定していますが、HL7 第二章、2.23.2 節に規定する
バッチ処理も適応できます。

仕様により、

4.35.2 使用例での役割
アクタ： 部門システム予定・オーダ実施役（Department System Scheduller/Order Filler, DSS/OF）
役割：課金情報の通知に関連する情報を収集し、下記の会計処理役（Charge Processor）に送信します。
アクタ：会計処理役（Charge Processor）
役割： 部門システム予定・オーダ実施役（DSS/OF）から情報を受けます。保険会社あるいは患者への請求書発行のため、請求を処理しまとめます。
4.35.3 参照する標準
Health Level 7 2.3.1 版：第 6 章 - 経済管理（Health Level Seven, Version 2.3.1: Chapter 6 - Financial

Management）
DICOM 2011 PS 3.4 撮影装置実装済検査段階 SOP クラス（DICOM 2011 PS 3.4. Modality Performed
Procedure Step SOP Class）
4.35.4 相互作用図
4.35.4.1 経済トランザクション通信文

詳細会計トランザクション(Detailed Finacial Transaction, DFT)通信文は、部門システム予定・オーダ実施役（DSS/OF）と会計処理役（Charge Processor）との間で伝達される会計トランザクションを記載するのに使用されます。
4.35.4.21.1 きっかけ事例
部門システム予定・オーダ実施役（DSS/OF）は会計処理役（Charge Processor）にいつ通知済課金情報トラ
ンザクションを送信するか決めます。会計トランザクション（Finantial transaction）には二つの類型があります。
技術料金と専門職料金です。それぞれは別々にきっかけを得て送信されてもよいですし、同時にきっかけを得て送信されてもよいです。
・技術料金請求書発行
検査の技術料金請求は典型的には検査完了がきっかけとなって行われます。検査実施状況管理役（Performed Procedure Step Manager, PPSM）は、撮影済段階完了（Modality Performed
Procedcure Step Completed）通知文を部門システム予定・オーダ実施役（DSS/OF）に送ります。この時点で、部門システム予定・オーダ実施役（DSS/OF）は検査が終了し会計処理役に課金情報を送信することを知ります。
乳房撮影 CAD の様なある種の後処理では、後処理管理役からの処理完了の確認通知を部門シ
ステム予定役・オーダ実行役（DSS/OF）が受け取るのをきっかけに、技術料金通知が送られます。
部門システム予定・オーダ実施役（DSS/OF）は、この確認通知を、後処理管理役とまとめて受け取ります； もし、後処理管理役が画像管理役（IM）と一体化されているときは、部門システム予定_______________________________________________________________________________________________________________________________________________

6
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
役・オーダ実行役（DSS/OF）への、後処理作業の完了を特定する、実行済作業状況更（Performed
Work Status Update）通信文をきっかけに、専門職料金の情報が会計処理役に送られます。
・専門職料金請求書発行
検査の専門職料金請求は放射線科医によるレポート作成完了・確認がきっかけとなって行われます。部門システム予定・オーダ実施役（DSS/OF）がレポートの作成完了を知ると、会計処理役に
専門職料金の情報が送られます。
部門システム予定・オーダ実施役（DSS/OF）は、レポート管理役(RM)からレポート作成の完了・確認の確認通知を受け取ります。部門システム予定・オーダ実施役（DSS/OF）は、この通知をレ
ポート管理役（RM）とまとめて受け取ります。もしレポート管理役(RM)がレポート業務流れ（RWF）
プロファイルを実装しているときは、レポート作成完了を特定する実行済作業状況更（Performed
Work Status Update）によるトランザクションがきっかけとなって、専門職料金の請求が会計処理役に送られます。
4.35.4.1.2 通信文の意味
部門システム予定・オーダ実施役（DSS/OF）は、詳細会計トランザクション（Detailed Financial Transaction、DFT）通信文を使って、必要な課金情報を会計処理役（Charge Processor）に送ります。会計処理役（Charge Processor）は、ADT 患者登録トランザクションで、以前受けた、関連する患者基本情報を取得しなければなりません。
部門システム予定・オーダ実施役（DSS/OF）は、撮影段階段階完了済/中止（Modality Procedure Step
Completed/Discontinued）トランザクションを受けて、検査完了を確認します。この情報には DICOM 請求と機材管理コードモジュール（DICOM Billing and Material Code Module）を含んでおり、検査、物品、および、機器の情報が提供されます。
通知済課金情報（Charge Posted）トランザクションは、DFT（Detailed Financial Transaction）通信文の P03
事例（event）を使って、通知されます。
追加の検査、機材、機器が存在する場合には、一個以上の PR1 セグメントが必要です。その他の場合には必要ありません。
注：追加の仕様レベルの資格と HL7 のプロファイルは RAD TF-2:2.3 に記されています。

必須のセグメントは以下に規定されます。他はオプションです。
注： IHE テクニカルフレームワークへの、適応可能な、地域あるいは国による追加により、PV1-19 来院番号が必須の時
は、PV-1 は、必須です(RAD TF-4 参照)。

個々の通信文は、DFT 通信文の受け側から送信側に送られた、HL7 ACK 通信文で受信を通知されねばなりません。ACK 通信文の定義と議論は、RAD TF-2: 2.4.3 「受信通知モード」を参照してください。
4.35.4.1.2.1 MSH セグメント （MSH Segment）
MSH セグメントは RAD TF-2:2.4.2.2 通信文制御で定義されたように構成されねばなりません。MSH-9 通信文類型（Message Type）は少なくとも 2 つの成分を持たねばなりません。1 番目は"DFT"、2 番目の成分
は"P03"です。
4.35.4.1.2.2 EVN セグメント （EVN Segment）
EVN セグメントは受信側アプリケーションに、必要なきっかけ事例の情報を通信するために使用されます。
_______________________________________________________________________________________________________________________________________________

7
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
EVN セグメントの必須およびオプションのデータ欄（field）は、RAD TF-2:4.1.4.1.2.1.2 を参照してください。
4.35.4.1.2.3 PID セグメント （PID Segment）
PID セグメントの全てのデータ欄（field）は表 4.35-1 に挙げるものを除いて、すべてオプションです。PID セ
グメントの全データ欄（field）の一覧は、RAD-TF-2:4.1.4.1.2.1.3 を参照してください。
表 4.35-1: IHE Profile – PID segement
4.35.4.1.2.4 PV1 セグメント （PV1 Segment）
PV1 セグメントの大部分のデータ欄（field）は、表 4.35-2 に挙げるものを除いて、すべてオプションです。
PID セグメントの全データ欄（field）の一覧は、RAD-TF-2:4.1.4.1.2.1.4 を参照してください。
表 4.35-2: IHE Profile – PV1 Segment
少なくとも、PID-18 患者会計口座番号、あるいは、PV1-19 来院番号のいずれか一方には値を入れねばなりません。これらのデータ欄（field）の値の追加要求事項は、IHE テクニカルフレームワークへの地域、国による追加に記載されていることがあります。 （RAD-TF4 参照）
PV1-19 来院番号（Visit Number）が存在するときにはデータ欄（field）PV1-51 来院指標（Visit Indicator）は、"V"の値を持たねばなりません。さもなければ省略可能です。
4.35.4.1.2.5 FT1 セグメント （FT1 Segment）
FT1 セグメントは、請求、クレジット、支払い、と訂正を患者の会計口座に記録するために使用されます。
表 4.35-3: IHE プロファイル– FT1 Segement
4.35.4.1.2.6 PR1 セグメント （PR1 segment） - 検査
PR1 セグメントは、患者に行われる検査の種々の類型に関連する情報を含みます。PR1 セグメントは検査情報を送信するのに使われます。たとえば、外科、核医学、造影 X 線検査、等です。PR1 セグメントは、た
とえば、診療録のコード化のため、会計処理のため、複数検査を送信するのに使われます。
表 4.35-4: PR1 Attribute
注： 個々の PR1 セグメントは一個の検査コードまたは一個の修飾子コードを持ちます。

4.35.4.2 情報源
課金情報通知済（Charge Posted）トランザクションは以下に記す三つの源泉からデータを導きだします。表4.35-4 に、FT1 セグメントと PR1 文節の対応を示します。
・ オーダ管理
オーダ発行役一般オーダ通信文（Order Placer General Order Message）は部門システム予定・オーダ実施
役（DSS/OF）に、PID セグメントで使用する、必須の課金情報通和済（Charge Posted）トランザクションデー
タ欄（field）を提供します。必須とオプションのデータ欄（field）については、RAD TF-2:4.2, 4.31 を参照して_______________________________________________________________________________________________________________________________________________

8
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________ください。
・ 撮影済検査段階（Modality Performed Proceduree Step, MPPS）
撮影機器一般オーダ通信文（Modality General zorder Message）は、部門システム予定役・オーダ
実行役（DSS/OF）に、FT1 セグメントと PT1 セグメントとで使用する、必須の課金情報通和済（Charge Posted）トランザクションデータ欄（field）を提供します。追加の、検査、機材の情報がDICOM 機材請求と管理通知文に含まれます。必須とオプションのデータ欄（field）については、
RAD-TF-2;4.7（撮影済検査段階完了/中止 (Modality Performed Porceure Step
Completed/Discontinued) ）を参照してください。
通信文の意味は DICOM 2011 撮影済検査段階 SOP クラス (Modality Performed Porceure Step SOPClass)の DICOM サービスクラス節にあります。検査情報の、部門システム予定・オーダ実施役（DSS/OF）
への送信を確保するのは、撮影装置の責任です。
・用手トランザクション・部門システム予定・オーダ実施役（DSS/OF）
課金情報通和済（Charge Posted）トランザクション情報の用手入力も可能です。会計処理役（Charge Processor）が必要としますが、撮影装置、オーダ発行役からは提供されない情報の入力を可能とします。このデータは、用手的に入力されるか、部門システム予定・オーダ実施役（DSS/OF）の機能とされます。
表 4.35-5: FT1 通信文の対応付け
表 4.35-6: PR1 セグメントの対応付け
4.35.4.2.1.1 予期される動作部門システム予定・オーダ実施役（DSS/OF）は課金情報通和済（Charge Posted）トランザクションを、きっかけ事例が起きたときに、会計処理役（Charge Processor）へ送ることが期待されています。これは、技術料金、
あるいは、専門職料金の請求トランザクションのことがあります。

4.36 会計口座管理 （Account Management）
この節は IHE テクニカルフレームワークの RAD-36 トランザクションに該当します。RAD-36 トランザクション
は患者登録と会計処理役（Charge Processor）に使用されます。
4.36.1 範囲
会計口座管理トランザクションは、ADT 患者登録と会計処理役（Charge Processor）の間の通信文を規定します。この通信文は患者の会計口座が作られる時、更新される時、あるいは閉鎖される時、送信されます。
部門システム予定・オーダ実施役（DSS/OF）に送る必要のある情報、たとえば、保険や保証人の情報、を最小にするのに役立ちます。会計処理役（Charge Processor）は、ADT から直接に情報を受け取ります。
4.36.2 使用例の役割
アクタ： ADT 患者登録
役割：患者口座（原文は Account patient. Patient account の誤り？）に関連する情報をあつめ、会計処理役（Charge Processor）に送信します。
アクタ： 会計処理役（Charge Processor）_______________________________________________________________________________________________________________________________________________

9
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
役割： 患者登録から情報を受け取ります。保険会社あるいは患者への請求書発行のため、請求を処理し、まとめます。
4.36.3 参照する標準
Health Level 7 2.3.1 版：第 6 章 - 経済管理 （Health Level Seven, Version 2.3.1: Chapter 6 -Financial Management）
4.36.4 相互作用図
4.36.4.1 会計口座管理 - 新規
会計口座管理通信文は、ADT 患者登録と会計処理役（Charge Processor）との間で交わされる、患者会計
口座トランザクションを記載するのに使用されます。ADT 患者登録アプリケーションから会計処理、経済シ
ステムへ、患者の請求・口座保存用記録を保管する会計口座開設のため、データが送られます。
4.36.4.1.1 きっかけ事例
新しい会計口座開設は以下の ADT 患者登録事例の一つが起こると、行われます。
・ 入院患者の施設への入院・ 外来患者の施設への来院時の登録・ 入院患者の仮入院（すなわち、実際の入院前に患者情報の登録を行うこと）
会計口座の開設は以下の口座管理通信文を生成します。
・ P01 － Add Patient Account
4.36.4.1.2 通信文の意味
会計口座管理（Account Management）トランザクションは、HL7 BAR 通信文により行われます。ADT アクタ
は、患者が入院したとき、仮入院したとき、あるいは登録されたときはいつでも、この通信文を生成しなければなりません。”P01”事例はあたらしい患者を加えるときのみ、つまり、以前に居なかった患者の登録のみに使用されねばならず、既存の口座の更新ではありません。新しい"P05"（update account）事例は既存の口座を更新するときに使用しなければなりません。新しい"P06"（end account）事例は既存の口座を閉鎖するときに使用しなければなりません。
会計口座作成の際に診断がわかっているなら、一個以上の DG1 セグメントが存在せねばなりません。それ以外ではなくて良いです。
会計口座作成の際に保証人（患者本人であってもよい）がわかっているなら、一個以上の GT1 セグメントが存在せねばなりません。それ以外ではなくて良いです。
会計口座作成の際に保険情報がわかっているなら、一個以上の IN1 セグメントが存在せねばなりません。
それ以外ではなくて良いです。
注：追加の仕様レベルの資格と HL7 のプロファイルは RAD TF-2:2.3 に記されています。

以下に列挙された"Add Patient Account"通信文のセグメントは必須で、通信文の詳細な記載は以下の亜節に記載されます。
注：適用可能な IHE テクニカルフレームワークへの地域、国による追加に沿うため、PV1-19 来院番号（Visit Number）の使用が必須の場合、PV1 が必須になることがあります。（RAD-TF4 参照）

個々の通信文は、BAR 通信文の受信側から送信側に送られた、HL7 ACK 通信文で受信を通知_______________________________________________________________________________________________________________________________________________

10
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
されねばなりません。ACK 通信文の定義と議論は、RAD TF-2: 2.4.3 受信通知モードを参照してく
ださい。
4.36.4.1.2.1 MSH セグメント （MSH Segment）
MSH セグメントは RAD TF-2:2.4.2.2 通信文制御で定義されたように構成されねばなりません。MSH-9 通信文類型（Message Type）は少なくとも 2 つの成分を持たねばなりません。1 番目は"BAR"、2 番目の成分
は"P01"です。
4.36.4.1.2.2 EVN セグメント （EVN Segment）
EVN セグメントは受信側アプリケーションに必要なきっかけ事例の情報を通信するために使用されます。
EVN セグメントの必須およびオプションのデータ欄（field）は、RAD TF-2:4.1.4.1.2.1.2 を参照してください。
4.35.4.1.2.3 PID セグメント （PID Segment）
PID セグメントの全てのデータ欄（field）は表 4.36-1 に挙げるものを除いて、すべてオプションです。PID セ
グメントの全データ欄（field）の一覧は、RAD-TF-2: 4.1.4.1.2.1.3 を参照してください。
4.36.4.1.2.4 PV1 セグメント （PV1 Segment）
PV1 セグメントの大部分のデータ欄（field）は表 4.36-2 に挙げるものを除いて、すべてオプションです。PID
セグメントの全データ欄（field）の一覧は、RAD-TF-2: 4.1.4.1.2.1.4 を参照してください。
表 4.36-1: IHE プロファイル – PID セグメント
少なくとも、PID-18 患者会計口座番号、あるいは、PV1-19 来院番号のいずれか一方には値を入れねばなりません。これらのデータ欄（field）の値の追加要求事項は、IHE テクニカルフレームワークへの地域、国による追加に記載されていることがあります。 （RAD-TF4 参照）
PV1-19 来院番号（Visit Number）が存在するときにはデータ欄（field）PV1-51 来院指標 （Visit Indicator）
は、"V"の値を持たねばなりません。さもなければ省略可能です。
4.36.4.1.2.5 DG1 セグメント （DG1 Segment）
DG1 文節は種々の類型の診断情報を含んでいます。たとえば、入院時診断、主要診断、等です。DG1 セ
グメントは複数の診断（たとえば、診療録のコード化のため）を送信するのに使用されます。TF1-19diagnosis code（診断コード）が十分な情報を会計システムに与えないときにも使用されます。この診断のコード化は、診療提供者が患者管理に使う臨床問題セグメントとは区別されねばなりません。表 4.36-3 は、
DG1 セグメントの必須およびオプションの属性の一覧です。
表 4.36-3: IHE プロファイル – DG1 セグメント
4.36.4.1.2.6 GT1 セグメント （GT1 Segment）
GT1 セグメントは、患者や保険会社への請求のため、保証人（たとえば、患者の勘定支払いに経済的責任を持つ人物あるいは組織）データを含んでいます。表 4.36-4 は、DG1 セグメントの必須およびオプションの属性の一覧です。
表 4.36-4: IHE プロファイル – GT1 セグメント
4.36.4.1.2.7 IN1 セグメント （IN1 Segment）_______________________________________________________________________________________________________________________________________________

11
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
IN1 セグメントは、患者や保険会社への請求のため必要な保険適応範囲方針情報を含みます。表 4.36-5
は、IN1 セグメントの必須およびオプションの属性の一覧です。
表 4.36-5: IHE プロファイル – IN1 セグメント
4.36.4.1.2.8 予期される動作
患者会計口座追加（ADD Patient Account）トランザクションを受信したあと、受信側のシステムは会計口座情報を作り、維持して、会計処理を行うときに利用します。

4.36.4.2 会計口座管理 － 口座の更新
4.36.4.2.1 きっかけ事例
患者会計口座情報の更新（例えば、患者氏名、住所、保証人、保険、などの変更）は、以下の会計口座更
新通信文のきっかけにせねばなりません。
・ P05 - 会計口座の更新
4.36.4.2.2 通信文の意味
会計口座管理トランザクションは、HL7 BAR 通信文により行われます。ADT アクタは、患者会計口座情報が変更されたときはいつでも、この通信文を生成しなければなりません。”P05”（update account）事例は既存の会計口座を更新する時のみ、使用されねばなりません。新しい"P06"（end account）事例を既存の口座を閉鎖するときに使用しなければなりません。
患者記録の全ての必須情報（"R"と"R2"）は”P05”通信文で再送されねばなりません。”P05”通信文のなかで NULL 値（すなわち２個のダブルクオーテーションマーク、""）で受信・送信された項目は、受信側システ
ムの該当患者の記録のデータベースからすべて削除されます。もし、”P05”トランザクションで値が送信されない（省略されている）と、受信側システムの該当患者の記録のータベースの古い値が変更されずに保持されます。
注：追加の仕様レベルの資格と HL7 のプロファイルは RAD TF-2:2.3 に記されています。

以下に列挙された患者会計口座追加（Add Patient Account）通信文のセグメントは必須で、通信文の詳細
は 4.36.4.1.2.5 節に記載されます。患者の診断が更新された場合は、一個以上の DG1 セグメントが存在せねばなりません。患者の保証人情報が更新された場合は、一個以上の GT1 セグメントが存在せねばな
りません。患者の保険情報が追加あるいは変更された場合は、一個以上の IN1 セグメントが存在せねばな
りません。
注：適用可能な IHE テクニカルフレームワークへの地域、国による追加に沿うため、PV1-19 来院番号（Visit
Number）の使用が必須の場合、PV1 も必須になることがあります。（RAD-TF4 参照）

個々の通信文は、受信側から送信側に送られた、HL7 ACK 通信文で受信を通知されねばなりません。
ACK 通信文の定義と議論は、RAD TF-2: 2.4.3 受信通知モードを参照してください。
4.36.4.2.2.1 MSH セグメント （MSH Segment）
MSH セグメントは RAD TF-2:2.4.2.2 「通信文制御（Message Control）」）で定義されたように構成されねばなりません。
MSH-9 通信文類型（Message Type）は少なくとも 2 つの成分を持たねばなりません。1 番目は"BAR"、2_______________________________________________________________________________________________________________________________________________

12
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
番目の成分は"P06"です。
4.36.4.2.2.2 EVN セグメント （EVN Segment）
EVN セグメントは受信側アプリに必要なきっかけ事例の情報を通信するために使用されます。EVN セグメ
ントの必須およびオプションのデータ欄（field）は、4.1.4.1.2.1.2 を参照してください。
4.36.4.2.2.3 PID セグメント （PID Segment）
PID セグメントの全てのデータ欄（field）は表 4.36-6 に挙げるものを除いて、すべてオプションです。PID セ
グメントの全データ欄（field）の一覧は、RAD-TF-2:4.1.4.1.2.1.3 を参照してください。
表 4.36-6: IHE プロファイル – PID セグメント
4.36.4.2.2.4 PV1 セグメント （PV1 Segment）
PV1 セグメントの大部分のデータ欄（field）は表 4.35-7 に挙げるものを除いて、すべてオプションです。PID
セグメントの全データ欄（field）の一覧は、RAD-TF-2:4.1.4.1.2.1.4 を参照してください。
表 4.36-7: IHE プロファイル – PV1 セグメント
少なくとも、PID-18 患者会計口座番号、あるいは、PV1-19 来院番号のいずれか一方には値を入れねばなりません。これらのデータ欄（field）の値の追加要求事項は、IHE テクニカルフレームワークへの地域、国による追加に記載されていることがあります。 （RAD-TF4 参照）
PV1-19 来院番号（Visit Number）が存在するときにはデータ欄（field） PV1-51 来院指標 （Visit Indicator）
は、"V"の値を持たねばなりません。さもなければ省略可能です。
4.36.4.2.2.5 DG1 セグメント （DG1 Segment）
DG1 文節の必須およびオプションデータ欄（field）については 4.36.4.1.2.5 節を参照してください。
4.36.4.2.2.6 GT1 セグメント （GT1 Segment）
GT1 文節の必須およびオプションデータ欄（field）については 4.36.4.1.2.6 節を参照してください。
4.36.4.3.2.7 IN1 セグメント （IN1 Segment）
IN1 セグメントの必須およびオプションデータ欄（field）については 4.36.4.1.2.7 節を参照してください。
4.36.4.2.3 予期される動作
会計口座情報更新（Update Account Information）通信文を受信したあと、受信側のシステムは現場施設の患者基本情報、診断、保証人、および・または、保険情報を更新しなければなりません。新しい"P05"通信文で NULL 値が受信されたとき、該当データは現場施設のデータベースから削除されねばなりません。
4.36.4.3 会計口座管理 － 口座の閉鎖
4.36.4.3.1 きっかけ事例
患者会計口座の終結あるいは閉鎖は、典型的には患者の退院、来院の終了、により起こり、以下の会計口
座管理通信文のきっかけになります。
・ P06 - 会計口座の閉鎖_______________________________________________________________________________________________________________________________________________

13
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.36.4.3.2 通信文の意味
会計口座管理トランザクションは、HL7 BAR 通信文により行われます。ADT アクタは、患者会計口座が閉鎖されたときはいつでも、この通信文を生成しなければなりません。新しい"P06"（end account）を既存の口座を閉鎖するときに使用しなければなりません。
注； 仕様の水準と HL7 プロファイルの追加の資格は、RAD TF-2.3 に述べられています。

以下に列挙された会計口座の閉鎖（End Account）通信文のセグメントは必須で、通信文の詳細な記載は以下の亜節に記載されます。
注：適用可能な IHE テクニカルフレームワークへの地域、国による追加に沿うため、PV1-19 来院
番号（Visit Number）の使用が必須の場合、PV1 も必須になることがあります。（RAD-TF4 参照）
個々の通信文は、受信側から送信側に送られた、HL7 ACK 通信文で受信を通知されねばなりません。
ACK 通信文の定義と議論は、RAD TF-2: 2.4.3 受信通知モードを参照してください。
4.36.4.3.2.1 MSH セグメント （MSH Segment）
MSH セグメントは RAD TF-2:2.4.2.2 通信文制御（message control）で定義されたように構成されねばなりません。MSH-9 通信文類型（Message Type）は少なくとも 2 つの成分を持たねばなりません。1 番目は"BAR"、2 番目の成分は"P06"です。
4.36.4.3.2.2 EVN セグメント （EVN Segment）
EVN セグメントは受信側アプリに必要なきっかけ事例の情を通信するために使用されます。EVN セグメン
トの必須およびオプションのデータ欄（field）は、RAD TF-2: 4.1.4.1.2.1.2 を参照してください。
4.36.4.3.2.3 PID セグメント （PID Segment）
PID セグメントの全てのデータ欄（field）は表 4.36-8 に挙げるものを除いて、すべてオプションです。PID セ
グメントの全データ欄（field）の一覧は、RAD-TF-2: 4.1.4.1.2.1.3 を参照してください。
表 4.36-8: IHE プロファイル – PID セグメント
4.36.4.3.2.4 PV1 セグメント （PV1 Segment）
PV1 セグメントの大部分のデータ欄（field）は表 4.35-9 に挙げるものを除いて、すべてオプションです。PID
セグメントの全データ欄（field）の一覧は、RAD-TF-2: 4.1.4.1.2.1.4 を参照してください。
表 4.36-9: IHE プロファイル - PV1 Segment
少なくとも、PID-18 患者会計口座番号、あるいは、PV1-19 来院番号のいずれか一方には値を入れねばなりません。これらのデータ欄（field）の値の追加要求事項は、IHE テクニカルフレームワークへの地域、国による追加に記載されていることがあります。 （RAD-TF4 参照）
PV1-19 来院番号（Visit Number）が存在するときにはデータ欄（field）PV1-51 来院指標 （Visit Indicator）
は、"V"の値を持たねばなりません。さもなければ省略可能です。

4.36.4.3.3 予期される動作_______________________________________________________________________________________________________________________________________________

14
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
患者会計口座閉鎖（End Patinet Account）通信文（P06）を受けた後、受信側システムは、現場施設の患者会計口座が閉鎖されたことを反映するように、患者会計情報を更新します。

4.37 後処理業務一覧問い合わせ（Query Post-Processing Worklist）
この節は IHE テクニカルフレームワークの RAD-37 トランザクションに該当します。RAD-37 トランザクション
は後処理管理役とエビデンス書類（ED）生成役に使用されます。
4.37.1 範囲
後処理業務一覧問い合わせは、後処理業務中にエビデンス生成役（EC）が、後処理管理役（PostProseccing Manager）によって予定された業務を、見いだすために使用されます。このトランザクションは、
画像処理、コンピュータ支援診断、コンピュータ支援検出の後処理関連業務項目のコードを提示します。
業務一覧を一般的に記述します。
後処理管理役は、業務一覧を提供します。部門システム予定・オーダ実施役（DSS/OF）、または、画像管理役（IM）と一体化されて、後処理管理役は必要な情報を得ます。エビデンス生成役（EC）は業務一覧を取得し、生成した結果インスタンスに受診した情報を入れ込み、エビデンス書類（ED）保存済、画像保存済の様な、インスタンス保存トランザクションにより、保存されます。
4.37.2 使用例役割
アクタ：エビデンス生成役（EC）（Evidence Creator）
役割： 後処理管理役（Post-Processing Manager）に後処理予定検査段階（Post-Proseccing Scheduled
Procedure Step）を問い合わせます。
アクタ： 後処理管理役（Post-Processing Manager）
役割： 画像処理、コンピュータ支援診断、コンピュータ支援検出の業務項目の、後処理検査段階を予定
します；業務一覧にある業務項目要求を受け付け、問い合わせを実行して結果をもどします。

4.37.3 参照する標準DICOM 2011 PS 3.4: 汎用業務一覧 SOP クラス（DICOM 2011 PS 3.4: General Purpose Worklist SOPClass）
4.37.4 相互作用図
4.37.4.1 汎用作業項目業務一覧問合せ通信文（Query General Purpose Worklist Message）
これは、後処理管理役へ送られる作業一覧問合せです。
4.37.4.1.1 きっかけ事例 （Trigger Events）
後処理管理役に送られた問い合わせがきっかけとなります。
4.37.4.1.2 通信文の意味
DICOM 汎用業務一覧 SOP クラス（General Purpose Worklist SOP）の"C-FIND"要求が汎用業務一覧問い
合わせに使用されます。エビデンス生成役（EC）は SCU となり、後処理管理役は SCP となります。

_______________________________________________________________________________________________________________________________________________

15
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.37.4.1.2.1 照合キーと返答キー
エビデンス生成役（EC）は、後処理の結果生成されたインスタンスに挿入する、特定の属性（返答キー）を問い合わせます。詳細は付録 D を参照してください。
エビデンス生成役（EC）は表 4.37-4「後処理業務一覧問い合わせ」の返答および照合キーに列挙された必須の問い合わせキーのそれぞれを別々に使用可能としなければなりません。加えて、以下の内、すくなくとも一個を、エビデンス生成役（EC）に実装しなければなりません。
１．患者指向問い合わせ： 特定の患者・検査に対する問い合わせです。SCU は表 7.37-1 に挙げられた、全て（31）の照合キー属性の組み合わせを、一個以上のキーを含んで使用可能としなければなりません。
斜字で示される一連属性は照合キーではありませんが、属性の値を問い合わせの中で伝えるため、問い合わせに含む必要があります。従って、SCU は患者氏名、患者 ID、承認番号（Accession Number）、と要望検査 ID、予定業務項目コードのいかなる組み合わせにも応える必要があります。
表 4.37-1: 患者指向問合せの GPWL キー
2. ワークステーション指向問い合わせ（Station -oriented Query）: 特定のワークステーションの広範な業
務一覧を問い合わせます。SCU は表 7.37-2 に挙げられた、全て（15）の照合キー属性の組み合わせを、一個以上のキーを含んで使用可能としなければなりません。斜字で示される一連属性は照合キーではありませんが、属性の値を問い合わせの中で伝えるため、問い合わせに含む必要があります。Scheduled
Station Name Code Sequence のコード値が存在する場合には、ワークステーションの General Purpose
Worklist SCU の AE Title でなければなりません。
表 4.37-2 ワークステーション指向問合せの GPWL キー
3. クラス指向問い合わせ （Class-oriented Query）: 特定のワークステーションクラスの広範な業務一覧を問い合わせます。SCU は表 7.37-3 に挙げられた、全て（15）の照合キー属性の組み合わせを、一個以上のキーを含んで使用可能としなければなりません。斜字で示されます。一連属性は照合キーではありませんが、属性の値を問い合わせの中で伝えるため、問い合わせに含む必要があります。
表 4.37-3 クラス指向問い合わせ GPWL キー
4.37.4.1.2.2 照合キー属性使用の例
・ 予定検査段階開始時刻と日付の使用：本日予定された後処理業務の問い合わせ。
・ 予定業務項目キーの使用：全てのコンピュータ支援検出（CAD）業務の問い合わせ・ 予定ステ－ション名キーの使用： このワークステ＾ションで予定されている全ての後処理の問い合わせ・予定検査段階開始時刻と日付、予定業務項目コード、予定ステーションクラスコードキーの使用：本日 CT 3D ワークステーションで予定された全ての業務
注：構造化の有無に関わらず問い合わせの成功を容易にするため、アプリは、ワイルドカード（*）を構造化患者氏名の各目の最後に追加するよう推奨されます。

4.37.4.1.2.3 照合キーと返答キー
エビデンス書類（ED）生成役は、自己の生成するオブジェクトの多くが必要とするような、特定の属性（返答キー）を問い合わせられねばなりません。保存オブジェクト属性の照合キー要求事項は付録 C に定義されています。問い合わせ可能な追加の属性もあります。
表 4.37-4 は、エビデンス生成役（EC）の使用者に使用可能にさせるため、照合キー要求事項と、問い合わ_______________________________________________________________________________________________________________________________________________

16
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
せと返答ができるオプションと必須の属性を、一覧にまとめています。詳細な情報と、この表で使用されている凡例とについては、RAD TF-2:2.2 を参照してください。
表 4.37-4:

後処理業務一覧問い合せ（Post-Proseccing Worklist Query)の照合キーと返答キー

4.37.4.1.3 期待される動作
後処理管理役は問い合わせを実行し、エビデンス生成役（EC）に問い合わせに合致する汎用業務一覧項
目を送信します。
4.37.4.2 汎用業務一覧受領通信文 （Recieve General Purpose Worklist Message ）これは後処理管理役が送る通信文で、エビデンス生成役（EC）からの問い合わせに応えて、後処理汎用業
務一覧情報を含んでいます。
4.37.4.2.1 きっかけ事例
後処理管理役が後処理業務一覧の問い合わせを受信します。
4.37.4.2.2 通信文の意味
DICOM 汎用業務一覧 SOP クラスの"C-FIND"応答がこの通信文に使用されます。業務一覧を通じて問い合わされた一部の属性は、業務流れの既往の検査段階のなかで他の情報源から派生し、（部門システム
予定・オーダ実行役（DSS/OF）あるいは画像管理役（IM）と一体化された）後処理管理役に、MPPS などの他のトランザクションにより使用可能とされます。作業項目予定処理段階（workitem Scheduled ProcedureStep）に使用するに適切な入力情報の決定、たとえば、検査(study)、シリーズなど、は後処理管理役に任されています。すなわち、予定処理段階は、撮影過程や結果生じる MPPS とは独立しています。
後処理アクタは、DCMR CID 9231 の以下の値を使用して、予定業務項目コード一連（0040, 4018）の内容のもとで、おこなう業務の類型を特定せねばなりません。
表 4.37-5: 後処理作業項目定義
4.37.4.2.3 予期される動作
自動化されたエビデンス生成役（EC）は業務一覧を使って後処理を開始するか、使用者が業務一覧を提供されて業務を開始します。

4.38 業務項目取得要求（Workitem claimed）

この節は IHE テクニカルフレームワークの RAD-38 トランザクションに該当します。RAD-38 トランザクショ
ンは後処理管理役、レポート管理役(RM)、レポート生成役（RC）、診療情報生成役に使用されます。
4.38.1 範囲
後処理業務項目を選択した時、エビデンス生成役（EC）はその項目の所有者となり、後処理管理役に業務項目の SPS（訳注：Scheduled Procedure Step, 予定検査段階）の状態を IN PROGRESS に変えるよう指示します。これにより、後処理管理役は業務一覧を更新して、他の業務一覧使用者が、この業務項目がすでに請求されおそらく既に業務が行われていることが、わかるようにします。
同様に、レポート業務流れでも、レポート処理業務項目を選択した時、レポート生成役（RC）はその項目の所有者となり、レポート管理役(RM)に業務項目の SPS の状態を IN PROGRESS に変えるよう指示します。
これにより、レポート管理役(RM)は業務一覧を更新して、他の業務一覧使用者が、この業務項目がすでに請求されおそらく既に業務が行われていることが、わかるようにします。
いずれの業務流れでも SCU は状態を SUSPEND に変更できます。
_______________________________________________________________________________________________________________________________________________

17
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.38.2 使用例役割
アクタ：エビデンス生成役（EC）
役割： エビデンス生成役（EC）が後処置 SPS（訳者注: Scheduled Procedure Step）を請求したとき、後処理
管理役の後処理 SPS を更新して新しくします。
アクタ：後処理管理役
役割： エビデンス生成役（EC）からの後処理 GP-SPS 更新情報を受け付けます
アクタ：レポート生成役（RC）
役割：レポート生成役（RC）がレポート SPS を請求したとき、レポート管理役(RM)のレポート SPS を更新します。
アクタ：レポート管理役(RM)
役割： レポート生成役（RC）からの後処理 GP-SPS 更新情報を受け付けます4.38.3 参照する標準DICOM 2011 PS 3.4: 汎用予定検査段階 SOP クラス（General Purpose Scheduled Procedure Step SOP Class）
4.38.4 相互作用図
4.38.4.1 汎用予定検査段階進捗/中断通信文（General Purpose Scheduled Procedure Step in
Progress/Suspend Message）
4.38.4.1.1 きっかけ事例
後処理管理役では、使用者あるいはエビデンス書類（ED）生成役の自動機能が後処理予定検査段階を処理し始める、あるいは、完成しないまま終了します。
レポート管理役(RM)では、使用者が後処理予定検査段階をレポート生成役（RC）で処理し始める、あるいは、完成しないまま終了します。

4.38.4.1.2 通信文の意味
エビデンス生成役（EC）は、DICOM 汎用予定検査段階 SOP クラスの N-ACTION 要求を使用して後処理管理役にその SPS が開始されたこと、状態は IN PROGRESS であることを通知します。エビデンス生成役（EC）は SCU として、後処理管理役は SCP として、働きます。SPS の中止や再開も可能で、これに関連して、SUSPENDED, SCHEDULED 状態にされます（追加の情報については、DICOM 2011, 第 4 部、F.1.6
節を参照して下さい。）
レポート生成役（RC）とレポート管理役(RM)は同じ機構を用います。レポート生成役（RC）が SCU として、
レポート管理役(RM)が SCP として、働きます。
もし、人間が後処理予定検査段階を実行しているなら、N-ACTION 要求は実人間実施者一連（Actual
Human Performer Sequence）を含みます。

_______________________________________________________________________________________________________________________________________________

18
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
レポート予定検査段階の場合には、レポート生成役（RC）は実人間実施者一連（Actual Human Performer
Sequence）をレポート管理役(RM)に送り、使用者に使用権限があるか調べます。レポート管理役(RM)アプ
リケーションは正しい使用者情報が含まれていることを確認します。

4.38.4.1.3 予期される動作
後処理管理役は SPS の状態を IN PROGRESS にします。これは SPS がすでに作業を受けており、他の証
拠書類作成役はいかなる行動をこれについて起こしてはいけないことを示します。いかなるエビデンス生成
役（EC）も、現在のトランザクション UID なしの SPS 更新を拒否されます。
後処理管理役が SPS の状態を SUSPEND、または SCHEDULED にしたときは、SPS はエビデンス生成役（EC）の制御を抜けます。

同様に、レポート管理役(RM)は SPS の状態を IN PROGRESS にします。これは SPS がすでに作業を受けており、他のレポート作成役はいかなる行動をこれについて起こしてはいけないことを示します。いかなるレ
ポート生成役（RC）も、現在のトランザクション UID なしの SPS 更新は拒否されます。
レポート管理役(RM)が SPS の状態を SUSPEND、または SCHEDULED にしたときは、SPS はレポート生
成役（RC）の制御を抜けます。

4.39 作業項目検査段階進行中（Workitem Performed Procedure Step in Progress）

この節は IHE テクニカルフレームワークの RAD-39 トランザクションに該当します。RAD-39 トランザクション
は後処理管理役とエビデンス生成役（EC）、および、レポート管理役(RM)とレポート生成役（RC）に使用されます。
4.39.1 範囲
取得請求された後処理予定検査段階（Scheduled Post-processing procedure step）に作業を加え始めると、エビデンス生成役（EC）は後処理管理役に、実行済検査段階（PPS）を生成するよう、通信文を送ります。
取得請求されたレポート予定検査段階に作業を加え始めると、レポート生成役（RC）はレポート管理役(RM)に、実行済検査段階（PPS）を生するよう、通信文を送ります。
4.39.2 使用例役割
アクタ： エビデンス生成役（EC）
役割： エビデンス生成役（EC）が作業をはじめたとき、後処理 PPS を生成して後処理管理役を更新します。
アクタ：レポート管理役(RM)
役割： レポート生成役（RC）から PPS 情報を受け取ります。
アクタ： レポート生成役（RC）
役割： レポート生成役（RC）が作業をはじめたとき、レポート作業項目 PPS を生成してレポート管理役(RM)を更新します。

_______________________________________________________________________________________________________________________________________________

19
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
アクタ：後処理管理役
役割：エビデンス生成役（EC）から後処理 PPS 情報を受け取ります。
4.39.3 参照する標準DICOM 2011 PS 3.4: 汎用実行済検査段階 SOP クラス（General Purpose Performed Procedure Step SOP Class）
4.39.4 相互作用図
4.39.4.1 汎用検査段階進行中通信文
4.39.4.1.1 きっかけ事例
後処理作業項目では、使用者あるいはエビデンス書類（ED）生成役の自動機能が、後処理実行済検査段
階を処理し始めます。
レポート作業項目では、使用者が後処理予定検査段階をレポート生成役（RC）で処理し始めます。
4.39.4.1.2 通信文意味
エビデンス生成役（EC）は、SCU として、DICOM 汎用実行済検査段階 SOP クラスの N-CREATE 要求を使用して、SCP としての後処理管理役にその PPS が開始されたこと、状態は IN PROGRESS であることを通知します。
4.39.4.1.3 予期される動作
後処理管理役あるいはレポート管理役(RM)は PPS を生成し、IN PROGRESS 状態にします。
参照汎用予定検査段階一連（Referenced General Purpose Scheduled Procedure Step Sequence（0040,4016））が N-CREATE 要求に含まれるなら、後処理管理役あるいはレポート管理役(RM)は、特定された汎用予定検査段階 SOP インスタンス[General Purpose Scheduled Procedure Step SOP Instance]の属性
生成汎用実行済検査段階一連[Attribute Resulting General Purpose Performed Procedure Step Sequence]（0040,4015）を更新しなければなりません。
後処理管理役は、業務実行状況更新トランザクションを使用して、受信した GP-PPS について、関心のある受信役に知らせることができます。
レポート管理役(RM)は、業務実行状況更新トランザクションを使用して、受信した GP-PPS について、関心のある受信役に知らせることができます。
4.39.4.1.3.1 予定検査段階（SPS）と実行済検査段階（PPS）との関係
予定と実行済の検査段階情報の関係は、以下の場合で 個々の場合の属性形成の詳細は、付録Ｃを参照してください。
4.39.1.3.1.1

単純例

この場合は、SPS と PPS が一対一の関係にあります。予定検査段階と要望検査の情報は、予定検査段階
オブジェクトから、実行済検査段階関係モジュールへコピーされます。
4.39.1.3.1.2 未予定の例
この場合は、SPS と PPS がゼロ対一の関係にあります。予定検査段階と要望検査の情報はエビデンス生_______________________________________________________________________________________________________________________________________________

20
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
成役（EC）には使用不能で、おそらく、レポート生成役（RC）にも使用不能です。理由はそれぞれ異なっています。例えば、汎用業務一覧 SCP が利用できない、レポート作成中には後処理が予定されていない、です。
4.39.1.3.1.3 追加の例
この場合は、SPS と PPS が一対多の関係にあり、最初に PPS が SPS に対応して生成されます。他の実行
済検査段階は、後に、順次追加されます。全ての実行済検査段階は、同じ要望検査と元の SPS を振り返って参照しなければなりません。全ての要望検査属性と予定検査段階属性は、予定検査段階オブジェ
クトから、実行済検査段階関係モジュール（Performed Procedure Step Relationship Module）と、生成された複合インスタンスの要望属性一連（Request Attribute Sequence）とへ、コピーされねばなりません。SPS 状態
が COMPLETED, DISCONTINUED の時には、PPS は追加できません。
4.39.1.3.1.4 廃棄例
この場合は、PPS が関連するエビデンス書類（ED）や画像、その他のデータオブジェクトを持っていても、持っていなくても、SPS と PPS が一対一の関係にあります。検査段階は完遂の前に、臨床的理由で廃棄されねばならないことがあります。SOP Instance がエビデンス生成役（EC）から画像保管庫（IA）に、あるいは、
レポート生成役（RC）からレポート管理役(RM)に、送信された場合には、PPS N-SET で特定されねばなりません。これは、この情報を後処理管理役に明示的にトランザクションするための、手段です。すべての要望検査と予定検査段階属性は、予定検査段階オブジェクトから実行済検査段階関係モジュールへ、コ
ピーされねばなりません。

4.40 作業項目検査段階完了（Workitem Performed Procedure Step Completed）
この節は IHE テクニカルフレームワークの RAD-40 トランザクションに該当します。RAD-40 トランザクション
は後処理管理役とエビデンス生成役、および、レポート管理役とレポート生成役に使用されます。
4.40.1 範囲
後処理実行済検査段階（post-processing performed procedure step）の完了や中止の後に、エビデン
ス生成役は、PPS 状態を COMPLETED あるいは DISCONTINUED 状態に更新するため、後処理管理役に通信文を送り、生成されて画像管理役・画像保管庫（IM/IA）に送信された結果を参照します。
報告書作成役は、同様に振舞い、レポート管理役を PPS 状態で更新し、生成されてレポート管理役に送信された結果への参照も更新します。例えば DICOM 構造化報告書オブジェクト、または IHE の範囲外のオブジェクトの外部 ID です。
4.40.2 使用例役割
アクタ: エビデンス生成役（Evidence Creator）
役割: エビデンス生成役が業務を完了した、あるいは、中止したとき、後処理管理役を後処理 PPS 状態で更新します。
アクタ: 後処理管理役（Post-Processing Manager）
役割: 後処理の PPS 情報をエビデンス生成役から受け取ります。
アクタ: 報告書作成役（Report Creator）
役割: 作業が完了あるいは中止したとき、レポート作業項目の状態でレポート管理役を更新します。
アクタ: レポート管理役（Report Manager）
役割: 報告書作成役から PPS 情報を受け取ります。
4.40.3 参照する標準_______________________________________________________________________________________________________________________________________________

21
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________DICOM 2011 PS 3.4 汎用実行済検査段階 SOP クラス（DICOM 2011 PS3.4: General Purpose Performed
Procedure Step SOP Class）
4.40.4 相互作用図
4.40.4.1 汎用実行済検査段階通信文（General Purpose Performed Procedure StepMessage）
4.40.4.1.1 きっかけ事象
自動化されたエビデンス生成役、または、使用者は、後処理作業項目の後処理予定済検査段階（PPS）を完了します。
利用者は、レポート作業項目についての、予定処理段階の作業を完了します。
4.40.4.1.2 通信文意味SCU としてのエビデンス生成役は、DICOM General Purpose Performed Procedure Step SOP Class の NSET 要求を使用して、特定の PPS が完了しその状態が COMPLETED になったことを、SCP としての後処理管理役に知らせます。エビデンス生成役は N-SET を使用して、PPS 情報の中間更新を行うこともあります。最終的な N-SET には COMPLETED か DISCONTINUED のどちらかの状態があります。 レポート管理役は SCU と同じ様に、SCP としてのレポート管理役と協働します。レポート管理役は、実行済業務項目
更新により、あるいは、DSS と一体化することにより、PPS 状態について DSS に通知します。
状態が COMPLETED か DISCONTINUED に設定されるとき、エビデンス生成役は出力情報シーケンス(0040、4033)内に生成されたすべての Composite SOP インスタンスの一覧を、後処理管理役に送らねばなりません。同様に、報告書作成役は出力情報シーケンス(0040、4033)内にすべての SOP インスタンスの一覧を送信するか、非 DICOM 出力情報シーケンス(0040、4032)内で非 DICOM 出力を識別するか、しな
くてはなりません。
4.40.4.1.3 報告書通信文意味
作業項目が完成した後に、報告書作成役は、実行された報告書作成作業の詳細をレポート管理役に提供せねばなりません。 この情報は General Purpose Procedure Step N-SET メッセージの実行済作業項目コー
ドシーケンス（Performed Work Item Code Sequence）に含められねばなりません。 報告書作成役は報告書作成中に生成された結果を参照しなければなりません。 出力情報は GPPPS 結果モジュール（General
Purpose Performed Procedure Step Results Module）の一部です。出力データは適切なデータ保管庫に保存しされねばなりません。 どのデータ保管庫に保存するかは、出力データのタイプ、すなわち、報告、音声、
エビデンスドキュメントまたは他のオブジェクト、に依存します。
また、報告書作成役はレポート管理役に後続作業項目を提案することもあります。 要求された後続作業項
目は GPPPS 結果モジュール（General Purpose Performed Procedure Step Rssults Module）に含まれています。
4.40.4.1.4 予期される動作
後処理管理役、あるいは、レポート管理役が PPS の状態を COMPLETED か DISCONTINUED に更新します。
_______________________________________________________________________________________________________________________________________________

22
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.41 作業項目完了済（Workitem Completed）
この節は IHE テクニカルフレームワークの RAD-41 トランザクションに該当します。RAD-41 トランザクション
は後処理管理役とエビデンス生成役、および、レポート管理役とレポート生成役に使用されます。
4.41.1 範囲
後処理予定手続段階（poat-processing scheduled proceude stpe）を完了、または中止した後に、エビデンス
生成役は、SPS 状態を COMPLETED、あるいは、DISCONTINUED に更新するために、後処理管理役に通信文を送信します。 これで、後処理管理役は作業項目一覧を更新することができます。
レポート予定手続段階（reporting scheduled procedure step）を完了、または中止した後に、レポート生成役
は、完了か中止への SPS 状態を更新するためにレポート管理役に通信します。 これで、レポート管理役は作業項目一覧を更新することができます。
4.41.2 使用例役割
アクタ: エビデンス生成役（Evidence Creator）
役割: エビデンス生成役が作業を完了したとき、後処理管理役を後処理 SPS の状態で更新します。
アクタ: 後処理管理役（Post-Processing Manager）
役割: 後処理の GP-PPS 情報をエビデンス生成役から受け取る。
アクタ: 報告書作成役（Report Creator）
役割: レポート管理役が作業を終了した時、レポート作業項目 SPS の状態でレポート管理役を更新します。
アクタ: レポート管理役（Report Manager）
役割: 報告書作成役から GP-SPS 情報を受け取ります。
4.41.3 参照する標準DICOM2011PS3.4: General Purpose Scheduled Procedure Step SOP Class
4.41.4 相互作用図
4.41.4.1 汎用 SPS 完了済み通信文（General Purpose SPS Completed Message）
4.41.4.1.1 きっかけ事象
エビデンス生成役の利用者または自動処理機能は、後処理作業項目について、後処理予定処理段階（post-processing scheduled procedure step）を終了します。
報告書作業項目は利用者が報告書生成の予約済み手続段階で作業を終了する。
4.41.4.1.2 通信文意味SCU としてエビデンス生成役は、特定の予定済検査段階が終了して、その状態が COMPLETED になったことを、DICOM General Purpose Scheduled Procedure Step SOP クラスの N-ACTION 要求を使用して、SCP としての後処理管理役へ通知します。このメッセージは、SPS が完了し、この SPS には更なる PPS は作成されないことを、後処理管理役に通知します。エビデンス生成役は DISCONTINUE 状態で SPS を中_______________________________________________________________________________________________________________________________________________

23
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
止することがあります。
同様に、報告書作成役は、DICOM General Purpose Scheduled Procedure Step SOP クラスの N-ACTION
要求を使用して、特定に予定検査段階が完了し、その状態が COMPLETED であることを、SCP としてのレポート管理役に通知します。
この通信文は、作業項目の SPS が完了しこの SPS にはさらなる PPS は作成されないことを、レポート管理役に知らせます。 また、報告書作成役は SPS を、DISOCNTINUED 状態で中止することがあります。
4.41.4.1.3 予期される動作
後処理管理役、またはレポート管理役は、SPS の状態を、COMPLETED あるいは、DISCONTINUED 状態に更新しますが。
さらに、後処理管理役、またはレポート管理役が、実行済作業状態更新（Performed Work Status Update）ト
ランザクションを使用して、部門システム予定役(DSS)と画像管理役（IA）に知らせます。

4.42 の実行済作業状態更新（Performed Work Status Update）
この節は IHE テクニカルフレームワークの RAD-42 トランザクションに該当します。RAD-42 トランザクション
は部門システム予定役（DSS）とレポート管理役（RM）、および画像管理役（IM）に使用されます。
4.42.1 範囲
このトランザクションは、管理中の実行済作業の状態を他に知らせるために、部門システム予定役（DSS）、
レポート管理役（RM）または画像管理役（IM）によって利用されます。 このトランザクションによって実行された作業を管理しないシステムでも状態との同期を保てます。
非管理システムが情報をどのように使用するか、あるいは、使用するか否かは、実装者や利用者の裁量によります。以下に例を示します。

ショ・部門システム予約役（DSS）は、後処理管理役（PM）と一体化され、すべての後処理を管理します。
このトランザクションにより、部門システム予定役（DSS）は、行われた処理作業に関して画像管理役（IM）に、通知できる様になります。たとえば、CAD が一組の画像に対して実行され、エビデンス書類が保存されます。
・画像管理役（IM）は、後処理管理役（PM）と一体化され、一部の後処理業務を管理します。この
トランザクションにより、画像管理役（IM）は、行われた後処理作業に関して部門システム予定役（DSS）に、通知できる様になります。
・レポート管理役は、独立したシステムとして実装され、報告書業務を管理します。このトランザク
ンにより、レポート管理役（RM）が、部門システム予定役（DSS）と画像管理役（IM）に、レポートが完成したことを通知できる様になります。

4.42.2 使用例役割
アクタ: 部門システム予定役（Department System Scheduler, DSS）
役割: 業務を管理する場合（すなわち、後処理管理役と一体化されている）は、画像管理役（IM）とレポート管理役（RM）に業務状態通知を送る必要があります。画像管理役（IM）またはレポート管理役（RM）に管理された業務の状態を監視する場合、部門システム予定役（DSS）業務状態の通知を受信する準備ができ_______________________________________________________________________________________________________________________________________________

24
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________ている必要があります。
アクタ: 画像管理役（Image Manager）
役割: 業務を管理する場合（すなわち、後処理管理役と一体化されている）は、部門システム予定役（DSS）とレポート管理役（RM）に業務状態通知を送る必要があります。部門システム予定役（DSS）または
レポート管理役（RM）に管理された業務の状態を監視する場合、画像管理役（IM）は業務状態通知を受信する準備ができている必要があります。
アクタ: レポート管理役（Report manager）
役割: 業務を管理する場合（すなわち、レポート業務一覧（Reprorting Worklist）、作業項目取得要求済（Workitem Claimed）、作業項目完成済（Workitem Completed）、作業項目実行済検査段階進行中（Workitem Performed Procedure Step In Progress）、作業項目実行済検査段階完了（Workitem Performed
Procedure Step Completed）を実装している）は、部門システム予定役（DSS）と画像管理役（IM）に業務状態通知を送る必要があります。部門システム予定役（DSS）または画像管理役（IM）に管理された業務の状態を監視する場合、レポート管理役（RM）は業務状態通知を受信する準備ができている必要があります。
4.42.3 参照する標準DICOM 2011 PS 3.4: General Purpose Performed Procedure Step SOP Class
4.42.4 相互作用図
4.42.4.1 後処理実行済処理段階生成/更新通信文（Post-Processing Performed Procedure Step

Created/Updated Message）
4.42.4.1.1 きっかけ事象
シナリオ A では部門システム予定役（DSS）は後処理管理役と一体化され、管理する業務状態の生成や更新を受けます。シナリオ B では、画像管理役（IM）が後処理管理役と一体化されているため、画像管理役（IM）は、管理する業務状態の生成や更新を、たとえば、エビデンス生成役から、受けます。シナリオ C では、レポート管理役（RM）は、管理する業務状態の生成や更新をレポート生成役（RM）から受けます。どのシナリオでも、例えば、後処理管理役かレポート管理役によって受け取られた GP-PPS 完了通信文は、送信する作業状況更新（Work Status Update）通信文のきっかけとなるものです。
4.42.4.1.2 通信文意味論
シナリオ A では、部門システム予定役は DICOM General Purpose Performed Procedure Step SOP の NCREATE と N-SET を使って、作業の開始や終了を画像管理役（DSS）とレポート管理役（RM）に知らせます。画像管理役（DSS）は SCU の役を演じ、画像管理役（IM）とレポート管理役（RM）は SCP の役を演じます。
シナリオ B では、画像管理役（IM）は DICOM General Purpose Performed Procedure Step SOP の NCREATE と N-SET を使って、作業の開始や終了を部門システム予定役（DSS）とレポート管理役（RM）に知らせます。画像管理役（RM）は SCU の役割を演じ、部門システム予定役（DSS）とレポート管理役（RM）
は SCP の役割を演じます。
シナリオ C では、レポート管理役は DICOM General Purpose Performed Procedure Step SOP の NCREATE と N-SET を使って、作業の開始や終了を部門システム予定役（DSS）と画像管理役（IM）に知らせます。レポート管理役（RM）は SCU の役割を演じ、部門システム予定役（DSS）と画像管理役（RM）は_______________________________________________________________________________________________________________________________________________

25
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________SCP の役割を演じます。
「実行された作業」は SCU によって管理される、ひとつまたはそれ以上の関連のあるサブ作業項目から成るかもしれません。SCU は、サブ作業項目のそれぞれについて状態情報を受け取ると、転じて SCU を更新します。サブ作業項目の取得要求の後で、かつ、その補足作業項目についての最初の作業項目実行済検査段階進行中（workitem performred procedure step in progress）トランザクションが実行されるより前に、
GP-PPS 状態を IN PROGRESS にして N-CREATE を送信します。N-CREATE では、SCU は、サブ作業項
目を通信するのに Performed Workitem Code Sequence (0040、4019)を使用します。SCU は、中間のアップ
デートを送信する場合に N-SET を使用することもあります。サブ作業項目 GP-SPS の完了後に、GP-PPS
状態を COMPLETED にして、最終的な N-SET を送ります。 SCU で管理されたサブ作業項目が更にある
場合は、N-SET は Performed Workitem Code Sequence を含み、更新される次の作業項目を示します。
SCU が、管理するすべてのサブ作業項目の更新を終了すると、この属性は「次の作業項目なし」作業項目とともに送信され、実行済作業セットが終了したことを明らかにします。これは、別のワークフローマネージャ
が次の作業セットの管理を引き継ぐことを意味します。
後処理管理役とレポート管理役（RM）は、実行済業務状態（Performed Worrk Status）で使用する、無予定（unscheduled）GP-PPS を生成せねばなりません。：エビデンス生成役（EC）か報告書作成役（RC）から受け取った GP－PPS を単に再送することはできません。実行済作業項目コードシーケンス（Performed
WorkItem Code Sequence）に値を入れるには、DCMR Context ID 9231 からの適切なコードを使用せねばなりません（表 4.42-1 参照）。
表 4.42-1: 状況 ID 9231 – 汎用作業項目定義
Context ID 9231 – General Purpose Workitem Definition
4.42.4.1.3 予期される動作部門システム予定役、または画像管理役は、その責任に適する様に、情報を記録し、使用します。

4.43 エビデンス書類保存完了（Evidence Document Stored）
この節は、IHE テクニカルフレームワークの RAD-43 トランザクションに相当します。RAD-43 は、撮影装置とエビデンス生成役（EC）に使用されます。
4.43.1 範囲
エビデンス書類（ED）保存完了トランザクションでは、撮影装置またはエビデンス生成役（EC）はエビデンス
書類（ED）を送信し、エビデンス書類（ED）は画像保管庫（IA）に保存されます。
エビデンス書類は、画像取得、画像処理、あるいはコンピュータ支援検出の様な、実行中検査段階の結果として生じる DICOM 複合オブジェクトです。
これらオブジェクトは、読影診断の根拠として役立つ様に意図されていますが、これは画像ではく、DICOM
構造化レポート書類です。エビデンス書類（ED）は解釈されていない情報で、おもに画像部門で管理され内部で使用されますが、画像部門外への配布が禁止されているわけではありません。このオブジェクトはレ
ポート管理役(RM)で管理されます。と想定されていません。乳房撮影のコンピュータコンピュータ支援検出のように、SOP クラスの SOP インスタンスとしてコード化されたオブジェクトは、エビデンス書類（ED）の例です。

_______________________________________________________________________________________________________________________________________________

26
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.43.2 使用例役割
アクタ： 撮影装置
役割： 画像でないエビデンス情報をエビデンス書類（ED）に記録し、画像保管庫（IA）に保存します。
アクタ： エビデンス生成役（EC）
役割：画像でないエビデンス情報をエビデンス書類（ED）に記録し、画像保管庫（IA）に保存します。
アクタ： 画像保管庫（IA）
役割： 撮影装置やエビデンス生成役（EC）から受診したエビデンス書類（ED）インスタンスを受付、保存します。
4.43.3 参照する標準DICOM 2011 PS 3.4: 保存サービスクラス（Storage Service Class）; 基本テキストSR SOPクラス （Basic
Text SR SOP Class）; 強化SR SOPクラス（ Enhanced SR SOP Class）; 総合SR SOPクラス（Comprehensive
SR SOP Class）; 胸部CAD SR SOPクラス（ Chest CAD SR SOP Class）; 乳房撮影CAD SR SOPクラス（ Mammography CAD SR SOP Class）; 産婦人科超音波検査レポート（OB-GYN Ultrasound Procedure
Reports）; 心臓カテーテル検査室SR（Catheterization Lab SR）; 血管超音波SR（Vascular Ultrasound SR）
この一覧は、実例の基本的一覧の提供を意図しています。DICOMは今後もエビデンス書類（ED）に適した追加のSR SOPクラスと雛形を刊行すると予測されます。
4.43.4 相互作用図
4.43.4.1 エビデンス書類（ED）保存完了
このトランザクションは、撮影装置またはエビデンス生成役（EC）と画像保管庫（IA）との間の”DICOM CSTORE”事例を関連させます。
4.43.4.1.1 きっかけ事例
撮影装置あるいはエビデンス生成役（EC）が、保存の必要があるエビデンス書類（ED）を生成します。
4.43.4.1.2 通信文の意味
撮影装置あるいはエビデンス生成役（EC）は、DICOM C-STORE通信文を使用して、エビデンス書類（ED）
を（SRオブジェクトとして）画像保管庫（IA）に保存のため転送します。撮影装置あるいはエビデンス生成役（EC）はDICOM保存SCUで、画像保管庫（IA）はDICOM保存SCPです。
ある種の情報は、エビデンス書類（ED）のヘッダーに記録されねばなりません。この様な情報のDICOM
SOPインスタンスへの割り付けは付録 C、表 C.1-1 に規定されています。
4.43.4.1.3 予期される動作

DICOM規格（2011）は、エビデンス書類（ED）の生成に使用されうるいくつかの非画像保存SOPクラスを規定しています。画像保存役は複数の保存SOPクラスを、下記の表 4.43-1 に規定するように使用可能にするとされています。
表 4.43-1: 示唆されるエビデンス書類（ED）SOPクラス_______________________________________________________________________________________________________________________________________________

27
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
表 4.43-2 に示すように、エビデンス書類（ED）に使用すると規定された一個以上の雛形を画像保管庫（IA）
で使用可能にするとされています。
表 4.43-2: 示唆されるエビデンス書類（ED）雛形
画像保管庫（IA）は保存レベル２が使用可能、すなわち全てのタイプ３属性が使用可能でなければなりません。

1.2.1.1.1.14.43.4.1.3.1 乳房撮影画像プロファイル（Mammography Image Profile）
乳房撮影画像プロファイルを使用可能とする、エビデンス生成役（EC）と画像管理役・画像保管(IM/IA)は、Mammography CAD SR SOP Class を使用可能とせねばなりません。特に、乳房撮影シ
ステムの解析を行うCADシステム（エビデンス生成役（EC）として動作する）は、Mammography
CAD SR SOP Classのインスタンスの形で結果を返せねばなりません。これは、表示条件の生成、および・または、キャプチャ画像、あるいは、乳房撮影画像を追加で生成することを妨げません。
画像管理役・画像保管庫（IM/IA）は、エビデンス生成役（EC）からMammography CAD SR SOPClass オブジェクトを受け取るのみならず、問合せ（後の取得に備えて全体がまるごと実際に保存され、単に処理され画像に動的に埋め込まれているのでない状態）に答えて、返信されねばなりません。エビデンス書類（ED）取得トランザクション（Retrieve Evidence Tranaction）4.45.4.2.3.1
節を参照してください。

4.44 エビデンス書類（ED）問合せ
この節は、IHE テクニカルフレームワークのトランザクション RAD-44 に該当します。トランザクション RAD44 は、画像保管庫（IA）と画像表示役（ID）に使用されます。
4.44.1 範囲
この節は、画像表示役（ID）が、エビデンス書類（ED）のインスタンスを画像保管庫（IA）に問い合わせる際に必要な、一連のトランザクションを記載します。
4.44.2 使用例役割
アクタ： 画像表示役（ID）
役割：エビデンス書類（ED）オブジェクトを問い合わせます（通常、取得を目的に行われます）。
アクタ：画像保管庫（IA）
役割： 画像表示役（ID）からのエビデンス書類（ED）オブジェクトの問い合わせに対応します。
4.44.3 参照する標準DICOM 2011 PS 3.4: 問合せ/取得サービスクラス Query/Retrieve Service Class
4.44.4 相互作用図
4.44.4.1 エビデンス書類（ED）問合せ

問い合わせ SOP Classes (Study Root – FIND と、オプションの Patient Root – FIND) が使用可能でなければなりません。詳細な記述的意味は、DICOM 2011 PS 3.4: 問合せ取得サービスクラスを参照してください。
_______________________________________________________________________________________________________________________________________________

28
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.44.4.1.1 きっかけ事例
画像表示役（ID）は、エビデンス書類（ED）についての情報を得る必要があります。
4.44.4.1.2 通信文の意味
通信文の意味は、DICOM 問合せ/取得 SOP クラス（Query/Retrieve SOP Class）に定義されています。

DICOM Study Root Query/Retrieve Information Model- FIND SOP Class または、DICOM Study
Root Query/Retrieve Information Model- FIND SOP Class からの C-FIND 要求は、画像表示役（ID）から画像保管庫（IA）へ送られねばなりません。
画像表示役（ID）は画像保管庫（IA）に、選択したレベル（患者、検査/シリーズ/インスタンス）で、一個以上の照合キーを条件として検索し、条件に一致するオブジェクトの一覧を得ます。
DICOM 規格で定められた必須で一意のキーに加え、問合せ SCU と SCP が使用可能とする照合キーと返答キーを IHE テクニカルフレームワークで定義しています。このキーは、RAD TF-2:4.14.4.1.2 節と表
4.14-1 に定義されています。キー使用法の凡例は RAD TF-2:2.2 節に定義されています。画像表示役（ID）（SCU）と画像保管庫（IA）（SCP）には、追加のエビデンス書類（ED）インスタンス特異キーが表 4.44-1の様に定義されています。
表 4.44-1 エビデンス書類（ED）インスタンス特異問合せ照合キーと返答キー
4.44.1.3 予期される動作
画像保管庫（IA）は C-FIND 要求を受付、与えられたキーへの一致を探し、C-FIND 応答を介して、画像表示役（ID）に一致する記録の一覧を送り返します。
画像表示役（ID）は、使用可能なエビデンス書類（ED）の取得のため、選択用の雛形 ID（Template ID）を使用するものとされます。
4.44.4.1.3.1 乳房撮影画像プロファイル
乳房撮影画像プロファイルが使用可能な、画像表示役（ID）と画像管理役・画像保管庫（IM/IA）は、
Mammography CAD SR SOP Class を使用可能とせねばなりません。

4.45 エビデンス書類（ED）の取得（Query Evidence Documents）
この節は、IHE テクニカルフレームワークのトランザクション RAD-45 に該当します。トランザクション RAD45 は、画像保管庫（IA）、画像表示役（ID）、画像書類ソース、画像書類利用役、に使用されます。
4.45.1 範囲
エビデンス書類（ED）取得トランザクションでは、DICOM エビデンス書類（ED）が、画像保管庫（IA）から画像表示役（ID）へ、あるいは、画像書類ソースから画像書類利用役へ転送されます。
4.44.2 使用例役割
アクタ： 画像保管庫（IA）
役割： 要求されたエビデンス書類（ED）を画像表示役（ID）に送ります。
アクタ： 画像書類ソース（Imaging Document Source）_______________________________________________________________________________________________________________________________________________

29
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
役割： 要求されたエビデンス書類（ED）を画像書類利用役（Imaging Document Consumer）に送ります。
アクタ： 画像表示役（ID）
役割： 要求したエビデンス書類（ED）を画像保管庫（IA）から受け取ります。
アクタ： 画像書類利用役
役割： 要求したエビデンス書類（ED）を画像書類ソースから受け取ります。
4.44.3 参照する標準DICOM 2011 PS 3.4: 問合せ/取得サービスクラス Query/Retrieve Service Class、保存 SOP クラス
Storage SOP Class
4.45.4 相互作用図
4.45.4.1 エビデンス書類（ED）取得
取得 SOP Classes（Study Root – MOVE とオプションの Patient Root – MOVE）が使用可能でなければなりません。SCU としての画像保管庫（IA）は、エビデンス書類（ED）として使用される DICOM Storage Classesが使用可能でなければなりません。SCU としての画像書類ソースは、それが共有用に生成するエビデンス
書類（ED）に使用される DICOM Storage SOP Classes が使用可能でなければなりません。詳細は DICOM
2011 PS 3.4, Annex C を参照してください（表 4.38-1 を見てください）。
施設間でエビデンス書類（ED）を取得する場合に、画像書類ソースと画像書類利用役間の書類交換のためには、画像書類共有ネットワーク（XDS-I.b）環境と、AE タイトルを DICOM AE ネットワークアドレス（IP ア
ドレスとポート番号）に対応付ける設定とが、必要です。
4.45.4.1.1 きっかけ事例
画像表示役（ID）と画像書類利用役が、画像保管庫（IA）または、画像書類ソースから特定のエビデンス書
類（ED）を選択します。
4.45.4.1.2 通信文の意味
通信文の意味は、DICOM 211 PS 3.4: Query/Retrieve Service Class の DICOM Query/Retrieve Service
Class 節に定義されています。画像保管庫（IA）や画像書類ソースから取得した時点で、エビデンス書類（ED）オブジェクト内の患者および検査情報が最新であることを保証するのは、画像保管庫（IA）や画像書
類ソースの責任です。
4.45.4.1.3 予期される動作
画像保管庫（IA）や画像書類ソースは C-MOVE 要求を受け付け、画像表示役（ID）あるいは画像書類ソースと連携を樹立し、DICOM C-STORE 命令により、要求されたエビデンス書類（ED）を転送します。
画像表示役（ID）や画像書類利用役は問合せに含まれる雛形 ID に基づいて合致する書類を選択できる
ので、画像表示役（ID）や画像書類利用役は、画像保管庫（IA）や画像書類ソースに、取得した書類の内容について、エラーを返さないよう要求されており、むしろ取得結果は単に捨てられます。
4.45.4.2 エビデンス書類（ED）の見読化
このトランザクションは、上図の「エビデンス書類（ED）見読化」事例に関係しています。
45.4.2.1 きっかけ事象_______________________________________________________________________________________________________________________________________________

30
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
画像表示役（ID）、あるいは、画像書類利用役は、画像保管庫（IA）、あるいは、画像書類ソースからエビデンス書類インスタンスを受け取ります。
4.45.4.2.2 発動の意味
これは、画像表示役（ID）や画像書類利用役に内在する機能の現場施設での発動です。画像表示役（ID）
や画像書類利用役の使用者にむけてエビデンス書類（ED）は表示されねばなりません。画像表示役（ID）
や画像書類利用役が、エビデンス書類（ED）を使用者に提示する方法は IHE テクニカルフレームワークの範囲外です。たとえば、画像表示役（ID）や画像書類利用役がエビデンス生成役（EC）と一括化されている場合には、エビデンス書類（ED）はエビデンス生成役（EC）によるさらなる処理への入力とされます。
4.45.4.2.3 予期される動作
画像表示役（ID）や画像書類利用役は取得したエビデンス書類（ED）を見読化します。画像表示役（ID）や画像書類利用役が書類の一部を扱えないときには、これを使用者に知らせ、低品質見読化するかどうかの選択を与えます。
エビデンス書類（ED）は他の種類のエビデンスオブジェクトへの参照を含むことがあります。画像表示役（ID）や画像書類利用役は、参照されたエビデンス書類（ED）を見読化（あるいは低品質見読化）するか、他の見読化機能を発動するかしなければなりません。
もし画像表示役（ID）が画像表示一貫性プロファイルも可能とするときは、エビデンス書類（ED）に参照された表示条件を関連する画像に適応できねばなりません。
もし画像表示役（ID）がキー画像注釈プロファイルを可能とするときは、エビデンス書類（ED）に参照された
キー画像注釈を見読化できねばなりません。
注：エビデンス書類（ED）の、取得したばかりのインスタンスを使用して、画像管理役・画像保管庫（IM/IA）での患者交信や融合を反映した最新の患者情報が表示されるよう、推奨されています。この患者情報は、以前に取得したエビデンス書類（ED）のコピ―とは一致しないことがあります。

4.45.4.2.3.1 乳房撮影画像プロファイル
乳房撮影画像プロファイルが使用可能な、画像表示役（ID）と画像管理役・画像保管庫（IM/IA）はMammography CAD SR SOP Class を使用可能とせねばなりません。
画像表示役（ID）は、表示した画像に Mammography CAD SR を適応できねばなりません： RAD TF-2:
4.16.4.2.2.1.1 節 CAD マークの表示を参照してください。必須の表示のための見読化の意図を持つデーの無視は許されていません：Mammography CAD SR には、低品質見読化の様なものはありません。

4.46 レポート作業一覧問合せ （Query Reporitng Worklist）
4.46.1 範囲
このトランザクションは、画像管理役（IM）により予定あるいは割り付けられている業務を、レポート生成役（RC）が行うレポート業務のなかで、見いだすために使用されます。このトランザクションにより、レポートの読影・口述・口述筆記・確認業務を行うために、レポート管理役(RM)がレポートに関連した作業項目コード
を含む業務一覧をレポート生成役（RC）に提供できる様になります。

_______________________________________________________________________________________________________________________________________________

31
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
レポート管理役(RM)は業務一覧を供給します。レポート管理役(RM)は、患者や検査の種類についての必要な情報を、検査予約済トランザクションを介して、部門システム予定役から取得します。レポート管理役(RM)は、画像や他のエビデンスオブジェクトの有無について実行済検査段階管理役から撮影段階完了済
トランザクションを介して通知され、画像可用性問合わせを介して可用性を確認することもできます。
レポート生成役（RC）は、業務一覧を取得し、患者基本情報・スタディインスタンス UID などの様な、取得情報を、作成したインスタンス（付録 D 参照）に含ませ、エビデンス書類（ED）保存済、画像保存済などの、インスタンス保存のトランザクショを介して、保存します。
4.46.2 使用例役割
アクタ： レポート生成役（RC）
役割： レポート予定業務段階をレポート管理役(RM)に問い合わせます。
アクタ： レポート管理役(RM)
役割： 読影、口述、口述筆記、確認業務、のうち該当する作業項目のレポート業務段階を予定します；業
務一覧の問合せ要求を受け取り、返答を返します。
4.46.3 参照する標準DICOM 2011 PS 3.4; 汎用作業項目 SOP クラス General Purpose Worklist SOP Class

4.46.4 相互作用図
4.46.4.1 汎用業務一覧通信文
これは、レポート管理役(RM)へ送られる業務一覧問合せです。
4.46.4.1.1 きっかけ事例
レポート生成役（RC）の使用者、あるいは、自動化機能が、予定レポート業務一覧の項目を問い合わせます。
4.46.4.1.2 通信文の意味
DICOM 汎用業務一覧 SOP クラスの C-FIND 要求が、汎用業務一覧の問い合わせに使用されます。レ
ポート生成役（RC）が SCU、レポート管理役(RM)が SCP となります。
4.46.4.1.2.1 照合キーと返答キー
レポート生成役（RC）は、診断レポート作成の結果生成されるインスタンスに挿入する、特定の属性（返答キー）を問い合わせねばなりません。詳細は付録 D を参照してください。
レポート生成役（RC）は、「表 4.46-3 – レポート業務一覧の返答および照合キー」に掲載する必須キーのそれぞれを個別に使用可能とせねばなりません。加えて、以下の組み合わせの少なくとも一つをレポート
生成役（RC）は実装せねばなりません。

_______________________________________________________________________________________________________________________________________________

32
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
1. 患者指向問合せ: 特定の患者・検査の業務一覧の問い合わせです。SCU は表 4.46-1 に掲示された照合キー属性を一個以上含む全ての組み合わせ（31）を使用可能とせねばなりません。斜体で示された一連の属性はそれ自身では照合キーではありませんが、問いあわせに含まれる属性の値を伝えるために、これに含まねばなりません。したがって、SCU は、患者氏名、患者 ID、アクセッション番号、要求検査 ID、予定作業項目コードのあらゆる組み合わせを使用可能とせねばなりません。
表 4.46-1: 患者指向問合せ用の GPWL キー
2. 使用者指向問合せ：特定の端末を使用している特定の使用者の広範な業務一覧の問い合わせです。
SCU は表 4.46-2 に掲示された照合キー属性を一個以上含む全ての組み合わせ（63）を使用可能とせねばなりません。斜体で示された一連の属性はそれ自身では照合キーではありませんが、問いあわせに含まれる属性の値を伝えるために、これに含まねばなりません。予定ステーション名コード順列コード値にもし値を入れるなら、ワークステーションの汎用業務一覧 SCU の AE タイトルにしなければなりません。
表 4.46-1: 使用者指向問合せ用の GPWL キー
4.46.4.1.2.2 照合キー属性使用例
・ 予定検査段階開始日時キー： 当日に予定されたレポート業務の全てを問い合わせ・ 予定作業項目コードキー： 全ての口述筆記業務の問い合わせ・ 実行人氏名キー： 該当する放射線科医に予定された全てのレポート業務の問い合わせ
・
予定検査段階開始日時キー、予定作業項目コードキーと実行人氏名キー： 該当する放射線科医に、当日に予定された、全てのレポート確認業務
注： 構造化された患者氏名の各構成成分の最後にはワイルドカード（*）を添付して、非構造化および構造化患者
氏名による一致検索を容易にすることがアプリケーションに推奨されています。

4.46.4.1.2.3 照合キーと返答キー
レポート生成役（RC）は、特定の属性（返答キー）を問い合わせねばなりません。これらの多くは生成物に必須のものです。保存された属性への要求項目は付録 D に定義されている問い合わせに使用できますが、他では使用されない追加の属性もあります。
表 4.46-3 に照合キーに要求される事項をまとめ、オプションおよび必須の属性を掲示してあります。この属
性は、要求可能で、レポート生成役（RC）の使用者に使用可能となるように返答されねばなりません。この表で示された必須事項の詳細は、RAD TF-2: 2.2 節を参照してください。
表 4.46-3: レポート業務一覧用の一致および返答キー
4.46.4.1.3 予期される動作
レポート管理役(RM)は、問い合わせを実行して、レポート管理役(RM)に、一致する汎用業務一覧の項目を送ります。
4.46.4.2 汎用業務一覧受信通信文
これは、レポート生成役（RC）の問い合わせに対する返答として、レポート管理役(RM)が汎用業務一覧項
目を送る通信文です。
4.46.4.2.1 きっかけ事例_______________________________________________________________________________________________________________________________________________

33
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
レポート管理役(RM)が業務一覧の問い合わせを受けます。
4.36.4.2.2 通信文の意味
DICOM 汎用業務一覧 SOP クラス（DICOM General Purpose Worklist SOP）からの C-FIND 応答がこの通信文に使用されます。業務一覧から問い合わされた属性の一部は、業務流れの前段階で別途生成したもので、MPPS の様な他のトランザクションにより、レポート管理役(RM)が使用できるようになります。スタディ、シリーズのような入力情報を、作業項目予定処理段階で適切に使用できるか決めるのは、レポート管理役(RM)です。すなわち、撮影業務とそれから生じる MPPS と、SPS とは関係ありません。
後処理管理役は、DCMR CID 9231 からとられた以下の値を使用して、予定作業項目コード順列（Scheduled Workitem Code sequence (0040, 4018)）の内容で、実行すべき業務のタイプを特定せねばなりません。
表 4.46-4: レポート作業項目定義
4.46.4.2.3 予期される動作
レポート生成役（RC）は、使用者に向けて業務一覧を表示し、使用者が作業する項目を選択します。使用者が作業項目を選択してレポート生成を行うと、レポート生成役（RC）は、要求済作業項目（Workitem
Claimed）、作業項目完了済（Workitem Completed）トランザクションに定義された様に、業務進捗状況をレ
ポート管理役(RM) （訳者注；原文ではこの語は「レポート生成役（RC）」ですが自己参照になるので「レポート管理役」の誤りと思われます。）に通知します。

4.47 媒体上画像情報配布（Distribute Imaging Information on Media）
この節は、IHE テクニカルフレームワークのトランザクション RAD-47 に該当します。RAD-47 トランザクショ
ンは、可搬媒体生成役と媒体読み取りアクタ（可搬媒体読込み役、画像表示役、レポート閲覧役、表示および印刷製作役）に使用されます。
4.47.1 範囲
媒体上画像情報配布トランザクションでは、可搬媒体生成役は、情報を収納する情報交換用媒体により、媒体閲覧役に情報を送ります。
4.47.2 使用例役割
アクタ：可搬媒体生成役（Portable Media Creator）
役割：媒体内容物を寄せ集め、配布する媒体に保存します。
アクタ：可搬媒体取り込み役
役割：配布された媒体の DICOM 内容物を読んで、DICOMDIR ファイルと参照されたインスタンス（DICOM FSR）に保存された情報を利用し、媒体にあるデータを読み込みます。
アクタ：可搬媒体生成役（Image Display）
役割：配布された媒体の DICOM 内容物を読んで、DICOMDIR ファイル（DICOM FSR）に保存された情報を利用し、参照されたエビデンスオブジェクトを表示します。

_______________________________________________________________________________________________________________________________________________

34
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
アクタ：レポート閲覧役（Report Reader）
役割：配布された媒体の DICOM 内容物を読んで、DICOMDIR（DICOM FSR）に保存された情報を利用し、参照された診断レポートを閲覧します。
アクタ：印刷製作役（Print Composer）
役割：配布された媒体の DICOM 内容物を読んで、DICOMDIR（DICOM FSR）に保存された情報を利用し、印刷データ（画像）をプリントサーバへ送信します。
4.47.3 参照する標準DICOM 2011 PS 3.10: Media Storage and File Format for Data Interchange
DICOM 2011 PS 3.11: Media Storage Application Profiles
DICOM 2011 PS 3.12: Media Formats and Physical Media for Data Interchange
DICOM Supplement 80 (final text): DVD Media Application Profiles
XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition). A Reformulationof HTML 4 in XML 1.0. W3C Recommendation 26 January 2000, revised 1 August 2002.
http://www.w3.org/TR/xhtml1.
XHTML™ Basic. W3C Recommendation 19 December 2000. http://www.w3.org/TR/xhtm1370
basic.
4.47.4 相互作用図
4.47.4.1 媒体上画像情報配布
このトランザクションは、製作された媒体を可搬媒体生成役から媒体閲覧アクタへの物理的輸送による情報の交換からなります。
4.47.4.1.1 きっかけ事象
可搬媒体生成役の使用者は、交換用媒体の作成と輸送により情報を伝えたいと思います。可搬媒体生成
役は情報交換用媒体の内容を寄せ集め、媒体に保存します。
4.47.4.1.2 通信文の意味
このトランザクションの通信文の意味は、媒体内容物の仕様により記述されます。
可搬媒体生成役は、一体化している IHE のアクタが使用可能な全ての DICOM オブジェクトを含められねばなりません。IHE アクタのどれとも一体化していない場合は、DICOM 適合性宣言に挙げられた全ての
DICOM Storage オブジェクトを含められねばなりません。
4.47.4.1.2.1 媒体のファイルシステムとファイル名の制限
媒体の DICOM 内容は、DICOM 規格に合致せねばならないので、DICOM PS 3.10.3.11 と 3.12 んい指定
された要求事項の一部をここに繰り返します。
・ISO 96600 レベル１に厳格に適合・パケットライト不可
・DICOMDIR ファアイルに参照されたファイルとフォルダの名前は、大文字、数字、下線のみの８文字に制限され、拡張子は不可とくに、DICOM ファイル名を SOP Instance UID に基づいて DICOM ファイル名を付けるのは許されません。
_______________________________________________________________________________________________________________________________________________

35
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
これは、８文字をこえ、使用不可の終止府（.）を含むからです。拡張子の.dcm を付けるのは許されません。
ファアイル名に小文字を使ってはならず、ISO 9660 の Joliet あるいは Rockridge 拡張によりコード化された
小文字に同等なファイル名も使ってはなりません。
相互運用性に悪影響を及ぼす、実装のよく見られる誤解や誤りについは、付録 E を参照してください。
非 DICOM データは ISO 9660 レベル 1 への適合のみとされていますが、拡張子と文字種についての
DICOM の制限はありません。つまり、拡張子の使用は許されます。
47.4.1.2.2 内容の構成の概観
以下の図に内容の構成の原則を示します（例は付録 F にあります）。
図 4.47.4.1.2.2-1: 媒体内容の構成
媒体ファイルシステムに含まれる内容の記載：
4.47.4.1.2.22.1 DICOM 内容
DIOCMDIR ファイルは、ルートディレクトリ（訳者注：最上位階層）に置かねばならず、媒体に含まれる全ての DICOM インスタンスを参与せねばなりません。
DICOM インスタンスのファイルはルートディレクトリにも、IHE_PDI の下位のディレクトリにも置いてはならず、
かわりに、特に名前の定められていないルートの下位のディレクトリに置かねばなりません。他の DICOM
インスタンスファイルは媒体に有ってはなりません。
以下に記す REAME.TXT ファイルを、ウエッブ閲覧可能内容オプションが使用可能で無くても、含む様、推奨されていますが、必須ではありません。
4.47.4.1.2.2.2 ウエッブ閲覧可能内容オプション
ウエッブ閲覧可能内容オプションを実装する可搬媒体生成役は以下の要求事項を満たさねばなりません。
・INDEX.HTM ファイルはルートディレクトリにおき、交換用媒体の内容を正確に表さねばなりません。このファイルは、・情報を示す見出し（header）で以下を含む
・交換用媒体を作成した施設の識別情報
・オプションで交換用媒体を作成した施設からの。個人情報・保安に関する免責宣言
・IHE_PDI ディレクトリのウエッブ内容を利用する着手点へのリンク
・README.TXT ファイルへのリンク
・追加の、制限のつかないファイル（もしあれば）へのリンク 4.47.4.1.2.2.3 参照
・可搬媒体取込み役で読込めるデータ（すなわち、媒体上の全ての DICOM 内容）を列挙した目録
・媒体上に DICOM 秒ビューワが存在する場合は、ビューワの開始点へのリンク
注： INDEX.HTM ファイルは上記の様に定められた内容を、使用者に提示できねばなりません。これは、情報がINDEX/HTM ファイルに含まれねばならないことを意味しません。かわりに、INDEX.HTM ファイルは追加の XHTML フ
ァイルをからなる別の表示枠を開き、全体として上記の様に規定された情報を含みます。

_______________________________________________________________________________________________________________________________________________

36
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________・README.TXT はルートディレクトリに置かれ、以下を含まねばなりません。
・媒体を作成した施設の連絡先
・媒体を作成したアプリケーションについての情報
・アプリケーション製品の名称とソフトウェアの版・媒体を作成下アプリケーションの製造者の連絡先情報・交換用媒体の全他愛構成についての全般的情報。これは、交換用媒体のこのインスタンスに保存された内容に特異的とは意図されていません。特異情報は、もしあれば、
INDEX.HTML ファアイルに記載されねばなりません。
・媒体閲覧アプリケーションが、あれば、それについての以下の情報・使用可能な基本システム
・アプリケーションの名称とシフトウェアの版
・媒体閲覧アプリケーション製造者の連絡先情報
・アプリケーションの意図された用途についての免責宣言
・最低必要使用の一覧
・アプリケーションの使用についての追加情報
README.TXT ファイルは媒体の臨床的内容とは独立していることに注意してください（すなわち、一つの施設でいつも同じ README.TXT が使われます）。
意図されたとおりに表示することが可能なウエッブ閲覧ソフト（版番号を含む）についての情報を
README.TXT ファイルに含むよう、推奨されています。

・IHE_PDI ディレクトリは交換用媒体のルートディレクトリに置かれ、以下を含まねばなりません。
・DICOM コード化オブジェクトから導き出された、ウエッブ閲覧ソフトで使用可能な
XHTML, JPEZG, PNG および・または GIF 形式のオブジェクト、あるいは、ウエッブページ逍遙に使用されるオブジェクト
・ウエッブ内容は患者の臨床情報を忠実に提示できねばなりません。
・IHE_PDI ディレクトリにそのほかの情報を置くことは許されていません。
・IHE_PDI ディレクトリの下にディレクトリをおくことは許されています。
これらは IHE の要求事項（DICOM 要求事項でありません）、媒体の全体の構成を容易にして INDEX.HTM ファイルの利用が、特に非専門の使用者である患者と紹介医に、容易とするためです。
注： シネやビデオデータへの要望があることが認識されていますが、しかし、IHE が是認する標準の方法（フォーマット）はいまだ定められておらず、トランザクションに含むことも是認できません。

4.47.4.1.2.2.3 オプションの内容
IHE_PDI ディレクトリの外に、他のデータを置くことが許されています。追加の内容は上記の制限事項を考慮に入れねばなりません。特に、・DICOM ファイルは許されていません
・データは、4.47.4.1.2.2.2 節で定められた様に、記述ないしは参照されねばなりません。
さらに、ルートディレクトリにある追加のディテクトリの名称は、”IHE”で始まってはなりません。
その他のファイル（必須以外のファイル）がルートディレクトリにあることは明示的に禁止されていませんが、推奨されてはいません。
自動実行される、いずれのアプリケエーションも、受け取り側で動作することを前提にしてはなりません。

_______________________________________________________________________________________________________________________________________________

37
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.47.4.1.2.2.3.1 DICOM 媒体閲覧ソフト（ビューワ）
媒体に DICOM 媒体ビューワがあるときは、以下が推奨されます。
・媒体に保存された全ての DICOM オブジェクトを正しく見読化できます。
・PDF 形式の使用説明書が媒体のルートディレクトリに含まれます。
・CD ケースに短い使用説明書の印刷物が含まれます。
4.47.4.1.2.2.4 媒体の同定
可搬媒体生成役は、物理的媒体の表面にヒトが判読可能な識別情報を、媒体製作者が追加できる様にせ
ねばなりません。媒体に刻印する方法は統合プロファイルの範囲外です。
患者氏名、患者 ID、生年月日、媒体製作日時、検査日、媒体生成施設の名称を、媒体に刻印するよう、推奨されます。内容のタイプ（”DICOM Only”、”DICOM PLUS Web”）も媒体に刻印することが推奨されています。
4.47.4.1.2.3 内容構成の詳細
4.47.4.1.2.3.1 DICOM 内容
媒体内容の DICOM 部分は、現行の DICOM 規格で規定されます。最大の相互運用性を許すため、生成されたファイルのセットは正しくフォーマットされねばなりません。
全ての DICOM データは、DICOMDIR ファイルで参照されねばなりません。
生成された媒体の相互運用性を確保するため、“広く流布する”汎用 DICOM 媒体アプリケーションプロ
ファアイル（DICOM Media Application Profile）が必須です。可搬媒体生成役、可搬媒体取込み役、画像
表示役、レポート閲覧役、印刷作成役は、交換用媒体上の DICOM 情報を交換するため、STD-GEN-CD
媒体保存アプリケーションプロファイル（STD-GEN-CD Media Storage Application Profile）を使用せねばな
りません。
可搬媒体生成役は、複数患者からのデータを含む媒体を生成できることは要求されていません。しかし、
媒体閲覧アクタは複数患者のデータを含む媒体を取り込めねばなりません。
可搬媒体生成役は、DICOM データを不正確にコード化するデータ源からの DICOM SOP インスタンスを訂正する必要は有りませんが、DICOM 媒体生成役は、DICOM ファイルを Explicit VR Little Endian で保存するよう、期待されています。可搬媒体生成役がもっぱら責任を持つ、DCIOMDIR は、参照された SOP
インスタンスの正確性に拘わらず、これを正確にコード化せねばなりません。
可搬媒体生成役は、必須の DICOMDIR 情報をコード化するのに必要な情報が不足している DICOM
SOP インスタンスを含める様に要求されることがあります。たとえば、患者 ID、検査 ID は 2 型、画像 SOP
インスタンスではゼロ長であるのに、患者および検査ディレクトリ記録では 1 型のことがあります。このカテゴ
リに属す属性はすべて、表 4.47.4-1 にあります。
表 4.47.4-1: DICOMDIR に必須の、オプションの DICOM SOP インスタンス属性
可搬媒体生成役は、この様なすべての必須属性の適切な値を、必ず合成するよう要求されます。異なった患者、検査（study）、シリーズ、は別であり続けなければならない（たとえば、異なった検査（study）インスタ
ンス UID を持つ異なった検査（study）には、合成された同一の検査 UID を割り当てられてはいけない）以_______________________________________________________________________________________________________________________________________________

38
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
外は、どこから適切な値を得るか、どのような既定値が適切か、についての特定のガイドは有りません。合成された患者 ID は、UID ではないので世界的に一意であるべきか否かについて、はっきりとした要求事項は有りません。しかし、患者 ID は、患者索引記録（Patient Directory Record）の中では唯一の 1 型属性であり、検索の一次キーです。該当する患者索引記録のそれぞれで、一意であると保証される様にするた
め、合成された患者 ID は、少なくとも作成された媒体の DICOMDIR の範囲では、一意でなければなりません。実装者は、複数の検査索引記録（Patient Directory Record）が、同じ検査（study）インスタンスを持つ
複数の検査索引記録（Patient Directory Record）に、確実にリンクされない様、注意を払わねばなりません。
検査索引記録（Patient Directory Record）は一意の検査（study）インスタンスを持つよう保証されるので、新しい検査（study）インスタンス UID 合成の要求事項はより緩くなっています。可搬媒体生成役は、媒体に保存されたインスタンスにこれらの合成値を加える様に要求されてはいません。
4.47.4.1.2.3.1.1 DICOM インスタンス内容
媒体上の DICOM インスタンス内に含まれる属性に追加の要求事項は、ここでは有りません。
可搬媒体生成役が、予定業務流れのなかで、撮影装置あるいは他のアクタと一体化されている時には、属
性は、DICOM 規格の要求事項を超えた制限を強制されることがあります。たとえば、撮影装置業務一覧問
合わせには、ある種の属性が含まれねばなりません。
しかし、このプロファイルではこの様な一体化は必要とされないので、可搬媒体生成役・画像表示役・レ
ポート閲覧役・印刷製作役の様な、生成された媒体を受けとるアクタは、DICOM インスタンス属性がDICOM 規格の IOD 定義を超えた制限を強制されることを前提とできません。
可搬媒体生成役で作成された交換媒体上のインスタンスは、すべて DICOM 複合 IOD でなければなりません。このため、可搬媒体は以下の SOP クラスのインスタンスを含んではなりません。

• Detached Patient Management SOP Class• Detached Study Management SOP Class• Detached Visit Management SOP Class• Study Component Management SOP Class• Modality Performed Procedure Step SOP Class• Detached Result Management SOP Class• Detached Interpretation Management SOP Class• Stored Print Storage SOP Class
4.47.4.1.2.3.1.2 DICOMDIR ディレクトリ内容
DICOM STD-GEN-CD 仕様の要求事項を超える追加の DICOMDIR キーはありません。
標準索引記録（standard directory records）には、私的要素は含まれてはならず、私的索引記録（private
directory records）が存在してはなりません。
以下の型のディレクトリは基本索引オブジェクト（Basic Directory Object、DICOMDIR ファイル）では使用されてはなりません。
・来院（VISIT）_______________________________________________________________________________________________________________________________________________

39
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・結果（RESULSTS）
・検査要素（STUDY COMPONENET
・保存済印刷物（STORED PRINT）
・トピック（TOPIC）
・私的情報（PRIVATE）
・患者 検査 シリーズ索引記録（PATIENT STUDY SERIES directory Records）は以下の規則に従わねばなりません。
・患者 ID 一個につき一個のみの索引記録（Directory Record）が DICOMDIR に存在せ
ねばなりません。
・検査（study）インスタンス UID 一個につき一個のみの検査索引記録（STUDY Directory
Record）が DICOMDIR に存在せねばなりません。
・シリーズインスタンス UID 一個につき一個のみのシリーズ索引記録（SERIES Directory
Record）が DICOMDIR に存在せねばなりません。これは、シリーズは一個の検査（study）に属すことを暗に示します。
・SOP インスタンス UID 一個につき一個のみの複合インスタンスレベル索引記録（composite instance level Directory Record）が存在せねばなりません。これは、インスタ
ンスは一個のみのシリーズに属すことを暗に示します。
・SOP インスタンス UID 一個につき一個のみの HL7 SRUC DOC 索引記録
（HL7 SRUC DOC Directory Record）が存在せねばなりません。
これは、インスタンスは一人の患者のみに属すことを暗に示します。

・SOP インスタンス UID 一個につき一個のみの HANGING PROTOCOL 索引記録
（HANGING PROTOCOL Directory Record）が存在せねばなりません。
使用者は、媒体生成役と閲覧役の適合宣言のなかで、媒体オブジェクトの相互運用性を確実にするために、使用可能な媒体保存 SOP クラス（Media Storage SOP Class）を閲覧せねばなりません。
4.47.4.1.2.3.1.3 DICOM レポート内容
媒体に診断レポートを保存することを強く推奨します。
可搬媒体生成役は、もしレポート生成役と一体化されたときは、画像診断レポートを作成できるようにせねばなりません。SINR（Simple image and numeric report）プロファイルで規定された様に単純画像レポートパ
ターン（Simple Image Report Pattern）の適切な部分集合に従って、基本テキスト DICOM SR（Basic Text
DICOM SR）が作成可能で、この種の診断レポートは可搬媒体取込み役で取り込みできます。
非 DICOM 形式（たとえば、HL7 CDA）の追加のオプションのレポートはこのトランザクションでは規定されておらず、DICOM SR を作成しなくとも媒体に記録できますが、これは、取り込み不可能データとなります。
注： この要求事項は、診断や治療レポートに使用される、他の DICOM SR SOP Class に適合します。最も基本的な放射線レポートでは、テキストの一段落を含んだ、一個以上の節をもつ単純なパターンで、この要求事項を満たせます。画像参照を含む必要はありませんが、望めば含むようにできます。

4.47.4.1.2.3.2 ウエッブ内容オプション_______________________________________________________________________________________________________________________________________________

40
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
ウエッブ内容オプションを持つ可搬媒体生成役は、以下の要求事項を満たさねばなりません。
最終段階の使用者が、最低限、媒体の内容をウエッブ形式で見られねばなりません。保存された XHTML
ファイルを使用して最大の相互運用性を可能とするため、W3C XHTML 1.0 推奨（W3C XHTML 1.0
Recommendation）の付録 C にある XTML 基本および W3C HTML 適合性ガイドライン（XHTML Basicand W3C HTML Compatibility Guidlines）に従ってフォーマットされねばなりません。
ウエッブ内容オプションが可能な可搬媒体生成役で生成された、ウエッブ閲覧可能なデータは、以下が必須です。
・媒体の DICOM 情報の部分集合のウエッブ上の提示を、XHTML ファイル、JPEG 参照画像、
PNG および・または GIF ファイルのみを用いて行うものを含むこと。
・基本システム（OS）を超えた相互運用性を振興するため小文字のみを含む XTML 内に、ハイパ
ーリンクを含むこと。
・IHE_PDI ディレクトリ内に置きます。一方、これを導出した元の対応する DICOM データは、別の、ルートより下位のディレクトリ（4.47.4.1.2.2.1 参照）に置くこと。
・INDEX.HTM ファイル内で完全に参照されること。
媒体に含まれるウエッブ閲覧可能なデータは、患者の臨床状態を忠実に提示するように生成時に考慮された、セットまたはその一部でなければなりません。
可搬媒体生成役で表示条件の使用が可能であれば、ウエッブで閲覧可能な内容を含むときに、関係する
画像に表示条件を適応できる能力を持たねばなりません。このアプリケーションの使用者は、この機能を使わない選択も可能です。
ISO 9660 ファイルシステムに DICIM が課す規制は、ウエッブ閲覧可能な内容には適応されません。すな
わち、3 文字の拡張子が許されます。
相互運用性を確保するため、JEPG は JFIF ヘッダーを持ち、順次 Huffman DCT 8bit/Component 処理（baseline）およびその進行型亜形でコード化されたファイルを意味します。
相互運用性を確保するため、XHTML の使用は静的および制限型動的コンテントに限られます。現時点
では、ウエッブ閲覧ソフト（ブラウザ）の相互運用性を確保する標準は確立されていないため、DHTML のよ
うな、動的内容（Dynamic Web Content）と多くのスクリプト言語は明示的に禁止されています。Java スクリプ
トの使用は明示的に許可されていますが、ブラウザの違いによる問題があります。可搬媒体生成役は存在する全ての携帯ブラウザに適合する様に携帯構成物や Java スクリプトを使用する様、最大限努力せねばなりません。さらに Java スクリプトの失敗でウエッブページが使用不能にならないようにせねばなりません。
従来の HTML でなく、XHTML が要求されるため、埋め込み型か外部スタイルシートを使うかについての情報を提供する必要があります。これは、見かけを制御する従来の属性が XHTML では許可されていないからです。カスケードスタイルシート（Cascading Style Sheet, CSS）は許可されていますが、ブラウザの違いによる問題があります。さらに CSS の失敗でウエッブページが使用不能にならないようにせねばなりません。
DICOM オブジェクトから導出されていないウエッブ閲覧可能な追加の内容は、媒体に保存できますが、
IHE_PDI ディレクトリには置きません。
4.47.4.1.3 予期される動作_______________________________________________________________________________________________________________________________________________

41
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
受け取り側の閲覧アクタは、媒体から患者のデータを読み、以下に指定された様に動作します。受け取り側の閲覧アクタは、その適合性宣言のなかで、どの DICOM オブジェクトが使用可能かを書面で示さねばなりません。媒体の SOP クラスが使用可能でないとき、DICOMDIR ファイルから取得した、患者氏名、患者
ID、検査 ID、検査日、検査およびシリーズ記述、撮影装置を含む、作業できないデータの要約を使用者に提示しなければなりません。
アプリケーションの自動起動は、このプロファイル内での交換媒体には明示的に禁止されていませんが、推奨されません。
悪意あるソフトウェアを忌避を容易にするため、受け取り側のアクタ（可搬媒体取込み役、画像表示役、レ
ポート閲覧役、印刷製作役、表示役）は、媒体にあるアプリケーションを自動起動する必要は有りません。
4.47.4.1.3.2 画像表示役
画像表示役は、媒体から DICOM 画像を読み、使用者に（使用可能な）すべての検査を閲覧する能力を与えます。GSPS（Grayscale Presentation Status、白黒画像表示条件）オブジェクトとキー画像注釈は、画像
表示一貫性とキー画像注釈の IHE 統合プロファイルが使用可能であれば、媒体から読み出され、適用されます。画像表示役は、他のエビデンス書類を閲覧する他のアクタとオプションで一体化されることがあります。
4.47.4.1.3.3 レポート閲覧役
レポート閲覧役は、DICOM SR レポートを媒体から読み込み、（使用可能な SR オブジェクトクラスに基づいて）処理できます。最低限、使用者に DICOM SR SCP 要求事項に従い、全てのレポートを閲覧する能力を与えます。
4.47.4.1.3.4 可搬媒体取込み役
可搬媒体取込み役は、媒体から DICOM データを読み込みます。一体化されている他のアクタ（第一巻参照）とともに、キー属性整合を実行できねばなりません。整合は、全ての例に必要では有りません（たとえば、同じ取込み施設の間）。整合させるキー属性については、表 4.47.4-2 を参照してください。取込み整合保持業務流れ（IRWF）は、キー属性の整合性を保つ業務流れを提供します（IRWF.b 試験実装版追補を参照してください）。参照検査順列（Referenced Study Sequence）と要求属順列（Requested Attributes
Sequence）は、一貫性保持のため SWF と PIR の未予定例の振る舞いから、削除されていることに注意してください。
一括化された複数のアクタは、使用可能な DICOM オブジェクトを、（画像、表示条件、キー画像注釈、エビデンス書類などの画像オブジェクトについては）画像管理役・画像保管庫（IM/IA）に、あるいは、（診断レ
ポートについては）レポート保管庫に保存できます。
表 4.47.4-2: 媒体インスタンス – 整合すべきキー属性
注 1: ADT の値を可搬媒体取込み役が受け取る方法は、このトランザクションの処理外です。
注 2: コード化された情報の取り扱いは、このトランザクションの範囲外です。

4.47.4.1.3.5 印刷製作役
印刷製作役は、DICOM 画像データを媒体から読み込んでそれを印刷する手段を提供します。
_______________________________________________________________________________________________________________________________________________

42
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.47.4.1.3.6 表示役
表示役（IHE の IT 基盤にて定義）は、媒体のウェッブ閲覧可能な内容を読み込んで、表示します。ウェッブ閲覧可能な情報は、可搬媒体生成役がウェッブ内容オプションを可能とするときのみ、存在することに注意してください。

_______________________________________________________________________________________________________________________________________________

43
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.48 予約通知（Appointment Notification）
この節は、IHE テクニカルフレームワークのトランザクション RAD-48 に該当します。RAD-48 トランザクショ
ンは、オーダ発行役（OP）と部門システム予定役・オーダ実行役(DSS/OF）に使用されます。
4.48.1 範囲
予約通知トランザクションでは、部門システム予定役・オーダ実行役（DSS/OF）から、オーダ発行役（OP）に、新しい予約や予約の変更を通知します。これには、予定検査段階（Scheduled Procedure Step）の日時と時間が含まれます。部門システム予定役・オーダ実行役（DSS/OF）はオーダ発行役（OP）に予約のキャンセ
ルを通知することもできます。
4.48.2 使用例役割
アクタ：部門システム予定役・オーダ実行役（DSS/OF）
役割：予約通知を生成し、対応するオーダ発行役に送ります。
アクタ：オーダ発行役（OP）
役割：予約通知通信文を受け、内部で処理します。
4.48.3 参照する標準
HL7 V2.4、第 10 章
4.48.4 相互作用図
4.48.4.1 予約通知 — 新規予約 （Appointment Notification — New Bookings）
4.48.4.1.1 きっかけ事象
SIU^S12 - 新しい予約の通知
部門システム予定役・オーダ実行役（DSS/OF）はオーダ発行役（OP）からオーダを受け取ります。部門シス
テム予定役・オーダ実行役（DSS/OF）は、どのような検査段階（procedure step）の予約が必要かをきめます。
予定の日を決めたら、部門システム予定役・オーダ実行役（DSS/OF）はオーダ発行役（OP）に、予約通知－ 新規予約 （Appointment Notiffication — New Booking）通信文を送ります。それぞれの予約通知は、ゼロ個以上の予定検査段階（Scheduled Procedure Step）を持ちます。AIS セグメントには、予約の日付と時間が記されます。
4.48.4.1.2 通信文の意味
通信文の意味は、SIU^12 の HL7 V 2.4 第 10 章の規定に従います。通信文の一般的意味については、
HL7 規格を参照してください。セグメントのそれぞれの基数は角括弧（[ ]）の中に与えられます（許される最小と最大の繰り返し回数）
ひとつの予約にひとつのグループ（RGS と AIS）があります。同一のオーダに数個の予約があるときは繰り返されます。これは予約のタイミング情報を含むので、少なくとも一組の RGS と AIS がなければなりません。

_______________________________________________________________________________________________________________________________________________

44
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
それぞれの通信文は、SIU 通信文の受信側から送信側へ、HL7 ACK メッセージで受信通知されねばなりません。
48.4.1.2.1 MSH セグメント
MSH セグメントは、RAD TF-2: 2.4.2.2 通信文制御（Message Control）に定められた様に、構成されねばな
りません。
MSH-9 Message Type の欄（field）は、最低二つの成分を持たねばなりません。最初の成分は SIU、第二の成分は S12、でなければなりません。第三の成分はオプションですが、もし値を持つなら、SIU_S12 でなければなりません。
4.48.1.2.2 SCH セグメント
以下の表に SCH セグメントの必須およびオプションの欄（field）を示します。
SCH-1 Placer Appointment ID （オーダ発行側予約 ID）欄（field）は、オーダ発行側アプリケーションの予約要求の永久識別子です。これは使用されません。
SCH-2 Filler Appointment ID （オーダ実施側予約 ID）欄（field）は、オーダ実施側アプリケーションの予約
要求の永久識別子です。これは送信が必須です。
SCH-4 Placer Group Number（オーダ発行側グループ番号）は、オーダ発行役とオーダ実行役の両方がオーダグループの構想を持つときのみ使用されます。それ以外では値があってはなりません。
SCH-6 Event Reason は HL7 V2.4 では必須ですが、この IHE トランザクションではオーダ発行役には使われません。HL7 V2.4 との適合性のため、オーダ実行役は^APT 値を送らねばなりません。
SCH-11 Appointment Quantity Timing は HL7 V2.4 では必須ですが、この IHE トランザクションではオーダ発行役には使われません。日付と時間は AIS セグメントで送られます。HL7 V2.4 との適合性のため、1 の値を入れて送らねばなりません。
SCH-16 Filler Contact Person は、要求された予約を入れた責任者です。多くの場合、この人は予定の管理や予約を検閲する責任者でもあります。これは、予約の変更や取消の場合に呼ばれる人です。
SCH-20 Entered by Person は、予約要求に予定を入れた責任者です。予約要求の責任者を追跡するために含まれています。
SCH-26 Placer Order Number は、オーダ発行側のアプリケーションが、オーダ実行役の予定作成応答と連携する予約に割り付けた、オーダ番号です。IHE 放射線の予定業務流れ（SWF）では、この欄（field）は送信されねばなりません。
SCH-27 Filler Order Number は、オーダ実行側のアプリケーションが、オーダ実行役の予定作成応答と連携する予約に割り付けた、オーダ番号です。IHE 放射線の予定業務流れ（SWF）では、この欄（field）は送信されねばなりません。

_______________________________________________________________________________________________________________________________________________

45
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.48.1.2.3 RGS セグメント
RGS セグメントは、予定された事例に特定される資源（日付、時間、場所、医療スタッフ）の関係を特定するのに使われます。関連する資源は資源群の中で規定されます。それぞれの群は、
RGS セグメントで始まり、AIS セグメント（日付と時間用）が続きます。他のセグメント（AIG,
AIL, AIP）の使用はこの統合プロファイルの範囲外です。同じ予約の中で起こる様に予約された予定検査段階（Scheduled Procedure Step）セット一個について一個の群が必要です。
RGSセグメントはHL7 V2.4第10章「予定」の10.6.3節「RGS – Resource Group
Segment」に記載の様に構成されねばなりません。
4.48.4.1.2.4 AIS セグメント
AIS セグメントは予定検査（Sheduled Prodedure）の日付と時間を含みます。資源一グループに一個のみ AIS セグメントが存在します。
AIS セグメントはHL7 V2.4 第10章「予定」の10.6.4節「AIS – Appointment Information Service
Segment」に記載の様に構成されねばなりません。以下の表に、AISの必須とオプションの欄（field）を示します。
AIS-2 Segment Action Code は、このセグメントの情報に追加、更新、変更するときに行われる動作を含んでいます。同じRGS群にあるすべてのAISセグメントは、同じ動作コードを持たねばなりません。この欄（filed）は必須で、A の値です。
AIS-3 Universal Service Identifier は、予定される予定検査段階（Schedled Procedure Step）の識別子と、関連する要求検査要素（Requested Procedure Components）を含んでいます。最初の三つの要素（識別子、文字列、コード化方式の名称）は、要求検査コード（Requested Procedure Code、コー
ド値、意味とコード形式）を含んでいます。第五の要素（代替テキスト）は予定検査段階（Scheduled Procedure Step）の連鎖されたテキスト形式の記述を含み、オーダ発行役のレベルで理解されます。第四と第六要素は使用されません。
AIS-4 Start Date/Time は、予約日付と時間を含んでいます。日付と時間の両方が必須です。をふくむことができます。時差が入っていないときは、送信者の現地時間として解釈されます。たとえば、米国中央時間で2004年10月22日午前9時は、200410220900-0600、または、米国中央時間圏内の送信者は、200410220900 となります。
4.48.1.2.5 NTEセグメント
検査に関連するあらゆる情報はNTEセグメントで送ることができます。たとえば患者への指示（空腹時、排尿しないで、排尿後）、前投薬（事前の注射、生物学的検査）、等です。
NTE-2 Source of Comment は、コメントの起原を示します。この欄（field）は必須ですが、空欄でも良いです。有効な値は以下です。
NTE-3 Comment は、コメントの文言を含みます。以前送信したコメントを削除するには、この欄（filed）は空白の引用符（""）を含まねばなりません。

_______________________________________________________________________________________________________________________________________________

46
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
NTE-4 Comment Type は、コメントの種類を示します。有効な値は以下です。
4.48.4.1.3 期待される動作
オーダ発行役は予約をうけとらねばならず、HL7 ACK通信文を返さねばなりません。
4.48.4.2 予約通知 — 予約変更 （Appointment Notification - Reschedule Bookings）
4.48.4.2.1 きっかけ事象
SIU^S13 - 予約変更 （Appointment Notification - Reschedule Bookings）
時には、放射線部門で予約が変更されることがあります。この通信文は、部門システム予定役・オーダ実行役（DSS/OF）により送られ、オーダ発行役（OP）に、既存の予約が変更されたことを通知します。AIS セグメ
ントには、既存の予約が移動してきた、あたらしい日付と時間が記されます。さらに、既存の予約の中の変更されない部分も記されます。
4.48.2.2 通信文の意味
通信文の意味は、SIU^13 の HL7 V 2.4 第 10 章の規定に従います。通信文の一般的意味については、
HL7 規格を参照してください。
ひとつの予約にひとつのグループ（RGS と AIS）があります。同一のオーダに数個の予約があるときは繰り返されます。これは予約のタイミング情報を含むので、少なくとも一組の RGS と AIS がなければなりません。
それぞれの通信文は、SIU 通信文の受信側から送信側へ、HL7 ACK メッセージで受信通知されねばなりません。
4.48.4.2.2.1 MSH セグメント
MSH セグメントは、RAD TF-2: 2.4.2.2 通信文制御（Message Control）に定められた様に、構成されねばな
りません。
MSH-9 Message Type の欄（field）は、最低二つの成分を持たねばなりません。最初の成分は SIU、第二の成分は S13、でなければなりません。第三の成分はオプションですが、もし値を持つなら、SIU_S13 でなければなりません。
4.48.2.2.2 SCH, RGS, NTE セグメント
SCH, RGS, NTE セグメントは、現行の提案の 4.48.4.1.2「通信文の意味」に記された様に構成されねばなりません。
4.48.4.2.2.2 AIS セグメント（訳者注：節番号は原本のエラー）
AIS セグメントは、AIS-2 Segment Action Code をU 値にする以外は、4.48.4.1.2 節に記載の様に構成されねばなりません。
4.48.4.2.3 期待される動作_______________________________________________________________________________________________________________________________________________

47
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
オーダ発行役は予約情報をうけとらねばならず、HL7 ACK通信文を返さねばなりません。

4.48.4.3 予約通知 — 予約取消 （Appointment Notification - Cancel Bookings）
4.48.4.3.1 きっかけ事象
SIU^S15 - 予約取消 （Appointment Notification - Cancel Bookings）
この事象は既存の予約がオーダ実行役に取り消されたことをきっかけに生じます。
4.48.3.2 通信文の意味
通信文の意味は、SIU^15 の HL7 V 2.4 第 10 章の規定に従います。通信文の一般的意味については、
HL7 規格を参照してください。
ひとつの予約にひとつのグループ（RGS と AIS）があります。同一のオーダに数個の予約があるときは繰り返されます。これは予約のタイミング情報を含むので、少なくとも一組の RGS と AIS がなければなりません。
それぞれの通信文は、SIU 通信文の受信側から送信側へ、HL7 ACK メッセージで受信通知されねばなりません。HL7 ACK 通信文の定義と議論については、RAD TF-2:2.4.3 受信通知モード（Acknowledgement
Mode）を見てください。
4.48.4.3.2.1 MSH セグメント
MSH セグメントは、RAD TF-2: 2.4.2.2 通信文制御（Message Control）に定められた様に、構成されねばな
りません。
MSH-9 Message Type の欄（field）は、最低二つの成分を持たねばなりません。最初の成分は SIU、第二の成分は S15、でなければなりません。第三の成分はオプションですが、もし値を持つなら、SIU_S15 でなければなりません。
4.48.2.2.2 SCH, RGS, NTE セグメント
SCH, RGS, NTE セグメントは、現行の提案の 4.48.4.1.2「通信文の意味」に記された様に構成されねばなりません。
4.48.4.2.2.3 AIS セグメント
AIS セグメントは、以下を除いて、4.48.4.1.2 節に記載の様に構成されねばなりません。
・AIS-2 Segment Action Code は D （Delete）
4.48.4.3.3 期待される動作
オーダ発行役は取消のために予約情報をうけとらねばならず、HL7 ACK通信文を返さねばなりません。この通信文は、オーダ発行役、あるいは、オーダ実施役がオーダを取り消すときには使用してはなりません。予約は、オーダ発行役とオーダ実行役により自動的に取り消され、オーダ発_______________________________________________________________________________________________________________________________________________

48
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
行役も同じ動作をするものとされてます。

4.49 インスタンス可用性通知（Instance Availability Notification）
この節は、IHE 放射線テクニカルフレームワークのトランザクション RAD-49 に該当します。画像管理役・画像保管庫（IM/IA）、部門システム予定役・オーダ実行役（DSS/OF）、後処理管理役とレポート管理役（RM）
4.49.1 範囲
部門システム予定役・オーダ実行役（DSS/OF）は、関連する実行役に、新しく保存された DICOM オブジェ
クトの可用性についての情報を知らせる通信文を送付します。通知を受ける実行役は、予定業務流れの実行にこれらのオブジェクトを必要とすることがわかっており、この通信文で参照されたオブジェクトを取得し、使用することができます。これにより、画像部門での様々な業務流れを使用可能にできます。
4.49.2 使用例役割
アクタ： 画像管理役・画像保管庫 （Image Manager/Image Archive, IM/IA）
役割： インスタンス可用性通知の通信文を生成して、部門システム予定役・オーダ実行役（DSS/OF）に、さらにオプションで他の業務流れ管理役（たとえば、後処理管理役、レポート管理役（RM））に、通信文を送付します。
アクタ：部門システム予定役・オーダ実行役（DSS/OF）
役割： インスタンス可用性通知の通信文を受け取り、内部で処理を行います。
アクタ： 後処理管理役
役割： インスタンス可用性通知の通信文を受け取り、内部で処理を行います。
アクタ： レポート管理役（RM）
役割： インスタンス可用性通知の通信文を受け取り、内部で処理を行います。
4.49.3 参照する標準DICOM 2011 PS3.4: Instance Availability Notification Service Class
4.49.4 相互作用図
4.49.4.1 インスタンス可用性通知（Instance Availability Notification､ IAN）
この通信文は、画像管理役・画像保管庫（IM/IA）からの Instance Availability Notification Service Class を使用し、他の業務流れ管理役が検査段階を予定したり開始するのに必要とし、待っている DICOM インス
タンスの可用性について、これら管理役に知らせます。
4.49.4.1.1 きっかけ事象
画像取得中に、MPPS が可能であるモダリティは一セットのインスタンスを生成し、画像管理役・画像保管
庫 （IM/IA）に保存します。あるいは、エビデンス書類取り込みの一部として、MPPS が使用可能な画像取り込み役（Importer）が、インスタンスを読み込み、画像管理役・画像保管庫 （IM/IA）に保存します。MPPSで参照された一セットのインスタンスの最後のインスタンスを読み込んだ後で、画像管理役・画像保管庫_______________________________________________________________________________________________________________________________________________

49
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________（IM/IA）は、インスタンス可用性通知を、部門システム予定役・オーダ実行役（DSS/OF）に、送らねばなりません。のとき、部門システム予定役・オーダ実行役（DSS/OF）は、関連する MPPS をすでに受け取っています。これは、業務流れに含まれる他のインスタンス管理役に、インスタンス可用性通知を送るかどうか決め、
関連する MPPS で参照されたすべてのインスタンスが可用であることを通知します。
インスタンスへの参照を含む、おのおのの MPPS に、一個のインスタンス可用性通知が送られねばなリません。これは、RAD-6 （Rad TF-2:4.6 単純例、未予定例、群化例、追加例（通常の例と群化された例）、中止例）トランザクションと、RAD-7 （Rad TF-2:4.7: MPPS DICPNTINUED、誤った業務を業務一覧から選んだ場合（Rad TF-2:4.7.4.1.3.1）を除く）トランザクションとに、記載されたすべての MPPS 例に、適応されます。
同様に、RAD TF-3:4.59.4.1.2（未予定読込みと未予定読み込み例）と PPS 読込み中止（RAD TF-3:
4.60.4.1.2.2）に記載された、PPS 読み込み例にも適応されます。
4.49.4.1.2 通信文の意味
生成され、画像管理役・画像保管庫（IM/IA）に保存予定の DICOM インスタンスを参照する、撮影装置からの MPPS 通信文により、部門システム予定役・オーダ実行役（DSS/OF）と画像管理役・画像保管庫（IM/IA）に、画像取得が終了したことが示されます。生成され、画像管理役・画像保管庫（IM/IA）に保存予定の DICOM インスタンスを参照する、取込み役（Importer）からの Import MPPS 通信文により、部門シ
ステム予定役・オーダ実行役（DSS/OF）と画像管理役・画像保管庫（IM/IA）に、画像取込みが終了したことが示されます。
MPPS とインスタンス可用性通知は、ことなった事例について知らせることに注意してください。このため、保存される画像の全容量と現場施設のシステム環境により、MPPS がインスタンス可用性通知よりも、部門
システム予定役・オーダ実行役（DSS/OF）に、相当早く到着することがあります。MPPS が撮影装置や取り込み役(Imporeter)から、画像管理役・画像保管庫（IM/IA）に時期をえた送信がおこなれない場合、MPPS
完了トランザクションへの IAN トランザクションの依存により、部門システム予定役・オーダ実行役（DSS/OF）への可用性の通知が遅れることがあります。
画像管理役・画像保管庫（IM/IA）は、Instance Availability Notification SOP Class の SCU として動作し、Instance Availability Notification SOP Class を生成せねばなりません。IM/IA は、参照実行済検査段階順
列（Referenced Performed Procedure Step Sequence）の Reference SOP Instance UID の値を埋めねばなりま
せん。IM/IA は、該当する MPPS で参照されたすべてのインスタンスへの参照を含まねばなりません。SOP
Class の他の属性は、DICOM 補遺 93 に示された様に、使用されます。
画像管理役・画像保管庫（IM/IA）は、複数のインスタンス可用性通知を送信できねばなりません。画像管理役・画像保管庫（IM/IA）は、部門システム予定役・オーダ実行役（DSS/OF）に、インスタンス可用性通知を送らねばならず、さらに、このトランザクションに記された他のアクタにも送信できるように設定されます。
部門システム予定役・オーダ実行役（DSS/OF）、後処理管理役、レポート管理役（RM）は、この通知を受け
たとｔきは、インスタンスの完全なセットが、Rtrieve AE Title 属性で識別される、画像管理役・画像保管庫（IM/IA）で使用可能であることを理解せねばなりません。
一過性のエラー状況により、アクタはインスタンス可用性通知を受け取ったインスタンスを取得できないことがあります。インスタンス可用性通知で参照されたインスタンスの可用性がアクタには不確かなときには、ア
クタは画像可用性問合せ（Images Availability Query [RAD-11]）を付加的方法として使用し、状態を確認できます。

_______________________________________________________________________________________________________________________________________________

50
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
さらに、画像管理役・画像保管庫（IM/IA）は、インスタンス保存や内部供給を、現場施設の方針に従って扱えるとものされています。

4.50 インスタンス保存 （Store Instances）
この節は、IHE テクニカルフレームワークのトランザクション RAD-50 に該当します。送出選択役と送出管理役がトランザクション RAD-50 を使用します、
4.50.1 範囲
インスタンス保存トランザクションでは、送出選択役が送出管理役に、選択した複合インスタンスを送信します。
4.50.2 使用例の役割
アクタ： 送出選択役（Export Selector）
役割： インスタンスを送出管理役に送ります。
アクタ： 送出管理役（Export Manager）
役割： 送出選択役からインスタンスを受け取り、識別情報削除や偽名化の待ち行列に入れます。
4.50.3 参照する標準DICOM 2011 PS 3.4: Storage Service Class
4.50.4 相互作用図
4.50.4.1 きっかけ事象
送出選択役は送出管理役に、一個以上の DICOM 連携を順次転送することができます。
4.50.4.1.3 予期される動作
送出管理役は、受け取った DICOM オブジェクトを、処理の準備ができるまで、待たせておきます。
DICOM 規格（2011）では、いくつかの複合保存クラス（composite storage SOP class）を定義しています。主出管理役は、画像（RAD TF-2; 表 4.8-1 を見てください）、エビデンス書類、構造化レポート、表示条件や放射線治療オブジェクトの様な、少なくともひとつの複合保存クラスを使用可能とせねばなりません。

4.51 送出選択保存 （Store Export Selection）
この節は、IHE 放射線テクニカルフレームワーク RAD-51 に該当します。送出選択役と送出管理役がRAD-51 トランザクションを使用します。
4.51.1 範囲
送出選択保存トランザクションでは、選択された複合インスタンスの目録（manifest）として働く、キーオブ_______________________________________________________________________________________________________________________________________________

51
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
ジェクト選択書類が、送出選択役から送出管理役におくられます。
4.51.2 使用例の役割
アクタ： 送出選択役
役割り： 送出管理役に目録（manifest）を送る。
アクタ：送出管理役
役割り： 送出選択役から目録を受け取り、参照された複合インスタンス（instance）を、処理（識別情報削除、匿名化、送出）のため、順番待ちさせます。
4.51.3 参照する標準DICOM 2011 PS 3.4: 保存サービスクラス（Storage Service Class）
DICOM 2011 PS 3.15: 基礎アプリケーション水準秘匿プロファイル（Basic Application Level
Confidentiality Profile）
DICOM 2011 PS 3.3:

情報オブジェクト定義（Information Object Definitions）

DICOM 2011 PS 3.16: 内容対応付け資源（Content Mapping Resource）
4.51.4 相互作用図
4.51.4.1 送出選択保存
4.51.4.1.1 きっかけ事例
送出選択役は DICOM 連携をもつ送出管理役に目録を転送することができます。転送のタイミングはインスタンス保存（Store Instance）トランザクションのどれとも連結していません。インスタンス保存トランザクションと同時にも、異なったときにも転送が行われ、また、目録はそれに参照されたインスタンスの送信前にも、後にも受信できるからです。
4.51.4.1.2 通信文の意味
送出選択役は DICOM C-Store 通信文を使用して目録を転送します。送出選択役は DICOM Storage
SCU で、送出管理役は DICOM Storage SCP です。
目録（送出選択）はキーオブジェクト選択 SOP クラス（Key Object Selection SOP Class）のインスタンスで、
表 4.51.4-1 の規定に従って構成されます。これは、DICOM 2011 PS 3.16 に定められた TID 20010 で、これ自身は拡張不能です。
表 4.51.4-1: 送出選択（目録）雛形 － DICOM TID 2010 の特別形
書類の表題は、（TCE001, IHERADTF, "For Teaching File Export"）か、（TCE002, IHERADTF, "For
Research Collection Export"）のいずれかでなければなりません。
Key Object Description の TEXT 内容項目は、存在するときは、選択の配置を記載しなければなりません。
この値の仕様は、選択送出役と選択管理役の間の協働を必要としますが、これは本トランザクションの定義の域を超えます。
・ ティーチングファイルの場合、この値は、編集用に症例データが送付されます。使用者の識別情報を含むことができますが、もっと一般的で、役割、部門、あるいは、種別の識別子とすることもできます。
_______________________________________________________________________________________________________________________________________________

52
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・ 治験の場合、この値は、治験のプロトコールの識別子を含むことができ、Remap Identifier オプ
ションの動作に影響することがあります。
・ 研究用データ集積の場合、この値は、研究用データ収集の識別子を含むことができます。
一個の書類表題修飾子（Document Title Modifier）内容項目が存在する場合には、表 4.51.4-2 に示す値の一つを特定します。
表 4.51.4-2 遅延理由値
目録（manifest）には参照されたインスタンスの集合を記述する追加の情報はありません。ティーチングファ
イル編集システムに伝える、予め書式化された情報のような追加情報は、目録で参照された別の SR 書類
として伝送されねばなりません。4.52 追加ティーチングファイル情報を参照してください。
目録（manifest）は、追加ティーチングファイル情報のみを参照してはなりません。従って、追加ティーチン
グファイル情報を含むあらゆる SR 書類は元の送出選択により参照されねばなりません。別の目録が追加されたり、送信されてはなりません。
DICOM TID1002 観察者状況（Observer Context）に含まれる DICOM TID 1003 観察者識別属性（Person Observer Identifying Attribute）が目録に含まれないときは、誰が選択したかが分からなくなることに注意してください。その結果、送出管理役と以降のアクタは、キーオブジェクト記載テキスト内容（KeyObject Description TEXT content）で示された送り先以外の、データ選択者の下へ届けることができなくなります。
目録は一人の患者のインスタンスのみを参照することができ、（この条件下で）多数の検査の複数のインスタンスが存在できます。
普通の使用例では、現検査と以前の検査の両方を選択すると、複数の検査が含まれます。選択に二個以上の検査を含むときは、DICOM では一個のキーオブジェクト選択書類（Key Object Selection Document）のインスタンスを生成し、一個のキーオブジェクト選択書類（Key Object Selection Document）インスタンスに一個の検査インスタンス UID （Study Instance UID）が必要で、同一書類順列（Identical Documents
Sequence） （DICOM 2011 PS 3.3 C.17.6.2.1 参照）で相互参照されねばなりません。従って、IHE では複数の同じ目録が必要で、一個の検査に一個の目録が必要です。
4.51.4.1.3 予期される動作
送出管理役は、目録に書かれた全ての DICOM インスタンスを受信するまで、処理を待ちます。
目録には必要な処理の形式が記載されているので、目録を受信する前に処理を開始してはなりません。遅延理由オプションを使用すると、処理をもっと遅らせることができます。4.51.4.1.5 節を参照してください。
複数検査を扱うために複数の目録を使用する場合には、どの目録でも同じ検査が参照されますので、送出管理役は全ての目録の到達を待たず、処理を開始できることに注意してください。この複数検査の例では、目録一個のみの受診をエラー状態とせず、通常の処理が行われなければなりません。送出管理役は、目録のそれぞれの同一書類順列（Identical Documents Sequence）を調べて複数例選択ですことを確認し、同じ送出の繰り返しを防がねばなりません。
インスタンスが受信されても、目録が設定可能な時間内に受信されない場合は、送出は行われてはなりません。
目録に記された全てのインスタンスが設定可能な時間内に受信されない場合は、送出管理役は不完全な_______________________________________________________________________________________________________________________________________________

53
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
ままで処理を行い、更新した目録を作成しなければなりません。無かったインスタンスが後に受信された場
合は、送出しないようにするか、後から受信したインスタンスのみを含む別の目録とともに別の送出として行
うか、のいずれかになります。
目録に参照されたインスタンスは、送出管理役が保存 SOP クラスとして処理可能でない SOP クラスのこともあり、決して受信できないことがあります。目録には SOP クラス UID が含まれます。送出管理役は不完全なままで処理を行い、更新した目録を作成しなければなりません。
送出管理役と画像管理役・画像保管庫（IM/IA）が一括化されており、参照された DICOM インスタンスをすべて保有している場合には、目録の受信と同時に処理を開始できます。
送出管理役は、目録に参照された全ての DICOM インスタンスに識別情報の削除と偽名化を、インスタン
ス送出[RAD-53]トランザクションを開始して送出を行う前に、4.51.4.1.4 節に規定されている様に、行います。
4.51.4.1.4 識別情報削除と偽名化
4.51.4.1.4.1 識別情報削除と偽名化の基礎的必須事項
適切な識別情報削除と偽名化の実現に、特定の目的に応じてどの属性を削除するかにはかなりの変動があります。付録 I.1 を参照してください。
このトランザクションはしたがって、全ての文字型属性や私的属性値の削除を要求するものではありません。
むしろ、削除したり値を変えたりする属性を、使用者が設定可能とするような機構を実装しなければなりません。このトランザクションの最小要求事項は、DICOM PS 3.5 の基礎的アプリ秘匿性プロファイル（Basic
Application level Confidentiality Profile）に記載された属性の全てを削除や値の置換ができるように設定可
能でなければなりません。さらに、一切識別情報削除をしない様に設定できねばなりません。
識別情報削除が行われたら、送出管理役は DICOM インスタンスの個々のデータセットに患者識別子削
除属性（0012, 0062）に”YES”を、識別子削除方法（00120, 0063）、または、識別子削除方法コード順列（00120, 0064）を追加せねばなりません。
ある種の想定業務手順では、ティーチングファイル受信役で全ての識別子削除を行うか、あるいは、全く行
わない場合の様に、送出管理役では識別情報削除を行わない設定が望ましいことがあります。この様な場
合には、患者識別情報削除属性（0012, 0062）がすでに存在している場合には、これを変更してはなりません。存在しない場合には、追加してはなりません。
ある種の識別情報削除想定業務手順では、UID を置き換える必要があります。このトランザクションでは
UID の置き換えは必須ではありませんが、UID を置き換えたときは、送出するインスタンスのセット内のデータ一貫性を保持するのは必須です。この両者ができるように設定できる様に実装しなければなりません。これにより、以下の規則が遵守されます。
・

データセット内の同じ種別の複数インスタンスの複合の場合には、同じ置換後の UID が使用されねばなりません。すなわち、同じ一つの検査に含まれる全てのインスタンスは同じ検査インス
タンス UID を持たねばなりません。

・同じデータセット内の、他インスタンスや種別が UID で参照されている場合には、この参照は更新されねばなりません。すなわち、前書類、参照画像、元画像のインスタンス UID の更新です。

・

同じデータセット内に無い、他インスタンスや種別が UID で参照されている場合には、削除、または、一貫した、良好に生成された、ダミーUID に置き換えるかしなければなりません。

_______________________________________________________________________________________________________________________________________________

54
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
もし同一のインスタンスが複数回にわたって別の時期に送出された場合には、識別属性 UID は同じ値で置き換えられことも、別の値になる、こともあります。これは、このトランザクションでは識別属性と UID の置
換は、再対応識別子オプションの規定以外には、決定論的振る舞いを要求されるものではないということです。付録 I.2 を参照してください。
識別情報削除と偽名化の行動は、無効な IOD を生成してはなりません。特に・必須および条件付き属性は削除せず、置き換えねばなりません。

・一型の属性は、値が無くてはなりません

・二型の属性は長さゼロでコード化できますが、患者氏名、患者 ID、検査 ID、アクセション番号の様な閲覧アプリで使用される属性には、値を入れることが推奨されます。

4.51.4.1.4.2 目録の強制送出選択役から受信した目録は、キーオブジェクト選択書類（Key Object Selection Document）で、一人の患者の複数インスタンスを含みますが、複数の検査の複数インスタンスのことがあり、複数の検査が含まれる場合には、キーオブジェクト選択書類（Key Object Selection Document）の複数のコピーがあります。
目録は元の識別情報を含んでいることがあるので、識別情報削除と偽名化を、参照する検査、シリーズやインスタンスと同じ必須事項に合致する識別情報削除と偽名化を、送出の前に受ける必要があります。
送出管理役は目録にある参照先の検査、シリーズ、インスタンスの UID を更新しなければなりません。
送出管理役が目録で参照されている全てのインスタンスを受領しておらず受領役に送出できないときは、送信する目録から、送出できないインスタンスは削除されねばなりません。
遅延理由を特定する書類標題修飾子は削除されねばなりません。
送出管理役から受領役への送出には目録が常に含まれねばなりません。
複数検査の例では、目録の正しい数を受領役へ、送出選択役から受信した内容に関係なく、送出しなけ
ればなりません。
4.51.4.1.4.3 識別子再割付オプション
このオプションの目的と要求事項は１RAD TF-1: 17.2.2 に記載されています。DICOM 治験属性は付録 I.3に詳述されています。
表 4.51.4-3 は、識別子の再割付に使用する値や置き換えるべき値を選択するキーとして使用する属性の一覧を示します。UID を含む他の属性は、個々のインスタンスで、同じ値に置き換えることも、置き換えないこともできます。このオプションでは、表 4.51.4-3 に示される属性のみに決定論的振る舞いが要求されます。
表 4.51.4-3 は以下の凡例を使用します。
・M – 「一致」。「一致」は、該当する属性がキー値として、指定されたレベルで一致させるのに使用されます。したがって、他の属性を該当レベルで割り付けるため、新しい値を選択することに使用します。

・C – 「変更」。「変更」は該当する値を非ゼロ値で置き換えるか、もしその属性が無いなら、非ゼロ値を挿入することを意味します。

・D – 「削除」。「削除」は、三型属性は削除し、二型属性は長さゼロのデータで置き換え、一型
はダミー値で置き換えることを意味します。

_______________________________________________________________________________________________________________________________________________

55
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・L – 「放置」。「放置」は既にある属性値を変更しないことを意味します。

注 1： 送出先である治験プロトコルは目録に指定された配置で伝達されるため、インスタンスの属性で定める治験プロトコル水準の対応付けは、指定されません。
注 2：削除オプションはこれらの属性にはありません。置換が必須です。これらの属性は従来のデータベー
スや閲覧アプリの適切な実行に重要で、空値（null）やダミー値は容認されません。たとえば、典型的には、治験対象 ID は、患者 ID、患者氏名にも繰り返し使われます。同様に、治験施設 ID は治験施設名にも繰り返し使われます。
注 3：検査日付と時刻をそのままにするか、置き換えるかは治験の要求事項により決まります。実装は両者が可能である必要があります。
注 4：二個以上のオプションが可能であることは、アプリはどのオプションにも対応できる様に設定できねばならないことを意味します。
4.51.4.1.4.4 埋め込み識別情報削除オプション
単フレームあるいは多フレーム画素に埋め込まれた識別情報（訳者注：識別情報が画像の付帯データでは無く、画像データの一部になっている状態）の削除は簡単な業務ではありません。多種の撮影装置や多種の製造者の画像源では、どの画素が識別情報なのかあらかじめ知ることは困難です。従ってこの作業は自動化することは困難で、使用者インターフェースを介した人間による操作が必要となりますが、操作は基本的に画素データ編集アプリです。
このオプションを可能と主張するアプリは、画素データの識別情報除去の方法を提供せねばなりません。これを実現する方法は指定されていません。患者識別情報が読めないか、回復できなければ、識別情報削除が成功したと見なされます。
特定の画像に埋め込まれた識別情報を削除するか否かを決めるのは困難なことがあり、人間の介在が必要なことがあります。このオプションでは、送出管理役が危険性のある画像の種別を判定する機構を提供し、人間の操作者が識別情報の削除を確認できる必要があります。
もしインスタンスの埋め込み注釈（0028,0301）属性が、すでに、”NO”であれば、画素埋め込み識別情報削除は必要ありません。画素埋め込み識別情報が削除されたときには、送出管理役は個々のインスタンスの
データセットに埋め込み注釈（0028,0301）属性の値を”NO”として、追加せねばなりません。
このオプションは、SOP インスタンスの変更を要求も禁止もしません。実装では、両者が可能な様に設定できねばなりません。
4.51.4.1.4.5 非画像インスタンスの識別情報削除
非画像インスタンスの識別情報削除には特定の必要事項やオプションはありません。たとえば、単純テキス
トレポートを含む SR オブジェクト、エビデンス書類（ED）、あるいは、被包化 PDF 書類は、関知し自動的に削除することが困難な識別情報を含むことがあり、操作者が必要になることがあります。この様な情報の削除機構を規定することはこのプロファイルの範囲外です。送出選択役が SCP として DICOM 複合保存
SOP インスタンスの部分集合を可能とし、この因子（識別情報削除）を考慮に入れるべきですと言えば十分です。
4.51.4.1.5 遅延理由
送出役が遅延理由オプションを可能とし、標題の書類標題修飾子が遅延理由のコード化値をもち、送出役がコード化された理由を使用可能なら、遅延理由が充足されるまでの設定した時間内に遅延理由が満たされないときは、処理されません。
_______________________________________________________________________________________________________________________________________________

56
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.52 ティーチングファイル追加情報保存（Store Additional Teaching File Information）
この節は、IHE テクニカルフレームワークの RAD-52 トランザクションに該当します。送出選択役と送出管理役が RAD-52 を使用します。
4.52.1 範囲
ティーチングファイル追加情報保存トランザクションでは、送出選択役は追加のティーチングファイル情報を含んだ SR 書類を送出管理役に送信します。
4.52.2 使用例の役割
アクタ： 送出選択役
役割： 送出管理役に情報を伝える。
実行約： 送出管理役
役割：送出選択役から情報を受け取り、識別情報削除と偽名化および送出の順番待ちに入れます。
4.52.3 参照する標準DICOM 211 PS 3-4: 保存サービスクラス （Storage Service Class）
4.52.4 相互作用図
4.52.4.1 ティーチングファイルへの追加情報の保存 （Store Teaching File Information）
4.52.4.1.1 きっかけ事例
送出選択役は、送出管理役に一個以上の DICOM 連携の中で、情報を送出管理役に逐次送ることができます。
伝送のタイミングは、インスタンス保存（Store Instance）、送出選択保存（Store Export Selection）トランザクションとは連結しておらず、同じあるいは異なる DICOM 連携のなかで起こり得ます。目録は、目録に記されたインスタンスの前でも、途中でも、後でも受信できます。
4.52.4.1.2 通信文の意味
送出選択役は、一個以上の強化 SR SOP クラスインスタンス（Enhanced SR SOP Class Instance）としてコード化された追加情報を伝送するために、DICOM C-Store 通信文を使用します。送出選択は DICOM
保存 SCU で、送出管理役が DICOM 保存 SCP です。
この情報には、参照されたインスタンスの集合を要約した目録（Manifest）とは異なった情報が含まれています。
一個以上のインスタンスが存在することがあります。
このトランザクションのインスタンスが、送出選択保存トランザクション内の目録で参照されていなければ、送出物には含まれません。
書類の表題は、（TCE006, IHERADTF, "Additional Teaching File Information"）でなければなりません。
典型的な放射線ティーチングファイル集合を記述します。雛形は付録 H に記載されています。
4.52.4.13 予期される動作_______________________________________________________________________________________________________________________________________________

57
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
送出管理役は、処理をはじめるまで、受信した DICOM オブジェクトを順番待ちに入れます。

4.53 インスタンスの送出 （Export Instances）
この節は、IHE テクニカルフレームワークの RAD-53 トランザクションに該当します。送出選択役と受信役
送出管が RAD-53 を使用します。
4.53.1 範囲
インスタンス送出トランザクションでは、送出選択役は識別情報削除・偽名化された複合インスタンス群と、集合の目録として使用されるキーオブジェクト選択書類（Key Object Selection documents）とを、受信役に送ります。目録の目的は、参照されたインスタンス群が送出される集合を構成するものであることを保持することです。
4.53.2 使用例役割
アクタ：送出役
役割： 識別情報削除・偽名化されたインスタンス群と目録を受信役に伝送します。
アクタ：受信役
役割：送出管理役からインスタンスを受け取ります。
4.53.3 参照される標準
DICOM 2011 PS3.4: 保存サービスクラス （Storage Service Class）
4.53.4 相互作用図
4.53.4.1 インスタンスの送出 （Export Instances）
4.53.4.1.1 きっかけ事例
送出選択と追加ティーチングファイル情報と目録とで参照された全てのインスタンスの識別情報削除と偽名化が済むと、送出管理役はこのトランザクションを開始できます。
4.53.4.1.2 通信文の意味
送出選択役は、DICOM C-STORE 通信文を使用して、インスタンスと目録を転送します。送出管理役はDICOM 保存 SCU で、受信役が DICOM 保存 SCP です。
送出管理役は一個以上の DICOM 連携で、受信役に一個以上のインスタンスと目録を転送できます。
目録と目録が参照するインスタンスの転送タイミングは規定されておらず、同一ないしは異なった連携の中で起こり、目録もこれが参照するインスタンスの前、最中、後のどのタイミングでも起こります。
目録は、キーオブジェクト選択 SOP クラス （Key Object Selection SOP Class） の一インスタンスです。
4.53.4.1.3 予期される行動
受信役はキーオブジェクト選択 SOP クラス （Key Object Selection SOP Class）を SCP として使用を可能にします。
受信役は、画像、エビデンス書類（ED）、構造化レポート、表示条件、および放射線治療オブジェクトを含む、複合保存 SOP クラスのいずれでも使用可能とします。
_______________________________________________________________________________________________________________________________________________

58
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
受信役が、送出されるインスタンスの全ての SOP クラスを使用可能としない限り、転送は部分的あるいは全面的に失敗します。
追加ティーチングファイル情報の使用が可能とする受信役は、強化 SR SOP クラスインスタンス（Enhanced SR SOP Class instances）を使用可能とせねばなりません。追加ティーチングファイル情報の受領には特定の意味は定められていません。
他のアクタと一体化されていない場合、インスタンスと目録を受け取った時の、受信役の振る舞いは、トランザクション定義の範囲を超えています。典型的には、・ ティーチングファイルの場合には、使用者による編集のために順番待ちするより前に間、目録が来るのを待つ間、この種の装置は受け取ったインスタンスを保存することがあります
・ 治験の場合には、治験業務の流れに乗るために順番待ちするより前に、目録が来るのを待つ間、この種の装置は受け取ったインスタンスを保存することがあります。
画像管理役・画像保管庫（IM/IA）と一体化された受信役の場合、受信したインスタンスは、他のプロファイ
ルで規定された様に、通常とおり使用できるようにせねばなりません。画像管理役・画像保管庫（IM/IA）で
キー画像注釈が使用可能とする場合には、目録がキー画像注釈として使用できねばなりません。
可搬媒体生成役と一体化された受信役は、媒体に参照されたインスタンスと目録を記録する前に、目録が来るまでの間、受信したインスタンスを保存できねばなりません。

4.54 画像書類セットの提供と登録（Provide and Register Imaging Document Set－廃止
4.55

WADO 取得（WADO Retrieve）

この節は IHE のテクニカルフレームワークのトランザクション RAD-55 に相当します。RAD-55 は、画像書類利用役および画像管理役・画像保管庫（IM/IA）アクタによって使用されます。

4.55.1 範囲 Scope
WADO 取得トランザクションは、画像書類利用役が HTTP/HTTPS プロトコルを介してウェブ・ベースのサービスにより、DICOM SOP インスタンスを利用することを可能にします。
4.55.2 ユースケースの役割 Use Case Roles
アクタ: 画像書類利用役（Imaging Document Consumer）
役割: DICOM インスタンスを利用するため HTTP Get Request を発行します。
アクタ: 画像書類ソース（Imaging Document Source）
役割: DICOM インスタンスを入手する HTTP Get Request を受け取り、適切な内容を持った HTTP 応答を生成します。
4.55.3 参照する規格
DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)
4.55.4 相互作用図 Interaction Diagram_______________________________________________________________________________________________________________________________________________

59
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.55.4.1 WADO 取得 Retrieve
画像書類利用役は、画像書類ソースから特定の DICOM インスタンスを要求する、「HTTP Get」を発行します。画像書類ソースは要求を受け取り、適切な内容を持った応答を生成し、画像書類利用役へ HTTP
Response を送ります。
4.55.4.1.1 きっかけ事例 Trigger Events
画像書類利用役は、DICOM 目録内で参照されている DICOM インスタンスの取得を望みます。
4.55.4.1.2 通信文意味 Message Semantics
通信文の意味は、DICOM 永続オブジェクトへのアクセス(DICOM Web Access to DICOM Persistent
Objects, WADO)、PS 3.18 によって定義されています。
WADO 取得トランザクションは、画像書類利用役が画像書類ソースのウェブサーバに HTTP Request-URIを送ることで実行されます。画像書類利用役は、DICOM インスタンスを取得するために HTTP RequestURI を生成します。DICOM インスタンスは、HTT Request-URI の中で、検査（Study）インスタンス UID、シ
リーズインスタンス UID および SOP インスタンス UID で指定されねばなりません。画像書類利用役は、このトランザクションを行なうためにウェブサーバのホスト情報（例えばウェブサーバ位置、またスクリプト言語）
を得なければなりません。画像書類利用役は SOP インスタンスの Retrieve AE タイトルを、現場施設の設定に基づいたウェブサーバのホスト情報に、対応付けることができます(付録 G を参照)。
さらに、画像書類利用役は、HTTP 要求で次のフィールドを使用可能にせなばなりません:
表 4.55-1: WADO HTTP Request フィールド
画像書類ソースは、このソースが使用可能なすべての媒体のタイプを、HTTP 要求の Accept フィールド内
で一覧にあげ、WADO HTTP パラメーターの contentType を使用して、HTTP レスポンスで取得されるオブジェクトに、希望する媒体のタイプを要求せねばなりません（表 4.55-2 を参照）。
次のテーブルに述べられているように、画像書類ソースおよび画像書類利用役は WADO HTTP RequestURI の中で多くのパラメーターを使用可能とするように要求されています。
表 4.55-2: WADO HTTP Request パラメータ
IHE-1: 画像書類利用役は、DICOM パート 10 ファイル形式での DICOM SOP インスタンスを取得するために値「application/dicom」を使用しなければなりません。これにより、画像書類利用役は、十分なデータ操作のため本来の DICOM フォーマットで SOP インスタンスを受け取れる様になります。
さらに、画像書類利用役は、JPEG Baseline フォーマットでコード化された画像が、単フレーDICOM
画像オブジェクト、あるいは、多フレーム DICOM 画像オブジェクトの中でコード化された単フレーム画像である場合に、この画像を取得するために値「application/jpeg」を使用することができます。
さらに、画像書類利用役は、テキスト形式か html フォーマットで表わされた DICOM SR オブジェク
トを取得するために、値「application/text」あるいは「application/html」を使用することができます。

_______________________________________________________________________________________________________________________________________________

60
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
さらに、画像書類利用役は、画像書類ソースで使用可能な場合、このパラメーターに DICOM
2011 PS 3.18 に指定されている他の値を、使用することができます。
このパラメーターは DICOM PS 3.18 ではオプションです。このパラメーターに値がない状態でHTTP Get 応答で取得される DICOM 永続オブジェクトの既定フォーマットは、取得されたオブジェ
クトの SOP クラスに依存して変わるため、相互運用性を改善するため、このトランザクションでは、このパラメーターが使用可能でなければなりません。
IHE-2: このパラメーターは、HTT Request-URI の「Accept」フィールドに画像書類利用役が置いた値と、互換性がなければなりません。
IHE-3: このパラメータは、DICOM SOP インスタンスが画像オブジェクトである場合にのみ当て
はまります。
4.55.4.1.2.1 WADO リクエスト-URI の例 Example of WADO Request-URI）
下記は、WADO を使用して、DICOM 永続オブジェクトを取得するための HTTP Request-URI の例です:
http://www.hospital/radiology/wado.php?requestType=WADO&studyUID=1.2.250.1.59.40211.12345678.67
8910&seriesUID=1.2.250.1.59.40211.789001276.14556172.67789&objectUID=1.2.250.1.59.40211.267881
0.87991027.899772.2&contentType=application2420 %2Fdicom
この例は、本来の DICOM パート 10 ファイル形式で返された DICOM SOP インスタンスを要求するために、
応答 MIME 形式に application/dicom を使用しています。
4.55.4.1.3 予期される動作
WADO HTTP Request の受け取りに際して、画像書類ソースはリクエストを解析するものとし、エラーがない
場合、要求された DICOM インスタンス内容で HTTP Get Response を構築し、HTTP 応答コード 200（OK）
と共に、DICOM WADO 規格によって規定されるレスポンスを返さねばなりません。
画像書類ソースがパラメーターcontentType、および・または、「Accept」フィールドに、要求された返答
MIME 形式を入れられない場合、画像書類ソースは HTTP 応答コード 406（Not Aceptable (受容可能でない)）を返すものとします。
要求された DICOM SOP インスタンスを見つけることができないか、受信された HTT Request-URI の中で指定された UID 値を認識することができない場合、画像書類ソースは HTTP 応答コード 404（NotFound (見つからなかった)）を返すものとします。
要求された HTTP フィールド、あるいは WADO HTTP パラメーターが、受信した HTTP Request-URI に見つからない場合、あるいは HTT Request-URI に他の構文エラーが検出された場合（例えば、contentType
パラメーターのメディアタイプが、「Accept」フィールドのメディアタイプと矛盾する場合）、画像書類ソースはHTTP 応答コード 400（Bad request (悪いリクエスト)）を返すものとします。

4.55.4.1.4 監査用のきっかけ事例
IHE は、IHE 監査追跡（Audit Tral、ITI TF-2a: 3.20）によって報告可能であるものとする多くの事例を定義_______________________________________________________________________________________________________________________________________________

61
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
します。IHE 放射線監査証跡オプション（Radiology Audit Tral Option）は、さらにこれらの事例の部分集合を定義します。それは放射線トランザクションに特に適用可能です。
表 4.55-3 に、トランザクション RAD-55 に適用される放射線監査証跡のきっかけ事例をすべて、挙げます。
最後の列は、トランザクションの送り手や受け手側のどちらが、事例を監査するように要求されるかを示します。
表 4.55-3: 監査記録トリガーイベント Audit Record Trigger Events

4.59 取込み検査段階進行（Import Procedure Step In Progress）
この節はIHEテクニカルフレームワークのRAD-59 トランザクションに対応します。RAD-59 は部門システム
予定役・オーダ実施役（DSS/OF）、画像管理役（IM）、実行済検査 1段階管理役（PPSM）、レポート管理役(RM)、取込み役（Importer）アクタによって使われます。
4.59.1 範囲
このトランザクションは取込み役（Importer）からPPSMへの通信文を含み、次々にDSS/OF、IM、RMへPPSが進行中であるという通信文を出します。
受信するPPSMは、IMあるいはDSS/OFと一体化され、一体化されているアクタを除いた二つの送信先アクタに向けて通信文を送らねばなりません。取込み役から対応する通信文を受けた後すぐに、設定された送信先のアクタに通信文を出し始めなければなりません。
正しく統合するには、次のことが考慮されなければなりません：
PPSMはPPSオブジェクトを維持し、対応するN-CREATEやN-SET通信文が、一体化されているアクタと二つの他のアクタに伝送されるまで、それらを保存しなければなりません。もし送信先への伝送が失敗したら、
PPSMは成功するまで周期的に伝送を繰り返さなければなりません。PPSMは、ひとつかそれ以上の伝送の失敗を、取込み役からの最初の伝送を拒否する理由として用いてはなりません。；
IMとDSS/OFの両方はPPSMの機能を組み入れるため、実行済検査段階（PPS）通信文の無限の再分配が可能です。PPSM機能を提供するIMとDSS/OFはこの機能を止めるように構成されるべきです。
受信するPPSMが統合されるシステムへの情報伝送は、IHEテクニカルフレームワークのスコープ外です。
（実装の中です）
4.59.2 使用例役割
アクタ： 部門システム予定・オーダ実施役（DSS/OF）
役割: PPSMが転送したPPS情報を受け取る。

1

訳者注： 原文は procedure だが、場合によっては「検査」や「処理」の役になる。ここでは取込みなので、「処理」の役とした。

_______________________________________________________________________________________________________________________________________________

62
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
アクタ: I画像管理役（IM）
役割: PPSMが転送したPPS情報を受け取る。
アクタ: レポート管理役(RM)
役割: PPSMが転送したPPS情報を受け取る。
アクタ: 取込み役
役割:

PPSMに、ある特定のPPSが開始されたことを伝える。

アクタ: PPSM
役割: 取込み役から、実行済検査段階の情報を受け取り、DSS/OF、IM、PPSM、RMへ転送する。
4.59.3 参照される標準
DICOM 2011 PS 3.4: Modality Performed Procedure Step SOP Class.
4.59.4 相互相互作用図
4.59.4.1 検査段階進行中の通信文
4.59.4.1.1 きっかけ事例
使用者は、取込み役からの取込み処理の段階を始めます。
4.59.4.1.2 通信文の意味
施設にエビデンスオブジェクトを輸入する取込み役は、PPSMに特定の検査段階（Procedure Step）が開始
され進行中であることを伝えるため、MPPS SOPクラス（N-CREATEサービス）を用います。次に、PPSMは情報をDSS/OF、IM、RMに転送するため、N-CREATEサービスを用います。この間、PPSMは同じPPS SOPインスタンスUIDを使わねばなりません。このステップを実装する際には、次の問題を考慮せねばなりません。
4.59.4.1.2.1 患者・検査・予定検査段階情報 Patient/Procedure/Scheduled Procedure Step Information
取込み役は 重要な患者情報は有効で正しいこと（RAD TF- 2: Appendix A.5 参照）を確保しなければなりません。加えて、検査段階の取込みが予定されたとき、検査情報を確認することも必要です。読み込まれる
エビデンスオブジェクトあるいはハードコピーが、施設にもともとなかったという事実により、正しい患者が読み込まれたデータと関連付けられているか確認する（使用者の）作業は、極めて重要です。
4.59.4.1.2.2 要求される属性
読み込まれたSOPインスタンスに含まれる情報、PPS属性、患者の基本情報、SPS情報に含まれる属性のう
ち、適応可能な属性の間での一貫性を確保するために、取込み役によって強制的に変更される多数の属
性を、RAD TF–2: Appendix A.5 に列挙しています。

_______________________________________________________________________________________________________________________________________________

63
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.59.4.1.2.3 予定検査段階、実行済検査段階と読み込んだDICOM複合オブジェクトの関係
Relationship between Scheduled and Performed Procedure Steps and the Imported DICOM
Composite Object
DICOM複合オブジェクトを読み込む（例：CDから）際には、DICOMヘッダー情報は 検査の完全性を確保するために保存されるか、ローカル施設に適合するように強制的に変更されなければなりません。スタディ
インスタンスUIDは、保持されねばならないデータ要素の一例です。
読み込まれる検査の予定と実施は、読み込む施設の外にて元々行われます。そのため、読み込まれる検査からのエビデンスオブジェクトとの関連付け（紐付け）は、簡単に表現できない関係を有することがあります。
ハードコピーをデジタル化して新たなDICOM 複合オブジェクトを作る時、元の患者や検査の詳細の一部
は手入力やOCR、設定などから得られることも、得られないこともあります。RAD TF-2: 付録 A.5 は特定の要求事項を定義しています。
取込みにおける、予定検査段階と実施済検査段階の情報の間の関係は，次の二つのケースに示されます。
その他の属性(Procedure ID, Accession Number, など)を埋める詳細については、それぞれのケースで
RAD TF-2: Appendix A.5 を参照してください。実施済検査取込みが進行中であることをシステムに知らせるために、それぞれのケースでMPPS N-Create 通信文が送られます。
4.59.4.1.2.3.1 予定された取込み
予定取込みオプション（SCHEDULED IMPORT option）では、SPS情報は装置業務一覧（Modality
Worklist, MWL）で提供されます。SPSとPPSは一対一の関係です。SPSの情報と要求検査はSPSオブジェ
クトからPPSモジュールへコピーされます（RAD TF-2: Appendix A.5）。
例：PSは予定どおり実施された。PSは再スケジュールがない状態で予定どおり正しく実施できなかった。例
えば一人の患者検査に複数の可搬型媒体が存在する場合。
4.59.4.1.2.3.2 予定外の取込み
予定外取込みオプション（UNSCHEDULED IMPORT option）の場合、取込み役は予定情報を受信しません。SPSとPPSは、ゼロ対一の関係です。患者情報は患者基本情報問合せ（Patient Demographics
Query）を通して行い、SPSや要求検査情報は利用できません。
4.59.4.1.2.3.3 取込み実施プロトコル順列 (Performed Protocol Sequence for Import)
取込み実施プロトコル順列（Performed Protocol Code Sequence (0040,0260)）は取込みMPPSに存在しなけ
ればなりません。取込みが如何に処理されるべきかの情報を提供するのに使われます（例：エビデンスオブ
ジェクトの解釈、関連するメディアの破壊）。
Performed Protocol Code Sequenceは常に(IRWF001, IHETFRAD, “Import”)の値をもつ、一項目を常に含
めねばなりません。
加えて、Scheduled Protocol Code Sequence (0040,0008)が存在するとき、操作者に変更されない限り、
Performed Protocol Code Sequence (0040,0260)にコピーされねばなりません。予定、あるいは予定外取込_______________________________________________________________________________________________________________________________________________

64
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
みの両方において、取込み役はImport Instructions (RAD TF-2:4.5-4 を参照）の追加・変更機能をもってよいです。
4.59.4.1.3 予期される動作部門システム予定・オーダ実施役（DSS/OF）、レポート管理役（RM）、画像管理役・画像保管庫（IM/IA）はPPSMから情報を受信し、予定されている場合には、要求検査とSPSにリンクせねばなりません。
如何にPPSM、部門システム予定・オーダ実施役（DSS/OF）、レポート管理役（RM）、画像管理役・画像保
管庫（IM/IA）がPerformed Protocol Sequenceの中に含まれる情報を用いるかは現在定義されていません。

4.60

取込み検査段階完了・中止（Import Procedure Step Completed/Discontinued）

この節は、IHE テクニカルフレームワーク RAD-60 トランザクションに対応します。RAD-60 トランザクション
は部門システム予約・オーダ実施役（DSS/OF）、レポート管理役（RM）と取込み役アクタに使われます。
4.60.1 範囲
このトランザクションは取込み役から実行済検査段階管理役（PPSM）への通信文を含んでおり、これを部門システム予約役・オーダ実行役(DSS/OF）、レポート管理役（RM）に転送し、データの取込みと PPS が完了したことを伝えます。
4.60.2

使用例の役割アクタ: 部門システム予約・オーダ実施役（DSS/OF）
役割: PPSMが転送したPPS情報を受けます。
アクタ: 画像管理役（Image Manager、IM）
役割: PPSMが転送したPPS情報を受けます。
アクタ: レポート管理役（Report Manager, RM）
役割: PPSMが転送したPPS情報を受けます。
アクタ: 取込み役（Importer）
役割: PPSMに、特定のPPSとデータ取込みが完了したことを、PPSMに知らせます。
アクタ: 実行済検査段階管理役（Performed Procedure Step Manager, PPSM)
役割: PPS情報を可搬媒体取込み役あるいはエビデンス生成役（EC）から受け、部門システム予定・オーダ
実施役(DSS/OF）、画像管理役（IM）、レポート管理役（RM）へ伝えます。

4.60.3 参照される標準_______________________________________________________________________________________________________________________________________________

65
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________DICOM 2011 PS 3.4: Modality Performed Procedure Step SOP Class.
DICOM 2011 PS 3.16: DCMR Context Groups (Normative)
4.60.4 相互相互作用図
注：上図はMPPS SOPクラスの通信文の流れを示します。取込み役はStorageとStorage Commitmentクラスを実装します。
PPS通信文とStorage とStorage Commitment通信文の時間的な関連とについては決めていません。即ち、PPS通信文は保存の要求が出る前や後に行われます。

4.60.4.1 検査段階完了／中断 Procedure Step Completed/Discontinued
4.60.4.1.1 きっかけ事例
ユーザは取込み役上で検査段階を完了します。
4.60.4.1.2 通信文の意味
取込み役はPPSMに特定のPPSが終了したか中断したかを伝えるMPPS SOP クラス（N-SET service）を送らなければなりません。
最終のN-SETは完了"COMPLETED"か中断"DICONTUNUED"のMPPSステータスをもちます。PSMはNSETを部門システム予定・オーダ実施役(DSS/OF）、画像管理役（IM）やレポート管理役（RM）に転送します。
エビデンスオブジェクトが生成され送られたなら、"DICONTUNUED"ステータスでN-SETが発行されるとき、一つかそれ以上のインスタンスのシリーズが参照されます。
注：DICOMは、属性がN-SETによる設定が許可されるとき、以前のN-CREATEかN-SETによって送られたどんな値も、最終（最新）のN-SETによって提供された値で書き換えることを規定しています。

4.60.4.1.2.1AE タイトルの取得
DICOM標準に従って、取込み役はPerformed Series Sequence (0040,0340)にRetrieve AE Title 属性(0008,0054)を含むことができます。シリーズに対して参照されたSOPインスタンスが取得できる部署のAEタ
イトルです。このRetrieve AE Titleは以下の状況で、ゼロ長か短期間のみ有効であることになります。
・もし、取込み役がSCPの役割としてRetrieve SOPクラスが実行可能なら、取込み役のRetrieve AE
Titleは含まれます；しかしながら、取込み役は長期間の利用については保証しません。
・画像管理役（IM）のRetrieve AE Titleは取込み役で設定できます。でなければこのフィールドではゼロ長を送らなければなりません。取込み役の実装者は、Storage SCP あるいはStorage
Commitment SCPで使われる相手先のAEタイトルと、画像取得で使われるものとが、同じであると仮定してはなりません。
・取込み役はStorage Commitment 通信文 (N- EVENT REPORT)でRetrieve AE Titleを受信する
かもしれません。しかし、この情報はMPPS N- SET （Complete）が実施されたかなり後に、取得されます。

_______________________________________________________________________________________________________________________________________________

66
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.60.4.1.2.2 PPS取込み例外管理 Import PPS Exception Management
MPPSが"DICONTUNUED"のステータスで送られたとき、検査中断理由コード順列（Procedure Step
Discontinuation Reason Code Sequence (0040,0281)） は、DICOM 2011 PS 3.16 Annex B Context ID 9300
あるいは 表 4.60-1 (DICOMで追加されたプロセスの中での追加コード)で定義された値で送られなければなりません。
表 4.60-1 状況ID 9300 - 検査中断理由抜粋 もっとも限定的な利用：定義
Context ID 9300 – Procedure Discintinuation Reasins Excxerpt Most Restrictive Use: Defined部門システム予定・オーダ実施役(DSS/OF）と画像管理役・画像保管庫（IM/IA）と情報をやりとりするとき、
理由コードはオーダのキャンセルも暗示しています。これは、より正確な会計を行うのに役立ちます。
「業務一覧内項目の誤選択（Incorrecet Worklist Entiry Selected）」という理由コードは、誤った患者基本情報（あるいは・または）SPSが選ばれた（同じ患者に、正しくない患者か要求検査（またはオーダ）が選ばれた）ことを伝えるのに、取込み役が使います。この場合、誤って読み込まれたエビデンスオブジェクト（誤った患者に割り付けられたデータ）は、一部あるいは全部が、すでに画像管理役（IM）に保存されてしまっているかもしれません。
誤選択結果のエビデンスオブジェクトをどう修正するかの決定が、取込み役の実装者の自由にまかされています。取込み役はMPPSのなかに、Import Storedトランザクションに含まれているか将来含まれる取込み
オブジェクトのリストを含まねばりません。
注：PPS DISCONTINUEDが"incorrect worklist entry selected"という理由コードで送られるとき、PPS DISCONTINUEDで参照されるエビデンスオブジェクトは、画像管理役・画像保管庫（IM/IA）にすでに送られたエビデンスオブジェクトであるかもしれません。IHEテクニカルフレームワークは、これらのインスタンスに対して取込みアクタがStorage Commitmentを実行するかどうかは規定しま せん。

中断理由コード“Equipment Failure”、 “Objects incorrectly formatted”、“Object Types not Supported”、“Object Set incomplete” および “Media Failure”は、期待されるエビデンスオブジェクトが読み込まれたことを示すのに使われることになります。
4.60.4.1.2.3 会計と物品管理オプション（Billing and Material Management Option）
通信文の意味は、DICOM MPPS SOPクラスのDICOMサービスクラスの節に定義されています。患者と検査の情報が部門システム予定・オーダ実施役(DSS/OF）に送られることを確認するのは取込み役の責任です。
表 4.60-2 に定義された属性は、会計処理役（Charge Processor） アクタへ通知する会計の計算に用いる物
品管理コードを、取込み役からDSS/OFへ伝える手段になります。
会計と物品管理オプション（BILLING AND MATERIAL MANAGEMENT）を使用可能とする取込み役は、
会計処理段階順列（Billing Procedure Step Sequence）と物品機器会計順列（Billing Supplies and Devices
Sequence）内に、内容を提供できなければなりません。会計処理段階（Billing Procedure Step）が利用されている場合、取込み役上に取込み会計コード表（Import Billing Code Table）が設定されねばなりません。このテーブルは、部門システム予定・オーダ実施役(DSS/OF）に同期しなければなりません。取込み役によっ_______________________________________________________________________________________________________________________________________________

67
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________て提供されるコードは、会計処理役（Charge Processor） に通知するときに部門システム予定・オーダ実施
役(DSS/OF）が使うように要求されているコードとは、同じではないかもしれません。
会計項目順列（Billing Item Sequence）は読み込まれた媒体の数を追跡する仕組みを提供します。CDや放射線のフィルムをデジタル化するなどの取込みの対象に関連する会計があるとき、会計項目順列で指定されるコード値のリストは表 4.60.3 を参照してください。複数のコードが存在します。
表 4.60-2: 会計と物品管理コードモジュール抜粋
4.60.4.1.3 予期される動作
画像管理役（IM）、レポート管理役（RM）と部門システム予定・オーダ実施役(DSS/OF）はPPSが完了か中断されようとしているかの情報を受信します。画像管理役（IM）、レポート管理役（RM）と部門システム予定・
オーダ実施役(DSS/OF）はMPPSステータスが"IN PRORESS"状態で中間のN-SET通信文に反応する必要はありません。
予定取込みの場合、全てのSPSに関連するPPSが完了するか正しく中断したとき、要求検査は、完了したとみなされます。
4.60.4.1.3.1 取込みPPS例外管理 Import PPS Exception Management
取込みの例外が起きた時、部門システム予定・オーダ実施役(DSS/OF）か画像管理役・画像保管庫（IM/IA）は、"DISCONTINUED"のステータスで送信される最終的なN-SETに、理由コードを使用しなければなりません。
MPPSが"DISCONTINUED"のステータスで受信されたとき、受信者はPPS Discontinuation Reason Code
Sequence (0040,0281)）の値を、DICOMで規定されている様に（4.60.1.1.2.2 参照）、解釈しなければなりません。部門システム予定・オーダ実施役(DSS/OF）と画像管理役・画像保管庫（IM/IA）が受信したとき、中断理由コードはオーダの変更やキャンセルの必要を示すことがあります。中断コード“Incorrect Worklist
Entry Selected”では、取込みアクタは、誤ったSPSか患者かが選択されてしまったこと（例えば、同じ患者に対して、違う患者、あるいは間違った要求検査）を伝えます。この場合、画像管理役（IM）と部門システム予定・オーダ実施役(DSS/OF）は、既に受信した間違ったインスタンス（例えば、中断PPSに参照されている
SOPインスタンス）が使われないよう確認する適切な動作をしなければなりません。もし、画像、表示状態、あるいはキー画像注釈が実際に削除されないのであれば、画像管理役（IM）は以下のことを実施しなければなりません。：
・問合せ応答に、画像に対するSOPインスタンスUIDを返さない
・患者、検査、シリーズの画像やインスタンスレベルの取得に応答しない
部門システム予定・オーダ実施役(DSS/OF）と画像管理役（IM）上では、オーダ／要求検査ステータスは中断されたPPS（誤ったワークリストが選ばれた場合）は有効ではないことがわかるように修正されなければなりません。それゆえ、部門システム予定・オーダ実施役(DSS/OF）は、画像可用性（Image Availability
Notification ）トランザクション [RAD-49]で、これらのインスタンスを問い合わせてはなりません。

_______________________________________________________________________________________________________________________________________________

68
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________MPPSが"DISCONTINUED"ステータスで受信されたとき、リスト（表 4.60-1 参照）から選ばれた中断理由
コードを含まなくてはなりません。中断コードはエビデンスオブジェクトの全体が取込みれなかったことを示します。典型的にはいくつかのDICOM複合オブジェクトが取込み側施設で使用可能でないからです。取込み施設がいかにこの状況に対応するかは現場施設の方針次第であり、このテクニカルフレームワークの範囲外です。
4.60.4.1.3.2 会計と物品管理オプション
部門システム予定・オーダ実施役(DSS/OF）でBILLING AND MATERIAL MANAGEMENTオプションが使用可能なとき、部門システム予定・オーダ実施役(DSS/OF）は、会計処理役（Charge Processor）に通知される会計計算のための最終のN-SETで提供される、会計コードと（または）物品使用情報を使用しなければなりません。提供された会計コードと、同じN-SETで提供された要求プロシージャコードやPPSプロトコル
コードとの、整合性を部門システム予定・オーダ実施役(DSS/OF）が確認することが推奨されます。

4.61 取込みオブジェクト保存済み （Imported Objects Stored）
この節は、IHEテクニカルフレームワークのトランザクションRAD-61 に対応しています。トランザクション
RAD-61 は画像保管庫（IA）と取込み役アクタによって使われます。
4.61.1 範囲
取込みオブジェクト保存済み（Imported Objects Stored）トランザクションでは、取込み役はエビデンスオブ
ジェクトを画像保管庫（IA）に送ります。撮影装置業務一覧（Modality Worklist）トランザクション（RAD TF-2:
4.5 参照）、または、患者基本情報問合せ（Patient Demographics Query） （ITI TF-2a:4.21 参照）からの整合された情報は、生成された画像のヘッダーに含まれねばなりません。
4.61.2 使用例の役割
アクタ: 画像保管庫（Image Archive, IA）
役割: 可搬媒体取込み役（Portable Media importor）から複合DICOMオブジェクトを受け、保存します
アクタ: 取込み役（Importer）
役割: 読み込まれたDICOMオブジェクトを画像保管庫（IA）に伝送する。
4.61.3 参照される標準
DICOM 2011 PS 3.4: Storage Service Class, Section B.4.1 Conformance as an SCPDICOM 2011 PS 3.3 SOP Information Objects, Common Module Attribute
4.61.4 相互作用図

4.61.4.1 エビデンスオブジェクト保存済 （Evidence Objects Stored）_______________________________________________________________________________________________________________________________________________

69
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.61.4.1.1 きっかけ事例
エビデンスオブジェクトが使用可能に、あるいは、まとまって利用できるようになるので、取込み役はエビデンスオブジェクトを画像保管庫（IA）に、一つかそれ以上のDICOM連携の中で、連続的に伝送することができます。
4.61.4.1.1.1 UID
有効なDICOM UIDは、世界的に一意で、現場施設のUIDとぶつかるリスクがあってはなりません。DICOMUIDの有効なセットが存在するとき、取込み役はこのセットを用い、変えてはなりません。もし取込み役が正しくないUID、あるいは整合しないUIDのセットを検出したら、取込み役は修正するかUIDを再度生成してもかまいません。UIDはオブジェクト間での参照に使われますが、もしそれらが変えられたら、取込み役は参照の完全性を維持しなければなりません。取込み役があらたな検査・シリーズ・画像インスタンスの生成をいつ引き起こすのが適当かについての追加の詳細は RAD TF-2: 4.8.4.1.1.1 “Study UIDs and Series
UIDs”に記述されています。
4.61.4.1.2 通信文の意味
取込み役はDICOM 複合オブジェクトを転送するためにDICOM C-STORE通信文を用います。取込み役がDICOM Storage SCUで、IAはDICOM Storage SCPとなります。
取込みが予定されていたとき、使用者は患者の利用できる情報とSPS/要求検査を確認し、患者／オーダ
情報に必要とされる変更を強制します（RAD TF-2: 付録 A.5 を参照してください）。
もし、取込みが予定されていなかったら、使用者は、患者の利用できる情報を確認し、患者情報に必要とされる変更を強制します。(RAD TF-2: Appendix A.5 を参照してください)
ある種の情報は画像ヘッダーに記録されることが要求事項です。DICOMインスタンスの対応付けの詳細についてはRAD TF-2: Appendix A.5 に規定されています。
DICOM規格により、取込み役は生成された画像に対して新たなシリーズ（例えば、フィルムのデジタイズ）を作成しなければなりません、またソース画像を含むシリーズを拡張してはなりません。
4.61.4.1.2.1 オリジナル属性順列 （Original Attributes Sequence）
元のエビデンスオブジェクトから強制的に変更する（例えば、属性を差し替えるか削除する）ときには、取込
み役はオリジナル属性順列（Original Attributes Sequence） （表 4.61.4.1.2-1 を参照）を、最上位に生成す
るか追加し、DICOM要素の元の値をその下に、RAD TF-2: 付録 A.5.に定義されたように、保存しなければなりません。
取込み役は元のデジタイズされていないデータ（例えば、元の施設、取込み時間、元の施設からの特定の属性）についての情報を保持するためオリジナル属性順列（Original Attributes Sequence）を用いねばなりません。保持される仕組みと値は本テクニカルフレームワークの範囲外です。
表 4.61.4.1.2-1: オリジナル属性順列（Original Attributes Sequence）
注 1： DICOMオブジェクトが読み込まれるたびに、新しいオリジナル属性順列が追加されます。

_______________________________________________________________________________________________________________________________________________

70
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
注 2： デジタイズされたハードコピーでは、「古い値」は操作者が用手入力した情報でしょう。この場合には一個の順列のみがあると期待されます。

4.61.4.1.2.2 関与装置順列 （Contributing Equipment Sequence）
これらのエビデンスオブジェクトが施設に読み込まれた事実を保存するため、関与装置順列（Contributing
Equipment Sequence (Table 4.61.4.1.2-2)）を使わねばなりません。現場施設が、エビデンスオブジェクトセッ
トを読み込んだとの事実に基づいて様々な決定ができる様にします（即ち、取込みに基づいた再読影の予定、一定時間経過後の取込みエビデンスオブジェクトの削除など）。読み込んだエビデンスオブジェクトが如何に利用され、維持されるかについての振る舞いは、このテクニカルフレームワークの範囲外です。
表 4.61.4.1.2-2: 関与装置順列（Contributing Equipment Sequence）
注 1: 取込み済みのオブジェクトでは、 DICOMオブジェクトが読み込まれるたびに新しい項目が関与装置順列（Contributing Equipment Sequence）に追加されねばなりません。関与装置順列の個々の項目は個々の取込み装置です。装置モジュール属性はインスタンスの元の生成役を記載します。
注 2： デジタイズされたハードコピーでは、元のデータ取得装置を記載する一個の項目を関与装置順列（Contributing Equipment Sequence）に含まねばなりません。デジタイザーはオリジナルのDICOMインスタン
スを生成する装置ですので、装置モジュール属性はハードコピーデジタイザを記載します。
次のテーブルは取込みを行った機器を記述するために使う情報です。この情報は後で施設に読み込まれたデータに特異な処理をするときに利用されることがあります。
表 4.61.4.1.2-3: 状況ID 7005 – 関与機器 もっとも制限された使用：定義
Context ID 7005 - Cornotibutiong Equipment Most Restiricetd Use: Defined

4.61.4.1.3 予期される動作
画像保管庫（IA）は受信したDICOM オブジェクトを保存します。
DICOM画像、エビデンス書類（ED）と診断レポートは、後にDICOM Level 2 Storage SCP （DICOM PS 3.4
B.4.1 を参照）に対して定義された規格に適合する形で取得できるように、保存されなければなりません。
(RAD TF- 2:4.16, RAD TF-2:4.17, RAD TF-2:4.27 と RAD TF-2:4.3 を参照)
4.61.4.1.3.1 DICOM保存SOPクラス （DICOM Storage SOP Classes）
4.61.4.1.3.1 DICOM保存SOPクラス
DICOM規格は、DICOM SRや包含化されたPDFなどの他のDICOM SOPクラスと同様に、画像に特定した
storage SOPクラスを規定しています。全ての標準的な属性と私的なデータ要素は保存されなければなりま
せん。
製品のDICOM適合性宣言は、製品がどのDICOM Storage SOPクラスが使用可能かを宣言します。
C−Storeの連携では、使用可能でないSOPクラスは画像管理役・画像保管庫（IM/IA）によって拒否されね_______________________________________________________________________________________________________________________________________________

71
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
ばなりません。取込み役からのDICOMオブジェクトが保存できない状況を施設でどのように扱うかはテクニ
カルフレームワークの範囲外です。

4.62

線量情報の保存 （Store Dose Information）

この節は、IHE テクニカルフレームワークの RAD-62 に対応します。RAD-62 は撮影装置、画像管理役・画像保管庫（IM/IA）、線量情報利用役、線量情報消費役で使われます。
4.62.1 範囲
この節では照射の詳細を示す線量オブジェクトを含む DICOM 構造化レポートオブジェクト（SR オブジェクト）の、DICOM 保存要求を記述します。撮影装置は線量オブジェクトを画像管理役・画像保管庫（IM/IA）に送り、患者被曝の監視や解析に利用します。
4.62.2 ユースケース役割
アクタ：撮影装置
役割： 撮影装置による照射事例を記述します。線量オブジェクトを生成し、ひとつ以上の受信アクタに保存します。
アクタ：画像管理役・画像保管庫（IM/IA）
役割： 線量オブジェクトを撮影装置から受け取り保存します。
アクタ： 線量情報利用役
役割： 線量オブジェクトを撮影装置から受け取り処理します。
アクタ： 線量情報報告役
役割： 線量オブジェクトを撮影装置から受けとります。
4.62.3 参照する標準DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD
DICOM 2011 PS 3.4: Storage Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes
DICOM 2011 PS 3.16: X-Ray Radiation Dose SR IOD Templates
2855 DICOM 2011 PS 3.16: CT Radiation Dose SR IOD Templates
DICOM 2011 PS 3.17: Annex AA: Radiation Dose Reporting Use Cases
4.62.4 関係図（図）
注： 上図では、線量情報消費役と線量情報レポート役は C-STORE 通信文も受けます。

4.62.4.1 線量情報保存
撮影装置はＸ線照射線量 SR 保存 SOP クラスの SCU として実装せねばなりません。画像管理役・画像保
管庫（IM/IA）、線量情報報告役、線量情報利用役は線量保存 SOP クラスの SCP として実装せねばなりません。
表 4.62-1 線量保存 SOP クラス_______________________________________________________________________________________________________________________________________________

72
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.62.4.1.1 きっかけ事例
被曝イベントは 1 回の連続した放射線の照射です。パルス照射、線量変調、2 重線源などを含む、被曝の詳細な定義は DICOM 2011 PS 3.16 を参照してください。
撮影装置は被曝イベントのそれぞれの重要な詳細を記録せねばなりません。この詳細は、以下のように線量オブジェクトに含まれます。
被曝イベントが生じた検査段階の完了や中断に際して、撮影装置はすべての被曝イベントを含む適切な線量オブジェクトを構成し、設定された先に送信します。
注： 線量オブジェクトは DICOM インスタンスで、検査段階の状況に従い生成され、対応する MPPS でインスタンスの一覧に載ることが期待されます。

検査段階の完了や中断に際して線量オブジェクトを生成することに加え、被曝イベントの完了に際して、撮影装置は線量オブジェクトを生成し送信することができます。このような振る舞いが可能な場合には、このア
クタは、これを無効とする設定方法も提供せねばなりません。このようなオブジェクトは、検査中にワークス
テーションにより、線量分布図作成の様なアプリケーションの使用を可能にできます。被曝イベントは検査段階の線量オブジェクトで二重に報告されますが、両方の線量オブジェクトが同じ被曝イベント UD を持つ
ため、受信システムで容易に検出できます。
検査段階の完了や中断に際して線量オブジェクトを生成することに加え、撮影装置は検査全体やシリーズをまとめた線量オブジェクトを構成し、送信することができます。このようなオブジェクトは数個の検査のまとめを必要とするシステムに好まれます。このような振る舞いが可能な場合には、このアクタは、これを無効とする設定方法も提供せねばなりません。被曝イベントは検査段階の線量オブジェクトで二重に報告されますが、両方の線量オブジェクトが同じ被曝イベント UD を持つため、受信システムで容易に検出できます。
撮影装置がこのようなオブジェクトを作製するときは、先のレポートに Predecessor Documents
Sequence(0040,A360)を記録するのが適切です。
撮影装置は、DICOM 適合宣言の中で、被曝イベントの群をまとめて線量オブジェクトにする能力について明白にせねばなりまん。
4.62.4.1.1.1 デジタル化
自施設現場施設で生成され線量オブジェクトが生成されないフィルムをデジタル化するシステムの場合は、デジタル画像とともに、線量オブジェクトを生成し保存するのは適切です。デジタル化システムは手動入力
でレポートを作製することもあります。隣接システムは、生成された画像や、フィルムを使う撮影装置のMPPS の情報を使って線量レポートを生成することもあります。
外部施設の過去画像のデジタル化は別に処理されねばなりません。オリジナル画像の作製施設が、オリジナルの線量記録の責任を持ちます。デジタル化システムは、施設外画像をデジタル化しても、線量オブジェクトを生成しないように制御、あるいは、設定可能でなければなりません。
4.62.4.1.2 通信文の意味
撮影装置は DICOM C-STORE で DICOM SR オブジェクトを送信せねばなりません。これはその装置で照射した記録です。
_______________________________________________________________________________________________________________________________________________

73
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
撮影装置は線量オブジェクトを複数の宛先に送れねばなりません。基本の送信先は画像管理役・画像保
管庫（IM/IA）ですが、線量情報報告役や線量情報利用役も送付先とできます。これにより画像管理役・画像保管庫（IM/IA）への頻回のポーリングを避けられます。
撮影装置は（モバイルやネットワーク障害、送信先のダウンなど）間欠的な接続であっても線量オブジェクトを配信する責任があります。
X 線の線量 SR オブジェクトの内容は通常、TID 10001 "Projection X-ray Radiation Dose"か TID 10011"CT Radiation Dose"の雛型に基づきますが、これらは拡張可能で、追加の雛型の使用は禁止されていません。
注： DICOM は雛形の最初の導入以来、数回拡張しており、将来のさらなる増強の可能性もあります。このような変化を監視し、実装を常に最新にしておくのは、実装者の責任であることを想起してください。

CT 型撮影装置の被曝イベントを報告する撮影装置は、TID 10011 に従う線量 SR オブジェクトを生成でき
ねばなりません。
XR, XA, RF, MG, CR, DX 型撮影装置の被曝イベントを報告する撮影装置は、TID 10001 に従う線量 SR
オブジェクトを生成できねばなりません。
受信システムは、雛形の被曝イベント UID で重複を検知できる様になります。たとえば、おなじ被曝イベン
トが、手技の SR 要約と全体検査の要約の両方に現れます。
以下の属性はタイプ 2 か 3 です。必須でなくても、撮影装置が属性に値を入れないと、線量オブジェクトの処理と解析が困難になります。線量オブジェクトに値がある場合には、属性値は表 4.62-2 の記述のように書き込まねばなりません。
表 4.62-2: 線量状況属性 Dose Context Attributes
群化検査症例の撮影（RAD TF-2: 4.6.4.1.2.3 を参照）では一個の実行済み撮影段階にあわせて、一個の線量オブジェクトが生成され、画像セットから属性値を取得せねばなりません。検査タイプは、撮影の組合せに対応します。線量の部分セットに擬似的な副次検査を割り当てる必要はありません。撮影装置がグループ症例の各撮影の線量オブジェクトを繰り返すなら適切な一意の書類順序を定めるべきです。いずれにせよ、DIR は被曝イベント UID によって重複を認識できます。
もし、線量オブジェクトが実際に照射した装置で作製されたなら、レポートを生成する装置は、関与装置順
列（Contributing Equipment Sequence (0018,A001)）内に、自身を参照すべきで、強化汎用装置モジュール（Enhanced General Equipment Module） (DICOM 2011 PS 3.3: C.7.5.3)内の 4 つのタイプ 1 の属性に照射装置を参照せねばなりません。
撮影装置は患者とファントム・校正スキャンの線量オブジェクトの両方を作製できねばなりません。
4.62.4.1.2.1 線量オブジェクトと画像オブジェクトの相互参照
RAD TF-2: 4.8.4.1.2.4 では、撮影装置が関連する画像インスタンスに Irradiation Event UID (0008,3010)を記録するのは必須としています。

_______________________________________________________________________________________________________________________________________________

74
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
Projection X-Ray Dose Template 雛形（TID 10003）は、被曝イベントで作製された画像インスタンスのAcquired Images 構成成分に UID 参照を記録するのが必須です。CT Dose Template は画像への参照を含みません。画像管理役（IM）に送られたインスタンスは、被曝のしばらく後に作製されるためです。
線量オブジェクトに画像オブジェクトがない場合があることに注意してください。たとえば、不良画像は保存されませんし、透視では画像は取得されないことがあります。

4.62.4.1.3 予期される動作
画像管理役・画像保管庫（IM/IA）はタイプ 2 の保存を可能とせねばなりません。これにより、DICOM のタ
イプ 1, 2, 3 の（公的、私的）属性が保存されます。線量オブジェクトを受け、保存し、検索・取得を可能にできねばなりません。
線量情報報告役と線量情報利用役は線量オブジェクトを受け取らねばなりません。線量オブジェクトは機能や設定、線量情報報告役と線量情報利用役の生成物の運営方針に応じて処理されねばなりません。可能性として、表示、処理、解析、印刷、取出しなどが考えられます。最低でも線量情報報告役は線量データの表示と集計ができなければなりません。
線量情報報告役は TID 10001 と TID 10011 の処理ができなければなりません。
複数の線量オブジェクトを受け取ったとき、同じ被曝イベント（被曝イベント UID (Irradiation Event UID)で認識）が、複数の線量レポートに参照されることがあります。処理や報告書の作成時にこのような重複被曝イベントを認識するのは受け取り側の責任です。

4.63 線量情報提出 （Submit Dose Information）
この章は IHE の RAD-63 の通信と対応します。RAD-63 は線量情報報告役と線量登録所で使われます。
4.63.1 範囲
この章は、詳細な被曝イベントの DICOM 構造化レポートオブジェクト（DICOM SR object）の secure FTP
通信を記述します。線量情報報告役は線量オブジェクトを線量登録所に、個人や集団の放射線被曝と臨床の編集、監視、分析のために、被曝情報を送ります。線量オブジェクトは集団への適応例では、送信前に、しばしば匿名化されます。
4.63.2 使用例

アクタ： 線量情報報告役
役割： 撮影装置が実行した被曝の線量オブジェクトを（匿名化して）送る
アクタ： 線量登録所
役割： 線量情報報告役からの線量オブジェクトを受け保存します。
4.63.3 参照する標準DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD_______________________________________________________________________________________________________________________________________________

75
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________DICOM 2011 PS 3.10: Media Storage and File Format
DICOM 2011 PS 3.16: X-Ray Radiation Dose SR IOD Templates
DICOM 2011 PS 3.16: CT Radiation Dose SR IOD Templates
IETF RFC-4217 Securing FTP with TLS
4.63.4 相互作用図
図4.63.4.1 線量情報送信
4.63.4.1.1 きっかけ事例
線量情報報告役は、前回の送信以降積み上げられた線量オブジェクトを、周期的に送信できねばなりません。
線量情報報告役は、設定可能な間隔で、手動で、もしくは両方で送信できねばなりません。
定期的な送信を行うか、頻度はどうするか、最初に匿名化するか、どの線量オブジェクト（たとえば、無作為抽出のサンプル、あるいは、特定の種別の検査のみを送る、など）を送信するか、は現場施設の方針と好みできまります。
4.63.4.1.2 通信文の意味
匿名化を除き、線量情報報告役が送信する線量オブジェクトは、通常、線量情報保存あるいは線量情報取得トランザクションにより受信したレポートの複製です。
線量情報報告役は表 4.62-2 の線量状況属性（Dose Context Attributes）にある RAD-62 に記述された属性が書き込まれている（すなわち、空白でなく、ゼロでなく、その他のダミー値でない）のを確認します。QCのための操作者による手入力が必要であっても、行います。
画像処理や手作業にて計測することがあるので、体の大きさの評価のため位置決め画像も登録するのを奨励します。それぞれの線量登録所はこれを必須とするかもしれないので、情報報告役は、CT 画像とImage Type (0008,0008) value 3 of LOCALIZER を受け取りレポートに含める機能を持つこともあります。
線量情報報告役は、IETF RFC-4217 “Securing FTP with TLS”に規定されたクライアントとして secure FTP
session を開始せねばなりません。
FTP session を開始したら、線量情報報告役は、
1. ファイアウォールに害のない接続法を使用せねばなりません
2. 他の FTP コマンドに先だって、まず TLS で接続折衝（negotiation）せねばなりません。
3. "Private"の秘匿レベルを要求せねばなりません（すなわち、Private のレベルで接続折衝できないなら、接続は失敗にせねばなりません）。
4. AES を可能とせねばなりませんが、TLS の一部として他の代替の暗号化が動的接続折衝することは容認できます。
5. 証明書による認証を使用可能とし受け入れねばならず、ユーザ認証は不要にせねばなりません。

_______________________________________________________________________________________________________________________________________________

76
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
6. X.509 に基づく証明書を使用可能とせねばなりません。
7. TLS が失敗したら切断せねばなりません。
注： 線量情報報告役と線量登録所による証明書管理は REM プロファイルの範囲外です。線量登録所は公共証明書を自身のウエッブサーバ上で使用可能にすると便利です。線量情報報告役を持つ病院は、線量登録プロジェクトに参加するとき、線量登録所の管理者に送付可能な e メール内で公共証明書のファイルが手に入る様にすることができ
ま す 。 証 明 書 管 理 の 詳 細 は 、 NEMA Security and Privacy Committee が 開 発 し た 、 "Management of Machine
Authentication Certificates"白書を参照してください。これは、NEMA のウエッブページ、www.medicalimaging.crg/wpcontent/uploads/2011/02/CertificateManagement-2007-05-Published.pdf で手に入ります。

線量登録所は secure FTP セッションを、上記の様に、受け入れ可能でなければなりません。
線量登録所は、USER ログイン（パスワードなし）で、あるいは、匿名 USER ログインの PASS で記述的文字列を提供して、線量情報報告役が自身を特定することを（監査の目的で）要求することがあります。線量情報報告役はこのような詳細を設定可能でなければなりません。
線量情報報告役は FTP を使って、Explicit VR Little Endian の転送構文で、DICOM Part10 メディアファイ
ルとしてフォーマットされ、DICOM SR にコード化した線量オブジェクトを送らねばなりません。
線量オブジェクトは以下のいずれかで送信されます。
・個別ファイル・DICOM 2011 PS 3.12 Annex V に記述された ZIP ファイルメディア
DICOM Zip File Media は有効な DICOMDIR が必要です。
線量情報報告役は複数の設定された送り先に線量オブジェクトを送れねばなりません。
線量情報報告役は間欠的な接続（ネットワーク障害、送付先システムの不調など）であっても線量オブジェ
クトを配信する責任があります。
4.63.4.1.2.1 識別情報削除 De-identification
線量情報報告役は線量オブジェクトを送信する前に識別情報削除できねばなりません。
どの属性を消すかは目的により様々です。RAD TF-3: 付録 I と DICOM 2011 PS 3.15 Annex E を参照してください。
したがって、このトランザクションは、文字情報の全てや私的属性値の全てを削除することを求めていません。
線量情報報告役は、削除あるいは置き換える属性を設定する方法を提供してもよいです。最低でも線量情報報告役は DICOM 2011 PS 3.15 の基本アプリケーションレベル秘匿性プロファイル（Basic Application
Level Confidentiality Profile） に列挙された全ての属性の消去や変更の設定を保証せねばなりません。以下の使用を設定できねばなりません。
・生涯記録の保持オプション
・患者特性の保持オプション
・装置情報の保持オプション
・UID の保持オプション_______________________________________________________________________________________________________________________________________________

77
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
これらが設定可能であることは重要です。患者の性や近似的な年齢と体重、撮影された解剖学的部位、検査のタイプは、典型的には集団線量解析の一部で、これらの情報を送信するデータから削除しないで手つかずで置く能力無しでは、解析は成し得ません。患者誕生日（Patient Birth Date (0010,0030)）が除かれた
ら、適切な患者年齢（Patient Age (0010,1010)）が含まれねばなりません。
識別情報削除後、線量情報報告役は DICOM データセットのそれぞれのインスタンスに、YES をいれた患
者識別情報削除済（Patient Identity Removed (0012,0062)）属性を加えます。さらに、識別情報削除法（Deidentification Method (0012,0063)） か、識別情報削除法コード順列（De-identification Method Code
Sequence (0012,0064)）か、に値を追加せねばなりません。
線量情報報告役は識別情報削除しない設定も可能であらねばなりません。
ある想定業務手順では、（必要な同意やプライバシー協定が必要ですが）特定患者の生涯記録研究など、
識別情報削除しないほうが好ましい場合もありえます。このような場合、もし患者識別除法削除済（Patient
Identity Removed (0012,0062)）属性があれば、データ送信前に変更してはなりません。もしなければ、NOの値を入れて加えるべきです。
線量情報報告役は、送り先のそれぞれに異なった患者識別除の設定を行えねばなりません。
識別情報削除の場合によっては、UID を変更しなければなりません。このトランザクションでは線量情報報
告役は UID を変更する機能は不要ですが、もし UID が変更されたら、送信するデータセット内、および、
経過中の複数送信の間での、内部整合が保持されねばなりません。以下のルールで整合性を取らねばらなりません。
・集合内では同じエンティティの全ての複合インスタンスは同じ UID を使う。もし、Study Instance UID が変更されたら同じ検査に属する全ての線量オブジェクトの値は全て同じにします。
・集合内の別のインスタンスやエンティティへの UID による参照は、更新します。たとえば 、 以 前 の書類、参照画像と元画像の SOP インスタンス UID への参照です。
・集合内にない他のインスタンスやエンティティへの UID による参照は削除するか、一貫性のある、良くできた、ダミー参照に変更せねばなりません。
もし、同じインスタンスが様々機会に複数回取り出されるなら、識別情報や UID はそれぞれの機会毎に同じ値に置き換えねばなりません。つまりこのトランザクションには、識別情報や UID の決定論的な置換が必要です。これにより、受けとる線量登録所が重複した線量を合算せずに済みます。もっとも安全な方法はUID を置換しないことですが、施設方針が許さないかもしれません。
識別情報削除を行う線量情報報告役は不適切な IOD を生成してはなりません。特に、・必須や条件付の属性は削除せず、置換せねばなりません。
・タイプ 1 属性には値を入れねばなりません。
・タイプ 2 属性は 0 長にコード化できますが、特に、患者名、患者 ID、検査 ID、アクセッション番号のような、ブラウザでよく使われる、属性には値を入れることを推奨します。
・UID は有効な根元値（root value）を持ち、世界で一意でなくてはなりません。

_______________________________________________________________________________________________________________________________________________

78
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
線量情報報告役は線量オブジェクトの偽名化機能を持つ必要はありません。偽名化については RAD TF3: 4.51.4.1.4 を参照してください。
4.63.4.1.3 予期される動作
線量登録所は受付けた線量オブジェクトを受け入れねばなりません。線量オブジェクトをどう扱うかは機能や設定、製品の動作方針によります。線量登録プロジェクトについては RAD TF-1: 付録 I – Deployment
of Dose Registries に記載があります。
線量情報報告役は、重複や欠損を避けるため、どの線量オブジェクトが送信されたかを把握しているかもしれませんが、線量登録所は全ての線量オブジェクトが送信されたと頼りにできませんし、二重登録をチエックする用意をせねばなりません。（被曝イベント UID を確認しますが、今回のあるいは以前の登録時の識
別情報削除に影響されます。特に、同じ情報が異なる報告役から複数回送られて来るような場合には影響されます。）

4.64 線量情報問合せ （Query Dose Information）
この章は IHE Technical Framework の RAD-64 に対応します。RAD-64 は線量情報報告役、線量情報利
用役、画像管理役（IM）で使われます。
4.64.1 範囲
線量情報報告役や線量情報利用役は画像管理役（IM）から特定のフィルターで絞り込まれたメタデータを要求し、受け取ります。
4.64.2 使用例役割
アクタ：線量情報報告役
役割：線量オブジェクトのリストを（通常はこれを受け取るために）検索します。
アクタ：線量情報利用役
役割：線量オブジェクトのリストを（通常はこれを受け取るために）検索します。
アクタ：画像管理役（IM）
役割：線量情報報告役や線量情報利用役からの特定のフィルターで絞りこんだ検索に応ずる
4.64.3 参照する標準DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes
DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD
4.64.4 相互作用図
注： 上図で、線量情報消費役は C-FIND 通信文も受信し、応答せねばなりません。

4.64.4.1 線量情報検索
検索 SOP クラスに対応します。詳細は DICOM 2011 PS 3.4 参照してください。

_______________________________________________________________________________________________________________________________________________

79
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.64.4.1.1 きっかけ事例
線量情報報告役は線量オブジェクトの情報を受け取る必要があります。
このきっかけは、線量情報報告役が線量オブジェクトを表示しり、処理したり、登録するときに起こります。たとえば、あるタイプの検査の診断参照値を越える検査の日報を作成する、昨年中にある患者に与えられた線量のサマリーを作成する、先週行われた全ての検査を国の線量登録所に登録するレポートを作る、などです。
線量情報消費役が線量オブジェクトの情報を取得する必要があります。
このきっかけは、線量情報消費役が線量オブジェクトを表示しり、一個以上の線量オブジェクトにさらに処理したり、登録するときに起こります。たとえば、線量図を作るために画像と線量オブジェクトを一緒に処理する、です。詳細は、RAD TF-1: 22.3 Radiation Exposure Monitoring Process Flow for more details の使用
例を参照してください。
4.64.4.1.2 通信文の意味
通信文の意味は DICOM Query/Retrieve SOP Classes で定義されます。
線量情報報告役および線量情報利用役は Query/Retrieve SOP Classes を SCU の役割として実装せねばなりません。画像管理役・画像保管庫（IM/IA）は Query/Retrieve SOP Classes を SCP の役割として実装せ
ねばなりません。
DICOM Study Root Query/Retrieve Infomation Model - FIND SCP Class、あるいは、DICOM Patient Root
Query/Retrieve Infomation Model - FIND SOP Class からの、C-FIND 要求は線量情報報告役、または、線量情報利用役から画像管理役（IM）に送られねばなりません。
線量情報報告役および線量情報利用役は一つ以上の検索キーを検索条件として使い、画像管理役（IM）
から選択したレベル（患者、検査／シリーズ／画像／インスタンス）で該当する項目のリストを受け取ります。
DICOM に定義された必須の一意キーに加えて Dose Report Query の SCU と SCP は、検査レベルとシリーズレベルの検索用の照合キーや返答キーが、RAD TF-2: 4.14.4.1.2 と表 4.14-1 に定義された様に、使用可能でなければなりません。
線量情報報告役(SCU)、線量情報利用役(SCU)、画像管理役・画像保管庫（IM/IA）(SCP)は表 4.64-1 に定義された線量情報に特定のキーにも対応せねばなりません。
表 4.64-1 線量報告書インスタンス限定の検索照合キーと返答キー
Dose Report Instance Specific Query Matching and Return Keys
上表のキー使用の必須の凡例は RAD TF-2:2.2 に定められています。
4.64.4.1.2.1 絞り込み方法
使用可能な照合キー、返答キー、オブジェクト内容に基づく絞り込み検索の方法はあきらかですが、いくつかの示唆を記します。

_______________________________________________________________________________________________________________________________________________

80
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
絞り込みは三点で起こり得ます。照合キーはサーバー側での絞り込みを可能にします；絞り込みに適合す
るメタデータを持つインスタンスのみ回答されます。返答キーはクライアント側で絞り込みを可能にします；
返答キーに合致するメータデータをもつインスタンスのみが取得されます。最後に、オブジェクトの属性や内容構成成分は、さらなるクライアント側での絞り込みを可能にします。；絞り込みに合致するインスタンスのみが処理されます。
クライアント側でオブジェクト属性と内容による絞り込みが最も柔軟ですが、不要な多量のオブジェクトの取り出しを避けるために照合キーと返答キーの使用がたいへん有用です。
線量オブジェクトを絞り込むには：・照合キー — SOP Class UID (0008,0016)で、X-ray Radiation Dose SR Storage SOPClass の選択ができます。
ある日付の範囲で絞り込むには：・照合キー — Study Date (0008,0020) や Performed Procedure Step Start
Date(0040,0244)を使います。
特定の撮影装置で絞り込むには、・照合キー — Modalities in Study (0008,0061)を使う。（CT, XA, DR, DX, CR, MX）
注：ある種の検査は複数の撮影装置をもつことがあり、線量レポートで装置を確認する必要が残ります。シリーズレベルの撮影装置属性は常に線量報告では SR であることも注意してください。

・返答キー — Template ID (0040,DB00)を使い、CT か投影 X 線の線量レポートかを区別します。
将来の線量レポートも新しい Template ID 値で同定可能で、画像保管庫（IA）が照合キーとして使用可能にできる貴重な属性になり得ます。
・オブジェクト内容樹 — Procedure Reported を使用して、マンモグラフィーを他の X 線撮影と区別します。
特別な手技を絞り込むには、・オブジェクト属性 — 実行済検査コード順列（Performed Procedure Code Seq.
(0040,A372)）はタイプ 2 ですが、線量オブジェクトで占められた場合、実行された撮影手技を含む
ので、検査の同定が可能となります。これは施設内のコードで変化しがちなので、種々の検査コー
ト・部位コードをより小さな集合に対応させ、分析を実行し報告するための参照表を使用する必要があるでしょう。
・オブジェクト内容樹 — 撮影プロトコル（Acquisition Protocol）があれば、手技のタイプを特定する助けになります。
注：シリーズ記述(0008,103E)はタイプ３属性です。存在すれば、線量オブジェクトは"Radiation Dose Information”の値を持ちます。

撮影部位で絞り込むには、・オブジェクト内容樹 — 目的部位（Target Region）が役立ちます。
注：実装によってはきわめて詳細な部位が提供されるが絞り込みはより広い範囲の部位にしたいことがあります；他の実装では簡略されすぎた部位のため絞り込みができないこともある。

・オブジェクト内容樹 — 解剖学的構造（Anatomical Structure）があれば、投影 X 線の線量報告
で体部位が同定可能です。
患者の年齢範疇で絞り込むには、_______________________________________________________________________________________________________________________________________________

81
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・返答キー — 患者生年月日（Patient’s Birth Date (0010,0030)）で患者の年齢層の特定ができます。
・返答キー — 患者年齢（Patient’s Age (0010,1010)）はタイプ 3 属性でオプションの返答キーですが、一部の患者の年齢層の特定ができます。
患者体重で絞り込むには・返答キー — 患者体重（Patient’s Weight (0010,1030)） はタイプ 3 属性で、オプションの返答
キーですが、一部の患者の体重範囲の特定ができます。
患者の性別で絞り込む
・返答キー — 患者性別（Patient’s Sex (0010,1040)）は、患者の性の特定が（例えば、妊娠可能
年齢の女性についての監視方針に従い）できます。
4.64.4.1.3 予期される動作
画像管理役・画像保管庫（IM/IA）は、C-FIND 要求を受け、与えられたキーにより検索し、合致する記録のリストを、C-FIND 応答を介して、線量情報報告役、あるいは、線量情報消費役に、返します。
線量情報報告役や線量情報利用役は返答キーの値を使って特定の線量オブジェクトを取得します。詳細は 4.64.4.1.2.1 節を参照してください。。
一部の詳細は初回の取得でのみ得て、ついで、線量オブジェクトを解析します。

4.65 線量情報取得 （Retrive Dose Information）
この章は IHE Technical Framework の RAD-65 に対応します。RAD-65 は線量情報報告役、線量情報利
用役、画像管理役（IM）で使われます。
4.65.1 範囲
線量情報報告役や線量情報利用役は画像管理役（IM）から線量オブジェクトを取得します。
4.65.2 使用例
アクタ：線量情報報告役
役割：線量オブジェクトを要求し取得します。
アクタ：線量情報利用役
役割：線量オブジェクトを要求し取得します。
アクタ：画像管理役（IM）
役割：線量情報報告役や線量情報利用役から要求された線量オブジェクトを提供します。
4.65.3 参照する標準DICOM 2011 PS 3.4: Query/Retrieve Service ClassDICOM 2011 PS 3.4: Structured Reporting Storage SOP Classes
DICOM 2011 PS 3.3: A.35.8 X-Ray Radiation Dose SR IOD
4.65.4 相互作用図
注： 上図では、線量情報消費役と線量情報レポート役は C-MOVE 要求を出し C-STORE 通信文も受けることがありま_______________________________________________________________________________________________________________________________________________

82
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________す。

4.65.4.1 線量情報取得
取得（Study Root – MOVE とオプションで、Patient Root – MOVE）SOP クラスが使用可能でなければなりません。これは、シリーズレベルで C-MOVE も使用可能でなければならないことになります。詳細な記述的意味は DICOM 2011 PS 3.4 Annex C 参照してください。
画像管理役・保管庫（IM/IA）、線量情報報告役、線量情報利用役は下記の表 4.65-1 に示す SOP クラスが使用可能でなければばなりません。
表 4.65-1： 線量保存 SOP クラス
4.65.4.1.1 きっかけ事例
線量情報報告役及び線量情報消費役が特定の線量オブジェクトを必要とすると決めます。
4.65.4.1.2 通信文の意味
通信文の意味は DICOM 2011 PS 3.4: Query/Retrieve Service Class の DICOM Query/Retrieve SOPClasses の章で定義されます。線量情報報告役または線量情報消費役は DICOM C-Move の SCU とDICOM Storage SCP の SCP で、画像管理役（IM）は DICOM C-Move の SCP と DICOM Storage の SCUです。
投影 X 線放射線量 SR オブジェクトは通常、TID 10001 "Projection X-ray Radiation Dose"か TID 10011"CT Radiation Dose"の基礎雛型に基づくが、これらの雛型は拡張可能で、追加の雛型の使用も禁止はされないことに注意せねばなりません。
画像管理役・画像保管庫（IM/IA）から線量オブジェクトを取り出すときに、患者や手技の情報が最新であることを保証するのは画像管理役・画像管理庫（IM/IA）の責任です。
画像管理役・画像保管庫（IM/IA）は C-MOVE 要求を受け、線量情報報告役または線量情報消費役とDICOM 連携を確立し、接続し、DICOM C-STORE コマンドで要求された線量オブジェクトを転送します。
4.65.4.1.3 予期される動作
線量情報報告役と線量情報利用役は線量オブジェクトを受け取らねばなりません。線量情報報告役や線量情報利用役の機能や設定、運用論理によって線量オブジェクトを処理されねばなりませんし。可能性として、表示、処理、解析、印刷、取り出しなどがあります。
線量情報報告役は TID 10001 と TID 10011 の両方の処理ができねばなりません。
線量情報報告役または線量情報消費役は画像保管庫（IA）に対して、使用されている雛形や取得した書類の内容を認識できないことを理由に、エラーを返してはなりません。結果は単に破棄せねばなりません。
同一の被曝イベント（被曝イベント UID で指揮罰可能）は、複数の線量オブジェクトで参照されることがあります。たとえば、手技ごとに集計した SR と検査全体を集計した SR とに、同じイベントが現れることがありえます。
_______________________________________________________________________________________________________________________________________________

83
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
線量情報報告役や線量情報利用役は、線量オブジェクト内の被曝イベント UID によって重複を認識せねばなりません。
線量情報報告役は、取得した線量情報に基づいてユーザに何らかの報告を提示出来ねばなりません。この様なレポートの形式や内容、解析法は REM プロファイルでは定義しません。このような詳細は製品設計の一部として作成されます。

4.66
4.67
4.68

意図して、一時的に空白です
意図して、一時的に空白です
画像書類セット提供と登録
MTOM/XOP

Provide and Register Imaging Document Set –この節はIHEテクニカルフレームワークのトランザクションRAD-68 に対応します。画像書類セット提供と登録－MTOM/XOP（Provide and Register Imaging Document Set – MTOM/XOP）は画像書類ソースに使われ、XDS画像書類セットを書類登録所（Document Registry）に提供し、保管庫にこれを保存し書類登録所（Document Registry）に登録する要求を行うため、画像書類ソースに使われます。保管庫（repositry）リポジ
トリはこれらの書類を保存し、書類登録所に登録します。このトランザクションはITIテクニカルフレームワー
クのITI-41 から導かれたものです。このトランザクションは、新たな書類コンテンツのタイプを追加し、同様に、ITI-41 に定義されたメタデータにも付加的意味および制約を追加します。
4.68.1 範囲
画像書類セット提供と登録－MTOM/XOPトランザクションは，画像書類ソースから書類保管庫に保管庫提出要求（Repositiry Submission Request）を渡します。
画像書類セット提供と登録－MTOM/XOPトランザクションは以下の項目を伝えます：・ゼロまたはそれ以上の新しい書類を記述したメタデータ（例：ゼロ書類を記述したメタデータは、すでに提出された書類への参照を行っている フォルダーを記述するのに使われる）・メタデータ内では、書類１つに対して１つのXDSDocumentEntryオブジェクト・ゼロまたはそれ以上のXDSフォルダー定義と新規および既存の書類へのリンク
・ゼロまたはそれ以上の書類

4.68.2 使用例役割
アクタ: 画像書類ソース（Imaging Document Source）
役割: 書類保管庫（Document Repository）へ、書類とこれに関連するメータデータを提出します。
アクタ: 書類保管庫（Document Repository）_______________________________________________________________________________________________________________________________________________

84
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
役割:

書類とこれに関連するメータデータの受信と：・書類の保存・後から書類の取得ができるように、提出されたメタデータをリポジトリ情報で補強する。
・強調されたメタデータを書類登録所にフォワードする

4.68.3 参照する標準ITI-41 Provide and Register Document Set-b から引き継がれた標準のリストについては、ITI TF-2b: 3.41.3
を参照してください。
加えて、放射線領域に特異な次の標準が用いられています。
DICOM 2011 PS 3.3: Key Object Selection Document (KOS)DICOM 2011 PS 3.16: Content Mapping Resource、
DICOM 2011 PS 3.18: Web Access to DICOM Persistent Objects (WADO)
PDF/A ISO 19005-1. Document management - Electronic document file format for long-term preservation Part 1: Use of PDF (PDF/A)
HL7 CDA Release 2.0 (denoted HL7 CDA R2, or just CDA, in subsequent text)
4.68.4 相互作用図
4.68.4.1 画像書類セット提供と登録－MTOM/XOP要求通信文
画像書類ソースアクタは書類と関連したメタデータを書類保管庫アクタに送ります。この通信文は ITI TF2b: 3.41.で定義された Provide and Register Document Set-b トランザクションです。
4.68.4.1.1 きっかけ事例
このトランザクションに対するきっかけは以下です：
・画像書類ソースアクタが１つまたはそれ以上の新たな画像書類を共有のために提出するように指示されるとき、または、・画像書類ソースの更新提出が必要となるような、すでに提出された書類が、または、すでに提出された目録の内容が、変化するとき。

4.68.4.1.2 通信文の意味
このトランザクションは、次のタイプの書類を共有するために、追加の書類コンテンツタイプを定義しITI-41
Provide and Register Document Set-bの通信文の意味を拡張しています。
1. DICOM SOP インスタンスのセット_______________________________________________________________________________________________________________________________________________

85
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
2. 画像診断レポート
これらのコンテンツタイプとその使用を可能とするため、追加の要求とXDS書類メタデータ上の制約が決められています。
画像書類セット提供と登録－MTOM/XOP 要求通信文の意味は次の小節で定義されています。
1. 目録書類を通した永続的 DICOM インスタンスの共有
2. PDF かテキスト形式の放射線診断レポートの共有
3. XDS-I.b 書類メタデータ定義
4. 放射線画像情報の共有における XDS 登録セットの概念の適用
画像書類ソースによって送られるこの提供と登録トランザクションに対するwsdl定義は、ITI-41 のXDS.b書
類ソースによって送られるものと変わりはありません。この提供と登録トランザクションのwsdl定義は以下の
IHE FTPサーバで見ることができます。

ftp://ftp.ihe.net/TF_Implementation_Material/ITI/wsdl/XDS.b_DocumentRepository.wsdl
4.68.4.1.2.1 DICOM インスタンスのセットの共有
画像書類ソースは、共有を意図するDICOM SOPインスタンスへの参照を記述しまとめた目録を、作成します。目録、即ちKey Object Selection (KOS)書類インスタンスは、書類登録所に登録され、書類保管庫に提供された実際の書類です。
IHE ITI XDS.b統合プロファイルに定義されたように、書類ソースと書類保管庫の間の通信文の構造はMTOM/ XOPにフォーマットされた通信文です。このトランザクションにおいて、ソースアクタは画像書類
ソースであすが、上述の要求を適用します。KOS書類インスタンスは、MIMEタイプ“application/dicom”をもつDICOM Part10 ファイルのフォーマットとして、通信文のなかで符号化されます。
画像書類ソースは、目録の中から参照されるDICOM SOP インスタンスが、取得可能であることを確実にせ
ねばなりません。画像書類ソースは、公開された目録で参照されている１つ以上のSOPインスタンスを利用できない場合、新たな目録を提出し、すでに公開され書類保管庫と書類登録所に存在する目録を置き換
えねばなりません(IHE ITI TF-3:4.1.6)。新しい目録は、公開された目録にあっても利用できないDICOM
SOPインスタンスを削除した、更新されたリストを持たねばなりません。もし画像書類ソースが、公開された目録にあるインスタンスのすべてが利用できない場合は、その目録を削除しなければなりません（IHE ITI
XDS Metadata Update Supplement）。
4.48.4.1.2.1.1 目録KOS 書類
DICOM SOP インスタンスの参照はKOS目録書類のCurrent Requested Procedure Evidence Sequence(0040,A375)属性に含まれなければなりません。
画像書類ソースはCurrent Requested Procedure Evidence Sequence (0040,A375)にあるいくつかの属性を使用可能とせねばなりません。Current Requested Procedure Evidence Sequence (0040,A375)は階層的なSOP
インスタンス参照マクロのなかで表現されており、以下の表のとおりです。
表 4.68.4.1.2.1-1: KOS目録文書における階層的SOPインスタンス参照マクロの属性
Attibutes of Hierachial SOP Instance Reference Macro in KOS Manifest Document_______________________________________________________________________________________________________________________________________________

86
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
これらの要求事項はDICOMのタイプ 2 または 3 の属性（R+で示されます）の属性で形成されています。
画像書類ソースは、特に、自己の識別情報として、Retrieve AE Title (0008,0054)とRetrieve Location UID(80040,E011)属性を含まねばなりません。これらの属性により、KOS目録で参照されたDICOMオブジェクトが後に取得可能となります。
4.68.4.1.2.2 レポートの共有
テキスト形式レポートはPDFレポートの弱点の多くを処理しますが、逆の場合もあるので、画像書類ソースは、共有されるレポートに、少なくとも次のひとつまたは二つの異なったフォーマットが使用可能でなければなりません。
・CDA包含テキスト形式
・PDF形式選択されたフォーマットの相互接続性を最大にするために、次の制限が要求されます。
・PDF書類に対しては:・特別なPDF バージョンを要求するのではないが、PDF/A(ISO 19005-1)を推奨します。
・CDA包含テキスト書類に対しては：・テキストはUTF-8 UNICODEで符号化されねばなりません。 CDAラッパー（CDA包含機能）の制限については 4.68.4.1.2.3.5 を参照してください。可能な程度まで、CDAラッパーの仕様はITI XDS Scanned Documents (XDS-SD) 統合プロファイル（ITI TF-3: 5.2.2 と5.2.3 も参照のこと）に準拠すること。
レポートはどのようなフォーマットが選択されていても画像参照付き、あるいは、無しで共有可能です。
もし共有レポートが画像参照を含む場合、PDFフォーマットに、選択された関連画像を埋め込むか、あるいは選択画像を指し示す完全なハイパーリンクを含めるか、ができます：ハイパーリンクはインタラクティブにクリック可能（例、PDF形式）、あるいは処理できるかコピー可能（例、テキスト形式）です。
共有レポートを提供し登録する画像書類ソースは、関係する画像を参照するハイパーリンクのフォーマット
に責任を持ちます。共有された画像レポートにある参照画像は特別な（DICOM）表示アプリを用いることなく入手されねねばなりません。
選択された画像を参照するハイパーリンクはDICOM WADO URIとしてフォーマットされねばなりません。共有環境は本質的に施設間なので、ハイパーリンクをフォーマットするときは、HTTPの安全性の高いバージョン（HTTPs）を用いねばなりません。
画像書類ソースには、画像参照が有効なリンクであることの確保が求められています。

_______________________________________________________________________________________________________________________________________________

87
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
特別な画像もDICOMでないフォーマット（PDFに埋め込まれた画像、PDFやテキストレポートのハイパーリンク）で共有可能ですが、DICOM 画像の大きなセットの共有は、目録書類を提供し登録して行われる
DICOM SOPインスタンスのセットの共有によって実現されねばなりません。これは、XDS書類登録所の中に、多数の個別書類を登録することを避けるためです。

4.68.4.1.2.3 メタデータ
画像書類セット提供と登録－MTOM/XOP 要求（Provide and Register Imaging Document Set –MTOM/XOP REquest）通信文は、XDS書類保管庫アクタによって、XDS書類登録所アクタに、Register
Document Set-b（ITI-42）を用いて、転送されたメタデータ属性を含まねばなりません。
画像書類ソースは、XDSDocumentEntryの全ての必要なレジストリオブジェクト属性を提供します。
4.68.4.1.2.3.1 メタデータ属性: 記載者情報と書類生成時刻
Metadata Attribute:

Author Information と Document Creation Time

XDSにおいては、登録書類は共有する意義のある臨床情報を直接含んでいます。そのため、登録用メタ
データは書類内容から直接集める必要があります。例えば退院状は書類保管庫に出される場合、記載者と作成情報はXDS書類メタデータに集められます。
XDS-I.bでは、書類保管庫に提出される目録書類は、通常、共有用の重要な臨床情報を直接構成するわけではありません。むしろそのような臨床情報を参照する情報のセットです。したがって、目録書類のメタデータは、共有情報の臨床的性質を反映するため、参照されたソースコンテンツか、その作成プロセスかに、関連付けられねばなりません。このことは、authorSpecialty, authorInstitution, authorPerson, authorRole,
creationTime, titleなど（これらに限るわけではないが）のメタデータ属性に影響を与えます。
もし，目録書類が複数の記載者からのソースデータを参照している場合、一人の主たる記載者やソース
データの作成時間と書類タイトルが選ばれねばなりません。データを見つけ出す際に使用者のレジストリへの問合せを最大限支えるため、このメタデータ属性は、共有の主内容をもっとも良く代表するソースデータの一部から加えられねばなりません。たとえば、今回のレポート、今回の検査、同様に、以前のレポートと検査とを参照する目録書類は、今回のレポート（これが共有に重要な臨床的内容です）から値をもらったメタ
データを登録すると思われます
共有すべきデータが保管庫に送られる前に元のフォーマット（例えば、DICOM）から別のフォーマット（例えば、PDF）に変換される場合、新たに生成された共有情報のメタデータは元のソースデータ（例えばDICOM データ）から加えられねばなりません。
まとめると、XDS-I.b メタデータは常に共有書類の主な臨床コンテンツを反映します。それらは書類に直接書かれるか、書類内で参照されるソースデータに記述されるか、変換された書類の起原データに記述されるか。します。

4.68.4.1.2.3.2 XDSDocumentEntry メタデータ

XDSDocumentEntry Metadata_______________________________________________________________________________________________________________________________________________

88
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.68.4.1.2.3.2 XDSDocumentEntry メタデータ
表 4.68.4.1.2.3-1 に、XDS-I.bで追加の制限がある、あるいは、画像書類ソースがメタデータに加える方法にXDS-I.b 特有の指示がある、XDSメタデータ要素を挙げている。別に指定されない限り、以下の表にリス
トされた属性がオプションかどうかは、XDSがソースアクタに要求するものと同じです。
XDS書類に関わる全てのメタデータの記述は、表 4.1-5 （ITI TF-2b: 4.1.7.）を参照してください。
表 4.68.4.1.2.3-1: XDS-I.bに特異なメタデータ要求事項
4.68.4.1.2.3.3 DICOM VRからXDS書類メタデータ型への変換
多くのXDS書類メタデータ属性は、値の表現にHL7 データ型を使用します。メタデータ属性の一部は、該当するDICOM SOPインスタンスのデータ要素から変換されることがあります。この節では、DICOM VR(Vlaue Representation)から、XDS書類メタデータで使用されるHL7 データ型への変換を記載します。
下記の変換でのHL7 データ型とは、IHE ITI XDS統合プロファイルに定義されたXDS書類メターデータでの規定の使用法を言います。
4.68.4.1.2.3.3.1 CX — 拡張複合ID CX — Extended Composite ID
表 4.68.4.1.2.3-2 に、IHE ITI XDS統合プロファイルに定義されたDICOM VR型データ要素（element）のCXデータ型への変換を示します。
表 4.68.4.1.2.3-2： CXデータ型対応付け
表に示されていないHL7 CXデータ成分（componenent）は、XDS書類メタデータでは使用されず、空白のままとされねばなりません。
4.68.4.1.2.3.2

DTM — Date/Time

DTM — Date / TimeHL7 DTMデータ型は、以下の正規表現で表されます：
YYYY[MM[DD[HH[MM[SS]]]]]
これは、DICOM要素のVR DA （書式：YYYYMMDD）とTM（書式： HHMMSS.fraction）から変換できま
表 4.68.4.1.2.3-2 に、IHE XDS に定義されたDICOM VRのデータ要素からCXデータタイプへの変換を示します。
4.68.4.1.2.3.3.3

XCN — 拡張複合患者ID番号と患者氏名

XCN — Extended Composite ID Number and Name for Person
Table 4.68.4.1.2.3-3 に、IHE XDS 統合プロファイルに定義されたDICOM VRからXCNデータタイプへの変換を示します。
表 4.68.4.1.2.3-3: XCNデータ型対応付け_______________________________________________________________________________________________________________________________________________

89
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
表に示されていないHL7 XCNデータ成分（componenent）は、XDS書類メタデータでは使用されず、空白のままとされねばなりません。

4.68.4.1.2.3.3.4 XON – 拡張複合組織名と組織ID番号
XCN — Extended Composite ID Number and Name for Organization
表 4.68.4.1.2.3-4 に、IHE XDS 統合プロファイルに定義されたDICOM VRからXONデータタイプへの変換を示します。
表 4.68.4.1.2.3-4: XONデータ型対応付け
表に示されていないHL7 XONデータ成分（componenent）は、XDS書類メタデータでは使用されず、空白のままとされねばなりません。
4.68.4.1.2.3.4 HL7 v2.5 データタイプで表現されたXDS/XDS-I.b メタデータの値
HL7 v2.5 データタイプとして表現されたXDS/ XDS-I.bメタデータは、対応するHL7 CDA R2 ヘッダーコン
ポーネントからの変換を要します。次の表(4.68.4.1.2.3-5)はこの変換の手引きで、このトランザクションを使用可能とする実装の、設定、および・または、変換への要求事項を、間接的に課します。さらに、このテーブ
ルはHL7 CDA R2 仕様をより制限します。CDAヘッダーのID（IIタイプ）に対応するメタデータのIDはルートと拡張の両方の属性をもつことが要求されます。
表 4.68.4.1.2.3-5: HL7 v2.5 とCDAデータ型の対応付け
注： XDSはCXデータ型のフォーマットを制限しています。ITI TF-2a:付録Eを参照。

4.68.4.1.2.3.5 CDAラッパー（包含機能） – テキストレポートの [CDA] オプション
この節はテキストコンテンツ用のHL7 CDA R2 ラッパーの内容を概観します。以下に規定された要求は、表現を拡張し書類の共有を促進するために、ラッパーデータの最小限の存在を確保することに注意してください。"nullFlavor"値はCDAの欠損値を表すことに注意してください。例えば、そのような情報がDICOM オ
ブジェクトから引き出せないのであれば，それで十分です。
「テキスト形式レポート（Text Report）[CDA]」プロファイルオプションの実装は、より豊富なコンテキストを提供するために、CDAヘッダー内の追加のアノテーションを利用しなければなりません。次に続く節にある例
は、定義された最小のラッパーデータを含んでおり、多くの例でenriched contextに追加するCDAヘッダー
要素を利用しています。
レポートテキストにおけるCDAラッパーの仕様は、ITI XDS Scanned Documents (XDS-SD)統合プロファイ
ルで定義されたCDAメタデータと、可能な程度まで整合してつくられ、読者の利便のためにここで繰り返されています。

_______________________________________________________________________________________________________________________________________________

90
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________CDA R2 仕様で許されている場面では、電子的に伝送された放射線レポートを共有する使用例は別として、
XDS-SDの使用例に適合するような要素と属性は除外されています。「 テキスト形式の放射線レポートを共有する」 使用例と整合する、要素と属性を如何に加えるかに対する記述は含まれています。

4.68.4.1.2.3.5.1 ラッパー（包含機能）フォーマット – HL7 CDA R2
単純なテキスト形式レポートに対するCDAメタデータラッパーは、以下に記載された例外と次の節に挙げた例外を除き、ITI XDS-SDプイロファイル（ITI TF-3: 5.2.3 のメタデータ定義テーブルを参照のこと）に定義されたものと同様です。
・ClinicalDocument/dataEnterer要素は、XDS-SDに定義されたように、レポート共有ユースケー
スに適用せず、省略されます。
4.68.4.1.2.3.5.1.1 ClinicalDocument 子無要素 ClinicalDocument Child-less Elements
CDA包含された単純テキスト形式レポートに対するClinicalDocument のChild-less要素への要求は、ITI
XDS-SD プロファイル (ITI TF-3: 5.2.3.1)と同様で、次の例外または説明が必要となります。
・ClinicalDocument/templateId要素は 1.3.6.1.4.1.19376.1.2.21であること
・ClinicalDocument/codeは次の属性値に従ってセットされること。
・code=“11528-7”
・codeSystem=“2.16.840.1.113883.6.1”
・codeSystemName=“LOINC”
・displayName=“Radiology Report”/>
・ClinicalDocument/effectiveTimeはCDAテキスト書類が記録された時刻を示さねばなりません。最小限、時刻は日まで正確であり、GMTからの時刻ゾーン時差値を含まねばなりません。
例：

4.68.4.1.2.3.5.1.2 ClinicalDocument/recordTarget
CDA包含された単純テキスト形式レポートに対するClinicalDocument/recordTarget要素への要求事項と例
は、ITI XDS-SDプイロファイル（ITI TF-3: 5.2.3.2 を参照のこと）に定義されたものと同様です。
4.68.4.1.2.3.5.1.3 ClinicalDocument/author (original)
CDA包含された単純テキスト形式レポートに対するClinicalDocument/author要素（レポートの作成者）への要求事項と例は、ITI XDS-SDプイロファイル（ITI TF-3: 5.2.3.3 を参照のこと）に定義されたものと同様です。
_______________________________________________________________________________________________________________________________________________

91
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.68.4.1.2.3.5.1.4 ClinicalDocument/author (レポートシステム)
CDA包含された単純テキスト形式レポートに対するClinicalDocument/author要素（レポート内容を作成するのに使われたレポーティングシステムとソフトウェアを表す）への要求は ITI XDS-SD プロファイル (ITI
TF-3: 5.2.3.4)と同様で、次の例外または説明が必要となります。
・XDS-SD の仕様を読む時、スキャンされた、スキャン中、スキャンされた内容、などの言葉は、ここの文脈では、レポート作成、レポート内容、などのことを言います。
・ClinicalDocument/author/assignedAuthor/assignedAuthoringDevice/code 要素に関する XDSSD の仕様を読むとき、CDA 包含された PDF への参照は、放射線レポート共有の使用例に適用しないので無視してよいです。
例：
4.68.4.1.2.3.5.1.5 ClinicalDocument/custodian
CDA包含された単純テキスト形式レポートに対するClinicalDocument/custodian要素への要求事項と例は、
ITI XDS-SD プロファイル（ITI TF-3: 5.2.3.6）と同様です。そのコンテキストは、現場施設の方針に従って定義され、レポート内容に責任をもつ実体を反映するよう、レポート作業を行う施設にまかされています。多くの場合、これはレポート作業をした施設です。
4.68.4.1.2.3.5.1.6 ClinicalDocument/legalAuthenticator
CDA包含された単純テキスト形式レポートに対するClinicalDocument/ legalAuthenticator要素への要求事
項と例は、ITI XDS-SD プロファイル (ITI TF-3: 5.2.3.7)と同様です。その状況は、現場施設の方針に従って定義されるよう、レポートする施設にまかされています。

4.68.4.1.2.3.5.1.7 ClinicalDocument/documentationOf
CDA包含された単純テキスト形式レポートに対するClinicalDocument/ documentationOf 要素への要求事
項と例は、ITI XDS-SD プロファイル （ITI TF-3: 5.2.3.8）と同様です。
4.68.4.1.2.3.5.1.8 ClinicalDocument/component/nonXMLBody
CDA包含された単純テキスト形式レポートに対するClinicalDocument/ component/nonXMLBody要素は必須で、テキスト内容を包含するのに使用されます。nonXMLBodyへの要求事項と例は ITI XDS-SD プロ
ファイル（ITI TF-3: 5.2.3.9）と同様で、次の例外または説明が必要となる。
・XDS-SD仕様を読む時、スキャンされた、スキャン中、スキャンされた内容などは、この文脈では、
レポート作成、レポート内容などのことを言います。
・ClinicalDocument/component/nonXMLBody要素に関するXDS-SD仕様を読む時、CDA包含されたPDFへの参照は、放射線レポート共有ユースケースに適用されないので無視して良いです。
例（レポートテキスト内容はラッパーと同じ言語となる）
4.68.4.1.2.4

XDS提出セットの利用_______________________________________________________________________________________________________________________________________________

92
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
4.68.4.1.2.4.1 DICOMインスタンスのセットへのレポートのリンク
図 4.68.4.1.2.4-1 に、以下の３つのSubmission Set（提出セット）の例を示します。
・提出セット１は書類保管庫に保存されたレポートと目録を含みます。目録は画像管理役・画像保
管庫（IM/IA）に保存されたDICOMインスタンスを参照します。
・提出セット２はひとつの目録を含みます。
・提出セット３は、目録によって参照された画像の読影によって生成されたため、レポートを含み、提出セット２からの目録を参照します。提出セット３は、目録によって参照されたレポートと画像が読影に使われたため、レポートと提出セット１からの目録とを参照 します。
4.68.4.1.2.4.2 レポートを以前の登録レポートにリンクする
以前の画像が読影するときにつかわれているならば、レポート提出セットは登録された以前の画像セットに対する目録を参照できます。同様にレポート提出セットは以前に提出したレポートを参照できます。
4.68.4.1.3 想定される動作
書類保管庫アクタはこの通信文を受信し、ITI TF-2b: 3.41.4.1.3.で定義された要求に従って処理します。
4.68.4.2 画像書類セット提供と登録– MTOM/XOP応答通信文
Provide and Register Imaging Document Set – MTOM/XOP Rspsonse Message
書類保管庫は、画像書類セット提供と登録– MTOM/XOP要求通信文（Provide and Register Imaging
Document Set – MTOM/XOP Request message）の処理が完了すると、画像書類セット提供と登録–
MTOM/XOP応答通信文（Provide and Register Imaging Document Set – MTOM/XOP Respsonse message）
を送ります。きっかけ事例や通信文意味、予期される動作の仕様は、ITI TF-2b: 3.41.4.2.で定義されたものと同様です。
失敗となる条件と可能なエラー通信文はebRS標準に定義されています。画像書類ソースは、ITI TF-3:
4.1.13 “Error Reporting”にあるProvide and Registerトランザクションに詳細が記述された全てのエラー通信文を処理せねばなりません。

4.69 画像書類セット取得（Retrieve Imaging Document Set）
この節はIHEテクニカルフレームワークのトランザクションRAD-69 に対応します。「画像書類セットの取得」
は、画像書類利用役が画像書類ソースからDICOMオブジェクトを取得するのに使用されます。取得されたオブジェクトはRAD TF-3: 4.68 に記述されたXDS-I.b目録書類の中で参照されたものです。このトランザク
ションはITIテクニカルフレームワークの書類セットの取得（Retrieve Document Set）トランザクション(ITI-43)
から導かれ、このトランザクションとほぼ同じです。このトランザクションは、ITI-43 に定められた要求事項に、意味や制約を少し追加しています。
4.69.1 範囲_______________________________________________________________________________________________________________________________________________

93
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
このトランザクションは画像書類ソースからDICOMオブジェクトのセットを取得するのに、画像書類利用役が使います。画像書類利用役は、グループ化された書類消費役がRetrieve Document Setトランザクション
を通して書類保管庫から事前に入手した目録オブジェクト（KOS）を利用します。画像書類利用役は、取得要求を作成するために、目録（KOS）オブジェクトから画像書類ソースに関連する
XDSDocumentEntry.uniqueIdとRepositoryUniqueIdを抽出します。
4.69.2 使用例の役割
アクタ: 画像書類利用役 （Imaging Document Consumer）
役割: DICOMインスタンスのセットを取得するため、インターネットサービス（web servicee）要求を発行します。
アクタ: 画像書類ソース
役割: : DICOMインスタンスのセットを取得するインターネットサービス（web servicee）要求を受け、適切な内容物を添えてインターネットサービス応答をだします。
4.69.3 参照する標準
参照する標準の一覧は、ITI-43 Retrieve Document Set（ITI TF-2b: 3.43.3 を参照）から引き継ぎます。
4.69.4 相互作用図
4.69.4.1 画像書類セット取得要求通信文 Retrieve Imaging Document Set Request Message
画像書類利用役は、目録ブジェクトから参照される画像のセットを取得するため、画像書類ソースに要求を送る。この通信文は ITI TF-2b: 3.43 で定義された Retrieve Document Set トランザクションの拡張です。
4.69.4.1.1 きっかけ事例
画像書類利用役は、グループ化されている書類消費役アクタによって事前に取得された、DICOM目録で参照されるDICOMインスタンスのセットを取得しようとします。画像書類利用役は、書類のuniqueIds （すなわち、DICOM目録で参照されたSOPインスタンス UID）を、関連するStudy Instance UIDとSeries Instans
UIDとともに、取得します。画像書類利用役は、repositoryUniqueIdを、DICOM目録にあるRetrieve AE Title
属性から計算するか、DICOM目録にあるRetrieve Location UID属性を用いてrepositoryUniqueIdを加える
か、します。画像書類利用役は、repositoryUniqueIdを、通信文のターゲットであるWebサービスのエンドポ
イントに、対応付けます。
書類のuniqueIdとrepositoryUniqueIdが得られたら、画像書類利用役は画像書類セット取得要求（Retrieve
Imaging Document Set Request）を画像書類ソースに送ります。
4.69.4.1.2 通信文意味
画像書類セット取得要求（Retrieve Imaging Document Set Request）は次の情報を運ばなければなりません：_______________________________________________________________________________________________________________________________________________

94
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・DICOMインスタンスを取得する画像書類ソースを特定するに必須のrepositoryUniqueId。この値はDICOM目録にあるRetrieve AE Title (0008, 0054) 属性をもとに「計算する」か、あるいはDICOM
目録に存在するRetrieve Location UID (0040,E011)属性から追加するかしなければなりません。この「計算」が如何に行われるかはIHE RAD TF-3: Appendix G.3.を参照してください。
・画像書類ソースのなかで書類を特定する一つかそれ以上のdocumentUniqueId必須のリス
これらの値は、DICOM目録に参照されたSOPインスタンスUIDに対応します。

ト。

・画像書類利用役が処理できる一つかそれ以上のDICOM転送構文 UID（transfer syntax
UID）のリスト
・取得するDICOM画像・オブジェクトを含む検査（Study）を特定する必須のStudy Instanceの値

UID・取得するDICOM画像・オブジェクトを含むシリーズを特定する必須のSeries Instance UID
値。 Series Instance UIDはKOSから取り出される。

の通信文は 4.69.5 節プロトコル要求に示されたように構造化されていなければなりません。
4.69.4.1.3 予期される動作
画像書類セット取得要求（Retrieve Imaging Document Set Rquest）を受信するとき、画像書類ソースは画像
書類セット取得応答（Retrieve Imaging Document Set Response）を生成しなければなりません。
4.69.4.2 画像書類セット取得応答（Retrieve Imaging Document Set Response）通信文
Retrieve Imaging Document Set Respsonse message
4.69.4.2.1 きっかけ事例
この通信文は画像書類セット取得要求（Retrieve Imaging Document Set Request）の受信によって生起します。 2
4.69.4.2.2 通信文意味
画像書類セット取得応答（Retrieve Imaging Document Set Response）通信文の意味はITI-43 トランザクショ
ンから継承されたものと同じで、ITI TF-2b: 3.43.4.2.2.に定義されています。
4.69.4.2.3 予期される動作
画像書類ソースは要求で指示された書類を提供しなければなりません。画像書類ソースは書類か、種類が返せないなら、エラーコードを、それぞれ返さねばなりません。画素値*は画像書類セット取得要求（Retrieve Imaging Document Set）通信文の中に含まれる DICOM 転送構文（transfer syntax）のひとつを用いて符号化されねばなりません。画像書類ソースが提供されたどの転送構文を用いても画素値*を符号化
2*

訳者注： オーバーレイ表示でなく、画素として画像中に埋め込まれた患者名などの非画像データのこと_______________________________________________________________________________________________________________________________________________

95
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
できない場合、エラーステータスが返されねばなりません。
画像書類利用役が 1.2.840.10008.1.2.4.94 (DICOM JPIP Referenced Transfer Syntax)または、
1.2.840.10008.1.2.4.95 (DICOM JPIP Referenced Deflate Transfer Syntax)の転送構文データ欄（field）（transfer syntax field）に特定するとき、次の動作が予期されます：
・ もしDICOM画像オブジェクトが要求された転送構文（transfer syntax）に一致したら、Retrieve
Imaging Document Set応答は、変更されていないDICOM画像オブジェクトを含みます。
・ もし、DICOM画像オブジェクトが要求とは異なる転送構文（transfer syntax）を持っていたら、Retrieve Imaging Document Set 応答は、要求された転送構文（transfer syntax）に変えた
DICOM画像を含まなければなりません。加えて、画素値の属性(7Fe0,0010 タグ)は削除されPixel Data Provider URL (0028,7FE0 タグ)に置き換えられます。URLはJPIP要求を表し、特定のターゲット情報を含みます。
・Retrieve Imaging Document Set 応答の受信により、画像書類利用役は、提供されたURLを用いて画素データ供給者から画素データを要求してもよい。画素データ提供者を利用するときには、アプ
リケーションに必要な追加のパラメータはURLに付けられてもよい。
・例えば、画像全体を 200X200 画素へ変換するJPIP要求はPixel Data Provider URLによって次のよ
うに構築されます。
・Pixel Data Provider URL (0028,7FE0) =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2,
・ URL Generated by the application =https://server.xxx/jpipserver.cgi?target=imgxyz.jp2&fsiz=200,200
失敗の条件と可能なエラー通信文はebRS標準で与えられ、ITI TF-3: 4.1.13 “Error Reporting”に詳細が記述されています。
4.69.5 プロトコル要求
このトランザクションの実装はITI TF-2x: Appendix V: Web Services for IHE Transactionsに記述されている全ての要求事項を満たさなければなりません。
Retrieve Imaging Document SetトランザクションはSOAP12 とXOPコーディングされたMTOM（MTOM/XOPとこの仕様では表記）を用いなければなりません。ITI TF-2x: Appendix Vを参照してください。
画像書類ソースは以下ができねばなりません：・MTOM/XOPフォーマットでRetrieve Document Set要求通信文を受け入れます。
・MTOM/XOPフォーマットでRetrieve Document Set応答通信文を生成します。

画像書類利用役は以下ができねばなりません：_______________________________________________________________________________________________________________________________________________

96
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・Retrieve Document Set要求通信文をMTOM/XOPフォーマットで生成します。
・MTOM/XOPフォーマットのRetrieve Document Set 応答通信文を受け入れます。
（表）
これらは、WSDL定義に現れる順番でのRetrieve Imaging Document Setトランザクションへの要求事項です。
・次のタイプは/definitions/types セクションに取込れ(xsd:import)ねばなりません：・namespace="urn:ihe:rad:xdsi-b:2009", schema="
XDSI.b_ImagingDocumentSource.xsd"
・The baseline XDS.b schema (namespace="urn:ihe:iti:xds-b:2007", schema=”
XDS.b_DocumentRepository.xsd”)
・Retrieve Imaging Document Set 要求通信文の/definitions/message/part/@element属性は“iherad:RetrieveImagingDocumentSetRequest”と定義されねばなりません。
・Retrieve Imaging Document Set 応答通信文の/definitions/message/part/@element属性は“ihe:RetrieveDocumentSetResponse”と定義されねばなりません。
・Retrieve Imaging Document Set 要求通信文の/definitions/portType/operation/input/@wsaw:Action属
性は “urn:ihe:rad:2009:RetrieveImagingDocumentSet”と定義されねばなりません。
・Retrieve Imaging Document Set 応答通信文の/definitions/portType/operation/output/@wsaw:Action属
性は“urn:ihe:iti:2007:RetrieveDocumentSetResponse” と定義されねばなりません。
・/definitions/binding/operation/soap12:operation/@soapAction属性は“urn:ihe:rad:2009:RetrieveImagingDocumentSet” と定義されねばなりません。
これらはSOAP通信文のワイヤフォーマットに影響する要求です。他のWSDL属性はWSDL定義内でのみ使われており、相互接続性に影響しません。サンプル要求と応答の通信文全体のサンプルは、4.69.5.1
サンプルSOAP通信文にあります。
画像書類ソースアクタに対するINFORMATIVEなWSDLについては、IHE FTP サーバー
ftp://ftp.ihe.net/TF_Implementation_Material/RAD 上にサンプルをみることができます。
Retrieve Imaging Document Set応答通信文として用いられる<iherad:RetrieveImagingDocumentSetRequest/> 要素は以下のように定義されます：
・取得されているDICOM 画像・オブジェクトに関連する検査（study）を特定する“studyInstanceUID”要素を個々に含む、一つかそれ以上の<iherad:StudyRequest/>要素。それぞれの<iherad:StudyRequest/>要素は次のものを含まねばなりません：_______________________________________________________________________________________________________________________________________________

97
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・取得されているDICOM 画像・オブジェクトに関連するシリーズを特定する“seriesInstanceUID”属性を個々に含む、一つかそれ以上の<iherad:SeriesRequest/>要素。
それぞれの<iherad:SeriesRequest/>要素は次のものを含まねばなりません：
・画像書類利用役が、画像書類ソースから取得したい個々の書類を表す一
つかそれ以上の<ihe:DocumentRequest/>要素。それぞれの<ihe:DocumentRequest/>要素は次のものを含みます：
・書類を取得すべき画像書類ソースを特定する、必須の<ihe:RepositoryUniqueId/>要素。この値はXDSDocument.entry.repositiryUniqueIdに対応します。
・画像書類ソース内にある書類を特定する、必須の<ihe:DocumentUniqueId/>要素。この値はDICOM目録の中のSOPインスタ
ンスUIDに対応します。
・ebRIMにおける特定可能なクラスのhome属性に対応するオプションの<ihe:HomeCommunityId/>要素
・一つかそれ以上の<ihe:TransferSyntaxUID>要素のリストを含む、必須の<iherad:TransferSyntaxUIDList/>要素。<iherad:TransferSyntaxUID>のそれぞれの要素はは画像書類利用役が処理可能な転送構文（transfer syntax）の符号化のひとつを表します。
このことは画像書類利用役が，書類保管庫から取得する一つかそれ以上の書類を特定することを可能にします。

Retrieve Imaging Document Set 応答通信文とともに使用される、<ihe:RetrieveDocumentResponse/>要素は、以下のように定義されます：
・必須の/ihe:RetrieveDocumentSetResponse/rs:RegistryResponse要素
・<ihe:DocumentResponse/>要素のオプションのシーケンスは以下を含んでいます・<ihe:HomeCommunityId/>要素。このエレメントの値はRetrieve Document Set 要求通信文
において/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest/HomeCommunityIdと同じ値をもたねばなりません。
・書類が取得される画像書類ソースを特定する、必須の<ihe:RepositoryUniqueId/>。この要素の値は、元のRetrieve Imaging Document Set 要求通信文における/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/RepositoryUniqueId要素の値と同じです。この値は、
XDSDocumentEntry.repositoryUniqueIdと対応します。
・画像書類ソース内にある書類を特定する、必須の<ihe:DocumentUniqueId/>。この要素の値は、元のRetrieve Imaging Document Set 要求通信文における_______________________________________________________________________________________________________________________________________________

98
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentReque
st/DocumentUniqueId要素の値と同じでなければなりません。この値は、DICOM目録にある
SOP インスタンスUID に対応します。
・取得されたbase64binary 符号化フオーマットの取得した書類を含む、必須の<ihe:Document/>要素
・取得された書類のMIMEタイプを示す、必須の<ihe:mimeType/>要素/RetrieveDocumentSetResponse/rs:RegistryResponse/@status属性は要求の全般的な状態を提供する：
次の値のひとつを含まなければなりません。
urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success
urn:ihe:iti:2007:ResponseStatusType:PartialSuccess urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Failure
この値に関する解釈は、ITI TF-3: 4.1.13 エラーレポートを参照してください。
/RetrieveImagingDocumentSetRequest/StudyRequest/SeriesRequest/DocumentRequest要素で要求されたそれぞれの書類について：
・もし書類を取得する際に警告が報告されたら、/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError 要素は 次の項目と一緒に返されねばなりません。

・@severityがurn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warningです。
・@errorCodeが特定されています・@codeContextは警告通信文を含みます
・@locationは要求された書類のDocumentUniqueIdを含みます
・書類は、/RetrieveDocumentSetResponse/DocumentResponse/Document のインスタンスとして
base64binary符号化データの形で戻らねばなりません。返された書類と警告はDocumentUniqueId
を通じて関連します。
・もし書類を取得する際にエラーが報告されると、/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError要素は次の項目とともに返されねばなりません。
・@severity は urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error です・@errorCode が特定されています・@codeContext がエラー通信文を含みます
・@location は 要求された書類のDocumentUniqueId を含む_______________________________________________________________________________________________________________________________________________

99
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
・対応するRetrieveDocumentSetResponse/DocumentResponseは返してはなりません
・もし書類の取得が警告なく成功するならば、/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:RegistryErrorList/ rs:RegistryError要素は存在してはならず、/RetrieveDocumentSetResponse/DocumentResponse/Document要素がbase64binary符号化データの形の書類を含んで返されねばなりません/RetrieveDocumentSetResponse/rs:RegistryResponse/rs:ResponseSlotList要素はこのトランザクションでは使われません。
RetrieveDocumentSetResponse/rs:RegistryResponse/@requestId属性はこのトランザクションでは使われません。
全部のXDS.bとXDS-I.bタイプのXMLスキーマ書類がIHE FTPサイトでオンラインで手に入ります：
ftp://ftp.ihe.net/TF_Implementation_Material/RAD (XDS-I.b) と
ftp://ftp.ihe.net/TF_Implementation_Material/ITI (XDS.b) です。
4.69.5.1 SOAP 通信文の例
次の２節は典型的なSOAP要求とSOAP応答を示します。サンプル通信文は、WS-Addressingヘッダ<Action/>,<MessageID/>, <ReplyTo/>...; についても例示しています。これらのWS-Addressingヘッダは、
IHE ITI TF-2x: Appendix V: Web Servicesに従って追加されます。SOAP通信文の本文（body）は省略されています；実際のシナリオでは、空の要素は適当なメタデータで埋められています。
この節で示されたサンプルはIHE FTPサイトでオンラインでも手に入ります
ftp://ftp.ihe.net/TF_Implementation_Material/RADを参照してください
4.69.5.1.1 画像書類セット取得 SOAP要求のサンプル
Sample Retrieve Imaging Document Set SOAP Request<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header> <a:Action
s:mustUnderstand="1">urn:ihe:rad:2009:RetrieveImagingDocumentSet</a:Action> <a:MessageID>urn:uuid:0fbfdced-6c01-4d09-a1102201afedaa02</a:MessageID> <a:ReplyTo s:mustUnderstand="1"><a:Address>http://www.w3.org/2005/08/addressing/anonymous</a:Address></a:ReplyTo> <a:To>http://localhost:2647/XdsService/IHEXDSIDocSource.svc</a:To></s:Header><s:Body>_______________________________________________________________________________________________________________________________________________

100
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________<RetrieveImagingDocumentSetRequest xmlns:iherad="urn:ihe:rad:xdsib:2009" xmlns:ihe="urn:ihe:iti:xds-b:2007"><StudyRequest studyInstanceUID="1.3.6.1.4...101"> <SeriesRequest
seriesInstanceUID="1.3.6.1.4...201"><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2300</ihe:DocumentUniqueId></ihe:DocumentRequest><ihe:DocumentRequest><ihe:RepositoryUniqueId>1.3.6.1.4...1000</ihe:RepositoryUniqueId><ihe:DocumentUniqueId>1.3.6.1.4...2301</ihe:DocumentUniqueId></ihe:DocumentRequest></SeriesRequest></StudyRequest><TransferSyntaxUIDList> <TransferSyntaxUID>
1.2.840.10008.1.2.1</TransferSyntaxUID> <TransferSyntaxUID>
1.2.840.10008.1.2.4.57</TransferSyntaxUID> <TransferSyntaxUID>
1.2.840.10008.1.2.4.70</TransferSyntaxUID></TransferSyntaxUIDList> </RetrieveImagingDocumentSetRequest></s:Body></s:Envelope>
4.69.5.1.2 Retrieve Document Set SOAP 要求の例
Sample Retrieve Imaging Document Set SOAP Response<s:Envelope xmlns:s="http://www.w3.org/2003/05/soap-envelope"
xmlns:a="http://www.w3.org/2005/08/addressing"><s:Header> <a:Action
s:mustUnderstand="1">urn:ihe:iti:2007:RetrieveDocumentSetResponse</a:Action> <a:RelatesTo>urn:uuid:0fbfdced-6c01-4d09-a1102201afedaa02</a:RelatesTo></s:Header><s:Body><RetrieveDocumentSetResponse xmlns="urn:ihe:iti:xds-b:2007"
xmlns:lcm="urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0"
xmlns:query="urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0"
xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"
xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0">_______________________________________________________________________________________________________________________________________________

101
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________<rs:RegistryResponse status="urn:oasis:names:tc:ebxmlregrep:ResponseStatusType:Success"/> <DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2300</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dGUXhEUzhi</Document></DocumentResponse><DocumentResponse><RepositoryUniqueId>1.3.6.1.4...1000</RepositoryUniqueId><DocumentUniqueId>1.3.6.1.4...2301</DocumentUniqueId><mimeType>application/dicom</mimeType><Document>UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUCx4hu</Document></DocumentResponse> </RetrieveDocumentSetResponse></s:Body></s:Envelope>_______________________________________________________________________________________________________________________________________________

102
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 A:
付録 B:

廃止
廃止

付録 C: 後処理業務流れでの汎用業務リスト、SPS, PPS および結果 Composite IOD 属性の整合
この付録は、後処理業務流れの異なる参加者が生成するオブジェクトの属性を使用する際の、要求事項を提供します。特に、後処理管理役が提供する属性のどれを、無変更のまま、GP-PPS オブジェクトの属性に、後処理で生成された結果に、および、作業項目を取得し完成するのに使用する N-ACTION 命令に、それぞれ、書き込むか、を特定します。

C. 1: 統合に不可欠の属性
この表は以下の様に理解されねばなりません。
・ 第一欄に記載の属性は、GPWL SCU（たとえば、画像処理ワークステーション、CAD 機器）が、
C-FIND 要求の返答キーとして要求しなければなりません。後処理管理役はレポート管、属性の値を C-FIND 応答で返さねばなりません。
・返答される属性値は、作業を行うステーションによって、表 C1-1 の該当する行に示された属性を複合インスタンス（第 2 欄）、GP-PPS インスタンスの両方に埋めるのに使用されねばな
りません。
・後処理管理役は、第 3 欄の該当する行に示された属性を、SCP 型と注釈で定められた様に扱え
ねばなりません。

_______________________________________________________________________________________________________________________________________________

103
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 D: レポート業務流れでの汎用業務リスト、SPS, PPS および結果 Composite IOD 属
性の整合
この付録は、レポート業務流れの参加者としてレポート生成役（RC）が作成する診断レポートの属性を使用する際の、要求事項を提供します。このレポートは DICOM SR オブジェクトとしてコード化されます。特に、レポート管理役(RM)が提供する属性のどれを、無変更のまま、GP-PPS オブジェクトの属性に、生成された
DICOM SR オブジェクトに、および、作業項目を取得し完成するのに使用する N-ACTION 命令に、それぞれ、書き込むか、を特定します。

D. 1: 統合に不可欠の属性
この表は以下の様に理解されねばなりません。
・ 第一欄に記載の属性は、GPWL SCU（レポート生成役（RC））が、C-FIND 要求の返答キーとして要求しなければなりません。レポート管理役(RM)は、属性の値を C-FIND 応答で返さねばなりません。
・返答されます。属性値は、レポート生成役（RC）によって、表 D1-1 の該当する行に示された属性を、複 合インスタンス（第 2 欄）、GP-PPS インスタンスの両方を、埋めるのに使用されねばなりません。
・レポート管理役(RM)は、第 3 欄の該当する行に示された属性を、SCP 型と注釈で定められた様に扱えねばなりません。

_______________________________________________________________________________________________________________________________________________

104
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 E: DICOM 媒体交換－不可欠な DICOM 互換性のコツ
この付録は、DICOM Media Interchange standard （PS 3.10, PS 3.11 と PS 3.12）に従わないために起こる互換性の問題を提示します。
この付録は、単に、過去にファイル制作役と取込み役間で起こった、もっとも多い互換性問題の備忘録を意図しています。

この一覧は、実装者が注意を払わねばなりません、唯一の DICOM 必須事項とは解釈しないでください。
IHE プロファイルの実装者が熟知すべきは、DICOM 規格で、これは非常に有効で完全ですと証明されています。

1． CD 媒体は ISO 9660 Level 1 に従ってフォーマットしてください。Joliet や Rock Ridge のような 拡張規格は、DICOM では禁止されておらず、PDI プロファイルでも使用が許されています。UDF
ファイルシステムは、ISO 9660 Level 1 が同時に存在しない限り、許可されません。この様な拡張
規格は、媒体上の非 DICOM 形式内容物のコ－ド化に必要で、例えば、画像観察ソフトウェアのための長いファイル名等です。このような拡張規格は、ISO 9660 Level 1 の大文字ファイル名が、Ｏ
Ｓの振る舞いに依存して、小文字あるいは、大・小文字混在のファイル名とそてソフトウェアに提示される様に結果としてなります。このため、すべての可搬媒体表示役と可搬媒体取込み役は、この点では、大文字・小文字の区別をしないようにしなければなりません。
2． DICOMDIR ファイルは交換用媒体のルートに置かねばなりません。
3． 全ての DICOM 形式ファイルの名称は、大文字、数字、下線のみからなり、拡張子を除いて、8 文
字以下でなくてはなりません。
4． DICOM フォルダ以下におかれた全てのディレクトリの名称は、大文字、数字、下線のみからなり、
拡張子はつけてはなりません。
5． 非 DICOM 形式ファイルは 3 文字以上の拡張子を持つことができます。
6． DICOM 形式ファイルは拡張子をもってはいけません。
7． DICOM 形式ファイルは、ISO 9660 第 1 版ですのです種の OS では、".1;"が最後につきます。
しかし、".1;"自身はファイル自身の名称に入れてはいけません。
8． ファイル名の版は DICOMDIR に記載されます。参照データ要素に含まれてはなりません。
9． ルートを含んで、最大 8 水準までのディレクトリが許されます。（ルートの下に 7 つまでの子ディレク
トリが作成できる）。
10．DICOM ファイルのオブジェクトは、Explicit VR Little Endian で無ければなりません。（Implicit はだめです）
11．DICOM ファイルのメタ情報は、Explicit VR Little Endian で無ければなりません。（Implicit はだめです）
12．ファイルメタ情報の版（0002.0001）は、0x00 バイト、次いで 0x01 バイトからなる 2 バイトの OB 値を_______________________________________________________________________________________________________________________________________________

105
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
持たねばなりません。16 ビッ little endian 短値としてコード化された 0x0001 ではありません。
13．ファイルメタ情報は、Media Storage Class UID （0002,0002）データ要素をもち、その値は、データ
組内の SOP Class UID に等しくなければなりません。
14．ファイルメタ情報は、Medaia Storage Instance UID （0002,0003）データ要素をもち、その値は、データ組内の SOP Instance UID に等しくなければなりません。
15． ファイルメタ情報に、私的要素を含んではなりません。
16． ファイルメタ情報のヘッダーには、属性（0002,0000） Group Length を含み、その正しい値がDICOM PS3.10 で規定された様に、入れられねばなりません。
17． DICOM CD-R の物理的フォーマットは、PS 3.12 に記された様に、ISO/IEC 10149 Part II 内の アプ
リケーション定義を守らねばなりません。媒体は以下の様に書かれます。
・Mode 1 sectors

あるいは・Mode 2, Form 1 Sectors で、CDROM-XA File Number = 0, Channel Number =0, Coding
Information Byte = 0_______________________________________________________________________________________________________________________________________________

106
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 F: 作成された媒体内容物の実例
例 F-1: 媒体は DICOM CT 画像、DICOM 表示条件と、DICOM 構造化レポートを含みます。媒体生成
役はインターネット内容物オプションに対応しており、媒体内 DICOM デ－タから作ったインターネット閲覧
ソフトで観察できるデータが含まれます。DICOM 観察ソフトも媒体に含まれます。

例 F-2: 媒体は DICOM US 画像、DICOM 構造化診断レポートを含みます。媒体生成役はインターネット
内容物オプションに対応していませんが、README.TXT ファイルはオプションとして入れます。媒体内
DICOM デ－タから作ったインターネット閲覧ソフトで観察できるデータは含まれません。

_______________________________________________________________________________________________________________________________________________

107
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 G: DICOM, WADO と web service 取得サービスの設定
G1: DICOM AE Title と DICOM AE Network Title
画像書類使用役が共有の目録で参照された DICOM インスタンスを、DICOM C-Move/C-Store で取得したい場合は、以下の設定が必要となります。

キーオブジェクト選択書類インスタンスには、AE タイトルが含まれますが、IP アドレスやその他の番号を含んではなりません。AE タイトルのみでは DICOM オブジェクトの取得に不足するので、画像書類使用役は
画像書類源の IP アドレス、AE タイトル、ポート番号、を現場施設の設定ファイルから取得します。
同様に、画像書類源は、DICOM オブジェクトの保存のため、画像書類使用役の IP アドレス、AE タイトル、
ポート番号、を必要とします。画像書類源は画像書類使用役の IP アドレス、AE タイトル、ポート番号、を現
場施設の設定ファイルから取得します。

このプロファイルでは、画像書類源と画像書類使用役の AE タイトルとネットワークアドレス（IP アドレス、
ポート番号）の対応は、関係するアクタ間で設定ファイルが、連携医療圏の方針と処理の誘導の元で、交換されることで可能になると想定されています。設定ファイルの交換方法はこのプロファイルの範囲外です。
将来は、DICOM 補遺 67 と、施設間での使用のための拡張により、この対応を自動化ができます。これは将来の IHE ITI 分野の統合プロファイル候補です。
IP アドレスとポート番号は AE タイトルから解決され値なりませんが、このプロファイルに含まれます。アクタの AE タイトルが、提携医療圏内で一意に割り付けられていることを確認しなければなりません。

G2: DICOM AE Title と WADO サービスのネットワークアドレスの対応付け
画像書類使用役が共有の目録書類で参照された DICOM インスタンスを、WADO 利用トランザクション（RAD-55）で取得したい場合は、SOP instance の WADO HTTP 要求-URI の樹立が必要になります。
SOP instance の特定情報は目録に完全に記載されていますが、画像書類使用役は、目録で参照された
SOP instance で特定されます。取得 AE タイトルと、サーバのネットワークアドレスとを対応させる、補助の方法が必要となります。この対応は WADO 取得サービスに必要です。
画像書類使用役には、提携医療圏内の全ての画像書類使用役サーバネットワークアドレスと取得 AE タイ
トルの対応設定を提携医療圏内で維持する必要があります。この対応をもちいて、目録内で参照された
SOP Instance の取得 AE タイトルは、WADO サービスのサーバーアドレスに変換され、SOP Instance 特定
情報、オプションの他の標準 WADO HTT パラメ－タと相まって、 WADO HTTP 要求-URI WADO サービスの樹立に使われます。
曖昧さの無い、自動的な、取得 AE タイトルと WADO 利用サービスサーバのネットワークアドレスの対応を実現するには、AE タイトルが提携医療圏内で一意に割り付けられていることを確認する方針が必要となり_______________________________________________________________________________________________________________________________________________

108
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________ます。

G3: DICOM AE Title と Web サービスのネットワークアドレスの対応付け
画像書類セット取得（RAD-69）トランザクションを使って、目録書類で参照された DICOM 十例を取得するには、画像書類使用役は、RepositoryUniqueId （保管庫固有 ID）属性を画像書類セット取得要求に入れなければなりません。

画像書類使用役には、提携医療圏内の全ての画像書類源のウェッブサービスアドレスと、取得 AE タイト
ルおよび・または取得位置 UID との、一覧を維持する必要があります。この対応を使用して、目録内で参照された SOP Instance の取得 AE タイトルは、RepositoryUniqueId に翻訳可能となります。
RepositoryUniqueId は画像書類セット取得要求に、書類固有 ID（documentUniqueId, SOP instance 特定情報）とともに、入れられます。あるいは、取得位置 UID （Retrieve Location UID）は画像書類セット取得
要求の中の RepositoryUniqueId として、直接に使用できます。
曖昧さの無い、自動的な、取得 AE タイトルとウェッブサービスアドレスの対応を実現するには、AE タイトル
が提携医療圏内（XDS Affinity Domain）で一意に割り付けられていることを確認する方針が必要となります。

_______________________________________________________________________________________________________________________________________________

109
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録: H ティーチングファイル構造化レポート目録のひな形例
ここにあるのは、DICOM PS 3.16 形式のひな形で、以下を含みます。
・ 節の見出（収納体の概念名）で、MIRC の、病歴、所見、考察、および、代替のコード、の概念を模した一塊のテキスト。
・ 節の見出（収納体の概念名）で、鑑別診断、診断、病理、解剖、臓器系などのコード体系の名称
・ 鑑別診断、診断、病理、解剖、臓器系のコード値の一群 （おそらく、SNOED +/- ICD9M, +/ACR index））
・診断確認フラグ

画像表示装置の上で、ティーチングファイルの完全なあるいは部分的な編集を行うための考えです。構想
は RSNA MIRC 書類図 16 版から得ました。
この雛形は、キーオブジェクト選定書類の、目録としての役割の複製ではありません。そのため、参照された含むべきインスタンスの一覧も、目録受信役が正しい使用者への届けるための観察者状況も、必要ありません。

_______________________________________________________________________________________________________________________________________________

110
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
付録 I: 識別子削除、識別子再付与、偽名化、識別子保持と臨床試験属性（情報的内容）
I. 1 識別子削除
インスタンスがいかに作成されたかの事前知識無しに、属性に含まれます。個人健康情報（PHI）をすべて取り除く、DICOM インスタンスの完全な個人識別情報削除には、書類を含む属性や私的属性の全てを削除する必要があります。以降の利用に必要な有益な情報が、書類値に含まれるため、これはしばしば非現実的です。

例えば、検査記述やシリーズ記述は、しばしば削除が望ましくない情報を含みます。検査記述やシリーズ
記述を、ティーチングファイルや治験のために、より意味のある、あるいは、より正確な記述に書き換える手段をあたえることが有益な場合もあります。例えば、情報が書かれいない場合に、”T1 強調造影後横断像”
や類似の記載をすることなどです。

日付と時間は、削除しても良いときと、しない方が良いときとがあります。例えば、来院日はある理由で削除するのが望ましいが、時刻は、検査の時間的順序を保持するために、削除しない方が良いことがあります。
他にも、治療の様な実世界でのインスタンスと関連させるために、日付は正確に保持されます。こともあります。

年齢と誕生日は特に問題です。これらは PHI の一部ですが、臨床試験の統計のために、あるいは、年齢が鑑別診断に影響します。ティーチングファイル例で意味のある読影のために、年齢が必要なこともあります。典型的な方法は、年齢を年代に変更する、日時を同じ月の初日にそろえる、等です。しかし、このような方法の有効性については、専門家の意見が必要です。

さらに、施設の方針、あるいは地域の規制により、PHI を削除する固有の要求事項が加えられることがあります。この要求事項が異なっているすべての使用例において、どの属性を削除すべきかを標準化することは可能でも、望ましいことでも、ありません。

極端には、識別情報削除のため、画像データにノイズを加える、顔貌を削除する、などがおこなわれます。
これはあったとしても希なことで、IHE の範囲外です。

I. 2 繰り返し送出での識別子一貫性
識別情報を、可逆的、ないし、非可逆的に新しい識別情報に入れ替えるアルゴリズムを、暗号化一方向性
隠蔽関数に基づき工夫することは可能ですが、可能な全ての入力値（施設の全患者の氏名と ID など）を入手できる人は誰でも、短時間の網羅的検索で同定できてしまいます。したがってこのような機構は、施設外への配布には有効な識別子削除であっても、施設内では十分とは言えません。

代替策として、対応表を長期にわたり（データベースの様に）保持し、次回もそのレコードを参照することがあります。しかし、このような記録は良く保護されねばなりません。

_______________________________________________________________________________________________________________________________________________

111
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
同じ理由で、監査のためのデータ送出の場合には、監査追跡記録に、元の識別情報と置き換えた識別情報の両方が含まれないようにしないとなりません。

可逆的方法も、元の識別情報を保持することを許可された人物がいる場合には、ある場合には有益なことがあります。これを達成する方法は IHE では定義されていませんが、上述の対応表の長期保存方法や、
DICOM 2011 PS 3.15 Basic Application Level Confidentially Profile で記載された暗号化埋込元属性が、使用できます。

不可逆の、しかし、反復可能な対応付は、ティーチングファイルに追加情報が使用可能になった時、後日更する場合には有用です。例えば、経過観察検査やレポート、病理情報が、同じ”偽名”の識別子が使用されます。ため、自動的に同じティ－チングファイルに加えられ、自動的にティーチングファイルの一部になります。

I. 3 臨床試験属性の付加
DICOM は臨床試験のために、複合 SOP Instance に付加可能な、追加のオプション属性を定義しています。これは、PS 3.3 の臨床試験対象、臨床試験検査、臨床試験シリーズモジュールです。
これらの属性は、以下を提供します。
・ 患者識別を強化する個人識別情報、例えば、臨床試験手順 ID, 臨床試験施設 ID、臨床試験
対象 ID、の組み合わせです。
・ 他の、試験特異的識別情報で臨床試験業務流れに有用で、患者を識別する情報ではありません。例えば、臨床試験時点 ID です。
これらの情報がデータ送出時までに知られている範囲で、データ欄（field）を埋めることが望ましいです。

多くの下流のシステムはこれらの属性を意識しないため、正常の DICOM 患者および他の識別情報を、臨床試験識別情報に入れ替えることがあります。例えば、臨床試験手順 ID, 臨床試験施設 ID、臨床試験対象 ID を挿入するのみならず、患者 ID を臨床試験対象 ID で、連続表記患者氏名を臨床試験手順 ID・臨
床試験施設 ID・臨床試験対象 ID で、施設名を臨床試験施設 ID で、それぞれ置き換えることがあります。
再対応付けオプションはこれらの値を自動的に埋こむ機能を与えます。

_______________________________________________________________________________________________________________________________________________

112
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.

IHE Radiology Technical Framework, Volume 3: Integration Profiles_______________________________________________________________________________
用語表
RAD TF-1: 付録 E - 用語一覧を参照してください。

_______________________________________________________________________________________________________________________________________________

113
Rev. 11.0 Final Text - 2012-07-24

Copyright © 2012: IHE International, Inc.