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

IHE 放射線
5

テクニカルフレームワーク
第 2x 巻
トランザクションへの付録
第 19.0 版 － 最終版
2020 年 9 月 18 日

10

IHE RAD TF-2x
Volume 2x
IHE RAD TF-2x
Appendices to Transactions
Revision 18.0 – Final Text

15

September 18, 2020
この和訳は、コンピュータ通信専門家でない医療関係者などが IHE を理解するために作成された参考資料です。専門用語は内容の理解が容易になるよう、医療での慣用を考慮して、日本語訳を改めたものがあります。
IHE 認定技術者試験の学習に使用できますが、同試験では IHE, HL7, DICOM 用語（統合
プロファイル・アクタ・トランザクション名称、属性など）には原語や英語頭文字略語を使用す
ることにご留意ください。同様に技術者との討論では、IHE, HL7, DICOM 用語には原語や英語頭文字略語を使用してください。
コンピュータ通信専門家には、この訳が IHE に含まれる医療環境の理解に役立つと思われます。

Copyright ©2020: IHE International, Inc.

20

目次
付録 A: 撮影装置業務一覧、複合 IOD、診療根拠書類、KIN、撮影装置施行検査段階の間における属性の整合性 ..................................................................................................................................................... 5
A. 1: 画像収集の統合に重要な属性 IMAGE ACQUISITION INTEGRATION-CRITICAL ATTRIBUTES...............5
A. 2: 診療根拠書類統合

25

重要な属性 EVIDENCE DOCUMENTS INTEGRATION - CRITICAL ATTRIBUTES 28

A. 3: 使用状況に必須の属性（CONTEXT-CRITICAL ATTRIBUTES） ......................................................... 31
A. 4: 一貫性データモデル ........................................................................................................................ 32
A. 5: 取り込まれた対象物の統合 - 必須の属性 ...................................................................................... 3530

付録

B: HL7 オーダの DICOM MWL への対応付け

HL7 ORDER MAPPING TO DICOM MWL ........ 45

付録

C: 放射線医学以外の情報の部門利用 DEPARTMENTAL ACCESS TO NON-RADIOLOGYINFORMATION ..................................................................................................................................... 57
C. 1: 範囲 ................................................................................................................................................. 57
C. 2: 問合せプロトコル ........................................................................................................................... 58
C. 3: 外部レポートの内容........................................................................................................................ 61
付録 D: 融合の場合の患者 ID の明確化 ............................................................................................... 6235

D. 1: はじめに ........................................................................................................................................ 62
D. 2: 管理事務の処理流れ（RAD TF-1:3.3.1） ...................................................................................... 63
D. 3: 患者情報融合（PATIENT MERGE） （RAD TF-1:3.3.2） .............................................................. 64

40

D. 4: 外傷ケス 1 と 2 （RAD TF-1:4.3） ............................................................................................ 65

D. 5: 外傷ケス 3 （RAD TF-1:4.3) ..................................................................................................... 66

D. 6 外傷ケ ス 4（RAD TF-1:4.3） ...................................................................................................... 69
D. 7: 外傷ケス 5 （RAD TF-1:4.3） ................................................................................................... 71

付録 E: DICOM 媒体交換－不可欠な DICOM 互換性のコツ

DICOM MEDIA INTERCHANGE -CRITICAL DICOM COMPATIBILITY TIPS............................................................................................. 74
付録 F: 作成された媒体内容物の実例

45

EXAMPLE CREATED MEDIA INSTANCE CONTENT ............... 76

付録 G: DICOM, WADO と WEB SERVICES 取得サービスの設定 CONFIGURATION FOR ACCESSINGDICOM, WADO AND WEB SERVICES RETRIEVE SERVICES ............................................................ 77
G.1: DICOM AE TITLE と DICOM AE NETWORK TITLE の対応付け ........................................................... 77
G.2: DICOM AE TITLE と WADO サービスのネットワークアドレスの対応付け ..................................... 78
G.3: DICOM AE TITLE と WEB サービスのアドレスの対応付け .............................................................. 7850

付録: H 教育ファイル構造化レポート目録のひな形例 EXAMPLE TEMPLATE FOR TEACHING FILE
STRUCTURED REPORT MANIFESTS ...................................................... 80

付録 I: 識別情報削除、識別子再付与、偽名化、識別子保持と臨床試験属性（情報的内容） DEIDENTIFICATION, RE-IDENTIFICATION, PSEUDONYMIZATION, PERSISTENCE OF IDENTIFICATIONAND CLINICAL TRIAL ATTRIBUTES (INFORMATIVE)......................................... 84

55

I. 1 識別情報削除 DE-IDENTIFICATION .................................................................................................... 84
I. 2 繰り返し送出での識別子一貫性....................................................................................................... 85
I. 3 臨床試験属性の付加 ADDITION OF CLINICAL TRIAL ATTRIBUTES........................................................ 8660

付録 J: 臨床判断支援（CLINICAL DECISION SUPPORT, CDS）、および、適切使用基準（APPROPRIATE USE CRITERIA, AUC）
CLINICAL DECISION SUPPORT (CDS) AND
APPROPRIATE USE CRITERIA (AUC) DATA EXPLANATION .................................. 87
付録 K: 読み込み整合性業務流れでの読み込み指示取扱いオプション（ IMPORT RECONCILIATIONWORKFLOW IMPORT INSTRUCTION HANDLING OPTION） .................................. 87

65

付録 L: 後処理業務流れでの汎用業務リスト、 SPS、PPS、および、結果複合 IOD 属性の整合
ATTRIBUTE CONSISTENCY BETWEEN GENERAL PURPOSE WORKLIST, SPS, PPS ANDRESULTING COMPOSITE IODS IN POST-PROCESSING WORKFLOW ......................... 88
L. 1: 統合に不可欠の属性 INTEGRATION-CRITICAL ATTRIBUTES ................................................................. 88
付録 M: レポート業務流れでの汎用業務リスト、SPS、PPS および結果の複合 IOD の整合（以前の第三巻付録 D）......................................................................................................................................... 91
M. 1: 統合に不可欠の属性 INTEGRATION-CRITICAL ATTRIBUTES ................................................................ 91

70

APPENDIX N. HL7 V2.5.1 で置き換えられる HL7 V2.3.1 通信文の概要（以前の第二巻付録 E） HL7
VERSION 2.3.1 MESSAGE FIELD REPLACED WITH HL7 VERSION 2.5.1 SUMMARY (PREVIOUSLY
VOL 3 APPX E) ..................................................................................................................................... 95
N. 1: PATIENT REGISTRATION [RAD-1]/ PATIENT UPDATE [RAD-12] ........................................................... 95
N. 2: PLACER ORDER MANAGEMENT [RAD-2]/ FILLER ORDER MANAGEMENT [RAD-3] .............................. 95

75

N. 3: PROCEDURE SCHEDULED [RAD-4]/PROCEDURE UPDATE [RAD-13] .................................................. 95
APPENDIX O: REASON FOR PROCEDURE CODE

SETS (INFORMATIVE) ..................................... 96

APPENDIX P: HL7 V2 ORU FOR EXTERNAL PRIOR REPORTS MAPPING ....................................... 96
APPENDIX Q: ORGANIZATION OF SERIES AND IMAGES INTO FRAMESETS ................................. 96
APPENDIX R; 意図的に空白です ......................................................................................................... 97

80

APPENDIX S: 意図的に空白です .......................................................................................................... 97
APPENDIX T: 意図的に空白です .......................................................................................................... 97
APPENDIX U: 意図的に空白です ......................................................................................................... 97
APPENDIX V: ATTRIBUTE CONSISTENCY BETWEEN UPS AND RESULTING COMPOSITE IODS .. 97
APPENDIX W: ORGANIZATION OF SERIES AND IMAGES INTO FRAMESETS................................. 97

85

日本語訳
Rev. 19, 2020 日本ＩＨＥ協会放射線企画委員会 本田憲業

2021/1/9

付録 A: 撮影装置業務一覧、複合 IOD、診療根拠書類、KIN、撮影装置施行検査段階の間における属性の整合性
この付録は IHE テクニカルフレームワークの不可分の一部を構成するものです。これは、IHE がDICOM 定義の属性一貫性（Annex J 、PS.3.17、DICOM 2006 年以降；以前： Annex M、PS3.4）を採用したことを反映しています。
この付録は次の四つの節から構成されています。







最初の節には、画像収集（image acquisition）に関連する DICOM PS.3.17, Annex J の、
IHE の明確化、追加、および、まとめが含まれています。IHE では、撮影装置（Acquisition Modality）はこの表で定義された属性対応付けを、トランザクション RAD6、RAD-7、RAD-20、RAD-21 で、撮影装置業務一覧（MWL）、各種 IOD Storage、および PPS SOP Class を実装する際に使用可能とすることを要求しています。IHE は DICOM
要求事項の一部を言い換えたり拡張するとともに、DICOM が与えたいくつかの選択肢を選んだり、あるいは、DICOM 推奨を強化します。さらに追加の二、三の IHE 勧告も定められています。
2 番目の節は、診療根拠書類（Evidence Document）と撮影装置（Acquisition Modality）で生成された、DICOM SR にもとづく診療根拠対象物（Evidence Object）の一貫性のための属性対応付けを定義しています。DICOM SR 対象物（DICOM SR objects）は既存の画像にもとづいて生成され、生成する新しい診療根拠書類（Evidence Document）に入れる値を提供します。
3 番目の節は DICOM C-FIND Return Key 属性の整合性に対し、IHE の追加要求事項を定義しています。
4 番目の節は、実体（entity）と一貫性に関連する属性の実世界データモデルを紹介しています。本書の読者には、このデータモデルを RAD-TF-1:3.4 節の記載事項とともに使用することを推奨します。このデータモデルは理解を助けるためのものであり、いかなる追加 IHE 要件も導入するものではありません。

A. 1: 画像収集の統合に重要な属性 Image Acquisition Integration-critical Attributes
以降の複数の表は画像収集（image acquisition）の例で、整合性が重要な属性の、要求事項、推奨、説明を記述しています。これらは 4.6.4.1.2.3 節で記述した PPS 例の予定および施行検査段
階（Scheduled and Performed Procedure Steps）を正しく関連付けるために、統合に重要な属性（integration-critical attributes）のどれを等しくすべきか（コピーするか現場で生成するか）を定義しています。
一般的な表の構造:
 第 1 列は DICOM 属性を示し、DICOM 対象物の間で対応付けせねばなりません（同じになるべき値が表の同じ行に示してあります）。DICOM 属性タグが明確化の為に示してあります。

 第 2 から第 4 の列はその属性がどこから来るかを示します。一つの表の行の、すべての定義された属性値は等しいです。
これらの列は左から右に向かって読まれます：撮影装置業務一覧（MWL）戻り値（第 2 列）は存在するのであれば Image/Standalone または MPPS IOD にコピーされる源の値として使用されねばなりません。
 撮影装置業務一覧列（MWL 列）は、記述される例が撮影装置業務一覧（MWL）戻り値を含んでいないか、表を単純化する（例えば Table A.1-3 の追加例（Append Case）やTable A.1-5 の群化例（Group Case））か、のため省略されています。
個別欄（Cell）内容の表記規則:
















表の個別欄（Cell）の"Source" は、表の列で定義され（たとえば MWL）、かつ、一個のアクタ（actor）で生成された DICOM 対象物は、DICOM 属性のこの値の源で、他の一個のアクタ（actor）が自身の対象物（たとえば、画像や MPPS）の値として埋めるべきであることを意味します。
表の個別欄（Cell）の"Copy" は、対応する別の一個の DICOM 対象物の属性から、表の列で定義された様に、コピーしなければならないことを意味します。
"Copy from: <DICOM Attribute>"は、同じ行の DICOM 属性を元の値として使用するのでなく、参照された DICOM 属性を源の値として使用せねばならないことを意味します。
表の個別欄（Cell）の"Equal"は 、アクタ（actor）は既に（例えば同じ内容の前回の実施
記録から）その値を知っていることを意味します。よって値が生成される条件は無視できます。
表の個別欄（Cell）の"Equal (internally generated)"は、アクタ（actor）は複数の DICOM
対象物に使われるかも知れない値を、他のアクタ（actor）から入手せずに（すなわち、コピー無し）、内部的に生成することを意味します。
表の個別欄（Cell）の"Equal (copied from MWL)" は撮影装置業務一覧問合せ（MWL
Query）結果からすでに判っている、追加例（append case）の同じ予定検査段階（SPS）
から入手した値を使わねばならないことを意味します。
表の個別欄（Cell）の"Source-1"、"Copy-1"、"Equal-1"などは、表の一行に数個の源がある場合の、該当の対応する属性です。
表の個別欄（Cell）の"See (IHE-X)"は、 対応する属性について追加の要求、推奨、説明が表の注の IHE-X にあることを示します。さもなければ、個別欄（Cell）に収まる程度の説明文が提供されます。
表の個別欄（Cell）の"n.a." は属性または値が存在してはならないことを意味します。
DICOM 規格では属性が定義されていないか、または、特殊な順列属性が DICOM のType 3 の属性であって DICOM が少なくとも一つの順列項目が存在することを要求しているか、です。

アクタ（actor）の挙動:
 "Modality Worklist"列の属性は MWL SCU（撮影装置（Acquisition Modality））により、
C-FIND Request の戻りキーとして要求されます。 部門システム予定役（Department
System Scheduler）は Modality Worklist C-FIND response で、属性値を返さねばなりません。詳細は Table 4.5-3 を参照してください。
 MWL 返り属性の値は、元の値として使用可能ならば、複合インスタンスと MPPS イン
スタンスに対応する両方の行に示される属性を埋める際に、撮影装置（Acquisition
Modality）によって使われねばなりません。
 MWL の値が存在しない（n.a）場合は撮影装置（Acquisition Modality）が内部で適切な値を生成する必要があります。
 施行検査段階管理役（PPSM）、画像管理役（Image Manager）、部門システム予定役（Department System Scheduler）の役割は、"MPPS IOD"列に対応する行に示された属性
を、SCP タイプと追加の注に従って、処理できなくてはなりません。
 部門システム予定役（Department System Scheduler）は、検査予定通信文(RAD TF2:4.4.4.1) の ZDS-1 （HL7 v2.3.1 通信文の意味）、あるいは、 IPC-3 （HL7 v2.5.1 通信文の意
味）からの Study Instance UID を、Referenced Study Sequence (0008,1110) の単一項目（Item）の SOP Instance UID (0008,1155) 属性にコピーせねばなりません。 この様な項目（Item）のSOP Class UID は “1.2.840.10008.3.1.2.3.2”でなければなりません。
 MPPS インスタンス（MPPS Instance）に空の Referenced Study Sequence (0008,1110)があるときは、未予定例（予定検査段階が使われない）であることを示します。
注： Referenced Study Sequence (0008,1110)の一項目（Item）の値は、DICOM 規格のこの順列の意図のとおりに Detached Study Management （退役しました） の SOP Instance の問合せ・取得に使用しては、なりません。 Detached Study Management SOP Class UID(1.2.840.10008.3.1.2.3.2)の使用は、SOP Instance UID が Study Instance UID であることを示すための印と意図されています。
表 A-1: 単純例 － 対応する属性の必須の対応付け
Table A.1-1: Simple Case - required mapping of corresponding attributes
単純な通常例では、検査段階（Procedure Step）は以下のように実行されます

予定通りに行われる



予定とは違うが、予定取り直しなし、例えば、造影剤のアレルギーによる場合。







（IHE-A.1.1）この属性に対して信頼できる値が一つもない場合は、データ長 0 のアクセッション番号（Zero Length Accession Number）（DICOM 規格 PS3.17 Annex J で提案されているオプションの一つ）が生成されるべきです。 信頼できる値とは用手データ入力以外の手段
によって伝達されたもので、例えば Accession Number を含む撮影装置業務一覧（Modality
Worklist）を経由してオーダ実施役（Order Filler）から、もしくはバーコードリーダから得られた値に基づくもの、です。
（IHE-A.1.2） 施行検査段階 ID（Performed Procedure Step ID）は撮影装置（Acquisition
Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる施行検査段階が同じ ID を共有しても構いません（例：他の撮影装置（Acquisition
Modality）で生成されていることがあります）。この ID は受信側システムが、信頼性を持って、関連する要求検査（Requested Procedure）および予定検査段階（SPS）を施行検査段階（PPS）と結びつけることを可能にしません。Scheduled Attributes Step Sequence の内容を詳細にチェックしなければ 、同じ値の施行検査段階 ID（PPS ID）をもつ二つの施行検査段階（SPS）が同じ予定検査段階（SPS）・要求検査を完遂すると見なせるほどの信頼性はありません。
（IHE-A.1.3）撮影装置（Acquisition Modality）アクタ（actor）が MPPS を使用可能とする場
合は、施行検査段階 SOP インスタンス UID（PPS SOP Instance UID）を含む、参照施行検査
段階順列（Referenced Performed Procedure Step Sequence (0008,1111)）が、含まれねばなりません。（DICOM PS3.3 、C.7.3 節の強い要望、General Series Module Table、Note 1 による）







（IHE-A.1.4）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected SOPClass UID (0000,0002)内で、PPS N-Set 通信文には Requested SOP Class UID (0000,0003)内で、SOP Class UID が送られます。SOP Class UID (0008,0016)は使ってはなりません。
（IHE-A.1.5）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected SOP
Instance UID (0000,1000)内で、PPS N-Set 通信文には Requested SOP Instance UID (0000,1001)内で、SOP Instance UID が送られます。SOP Instance UID (0008,0018)は使ってはなりません。
(IHE-A.1.6) 機関識別オプション（Enterprise Identity Option） を使用可能とする撮影装置（Acquisition Modalities）は、RAD TF-2: 4.6.4.1.2.5 と RAD TF-2: 4.8.4.1.2.5 を見てください。. 機関
識別オプション（Enterprise Identity Option） を使用可能とする、診療根拠書類生成役（Evidence
Creators） は、 RAD TF-2: 4.18.4.1.2.6 と RAD TF-2: 4.20.4.1.2.4 を見てください。.
表 A.1-2: 未予定例 - 対応する属性の必須の対応付け
Table A.1-2: Unscheduled Case - required mapping of corresponding attributes

（IHE-A.2.1）施行検査段階 ID（Performed Procedure Step ID）は撮影装置（Acquisition
Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異な









る施行検査段階 ID が同じ ID を共有しても構いません。（例：既に他の撮影装置（Acquisition Modality）で生成されている場合）（IHE-A.2.2）撮影装置（Acquisition Modality）アクタ（actor）が撮影装置施行検査段階（MPPS）を使用可能とする場合は、施行検査段階 SOP インスタンス UID（PPS SOPInstance UID）を含む参照施行検査段階順列（Referenced Performed Procedure Step Sequence(0008,1111)）が、含まれねばなりません。（DICOM PS3.3 節 C.7.3 の強い要望、General
Series Module Table, Note 1 による）
（IHE-A.2.3） 撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected
SOP Class UID (0000,0002)の中で、PPS N-Set 通信文には Requested SOP Class UID(0000,0003)の中で、SOP Class UID が送られます。SOP Class UID (0008,0016)は使ってはな
りません。
（IHE-A.2.4）撮影装置施行検査段階（MPPS）においては、PPS N-Create 通信文にはAffected SOP Instance UID (0000,1000)のなかで、PPS N-Set 通信文には Requested SOP
Instance UID (0000,1001)のなかで、SOP Instance UID が送られます。SOP Instance UID(0008,0018)は使ってはなりません。
(IHE-A.2.5) 機関識別オプション（Enterprise Identity Option）を使用可能とする撮影装置（Acquisition Modalities）は、RAD TF-2: 4.6.4.1.2.5 と RAD TF-2: 4.8.4.1.2.5 を見てください。
表 A.1-3:

単純・通常例への追加 - 対応する属性の必須の対応付け

Table A.1-3: Append to a Simple/ Normal Case - required mapping of corresponding
attributes
単純な例と同じように、最初の施行検査段階（PPS）は予定検査段階（SPS）に対する応答として生成されます。その他の施行検査段階（PPS）は以降に追加されます。例えば、いくつかの画像の品質が受け入れられない場合です。







（IHE-A.3.1）この属性に対して信頼できる値が一つもない場合は、データ長 0 アクセッション番号（Zero Length Accession Number）（DICOM 規格 PS3.17 Annex J で提案されているオプションの一つ）が生成されるべきです。 信頼できる値とは用手データ入力以外の手段
によって伝達されたもので、例えばクセッション番号（Accession Number）を含む撮影装置
業務一覧（Modality Worklist）を経由してオーダ実施役（Order Filler）から、もしくはバー
コードリーダから、得られた値に基づくものです。
（IHE-A.3.2） 施行検査段階 ID（Performed Procedure Step ID）は撮影装置（Acquisition
Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる施行検査段階 ID が同じ ID を共有しても構いません（例：他の撮影装置（Acquisition
Modality）で生成されてことがあります）。この ID は受信側システムが、信頼性を持って、関連する要求検査（Requested Procedure）および予定検査段階（SPS）を施行検査段階（SPS）と結びつけることを可能にしません。予定属性段階順列（Scheduled Attributes Step
Sequence）の内容を詳細にチェックしなければ 、同じ値の施行検査段階 ID（PPS ID）をもつ二つの施行検査段階（SPS）が同じ予定検査段階（SPS）・要求検査を完遂すると見なせるほどの信頼性はありません。
（IHE-A.3.3）追加例で生成された画像 IOD には、スタディ日付（Study Date）とスタディ時
刻（Study Time）とに、追加先の画像から得た、対応する値が再使用されねばなりません。









（IHE-A.3.4）撮影装置（Acquisition Modality）アクタ（actor）が MPPS を使用可能とする場
合は、PPS SOP Instance UID を含む Referenced Performed Procedure Step Sequence (0008,1111)が、含まれねばなりません。（DICOM PS3.3 、C.7.3 節の強い要望、General Series Module
Table, Note 1 による）
（IHE-A.3.5）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected SOP
Instance UID (0000,1000)内で、PPS N-Set message には Requested SOP Instance UID (0000,1001)
内で、SOP Instance UID が送られます。SOP Instance UID (0008,0018)は使ってはなりません。
（IHE-A.3.6）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected SOP
Instance UID (0000,1000)のなかで、PPS N-Set 通信文には Requested SOP Instance UID(0000,1001)のなかで、SOP Instance UID が送られます。SOP Instance UID (0008,0018)は使ってはなりません。
（IHE-A.3.7）機関識別オプション（Enterprise Identity Option） を使用可能とする撮影装置（Acquisition Modalities）は、RAD TF-2: 4.6.4.1.2.5 と RAD TF-2: 4.8.4.1.2.5 を見てください。

もし、施行検査段階（SPS）と関連する画像が群化例（Rad TF-2, 4.6.4.1.2.3.3 節参照）に追加されるな
ら、たとえば、群化された MR 頭部と頸部の検査に、3D 後処理診療根拠を追加する場合、単純な例に追加することと比較して、追加された画像と撮影装置施行検査段階（MPPS）について、以下の条件を考慮せねばなりません。
 追加された画像と施行検査段階（SPS）の Study Instance UID (0020,000D)は、追加先の群化された画像の Study Instance UID と同じ値を持たねばなりません。
 群化後の予定検査段階（SPS）が同じアクセッション番号（Accession Number）を持たない
場合はアクセッション番号（Accession Number） (0008,0050)は空白であること。
 追加された画像の参照スタディ順列（Referenced Study Sequence ）(0008,1110)は群化された要求検査（Requested Procedure）と同じ数の順列項目（sequence items）を含むこと
 追加された画像の要求属性順列（Request Attributes Sequence） (0040,0275)は群化された予定検査段階（SPS）と同じだけの数の順列項目（sequence items）を含むこと。
 追加された画像と関連する予定段階属性順列（Scheduled Step Attributes Sequence）(0040,0270)は群化された予定検査段階（SPS）と同じ数の順列項目（sequence items）を含むこと。
 施行プロトコルコード順列（Performed Protocol Code Sequence）(0040,0260)は多くの場合、元の群化された画像とは異なる値を持つことになります。
 システムが予定されたものと生成されたものとの同一性を確認できるのであれば、追加された画像と関連する撮影装置施行検査段階（MPPS）の検査コード順列（Procedure Code
Sequence）(0008,1032) は、要求検査（Requested Procedure）に有る異なる検査コード（Procedure Code）の数だけの項目を含むことが推奨されます。撮影装置業務一覧（Modality Worklist）で検査コード順列（Procedure Code Sequence）がない場合や実施された
画像収集が予定されたものと異なる場合は、これは空白にしておくことが推奨されます。

表 A.1-4：群化例（3 個の SPS が 2 個の要求検査に属する）- 対応する属性の必須の対応付
Table A.1-4: Group Case (3 SPSs belonging to 2 Requested Procedures) - required
mapping of corresponding attributes
このシナリオは最初の要求検査はひとつの施行検査段階（SPS）を持ち、二番目の要求検査が二つの施行検査段階（SPS）を持つ場合です。（RAD TF-2: 4.6.4.1.2.3.6 節の図に示すような群化）
注：群化例に追加する施行検査段階（SPS）を生成する場合、撮影装置（Acquisition Modality）アクタ（actor）は現在 DICOM で規定されていない追加の属性を記入する必要があります。これは要求されたもしくは計画された情報に関係しています。現在 DICOM に対してこの問題を解決するため、image IOD 内の要求属性順列（Request Attributes Sequence）と、撮影装置施行検査段階（MPPS）
内の予定段階属性順列（Scheduled Step Attribute Sequence）に、オプションの属性をそれぞれ追加する、訂正提案（Correction Proposal）が出ています（詳細は Rad TF-1x: B.2.2 参照してください）。









（IHE-A.4.1）施行検査段階 ID（PPS ID）は撮影装置（Acquisition Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる施行検査段階 ID が同じ ID を共有しても構いません（例：他の撮影装置（Acquisition Modality）で生成されていることがあります）。 この IDは受信側システムが信頼性を持って、施行検査段階（SPS）と関連する要求検査（Requested
Procedure）および予定検査段階（SPS）とを結びつけることを可能にしません。予定属性段階順列（Scheduled Attributes Step Sequence）の内容を詳細にチェックしなければ 、同じ値の施行検査段階
ＩＤ（PPS ID）をもつ二つの施行検査段階（SPS）が同じ予定検査段階（SPS）・要求検査を完遂すると見なせるほどの信頼性はありません。
（IHE-A.4.2） 撮影装置アクタ（Acquisition Modality actor）が撮影装置施行検査段階（MPPS）を使用可能とする場合は、PPS SOP Instance UID を含む Referenced Performed Procedure Step
Sequence (0008,1111) が含まれねばなりません。（DICOM PS3.3 節 C.7.3 の強い要望、General
Series Module Table, Note 1 による）
（IHE-A.4.3） 撮影装置施行検査段階（MPPS）、PPS N-Create 通信文では Affected SOP ClassUID (0000,0002) の中で、PPS N-Set 通信文では Requested SOP Class UID (0000,0003) の中で、SOP Class UID が送られます。SOP Class UID (0008,0016) は使ってはなりません。
（IHE-A.4.4）撮影装置施行検査段階（MPPS）、PPS N-Create 通信文では Affected SOP Instance
UID (0000,1000) のなかで、PPS N-Set 通信文では Requested SOP Instance UID (0000,1001) のなかで、SOP Instance UID が送られます。SOP Instance UID (0008,0018) は使ってはなりません。

表 A.1-5: PGP 群化例（3 個の SPS が 2 個の要求検査に属する）- 対応する属性の必須の対応付
Table A.1-5: Group Case with PGP (3 SPS belonging to 2 Requested Procedures) required mapping of corresponding attributes
TableA.1-4 の拡張として、このシナリオは同じ群化を基本にしています。最初の要求検査は一つの予定検査段階（SPS）を、2 番目の要求検査は二つの予定検査段階（SPS）を持つ場合です。
（4.6.4.1.2.3.6 節と同等の群化）この表は 群化例が、IHE の定める予定検査プロファイル（Scheduled Workflow Profile）の中で撮影装置群化群オプション（Modality Group Case Option）の一部として実施完了していることを仮定しています。これは GSPS を生成するアクタ（actor）（撮影装置（Acquisition Modality）など）と提示段階で生成される業務流れの施行検査段階（SPS）（すなわち段階の分割）の対応付けを記述します。従って、対応付けの入力は、先行する群化例収集（Group Case acquisition）の結果として生じた Image IOD に由来します（TableA.1-4 を参照してください）。
注：群化例に追加する施行検査段階（SPS）を生成する場合、撮影装置（Acquisition Modality）アクタ（actor）は現在 DICOM で規定されていない追加の属性を記入する必要があります。これは要求されたもしくは計画された情報に関係しています。現在 DICOM に対してこの問題を解決するための CP（image IOD 内の Request Attributes Sequence に、MPPS 内の Scheduled Step Attribute Sequenceに、それぞれオプションの attributes を追加する）が出ています（詳細は Rad TF-1, B.2.2 参照してく
ださい）。



（HE-A.5.1） 同一の画像サービス要求（Imaging Service Request）に付随する要求検査（Requested Procedures）に属する数個の予定検査段階（SPS）が群化された場合、GSPS の Accession Number には元の Accession Number (0008,0050)と Issuer ofAccession Number Sequence (0008,0051) がコピーされねばなりません。異なる画像サービス要求に付随する要求検査群に属する数個の予定検査段階（SPS）が群化された
場合、元の画像の Accession Number (0008, 0050) は IHE の群化プロファイルに従い空白が予想されます。よって（元の画像として同じ Study に属するわけだから）生成された GSPS の Accession Number (0008, 0050)も空白となります。

（IHE-A.5.2） 撮影装置施行検査段階（MPPS）対象物内のアクセッション番号（Accession Number）と関連するIssuer of the Accession Number Sequence は、画像とStandalone IODとGSPSのAccession Number（データ長0を含め）、または、関連する
Issuer of the Accession Number Sequence とは無関係に、撮影装置業務一覧（Modality
















Worklist）内のAccession Numberと関連するIssuer of the Accession Number Sequence 返
り値と等しくなければなりません。
（IHE-A.5.3） 推奨：値が不明の場合は空値です。もし Assisted Protocol Setting オプションが使用可能である場合（RAD TF-2: 4.6.4.1.2.4 参照）は、群化画像を分割したことを示す特定コードが書かれていて空でない値であることが推奨されます。
（IHE-A.5.4） 値が不明の場合はデータ長 0 とすべきです。例えば Assisted Protocol
Setting オプションが使用可能でない場合です。Assisted Protocol Setting オプションが使用可能な場合（RAD TF-2: 4.6.4.1.2.4 参照）は群化画像を分割したことを示す特定
コードが書かれていて空でない値であることが推奨されます。
（IHE-A.5.5） 施行検査段階 ID（Performed Procedure Step ID）は撮影装置（Acquisition Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる Performed Procedure Step ID が同じ ID を共有しても構いません（例：既に他の撮影装置（Acquisition Modality）で生成されています）。 この ID は受信側システムが信頼性を持って、施行検査段階（SPS）を関連する要求検査（Requested Procedure）および予定検査段階（SPS）に結びつけることを可能にしません。Scheduled Attribute Step Sequence の内容を確認しない限り、同じ施行検査段階
ID（PPS ID）を持つ二つの施行検査段階（SPS）が予定検査段階・要求検査（SPS/RP）の同じセットを完遂させるとは、信頼性を持って見なせません。
（IHE-A.5.6） PGP の"分割処理"内で生成される GSPS IOD 内で、検査日・検査時
刻・検査記述は追加先の元画像の値が流用されねばなりません。
（IHE-A.5.7） 撮影装置施行検査段階（MPPS）、PPS N-Create 通信文では Affected
SOP Class UID (0000,0002) 内で、PPS N-Set 通信文では Requested SOP Class UID(0000,0003) 内で、SOP Class UID が送られます。SOP Class UID (0008,0016) は使ってはなりません。
（IHE-A.5.8）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文の Affected
SOP Instance UID (0000,1000)内で、PPS N-Set message には Requested SOP Instance UID(0000,1001) 内で、SOP Instance UID が送られます。SOP Instance UID (0008,0018) は使ってはなりません。
（IHE-A.5.9） 撮影装置（Acquisition Modality）が撮影装置施行検査段階（MPPS）を使用可能とする場合は、PPS SOP Instance UID を含む Referenced Performed Procedure
Step Sequence (0008,1111)が、含まれねばなりません。（DICOM PS3.3 節 C.7.3 の強い要望、General Series Module Table, Note 1 による）
（IHE-A.5.10） 機関識別オプション（Enterprise Identity Option）を使用可能とする撮影装置（Acquisition Modality）では、RAD TF-2: 4.6.4.1.2.5 と RAD TF-2: 4.8.4.1.2.5.見てください。

A. 2: 診療根拠書類統合－重要な属性 Evidence Documents Integration - Critical Attributes
この章の表は前の章のものと似ていて、撮影装置（Acquisition Modality）は関係する画像の情報を確実に埋めるために撮影装置業務一覧（Modality Worklist）から必要な属性を、一貫性のある方法で利用します。同様に診療根拠書類統合プロファイル（Evidence Documents Integration
Profile）での診療根拠生成役（Evidence Creator）や撮影装置（Acquisition Modality）は、撮影装置業務一覧（Modality Worklist）を受信しませんが、DICOM SR Evidence Document の対応する値を確実に埋めるための入力として、予定にしたがい収集された画像から得た関連する情報を利用します。
注：SWF プロファイルでは診療根拠生成役（Evidence Creator）は画像を生成します。この例は画像収集追加例と考えることができます（Table A.1-2 参照してください）。
一般的な表構造:

第 1 列は DICOM 対象物間で値が対応付けされる DICOM 属性を示します（表の同じ行の値が等しくなります）。 DICOM 属性タグ（DICOM attribute tag）は明確化のために示されています。
第 2, 3 列は、異なる IOD で属性の値がどのように埋められるかを個々の属性について示します。
同じ行内では、列は左から右に読みます： Image/ Standalone IOD（第 2 列）が診療根
拠書類（Evidence Document (DICOM SR IOD)）へのコピー元として使われねばなりません。

個別欄（Cell）内容の規約:
A.1 節の関連する段落と同じ定義です。

アクタ（actor）の挙動:
 画像あるいは Standalone IOD からの値は、もし源の値として利用可能であれば、診療根拠生成役（Evidence Creator）あるいは撮影装置（Acquisition Modality）が、対応する行に示された診療根拠書類（Evidence Document）事例（instance）の属性を埋めるために使用されねばなりません。
表 A.2-1 は、診療根拠書類統合プロファイル（Evidence Documents Integration Profile）で、診療根拠生成役（Evidence Creator）あるいは撮影装置（Acquisition Modality）によって生成された新規の診療根拠書類（Evidence Document）に値を入れるために、異なるアクタ（actor）によって以前に生成された画像・Standalone IOD の値をどのように利用するかを示しています。
ここで、この対応表は予定された撮影から生成した画像にもとづいて診療根拠が生成される例に最も重要である点に注意します。さもなければ業務流れの統合に必須の属性の多くは、源の画
像／Standalone IOD で値が空白か不在となるでしょう。この表は診療根拠書類（Evidence
Document）が後処理作業流れ（Post-Processing Workflow）の結果として生成された場合を考慮していません。

（IHE-A.2-1.1） 診療根拠書類（Evidence Document）の生成が要求検査（Requested
Procedure）に関連する場合、この情報を Referenced Request Sequence (0040,A370) にも記入することが DICOM で規定されています。
（IHE-A.2-1.2） これは 未予定の画像収集の場合は存在しなくても構いません。
（IHE-A.2.1.3） 機関識別オプション（Enterprise Identity Option）を使用可能とする
診療根拠生成役（Evidence Creators）については、RAD TF-2: 4.18.4.1.2.6 を見てください。

A. 3: 使用状況に必須の属性（Context-critical Attributes）
この節は、戻りキー属性（Return Key Attributes）のなかで C-FIND 要求（C-FIND Request）に対応して提供された場合の、画像と standalone IOD に共通の、多数の状況に必須の属性（DICOM では 2型）に基づく追加の IHE 要求事項で、上記の表を拡張したものです。この表の内容は DICOM PS3.17
Annex J に厳密に準拠しています。

Modality Worklist

Images and Standalone IOD

MPPS IOD

Patient Name

Patient Name (note 1)

Patient Name (note 1)

Patient ID

Patient ID (note 1)

Patient ID (note 1)

Issuer of Patient ID

Issuer of Patient ID (note 3)

Issuer of Patient ID(Note 3)Issuer of Patient ID
Qualifiers Sequence

Issuer of Patient ID Qualifiers
Sequence (note 3)

Issuer of Patient ID
Qualifiers
Sequence (Note 3)

Patient’s Birth Date

Patient’s Birth Date (Note 2)

Patient’s Birth Date
(Note 2)

Patient ‘s Sex

Patient ‘s Sex (note 2)

Patient ‘s Sex (note 2)

Other Patient IDs Sequence

Other Patient IDs Sequence (Note 4)----

Referring Physician's Name

Referring Physician's Name (note 2)----

注 1：撮影装置（Acquisition Modality）に撮影装置業務一覧（Modality Worklist）を提供する部門
システム予定役・オーダ実施役（Department System Scheduler/Order Filler）が利用できない
場合、この属性はデータ長 0 でも構いません。IHE テクニカルフレームワークで定めた身元不明患者（Unidentified Patient cases）の例では、事前登録された患者 ID と患者氏名の値が使われます。
注 2：撮影装置業務一覧（Modality Worklist）サービスを提供する部門システム予定役・オーダ
実施役（Department System Scheduler/Order Filler）が利用できない場合、もしくは撮影装置業務一覧（Modality Worklist）からの返り値がデータ長 0 の場合は、これらの属性はデータ
長 0 となる場合があります。

注 3: 機関識別オプション（Enterprise Identity Option）については以下を見てくだい。
Acquisition Modality では、RAD TF-2: 4.6.4.1.2.5 と RAD TF-2: 4.8.4.1.2.5



Evidence Creator では、RAD TF-2: 4.18.4.1.2.6 と RAD TF-2: 4.20.4.1.2.4

注 4: 機関識別オプション（Enterprise Identity Option）では、Other Patient IDs Sequence は、情報が Modality Worklist item にあるなら、画像と Standalone IODs にコピーされねばなりません。
A. 4: 一貫性データモデル
この章は、実体（Entity）のデータモデルと、整合性に関連する属性とを紹介します。本書の読者には、このデータモデルをこの付録の第一節にある表とともに使用することを勧めます。このデータモデルは理解を助けることを目的としており、C.2 節に規定されている以外のいかな
る追加 IHE 要件も導入するものではありません。
実体（entity）は実線の長方形で表します。
二つの実体（entity）の関係を矢印または直線で表します。直線の場合、この関係を定義するために使用した属性はこのモデルでは説明されていません（一般によく理解されています）。矢印を使用した場合は以下の様です：


この関係を定義するために使用した参照された実体（entity）の属性は、矢印の根元のとなりにある長方形内の実体（entity）に示します（例えば、要求検査実体の Ref. St. Seq.
は、この実体（entity）を構想スタディ管理実体（Conceptual Study Management Entity）にリンクするために使われる）。
 参照された属性は矢印の先端に示され、同じく長方形長方形内にあり、中括弧でくくられます（例、{Study Instance UID}）。場合によっては、参照する属性が参照されたこの属性と異なる名前を持つことがあります。これは、DICOM のこのような属性の名前付け、
エンコード方法を反映しています。角括弧で囲まれた数字は、DICOM で定義されたデータ型です。
関係の起生数（Cardinality）は直線と矢印の両方に従って定義されます。
 実体（entity）間の関係の起生数（Cardinality）は直線と矢印の両方に沿って表されます。
矢印の方向は起生数（Cardinality）の定義に影響を与えません。この起生数（Cardinality）は実世界データモデルの実体（entity）間の起生数（Cardinality）を反映しています。DICOM 情報対象物定義データモデル（DICOM Information Object）は情報通信の状況でサポートされる実体（entity）間の関係を反映するものであることから、この起生数（Cardinality）は DICOM 情報対象物定義データモデル（DICOM Information
Definition data models Object Definition data models）のものとわずかに異なる場合があります。例えば、“I-Series to I-Composite”は、施行検査段階（SPS）が複合インスタンス（画像、GSPS など）を伴わないシリーズを含んでいることを示す 1 対 0--n 関係です。しかし、DICOM 保存サービスクラス（DICOM Storage Service Class）の状況では、シリーズは少なくとも一つの複合インスタンス（画像、GSPS など）を含んでいなければなりません。言い換えるならば、画像を伴わないシリーズは保存することはできないが、DICOM 施行検査段階（DICOM Performed Procedure Step）で定義することはできます。
太線の矢印は、参照する属性が UID（幅広い一意性）であり、細い線の矢印で示されるシンプル
ID ではないことを示しています。
このデータモデルでは、点線による長方形が二つ表示されます。


最初の長方形は、I-Patient、I-Study、I-Series、I-Composite という 4 つの実体
（entity）を群化します。これは、複合インスタンスがこれら 4 つの実体（entity）を群化して転送される（保存サービスクラス）という事実を反映するためです。これら 4 つの実体（entity）は DICOM 複合画像情報モデルによって定義されます（PS3.3、節 A.1.2 参照）。
二番目の長方形は、要求検査（Requested Procedure）と構想スタディ管理（Conceptual Study Management）という二つの実体（entity）を群化します。これは、この二つの実体（entity）が常に 1 対 1 の関係であることを反映しています。要求検査実体（Requested Procedure entity）とそれに関連付けられたもの（患者、画像
サービスリクエスト、予定検査段階、施行検査段階）は、撮影装置-IS インタフェー
スを目的に、実世界 DICOM モデル（DICOM Model of the Real World）によって定義されます（PS3.3、節 7.3 参照）。構想スタディ管理実体（Conceptual StudyManagement entity）は、この IHE テクニカルフレームワークの状況では唯一Referenced SOP Instance UID 属性（Reference Study Sequence に有り）のみである点で、特殊です。（使用中の Detached Management Study SOP Class のない）この概念
的検査分離検査実体（Conceptual Study Detached Study entity）は DICOM PS3.4 M.2 節で定義されます。

Figure A-1:

Data Consistency Model: Modality Worklist Information Model, Composite
IODs and Modality Performed Procedure Step IOD

図 A-1: データ一貫性モデル： 撮影装置業務一覧情報モデル、複合 IODs、および、施行検査段階
IOD

A. 5: 取り込まれた対象物の統合 - 必須の属性
取込み役（Importer）は現場医療機関からの必須の属性が取り込める様に、個々の DICOM 対象
物を修正せねばなりません。
以下の表は現場環境にデジタルメディアを取り込んだり、デジタル化された対象物を生成したりしたときの例について、統合に必須な属性の要求事項、推奨事項、説明を記述しています。
組織間でコードセット（Code Set）が統合されなければ、ひとつの組織内で使われている撮影手
順コード（Protocol Code）セットは多くの場合、他の組織の中では有効になりません。コードセットの強制統合規則やメカニズムは放射線テクニカルフレームワークの範疇外です。
一般的なテーブル構成:
 第 1 列は DICOM 対象物間で対応付けされるべき DICOM 属性（同じ行に等しい値）を示しています。 DICOM タグが明確化のために示されています。
 第 2 から第 5 列は属性の値がどこから来るかを示しています。テーブルの一行の属性値は同一となります。これらの列は左から右に読まれます。
 “Objects for Import”の名称の列は、取込まれるはずの対象物に、含まれる、もしくは、"抽出"される属性とその値を参照します。ハードコピーの取込の場合（例：デジタイザ取込）"抽出" 作業は OCR か、手入力かにより、付随する紙書類からか、もしくはその他の手段で行われます。この列に示される属性のすべてが存在しないこともあります。
 “Resultant IOD”の名称の列は取込作業の結果生じる対象物に含まれる属性と値を反映することを示します（取込まれる元データには関係有りません）。
 取込役が、DICOM 撮影装置業務一覧（Modality Worklist）応答によるのでなく、HL7
問い合わせ通信文（HL7 query message）により情報を入手する Unscheduled Case では、
撮影装置業務一覧（Modality Worklist）の列は Demographic Query Information と書かれた列で置き換えられます。
個別欄（Cell）内容の規則:
 表の個別欄（Cell）の中の" Source" は、このテーブルの列で定義される DICOM 対象物（DICOM object）（例：撮影装置業務一覧（MWL））で一つのアクタ（actor）が生成す
るものは、別のアクタ（actor）が自身の対象物（画像あるいは MPPS）に書き込む
DICOM 属性のこの値の源でなければならないことを意味します。
 表の個別欄（Cell）の中の"Copy"は、この値は、別の DICOM 対象物の対応する源の属性から、テーブルの列が規定する様に、コピーされることを示します。
 表の個別欄（Cell）の中の "Copy from: <DICOM attribute> "は、DICOM 属性の同じ行の属性を源にするのではなく、参照された DICOM 属性で指定された源からコピーすることを示します。
 表の個別欄（Cell）の中の" Equal" はアクタ（actor）がすでに値を知っている（例：以前に実施した動作によって）ことを示します。よって値の生成条件は関係しません。

 表の個別欄（Cell）の中の" Equal （internally generated）" は他のアクタ（actor）から値を受け取ることなく（すなわち、コピー無し）一つ以上の DICOM 対象物で使われる可能性のある値を内部ですでに生成していることを示します。
 表の個別欄（Cell）の中の"Source-1"、"Copy-1"、"Equal-1"、その他の表記は、複数の元となる値がテーブルの行に登場した場合にどれを使うかを示します。
 表の個別欄（Cell）の中の Copy-2 [Copy-1] は、Copy-2 に値が存在すれば Copy-2 からコ
ピーし、さもなければ Copy-1 からコピーすることを示します。
 表の個別欄（Cell）の中の" Merge Copy-1, Copy-2" は複数のデータ元からコピーした値が、結果として作成される属性にすべて含まれることを示します。 注：これは一部の複数値を持つ属性、もしくは順列の属性にのみ適用されます。
 表の個別欄（Cell）の中の"See (IHE-X)" はその属性と値が表の注釈（IHE-X）に示される、追加の要求事項、推奨事項、説明に従うことを示します。
 表の個別欄（Cell）の中の" n.a." はそのような属性や値が存在してはならないことを示します。その対象物について DICOM が属性を定義していないか、特定の順列属性は
DICOM 3 型の属性である場合で、DICOM が少なくとも一つの順列項目の存在を要求している場合です。
アクタ（actor）の挙動：
 一般的に取込みを行うアクタ（actor）（取込み役（Importer））の役割はオリジナルの対
象物への変更を最小限にすることです。受信する環境での識別情報整合性の確保のために必須である属性のみが修正されます。
 取込みを行うアクタ（actor）（取込み役（Importer））は第 2、第 3 列の値（"Objects forimport" および、"MWL return values" 、あるいは、Demographic Query Information）を源に、テーブルで定義した規則に従って Image/ Standalone または MPPS IOD へコピーせねばなりません。
 取込みを行うアクタ（actor）（取込み役（Importer））はメディアから読み込むインスタ
ンスが同一の Series, Study, Patient に属すると仮定してはなりません。一枚のメディアが複数の患者の情報を含む例もあり得ます。
 オリジナルの対象物（Objects）にあったが取込み作業によって入れ替えられた属性は、取り込まれた対象物（Objects）の"Original Attributes Sequence"に記録されなくてはなりません。
 撮影装置業務一覧（Modality Worklist）列にある属性は、C-FIND Request の戻りキーとして MWL SCU（取込み役（Importer））により要求されねばなりません。部門システム予定役（Department System Scheduler）は これらの属性値を Modality Worklist C-FIND の応
答で返さなくてはなりません。（詳細は RAD TF-2: Table 4.5-3 を参照）
 施行検査段階管理役（PPSM）、イメージ管理役（Image Manager）、部門システム予定役（Department System Scheduler）は 、SCP Type と追加の注で定義されたように、”MPPS
IOD”と書かれた列に示された属性を扱えなくてはなりません。最終的な形態は取込まれたインスタンスを表現する施行検査段階（SPS）情報を、結果として生成される施行検査段階（SPS）で使うことです。

表 A.5-1: 予定取込み―対応する属性の必須の対応つけ
Table A.5-1: Scheduled Import - Required Mapping of Corresponding Attributes （IHE-A.5-1.1） 施行検査段階 ID（Performed Procedure Step ID） は撮影装置（Acquisition Modality）によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる施行検査段階が同じ ID を共有しても構いません（例：既に他の取込役（Importer）生成されていることがあります）。施行検査段階 ID （Performed Procedure
Step ID）(0040,0253)はデータが非デジタルメディア（ハードコピーのデジタイズなど）
から取込まれた場合は存在しません。
 （IHE-A.5-1.2） 有効な DICOM UID は世界規模で一意です。それ故、現場施設の UID と重複する恐れはありません。有効な DICOM UID が存在する場合は、取込役（Importer）
はそれを使い、改変してはなりません。取込役（Importer）が、間違った UID や一貫性の疑われる UID を発見した場合は、取込役（Importer）はそれを修正するか、新たにUID を生成できます。UID は対象物間の参照のために使われるので、それが改変される
場合は取込役（Importer）が参照での統合性を保持しなくてはなりません。
 （IHE-A.5-1.3） この属性に対して信頼できる値が一つもない場合は、データ長 0 のアクセッション番号（Zero Length Accession Number、DICOM 規格 PS3.17 Annex J で提案されているオプションの一つ）が生成されるべきです。 信頼できる値とは用手データ入力以
外の方法で伝達できるもので、例えばアクセッション番号（Accession Number）を含む
撮影装置業務一覧（Modality Worklist）を介してオーダ実施役（Order Filler）から、もし
くはバーコードリーダから、得られた値に基づくものを含みます。
 （IHE-A.5-1.4） 撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected
SOP Class UID (0000,0002)の中で、PPS N-Set message には Requested SOP Class UID

(0000,0003) の中で、SOP Class UID が送信されます。SOP Class UID (0008,0016) は使ってはなりません。
 （IHE-A.5-1.5） 撮影装置施行検査段階（MPPS）、PPS N-Create 通信文では Affected SOP
Instance UID (0000,1000)の中で、PPS N-Set 通信文では Requested SOP Instance UID(0000,1001) の中で、SOP Instance UID が送信されます。SOP Class UID (0008,0018) は使ってはなりません。
 （IHE-A.5-1.6） 撮影装置業務一覧問合せトランザクション（Query Modality Worklist
transaction）(RAD TF-2: 4.5.4.1.2.2）に従い、部門システム予定役・オーダ実施役（Department System Scheduler/Order Filler） は、Study Instance UID 属性(0020,000D) とReferenced Study Sequence (0008,1110) 内の両方に Study Instance UID を複製する必要があります。
 （IHE-A.5-1.7） 医療機関で使われている記述とコードは診療根拠書類（Evidence
Document）で使われているものと一致しない可能性があります。それらを強要する手段
はテクニカルフレームワークの範囲外です。診療根拠書類（Evidence Document）から得られるコードと詳細は有益な場合もあることを注記します。
 （IHE-A.5-1.8） Referenced Study Sequence (0008,1110) は非デジタルメディア（例：ハードコピーのデジタイズ）の場合は提供されません。
 （IHE-A.5-1.9） 医療機関内で使われている Performed Protocol Code は診療根拠書類（Evidence Document）で使われているものと一致しない可能性があります。それらをコピーするか、強要するか、削除するかの決定は、テクニカルフレームワークの範囲外です。診療根拠書類（Evidence Document）から得られるコードは有益な場合もあることを注記します。
 （IHE-A.5-1.10） RAD TF-4.59.4.1.2.3 を参照してください。予定取込（Scheduled Import）
に関する情報が存在しない場合、これは内部で生成され、Performed Protocol Sequence 内の項目の一つとして含まれねばなりません。医療機関内で使われている Performed
Protocol Code は診療根拠書類（Evidence Document）で使われているものと合致しない可
能性があります。それらを融合するか、強要するか、廃棄するかの決定は、テクニカル
フレームワークの範囲外です。診療根拠書類（Evidence Document）から得たコードが有益な場合もあることを注記します。
表 A.5-2：未予定取込み―対応する属性の必須の対応つけ
Table A.5-2: Unscheduled Import - required mapping of corresponding attributes









（IHE-A.5-2.1） 施行検査段階 ID（Performed Procedure Step ID）は取込役によって便宜的に生成され、必ずしも一意である必要はありません。二つの異なる施行検査段階 ID
が同じ ID を共有しても構いません（例：既に他の取込役で生成されていることがあります）。
（IHE-A.5-2.2）施行検査段階 SOP インスタンス UID（PPS SOP Instance UID SOP）を含
む Referenced Performed Procedure Step Sequence (0008,1111)が含まれなくてはなりません。（DICOM PS3.3 節 C.7.3 の強い要望、General Series Module Table, Note 1 による）
（IHE-A.5-2.3） 撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文にはAffected SOP Class UID (0000,0002)のなかで、PPS N-Set 通信文には Requested SOP ClassUID (0000,0003) のなかで、SOP Class UID が送られます。SOP Instance UID (0008,0018)
は使ってはなりません。
（IHE-A.5-2.4）撮影装置施行検査段階（MPPS）では、PPS N-Create 通信文には Affected
SOP Instance UID (0000,1000) の中で、PPS N-Set 通信文には Requested SOP Instance UID









(0000,1001) のなかで、
SOP Instance UID が送られます。SOP Instance UID (0008,0018)は使ってはなりません。
（IHE-A.5-2.5）医療機関内で使われている記述とコードは、取り込む診療根拠書類（Evidence Document）で使われているものと一致しない可能性があります。記述とコードを強要する手段はテクニカルフレームワークの範疇外です。診療根拠書類（Evidence
Document）から得られる記述とコードは有益な場合もあることを注記します。
（IHE-A.5-2.6） 理想的には、有効な DICOM UID は世界的に一意です。それ故、現場施設のローカル UID と重複する恐れはなく、UID を変えねばならない理由は無いはずです。外部で生成されたデータの統一性は不確かなので、取込役はそれを修正するか、新たに UID を生成する必要があるかもしれません。UID は対象物間の参照のために使われるので、それが改変される場合は取込役が参照での統合性を保持しなくてはなりません。
（IHE-A.5-2.7） 医療機関内で使われている Performed Protocol Code は診療根拠書類（Evidence Document）で使われているものと一致しない可能性があります。コードをコピーするか、強要するか、削除するかの決定はテクニカルフレームワークの範疇外です。診療根拠書類（Evidence Document）から得られるコードは有益な場合もあることを注記します。
（IHE-A.5-2.8） RAD TF-4.59.4.1.2.3 を参照してください。取込む対象物（Objects）内部の Performed Protocol Code と診療根拠書類（Evidence Document）で使われているものとは一致しない可能性があります。コードを融合するか、強要し統合するか、廃棄するかを決めるのは、テクニカルフレームワークの範囲外です。診療根拠書類（Evidence
Document）から得られるコードは有益な場合もあることを注記します。

付録 B: HL7 オーダの DICOM MWL への対応付け HL7 Order Mapping to DICOM MWL
この付録は、HL7 ADT、OMG、ORM 通信文の DICOM 撮影装置業務一覧（Modality Worklist）への対応付けを定義するものです。HL7 通信文はスケジュール設定や機器・人員・設備等（resource）
管理情報ではなく、発行側オーダ管理トランザクション（Placer Order Management transaction）[RAD-2] にある、オーダに関する情報を取り扱うものである点に注意します。スケジュール設定
および資源（機器・人員・設備等）管理は部門システム予定役（Department System Scheduler）内部の問題です。
この対応付けは検査予定トランザクション（Procedure Scheduled transaction）[RAD-4]（部門シス
テム予定役から画像管理役への通信文：RAD TF-2: 4.4 を参照してください）に適用されない点にも注意します。フィールド（field）長、値表示、属性タイプのより厳格な定義については IHE
ER モデル（RAD TF-1: 3.4）および HL7 実装に関する注意（RAD TF-2: 2.5）も参照してください。HL7 と DICOM の間の対応付けは次のように表します：

Element Name (HL7 item_number.component #/ DICOM (group, element))
HL7 要素（Element）が複数の成分（Component）を含んでいない場合、成分値は一覧表に示されません。
表 B1: HL7 オーダの DICOM MWL への対応つけ
Table B-1:

HL7 Order mapping to DICOM MWLAdapted from DICOM PS 3.4
 注 1：普遍サービス ID（Universal Service ID）、オーダ発行側付随サービス情報（Placer
Supplemental Service Information）と試料源（Specimen Source）の解読○ 受領したオーダを完遂するために部門システム予定役は一つもしくは複数の要求検査（Requested procedure）を発行します。それらには現場または広くつかわれる（例：
CPT-4 や LONIC）コーディング手法から得る ID とコードが与えられます。
○ 左右の別が普遍サービス ID（Universal Service ID）に規定されていない場合は、オーダの自由記述テキストの使用をさらに明確にするためにも HL7 v2.5.1 Placer
Supplemental Information (01474) もしくは HL7 v2.3.1 Specimen Source (00249)を使用することが推奨されます。
注 2：IHE では HL7 の量・時間の優先要素で推奨された値のみを使わねばなりません。これらは DICOM 優先度フィールド（field）に以下のように対応付けされます。
HL7 Status

DICOM Status

S - STATSTAT

A - ASAP

HIGH

R - Routine

ROUTINEP - Pre-op

HIGH

C - Callback

HIGH

HL7 Status
T – Timing

DICOM Status
MEDIUM

注 3：部門システム予定役・オーダ実施役（Department System Scheduler/Order Filler）はオーダの内容によって DICOM Modality (0008,0060) 属性の値を決定せねばなりません。
DICOM PS3.3 に列挙された様に、撮影装置業務一覧（Modality Worklist）応答には
DICOM が定義した用語が使われなくてはなりません。



注 4：属性 (0040,2016) と(0040, 2017)は HL7 要素の Placer Issuer と Number、および、
Filler Issuer と Number を合体させるためのものです。患者識別子に複数の発行元がある医療機関では、一意性を保証するには、発行者（Issuer）の名前と番号の両方が必須です。



注 5：患者 ID（Patient ID）とその発行者（Issuer of Patient ID）の対応付けに関する異なる使用例の詳細は付録 D を参照してください。



注 6：RAD TF-2: 4.1.4.1.2.4 で検討したように、PID-18 Patient Account Number（会計口座番号）もしくは PV1-19 Visit Number（来院番号）のいずれか、もしくは両方は、個別の国別要求に依存して値を持つことがあります。オーダ通信文内の PV1-19 Visit Number が値を持つ場合は、常にその要素は撮影装置業務一覧（Modality Worklist）応答の中で
Admission ID (0038,0010) と Issuer of Admission ID (0038,0011) に反映しなければなりません。PV1-19 Visit Number が値を持たない場合、これらの属性は PID-18 Patient AccountNumber の要素から値を流用すべきです。つまり Visit Numbers は全ての会計口座番号の中で一意であることを要求しています。Issuer of Admission ID (0038,0011)は、以前、この注にありましたが、DICOM から引退しました。



注 7：患者の体重、身長（Patient's Weight and Patient's Size）は複数の OBX セグメントからの二つの観測値です。符号化手法は IHE では定めませんが、”Body Weight”と”Body
Height”の 2 種類のテキスト値で、測定値を区別することが要求されます。注：DICOM
では kg と m を使用することを規定しています。HL7 エンコーディングの例は○ OBX||ST|^BODY WEIGHT||62|kg|||||F○ OBX||ST|^BODY HEIGHT||1.90|m|||||F
注 8：DICOM の Special Needs (0038, 0050)は、表 D-1 では HL7 通信文からの特定の対応付けを持ちません。IHE デモンストレーションではこの値は部門システム予定役・オーダ実施役（Department System Scheduler/Order Filler）から供給されます。この属性の HL7への対応付けは将来検討されます。
注 9：ORM や OMG 通信文の OBR-34 Technician は反復可能です。そのデータタイプはCM であり、以下の成分（Components）を持っています：<name (CN)> ^ <start date/time(TS)> ^ <end date/time (TS)> ^ <point of care (IS)> ^ <room (IS)> ^ <bed (IS)> ^ <facility (HD)>^<location status (IS)> ^ <patient location type (IS)> ^ <building (IS)> ^ <floor (IS)>○ よって、DICOM の Scheduled Performing Physician (0040,0006)への対応付けでは、そのフィールド（field）の最初の繰り返しの最初の成分（component）の亜成分のみが使われねばなりません。



注 10：HL7 ORM もしくは OMG PID:5 要素にある患者氏名は変更せずに DICOM の
Patient’s Name (0010,0010)に以下のように対応付けされます。
HL7<family_name&last_name_prefix><given_name><middle_initial_or_name><suffix><degree> (Note)<prefix>

DICOM=> <family_name_complex>=> <given_name_complex>=> <middle_name>=> <name_suffix>=> <name_prefix>

注：HL7 での degree 要素は DICOM の name_suffix 要素の第 2 成分（Component）に吸収されています。



注 11：DICOM の Patient’s Sex (0010,0040)属性は M、F、O（その他）、もしくは、不明の場合はデータ長 0 とします。これらは予約語であり、これら以外の値は違反です。HL7 v2 では M、F、O
を使用しますが、不明の場合に U を提案しているのでこれはデータ長 0 に対応付けする必要があります。HL7 ではこれらはあくまで提案された値なので、これら以外の値が登場した場合は有効な DICOM の値に対応付けする必要があります。HL7 v2.5.1 では更に A（不明瞭）、N（対応不能）が存在します。これらは DICOM では違反なので O に対応付けされます。



注 12：文字セットに関する国際要求は以下に定義されます。（国別詳細は RAD TF- 4 を参照してください）
National
Extension

DICOM attribute:
Specific Character Set(0008,0005)

HL7 field:
Character Set MSH
18

FranceISO_IR 100

8859/1

Germany

ISO_IR 100

8859/1

United States

ISO_IR 100

8859/1

Italy

ISO_IR 100

8859/1UK

ISO_IR 100

8859/1

CanadaISO_IR 100

8859/1

Spain

ISO_IR 100

8859/1

Japan\ISO 2022 IR 87

ASCII~ISO IR87

付録 C: 放射線医学以外の情報の部門利用 Departmental Access to Non-Radiology Information
C. 1: 範囲
画像部門外の非放射線レポートの利用は、画像部門の構造化レポート（Structured Reports）の利用にも使用される（RAD TF-2: 4.26 and 4.27 を見てください）、レポート問合せ（Query
Reports）、および、レポート取得トランザクション（Retrieve Reports Transactions）を利用し

て、IHE テクニカルフレームワークで可能です。外部レポート保管庫利用（External Report
Repository Access）は他部門レポート（例えば臨床検査）を取得する方法を提供します。
IHE テクニカルフレームワークは外部レポート保管庫利用（External Report Repository Access）を実装するやり方を制限しません。例えば以下の様です：
 このアクタ（actor）と、これに関連するレポート問合せとレポート取得トランザクショ
ン（Query Reports and Retrieve Reports Transactions）を直接使用を可能とする臨床検査結果保管庫システム（Laboratory Repository System）にします。
 レポート問合せとレポート取得トランザクション（Query Reports and Retrieve Reports
Transactions）を一方で受け取り、これらを特定の臨床検査レポート保管庫で使用可能な
問合せトランザクションに変換します。
この付録では、正しく統合するために外部レポート保管庫利用（External Report Repository
Access）が使用可能とすべき制約について説明します。
C. 2: 問合せプロトコル
外部レポート保管庫利用役（External Report Repository Access）の動作には、次が仮定されています。
1.

外部レポート保管庫利用役（External Report Repository Access）は、他部門のレポート（例：臨床検査レポート）を DICOM 構造化レポート対象物の形式に変換する責任を負います（内容の制約については、C.3 節を参照してください）。IHE テクニカルフレー
ムワークでは臨床検査レポートを重視するが、他の部門のレポートを使用可能としても
よいです。

2.

臨床検査（または他の部門）の部門レポート内と画像部門内では、一貫した患者 ID が使用されます。これにより、画像表示役により表示される画像を同じ患者の最新臨床検査
レポートの取得キーとして使用できます。つまり、臨床検査情報システムが同じ ADT
患者登録に統合されていることを意味します（ただし、この統合は IHE テクニカルフレームワークの範囲外です）。

3.

Study と Series のグループ分けは IHE テクニカルフレームワークでは定義されず、外部
レポート保管庫利用役（External Report Repository Access）が任意に使用できます。例えば、一つ以上の臨床検査レポートを含むオーダ（Accession Number）の各々に対して
DICOM Study を作成し、臨床検査要求の各々に対して一つの Series を作成して、レポー
トが改正されていない限り、大部分が一つのレポートが含まれるようにします。あるいは、同一のオーダで複数の異なる臨床検査が要求される場合には、一つの Series を作成し、その中に複数のレポートが含まれてもよいです。

4.

外部レポート保管庫利用役（External Report Repository Access）はレポートをグループ分けするために、Study Instance UID、Series Instance UID、SOP Instance UID を作成してもよいです。これらの UID は、適切な形式の DICOM UID でなければなりません。つまり、登録済みのルートを使用します。

5.

同一のレポートが複数回にわたって問合せ、取得される場合は、外部レポート保管庫利用役（External Report Repository Access）は、Study、Series、SOP Instance UID の同じ組み合わせを提供せねばなりません。これにより、別の問合せで同じレポートを選択した場
合に、同じインスタンスが特定され、同一のコピーが取得されることが保証されます。
これは、同じ内容の複数のコピーによる臨床医の混乱を防ぐため、重要です。

6.

表 C.2-1 は、異なった DICOM 階層レベルで外部レポート保管庫利用役（External Report
Repository Access）が SCP として最低限使用可能とせねばならない合致キーと戻りキーの組み合わせを示します。これは放射線部門のキー（RAD TF-2: 4.14.4.1.2 を参照してください）の縮小セットです。外部レポート保管庫利用役が SCP としてサポートせねばな
らない SR インスタンス（SR Instance）特異の追加キーは、RAD TF-2: 4.26.4.1.2 と表
4.26-1 に定義されています。 最低限の DICOM 準拠は必須です。表 C.2-1 の表記規約については RAD TF-2: 2.2 を参照してください。

注：SCU 列に N/A（該当なし）が使用されている理由は、外部レポート保管庫利用役は単に問合せ要求の SCP だからです。
表 C.2-1: 問合せ合致キーと戻りキー
Attributes
Name

Table C.2-1:
Tag

Query Matching and Return Keys
Query Keys
Query Keys
Matching
Return
SCU

SCP

SCU

Notes

SCP

Study Level
Study Date

(0008,002
0)

N/A

R

N/A

R

Study Time

(0008,003
0)

N/A

R

N/A

R

Accession
Number(0008,005
0)

N/A

R

N/A

R

Patient Name

(0010,001
0)

N/A

R

N/A

R

Patient ID(0010,002
0)

N/A

R

N/A

R

Study ID

(0020,001
0)

N/A

R

N/A

R

Study Instance
UID(0020,000
D)

N/A

R

N/A

R

Referring
Physician’s name(0008,009
0)

N/A

R+

N/A

R+

Study Description(0008,103
0)

N/A

O

N/A

O

IHE-1,IHE-2

IHE-1,
IHE-2

Attributes
Name

Tag

Query Keys
Matching

Query Keys
Return

SCU

SCU

SCP

Notes

SCP

Procedure Code
Sequence(0008,103
2)

N/A

O

N/A

O

Patient’s Birth
Date(0010,003
0)

N/A

O

N/A

R+

Patient’s Sex(0010,004
0)

N/A

O

N/A

R+

Modality(0008,006
0)

N/A

R

N/A

R

Series Number(0020,001
1)

N/A

R

N/A

R

Series Instance
UID(0020,000
E)

N/A

R

N/A

R

IHE-3

Series Level
IHE-5

Composite Object Instance Level
Instance Number(0020,001
3)

N/A

R

N/A

R

SOP Instance UID(0008,001
8)

N/A

R

N/A

R

SOP Class UID(0008,001
6)

N/A

R+

N/A

R+

IHE-4

IHE-1：IHE テクニカルフレームワークでは、VR PN の属性については大文字と小文字の区
別のない照合が許可されています。PN 属性での大文字と小文字の区別を無視するための
DICOM 変更提案（CP 190）は、DICOM 2001 で投票されました。
IHE-2：SCU では、照合の利便性のため、構造化された名前の各要素の最後にワイルドカー
ド（"*"）の追加が推奨されます（たとえば、PN 属性）。
IHE-3：VR SQ の属性に対する全般的照合（Universal Matching）（リターンキーの選択）
は、問合せ SCU により Zero Length Sequence 属性を使って要求されます。問合せ SCP
は、このような全般的照合要求を受容します。さらに DICOM 標準により、問合せ SCP
では、長さゼロの項目として符号化されている SQ 属性の全般的照合（Universal
Matching）の要求を使用可能とする必要があります。
IHE-4：SOP ClassUID は、非あいまいキーであり、特定タイプの画像を識別します（Modality はそうではありません）。
IHE-5：Modality 合致キーは、必ず"SR"に設定されます。

C. 3: 外部レポートの内容
レポート問合せ、および、レポート取得トランザクション（Query Reports and Retrieve Reports
Transactions）を介する、外部レポート保管庫（External Repot Repository）が取り扱う符号化エントリとレポート構造の要求事項は、レポート生成役に類似でなければなりません（RADTF-2:
4.24.4.1.2.1 節を見てください）：
 外部レポート保管庫が生成するレポートの型は、RAD TF1: 9.4 に定められています。外部レポート保管庫（External Repot Repository）は、オプションで画像への参照を持つ単純画像レポート（Simple Image Report、RAD TF-1: 9.4.1）に基づいてレポートを生成でき
ねばなりません。外部レポート保管庫が強化 SR 情報対象物定義（Enhanced SR
Information Object Definition）を使用可能とするなら、単純画像数値レポート（Simple
Image and Numeric Reports、RAD TF-1: 9.4.2）も使用可能とせねばなりません。


利用される部門保管庫のタイプごとに、Report Title、Report Section Heading、Concept
Name Code、Observation Context Code、Measurement Code、Disposition または Conclusion
Code の特定の組み合わせが定義されます（例：臨床検査部門に臨床検査コード）。

付録 D: 融合の場合の患者 ID の明確化
D. 1:

はじめに

IHE テクニカルフレームワークでは、HL7 v2.3.1 と HL7 v2.5.1 での 患者 ID の変更を採用しました。これには、次の事項が含まれます。


外部患者 ID（External Patient ID (PID-2)）は、旧版との互換性のために残された。



代替患者 ID（Alternate Patient ID (PID-4)）は、旧版との互換性のために残された。

内部患者 ID（Internal Patient ID (PID-3)）は、患者識別子一覧（"Patient Identifier List"）と改名され、繰り返しが許可されるようになった。

これらの HL7 変更の採用により、IHE では、PID-3 成分 4（PID-3conponent 4）の中の割付け責任機関（assigning authority）と PID-3 成分 1（PID-3 component 1）の中の識別子（identifier）の使用が強制されます。
DICOM の患者 ID 属性（Patient ID Attribute (0010,0020)）は割付け責任機関（assigningauthority）を伝えず、DICOM では 患者 ID 発行者（Issuer of Patient ID (0010,0021)）はオプショ
ン属性なので、画像管理役と部門システム予定・オーダ実施役（Department System
Scheduler/Order Filler）はどちらも、DICOM Modality PPS を通じて撮影装置（Acquisition
Modality）から送られた患者 ID の割付け責任機関（assigning authority）に関する仮定を行うことができなければなりません。「一つの医療機関内の単一の ADT アクタ（actor）、または、識別子発行者が割り当てた患者識別子の有効範囲は認識可能である」と想定されます。
IHE により指定されるすべての HL7 トランザクション内の PID-3 の中の識別子は、単一の値であり、ADT（患者登録アクタ（actor））により使用されます。ただし例外として、トランザクシ
ョン RAD-4 は部門システム予定役・オーダ実施役（Department System Scheduler/Order Filler）が割り当てた識別子を使用してもよいです。
将来 IHE に MPI を導入する際には、すべての HL7 トランザクションで PID-3 に MPI の識別子が使用されることが想定されます。
医療機関では、暫定患者識別子の発行者が ADT か、画像管理役と部門システム予定役・オーダ
実施役（Department System Scheduler/Order Filler）の両者内の部門発行者（Departmental Issuer）か、のいずれかに設定することが必要です。これにより、DICOM の Patient ID (0010,0020) が HL7 通
信文の PID-3 に対応付けされたときに、確実に同じ発行者に関連付けられます。
しかし、医療機関は ADT が発行した暫定患者識別子で運用される場合があり、主に例 1、2、3と例 5 が発生した場合に使用されます。これは、例 3 で患者識別子を手動入力するときに、撮影装置（Acquisition Modality）のオペレータエラーが原因で発生します。この場合、部門システム
予定役・オーダ実施役（Department System Scheduler/Order Filler）と画像管理役はこのエラーを識別せねばならず、同一の発行者に誤った識別子を関連付けます。部門システム予定役・オーダ実施役（Department System Scheduler/Order Filler）で整合性の保持が行われ、画像管理役（ImageManager）に対して、部門システム予定役・オーダ実施役（Department System Scheduler/Order
Filler）は患者融合通信文（Patient Merge message）を送信します。画像管理役（Image Manager）
で、古い患者識別子と新しい患者識別子が同じ発行者に関連付けられます。
RAD TF-1: 3.3 および 4.3 の使用例を使用して、以下の節に PID-3 の使用法が説明されます。以下に示す例では、時間は上部の行から下部の行に流れます。
Table
Acronyms

Description

IM

Image Manager

OF

Order Filler/Departmental System Scheduler

OP

Order Placer

PPSM

Performed Procedure Step Manager

D. 2: 管理事務の処理流れ（RAD TF-1:3.3.1）
説明には A01・A04・A05・A11・A30 が含まれますが、この例には A01 だけが含まれます。下の例で使用される ADT の ID 番号は"123"、割付け責任機関は "ADT_Issuer"、Universal ID
は”1.2.3.4”、Universal ID Type は “ISO” です。
Transaction

PID-3(Patient
Identifier List)

DICO
M(0010,
0020)

DICOM(0010,
0021)

DICO
M
(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

A01 (ADT ->OF)123^^^ADT_Issu
er&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OP)

123^^^ADT_Issu
er&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

ORM (OP>OF)(HL7 v2.3.1)
OMG(OP>OF)(HL7 v.2.5.1)

123^^^ADT_Issu
er&1.2.3.4&ISO

N/A
N/A

N/A

N/A

N/A

ORM (OF>IM(HL7 v2.3.1)
OMG(OF>IM(HL7 v.2.5.1)

123^^^ADT_Issu
er&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

DICOM MWL
(OF ->
Modality)

N/A

123

ADT_Issuer

1.2.3.4

ISO

N/A

PPS (Modality-> PPSM)

N/A

123

ADT_Issuer

1.2.3.4

ISO

N/A

PPS (PPSM ->
IM)

N/A

123

ADT_Issuer

1.2.3.4

ISO

N/A

PPS (PPSM ->
OF)

N/A

123

ADT_Issuer

1.2.3.4

ISO

N/A

D. 3: 患者情報融合（Patient Merge） （RAD TF-1:3.3.2）
ここでは、RAD TF-1: 3.3.2.2 節の患者情報融合のシナリオに注目します。下の例では、古い
ADT ID 番号は "123"、割付け責任機関（assigning authority）は"ADT_Issuer" です。新しい ADT
ID 番号は "456"、割付け責任機関（assigning authority）は"ADT_Issuer"、Universal ID は“1.2.3.4”
で、Universal ID Type は“ISO” です。
Transaction

PID-3(Patient
Identifier List)

DICO
M(0010,
0020)

DICOM(0010,
0021)

DICO
M
(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

A01 (ADT ->OF)123^^^ADT_Issuer&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OP)

123^^^ADT_Issuer&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

ORM (OP->OF)(HL7 v2.3.1)
OMG(OP->OF)(HL7 v.2.5.1)

123^^^ADT_Issuer&1.2.3.4&ISO

N/A
N/A

N/A

N/A

N/A

ORM (OF>IM(HL7 v2.3.1)
OMG(OF>IM(HL7 v.2.5.1)

123^^^ADT_Issuer&1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

DICOM MWL
(OF ->
Modality)

N/A

123

ADT_Issu
er

1.2.3.4ISO

N/A

A40 (ADT ->OF)

456^^^ADT_Iss
uer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

123^^^ADT_I
ssuer&1.2.3.4&ISO

A40 (OF->IM)456^^^ADT_Iss
uer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

123^^^ADT_I
ssuer&1.2.3.4&ISO

A40 (ADT ->OP)

456^^^ADT_Iss
uer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

123^^^ADT_I
ssuer&1.2.3.4&ISO

D. 4: 外傷ケ－ス 1 と 2 （RAD TF-1:4.3）
次の例で、患者”John Doe”に使用される ADT 暫定患者 ID は"Temp.123"、割付け責任機関（assigning authority）は"ADT_Issuer"、Universal ID は“1.2.3.4”で、Universal ID Type は“ISO” です。
Transaction

PID-3(Patient
Identifier List)

DICO
M(0010,
0020)

DICO
M
(0010,
0021)

DICOM(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

A01 (ADT ->OF)

Temp_123^^^ADT_Issuer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OP)

Temp_123^^^ADT_Issuer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

N/A

ORM (OP->OF)(HL7 v2.3.1)
OMG(OP->OF)(HL7 v.2.5.1)

Temp_123^^^ADT_Issuer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

N/A

ORM (OF>IM(HL7 v2.3.1)
OMG(OF>IM(HL7 v.2.5.1)

Temp_123^^^ADT_Issuer&1.2.3.4&
O

N/A

N/A

N/A

N/A

N/A

DICOM MWL
(OF ->
Modality)

N/A

Temp_
123

ADT_
Issuer

1.2.3.4

ISO

N/A

PPS (Modality > PPSM)

N/A

Temp_
123

ADT_
Issuer

1.2.3.4

ISO

N/A

PPS (PPSM ->
IM)

N/A

Temp_
1
23

ADT_
Issuer

1.2.3.4

ISO

N/A

PPS (PPSM ->
OF)

N/A

Temp_
1
23

ADT_
Issuer

1.2.3.4ISO

N/A

A40 (ADT ->OF)

456^^^ADT_
Issuer&1.2.3.
4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

A40 (OF->IM)456^^^ADT_
Issuer&1.2.3.
4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

A40 (ADT ->OP)

456^^^ADT_
Issuer&1.2.3.
4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

D. 5: 外傷ケ－ス 3 （RAD TF-1:4.3)
次の例で、患者”John Doe” に使用される ADT 暫定患者 ID は"Temp.123"です。患者は後で永久患者 ID"Real_456"を割り当てられます。割付け責任機関（assigning authority）は"ADT_Issuer"、
Universal ID は“1.2.3.4”で、Universal ID Type は“ISO” です。

Transaction

PID-3(Patient
Identifier
List)

DICOM
(0010,0
020)

DICO
M
(0010,
0021)

DICOM(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

A01 (ADT ->OF)

Temp_123^^^ADT_Issuer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OP)

Temp_123^^^ADT_Issuer&1.2.3.4&IS
O

N/A

N/A

N/A

N/A

N/A

(Note:
Temporary
Patient ID“Temp_123” ismanually
enteredat the modality.)

N/A

N/A

N/A

N/A

N/A

N/A

PPS (Modality >
PPSM)

N/A

Temp_1
23

ADT_
Issuer

1.2.3.4

ISO

N/A

PPS (PPSM >
IM)

N/A

Temp_1
23

ADT_
Issuer

1.2.3.4

ISO

N/A(Note: The IMrecognizes anunscheduled
PPS
and assumes asite
configured
assigningauthority of“ADT_Issuer”.
)

N/A

Temp_1
23

ADT_
Issuer

1.2.3.4

ISO

N/A

PPS (PPSM >
OF)

N/A

Temp_1
23

ADT_
Issuer

1.2.3.4

ISO

N/A

(Note: The OF
recognizes anunscheduled
PPS
with a valid
ADT
Patient ID –witha site configured
assigningauthority of“ADT_Issuer”.
)

N/A

N/A

N/A

N/A

N/A

N/A

ORM (OF->OP)(HL7 v2.3.1)
OMG (OP->OF)(HL7 v2.5.1)

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

ORR (OP->OF)(HL7 v2.3.1)
ORG (OP->OF)(HL7 v2.5.1)

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

ORM (OF-> IM)(HL7 v2.3.1)
OMI (OF->IM)(HL7 v2.5.1)

Temp_123^^^
ADT_Issuer&
1.2.3.4&ISO

N/A

N/A

N/A

N/A

N/A

(Note: Patient
Reconciliation
occurs on the
ADT system.)

N/A

N/A

N/A

N/A

N/A

N/A

A40 (ADT ->OF)

Real_456^^^A
DT_Issuer&1.
2.3.4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&1.2.3.
4&ISO

A40 (ADT ->OP)

Real_456^^^A
DT_Issuer&1.
2.3.4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&1.2.3.
4&ISO

A40 (OF-> IM)

Real_456^^^A
DT_Issuer&
1.2.3.4&ISO

N/A

N/A

N/A

N/A

Temp_123^^^
ADT_Issuer&1.2.3.
4&ISO

D. 6 外傷ケ－ス 4（RAD TF-1:4.3）
次の例で、患者”John Doe” に使用される OF 暫定患者 ID は"Dept_789"です。割付け責任機関（assigning authority）は"OF_Issuer"、Universal ID は“1.2.3.5”で、Universal ID Type は“ISO”です。患者は後で永久患者 ID"123"を割り当てられます。割付け責任機関（assigning authority）
は"ADT_Issuer"、Universal ID は“1.2.3.4”で、Universal ID Type は“ISO” です。
Transaction

PID-3(Patient
Identifier
List)

DICOM
(0010,0020)

DICOM(0010,
0021)

DICOM(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

ORM (OF->IM)

Dept_789^^^OF_Issu
er&1.2.3.5
&ISO

N/A

N/A

N/A

N/A

N/A

DICOM MWL
(OF->Modality)

N/A

Dept_789OF_Issuer

1.2.3.5ISO

N/A

PPS (Modality >
PPSM)

N/A

Dept_789OF_Issuer

1.2.3.5ISO

N/A

PPS (PPSM ->
IM)

N/A

Dept_789OF_Issuer

1.2.3.5

ISO

N/A(Note: The IMrecognizes ascheduled PPS
witha Patient ID witha site configured
assigningauthorityof “OF_Issuer”.)

N/A

N/A

OF_Issuer

1.2.3.5

ISO

N/APPS (PPSM ->
OF)

N/A

Dept_789OF_Issuer

1.2.3.5

ISO

N/A(Note: The OF
recognizes ascheduled PPS
witha Patient ID
issuedby the OF.)

N/A

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OP)

123^^^AD
T_Issuer&
1.2.3.4&I
SO

N/A

N/A

N/A

N/A

N/A

A01 (ADT ->OF)123^^^AD
T_Issuer&
1.2.3.4&I
SO

N/A

N/A

N/A

N/A

N/A

(Note: The
patient
Dept_789^^^OF_Is
suer&1.2.3.5&I
SO
is manuallyreconciled with123^^^ADT_Issuer&1.2.3.4&ISO)

N/A

N/A

N/A

N/A

N/A

N/A

A40 (OF-> IM)

123^^^AD
T_Issuer&
1.2.3.4&ISO123^^^A
D
T_Issuer&
1.2.3.4&
IS O

N/A

N/A

N/A

Dept_789^^^
OF_Issuer&1.2.3.5&ISO

ORM (OP->OF)(HL7 v2.3.1)
OMG(OP->OF)(HL7 v.2.5.1)

123^^^AD
T_Issuer&
1.2.3.4&I
SO

N/A

N/A

N/A

N/A

N/A

ORM (OF>IM(HL7 v2.3.1)
OMG(OF>IM(HL7 v.2.5.1)
ORR (OP->OF)(HL7 v2.3.1)
ORG (OP->OF)(HL7 v2.5.1)

123^^^AD
T_Issuer&
1.2.3.4&I
SO

N/A

N/A

N/A

N/A

N/A

123^^^AD
T_Issuer&
1.2.3.4&I
S
O

N/A

N/A

N/A

N/A

N/A

D. 7: 外傷ケ－ス 5 （RAD TF-1:4.3）
次の例で、身元未確認の患者”John Doe”に使用される暫定患者 ID は"Dept_123"で、撮影装置（Acquisition Modality）にて手入力されます。割付け責任機関（assigning authority）は"OF_Issuer"、Universal ID は“1.2.3.6”で、Universal ID Type は“ISO” です。患者は後で永久患者 ID"123"を割り当てられます。割付け責任機関（assigning authority）は"Configured_Issuer"、
Universal ID は“1.2.3.6”で、Universal ID Type は“ISO” です。患者は後で永久患者 ID"Real_456"を割り当てられます。割付け責任機関（assigning authority）は"ADT_Issuer"、Universal
ID は“1.2.3.4”で、Universal ID Type は“ISO” です。
Transaction

PID-3(Patient
Identifier
List)

DICOM
(0010,0020)

DICOM(0010,002
1)

DICOM(0010,
0024)(0040,
0032)

DICO
M
(0010,
0024)(0040,0033)

MRG-1(PriorPatient
Identifier
List)

PPS (Modality >
PPSM)

N/A

Dept_123

Configured_Issuer

1.2.3.6

ISO

N/A

PPS (PPSM ->
IM)

N/A

Dept_123

Configured_Issuer

1.2.3.6

ISO

N/A(Note: The IMrecognizes anunscheduled
PPS andassumes a site
configured
assigningauthority)

N/A

N/A

N/A

N/A

N/A

N/A

PPS (PPSM ->
OF)

N/A

Temp_1
23

Configured_Issuer

1.2.3.6

ISO

N/A

(Note: The OF
recognizes anunscheduled
PPS andassumes a site
configured
assigningauthority;
recognizes that
Patient ID isinvalid.)

N/A

N/A

N/A

N/A

N/A

N/A

A01 (ADT>OF)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

N/A

A01 (ADT>OP)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

N/A

(Note: Manual
patient
reconciliation
occurs on the
OF system.)

N/A

N/A

N/A

N/A

N/A

N/A

A40 (OF-> IM)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

Dept_123^^^
Configured_Is
suer&1.2.3.6&
ISO

ORM (OP->OF)(HL7 v2.3.1)
OMG(OP->OF)(HL7 v.2.5.1)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

N/A

ORR (OP>OF(HL7 v2.3.1)
ORG(OP>OF(HL7 v.2.5.1)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

N/A

ORM (OF->IM)(HL7 v2.3.1)
OMI (OF->IM)(HL7 v2.5.1)

Real_456^^^ADT_Issuer&1.2.3.4
&ISO

N/A

N/A

N/A

N/A

N/A

付録 E: DICOM 媒体交換－不可欠な DICOM 互換性のコツ DICOM Media Interchange - Critical
DICOM Compatibility Tips
この付録は、DICOM Media Interchange standard （PS 3.10, PS 3.11 と PS 3.12）に従わないために起こる互換性の問題を提示します。この付録は、単に、過去にファイル制作役と取込み役（Importer）間で起こった、もっとも多い互換性問題の備忘録を意図しています。
この一覧は、実装者が注意を払わねばならない唯一の DICOM 必須事項とは解釈しないでくださ
い。IHE プロファイルの実装者が熟知すべきは DICOM 規格で、これは非常に有効で完全な仕様と証明されています。
1. CD 媒体を使用するなら、ISO 9660 Level 1 に従ってフォーマットしてください。Joliet やRock Ridge のような拡張規格は、DICOM では禁止されておらず、PDI プロファイルでも使用が許されています。UDF ファイルシステムは、ISO 9660 Level 1 ファイルシステム
が同時に存在しない限り、許可されません。この様な拡張規格は、媒体上の非 DICOM
形式内容物のコ－ド化に必要で、例えば、画像観察ソフトウェアのための長いファイル
名等です。このような拡張規格は、ISO 9660 Level 1 の大文字ファイル名が、OS の媒体
マウント時の挙動に依存して、小文字あるいは、大・小文字混在のファイル名としてソフトウェアに提示される様に結果としてなります。このため、すべての可搬媒体表示役と可搬媒体取込み役（Importer）は、この点では、大文字・小文字の区別をしないようにせねばなりません。
2. DICOMDIR ファイルは交換用媒体のルートに置かねばなりません。
3. 全ての DICOM 形式ファイルの拡張子の無い名称は、大文字、数字、下線のみからな
り、8 文字以下でなくてはなりません。
4. DICOM フォルダ以下におかれた全てのディレクトリの名称は、大文字、数字、下線のみからなり、拡張子はつけてはなりません。
5． 非 DICOM 形式ファイルは 3 文字以上の拡張子を持つことができます。
6． DICOM 形式ファイルは拡張子をもってはいけません。
7. DICOM 形式ファイルは、ISO 9660 第 1 版でなければならず、ある種の OS では、".1;"が最後につきます。しかし、".1;"自身はファイル自身の名称に入れてはいけません。ある
種のオーサリングソフトウェアは".1;"の前に置かれる必須の”.”を入れるのに失敗した
り、必須の".1;"を省いたりして、ISO 9660 Level 1 標準を破ります。これは普通にみられる誤りで、相互運用性に影響しません、閲覧役が無視すればよいのです。
8. ファイル名の版は DICOMDIR に記載される参照データ要素に含まれてはなりません。
9. ルートを含んで、最大 8 水準までのディレクトリが許されます。
（ルートの下に 7 つまでの子ディレクトリが作成できる）。
10. DICOM ファイルの対象物は、Explicit VR Little Endian で無ければなりません（Implicit はだめです）。DVD と USB オプションでは適切な圧縮転送文法（Transfer Syntax）です。
11. DICOM ファイルのメタ情報は、Explicit VR Little Endian で無ければなりません（Implicit
はだめです）
12. ファイルメタ情報版（File Meta Information Version）(0002,0001)は、0x00 バイト、次いで0x01 バイトからなる 2 バイトの OB 値を持たねばなりません。little endian16 ビット短値

（little endian 16 bit short value）としてコード化された 0x0001 ではありません。
13. ファイルメタ情報（file meta information）は、Media Storage Class UID (0002,0002) データ
要素をもち、その値は、データセット内の SOP Class UID データ要素に等しくなければなりません。
14. ファイルメタ情報（file meta information）は、Media Storage Instance UID (0002,0003)デー
タ要素をもち、その値は、データセット内の SOP Instance UID に等しくなければなりません。
15. ファイルメタ情報（file meta information）に、私的要素を含んではなりません。
16. ファイルメタ情報ヘッダ（file meta information header）には、属性 Group Length(0002,0000)を含み、DICOM PS3.10 で規定された様に、その正しい値が入れられねばなりません。
17. DICOM DVD ディスク、あるいは USB 媒体の物理フォーマットは DICOM PS3.12 に記載されています。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

付録 F: 作成された媒体内容物の実例

Example Created Media Instance Content

例 F-1: 媒体は DICOM CT 画像、DICOM 表示条件（DICOM Presentation States）と、DICOM 構
造化レポート（DICOM Structured Report）を含みます。媒体生成役はインターネット内容物オプション（Web Content Option）に対応しており、媒体内 DICOM デ－タから作ったインターネット
閲覧ソフトで観察できるデータが含まれます。DICOM 観察ソフトも媒体に含まれます。

例

F-2: 媒体は DICOM US 画像、DICOM 構造化診断レポート（DICOM SR diagnostic Report）

を含みます。媒体生成役はインターネット内容物オプション（Web Content Option）に対応していませんが、README.TXT ファイルはオプションとして入れます。媒体内 DICOM デ－タから作ったインターネット閲覧ソフトで観察できるデータは含まれません。

付録 G: DICOM, WADO と Web Services 取得サービスの設定 Configuration for Accessing
DICOM, WADO and Web Services Retrieve Services
G.1: DICOM AE Title と DICOM AE Network Title の対応付け
Mapping DICOM AE Title to DICOM AE Network Address
画像書類利用役（Imaging Document Consumer）が共有の目録（manifest）で参照された DICOM
インスタンスを、DICOM C-Move/C-Store で取得したい場合は、以下の設定が必要となります。
キー対象物選択書類インスタンス（Key Object Selection Document Instance）には、AE タイトルが含まれますが、IP アドレスやその他のポート番号を含みません。AE タイトルのみでは
DICOM 対象物（DICOM objects）の取得に不足するので、画像書類利用役（Imaging Document
Consumer）は画像書類源（Imaging Document Source）の IP アドレス、AE タイトル、ポート番号、を現場施設の設定ファイルから取得します。
同様に、画像書類源（Imaging Document Source）は、DICOM 対象物（DICOM objects）の保存のため、画像書類利用役（Imaging Document Consumer）の IP アドレス、AE タイトル、ポート番号、を必要とします。画像書類源（Imaging Document Source）は画像書類利用役（Imaging
Document Consumer）の IP アドレス、AE タイトル、ポート番号、を現場施設の設定ファイルか

ら取得します。
このプロファイルでは、画像書類源（Imaging Document Source）と画像書類源（Imaging
Document Source）の AE タイトルとネットワーク提示アドレス（IP アドレス、ポート番号）の対応は、関係するアクタ（actor）間で設定ファイルが、連携医療圏の方針と処理の誘導の元で、交換されることで可能になると想定されています。設定ファイルの交換方法はこのプロファイルの範囲外です。将来は、DICOM Supplement 67（Configuration Management）と、施設間での使用のための拡張により、この対応を自動化できます。これは将来の IHE ITI 分野の統合プロファイ
ル候補です。
IP アドレスとポート番号は AE タイトルから解決されねばなりませんが、このプロファイルに含まれるアクタ（actor）の AE タイトルが、提携医療圏（affinity domain）内で一意に割り付けられていることを確認せねばなりません。
G.2: DICOM AE Title と WADO サービスのネットワークアドレスの対応付け
Mapping DICOM AE Title to WADO Service Network Address
画像書類利用役（Imaging Document Consumer）が共有の目録書類（Manifest Document）で参照された DICOM インスタンスを、WADO 取得トランザクション（WADO Retrieve transaction）[RAD-55] で取得したい場合は、SOP instance の WADO HTTP Request-URI の樹立が必要になります。SOP instance の特定情報は目録（Manifest）に完全に記載されていますが、画像書類利用役（Imaging Document Consumer）は、目録（Manifest）で参照された SOP instance で特定される
Retrieve AE Title と、サーバのネットワークアドレスとを対応させる、補助の方法が必要となります。このネットワークアドレスは WADO 取得サービスに必要です。
画像書類利用役（Imaging Document Consumer）は、提携医療圏内の全ての画像書類源（Imaging
Document Source）サーバネットワークアドレスと Retrieve AE タイトルの対応設定を提携医療圏内で維持する必要があります。この対応をもちいて、目録内で参照された SOP Instance のRetrieve AE タイトルは、WADO サービスのサーバーアドレスに変換され、SOP Instance 特定情報、オプションの他の標準 WADO HTT パラメ－タと相まって、WADO HTTP Request-URI
WADO サービスの樹立に使われます。
曖昧さの無い、自動的な、Retrieve AE タイトルと WADO 利用サービスサーバのネットワークア
ドレスの対応を実現するには、AE タイトルが提携医療圏内で一意に割り付けられていることを確認する方針が必要となります。
G.3: DICOM AE Title と Web サービスのアドレスの対応付け
Mapping DICOM AE Title to WADO Services Address
画像書類セット取得[RAD-69]トランザクション（Retrieve Imaging Document Set transaction）を使って、目録書類（manifest document）で参照された DICOM インスタンスを取得するには、画像

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

付録: H 教育ファイル構造化レポート目録のひな形例
Example Template for Teaching File Structured Report Manifests
ここにあるのは、DICOM PS 3.16 形式のひな形で、以下を含みます。


節の見出（収納体の構想名（container concept names)））で、MIRC の、病歴、所見、考察、および、代替のコード、の概念を模した一塊のテキスト。



節の見出（収納体の構想名（container concept names））で、鑑別診断、診断、病理、解剖、臓器系などのコード体系の名称

鑑別診断、診断、病理、解剖、臓器系のコード値の一群 （おそらく、SNOED +/ICD9M, +/- ACR index））



診断確認フラグ（diagnosis confirmation flag）

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

表 H-1: 追加教育用資料ひな形の例
Table H-1: Example Additional Teaching File Information Template
NL

Rel with

Value Type

Concept Name

VM

parent1

Req

Constrain
Root node

1

M

2

>

CONTAINSTEXT

EV (TCE101,
IHERADTF,“Author”)

1

M

3

>>

HAS

TEXT

EV (TCE102,
IHERADTF,”
Affiliation”)

1

U

TEXT

EV (TCE103,
IHERADTF,“Contact”)
EV (TCE104,
IHERADTF,“Abstract”)

1

U

1

M

4

>>

HAS
PROPERTIES

Value Set

Type
CONTAINER EV (TCE006,
IHERADTF,“Additional
Teaching File
Information”)

PROPERTIES

Cond

5

>

CONTAINS

TEXT

6

>

CONTAINSTEXT

EV (TCE105,
IHERADTF,“Keywords”)

1-n

MC

XOR
row 7

7

>

CONTAINS

CODE

EV (TCE105,
IHERADTF,

1-n

MC

XOR
row 6

“Keywords”)
8>

CONTAINSTEXT

EV (121060,
DCM, "History")

1-n

U

9

>

CONTAINS

CODE

EV (121060,
DCM, "History")

1-n

U

10 >

CONTAINSTEXT

EV (121071,
DCM, "Finding")

1-n

U

11 >

CONTAINS

CODE

EV (121071,
DCM, "Finding")

1-n

U

12 >

CONTAINSTEXT

EV (TCE106,
IHERADTF,
Discussion”)

1-nU

ACR orMESH orICD9CM
Diagnosis
Codes

13 >

CONTAINS

TEXT(111023, DCM,
“Differential
Diagnosis/
Impression”)

1-n

U

14 >

CONTAINS

CODE(111023, DCM,
“Differential
Diagnosis/
Impression”)

1-n

U

15 >

CONTAINSTEXT

EV (TCE107,
IHERADTF,
Diagnosis”)

1-n

U

16 >

CONTAINS

CODE

EV (TCE107,
IHERADTF,“Diagnosis”)

1-n

U

17 >

CONTAINSTEXT(112005, DCM,
“Radiographic
anatomy”)

1-n

U

18 >

CONTAINS

CODE(112005, DCM,
“Radiographic
anatomy”)

1-n

U

19 >

CONTAINS

TEXT(111042, DCM,
“Pathology”)

1-n

U

20 >

CONTAINS

CODE(111042, DCM,
“Pathology”)

1-n

U

21 >

CONTAINSTEXT

EV (TCE108,
IHERADTF,“Organ system”)

1-n

U

22 >

CONTAINS

CODE

EV (TCE108,
IHERADTF,“Organ system”)

1-n

U

23 >

CONTAINS

CODE

EV (TCE108,
IHERADTF,“Organ system”)(121139, DCM,
“Modality”)

1-nU

EV (TCE109,
IHERADTF,“Category”)

1

24 >

CONTAINS

CODE

DCID (29)Acquisition
Modality

M

BCID
Table Q-2
categories
of teaching
files

25 >

CONTAINS

CODE

EV (TCE110,
IHERADTF,“Level”)

1

U

BCID
Table Q-3
levels ofteaching
files

27 >

CONTAINS

CODE

EV (TCE111,
IHERADTF,“Diagnoses
confirmed”)

1

U

DCID
(230) YesNo表 H-2: 教育用資料のカテゴリー（米国放射線専門医会）
Table H-2: Categories of Teaching Files (American Board of Radiology categories)
Coding Scheme
Designator

Code ValueIHERADTF

TCE301

Musculoskeletal

IHERADTF

TCE302

Pulmonary

IHERADTF

TCE303

Cardiovascular

IHERADTF

TCE304

Gastrointestinal

IHERADTF

TCE305

Genitourinary

IHERADTF

TCE306

Neuro

IHERADTF

TCE307

Vascular and Interventional

IHERADTF

TCE308

Nuclear

IHERADTF

TCE309Ultrasound

IHERADTF

TCE310Pediatric

IHERADTF

TCE311

BreastCoding Scheme
Designator

Code Meaning

表 H-3: 教育用資料のレベル
Table H-3: Levels of Teaching Files
Code Value

Code Meaning

IHERADTF

TCE201Primary

IHERADTF

TCE202

Intermediate

IHERADTF

TCE203

Advanced

付録 I: 識別情報削除、識別子再付与、偽名化、識別子保持と臨床試験属性（情報的内容）
De-identification, Re-identification, Pseudonymization, Persistence of Identification andClinical Trial Attributes (Informative)
I. 1

識別情報削除 De-identification

事例（instance）がいかに作成されたかの事前知識無しに、属性に含まれる個人健康情報（PHI）をすべて取り除く DICOM 事例（DICOM instance）の完全な個人識別情報削
除には、書類を含む属性や私的属性の全てを削除する必要があります。以降の利用に必要な有益な情報が、文章値（text value）に含まれるため、これはしばしば非現実的

です。
例えば、検査記述（Study Description）やシリーズ記述（Series Description）は、しばしば削除が望ましくない情報を含みます。レポートの識別情報削除は通常、レポート本体である文書値（text value）を削除しません。検査記述（Study Description）やシリーズ記述（Series Description）を、教育ファイルや治験のために、より意味のある、あるいは、より正確な記述に書き換える手段をあたえることが有益な場合もあります。
例えば、情報が書かれていない場合に、”T1 強調造影後横断像”や類似の記載をすることなどです。
日付と時間は、削除しても良いときと、しない方が良いときとがあります。例えば、来院日はある理由で削除するのが望ましいが、時刻は、検査の時間的順序を保持するために、削除しない方が良いことがあります。他にも、治療の様な実世界でのインス
タンスと関連させるために、日付は正確に保持されることもあります。
年齢と誕生日は特に問題です。これらは PHI の一部ですが、臨床試験の統計のために、あるいは、年齢が鑑別診断に影響する教育ファイル例で意味のある読影のために、年齢が必要なこともあります。典型的な方法は、年齢を年代に変更する、日時を同じ月の初日にそろえる、等です。しかし、このような方法の有効性については、専門家の意見が必要です。
さらに、施設の方針、あるいは地域の規制により、PHI を削除する固有の要求事項が加えられることがあります。この要求事項が異なっているすべての使用例において、どの属性を削除すべきかを標準化することは可能でも、望ましいことでも、ありません。
極端には、識別情報削除のため、画像データにノイズを加え、バイナリあるいはハッシュ値による合致をかく乱する、顔貌を削除する、などがおこなわれます。これはあったとしても希なことで、IHE の範囲外です。

I. 2

繰り返し送出での識別子一貫性

識別情報を、可逆的、ないし、非可逆的に新しい識別情報に入れ替えるアルゴリズム
を、暗号化一方向性要約関数に基づき工夫することは可能ですが、可能な全ての入力
値（施設の全患者の氏名と ID など）を入手できる人は誰でも、短時間の網羅的検索で同定できてしまいます。したがってこのような機構は、施設外への配布には有効な識別情報削除であっても、施設内では十分とは言えません。
代替策として、対応表を長期にわたり（データベースの様に）保持し、次回もそのレコードを参照することがあります。しかし、このような記録は良く保護されねばなりません。
同じ理由で、監査のためのデータ送出の場合には、監査追跡記録に、元の識別情報と置き換えた識別情報の両方が含まれないようにしないとなりません。
可逆的方法も、元の識別情報を保持することを許可された人物がいる場合には、ある場合には有益なことがあります。これを達成する方法は IHE では定義されていません
が、上述の対応表の長期保存方法や、DICOM PS 3.15 Basic Application Level
Confidentially Profile で記載された様に、暗号化埋込された元の属性が、使用できます。
不可逆の、しかし、反復可能な対応付は、教育ファイルに追加情報が使用可能になった時、後日更新する場合には有用です。例えば、経過観察検査やレポート、病理情報が、同じ”偽名”の識別子が使用されるため、自動的に同じティ－チングファイルに加えられ、自動的に教育ファイルの一部になります。

I. 3

臨床試験属性の付加 Addition of Clinical Trial Attributes

DICOM は臨床試験のために、複合 SOP Instance に付加可能な、追加のオプション属性を定義しています。これは、PS 3.3 の臨床試験対象、臨床試験検査、臨床試験シリーズモジュール（Clinical Trial Subject, Clinical Trial Study and Clinical Trial Series
Modules）です。

これらの属性は、以下を提供します。
 患者識別を強化する個人識別情報、例えば、臨床試験手順 ID（Clinical
Trial Protocol ID）、臨床試験施設 ID（Clinical Trial Site ID）、臨床試験対象
ID（Clinical Trial Subject ID）、の組み合わせです。
 他の、試験特異的識別情報で臨床試験業務流れに有用ですが、患者を識別する情報でないものがあります。例えば、臨床試験時点 ID（Clinical Trial
Timepoint ID）です。
これらの情報がデータ送出時までに知られている範囲で、フィールド（field）を埋めることが望ましいです。
多くの下流のシステムはこれらの属性を意識しないため、正常の DICOM 患者および他の識別情報を、臨床試験識別情報に入れ替えることがあります。例えば、臨床試験

手順 ID、臨床試験施設 ID、臨床試験対象 ID を挿入するのみならず、患者 ID を臨床試験対象 ID で、患者氏名を臨床試験手順 ID・臨床試験施設 ID・臨床試験対象 ID の連結で、施設名を臨床試験施設 ID で、それぞれ置き換えること、などがあります。
再対応付けオプションはこれらの値を自動的に入力する機能を与えます。

付録 J: 臨床判断支援（Clinical Decision Support, CDS）、および、適切使用基準（Appropriate Use Criteria, AUC）
Clinical Decision Support (CDS) and Appropriate Use Criteria (AUC) Data Explanation
この付録は現状では、臨床判断支援－オーダ適切性追跡（Ckinical Decision Support (CDS)
and Appropriate Use Criteria (AUC) Data Explanation）試験実装版です。

付録 K: 読み込み整合性業務流れでの読み込み指示取扱いオプション（Import
Reconciliation Workflow Import Instruction Handling Option）
この付録は現状では、読込み整合性業務流れ.b (Import Reconciliation Worklist.b) 試験実装版です。

付録 L: 後処理業務流れでの汎用業務リスト、SPS、PPS、および、結果複合 IOD 属性の整合
Attribute Consistency between General Purpose Worklist, SPS, PPS and Resulting
Composite IODs in Post-Processing Workflow

この付録は、後処理業務流れ（Post-Processing Workflow）の異なる参加者が生成する
対象物の属性を使用する際の、要求事項を提供します。特に、後処理管理役（PostProcessing Manager）が提供する属性のどれを、無変更のまま、GP-PPS 対象物の属性に、後処理で生成された結果に、および、業務項目を取得し完成するのに使用する NACTION 命令に、それぞれ、書き込むか、を特定します。
L. 1: 統合に不可欠の属性 Integration-critical Attributes
この表は以下の様に理解されねばなりません。


第一欄に記載の属性は、GPWL SCU（たとえば、画像処理ワークステーショ
ン、CAD 機器）が、C-FIND 要求の戻りキーとして要求せねばなりません。
後処理管理役（Post-Processing Manager）は属性の値を C-FIND 応答で返さねばなりません。



返答される属性値は、表 C1-1 の該当する行に示された属性を、作業を行う
ステーションが複合インスタンス（Composite Instances (）（第 2 欄）と GPPPS インスタンスの両方を埋めるのに使用せねばなりません。



後処理管理役 Post-Processing Manager）は、第 3 欄の該当する行に示された属性
を、SCP 型と注釈で定められた様に扱えねばなりません。
表 L.1-1: 対応する、汎用業務一覧、SPS、PPS、画像、GSPS、および、
IOD の比較付録 M: レポート業務流れでの汎用業務リスト、SPS、PPS および結果の複合 IODの整合（以前の第三巻付録 D）
Attribute Consistency between General Purpose Worklist, SPS, PPS and Resulting
Composite IODs in Reporting Workflow (previously Vol 3 Appx D)
この付録は、レポート業務流れ（Reporting Workflow）の参加者としてレポート生成役（Report Creator）が作成する診断レポートの属性を使用する際の、要求事項を提供します。このレポートは DICOM SR 対象物として符号化されます。特に、レポート管理役（Report Manager）が提供する属性のどれを、無変更のまま、GP-PPS 対象物（GPPPS objects）の属性に、生成された DICOM SR 対象物（DICOM SR objects）に、および、業務項目を取得し完成するのに使用する N-ACTION 命令に、それぞれ、書き込むか、を特定します。
M. 1: 統合に不可欠の属性 Integration-critical Attributes
この表は以下の様に理解されねばなりません。
 第一列に記載の属性は、GPWL SCU（レポート生成役（Report Creator））
が、C-FIND 要求の戻りキーとして要求せねばなりません。レポート管理役（Report Manager）は、属性の値を C-FIND 応答で返さねばなりません。
 返答される属性値は、レポート生成役（Report Creator）によって、表 M1-1の該当する行に示された属性を、複合インスタンス（第 4 列）と GP-PPS
インスタンス（GP-PPS Instances）の両方を、埋めるのに使用されねばなりません。
 レポート管理役（Report Manager ）は、第 3 列の該当する行に示された属
性を、SCP 型と注釈で定められた様に扱えねばなりません。
表 M.1-1: General Purpose Worklist, SPS, PPS, Images, GSPS その他の IODsの対応する属性の比較
Table M.1-1: Comparison of Corresponding Attributes of General Purpose
Worklist, SPS,
PPS, Images, GSPS and other IODs
General Purpose
Worklist--

General Purpose
SPS N-ACTION

General Purpose
PPS--

Referenced General
Purpose Scheduled
Procedure StepSR Based Report
Documents--

Sequence [1C]
SOP Class UID [1]

SOP Class UID [1]>SOP Class UID [1]--

SOP Instance UID [1]

SOP Instance UID[1]>SOP Instance UID[1]--Transaction UID [1]> Referenced
GeneralPurpose Scheduled
Procedure Step
Transaction UID [1]--General Purpose
Scheduled Procedure
Step Status [1]General Purpose
Scheduled Procedure
Step Status[1]----Input Information
Sequence [2]----Current Requested
Procedure Evidence
Sequence [1C]

Relevant Information
Sequence [2]----Pertinent Other
Evidence Sequence[1C]

Referenced Study
Component Sequence[2]
Resulting General
Purpose Performed
Procedure Step
Sequence [2]Referenced Study
Component Sequence[2]>Referenced SOPClass UID [1]--

SOP Class UID [1]>SOP Class UID [1]>Referenced SOP
Instance UID [1]--

SOP Instance UID[1]>SOP Instance UID[1]--Actual Human
Performers Sequence[3]

Actual Human
Performers Sequence[2]

Actual Human
Performers Sequence[2]

Study Instance UID
[1]

--

--

Study Instance UID
[1]

--

--

--

--

Scheduled ProcedureStep ID [1]Referenced Request
Sequence [1]Referenced Request
Sequence [2]Referenced Request
Sequence[1C]>Study Instance UID[1]>Study Instance UID[1]>Study Instance UID[1]>Requested Procedure
ID [1]>Requested
ProcedureID [2]>Requested Procedure
ID [2]>Requested Procedure
Description [1C]

>Requested
Procedure
Description [2]>Requested Procedure
Description [2]>Requested Procedure
Code Sequence [1C]

>Requested
Procedure
Code Sequence [2]>Requested Procedure
Code Sequence [2]>Referenced Study
Sequence [2]>Referenced Study
Sequence [2]>Referenced Study
Sequence [2]>Accession Number[2]>Accession Number[2]>Accession Number[2]>Placer Order
Number/Imaging
Service Request [3]>Placer Order
Number/Imaging
Service Request [3]>Placer Order
Number/Imaging
Service Request [2]>Filler Order
Number/Imaging
Service Request [3]>Filler Order
Number/Imaging
Service Request [3]>Filler Order
Number/Imaging
Service Request [2]>Requesting Physician[2]>Requesting
Physician[2]>Requesting Physician[2]

Performed Procedure
Step ID [1]Performed Procedure
Step Start Date [1]Performed Procedure
Step Start Time [1]Performed Procedure
Step Description [1]Appendix N. HL7 v2.5.1 で置き換えられる HL7 v2.3.1 通信文の概要（以前の第二巻付
録 E） HL7 Version 2.3.1 Message Field Replaced with HL7 Version 2.5.1
Summary (previously Vol 3 Appx E)

この付録はこのテクニカルフレームワークにて HL7 v2.3.1 通信文意味で適合化されている、想定を超えて使用されている、もしくは、旧式な通信文フィールド（message fields）と、HL7
v2.5.1 オプションで適合化されている通信文フィールド（message fields）の置き換えに関する概要です。詳細はテクニカルフレームワークのトランザクション記述を参照してください。以下の表は参考のために掲載します。
N. 1: Patient Registration [RAD-1]/ Patient Update [RAD-12]
ADT Version 2.3.1
Segment
PV1

SEQ
9ADT Version 2.5.1

Element Name
Consulting Doctor

Segment
ROL

SEQ
4

Element Name
ROLE-Person

N. 2: Placer Order Management [RAD-2]/ Filler Order Management [RAD-3]（訳者注：原本の上記表題の末尾にある[RAD-13]は誤り。上記のように[RAD-3]が正しい）
ORM/ORR Version 2.3.1
Segment

SEQ

OMG/ORG Version 2.5.1
Element

Segment

SEQ

Element Name

Name
PV1

9

Consulting

ROL

4

ROLE-Person

TQ1

7

Start Time Date

Doctor
ORC

7

Timing/Quantity

N. 3: Procedure Scheduled [RAD-4]/Procedure Update [RAD-13]
ORM Version 2.3.1
Segment

SEQ:<com
p>

PV1

9

OMI Version 2.5.1
Element
Name

Consulting

Segment

SEQ

Element Name

ROL

4

ROLE-Person

Doctor
ORC

7

Timing/Quantity

TQ1

7Start Time Date

ZDS

1Study Instance

IPC

3

Study Instance

UID

UID

ORM Version 2.3.1
Segment

SEQ:<com
p>

OBR

4:4-6

OMI Version 2.5.1
Element
Name

Universal

Segment

SEQ

Element Name

IPC

6

Protocol Code

Service ID
OBR

15Specimen
SourceOBR

46

Placer
Supplemental
Service
Information

OBR

18

Placer Field 1

IPC1

Accession
Identifier

OBR

19

Placer Field 2

IPC

2

Requested
Procedure ID

OBR

20

Filler Field 1

IPC

4

Scheduled
Procedure Step ID

OBR

24

Diagnostic
Service ID

IPC

5Modality

Appendix O: Reason for Procedure Code sets (Informative)
この付録は現在では、Encounter-based Imaging Workflow 試験実装版です。
Appendix P: HL7 v2 ORU for External Prior Reports Mapping
この付録は現在では、Import and Display of External Priors 試験実装版です。
Appendix Q: Organization of series and images into framesets
この付録は現在では、Basic Image Review 試験実装版です。

Appendix R; 意図的に空白です
Appendix S: 意図的に空白です
Appendix T: 意図的に空白です
Appendix U: 意図的に空白です
Appendix V: Attribute Consistency between UPS and Resulting Composite IODs
この付録は現在では、AI Workflow for Imaging 試験実装版です（以前の PAWF）。
Appendix W: Organization of series and images into framesets
この付録は現在では、AI Workflow for Imaging 試験実装版です。